Indicazioni sul flusso cumulativo, sul lead time e sul ciclo

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 procedure lean con Scrum o altre metodologie, il che significa che si esercitano all'interno dell'intervallo di 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 periodo fisso illustrato 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, il coefficiente angolare dello stato Chiuso indica se una squadra è in pista per completare lo sprint. Il modo più semplice per pensare a questa visualizzazione è 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 periodo fisso per uno sprint completato

Metriche del grafico

I grafici CFD visualizzano il numero di elementi di lavoro raggruppati per colonna di stato/Kanban 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 1}

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 un periodo fisso: misura l'ora da quando inizia il lavoro su una richiesta fino al completamento del lavoro (ovvero l'ora 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 di cui è stato eseguito il commit 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ù WIP, più lungo è il tempo del ciclo, che porta anche a tempi di lead 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 fondamentale per cui è possibile impostare limiti di lavoro in corso sulla scheda Kanban.

Il conteggio degli elementi di lavoro indica la quantità totale di lavoro in un determinato giorno. In un cfd a periodo fisso, una modifica 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 Kanban fornisce una visualizzazione in cui il 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 GRAFICO CFD visivo fornisce prove che qualcosa sta accadendo in un determinato 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 Kanban.

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 "rigonfiarsi"?

Mura, il termine snella per linee e rigonfiamenti piatti, significa irregolarità e indica una forma di rifiuti (Muda) nel sistema. Qualsiasi irregolarità nel sistema causerà la visualizzazione di rigonfiamenti nel CFD.

Il monitoraggio del CFD per linee e rigonfiamenti flat supporta una parte fondamentale della teoria dei vincoli processo di gestione del progetto. La protezione dell'area più lenta del sistema viene definita processo a fune da tamburo e fa parte del modo in cui è pianificato il lavoro.

Due problemi vengono visualizzati visivamente come linee piatte e comebulges.

Le linee piatte vengono visualizzate quando il team non aggiorna il lavoro con cadenza regolare. La scheda Kanban offre il modo più rapido per eseguire la transizione del 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

I rigonfiamenti si verificano quando il lavoro viene compilato in una parte del sistema e non si sposta attraverso un processo.
Ad esempio, una bulge può verificarsi quando il test richiede un lungo periodo di tempo mentre lo sviluppo richiede un periodo di tempo più breve, causando l'accumulo del lavoro nello stato di sviluppo (ibulge indicano che un passaggio successivo presenta un problema, non necessariamente il passaggio in cui si verifica la struttura).

Rigonfiamenti

Come è possibile risolvere i problemi di flusso?

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

• Stand-up giornalieri.
• 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 flat 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 passa ad altre opportunità che non vengono acquisite sul tavolo.

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, il coefficiente angolare è previsto (come nell'esempio precedente) o il problema è noto e già generato dal team come problema. Se si tratta di un problema noto, la risoluzione del problema non rientra nell'ambito di questo articolo.

Teams può risolvere in modo proattivo i problemi che appaiono come rigonfiamenti CFD. A seconda della posizione in cui si verifica la lampadina, la correzione può essere diversa. Si supponga, ad esempio, che il rigonfiamento si verifichi nel processo di sviluppo. La lampadina potrebbe verificarsi perché l'esecuzione di 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. Cercare soluzioni semplici per eliminare le lampadine.

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 relative all'ambito si applicano solo ai FILE di database a periodo fisso.Scope changes apply to fixed period CFDs only. La riga superiore del grafico indica l'ambito del lavoro. Uno sprint viene precaricato 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. Usare il burn-down di visualizzazione/configurazione dello sprint per monitorare le modifiche all'ambito.

Troppo WIP?

È possibile monitorare facilmente se i limiti wip sono stati superati dalla scheda Kanban. È 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 wip influisce negativamente sul ciclo e sul lead time.

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. La presenza di un secondo elemento di lavoro da pivot per fornire un certo livello 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 e tempo del 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 all'immissione di uno stato Completato. L'ora del ciclo viene calcolata dalla prima immissione di una categoria di stato In corso o Risolta per immettere una categoria 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 entra in una categoria di stato Completato per la seconda volta.

Se il team usa la bacheca Kanban, è necessario comprendere il mapping delle colonne Kanban agli stati del flusso di lavoro. Per altre informazioni sulla configurazione della scheda Kanban, 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.

Pianificare l'uso di stime dei tempi di consegna in base ai tempi di lead/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 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 del processo può contribuire a ridurre la deviazione standard del team e migliorare la prevedibilità del team.

Widget Ciclo di esempio che mostra diversi outlier

È anche possibile vedere in che modo le modifiche al processo influiscono sul lead e sul tempo del 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

Configurare i grafici di flusso cumulativi o Configurare un grafico tempo di lead time o ciclo