I punti storia sono un mezzo comune per stimare il lavoro durante l’utilizzo di framework agili come Scrum e EXTREME Programming.
Sfide relative alla stima
Quando gli ingegneri stimano il tempo per completare qualsiasi attività, spesso stimano in un giorno di ingegneria ideale. Sfortunatamente, i giorni di ingegneria ideali non esistono. Quando si tiene conto del tempo speso per altre attività come Slack, e-mail, riunioni e altre attività amministrative e non tecniche se sono fortunati, otterranno il 50% del tempo produttivo.,
A volte il lavoro è facile da stimare. Gli elementi che hanno un’aria di ripetizione, come la lettura di alcuni dati da un database e la visualizzazione sullo schermo, sono semplici da capire e stimare. Anche il lavoro ripetitivo o simile è facile da stimare. Tuttavia, lo sviluppo del software richiede spesso soluzioni su misura che non sono mai state tentate prima (almeno non dal team che fa le stime). Potrebbe anche essere necessario integrarsi con componenti sviluppati da altri gruppi. Come la complessità aumenta, così fa l’incertezza.,
Quando viene chiesto di stimare qualcosa di personalizzato o complesso, siamo spesso troppo sicuri nel tempo necessario per completare l’attività. Un contributo significativo a questo è il fatto che non possiamo prevedere ogni singolo passo che potrebbe essere richiesto. Le attività spesso emergono mentre il lavoro è in corso, poiché sfide impreviste generano ulteriori passaggi. Questa eccessiva fiducia si traduce in sottovalutare il tempo e lo sforzo per fare il lavoro.
Vantaggi della stima
Non a tutti piace la stima, e ci vuole tempo e fatica per farlo. Dati i costi e le sfide per farlo bene, perché preoccuparsi a tutti?,
Vantaggi per i team di sviluppo:
- Sanno quanto pianificare in uno sprint in modo da poter lavorare a un ritmo sostenibile.
- È più probabile che creino un incremento fatto non pianificando eccessivamente lo sprint.
- Aumenta la comprensione dei requisiti e della strategia di implementazione attraverso la discussione e l’elaborazione
Vantaggi per i proprietari di prodotti:
- Devono prevedere la consegna a lungo termine del loro prodotto.,
- Possono valutare il “rapporto qualità-prezzo” o il “ritorno sull’investimento” degli articoli
- Ottengono visibilità dei rischi tecnici associati a oggetti di grandi dimensioni
Concetti critici in story pointing
Story pointing riunisce diversi concetti
La stima relativa è più semplice della stima assoluta. È molto più facile confrontare due elementi del product backlog e dire che uno è due volte più difficile dell’altro. È molto più difficile pensare a quante righe di codice richiede una cosa e quindi quanto tempo ci vuole per codificare e testare.,
Utilizzando la diversità di tutta la squadra crea stime migliori. Conosciuto anche come la saggezza delle folle. Le squadre portano una diversità di pensiero e di opinione. Diversi membri del team vedranno lo stesso problema da un diverso punto di vista, consentendo un input più ampio nella discussione del problema. Una semplice correzione di bug può richiedere solo una riga di codice per cambiare, ma molte ore di test di regressione. Se solo un parere è considerato, la dimensione della voce può essere modo fuori.
La precisione e la comprensione si riducono man mano che gli elementi diventano più grandi. La dimensione dei diamanti è misurata in mm di solito a 1 decimale., La differenza in quel 0,1 mm in più può essere abbastanza significativa e vale la pena discutere. Confrontandolo con Giove, che ha un raggio medio di 69911 km, sarebbe ridicolo discutere di un extra di 0,1 mm. I punti storia usano una scala non lineare come la sequenza di Fibonacci, che aumenta gli spazi tra i numeri man mano che aumenta. C’è un 34 ma non 33 o 35.
I punti storia non riguardano il tempo necessario a qualsiasi individuo per svolgere il lavoro. In Scrum e XP, a una persona non viene assegnato il lavoro al punto di stima., L’intera squadra rimane proprietaria del lavoro, il che significa che chiunque nella squadra può raccoglierlo. Invece di sforzi individuali di tempo, punti storia rappresentano una combinazione di dimensioni, complessità e rischio. Quanto lavoro può essere completato nello sprint viene calcolato utilizzando la velocità della squadra (quanti punti ha completato nello sprint precedente).
Approccio
Calibrazione
Prima di iniziare a stimare in punti, l’intero team deve calibrare quanto vale un punto., Per calibrare la scala, scegliere un elemento dal backlog che è semplice, e tutti nel team capisce e definire che sulla scala. (ad esempio 2 punti). Per migliorare ulteriormente la calibrazione, trovare un esempio più in alto della scala forse quattro volte più grande e definirlo come un 8. La calibrazione della scala di stima migliorerà significativamente il tuo successo con la stima.
Concordare su come gestire le differenze
Il team di sviluppo deve concordare su come gestire le differenze nelle stime. Quanti round andranno e cosa dovrebbero fare se le stime non convergono., Per ottenere i benefici della stima di gruppo, un minimo di due turni fornirà il dialogo per prendere in giro le ipotesi. Il facilitatore potrebbe aver bisogno di ricordare alla squadra che c’è un valore limitato in lunghi dibattiti tra stime simili – se la squadra sta lottando per concordare se si tratta di un 2 o di un 3, basta sceglierne uno e andare avanti.
Riunione di stima
La riunione di stima procede come segue:
- Lo Scrum Master, che non giocherà, presiede la riunione.
- Il Product Owner fornisce una breve panoramica di un Product Backlog item (PBI) da stimare., Il team di sviluppo pone domande e discute per chiarire ipotesi e rischi. Un riassunto della discussione viene registrato dal team di sviluppo.
- Ogni membro del team di sviluppo confronta le dimensioni del PBI rispetto ai PBI di calibrazione e sceglie la loro stima delle dimensioni. Durante la discussione, i numeri non devono essere menzionati affatto in relazione alla dimensione della caratteristica per evitare l’ancoraggio.
- Tutti chiamano le loro stime contemporaneamente. Solo il team di sviluppo può stimare., Il proprietario del prodotto è autorizzato a chiedere perché qualcosa è di una certa dimensione e può avviare una negoziazione sull’ambito che può influire sulle dimensioni di un articolo.
- Le persone con stime elevate e stime basse offrono la loro logica per la loro stima, e poi la discussione continua. Durante il dibattito, le ipotesi dovrebbero essere ventilate e il proprietario del prodotto può fornire chiarezza.
- Questo passaggio spesso emerge una diversa comprensione dell’ambito o dell’implementazione, che può quindi essere chiarita e concordata., La persona che ha dato un 2 può conoscere una soluzione facile, ma la persona che ha dato un 13 può anticipare un difficilmente nessun altro pensato.
- Ripetere il processo di stima fino a raggiungere un consenso. O una convergenza sufficiente è raggiunta secondo le regole dei team di sviluppo.
Non si tratta dei punti
Il successo alla fine di uno sprint/iterazione non è misurato dal numero di punti completati o dal rapporto tra punti pianificati e punti effettivi raggiunti. Il successo è misurato da quanto valore è stato creato. I punti sono un mezzo per contribuire a creare valore, non un fine in se stessi.
