Metriche e KPI di sviluppo software agile che aiutano a ottimizzare la consegna del prodotto

Tempo di lettura: 13 minuti

L’approccio agile allo sviluppo software è da tempo una pratica comune. Secondo il sondaggio online di HP, il 16% dei professionisti IT opta per l’agile puro, il 51% si appoggia all’it e il 24% adotta un approccio ibrido agile. Oggi, lo sviluppo a cascata è menzionato più spesso come un differenziatore agile, ciò che agile non è. Abbiamo ampiamente discusso le principali differenze nel nostro white paper sulle metodologie di gestione del progetto agile.

Nonostante l’adattabilità e la flessibilità della gestione agile e la sua risposta rapida ai cambiamenti, il flusso di lavoro può rimanere centralizzato e controllato. I KPI agili (key Performance Indicators) forniscono indicazioni per la pianificazione strategica, la valutazione e il miglioramento dei processi operativi.

I sistemi di gestione del valore tradizionali tendono a concentrarsi sul completamento delle attività nel quadro del programma categorico e dei costi. Tuttavia, con agile, i clienti e i membri del team vedono risultati immediati e regolano i tempi e gli sforzi per fornire un prodotto che corrisponda ai requisiti di pianificazione. Quali strumenti e tecniche richiede tale conoscenza? Ecco la nostra panoramica sulla valutazione delle prestazioni delle metriche di sviluppo agile.

KPI di sviluppo software agile

In questo articolo, non esploreremo tutte le possibili metriche e KPI di sviluppo agile. In cima a quello, si può inventare il proprio quelli che corrispondono al vostro progetto migliore. Tuttavia, descriveremo i KPI più comuni utilizzati su più aspetti di sviluppo software:

• Velocità
• Sprint burndown
• Release burndown
• tempo di Ciclo
• flusso Cumulativo
• l’efficienza del Flusso
• Codice di copertura con test automatizzati
• l’automazione del Test test manuale
• McCabe Complessità Ciclomatica (MCC)
• varianza del Codice

Misura lavori in corso

Velocità

Velocità di misura la quantità di lavoro (un certo numero di caratteristiche) completato in uno sprint. Anche se non è uno strumento di previsione o confronto, velocity fornisce ai team un’idea su quanto lavoro può essere fatto nel prossimo sprint.

L’indice di velocità è unico per ogni squadra e dovrebbe essere impostato per valutare quanto sia realistico l’impegno. Ad esempio, se il backlog del progetto ha 200 punti storia e in media il team completa 10 punti storia per sprint, significa che il team richiederà circa 20 sprint per completare il progetto.

Più a lungo si traccia la velocità, maggiore è la precisione della corrispondenza tra obblighi e costi

Per un team che ha appena adottato la metodologia agile o addirittura intrapreso un nuovo prodotto, le stime di velocità dei primi sprint saranno probabilmente erratiche. Ma man mano che i team acquisiscono esperienza, la velocità raggiungerà il picco e quindi raggiungerà un plateau di flusso prevedibile e aspettativa di prestazioni. Una diminuzione del flusso coerente indicherà problemi nello sviluppo e rivelerà la necessità di un cambiamento.

Suggerimenti per l’utilizzo della metrica della velocità

Incoerenza di combattimento dopo 3-5 sprint. Se la velocità rimane incoerente dopo un lungo periodo di tempo, considerare la valutazione di fattori esterni e interni che impediscono una stima chiara.

Modificare il monitoraggio della velocità in seguito alle modifiche di squadra e attività. Quando un membro del team lascia il progetto o vengono aggiunti più membri / attività, ricalcolare la velocità o riavviare completamente il calcolo.

Tre sprint sono sufficienti per le prime previsioni. Per prevedere le prestazioni future, utilizzare la media dei tre sprint precedenti.

Grafico Sprint burndown

Il grafico sprint burndown mostra la quantità di lavoro rimanente da eseguire prima della fine di uno sprint. Lo strumento è particolarmente prezioso perché visualizza i progressi verso l’obiettivo invece di elencare gli elementi completati. È anche molto utile per scoprire gli errori di pianificazione che una squadra ha fatto all’inizio di uno sprint.

Nel grafico sotto la linea nera rappresenta la linea prevista (tendenza ideale) che mostra a quale velocità la squadra deve bruciare i punti della storia per completare lo sprint in tempo. La linea blu indica la quantità totale di lavoro e il suo progresso durante lo sprint. Puoi vedere che durante i giorni cinque e sei, una squadra non è riuscita a realizzare i progressi previsti. Tuttavia, il settimo giorno, la questione è stata affrontata e il lavoro è tornato in pista. Tali aggiornamenti in corso consentono ai team di affrontare i problemi emergenti durante le riunioni stand-up quotidiane.

Oltre alle prestazioni di lavoro in sé, i grafici burndown possono rivelare problemi di pianificazione

Suggerimenti per avvicinarsi a sprint burndown

I punti storia dovrebbero essere anche nell’ambito. Se il flusso di lavoro non è coerente, alcune attività potrebbero essere state suddivise in blocchi irregolari. La portata della deviazione tra una tendenza ideale e la realtà evidenzia distintamente questo problema.

Account per attività non pianificate. Il grafico burndown è utile per comprendere l’ambito delle attività nascoste e non tracciate. Se la quantità di lavoro aumenta invece di diminuire, il progetto ha molte attività non valutate o non pianificate che dovrebbero essere affrontate.

Utilizzare un grafico di burndown per valutare la fiducia del team. Considerando le tariffe attuali, chiedi al tuo team quanto sono sicuri di completare lo sprint in tempo. Più a lungo si applica questa metrica, più accurate sono le stime sprint.

Stima del rilascio con un grafico di burndown

Un grafico di burndown del rilascio indica la quantità di lavoro che deve essere completata prima di un rilascio. Il grafico illustra la panoramica dei progressi e consente di implementare le modifiche per garantire la consegna puntuale.

Una versione tradizionale del grafico è simile al grafico sprint burndown, ma fornisce una panoramica dell’intero progetto in cui l’asse y è sprint e l’asse x è una misura del lavoro rimanente (giorni, ore o punti storia). Ma, cosa succede se più lavoro viene aggiunto al progetto o il vostro lavoro stimato non soddisfa le aspettative?

Nella tabella sottostante, una squadra pianificava di completare un progetto in quattro sprint e inizialmente aveva 45 punti storia. Mentre i progressi sono andati come previsto durante il primo e il secondo sprint, al terzo sprint il lavoro stimato è aumentato, il che si riflette sull’asse y in valori negativi. Durante il terzo sprint, sono comparsi 5 nuovi punti storia. Non sono stati completati e il quarto sprint ha aggiunto altri 5 punti storia. Pertanto, il progresso e il tempo di rilascio dovevano essere regolati.

Il grafico del burndown del rilascio è super efficace per situazioni con molti requisiti mutevoli e consente a un team di rimanere in pista durante ogni sprint

Come può aiutare il grafico del burndown del rilascio?

Previsione in tempo reale al rilascio. Una volta che il progetto subisce modifiche, che si verificano ogni volta con lo sviluppo iterativo dei prodotti, è necessario vedere in che modo queste modifiche influiscono sulla data di rilascio. Il grafico di burndown del rilascio consente di prevedere la data di rilascio in tempo reale in base agli aggiornamenti nell’ambito di lavoro.

Previsioni scadenza. È possibile stimare se il team può completare una versione del prodotto in tempo o anticipare che la scadenza dovrebbe spostarsi ulteriormente considerando le attività aggiunte.

Stima del numero di sprint. Valutare quanti sprint sono necessari per completare il lavoro è anche un fattore importante da considerare con il grafico di burndown del rilascio.

Valutazione dello stato del processo e individuazione dei colli di bottiglia

Tempo ciclo

La metrica tempo ciclo descrive quanto tempo è stato dedicato a un’attività, incluso ogni volta che il lavoro doveva essere riaperto e completato di nuovo. Il calcolo del tempo di ciclo fornisce informazioni sulle prestazioni complessive e consente di stimare il completamento delle attività future. Mentre il tempo di ciclo più breve illustra prestazioni migliori, i team che forniscono all’interno di un ciclo coerente sono valutati al massimo.

Utilizzando il grafico sottostante è possibile identificare il tempo medio necessario per completare un’attività, tracciare una linea mediana o limite di controllo che non dovrebbe essere attraversata e notare quali attività hanno richiesto insolitamente tempo per essere completate.

La deviazione standard disegna una linea tra il normale e non è raccomandato numero di giorni per completare l’operazione

È anche possibile raggruppare tutti i cicli per un determinato periodo e trarre informazioni dal confronto con gli altri dati. Conducendo un’ulteriore indagine, puoi trarre conclusioni sulla qualità del lavoro.

Qui puoi vedere che il numero di attività completate da marzo a giugno è cresciuto così come il numero di bug

Come usare il tempo di ciclo

Cerca somiglianze. Una buona pratica è trovare articoli simili che richiedono tempi di ciclo imprevedibili per essere completati, rivelando problemi ricorrenti, sia in ingegneria che in gestione.

Disegna le previsioni. È possibile prendere decisioni basate sui dati prevedendo il tempo per completare nuove attività in base a quelle simili del passato.

Traccia il ritmo. Il grafico descrive come mantenere lo stesso ritmo di lavoro e definire se ci sono problemi interni che riducono la velocità di lavoro.

Diagramma di flusso cumulativo (CFC)

La metrica di flusso cumulativo è descritta dall’area del grafico che mostra il numero di diversi tipi di attività in ogni fase del progetto con l’asse x che indica le date e l’asse y che mostra il numero di punti storia. Il suo obiettivo principale è fornire una facile visualizzazione di come le attività vengono distribuite in diverse fasi. Le linee sul grafico dovrebbero rimanere più o meno anche mentre la band con i compiti “fatti” dovrebbe crescere continuamente.

Il grafico rivela un sacco di informazioni critiche come improvviso colli di bottiglia o sale in tutte le bande

CFC sarà di grande utilità per Kanban squadre come semplice visualizzazione del lavoro di gruppo. Il grafico corrisponde anche al flusso di lavoro in tre fasi di Kanban. Qui si mappano anche tre categorie di attività principali: to-do, in corso, e completato.

Inoltre, il grafico aiuta a identificare quando i limiti WIP (work-in-Progress) vengono superati. Essendo uno degli strumenti più preziosi nello sviluppo agile, i limiti WIP hanno lo scopo di coltivare la cultura del lavoro di finitura ed eliminare il multitasking impostando la quantità massima di lavoro per ogni stato del progetto.

Quali problemi vengono evidenziati dalla CFC?

• Backlog crescita indica irrisolte le attività che sono o troppo bassa priorità per affrontare al momento o sono obsoleti
• flusso incostante e improvvisa colli di bottiglia indicare quali aree devono essere appianate in fasi successive
• La larghezza di banda in mostra la media del tempo di ciclo
• Il significativo ampliamento dell’ “In progress” area può dire che la squadra non sarà in grado di completare l’intero progetto in tempo

l’Efficienza del Flusso

l’efficienza del Flusso è molto utile metrica in Kanban di sviluppo per lo più trascurato lo sviluppo team. Mentre l’efficienza del flusso integra il flusso cumulativo, fornisce informazioni sulla distribuzione tra il lavoro effettivo e i periodi di attesa. È un caso raro quando uno sviluppatore lavora su una cosa alla volta senza aspettare. La realtà è di solito più complessa. E “work-in-progress” è un nome che non sempre corrisponde allo stato.

Ad esempio, il codice potrebbe avere molte dipendenze e non è possibile iniziare a lavorare con alcune funzionalità prima che un’altra sia terminata, o che le priorità cambino o che si stia aspettando l’approvazione di uno stakeholder. Misurare quanto tempo si attende rispetto al lavoro può essere ancora più utile di snellire i processi relativi al lavoro effettivo.

Osservando gli indicatori di efficienza più bassi, è possibile comprendere i principali colli di bottiglia

Come utilizzare la formula di calcolo dell’efficienza di flusso

. A meno che non si applichi un software di gestione del progetto che incorpora queste metriche, è possibile calcolare l’efficienza del flusso con questa semplice formula: Lavoro/(lavoro+attesa) * 100%. Quindi puoi visualizzarlo digitalmente o persino disegnare il grafico sulla lavagna dell’ufficio.

Definisci la tua normale efficienza di flusso. Come con tutte le altre metriche, è impossibile rivendicare cifre normali per tutti i progetti. Alcuni dicono che il segno del 15% va bene per la maggior parte dei progetti, il che significa fondamentalmente che un punto storia o un altro elemento di lavoro attende l ‘ 85% contro il tempo di elaborazione del 15%. David J. Anderson, un esperto di gestione della LeanKanban School of Management, suggerisce che il 40 percento e oltre dovrebbe essere l’obiettivo per la maggior parte delle squadre.

Decomporre i dettagli del lavoro prima di fissare l’efficienza del flusso. Il grafico consentirà di visualizzare i periodi di tempo esatti in cui l’efficienza è stata la più bassa. E questi dati devono essere analizzati con molta attenzione, poiché la vera causa e il suo rimedio non vengono rivelati così facilmente. Prima di iniziare azioni intensive, effettuare un’indagine approfondita delle cause.

Aumentare l’efficienza del flusso con l’analisi blocker. Un buon mezzo per realizzare il punto precedente è aumentare l’efficienza del flusso con l’analisi del clustering blocker. Se qualche lavoro è bloccato, merita un adesivo colorato o un’altra forma di segnale visivo per portare questi bloccanti all’attenzione della squadra in modo che possano reagire a loro.

È possibile contrassegnare quanti giorni parte del lavoro è bloccata e dare priorità alla risoluzione

Di solito, i bloccanti si accumulano in cluster poiché hanno molte dipendenze l’uno con l’altro. Una migliore analisi dei blocchi può essere eseguita se li si raggruppa partendo da somiglianze di alto livello come bloccanti interni ed esterni e quindi specificando ulteriormente per progettazione, contenuto mancante o altre funzionalità mancanti. L’analisi Blocker è un modo semplice per indagare le valli nell’efficienza del flusso.

Misurazione della qualità del codice

Copertura del codice

Copertura del codice definisce quante righe di codice o blocchi vengono eseguiti durante l’esecuzione di test automatizzati. La copertura del codice è una metrica critica per la pratica di test-driven Development (TDD) e la distribuzione continua. Tradizionalmente, la metrica è interpretata da un approccio semplice: maggiore è la copertura del codice, migliore è. Per misurare questo, avrete bisogno di uno degli strumenti disponibili come tute. Ma funzionano tutti più o meno allo stesso modo: mentre esegui i test, lo strumento rileverà quale delle righe di codice viene chiamata almeno una volta. La percentuale di linee chiamate è la copertura del codice.

Tuta, per esempio, si rompe la copertura del codice, per ogni file di misurazione e di evidenziare coperto e scoperto linee

Come utilizzare il codice di copertura

messa a Fuoco sulla scoperta linee e non sopravvalutare l’coperti. Se la riga di codice viene chiamata una volta o anche più, non significa necessariamente che la funzione che supporta funzioni perfettamente e gli utenti rimarranno soddisfatti. Chiamare una riga di codice non è sempre sufficiente per chiudere l’attività di test. D’altra parte, la percentuale di linee scoperte mostra ciò che non è stato coperto affatto e potrebbe meritare test.

Dare priorità al codice coperto e non puntare al 100%. Anche se questo sembra controintuitivo, la copertura al 100% non significa che tu abbia testato correttamente il codice. Il tuo progetto ha il codice che conta e il resto di una base di codice. Poiché l’automazione dei test è di solito un’iniziativa costosa, dovrebbe dare la priorità alle funzionalità e ai blocchi di codice corrispondenti.

Automazione di test contro test manuali

Questa misurazione definisce quante righe di codice all’interno di una funzionalità sono già coperte da test automatici rispetto a quelle testate manualmente. Questo segue direttamente la metrica precedente ma ha un caso d’uso specifico. La proporzione di automazione dei test rispetto ai test manuali viene utilizzata solo quando è necessario l’automazione per coprire le regressioni. Il test di regressione viene eseguito per verificare se qualcosa si è rotto dopo gli aggiornamenti delle funzionalità. E se il prodotto subisce miglioramenti costanti-che dovrebbe-test per la regressione dovrebbe essere automatizzato. In caso contrario, gli specialisti del QA manuali dovranno ripetere ripetutamente gli stessi scenari di test dopo ogni commit di aggiornamento.

È possibile utilizzare gli stessi strumenti utilizzati per la copertura del codice per disegnare questa metrica

Delineando la copertura di test automatizzati per funzione consente di definire la priorità delle funzionalità che 1) possono soffrire di regressione dopo gli aggiornamenti, e 2) per i quali i test sono fondamentali. Di solito, non hai abbastanza tempo e risorse umane per coprire tutto con test automatici contemporaneamente, a meno che non lavori all’interno del framework di sviluppo basato sui test. Quindi, è meglio dare la priorità alle funzionalità che avranno sicuramente un impatto sull’esperienza dell’utente.

McCabe Cyclomatic Complexity (MCC) of code

Le misurazioni della complessità del codice vengono utilizzate per valutare i rischi di problemi durante il test e la manutenzione del codice. Maggiore è la complessità del codice, più diventa difficile garantire che abbia un numero accettabile di bug e mantenga un’elevata manutenibilità. L’approccio più comune per misurare la complessità del codice è la McCabe Cyclomatic Complexity Metric (MCC). Una delle formule per disegnare i risultati di complessità per MCC è la seguente:

MCC = bordi – nodi + istruzioni return

MCC sull’immagine è uguale a 3

Con questa metrica, gli sviluppatori non valutare la loro complessità di codice da soggettivamente, cercando in esso. Poiché le competenze degli ingegneri differiscono, le loro valutazioni variano, il che rende il refactoring del codice o la correzione dei bug più impegnativi a lungo termine. Esistono molti strumenti di misurazione MCC sul mercato che possono essere combinati con altre metriche di complessità del codice come la profondità della gerarchia del codice e il numero di righe di codice.

MCC utilizza specifiche e insidie

Bilancia la percezione umana e macchina della complessità del codice. Uno dei motivi principali per utilizzare MCC è quello di rendere il codice leggibile per gli altri sviluppatori. La leggibilità del codice riduce i rischi di onboarding a lungo termine di nuovi sviluppatori che hanno a che fare con il codice legacy. Semplificherà anche il refactoring lungo la strada. Il problema qui è che il modello MCC può considerare inaccettabili alcuni metodi complessi ma leggibili. E se costringi uno sviluppatore a refactoring di metodi complessi in molti sotto-metodi, puoi ottenere i risultati opposti: molti metodi con logiche semplici possono diventare ancora più difficili da comprendere per un essere umano rispetto a un singolo metodo ancora complesso.

Non rendere MCC una metrica restrittiva. Alcune organizzazioni praticano la chiusura di commit di codice che non superano il test MCC. Mentre questo può potenzialmente aumentare la semplicità del codice, è naturale avere codice complesso sui livelli di classi, metodi e funzioni. Bloccarli completamente non è sempre vantaggioso. Una buona pratica è quella di impostare KPI di complessità generale del codice per gli sviluppatori, che li incoraggerà ad avvicinarsi alla codifica in modo più consapevole e pensare alla semplicità.

Applicare MCC per la revisione del codice. Un’altra pratica preziosa per i test MCC è applicarla durante le revisioni del codice per restringere lo scopo del lavoro per rivedere blocchi di codice specifici in cui i rischi di difetti sono i più alti.

Code churn

Code churn è una visualizzazione molto utile delle tendenze e delle fluttuazioni che si verificano in una base di codice sia in termini di processo complessivo che di tempo prima di un rilascio. Churn misura quante righe di codice sono state aggiunte, rimosse o modificate. A volte i grafici mostrano tutte e tre le misurazioni.

Questo esempio di Microsoft include tutti e tre i parametri, ma è possibile utilizzarli in modo selettivo

Sebbene il monitoraggio del code churn possa sembrare una metrica un po ‘ primitiva, consente di valutare la stabilità del codice in diverse fasi di sviluppo. Dovresti aspettarti la stabilità più bassa durante i primi sprint e la massima stabilità – con il concomitante churn più basso – subito prima di un rilascio. Se il tuo codice è altamente instabile e la data di rilascio si avvicina, suona l’allarme.

Casi d’uso del codice churn

Cerca le regolarità. Picchi regolari nelle modifiche al codice possono rivelare che l’approccio di generazione delle attività non è abbastanza focalizzato e produce molte attività di grandi dimensioni su base ricorrente.

Picchi irregolari ma alti richiedono indagini. Se si hanno picchi irregolari ma potenti nelle modifiche al codice, è possibile indagare quali attività hanno causato tali picchi sismici nel codice e riconsiderare il livello di dipendenze, specialmente se il numero di nuove righe di codice ha aumentato anche il numero di righe modificate.

Presta attenzione alle tendenze. La stabilità del prodotto diventa piuttosto critica prima di un rilascio. Come abbiamo detto, il tasso di abbandono dovrebbe avere una tendenza al declino più vicino la tua squadra arriva a un rilascio. Una tendenza crescente significa possibile instabilità del prodotto dopo un rilascio perché è probabile che il nuovo codice non sarà sottoposto a test sufficienti.

Mira al progresso, non al controllo

Proprio come qualsiasi altro indicatore di prestazioni, le metriche agili non hanno sempre risposte distinte o suggerimenti attuabili che sigilleranno il tuo successo. Tuttavia, è necessario utilizzare le conoscenze che forniscono per avviare una discussione, condurre una valutazione e offrire il proprio piano per affrontare problemi problematici.

Mentre le metriche forniscono la visione numerica delle prestazioni di un team e la soddisfazione generale del lavoro, non fissarle. Considerando che le metriche agili non sono standardizzate, non ha senso confrontare i successi di diversi team. Piuttosto assicurati di abbracciare il feedback del tuo team, avviare discussioni regolari e nutrire un’atmosfera di obiettivi e supporto comuni.