Leitfaden zu kumulativem Fluss, Vorlaufzeit und Zykluszeit
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Sie verwenden kumulierte Flussdiagramme (CFD), um den Arbeitsfluss durch ein System zu überwachen. Die beiden primären Metriken zum Nachverfolgen, Zykluszeit und Vorlaufzeit können aus dem Diagramm extrahiert werden. Informationen zum Konfigurieren oder Anzeigen von CFD-Diagrammen finden Sie unter Konfigurieren eines kumulativen Flussdiagramms.
Alternativ können Sie Ihren Dashboards die Diagramme "Lead time and cycle time control" hinzufügen.
Beispieldiagramme und primäre Metriken
Der Fortlaufende Fluss CFD bietet das Diagramm, das am meisten von Teams bevorzugt wird, die einem schlanken Prozess folgen.
Viele Teams haben jedoch begonnen, schlanke Praktiken mit Scrum oder anderen Methoden zu kombinieren, was bedeutet, dass sie innerhalb der Spanne einer Iteration oder eines Sprints lean üben. In dieser Situation übernimmt das Diagramm ein etwas anderes Aussehen und bietet zwei zusätzliche und sehr wertvolle Informationen, wie im nächsten Diagramm dargestellt.
Kontinuierlicher Fluss
Der hier gezeigte Fixzeitraum CFD gilt für einen abgeschlossenen Sprint.
Die oberste Linie stellt den Bereich für den Sprint dar. Und da die Arbeit am letzten Tag des Sprints abgeschlossen werden muss, gibt die Steigung des geschlossenen Zustands an, ob ein Team auf der Strecke ist, um den Sprint abzuschließen. Die einfachste Möglichkeit, diese Ansicht zu betrachten, ist ein Burnup-Diagramm.
Die Daten werden immer mit dem ersten Schritt im Prozess als oben links und der letzte Schritt im Prozess als unten rechts dargestellt.
Festzeitraum CFD für einen abgeschlossenen Sprint
Diagrammmetriken
CFD-Diagramme zeigen die Anzahl der Arbeitsaufgaben an, die im Laufe der Zeit nach Status/Spalte gruppiert sind. Die beiden primären Metriken zum Nachverfolgen, Zykluszeit und Vorlaufzeit können aus dem Diagramm extrahiert werden.
Metrik
Definition
Zykluszeit 1
Misst die Zeit, die zum Verschieben der Arbeit in einem einzelnen Prozess- oder Workflowstatus erforderlich ist. Die Berechnung erfolgt vom Anfang eines Prozesses bis zum Anfang des nächsten Prozesses.
Lead Time 1
Für einen kontinuierlichen Ablaufprozess: Misst den Zeitraum, ab dem eine Anforderung gestellt wird (z. B. hinzufügen eines vorgeschlagenen Benutzerabschnitts), bis diese Anforderung abgeschlossen ist (geschlossen).
Für einen Sprint- oder festen Zeitraum: Misst die Zeit, ab der die Arbeit an einer Anforderung beginnt, bis die Arbeit abgeschlossen ist (d. h. die Zeit von "Aktiv" bis "Geschlossen").
Arbeiten in Bearbeitung
Misst die Arbeitsmenge oder die Anzahl der Arbeitsaufgaben, die aktiv bearbeitet werden.
Umfang
Stellt die Arbeitsmenge dar, die für den angegebenen Zeitraum zugesichert wurde. Gilt nur für Prozesse mit fester Periode.
1 Das CFD-Widget (Analyse) und das integrierte CFD-Diagramm (Work Tracking Data Store) stellen keine diskreten Zahlen für Leadzeit und Zykluszeit bereit. Die Widgets "Lead Time" und "Zykluszeit" stellen diese Zahlen jedoch bereit.
Es gibt eine gut definierte Korrelation zwischen Lead Time/Cycle Time und Work in Progress (WIP). Je mehr WIP, desto länger die Zykluszeit, was auch zu längeren Vorlaufzeiten führt. Das Gegenteil ist auch wahr – je weniger WIP, desto kürzer der Zyklus und die Vorlaufzeit. Wenn sich das Entwicklungsteam auf weniger Elemente konzentriert, reduzieren sie den Zyklus und die Vorlaufzeiten. Diese Korrelation ist ein wichtiger Grund, warum Sie die Grenzwerte für "Arbeiten in Bearbeitung" auf dem Board festlegen können und festlegen sollten.
Die Anzahl der Arbeitsaufgaben gibt die Gesamtarbeitsmenge an einem bestimmten Tag an. In einem festen Perioden-CFD gibt eine Änderung dieser Anzahl eine Bereichsänderung für einen bestimmten Zeitraum an. In einem kontinuierlichen Fluss CFD gibt es die Gesamtarbeitsmenge in der Warteschlange an und wird für einen bestimmten Tag abgeschlossen.
Durch die Dekompilierung von Arbeiten in bestimmte Boardspalten wird eine Ansicht bereitgestellt, in der sich die Arbeit befindet. Diese Ansicht bietet Einblicke darüber, wo sich die Arbeit reibungslos bewegt, wo es Blockaden gibt und wo überhaupt keine Arbeit geleistet wird. Es ist schwierig, eine tabellarische Ansicht der Daten zu entschlüsseln, das visuelle CFD-Diagramm liefert jedoch Beweise dafür, dass etwas in einer bestimmten Weise geschieht.
Identifizieren von Problemen, Ergreifen geeigneter Maßnahmen
Der CFD beantwortet mehrere spezifische Fragen und basierend auf der Antwort können Maßnahmen ergriffen werden, um den Prozess anzupassen, um die Arbeit durch das System zu bewegen. Sehen wir uns die einzelnen Fragen hier an.
Wird das Team rechtzeitig arbeiten?
Diese Frage gilt nur für CFDs mit fester Periode. Sie erhalten ein Verständnis, indem Sie die Kurve (oder den Fortschritt) der Arbeit in der letzten Spalte des Boards betrachten.
In diesem Szenario kann es sinnvoll sein, den Umfang der Arbeit in der Iteration zu reduzieren, wenn klar ist, dass die Arbeit in einem stetigen Tempo nicht schnell genug abgeschlossen wird. Es kann darauf hindeuten, dass die Arbeit unterschätzt wurde und in die nächste Sprintplanung eingegliedert werden sollte.
Es kann jedoch andere Gründe geben, die durch die Betrachtung anderer Daten im Diagramm bestimmt werden können.
Wie läuft der Arbeitsfluss ab?
Wird das Team die Arbeit in einem stetigen Tempo abschließen? Eine Möglichkeit, dies zu sagen, besteht darin, den Abstand zwischen den verschiedenen Spalten im Diagramm zu betrachten. Sind sie von Anfang bis Ende von einem ähnlichen oder einheitlichen Abstand voneinander entfernt? Scheint eine Spalte über einen Zeitraum von mehreren Tagen flach zu sein? Oder scheint es "bulge" zu sein?
Mura, der schlanke Begriff für flache Linien und Bulges, bedeutet Ungleichheit und weist auf eine Form von Abfall (Muda) im System hin. Jede Uneinheitlichkeit im System führt dazu, dass Bulges im CFD auftreten.
Die Überwachung des CFD für flache Linien und Bulges unterstützt einen wichtigen Teil der Theorie des Constraints-Projektmanagementprozesses. Der Schutz der langsamsten Fläche des Systems wird als Trommelpuffer-Seilprozess bezeichnet und ist Teil der Planung der Arbeit.
Zwei Probleme werden visuell als flache Linien und als Bulges angezeigt.
Flache Linien werden angezeigt, wenn das Team seine Arbeit nicht regelmäßig aktualisiert. Das Board bietet die schnellste Möglichkeit, die Arbeit von einer Spalte in eine andere zu übertragen.
Flache Linien können auch angezeigt werden, wenn die Arbeit in einem oder mehreren Prozessen länger dauert als geplant. Flache Linien werden über viele Teile des Systems hinweg angezeigt, da wenn nur ein Teil des Systems oder zwei Teile eines Systems Probleme haben, wird eine Bulge angezeigt.
Flache Linien
Bulges treten auf, wenn die Arbeit in einem Teil des Systems aufbaut und sich nicht durch einen Prozess bewegt.
Beispielsweise kann eine Bulge auftreten, wenn das Testen lange dauert, während die Entwicklung einen kürzeren Zeitraum dauert, was dazu führt, dass sich die Arbeit im Entwicklungszustand ansammelt (Bulges deuten darauf hin, dass ein erfolgreicher Schritt ein Problem hat, nicht notwendigerweise der Schritt, in dem die Bulge auftritt).
Ausbuchtungen
Wie beheben Sie Flussprobleme?
Sie können das Problem eines Mangels an rechtzeitigen Updates beheben, indem Sie:
- Tägliche Stand-ups.
- Andere regelmäßige Besprechungen.
- Planen einer täglichen Teamerinnerungs-E-Mail.
Systemische flache Probleme deuten auf ein schwierigeres Problem hin, obwohl solche Probleme selten sind. Flache Linien deuten darauf hin, dass die Arbeit im gesamten System angehalten wurde. Zugrunde liegende Ursachen können sein:
- Prozessweite Blockierungen.
- Prozesse dauern lange.
- Die Arbeit wechselt zu anderen Möglichkeiten, die nicht auf dem Board erfasst werden.
Ein Beispiel für systemische Flatline kann mit einem CFD-Feature auftreten. Featurearbeit kann viel länger dauern als die Arbeit an Benutzergeschichten, da Features aus mehreren Geschichten bestehen. In diesen Situationen wird entweder die Steigung erwartet (wie im obigen Beispiel), oder das Problem ist bekannt und wird bereits vom Team als Problem angesprochen. Wenn es sich um ein bekanntes Problem handelt, liegt die Problembehebung außerhalb des Umfangs dieses Artikels.
Teams kann Probleme proaktiv beheben, die als CFD-Bulges erscheinen. Je nachdem, wo die Bulge auftritt, kann der Fix unterschiedlich sein. Nehmen wir beispielsweise an, dass die Bulge im Entwicklungsprozess auftritt. Die Bulge kann auftreten, da die Ausführung von Tests viel länger dauert als das Schreiben von Code. Tester können auch eine große Anzahl von Fehlern finden. Wenn sie die Arbeit kontinuierlich an die Entwickler zurückführen, erben die Entwickler eine wachsende Liste aktiver Arbeiten.
Zwei potenziell einfache Möglichkeiten, dieses Problem zu lösen, sind: 1) Verschieben von Entwicklern aus dem Entwicklungsprozess in den Testprozess, bis die Bulge eliminiert wird oder 2) die Reihenfolge der Arbeit so ändern, dass die Arbeit, die schnell durchgeführt werden kann, mit Arbeit verwoben wird, die länger dauert. Suchen Sie nach einfachen Lösungen, um die Wölbe zu beseitigen.
Hinweis
Da viele verschiedene Szenarien auftreten können, die dazu führen, dass die Arbeit ungleichmäßig verläuft, ist es wichtig, dass Sie eine tatsächliche Analyse des Problems durchführen. Der CFD teilt Ihnen mit, dass es ein Problem gibt und ungefähr wo es sich befindet, aber Sie müssen untersuchen, um zur Ursache(n) zu gelangen. Die hier bereitgestellten Anleitungen geben empfohlene Aktionen an, die bestimmte Probleme lösen, die jedoch möglicherweise nicht für Ihre Situation gelten.
Hat sich der Bereich geändert?
Bereichsänderungen gelten nur für CFDs mit fester Periode. Die oberste Linie des Diagramms gibt den Umfang der Arbeit an. Ein Sprint wird vorgeladen mit der Arbeit am ersten Tag. Änderungen an der obersten Zeile deuten darauf hin, dass Arbeit hinzugefügt oder entfernt wurde.
Das ein Szenario, in dem Sie Bereichsänderungen mit einem CFD nicht nachverfolgen können, wenn dieselbe Anzahl von Arbeitsaufgaben hinzugefügt wird wie am selben Tag entfernt. Die Linie würde weiterhin flach sein. Vergleichen Sie mehrere Diagramme miteinander. Überwachen Sie die spezifischen Probleme. Verwenden Sie den Sprint-Burndown anzeigen/konfigurieren, um Bereichsänderungen zu überwachen.
Zu viel WIP?
Sie können ganz einfach überwachen , ob WIP-Grenzwerte von der Tafel überschritten wurden. Sie können es auch vom CFD überwachen.
Eine große Menge an WIP wird in der Regel als vertikale Bulge angezeigt. Je länger wip es gibt, desto mehr wird die Bulge zu einem Oval. Es ist ein Hinweis darauf, dass die WIP den Zyklus und die Vorlaufzeit negativ beeinflusst.
Hier ist eine gute Faustregel für laufende Arbeiten. Es sollten nicht mehr als zwei Elemente pro Teammitglied zu einem bestimmten Zeitpunkt ausgeführt werden. Der Hauptgrund für zwei Elemente im Vergleich zu strengeren Grenzwerten ist, dass die Realität häufig in jeden Softwareentwicklungsprozess eindringt.
Manchmal dauert es Zeit, um Informationen von einem Projektbeteiligten zu erhalten, oder es dauert mehr Zeit, um die erforderliche Software zu erwerben. Es gibt eine Reihe von Gründen, warum Die Arbeit möglicherweise angehalten wird. Eine zweite Arbeitsaufgabe zum Pivotieren bietet einen gewissen Spielraum. Wenn beide Elemente blockiert sind, ist es an der Zeit, ein rotes Kennzeichen auszuheben, um etwas entsperrt zu erhalten , nicht nur zu einem anderen Element zu wechseln. Sobald eine große Anzahl von elementen ausgeführt wird, hat die Person, die an diesen Elementen arbeitet, Schwierigkeiten beim Wechseln des Kontexts. Es ist wahrscheinlicher, dass sie vergessen werden, was sie getan haben, und Fehler können auftreten.
Leadzeit im Vergleich zur Zykluszeit
Das folgende Diagramm veranschaulicht, wie sich die Leadzeit von der Zykluszeit unterscheidet. Die Leadzeit wird von der Erstellung von Arbeitsaufgaben bis zum Eingeben eines Abgeschlossenen Zustands berechnet. Die Zykluszeit wird von der ersten Eingabe einer Statuskategorie "In Bearbeitung" oder "Aufgelöst" bis zur Eingabe einer Statuskategorie "Abgeschlossen" berechnet.
Abbildung der Vorlaufzeit im Vergleich zur Zykluszeit
Wenn eine Arbeitsaufgabe einen Status "Abgeschlossen" eingibt und dann erneut aktiviert wird, trägt jede zusätzliche Zeit, die sie in einem vorgeschlagenen, in Bearbeitungs- oder aufgelösten Zustand verbringt, zu ihrer Lead-/Zykluszeit bei, wenn sie eine Kategorie "Abgeschlossen" zum zweiten Mal eingibt.
Wenn Ihr Team das Board verwendet, sollten Sie verstehen, wie Ihre Spalten Workflowzuständen zugeordnet sind. Weitere Informationen zum Konfigurieren der Tafel finden Sie unter Hinzufügen von Spalten.
Weitere Informationen zur Verwendung der Statuskategorien "Vorgeschlagen", "In Bearbeitung", "Gelöst" und "Abgeschlossen" finden Sie unter Workflowstatus und Statuskategorien.
Planen der Nutzung von geschätzten Lieferzeiten basierend auf Lead-/Zykluszeiten
Sie können die durchschnittliche Lead-/Zykluszeiten und Standardabweichungen verwenden, um Lieferzeiten zu schätzen.
Wenn Sie eine Arbeitsaufgabe erstellen, können Sie die durchschnittliche Vorlaufzeit Ihres Teams verwenden, um zu schätzen, wann Ihr Team diese Arbeitsaufgabe abschließen wird. Die Standardabweichung Ihres Teams informiert Sie über die Variabilität der Schätzung. Ebenso können Sie die Zykluszeit und deren Standardabweichung verwenden, um den Abschluss einer Arbeitsaufgabe zu schätzen, sobald die Arbeit begonnen hat.
Im folgenden Diagramm beträgt die durchschnittliche Zykluszeit acht Tage. Die Standardabweichung beträgt +/- sechs Tage. Anhand dieser Daten können wir schätzen, dass das Team zukünftige Benutzergeschichten ungefähr 2-14 Tage nach Beginn der Arbeit abschließen wird. Je schmaler die Standardabweichung ist, desto vorhersehbarer sind Ihre Schätzungen.
Beispiel für Zykluszeitwidget
Identifizieren von Prozessproblemen
Überprüfen Sie das Steuerelementdiagramm Ihres Teams auf Ausreißer. Ausreißer stellen häufig ein zugrunde liegendes Prozessproblem dar. Warten Sie z. B. zu lange, um PR-Rezensionen abzuschließen oder eine externe Abhängigkeit schnell zu lösen.
Wie Sie im folgenden Diagramm sehen können, das mehrere Ausreißer zeigt, dauerten mehrere Fehler länger als der Durchschnitt des Teams. Die Untersuchung, warum diese Fehler länger gedauert haben, kann dazu beitragen, Prozessprobleme aufzudecken. Die Behandlung der Prozessprobleme kann dazu beitragen, die Standardabweichung Ihres Teams zu verringern und die Vorhersagbarkeit Ihres Teams zu verbessern.
Beispiel-Zykluszeit-Widget mit mehreren Ausreißern
Sie können auch sehen, wie sich Prozessänderungen auf Ihre Lead- und Zykluszeit auswirken. Beispielsweise hat das Team am 15. Mai einen konzertierten Versuch unternommen, die WIP einzuschränken und veraltete Fehler zu beheben. Sie können sehen, dass sich die Standardabweichung nach diesem Datum einschränkt und eine verbesserte Vorhersagbarkeit anzeigt.