Leitfaden zu kumulativem Fluss, Vorlaufzeit und Zykluszeit

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019 | TFS 2018

Sie verwenden kumulative Flussdiagramme (CFD), um den Arbeitsfluss über ein System zu überwachen. Die beiden primären Metriken, die nachverfolgt werden sollen, 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 Steuerungsdiagramme "Leadzeit" und "Zykluszeit" hinzufügen.

Beispieldiagramme und primäre Metriken

Continuous Flow CFD stellt das Diagramm bereit, das von Teams am meisten bevorzugt wird, die einem schlanken Prozess folgen.

Viele Teams haben jedoch begonnen, Lean-Praktiken mit Scrum oder anderen Methoden zu kombinieren, was bedeutet, dass sie Lean innerhalb der Zeitspanne einer Iteration oder eines Sprints üben. In dieser Situation hat das Diagramm ein etwas anderes Aussehen und bietet zwei zusätzliche und sehr wertvolle Informationen, wie im nächsten Diagramm gezeigt.

Fortlaufender Fluss
Konzeptionelles Bild von CFD-Metriken.

Der hier gezeigte CFD-Wert für einen festen Zeitraum ist für einen abgeschlossenen Sprint.

Die obere Zeile stellt den für den Sprint festgelegten Bereich dar. Und da die Arbeit bis zum letzten Tag des Sprints abgeschlossen sein muss, gibt die Steigung des Zustands Geschlossen an, ob ein Team auf dem richtigen Weg ist, den Sprint abzuschließen. Die einfachste Möglichkeit, sich diese Ansicht zu vorstellen, ist ein Burnupdiagramm.

Die Daten werden immer mit dem ersten Schritt im Prozess oben links und dem letzten Schritt im Prozess unten rechts dargestellt.

CFD für einen festen Zeitraum für einen abgeschlossenen Sprint
CFD-Metriken, fester Zeitraum.

Diagrammmetriken

CFD-Diagramme zeigen die Anzahl der Arbeitselemente an, die nach Status/Kanban-Spalte im Zeitverlauf gruppiert sind. Die beiden primären Metriken, die nachverfolgt werden sollen, Zykluszeit und Vorlaufzeit, können aus dem Diagramm extrahiert werden.


Metrik

Definition


Zykluszeit1

Misst die Zeit, die benötigt wird, um die Arbeit durch einen einzelnen Prozess- oder Workflowzustand zu verschieben. Die Berechnung erfolgt vom Anfang eines Prozesses bis zum Beginn des nächsten Prozesses.

Vorlaufzeit1

Für einen kontinuierlichen Ablaufprozess: Misst den Zeitraum, der von der Durchführung einer Anforderung (z. B. dem Hinzufügen einer vorgeschlagenen User Story) bis zum Abschluss (Geschlossen) dauert.

Für einen Sprintprozess oder einen bestimmten Zeitraum: Misst die Zeit von beginn der Arbeit an einer Anforderung bis zum Abschluss der Arbeit (d. h. die Zeit von Aktiv bis Geschlossen).

In Bearbeitung

Misst die Menge der Arbeit oder die Anzahl der Arbeitselemente, die aktiv bearbeitet werden.

Umfang

Stellt den Arbeitsaufwand für den angegebenen Zeitraum dar. Gilt nur für Prozesse mit fester Dauer.


1 Das CFD-Widget (Analyse) und das integrierte CFD-Diagramm (Arbeitsverfolgungsdatenspeicher) stellen keine diskreten Zahlen für Die Vorlaufzeit und die Zykluszeit bereit. Die Widgets "Vorlaufzeit" und "Zykluszeit" stellen diese Zahlen jedoch bereit.

Es gibt eine klar 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 der Fall– 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 Durchlaufzeiten. Diese Korrelation ist ein wichtiger Grund, warum Sie Grenzwerte für "In Bearbeitung" auf dem Kanban-Board festlegen können und sollten.

Die Anzahl der Arbeitselemente gibt die Gesamtarbeitsmenge an einem bestimmten Tag an. Bei einem CFD für einen festen Zeitraum gibt eine Änderung dieser Anzahl eine Bereichsänderung für einen bestimmten Zeitraum an. In einem continuous flow CFD gibt es die Gesamtarbeit in der Warteschlange an, die für einen bestimmten Tag abgeschlossen wurde.

Das Zerlegen von Arbeit in bestimmte Kanban-Boardspalten bietet eine Ansicht, wo die Arbeit gerade ausgeführt wird. Diese Ansicht bietet Einblicke, wo die Arbeit reibungslos verläuft, wo es Zusperren gibt und wo überhaupt keine Arbeit ausgeführt wird. Es ist schwierig, eine tabellarische Ansicht der Daten zu entschlüsseln, aber das visuelle CFD-Diagramm zeigt, 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 Aktionen ergriffen werden, um den Prozess anzupassen, um die Arbeit durch das System zu verschieben. Sehen wir uns hier jede dieser Fragen an.

Wird das Team die Arbeit pünktlich abschließen?

Diese Frage gilt nur für CFDs mit fester Laufzeit. Sie erhalten ein Verständnis, indem Sie die Kurve (oder den Fortschritt) der Arbeit in der letzten Spalte des Kanban-Boards betrachten.

Beispiel-CFD mit einem halb abgeschlossenen Diagramm mit gepunkteten Linien, die zeigen, dass die Arbeit nicht abgeschlossen wird

In diesem Szenario kann es sinnvoll sein, den Arbeitsumfang in der Iteration zu verringern, wenn klar ist, dass die Arbeit in einem konstanten Tempo nicht schnell genug abgeschlossen wird. Dies kann darauf hindeuten, dass die Arbeit unterschätzt wurde und in die planung der nächsten Sprints berücksichtigt werden sollte.

Es kann jedoch andere Gründe geben, die durch die Betrachtung anderer Daten im Diagramm ermittelt werden können.

Wie verläuft der Arbeitsablauf?

Führt das Team die Arbeit in einem konstanten Tempo durch? Eine Möglichkeit, dies zu erkennen, besteht darin, den Abstand zwischen den verschiedenen Spalten im Diagramm zu betrachten. Weisen sie von Anfang bis Ende einen ähnlichen oder einheitlichen Abstand voneinander auf? Wird eine Spalte über einen Zeitraum von mehreren Tagen flach angezeigt? Oder scheint es sich zu "wölben"?

Mura, der magere Begriff für flache Linien und Ausbuchtungen, bedeutet Unebenheiten und weist auf eine Form von Abfall (Muda) im System hin. Jede Unebenheit im System führt dazu, dass Wulstungen im CFD auftreten.

Die Überwachung des CFD für Flachlinien und Wulstungen unterstützt einen wichtigen Teil des Theory of Constraints-Projektmanagementprozesses. Der Schutz des langsamsten Bereichs des Systems wird als Trommel-Puffer-Seil-Prozess bezeichnet und ist Teil der Planung der Arbeit.

Zwei Probleme zeigen sich visuell als flache Linien und als Wulstungen.

Flache Linien werden angezeigt, wenn das Team seine Arbeit nicht in einem regelmäßigen Rhythmus aktualisiert. Das Kanban-Board bietet die schnellste Möglichkeit, 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, denn wenn nur ein Teil des Systems oder zwei Teile eines Systems Probleme haben, sehen Sie eine Ausbuchtung.

Flache Linien
CFD-Metriken, flache Linien.

Wulstungen treten auf, wenn sich Arbeit in einem Teil des Systems aufbaut und sich nicht durch einen Prozess bewegt.
Beispielsweise kann eine Ausbuchtung auftreten, wenn das Testen einen langen Zeitraum dauert, während die Entwicklung einen kürzeren Zeitraum dauert, was dazu führt, dass sich arbeit im Entwicklungszustand ansammelt (Ausbuchtungen deuten darauf hin, dass ein erfolgreiches Schritt ein Problem hat, nicht notwendigerweise der Schritt, in dem die Ausbuchtung stattfindet).

Ausbuchtungen
CFD-Metriken, Wulstungen.

Wie beheben Sie Flowprobleme?

Sie können das Problem eines Mangels an rechtzeitigen Updates durch Folgendes lösen:

  • Tägliche Stand-ups.
  • Weitere regelmäßige Besprechungen.
  • Planen einer täglichen Teamerinnerungs-E-Mail.

Systemische Flachlinienprobleme weisen auf ein schwierigeres Problem hin, obwohl solche Probleme selten sind. Flache Linien geben an, dass die Arbeit im gesamten System beendet wurde. Die zugrunde liegenden Ursachen können sein:

  • Prozessweite Blockierungen.
  • Prozesse dauern lange.
  • Die Arbeit verlagert sich auf andere Möglichkeiten, die nicht auf dem Board erfasst werden.

Ein Beispiel für systemische Flatline kann mit einem Feature-CFD auftreten. Die Arbeit an Features kann viel länger dauern als die Arbeit an User Storys, 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 Geltungsbereichs dieses Artikels.

Teams können Probleme proaktiv beheben, die als CFD-Wulst angezeigt werden. Je nachdem, wo die Ausbuchtung auftritt, kann die Korrektur unterschiedlich sein. Nehmen wir beispielsweise an, dass die Ausbuchtung im Entwicklungsprozess auftritt. Die Ausbuchtung kann auftreten, weil das Ausführen von Tests viel länger dauert als das Schreiben von Code. Tester finden möglicherweise auch eine große Anzahl von Fehlern. Wenn sie die Arbeit kontinuierlich zurück an die Entwickler übergeben, erben die Entwickler eine wachsende Liste aktiver Arbeit.

Zwei potenziell einfache Möglichkeiten, dieses Problem zu lösen, sind: 1) Entwickler vom Entwicklungsprozess in den Testprozess verschieben, bis die Ausbuchtung beseitigt ist, oder 2) die Reihenfolge der Arbeit so ändern, dass schnell zu erledigende Arbeiten mit Arbeiten verwoben werden, die länger dauern. Suchen Sie nach einfachen Lösungen, um die Ausbuchtungen 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 zu den Grundursachen zu gelangen. Die hier bereitgestellten Anleitungen enthalten empfohlene Maßnahmen, 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 für festen Zeitraum. Die obere Zeile des Diagramms gibt den Umfang der Arbeit an. Ein Sprint ist mit der am ersten Tag zu erledigenden Arbeit vorab geladen. Änderungen an der obersten Zeile deuten darauf hin, dass Arbeit hinzugefügt oder entfernt wurde.

Das eine Szenario, in dem Sie Bereichsänderungen mit einem CFD nicht nachverfolgen können, tritt auf, wenn die gleiche Anzahl von Arbeitselementen hinzugefügt wird, die am selben Tag entfernt wurden. Die Linie würde weiterhin flach bleiben. 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 problemlos überwachen , ob WIP-Grenzwerte über das Kanban-Board überschritten wurden. Sie können sie auch über den CFD überwachen.

Eine große Menge an WIP zeigt sich in der Regel als vertikale Ausbuchtung. Je länger eine große Menge an WIP vorhanden ist, desto mehr erweitert sich die Ausbuchtung zu einem Oval. Dies ist ein Hinweis darauf, dass sich das WIP negativ auf den Zyklus und die Durchlaufzeit auswirkt.

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 Standard Grund 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 Beteiligten zu erhalten, oder es dauert mehr Zeit, um die erforderliche Software zu erwerben. Es gibt eine Reihe von Gründen, warum die Arbeit eingestellt werden kann. Ein zweites Arbeitselement, auf das pivotieren soll, bietet einen gewissen Spielraum. Wenn beide Elemente blockiert sind, ist es an der Zeit, ein rotes Flag auszulösen, um eine Entsperrung zu erhalten – und nicht einfach zu einem anderen Element zu wechseln. Sobald eine große Anzahl von Elementen in Bearbeitung ist, hat die Person, die an diesen Elementen arbeitet, Schwierigkeiten beim Kontextwechsel. Es ist wahrscheinlicher, dass sie vergessen, was sie getan haben, und es können Fehler auftreten.

Vorlaufzeit im Vergleich zu Zykluszeit

Das folgende Diagramm veranschaulicht, wie sich die Vorlaufzeit von der Zykluszeit unterscheidet. Die Durchlaufzeit wird von der Erstellung eines Arbeitselements bis zur Eingabe des Status Abgeschlossen berechnet. Die Zykluszeit wird von der ersten Eingabe einer Statuskategorie "In Bearbeitung" oder "Aufgelöst" bis zur Eingabe einer Statuskategorie "Abgeschlossen" berechnet.

Veranschaulichung der Vorlaufzeit im Vergleich zur Zykluszeit

Konzeptionelles Bild der Messung von Zykluszeit und Durchlaufzeit

Wenn ein Arbeitselement in den Status Abgeschlossen wechselt und dann reaktiviert wird, trägt jede zusätzliche Zeit, die es im Status "Vorgeschlagen", "In Bearbeitung" oder "Aufgelöst" aufwendet, zur Lead-/Zykluszeit bei, wenn es zum zweiten Mal in die Statuskategorie Abgeschlossen wechselt.

Wenn Ihr Team das Kanban-Board verwendet, sollten Sie verstehen, wie Ihre Kanban-Spalten den Workflowzuständen zugeordnet werden. Weitere Informationen zum Konfigurieren Ihres Kanban-Boards finden Sie unter Hinzufügen von Spalten.

Weitere Informationen dazu, wie das System die Zustandskategorien (Vorgeschlagen, In Bearbeitung, Aufgelöst und Abgeschlossen) verwendet, finden Sie unter Workflowzustände und Zustandskategorien.

Planen mithilfe von Geschätzten Lieferzeiten basierend auf Vorlaufzeiten/Zykluszeiten

Sie können die durchschnittlichen Durchlaufzeiten und Standardabweichungen verwenden, um die Lieferzeiten zu schätzen.

Wenn Sie ein Arbeitselement erstellen, können Sie die durchschnittliche Durchlaufzeit Ihres Teams verwenden, um abzuschätzen, wann Ihr Team dieses Arbeitselement abschließen wird. Die Standardabweichung Ihres Teams gibt Ihnen die Variabilität der Schätzung an. Ebenso können Sie die Zykluszeit und deren Standardabweichung verwenden, um den Abschluss eines Arbeitselements zu schätzen, nachdem die Arbeit begonnen hat.

Im folgenden Diagramm beträgt die durchschnittliche Zykluszeit acht Tage. Die Standardabweichung beträgt +/- sechs Tage. Mithilfe dieser Daten können wir schätzen, dass das Team zukünftige Benutzergeschichten etwa 2-14 Tage nach Beginn der Arbeit abschließen wird. Je schmaler die Standardabweichung ist, desto besser sind Ihre Schätzungen vorhersagbar.

Beispiel für Zykluszeitwidget

Zykluszeitwidget

Identifizieren von Prozessproblemen

Überprüfen Sie das Kontrolldiagramm Ihres Teams auf Ausreißer. Ausreißer stellen häufig ein zugrunde liegendes Prozessproblem dar. Beispielsweise zu lange warten, um PR-Überprüfungen abzuschließen oder eine externe Abhängigkeit nicht schnell aufzulö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 dauerten, 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-Widget "Zykluszeit" mit mehreren Ausreißern

Zykluszeitwidget mit mehreren Ausreißern

Sie können auch sehen, wie sich Prozessänderungen auf Ihre Vor- und Zykluszeit auswirken. Am 15. Mai unternahm das Team beispielsweise einen konzertierten Versuch, das WIP zu begrenzen und veraltete Fehler zu beheben. Sie können sehen, dass sich die Standardabweichung nach diesem Datum verringert, was eine verbesserte Vorhersagbarkeit zeigt.

Nächste Schritte