Nel mondo waterfall la data di rilascio di un progetto – quando non è fissata da contratto – è il risultato di una pianificazione iniziale.
Con l’ausilio di un Gannt vengono messe in sequenza le varie attività da completare in base all’ordine logico di implementazione (concept, progettazione, sviluppo, test, ecc.).
Sulla base del Documento di Requisiti si fa la “lista della spesa” delle attività da realizzare, se ne evidenziano le dipendenze, si assegnano le risorse e mediando tra tempi, costi e ambito si tenta di contenere il più possibile la durata del progetto.
In questo caso le persone che prendono direttamente o indirettamente parte al progetto (gli sviluppatori in prima persona, ma anche i responsabili d’area o eventuali esperti di settore) forniscono una stima temporale delle singole attività.
La somma delle singole durate insieme alla sequenza delle stesse determina la data di rilascio finale.
Quando si utilizzano invece le metodologie Agili il primo passo per stimare la durata di un progetto consiste nel valutarne il size, ovvero la dimensione.
La domanda che si pone lo Scrum Team è:
“Quanto è grande il progetto?”
Per valutarne la dimensione il gruppo di lavoro deve avere un’idea condivisa di cosa è necessario realizzare.
Una volta comprese le finalità del progetto nel suo complesso e tradotte le componenti chiave in user stories si procedere a valutarne il size mediante story points o in giornate di lavoro ideali.
Entrambe queste tecniche consentono di esprimere con un sufficiente grado di confidenza la dimensione di una user story, vale a dire l’effort necessario per realizzare la funzionalità in tutte le sue componenti.
Il team in questa fase di analisi deve porre attenzione al fatto che il peso relativo delle storie sia consistente piuttosto che alla precisione della singola stima.
Solo quando tutte le user stories del progetto sono state stimate – anche ad alto livello – si deriva una durata complessiva.
Per farlo è sufficiente dividere la somma degli story points per la velocity del team, ovvero la misura della progressione che è in grado di portare a termine in un singolo sprint.
Facciamo un esempio per chiarire: il team ha valutato che il nuovo progetto cuba in tutto 150 story points. In passato il medesimo team ha avuto una velocity media pari a 25 story points per singola iterazione. Il nuovo progetto durerà quindi 6 sprint.
A questo punto siamo in grado di prendere in mano il calendario e comunicare una data di rilascio: 6 sprint di 2 settimane significano 3 mesi di lavoro.
Ho volutamente portato l’esempio più semplice per far capire come avviene il calcolo della durata. Ci sono tuttavia occasioni in cui il team è totalmente nuovo e lavora per la prima volta assieme, oppure i confini del progetto non sono del tutto chiari in partenza.
E’ utile tener presente che le stime Agili possono esserci d’aiuto anche in questi frangenti, ma le casistiche sono variegate e meritano un approfondimento successivo.
Ricapitolando…
Quando utilizziamo metodologie agili per la stima evitiamo di correre subito alle conclusioni assegnando ad ogni singolo task una durata prevista.
Partiamo sempre dalle funzionalità che rilasceremo al cliente finale (perché solo queste hanno reale valore) e seguiamo 3 step:
- stimiamo la dimensione di ogni user story e le sommiamo assieme
- dividiamo la somma degli story points per la velocità media del team (solo in questa fase iniziamo a parlare della variabile tempo!)
- il numero di sprint risultante ci consente di dire, a calendario, quando finiremo
Perché tanta enfasi sulle dimensioni?
Perché solo separando le due variabili di dimensione e durata possiamo garantire massima flessibilità al nostro piano di rilascio… e il Product Owner ed il Team saranno messi nelle condizioni migliori per valutare come procedere al termine di ogni sprint.
