Stime agili
Luca | September 28, 2006L’altra sera sono andato al primo incontro dell’APLN London: speaker della serata Mike Cohn che ha parlato di stime e pianificazione; l’ospite non poteva non esser più gradito, dato che sto finendo il suo libro proprio su questo argomento.
Continuo a pensare che il concetto di stimare per dimensione e non per durata sia grande: cerchiamo di capire quanto lavoro siamo capaci di fare, il tempo è una grandezza secondaria che otteniamo dalla velocità del team.
Questo secondo me ha alcuni grandi vantaggi:
- sposta l’attenzione sul “fare”
- semplifica le stime
- ottieni una stima temporale data dalla velocità che è accurata per gli obiettivi del progetto (“quando finiamo ?”… a nessuno interessa sapere “quando è pronto il CRUD ?”)
Questo in realtà si scontra parzialmente con quanto affermato da Mike: lui ha detto di evitare di farsi guidare dalla velocità nella fase di planning ma di fare stime in ore reali dei task…io invece vorrei proprio uscire dalla stima dei singoli task in ore e passare ai punti pure su quelli!!
Usare ore reali per stimare i task e definire il lavoro di ogni iterazione ed usare punti e velocità per capire quante iterazioni servono per finire il progetto mi sembra riduttivo: al momento nel team di cui faccio parte stimiamo sempre in ore reali e francamente la cosa non mi sembra molto produttiva, perchè si hanno comunque delle fluttuazioni nelle stime che le rendono tutte inaccurate…se invece stimo che su una iterazione posso produrre 20 punti non mi preoccupo se per 10 di questi impiego 5 giorni e per i restanti 15! E’ ovvio che anche in questo caso si può ribattere che la stima non è perfetta, ma la pianificazione dell’iterazione è comunque funzionale !!
Mi piacerebbe dare una chance all’approccio appena descritto per capire se può funzionare (ovviamente io credo di si 
)
..ci sto provando da un pò ad introdurlo nel team, vediamo se in futuro vorremo provare.
ottimo il libro di mike cohn! avrei dato un'occhio per
simone genini | October 5, 2006ottimo il libro di mike cohn! avrei dato un’occhio per partecipare all’incontro di cui parli. (c:
la nostra esperienza…
abbiamo cominciato ad adottare le “stime a punti” dopo due anni di tentativi vari e – soprattutto – dopo aver letto “agile estimating and planning”.
siamo passati dai giorni perfetti, ai “giorni e basta”, alle mezze giornate, alle ore e alle mezz’ore (aka pomodori, per i task).
non siamo mai stati molto soddisfatti perchè il costo delle stime era sempre maggiore al vantaggio che ci portavano, soprattutto pensando anche alle loro fluttuazioni.
domande tipiche che ci ponevamo erano: “ma vale la pena buttare tutto questo tempo per delle stime non proprio usabili?”
da qualche tempo – come detto – valutiamo per difficoltà (o peso) che significano la stessa cosa per noi.
non “buttiamo” più molto tempo per le stime (non abbiamo più questa sensazione) e sembra funzionare meglio anche se mi sembra un po’ prematuro cantare vittoria, attenderei ancora un po’…
la cosa che mi fa pensare è questa:
il primissimo modo di stimare del quale ho letto anni fa era quello famoso degli “orsetti di gomma” (ora non ricordo più se era per le storie, per i task o per entrambi)
beh, non erano punti quelli? certo che lo erano… purtroppo – qui da noi – eravamo troppo giovani per capire esattamente a cosa potessero servire.
in effetti il mio rammarico è che abbiamo letto, provato, adattato, modificato… il tutto spendendo dei soldini… per arrivare al punto di partenza…
sarebbe ingiusto comunque dire che le due consapevolezze sono uguali; non si assomigliano proprio per niente, forse anche dato dal sudore che abbiamo versato per raggiungere la seconda però…
… si sarebbe probabilmente potuto risparmiare qualcosa con un po’ di fede in più e cercando di capire cosa significava prima di cercare nuove soluzioni.
per tornare in tema:
per il momento l’utilizzo dei punti soddisfa me (come manager), soddisfa gli sviluppatori e sono convinto che soddisferà pienamente anche il cliente che per il momento è *solamente* neutro (c:
noi li usiamo solo per le storie siccome abbiamo abolito i task (anche se esistono comunque come “lista di cose da fare in una storia”, non vengono però stimati).
se ti va ti faccio sapere se e quando cambio opinione… in meglio, in peggio non lo so ancora. so solo che succederà . (c;
ciao
simone
e certo che mi interessa sapere se cambi opinione!! e
Administrator | October 5, 2006e certo che mi interessa sapere se cambi opinione!! e soprattutto nel caso cambiaste modo di stimare…cosa vi ha spinto a cambiare!
[...] qualche giorno fa mi sono trovato sul blog di
Perchè non stimiamo più i task « Enri Blog | October 6, 2006[...] qualche giorno fa mi sono trovato sul blog di luca grulla e ho risposto ad un suo articolo riguardante la stima agile delle storie. poi luca mi ha mandato un email con le seguenti domande: “come siete passati da stimare i task a decidere di che non era più utile e stimare solo le storie ? quale è stato il passaggio che vi ha spinto in questa direzione ?“ [...]
pienamente d'accordo sull'inutilità , in generale, dei class diagram ma
marcello | October 24, 2006pienamente d’accordo sull’inutilità , in generale, dei class diagram ma ultimamente ho trovato una loro dignità : a fronte di una attività di sviluppo posso rappresentare lo stato attuale delle dipendenze, giusto per vedere se e come posso migliorare il design.
Ciao Luca! Ho cambiato dominio, quello nuovo è: RED GREEN REFACTOR
Enri | November 10, 2006Ciao Luca!
Ho cambiato dominio, quello nuovo è:
RED GREEN REFACTOR IT!
Il blog su wordpress.com non lo utilizzerò più.
A presto!