DORA-2: Lead Time per le Modifiche

Descrizione

Il lead time per le modifiche misura il tempo che intercorre tra il commit del codice (tipicamente il merge in main) e la sua esecuzione in produzione. È un indicatore della velocità del processo di delivery.

Guida

Perché è importante

Lead time più brevi:

Riducono il work in progress: Meno lavoro non deployato si accumula nel sistema
Accelerano il feedback: I team ricevono feedback dagli utenti più rapidamente
Migliorano la reattività: Più facile rispondere a problemi o cambiare priorità
Riducono il rischio: Meno modifiche accumulate riducono la complessità di ogni rilascio

Differenza da cycle time

Lead time: Dal merge del codice al deployment in produzione (focus di questa metrica)
Cycle time: Dall’inizio del lavoro al deployment in produzione (include tempo di sviluppo)

Target raccomandati

I team DOVREBBERO (SHOULD) puntare a:

Minimo: 1-3 giorni
Ideale: Minuti o ore
Elite: < 1 ora

Come migliorare

Per ridurre il lead time:

Automatizzare la pipeline CI/CD: Ridurre i passaggi manuali
Parallelizzare i test: Eseguire test in parallelo per velocizzare
Ottimizzare i processi di approvazione: Ridurre i gate di approvazione manuale
Implementare deployment automatici: Eliminare il deployment manuale
Ridurre le dimensioni dei batch: Modifiche più piccole passano più velocemente
Migliorare l’infrastruttura: Pipeline più veloci, ambienti on-demand

Misurazione

Stato	Criteri
🟢 VERDE	Lead time di minuti o ore
🟡 AMBRA	Lead time di 1-3 giorni
🔴 ROSSO	Lead time superiore a 3 giorni

Come misurare

Tracciare:

Timestamp del merge in main
Timestamp del deployment in produzione
Tempo medio tra i due eventi
Distribuzione (percentili: p50, p90, p95)

Strumenti:

Git commit timestamps + deployment logs
CI/CD analytics (GitHub Actions, GitLab CI)
DORA metrics tools (Sleuth, LinearB, Haystack)