Lavoro per una piccola azienda. Il braccio di sviluppo software della società prima che venissi assunto era costituito da un ragazzo autodidatta oberato di lavoro. Ora che scrivo software per l'azienda da alcuni anni, mi è stato affidato il compito di stabilire pratiche formali di sviluppo software a livello aziendale. Al momento non abbiamo linee guida, a parte

Scrivi il codice, testalo, mettilo in un file .zip e invialo al client. Punti bonus per TDD e controllo della versione.

Il mio capo vuole che scriva un manuale per sviluppatori di software che definisce i processi generali, i protocolli, gli strumenti e le linee guida che usiamo per fare le cose. In altre parole, vuole un libro "Questo è quello che facciamo qui" per rendere più facile far conoscere a un nuovo dipendente il modo in cui facciamo le cose, oltre ad aiutare il mio capo a capire cosa stanno facendo i suoi seguaci e come fanno esso.

Per come la vedo, sto gettando le basi e deve essere fatto bene. Come sceglieresti argomenti per un simile manuale? Potete fornire alcuni esempi di argomenti?

Nota a margine: se è importante, siamo principalmente un negozio Microsoft .NET. E stiamo esaminando pratiche agili come XP e Scrum, ma potremmo doverle modificare pesantemente per farle funzionare nella nostra azienda.

Lo spezzerei in sezioni come

• Personale attuale - nomi e titoli (idealmente con foto)
• Applicazioni, accessi, dati da conoscere e richieste di autorizzazione da inviare
• Segnalibri per siti aziendali e siti chiave esterni rilevanti per l'azienda
• Applicazioni che l'azienda utilizza per comunicazioni, e-mail, prenotazione di sale conferenze, schermo condiviso
• Procedure per attività connesse all'azienda come spese di spesa, prenotazione viaggi
• Impostazione macchina sviluppatore. Descrivere in dettaglio il processo di impostazione di una nuova macchina per sviluppatori. Di solito, ci si aspetta che questo richieda solo un giorno, ma spesso ci vogliono 3-5 giorni nella realtà.
• Il processo di sviluppo, il modo in cui il lavoro viene monitorato, assegnato e aggiornato e quali strumenti vengono utilizzati.
• Come testare, cosa testare, quando testare, dove testare.
• Standard di codifica incluse convenzioni di denominazione dei file e standard specifici della lingua.
• Come gestire i bug, dove documentarli, come risolverli.
• processo di distribuzione, quali sono le cose chiave da sapere per le spinte di produzione.
• Come documentare, cosa documentare, quando documentare.
• Dove roba "è", ad es. Posizione (i) per codice, dati, standard, documentazione, collegamenti e altre risorse.

Renderlo modulare consentirà anche a te o ad altri di aggiornare i pezzi separatamente, ad esempio i nomi e le posizioni dei dipendenti cambieranno frequentemente man mano che le persone vanno e vengono.

Per ogni sezione farei del mio meglio per scriverlo da un punto di vista "da principiante". La cosa più importante sarà assicurarsi che abbia davvero senso per un principiante. Il tuo capo, ovviamente, non è la persona giusta per esaminarlo perché non è il pubblico previsto. Ha ragione a volerlo, assicurati solo che il contenuto non finisca per essere testato da lui. Anche un "principiante" ha entrambi "1 settimana" solo come principiante ... e ha solo un punto di vista. Quindi è probabile (e raccomandato) che il documento venga perfezionato con ogni nuovo dipendente. In effetti è un compito piuttosto buono assegnarli anche alla loro prima settimana, ovvero "Aggiorna il manuale per principianti".

Per Agile / SCRUM:

La parte più difficile del fare Agile e SCRUM è "davvero" farlo.

Per leggere vorrei iniziare su http://agilemanifesto.org/ e andare da lì.

Vorrei anche leggere il noto http://www.halfarsedagilemanifesto.org/ che aggiunge peso al fatto che devi davvero abbracciare tutti gli aspetti affinché funzioni. Se è necessario modificare fortemente Agile per le proprie organizzazioni, è probabile che le persone desiderino i vantaggi, senza utilizzare i processi corretti. Questo fatto in sé dovrebbe essere presentato per scongiurare qualsiasi mezzo assurdo.

Sembra che dovrai introdurre alcune pratiche prima di documentarle!

a) Controllo delle fonti: come archiviare le fonti e eseguire il controllo delle revisioni

b) Gestione e tracciamento delle versioni: come si fa a creare una build, numerare una versione, confrontare un candidato alla versione corrente con una versione precedente

c) Gestione dei problemi - come tenere traccia dei bug nelle tue versioni.

Queste sono cose piuttosto basilari ma possono impiegare molto tempo (e possibilmente costare denaro) per essere implementate.

Argomenti che vorrei includere nel manuale di uno sviluppatore:

• Ruoli / posizioni all'interno del dipartimento e relative responsabilità
• Requisiti software della macchina per sviluppatori (ovvero ambiente di sviluppo richiesto)
• Dove e come accedere al repository del codice sorgente
• Strumenti di sviluppo utilizzati (ad es. IDE)
• Stile / standard di codifica
• Standard di documentazione
• Processo di test
• Processo di costruzione
• Processo di distribuzione
• Supporto e processo di gestione dei problemi
• Dove ottenere la versione più aggiornata di questo manuale

Tieni presente che questo manuale dovrebbe contenere solo elementi specifici per lo sviluppo e non informazioni a livello aziendale (che dovrebbero essere contenute in un manuale per i dipendenti).

Uso del controllo del codice sorgente

• Quale strumento di controllo del codice sorgente stai utilizzando.
• Sintassi di comandi / strumenti comuni nell'IDE.
• Strategia di diramazione / unione.
• Quale dovrebbe essere l'unità di un commit? Quanto tempo è troppo lungo per il checkout / il commit di un file?
• Quale livello di "doneness" indica un commit / check-in? Compila? Passano i test unitari? Rivisto?
• Cosa dovrebbe essere incluso nelle note per un commit / check-in.
• Procedure di rollback.