Tra le tantissime funzionalità introdotte con TFS11, sicuramente il nuovo web access spicca su tutto. L’interfaccia è infatti completamente scritta in HTML, completamente asincrona e supporta drag & drop per riordinare i PBI (Product Backlog Item) e per assegnarli ai vari sprint. In questo post però voglio parlare della funzione di Forecast, perchè riveste secondo me un’importanza molto elevata.
Nelle pianificazioni Agili viene assegnato un numero ad ogni PBI, chiamato Effort. Questo numero non rappresenta ore di lavoro, ma è un valore empirico che il team da ad un PBI per quantificare lo sforzo che si ritiene sia necessario per completarlo. Usualmente questo valore viene assegnato con il Planning Poker, dove ogni persona del team ha un mazzo di carte con varie quantità scritte sopra, e per ogni PBI ogniuno fa la sua stima e mette la carta corrispondente coperta nel tavolo. Quando tutti hanno messo la carta le si scoprono e si effettua un confronto. Questo modo molto semplice e divertente permette però fin da subito di stimare empiricamente la difficoltà di completamento di un PBI. Lo scopo è il confronto, ad esempio se in 5 persone si ha una cosa del tipo: 2, 3, 2, 4, 20, significa che la persona che ha stimato 20 probabilmente è a conoscenza di qualche particolare impedimento o difficoltà che fa si che la sua stima sia molto differente dagli altri e quindi se ne discute.
Sebbene il valore di Effort sia empirico, iterazione dopo iterazione, sprint dopo sprint, se il team non cambia radicalmente il quantitativo di effort che si riesce a realizzare in uno sprint tende ad assestarsi. Una cosa simile accade quando si stima in maniera classica un progetto, alla fine ci si accorge che si era sottostimato, per cui alla stima successiva, si aggiunge un X% perché: “si era sottostimato la volta precedente, per cui è probabile che si sia sottostimato anche ora”. Nei team agili, il quantitativo di Effort medio che si è realizzato negli sprint passati si chiama velocity.
Arriviamo quindi alla funzionalità di TFS chiamata “forecast”, che semplicemente fa una previsione (forecast) del backlog basandosi sulla velocity del team.
In questo esempio potete infatti vedere in alto che le previsioni sono fatte basandosi su una velocità di 10 (presa dai dati storici delle precedenti iterazioni), e la colonna forecast contiene gli sprint in cui si prevede che i vari PBI verranno completati. Questo dato, sebbene come detto basato su un valore di effort empirico, sprint dopo sprint tende ad assestarsi e ad essere quindi molto realistico.
Naturalmente questo tipo di pianificazione non è relegata solamente al mondo agile o scrum, ma è adatta per qualsiasi processo di tipo iterativo, dove il team si concentra quindi su un certo numero di PBI (feature, request, but, etc) per volta, che vengono portati a compimento iterazione dopo iterazione. L’accento è però sul “portati a compimento” perché sebbene ci sia molto da discutere sul “definition of done”, affinché questo tipo di pianificazione possa funzionare, quando un PBI è considerato chiuso significa che il team non deve più spendere tempo per lavorarci e non debbono esserci attività in sospeso.
Alk.