Indice
Quello delle stime è uno dei principali problemi nello sviluppo di progetti software su misura, ed è un problema ad oggi non ancora del tutto risolto.
Ci sono però vari modi per affrontare le stime e ridurre il rischio, uno di questi quando si lavora con processi di sviluppo ad iterazioni come Scrum e/o utilizzando le User Stories è quello degli Story Point.
In questa che è la seconda delle due puntate del podcast dedicate all’argomento spiego come si utilizza questo metodo nel migliore dei modi.
In particolare approfondisco l’argomento dal punto di vista di come usare al meglio la tecnica del planning poker, oltre a fornire alcuni suggerimenti derivanti dall’esperienza da applicare quando si deve stimare da zero un nuovo progetto di dimensioni non piccole.
Clicca il tasto play nel player qui sotto per ascoltare subito questa puntata del podcast.
Trascrizione
Ciao da Alex Pagnoni e benvenuto nel CTO Podcast, il podcast di Axelerant dedicato ai CTO e ai responsabili dei team di sviluppo, a chi vorrebbe diventarlo e a Founder e imprenditori digitali.
Nella precedente puntata ho iniziato a parlare delle stime elaborate in forma di Story Point, che vengono adottate tipicamente quando si lavora ad iterazioni come in Scrum o quantomeno quando si lavora basando i requisiti sulle User Story.
Un modo veloce per procedere con le stime è quello del planning poker, che è basato su delle carte come quelle di cui avevo accennato brevemente prima dove sono riportati i vari valori che possono assumere gli Story Point e che vengono distribuite in tante copie quanti sono i membri del team.
Quando si decide di utilizzare questo approccio, una persona, come ad esempio il Product Owner, legge il titolo e la descrizione dei singoli item del backlog.
Prima ancora che la discussione parta, tutte le persone che fanno parte del team di sviluppo devono scegliere una carta con la propria stima per poi metterla a faccia in giù sul tavolo, in modo che si possa vedere quando tutti hanno completato la stima.
Nel caso in cui uno sviluppatore dovesse essere indeciso su due valori, di base dovrebbe sempre scegliere quello più grande.
Una volta che tutti hanno messo la propria carta sul tavolo, le carte vanno girate in modo da mostrare le stime.
A quel punto, se tutte le stime sono uguali, si registra il numero di Story Point per quell’item e si procede senza ulteriori discussioni o approfondimenti.
Altrimenti, se c’è varietà di stime, si chiede alle persone che hanno indicato i valori più bassi e quelli più alti di spiegare perché hanno avuto quella percezione a riguardo della dimensione dell’item.
A questa spiegazione può anche seguire una breve discussione, ma si deve poi procedere il più presto possibile a ripetere la stima ripartendo della carte a faccia in giù, a meno che tutti i membri del team non siano d’accordo a voce a procedere assegnando direttamente un certo numero.
Se ad un certo punto si dovesse rimanere bloccati su due numeri, anche in questo caso si sceglie il numero più grande e si procede.
L’importante è focalizzarsi sul trovare un numero su cui il team è d’accordo, più che ad andare ad approfondire in dettaglio l’item.
In questo processo andrebbero stimati anche i bug, le attività di routine e le attività esplorative chiamate Spike, al cui interno ricadono anche le attività di ricerca, prototipazione, progettazione e così via.
Questo perché le stime rappresentano la dimensione del costo di un certo item e non il valore che questi item creano.
Dato che i bug, le attività di routine e gli spike richiedono tempo e denaro proprio come le user stories, andrebbero stimati se sono pianificati e mescolati nel backlog assieme agli altri item.
L’unica eccezione a questa regola è quando uno di questi task rappresenta un lavoro o un requisito emergente dello sprint in corso, quindi non presente inizialmente in fase di sprint planning, in quel caso non è necessario stimarlo per forza.
Va invece interpretato come una sorta di rumore di fondo o distrazione rispetto al lavoro pianificato inizialmente.
Qui bisogna ricordarsi che è del tutto normale rinegoziare in corso d’opera il contenuto dello sprint, proprio per via della natura adattativa di un processo di lavoro di questo tipo.
Un capitolo a parte va dedicato a quei casi in cui bisogna affrontare un nuovo backlog di grandi dimensioni, come ad esempio un nuovo progetto.
Se infatti ti stai preparando ad affrontare lo sviluppo di un nuovo prodotto digitale, che può durare ad esempio tra i 3 e i 6 mesi, allora sicuramente ti potresti ritrovare con un lungo elenco di item da stimare.
Si tratta sempre di una fase molto delicata e critica, è uno di quei momenti che contribuiscono a decretare il successo o l’insuccesso sia tecnologico che economico di una nuova iniziativa, per esperienza ho una serie di suggerimenti.
Il primo è quello di mettere da parte un paio di giorni da dedicare a questa attività.
Sicuramente avrai infatti bisogno di almeno una o due giornate del tuo team per stimare un progetto che dura almeno 3 mesi.
L’ideale è pianificare queste sessioni in anticipo in modo da includervi pause, cibo e tante stime fino a quando non si è processato l’intero backlog.
Il secondo suggerimento è di utilizzare anche i numeri più grandi degli Story Point, come 20, 40 e 100.
Bisogna infatti evitare di ignorare la stima di alcuni item finché non ci sono più informazioni o di spezzarli in modo da valutarli con maggiore precisione.
Se qualcosa può sembrare troppo grande o rischio, conviene usare i numeri più grandi per comunicare questo tipo di rischio al Product Owner o al cliente.
Inoltre, ogni volta che il tuo team assegna uno dei numeri più grandi come Story Point di un item, valuta se puoi aggiungere al backlog anche un task di routine di una durata predefinita per raccogliere maggiori informazioni per rielaborare la stima o spezzare l’item.
Il terso consiglio è di fare delle pause quando necessario e poi continuare con le stime.
Le prime iterazioni di un progetto sono fondamentali per stabilire la velocità del team di sviluppo, ma se quei primi sprint vengono ingolfati da sessioni da dedicare alla stima dei rimanenti item del backlog la velocity non corrisponderà alle effettive capacità del team.
Ecco perché è molto importante definire il primo giro di stime per l’intero backlog prima di iniziare con lo Sprint n. 1, anche se tutti non vedono l’ora di iniziare a lavorarci.
Come accennavo prima, si può utilizzare la carta del planning poker con il caffè per fare delle pause quando si è stanchi, lasciando ampia libertà al team in questo senso.
Inoltre bisognerebbe valutare di finire la giornata un po’ prima, in modo da consentire al team di mettersi al pari con email e messaggi vari e dargli del tempo per ricaricarsi.
Infine, l’ultimo consiglio è quello di non stare a confrontare in modo eccessivo i tempi effettivi rispetto alle stime.
Se pensi che un certo item sia stato stimato male in modo grossolano dopo che è stato consegnato, allora ovviamente bisogna chiedere approfondimenti al team durante una retrospettiva, che potrebbe offrire l’opportunità di imparare nuove cose o migliorare il processo.
Ma per il resto la maggior parte degli item con la stessa stima in termini di Story Point non richiede esattamente la stessa quantità di tempo.
Il messaggio importate, in questo senso, è infatti che tenere traccia di una buona velocità è più importante che analizzare le stime come se fossero degli impegni, magari addirittura contrattuali, perché le stime sono solo delle previsioni e non degli impegni veri e propri.
Questo ovviamente non deve andare contro alla capacità di un team di sapersi prendere delle responsabilità ed essere efficaci e puntuali nelle consegne, ma bisogna essere consapevole come accennavo prima che gli sprint sono rinegoziabili perché le stime sono appunto delle stime, e riguardano un tipo di lavoro che nel digitale è difficile che si ripeta sempre uguale anche per persone che hanno molta esperienza.
Con questa puntata ho sviscerato abbastanza l’argomento relativo agli Story Point e alle stime, quindi per ora chiudo qui e ti ringrazio per averla ascoltata.
Se hai bisogno di consulenza o supporto per impostare al meglio le stime con il tuo team di sviluppo, o per capire meglio perché i tuoi sviluppatori hanno problemi con le stime, puoi contattarmi tramite la pagina contatti del sito di CTO Mastermind.
Se vuoi approfondire questo argomento o vuoi riportare la tua esperienza, oppure se vuoi suggerire un argomento per le prossime puntate, puoi scrivere nella CTO Mastermind Community.
Visto che ho già dedicato due puntate consecutive al tema delle stime, nei prossimi episodi parlerà di altri argomenti ma poi riprenderò questo filone in altre puntate dove tratterò l’argomento anche da altri punti di vista.
Grazie di nuovo e al prossimo episodio, ciao da Alex.
