Informationen zu Workflowzuständen in Backlogs und Boards

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Workflows sind von zentraler Bedeutung dafür, wie Azure Boards Arbeitselemente nachverfolgt. Jeder Arbeitsaufgabentyp verfügt über einen eigenen Workflow, der Zustände, Übergänge und Gründe definiert. Übergänge verschieben Arbeitsaufgaben vorwärts und rückwärts zwischen Zuständen. Wenn Sie einen benutzerdefinierten Zustand hinzufügen, fügt Azure DevOps standardübergänge basierend auf Prozessregeln hinzu.

Azure Boards verwendet Statuskategorien, um das Workflowverhalten konsistent in Backlogs, Boards und Widgets anzuwenden. In diesem Artikel wird erläutert, wie Zustände Kategorien zugeordnet werden und wie sich diese Zuordnung auf die Sichtbarkeit von Elementen, Boardspalten und das Berichtsverhalten auswirkt.

Workflow-Zustände

Workflowzustände definieren, wie eine Arbeitsaufgabe von der Erstellung zum Schließen verschoben wird. Im Agile-Prozess bewegt sich eine Benutzergeschichte in der Regel durch "Neu", "Aktiv", "Gelöst" und "Geschlossen". Verwenden Sie den Status "Entfernt", um eine Arbeitsaufgabe aus dem Backlog zu entfernen. Weitere Informationen finden Sie unter Verschieben, Ändern oder Löschen von Arbeitselementen.

Das folgende Diagramm zeigt die typischen Progressions- und Regressionspfade für allgemeine Arbeitsaufgabentypen: User Story (Agile), Problem (Basic), Product Backlog Item (Scrum) und Anforderung (CMMI).

Workflow-Zustände: User Story, Agile Prozess

Diagramm, das die Zustände des User Story-Workflows für den Agile-Prozess zeigt.

Kategoriezustände

Statuskategorien standardisieren, wie agile Planungstools und Dashboard-Widgets Workflowzustände interpretieren. Teams zuordnen Workflowzustände zu diesen Kategoriezuständen: Vorgeschlagen, In Bearbeitung, Aufgelöst und Abgeschlossen.

Die folgende Tabelle zeigt, wie standardmäßig geerbte Zustände den Kategoriezuständen in den vier Systemprozessen zugeordnet sind, einschließlich der Arbeitselementtypen des Testplans. Testfall-, Testdesign- und Test Suite-Workflows verwenden die gleichen Zuordnungen in allen vier Prozessen.

Categories

Arbeitsnachverfolgung

Testverfolgung

Vorgeschlagen: Verwenden Sie diese Kategorie für neu hinzugefügte Arbeitsaufgabenzustände. Elemente werden im Backlog angezeigt und die erste Spalte auf Boards und Taskboards ist "Vorgeschlagen" zugeordnet.

New

Entwurf (Testfall)

In Bearbeitung: Verwenden Sie diese Kategorie für aktive Arbeitszustände. Elemente erscheinen im Backlog (sofern sie nicht ausgeblendet sind) und werden den mittleren Boardspalten zugeordnet.

Aktiv (Fehler, Epic, Feature, User Story)

Aktiv (Testplan); In Planung (Testsuite); In Bearbeitung (Testsuite); Bereit (Testfall)

Behoben: Verwenden Sie diese Kategorie für Zustände, in denen eine Lösung implementiert, aber noch nicht überprüft wird (häufig für Fehler). Erledigte Elemente erscheinen standardmäßig im Backlog, können in Burndown-Diagrammen berücksichtigt werden und verhalten sich in vielen Tools wie „In Progress“.

Behoben (Fehler)

n/a

Abgeschlossen: Verwenden Sie diese Kategorie für abgeschlossene Arbeitszustände. Elemente werden nicht im Backlog angezeigt und werden der letzten Boardspalte zugeordnet. Jeder Arbeitsaufgabentyp kann nur einen Zustand dieser Kategorie zugeordnet haben.

Geschlossen (Fehler, Epic, Feature, User Story)

Geschlossen (Testfall); Abgeschlossen (Test Suite); Inaktiv (Testplan)

Entfernt: Verwenden Sie diese Kategorie mit dem Status "Entfernt", um Elemente aus dem Backlog- und Board-Erlebnis auszublenden.

Entfernt (Epic, Feature, User Story)

n/a

Wo Arbeitsaufgabentypen angezeigt werden

Verwenden Sie die folgende Tabelle als schnelle Referenz dafür, wo die einzelnen Kategorien von Arbeitselementtypen angezeigt werden.

Kategorie des Arbeitselementtyps Erscheint auf
Requirement Nur Produktboard
Feature Nur Feature-Portfolio-Board
Epic Nur Epic-Portfolio-Board
Custom Nur benutzerdefiniertes Portfolioboard

Tip

Ordnen Sie jeden Workflowstatus einer Tafelspalte zu. Wenn ein Zustand nicht zugeordnet ist, erscheint er nicht auf dem Board.

Note

  • Backlogs und Boards blenden abgeschlossene oder geschlossene Arbeitsaufgaben aus, wenn ihr Geändertes Datum älter als 183 Tage (etwa sechs Monate) ist.
  • Suchen Sie ausgeblendete Elemente, indem Sie eine Abfrage ausführen.
  • Zeigen Sie ein Element erneut in einem Backlog oder Board an, indem Sie ein kleineres Update vornehmen, um das geänderte Datum zu aktualisieren.

Note

  • Backlogs und Boards blenden abgeschlossene oder geschlossene Arbeitsaufgaben aus, wenn ihr Geändertes Datum älter als ein Jahr ist.
  • Suchen Sie ausgeblendete Elemente, indem Sie eine Abfrage ausführen.
  • Zeigen Sie ein Element erneut in einem Backlog oder Board an, indem Sie ein kleineres Update vornehmen, um das geänderte Datum zu aktualisieren.

Felder „Aktiviert von“/„Aktivierungsdatum“ und „Gelöst von“/„Lösungsdatum“

Das System aktualisiert diese Felder – Aktiviert von, Aktivierungsdatum, Gelöst von und Gelöst am – auf Grundlage von Statusänderungen der Workflowkategorie:

  • Wenn sich der Workflowstatus in die Kategorie "In Bearbeitung" ändert, aktualisiert das System Aktiviert von und Aktiviert am.
  • Wenn sich der Workflowstatus in die Kategorie Aufgelöst ändert, aktualisiert das System Aufgelöst durch und Auflösungsdatum.

Weitere Informationen dazu, wie Workflowzustände den Zustandskategorien zugeordnet werden, finden Sie unter Wie Workflowzustände und Zustandskategorien in Backlogs und Boards verwendet werden.

Note

Diese Logik gilt für Azure DevOps Services, Azure DevOps Server 2020.1 Update und höhere Versionen.

Da diese Felder auf Workflowstatuskategorien verweisen, lösen alle benutzerdefinierten Workflowzustände, die Sie hinzufügen, auch Feldaktualisierungen aus. Weitere Informationen finden Sie unter Anpassen des Workflows für einen Prozess.

Zusätzliche Hinweise

  • Die Felder werden aktualisiert, wenn ein Arbeitselement von einem Kategoriestatus zu einem anderen wechselt, der nicht der festgelegte ist. Wenn Sie z. B. eine Arbeitsaufgabe von "Neu " in "Behoben" verschieben, werden die Felder " Aufgelöst nach"/"Aufgelöst am" aktualisiert. Wenn Sie von "Fixed " zu " Ready for Testing" wechseln – die sich im selben Kategoriezustand befinden – werden die Felder "Gelöst nach"/"Gelöst am " nicht aktualisiert.
  • Wenn Sie rückwärts wechseln, z. B. von einem aufgelösten in einen aktiven Zustand, löscht das System die Felder "Aufgelöst nach/Aufgelöst am" . Wenn Sie von Aktiv zu Neu wechseln, löscht das System die Felder Aktiviert von/Aktiviert am.
  • Ändern Sie diese Feldwerte nicht manuell. Bei diesen Feldern handelt es sich um Systemfelder, die von Systemregeln gesteuert werden, und Azure DevOps alle manuellen Werte überschreibt.

Wann sollte ein Status im Vergleich zu einer Spalte hinzugefügt werden?

Verwenden Sie Zustände und Spalten zusammen, um den Arbeitsstatus nachzuverfolgen, verwenden Sie jedoch jede(n) für einen anderen Bereich:

  • Zustand: Workflow-Logik auf Projektebene, die teamübergreifend genutzt wird.
  • Spalte: Board-Visualisierung auf Team-Ebene.

Benutzer mit Prozessbearbeitungsberechtigungen (in der Regel Project Sammlungsadministratoren oder delegierte Prozess-Editoren) können benutzerdefinierte Zustände hinzufügen. Teamadministratoren und Projektadministratoren können Board-Spalten hinzufügen.

Fügen Sie benutzerdefinierte Zustände hinzu, wenn Teams eine gemeinsame Workflow-Definition für Abfragen, Berichte und teamübergreifende Einheitlichkeit benötigen. Benutzerdefinierte Zustände werden an Arbeitsaufgabentypen weitergegeben, die auf den Prozess verweisen.

Hinzufügen oder Anpassen von Spalten, wenn ein Team eine boardspezifische Ansicht der Arbeit benötigt, ohne den freigegebenen Workflow zu ändern.

Um Verwirrung zu vermeiden, sollten Sie die Zuständigkeit für Arbeitselemente auf die Bereichspfade des Teams abstimmen oder gemeinsame Workflows mit benutzerdefinierten Zuständen standardisieren, wenn mehrere Teams demselben Prozess folgen.

Arbeitselemente mit Pull Requests automatisch abschließen

Wenn Sie eine Arbeitsaufgabe mit einer Pullanforderung (PR) verknüpfen, kann Azure DevOps die verknüpfte Arbeitsaufgabe automatisch abschließen, wenn die PR abgeschlossen ist. Weitere Informationen finden Sie unter Automatisches Abschließen von Arbeitselementen mit Pull Requests.

Statusübergänge von Arbeitselementen automatisieren

Azure DevOps kann den Status eines übergeordneten Arbeitselements basierend auf dem Status seiner untergeordneten Aufgaben automatisch aktualisieren. Ausführliche Informationen finden Sie unter Automatisieren von Übergängen des Arbeitsaufgabenstatus.

Verwandte Inhalte

Vererbungsprozess-Modell

Lokales XML-Prozessmodell

Dashboard-Widgets

  • Last updated on