DORA metrics 2021: i 4 KPI DevOps per team engineering

Nel giugno 2021 Google Cloud, in collaborazione con il team DORA (DevOps Research and Assessment), ha pubblicato l’ottava edizione del report Accelerate State of DevOps. Lo studio ha raccolto le risposte di oltre 36.000 professionisti tech a livello globale e ha confermato, ancora una volta, che le pratiche DevOps non sono solo “una moda da Silicon Valley”, ma una leva concreta di performance per qualsiasi organizzazione che sviluppa software. Dietro al rumore di sigle, dashboard e framework, il report ricorda una verità semplice: quello che non si misura non si migliora.

Le DORA metrics sono il linguaggio comune che oggi engineering manager, CTO e responsabili di engineering usano per parlare di velocità, qualità e affidabilità del software. Quattro indicatori storici (Deployment Frequency, Lead Time for Changes, MTTR, Change Failure Rate) ai quali nel 2021 si aggiunge una quinta dimensione: la Reliability operativa, in linea con i principi SRE di Google.

Questa guida è pensata per chi guida un team di sviluppo in una PMI software house italiana e vuole capire come introdurre le DORA metrics senza trasformarle nell’ennesimo cruscotto vanity. Vedremo cosa misurare, come misurarlo con tool maturi nel 2021, quali errori evitare e una roadmap di adozione a 60 giorni testata sul campo.

Cosa sono le DORA metrics

L’acronimo DORA sta per DevOps Research and Assessment: un team di ricerca fondato nel 2015 da Nicole Forsgren, Jez Humble e Gene Kim, acquisito da Google Cloud a fine 2018. La loro tesi, validata da sei anni di ricerca quantitativa e dal libro Accelerate (2018), e’ che esistono quattro indicatori capaci di prevedere in modo statisticamente significativo la performance di un’organizzazione software.

I quattro KPI originali si dividono in due famiglie: velocita’ di consegna (Deployment Frequency e Lead Time) e stabilita’ (MTTR e Change Failure Rate). Il messaggio chiave del report 2021 e’ che velocita’ e stabilita’ non sono in trade-off, anzi: i team che vanno piu’ veloci sono anche quelli che falliscono meno. La quinta metrica introdotta nel 2021 – la Reliability operativa – chiude il cerchio collegando il lavoro di engineering all’esperienza percepita dall’utente finale tramite SLO, SLI e error budget.

Le DORA metrics non sono inventate dal nulla: derivano da decenni di Lean Manufacturing applicato al software, e si integrano in modo naturale con framework come Scrum, Kanban e SAFe. Per una PMI, il valore non e’ nel singolo numero ma nel trend: misurare per migliorare, non per giustificare bonus.

I 4 KPI DORA + la quinta metrica 2021

Vediamo nel dettaglio i cinque indicatori del report 2021. Per ciascuno indico definizione operativa, unita’ di misura e soglie per il tier Elite dichiarate nel report.

• Deployment Frequency – quanto spesso il team rilascia codice in produzione. Elite: on demand, piu’ deploy al giorno. Low: meno di un deploy ogni sei mesi.
• Lead Time for Changes – tempo che intercorre tra il commit del codice e il suo rilascio in produzione. Elite: meno di un’ora. Low: oltre sei mesi.
• MTTR (Mean Time To Restore) – tempo medio per ripristinare il servizio dopo un incidente in produzione. Elite: meno di un’ora. Low: oltre sei mesi.
• Change Failure Rate – percentuale di deploy che causano un degrado del servizio (rollback, hotfix, incident). Elite: 0-15%. Low: 46-60%.
• Reliability (nuova 2021) – misura quanto le promesse fatte agli utenti (SLA, SLO) vengono rispettate, includendo disponibilita’, latenza e correttezza.

La quinta metrica nasce dall’osservazione che molti team raggiungevano tier Elite sui primi quattro KPI ma fallivano nel mantenere la promessa di affidabilita’ verso l’utente: deployare 50 volte al giorno non serve se il servizio e’ instabile. La Reliability riallinea la velocita’ al valore percepito.

Elite vs Low performer: il moltiplicatore 973x

Il dato piu’ impressionante del report 2021 e’ il differenziale tra tier Elite e tier Low: i primi rilasciano codice in produzione 973 volte piu’ spesso dei secondi. Hanno un Lead Time piu’ breve di un fattore 6.570x e si recuperano dagli incidenti 6.570 volte piu’ velocemente. Numeri che sembrano usciti da una presentazione marketing, ma che derivano da survey peer-reviewed.

I quattro tier sono Elite, High, Medium, Low. Nel 2021 circa il 26% dei rispondenti si colloca nel tier Elite, il 40% in High, il 28% in Medium e solo il 7% in Low. Il dato e’ incoraggiante: due terzi dei team mondiali ha gia’ superato la soglia di “deploy multipli a settimana”.

Per una PMI italiana il riferimento realistico nei primi 6-12 mesi e’ il tier High: deploy giornalieri o quasi, lead time di un giorno, MTTR sotto le 24 ore, CFR sotto il 20%. Saltare direttamente a Elite richiede investimenti in automazione, infrastruttura e cultura che raramente si giustificano per progetti monolitici o legacy.

Come misurare Deployment Frequency in una PMI

La Deployment Frequency e’ il KPI piu’ semplice da misurare e quello con cui partire. Bastano tre fonti dati: tag git, log della pipeline CI/CD, registro deploy del sistema di orchestrazione.

In GitLab bastano due colpi di SQL sul database delle pipeline o un export via API. GitHub Actions offre da fine 2020 un endpoint REST per i workflow run filtrabili per environment. Jenkins espone via plugin “Build History” un report mensile. Se usi CircleCI, l’orb ufficiale espone metriche su pipeline e job.

Il consiglio operativo e’ definire fin da subito cosa conta come “deploy”. Solo produzione? Anche staging? Solo deploy completi o anche feature flag attivati a runtime? Senza una definizione condivisa, due team della stessa PMI finiscono per misurare cose diverse e confrontarsi diventa impossibile. Nella nostra esperienza la definizione piu’ utile e’ “ogni push in produzione che cambia comportamento osservabile dall’utente, inclusi gli attivatori di feature flag”.

Come misurare Lead Time for Changes

Il Lead Time for Changes e’ la metrica piu’ delicata perche’ richiede di tracciare la storia di ogni commit dal momento in cui entra in main fino al rilascio in produzione. Strumenti come LinearB, Sleuth e Faros AI (quest’ultimo lanciato a gennaio 2021) lo calcolano in automatico correlando eventi git, ticket Jira e deploy.

Se preferisci un approccio fatto in casa, la formula e’ semplice: per ogni release, prendi il timestamp del primo commit incluso e quello del deploy, poi calcola la mediana e il 95esimo percentile su una finestra mensile. La mediana e’ utile per il trend, il p95 per individuare i bottleneck.

Un Lead Time alto in una PMI ha sempre la stessa causa: troppe review manuali, ambienti di staging instabili, batch di rilascio mensili. La cura e’ altrettanto nota: trunk-based development, feature flag, deploy continui. La transizione richiede tempo e un buy-in del business: bisogna spiegare a vendite e marketing che la frequenza alta non significa “rilasciare codice rotto”, ma “rilasciare piu’ piccoli incrementi controllati”.

Come misurare MTTR e gestire l’incident response

Il MTTR (Mean Time To Restore, da non confondere con MTTR-repair) si calcola sommando il tempo tra l’apertura di un incident e la sua risoluzione conclamata, diviso per il numero di incident in un periodo. La precondizione e’ avere un processo di incident management tracciato: senza ticket aperti su PagerDuty, Opsgenie o un canale Slack dedicato, qualsiasi misura e’ una stima.

Per una PMI con due-tre sviluppatori in on-call, il setup minimo prevede: un canale di alert (Datadog, Grafana, New Relic), una rotazione settimanale documentata, una postmortem template e un registro condiviso degli incident. Datadog ha introdotto nel corso del 2021 una DORA dashboard in preview che calcola MTTR e Change Failure Rate correlando deploy events e monitor.

Un errore frequente e’ considerare “incident” solo quanto viene dichiarato esplicitamente dal team. Per metriche affidabili serve definire a priori una soglia tecnica: per esempio “ogni alert P1/P2 che dura piu’ di 10 minuti e che ha generato un ticket”. Le micro-degradazioni risolte in 30 secondi non hanno bisogno di entrare nel calcolo, altrimenti il MTTR diventa rumore.

Come misurare Change Failure Rate

Il Change Failure Rate e’ il KPI piu’ politicamente sensibile, perche’ tocca la qualita’ del lavoro del team. Si calcola dividendo il numero di deploy che hanno richiesto rollback, hotfix o causato incident attribuibili nei n giorni successivi, per il totale dei deploy nello stesso periodo.

La parola chiave e’ “attribuibili”: serve un meccanismo per collegare un incident al deploy che l’ha causato. Sleuth e LinearB lo fanno tracciando deploy markers nei sistemi di monitoring. Se preferisci una soluzione artigianale, ti basta una tabella su BigQuery o un foglio condiviso aggiornato durante la postmortem.

Le soglie del report 2021 sono: Elite 0-15%, High 16-30%, Medium 16-30%, Low 46-60%. Per una PMI che parte da zero, un CFR del 30% e’ un buon obiettivo a 6 mesi. Se sei sopra il 40% non e’ un problema di metriche ma di processo: probabilmente mancano test automatici, review strutturate o canary release.

Tools 2021 per DORA metrics: ecosistema maturo

Nel 2021 il mercato dei tool per DORA si e’ affollato di soluzioni specializzate. Vediamo le opzioni piu’ rilevanti per una PMI software house.

• GitLab – Value Stream Analytics nativo da Premium tier, calcola Lead Time, deploy frequency e cycle time. Ideale se gia’ usi GitLab CI.
• GitHub – Insights e Code Scanning, integrazione con GitHub Actions per metriche deploy. Per il calcolo completo DORA serve un layer aggiuntivo.
• Jenkins – plugin “Build History Metrics” e “Performance” per dashboard custom. Storicamente la scelta dell’enterprise on-premise.
• CircleCI – Insights nativo da inizio 2020, mostra success rate, duration e throughput per pipeline.
• Datadog – DORA dashboard preview lanciata nel 2021, integra deploy events e APM per CFR e MTTR.
• LinearB – lanciato nel 2020, specializzato su DORA + workflow git. Pricing accessibile alle PMI.
• Sleuth – dal 2020, focus su deploy tracking e Change Failure Rate. Integrazione nativa con feature flag e monitoring.
• Faros AI – lanciato a gennaio 2021, piattaforma di engineering operations con DORA come prodotto core.
• Allstacks – analytics di engineering con visione predittiva, integra DORA con risk scoring.
• Pluralsight Flow e Jellyfish – alternative enterprise per organizzazioni piu’ grandi.
• Code Climate Velocity, Athenian – opzioni focalizzate su productivity engineering.

La scelta dipende da budget e maturita’. Una PMI che parte da zero puo’ iniziare con GitLab o GitHub nativo, integrare un cruscotto Datadog per stabilita’ e adottare LinearB o Sleuth quando serve un layer specifico DORA. Evita di comprare suite costose prima di aver chiarito chi guarda le dashboard e con quale frequenza.

DORA come baseline per Lean e Agile transformation

Una delle scoperte piu’ importanti del filone di ricerca DORA e’ che le metriche non sono solo descrittive ma prescrittive: migliorarle implica adottare pratiche di Lean e Agile mature. Trunk-based development, infrastructure as code, test automation, observability, postmortem blameless: tutte pratiche che convergono nei KPI.

Per una PMI che sta avviando una trasformazione Agile, usare DORA come baseline e come “stella polare” e’ molto piu’ efficace di misurare velocity o burndown. Le metriche tradizionali Scrum descrivono “quanto lavoro abbiamo fatto”, le metriche DORA descrivono “quanto valore abbiamo consegnato in produzione”. E’ una differenza enorme: e’ la differenza tra produrre output e produrre outcome.

Un consiglio dal libro Accelerate (Forsgren, Humble, Kim, 2018) e’ partire con un assessment, identificare il KPI piu’ debole e dedicare un trimestre a un esperimento mirato. La trasformazione DORA non e’ big bang: e’ una sequenza di piccole vittorie misurabili.

Errori comuni nell’adozione DORA

Dopo decine di progetti di engineering transformation, gli errori ricorrenti che vediamo in PMI italiane sono pochi e ricorrenti.

• Vanity metrics: pubblicare numeri senza un piano di intervento. Un cruscotto DORA appeso al muro che nessuno commenta in retrospettiva e’ un costo, non un valore.
• No buy-in del team: imporre dall’alto le metriche senza spiegare il “perche'”. Il rischio e’ che il team ottimizzi i numeri (deployare cose vuote per gonfiare la frequency) anziche’ il valore.
• Comparazioni tra team disomogenei: confrontare un team che gestisce un microservizio con uno che lavora su un monolite e’ ingiusto e demotivante.
• Mancanza di improvement loop: senza un meeting mensile dedicato a interpretare i trend, le metriche scivolano nell’irrilevanza.
• Mescolare DORA con valutazioni di performance individuale: i KPI sono di team, non di persona. Usarli per bonus individuali distrugge la fiducia.
• Ignorare la Reliability: ottimizzare solo i primi quattro KPI puo’ portare a deploy frequenti ma instabili.

L’antidoto e’ un patto culturale: il cruscotto DORA appartiene al team, viene rivisto in retrospettiva ogni due o quattro settimane e ogni KPI debole genera un’azione concreta. Non slogan, non bonus, non politica.

Relazione tra DORA e SRE Google: SLO, SLI, SLA

La quinta metrica del 2021, la Reliability, e’ il ponte esplicito tra le pratiche DevOps e la disciplina SRE (Site Reliability Engineering) di Google. SLO (Service Level Objective), SLI (Service Level Indicator) e SLA (Service Level Agreement) sono i mattoni del libro Site Reliability Engineering pubblicato da Google nel 2016.

Per una PMI che vuole adottare la Reliability metric, il punto di partenza e’ definire 2-3 SLI per ogni servizio critico: tipicamente disponibilita’ (uptime), latenza (p95) e tasso di errore. Per ciascuno si fissa un SLO: per esempio “99% di uptime mensile” o “latenza p95 sotto 300ms”. La differenza tra realta’ e SLO alimenta l’error budget: lo spazio di “errore tollerato” che il team puo’ bruciare per innovare velocemente.

La logica e’ geniale: se l’error budget e’ ampio, il team puo’ deployare aggressivamente; se e’ esaurito, deve rallentare e investire in qualita’. E’ un sistema di auto-regolazione che incarna lo spirito DORA: velocita’ e stabilita’ non in conflitto ma in equilibrio dinamico.

Caso reale: PMI romana SaaS, da 1 deploy a settimana a 8 al giorno

Per concretizzare, condivido il caso di una PMI romana, software house SaaS B2B con 14 sviluppatori, su cui abbiamo lavorato nel 2021. Stack: monorepo PHP/Symfony, frontend Vue 2, infrastruttura AWS gestita via Terraform. Situazione iniziale:

• Deployment Frequency: 1 deploy a settimana, sempre il giovedi’ pomeriggio.
• Lead Time for Changes: 6 giorni in mediana, 18 al p95.
• MTTR: 4 ore in mediana, con picchi di 12 ore.
• Change Failure Rate: 38%.

Tier Medium al limite con il Low sul CFR. Il primo intervento e’ stato culturale: workshop di 2 giorni sul libro Accelerate, definizione condivisa di “deploy” e setup di una dashboard Datadog condivisa con i quattro KPI. Poi, in sei mesi, gli interventi tecnici:

• migrazione da branch lunghi a trunk-based development con feature flag (Unleash self-hosted);
• introduzione di canary release con Kubernetes Argo Rollouts;
• refactoring della test suite (da 12 a 4 minuti di esecuzione, parallelizzazione su CircleCI);
• postmortem template e canale Slack dedicato per incident, rotazione on-call settimanale;
• training su observability con Datadog APM e log strutturati.

Dopo sei mesi, i numeri:

• Deployment Frequency: 8 deploy al giorno, distribuiti su tre microservizi.
• Lead Time for Changes: 2 ore in mediana, 8 al p95.
• MTTR: 22 minuti in mediana.
• Change Failure Rate: 12%.

Tier Elite su tre KPI, High sul Lead Time. Il punto chiave non sono i numeri assoluti, ma il modo: nessun outsourcing, nessun rewrite del monolite, nessun “DevOps engineer” assunto ad hoc. Solo pratiche, disciplina e una dashboard che il team controlla ogni venerdi’.

Roadmap DORA in 60 giorni: piano step-by-step

Vediamo una roadmap concreta per una PMI che parte da zero e vuole avere un cruscotto DORA funzionante in 60 giorni.

Settimana 1-2: assessment. Mappa lo stato attuale leggendo log di GitLab/GitHub e ticket di incident degli ultimi 90 giorni. Costruisci un foglio con i quattro KPI in valore mediano. Identifica il KPI piu’ debole.

Settimana 3-4: definizione operativa. Concorda con il team cosa conta come deploy, come incident, come hotfix. Documenta tutto in una pagina di Confluence/Notion. Allinea aspettative con il management su tier target a 6 mesi.

Settimana 5-6: strumentazione. Implementa la dashboard. Per partire bastano due script Python che leggono API di GitLab/GitHub e Datadog, e un cron che alimenta una tabella su BigQuery o un foglio Google. Non serve LinearB dal giorno 1.

Settimana 7-8: primo improvement loop. Retrospettiva dedicata a DORA: il team guarda i numeri, sceglie un’azione di miglioramento sul KPI piu’ debole, la incorpora nello sprint successivo. Ripeti ogni due settimane.

Settimana 9-10: socializzazione. Condividi il cruscotto con il management. Racconta il trend, non il numero assoluto. Allinea le aspettative: il miglioramento e’ graduale, ma costante.

Sessanta giorni dopo, dovresti avere: una dashboard funzionante, una baseline storica, un loop di miglioramento attivo e un team che comincia a sentire le metriche come proprie. Da qui in poi e’ tutto manutenzione e iterazione.

FAQ – Domande frequenti su DORA metrics

Quali sono i 4 KPI delle DORA metrics?

I 4 KPI originali sono Deployment Frequency, Lead Time for Changes, MTTR e Change Failure Rate. Nel 2021 e’ stata aggiunta la Reliability come quinta metrica.

Chi pubblica le DORA metrics?

Le DORA metrics sono pubblicate nel report annuale Accelerate State of DevOps di Google Cloud, basato sulla ricerca del team DORA fondato da Forsgren, Humble e Kim. L’edizione 2021 ha raccolto oltre 36.000 risposte.

Quanto deve essere alta la Deployment Frequency per essere Elite?

Il tier Elite richiede deploy on demand, cioe’ multipli deploy al giorno. Il tier High e’ tra una volta al giorno e una a settimana.

Una PMI italiana puo’ raggiungere il tier Elite?

Si’, ma richiede tipicamente 12-18 mesi di lavoro su automazione, cultura e infrastruttura. Un obiettivo realistico a 6 mesi e’ il tier High.

Qual e’ la differenza tra MTTR e MTBF?

MTTR (Mean Time To Restore) misura quanto tempo serve per recuperare da un incidente. MTBF (Mean Time Between Failures) misura l’intervallo medio tra un guasto e il successivo. DORA usa MTTR.

Quali tool gratuiti consigliate per iniziare con DORA?

Per partire: GitLab CE con Value Stream Analytics (per le pratiche di base), GitHub Insights, o uno script Python che legge le API e alimenta un foglio Google. Non serve subito un tool a pagamento.

Le DORA metrics si possono usare per valutare i singoli sviluppatori?

No, e’ un errore. Le DORA metrics sono di team, non individuali. Usarle per valutazioni di performance personale distrugge la fiducia e incentiva comportamenti perversi.