Le stime e le misure nel software. Quanto sono importanti?
Bentrovati a uno degli ultimi appuntamenti del 2021 con l’eXtreme Programming User Group Bergamo, la community che permettere a tutti gli appassionati, o anche solo curiosi, di eXtreme Programming e metodologie di sviluppo Agile del software di incontrarsi e scambiare esperienze e conoscenze.
Protagonista del meetup organizzato il 23 novembre è stato Marco Fracassi, sviluppatore per Chili, il quale ha affrontato una tematica cara a tutti coloro che si occupano di sviluppo software: le stime.
“Misurare non è il fine ma un mezzo, ma un mezzo per cosa?
La pratica di stimare il nostro lavoro per capire quanto ci metteremmo a produrre del software è sempre più comune, ma spesso ci dimentichiamo che le stime, in quanto tali, sono sbagliate per definizione.
Siamo sicuri che ha veramente senso quello che facciamo?
Per cosa usiamo realmente tutte queste stime che forniamo?”
Con il suo talk “Ma diamo i numeri? Le misure nel software” Marco ha portato la sua esperienza nell’utilizzo di stime e misure nel software.
Stime e misure nel software: perché?
Vi siete mai chiesti perché dedichiamo del tempo a stimare e misurare qualcosa relativamente al software che stiamo sviluppando? Alcuni team lo fanno perché semplicemente lo devono fare, senza percepire il reale valore dell’attività.
Adottare stime e misure è importanteper diverse ragioni:
- Aiutano il team nel facilitare discussioni.
- Permettono al team di essere predittivo.
- Favoriscono un ambiente “Fail fast”, ovvero dove si fallisce il più velocemente possibile. Questo perché misurare ciò che facciamo fornisce il “polso della situazione” e quindi correggere il tiro.
- Permettono la condivisione dei progressi a tuti gli attori coinvolti nel progetto.
Prima di parlarci di stime e misure, Marco ha voluto fare chiarezza su due termini che per molti possono risultare sinonimi: piano e planning.
Piano vs Planning
Un piano è generalmente una serie di azioni da svolgere per portare a termine un lavoro o raggiungere un obiettivo. Solitamente lo si fornisce in risposta alla classica domanda “Quanto tempo impiegherete?”. È qualcosa di statico.
La parola planning ci richiama a un’azione che svolgiamo insieme con il team con una certa frequenza, dopo il piano. Richiama a qualcosa di dinamico, che si fa in corso d’opera.
MVP, User Story e pomodori
Per chi come Marco lavora adottando un approccio Lean – ma non solo – il termine MVP risulterà familiare. Brevemente con MVP si intende una versione del prodotto che comprende solo quelle caratteristiche ritenute sufficienti per essere di valore per i clienti e consentirne il rilascio ai primi utenti. Il feedback dei clienti servirà per apportare modifiche / inserire nuove feature durante i successivi cicli di sviluppo.
Un tipico processo di sviluppo software è composto da 3 macro fasi:
- Definizione dell’MVP.
- Scomposizione dell’MVP in User Story (US).
- Stima di ogni US utilizzando come unità di misura il pomodoro.
Nella sua esperienza di sviluppatore Marco ha trovato molto comodo l’utilizzo del pomodoro come unità di misura della difficoltà di una US. Stimare le US è risultata nel tempo un’attività più veloce, dando inoltre una visione più chiara della difficoltà di sviluppo di ogni US. Ad esempio una US stimata 4 pomodori è sicuramente più complessa di una US stimata con 2 pomodori.
Tornando a uno dei vantaggi dell’uso delle stime…come misurare per essere predittivi? Si potrebbero misurare il numero di righe di codice scritte, o meglio ancora l’outcome finale. Misurare l’outcome sarebbe molto interessante perché, iterazione dopo iterazione, o sprint dopo sprint per utilizzare una terminologia Scrum, porterebbe ad avere dati utili al team che faciliterebbero discussioni costruttive per il progetto.
Che cosa stimare?
Oltre al numero di righe di codice scritte potremmo adottare altre misure per stimare l’efficienza del lavoro di un team:
- Le User Story, o meglio il numero di US che vengono rilasciate. Con US rilasciata intendiamo: lo stato della US in Done, i test scritti ed eseguiti con successo e la verifica da parte del Product Owner.
- Il valore che ogni US porta al prodotto sul quale stiamo lavorando.
- Altri aspetti di natura non tecnologica, ma servirebbe definire dei KPI, acronimo di Key Performance Indicator.
Che siano righe di codice o US rilasciate, le stime sono numeri che si riferiscono a qualcosa di poco certo, di non predittibile. Marco suggerisce di stimare e misurare stando il più possibile aderenti al numero.
Una unità di misura molto utilizzata è la velocity.
Velocity
Nelle metodologie agili, la velocity è l’unità di misura che consente di tenere traccia di quanto lavoro può svolgere il team durante uno sprint iterazione. Si prendono in considerazione soltanto le US che sono state completate e validate al termine di ciascuno sprint. È uno strumento molto utile per fare proiezioni su cosa può essere pianificato nello sprint successivo. Spesso la velocity fa riferimento alla velocity media e mai a quella di un singolo sprint ed è utilizzata anche come indicazione di massima per capire cosa è possibile realizzare nel medio termine, e per impostare a grandi linee una roadmap.
Un’altra variante è rappresentata da una percentuale ottenuta mettendo in relazione tra loro l’estimate – la stima – e l’effort – la capacità del team per lo sprint con la seguente formula: (estimate - effort) / effort * 100.
E se non stimassimo più? #noEstimates
Riprendiamo per un attimo il pomodoro utilizzato da Marco e il suo team. Ecco, questo sforzo di decidere un’unità di misura più snella che non sia strettamente un numero è un primo passo verso #noEstimates.
L’approccio #noEstimates, sviluppatosi negli anni con la diffusione delle metodologie Agili, altro non è che un modo per ridurre al minimo l’effort di un team nelle stime e pianificazioni concentrandosi invece su ciò che davvero conta, lo sviluppo e il rilascio di software funzionante.
Il tema di #noEstimates è ampio, vi suggerisco la visione dello speech curato da Woody Zuill (uno dei pionieri della pratica del mob programming, n.d.r.) e la lettura del libro “NoEstimates: How To Measure Project Progress Without Estimating” di Vasco Duarte.
Conclusioni
Durante questo meetup è stato interessante ascoltare Marco che, con i suoi racconti, ha generato un bel momento di condivisione e discussione con i presenti.
È questo lo spirito dei meetup dell’XPUG Bergamo, imparare e condividere conoscenze.