Ore, Stime, Story Points…

Stimare il lavoro da svolgere è difficile. Per gli sviluppatori di software, è tra gli aspetti più intricati. Bisogna prendere in considerazione una serie di fattori che servono al Product Owner a prendere, a sua volta, decisioni che influenzano l’intero Team (e il business).

Quindi non bisogna meravigliarsi che tutti, dagli sviluppatori ai dirigenti, siano inclini a trasformare le stime in spade di Damocle sulle loro teste. La stima è proprio questo: una stima. Non un giuramento di sangue.

Non c’ è alcun obbligo di lavorare nei fine settimana per compensare una sottovalutazione di un lavoro. Detto questo, esaminiamo alcuni modi per fare stime il più accurate possibile.

Nello Sviluppo Agile, il Product Owner ha il compito di dare priorità all’arretrato, l’elenco ordinato di lavori che contiene brevi descrizioni d tutte le caratteristiche desiderate e correzioni per un prodotto.

Il Product Owner cattura i requisiti, ma non sempre conosce i dettagli dell’implementazione. Così una buona stima può dare al P.O. una nuova visione del livello di sforzo necessario per ogni elemento di lavoro. Poi trasformerà questa valutazione nella priorità relativa di ogni elemento.

Quando il Team di Sviluppo inizia il processo di stima, di solito sorgono domande sui requisiti e sulle storie degli utenti. E questo è certamente positivo: le domande aiutano l’intera squadra a comprendere meglio il lavoro da svolgere.

Per il Product Owner in particolare, suddividere gli elementi di lavoro in “mattoncini più piccoli” e fare le stime li aiuta a dare la priorità a tutte le aree di lavoro (anche quelle potenzialmente nascoste!). Una volta concluso questo processo, non è raro che il P.O. riordini nuovamente le attività sul Backlog.

La Stima Agile è uno sport di squadra. Coinvolgere tutti (sviluppatori, progettisti, collaudatori, installatori… tutti) nel team è fondamentale. Ricorda però che ogni membro del Team vede il lavoro da una prospettiva diversa.

Ad esempio, se la gestione del prodotto vuole fare qualcosa che sembra semplice, come supportare un nuovo browser web, lo sviluppo e la QA devono essere considerati, in quanto la loro esperienza ha insegnato loro quali problemi potrebbero essere in agguato dietro l’angolo.

Allo stesso modo, le modifiche progettuali richiedono non solo il contributo del team di progettazione, ma anche quello dello sviluppo e della QA.

Lasciando una parte del più ampio team di prodotto fuori dal processo di stima si creano stime di qualità inferiore, si riduce il morale perché i principali contributori si sentono esclusi e si compromette la qualità del software.

Non è scritto su nessun manuale, ma è la realtà. L’esperienza insegna. Quindi non lasciate che la vostra squadra sia vittima di stime fatte nel vuoto. L’unica garanzia che avrete sarà il fallimento, veloce!

E veniamo adesso all’altro tema importantE: Story Points versus ore. I team di software tradizionali forniscono stime in un formato temporale: giorni, settimane, mesi. Molti Scrum Team invece adottano, giustamente e correttamente, gli Story Points.

Sono “valori” che quantificano lo sforzo relativo del lavoro in un formato simile alla sequenza di Fibonacci: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100.

Può sembrare un metodo contro-intuitivo, ma l’astrazione è effettivamente utile perché induce il Team a prendere decisioni più difficili riguardo la difficoltà del lavoro da svolgere.

Io vedo pochi motivi per non usare gli Story Points:

  • le date non tengono conto del lavoro non legato al progetto che inevitabilmente si incastrerà nel complesso delle attività. Ad esempio tutte quelle interminabili riunioni senza nemmeno un’agenda dei temi, e-mail, interviste in cui un membro del team potrebbe essere coinvolto;
  • le date hanno un fondamento emotivo e non reale. La stima relativa rimuove l’attaccamento emotivo (si deve rilasciare entro la data X perché entriamo nel segno del capricorno oppure perché la Luna è in fase di quarto calante… o altre “necessità” di business).

Poiché ogni Team valuterà il lavoro su scala leggermente diversa, la loro velocità (misurata in punti) sarà naturalmente diversa. Questo, a sua volta, rende impossibile fare statistica usando la velocità come strumento.

I Team che iniziano con punti storia usano un esercizio chiamato pianificazione del poker.

Pianificare il poker è una pratica comune. In breve: il Team prenderà un’attività dal Backlog, ne discuterà brevemente e ciascun membro formulerà mentalmente una stima.

Poi ognuno tiene una carta con il numero che riflette la sua stima.

Se tutti sono d’accordo, grande risultato (passate a comprare anche un biglietto di gratta-e-vinci che non si sa mai…).

In caso contrario, prendetevi un po’ di tempo (ma non troppo, bastano pochi minuti) per capire la logica alla base delle diverse stime.

Ricordate però che la stima dovrebbe essere un’attività di alto livello. Se il team è in empasse, armi e coraggio e superate la discussione con una decisione definitiva.

Stima più intelligente, non più difficile. Nessuna attività individuale deve superare le 16 ore di lavoro. Se si utilizzano Story Points, si può decidere che, ad esempio, 20 punti è il limite superiore.

È semplicemente troppo difficile stimare i singoli elementi di lavoro più grandi di quel valore. La fiducia, in uno Scrum Team, è particolarmente importante per le attività in cima al Backlog.

Quando qualcosa è stimato sopra la soglia di 16 ore (o 20 punti), questo è un segnale per dividerla in pezzi più piccoli e rivalutare. Per le voci più in basso nel Backlog basterà fornire una stima approssimativa. La affinerete proseguendo.

Infatti, quando il Team inizierà effettivamente a lavorare su questi elementi, i requisiti potrebbero cambiare e la vostra applicazione sarà certamente cambiata.

Quindi le stime preliminari non saranno così accurate. Non perdete tempo a stimare il lavoro che probabilmente cambierà. Basta dare al Product Owner una mappa, non riportare un plastico in scala del territorio …

Infine, imparate dalle stime passate. Le retrospettive sono il momento per il Team di assimilare l’esperienza frutto delle precedenti iterazioni, inclusa l’accuratezza delle loro stime.

Molti strumenti agili (come JIRA Software) consentono di tracciare Story Points, semplificando notevolmente la ricalibrazione delle stime.

Provate, per esempio, a tirare su le ultime cinque storie utente consegnate dal Team con il valore del punto storia otto. Poi discutete se ciascuno di queste attività di lavoro ha avuto un livello di sforzo simile. In caso contrario, discutete il motivo. Utilizzate queste informazioni nelle future discussioni sulle stime.

In Agile, la stima è una pratica. Con il tempo si ottiene sempre meglio.

Agile Estimation Practices – Demystifying Story Points, di John Donovan