Feature Driven Development

Il feature driven development è una metodologia agile, ideata da Jeff De Luca e Peter Coad, che propone una robusta fase di analisi e progettazione integrata con un modello di sviluppo agile.

Come s'intuisce dal nome è una forma di sviluppo guidata dalle funzionalità richieste e necessarie del programma. Sono disponibili diversi strumenti di supporto free, alcuni anche open source, pur strettamente basata sull'utilizzo del UML e naturalmente sulla versione colorata del UML ideata dagli autori. Inoltre esiste una community molto attiva che si occupa di questa metodologia e degli strumenti utili per automatizzarne l'utilizzo, sviluppandoli e confrontandosi.

È forse il miglior compromesso e la miglior soluzione agile possibile, ma è molto meno conosciuta di Extreme Programming, pur essendo indicata nell'Agile Manifesto. Serguei Khramtchenko fa un confronto diretto (vedi Bibliografia) dal quale emerge sorprendentemente che Feature Driven Development è addirittura più flessibile di Extreme Programming anche se la prima ha una fase di progettazione classica che la seconda elimina proprio per guadagnarne in flessibilità.

Storia

FDD è stato inventato da Jeff De Luca nel 1997, che propose un insieme di cinque processi che riguardavano lo sviluppo completo basato sulle features. Tale modello era fortemente basato sulle idee di Peter Coad e integrato dall'esperienza personale. La prima forma strutturata di FDD fu presentata nel libro Java Modeling in Color with UML dello stesso Coad, Eric Lefebvre and Jeff De Luca nel 1999; in seguito una versione più generale fu pubblicata nel libro di Stephen Palmer e Mac Felsing A Practical Guide to Feature-Driven Development . Ulteriori informazioni storiche si possono trovare nel sito personale di Jeff De Luca.

Le fasi di sviluppo

Il progetto viene diviso in cinque fasi, dette processi:

• sviluppare un modello generale
  • criteri d'ingresso: avere scelto gli esperti del problema, i capi-programmatori ed il capo-architetto;
  • attività: il project manager deve formare il team di modellazione; il team di modellazione deve offrire una panoramica del dominio del problema, preparare i documenti funzionali e, diviso in piccoli gruppi, sviluppare il modello; il capo-architetto deve rifinire il modello generale ad oggetti insieme al team di modellazione e scrivere le note al modello insieme ai capi-programmatori;
  • verifica: il team di modellazione deve effettuare un accertamento interno ed esterno con riferimento agli esperti di business ed ai futuri utenti;
  • criteri d'uscita: avere definito il modello ad oggetti avendo quindi a disposizione i diagrammi delle classi, i metodi e gli attributi delle classi, la sequenza delle classi (se esiste), le note al modello;
• costruire una lista di funzionalità
  • criteri d'ingresso: avere scelto gli esperti del problema, il capo-programmatore ed i capi-architetti;
  • attività: il project manager deve formare il team della lista delle funzionalità che deve comprendere i capi-programmatori del team di modellazione; il team della lista delle funzionalità deve definire la lista delle funzionalità in termini di azione-risultato-oggetto;
  • verifica: il team della lista delle funzionalità deve effettuare un accertamento interno ed esterno con riferimento agli esperti di business ed ai futuri utenti;
  • criteri d'uscita: avere definito la lista delle funzionalità avendo quindi a disposizione la lista delle aree oggetto, la lista delle attività di business per ogni area oggetto, la lista delle funzionalità che soddisfino tutti i punti di ogni lista delle attività;
• pianificare per funzionalità
  • criteri d'ingresso: è stato portato a termine il processo costruire una lista di funzionalità;
  • attività: il project manager deve formare il team di progettazione che comprende capi-programmatori e manager dello sviluppo; il team di progettazione deve definire la sequenza di sviluppo, assegnare le attività di business ai capi-programmatori ed assegnare le classi agli sviluppatori;
  • verifica: il team di progettazione deve effettuare un'autoverifica sul lavoro svolto;
  • criteri d'uscita: avere definito un piano di sviluppo comprendente le attività di business con le date di completamento ed i capi-programmatori responsabili assegnati, la date di completamento delle aree oggetto (derivate da quelle delle attività di business), la lista delle classi con relativi sviluppatori;
• progettare per funzionalità
  • criteri d'ingresso: è stato portato a termine il processo pianificare per funzionalità;
  • attività: ogni capo-programmatore forma il team delle funzionalità; ogni esperto del problema definisce la strada per affrontare il problema e risolverlo; il team delle funzionalità studia i documenti dei requisiti delle proprie funzionalità; il team di progettazione sviluppa i diagrammi di sequenza; il capo-programmatore raffina il modello ad oggetti per definire se scrivere o modificare classi, metodi, attributi; il team delle funzionalità scrive le classi e gli header dei metodi;
  • verifica: il team delle funzionalità ispeziona il progetto in tutti i suoi aspetti funzionali e temporali;
  • criteri d'uscita: avere definito un pacchetto di progettazione completo che comprenda un documento esplicativo dell'intero progetto con le specifiche referenziate (se esistono riferimenti), i diagrammi di sequenza, le alternative di progetto (se esistono), il modello ad oggetti completo di classi, metodi e attributi, gli header di classi e metodi, una todo list con un calendario delle scadenze per ogni attività ed ogni membro del team;
• sviluppare per funzionalità
  • criteri d'ingresso: è stato portato a termine il processo pianificare per funzionalità ed è stato ispezionato con successo il progetto in tutti i suoi aspetti funzionali e temporali;
  • attività: il team delle funzionalità implementa classi e metodi, ispeziona il codice ed effettua i test unitari; il capo-programmatore decide (dopo i test unitari) insieme al team delle funzionalità quali classi siano promuovibili come utili alla costruzione del progetto in riguardo alle funzionalità richieste;
  • verifica: il capo-programmatore sovrintende affinché siano completate effettivamente in tutti i punti dal team delle funzionalità l'ispezione dei codici e la soddisfazione dei test unitari;
  • criteri d'uscita: avere ottenuto classi e metodi che siano stati ispezionati e testati con successo, infine promossi all'integrazione nel progetto (ovviamente a copertura di tutte le funzionalità previste).

In pratica si può ridurre l'iterazione al semplice ciclo composto dai soli ultimi due passi: definire una lista di funzionalità / sviluppare per funzionalità. Il processo critico è il primo, ossia sviluppare un modello generale, ed è questo deve dare in uscita la documentazione UML. Questi diagrammi devono essere impostati in maniera tale da ottenere una frammentazione (una granularità) dall'alto verso il basso, in modo da avere funzionalità da sviluppare che possano essere prodotte in brevi iterazioni. Queste funzionalità devono poi essere riunite in un singolo package alla fine di ogni iterazione.

Ogni iterazione è composta da sei fasi:

• Kickoff Meeting del Package (viene chiarito ogni dettaglio delle funzionalità incluse);
• Design (vengono definiti classi/metodi/documentazioni richiesti);
• Design review (tutti gli attori dello sviluppo revisionano il progetto proposto);
• Development (si implementa il codice previsto con i relativi unit test);
• Code review meeting (la revisione del codice viene effettuata da tutti i programmatori);
• Release meeting (le funzionalità implementate vengono "promosse" al processo di integrazione).

Il processo di sviluppo

La collezione dei requisiti dell'utente e delle specifiche, avviene coinvolgendo il cliente anche durante lo sviluppo del progetto e non solo in una fase iniziale. Inizialmente si ottengono una lista di funzionalità richieste, che diventerà la base della timeline del progetto, ed uno o più diagrammi UML che definiscano il dominio del problema. Partendo da questa base, cliente e sviluppatori lavoreranno insieme ai requisiti in brevi iterazioni che coprano frammenti di business.

C'è da aspettarsi che siano necessari 6 mesi di sviluppo per completare i processi modellati in 2 settimane di riunioni preliminari con il cliente.

Feature Driven Development non richiede esplicitamente la stesura di documentazione, ma obbliga all'utilizzo dei diagrammi UML. Questo per avere una base decisionale che sia stabile durante tutto il processo di sviluppo, solo in seconda battuta sarà utile per scrivere una documentazione formale, se richiesta.

Nel corso del progetto ci sono molti documenti che devono essere disponibili per i diversi attori, quindi la miglior soluzione è organizzare un sito web interno che contenga tutte le informazioni sul progetto: la lista di sviluppatori ed esperti del problema, il modello UML con i commenti, i forum di discussione, le convenzioni di scrittura del codice, la lista degli strumenti e delle librerie usate, i report dei test unitari, lo status del progetto, la timeline comprensiva della pianificazione futura, ecc...

Durante lo sviluppo, organizzato in iterazioni brevi, si forma una struttura gerarchica con figure a metà strada fra il project manager e gli sviluppatori: i capi-programmatori. Questi sono a capo di ogni singola iterazione, che quindi possono essere numerose e procedere parallelamente, scegliendo anche il team (composto da 3-5 persone) che se ne occuperà.

L'esperienza dei capi-programmatori e la frammentazione del lavoro in iterazioni, sono i meccanismi di controllo e regolazione di Feature Driven Development. All'inizio di ogni iterazione si organizzano delle riunioni di progettazione che servono a far confrontare i membri del team e ad ottenere la documentazione del codice.

La stesura del codice prevede l'utilizzo rigoroso di uno standard comune di scrittura e il ricorso ad i test unitari, che possono essere organizzati a discrezione dei capi-programmatori.

Date le numerose riunioni effettuate prima di cominciare a scrivere il codice, questa attività diventa qualcosa di meccanico, infatti Feature Driven Development scoraggia l'uso di pratiche tipo il Refactoring mentre incoraggia la condivisione del codice prodotto (in maniera particolare della documentazione relativa) fra i diversi programmatori.

Per la revisione del codice si va oltre il Pair programming visto che la condivisione all'interno del team dell'iterazione permette una verifica molto più ampia. In ogni caso è proprio per permettere la miglior revisione possibile del codice che i team di sviluppo devono essere poco numerosi e che le iterazioni devono essere brevi, fra 1 e 3 settimane.

Il rilascio delle versioni è previsto per la fine di ogni iterazione, raramente di più iterazioni, ma ciò permette di coinvolgere molto di meno il cliente rispetto a quanto facciano le altre metodologie leggere. E permette anche di non consegnare alcune versioni intermedie quando le condizioni al contorno non lo rendano possibile, ad esempio in caso di software medici embedded.

Tenere una traccia dello status del progetto è un compito reso semplice da Feature Driven Development in quanto si ha a disposizione sin dall'inizio la lista delle funzionalità da implementare ed ogni iterazione ha dei pesi ben definiti per ogni passo:

• iteration planning meeting - domain walkthrough (1%),
• design phase (40%),
• design review meeting - inspection (3%),
• coding phase (45%),
• code review meeting - inspection (10%),
• promote to build moment (1%).

Partendo da questi dati, Jeff De Luca afferma che cambiamenti fino al 10% dei requisiti durante il corso del progetto non incidono in maniera tale da inficiare la deadline prevista.

Strumenti a supporto

Benché tutta la struttura organizzativa ed ogni processo di Feature Driven Development possano essere eseguiti manualmente, esistono diversi strumenti a supporto di questa metodologia. In particolare si possono trovare strumenti free, ed anche open source, tramite la community FDD. Riteniamo però più utile soffermarsi sugli oggetti e le attività, rispetto ai singoli, differenti, strumenti che le supportano.

UML colors

Per UML colorato si intende un UML standard con le classi divise in quattro categorie individuate da quattro colori diversi:

• giallo (indica un Ruolo, ricoperto da persona o da organizzazione, come ad esempio i differenti tipi di utente di un servizio);
• blu (indica una Descrizione modello-catalogo, ad esempio il tipo di oggetto in un database ma non il singolo oggetto);
• verde (indica un Luogo o un Oggetto, ad esempio il singolo oggetto del database di prima);
• rosa (indica i Tempi, un momento o un intervallo associati ad un processo, ad esempio ad un'azione su di un oggetto del database).

Le classi ausiliari e le interfacce restano standard e non sono colorate.

Progress Report

Un Progress Report è definito e rappresentato con un modello esclusivo di Feature Driven Development, i diagrammi a parcheggio. Ogni posto auto rappresenta un set di funzionalità e la sua lettura è piuttosto semplice ed immediata.

• Sfondo verde: funzionalità completate;
• Sfondo blu: sviluppo in corso;
• Sfondo rosso: sviluppo in ritardo rispetto allo scheduling previsto;
• Sfondo bianco: sviluppo non ancora iniziato;
• Lettere in alto a destra: iniziali del responsabile del blocco, ossia il capo-programmatore;
• Numero fra parentesi: numero di funzionalità appartenenti al blocco;
• Percentuale: percentuale delle funzionalità completate;
• Mese in basso: deadline per lo sviluppo del blocco di funzionalità.

Lo stesso Progress Report ha un livello di dettaglio maggiore in una tabella con la timeline per singola funzionalità. Sono previste le milestone di ogni passo dell'iterazione mentre i colori indicano semplicemente: verde (tutto secondo i piani), rosso (lo sviluppo della funzionalità è in ritardo rispetto allo scheduling previsto).

Bibliografia

• Serguei Khramtchenko, Comparing eXtreme Programming and Feature Driven Development in academic and regulated environments – Harvard University, CSCIE-275: Software Architecture and Engineering – 2004.

Voci correlate

• Metodologia agile
• Extreme Programming
• Presenter first