Vägledning för kumulativt flöde, ledtid och cykeltid

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Du använder kumulativa flödesdiagram (CFD) för att övervaka flödet av arbete genom ett system. De två primära måtten för att spåra, cykeltid och ledtid kan extraheras från diagrammet. Information om hur du konfigurerar eller visar CFD-diagram finns i Konfigurera ett kumulativt flödesdiagram.

Eller så kan du lägga till kontrolldiagrammen Leadtid och cykeltid i dina instrumentpaneler.

Exempeldiagram och primära mått

CFD för kontinuerligt flöde är det diagram som gynnas mest av team som följer en mager process.

Många lag har dock börjat kombinera magra metoder med Scrum eller andra metoder, vilket innebär att de tränar lean inom ramen för en iteration eller sprint. I den här situationen får diagrammet ett något annorlunda utseende och ger ytterligare två, och mycket värdefulla, informationsdelar som visas i nästa diagram.

Kontinuerligt flöde

Cfd för fast period som visas här är för en slutförd sprint.

Den översta raden representerar omfångsuppsättningen för sprinten. Och eftersom arbetet måste slutföras den sista dagen i sprinten anger lutningen i tillståndet Stängd om ett lag är på rätt spår för att slutföra sprinten. Det enklaste sättet att se den här vyn är som ett uppbränt diagram.

Data avbildas alltid med det första steget i processen som det övre vänstra och det sista steget i processen som längst ned till höger.

Cfd för fast period för en slutförd sprint

Diagrammått

CFD-diagram visar antalet arbetsobjekt grupperade efter delstat/Kanban-kolumn över tid. De två primära måtten för att spåra, cykeltid och ledtid kan extraheras från diagrammet.

---

Mått

Definition

---

Cykeltid¹

Mäter den tid det tar att flytta arbetet genom ett enda process- eller arbetsflödestillstånd. Beräkningen är från början av en process till början av nästa process.

Ledtid¹

För en kontinuerlig flödesprocess: Mäter hur lång tid det tar från när en begäran görs (till exempel att lägga till en föreslagen användarberättelse) tills den begäran har slutförts (stängd).

För en sprint- eller fast periodprocess: Mäter tiden från när arbetet med en begäran börjar tills arbetet har slutförts (dvs. tiden från Aktiv till Stängd).

Pågående arbete

Mäter mängden arbete eller antalet arbetsobjekt som aktivt bearbetas.

Definitionsområde

Representerar mängden arbete som har utförts under den angivna tidsperioden. Gäller endast för processer med fast period.

---

¹ CFD-widgeten (analys) och det inbyggda CFD-diagrammet (datalagret för arbetsspårning) ger inte diskreta siffror om ledtid och cykeltid. Widgetarna leadtid och cykeltid anger dock dessa siffror.

Det finns en väldefinierad korrelation mellan ledtid/cykeltid och pågående arbete (WIP). Ju mer WIP, desto längre cykeltid, vilket också leder till längre ledtider. Det motsatta är också sant – ju mindre WIP, desto kortare cykel- och ledtid. När utvecklingsteamet fokuserar på färre objekt minskar de cykel- och ledtiderna. Den här korrelationen är en viktig orsak till varför du kan och bör ange gränser för pågående arbete på Kanban-tavlan.

Antalet arbetsobjekt anger den totala mängden arbete på en viss dag. Under en cfd med fast period anger en ändring i det här antalet omfångsändringar för en viss period. I ett kontinuerligt flödes-CFD anger det den totala mängden arbete i kön och slutfört under en viss dag.

Att dela upp arbete i specifika Kanban-brädkolumner ger en vy där arbetet pågår. Den här vyn ger insikter om var arbetet rör sig smidigt, där det finns blockeringar och där inget arbete görs alls. Det är svårt att dechiffrera en tabellvy över data, men det visuella CFD-diagrammet ger bevis för att något händer på ett givet sätt.

Identifiera problem, vidta lämpliga åtgärder

CFD svarar på flera specifika frågor och baserat på svaret kan åtgärder vidtas för att justera processen för att flytta arbetet genom systemet. Låt oss titta på var och en av dessa frågor här.

Kommer teamet att slutföra arbetet i tid?

Den här frågan gäller endast cfd:er för fast period. Du får en förståelse genom att titta på arbetskurvan (eller förloppet) i den sista kolumnen på Kanban-tavlan.

I det här scenariot kan det vara lämpligt att minska omfattningen av arbetet i iterationen om det är uppenbart att arbetet i stadig takt inte slutförs tillräckligt snabbt. Det kan tyda på att arbetet underskattades och bör räknas in i nästa sprintplanering.

Det kan dock finnas andra orsaker som kan fastställas genom att titta på andra data i diagrammet.

Hur fortskrider arbetsflödet?

Slutför teamet arbetet i stadig takt? Ett sätt att se är att titta på avståndet mellan de olika kolumnerna i diagrammet. Är de av ett liknande eller enhetligt avstånd från varandra från början till slut? Ser en kolumn ut att vara platt under en period på flera dagar? Eller verkar det "svälla"?

Mura, den magra termen för platta linjer och utbuktningar, innebär ojämnhet och indikerar en form av avfall (Muda) i systemet. Eventuella ojämnheter i systemet gör att utbuktningar visas i CFD:en.

Övervakning av CFD för plana linjer och utbuktningar stöder en viktig del av projekthanteringsprocessen Teori om begränsningar. Att skydda systemets långsammaste område kallas för trumbuffertrepprocessen och är en del av hur arbetet planeras.

Två problem visas visuellt som platta linjer och som utbuktningar.

Platta linjer visas när teamet inte uppdaterar sitt arbete med en regelbunden takt. Kanban-tavlan är det snabbaste sättet att övergå från en kolumn till en annan.
Platta linjer kan också visas när arbetet i en eller flera processer tar längre tid än planerat. Platta linjer visas över många delar av systemet eftersom om bara en del av systemet eller två delar av ett system har problem så ser du en utbuktning.

Plana linjer

Utbuktningar uppstår när arbetet byggs upp i en del av systemet och inte rör sig genom en process.
En utbuktning kan till exempel inträffa när testningen tar lång tid medan utvecklingen tar en kortare tid, vilket gör att arbetet ackumuleras i utvecklingstillståndet (utbuktningar indikerar att ett efterföljande steg har ett problem, inte nödvändigtvis steget där utbuktningen inträffar).

Utbuktningar

Hur åtgärdar du flödesproblem?

Du kan lösa problemet med brist på uppdateringar i tid via:

• Dagliga stand-ups.
• Andra regelbundna möten.
• Schemalägg ett e-postmeddelande om en daglig teampåminnelse.

Systemiska flat-line problem tyder på ett mer utmanande problem, även om sådana problem är sällsynta. Plana linjer indikerar att arbetet i systemet har stoppats. Underliggande orsaker kan vara:

• Processomfattande blockeringar.
• Processer som tar lång tid.
• Arbetet övergår till andra möjligheter som inte fångas på tavlan.

Ett exempel på systemisk platt linje kan förekomma med en cfd-funktion. Funktionsarbete kan ta mycket längre tid än att arbeta med användarberättelser eftersom funktioner består av flera berättelser. I dessa situationer förväntas antingen lutningen (som i exemplet ovan) eller så är problemet välkänt och tas redan upp av teamet som ett problem. Om det är ett känt problem ligger problemlösningen utanför omfånget för den här artikeln.

Teams kan proaktivt åtgärda problem som visas som CFD-utbuktningar. Beroende på var utbuktningen inträffar kan korrigeringen vara annorlunda. Anta till exempel att utbuktningen sker i utvecklingsprocessen. Utbuktningen kan inträffa eftersom det tar mycket längre tid att köra tester än att skriva kod. Testare kan också hitta ett stort antal buggar. När de kontinuerligt övergår arbetet tillbaka till utvecklarna ärver utvecklarna en växande lista över aktivt arbete.

Två potentiellt enkla sätt att lösa det här problemet är: 1) Flytta utvecklare från utvecklingsprocessen till testningsprocessen tills utbuktningen har eliminerats eller 2) ändra arbetsordningen så att arbete som kan utföras snabbt är sammanvävt med arbete som tar längre tid att göra. Leta efter enkla lösningar för att eliminera utbuktningarna.

Kommentar

Eftersom många olika scenarier kan uppstå som gör att arbetet fortsätter ojämnt är det viktigt att du utför en faktisk analys av problemet. CFD kommer att berätta för dig att det finns ett problem och ungefär var det är men du måste undersöka för att komma till rotorsakerna. Vägledningen här anger rekommenderade åtgärder som löser specifika problem men som kanske inte gäller för din situation.

Ändrades omfånget?

Omfångsändringar gäller endast cfd:er för fast period. Den översta raden i diagrammet anger omfånget för arbetet. En sprint är förinstallerad med det arbete som ska utföras den första dagen. Ändringar på den översta raden indikerar att arbetet har lagts till eller tagits bort.

Det enda scenario där du inte kan spåra omfångsändringar med en CFD inträffar när samma antal arbetsobjekt läggs till som borttagna samma dag. Linjen skulle fortsätta att vara platt. Jämför flera diagram med varandra. Övervaka de specifika problemen. Använd Visa/konfigurera sprint burndown för att övervaka omfångsändringar.

För mycket WIP?

Du kan enkelt övervaka om WIP-gränserna har överskridits från Kanban-tavlan. Du kan också övervaka den från CFD:en.

En stor mängd WIP visas vanligtvis som en lodrät utbuktning. Ju längre det finns en stor mängd WIP, desto mer expanderas utbuktningen till att bli en oval. Det är en indikation på att WIP påverkar cykeln och ledtiden negativt.

Här är en bra tumregel för pågående arbeten. Det får inte finnas fler än två objekt som pågår per gruppmedlem vid en viss tidpunkt. Den främsta orsaken till två objekt jämfört med strängare gränser är att verkligheten ofta inkräktar på alla programutvecklingsprocesser.

Ibland tar det tid att få information från en intressent, eller så tar det längre tid att skaffa nödvändig programvara. Det finns ett antal orsaker till varför arbetet kan stoppas. Att ha ett andra arbetsobjekt att pivotleda till ger lite spelrum. Om båda objekten blockeras är det dags att hissa en röd flagga för att få något avblockerat – inte bara växla till ännu ett objekt. Så snart ett stort antal objekt pågår kommer personen som arbetar med dessa objekt att ha svårt att växla kontext. Det är mer troligt att de glömmer vad de gjorde, och misstag kan inträffa.

Ledtid kontra cykeltid

Diagrammet nedan visar hur ledtiden skiljer sig från cykeltiden. Ledtiden beräknas från skapande av arbetsobjekt till att ange ett slutfört tillstånd. Cykeltiden beräknas från att först ange en statuskategori för Pågående eller Löst till att ange en slutförd tillståndskategori.

Bild av ledtid kontra cykeltid

Om ett arbetsobjekt anger ett slutfört tillstånd och sedan återaktiveras, kommer eventuell extra tid som den spenderar i tillståndet Föreslagen, Pågår eller Löst att bidra till dess lead-/cykeltid när den anger en slutförd tillståndskategori för andra gången.

Om ditt team använder Kanban-tavlan vill du förstå hur dina Kanban-kolumner mappar till arbetsflödestillstånd. Mer information om hur du konfigurerar kanbankortet finns i Lägg till kolumner.

Mer information om hur systemet använder tillståndskategorierna – Föreslagna, Pågående, Lösta och Slutförda – finns i Arbetsflödestillstånd och tillståndskategorier.

Planera med uppskattning av leveranstider baserat på led-/cykeltider

Du kan använda genomsnittliga led-/cykeltider och standardavvikelser för att uppskatta leveranstider.

När du skapar ett arbetsobjekt kan du använda teamets genomsnittliga ledtid för att beräkna när ditt team ska slutföra arbetsobjektet. Teamets standardavvikelse anger variabiliteten för uppskattningen. På samma sätt kan du använda cykeltid och dess standardavvikelse för att uppskatta slutförandet av ett arbetsobjekt när arbetet har påbörjats.

I följande diagram är den genomsnittliga cykeltiden åtta dagar. Standardavvikelsen är +/- sex dagar. Med hjälp av dessa data kan vi uppskatta att teamet slutför framtida användarberättelser ungefär 2–14 dagar efter att de har börjat arbeta. Ju smalare standardavvikelsen är, desto mer förutsägbara är dina uppskattningar.

Exempel på widget för cykeltid

Identifiera processproblem

Granska teamets kontrolldiagram för avvikande värden. Extremvärden representerar ofta ett underliggande processproblem. Du kan till exempel vänta för länge för att slutföra PR-granskningar eller inte snabbt lösa ett externt beroende.

Som du ser i följande diagram, som visar flera extremvärden, tog det längre tid att slutföra flera buggar än teamets genomsnitt. Att undersöka varför dessa buggar tog längre tid kan hjälpa dig att upptäcka processproblem. Om du tar itu med processproblemen kan du minska teamets standardavvikelse och förbättra teamets förutsägbarhet.

Exempel på widget för cykeltid som visar flera extremvärden

Du kan också se hur processändringar påverkar din led- och cykeltid. Till exempel gjorde teamet den 15 maj en samlad insats för att begränsa WIP och åtgärda inaktuella buggar. Du kan se att standardavvikelsen begränsas efter det datumet, vilket visar förbättrad förutsägbarhet.

Nästa steg

Konfigurera dina kumulativa flödesdiagram eller Konfigurera ett ledtids- eller cykeltidsdiagram