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 ?“
per chi non ha letto l’articolo siamo passati da una situazione dove stimavamo solo i task in pomodori a stimare solo le storie in punti
(questa è solo l’ultima puntata del: “imparare a pianificare agile”, vi risparmio le altre)
un bel cambiamento insomma… qui sotto vi spiego il perchè di questa decisione.
innanzitutto il grande costo della definizione e valutazione dei task.
in particolare per quanto riguarda due temi particolari: soldi e energia
- per i soldi è chiaro: più tempo investito = più soldi investiti
- per l’energia invece ci vuole un po’ di empatia…
però quando finite le stime ti trovi con un team completamente spremuto – se ci tienti alle persone con cui lavori – allora forse ti viene da cercare un’altra soluzione.
un altro motivo era l’efficacia (o meglio la non-efficacia) di questa micro-pianificazione.
tirando le somme, alla fine, non è che ci si poteva poi fare molto, anche qui in due termini: precisione e correttezza.
spiego cosa intendo con questi due termini perchè non li trovo molto esplicativi:
- con precisione intendo la differenza fra le stime e il tempo impiegato.
riuscivamo abbastanza bene a stimare i task di una certa dimensione ma oltre questa soglia le stime erano inaffidabili.
era inoltre impossibile condurli tutti a questa dimensione; sarebbe stato un suicidio e poi ci avrebbe portato a peggiorare ulteriormente la loro “correttezza“, che spiego più avanti. - inoltre non sono nemmeno mai riuscito (come manager) a trovare un fattore “stima/tempo reale” del tipo: “per ogni mezz’ora stimata ce ne mettiamo due” quindi non si potevano utilizzare nemmeno per fare “stime a punti” molto grossolane (sono cosciente che sarebbe stato comunque un abuso, ma ho tentato anche questo).
- con correttezza invece intendo la bontà della strada scelta (supponiamo che la storia sia il punto di arrivo e i task siano i passi di questa strada)
molto semplice… quante volte la strada decisa e pianificata davanti ad un tavolo corrisponde a quella che poi salta fuori davanti ai pc? … non così spesso…
inoltre suonava un po’ di BDUF… se non propriamente “Big” almeno “Too Much”
quindi non in termini di “mega-documentazione-specifiche” per lo meno in termini di “definiamo adesso dove andremo tra un po’“
il tutto senza avere dei punti concreti su cui basarci che non siano i ricordi delle persone sedute al tavolo in quel momento.
evidentemente capitava regolarmente di cancellare dei task (faticosamente definiti e stimati) e/o di aggiungerne di nuovi.
inoltre – usando la metafora a me molto cara della strada, qui soprta – il punto di arrivo non era più definito.
esistevano solo i passi che … deviando un po’ adesso e deviando un po’ dopo… non portavano più alla meta definita inizialmente. questo inoltre si scopriva solamente (troppo) tardi.
questi motivi, uniti alle indicazioni degli amici di quinary e ad una frase nel primo “extreme programming explained” ci hanno spinti a provare a valutare solo le storie, giudicando un’ulteriore divisione in task superflua.
per il momento ci basta, anche se siamo ancora un po’ “acerbi” per consigliarlo o sconsigliarlo a qualcuno.
non escludo che un giorno ritorneremo a stimare anche i task.
sono cosciente che il nostro approccio “solo-task” avesse mille pecche e problemi però per lo meno ci ha aperto un po’ la visuale e ci ha aiutato ad imparare a stimare e a definire in modo migliore, almeno inizialmente.
in effetti è stato un buon esercizio (non necessariamente economico) per poi poter stimare meglio…
come sempre consiglio però di provare a far funzionare la soluzione classica e di abbandonarla solo quando si è coscienti delle conseguenze che porta… non come facciamo noi quindi 
Molto interessante.
Fermo restando che siete arrivati a questa pratica per mezzo di un cammino di miglioramento supportato da misure (=bontà delle stime) e che quindi tale pratica è giustificata, tuttavia mi chiedo:
1. tipicamente quanto erano grandi le storie che stimavate? ed i task?
2. al cliente cosa comunicavate come stima?
3. tracciate a livello di task? in che modo valutate la bontà delle stime?
Commento di Enri — 6 Ottobre, 2006 @ 2:55 pm
1.
stimavamo solo i task in questo passaggio che ho raccontato, niente storie.
diciamo che fino a 8 (pomodori) andava ancora mica male più in là era “lo sconosciuto”
2.
“questa settimana faremo la cosa a, la cosa b e la cosa c”
dove a, b e c erano contenitori di task (praticamente le storie ma usate solo come raggruppamento)
3. tracciavamo i task ma ora tracciamo le storie (i task non ci sono più)
per valutare la bontà delle stime adesso facciamo delle “review” nelle quali diciamo:
“ma questa storia valeva veramente 5?”
“hmmm…. no, valeva 3″
quando questi due valori: “stima” e “stima rivisitata” corrispondono allora era buona.
dall’altra parte io sto cominciando a dargli anche un valore temporale… una cosa del tipo: “so che un punto difficoltà ci mette X giorni per essere sviluppato”
ma anche qui siamo ancora un po’ giovani… ho appena fatto i primi calcoli basati su un tot di storie finite in questo modo… il tempo ci dirà quanto stiamo andando bene…
Commento di simone — 6 Ottobre, 2006 @ 3:04 pm
1. Intendi 8 pomodori per task? Se dici che fino ad 8 pomodori per task le stime erano accurate, mi viene da pensare che allora il problema poteva risiedere nella granularità con la quale definivate un task.
Avete pensato di unire il meglio dei due approcci spezzando in task (della giusta dimensione) e contemporaneamente “controllando” le stime dei task pensando alla storia nella sua interezza in una sorta di “double-checking” in fase di pianificazione?
2. in base a cosa dite che in una settimana potete fare a,b,c? In base alla velocità dell’iterazione precedente?
3. immagino che la storia la tracciate in pomodori. Quindi non verrebbe comodo (=meno dispendioso) avere anche la stima in pomodori (somma dei task)?
Mi rendo conto per esperienza che spesso quando si spezza una storia in task se ne dimentica qualcuno o si valuta un task in modo eccessivo, ma ragionare anche su questo non può servire anche qui a migliorare la volta successiva? Soprattutto se si applica quel double checking di cui parlavo.
Non ho la soluzione in tasca, solo mi interessa ragionarci a voce alta con te.
Commento di Enri — 6 Ottobre, 2006 @ 3:18 pm
1.
granularità
giusto ma con i presupposti del caso “solo task, misurati in pomodori” non si poteva fare molto diversamente.
non abbiamo mai pensato a stimare un task di 47 pomodori… non avrebbe senso. sarebbe più una lotteria che una stima!
in effetti la nostra scelta di passare alle storie è stata una scelta di granularità
due approcci
non ci abbiamo pensato perchè siamo partiti con i presupposti del primo “xp explained” che diceva di mai confrontare i punti storia con i “perfect days” (mi sembra si chiamassero così) per un numero di motivi… ora non li ricordo tutti.
da un lato si voleva evitare di stimare la volta successiva con una misura di tempo (avendo fatto il paragone) invece che in punti astratti.
dall’altro le due stime sono fatte in tempi diversi: la prima in “release planning”… mentre la seconda in “iteration planning”.
in “iteration planning” il cliente ha già scelto le storie che vuole.
confrontare in questo momento significa ritornare al “release planning” per vedere cosa ci sta o meno in base ai nuovi dati.
è vero che è meglio saperlo presto piuttosto che tardi ma allora a quel punto faccio fare dapprima agli sviluppatori la divisione in task e poi faccio la release planning con il cliente… onestamente mi sembra un po’ tempo buttato perchè il cliente magari cambia una storia, ne mette una nuova, ne butta una vecchia e si ricomincia da capo con le valutazioni.
2.
più o meno… faccio una media delle ultime x velocità
3.
il nostro nuovo approccio (quello classico) non ci fa stimare con misure relative al tempo ma con punti astratti, anche qui per un numero di ragioni che non vado ad elencare, su “agile estimating and planning” ci sono un tot di motivi che mi hanno convinto a scegliere questo piuttosto che un valore legato al tempo.
ragionare sui problemi passati aiuta in effetti per le volte successive! ma non era questo il problema.
il fatto era che spendevamo troppi soldi per definire un percorso senza basi solide e poi dovevamo improvvisare di fronte alle situazioni.
allora ci siamo detti: “perchè spendere soldi e poi improvvisare? ne spendiamo meno, improvvisiamo uguale e magari risparmiamo anche qualcosa”.
del double checking ho già parlato al punto 1.
nemmeno io ho la soluzione… e sono qui *anche* per parlare con te (o con chiunque voglia) di queste cose…
Commento di simone — 6 Ottobre, 2006 @ 3:41 pm
Cosa intendi per non sono nemmeno mai riuscito a trovare un fattore stima/tempo reale?
Noi stimiamo genericamente per task.
La velocita’ che ne esce e’ un ottimo parametro per le stime.
Aggiungo che misuriamo l’errore di stima (lo consiglio, almeno all’inizio) e piu’ la stima e’ piccola piu’ la % di sovrastima e la % di sottostima si assomigliano =>, nel complesso, stimiamo normalmente in modo preciso.
Insisti insisti!!
PierG
http//pierg.wordpress.com
Commento di PierG — 6 Ottobre, 2006 @ 4:52 pm
intendo che – dopo un considerevole tempo dedicato alla pratica – il valore calcolato non convergeva ancora verso qualcosa che si sarebbe potuto utilizzare per calcolare un tempo reale.
)
la cosa strana è che in effetti si trattava proprio di stime su tempo (non punti), quindi dopo un certo periodo di “rodaggio” si dovrebbe avvicini sempre di più alla realtà, per lo meno come tendenza.
rivalutandolo però “con il senno di poi”… non mi andava per concetto di trovare una costante da applicare ad una stima di tempo per trovare il tempo.
suona già male a scriverlo, figuriamoci a farlo
(anche se ammetto che qualcosa di simile la facevo spontaneamente, senza farmi vedere troppo
penso che insistendo saremmo arrivati a qualcosa di utilizzabile però questo non era l’unico motivo, in fondo abbiamo deciso di cambiare soprattutto per gli altri (in particolar modo il costo in energia ed in tempo (soldi) delle stime).
sotto questo aspetto i punti ci danno una buona astrazione che incute meno pressione sul fatto di azzeccare il numero.
ci si mette molto meno ed il risultato non è peggiore… contiamo inoltre con le review, di migliorare ulteriormente.
penso che il nostro problema in questo ambito era quello di “voler far troppo bene” e – quello che vedevo in fase di stima – era una ricerca “del modo di calcolare” quanto ci metterà il task…
beh… se esistesse veramente non dovrei più fare un meeting con delle persone per ottenere questo valore… giusto?
grazie PierG per avermi spinto verso queste (più o meno) nuove riflessioni!
Commento di simone — 9 Ottobre, 2006 @ 8:55 am
Sinceramente noi abbiamo fatto il percorso inverso: dallo stimare solo la storia in giorni ideali, senza dividerla in task, a dividerla in task con l’obiettivo di migliorare la stima e comprendere se magari è necessario uno spike perché vi sono buchi neri tecnologici rischiosi per la stima (e quindi per il cliente).
Ad ogni modo la stima della storia nella sua interezza aiuta a comprendere se magari ci si sta dimenticando un task, in una sorta di double-checking tra stime dei task e stima della storia. A me viene molto utile pensare ai task anche da un punto di vista psicologico: mi aiuta ad entrare in un stato mentale di “esplorazione del problema“, un po’ come quando si butta giù un piccolo UML prima di scrivere del codice. Non credo sia una decisione di big up-front, in fondo è questione di qualche minuto…e ovviamente nulla vieta di adattare alla luce dell’esperienza.
Commento di Enri — 10 Ottobre, 2006 @ 12:45 pm