Esiste un limite di durata per il Progetto FDD quando è probabile che quei progetti falliscano a causa di fattori esterni ed interni?
Ad esempio, i progetti di XP dovrebbero essere mantenuti a breve a causa dell'apertura del concetto e dipendenti dagli individui nel team e dalla mancanza di documentazione che è vulnerabile a disturbi come perdere i membri del team e così via.
La possibilità di un fallimento del progetto è qualcosa a cui tenti di entrare presto. Se vedi che un progetto ha un'elevatissima probabilità di fallimento, o non verrà decollato, o nella fase esplorativa iniziale i rischi identificati dovranno essere gestiti. Come nell'esempio OP, le persone che si ammalano o lasciano la squadra sono fattori che possono verificarsi in qualsiasi progetto, e un buon pianificatore di progetto proverà a creare un po 'di margine addizionale nel programma per cercare di risolvere i problemi "imprevisti" che potrebbero sorgere.
Il problema di una mancanza di documentazione non dovrebbe sorgere su un progetto FDD, poiché è un metodo molto pesante per gli artefatti. Inoltre, la mancanza di documentazione su un XP o un processo agile per estendere l'esempio OPs non dovrebbe essere un problema per un processo agile se il codice è scritto per essere leggibile, ei requisiti sono stati elencati e fascicolati in modo appropriato.
Quindi un limite di "durata" in realtà non ha molto senso secondo la domanda degli OP, poiché la durata di un progetto FDD è di solito qualcosa che viene fissato per contratto. I deliverable all'interno della durata del progetto vengono generalmente definiti come set di caratteristiche e la durata di un set di funzionalità sarà variabile in quanto dipende dal numero e dalla complessità delle funzionalità implementate.
Tuttavia, FDD è anche quello che mi piace pensare come una metodologia wrapper, in quanto nell'ambito delle fasi di sviluppo / test, i set di funzionalità possono essere trattati come mini-progetti in sé stessi e potrebbero essere implementati utilizzando un Metodologia agile se si ritiene che offra valore al progetto e a tutti i suoi stakeholder. Quello che FDD offre davvero è una collezione di artefatti - e in particolare i report - che possono essere utilizzati per misurare i progressi del progetto, e questo è particolarmente importante quando è visto come difficile da offrire codice di lavoro alla fine di ogni iterazione, come il cliente vuole sapere che mesi di sviluppo in cui non vedono quello che stanno pagando sono stati spesi fruttuosamente. Pertanto, laddove i rischi sono alti e i moduli di lavoro sono specificati contrattualmente solo per un numero limitato di intervalli per un lungo periodo di tempo, i risultati finali sotto forma di report e altri artefatti del progetto possono essere utilizzati per attenuare alcuni dei problemi che possono sorgere quando un progetto sembra che potrebbe essere fuori dai binari. Prima possono essere consegnati i report / grafici di parcheggio / ecc ..., prima si possono prendere misure per cercare di mantenere un progetto in pista o limitare i danni che potrebbero verificarsi nel tempo.
Qualsiasi progetto in cui esiste un alto rischio di fallimento dovrebbe mirare a fornire qualcosa il prima possibile.
Questo è vantaggioso per diversi motivi:
Questo è vero indipendentemente dall'approccio che usi per lo sviluppo.
Ovviamente la durata esatta di ogni fase / fase / sprint dipenderà dallo sforzo di sviluppo che puoi inserire e dall'insieme minimo di requisiti che devono essere soddisfatti ad ogni iterazione.
Leggi altre domande sui tag project-management agile