5 metriche Agile indispensabili

Le metriche rappresentano un argomento un po’ delicato.

Da una parte, tutti ci siamo trovati a lavorare almeno una volta su un progetto in cui nessun dato di alcun tipo era stato tracciato, e risultava difficile capire se eravamo in linea con i tempi di release e aumentare i livelli di efficienza man mano che il progetto proseguiva. Dall’altra parte, molti di noi hanno avuto la sfortuna di trovarsi a lavorare su progetti per i quali le statistiche venivano utilizzate come arma per mettere un team in competizione con l’altro, o per giustificare del carico extra di lavoro da svolgere obbligatoriamente durante il weekend.

Non sorprende dunque che molti di noi abbiano un rapporto di amore/odio con le metriche.

Ma non deve essere necessariamente così. Il monitoraggio e condivisione di metriche agile deve servire a ridurre la confusione e mettere in luce il progresso (e gli ostacoli) per il team durante tutto il ciclo di sviluppo. Qui spiegheremo come fare.

Conosci il tuo business

Lo stato “Completato” racconta solo una parte della storia. La cosa importante è costruire il prodotto giusto, al tempo giusto, per il mercato giusto. Per mantenere la giusta direzione durante tutto il programma, è necessario raccogliere e analizzare determinati dati. Per qualsiasi programma Agile, è fondamentale monitorare tanto le metriche di business quanto quelle Agile. Le metriche di business determinano se la soluzione può soddisfare esigenze del mercato, mentre le metriche Agile misurano alcuni aspetti del processo di sviluppo.

Le metriche di business di un programma dovrebbero essere incorporate nella sua roadmap

Per ogni iniziativa in roadmap, predisponi dei KPI che mappino gli obiettivi del programma. Inoltre, specifica quali sono i criteri di misurazione del successo per ogni requisito del prodotto, come la percentuale di adozione da parte degli utenti finali o la percentuale di codice coperto da test automatizzati.
Questi criteri di successo alimentano le metriche agile del programma. E più il team apprende, meglio potrà adattarsi ed evolvere.

Come utilizzare le metriche Agile per ottimizzare la delivery

Le metriche Agile che esponiamo qui sotto si focalizzano sulla delivery del software. Che il tuo team lavori con metodologia Scrum o Kanban, ognuna di queste metriche potrà aiutarti a comprendere meglio il processo di sviluppo, rendendo più facile e rapida la release del software.

1. Sprint Burndown

I team che lavorano in Scrum organizzano il processo di sviluppo per cadenze temporali definite Sprint. All’inizio di ogni Sprint, il team fa previsioni sulla mole di lavoro che potrà essere completata in quell’intervallo di tempo. Un report di Sprint Burndown, traccia il completamento di lavoro per Sprint.
L’asse X rappresenta il tempo, mentre l’asse Y rappresenta la mole di lavoro che deve essere ancora completata, e che può essere misurata in story points oppure in ore. L’obiettivo è di completare tutto il lavoro previsto entro la fine dello Sprint.

Un team che riesce sempre a rispettare le sue previsioni è certamente un ottimo esempio di Agile per l’organizzazione. Ma assicurati che non si tenti di rispettare i numeri dichiarando certe attività complete prima che lo siano veramente. Ciò potrà dare un’immagine positiva nel breve termine, ma nel lungo periodo impedisce ogni forma di apprendimento e crescita.

Situazioni da evitare:

Il team completa l’ammontare di lavoro prima della chiusura ad ogni sprint perché non stanno prendendo in carico abbastanza lavoro;
Il team non soddisfa le previsioni ad ogni Sprint perché stanno stanno prendendo in carico troppo lavoro;
Il grafico di burndown presenta una linea che procede a gradoni piuttosto che in maniera graduale perché il lavoro non è stato scomposto in porzioni granulari;
Il Product Owner aggiunge o modifica lo scope nel mezzo di uno Sprint.

2. Epic e Release Burndown

I grafici di burndown di Epic e release (o versioni) tracciano il progresso di sviluppo su porzioni di lavoro più ampie rispetto che ad una Sprint Burndown, e indirizzano lo sviluppo per team che lavorano tanto in scrum quanto in Kanban. Dal momento che uno sprint (nel caso di Scrum team) può contenere lavoro relativo a molteplici epic e versioni, è importante mappare tanto i risultati per singole sprint quanto quelli relativi alle diverse epic e versioni.

Con il termine “scope creep” si fa riferimento all’inserimento di più requisiti su un progetto già precedentemente definito. Per esempio, se il team si sta occupando di sviluppare un nuovo sito web per l’azienda, uno scope creep potrebbe essere la richiesta di aggiunta di nuove feature dopo che i requisiti iniziali sono già stati disegnati. Mentre lo scope creep è da evitare nell’ambito di una Sprint in corso, la modifica nello scope nel corso di epic e versioni è un aspetto fisiologico dello sviluppo in agile. Mentre il team porta in avanti il progetto, il Product Owner potrà decidere di aggiungere o rimuovere parti di lavoro sulla base di ciò che si sta apprendendo. Un grafico di Epic e Release Burndown serve proprio a rendersi consapevoli dei riflussi di lavoro tra epic e version.

Situazioni da evitare:

Le previsioni di epic o release non sono aggiornate man mano che il team va avanti col lavoro;
Non vengono fatti progressi col passare di numerose iterazioni;
Scope creep cronico, che può essere un segnale che il Product Owner non comprende pienamente il problema che si vuole risolvere attraverso il lavoro;
Lo scope cresce a ritmi più veloci di quanto il team riesca a sostenere;
Il team non sta effettuando rilasci incrementali nel corso di una epic.

3. Velocity

Per Velocity si intende la percentuale media di lavoro che uno scrum team riesce a completare durante una sprint, può essere misurata in story points oppure in ore, ed è molto utile per effettuare previsioni.

Il Product Owner può ricorrere alla Velocity per ipotizzare quanto velocemente il team può portare avanti il lavoro in backlog, in quanto il report traccia i livelli di lavoro previsto e completato nel corso di numerose iterazioni – maggiore il numero di iterazioni, maggiore l’accuratezza.

Ipotizziamo che il Product Owner voglia completare 500 story points nel backlog. Sappiamo che il team di sviluppo in genere completa 50 story points per iterazione. Il Product Owner potrà ragionevolmente stimare che il team avrà bisogno di circa 10 iterazioni per completare il lavoro richiesto. È importante in che modo la Velocity evolve nel tempo: i nuovi team possono aspettarsi un incremento nella Velocity man mano che il team ottimizza le relazioni e il processo lavorativo. I team rodati possono tracciare la loro Velocity per assicurarsi una performance consistente nel corso del tempo, e confermare se un particolare cambiamento nel processo abbia avuto risultati positivi o meno. Una diminuizione nella Velocity media è in genere un segnale che una parte del processo di sviluppo sta diventando inefficiente e debba essere rivista alla prossima retrospettiva.

Situazioni da evitare:

Quando la Velocity risulta irregolare per un lungo periodo di tempo, rivedete sempre i metodi di stima adottati dal team. Durante la retrospettiva, chiedetevi le seguenti domande:

Sono emerse sfide di sviluppo non previste di cui non abbiamo tenuto conto al momento della stima? Come possiamo approcciarci meglio al lavoro per scoprire alcune di queste sfide?
Ci sono pressioni di business esterne che spingono il team oltre i proprio limiti? Ciò ha ripercussioni sull’adozione delle best practice di sviluppo?
Siamo eccessivamente ottimisti nella stima per lo sprint?

La Velocity di ogni team è un aspetto peculiare del determinato team. Se il team A ha una Velocity pari a 50 e il team B una pari a 75, ciò non significa che il team B ha una velocità di esecuzione maggiore tra i due: dal momento che ogni team ha una proprio “cultura di stima“, altrettanto unica sarà la loro velocity.
Resisti alla tentazione di comparare questo parametro tra team differenti! Misura invece il livello di effort e il risultato lavorativo ottenuto secondo i criteri unici di interpretazione degli story points da parte dello specifico team.

4. Control Chart

I grafici di controllo (Control Chart) si focalizzano sui tempi di ciclo delle singole issue – il tempo totale per il passaggio da “In progress” a “Done”. I team con tempi di ciclo più brevi probabilmente avranno rendimenti superiori, e per i team che hanno tempi di ciclo costanti su diverse issue è più facile prevederne i risultati.

Il tempo di ciclo è una metrica primaria per i team Kanban, ma anche i team di Scrum possono beneficiare di tempi di ciclo ottimizzati.

Misurare il tempo di ciclo è infatti un modo flessibile ed efficiente di migliorare i processi di un team in quanto i risultati dovuti a cambiamenti sono quasi immediatamente individuabili, permettendo quindi al team di fare progressivi aggiustamenti. L’obiettivo è di raggiungere costanti e brevi cicli di tempi di ciclo, a prescindere dal tipo di mansione (nuova feature, debito tecnico, etc.).

Situazioni da evitare:

I grafici di controllo possono sembrare complessi in un primo momento. Non preoccuparti di ogni singolo elemento, concentrati sul trend.
Queste sono le due aree su cui focalizzarsi:

Aumento del tempo di ciclo – l’aumento del tempo di ciclo riflette la difficoltà del team di guadagnare “agilità”. Durante le retrospettive del team, prendi del tempo per cercare di comprendere il motivo di questo incremento. Una eccezione: se la definizione di “completo” da parte del team è stata estesa, è fisiologico che risulteranno estesi anche i tempi di ciclo;
Tempo di ciclo irregolare – l’obiettivo è di avere tempi di ciclo costanti per attività che hanno valori di story point simili. Filtra la Control Chart per i diversi valori di story point per verificare che sussista tale costanza. Qualora il tempo di ciclo risultasse irregolare su valori di story point piccoli e grandi, prendetevi del tempo per esaminare e migliorare le stime future.

5. Diagramma Cumulativo di Flusso

Il diagramma cumulativo di flusso è una risorsa fondamentale per i kanban team, per aiutarli ad assicurarsi che il flusso di lavoro risulti coerente. Con il numero di issue posto in asse Y, il tempo sull’asse X, e i colori che indicano i vari stati di workflow, questo diagramma evidenzia visualmente carenze e colli di bottiglia, lavorando in maniera congiunta con i limiti di WIP.

Il diagramma dovrebbe apparire liscio (il più possibile), in quanto le curve convesse o concave indicano rispettivamente carenze e colli di bottiglia, pertanto quando ne vedi una cerca dei modi per raddrizzarle, per qualsiasi banda di colore presente nel diagramma.

Situazioni da evitare:

Issue bloccanti, che creano curve concave in alcune parti del processo e convesse in altre;
Crescita di backlog senza controllo nel corso del tempo. Ciò è causato da Product Owner che non chiudono issue obsolete o semplicemente con priorità troppo bassa per essere messe in esecuzione

E altre metriche ancora!

Esistono molte altre metriche utili oltre a quelle riportate in questo articolo. Per esempio, la qualità è una buona metrica per i team agile e ci sono numerose metriche tradizionali che possono essere applicata anche allo sviluppo in agile, ad esempio:

Quanti errori sono stati individuati…
- in fase di sviluppo?
- a rilascio avvenuto?
- da individui esterni al team?

Quanti errori sono stati rinviati alla prossima release?
Quante richieste di supporto da parte del cliente stanno arivando?
Qual è la percentuale coperta da test automatizzati?

I team Agile dovrebbero inoltre monitorare la frequenza di release e la velocità nella delivery. Al termine di ogni sprint, il team dovrebbe rilasciare del software in produzione.
Quanto spesso ciò avviene effettivamente? Quanto tempo è necessario al team per rilasciare una fix d’emergenza in produzione? La release è un’operazione semplice per il team o appare come un’impresa eroica?

Le metriche sono solo un tassello per costruire una cultura di team. Queste danno informazioni quantitative sulla performance del team e forniscono obiettivi misurabili per la squadra. Nonostante le metriche siano importanti, non dovete esserne ossessionati.
Ascoltare i feedback dei membri del team durante le retrospettive è altrettanto importante nel costruire fiducia all’interno del team, qualità nel prodotto, e velocità lungo il processo di release.
Utilizza tanto i feedback quantitativi quanto quelli qualitativi per guidare il cambiamento!

5 metriche Agile indispensabili

Conosci il tuo business