Team gewinnt – das Work Item Tracking

… Ü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.

Abb. 6: Der Zustandsautomat des Task Work-Items

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.

Abb. 7: Der Work Item Query-Editor

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 WHERE
System.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

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.