Stimare la project velocity alla prima iterazione – Prima parte

Circostanza frequente: team agile approntato, progetto intrapreso secondo la metodologia preferita (extreme programming o scrum o entrambe o…), hai terminato di stimare le user story, hai assegnato le dovute priorità insieme al resto del team e ora devi approntare un release plan che permetta di capire per quanto ne avrete. “Facile!” esclama il giovane agilista, “Basta prendere la somma degli story point e dividerla per la velocity del progetto!”. Senza dubbio corretto in linea di principio – e comunque non è mai così semplice nella pratica – ma soprattutto: alla prima iterazione che valore di velocity userai? Tu e il tuo team non avete mai lavorato su questo progetto, non hai dati retrospettivi su cui contare. E quindi? Affiderai tutto al caso?

Assolutamente no, ci sono delle tecniche per (aiutarci a) sciogliere questo nodo e voglio illustrartene qualcuna.

L’intelligenza umana è ottima in pochi aspetti, ma in una specifica operazione analitica noi esseri umani siamo davvero insuperabili: stabilire analogie fuzzy fra sistemi fra loro non perfettamente analoghi (isomorfi, se volete). Questa facoltà, per esempio, è al centro del planning game quando per stimare le user story si procede per triangolazione: la storia A sembra più piccola di una storia da 5 story point ma più grande di un’altra da 1 story point, ergo probabilmente si deciderà di assegnarle 2 o 3 punti.

Lo stesso… pattern (n.d.a.: non ho resistito!) è possibile individuarlo e applicarlo alla stima della project velocity.

  • Hai già lavorato insieme alle persone che compongono il tuo team?
  • Hai già lavorato su progetti simili a quello che stai avviando?
  • Hai già lavorato con lo stesso cliente?
  • Hai già lavorato con gli stessi utenti?
  • Hai già lavorato con le stesse tecnologie e nello stesso ambiente?
  • Hai già lavorato precedentemente con più di uno dei suddetti fattori in concomitanza fra loro?
Se la risposta ad alcune di queste domande è affermativa, beh… allora hai parecchi elementi su cui basarti per spianare la strada verso una stima attendibile della project velocity. Lo stesso team tende infatti ad avere prestazioni simili in condizioni simili e questo è possibile affermarlo sulla base di due considerazioni:
  1. un dato team ha una capacità pressoché uniforme di produrre valore per il cliente
  2. il calcolo della velocity alla fine di ogni iterazione ha un effetto retroattivo di controllo (di controreazione, in gergo ingegneristico classico) sul peso assoluto assegnato dal team stesso alle user story.
Mi spiego meglio.

Ogni team valuta ogni progetto in un momento diverso della propria vita. Pertanto la stima di uno stesso progetto da parte di uno stesso team ora o fra 1 anno non ci attendiamo sia proprio identica. Panta rei diceva il filosofo e

Nessun uomo può bagnarsi nello stesso fiume per due volte

Ciò nonostante però, come non ci sogneremmo di dire che nostra madre non è più sé stessa eventualmente cambiasse idea sui suoi gusti in fatto di budini, così non ci può sfiorare l’idea che un team non abbia una sua identità. Un’identità destinata sì a mutare, anzi, a crescere nel tempo, ma anche ad essere comunque fortemente riconoscibile anche a distanza di molti mesi. Ogni team ha un suo modo di stimare le user story che, insieme ad altri fattori, va a far parte della sua propria impronta digitale. Un team quindi avrà un suo tipico valore assoluto associato ad ogni story point. Uno stesso progetto per un team potrà valere 258 story point, per un altro team 371, per un altro ancora solo 198. Ognuna di queste stime avrebbe lo stesso esatto gradi di legittimità!

Lo strumento di cui disponiamo per ridurre drasticamente questa varianza di stima è per l’appunto la project velocity. Se il team A è solito assegnare 1 punto a storie che il team B valuta 13 punti è plausibile che la velocity calcolata a fine iterazione sia molto molto più alta per il team B che per il team A. Questo valore viene usato poi non solo per stimare la velocity dell’iterazione successiva, ma – tornando al nostro problema iniziale – entra a far parte dell’identità, del DNA del team in questione rimanendo a disposizione per stimare la velocity per la prima iterazione di un nuovo progetto.

Per questo mi sforzo sempre di far capire ai dirigenti delle aziende in cui lavoro – e soprattutto ai commerciali – che non ha senso parlare di un “progettino da 100-120 punti per cui dobbiamo mettere su un team” se non si ha ancora chiaro… il team!

Questo approccio per analogia è molto potente e chiaramente vale in misura decrescente man mano che l’identità del gruppo viene compromessa: nuovi ingressi, nuovi clienti, nuove tecnologie, ma soprattutto nuove assenze di membri del team che svolgevano la preziosa funzione di diffusori di conoscenza sul processo tipico di quel dato team. Con questo però non intendo certo dire che il metodo diventi perfettamente inutile con l’introduzione di un po’ di incertezza! Vale sempre la pena cercare di stabilire analogie con precedenti progetti, anche solo come spunto analitico retrospettivo, e stimare la project velocity per proiezione è il passo successivo dopo la stima per analogia.

E tu? Sapevi di usare spesso l’analogia come strumento di stima? E in quali situazioni stimi per analogia?

Ci vediamo tra qualche giorno per la seconda parte di questo articolo!

October 16 2008 04:08 pm | Esperti

Trackback URI | Comments RSS

Leave a Reply