Monitorare ciò che conta: KPI e dashboard

Nel nostro capitolo precedente, Progettare per la testabilità: superare il prossimo ostacolo, abbiamo analizzato come la testabilità sia diventata un obiettivo centrale dopo aver risolto i problemi iniziali legati all'organizzazione dei team e ai test manuali. Quel capitolo ha segnato una svolta nella nostra trasformazione DevOps, poiché abbiamo spostato l'attenzione su principi di progettazione software più approfonditi che hanno reso i test più semplici e rapidi.

Ora, nel Capitolo 4, passiamo a una nuova fase fondamentale: la definizione e il monitoraggio dei KPI più adatti e la configurazione delle dashboard per misurare i nostri progressi. Con le pratiche di base ormai consolidate e una testabilità in costante miglioramento, avevamo bisogno di strumenti oggettivi e basati sui dati per visualizzare i flussi di lavoro, individuare le criticità e migliorare continuamente.

Perché i KPI e le dashboard sono importanti nel DevOps

Nel nostro percorso verso la semplificazione della consegna End-to-end, abbiamo riconosciuto la necessità di un meccanismo visivo e obiettivo per tracciare il lavoro e individuare eventuali colli di bottiglia. Ciò ha significato definire KPI che non riguardassero solo i numeri, ma che evidenziassero approfondimenti utili e promuovessero i giusti comportamenti.

Quando si impostano i KPI, è fondamentale considerare che i team e le organizzazioni tendono a ottimizzare le metriche che monitorano. Questo aspetto trova riscontro nella legge di Goodhart, secondo la quale:

"Quando una misura diventa un obiettivo, cessa di essere una buona misura."

Questo principio evidenzia l'importanza di selezionare KPI che guidino i team verso i risultati corretti, anziché incoraggiarli semplicemente a raggiungere dei target numerici. Lo scopo di questi KPI è misurare i progressi verso il nostro obiettivo principale. Ma qual è esattamente questo obiettivo?

Definire l'obiettivo

Come discusso in The Goal da Eliyahu M. Goldratt, l'obiettivo di un'azienda è aumentare l'utile netto migliorando al contempo il ROI e il flusso di cassa. Traducendo questo concetto nel nostro contesto di sviluppo software, in cui ci troviamo attualmente nella fase di investimento, abbiamo definito l'obiettivo come:

 “Sviluppare e fornire un prodotto software commercializzabile che generi ricavi sostenibili.”

Per raggiungere questo obiettivo è necessario soddisfare diverse condizioni essenziali, tra cui:

• Time-to-market → Rilasciare rapidamente funzionalità e prodotti per cogliere le opportunità del mercato.
• Scalabilità futura → Garantire che il software sia progettato per crescere insieme alla domanda senza compromettere le prestazioni.
• Ottimizzazione dei costi → Bilanciare le spese di sviluppo massimizzando al contempo il valore offerto.
• Ritorno sull'investimento (ROI) → Garantire che il prodotto offra benefici finanziari a lungo termine che giustifichino l'investimento.

Queste condizioni hanno guidato la definizione dei nostri KPI, concentrandoci non solo sulla velocità e sull'efficienza, ma anche sulla creazione di un prodotto scalabile e conveniente in grado di generare valore aziendale a lungo termine.

Visualizzare il flusso: configurazione delle dashboard

Come illustrato nel libro Accelerate di Nicole Forsgren, Jez Humble e Gene Kim, il nostro obiettivo era configurare una dashboard in grado di visualizzare e monitorare le quattro metriche DevOps chiave:

• Frequenza dei rilasci → La frequenza con cui i team distribuiscono il codice nell'ambiente di produzione.
• Tempo di lead per le modifiche → La rapidità con cui il codice passa dal commit alla produzione.
• Tasso di errore delle modifiche → La percentuale di rilasci che causa problemi o interruzioni.
• Tempo medio di ripristino (MTTR) → La velocità con cui i team si riprendono da eventuali guasti o problemi.

Tuttavia, generare queste metriche in modo significativo si è rivelato inizialmente complesso a causa della mancanza di un monitoraggio sistematico delle attività tra i vari team. È qui che l'adozione di Azure DevOps come soluzione comune e unificata per la gestione del lavoro di tutti i team ha fatto una differenza significativa.

Abbiamo iniziato configurando dashboard specifiche per team per monitorare:

• Tutte le attività assegnate a ciascun team.
• Il lavoro attualmente in corso.
• Il lavoro completato.
• Difetti classificati per fase e priorità.

Prima sfida: utilizzo non coerente

Nonostante linee guida chiare, i team utilizzavano stati e categorie di difetti in modo diverso. Questa incoerenza rendeva quasi impossibile l'analisi del flusso tra i vari team.

La prima sfida che abbiamo incontrato è stata l'uso non coerente degli stati degli elementi di lavoro e delle classificazioni dei difetti, nonostante la presenza di linee guida chiare. Team diversi utilizzavano gli stati in modo differente, rendendo difficile individuare i problemi di flusso tra i gruppi. Uniformare il monitoraggio del lavoro è diventato fondamentale per garantire che i dashboard potessero essere utilizzati non solo dai singoli team, ma anche per ottimizzare il flusso in tutta l'organizzazione.

Ci siamo quindi concentrati sulla definizione corretta degli elementi di lavoro, assicurandoci che riflettessero accuratamente la fase del valore in cui si trovavano, pur rimanendo abbastanza generici da poter essere utilizzati da più team. La maggior parte degli strumenti fornisce categorie di stato predefinite, ma non sempre erano sufficienti. Era importante definire categorie di stato in linea con la nostra struttura di team, il modo in cui il lavoro scorreva e i nostri colli di bottiglia noti.

Analisi del flusso di lavoro per identificare i colli di bottiglia

I primi dashboard sono stati impostati principalmente per visualizzare il lavoro in corso, così da avere un quadro chiaro di ciò che stava accadendo tra i team. Questo includeva storie di funzionalità, storie utente, difetti e piani di test. Tali strumenti fornivano un'istantanea del lavoro in corso, ma non offrivano ancora una visione chiara del flusso complessivo del lavoro e del valore.

Avere visibilità sul lavoro in corso è stato un primo passo importante, ma la sfida successiva è stata collegare questa visibilità a metriche basate sul flusso che potessero evidenziare dove il lavoro si bloccava e dove era necessario migliorare.

Utilizzando lo stato degli elementi di lavoro, abbiamo creato metriche per mostrare il numero di elementi in ciascuna fase. Inizialmente avevamo informazioni solo sul conteggio degli elementi di lavoro nei diversi stati. Analisi più avanzate, come il monitoraggio del tempo in cui gli elementi rimanevano in ciascuno stato, hanno richiesto strumenti aggiuntivi, introdotti in seguito. In questa fase iniziale, tuttavia, abbiamo iniziato la nostra analisi utilizzando solo i conteggi.

Anche con questi dati di base, i dashboard si sono rivelati utili per identificare i principali colli di bottiglia:

• Troppi elementi di lavoro in corso rispetto al numero di elementi completati in un determinato periodo.
• Un carico di lavoro arretrato in crescita di nuovi elementi che superava di gran lunga ciò che potevamo realisticamente completare nei successivi 3-6 mesi.
• I team con la mole maggiore di lavoro non terminato, indicando dove fossero necessari ulteriore attenzione e supporto.

Ognuna di queste informazioni richiedeva una soluzione diversa, ma la capacità di visualizzare il flusso di lavoro ha rappresentato una svolta importante. Questo miglioramento ha spinto ulteriormente l'aspetto degli Strumenti del nostro Triangolo DevOps, fornendo l'impulso per progressi negli altri due aspetti: Architettura e Persone.

Utilizzo dei KPI per guidare il miglioramento continuo

Siamo tornati sul tema dei KPI in diverse fasi della nostra trasformazione DevOps. Con il miglioramento delle nostre capacità di tracciamento, siamo stati in grado di generare metriche più dettagliate che ci hanno aiutato a:

• Misurare i progressi nel tempo per garantire il raggiungimento del nostro obiettivo di sviluppare un prodotto software commercializzabile.
• Identificare dipendenze e passaggi di consegne che causavano ritardi nel flusso di lavoro.
• Individuare le aree in cui i team necessitavano di ulteriore supporto o di miglioramenti dei processi.
• Allineare i nostri KPI più strettamente alle quattro metriche DevOps chiave di Accelerate, fornendo una misura oggettiva del nostro successo.

Allineando strumenti, architettura e personale con i giusti KPI, abbiamo creato un sistema che ha fornito una chiara visibilità sui nostri progressi, ci ha aiutato a individuare e sbloccare i colli di bottiglia e ha garantito che rimanessimo concentrati sulla creazione di valore aziendale a lungo termine.

Quali sono i prossimi passi? Branching e distribuzione continua

Con i nostri KPI e dashboard operativi, siamo ora pronti a ottimizzare il flusso del codice attraverso gli ambienti fino alla produzione. Nel Capitolo 5, approfondiremo il nostro approccio a Branching e Continuous Deployment e i cambiamenti culturali e tecnici che ci hanno permesso di rilasciare aggiornamenti in modo più rapido e sicuro.

Rimanete sintonizzati!