Richtlijnen voor cumulatieve stroom, doorlooptijd en cyclustijd

2025-05-02

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

U kunt cumulatieve stroomdiagrammen (CFD's) gebruiken om de werkstroom via een systeem te bewaken. De cyclustijd en de doorlooptijd zijn de twee primaire metrische gegevens die worden gebruikt voor het bijhouden. U kunt deze metrische gegevens extraheren uit een CFD.

nl-NL: Dit artikel laat zien hoe u CFD's, cyclustijden en levertijden kunt gebruiken om problemen in uw werkproces te identificeren en u te helpen werk door uw systeem te verplaatsen.

Als u een CFD wilt configureren of weergeven, raadpleegt u Een cumulatief stroomdiagram weergeven en configureren.
Zie widgets voor leadtijd en cyclustijd als u een controlegrafiek voor leadtijd of cyclustijd aan een dashboard wilt toevoegen.

Voorbeeldgrafieken en primaire metrische gegevens

De CONTINUOUS-flow CFD biedt het diagram dat het meest geschikt is voor teams die een lean proces volgen.

Veel teams combineren echter lean practices met Scrum of andere methodologieën. Als gevolg hiervan gebruiken ze lean-praktijken tijdens een iteratie of sprint. In deze situatie krijgt het diagram een iets andere uitstraling. Het biedt twee extra en zeer waardevolle informatie, zoals wordt weergegeven in de volgende grafiek, de CFD voor een vaste periode.

CFD voor continue stroom
Grafiek met een abstracte continue stroom CFD. Labels wijzen op de doorlooptijd, cyclustijd, werk in uitvoering en items in verschillende statussen.

Deze CFD voor een vaste periode is bedoeld voor een afgeronde sprint.

De bovenste regel vertegenwoordigt het bereik dat is ingesteld voor de sprint. Omdat het werk moet worden voltooid op de laatste dag van de sprint, geeft de helling van de gesloten status aan of een team op schema is om de sprint te voltooien. De eenvoudigste manier om deze weergave te zien is als een burnup-grafiek.

In de grafiek wordt de eerste stap in het proces weergegeven als het gebied linksboven. De laatste stap in het proces wordt weergegeven in het gebied rechtsonder.

CFD met vaste periode voor een voltooide sprint
Grafiek die een abstracte CFD met een vaste periode weergeeft. Labels wijzen op actieve, opgeloste en gesloten items en de bereikwijziging.

Metrische grafiekgegevens

MET CFD's wordt het aantal werkitems weergegeven dat in de loop van de tijd is gegroepeerd op status of kolom. De twee primaire metrische gegevens die worden gebruikt voor het bijhouden zijn de cyclustijd en de doorlooptijd. U kunt deze metrische gegevens uit de grafiek extraheren.

Metrische gegevens

Definitie

Cyclustijd¹

De tijd die nodig is om werk door één proces of workflow-fase te doorlopen. De lengte wordt gemeten vanaf het begin van het ene proces tot het begin van het volgende proces.

Doorlooptijd¹

Voor een continue stroomproces: de tijd vanaf het moment waarop een aanvraag wordt ingediend (zoals het toevoegen van een voorgesteld gebruikersverhaal) totdat die aanvraag is voltooid (gesloten).

Voor een sprint of een proces met een vaste periode: de tijd vanaf het moment waarop het werk aan een aanvraag begint totdat het werk is voltooid (bijvoorbeeld de tijd van de status Actief naar Gesloten).

Werk in uitvoering (WIP)

De hoeveelheid werk of het aantal werkitems waaraan actief wordt gewerkt.

Omvang

De hoeveelheid werk die is vastgelegd voor de opgegeven periode. Deze metrische waarde is alleen van toepassing op processen met een vaste periode.

¹ De CFD-widget die gebruikmaakt van analysegegevens en de ingebouwde CFD die u kunt bekijken vanuit een teamachterstand of bord, bieden geen discrete doorlooptijd- en cyclustijdwaarden. De widgets leadtijd en cyclustijd bieden deze waarden echter wel.

Er is een goed gedefinieerde correlatie tussen de doorlooptijd of cyclustijd en WIP. Meer WIP resulteert in langere cyclustijden, wat leidt tot langere doorlooptijden. Het tegenovergestelde is ook waar: minder WIP resulteert in kortere cyclus en doorlooptijden. Wanneer het ontwikkelteam zich op minder items richt, verminderen ze de cyclus en doorlooptijden. Deze correlatie is een belangrijke reden waarom u WIP-limieten moet instellen op het bord dat u gebruikt om werk bij te houden en te beheren.

Het aantal werkitems geeft de totale hoeveelheid werk op een bepaalde dag aan. In een CFD met een vaste periode geeft een wijziging in dit aantal de bereikwijziging voor een bepaalde periode aan. In een CFD voor doorlopende stroom geeft het de totale hoeveelheid werk aan die op een gegeven dag in de wachtrij staat en is voltooid.

Wanneer u werk in specifieke bordkolommen categoriseert, ziet u de hoeveelheid werk in elk gebied van het proces. Deze weergave biedt inzicht in waar het werk soepel verloopt, waar er obstakels zijn en waar helemaal geen werk wordt uitgevoerd. Het is moeilijk om een tabelweergave van de gegevens te ontcijferen. De visuele CFD helpt u echter te begrijpen wat er gebeurt in uw werkproces en waarom dit gebeurt.

Problemen identificeren en passende acties ondernemen

De CFD biedt antwoorden op de volgende vragen. Op basis van de antwoorden kunt u het proces aanpassen om het werk door het systeem te verplaatsen.

Is het team op tijd aan het werk?

Deze vraag is alleen van toepassing op CFD's met een vaste periode. U kunt inzicht krijgen door te kijken naar de curve (of voortgang) van het werk in de laatste kolom van het bord.

Grafiek met een half voltooid CFD. De geprojecteerde curve voor voltooide items ligt onder het bereikniveau aan het einde van de sprint.

In dit scenario kunt u overwegen om het werkbereik in de iteratie te verminderen. Deze actie is geschikt als duidelijk is dat het werk niet snel genoeg wordt voltooid, ervan uitgaande dat het in een stabiel tempo wordt voortgezet. In dit scenario kan worden aangegeven dat het werk is onderschat en moet worden meegenomen in de planning van de volgende sprint.

Er kunnen echter andere redenen zijn waarom het werk niet snel genoeg wordt voltooid. U kunt deze redenen bepalen door andere gegevens in de grafiek te bekijken.

Hoe verloopt de voortgang van het werk?

Is het team bezig met het voltooien van werk in een stabiel tempo? Een manier om te vertellen is om de afstand tussen de verschillende kolommen in de grafiek te bekijken. Zijn ze van begin tot eind op een vergelijkbare of uniforme afstand van elkaar? Zijn er kolommen die over een periode van meerdere dagen een vlakke lijn vertonen? Of puilt er iets uit?

Mura, of oneffenheid, is de magere term voor platte lijnen en bulges. Mura geeft een vorm van afval (Muda) in het systeem aan. Eventuele ongelijkheden in het systeem veroorzaken bulten in de CFD.

Het monitoren van de CFD voor vlakke lijnen en uitstulpingen ondersteunt een belangrijk onderdeel van het projectmanagementproces van de Theory of Constraints. Het beveiligen van het traagste deel van het systeem wordt aangeduid als het trommelbuffer-touwproces en is onderdeel van de werkplanning.

Twee problemen worden visueel weergegeven als platte lijnen en als uitstulpingen.

Platte lijnen worden weergegeven wanneer het team de status van hun werkitems niet met een normale frequentie bijwerkt. Het bord dat u gebruikt om werk bij te houden en te beheren , biedt de snelste manier om werk van de ene kolom naar de andere over te zetten.
Platte lijnen kunnen ook worden weergegeven wanneer het werk in een of meer processen langer duurt dan gepland. Platte lijnen verschijnen in veel delen van het systeem, omdat als er slechts één of twee delen problemen hebben, u een bult ziet.

Platte lijnen
Grafiek van een abstracte CFD. Lijnen voor het aantal actieve, opgeloste en gesloten items blijven gedurende een aanzienlijk aantal perioden vlak.

Bulges treden op wanneer het werk zich in één deel van het systeem ophoopt en zich niet door een proces verplaatst.
Een bult kan bijvoorbeeld optreden wanneer het testen lang duurt, maar het ontwikkelen minder tijd kost. Het resultaat is dat werk zich opstapelt in de ontwikkelingsfase. Uitstulpingen geven aan dat een volgende stap een probleem heeft, niet noodzakelijkerwijs de stap waarin de uitstulping optreedt.

Uitstulpingen
Grafiek van een abstract CFD. Het gebied voor actieve items bult zich naar de rechterbenedenhoek van de grafiek.

Hoe lost u stroomproblemen op?

U kunt het probleem van een gebrek aan tijdige updates oplossen door de volgende acties uit te voeren:

Dagelijkse stand-ups houden
Andere regelmatige vergaderingen houden
Een e-mail met een dagelijkse teamherinnering plannen

Systemische vlaklijnproblemen geven een lastiger probleem aan, hoewel dergelijke problemen zeldzaam zijn. Platte lijnen geven aan dat het werk in het systeem is gestopt. Onderliggende oorzaken kunnen de volgende problemen bevatten:

Procesbrede blokkades
Processen duren lang
Werk verschuift naar andere kansen die niet op het bord worden vastgelegd

Een voorbeeld van systemische flatlining kan optreden in een kenmerken CFD. Functiewerk kan aanzienlijk langer duren dan het werk aan gebruikersverhalen, omdat functies bestaan uit verschillende verhalen. In deze situaties wordt de helling verwacht (zoals in een eerder voorbeeld) of is het probleem bekend en heeft het team het al gemeld. Als het een bekend probleem is, valt de oplossing buiten het bereik van dit artikel.

Teams kunnen proactief problemen oplossen die worden weergegeven als CFD-bulges. De oplossing die geschikt is, kan afhankelijk zijn van waar de bult zich voordoet. Stel dat de bult zich voordoet in het ontwikkelingsproces. De bult kan zich voordoen omdat het testen aanzienlijk langer duurt dan het schrijven van code. Testers kunnen ook een groot aantal bugs vinden. Wanneer ze het werk voortdurend overschakelen naar de ontwikkelaars, nemen de ontwikkelaars een groeiende lijst met actieve werkzaamheden over.

Er zijn twee mogelijk eenvoudige manieren om dit probleem op te lossen:

Verschuif ontwikkelaars van het ontwikkelproces naar het testproces totdat de bult wordt geëlimineerd.
Wijzig de werkvolgorde. Wissel snel uitvoerbaar werk af met werk dat meer tijd vergt.

Zoek naar basisoplossingen om de uitstulpingen te elimineren.

Notitie

Omdat er verschillende scenario's kunnen optreden waardoor werk ongelijkmatig kan worden voortgezet, is het essentieel dat u een werkelijke analyse van het probleem uitvoert. De CFD kan u vertellen dat er een probleem bestaat. Het kan u ook ongeveer vertellen waar het probleem zich bevindt, maar u moet onderzoeken om de hoofdoorzaken te bereiken. Deze richtlijnen bieden aanbevolen acties die specifieke problemen oplossen, maar de oplossingen zijn mogelijk niet van toepassing op uw situatie.

Is het bereik gewijzigd?

Bereikwijzigingen zijn alleen van toepassing op CFD's met een vaste periode. De bovenste lijn van het diagram geeft het werkbereik aan. Een sprint is vooraf gevuld met het werk dat op de eerste dag moet worden uitgevoerd. Wijzigingen in de bovenste regel geven de toevoeging of verwijdering van werk aan.

In een bepaald scenario kunt u geen wijzigingen in het bereik bijhouden met een CFD. Dit scenario treedt op wanneer hetzelfde aantal werkitems op dezelfde dag wordt toegevoegd en verwijderd. De lijn blijft in dit geval vlak.

Als u de wijzigingen in het bereik in dit geval wilt bijhouden, voert u de volgende acties uit:

Vergelijk verschillende grafieken met elkaar.
Bewaak specifieke problemen.
Gebruik sprint burndown om bereikwijzigingen te controleren.

Is er te veel WIP?

U kunt het bord eenvoudig controleren om te bepalen of de WIP-limieten worden overschreden. U kunt ook WIP-niveaus bewaken met behulp van de CFD.

Een grote hoeveelheid WIP wordt meestal weergegeven als een verticale bult. Hoe langer er een grote hoeveelheid WIP is, hoe meer de bult zich uitbreidt tot een ovale vorm. Dit gedrag is een indicatie dat de WIP de cyclus en de doorlooptijd negatief beïnvloedt.

Hier volgt een goede vuistregel voor WIP: er mogen op elk gewenst moment niet meer dan twee items worden uitgevoerd per teamlid. De belangrijkste reden voor het gebruik van een limiet van twee items, niet een strengere limiet, is dat de realiteit vaak indringt in het softwareontwikkelingsproces.

Soms kost het tijd om informatie op te halen van een belanghebbende of om de benodigde software te verkrijgen. Er zijn een aantal redenen waarom werk kan worden gestopt. Als u een tweede werkitem hebt om naar over te schakelen, kan dat wat speelruimte geven. Als beide items worden geblokkeerd, is het tijd om een waarschuwing af te geven om iets te deblokkeren, niet alleen om over te schakelen naar een ander item. Zodra er een groot aantal items in behandeling is, kan de persoon die aan deze items werkt, problemen hebben met het schakelen tussen contexten. Het is waarschijnlijk dat ze vergeten wat ze aan het doen waren, wat kan leiden tot fouten.

Doorlooptijd versus cyclustijd

In het volgende diagram ziet u hoe de doorlooptijd verschilt van de cyclustijd. De doorlooptijd begint wanneer een werkitem wordt gemaakt en eindigt wanneer het werkitem een categorie Voltooide status invoert. De cyclustijd begint wanneer een werkitem voor het eerst een statuscategorie Wordt uitgevoerd of Opgelost invoert. De cyclustijd eindigt wanneer het werkitem een categorie Voltooide status invoert.

Diagram waarin wordt getoond hoe statuscategorieën worden gebruikt om cyclustijd en doorlooptijd te meten.

Als een werkitem een statuscategorie Voltooid invoert en vervolgens opnieuw wordt geactiveerd, worden de lead- en cyclustijden beïnvloed. Elke extra tijd die wordt besteed aan een voorgestelde, in uitvoering of opgeloste statuscategorie draagt bij aan de lead- en cyclustijden.

Als uw team een bord gebruikt om werk bij te houden en te beheren, is het handig om te begrijpen hoe uw kolommen worden toegewezen aan werkstroomstatussen. Zie Kolommen op uw bord beheren voor meer informatie over het configureren van uw bord.

Zie Over werkstroomstatussen in achterstanden en borden voor meer informatie over hoe het systeem gebruikmaakt van de statuscategorieën (Voorgesteld, Wordt uitgevoerd, Opgelost en Voltooid).

Geschatte levertijden op basis van lead- en cyclustijden

U kunt uw gemiddelde lead- en cyclustijden en standaarddeviaties gebruiken om de levertijden te schatten.

Wanneer u een werkitem maakt, kunt u de gemiddelde doorlooptijd van uw team gebruiken om de voltooiingsdatum van dat werkitem te schatten. De standaarddeviatie van uw team geeft de variabiliteit van de schatting aan. Op dezelfde manier kunt u de cyclustijd en de standaarddeviatie gebruiken om een schatting te maken van de voltooiing van een werkitem nadat het werk is begonnen.

In de volgende grafiek is de gemiddelde cyclustijd acht dagen. De standaarddeviatie is zes dagen. Met behulp van deze gegevens kunt u schatten dat het team toekomstige gebruikersverhalen ongeveer 2 tot 14 dagen nadat ze aan het werk zijn begonnen, voltooit. Hoe smaller de standaarddeviatie, hoe voorspelbaarder uw schattingen.

Schermopname van een Cyclustijd-widget. Een spreidingsdiagram heeft punten voor werkitems, een voortschrijdend gemiddelde lijn en een standaarddeviatieband.

Procesproblemen identificeren

Uitschieters duiden vaak op een onderliggend procesprobleem. Voorbeelden hiervan zijn te lang wachten om pull-aanvragen te controleren of om een externe afhankelijkheid niet snel op te lossen. Bekijk het controlediagram van uw team voor uitschieters.

In de volgende grafiek ziet u verschillende uitbijters, omdat verschillende bugs langer duurde dan het gemiddelde om te voltooien. Het onderzoeken waarom deze fouten langer duren, kan helpen bij het ontdekken van procesproblemen. Het oplossen van procesproblemen kan helpen de standaarddeviatie van uw team te verminderen en de voorspelbaarheid van uw team te verbeteren.

Schermopname van een Cyclustijd-widget. Verschillende puntjes van werkitems liggen ver boven de lijn voor bewegend gemiddelde en de standaarddeviatieband.

U kunt ook zien hoe proceswijzigingen van invloed zijn op uw lead- en cyclustijden. Op 15 mei heeft het team bijvoorbeeld een gezamenlijke inspanning gedaan om de WIP te beperken en verouderde bugs aan te pakken. U kunt zien dat de standaarddeviatie na die datum wordt verkleind, met verbeterde voorspelbaarheid.

Volgende stappen

Een cumulatief stroomdiagram weergeven en configureren

Widgets voor doorlooptijd en cyclustijd