Linee guida per il flusso cumulativo, il tempo di lead e il ciclo

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

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

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

Grafici di esempio e metriche primarie

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

Tuttavia, molti team hanno iniziato a combinare le procedure di base con Scrum o altre metodologie che significa che praticano l'inclinazione all'interno dell'intervallo 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
Conceptual image of CFD metrics.

Il CFD periodo fisso illustrato qui è per uno sprint completato.

La riga superiore rappresenta l'ambito impostato per lo sprint. E, perché il lavoro deve essere completato dall'ultimo giorno dello sprint, la pendenza 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 di burnup.

I dati vengono sempre illustrati con il primo passaggio del processo come superiore sinistro e l'ultimo passaggio del processo come in basso a destra.

Tempo fisso CFD per uno sprint completato
CFD metrics, fixed period.

Metriche del grafico

I grafici CFD visualizzano il numero di elementi di lavoro raggruppati in base alla colonna state/Kanban nel tempo. Le due metriche primarie per tenere traccia, il tempo di ciclo e il tempo di lead possono essere estratti dal grafico.


Metrica

Definition


Tempo ciclo1

Misura il tempo necessario per spostare il lavoro attraverso un singolo processo o uno stato del flusso di lavoro. Il calcolo si trova dall'inizio di un processo all'inizio del processo successivo.

Tempo di lead1

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

Per un processo sprint o periodo fisso: misura il tempo da quando il lavoro su una richiesta inizia fino a quando il lavoro non viene completato (ad esempio l'ora da Attivo a Chiuso).

Lavoro in corso

Misura la quantità di lavoro o il numero di elementi di lavoro che vengono attivamente elaborati.

Ambito

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


1 Il widget CFD (Analytics) e il grafico CFD predefinito (archivio dati di rilevamento lavoro) non forniscono numeri discreti in Tempo di lead e ciclo. Tuttavia, i widget Lead Time e Cycle Time forniscono questi numeri.

Esiste una correlazione ben definita tra tempo di lead/ciclo e tempo di lavoro in corso (WIP). Più WIP, più tempo del ciclo, che porta anche a tempi di lead più lunghi. L'opposto è anche vero, meno WIP, più breve il ciclo e il tempo di lead. Quando il team di sviluppo si concentra su meno elementi, riduce il ciclo e i tempi di lead. 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 punto fisso CFD, una modifica in questo conteggio indica la modifica dell'ambito per un determinato periodo. In un CFD di flusso continuo indica la quantità totale di lavoro nella coda e completata per un determinato giorno.

La scomposizione del lavoro in colonne della scheda Kanban specifiche offre una visualizzazione in cui il lavoro è in fase di elaborazione. Questa visualizzazione fornisce informazioni dettagliate sulla posizione in cui il lavoro viene spostato senza problemi, dove ci sono blocchi e dove non viene eseguito alcun lavoro. È difficile decifrare una visualizzazione tabulare dei dati, tuttavia, il 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, le azioni possono essere eseguite per modificare il processo per spostarsi attraverso il sistema. Esaminiamo ognuna di queste domande qui.

Il team funzionerà in tempo?

Questa domanda si applica solo ai CFD fissi. Si ottiene una comprensione esaminando la curva (o la progressione) del lavoro nell'ultima colonna della scheda Kanban.

Sample CFD with a half completed chart, dotted lines show the work won't be completed

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

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

In che modo il flusso di avanzamento del lavoro?

Il team sta completando il lavoro in modo costante? Un modo per indicare consiste nell'esaminare la spaziatura tra le diverse colonne del grafico. Sono di una distanza simile o uniforme tra loro dall'inizio alla fine? Una colonna sembra essere flat-line in un periodo di più giorni? Oppure, sembra "bulge"?

Mura, il termine sporchio per linee flat e ribulge, 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 flat e bulges supporta una parte fondamentale della teoria dei vincoli processo di gestione dei progetti. La protezione dell'area più lenta del sistema viene definita processo a corda del buffer del batterio e fa parte del modo in cui è pianificato il lavoro.

Due problemi vengono visualizzati visivamente come linee flat e come rigonfiamenti.

Le linee flat vengono visualizzate quando il team non aggiorna il lavoro con una cadenza regolare. La scheda Kanban offre il modo più rapido per passare 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 rispetto al previsto. Le linee flat vengono visualizzate in molte parti del sistema perché se solo una parte del sistema o due parti di un sistema hanno problemi, si noterà un rigonfiamento.

Linee flat
CFD metrics, flat lines.

Le bulges si verificano quando il lavoro si compila in una parte del sistema e non viene spostato 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'accumulazione del lavoro nello stato di sviluppo (i ribulgi indicano che un passaggio riuscito ha un problema, non necessariamente il passaggio in cui si sta verificando il rigonfiamento).

Rigonfiamenti
CFD metrics, bulges.

Come è possibile risolvere i problemi del 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 flat 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.
  • Lavoro che passa ad altre opportunità che non vengono acquisite sul tavolo.

Un esempio di linea flat sistemica può verificarsi con un CFD di funzionalità. Il lavoro delle funzionalità può richiedere molto più tempo rispetto al lavoro sulle storie utente perché le funzionalità sono costituite da diverse storie. In queste situazioni, la pendenza è prevista (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 bulge CFD. A seconda della posizione in cui si verifica il rigonfiamento, la correzione potrebbe essere diversa. Si supponga, ad esempio, che il ribulge si verifichi nel processo di sviluppo. Il bulge 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 semplici per risolvere questo problema sono: 1) Spostare gli sviluppatori dal processo di sviluppo al processo di test fino a quando la lampadina non viene eliminata o 2) modificare l'ordine di lavoro in modo che il lavoro che può essere eseguito rapidamente è intesso con il lavoro che richiede più tempo. Cercare soluzioni semplici per eliminare i rigonfiamenti.

Nota

Poiché è possibile che si verifichino molti scenari diversi che causano un'irregolarità del lavoro, è fondamentale eseguire un'analisi effettiva del problema. Il CFD vi dirà che c'è un problema e approssimativamente dove si trova, ma è necessario indagare per ottenere 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 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 lo stesso numero di elementi di lavoro viene aggiunto come rimosso 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 viene in genere visualizzata come un rigonfiamento verticale. Più a lungo c'è una grande quantità di WIP, più la lampadina si espanderà per diventare un ovale. È un'indicazione che wip influisce negativamente sul ciclo e sul lead time.

Ecco una buona regola generale per i lavori in corso. Non ci devono essere 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 è dovuto al fatto che la realtà viene spesso intrusa in qualsiasi processo di sviluppo software.

A volte ci vuole 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, è possibile 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 dimentichino quello che stavano facendo e che si verifichino 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. Il tempo del ciclo viene calcolato dalla prima immissione di una categoria di stato In corso o Risolta per l'immissione di una categoria stato Completato.

Illustrazione del lead time e del tempo del ciclo

Conceptual image of how cycle time and lead time are measured

Se un elemento di lavoro entra in stato Completato e 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 recapito in base ai tempi di lead/ciclo

È possibile usare i tempi medi del 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 utilizzare 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

Cycle Time widget

Identificare i problemi del processo

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

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

Widget Ciclo di esempio che mostra diversi outlier

Cycle Time widget showing several outliers

È anche possibile vedere come le modifiche del 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 non aggiornati. È possibile notare che la deviazione standard si restringe dopo tale data, mostrando una maggiore prevedibilità.

Passaggi successivi