Freigeben über

Ändern des Workflows für einen Arbeitsaufgabentyp

  • Artikel

Azure DevOps Server 2022 – Azure DevOps Server 2019

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

Der Workflow bestimmt die logische Entwicklung und Regression der Arbeit, die Teammitglieder ausführen. Außerdem werden die Werte angegeben, die in den Dropdownmenüs für die Felder "Status" und "Grund" angezeigt werden. Weitere Informationen finden Sie unter Informationen zu Prozessen und Prozessvorlagen.

Workflow für Produktrückstandselement (Scrum-Prozessvorlage)

Backlog-Elementworkflow für Produkt, Scrum-Prozess

Hinweis

In diesem Artikel wird beschrieben, wie Sie einen Workflowstatus anpassen. Wenn Sie stattdessen den Status ändern möchten, der einer bestimmten Arbeitsaufgabe zugewiesen ist, lesen Sie einen der folgenden Artikel: Board, Nachverfolgen der laufenden Arbeit oder Task Board, Vorgangsstatus aktualisieren. Sie können auch eine Massenaktualisierung des Zustands für viele Arbeitsaufgaben durchführen.

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

Aktualisieren der XML-Definition für einen Arbeitsaufgabentyp

Wenn Sie mit der WIT-Anpassung noch nicht angemeldet 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 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 entweder zu den Kategorien "Anforderung" oder "Vorgang". Weitere Informationen zu Statuskategorien finden Sie unter Workflowstatus und Statuskategorien.

Workflowentwurfsrichtlinien

Sie definieren den Workflow, indem Sie zuerst die Zustände und die gültigen Übergänge zwischen ihnen 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 einer Arbeitsaufgabe ändert.

Im Allgemeinen ordnen Sie jeden Zustand einer Teammitgliedsrolle und einer Aufgabe zu, die eine Person in dieser Rolle ausführen muss, um die Arbeitsaufgabe zu verarbeiten, bevor Sie den Status ändern. Übergänge definieren die gültigen Progressionen und Regressionen zwischen Zuständen. Gründe dafür, warum ein Teammitglied eine Arbeitsaufgabe von einem Zustand in einen anderen ändert, und Aktionen unterstützen die Automatisierung des Übergangs einer Arbeitsaufgabe an einem Punkt im Workflow.

Beispielsweise wird der Status auf "Neu " festgelegt, wenn ein Tester einen neuen Fehler öffnet, der auf dem standardmäßigen 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 in "Geschlossen ", und das Feld "Grund" wird in "Überprüft" geändert. Wenn der Tester festgestellt hat, dass der Entwickler den Fehler nicht behoben hatte, ändert der Tester den Status des Fehlers in "Aktiv ", und geben Sie den Grund als "Nicht behoben " oder "Test fehlgeschlagen" an.

Berücksichtigen 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 eine Arbeitsaufgabe ausführen wird. 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 "Status " in alphanumerischer Reihenfolge aufgeführt.

    Wenn Sie einen Status zu einem Arbeitsaufgabentyp hinzufügen, der auf den Backlog- oder Boardseiten im Webportal angezeigt wird, müssen Sie den Status auch einer Statuskategorie zuordnen. Weitere Informationen: Überprüfen Sie Workflowzustände und Statuskategorien.

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

    Sie müssen mindestens einen Übergang für jeden Zustand und den Übergang vom NULL-Zustand zum Anfangszustand definieren.

    Sie können nur einen Übergang von nicht zugewiesen (null) zum Anfangszustand definieren. Wenn Sie eine neue Arbeitsaufgabe speichern, wird sie automatisch dem Anfangszustand zugewiesen.

    Wenn ein Teammitglied den Status einer Arbeitsaufgabe ändert, löst diese Änderung den Übergang und die Aktionen aus, die Sie für den ausgewählten Zustand und den Übergang definieren. Benutzer können nur die Zustände angeben, die basierend auf den Übergängen gültig sind, die Sie für den aktuellen Zustand definieren. Darüber hinaus kann ein ACTION Element, bei dem es sich um ein untergeordnetes Element handelt TRANSITION, den Status einer Arbeitsaufgabe ändern.

  • Für jeden Übergang definieren Sie einen Standardgrund mithilfe des DEFAULTREASON Elements. 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 Status der Arbeitsaufgabe ändert, wenn sie übergibt 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.

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

Workflowdiagramm und Codebeispiel

Das folgende Codebeispiel zeigt 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 den Status "Aktiv", "Aufgelöst" und "Geschlossen" an. Alle möglichen Kombinationen für Progressions- und Regressionsübergänge werden für die drei Zustände definiert, mit Ausnahme einer. Der Übergang von "Geschlossen" zu "Aufgelöst" ist nicht definiert. Daher können Teammitglieder eine Arbeitsaufgabe dieses Typs nicht auflösen, wenn die Arbeitsaufgabe geschlossen ist.

In diesem Beispiel werden nicht alle Elemente für DEFAULTREASON, , REASON, ACTIONund FIELD.

Beispiel für Workflowstatusdiagramm – Agile Bug WIT

Fehlerworkflowstatus, 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 der Anzahl und Der Typen von Zuständen

Sie bestimmen die Anzahl und Typen gültiger Zustände basierend auf der Anzahl unterschiedlicher logischer Zustände, in denen die Arbeitsaufgaben dieses Typs vorhanden sein sollen. Wenn unterschiedliche Teammitglieder unterschiedliche Aktionen ausführen, können Sie auch die Definition eines Zustands basierend auf einer Mitgliedsrolle in Betracht ziehen. Jeder Zustand entspricht einer Aktion, die ein Teammitglied für die Arbeitsaufgabe ausführen muss, um ihn in den nächsten Zustand zu verschieben. Für jeden Zustand sollten Sie die spezifischen Aktionen und die Teammitglieder definieren, die diese Aktionen ausführen dürfen.

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

State Gültiger Benutzer Action to perform
Proposed Projektmanager Jeder kann eine Funktionsarbeitsaufgabe erstellen. Allerdings können nur Projektmanager die Arbeitsaufgabe genehmigen oder ablehnen. Wenn ein Projektmanager ein Feature genehmigt, ändert der Projektmanager den Status der Arbeitsaufgabe in "Aktiv". andernfalls schließt ein Teammitglied es.
Aktiv Entwicklungsleiter Der Entwicklungsleiter überwacht die Entwicklung des Features. Wenn das Feature abgeschlossen ist, ändert der Entwicklungsleiter den Status der Funktionsarbeitsaufgabe in "Überprüfen".
Überprüfung Projektmanager Der Projektmanager überprüft das Feature, das das Team implementiert hat, und ändert den Status der Arbeitsaufgabe in "Geschlossen", wenn die Implementierung zufriedenstellend ist.
Geschlossen Projektmanager Es wird erwartet, dass keine zusätzliche Aktion für Arbeitsaufgaben ausgeführt wird, die geschlossen sind. Diese Elemente verbleiben in der Datenbank für Archivierungs- und Berichterstellungszwecke.

Hinweis

Alle Zustände werden in alphabetischer Reihenfolge in der Liste im Formular für eine Arbeitsaufgabe eines bestimmten Typs angezeigt, unabhängig von der Reihenfolge, in der Sie sie angeben.

Definieren von Übergängen

Sie steuern die Zustände in und von denen Teammitglieder eine Arbeitsaufgabe ändern können, wenn Sie die gültigen Zustandsverläufe und Regressionen definieren. Wenn Sie keinen Übergang von einem Zustand zu einem anderen definieren, können Teammitglieder eine Arbeitsaufgabe eines bestimmten Typs nicht von einem bestimmten Zustand in einen anderen bestimmten Zustand ändern.

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

State Übergang zum Zustand Standardgrund
Proposed Aktiv (Progression) Genehmigt für die Entwicklung
Geschlossen (Progression) Nicht genehmigt
Aktiv Überprüfen (Fortschritt) Akzeptanzkriterien erfüllt
Überprüfung Geschlossen (Progression) Feature abgeschlossen
Aktiv (Regression) Erfüllt keine Anforderungen
Geschlossen Vorgeschlagen (Regression) Zur Genehmigung überdenken
Aktiv (Regression) Fehler beim Schließen

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 verwenden. Wie im folgenden Beispiel gezeigt, können Tester einen Fehler erneut öffnen, entwickler jedoch nicht.

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

Angeben der Gründe

Wenn ein Teammitglied das Feld "Status" ändert, kann dieser Benutzer den Standardgrund für diesen Übergang beibehalten 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. Sie sollten zusätzliche Gründe nur angeben, wenn sie dem Team helfen, Daten nachzuverfolgen oder zu melden.

Ein Entwickler kann z. B. einen der folgenden Gründe angeben, wenn er einen Fehler behebt: Fixed (Standard), Verzögert, Duplikat, Wie entworfen, Nicht reproduzieren oder veraltet. Jeder Grund gibt eine bestimmte Aktion für den Tester in Bezug auf den Fehler an.

Hinweis

Alle Gründe werden in der Liste im Arbeitsformular für Arbeitsaufgaben 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, die die Gründe definieren, warum ein Mitglied des Teams einen Fehler beheben kann:

<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 einer Arbeitsaufgabe, indem Sie einen anderen Wert für das Feld "Bundesland " angeben und dann die Arbeitsaufgabe speichern. Sie können jedoch auch ein ACTION Element definieren, das den Status einer Arbeitsaufgabe automatisch ändert, wenn dieser Übergang eintritt. Wie im folgenden Beispiel gezeigt, können Sie angeben, dass Fehlerarbeitselemente automatisch aufgelöst werden sollen, wenn sie Dateien zugeordnet sind, die ein Entwickler in die Versionsverwaltung 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 Arbeitsaufgaben 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 auftreten (z. B. von einem Tool, das Aufrufe verfolgt). Weitere Informationen finden Sie unter ACTION.

Aktualisieren eines Felds während einer Workflowänderung

Sie können Regeln definieren, die Felder aktualisieren, 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 zu TRANSITION , wenn die Regel für diesen Übergang und alle Gründe für diesen Übergang gelten soll.

  • Weisen Sie eine Feldregel zu DEFAULTREASON , oder REASON wenn die Regeln nur aus diesem bestimmten Grund gelten 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 versuchen, die Anzahl der Bedingungen zu minimieren, die Sie für einen arbeitsaufgabentyp definieren. Mit jeder von Ihnen hinzugefügten bedingungsbedingten Regel erhöhen Sie die Komplexität des Überprüfungsprozesses, der jedes Mal auftritt, wenn ein Teammitglied eine Arbeitsaufgabe speichert. Komplexe Regelsätze können die Zeit erhöhen, die zum Speichern der Arbeitsaufgabe erforderlich ist.

    Die folgenden Beispiele zeigen einige der Regeln, die auf Systemfelder in der Prozessvorlage für die MSF Agile Software Development angewendet werden.

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

Wenn der Wert des Felds "Status" für eine Arbeitsaufgabe auf "Aktiv" festgelegt ist und die Arbeitsaufgabe 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 Gruppe "Gültige Benutzer" von Team Foundation Server 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 Werts eines Felds, wenn sich der Wert eines anderen Felds ändert

Wenn der Wert des Felds "Status" für eine Arbeitsaufgabe auf "Aktiv" festgelegt ist und die Arbeitsaufgabe gespeichert wird, werden die Felder "Geschlossen am" und "Geschlossen nach" automatisch auf NULL festgelegt und schreibgeschützt, 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 basierend auf dem Inhalt eines anderen Felds

Wenn sich der Wert des Felds "Status" für eine Arbeitsaufgabe in "Aufgelöst" ändert und die Arbeitsaufgabe 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 Erweiterung "Zustandsmodellvisualisierung" aus dem Visual Studio Marketplace installieren.