Richtlijnen voor cumulatieve stroom, doorlooptijd en cyclustijd
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
U gebruikt cumulatieve stroomdiagrammen (CFD) om de werkstroom via een systeem te bewaken. De twee primaire metrische gegevens voor het bijhouden, de cyclustijd en de doorlooptijd kunnen worden geëxtraheerd uit de grafiek. Zie Een cumulatief stroomdiagram configureren of weergeven als u CFD-grafieken wilt configureren of weergeven.
U kunt ook de grafieken met lead- en cyclustijdbeheer toevoegen aan uw dashboards.
Voorbeeldgrafieken en primaire metrische gegevens
De CONTINUE stroom CFD biedt de grafiek die het meest wordt gebruikt door teams die een lean proces volgen.
Veel teams zijn echter begonnen met het combineren van lean practices met Scrum of andere methodologieën, wat betekent dat ze in de loop van een iteratie of sprint kunnen oefenen. In deze situatie krijgt het diagram een iets ander uiterlijk en biedt het twee extra, zeer waardevolle, gegevens, zoals wordt weergegeven in de volgende grafiek.
Doorlopende stroom
De vaste periode CFD die hier wordt weergegeven, is voor een voltooide sprint.
De bovenste regel vertegenwoordigt het bereik dat is ingesteld voor de sprint. En omdat het werk moet worden voltooid op de laatste dag van de sprint, geeft de helling van de gesloten toestand 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.
De gegevens worden altijd weergegeven met de eerste stap in het proces als linksboven en de laatste stap in het proces als de rechterbenedenhoek.
Vaste periode CFD voor een voltooide sprint
Metrische grafiekgegevens
CFD-grafieken geven het aantal werkitems weer gegroepeerd op staat/kolom in de loop van de tijd. De twee primaire metrische gegevens voor het bijhouden, de cyclustijd en de doorlooptijd kunnen worden geëxtraheerd uit de grafiek.
Metrische gegevens
Definitie
Cyclustijd 1
Meet de tijd die nodig is om werk door één proces- of werkstroomstatus te verplaatsen. Berekening is van het begin van het ene proces tot het begin van het volgende proces.
Doorlooptijd 1
Voor een doorlopend stroomproces: Meet de hoeveelheid tijd die nodig is wanneer een aanvraag wordt ingediend (zoals het toevoegen van een voorgesteld gebruikersverhaal) totdat die aanvraag is voltooid (gesloten).
Voor een sprint- of vaste periodeprocedure: Meet de tijd vanaf het moment waarop het werk aan een aanvraag begint totdat het werk is voltooid (dat wil bijvoorbeeld de tijd van Actief naar Gesloten).
Werk wordt uitgevoerd
Meet de hoeveelheid werk of het aantal werkitems dat actief wordt gewerkt.
Scope
Vertegenwoordigt de hoeveelheid werk die is vastgelegd voor de opgegeven periode. Alleen van toepassing op processen met een vaste periode.
1 De CFD-widget (Analyse) en het ingebouwde CFD-diagram (gegevensarchief voor het bijhouden van werk) bieden geen discrete getallen voor leadtijd en cyclustijd. De widgets voor de doorlooptijd en cyclustijd bieden deze getallen echter wel.
Er is een goed gedefinieerde correlatie tussen leadtijd/cyclustijd en werk in uitvoering (WIP). Hoe meer WIP, hoe langer de cyclustijd, wat ook leidt tot langere levertijden. Het tegenovergestelde is ook waar: hoe minder WIP, hoe korter de cyclus en de doorlooptijd. Wanneer het ontwikkelteam zich op minder items richt, verminderen ze de cyclus en doorlooptijden. Deze correlatie is een belangrijke reden waarom u de limieten voor werk in uitvoering kunt instellen op het bord.
Het aantal werkitems geeft de totale hoeveelheid werk op een bepaalde dag aan. In een vaste periode geeft een wijziging in dit aantal een bereikwijziging aan voor een bepaalde periode. In een continue stroom CFD geeft het de totale hoeveelheid werk in de wachtrij aan en voltooid voor een bepaalde dag.
Het opsplitsen van werk in specifieke bordkolommen biedt een weergave waarin werk wordt verwerkt. Deze weergave biedt inzicht in waar het werk soepel verloopt, waar er obstakels zijn en waar helemaal geen werk wordt uitgevoerd. Het is echter moeilijk om een tabellaire weergave van de gegevens te ontcijferen, maar het visuele CFD-diagram geeft bewijs dat er iets op een bepaalde manier gebeurt.
Problemen identificeren, passende acties ondernemen
De CFD beantwoordt verschillende specifieke vragen en op basis van het antwoord kunnen acties worden ondernomen om het proces aan te passen om het werk door het systeem te verplaatsen. Laten we eens kijken naar elk van deze vragen.
Is het team op tijd aan het werk?
Deze vraag is alleen van toepassing op CFD's met een vaste periode. U krijgt inzicht door te kijken naar de curve (of voortgang) van het werk in de laatste kolom van het bord.
In dit scenario kan het handig zijn om het werkbereik in de iteratie te verminderen als duidelijk is dat werk, in een stabiel tempo, niet snel genoeg wordt voltooid. Het kan erop wijzen dat het werk is onderschat en moet worden meegenomen in de planning van de volgende sprints.
Er kunnen echter andere redenen zijn die kunnen worden bepaald 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 een vergelijkbare of uniforme afstand van elkaar van begin tot eind? Lijkt een kolom gedurende een periode van meerdere dagen plat te zijn? Of, lijkt het te "bulten"?
Mura, de magere term voor platte lijnen en bulges, betekent oneffenheid en geeft een vorm van afval (Muda) in het systeem aan. Eventuele ongelijkheden in het systeem veroorzaken bulten in de CFD.
Monitoring the CFD for flat lines and bulges supports a key part of the Theory of Constraints project management process. Het beveiligen van het langzaamste gebied van het systeem wordt het trommelbuffer-touwproces genoemd en maakt deel uit van de planning van het werk.
Twee problemen worden visueel weergegeven als platte lijnen en als uitstulpingen.
Platte lijnen worden weergegeven wanneer het team hun werk niet regelmatig bijwerkt. Het bord biedt de snelste manier om van de ene kolom naar de andere over te stappen.
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 slechts één deel van het systeem of twee delen van een systeem problemen ondervindt, ziet u een bult.
Platte lijnen
Bulges treden op wanneer werk zich in één deel van het systeem opstelt en niet door een proces loopt.
Een bult kan bijvoorbeeld optreden wanneer het testen een lange periode duurt terwijl het ontwikkelen een kortere periode duurt, waardoor het werk zich in de ontwikkelingsstatus opstapelt (bulten geven aan dat een geslaagde stap een probleem heeft, niet noodzakelijkerwijs de stap waarin de bult zich voordoet).
Uitstulpingen
Hoe lost u stroomproblemen op?
U kunt het probleem van een gebrek aan tijdige updates oplossen via:
- Dagelijkse stand-ups.
- Andere gewone vergaderingen.
- 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 zijn:
- Procesbrede obstakels.
- Processen duren lang.
- Werk verschuift naar andere kansen die niet op het bord worden vastgelegd.
Een voorbeeld van systemische platte lijn kan optreden met een kenmerken CFD. Functiewerk kan veel langer duren dan werk aan gebruikersverhalen omdat functies bestaan uit verschillende verhalen. In deze situaties wordt de helling verwacht (zoals in het bovenstaande voorbeeld) of is het probleem bekend en wordt het al door het team als een probleem 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. Afhankelijk van waar de bult zich voordoet, kan de oplossing afwijken. Stel dat de bult zich voordoet in het ontwikkelingsproces. De bult kan zich voordoen omdat het uitvoeren van tests veel 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.
Twee mogelijk eenvoudige manieren om dit probleem op te lossen zijn: 1) Verschuif ontwikkelaars van het ontwikkelproces naar het testproces totdat de bulge wordt geëlimineerd of 2) de volgorde van werk zodanig wijzigen dat werk dat snel kan worden gedaan, is verbonden met werk dat langer duurt. Zoek naar eenvoudige oplossingen om de uitstulpingen te elimineren.
Notitie
Omdat veel 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 zal u vertellen dat er een probleem is en ongeveer waar het is, maar u moet onderzoeken om de hoofdoorzaak(en) te krijgen. De hier beschreven richtlijnen geven aanbevolen acties aan die specifieke problemen oplossen, maar die mogelijk niet van toepassing zijn 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 wordt vooraf geladen met het werk dat op de eerste dag moet worden uitgevoerd. Wijzigingen in de bovenste regel geven aan dat werk is toegevoegd of verwijderd.
Het ene scenario waarin u de wijzigingen in het bereik met een CFD niet kunt bijhouden wanneer hetzelfde aantal werkitems wordt toegevoegd als verwijderd op dezelfde dag. De lijn blijft vlak. Vergelijk verschillende grafieken met elkaar. Bewaak de specifieke problemen. Gebruik Burndown voor het weergeven/configureren van sprints om bereikwijzigingen te controleren.
Te veel WIP?
U kunt eenvoudig controleren of de WIP-limieten van het bord zijn overschreden. U kunt het ook bewaken vanuit 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 uitbreidt om een ovaal te worden. Het is een indicatie dat de WIP een negatieve invloed heeft op de cyclus en de doorlooptijd.
Hier volgt een goede vuistregel voor werkzaamheden die worden uitgevoerd. Er mogen op elk moment niet meer dan twee items worden uitgevoerd per teamlid. De belangrijkste reden voor twee items versus strengere limieten is omdat de realiteit vaak indringt in elk softwareontwikkelingsproces.
Soms kost het tijd om informatie op te halen van een belanghebbende, of het kost meer tijd om de benodigde software te verkrijgen. Er zijn een aantal redenen waarom het werk mogelijk wordt gestopt. Als u een tweede werkitem hebt om te draaien, krijgt u wat ruimte. Als beide items worden geblokkeerd, is het tijd om een rode vlag te genereren om iets te deblokkeren, niet alleen om te schakelen naar nog een ander item. Zodra er een groot aantal items in behandeling is, heeft de persoon die aan deze items werkt problemen met het schakelen tussen contexten. Het is waarschijnlijker dat ze vergeten wat ze deden en fouten kunnen optreden.
Doorlooptijd versus cyclustijd
In het onderstaande diagram ziet u hoe de doorlooptijd verschilt van de cyclustijd. De doorlooptijd wordt berekend op basis van het maken van werkitems tot het invoeren van een voltooide status. De cyclustijd wordt berekend van het eerste invoeren van een statuscategorie Wordt uitgevoerd of Opgelost tot het invoeren van een categorie Voltooide status.
Afbeelding van doorlooptijd versus cyclustijd
Als een werkitem de status Voltooid invoert en vervolgens opnieuw wordt geactiveerd, draagt elke extra tijd die het besteedt aan een voorgestelde, actieve of opgeloste status bij aan de lead-/cyclustijd wanneer deze voor de tweede keer een categorie Voltooide status invoert.
Als uw team het bord gebruikt, wilt u weten hoe uw kolommen worden toegewezen aan werkstroomstatussen. Zie Kolommen toevoegen voor meer informatie over het configureren van uw bord.
Zie werkstroomstatussen en statuscategorieën voor meer informatie over hoe het systeem gebruikmaakt van de statuscategorieën Voorgesteld, Wordt uitgevoerd, Opgelost en Voltooid.
Plannen met schatting van levertijden op basis van lead-/cyclustijden
U kunt de gemiddelde lead-/cyclustijden en standaarddeviaties gebruiken om de levertijden te schatten.
Wanneer u een werkitem maakt, kunt u de gemiddelde doorlooptijd van uw team gebruiken om te schatten wanneer uw team dat werkitem voltooit. De standaarddeviatie van uw team geeft de variabiliteit van de schatting aan. Op dezelfde manier kunt u cyclustijd en de standaarddeviatie gebruiken om de voltooiing van een werkitem te schatten zodra het werk is begonnen.
In de volgende grafiek is de gemiddelde cyclustijd acht dagen. De standaarddeviatie is +/- zes dagen. Met behulp van deze gegevens kunnen we schatten dat het team toekomstige gebruikersverhalen ongeveer 2-14 dagen na het begin van het werk zal voltooien. Hoe smaller de standaarddeviatie, hoe voorspelbaarder uw schattingen.
Voorbeeldwidget Cyclustijd
Procesproblemen identificeren
Bekijk het controlediagram van uw team voor uitbijters. Uitbijters vertegenwoordigen vaak een onderliggend procesprobleem. Wacht bijvoorbeeld te lang om pr-beoordelingen te voltooien of een externe afhankelijkheid niet snel op te lossen.
Zoals u kunt zien in de volgende grafiek, waarin verschillende uitschieters worden weergegeven, duurde het langer om verschillende bugs te voltooien dan het gemiddelde van het team. Het onderzoeken waarom deze fouten langer duren, kan helpen bij het ontdekken van procesproblemen. Het oplossen van de procesproblemen kan helpen de standaarddeviatie van uw team te verminderen en de voorspelbaarheid van uw team te verbeteren.
Voorbeeld van de widget Cyclustijd met verschillende uitbijters
U kunt ook zien hoe proceswijzigingen van invloed zijn op uw lead- en cyclustijd. 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.