Riepilogo: le metriche Agile forniscono informazioni sulla produttività nelle diverse fasi del ciclo di vita dello sviluppo software. Ciò aiuta a valutare la qualità di un prodotto e a monitorare le prestazioni del team.
Le metriche sono un argomento delicato.
Da un lato, abbiamo tutti lavorato a un progetto in cui non venivano tracciati dati di alcun tipo ed era difficile capire se si era sulla buona strada verso il rilascio o se l'efficienza aumentava man mano che il progetto andava avanti. D'altra parte, molti di noi hanno avuto la sfortuna di partecipare a progetti in cui le statistiche venivano utilizzate come arma, mettendo i team gli uni contro gli altri o giustificando il lavoro obbligatorio nel fine settimana. Quindi non sorprende che la maggior parte dei team abbia un rapporto di amore/odio verso le metriche.
Ma non deve essere per forza così. Il monitoraggio e la condivisione di solide metriche Agile possono ridurre la confusione e far luce sull'avanzamento (e sulle battute d'arresto) del team durante tutto il ciclo di sviluppo. Ecco come.
Conosci la tua azienda
Lo stato "Completato" racconta solo una parte della storia. L'essenza consiste nel creare il prodotto giusto, al momento giusto e per il mercato giusto. Restare al passo durante l'intero programma significa raccogliere e analizzare dati pertinenti lungo il percorso. In qualsiasi programma Agile, è importante tenere traccia sia delle metriche aziendali che delle metriche Agile. Le metriche aziendali consentono di assicurarsi che la soluzione soddisfi le esigenze del mercato, mentre le metriche Agile misurano gli aspetti del processo di sviluppo.
"Le metriche aziendali di un programma dovrebbero essere radicate nella sua roadmap."
Per ogni iniziativa sulla roadmap, includi diversi indicatori di prestazione chiave (KPI) che mappano agli obiettivi del programma. Inoltre, includi i criteri di successo per ogni requisito di prodotto, come il tasso di adozione da parte degli utenti finali o la percentuale di codice coperta dai test automatizzati. Questi criteri di successo si inseriscono nelle metriche Agile del programma. E più i team imparano, meglio possono adattarsi ed evolversi.
Come utilizzare le metriche KPI Agile per ottimizzare la consegna
Burndown sprint
I team Scrum organizzano lo sviluppo in sprint a temporizzati. All'inizio dello sprint, il team prevede quanto lavoro può completare durante uno sprint. I report burn-down dello sprint monitorano quindi il completamento del lavoro durante lo sprint. L'asse x rappresenta il tempo e l'asse y si riferisce alla mole di lavoro rimanente da completare, misurata in Story Point o in ore. L'obiettivo è quello di completare tutto il lavoro previsto entro la fine dello sprint.
Un team che rispetta in modo costante le previsioni è una pubblicità convincente di Agile nella propria organizzazione. Ma non lasciare che questo ti tenti a truccare i risultati dichiarando un articolo completo prima che lo sia davvero. Questa può sembrare una procedura vincente a breve termine, ma nel lungo periodo ostacola l'apprendimento e il miglioramento.
- Il team finisce in anticipo sprint dopo sprint perché non si impegna abbastanza nel lavoro.
- Il team non rispetta la previsione sprint dopo sprint perché si impegna troppo nel lavoro.
- La linea di burn-down fa cali ripidi piuttosto che un burn-down più graduale perché il lavoro non è stato scomposto in porzioni granulari.
- L'owner di prodotto aggiunge o modifica l'ambito a metà sprint.
Grafico burn-down su epic e rilasci
I grafici burn-down su epic e rilasci (o versioni) tengono traccia dell'avanzamento dello sviluppo su una mole di lavoro più ampia rispetto al burn-down dello sprint e guidano lo sviluppo sia per i team Scrum che per i team Kanban. Dal momento che uno sprint (per i team Scrum) può contenere il lavoro di più epic e versioni, è importante monitorare l'avanzamento sia dei singoli sprint che degli epic e delle versioni.
Lo "slittamento dell'ambito" consiste nell'aggiunta di ulteriori requisiti a un progetto precedentemente definito. Ad esempio, se il team sta lavorando al rilascio di un nuovo sito Web dell'azienda, lo slittamento dell'ambito può implicare la richiesta di nuove funzioni dopo che i requisiti iniziali sono stati abbozzati. Anche se tollerare lo slittamento dell'ambito durante uno sprint è una cattiva pratica, il cambiamento dell'ambito all'interno di epic e versioni è una conseguenza naturale dello sviluppo Agile. Man mano che il team avanza nel progetto, l'owner di prodotto può decidere di prendere o rimuovere lavoro in base alle informazioni in suo possesso. I grafici burn-down su epic e rilasci mantengono tutti informati sugli alti e i bassi del lavoro all'interno dell'epic e della versione.
- Le previsioni su epic o rilasci non vengono aggiornate man mano che il team prosegue con il lavoro.
- Non viene fatto alcun progresso in un periodo di diverse iterazioni.
- Slittamento cronico dell'ambito, che potrebbe indicare che l'owner di prodotto non comprende appieno il problema che la porzione di lavoro in questione sta cercando di risolvere.
- L'ambito cresce più velocemente di quanto il team sia in grado di assorbire.
- Il team non rilascerà versioni incrementali durante lo sviluppo di un epic.
Velocity
La velocity è la quantità media di lavoro che un team Scrum completa durante uno sprint, misurata in Story Point o in ore, ed è molto utile per le previsioni. L'owner di prodotto può utilizzare la velocity per prevedere la velocità con cui un team può lavorare sul backlog, perché il report tiene traccia del lavoro previsto e completato su diverse iterazioni: più iterazioni ci sono, più accurata è la previsione.
Supponiamo che l'owner di prodotto voglia completare 500 Story Point nel backlog. Sappiamo che il team di sviluppo generalmente completa 50 Story Point per iterazione. L'owner di prodotto può ragionevolmente presumere che il team avrà bisogno di 10 iterazioni (più o meno) per completare il lavoro richiesto.
È importante monitorare l'evoluzione della velocity nel tempo. I nuovi team possono aspettarsi di vedere un aumento della velocity man mano che il team ottimizza le relazioni e il processo di lavoro. I team esistenti possono monitorare la loro velocity per garantire prestazioni costanti nel tempo e possono verificare se una particolare modifica del processo ha apportato miglioramenti o meno. Una diminuzione della velocity media è di solito un segno che una parte del processo di sviluppo del team è diventata inefficiente e che dovrebbe essere quindi oggetto di discussione durante la prossima retrospettiva.
Quando la velocity è irregolare per un lungo periodo di tempo, occorre rivedere le pratiche di stima del team. Durante la retrospettiva del team, poni le seguenti domande:
- Ci sono problemi di sviluppo imprevisti che non abbiamo preso in considerazione nella stima di questo lavoro? Come possiamo scomporre meglio il lavoro per scoprire alcune di queste sfide?
- C'è una pressione aziendale esterna che spinge il team oltre i suoi limiti? Di conseguenza, l'adesione alle best practice di sviluppo ne risente?
- Come team, siamo troppo zelanti nelle previsioni per lo sprint?
La velocity di ogni team è unica. Se il team A ha una velocity di 50 e il team B ha una velocity di 75, ciò non significa che il team B abbia una produttività più elevata. Poiché la cultura della stima di ogni team è unica, lo sarà anche la velocity. Resisti alla tentazione di confrontare la velocity tra i team. Misura il livello di impegno e l'output del lavoro in base all'interpretazione degli Story Point unica di ogni team.
Grafico di controllo
I grafici di controllo si concentrano sulla durata di ciclo dei singoli ticket, ovvero sul tempo totale che intercorre tra gli stati "In corso" e "Completato". È probabile che i team con durate di ciclo più brevi abbiano una produttività più elevata e che i team con durate di ciclo coerenti su più ticket garantiscono rilasci più prevedibili. Sebbene la durata di ciclo sia una metrica primaria per i team Kanban, anche i team Scrum possono trarre vantaggio dalla durata di ciclo ottimizzata.
Misurare la durata di ciclo è un modo efficiente e flessibile per migliorare i processi di un team perché i risultati delle modifiche sono percepibili quasi subito e consentono ai team di apportare ulteriori modifiche immediatamente. L'obiettivo finale è quello di avere una durata di ciclo costante e breve, indipendentemente dal tipo di lavoro (nuova funzione, debito tecnico ecc.).
I grafici di controllo possono apparire inizialmente volubili. Non preoccuparti delle anomalie. Cerca le tendenze. Ecco due aree a cui prestare attenzione:
- Durata di ciclo in aumento: l'aumento della durata di ciclo priva il team dell'agilità ottenuta con fatica. Nella retrospettiva del team, prenditi del tempo per analizzare questo aumento. Un'eccezione: se la definizione di lavoro completato stabilita dal team è stata ampliata, probabilmente anche la durata di ciclo si espanderà.
- Durata di ciclo irregolare: l'obiettivo è raggiungere un durata di ciclo coerente per gli elementi di lavoro con valori di Story Point simili. Filtra il grafico di controllo per ogni valore di Story Point per verificarne la coerenza. Se la durata di ciclo è irregolare su valori di Story Point piccoli e grandi, dedica del tempo durante la retrospettiva ad esaminare i fallimenti e a migliorare le stime future.
Diagramma di flusso cumulativo
Il diagramma di flusso cumulativo dovrebbe apparire più o meno uniforme da sinistra a destra. Bolle o spazi vuoti di un colore qualsiasi indicano carenze e colli di bottiglia, quindi quando vedi uno di questi elementi, cerca dei modi per rendere omogenee le bande di colore sul grafico.
- I ticket di blocco creano backup di grandi dimensioni in alcune parti del processo e nulla in altre.
- Crescita incontrollata del backlog nel tempo. Ciò deriva dal fatto che gli owner di prodotto non chiudono i ticket obsoleti o semplicemente con priorità troppo bassa per essere visualizzati.
Ancora altre metriche
Le metriche valide non si limitano ai report descritti sopra. Ad esempio, la qualità è una metrica importante per i team Agile e ci sono una serie di metriche tradizionali che possono essere applicate allo sviluppo Agile:
- Quanti difetti sono stati rilevati?
- durante lo sviluppo?
- dopo il rilascio ai clienti?
- da parte di persone esterne al team?
- Quanti difetti sono rinviati a un rilascio futuro?
- Quante richieste di assistenza clienti vengono ricevute?
- Qual è la percentuale di copertura dei test automatizzati?
I team Agile devono considerare anche la frequenza di rilascio e la velocità di consegna. Alla fine di ogni sprint, il team dovrebbe rilasciare il software nell'ambiente di produzione. Quante volte ciò succede davvero? La maggior parte delle build di rilascio viene rilasciata? Allo stesso modo, quanto tempo impiega il team a rilasciare una correzione di emergenza nell'ambiente di produzione? Il rilascio è agevole per il team o richiede dei salti mortali?
Trova approfondimenti nel contesto
Gli approfondimenti sono un ottimo strumento che i team possono usare per accedere alle metriche quando ne hanno bisogno: durante la pianificazione dello sprint, per un controllo durante le riunioni stand-up giornaliere o per ottimizzare il rilascio. Puoi trovare gli approfondimenti nell'angolo in alto a destra nella vista della board, del backlog e delle distribuzioni di Jira.
Gli approfondimenti forniscono un'istantanea visiva delle seguenti metriche:
- Avanzamento dello sprint
- Ripartizione per tipologia ticket
- Commit dello sprint
- Frequenza di distribuzione
- Durata ciclo
Usa queste metriche per ottimizzare continuamente le prestazioni del team. Scopri di più sugli approfondimenti.
In conclusione...
Le metriche Agile e i KPI sono solo una parte del processo di creazione della cultura di un team. Forniscono informazioni quantitative sulle prestazioni del team e obiettivi misurabili per quest'ultimo. Sebbene siano importanti, non bisogna esserne ossessionati. Ascoltare il feedback del team durante le retrospettive è altrettanto importante per alimentare la fiducia in tutto il team, la qualità del prodotto e la velocità di sviluppo nel processo di rilascio. Usa il feedback sia quantitativo che qualitativo per guidare il cambiamento.
