Indicazioni sul flusso cumulativo, sul lead time e sul cycle time

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Si usano diagrammi di flusso cumulativi (CFD) per monitorare il flusso di lavoro attraverso un sistema. Le due metriche principali da tenere traccia, il tempo del ciclo e il lead time, possono essere estratte dal grafico. Per configurare o visualizzare grafici CFD, vedere Configurare un grafico di flusso cumulativo.

In alternativa, è possibile aggiungere i grafici di controllo del tempo di lead e del ciclo ai dashboard.

Grafici di esempio e metriche principali

Il CFD flusso continuo fornisce il grafico più favorito dai team che seguono un processo snello.

Tuttavia, molti team hanno iniziato a combinare pratiche Lean con Scrum o altre metodologie, il che significa che le applicano all'interno del ciclo di un'iterazione o sprint. In questa situazione il diagramma assume un aspetto leggermente diverso e fornisce due informazioni aggiuntive e molto preziose, come illustrato nel grafico successivo.

Flusso continuo

Il CFD a periodo fisso mostrato qui è per uno sprint completato.

La riga superiore rappresenta l'ambito impostato per lo sprint. E, poiché il lavoro deve essere completato entro l'ultimo giorno dello sprint, la pendenza dello stato Chiuso indica se il team è sulla buona strada per completare lo sprint. Il modo più semplice per pensare a questa visualizzazione è considerarla come un grafico burnup.

I dati vengono sempre rappresentati con il primo passaggio del processo come in alto a sinistra e l'ultimo passaggio del processo come in basso a destra.

CFD a periodo fisso per uno sprint terminato

Metriche del grafico

I grafici CFD visualizzano il numero di elementi di lavoro raggruppati per stato/colonna nel tempo. Le due metriche principali da tenere traccia, il tempo del ciclo e il lead time, possono essere estratte dal grafico.

---

Metrica

Definizione

---

Tempo ciclo¹

Misura il tempo necessario per spostare il lavoro in un singolo processo o stato del flusso di lavoro. Il calcolo va dall'inizio di un processo all'inizio del processo successivo.

Lead Time¹

Per un processo di flusso continuo: misura la quantità di tempo che richiede quando viene effettuata una richiesta (ad esempio l'aggiunta di una storia utente proposta) fino al completamento della richiesta (chiusa).

Per un processo sprint o a periodo fisso: misura il tempo da quando inizia il lavoro su una richiesta fino al completamento del lavoro (ovvero il tempo da Attivo a Chiuso).

Lavoro in corso

Misura la quantità di lavoro o il numero di elementi di lavoro in corso di lavoro.

Scope

Rappresenta la quantità di lavoro impegnata per il periodo di tempo specificato. Si applica solo ai processi a periodo fisso.

---

¹ Il widget CFD (Analisi) e il grafico CFD predefinito (archivio dati di rilevamento del lavoro) non forniscono numeri discreti in lead time e tempo del ciclo. Tuttavia, i widget Lead Time e Cycle Time forniscono questi numeri.

Esiste una correlazione ben definita tra il tempo di lead/il tempo di ciclo e il lavoro in corso (WIP). Più lavoro in corso (WIP) c'è, più lungo è il tempo del ciclo, il che porta anche a tempi di consegna più lunghi. L'opposto è anche vero, meno WIP, più breve è il ciclo e il lead time. Quando il team di sviluppo si concentra su un minor numero di elementi, riduce il ciclo e i lead time. Questa correlazione è un motivo chiave per cui è possibile e necessario impostare limiti di lavoro in corso sulla scheda.

Il conteggio degli elementi di lavoro indica la quantità totale di lavoro in un determinato giorno. In un CFD a periodo fisso, una variazione in questo conteggio indica la modifica dell'ambito per un determinato periodo. In un flusso continuo CFD indica la quantità totale di lavoro nella coda e completata per un determinato giorno.

La scomposizione del lavoro in colonne specifiche della scheda fornisce una visualizzazione del lavoro in corso. Questa visualizzazione fornisce informazioni dettagliate sulla posizione in cui il lavoro si sposta senza problemi, in cui sono presenti blocchi e dove non viene eseguito alcun lavoro. È difficile decifrare una visualizzazione tabulare dei dati, ma il grafico CFD visivo dimostra che sta accadendo qualcosa in un certo modo.

Identificare i problemi, eseguire azioni appropriate

Il CFD risponde a diverse domande specifiche e in base alla risposta, è possibile intraprendere azioni per regolare il processo di spostamento del lavoro attraverso il sistema. Esaminiamo ognuna di queste domande qui.

Il team completerà il lavoro in tempo?

Questa domanda si applica solo ai CFD a periodo fisso. Si ottiene una comprensione esaminando la curva (o la progressione) del lavoro nell'ultima colonna della lavagna.

In questo scenario, può essere opportuno ridurre l'ambito del lavoro nell'iterazione se è chiaro che il lavoro, a un ritmo costante, non viene completato abbastanza rapidamente. Potrebbe indicare che il lavoro è stato sottovalutato e dovrebbe essere inserito nella pianificazione degli sprint successivi.

Esistono tuttavia altri motivi che possono essere determinati esaminando altri dati nel grafico.

Qual è il flusso di avanzamento del lavoro?

Il team sta completando il lavoro a ritmo costante? Un modo per indicare è esaminare la spaziatura tra le diverse colonne del grafico. Sono di una distanza simile o uniforme l'una dall'altra dall'inizio alla fine? Una colonna viene visualizzata in linea piatta in un periodo di più giorni? O sembra "gonfiarsi"?

Mura, il termine per indicare linee piatte e rigonfiamenti nel contesto lean, significa irregolarità e indica una forma di spreco (Muda) nel sistema. Qualsiasi irregolarità nel sistema causerà la visualizzazione di rigonfiamenti nel CFD.

Il monitoraggio del CFD per linee piatte e rigonfiamenti supporta una parte fondamentale del processo di gestione del progetto basato sulla teoria dei vincoli. La protezione dell'area più lenta del sistema è definita come processo drum-buffer-rope e fa parte della pianificazione del lavoro.

Due problemi vengono visualizzati come linee piatte e come rigonfiamenti.

Le linee piatte vengono visualizzate quando il team non aggiorna il lavoro con cadenza regolare. La bacheca offre il modo più rapido per spostare il lavoro da una colonna a un'altra.
Le linee flat possono essere visualizzate anche quando il lavoro tra uno o più processi richiede più tempo del previsto. Le linee piatte appaiono in molte parti del sistema perché se solo una parte del sistema o due parti di un sistema presentano problemi, si noterà un rigonfiamento.

Linee piatte

Gli accumuli si verificano quando il lavoro si accumula in una parte del sistema e non si sposta attraverso il processo.
Ad esempio, un rigonfiamento può verificarsi quando i test richiedono un periodo più lungo rispetto allo sviluppo, causando l'accumulo del lavoro nello stato di sviluppo (i rigonfiamenti indicano che una fase successiva presenta un problema, non necessariamente la fase in cui si verifica il rigonfiamento).

Rigonfiamenti

Come è possibile risolvere i problemi di flusso?

È possibile risolvere il problema di mancanza di aggiornamenti tempestivi tramite:

• Riunioni brevi giornaliere.
• Altre riunioni regolari.
• Pianificazione di un messaggio di posta elettronica di promemoria del team giornaliero.

I problemi di linea piatta sistemica indicano un problema più complesso, anche se tali problemi sono rari. Le linee piatte indicano che il lavoro nel sistema è stato arrestato. Le cause sottostanti possono essere:

• Blocchi a livello di processo.
• I processi richiedono molto tempo.
• Il lavoro si sposta verso altre opportunità che non vengono catturate sulla scheda.

Un esempio di linea piatta sistemica può verificarsi con una funzione CFD. Il lavoro delle funzionalità può richiedere molto più tempo rispetto al lavoro sulle storie utente perché le funzionalità sono composte da diverse storie. In queste situazioni, la pendenza è prevista (come nell'esempio precedente) oppure il problema è noto e già sollevato dal team come questione. Se si tratta di un problema noto, la risoluzione del problema non rientra nell'ambito di questo articolo.

Le squadre possono risolvere in modo proattivo i problemi che appaiono come rigonfiamenti CFD. A seconda della posizione in cui si verifica il rigonfiamento, la correzione può essere diversa. Si supponga, ad esempio, che il rigonfiamento si verifichi nel processo di sviluppo. Il rigonfiamento potrebbe verificarsi perché l'esecuzione dei test richiede molto più tempo rispetto alla scrittura del codice. I tester potrebbero anche trovare un numero elevato di bug. Quando passano continuamente il lavoro agli sviluppatori, gli sviluppatori ereditano un elenco crescente di attività attive.

Due modi potenzialmente facili per risolvere questo problema sono: 1) Spostare gli sviluppatori dal processo di sviluppo al processo di test fino a quando la bulge non viene eliminata o 2) modificare l'ordine di lavoro in modo che il lavoro che può essere eseguito rapidamente è intrecciato con il lavoro che richiede più tempo. Cerca soluzioni semplici per eliminare i gonfiori.

Nota

Poiché molti scenari diversi possono verificarsi che causano un funzionamento non uniforme, è fondamentale eseguire un'analisi effettiva del problema. Il CFD vi dirà che c'è un problema e approssimativamente dove si trova, ma è necessario indagare per raggiungere le cause radice. Le indicazioni fornite qui indicano le azioni consigliate per risolvere problemi specifici, ma che potrebbero non essere applicabili alla situazione.

L'ambito è cambiato?

Le modifiche all'ambito si applicano solo ai CFD a periodo fisso. La riga superiore del grafico indica l'ambito del lavoro. Uno sprint viene caricato con il lavoro da eseguire il primo giorno. Le modifiche apportate alla riga superiore indicano che il lavoro è stato aggiunto o rimosso.

Uno scenario in cui non è possibile tenere traccia delle modifiche all'ambito con un CFD si verifica quando viene aggiunto lo stesso numero di elementi di lavoro rimossi nello stesso giorno. La linea continuerà a essere piatta. Confrontare più grafici tra loro. Monitorare i problemi specifici. Visualizza/configura il burn-down dello sprint per monitorare le modifiche all'ambito.

Troppo lavoro in corso?

È possibile monitorare facilmente se i limiti WIP sono stati superati dalla lavagna. È anche possibile monitorarlo dal CFD.

Una grande quantità di WIP in genere viene visualizzata come un rigonfiamento verticale. Più a lungo c'è una grande quantità di WIP, più il rigonfiamento si espanderà per diventare un ovale. È un'indicazione che il WIP influisce negativamente sul ciclo e sul tempo di consegna.

Ecco una buona regola per i lavori in corso. Non devono essere presenti più di due elementi in corso per ogni membro del team in un determinato momento. Il motivo principale per due elementi rispetto ai limiti più rigorosi è che la realtà spesso intrusa in qualsiasi processo di sviluppo software.

A volte richiede tempo per ottenere informazioni da uno stakeholder o richiede più tempo per acquisire il software necessario. Esistono diversi motivi per cui il lavoro potrebbe essere interrotto. Avere un secondo elemento di lavoro a cui ruotare offre un certo margine di flessibilità. Se entrambi gli elementi sono bloccati, è il momento di generare un flag rosso per sbloccare un elemento, non solo passare a un altro elemento. Non appena è in corso un numero elevato di elementi, la persona che lavora su tali elementi avrà difficoltà a cambiare contesto. È più probabile che dimenticheranno ciò che stavano facendo, e possono verificarsi errori.

Tempo di lead rispetto al tempo di ciclo

Il diagramma seguente illustra come il lead time differisce dal tempo del ciclo. Il lead time viene calcolato dalla creazione dell'elemento di lavoro fino al raggiungimento di uno stato completato. Il tempo del ciclo viene calcolato dal primo ingresso in una categoria di stato In corso o Risolta fino all'ingresso in una categoria di stato Completato.

Illustrazione del lead time e del tempo del ciclo

Se un elemento di lavoro entra in uno stato Completato e quindi viene riattivato, qualsiasi tempo aggiuntivo trascorso in uno stato Proposto, In corso o Risolto contribuirà al tempo di lead/ciclo quando rientra nella categoria di stato Completato per la seconda volta.

Se il team utilizza la bacheca, è necessario comprendere come le colonne corrispondono agli stati del flusso di lavoro. Per altre informazioni sulla configurazione della scheda, vedere Aggiungere colonne.

Per altre informazioni su come il sistema usa le categorie di stato proposte, in corso, risolte e completate, vedere Stati del flusso di lavoro e categorie di stato.

Pianifica utilizzando i tempi di consegna stimati basati sui tempi di consegna/ciclo.

È possibile usare i tempi medi di lead/ciclo e le deviazioni standard per stimare i tempi di consegna.

Quando si crea un elemento di lavoro, è possibile usare il lead time medio del team per stimare quando il team completerà tale elemento di lavoro. La deviazione standard del team indica la variabilità della stima. Analogamente, è possibile usare il tempo del ciclo e la relativa deviazione standard per stimare il completamento di un elemento di lavoro dopo l'avvio del lavoro.

Nel grafico seguente il tempo medio del ciclo è di otto giorni. La deviazione standard è +/- sei giorni. Usando questi dati, è possibile stimare che il team completerà le storie utente future circa 2-14 giorni dopo l'inizio del lavoro. Più stretta è la deviazione standard, più prevedibile sono le stime.

Widget Tempo del ciclo di esempio

Identificare i problemi del processo

Esaminare il grafico di controllo del team per individuare gli outlier. Gli outlier rappresentano spesso un problema di processo sottostante. Ad esempio, attendere troppo tempo per completare le revisioni pull o non risolvere rapidamente una dipendenza esterna.

Come si può notare nel grafico seguente, che mostra diversi outlier, diversi bug hanno richiesto più tempo per il completamento rispetto alla media del team. L'analisi del motivo per cui questi bug hanno richiesto più tempo può aiutare a individuare i problemi di processo. Risolvere i problemi dei processi può contribuire a ridurre la deviazione standard del tuo team e a migliorarne la prevedibilità.

Widget del tempo di ciclo di esempio che mostra diversi valori anomali

È anche possibile vedere in che modo le modifiche al processo influiscono sul lead time e sul tempo di ciclo. Ad esempio, il 15 maggio il team ha fatto uno sforzo concertato per limitare il WIP e risolvere i bug obsoleti. È possibile notare che la deviazione standard si restringe dopo tale data, mostrando una migliore prevedibilità.

Passaggi successivi

Configura i grafici di flusso cumulativi o Configura un grafico del tempo di attraversamento o del tempo di ciclo