checklist per la consegna del lavoro [duplicato]

Non preoccuparti del formato della documentazione. Mi limiterò a un documento semplice, piuttosto che a un wiki: è facile distrarsi dai problemi meccanici e sprecare tempo prezioso che sarebbe meglio spendere per documentare le cose.

Punti importanti da documentare:

1. Interfacce. Assicurati di identificare almeno ciascuna interfaccia.
2. Processo di creazione. Dove sono tutti i pezzi? Come metterlo insieme in una build funzionante? Dove sono finiti i casi di test (se ce ne sono stati)?
3. Altri strumenti. Cosa è necessario per lavorare e / o finire il software? Quali ambienti, compilatori, computer, ecc.? Cosa è necessario per implementare il software?
4. Che cosa non è fatto? Quali sono i compiti che devono essere completati per completare il software? Cosa è stato testato finora?
5. Risorse. Chi altro è coinvolto? Dove sono i requisiti, se ce ne sono? Chi deve firmare il software? Chi è il cliente?

Le domande più importanti a cui rispondere nella documentazione:

• Dov'è il codice? (Accesso SCM, ecc.)
• Di cosa ho bisogno per lavorare su di esso (compilare, testare, eseguire, distribuire)?
• Come posso configurare il mio ambiente di sviluppo?
• Dove posso iniziare a leggere?
• Quali sono i trucchi?
• Qualcos'altro fuori dall'ordinario?

Probabilmente è anche bello includere informazioni sulla squadra, ma dipende dalla situazione se ne hai bisogno.

Suppongo tu abbia una specie di bug & funzionalità di tracciamento sul posto; se non lo fai, devi anche includere tutto ciò che normalmente inseriresti lì, che è:

• bug noti
• work in progress
• funzionalità richieste

Informazioni dettagliate su certe parti del codice, come peculiarità specifiche di una particolare funzione, sono meglio lasciate nei commenti nel codice sorgente stesso. Assicurati che siano completi, accurati e utili. E mentre ci sei: rimuovi il codice inutilizzato / commentato, esegui una pulizia generale, rivisita tutto ciò su cui hai lavorato (se possibile).

Il modo migliore per affrontarlo è dalla tua prospettiva. Dato ciò che ora sai dei tuoi progetti, chiediti cosa avresti voluto sapere il primo giorno, quando hai iniziato a lavorare. Quindi, organizza queste informazioni in un documento di struttura, sia che sia scritto in un wiki o che utilizzi un elaboratore di testi. Se qualcuno dei tuoi attuali collaboratori assumerà il progetto, lavorerà anche con loro e vedrà cosa potrebbe cercare.

Dovresti anche aggiornare qualsiasi documentazione esistente, ma potrebbe non essere aggiornata. Niente è peggiore di una specifica, un documento di progettazione o anche un manuale utente che non corrisponde allo stato attuale dell'applicazione. Personalmente, prima di iniziare lo sviluppo, leggo tutto ciò che posso associare al progetto per dare un'idea all'utente finale, i requisiti, lo sviluppatore precedente e le indicazioni e le influenze sul progetto. I documenti obsoleti ostacolano davvero questo sforzo.

Sono d'accordo con il fatto che non è necessario mettere il cuore e l'anima in un sistema di documentazione complesso. Alger ha risposto a quali informazioni è necessario passare. Inoltre, non dimenticare di annotare le molte password che potresti essere l'unico a sapere.

Sto utilizzando personalmente TiddlyWiki che è un mini wiki memorizzato in un file HTML. È davvero un ottimo strumento per archiviare varie informazioni e per passare le informazioni necessarie per dare il file HTML al nuovo ragazzo. Ognuno dei ragazzi ha il suo, e abbiamo anche un mini wiki "nuovo arrivato" che aggiorniamo continuamente e che danno ogni volta che arriva un nuovo sviluppatore. Contiene varie informazioni come dove trovare software, repository di sorgenti di codice, chi è il responsabile di un determinato progetto Java, ecc.