Come pianificare enormi progetti software?

Question

Abbiamo avviato un grande progetto. Sappiamo cosa deve sembrare ma non come implementarlo. Abbiamo iniziato scrivendo prototipi per testare diverse implementazioni. Quello che ci manca è la panoramica dei progressi generali dello sviluppo. Non sappiamo se dedichiamo troppo tempo ai dettagli o se quei dettagli sono abbastanza importanti da passare il tempo.

Ho iniziato creando un elenco di attività che dobbiamo svolgere, ad esempio "implementa funzionalità X", "controlla come implementare Y". Ora ho una grande mappa mentale con circa 500 compiti. Il prossimo passo che potrei fare è definire le dipendenze tra le attività. In questo modo, saprei cosa mettere in pratica per prima cosa e le attività che più dipendono sono le più critiche. Ma non posso fare questo tipo di ordinamento con lo strumento mappa mentale. È molto frustrante.

Come pianificare progetti software enormi?

Answer 1

Questo è ciò che mi ha aiutato a iniziare:

[1 ] Iniziare con un documento requisiti. Scrivi dal punto di vista dei clienti. Scrivi tutto ciò che il software dovrebbe essere in grado di fare. Evita di dare soluzioni. Sii esplicito. Se una funzionalità riceve input specificare cosa esattamente si può aspettare, quanto dovrebbe aspettarsi e come dovrebbe agire in situazioni di errore.

Non dimenticare di specificare i limiti. Tutto ha un limite. Se la tua soluzione gestirà account quanti dovrebbero essere in grado di gestire? 20 o 10 milioni?

Il documento dei requisiti deve includere requisiti funzionali e non requisiti funzionali. I requisiti non funzionali sono: prestazioni, stabilità, utilizzo delle risorse, sicurezza e così via.

[2] requisiti Quando hai finito specificando danno ogni esigenza un punteggio importanza: deve avere, importante, opzionale.

[3] Ora scrivere un documento in cui si specifica come sarà attuato ogni esigenza. Stai attento con i dettagli. Non andare in profondità Vai per la regola del 20/80. Specifica il 20% della funzionalità in profondità, che influirà sull'80% della soluzione.

Probabilmente noterete che non è possibile descrivere come verranno implementati tutti i requisiti. Va bene scrivere "Non ho idea di come implementarlo". Ma è importante che tu lo scriva! La quantità di "non so" ti dirà quanto è rischioso il tuo progetto.

[4] Il passaggio successivo è creare un elenco di attività. Avrai bisogno di sapere cosa devi fare in realtà. Per ogni esigenza avrai un paio di compiti da eseguire.

Uno di questi compiti è scoprire come implementare i requisiti "non so". Non cercare di chiarire ogni "non so". Vai per il must-have e quelli importanti. Chiarire alcuni dei "non so" potrebbe anche essere un mini progetto secondario.

[5] Una volta che i tuoi compiti stimano il tempo necessario per completarli. Non essere timido stimare. È impossibile valutare con precisione quando si è all'inizio del progetto. Man mano che il progetto procede, le attività verranno rideterminate e le stime diventeranno più accurate.

È stato molto utile per me fare le cosiddette stime a tre punti. Stima il tempo che ti servirà se tutto andrà bene. Questo è il tuo momento ottimista. Quindi stimare quanto tempo ci vorrà se si incontrano problemi. Questo è il tuo tempo pessimista. Quindi stimare un tempo realistico. L'intervallo tra tempo ottimistico e pessimistico ti dirà quanto sei incerto sull'implementazione.

[6] Ora dovrai portare i compiti nell'ordine in cui saranno implementati. Alcune delle attività avranno dipendenze che il tuo ordine dovrà riflettere. C'è un ottimo strumento per aiutarti a visualizzare questo ordine: il tuo muro dell'ufficio. Scrivi i tuoi compiti su post-it e mettili sul muro. Sul serio. Ha funzionato molto bene per me.

[7] Ora sei già nel bel mezzo del tuo progetto. La somma delle tue stime ti darà due date di rilascio (l'ottimista e il pessimista). È possibile impostare pietre miliari. Aggiorna periodicamente le stime per le tue attività. La modifica della data di rilascio calcolata ti dirà come ti stai comportando.

Answer 2

Fai il tuo lavoro in iterazioni. Concentrati su ciò che è essenziale per una particolare iterazione. se ti concentri su tutti i dettagli allo stesso tempo, fallirai.

In primo luogo, decidere quali funzioni generali si desidera avere e progettare per questo.

Nei prossimi passaggi si aggiungeranno sempre più funzionalità avanzate.

Quando si ha un'architettura wireframe stabile, è possibile dividere il progetto in moduli e distribuirli a più team. Anche le squadre lavoreranno in iterazioni.

Nessuno può progettare un enorme progetto software dall'inizio. Un enorme progetto sta crescendo lentamente, con tutti i soliti problemi dell'infanzia.

Answer 3

Ci sono un certo numero di buoni articoli e libri su questo argomento. Ma in breve, abbattere le dipendenze, mantenere le cose semplici ma flessibili e iniziare scrivendo rapidamente componenti codificabili - questo ti dà un "feeling" molto migliore per come devi fare le cose. Preparati all'evoluzione dei tuoi progetti e preparati a riscrivere un bel po 'di codice.

Non provare a scrivere il sistema perfetto da zero. Impostare per scrivere un sistema semplicistico e si potrebbe, per caso, finire per scrivere il sistema perfetto.

Answer 4

Un boccone alla volta.

Seriamente, guardare l'intera faccenda è buona se non si è completamente concentrati. Dobbiamo scomporlo in progetti sempre più piccoli finché non riusciremo a circondarlo.

Se non si è già andati in questo modo, le metodologie Agile funzionano meglio. Scrum è ottimo, XP è buono. Questi usano le iterazioni, che stanno ottenendo pochi elementi di funzionalità il più rapidamente possibile.

Cercare di abbracciare il tutto è davvero, davvero difficile e l'ho trovato estremamente demotivante. Ma con una tecnica Agile, gli utenti vedono i progressi immediatamente e il nostro team si entusiasma perché il loro codice viene utilizzato nella vita reale.

Answer 5

Tutto questo dovrebbe provenire dal documento dei requisiti del progetto, questo vi permetterà di sapere quali caratteristiche sono effettivamente richieste e quali caratteristiche sono state aggiunte in ambito di creep. Assicurati di attuare ciò che vogliono.

Il mio consiglio parla sempre con la persona a cui è necessario consegnare il progetto, con un programma di quando sarà completata la funzione x importante. La scoperta di ciò che deve essere fatto è un inizio attraverso un documento dei requisiti e per grandi priorità di progetto (e piccole) stabilite su quale attività dovrebbe essere consegnata per prima.

Talk Talk Talk è il modo migliore per assicurarsi che tutti sappiano cosa sta succedendo in ogni momento.

Answer 6

Inizia con 1 peice, sviluppalo, perfezionalo e impara da esso. Dopo averlo fatto, passa al pezzo successivo. Come fai ogni pezzo, aggiungi alla tua libreria di codice riutilizzabile. Mentre procedi, il processo dovrebbe essere più raffinato e il tempo di sviluppo dovrebbe ridursi. La cosa peggiore che puoi fare è sviluppare tutto in un approccio basato sulla cascata. Ottieni qualcosa funzionante e perfetto, questo non solo ti consentirà di mostrare i pezzi funzionanti dei capi, ma ti permetterà anche di trovare il tuo naturale equilibrio tra pianificazione e codifica.

Se si desidera un modo formale di pianificare, suggerirei uno sviluppo agile. Ti fornirà una buona guida su come pianificare i tuoi compiti ed eseguirli. Ma penso ancora che un team di sviluppo cadrà in un ritmo che gli offre il meglio e un approccio incrementale lo consentirà.

Answer 7

Ovviamente si vuole abbattere in pezzi più piccoli, ricordate quando si fa il (WBS) WBS a rompere non solo verso il basso per pezzi più piccoli, ma a anche:

• definiscono quali pezzi saranno lavorato prima (prioritize dei più importanti di business)
• piano alla consegna, molti progetti consegnano il codice ma poi hanno un momento difficile nella promozione, pianificano come ogni rilascio verrà consegnato e potenziali impatti agli utenti
• ottenere qualcosa fatto presto/rapidamente - nulla crea fiducia come una vittoria iniziale
• sviluppare il piano di comunicazione - chi deve sapere cosa e quando - Es: per ogni versione iterativa che deve essere notificato alla modifica/impatto
• determinare se si rivaluterà il feedback durante le pubblicazioni per determinare se l'ordine di consegna o la funzionalità è cambiato
• rende conto che quanto prima si rilascia alla produzione più presto è necessario sostenerlo, oltre che continuare con lo sviluppo