Tracciare ciò che conta: KPI e cruscotti

Nel capitolo precedente, Progettare per la testabilità: Rompere la prossima barrieraabbiamo analizzato come la testabilità sia diventata un obiettivo chiave dopo aver risolto i colli di bottiglia iniziali nella configurazione del team e nei test manuali. Quel capitolo ha segnato un punto di svolta nella nostra trasformazione DevOps, in quanto abbiamo spostato l'attenzione su principi di progettazione del software più profondi che hanno permesso di eseguire test più fluidi e veloci.

Ora, nel Capitolo 4, passiamo alla fase successiva, fondamentale: la definizione e il monitoraggio dei giusti KPI e la creazione di dashboard per misurare i nostri progressi. Dopo aver messo in atto le pratiche fondamentali e aver migliorato la testabilità, avevamo bisogno di metodi oggettivi e basati sui dati per visualizzare il flusso, identificare i vincoli e migliorare continuamente.

Perché KPI e dashboard sono importanti in DevOps

Man mano che progredivamo nel nostro percorso di ottimizzazione delle consegne end-to-end, abbiamo riconosciuto la necessità di un meccanismo visivo e oggettivo per tracciare il lavoro e scoprire i colli di bottiglia. Ciò significava definire KPI che non si limitassero ai numeri, ma che mettessero in evidenza le intuizioni attuabili e guidassero i comportamenti giusti.

Quando si definiscono i KPI, è essenziale riconoscere che i team e le organizzazioni tendono a ottimizzare le metriche che monitorano. Ciò è in linea con la legge di Goodhart, che afferma che:

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

Questo principio sottolinea l'importanza di selezionare KPI che guidino i team verso i giusti risultati, piuttosto che incoraggiarli a raggiungere semplicemente gli obiettivi. Lo scopo di questi KPI è misurare i progressi verso il nostro obiettivo generale. Ma qual è esattamente questo obiettivo?

Definire l'obiettivo

Come discusso in The Goal di Eliyahu M. Goldratt, l'obiettivo di un'azienda è aumentare l'utile netto migliorando contemporaneamente il ROI e il flusso di cassa. Trasponendo questo concetto al contesto dello sviluppo software, dove attualmente ci troviamo nella fase di investimento, abbiamo identificato l'obiettivo come segue:

 "Sviluppare e fornire un prodotto software commerciabile che generi entrate sostenibili".

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

• Time to Market → Fornire rapidamente funzionalità e prodotti per cogliere le opportunità del mercato.
• Scalabilità futura → Garantire che il software sia progettato per crescere con la domanda senza compromettere le prestazioni.
• Ottimizzazione dei costi → Bilanciare le spese di sviluppo massimizzando la fornitura di valore.
• Ritorno sull'investimento (ROI) → Garantire che il prodotto offra vantaggi finanziari a lungo termine che giustifichino l'investimento.

Queste condizioni hanno guidato la definizione dei nostri KPI, concentrandosinon solo sulla velocità e sull'efficienza, ma anche sulla costruzione di un prodotto scalabile ed economico che offra un valore aziendale a lungo termine.

Visualizzazione del flusso: impostazione dei dashboard

Come descritto in Accelerate di Nicole Forsgren, Jez Humble e Gene Kim, il nostro obiettivo era quello di creare una dashboard in grado di visualizzare e tracciare le quattro metriche DevOps principali:

• Frequenza di distribuzione → Con quale frequenza i team distribuiscono il codice in produzione.
• Lead Time delle modifiche → Velocità con cui il codice passa dal commit alla produzione.
• Tasso di fallimento delle modifiche → La percentuale di distribuzioni che causano fallimenti.
• Tempo medio di ripristino (MTTR) → Velocità con cui i team si riprendono dai guasti.

Tuttavia, generare queste metriche in modo significativo è stato inizialmente difficile a causa della mancanza di un tracciamento sistematico del lavoro tra i vari team. È qui che l'adozione di Azure DevOps come soluzione di gestione del lavoro unica e comune per tutti i team ha fatto una differenza significativa.

Abbiamo iniziato con l'impostazione di dashboard specifici per i team da monitorare:

• Tutti gli elementi di lavoro assegnati per squadra.
• Lavori in corso.
• Lavoro completato.
• Difetti classificati per fase e priorità.

Prima sfida: uso incoerente

Anche in presenza di linee guida chiare, i team utilizzavano gli stati e le categorie di difetti in modo diverso. Questa incoerenza ha reso quasi impossibile l'analisi del flusso tra i team.

La prima sfida che abbiamo incontrato è stata l'uso incoerente degli stati degli elementi di lavoro e delle classificazioni dei difetti, nonostante l'esistenza di linee guida chiare. I diversi team utilizzavano gli stati in modo diverso, rendendo difficile l'identificazione dei problemi di flusso tra i vari team. È diventato fondamentale rendere coerente il modo in cui il lavoro veniva tracciato, assicurando che i dashboard potessero essere utilizzati non solo per i singoli team, ma per l'ottimizzazione del flusso in tutta l'organizzazione.

Ci siamo quindi concentrati sulla definizione corretta delle voci di lavoro, assicurandoci che riflettessero accuratamente la posizione del lavoro nella catena del valore, pur essendo abbastanza generiche da poter essere utilizzate da più team. La maggior parte degli strumenti fornisce categorie di stato predefinite, ma non sempre sono sufficienti. Era importante definire categorie di stato che fossero in linea con la struttura del nostro team, con il flusso di lavoro e con 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, per avere un quadro chiaro di ciò che accadeva nei vari team. Si trattava di feature stories, user stories, difetti e piani di test. Questi dati fornivano un'istantanea del lavoro in corso, ma non fornivano ancora un quadro chiaro del flusso complessivo di lavoro e di valore.

Avere visibilità del lavoro in corso è stato un primo passo importante, ma la sfida successiva è stata quella di 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 delle metriche per mostrare il numero di elementi di lavoro in ogni stato. Inizialmente, disponevamo solo di informazioni sul numero di elementi di lavoro in diversi stati. Analisi più avanzate, come il monitoraggio della durata della permanenza degli elementi di lavoro in ogni stato, richiedevano strumenti aggiuntivi, che abbiamo introdotto 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 preziosi per identificare i principali colli di bottiglia:

• Troppi lavori in corso rispetto al numero di lavori da completare in un determinato periodo.
• Un crescente arretrato di nuovi lavori che superava di gran lunga le possibilità di completamento realistico nei prossimi 3-6 mesi.
• I team con il maggior numero di voci di lavoro arretrate, che indicano la necessità di ulteriore attenzione e supporto.

Ognuna di queste intuizioni ha richiesto una soluzione diversa, ma la capacità di visualizzare il flusso di lavoro ha rappresentato una svolta importante. Questo miglioramento ha portato avanti l'aspetto Strumenti del nostro Triangolo DevOps, fornendo l'impulso per i progressi negli altri due aspetti - Architettura e Persone.

Utilizzare i KPI per promuovere il miglioramento continuo

Siamo tornati sull'argomento dei KPI in diverse fasi della nostra trasformazione DevOps. Man mano che le nostre capacità di monitoraggio miglioravano, siamo stati in grado di generare metriche più dettagliate che us hanno aiutato a:

• Misurare i progressi nel tempo per assicurarci che ci stessimo muovendo verso il nostro obiettivo di sviluppare un prodotto software commerciabile.
• Identificare le dipendenze e i passaggi di consegne che causavano ritardi nel flusso di lavoro.
• Individuare le aree in cui i team necessitano di ulteriore supporto o di miglioramenti dei processi.
• Allineare maggiormente i nostri KPI alle quattro metriche DevOps chiave di Accelerate, fornendo una misura oggettiva del nostro successo.

Allineando strumenti, architettura e persone con i KPI giusti, abbiamo creato un sistema che ha fornito una chiara visibilità sui nostri progressi, us ha aiutatoa identificare e sbloccare i colli di bottiglia e ci ha permesso di rimanere concentrati sulla creazione di valore aziendale a lungo termine.

Cosa c'è dopo? Diramazione e distribuzione continua

Con i nostri KPI e dashboard in funzione, siamo ora pronti per ottimizzare il flusso di codice attraverso gli ambienti e nella produzione. Nel capitolo 5 approfondiremo il nostro approccio al branching e al continuous deployment, nonché i cambiamenti culturali e tecnici che us hanno consentito us implementare in modo più rapido e sicuro.

Restate sintonizzati!