Metriche Agile con Jira Report

[#1]

"Condivido questo artícolo di @Kalos Bonasia con il suo permesso, speriamo entrambi che aggiunga valore a tutti, e i commenti sono i benvenuti.
Molte grazie"

Le metriche agili misurano gli aspetti chiave di un processo quando si intende applicarle ad una iniziativa di trasformazione digitale. 

Tutti siamo stati coinvolti almeno una volta in un progetto e ci ricordiamo come il fatto di non avere tracciato fin dall’inizio i dati abbia reso poi difficoltoso rispondere, ad esempio, alla classica domanda: “siamo sulla buona strada per il rilascio?”. 

D’altro canto, raccogliere dati senza un obiettivo chiaro fin dall’inizio, potrebbe trasformare queste statistiche in un’arma, mettendo in competizione i team tra di loro o giustificando il lavoro extra nel fine settimana. 

In un contesto di lavoro agile infatti, quale per esempio Scrum, quello che importa non è tanto l’efficienza del team quanto la sua capacità di permettere al proprio cliente, in Scrum rappresentato dal ruolo del Product Onwer, di ottenere i risultati che creano valore per il cliente stesso.

Questi risultati che creano valore in inglese sono detti Outcome e infatti si dice che le metriche per misurare un team agile devono essere Outcome based.

Monitorare e condividere metriche agili può ridurre la confusione e far luce sui progressi (e sulle battute d’arresto) del team durante tutto il ciclo di sviluppo. 

Ma è fondamentale conoscere il proprio business, perché si tratta di costruire il prodotto giusto, al momento giusto, per il mercato giusto. 

Bisogna individuare i criteri di successo per ogni requisito di prodotto, ad esempio il tasso di adozione da parte degli utenti finali o la percentuale di codice coperta da test automatizzati. 

A prescindere che si adotti Scrum o Kanban, ognuna di queste metriche ti aiuterà a capire meglio il processo di sviluppo, rendendo più facile il rilascio del software.

Burndown Sprint

I team Scrum organizzano il lavoro in finestre temporali ben definite e prevedono quanto lavoro potranno portare a termine. 

Un report Burndown Sprint traccia sull’asse X il tempo mentre sull’asse Y la quantità di lavoro rimanente, misurata in story points oppure in ore. L’obiettivo è quello di completare tutti i lavori previsti entro la fine dello Sprint. 

La bravura di un team quindi sta nel rispettare le previsioni, non è sempre facile almeno all’inizio. L’importante è non cedere alla tentazione di alterare i numeri dichiarando un elemento completo prima che lo sia davvero. Può sembrare positivo a breve termine, ma a lungo termine ostacola solo l’apprendimento e il miglioramento.

Burndown Epic

Con questa metrica ci si concentra sul rilascio del lavoro, l’epica circoscrive un sotto insieme di attività su un corpo di lavoro più ampio rispetto a quello dello Sprint Burndown, e guida lo sviluppo sia per i team Scrum che per quelli che invece adottano Kanban. 

Per esempio il blocco di attività da svolgere per un team Scrum può contenere lavori appartenenti a diverse epiche e versioni, quindi è importante tenere traccia sia dell’avanzamento dei singoli sprint sia delle epiche e delle versioni. 

Con il termine “Scope Creep” ci si riferisce a quella situazione in cui vengono inseriti più requisiti in un progetto definito in precedenza. 

Per esempio, se il team sta consegnando un nuovo sito web per l’azienda, potrebbero essere richieste nuove funzionalità dopo che i requisiti iniziali sono già stati delineati. Tollerare uno Scope Creep durante uno sprint è una cattiva pratica. 

Invece, lo Scope Change all’interno di epiche e versioni è una conseguenza naturale di uno sviluppo agile. Mentre il team si muove attraverso il progetto, il proprietario del prodotto può decidere di assumere o rimuovere il lavoro in base a ciò che sta imparando. 

Il grafico Epic Burndown permette di rendere tutti consapevoli del flusso di lavoro (e del “riflusso”) all’interno di ciascuna Epic e di ciascuna Versione.

Velocity

Con questa metrica si indica la quantità media di lavoro che un team Scrum compie durante uno Sprint, misurata in punti storia o in ore, ed è molto utile per le previsioni. 

Il Product Owner può utilizzare un Velocity Report per prevedere la velocità con cui un team può lavorare sul backlog, perché il rapporto tiene traccia del lavoro previsto e completato su diverse iterazioni: più iterazioni saranno registrate, più accurata sarà la previsione. 

Diciamo che il Product Owner vuole completare 500 punti storia in arretrato. Sappiamo che il team di sviluppo generalmente completa 50 punti storia per iterazione.

Il Product Owner può ragionevolmente supporre che il team avrà bisogno di 10 iterazioni per completare il lavoro richiesto. 

È importante monitorare l’evoluzione della velocità nel tempo. I team esistenti possono monitorare la loro velocità per garantire prestazioni costanti nel tempo e possono confermare se una particolare modifica del processo ha apportato o meno miglioramenti. 

Una diminuzione della velocità media è di solito un segno che una parte del processo di sviluppo del team è diventato inefficiente e questo problema dovrebbe essere affrontato durante la prossima retrospettiva. 

La velocità di ogni team è unica. Se la squadra A ha una velocità di 50 e la squadra B ha una velocità di 75, ciò non significa che la squadra B abbia un rendimento maggiore. Poiché la modalità di fare stime di ogni squadra è unica, lo sarà anche la loro velocità. 

È ancora molto importante tenere presente questo aspetto. Resisti alla tentazione di confrontare la velocità tra le squadre. 

Bisogna misurare il livello di sforzo e di produzione del lavoro in base all’interpretazione unica che ciascun team dà sotto forma di story point.

Control Chart

Questo grafico che mette in relazione il tempo di ciclo delle singole attività, il tempo totale da “in corso” a “fatto”. I team con tempi di ciclo più brevi avranno probabilmente una maggiore produttività e quelli con tempi di ciclo costanti per molti aspetti saranno più prevedibili nell’esecuzione del lavoro. 

Il Cycle Time è una metrica primaria per i team che adottano Kanban, ma anche i team Scrum possono beneficiare di un tempo di ciclo ottimizzato. 

Questa misurazione del tempo è un modo efficiente e flessibile per migliorare i processi di un team poiché i risultati dei cambiamenti sono percepibili quasi immediatamente, consentendo di apportare immediatamente ulteriori modifiche. 

L’obiettivo finale è quello di avere un tempo ciclo coerente e breve, indipendentemente dal tipo di lavoro (nuova caratteristica, debito tecnico, eccetera).

Diagramma di flusso cumulativo

Il Cumulative Flow è uno strumento chiave per chi adotta Kanban, perché aiuta a garantire che il flusso di lavoro all’interno del team sia costante. Troviamo il numero di attività / issue sull’asse Y, e il tempo sull’asse X. 

Si usano dei colori per indicare i vari stati del flusso di lavoro, in questo modo a colpo d’occhio si vedranno i colli di bottiglia in combinazione con i limiti WIP. Il diagramma di flusso cumulativo dovrebbe essere liscio da sinistra a destra. 

Bolle o spazi vuoti in qualsiasi colore indicano carenze e colli di bottiglia, quindi si deve cercare di livellare le bande di colore in tutto il grafico. 

Altre metriche importanti in un programma di Digital Transformation Agile sono:

• quanti difetti (bug) sono stati riscontrati durante lo sviluppo ?
• quanti difetti invece dopo il rilascio ai clienti ?
• quanti difetti trovati da persone esterne al team ?
• quanti difetti vengono rinviati a una versione futura ?
• quante richieste di assistenza clienti arrivano ?
• qual è la percentuale di copertura dei test automatizzati ?

I team agili dovrebbero anche considerare la frequenza di rilascio e la velocità di consegna. Alla fine di ogni sprint, il team dovrebbe rilasciare il software per la produzione. Quante volte ciò sta effettivamente accadendo? 

La maggior parte delle release viene consegnata ? 

Nella stessa ottica, quanto tempo ci vuole perché il team rilasci una correzione d’emergenza (patch) in produzione ? 

Le metriche sono solo una parte della costruzione della cultura di un team. Essi forniscono una visione quantitativa della performance del team e forniscono obiettivi misurabili per il team. 

Anche se sono importanti, non fatevi ossessionare. Ascoltare i feedback del team durante le retrospettive è altrettanto importante per aumentare la fiducia nel team, la qualità del prodotto e la velocità di sviluppo durante il processo di rilascio.