Monitorare ciò che conta: KPI e Dashboard

Nel nostro capitolo precedente, Progettare per la Testabilità: Rompere la Prossima Barriera, abbiamo esplorato come la testabilità sia diventata un focus 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, poiché abbiamo spostato l'attenzione su principi di progettazione software più profondi che hanno permesso test più fluidi e veloci.

Ora, nel Capitolo 4, passiamo a una fase successiva critica: definire e monitorare i KPI giusti e impostare dashboard per misurare i nostri progressi. Con le pratiche fondamentali in atto e la testabilità in miglioramento, avevamo bisogno di modi oggettivi e basati sui dati per visualizzare il flusso, identificare i vincoli e migliorare continuamente.

Perché i KPI e i dashboard sono importanti nel DevOps

Man mano che progredivamo nel nostro percorso per ottimizzare la consegna End-to-End, abbiamo riconosciuto la necessità di un meccanismo visivo e oggettivo per monitorare il lavoro e individuare i colli di bottiglia. Ciò significava definire KPI che non riguardassero solo i numeri, ma che evidenziassero intuizioni attuabili e promuovessero i comportamenti giusti.

Quando si impostano i KPI, è essenziale riconoscere che i team e le organizzazioni tendono a ottimizzare le metriche che monitorano. Ciò si allinea con la Legge di Goodhart, che afferma:

Quando una misura diventa un obiettivo, smette di essere una buona misura.

Questo principio sottolinea l'importanza di selezionare KPI che guidino i team verso i risultati giusti 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 il profitto netto migliorando contemporaneamente il ROI e il flusso di cassa. Traducendo questo nel nostro contesto di sviluppo software, dove siamo attualmente nella fase di investimento, abbiamo identificato l'obiettivo come:

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

Il raggiungimento di questo obiettivo richiede il soddisfacimento di diverse condizioni necessarie, tra cui:

• Tempo di immissione sul mercato → Fornire rapidamente funzionalità e prodotti per cogliere le opportunità di 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 l'erogazione di valore.
• Ritorno sull'investimento (ROI) → Assicurare 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 su velocità ed efficienza, ma anche sulla creazione di un prodotto scalabile ed economicamente vantaggioso che offra valore aziendale a lungo termine.

Visualizzare il flusso: Configurazione delle dashboard

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

• Frequenza di distribuzione → Quanto spesso i team distribuiscono il codice in produzione.
• Tempo di realizzazione per le modifiche → Quanto velocemente il codice passa dal commit alla produzione.
• Tasso di fallimento delle modifiche → La percentuale di implementazioni che causano guasti.
• Tempo medio di ripristino (MTTR) → Indica la rapidità con cui i team si riprendono dai guasti.

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

Abbiamo iniziato configurando dashboard specifiche per team per monitorare:

• Tutti gli elementi di lavoro assegnati per team.
• Lavoro attualmente in corso.
• Lavoro completato.
• Difetti categorizzati per fase e priorità.

Prima sfida: Utilizzo incoerente

Anche con linee guida chiare, i team utilizzavano stati e 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 fossero in vigore linee guida chiare. Team diversi utilizzavano gli stati in modo differente, rendendo difficile identificare i problemi di flusso tra i team. Garantire la coerenza nel modo in cui il lavoro veniva tracciato è diventato fondamentale, assicurando che le dashboard potessero essere utilizzate non solo per i singoli team ma per l'ottimizzazione del flusso in tutta l'organizzazione.

Ci siamo poi concentrati sulla definizione corretta degli elementi di lavoro, assicurandoci che potessero riflettere accuratamente dove si trova il lavoro nella catena del valore, pur essendo abbastanza generici da essere utilizzati da più team. La maggior parte degli strumenti fornisce categorie di stato predefinite, ma queste non erano sempre sufficienti. Era importante definire categorie di stato che si allineassero alla nostra struttura del team, al flusso di lavoro e ai nostri colli di bottiglia noti.

Analisi del flusso di lavoro per identificare i colli di bottiglia

Le prime dashboard sono state configurate principalmente per visualizzare il lavoro in corso, al fine di ottenere un quadro chiaro di ciò che stava accadendo tra i team. Ciò includeva feature stories, user stories, difetti e piani di test. Queste fornivano un'istantanea del lavoro in corso, ma non fornivano ancora un quadro chiaro del flusso complessivo del lavoro e del valore.

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

Utilizzando lo stato degli elementi di lavoro, abbiamo creato delle metriche per mostrare il numero di attività in ogni fase. Inizialmente, avevamo solo informazioni sul conteggio delle attività nei diversi stati. Analisi più avanzate, come il monitoraggio del tempo in cui le attività rimanevano 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, le dashboard si sono rivelate preziose nell'individuare i principali ostacoli:

• Troppi elementi di lavoro in corso rispetto al numero di elementi completati in un dato periodo.
• Un crescente arretrato di nuove attività che superava di gran lunga ciò che avremmo potuto realisticamente completare nei prossimi 3-6 mesi.
• Team con il maggior arretrato di elementi di lavoro non completati, indicando dove erano necessari maggiore attenzione e supporto.

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

Utilizzo dei KPI per guidare 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 ci hanno aiutato a:

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

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

Cosa c'è dopo? Branching e Continuous Deployment

Con i nostri KPI e dashboard in atto, siamo ora pronti a ottimizzare il flusso di codice attraverso gli ambienti e in produzione. Nel Capitolo 5, approfondiremo come abbiamo affrontato il Branching e il Continuous Deployment, e i cambiamenti culturali e tecnici che ci hanno permesso di effettuare deployment più rapidi e sicuri.

Resta sintonizzato!