Ogni team produttivo di ingegneria del software tiene traccia dei propri miglioramenti attraverso un insieme di indicatori scelti chiamati metriche di ingegneria KPI. Queste sono le 5 metriche di sviluppo Key Performance Indicator (KPI) più essenziali che dovresti iniziare a tracciare oggi stesso.

Hai mai lavorato con un team di ingegneria in cui non venivano misurate metriche KPI? Se lo avete fatto, allora probabilmente sapete quanto sia difficile dire se il team è sulla buona strada per il rilascio o meno.

La verità è che se volete raggiungere i vostri obiettivi di business, dovete assicurarvi che il vostro software soddisfi tutti i requisiti. Per farlo, dovete implementare le metriche di ingegneria KPI nei processi di sviluppo.

Impostare le metriche di ingegneria KPI per il vostro team di sviluppo software, vi permetterà di evitare la scarsa qualità e le scadenze mancate. Quello che otterrete è un team produttivo e un prodotto di alta qualità.

Qui ci sono cinque metriche di sviluppo KPI essenziali che dovresti tracciare per raggiungere i tuoi obiettivi di business.

Sprint Burndown

Che cos’è lo Sprint Burndown?

I team Agile organizzano il loro sviluppo in sprint. Uno sprint burndown misura quanto lavoro il team ha completato durante uno sprint.

Quali sono i benefici?

• Uno sprint burndown è ottimo per mantenere il team consapevole di eventuali blocchi stradali che si verificano.
• Misurando lo sprint breakdown, si può controllare se il team rispetta le sue previsioni.
• Utilizzando un grafico di ripartizione dello sprint, il team può gestire i suoi progressi. Se il team si rende conto che potrebbe non raggiungere l’obiettivo dello sprint, i membri del team possono intraprendere azioni appropriate per rimanere in pista.

Come si misura?

I team Agile usano grafici di ripartizione dello sprint per visualizzare il loro flusso di lavoro. Il grafico ha un asse x che rappresenta il tempo e un asse y che rappresenta la quantità di lavoro rimasto da completare. Si può misurare il tempo in ore o punti storia. Oppure, potete pensare alle vostre statistiche. L’obiettivo principale qui è di avere tutto il lavoro previsto completato entro la fine dello sprint.

Uno strumento che puoi usare è la tabella di scomposizione dello sprint di Jira. Per usarlo, devi creare un account Jira Software e un progetto Jira Software Scrum.

Vedrai un asse verticale che rappresenta i punti della storia. L’asse orizzontale mostra il tempo. La linea rossa nel grafico rappresenta la quantità di lavoro rimasto nello sprint. La linea grigia è la linea di lavoro attuale. Se la linea rossa è sotto la linea grigia, allora significa che il team è sulla buona strada. Tuttavia, se la linea rossa è sopra la linea grigia, questo significa che il progetto è in ritardo sulla tabella di marcia.

Release Burndown

Che cos’è il Release Burndown?

Release burndown offre una panoramica del progresso del rilascio. È simile allo Sprint burn down, ma ha una portata maggiore. Aiuta i team a controllare se riusciranno a rilasciare il prodotto entro una data specifica. Se si rendono conto di essere in ritardo sulla tabella di marcia, possono informare gli utenti e gli stakeholder del ritardo. O, in caso contrario, possono ridurre lo scopo del lavoro per rilasciare il prodotto in tempo.

Quali sono i benefici?

• Puoi controllare quanto velocemente il tuo team sta lavorando attraverso il backlog.
• Puoi avere un’idea di come il lavoro aggiunto e rimosso influenza il progresso del tuo team.
• Puoi fare previsioni su quanti sprint ci vorranno per il tuo team per completare il lavoro.

Come lo misuri?

Il burndown del rilascio è misurato usando un grafico che è simile al grafico della suddivisione dello sprint. La differenza è che ora, l’asse orizzontale rappresenta gli sprint, e l’asse verticale rappresenta il lavoro rimanente (giorni, ore, o punti storia).

Per esempio, guardiamo l’immagine qui sotto. È un grafico di burndown del rilascio di Jira. Si può vedere che il team ha inizialmente fissato quattro sprint e 43 punti storia. In questi quattro sprint, il team ha ridotto il numero di storie da 43 a 26. Il team ha anche previsto che il rilascio del prodotto richiederà altri sette sprint, per un totale di 11.

Cycle Time

Che cos’è il Cycle Time?

Il tempo di ciclo è una metrica di sviluppo KPI che misura quanto tempo il team passa a lavorare su un compito. I grafici del tempo di ciclo sono usati da Scrum Masters e Product Owners per controllare l’efficienza del processo di sviluppo.

Quali sono i benefici?

• Fornisce informazioni sulle prestazioni complessive del team.
• Permette di stimare il completamento dei compiti futuri.
• Puoi notare eventuali colli di bottiglia e rallentamenti nel flusso di lavoro.

Come si misura?

Il tempo di ciclo è uguale alla data finale meno la data iniziale. Per esempio, se il team inizia il lavoro il 1 dicembre e finisce il 10 dicembre, allora il tempo di ciclo è di nove giorni.

Se la squadra inizia il lavoro il 1 dicembre e finisce il compito lo stesso giorno, allora il tempo di ciclo non sarà zero ma uno. Per i progetti che iniziano e finiscono lo stesso giorno, il tempo di ciclo è uguale alla data di fine meno la data di inizio +1.

Puoi sostituire i giorni con settimane, ore, o anche sprint.

Considera di usare i grafici del tempo di ciclo per visualizzare il tuo flusso di lavoro. Questi grafici mostrano quanto tempo un problema ha richiesto per essere completato rispetto al giorno di completamento.

Per esempio, guardiamo il grafico qui sotto. Sull’asse delle x, potete vedere la data in cui il compito è stato chiuso, e sull’asse delle y, potete vedere il tempo impiegato. I cerchi verdi sono i compiti. Un cerchio solido indica un gruppo di problemi, mentre un cerchio aperto indica un singolo problema. Se stai usando uno strumento come Jira, puoi vedere la chiave del compito, il suo codice e il tempo di esecuzione passando il mouse sul cerchio. La linea rossa rappresenta il tempo di ciclo medio, e la linea blu rappresenta il tempo di ciclo medio mobile.

L’obiettivo finale è che la squadra abbia tempi di ciclo coerenti per gli elementi di lavoro che hanno valori simili di story point. Valori più bassi significano che il team sta lavorando in modo efficiente, mentre valori più alti possono indicare colli di bottiglia nel processo di lavoro.

Team Velocity

Che cos’è Team Velocity?

Velocity è un’altra metrica di ingegneria agile KPI che misura la quantità di lavoro che un team completa durante uno sprint. La quantità di lavoro è solitamente misurata in punti storia o ore.

I proprietari dei prodotti usano la velocità per calcolare quanto velocemente un team può lavorare attraverso il backlog. L’indice di velocità è unico per ogni team, e non dovresti paragonare la velocità tra i vari team.

Per esempio, diciamo che vuoi completare 300 punti storia nel backlog. Sapete che il team di sviluppo, in media, completa circa 50 punti storia per iterazione. Con queste informazioni a portata di mano, si può prevedere che il team avrà bisogno di sei iterazioni per completare il lavoro richiesto.

Quali sono i benefici?

• È molto utile per le previsioni.
• Può aiutare a pianificare gli sprint futuri.
• Può aiutare a capire se il team è bloccato o se i cambiamenti del processo stanno funzionando.

Come si misura?

Se avete un team stabile, riuscirete a stabilire una velocità media misurando almeno 5-7 sprint. Se il tuo sprint abituale è settimanale, e il team completa 250 punti storia in un periodo di cinque settimane, allora il tuo tasso di velocità media è di 50 punti storia a settimana.

Guardiamo il grafico della velocità di Jira qui sotto. Le barre blu rappresentano l’impegno, e quelle verdi rappresentano il lavoro effettivo completato. Nello sprint numero 1, il team ha pianificato 16 story point e completato 16 story point. Questo indica che le loro stime erano corrette. Tuttavia, nel secondo sprint, il team ha pianificato 19 punti storia ma ne ha completati solo 12. Questo suggerisce che la prossima volta dovrebbero ridurre il loro piano.

Un flusso incoerente è un indicatore che hai problemi nello sviluppo e devi fare dei cambiamenti.

Flusso cumulativo

Cos’è il flusso cumulativo?

Il flusso cumulativo visualizza lo stato dei tuoi ticket in un periodo di tempo. Mostra il passaggio dei tuoi ticket da uno stato all’altro man mano che il tuo progetto procede.

Quali sono i benefici?

• E’ utile per identificare i colli di bottiglia.
• Aiuta i team ad assicurarsi che il flusso di lavoro sia coerente.
• Ti mostra quanto è stabile il tuo flusso di lavoro.
• Ti aiuta a capire come puoi rendere il tuo processo più prevedibile.

Come lo misuri?

Il modo più semplice per misurare il flusso di lavoro cumulativo è usare i grafici. Essi visualizzano le tre più importanti metriche di ingegneria del software del vostro flusso, incluso il tempo di ciclo, il rendimento e il lavoro in corso.

Guardiamo il grafico qui sotto. L’asse x orizzontale indica il tempo, mentre l’asse y verticale indica gli elementi di lavoro. I diversi colori rappresentano i vari stati del flusso di lavoro. Se le bande procedono in parallelo, significa che il vostro throughput è stabile. Indica che il numero di nuovi compiti che entrano nel vostro flusso di lavoro è uguale al numero di quelli che lo lasciano.

Se una banda si restringe rapidamente, significa che avete più capacità di quella che vi serve. Dovresti riposizionare la capacità per ottimizzare il flusso.

Se una banda si sta rapidamente allargando, significa che stanno entrando nella fase corrispondente più carte di quelle che la stanno lasciando.

Summing Up

Tracciare le metriche di sviluppo KPI sopra descritte può portare ad un esito positivo del processo di sviluppo del prodotto. Riuscirete alla fine a smettere di giudicare il progresso del vostro progetto e ad ottenere una visione dettagliata di ogni fase del ciclo di vita dello sviluppo.

Se volete mettere fine al circolo vizioso di prodotti di bassa qualità, scadenze mancate e fallimenti del codice, iniziate a implementare lo sviluppo di KPI oggi stesso. Riuscirete a rilasciare un prodotto di alta qualità senza rischi connessi.