Cinque metriche KPI Agile che non disprezzerai

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.

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.

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.

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.

Scopri come usare i grafici burn-down in Jira

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.

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.

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.

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.).

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.

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?