Ändern des Workflows für einen Arbeitsaufgabentyp

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

Sie können den Workflow für einen Arbeitselementtyp (WIT) ändern, um Ihre Geschäfts- und Teamprozesse zu unterstützen. WITs unterstützen die Nachverfolgung aller Arten von Arbeiten – Anforderungen, Aufgaben, Codefehler – zur Unterstützung der Softwareentwicklung.

Der Workflow ermittelt die logische Progression und Regression der Arbeit, die die Teammitglieder durchführen. Er gibt zudem die Werte an, die in den Dropdownmenüs für die Felder "Zustand" und "Grund" angezeigt werden. Weitere Informationen finden Sie unter Informationen zu Prozessen und Prozessvorlagen.

Workflow für Product Backlog Item (Scrum-Prozessvorlage)

Workflow für Produktbacklogelemente, Scrum-Prozess

Hinweis

In diesem Artikel wird beschrieben, wie Sie einen Workflowstatus anpassen. Wenn Sie stattdessen den Zustand ändern möchten, der einem bestimmten Arbeitselement zugewiesen ist, lesen Sie einen der folgenden Artikel: Kanban-Board, Nachverfolgen der laufenden Arbeit oder Taskboard, Aufgabe aktualisieren status. Sie können auch eine Massenaktualisierung des Zustands für viele Arbeitselemente durchführen.

Informationen zu Buildpipelineworkflows finden Sie unter Erste Schritte mit CI/CD.

Aktualisieren der XML-Definition für einen Arbeitselementtyp

Beachten Sie Folgendes, wenn Sie noch nicht mit der WIT-Anpassung sind:

Führen Sie zum Anpassen des Workflows die folgenden beiden Schritte aus:

  1. Ändern Sie den WORKFLOW Abschnitt der WIT-Definition wie in diesem Thema beschrieben.

  2. Ändern Sie die Prozesskonfiguration, um metastates neue Workflowzustände zuzuordnen.

    Dieser zweite Schritt ist erforderlich, wenn Sie den Workflow für einen WIT ändern, der auf einer Agile-Toolseite angezeigt wird. Diese WITs gehören den Anforderungs- und Aufgabenkategorien an. Weitere Informationen zu Zustandskategorien finden Sie unter Workflowzustände und Zustandskategorien.

Workflow-Entwurfsanleitungen

Sie definieren den Workflow, indem Sie zuerst die Zustände und die gültigen Übergänge zwischen diesen identifizieren. Der WORKFLOW Abschnitt der WIT-Definition gibt die gültigen Zustände, Übergänge, Gründe für die Übergänge und optionale Aktionen an, die ausgeführt werden, wenn ein Teammitglied den Status eines Arbeitselements ändert.

Im Allgemeinen verknüpfen Sie jeden Zustand mit einer Teammitgliederrolle und einer Aufgabe, die eine Person in dieser Rolle zum Verarbeiten des Arbeitselements ausführen muss, bevor der Zustand geändert werden kann. Durch Übergänge werden die gültigen Fortschritte und Regressionen zwischen Zuständen definiert. Anhand von Gründen wird angegeben, warum ein Teammitglied ein Arbeitselement von einem Zustand in einen anderen ändert, und durch Aktionen wird die Automatisierung des Übergangs eines Arbeitselements an einem Punkt im Workflow unterstützt.

Der Status wird beispielsweise auf Neu festgelegt, wenn ein Tester einen neuen Fehler öffnet, der auf dem Agile-Standardprozess basiert. Der Entwickler ändert den Status beim Beheben des Fehlers in Aktiv . Nach dem Beheben des Fehlers ändert der Entwickler seinen Status in Aufgelöst und legt den Wert des Felds Grund auf Behoben fest. Nach dem Überprüfen des Fixs ändert der Tester den Status des Fehlers in Geschlossen , und das Feld Grund ändert sich in Überprüft. Wenn der Tester festgestellt hat, dass der Entwickler den Fehler nicht behoben hat, ändert der Tester den Status des Fehlers in Aktiv und gibt den Grund als Nicht behoben oder Fehler beim Testen an.

Beachten Sie beim Entwerfen oder Ändern eines Workflows die folgenden Richtlinien:

  • Verwenden Sie das STATE -Element, um einen eindeutigen Zustand für jede Teammitgliedrolle zu definieren, die eine bestimmte Aktion für ein Arbeitselement ausgibt. Je mehr Zustände Sie definieren, desto mehr Übergänge müssen Sie definieren. Unabhängig von der Reihenfolge, in der Sie die Zustände definieren, werden sie im Dropdownmenü für das Feld Zustand in alphanumerischer Reihenfolge aufgeführt.

    Wenn Sie einem Arbeitselementtyp, der auf den Backlog- oder Boardseiten im Webportal angezeigt wird, einen Zustand hinzufügen, müssen Sie den Zustand auch einer Statuskategorie zuordnen. Weitere Informationen finden Sie unter Workflowzustände und Statuskategorien.

  • Verwenden Sie das TRANSITION -Element, um einen Übergang für jede gültige Progression und Regression von einem Zustand in einen anderen zu definieren.

    Sie müssen mindestens einen Übergang für jeden Zustand sowie den Übergang vom Zustand NULL in den Ausgangszustand definieren.

    Sie können nur einen Übergang vom nicht zugewiesen Zustand (NULL) in den Anfangszustand definieren. Wenn Sie ein neues Arbeitselement speichern, wird diese automatisch dem Anfangszustand zugewiesen.

    Wenn ein Teammitglied den Zustand eines Arbeitselements ändert, werden dadurch der Übergang und die von Ihnen definierten Aktionen ausgelöst, die für den ausgewählten Zustand und den Übergang ausgeführt werden sollen. Benutzer können nur solche Zustände angeben, die auf Grundlage der Übergänge, die Sie für den aktuellen Zustand definieren, gültig sind. Darüber hinaus kann ein ACTION Element, das ein untergeordnetes Element von TRANSITIONist, den Zustand eines Arbeitselements ändern.

  • Für jeden Übergang definieren Sie mithilfe des DEFAULTREASON -Elements einen Standardgrund. Sie können beliebig viele optionale Gründe definieren, indem Sie das REASON -Element verwenden. Diese Werte werden im Dropdownmenü des Felds Grund angezeigt.

  • Sie können Regeln angeben, die angewendet werden, wenn sich der Zustand des Arbeitselements ändert, den Zustand wechselt oder wenn ein Benutzer einen bestimmten Grund auswählt. Viele dieser Regeln ergänzen die bedingten Regeln, die Sie anwenden können, wenn Sie die Felder im FIELDS Abschnitt unter der WORKITEMTYPE Definition definieren. Weitere Informationen finden Sie unter Aktualisieren von Feldern während einer Workflowänderung weiter unten in diesem Thema.

  • Bei den Namen, die Sie Zuständen und Gründen zuweisen, wird die Groß-/Kleinschreibung nicht beachtet.

    In den Dropdownmenüs für die Felder Zustand und Grund im Arbeitselementformular oder Abfrage-Editor werden die im Abschnitt des WORKFLOW Arbeitselementtyps zugewiesenen Werte angezeigt.

Workflowdiagramm und Codebeispiel

Das folgende Codebeispiel zeigt die für die WORKFLOW Bug WIT-Definition für die Agile-Prozessvorlage. In diesem Beispiel werden drei Zustände und fünf Übergänge definiert. Die STATE -Elemente geben die Status "Aktiv", "Aufgelöst" und "Geschlossen" an. Außer einer werden alle möglichen Kombinationen für Fortschritts- und Regressionsübergänge für die drei Zustände definiert. Der Übergang von Geschlossen in Gelöst wird nicht definiert. Daher können Teammitglieder keine Arbeitsaufgabe dieses Typs auflösen, wenn die Arbeitsaufgabe geschlossen ist.

In diesem Beispiel werden nicht alle Elemente für DEFAULTREASON, , REASONund ACTIONFIELDaufgelistet.

Beispieldiagramm zum Workflowzustand – Agile Bug WIT

Fehlerworkflowzustände, agile Prozessvorlage

<WORKFLOW>
 <STATES>
    <STATE value="Active">
      <FIELDS> . . . </FIELDS>
    </STATE>
    <STATE value="Resolved">
     <FIELDS> . . . </FIELDS>
    </STATE>
    <STATE value="Closed">
     <FIELDS> . . . </FIELDS>
    </STATE>
 </STATES>
 <TRANSITIONS>
    <TRANSITION from="" to="Active">
       <REASONS>
          <REASON value="Build Failure" />
           <DEFAULTREASON value="New" />
       </REASONS>
       <FIELDS> . . . </FIELDS>
    </TRANSITION>
    <TRANSITION from="Active" to="Resolved">
     <ACTIONS> . . . </ACTIONS>
     <REASONS> . . . </REASONS>
    </TRANSITION>
    <TRANSITION from="Resolved" to="Active">
       <REASONS> . . . </REASONS>
    </TRANSITION>
    <TRANSITION from="Resolved" to="Closed">
       <REASONS>
          <DEFAULTREASON value="Verified" />
       </REASONS>
     <FIELDS> . . . </FIELDS>
    </TRANSITION>
    <TRANSITION from="Closed" to="Active">
       <REASONS>
          <REASON value="Reactivated" />
          <DEFAULTREASON value="Regression" />
       </REASONS>
     <FIELDS> . . . </FIELDS>
    </TRANSITION>
 </TRANSITIONS>
 </WORKFLOW>

Ermitteln Sie die Anzahl und Typen der Zustände

Sie bestimmen die Anzahl und Typen der gültigen Zustände auf Grundlage der Anzahl unterschiedlicher logischer Zustände, in der die Arbeitselemente dieses Typs vorhanden sein sollen. Wenn außerdem verschiedene Teammitglieder unterschiedliche Aktionen ausführen, sollten Sie eventuell auch einen Zustand auf Grundlage einer Mitgliederrolle definieren. Jeder Zustand entspricht einer Aktion, die ein Teammitglied für das Arbeitselement ausführen muss, damit der nächste Zustand erreicht wird. Für jeden Zustand sollten Sie die spezifischen Aktionen sowie die Teammitglieder, die diese Aktionen durchführen dürfen, definieren.

Die folgende Tabelle enthält ein Beispiel für vier Zustände, die definiert werden, um den Status einer Funktion und die gültigen Benutzer zu verfolgen, die die angegebenen Aktionen ausführen müssen:

State Gültiger Benutzer Auszuführende Aktion
Proposed Projektmanager Jeder kann ein Funktionsarbeitselement erstellen. Allerdings kann das Arbeitselement nur von Projektmanagern genehmigt oder abgelehnt werden. Wenn ein Projektmanager eine Funktion genehmigt, ändert er den Status der Arbeitsaufgabe in Aktiv. Andernfalls wird sie von einem Teammitglied geschlossen.
Aktiv Entwicklungsleiter Der Entwicklungsleiter beaufsichtigt die Entwicklung der Funktion. Wenn die Funktion abgeschlossen ist, ändert der Entwicklungsleiter den Status des Funktionsarbeitselements in Prüfen.
Überprüfung Projektmanager Der Projektmanager überprüft die Funktion, die vom Team implementiert wurde, und ändert den Status der Arbeitsaufgabe in Geschlossen, wenn die Implementierung zufriedenstellend ist.
Geschlossen Projektmanager Für geschlossene Arbeitselemente wird keine zusätzliche Aktion mehr erwartet. Diese Elemente verbleiben zu Archivierungs- und Berichtszwecken in der Datenbank.

Hinweis

Alle Zustände werden in der Liste auf dem Formular für ein Arbeitselement eines bestimmten Typs in alphabetischer Reihenfolge angezeigt, unabhängig von der Reihenfolge, in der Sie diese angeben.

Definieren von Übergängen

Wenn Sie die gültigen Zustandsfortschritte und -regressionen definieren, steuern Sie die Zustände, in die und von denen Teammitglieder ein Arbeitselement ändern können. Wenn Sie keinen Übergang von einem Zustand in einen anderen definieren, können Teammitglieder ein Arbeitselement eines bestimmten Typs nicht von einem bestimmten Zustand in einem anderen bestimmten Zustand ändern.

In der folgenden Tabelle sind die gültigen Übergänge für jeden der vier Zustände definiert, die weiter oben in diesem Thema beschrieben wurden, zusammen mit dem jeweiligen Standardgrund.

State Übergang in Zustand Standardgrund
Proposed Aktiv (Fortschritt) Genehmigt für Entwicklung
Geschlossen (Fortschritt) Nicht genehmigt
Aktiv Prüfen (Fortschritt) Akzeptanzkriterien erfüllt
Überprüfung Geschlossen (Fortschritt) Funktion abgeschlossen
Aktiv (Regression) Erfüllt die Anforderungen nicht
Geschlossen Vorgeschlagen (Regression) Genehmigung erneut prüfen
Aktiv (Regression) Versehentlich geschlossen

Sie können einschränken, wer einen Übergang von einem Zustand zu einem anderen vornehmen darf, indem Sie die Attribute for und nicht das TRANSITION -Element verwenden. Wie im folgenden Beispiel veranschaulicht, können Tester einen Fehler erneut öffnen, Entwickler jedoch nicht.

<TRANSITION from="Closed" to="Active"  
   for="[Project]\Testers"  
   not="[Project]\Developers">  
   . . .  
</TRANSITION>  

Angeben von Gründen

Wenn ein Teammitglied das Feld Zustand ändert, kann dieser Benutzer den Standardgrund für diesen Übergang übernehmen oder einen anderen Grund angeben, wenn Sie zusätzliche Optionen definieren. Sie müssen das DEFAULTREASON -Element verwenden, um nur einen Standardgrund anzugeben. Zusätzliche Gründe sollten Sie nur dann angeben, wenn diese das Team beim Nachverfolgen von Daten oder bei der Berichterstellung unterstützen.

Ein Entwickler kann z. B. in Bezug auf die Fehlerbehebung einen der folgenden Gründe angeben: Korrigiert (Standard), Verzögert, Doppelt, Wie entwickelt, Nicht reproduzierbar oder Veraltet. Jeder Grund gibt eine bestimmte Aktion an, die der Tester hinsichtlich des Fehlers ausführen soll.

Hinweis

Alle Gründe werden in der Liste auf dem Arbeitsformular für Arbeitselemente eines bestimmten Typs in alphabetischer Reihenfolge angezeigt, unabhängig von der Reihenfolge, in der Sie die REASON Elemente angeben.

Das folgende Beispiel zeigt die Elemente, mit denen die Gründe definiert werden, warum ein Mitglied des Teams einen Fehler beheben könnte:

<TRANSITION from="Active" to="Resolved">  
      . . .  
      <REASONS>  
      <DEFAULTREASON value="Fixed"/>  
      <REASON value="Deferred"/>  
      <REASON value="Duplicate"/>  
      <REASON value="As Designed"/>  
      <REASON value="Unable to Reproduce"/>  
      <REASON value="Obsolete"/>  
      </REASONS>  
      . . .  
</TRANSITION>  

Angeben von Aktionen

Im Allgemeinen ändern Teammitglieder den Status eines Arbeitselements, indem sie einen anderen Wert für das Feld State angeben und dann das Arbeitselement speichern. Sie können jedoch auch ein ACTION Element definieren, das den Zustand eines Arbeitselements automatisch ändert, wenn dieser Übergang eintritt. Wie das folgende Beispiel zeigt, können Sie angeben, dass Fehlerarbeitselemente automatisch aufgelöst werden sollen, wenn sie Dateien zugeordnet sind, die ein Entwickler in die Versionskontrolle eincheckt:

<TRANSITION from="Active" to="Resolved">  
      <ACTIONS>  
      <ACTION value="Microsoft.VSTS.Actions.Checkin"/>  
      </ACTIONS>  
. . .  
</TRANSITION>  

Sie können das ACTION -Element verwenden, um den Status von Arbeitselementen eines bestimmten Typs automatisch zu ändern, wenn Ereignisse an anderer Stelle in der Microsoft Visual Studio Application Lifecycle Management oder außerhalb der Visual Studio Application Lifecycle Management auftreten (z. B. über ein Tool, das Aufrufe nachverfolgt). Weitere Informationen finden Sie unter ACTION.

Aktualisieren eines Felds während einer Workflowänderung

Sie können Regeln definieren, mit denen Felder immer dann aktualisiert werden, wenn die folgenden Ereignisse auftreten:

  • Weisen Sie unter eine Feldregel zu STATE , wenn die Regel für alle Übergänge und Gründe für die Eingabe dieses Zustands gelten soll.

  • Weisen Sie eine Feldregel unter TRANSITION zu, wenn die Regel für diesen Übergang gelten soll, und alle Gründe für diesen Übergang.

  • Weisen Sie eine Feldregel unter DEFAULTREASON oder REASON zu, wenn die Regeln nur aus diesem bestimmten Grund angewendet werden sollen.

    Wenn ein Feld immer denselben Wert enthalten soll, definieren Sie die Regel unter dem FIELD Element, das dieses Feld definiert. Weitere Informationen zur Regelverwendung finden Sie unter Regeln und Regelauswertung.

    Sie sollten möglichst wenige Bedingungen für die einzelnen Arbeitselementtypen definieren. Mit jeder bedingten Regel, die Sie hinzufügen, wird der Validierungsprozess beim Speichern einer Arbeitsaufgabe durch ein Teammitglied komplexer. Komplexe Regelsätze verlängern möglicherweise den Zeitraum, der zum Speichern des Arbeitselements erforderlich ist.

    In den folgenden Beispielen werden einige der Regeln gezeigt, die in der Prozessvorlage für MSF Agile Software Development auf Systemfelder angewendet werden.

Ändern des Werts eines Felds, wenn der Zustand geändert wird

Wenn der Wert des Felds Status für ein Arbeitselement auf Aktiv festgelegt ist und das Arbeitselement gespeichert wird, werden die Werte der Felder Aktiviert von und Zugewiesen an automatisch auf den Namen des aktuellen Benutzers festgelegt. Dieser Benutzer muss Mitglied der Team Foundation Server-Gruppe Gültige Benutzer sein. Der Wert des Felds Aktiviertes Datum wird ebenfalls automatisch festgelegt. Das folgende Beispiel zeigt die Elemente, die diese Regel erzwingen:

<STATE value="Active">  
<FIELDS>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedBy">  
      <COPY from="currentuser"/>  
      <VALIDUSER/>  
      <REQUIRED/>  
      </FIELD>  
      <FIELD refname="Microsoft.VSTS.Common.ActivatedDate">  
      <SERVERDEFAULT from="clock"/></FIELD>  
      <FIELD refname="System.AssignedTo">  
      <DEFAULT from="currentuser"/>  
      </FIELD>  
. . .  
</FIELDS>  
</STATE>  

Löschen des Wert eines Felds, wenn sich der Wert eines anderen Felds ändert

Wenn der Wert des Felds Status für ein Arbeitselement auf Aktiv festgelegt ist und das Arbeitselement gespeichert wird, werden die Felder Geschlossener Termin und Geschlossen von automatisch auf NULL festgelegt und als schreibgeschützt festgelegt, wenn Sie das EMPTY Element verwenden, wie im folgenden Beispiel gezeigt.

<STATE value="Active">  
      <FIELDS>  
. . .  
      <FIELD refname="Microsoft.VSTS.Common.ClosedDate"><EMPTY/></FIELD>  
      <FIELD refname="Microsoft.VSTS.Common.ClosedBy"><EMPTY/></FIELD>  
      </FIELDS>  
</STATE>  

Definieren eines Felds auf der Grundlage des Inhalts eines anderen Felds

Wenn sich der Wert des Felds Status für ein Arbeitselement in Aufgelöst ändert und das Arbeitselement gespeichert wird, wird der Wert des Felds Aufgelöster Grund auf den Wert festgelegt, den der Benutzer im Feld Grund angegeben hat. Das folgende Beispiel zeigt die Elemente, die diese Regel erzwingen:

<STATE value="Resolved">  
      <FIELDS>  
. . .  
      <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">  
         <COPY from="field" field="System.Reason"/>  
      </FIELD>  
      </FIELDS>  
</STATE>  

Toolunterstützung

Sie können Ihre Benutzer bei der Visualisierung des Workflows unterstützen, indem Sie die Erweiterung Zustandsmodellvisualisierung aus dem Visual Studio Marketplace installieren.