← Torna a tutti gli articoli
Sfide

Perché le Metriche DORA Contano Più della Velocità

Di Marc Molas·17 luglio 2023·9 min di lettura

Ogni sprint planning a cui ho partecipato ha lo stesso rituale. Qualcuno mostra il grafico della velocità, il team discute se i 42 punti dell'ultimo sprint erano "buoni", e tutti si impegnano per arrivare a 45 questa volta. Due settimane dopo, il ciclo si ripete. Nessuno pone la domanda che conta: stiamo migliorando nel consegnare software?

La velocità misura l'attività. Non dice nulla se quei punti si sono tradotti in valore, se il codice era stabile, o se il team sta migliorando. Ho visto team con velocità alle stelle che non riuscivano a consegnare una funzionalità affidabile per salvarsi la vita. E piccoli team con un throughput modesto che deployavano con fiducia più volte al giorno con quasi zero incidenti.

La differenza? Il secondo gruppo stava tracciando le metriche DORA.

Cosa Sono le Metriche DORA?

Nel 2018, Nicole Forsgren, Jez Humble e Gene Kim hanno pubblicato Accelerate: The Science of Lean Software and DevOps. Il libro ha distillato anni di ricerca in quattro metriche che predicono le performance di consegna del software. Non opinioni — indicatori validati dai dati attraverso migliaia di organizzazioni.

Frequenza di Deploy — quanto spesso il tuo team esegue deploy in produzione. I team d'élite deployano su richiesta, più volte al giorno. I low performer deployano mensilmente o meno. Questo cattura la tua capacità di consegnare cambiamenti piccoli e incrementali invece di rilasci grandi e rischiosi.

Lead Time per i Cambiamenti — il tempo dal commit del codice a quando gira in produzione. Élite: meno di un'ora. Low performer: da uno a sei mesi. Ogni collo di bottiglia nel tuo pipeline — revisione del codice, CI/CD, test, approvazioni — appare qui.

Tempo Medio di Ripristino (MTTR) — quando la produzione si rompe, quanto tempo ci vuole per ripristinarla? L'élite ripristina in meno di un'ora. I low performer impiegano una settimana o più. Questo riflette direttamente il tuo monitoraggio, alerting e risposta agli incidenti.

Tasso di Fallimento dei Cambiamenti — quale percentuale di deploy causa un fallimento in produzione. L'élite rimane tra 0-15%. I low performer superano il 46%. Questo cattura la qualità del codice, la copertura dei test e l'affidabilità del pipeline.

La scoperta controintuitiva: velocità e stabilità non sono compromessi. I team più performanti sono sia i più veloci che i più stabili. Deployano più frequentemente, si ripristinano più velocemente e rompono meno.

Perché la Velocità Ti Delude

È un numero relativo e interno. I story point significano cose diverse per team diversi. Una velocità di 60 non ti dice nulla senza un contesto profondo su cosa rappresentano quei punti. Non c'è un benchmark esterno.

Incentiva il comportamento sbagliato. Quando il management osserva la velocità, i team la ottimizzano. Gonfiano le stime, dividono le storie per aumentare i conteggi, e evitano il refactoring perché non produce punti "visibili". La metrica diventa un obiettivo, e una volta che una metrica diventa un obiettivo, cessa di essere una buona metrica — la Legge di Goodhart.

Misura gli output, non gli outcome. Uno sprint in cui il team brucia 50 punti ma rompe la produzione per due giorni? La velocità dice ottimo sprint. DORA dice disastro.

Come Iniziare a Tracciare

Non hai bisogno di una piattaforma. Inizia in modo semplice.

Frequenza di Deploy. Conta i deploy in produzione per settimana dai tuoi log CI/CD. Se deploi meno di una volta a settimana, i tuoi release sono troppo grandi, i tuoi branch vivono troppo a lungo, o il tuo processo di deploy è troppo doloroso.

Lead Time per i Cambiamenti. Timestamp del merge commit meno il primo commit sul branch. Se è più di una settimana, trova il vincolo: ritardi nella revisione del codice? CI lento? Collo di bottiglia di QA manuale?

MTTR. Traccia gli incidenti di produzione: quando rilevati, quando risolti. Anche un foglio di calcolo funziona. Punta a meno di 24 ore inizialmente; meno di un'ora è l'élite.

Tasso di Fallimento dei Cambiamenti. Deploy che hanno causato incidenti diviso per il totale dei deploy. Sotto il 15% è élite. Sopra il 30% significa che il tuo pipeline di test ha dei buchi.

La Conversazione Cambia

Quando i team passano alle metriche DORA, le conversazioni si spostano. Invece di "abbiamo rispettato il nostro impegno di sprint?" chiedono "perché il nostro lead time è aumentato la settimana scorsa?" Invece di discutere 3 punti contro 5, gli ingegneri indagano perché il deploy di giovedì è fallito.

Le metriche DORA sono indicatori anticipatori. Un tasso di fallimento dei cambiamenti in aumento ti avverte prima del prossimo incidente. Un lead time che aumenta segnala un collo di bottiglia prima che diventi una crisi. La velocità è un indicatore ritardato dello sforzo nel migliore dei casi — una metrica di vanità nel peggiore.

I story point possono ancora essere utili per la pianificazione dello sprint all'interno di un team. Ma non dovrebbero mai essere la metrica che riporti al leadership, usi per confrontare i team, o tratti come salute dell'ingegneria. Per questo esistono le metriche DORA.

Per Farlo Durare

Traccia le quattro metriche settimanalmente. Mettile su un dashboard visibile. Discuti le tendenze nelle retro. Fissa obiettivi direzionali: "lead time sotto 3 giorni questo trimestre" è utile. "Aumentare la velocità del 20%" non lo è.

Per la ricerca più approfondita, leggi Accelerate di Forsgren, Humble e Kim. È il libro più basato sui dati sulla consegna del software che abbia trovato, e abbastanza breve per un weekend.

In Conectia, quando integriamo ingegneri senior nel team di un cliente, una delle prime cose che guardiamo insieme è come il team misura le proprie performance. Gli ingegneri che capiscono le metriche DORA non scrivono solo codice — migliorano il sistema che consegna il codice. Questa mentalità è ciò che separa uno sviluppatore che occupa un posto da uno che eleva la capacità del team.


Cerchi ingegneri che si preoccupino delle performance di consegna, non solo delle righe di codice? Parla con un CTO — i nostri ingegneri senior LATAM portano le pratiche e la mentalità che fanno muovere le tue metriche DORA nella direzione giusta.

Pronto a costruire il tuo team di ingegneria?

Parla con un partner tecnico e distribuisci sviluppatori validati da CTO in 72 ore.