Ändern des Workflows für einen Arbeitsaufgabentyp

Sie ändern den Workflow für einen Arbeitsaufgabentyp (WIT), um Ihre Geschäfts- und Teamprozesse zu unterstützen. WITs unterstützen das Nachverfolgen aller Arbeitstypen – Anforderungen, Aufgaben, Codefehler – für den Support der Softwareentwicklung mit Team Foundation Server (TFS).

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.

Workflow für Product Backlog Item (Scrum-Prozessvorlage

Eine Übersicht der unterstützen Standard-Workflowzustände in den Standardprozessvorlagen, die TFS bereitstellt, finden Sie unter Arbeiten mit Teamprojektartefakten, Auswählen eines Prozessleitfadens. Informationen zum Erstellen eines Definitionsworkflows finden Sie unter Anpassen der Buildprozessvorlage.

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 einer Arbeitsaufgabe ändert.

Im Allgemeinen verknüpfen Sie jeden Zustand mit einer Teammitgliederrolle und einer Aufgabe, die eine Person in dieser Rolle zum Verarbeiten der Arbeitsaufgabe 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 eine Arbeitsaufgabe von einem Zustand in einen anderen ändert, und durch Aktionen wird die Automatisierung des Übergangs einer Arbeitsaufgabe an einem Punkt im Workflow unterstützt.

Beispielsweise wird der Zustand auf Neu festgelegt, wenn ein Tester einen neuen Fehler öffnet, der auf der Agile-Standardprozessvorlage basiert, die durch Team Foundation Server (TFS) bereitstellt wird. Der Zustand wird durch den Entwickler in Aktiv geändert, während er an der Behebung des Fehlers arbeitet. Sobald der Fehler behoben wurde, wird der Zustand durch den Entwickler in Gelöst geändert und der Wert des Felds "Grund" in Korrigiert festgelegt. Der Tester ändert den Zustand des Fehlers in Geschlossen, nachdem er die Lösung überprüft hat, und das Feld "Grund" wird in Bestätigt geändert. Wenn der Tester feststellt, dass der Fehler vom Entwickler nicht behoben wurde, ändert er den Zustand des Fehlers in Aktiv und gibt den Grund als Nicht behoben oder Fehler bei Test an.

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

• Verwenden Sie das STATE-Element zum Definieren eines eindeutigen Status für jede Teammitgliederrolle, 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 Status definieren, werden diese in alphanumerischer Reihenfolge im Dropdownmenü für das Feld Zustand aufgeführt.

  Wenn Sie einem Arbeitsaufgabentyp einen Zustand hinzufügen, der auf der Backlog- oder Boardseite in Team Web Access angezeigt wird, müssen Sie auch den Zustand einem Metazustand zuordnen. Siehe XML-Elementreferenz für die Prozesskonfiguration.

• Verwenden Sie das TRANSITION-Element zum Definieren eines Übergangs für alle gültigen Fortschritte und Regressionen von einem Status in einen anderen.

  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 eine neue Arbeitsaufgabe speichern, wird diese automatisch dem Anfangszustand zugewiesen.

  Wenn ein Teammitglied den Zustand einer Arbeitsaufgabe ä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. Außerdem kann der Zustand einer Arbeitsaufgabe von einem ACTION-Element, ein untergeordnetes Element von TRANSITION, geändert werden.

• Für jeden Übergang definieren Sie einen Standardgrund durch die Verwendung des DEFAULTREASON-Elements. Mit dem REASON-Element können Sie beliebig viele optionale Gründe definieren. Diese Werte werden im Dropdownmenü des Felds Grund angezeigt.

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

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

  Die Dropdownmenüs der Felder "Zustand" und "Grund" innerhalb des Arbeitsaufgabenformulars oder des Abfrage-Editors zeigen die Werte an, die im WORKFLOW-Abschnitt des Arbeitsaufgabentyps zugewiesen werden.

Workflowdiagramm und Codebeispiel

Das folgende Codebeispiel zeigt den WORKFLOW für die 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 Zustände Aktiv, Gelö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.

Dieses Beispiel führt nicht alle Elemente für DEFAULTREASON, REASON, ACTION und FIELD auf.

<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>

Beispiel: Workflowzustandsdiagramm – agile Bug WIT

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 Arbeitsaufgaben 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 die Arbeitsaufgabe 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:

Definieren von Übergängen

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

Sie können einschränken, wer einen Übergang von einem in einen anderen Zustand vornehmen darf, indem Sie die for and not-Attribute des TRANSITION-Elements 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. Mit dem DEFAULTREASON-Element darf genau ein Standardgrund angegeben werden. 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.

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 Zustand einer Arbeitsaufgabe, indem sie einen anderen Wert für das Feld Zustand angeben und die Arbeitsaufgabe dann speichern. Sie können jedoch auch ein ACTION-Element definieren, anhand dessen der Zustand einer Arbeitsaufgabe automatisch geändert wird, wenn dieser Übergang auftritt. Wie das folgende Beispiel zeigt, können Sie angeben, dass Fehlerarbeitsaufgaben 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>

Mithilfe des ACTION-Elements können Sie den Zustand der Arbeitsaufgaben eines bestimmten Typs automatisch ändern, wenn an anderer Stelle in Microsoft Visual Studio Application Lifecycle Management oder außerhalb von Visual Studio Application Lifecycle Management Ereignisse auftreten (z. B. in einem Tool, das Aufrufe nachverfolgt). Weitere Informationen finden Sie unter Automatisieren von Feldzuweisungen auf Grundlage von Zustand, Übergang oder Grund.

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 STATE eine Feldregel zu, wenn die Regel für alle Übergänge zu diesem Zustand und Gründe für das Eintreten in diesen Zustand angewendet werden soll.

• Weisen Sie unter TRANSITION eine Feldregel zu, wenn die Regel für diesen Übergang und für alle Gründe zur Durchführung dieses Übergangs angewendet werden soll.

• Weisen Sie unter DEFAULTREASON oder REASON eine Feldregel zu, wenn die Regeln nur für diesen bestimmten Grund angewendet werden sollen.

Wenn ein Feld immer den gleichen Wert enthalten soll, definieren Sie die Regel unter dem FIELD-Element, von dem das entsprechende Feld definiert wird. Weitere Informationen zur Verwendung von Regeln finden Sie unter Anwenden einer Regel auf ein Arbeitsaufgabenfeld.

Sie sollten möglichst wenige Bedingungen für die einzelnen Arbeitsaufgabentypen 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 der Arbeitsaufgabe erforderlich ist.

Im folgenden Beispiel werden einige der Regeln gezeigt, die in der Prozessvorlage für MSF Agile Software Development 2013 auf Systemfelder angewendet werden.

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

Wenn der Wert des Felds Zustand 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 Team Foundation Server-Benutzer" sein. Der Wert des Felds Aktivierungsdatum 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 Zustand für eine Arbeitsaufgabe auf Aktiv festgelegt ist und die Arbeitsaufgabe gespeichert wird, werden, wie das folgende Beispiel zeigt, die Felder Schließungsdatum und Geschlossen von automatisch auf NULL festgelegt und schreibgeschützt, wenn Sie das EMPTY-Element verwenden.

<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

Wird der Wert des Felds Zustand für eine Arbeitsaufgabe in Gelöst geändert und die Arbeitsaufgabe gespeichert, wird der Wert des Felds Grund für Lösung auf den Wert festgelegt, der vom Benutzer im Feld Grund angegeben wurde. 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>

Fragen und Antworten

F: Gibt es ein Tool zum Ändern des Workflows oder zum Anzeigen der Workflowzustandsdiagramme?

A: Ja. Sie können den Workflow ändern oder das Workflowzustandsdiagramm anzeigen, das Sie definieren, indem Sie den Prozess-Editor verwenden, ein leistungsfähiges Tool für Visual Studio. Weitere Informationen finden Sie auf der folgenden Seite der Microsoft-Website: Team Foundation Server Power Tools.

F: Wo erhalte ich einen Überblick zu WIT-Definitions-XML-Elementen?

A: Siehe Verweis für alle WIDT-XML-Elemente.