Ä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 Verfolgung aller Arbeitstypen – 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. Eine Übersicht über die standardbasierten Workflowzustände, die in den Standardprozessvorlagen unterstützt werden, finden Sie unter Auswählen eines Prozesses.

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

Workflow des Produktbacklogelements, Scrum-Prozess

Hinweis

In diesem Artikel wird beschrieben, wie Sie einen Workflowstatus anpassen. Wenn Sie stattdessen den Status ändern möchten, der einem bestimmten Arbeitselement zugewiesen ist, lesen Sie eine der folgenden Themen: Hinzufügen von Arbeitselementen, Aktualisieren des Arbeitsstatus,Kanban-Board, Nachverfolgen der Arbeit in Bearbeitung oder Taskboard, Vorgangsstatus aktualisieren. Sie können auch eine Massenaktualisierung des Status für viele Arbeitselemente ausführen.

Informationen zu Buildpipeline-Workflows finden Sie unter "Erste Schritte mit CI/CD".

Aktualisieren der XML-Definition für ein WIT

Wenn Sie neu bei der WIT-Anpassung sind, beachten Sie folgendes:

Führen Sie die folgenden beiden Schritte aus, um den Workflow anzupassen:

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

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

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

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 Zustand 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 Standard-Agile-Prozess basiert. Der Entwickler ändert den Status beim Beheben des Fehlers in "Aktiv", und sobald es behoben wurde, ändert der Entwickler seinen Zustand in "Aufgelöst", und legt den Wert des Felds "Grund" auf "Behoben" fest. Nach der Überprüfung des Fixs ändert der Tester den Zustand des Fehlers auf "Geschlossen ", und das Feld "Grund" wird auf "Überprüft" geändert. Wenn der Tester festgestellt hat, dass der Entwickler den Fehler nicht behoben hatte, würde der Tester den Status des Fehlers in Active ändern und den Grund als nicht behoben oder testen fehlgeschlagen angeben.

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 übernimmt. Je mehr Zustände Sie definieren, desto mehr Übergänge müssen Sie definieren. Unabhängig von der Sequenz, in der Sie die Zustände definieren, werden sie in alphanumerischer Reihenfolge im Dropdownmenü für das Feld "Status " aufgeführt.

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

  • Verwenden Sie das TRANSITION Element, um einen Übergang für jeden gültigen Fortschritt und eine Regression von einem Zustand zu einem 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 ist TRANSITION, den Zustand eines Arbeitselements ändern.

  • Für jeden Übergang definieren Sie einen Standardgrund mithilfe des DEFAULTREASON Elements. Sie können so viele optionale Gründe definieren, wie Sie möchten, 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 Abschnitt unter der FIELDSWORKITEMTYPE Definition definieren. Weitere Informationen finden Sie unter Aktualisieren von Feldern während einer Workflowänderung später in diesem Thema.

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

    Die Dropdownmenüs für die Felder "Zustand" und "Grund" im Arbeitselementformular oder Abfrage-Editor zeigen die im Abschnitt des Arbeitselementtyps zugewiesenen WORKFLOW Werte an.

Workflowdiagramm und Codebeispiel

Im folgenden Codebeispiel wird die WORKFLOW Bug WIT-Definition für die Agile-Prozessvorlage dargestellt. In diesem Beispiel werden drei Zustände und fünf Übergänge definiert. Die STATE Elemente geben die Status "Active", "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, REASONACTIONund FIELD.

Beispiel für Workflowstatusdiagramm – Agiler Fehler WIT

Fehler-Workflowzustä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 des TRANSITION Elements verwenden und nicht. 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 einen und 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 alphabetischer Reihenfolge in der Liste des Arbeitsformulars für Arbeitselemente eines bestimmten Typs 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 "Status " 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 auftritt. 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 microsoft Visual Studio Application Lifecycle Management oder außerhalb von Visual Studio Application Lifecycle Management (z. B. aus einem Tool, das Aufrufe nachverfolgt) auftreten. 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 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 , wenn die Regel für diesen Übergang und alle Gründe für diesen Übergang angewendet werden soll.

  • Weisen Sie eine Feldregel unter DEFAULTREASON oder REASON wenn die Regeln nur aus diesem bestimmten Grund gelten sollen.

    Wenn ein Feld immer denselben Wert enthalten sollte, definieren Sie die Regel unter dem FIELD Element, das dieses Feld definiert. Weitere Informationen zur Regelnutzung finden Sie unter "Regeln und Regelbewertung".

    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 Statusfelds für ein Arbeitselement auf "Aktiv" festgelegt ist und das Arbeitselement gespeichert wird, werden die Werte der Felder "Aktiviert nach" und "Zugewiesen an" automatisch auf den Namen des aktuellen Benutzers festgelegt. Dieser Benutzer muss Mitglied der Gruppe "Gültige Benutzer" der Team Foundation Server-Gruppe sein. Der Wert des Felds "Aktiviertes Datum " wird auch 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 "Geschlossenes Datum" und "Geschlossen nach" automatisch auf NULL festgelegt und schreibgeschützt gemacht, 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 der Wert des Statusfelds für ein Arbeitselement in "Aufgelöst" geändert wird 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 unterstützen, den Workflow zu visualisieren, indem Sie die Statusmodellvisualisierungserweiterung aus dem Visual Studio Marketplace installieren.