Ebbene sì, signore e signori la convivenza è possibile e vi dirò di più è anche molto efficace. La metodologia si chiama Feature Driven Development detta anche FDD ed è stata ideata da Jeff De Luca e Peter Coad e si basa un una robusta fase di analisi e progettazione con un modello di sviluppo di tipo agile.

Il modello si sviluppa lungo 5 fasi che vi racconterò qui di seguito:

Fase 1 Sviluppare un modello generale: a questa fase partecipa il team costituito da esperti di dominio (analisti funzionali) e cliente, insieme definiscono un modello che riflette la loro comprensione condivisa degli oggetti importanti nel nuovo sistema.

Fase 2 Costruire una lista di funzionalità: in questa fase il team funzionale definisce la lista delle funzionalità in termini di azione-risultato-oggetto. Il team funzionale deve effettuare un accertamento sulla qualità delle funzionalità identificate coinvolgendo cliente ed esperti di business. In questa fase è preferibile un confronto anche con quelli che saranno gli utilizzatori futuri. E’ utile in questa fase coinvolgere anche gli Scrum Master per permettergli di avere una visione d’insieme degli obiettivi del nuovo sistema.

Fase 3 Pianificare per funzionalità: in questa fase il team funzionale ed il team di sviluppo definiscono la sequenza di sviluppo delle funzionalità.

Fase 4 Progettare per funzionalità: questa a mio parere è la fase più interessante di tutto il processo. Qui il team funzionale ed il team di sviluppo iniziano ad avviare gli sprint. Il primo a partire è il team funzionale che pianifica nel proprio sprint un set di funzionalità (sempre rispettando la sequenza definita in fase 3) e realizza la documentazione di dettaglio dei requisiti delle funzionalità. L’output di questo sprint condotto dal team funzionale abilita e fa avviare lo sprint del team di sviluppo che sempre in modalità agile pianifica lo sprint sulla base degli output prodotti dal team funzionale. Il team funzionale a fine del proprio sprint effettuerà la retrospettiva insieme a business e cliente mentre il team di sviluppo effettuerà alla retrospettiva insieme al team funzionale. Prima della fase di Planning del team di sviluppo sarà svolto un incontro che si chiama Design Meeting in cui il team funzionale ed il team di sviluppo si confrontano su quanto prodotto dal team funzionale. L’adozione di diagrammi UML può sensibilmente favorire il dialogo tra team funzionale e team di sviluppo. Il mio personale consiglio è di pianificare la durata dello sprint funzionale a 2 settimane effettuando il design meeting a valle della retrospettiva del team funzionale e impostare la durata dello sprint di sviluppo a 4 settimane.

Fase 5 Sviluppare per funzionalità: questa fase è totalmente in carico al team di sviluppo che deve pianificare il proprio sprint con l’obiettivo di avere come output dello sprint lo sviluppo di un set di funzionalità consistenti i cui test unitari e test funzionali siano eseguibili con successo.

La fase più delicata di tutte è la fase 1 perché è quella che stabilisce il modello con cui saranno definite le funzionalità da sviluppare che dovranno essere di una granularità tale da poter essere prodotte in brevi iterazioni. le fasi 1,2 e 3 sono sequenziali mentre le fasi 4 e 5 si svolgono mediante iterazioni cicliche.

C’è una cosa interessante per la rappresentazione dello stato di avanzamento di un progetto sviluppato con metodologia FDD e consiste nell’utilizzo dei diagrammi a parcheggio. Ogni posto auto rappresenta un set di funzionalità e viene colorato (verde, blu, rosso, bianco) in funzione allo stato di sviluppo. In alto a destra vengono indicate le iniziali del referente funzionale, nel corpo del riquadro sono elencate le funzionalità previste per quel blocco mentre in basso sono riportate le percentuali di avanzamento e la data di deadline per lo sviluppo del blocco di funzionalità.

Dall’esperienza di Jeff De Luca e Peter Coad, 2 settimane di analisi possono produrre requisiti che arrivano a impegnare il team di sviluppo fino a 6 mesi. Ma la cosa interessante di questo approccio è la possibilità di avviare più team di sviluppo visto che la stesura dei requisiti avviene per funzionalità consistenti che quindi possono essere sviluppate in parallelo da più team di sviluppo.