Informationen zu Workflowzuständen in Backlogs und Boards

  • Artikel

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

Alle Workflows bestehen aus Status, Übergängen und Gründen. Workflows werden für einen Arbeitselementtyp definiert. Ein Übergang unterstützt die Vorwärts- und Rückwärtsbewegung zwischen zwei Status. Wenn Sie einen benutzerdefinierten Status hinzufügen, fügt das System Übergänge vom benutzerdefinierten Status zu allen anderen geerbten Status (mit Ausnahme von „Entfernt“) automatisch hinzu.

Jeder Status gehört zu einer Statuskategorie (zuvor als „Metastatus“ bezeichnet). Statuskategorien unterstützen das Backlog und die Boardansichten des Agile-Tools.

Workflowzustände

Workflowstatus definieren, wie ein Arbeitselement von seiner Erstellung bis zum Abschluss fortschreitet. Die vier für die User Story (Agile-Prozess) definierten Standardstatus beschreiben den Fortschritt einer User Story. Die Workflowstatus sind „Neu“, „Aktiv“, „Gelöst“ und „Geschlossen“. (Der Status „Entfernt“ unterstützt das Entfernen eines Arbeitselements aus der Anzeige im Backlog. Weitere Informationen finden Sie unter Verschieben, Ändern oder Löschen von Arbeitselementen.)

Die natürlichen Fortschritte und Regressionen für die Arbeitselementtypen – User Story (Agile), Issue (Basic), Product Backlog Item (Scrum) und Anforderung (CMMI) – sind wie dargestellt.

Workflowstatus: User Story, Agile-Prozess

User Story-Workflowstatus, Agile-Prozess

Kategoriestatus

Kategoriestatus bestimmen, wie Agile-Planungstools und Widgets zum Auswählen von Dashboards jeden Workflowstatus behandeln. Die von den Backlogs, Boards und Widgets verwendeten Statuskategorien sind Vorgeschlagen, In Bearbeitung, Gelöst und Abgeschlossen.

Hier erfahren Sie, wie die geerbten Standardstatus den Kategoriestatus für die vier Systemprozesse zugeordnet werden, einschließlich der Arbeitselementtypen „Testplan“. Die Workflowstatus für „Testfall“, „Testentwurf“ und „Testsammlung“ sind in allen vier Systemprozessen identisch.

Kategorien

Arbeitsüberwachung

Testnachverfolgung

Vorgeschlagen: Wird Status zugewiesen, die neu hinzugefügten Arbeitselementen zugeordnet wurden, damit sie im Backlog angezeigt werden. Die erste Spalte auf den Kanban-Boards und Taskboards wird der Statuskategorie „Vorgeschlagen“ zugeordnet.

Neu

Entwurf (Testfall)

In Bearbeitung: Wird Status zugewiesen, die aktive Arbeit darstellen. Arbeitselemente, die den dieser Kategorie zugeordneten Status zugewiesen wurden, werden im Backlog angezeigt (außer wenn Sie sie ausblenden möchten) und bilden die mittleren Spalten auf Kanban-Boards.

Aktiv (Fehler, Epic, Feature, User Story)

Aktiv (Testplan), In Planung (Testsammlung), In Bearbeitung (Testsammlung), Bereit (Testfall)

Gelöst: Status zugewiesen, die eine Lösung darstellen – wurden implementiert, aber noch nicht überprüft. Normalerweise gelten diese Status für Fehler. Arbeitselemente im Kategoriestatus Gelöst werden standardmäßig im Backlog angezeigt. Die Agile-Tools behandeln den Kategoriestatus Gelöst genauso wie den Kategoriestatus In Bearbeitung.

Gelöst (Fehler)

–

Abgeschlossen: Wird Status zugewiesen, die abgeschlossene Arbeit darstellen. Arbeitselemente, deren Status in dieser Kategorie enthalten ist, werden im Backlog nicht angezeigt, aber in der letzten Spalte des Kanban-Boards angezeigt. Sie können in dieser Kategorie keine Status ändern und ihr auch keine Status hinzufügen.

Geschlossen (Fehler, Epic, Feature, User Story)

Geschlossen (Testfall), Abgeschlossen (Testsammlung), Inaktiv (Testplan)

Entfernt: Wird dem Status „Entfernt“ zugewiesen. Arbeitselemente in einem Status, der der Kategorie „Entfernt“ zugeordnet wurde, werden in den Backlog- und Boardfunktionen ausgeblendet.

Entfernt (Epic, Feature, User Story)

–

Hinweis

Abgeschlossene oder geschlossene Arbeitselemente werden in den Backlogs und auf den Boards nicht angezeigt, sobald deren Änderungsdatum mehr als 183 Tage (ungefähr ein halbes Jahr) zurückliegt. Sie können diese Elemente weiterhin mithilfe einer Abfrage auflisten. Wenn Sie möchten, dass sie in einem Backlog oder auf einem Board angezeigt werden, können Sie eine geringfügige Änderung an ihnen vornehmen, um die Uhr zurückzusetzen.

Hinweis

Abgeschlossene oder geschlossene Arbeitselemente werden in den Backlogs und auf den Boards nicht angezeigt, sobald deren Änderungsdatum mehr als ein Jahr zurückliegt. Sie können diese Elemente weiterhin mithilfe einer Abfrage auflisten. Wenn Sie möchten, dass sie in einem Backlog oder auf einem Board angezeigt werden, können Sie eine geringfügige Änderung an ihnen vornehmen, um die Uhr zurückzusetzen.

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

Das System aktualisiert die Felder Aktiviert von, Aktivierungsdatum, Gelöst von und Lösungsdatum, wenn basierend auf den entsprechenden Workflowkategoriezuständen eine Änderung erfolgt. Wenn sich der Workflowstatus in die Zustandskategorie In Bearbeitung ändert, werden Aktiviert von und Aktivierungsdatum aktualisiert. Wenn sich der Workflowstatus in die Zustandskategorie Gelöst ändert, werden Gelöst von und Lösungsdatum aktualisiert.

Weitere Informationen zur Zuordnung von Workflowstatus zu Statuskategorien finden Sie unter Verwenden von Workflowstatus und Statuskategorien in Backlogs und Boards.

Hinweis

Die Logik zum Steuern der hier beschriebenen Felder gilt für Azure DevOps Services, Azure DevOps Server Update 2020.1 und höhere Versionen.

Weil diese Felder auf die Workflowstatuskategorien verweisen, wird beim Aktualisieren der Felder auf die von Ihnen hinzugefügten benutzerdefinierten Workflowstatus verwiesen. Weitere Informationen zur Anpassung finden Sie unter Anpassen des Workflows für einen Prozess.

Weitere Hinweise:

  • Die Felder werden jedes Mal aktualisiert, wenn ein Arbeitselement aus einem anderen Kategoriestatus als dem festgelegten wechselt. Wenn Sie beispielsweise ein Arbeitselement von Neu in Korrigiert aktualisieren, werden die Felder Gelöst von/Lösungsdatum aktualisiert. Aber bei einer Aktualisierung von Korrigiert und Bereit für Tests – bei identischem Kategoriestatus – werden die Felder Gelöst von/Lösungsdatum nicht aktualisiert.
  • Wenn Sie zurückwechseln (z. B. vom Status Gelöst zum Status Aktiv), löscht das System die Werte für die Felder Gelöst von/Lösungsdatum. Bei einem Wechsel von Aktiv zu Neu löscht das System die Werte für die Felder Aktiviert von/Aktivierungsdatum.
  • Ändern Sie die Werte für diese Felder nicht manuell. Dies sind Systemfelder, die von Systemregeln gesteuert werden. Jeder Wert, den Sie festlegen möchten, wird überschreiben.

Wann eine Statusspalte im Vergleich zu einer Kanban-Spalte hinzugefügt werden sollte

Verwenden Sie sowohl Status- als auch Kanban-Spalten, um den Status von Arbeit nachzuverfolgen. Workflowstatus werden in einem Projekt freigegeben, während Kanban-Spalten innerhalb eines Teams freigegeben werden. Nur Projektsammlungsadministratoren können benutzerdefinierte Status hinzufügen, während Teamadministratoren Kanban-Spalten hinzufügen können.

Fügen Sie benutzerdefinierte Status hinzu, wenn alle Teams den Status entsprechend dem von der Organisation übernommenen Geschäftsworkflow nachverfolgen sollen. Durch Anpassen des Prozesses passen Sie die Projekte und Arbeitselementtypen, die darauf verweisen, automatisch an.

Durch das Hinzufügen von benutzerdefinierten Status zur Unterstützung von Workflowstatus, die mehrere Teams nachverfolgen möchten, kann die daraus resultierende Verwirrung vermieden werden, wenn verschiedene Teams Abfragen – basierend auf einer Kanban-Spalte – erstellen. Weil jedes Team die Kanban-Boardspalten und -Swimlanes anpassen kann, sind die Werte, die den auf verschiedenen Boards angezeigten Arbeitselementen zugewiesen sind, möglicherweise nicht identisch. Die primäre Umgehung bei diesem Problem besteht darin, den einzelnen Besitz von Arbeitselementen nach Teambereichspfad beizubehalten. Eine weitere Problemumgehung besteht darin, die Spalten zu formalisieren, indem benutzerdefinierte Status hinzugefügt werden, die teamübergreifend freigegeben werden können.

Automatische Vervollständigung von Arbeitselementen mit Pull Requests

Wenn Sie ein Arbeitselement mit einem Pull Request (PR) verknüpfen, können Sie diese Arbeitselemente automatisch vervollständigen lassen, wenn Sie den PR vervollständigen. Weitere Informationen finden Sie unter Automatisches Abschließen von Arbeitselementen mit Pull Requests.

Statusübergänge von Arbeitselementen automatisieren

Sie können den Status eines Arbeitselements automatisch entsprechend dem Status der untergeordneten Vorgänge aktualisieren. Weitere Informationen finden Sie unter Automatisieren von Übergängen des Arbeitsaufgabenstatus.