“Greatness doesn't require great talent. Talent doesn't hurt, by any means, but I've helped ordinary people work together to create great teams. No, it's not talent that's needed. What's needed is will.”
Storie d'uso
Un team agile pianifica il lavoro spezzandolo in storie d'uso (user stories), che sono frammenti di funzionalità visibili dall'utente. Le storie d'uso sono scritte dal cliente in collaborazione con gli sviluppatori. Un esempio da un servizio di ricerca personale:
- Come azienda, voglio inserire un'offerta di lavoro, per trovare candidati.
- Come candidato, voglio vedere le offerte che corrispondono al mio profilo, per trovare lavoro.
- Come candidato, voglio inserire il mio curriculum, perché le aziende possano trovarmi.
- Come amministratore, voglio leggere un report degli annunci pubblicati nell'ultimo mese, per vedere quali sono i nostri clienti migliori.
Stime di complessità
Gli sviluppatori assegnano una stima di complessità a ogni storia. La stima è in “punti” astratti. Questi punti rappresentano la difficoltà di realizzare una storia, relativamente ad altre storie. Ad esempio, se la storia A è stimata 2 punti e le storia B e C sono stimate 1 punto ciascuna, possiamo attenderci che sviluppare A costi più o meno quanto sviluppare B e C.
Prioritizzare
Il cliente sceglie l'ordine in cui le storie devono essere realizzate. In questo modo verranno affrontate per prime le storie che rappresentano per il cliente il valore maggiore.Iterazioni e velocità
Un'iterazione dura due settimane.
In questo periodo gli sviluppatori completano le storie più importanti, secondo l'ordine di priorità specificato dal cliente. Alla fine dell'iterazione il cliente può verificare sul sistema il funzionamento delle storie che egli stesso ha chiesto.
Ma quante storie riescono a realizzare gli sviluppatori in un'iterazione? Dipende da tanti fattori. Quello che sappiamo è che a regime, gli sviluppatori riescono a realizzare un numero di punti complessità più o meno costante. Misureremo che in una tipica iterazione si riescono a sviluppare storie per un totale di, poniamo, 12 punti complessità. Questo numero è detto la velocità del team.
La velocità non serve a misurare la produttività del team; serve a stimare quante storie possiamo attenderci di realizzare in un'iterazione. La velocità dipende da tanti fattori, ad esempio da quanto è difficile il dominio dell'applicazione (per la fisica quantistica dovremmo fare prima un mini-corso di aggiornamento), oppure dai vincoli tecnologici (dovete usare Java 1.0 e programmare con una mano legata dietro la schiena.)
Burndown chart
Se sommiamo la complessità di tutte le storie, otteniamo la complessità totale di quello che vogliamo realizzare. Se sappiamo quanti punti riusciamo a realizzare in un'iterazione, possiamo stimare quante iterazioni servono per completare lo sviluppo: ad esempio, per un progetto di 120 punti e una velocità di 12 punti, sappiamo che serviranno (circa) 10 iterazioni, ovvero 20 settimane.
E' possibile tracciare il progresso del team graficamente. Il burn down chart rappresenta quanti punti restano da sviluppare, iterazione per iterazione.
Dopo qualche iterazione, possiamo estrapolare la pendenza della curva per capire fra quanto tempo finiremo.
Per saperne di più
Il libro migliore sull'argomento è Agile Estimating and Planning di Mike Cohn. Il suo sito web contiene una quantità di informazioni aggiuntive.
Ron Jeffries in questa intervista spiega come un team agile misura il progresso sulla base delle “running, tested features”.
Robert C. Martin ha scritto un articolo sul minimo comun denominatore che contraddistingue un team realmente agile: Agile Methods: The Bottom Line (pdf).