Entwerfen des Workflows

Sie entwerfen den Workflow für einen Arbeitsaufgabentyp zur Unterstützung von Geschäfts- und Teamprozessen. Der Workflow bestimmt den logischen Fortschritt der ausgeführten Aufgaben und von wem diese ausgeführt werden. Sie definieren den Workflow, indem Sie zuerst die Zustände und die gültigen Übergänge zwischen diesen identifizieren. Im Abschnitt WORKFLOW der Definition für den Arbeitsaufgabentyp werden die gültigen Zustände, Übergänge, Gründe für die Übergänge sowie die optionalen Aktionen definiert, die ausgeführt werden, wenn ein Teammitglied den Zustand einer Arbeitsaufgabe ändert. Weitere Informationen zu Typdefinitionen finden Sie unter XML-Elementreferenz für WITD.

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 Aktiv festgelegt, wenn ein Tester einen neuen Fehler öffnet, der auf der Prozessvorlage für Microsoft Solutions Framework (MSF) for Agile Software Development 5.0 basiert. Der Entwickler ändert den Zustand in Gelöst, nachdem er den Fehler behoben hat, und legt den Wert des Felds Grund auf Korrigiert fest. Der Tester ändert den Zustand des Fehlers in Geschlossen, nachdem er die Lösung überprüft hat, und lässt den Wert des Felds Grund auf Korrigiert. 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 Lösung verweigert oder Fehler bei Test an.

Tipp

Mit dem Process Editor, einem Power Tool für Visual Studio, können Sie die Definitionen für Arbeitsaufgabentypen und andere Objekte erstellen und ändern, um Arbeitsaufgaben nachzuverfolgen. Dieses Tool wird nicht unterstützt. Weitere Informationen finden Sie auf der folgenden Seite der Microsoft-Website: Team Foundation Server Power Tools April 2010.

In diesem Thema

• Richtlinien für den Workflowentwurf

• Workflowdiagramm und Codebeispiel

• Bestimmen von Anzahl und Typen der Zustände

• Definieren der Übergänge

  • Festlegen der Gründe

  • Festlegen von Aktionen

• Aktualisieren eines Felds bei Zustandsänderungen

  • Definieren eines Felds bei Zustandsänderungen

  • Löschen des Werts für ein Feld

  • Definieren eines Felds auf Grundlage des Inhalts eines anderen Felds

• Anzeigen des Workflowzustandsdiagramms

Richtlinien für den Workflowentwurf

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

• Mit dem STATE-Element definieren Sie für jede Teammitgliederrolle, die eine bestimmte Aktion für eine Arbeitsaufgabe ausführt, einen eindeutigen Zustand. 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 diese in alphanumerischer Reihenfolge in der Liste Zustand aufgeführt.

• Mit dem TRANSITION-Element definieren Sie einen Übergang für alle gültigen Fortschritte und Regressionen von einem Zustand in einen anderen.

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

• Für jeden Übergang muss mit dem DEFAULTREASON-Element ein Standardgrund definiert werden. Mit dem REASON-Element können Sie beliebig viele optionale Gründe 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.

• Sie können für jedes Feld bedingte Regeln definieren, die angewendet werden, wenn sich der Zustand der Arbeitsaufgabe ändert, wenn Übergänge ausgeführt werden 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 Aktualisieren eines Felds bei Zustandsänderungen weiter unten in diesem Thema.

• 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 können die Zeitspanne für das Speichern der Arbeitsaufgabe verlängern.

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

Zurück nach oben

Workflowdiagramm und Codebeispiel

In der folgenden Tabelle werden der Abschnitt WORKFLOW der Definition für einen Arbeitsaufgabentyp, mit dem Codefehler verfolgt werden, sowie das Workflowzustandsdiagramm für die Definition dargestellt. In diesem Beispiel werden drei Zustände, sechs Übergänge und neun Gründe 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.

Tipp

Im Beispiel sind die Elemente für DEFAULTREASON, REASON, ACTION und FIELD nicht aufgeführt.

<WORKFLOW> <STATES>   <STATE value="Active">     <FIELDS> . . . </FIELDS>   </STATE>   <STATE value="Resolved">     <FIELDS> . . . </FIELDS>   </STATE>   <STATE value="Closed" /> </STATES> <TRANSITIONS>   <TRANSITION from="" to="Active">     <REASONS>       <DEFAULTREASON value="New" />     </REASONS>     <FIELDS> . . . </FIELDS>   </TRANSITION>   <TRANSITION from="Active" to="Resolved">     <REASONS> . . . </REASONS>     <FIELDS> . . . </FIELDS>     < ACTIONS > . . . </ ACTIONS > </TRANSITION> <TRANSITION from="Resolved" to="Closed">     <REASONS> . . . </REASONS>     <FIELDS> . . . </FIELDS>     < ACTIONS > . . . </ ACTIONS > </TRANSITION> <TRANSITION from="Resolved" to="Active">     <REASONS> . . . </REASONS>     <FIELDS> . . . </FIELDS> </TRANSITION> <TRANSITION from="Active" to="Closed ">     <REASONS> . . . </REASONS>     <FIELDS> . . . </FIELDS> </TRANSITION> <TRANSITION from="Closed" to="Active">     <REASONS> . . . </REASONS>     <FIELDS> . . . </FIELDS> </TRANSITION> </TRANSITIONS> </WORKFLOW>

Beispiel für ein Workflowzustandsdiagramm

Bestimmen von 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:

Zustand	Gültiger Benutzer	Auszuführende Aktion
Vorgeschlagen	Projektmanager	Jeder kann eine Funktionsarbeitsaufgabe erstellen. Allerdings kann die Arbeitsaufgabe 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 der Funktionsarbeitsaufgabe in Prüfen.
Prüfen	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.
Closed	Projektmanager	Für geschlossene Arbeitsaufgaben wird keine zusätzliche Aktion mehr erwartet. Diese Elemente verbleiben zu Archivierungs- und Berichtszwecken in der Datenbank.

Tipp

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

Zurück nach oben

Definieren der Übergänge

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.

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

Mit den for- und not-Attributen des TRANSITION-Elements können Sie einschränken, wer einen Übergang von einem Zustand in einen anderen durchführen darf. 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>

Zurück nach oben

Festlegen der Gründe

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.

Tipp

Alle Gründe werden in der Liste auf dem 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, 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>

Zurück nach oben

Festlegen 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 Verwaltung von Anwendungslebenszyklen von Visual Studio Ereignisse auftreten (z. B. in einem Tool, das Aufrufe verfolgt). Weitere Informationen finden Sie unter Automatisieren von Feldzuweisungen auf Grundlage von Zustand, Übergang oder Grund.

Zurück nach oben

Aktualisieren eines Felds

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 finden Sie unter Festlegen von Bedingungen für ein Arbeitsaufgabenfeld.

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

• Ändern des Werts eines Felds bei Zustandsänderungen

• Löschen des Werts eines Felds bei Änderungen des Werts eines anderen Felds

• Definieren eines Felds auf Grundlage des Inhalts eines anderen Felds

Zurück nach oben

Ändern des Werts eines Felds bei Zustandsänderungen

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>

Zurück nach oben

Löschen des Werts eines Felds bei Änderungen des Werts eines anderen Felds

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>

Zurück nach oben

Definieren eines Felds auf 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>

Zurück nach oben

Anzeigen des Workflowzustandsdiagramms

Sie können die Workflowdefinition eines beliebigen Arbeitsaufgabentyps anzeigen, wenn Sie Team Web Access zum Öffnen des Zustandsdiagramms für eine beliebige Arbeitsaufgabe dieses Typs verwenden. Weitere Informationen finden Sie unter Verwalten der Arbeit mit Team Web Access.

Tipp

Sie können auch das Workflowzustandsdiagramm anzeigen, das Sie mit dem Process Editor, einem Power Tool für Visual Studio, definieren. Dieses Tool wird nicht unterstützt. Weitere Informationen finden Sie auf der folgenden Seite der Microsoft-Website: Team Foundation Server Power Tools April 2010.

Zurück nach oben

Siehe auch

Weitere Ressourcen

Definieren und Anpassen des Workflows für Arbeitsaufgaben

Änderungsprotokoll

Datum	Versionsgeschichte	Grund
Januar 2011	Die Tabelle mit WORKFLOW-Elementen wurde in ein neues Thema (XML-Elementreferenz für WORKFLOW) verschoben.	Informationsergänzung.
Juli 2010	Vollständig überarbeitet, um weitere Informationen, Beispiele und eine Zusammenfassung aller WORKFLOW-Elemente und -Attribute bereitzustellen.	Informationsergänzung.