Simyl
simylflow
Home del Corso
Modulo 3: Flusso di Valore e Flusso
Lezione 3 di 5
12 min

Lead Time vs. Cycle Time

Misurare ciò che i clienti percepiscono rispetto a ciò che i lavoratori sperimentano.

1Definizioni che contano

Questi termini sono spesso confusi ma crucialmente diversi:

Lead Time: Il tempo totale trascorso da quando un cliente fa una richiesta a quando riceve il valore. Questo è ciò che il cliente sperimenta. Include tutta l'attesa, tutta l'elaborazione, tutto.

Cycle Time: Il tempo che il lavoro trascorre essendo attivamente lavorato. Questo è ciò che i lavoratori sperimentano durante la loro porzione del flusso.

Esempio: Un cliente richiede una funzionalità lunedì. Viene prioritizzata e inserita nello sviluppo mercoledì. Uno sviluppatore ci lavora per 2 giorni. Rimane in revisione PR per 3 giorni. Il testing richiede 1 giorno. Viene rilasciata venerdì della settimana successiva.

  • Lead Time: 12 giorni (da lunedì a venerdì della settimana 2)
  • Cycle Time (Sviluppo): 2 giorni
  • Cycle Time (Revisione): Alcune ore
  • Cycle Time (Testing): 1 giorno

Nota: il lavoro attivo è stato forse 4 giorni in totale. Il lead time è stato 12 giorni. Otto giorni sono stati di attesa.

La metrica che probabilmente tracci è sbagliata

La maggior parte dei team traccia il cycle time o la velocity—ciò che i lavoratori producono. Ma ai clienti non importa della tua velocity. A loro importa del lead time—quanto tempo aspettano. Ottimizza per ciò che i clienti percepiscono, non per ciò che sembra buono internamente.

2Da dove viene il divario

Il divario tra lead time e cycle time è il tempo di attesa. E il tempo di attesa tipicamente domina.

Tempo in coda: Lavoro che sta nei backlog, in attesa di essere prioritizzato, in attesa che qualcuno lo prenda in carico.

Ritardi di passaggio: Lavoro completato in una fase, in attesa che la fase successiva abbia capacità.

Ritardi di raggruppamento: Lavoro che è finito ma in attesa di essere rilasciato con altro lavoro.

Dipendenze esterne: In attesa di altri team, fornitori o approvazioni.

Ritardi di calendario: Lavoro che è pronto ma "rilasciamo solo il martedì."

Nella maggior parte delle organizzazioni software, il tempo di attesa è l'80-95% del lead time. Ciò significa che solo il 5-20% del tempo, il lavoro viene effettivamente lavorato.

L'implicazione: migliorare la velocità con cui lavori ha un impatto minimo. Se lavori due volte più velocemente ma le attese rimangono le stesse, il lead time cambia appena. La leva è nelle attese.

2 ore di lavoro, 2 settimane di Lead Time

Una semplice correzione di bug: 2 ore di tempo sviluppatore. Ma: 3 giorni in attesa di assegnazione, 2 giorni in attesa di revisione PR, 1 giorno in attesa di QA, 3 giorni in attesa del rilascio settimanale, 2 giorni di monitoraggio in produzione. Lead time: 11 giorni.

Stesso lavoro, sistema diverso

Stessa correzione di bug, team diverso: PR revisionata in poche ore (PR piccole, priorità del team sulla revisione). Nessuna coda QA (gli sviluppatori testano il proprio codice). Rilascio continuo (nessuna finestra di deploy). Lead time: 3 ore.

3Touch Time e Wait Time

Un'altra suddivisione utile:

Touch Time: Tempo in cui il lavoro viene attivamente fatto progredire da un essere umano. Mani sulla tastiera. Cervello impegnato su questo problema.

Wait Time: Tutto il tempo intermedio. Nelle code. In attesa di revisione. In attesa di rilascio. In attesa di informazioni.

Processing Time: Touch time più tempo macchina (build, test, deploy). Questo è il cycle time.

Quando comprendi questa suddivisione, puoi indirizzare correttamente i miglioramenti:

  • Touch time lungo ma alto valore aggiunto? Probabilmente non è spreco—questo è lavoro qualificato.
  • Touch time lungo ma basso valore aggiunto? Potenziale spreco—automatizza o elimina.
  • Wait time lungo? Quasi certamente spreco—riduci i batch, limita il WIP, elimina le code.

La maggior parte dei team cerca di rendere il touch time più veloce (strumenti migliori, più sviluppatori) quando il problema è il wait time (troppo WIP, raggruppamento, code). È come cercare di far andare le auto più veloci quando sono bloccate nel traffico.

Se hai un problema di lead time, probabilmente hai un problema di wait time. Se hai un problema di wait time, probabilmente hai un problema di WIP. Ridurre il WIP è solitamente il percorso più veloce verso lead time più brevi.

Punti Chiave
  • Il lead time è ciò che i clienti sperimentano; il cycle time è il tempo di lavoro
  • Il divario tra loro è il wait time—solitamente l'80-95% del lead time
  • Migliorare la velocità del lavoro ha un impatto minimo sul lead time
  • Il wait time è solitamente il punto di leva più grande per il miglioramento
  • Traccia il lead time come metrica primaria—è ciò che i clienti percepiscono