Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019
Sie können kumulierte Flussdiagramme (CFDs) verwenden, um den Arbeitsfluss über ein System zu überwachen. Die Zykluszeit und die Vorlaufzeit sind die beiden primären Metriken, die für die Nachverfolgung verwendet werden. Sie können diese Metriken aus einem CFD extrahieren.
In diesem Artikel erfahren Sie, wie Sie CFDs, Zykluszeiten und Leadzeiten verwenden können, um Probleme in Ihrem Arbeitsprozess zu identifizieren und Ihnen bei der Arbeit in Ihrem System zu helfen.
- Informationen zum Konfigurieren oder Anzeigen eines CFD finden Sie unter Anzeigen und Konfigurieren eines kumulativen Flussdiagramms.
- Informationen zum Hinzufügen eines Leadzeit- oder Zyklus-Kontrollcharts zu einem Dashboard finden Sie unter Lead Time and Cycle Time widgets.
Beispieldiagramme und primäre Metriken
Der Cfd für kontinuierlichen Fluss stellt das Diagramm bereit, das von Teams am meisten bevorzugt wird, die einem schlanken Prozess folgen.
Viele Teams kombinieren jedoch schlanke Praktiken mit Scrum oder anderen Methoden. Daher verwenden sie schlanke Praktiken innerhalb der Zeitspanne einer Iteration oder eines Sprints. In dieser Situation nimmt das Diagramm ein etwas anderes Aussehen auf. Es stellt zwei zusätzliche und sehr wertvolle Informationen bereit, wie im nächsten Diagramm gezeigt, der Festzeitraum CFD.
CFD mit kontinuierlichem Fluss
Dieser CFD für einen festen Zeitraum ist für einen abgeschlossenen Sprint vorgesehen.
Die oberste Linie stellt den Bereich für den Sprint dar. Da die Arbeit bis zum letzten Sprinttag abgeschlossen werden muss, gibt die Steigung des geschlossenen Status an, ob ein Team im Zeitplan liegt, um den Sprint zu beenden. Die einfachste Möglichkeit, diese Ansicht zu betrachten, ist ein Burnup-Diagramm.
Im Diagramm wird der erste Schritt im Prozess als obere linke Fläche dargestellt. Der letzte Schritt im Prozess wird als der untere rechte Bereich dargestellt.
CFD mit fester Dauer für einen abgeschlossenen Sprint
Diagrammmetriken
CFDs zeigen im Laufe der Zeit die Anzahl der Arbeitsaufgaben an, die nach Status oder Spalte gruppiert sind. Die beiden primären Metriken, die für die Nachverfolgung verwendet werden, sind die Zykluszeit und die Vorlaufzeit. Sie können diese Metriken aus dem Diagramm extrahieren.
Metrik
Definition
Zykluszeit1
Die Zeit, die benötigt wird, um die Arbeit durch einen einzelnen Prozess oder einen Workflow-Zustand zu bewegen. Die Länge wird vom Anfang eines Prozesses bis zum Anfang des nächsten Prozesses gemessen.
Vorlaufzeit1
Für einen kontinuierlichen Prozess: Der Zeitraum, von dem eine Anforderung gestellt wird (z. B. das Hinzufügen einer vorgeschlagenen User Story), bis diese Anforderung abgeschlossen ist (geschlossen).
Für einen Sprint- oder Festzeitprozess: Die Zeit, ab der die Arbeit an einer Anforderung beginnt, bis die Arbeit abgeschlossen ist (z. B. die Zeit vom Aktiven bis zum Zustand "Geschlossen").
Laufende Arbeit (WIP)
Die Menge der Arbeit oder anzahl der Arbeitsaufgaben, an denen aktiv gearbeitet wird.
Umfang
Die Menge der für den angegebenen Zeitraum zugesicherten Arbeit. Diese Metrik gilt nur für Prozesse mit fester Periode.
1 Das CFD-Widget, das Analysedaten und den eingebauten CFD verwendet und das Sie über einen Teamrückstand oder ein Board anzeigen können, bietet keine diskreten Werte für Lead- und Zykluszeit. Die Widgets "Lead Time" und "Zykluszeit" stellen jedoch diese Werte bereit.
Es gibt eine gut definierte Korrelation zwischen Vorlaufzeit oder Zykluszeit und WIP. Mehr WIP führt zu längeren Zykluszeiten, was zu längeren Vorlaufzeiten führt. Das Gegenteil ist auch wahr – weniger WIP führt zu kürzeren Zyklus- und Vorlaufzeiten. Wenn sich das Entwicklungsteam auf weniger Elemente konzentriert, reduzieren sie den Zyklus und die Vorlaufzeiten. Diese Korrelation ist ein wichtiger Grund, warum Sie WIP-Grenzwerte für das Board festlegen sollten, das Sie zum Nachverfolgen und Verwalten von Arbeiten verwenden.
Die Anzahl der Arbeitsaufgaben gibt die Gesamtarbeitsmenge an einem bestimmten Tag an. Bei einem CFD mit fester Periode gibt eine Änderung dieser Anzahl eine Bereichsänderung für einen bestimmten Zeitraum an. In einem Kontinuierfluss-CFD zeigt es den Gesamtbetrag der Arbeit an, die sich in der Warteschlange befindet und für einen bestimmten Tag abgeschlossen ist.
Die Kategorisierung von Arbeit in Spalten eines Boards zeigt Ihnen, wie viel Arbeit in jedem Bereich des Prozesses steckt. 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 hilft Ihnen jedoch zu verstehen, was in Ihrem Arbeitsprozess passiert und warum es passiert.
Identifizieren von Problemen und Ergreifen geeigneter Maßnahmen
Der CFD bietet Antworten auf die folgenden Fragen. Basierend auf den Antworten können Sie den Prozess anpassen, um die Arbeit durch das System zu durchlaufen.
Wird das Team rechtzeitig arbeiten?
Diese Frage gilt nur für CFDs mit fester Periode. Sie können ein Verständnis gewinnen, indem Sie die Kurve (oder den Fortschritt) der Arbeit in der letzten Spalte des Boards betrachten.
In diesem Szenario können Sie erwägen, den Umfang der Arbeit in der Iteration zu verringern. Diese Aktion ist angemessen, wenn klar ist, dass die Arbeit nicht schnell genug abgeschlossen wird, vorausgesetzt, sie wird in einem stetigen Tempo fortgesetzt. Dieses Szenario kann darauf hinweisen, dass die Arbeit unterschätzt wurde und in die Planung des nächsten Sprints eingegliedert werden sollte.
Es kann jedoch andere Gründe geben, warum die Arbeit nicht schnell genug abgeschlossen wird. Sie können diese Gründe ermitteln, indem Sie andere Daten im Diagramm betrachten.
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? Scheinen einige Spalten über einen Zeitraum von mehreren Tagen ohne Veränderung zu bleiben? Oder scheinen sie sich zu wölben?
Mura oder Ungleichheit ist der schlanke Begriff für flache Linien und Bölbe. Mura gibt eine Form von Abfällen (Muda) im System an. Jede Uneinheitlichkeit im System bewirkt, 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 des langsamsten Bereichs des Systems wird als Trommel-Puffer-Seil-Prozess bezeichnet und ist Teil der Arbeitsplanung.
Zwei Probleme werden visuell als flache Linien und als Bulges angezeigt.
Flache Linien werden angezeigt, wenn das Team den Status ihrer Arbeitsaufgaben nicht mit einem normalen Rhythmus aktualisiert. Das Board, das Sie zum Nachverfolgen und Verwalten von Arbeiten verwenden, bietet die schnellste Möglichkeit, die Arbeit von einer Spalte zu einer anderen zu wechseln.
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, weil, wenn nur ein oder zwei Teile Probleme haben, eine Auswölbung sichtbar wird.
Flache Linien
Engpässe treten auf, wenn sich die Arbeit in einem Teil des Systems staut und nicht durch den Prozess weitergeleitet wird.
Beispielsweise kann ein Engpass auftreten, wenn Tests eine lange Zeit dauern, aber die Entwicklung weniger lange dauert. Das Ergebnis ist, dass sich die Arbeit in der Entwicklungsphase ansammelt. Ausbeulungen deuten darauf hin, dass ein nachfolgender Schritt ein Problem hat, nicht unbedingt der Schritt, bei dem die Ausbeulung auftritt.
Ausbuchtungen
Wie beheben Sie Flussprobleme?
Sie können das Problem eines Mangels an rechtzeitigen Updates lösen, indem Sie die folgenden Aktionen ausführen:
- Tägliche Stand-ups halten
- Andere regelmäßige Besprechungen abhalten
- 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 wird. Zugrunde liegende Ursachen können die folgenden Probleme umfassen:
- Prozessweite Blockierungen
- Prozesse dauern lange
- Die Arbeit wechselt zu anderen Möglichkeiten, die nicht auf dem Board erfasst werden
Ein Beispiel für einen systemischen Stillstand kann bei einem CFD-Feature vorkommen. Featurearbeit kann erheblich länger dauern als die Arbeit an Benutzergeschichten, da Features aus mehreren Geschichten bestehen. In diesen Situationen wird entweder die Steigung erwartet (wie in einem früheren Beispiel), oder das Problem ist bekannt, und das Team hat es bereits ausgelöst. 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. Der geeignete Fix kann davon abhängen, wo die Bulge auftritt. Nehmen wir beispielsweise an, dass die Ausbuchtung im Entwicklungsprozess auftritt. Die Verzögerung könnte auftreten, weil die Tests wesentlich länger dauern 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.
Es gibt zwei potenziell einfache Möglichkeiten, dieses Problem zu lösen:
- Verschieben Sie Entwickler vom Entwicklungsprozess in den Testprozess, bis der Engpass beseitigt ist.
- Ändern Sie die Arbeitsreihenfolge. Insbesondere verweben Sie Arbeit, die schnell mit der Arbeit durchgeführt werden kann, die länger dauert.
Suchen Sie nach grundlegenden Lösungen, um die Wölbe zu beseitigen.
Hinweis
Da 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 kann Ihnen mitteilen, dass ein Problem besteht. Es kann Ihnen auch sagen, wo das Problem liegt, aber Sie müssen untersuchen, um zu den Ursachen zu gelangen. Diese Anleitung enthält empfohlene Aktionen, die bestimmte Probleme lösen, aber die Lösungen gelten möglicherweise nicht für Ihre Situation.
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 mit der Arbeit vorgeladen, die am ersten Tag zu erledigen ist. Änderungen an der obersten Zeile geben das Hinzufügen oder Entfernen von Arbeiten an.
In einem bestimmten Szenario können Sie Bereichsänderungen mit einem CFD nicht nachverfolgen. Dieses Szenario tritt auf, wenn die gleiche Anzahl von Arbeitsaufgaben am selben Tag hinzugefügt und entfernt wird. Die Linie bleibt in diesem Fall flach.
Führen Sie die folgenden Aktionen aus, um Bereichsänderungen in diesem Fall nachzuverfolgen:
- Vergleichen Sie mehrere Diagramme miteinander.
- Überwachen Sie bestimmte Probleme.
- Verwenden Sie sprint burndown, um Änderungen im Arbeitsumfang zu überwachen.
Gibt es zu viel WIP?
Sie können das Board ganz einfach überwachen, um festzustellen, ob WIP-Grenzwerte überschritten werden. Sie können WIP-Ebenen auch mithilfe des CFD überwachen.
Eine große Menge an WIP wird in der Regel als vertikale Bulge angezeigt. Je länger es eine große Menge an WIP gibt, desto mehr erweitert sich die Ausbeulung zu einer ovalen Form. Dieses Verhalten ist ein Hinweis darauf, dass der WIP den Zyklus und die Vorlaufzeit negativ beeinflusst.
Dies ist eine gute Faustregel für WIP: Es sollten nicht mehr als zwei Elemente pro Teammitglied zu einem bestimmten Zeitpunkt ausgeführt werden. Der Hauptgrund für die Verwendung eines Grenzwerts von zwei Elementen, nicht eine strengere Grenze, ist, dass die Realität häufig in den Softwareentwicklungsprozess eindringt.
Manchmal dauert es Zeit, Um Informationen von einem Projektbeteiligten zu erhalten oder erforderliche Software zu erwerben. Es gibt eine Reihe von Gründen, warum Arbeit angehalten werden kann. Eine zweite Arbeitsaufgabe kann etwas Spielraum bieten. 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 viele Elemente in Bearbeitung sind, kann die Person, die an diesen Elementen arbeitet, Schwierigkeiten beim Wechseln des Kontexts haben. Es ist wahrscheinlich, dass sie vergessen, was sie getan haben, was zu Fehlern führen kann.
Leadzeit im Vergleich zur Zykluszeit
Das folgende Diagramm veranschaulicht, wie sich die Leadzeit von der Zykluszeit unterscheidet. Die Durchlaufzeit beginnt, wenn ein Arbeitselement erstellt wird, und endet, wenn das Arbeitselement eine abgeschlossene Zustandkategorie erreicht. Die Zykluszeit beginnt, wenn eine Arbeitsaufgabe zuerst eine Statuskategorie "In Bearbeitung" oder "Aufgelöst" eingibt. Die Zykluszeit endet, wenn die Arbeitsaufgabe eine Statuskategorie "Abgeschlossen" eingibt.
Wenn eine Arbeitsaufgabe eine Statuskategorie "Abgeschlossen" eingibt und dann reaktiviert wird, sind die Lead- und Zykluszeiten betroffen. Jede zusätzliche Zeit, die sie in einer Statuskategorie "Vorgeschlagen", "In Arbeit" oder "Gelöst" verbringt, trägt zu den Durchlauf- und Zykluszeiten bei.
Wenn Ihr Team ein Board zum Nachverfolgen und Verwalten von Arbeiten verwendet, hilft es ihnen zu verstehen, wie Ihre Spalten Workflowzuständen zugeordnet sind. Weitere Informationen zur Konfiguration Ihres Boards finden Sie unter Spalten auf Ihrem Board verwalten.
Weitere Informationen zur Verwendung der Statuskategorien "Vorgeschlagen", "In Bearbeitung", "Gelöst" und "Abgeschlossen" finden Sie unter "Informationen zu Workflowzuständen in Backlogs und Boards".
Abschätzung der Lieferzeiten basierend auf Durchlauf- und Zykluszeiten
Sie können Ihre durchschnittliche Lead- und Zykluszeiten und Standardabweichungen verwenden, um Lieferzeiten zu schätzen.
Wenn Sie eine Arbeitsaufgabe erstellen, können Sie die durchschnittliche Vorlaufzeit Ihres Teams verwenden, um den Abschlusstermin dieser Arbeitsaufgabe zu schätzen. Die Standardabweichung Ihres Teams informiert Sie über die Variabilität der Schätzung. Ebenso können Sie die Zykluszeit und die Standardabweichung verwenden, um den Abschluss einer Arbeitsaufgabe nach Beginn der Arbeit zu schätzen.
Beispiel für Zykluszeitwidget
Im folgenden Diagramm beträgt die durchschnittliche Zykluszeit acht Tage. Die Standardabweichung beträgt sechs Tage. Anhand dieser Daten können Sie schätzen, dass das Team zukünftige Benutzergeschichten ungefähr 2 bis 14 Tage nach beginn der Arbeit abgeschlossen hat. Je schmaler die Standardabweichung ist, desto vorhersehbarer sind Ihre Schätzungen.
Identifizieren von Prozessproblemen
Ausreißer stellen häufig ein zugrunde liegendes Prozessproblem dar. Beispiele sind zu langes Warten, um Pullanforderungen zu überprüfen, oder eine externe Abhängigkeit nicht schnell genug zu lösen. Überprüfen Sie das Steuerelementdiagramm Ihres Teams auf Ausreißer.
Beispiel-Zykluszeit-Widget mit mehreren Ausreißern
Das folgende Diagramm zeigt mehrere Ausreißer, da mehrere Bugs mehr Zeit als der Durchschnitt benötigten. Die Untersuchung, warum diese Fehler länger gedauert haben, kann dazu beitragen, Prozessprobleme aufzudecken. Die Behandlung von Prozessproblemen kann dazu beitragen, die Standardabweichung Ihres Teams zu verringern und die Vorhersehbarkeit Ihres Teams zu verbessern.
Sie können auch sehen, wie sich Prozessänderungen auf Ihre Durchlauf- und Zyklusdauer 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.