Ändern des Workflows für einen Arbeitsaufgabentyp

Azure DevOps Server | Azure DevOps Server 2022

Ändern Sie den Workflow für einen Arbeitsaufgabentyp (WIT), 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)

Aktualisieren der XML-Definition für einen Arbeitsaufgabentyp

Wenn Sie mit der WIT-Anpassung noch nicht fertig sind, beachten Sie Folgendes:

• Aktualisieren Sie die XML-Definition, um einen beliebigen Aspekt eines Arbeitsaufgabentyps anzupassen. Weitere Informationen finden Sie in der Referenz zu allen WITD-XML-Elementen.
• Wenn Sie das Webformular anpassen, das die neue Arbeitsobjekt-Erfahrung verwendet, sehen Sie sich die WebLayout- und Control-Elemente an.
• Wenn Sie ein Clientformular für die Verwendung mit Visual Studio anpassen, lesen Sie in der Layout-XML-Elementreferenz.
• Führen Sie die Reihenfolge der Schritte aus, die im Webformular für die Nachverfolgung von Arbeitsaufgaben beschrieben sind.

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 Workflow-Zustände Metastaten 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

Definieren Sie 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.

Ordnen Sie im Allgemeinen jedem Status eine Teammitgliedsrolle und eine Aufgabe zu, die eine Person in dieser Rolle ausführen muss, um das Arbeitselement zu verarbeiten, bevor dessen Status geändert wird. Ü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.

Legen Sie beispielsweise den Status auf "Neu " fest, 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 hat, ändert der Tester den Status des Fehlers in "Aktiv " und gibt 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ührt. 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 angezeigt.

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

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

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

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

  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.

• Definieren Sie für jeden Übergang 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 gelten, wenn sich der Zustand des Arbeitselements ändert, wenn es übergeht 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, ACTION und FIELD aufgelistet.

Beispiel für Workflowstatusdiagramm – Agile Bug WIT

<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 Arten von Zuständen

Legen Sie die Anzahl und die Typen gültiger Zustände basierend auf der Anzahl unterschiedlicher logischer Zustände fest, in denen die Arbeitsaufgaben dieses Typs vorhanden sein sollen. Wenn unterschiedliche Teammitglieder unterschiedliche Aktionen ausführen, sollten Sie auch einen Status basierend auf einer Mitgliedsrolle definieren. Jeder Zustand entspricht einer Aktion, die ein Teammitglied für die Arbeitsaufgabe ausführen muss, um ihn in den nächsten Zustand zu verschieben. Definieren Sie für jeden Zustand die spezifischen Aktionen und die Teammitglieder, die diese Aktionen ausführen dürfen.

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

Definieren von Übergängen

Sie steuern die Zustände in und von denen Teammitglieder eine Arbeitsaufgabe ändern können, indem Sie die gültigen Zustandsverläufe und Regressionen definieren. Wenn Sie keinen Übergang von einem Zustand in einen anderen Zustand 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.

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

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

Angeben der Gründe

Wenn ein Teammitglied das Feld "Bundesland" ändert, kann er den Standardgrund für diesen Übergang beibehalten oder einen anderen Grund angeben, wenn Sie zusätzliche Optionen definieren. Verwenden Sie das DEFAULTREASON Element, um einen und nur einen Standardgrund anzugeben. Fügen Sie zusätzliche Gründe nur hinzu, 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.

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>  

Verwenden Sie das ACTION Element, 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 unter STATE zu, wenn die Regel für alle Übergänge zu diesem und alle Gründe für das Betreten dieses Zustands gelten soll.

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

• Weisen Sie eine Feldregel unter DEFAULTREASON oder REASON zu, wenn die Regeln nur aus diesem spezifischen 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.

  Minimieren Sie die Anzahl der Bedingungen, die Sie für einen arbeitsaufgabentyp definieren. Jede bedingte Regel fügt dem Überprüfungsprozess Komplexität hinzu, 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 Sie den Wert des Felds "Status" für eine Arbeitsaufgabe auf "Aktiv" festlegen und die Arbeitsaufgabe speichern, 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 Sie den Wert des Felds State für eine Arbeitsaufgabe auf Aktiv festlegen und die Arbeitsaufgabe speichern, setzt das EMPTY-Element automatisch die Felder "Geschlossen am" und "Geschlossen von" auf null und macht sie schreibgeschützt, 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 Sie den Wert des Felds "Status" für eine Arbeitsaufgabe in "Aufgelöst" ändern und die Arbeitsaufgabe speichern, 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>  

Verwandte Inhalte

• Workflowstatus und Statuskategorien
• Anpassen Ihrer Arbeitstracking-Erfahrung
• Abfragen nach Zuordnungs-, Workflow- oder Boardänderungen
• Entwerfen des Arbeitsaufgabenformulars
• Importieren, Exportieren und Verwalten von Arbeitsaufgabentypen

Toolunterstützung

Um Ihren Benutzern zu helfen, den Workflow zu visualisieren, installieren Sie die Erweiterung "Zustandsmodellvisualisierung" aus dem Visual Studio Marketplace.