Stima in XP

Gli esseri umani sono scarsi nello stimare il tempo assoluto. "Ci vorranno 3 giorni" è quasi sempre sbagliato. Sottostimiamo la complessità e sovrastimiamo la nostra produttività.

Ma gli esseri umani sono bravi nel confronto relativo. "Questa storia è circa il doppio di quella" è qualcosa che possiamo fare in modo affidabile.

XP usa la stima relativa. Invece di stimare ore, stimiamo la dimensione. Una storia potrebbe essere un "2" o un "5" o un "13". Questi numeri non significano ore o giorni—significano dimensione relativa rispetto ad altre storie.

Perché il relativo funziona:

• Stiamo confrontando cose che comprendiamo (storia con storia, non storia con tempo)
• È più veloce (non servono suddivisioni dettagliate dei task)
• È più onesto (nessuna falsa precisione)
• Si autocorregge attraverso il monitoraggio della velocity

Gli Story Point sono l'unità più comune per la stima relativa.

I punti rappresentano sforzo, complessità e incertezza combinati—non tempo. Una storia da 5 punti richiede circa il doppio dello sforzo di una storia da 2 punti (più o meno), ma non necessariamente il doppio delle ore.

Scale di punti comuni:

• Fibonacci: 1, 2, 3, 5, 8, 13, 21, ? (i salti ti costringono a scegliere)
• Potenze di 2: 1, 2, 4, 8, 16 (semplice raddoppio)
• Taglie: XS, S, M, L, XL (non numeriche, buone per la pianificazione ad alto livello)

Consigli per assegnare punti alle storie:

• Confronta con storie di riferimento ("È più grande o più piccola della Storia X?")
• Non pensarci troppo (i punti sono sfocati per design)
• Includi l'incertezza nella stima (sconosciuto = più grande)
• Ristima se apprendi qualcosa che cambia la tua comprensione

Il Planning Poker è una tecnica per raggiungere il consenso del team sulle stime.

Come funziona:

1. Il product owner legge una storia
2. I membri del team fanno domande di chiarimento
3. Tutti selezionano privatamente una carta di stima
4. Tutte le carte vengono rivelate simultaneamente
5. Gli stimatori più alti e più bassi spiegano il loro ragionamento
6. Il team discute e rivota se necessario
7. Emerge il consenso (o si prende la media)

Perché la rivelazione simultanea? Per prevenire l'ancoraggio. Se lo sviluppatore senior dice "5" per primo, tutti gli altri si adeguano verso il 5. Rivelare simultaneamente cattura opinioni indipendenti.

Perché discutere i valori estremi? La persona che ha detto "13" potrebbe sapere qualcosa che gli altri non sanno ("questo richiede una migrazione del database"). La persona che ha detto "2" potrebbe avere un approccio più semplice. Entrambe le visioni migliorano la stima.

Il Planning Poker serve tanto a costruire una comprensione condivisa quanto a ottenere un numero. La discussione fa emergere assunzioni, rischi e decisioni di design.

La velocity è quanti punti il team completa per iterazione. È la chiave per trasformare le stime relative in previsioni.

Se il team ha completato 30 punti nell'ultima iterazione, probabilmente completerà circa 30 punti nella prossima iterazione. Questo si chiama il tempo di ieri—il miglior predittore del tempo di domani è il tempo di oggi.

Usare la velocity:

• Se hai 100 punti di lavoro e una velocity di 20, aspettati circa 5 iterazioni
• Se il cliente vuole rilasciare in 3 iterazioni, puoi fare circa 60 punti di lavoro
• La velocity fluttua; usa una media mobile (ultime 3-5 iterazioni)

Cosa influenza la velocity:

• Composizione del team (ferie, nuovi membri)
• Ambiente tecnico (nuovo framework, cambiamenti infrastrutturali)
• Tipo di lavoro (nuova funzionalità vs correzione bug)
• Focus del team (le interruzioni uccidono la velocity)

Non manipolare la velocity. Non è una metrica di produttività—è uno strumento di pianificazione. Gonfiare i punti o tagliare gli angoli per "aumentare la velocity" vanifica lo scopo.

Le stime sono ipotesi. Saranno sbagliate. XP riconosce questo e integra l'adattabilità.

Fallimenti comuni nella stima:

• Incognite sconosciute: Emerge complessità imprevista
• Dipendenze: Team o sistemi esterni causano ritardi
• Scope creep: La storia cresce mentre la costruisci
• Debito tecnico: Il codice esistente è più difficile da modificare del previsto

Cosa fare quando si è fuori rotta:

1. Fallo emergere immediatamente (trasparenza)
2. Ristima in base alla nuova comprensione
3. Discuti con il product owner
4. Negozia lo scope se necessario (incremento più piccolo, rinvia funzionalità)

Non nasconderlo. Non fare straordinari per rispettare una stima sbagliata. Il punto della stima è pianificare—se il piano è sbagliato, cambialo.

Nel tempo, le stime migliorano. Man mano che il team acquisisce esperienza con il codebase e tra loro, l'incertezza diminuisce. Ma non saranno mai perfette—ecco perché XP enfatizza l'adattamento rispetto alla previsione.