Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020
I diagrammi di flusso cumulativi consentono di monitorare il processo di lavoro visualizzando il flusso di lavoro attraverso il sistema. Questo articolo illustra come usare i cfd, i tempi di ciclo e i lead time per identificare i problemi e migliorare l'efficienza del flusso di lavoro.
- Per configurare o visualizzare un CFD, vedere Visualizzare e configurare un diagramma di flusso cumulativo.
- Per aggiungere un grafico di controllo del lead time o del tempo di ciclo a una dashboard, vedere Widget Lead Time e Tempo di ciclo.
- Per configurare o visualizzare un CFD, vedere Visualizzare e configurare un diagramma di flusso cumulativo.
- Per aggiungere un grafico di controllo del lead time o del tempo di ciclo a una dashboard, vedere Widget Lead Time e Tempo di ciclo.
Il CFD a flusso continuo è il grafico che la maggior parte delle squadre che seguono un processo snello preferiscono.
Ma molti team combinano pratiche snelle con Scrum o altri metodi. Usano pratiche snelle durante un'iterazione o uno sprint. In questo caso, il diagramma ha un aspetto leggermente diverso. Mostra due elementi extra, il flusso continuo CFD è il grafico preferito dalla maggior parte dei team che seguono un processo snello.
Ma molti team combinano pratiche snelle con Scrum o altri metodi. Usano pratiche snelle durante un'iterazione o uno sprint. In questo caso, il diagramma ha un aspetto leggermente diverso. Mostra due informazioni aggiuntive, preziose, come illustrato nel grafico successivo, il CFD a periodo fisso.
CFD a flusso continuo
Questo CFD a periodo fisso mostra uno sprint completato.
La riga superiore mostra l'ambito impostato per lo sprint. Poiché il lavoro deve terminare entro l'ultimo giorno, l'andamento dello stato Chiuso indica se un team è sulla buona strada. Considera questa visualizzazione come un grafico burnup.
Nel grafico il primo passaggio del processo si trova nell'area superiore sinistra. L'ultimo passaggio si trova nell'area in basso a destra.
CFD a periodo fisso per uno sprint completato
Metriche del grafico
I Diagrammi di flusso cumulativi (CFD) indicano il numero di elementi di lavoro raggruppati in base allo stato o alla colonna nel tempo. Le due metriche principali per il rilevamento sono il tempo di ciclo e il lead time. Queste metriche vengono estratte dal grafico.
Metrica
Definizione
Tempo di ciclo1
Il tempo necessario per spostare il lavoro attraverso un singolo processo o stato del flusso di lavoro. Misurare la lunghezza dall'inizio di un processo all'inizio del processo successivo.
Tempi di consegna1
Per un processo di flusso continuo: l'ora di esecuzione di una richiesta (ad esempio l'aggiunta di una storia utente proposta) fino al completamento della richiesta (chiusa).
*Per uno sprint o fi Per un processo di flusso continuo: ora da quando viene effettuata una richiesta (ad esempio aggiungendo una storia utente proposta) fino al completamento della richiesta (chiusa).
Per uno sprint o un processo a periodo fisso: il tempo che intercorre tra l'inizio del lavoro su una richiesta e il completamento del lavoro (ad esempio, il tempo che intercorre tra lo stato Attivo e quello Chiuso).
Lavori in corso (WIP)
Quantità di lavoro o numero di elementi di lavoro attivamente in corso.
Ambito
Quantità di lavoro impegnata per il periodo specificato. Questa metrica si applica solo ai processi a periodo fisso.
1 Il widget CFD che utilizza i dati di Analytics e il CFD integrato che puoi visualizzare da un backlog del team o da una bacheca non forniscono valori discreti del lead time e del tempo di ciclo. Tuttavia, i widget Lead Time e Cycle Time forniscono questi valori.
Esiste una chiara correlazione tra il lead time o il tempo del ciclo e WIP. Più lavori in corso portano a tempi di ciclo più lunghi e tempi di consegna più lunghi. L'opposto è anche vero: meno WIP porta a cicli più brevi e tempi di consegna più brevi. 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 impostare i limiti WIP sulla scheda che usate per tracciare e gestire il lavoro.
Il conteggio degli elementi di lavoro mostra la quantità totale di lavoro in un determinato giorno. In un CFD a periodo fisso, una modifica in questo conteggio significa una modifica dell'ambito per quel periodo. In uno CFD di flusso continuo, mostra la quantità totale di lavoro presente nella coda e completata per un determinato giorno.
La categorizzazione del lavoro in colonne specifiche della scheda mostra la quantità di lavoro in ogni area del processo. Questa vista offre informazioni dettagliate sul modo in cui il lavoro si sposta senza problemi, dove sono presenti blocchi e dove non viene eseguito alcun lavoro. È difficile comprendere una visualizzazione tabulare dei dati, ma il CFD visivo consente di vedere cosa sta accadendo nel processo di lavoro e perché.
Identificare i problemi e intraprendere le azioni appropriate
Il CFD fornisce le risposte alle seguenti domande. In base alle risposte, è possibile regolare il processo per spostare il lavoro attraverso il sistema.
Il team completerà il lavoro in tempo?
Questa domanda si applica solo ai CFD a periodo fisso. Puoi capire guardando la curva (o progressione) del lavoro nell'ultima colonna della lavagna.
In questo scenario, è possibile prendere in considerazione la possibilità di ridurre l'ambito di lavoro nell'iterazione. Questa azione è appropriata se è chiaro che il lavoro non viene completato abbastanza rapidamente, supponendo che continui a un ritmo costante. Questo scenario può indicare che il lavoro è stato sottovalutato e deve essere preso in considerazione nella pianificazione dello sprint successivo.
Tuttavia, potrebbero esserci altri motivi per cui il lavoro non viene completato abbastanza rapidamente. È possibile determinare questi motivi esaminando altri dati sul grafico.
Qual è il flusso di avanzamento del lavoro?
Il team sta completando il lavoro a ritmo costante? Un modo per capirlo è guardare la spaziatura tra le varie colonne del grafico. Sono di una distanza simile o uniforme l'una dall'altra dall'inizio alla fine? Alcune colonne sembrano essere piatte per un periodo di più giorni? O qualcuno sembra gonfiarsi?
Mura, o irregolarità, è il termine magro per linee piatte e rigonfiamenti. Mura indica una forma di scarto (Muda) nel sistema. Qualsiasi irregolarità nel sistema provoca la comparsa 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 è indicata come processo tamburo-tampone-fune e fa parte del modo in cui viene pianificato il lavoro.
Due problemi vengono visualizzati come linee piatte e come rigonfiamenti.
Le linee piatte vengono visualizzate quando il team non aggiorna lo stato degli elementi di lavoro con una cadenza regolare. La bacheca utilizzata per tenere traccia e gestire il lavoro offre il modo più rapido per trasferire il lavoro da una colonna all'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 o due parti hanno problemi, si vede un rigonfiamento.
Linee piatte
I rigonfiamenti si verificano quando il lavoro si accumula in una parte del sistema e non si muove attraverso un processo.
Ad esempio, un rigonfiamento può verificarsi quando i test richiedono molto tempo, ma lo sviluppo richiede meno tempo. Il risultato è che il lavoro si accumula nello stato di sviluppo. I rigonfiamenti indicano che un passaggio successivo sta avendo un problema, non necessariamente il passaggio in cui si sta verificando il rigonfiamento.
Rigonfiamenti
Come è possibile risolvere i problemi di flusso?
È possibile risolvere il problema della mancanza di aggiornamenti tempestivi intraprendendo le seguenti azioni:
- Organizzazione di stand-up giornalieri
- Tenere altre riunioni periodiche
- Pianificazione di un'e-mail di promemoria giornaliera per il team
I problemi di linea piatta sistemica indicano un problema più complesso, anche se tali problemi sono rari. Le linee piatte indicano che il lavoro attraverso il sistema è stato interrotto. Le cause sottostanti possono includere i problemi seguenti:
- Blocchi a livello di processo
- Processi che richiedono molto tempo
- Il lavoro si sposta su altre opportunità che non vengono catturate sulla lavagna
Un esempio di rivestimento piatto sistemico può verificarsi in una funzione CFD. Il lavoro delle funzionalità può richiedere più tempo rispetto al lavoro sulle storie utente, perché le funzionalità sono composte da diverse storie. In queste situazioni, il coefficiente angolare è previsto (come in un esempio precedente) o il problema è noto e il team lo ha già sollevato. 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. La correzione appropriata può dipendere da dove si verifica il rigonfiamento. Ad esempio, supponiamo che il rigonfiamento si verifichi nel processo di sviluppo. Il rigonfiamento potrebbe verificarsi poiché il testing richiede 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.
Esistono due modi potenzialmente semplici per risolvere questo problema:
- Sposta gli sviluppatori dal processo di sviluppo al processo di test fino a quando il rigonfiamento non viene eliminato.
- Modificare l'ordine di lavoro. In particolare, intreccia il lavoro che può essere svolto rapidamente con il lavoro che richiede più tempo per essere eseguito.
Cerca soluzioni di base per eliminare i rigonfiamenti.
Nota
Poiché possono verificarsi vari scenari che causano un proseguimento non uniforme del lavoro, è fondamentale eseguire un'analisi effettiva del problema. Il CFD può dirti che esiste un problema. Può anche dirti approssimativamente dove si trova il problema, ma devi indagare per arrivare alle cause alla radice. In queste linee guida vengono fornite le azioni consigliate per risolvere problemi specifici, ma le soluzioni 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 svolgere il primo giorno. Le modifiche alla riga superiore indicano l'aggiunta o la rimozione di lavoro.
In uno scenario particolare, non è possibile tenere traccia delle modifiche dell'ambito con un CFD. Questo scenario si verifica quando lo stesso numero di elementi di lavoro viene aggiunto e rimosso nello stesso giorno. In questo caso, la linea rimane piatta.
Per tenere traccia delle modifiche dell'ambito in questo caso, eseguire le azioni seguenti:
- Confrontare più grafici tra loro.
- Monitora problemi specifici.
- Usare il burn-down dello sprint per monitorare le modifiche dell'ambito.
C'è troppo WIP?
È possibile monitorare facilmente la scheda per determinare se i limiti WIP sono stati superati. È inoltre possibile monitorare i livelli WIP utilizzando il 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 espande in una forma ovale. Questo comportamento indica che il WIP influisce negativamente sul ciclo e sul lead time.
Ecco una buona regola empirica per WIP: non dovrebbero esserci più di due elementi in corso per membro del team in un dato momento. Il motivo principale per l'utilizzo di un limite di due elementi, non di un limite più rigoroso, è che la realtà spesso si intromette nel processo di sviluppo del software.
A volte ci vuole tempo per ottenere informazioni da uno stakeholder o per acquisire il software necessario. Ci sono diversi motivi per cui il lavoro può essere interrotto. La gestione di un secondo elemento di lavoro offre flessibilità operativa durante ritardi imprevisti. 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 c'è un gran numero di elementi in corso, la persona che lavora su tali elementi può avere difficoltà a cambiare contesto. È probabile che dimentichino quello che stavano facendo, il che può portare a errori.
Tempo di lead rispetto al tempo di ciclo
Il diagramma seguente mostra come differisce il tempo di lead time e il tempo del ciclo. Il lead time inizia quando viene creato un elemento di lavoro e termina quando l'elemento di lavoro entra in una categoria di stato Completato. L'ora del ciclo inizia quando un elemento di lavoro entra in una categoria di stato In corso o Risolto e termina quando entra in una categoria stato Completato.
Se il team usa una bacheca per tenere traccia e gestire il lavoro, comprendere il mapping delle colonne agli stati del flusso di lavoro consente di gestire il lavoro in modo più efficace. Per informazioni su come configurare la scheda, vedere Gestire le colonne nella scheda.
Per informazioni su come il sistema usa le categorie di stato, proposte, in corso, risolte e completate, vedere Informazioni sugli stati del flusso di lavoro nei backlog e nelle bacheche.
Come il tempo di ciclo gestisce gli elementi di lavoro riattivati
Per gli elementi di lavoro riattivati (spostati da uno stato Completato a uno stato In corso ), l'ora del ciclo inizia dalla prima volta che l'elemento di lavoro entra in una categoria di stato In corso o Risolto e termina l'ora finale in cui entra in una categoria stato Completato . Il tempo del ciclo include l'intero periodo di lavoro attivo, incluso qualsiasi momento dopo la riattivazione.
Scenario di esempio:
- Nuovo → Attivo → Risolto → Chiuso → Nuovo → Attivo → Chiuso
- Calcolo del tempo del ciclo: Dalla prima transizione ad Active alla transizione finale a Closed
- Tempo totale ciclo: Include sia i periodi lavorativi attivi che il tempo in Stato chiuso prima della riattivazione
Questo metodo di calcolo fornisce un quadro completo del tempo totale necessario per completare l'elemento di lavoro, incluse eventuali operazioni di rielaborazione o lavoro aggiuntivo dopo la riattivazione. Il calcolo del lead time segue lo stesso principio, che copre l'intero periodo dalla creazione dell'elemento di lavoro al completamento finale, indipendentemente dagli stati intermedi completati.
Stima i tempi di consegna in base ai tempi di consegna e di ciclo
Usa il tempo medio di lead e il tempo medio di ciclo e deviazione standard per stimare i tempi di consegna.
Quando si crea un elemento di lavoro, usare il lead time medio del team per stimare la data di completamento. La deviazione standard del team mostra la variabilità della stima. Analogamente, usare il tempo del ciclo e la deviazione standard per stimare quando un elemento di lavoro termina dopo l'inizio del lavoro.
Widget Tempo del ciclo di esempio
Nel grafico seguente il tempo medio del ciclo è di otto giorni e la deviazione standard è di sei giorni. Con questi dati, stimare che il team possa completare le future storie degli utenti da 2 a 14 giorni dopo l'inizio del lavoro. Una deviazione standard più stretta rende le stime più prevedibili.
Identificare i problemi del processo
I valori anomali spesso indicano un problema del processo. Ad esempio, attendere troppo tempo per esaminare le richieste pull o non correggere rapidamente una dipendenza esterna. Controlla il diagramma di controllo del team per individuare i valori anomali.
Un widget di esempio di tempo di ciclo che mostra diversi outlier
Il grafico seguente mostra diversi outlier perché alcuni bug hanno richiesto più tempo rispetto alla media per il completamento. Controllare il motivo per cui questi bug hanno richiesto più tempo può aiutare a individuare i problemi di processo. La correzione dei problemi di processo consente di ridurre la deviazione standard del team e di migliorare la prevedibilità del team.
Si può anche vedere in che modo le modifiche del processo influiscono sui tempi di lead e di ciclo. Ad esempio, il 15 maggio, il team ha lavorato per limitare il WIP e correggere i bug obsoleti. La deviazione standard si restringe dopo tale data, mostrando una migliore prevedibilità.