Stima agile: la guida completa
Una guida pratica alla stima agile: user story, planning poker, story point, velocità e le tecniche che si rivelano efficaci quando una user story si rivela più complessa di quanto sembrasse.
Le stime falliscono nei modi più comuni: numeri che assumono significati diversi a seconda delle persone, sessioni che superano i tempi previsti, previsioni di cui nessuno si fida. La soluzione raramente consiste in una formula migliore: si tratta piuttosto di una visione condivisa da tutto il team e di stime considerate come previsioni piuttosto che come impegni che possono essere utilizzati contro di voi.
Questa guida illustra gli elementi che si dimostrano efficaci nella pratica: user story, planning poker, story point, velocità e le tecniche che continuano a funzionare quando una story si rivela più ampia di quanto sembrasse inizialmente. Quando sarete pronti a effettuare una stima con il vostro team, effettuate la stima in TeamRetro: planning poker con votazione privata, mazzi riutilizzabili e story point finali che si sincronizzano direttamente con il vostro backlog.
Il Planning Poker è una tecnica di stima agile basata sul consenso: i team votano in modo riservato, rivelano tutte le carte contemporaneamente e discutono la distribuzione dei voti fino a quando le stime non convergono.
Come condurre una sessione di Planning Poker che fornisca stime utili senza protrarsi all’infinito: preparazione, il ciclo in quattro fasi, la scelta del mazzo e una rigorosa limitazione temporale.
Gli story point misurano lo sforzo relativo, la complessità e l’incertezza del lavoro, non le ore. Come valutare l’entità di un’attività rispetto a una storia di riferimento e le domande che mettono in difficoltà i team.
I punti di storia salgono a 1, 2, 3, 5, 8, 13 perché gli intervalli sempre più ampi riflettono l’incertezza: la scala smette di fingere che si possa distinguere un 13 da un 14. Ecco perché gli intervalli sono il punto fondamentale.
I punti storia misurano lo sforzo relativo; le ore misurano la durata: si tratta di assi diversi. Se si crea una tabella di conversione da punti a ore, si è tornati, senza rendersene conto, a stimare il tempo.
Scoprite cos’è la velocità di un team nell’agile, come calcolarla e come pianificare gli sprint tenendone conto, oltre a un calcolatore di velocità gratuito.
Le persone non sono brave a valutare “quanto tempo ci vorrà”, ma sono brave a valutare “se una cosa è più grande di un’altra”. La stima relativa si basa su quest’ultimo principio — ed è per questo che gli story point funzionano.
Le stime iniziali presentano un ampio margine di variazione perché il lavoro è sconosciuto, non perché il vostro team non sia in grado di stimare correttamente. Cosa significa il “cono di incertezza” e come restringerlo — anziché ampliarlo.
Le epiche, le storie e le attività costituiscono tre livelli, ciascuno con tre ruoli. In cosa consistono, quale di essi genera punti storia e perché attribuire punti al livello sbagliato rende la velocità un parametro privo di significato.
Una guida pratica alle tecniche di stima agile: planning poker, story point, t-shirt sizing, stima per affinità e velocità, e quando utilizzare ciascuna di esse.
I problemi ricorrenti che possono insorgere durante le sessioni di Planning Poker — calcolo della media delle carte, stime in ore, “velocity” utilizzata come arma, inflazione dei punti storia — e come risolverli.
I criteri di accettazione costituiscono il test di superamento o meno di una story, redatto prima dell’inizio dei lavori: i formati validi, gli esempi concreti e le differenze rispetto alla definizione di “completato”.
La definizione di "completato" consiste in una checklist condivisa da tutto il team che ogni story deve superare prima di essere rilasciata. Un esempio di tale definizione, chi ne è responsabile e in che modo essa differisce dai criteri di accettazione.
La definizione di “pronto” è la lista di controllo che indica se una story è pronta per essere inserita nello sprint. Cosa comprende una lista utile, perché la maggior parte viene ignorata e quale versione costituisce effettivamente un ostacolo.
Una storia di cui non si riesce a valutare la lunghezza è solitamente una storia che non è ancora pronta per essere pubblicata. Come capire quando è il momento di suddividerla, quali sono le linee di taglio che producono parti pubblicabili e quali invece danno solo l’impressione di farlo.
SPIDR consiste in cinque metodi affidabili per suddividere una user story: spike, percorso, interfaccia, dati, regole. Ogni linea di suddivisione: quando funziona e quando produce una suddivisione errata.
Le suddivisioni verticali generano valore; quelle orizzontali generano promesse. Perché la suddivisione per livello tecnologico ritarda la generazione di valore e come suddividere in base ai risultati per l’utente, in modo che ogni sprint produca qualcosa di concreto.
Una user story è una breve promessa di valore formulata in un linguaggio semplice. Il formato “ruolo-obiettivo-vantaggio”, le tre “C”, la checklist INVEST e i casi in cui le user story non rappresentano lo strumento adeguato.
Sedici esempi di user story relativi ad autenticazione, e-commerce, dispositivi mobili, API e bug — ciascuno corredato di note, con le versioni errate riportate accanto alle rispettive revisioni, in modo da rendere evidente la differenza.
Il modello classico di user story con una scheda “copia-incolla”, le varianti da conoscere e un esempio concreto che illustra il percorso dal modello ai criteri di accettazione fino alla stima.
Cosa si intende per "taglie delle magliette", come condurre una sessione e come convertire le taglie S/M/L in story point, oltre a quando è preferibile ricorrere al planning poker.