Cosa dovrebbe accadere all'avvio di un avvio di un progetto software?

Per il progetto specifico non c'è molto che puoi fare fino a quando non scopri cosa vuole il cliente. Tuttavia, ci sono alcune cose che puoi fare ora, in modo che il tuo team sia pronto.

1. Come gestirai il controllo della versione?
2. Farai le revisioni del codice?
3. Quando si terranno gli incontri giornalieri in piedi? Quali sono le regole?
4. Che ruolo giocano tutti?
5. Come vengono gestite le build?
6. Dove mettere i documenti in modo che tutti possano avere accesso?

Chiedi al gruppo di lavorare su un progetto molto semplice per testare tutto questo in una lingua richiesta o sceglierne uno familiare.

1. Configura il tuo sistema di controllo della versione e documenta la sua configurazione
2. Configura un sistema di build automatico
3. Imposta test unitari automatizzati che si integrano con il sistema di build
4. Configura un server web per pubblicare contenuti statici come documenti e report generati automaticamente dal tuo Sistema di integrazione continua.
5. Configura un server di Continuous Integration per eseguire build e test e pubblicare i risultati

6. Configura un Wiki da utilizzare per la documentazione "live" del progetto e altre cose.

7. Determina cosa intenderai utilizzare per gestire il tuo backlog di funzioni e attività

8. Determina chi è il proprietario del prodotto e responsabile del monitoraggio di tutto il lavoro
9. Determina chi assicurerà che il team rimanga concentrato sul lavoro impegnato
10. Determina la frequenza con cui verranno rilasciate le build al proprietario del tuo prodotto e rispetta questa pianificazione.

Il mio allarme interno sta squillando quando vedo the opportunity to start specifying the requirements e these items didn't take that long to finish insieme. Mentre altre risposte forniscono ottimi modi per creare un ambiente sano, sii certo che uno dei maggiori pericoli è nelle specifiche. Quindi potresti passare un po 'di tempo in questa fase. Può essere una settimana (a tempo pieno) nel tuo progetto di 8 settimane.

La parte difficile è trovare la specifica mancante e le cose che non funzionano nelle specifiche attuali. È davvero difficile criticare il tuo lavoro. Quello che dovresti fare è un po 'o un gioco di ruolo. Alcune persone sono il cliente e l'altro i membri del progetto. Il cliente è qualcuno che giudicherà il tuo lavoro (insegnante, mentore ...). Potrebbe essere un membro esterno del progetto (trovare qualcuno con una certa esperienza con questo tipo di progetto). L'iterazione dovrebbe andare in questo modo:

• client legge i requisiti
Il client
• fa domande sui requisiti mancanti, sulle specifiche delle caratteristiche, sulla valutazione dei possibili errori, sull'organizzazione dei test, sulla scelta del framework ...
• team di progetto risponde & aggiorna i documenti

Se non sai cosa vuoi fare, puoi iniziare a configurare un flusso di lavoro per il tuo team.

Alla fine di questo lavoro dovresti avere una serie di funzionalità con la ripartizione delle attività di base per ognuna di esse. Impostare le pietre miliari (settimana 3 abbiamo bisogno di avere un milestone finito 1 e 2, settimana 6 abbiamo bisogno di avere un codice sorgente stabile per testarlo nelle settimane 7 e 8 e attenersi a piccoli bugfix + documentazione di scrittura ...). Quando si avvia una pietra miliare, pubblicare un elenco di attività da qualche parte (è possibile utilizzare un foglio Excel o anche un bug tracker per questo) e concordare chi inizia con cosa. Quando qualcuno finisce il suo compito, ne prende un altro (e ne parla). Prima di questo, qualcun altro dovrebbe dare una rapida occhiata a ciò che ha fatto per verificare se è corretto e completo.

Configurare tutto questo flusso di lavoro è un po 'difficile per i principianti, ma è molto più importante che avere un buon servizio wiki. Devi prendere almeno una settimana per pensare a come lavorerai. Non è necessario applicare l'organizzazione che ho descritto qui (questo è solo un esempio), ma è necessario dedicare del tempo a pensare a tutto ciò che funziona con voi e impostare gli strumenti necessari. L'obiettivo è coinvolgere tutti. Ci dovrebbe sempre essere una risposta facile alla domanda "cosa dovrei fare ora?".

Sì, l'avvio di un progetto è lento e spesso non riempie l'intera giornata a causa della necessità di concertare con altri che potrebbero avere il proprio programma. (Alcune altre domande hanno proposto cose che potresti voler considerare, ma il partner dell'azienda nel tuo progetto potrebbe anche averne bisogno, parlarne e essere pronto a proporre qualcosa se non ha importanza per loro).

Torna a quello che penso sia il nocciolo della tua domanda. Nella mia pratica, l'avvio di un progetto viene eseguito in modo incrementale: solo una parte del team inizia a lavorare sul nuovo progetto e solo a un tempo parziale, completando il precedente.

Cosa dovrebbe accadere all'inizio di un progetto software? Come funziona nel "mondo reale"? Trascorri il tuo tempo a chiedersi "cosa dovrei fare ora" o hai una visione chiara di ciò che dovresti fare in quel momento?

Quello che cerco di fare all'inizio di un progetto software è passare del tempo a conoscere le persone con cui lavoro.

Mi piace sviluppare e modificare le pratiche e le procedure del team nel tempo, tuttavia l'inizio di un progetto o di una squadra può essere un buon momento per concordare alcune regole iniziali o "carta".

Cerca di trovare un modo di lavorare insieme che funzioni per il team per qualsiasi situazione e mix di membri che hai e trova i migliori strumenti per e-mail, im, tracciamento dei biglietti, wiki, ecc. per la situazione attuale. Acquisisci dimestichezza con l'utilizzo e l'adattamento di questi strumenti per soddisfare le tue esigenze specifiche in modo che, quando arriva il momento per le modifiche rapide, tu sia esperto nel farle.