... Über das Register Workflow gelangt man zum grafischen Workflow- Designer, mit dem sich die Stati des Work Item-Types und das Verhalten der Statusübergänge (Transition) definieren lassen (siehe Abbildung 6). Bei den Status und den Statusübergängen können, genau wie bei der Felddefinition, Rules angeben werden. So kann ein Bug automatisch einem Tester zugewiesen werden, wenn der Bug von „Active“ auf „Resolved“ gesetzt wird. Unter Actions lassen sich Trigger angeben, die diesen Übergang auslösen können. Eingebaut ist derzeit nur der Trigger Micrsoft.VSTS. Actions.Checkin der beim Einchecken und gleichzeitigen Zuweisen eines Work Items ausgelöst wird.
Beim Speichern der Änderungen werden diese gegen das XML-Schema der Work Item Type-Definition geprüft und auf dem Server veröffentlicht beziehungsweise in der geöffneten Datei gespeichert. Auf dem Server veröffentlichte Änderungen werden erst sichtbar, wenn der Baum im Team Explorer aktualisiert wurde. Neue Work Item-Queries lassen sich leicht über den Team Explorer oder durch Kopieren und Editieren einer vorhandenen Query erstellen. Im Designbereich der Query – zu sehen in Abbildung 7 – kann pro Zeile eine Regel über die Spalten AND/OR, FIELD, OPERATOR und VALUE definiert werden.
Regeln lassen sich gruppieren und in der Spalte VALUE können Makros verwendet werden. Das Makro @Project wird beim Ausführen der Abfrage durch das aktuelle Team-Projekt ersetzt. Häufig genutzte Makros sind @Me, @Now oder @Today. Bei @Today sind auch @Today-7 zugelassen. Eine neue Query kann als Team Query, als My Query oder als File gespeichert werden. Eine Team Query ist für alle Team-Mitglieder sichtbar, allerdings sind zum Speichern Team Project Administrator-Rechte erforderlich.
Berechtigungen für Work Items können auf zwei unterschiedliche Arten vergeben werden. Zum einen für Areas, die auf Ebene eines Team-Projekts festgelegt werden. Beim Ausführen einer Query werden dann ausschließlich die Work Items angezeigt, die einer Area zugeordnet sind, für die der Benutzer berechtigt ist. Die andere Möglichkeit ist die Einschränkung der Editierbarkeit von Work Item-Feldern für bestimmte Benutzer oder Benutzergruppen über Rules in der oben beschriebenen Work Item Type-Definition. Mit der September-Version der TFS Power Tools kommen eine Reihe von Work Item-Templates mit. Damit lassen sich vorausgefüllte Work Items erstellen und nutzen, wenn eine große Anzahl von gleichartigen Work Items erzeugt werden soll. Die Templates lassen sich auch für das gleichzeitige Verändern (Bulk Edit) von mehreren Work Items verwenden. Die Möglichkeiten werden ausführlich in drei Blogbeiträgen des Work Item Tracking-Teams beschrieben [9].
Der im Team Explorer vorhandene grafische Dialog Project Alerts bietet die Möglichkeit, sich über „My work items are changed by others“ benachrichtigen zu lassen. Das reicht sicherlich für den Anfang aus, aber wenn der Projektleiter automatisch darüber informiert werden möchte, wenn ein Requirement auf den Status „Resolved“ gesetzt wurde, wird er erfreut sein, dass auch das geht. Der mühsame Weg führt über die Kommandozeilen mit Bissubscribe.exe. Eine grafische Oberfläche bietet das TFS Event Subscription Tool auf CodePlex [10].
In den meisten Fällen werden kleinere Änderungen an den Work Item-Typen ad hoc durchgeführt. Vor größeren Änderungen oder vor dem Hinzufügen von neuen Work Item-Typen sollte eine sorgfältige Planung der Arbeitsabläufe und ein ausgiebiger Test, am Besten auf einem seperaten Testsystem in einer virtuellen Umgebung, erfolgen.
Work Items erweitern
Falls die beschriebenen Anpassungsmöglichkeiten nicht reichen, gibt es noch einige Erweiterungsmöglichkeiten für Work Items. Das Visual Studio Software Development Kit [11] bietet dafür den geeigneten Einstiegspunkt. Den meisten Nutzen werden sicherlich Custom Controls (seit Team Foundation Server Service Pack 1) bieten, die den Umgang mit den Work Items komfortabler gestalten. Allerdings lassen sich mit dem oben beschriebenen Process Editor zurzeit noch keine Custom Controls zur Work Item Type-Definition hinzufügen. Sollen Custom Controls verwendet werden, empfiehlt es sich, zuerst die Definition im Process Editor durchzuführen, diese auf den Server hochzuladen und danach die Custom Controls manuell mit einem XML-Editor hinzuzufügen. In dem Fall muss die Typdefinition mithilfe der Kommandozeilenbefehle Witexport/Witimport ausgelesen und zurückgeschrieben werden. Eine ausführliche Anleitung zum Erstellen von Custom Controls findet sich in [12].
Mithilfe der Work Item Query Language [13], einer SQL-ähnlichen Sprache, lässt sich die Work Item-Datenbank über das Work Item Tracking-Objektmodell abfragen. Folgende Abfrage liefert die ID und den Titel aller Work Items, die dem angemeldeten Benutzer zugeordnet sind. Die Felder werden über den RefName der Work Items angesprochen. Ebenso können Makros (@Me) verwendet werden:
SELECT System.ID, System.Titel FROM workitems WHERESystem.AssignedTo = @Me
Weitere Möglichkeiten ergeben sich im Zusammenspiel mit dem Eventing Service. Wie weiter oben bereits beschrieben, lassen sich Benachrichtigungen abonnieren, die entweder an einen E-Mail-Empfänger oder an einen SOAP-Endpoint geschickt werden können. Dieser Mechanismus wird bei Scrum for Teamsystem genutzt, um die verbleibende Arbeit (Work Remaining) auf Product Backlog-Level zu berechnen. Immer, wenn sich in einem untergeordneten Sprint Backlog Item der Wert im Feld Work Remaining ...
