Cosa Sono le Metriche DORA? Guida ai Quattro Indicatori

cosa sono le metriche dora

Se ti hanno chiesto cosa sono le metriche DORA e cercavi una risposta diretta: sono quattro misurazioni che quantificano la performance del delivery di software. Deployment Frequency, Lead Time for Changes, Change Failure Rate e Time to Restore Service. Sviluppate da Nicole Forsgren, Jez Humble e Gene Kim, validate su decine di migliaia di team di engineering e acquisite da Google nel 2018. Questa guida copre cosa misura ogni metrica, come si presentano i benchmark in pratica, e dove il modello smette di essere la lente giusta.

Da dove vengono le metriche DORA e perché la ricerca conta

Il programma DORA è iniziato nel 2014 con una domanda specifica: cosa fanno diversamente i team software ad alta performance rispetto a tutti gli altri? Il team di ricerca ha condotto survey annuali su decine di migliaia di developer in diversi settori, cercando le pratiche che predicevano outcome di delivery robusti.

Il risultato che ha reso la ricerca rilevante era controintuitivo. I team elite non scambiavano velocità per stabilità. Shipnavano più velocemente e avevano meno incident in produzione. Questo risultato minava la giustificazione standard per rallentare i cicli di release: se deployiamo meno frequentemente, romperemo meno cose.

I dati dicevano il contrario. I team che deployavano frequentemente costruivano feedback loop migliori, beccavano i problemi prima, e si riprendevano più velocemente quando qualcosa andava storto. Velocità e stabilità non erano in opposizione. Erano correlate.

Google ha acquisito il programma DORA nel 2018. Il team ora pubblica uno State of DevOps Report annuale, ha aggiornato il suo modello nel 2025 con una quinta metrica (Rework Rate), e mantiene la ricerca come iniziativa open a dora.dev. Questa ricerca, durata più di un decennio, è diventata il riferimento industriale per misurare la health di un team di engineering.

Le quattro misurazioni e cosa ognuna effettivamente traccia

Il modello è stato aggiornato nel 2025 per aggiungere Rework Rate come quinta metrica, ma i quattro indicatori originali rimangono la baseline per la maggior parte dei tool e discussioni team.

Deployment Frequency

Quanto spesso il tuo team pushes in produzione. Questa è la definizione completa.

I team elite deployano on-demand: più volte al giorno quando qualcosa è pronto. I low performer deployano una volta al mese o meno. Per un builder singolo, qualsiasi cadenza di shipping consistente settimanale ti mette solidamente in zona high-performing solo da questa singola misura.

La deployment frequency è un proxy per la confidence nella pipeline. I team che deployano infrequentemente solitamente hanno infrastruttura fragile, gate di testing manuali pesanti, o approval chain organizzativi che rallentano i rilasci. I team che shippano più volte al giorno hanno automatizzato via la maggior parte di quei colli di bottiglia. La frequenza è un sintomo di processi solidi, non la causa del successo. È il termometro di una cultura di shipping.

Lead Time for Changes

Il tempo da quando un commit arriva in version control a quando lo stesso change è live in produzione.

La maggior parte di questa durata non è scrivere codice. È aspettare: aspettare che la coda di pull request si svuoti, aspettare che le pipeline CI/CD finiscano, aspettare uno slot di deployment, aspettare qualcuno con accesso per triggerare il rilascio. Un lead time di poche ore significa che il workflow è tight e largamente automatizzato. Un lead time misurato in settimane significa che qualcosa di strutturale sta aggiungendo friction in uno o più di quei handoff point.

Per i developer singoli, il lead time è qualsiasi cosa stia tra fare push a un commit e gli user che vedono il risultato. A volte è una deployment pipeline che impiega dodici minuti. A volte è esitazione interna su se un change sia stabile abbastanza per shippare. Misurare il tuo lead time rivela dove passa il tempo nel tuo workflow e dove puoi automatizzare.

Change Failure Rate

La percentuale di deployment che causano un problema serio abbastanza da richiedere una hotfix, rollback, o incident response.

Questo è il segnale di qualità nel modello DORA. Lo State of DevOps Report 2024 mette i team elite intorno al 5% di change failure rate. I low performer corrono al 46-63%. Se grosso modo metà dei tuoi deployment richiedono intervento immediato, la tua copertura di testing e processo di review hanno gap strutturali significativi. Questo metrica rivela la solidità del tuo testing pipeline e la qualità della review di codice nel team.

Time to Restore Service

Quando un deployment causa un incident, quanto tempo passa prima che il servizio sia ripristinato?

Era originariamente labeled Mean Time to Recovery (MTTR). Il team DORA ha aggiornato il framing nel 2025 a Failed Deployment Recovery Time, tracciando specificamente il recovery da deployment-caused incident. La distinzione conta perché questi incident sono completamente sotto il controllo del team, che li rende il target giusto per il miglioramento di processo.

I team elite ripristinano il servizio in meno di un'ora. I low performer possono impiegare giorni a una settimana. Se sei un builder singolo, questa metrica è largamente su se hai monitoring e alerting in place. La velocità di recovery dipende da quanto velocemente scopri il problema e quanto velocemente puoi deployare la fix.

Come si presentano effettivamente i livelli di performance

Lo State of DevOps report raggruppa i team in quattro livelli in base ai loro numeri DORA. Questi sono range dal report 2024:

Elite tier: Più volte al giorno | Meno di 1 ora | Meno del 5% | Meno di 1 ora

Alto tier: Giornalmente a settimanalmente | 1 giorno a 1 settimana | 5-10% | Meno di 1 giorno

Medio tier: Settimanalmente a mensilmente | 1 settimana a 1 mese | 10-15% | 1 giorno a 1 settimana

Basso tier: Mensilmente o meno | 1 a 6 mesi | 46-63% | 1 settimana a 6 mesi

Il gap tra elite e basso non è incrementale. I low-performing team possono impiegare oltre 180 volte più tempo per deployare e più di 2.500 volte più tempo per recuperare da incident rispetto ai team elite. Non sono differenze marginali. Raggiungere il livello elite è fattibile con investimento sostenuto in automazione CI/CD, copertura di test e observability tooling. Non accade scrivendo codice più veloce. Accade togliendo i step manuali tra committare codice e averlo correre in produzione in modo affidabile.

Come i tool di development AI stanno spostando i numeri DORA nel 2026

Nel 2026, i tool di coding AI sono diventati comuni abbastanza per affettare i numeri DORA in modi che meritano di essere trackati specificamente. Cursor, GitHub Copilot, e modelli simili stanno trasformando come i developer scrivono e testano il codice.

I team che usano questi tool stanno scrivendo codice più veloce, il che tende a spingere la deployment frequency su. Il lead time si è anche accorciato in molti team perché più codice viene prodotto per developer per settimana, significa più commit che fluiscono nella pipeline.

La change failure rate è andata in entrambe le direzioni. I team con forti processi di review e copertura di test hanno mantenuto i loro failure rate stabili mentre shippavano di più. I team che shippano codice AI-generated senza adeguato review hanno visto i failure rate aumentare.

Lo DORA 2024 State of DevOps Report ha trovato che il 41% dei team surveyed ha riportato l'uso di tool di development assistito da AI. Quei team hanno mostrato deployment frequency più alta senza un aumento proporzionale della change failure rate quando l'adozione di AI era paired con automated testing e review pipeline. La lezione è chiara: gli AI tool accelerano la produttività, ma la qualità dipende dalla disciplina nel testing e review.

Tool per trackare metriche DORA senza overbuildare lo stack

La maggior parte dei team inizia a misurare metriche DORA tirando dati dai tool che già usano: GitHub o GitLab per deployment event e timestamp di commit, PagerDuty o OpsGenie per recovery time data, e il sistema di incident management per conteggi di change failure rate.

Diverse piattaforme hanno built dashboard DORA specificamente intorno a questi quattro indicatori. DataDog, New Relic, e Sumo Logic offrono DORA dashboard ready-made per team enterprise. Per un builder singolo senza budget di tooling, uno script che loga il timestamp di ogni deployment in produzione e ogni evento di recovery ti dà deployment frequency e recovery time senza costo di infrastruttura. Il lead time può essere approssimato dai timestamp di commit nel Git log.

Dove le metriche DORA hanno veri limiti

Misurare DORA è utile. Trattarlo come la foto completa della performance di engineering crea diversi blind spot specifici che meritano di essere nominati.

Accumulo di technical debt. Alta deployment frequency con bassa change failure rate non ti dice nulla su se la codebase stia diventando più difficile da lavorare con nel tempo. Un team può raggiungere numeri DORA elite mentre costantemente accumula il tipo di debt che rende ogni nuova feature più lenta da shippare. DORA misura l'output di delivery; non misura lo stato di quello che stai deliverying dentro.

Allineamento di outcome. Deployment frequency misura output, non outcome. Shippare cinque volte al giorno non importa se nessuno di quei change muove una metrica che il prodotto o il business cura. Feature flag, infrastruttura di A/B testing, e tracking di business metric stanno completamente fuori dal modello DORA.