Team gewinnt – das Work Item Tracking

… Der Projektleiter prüft täglich den
Fortschritt der Arbeit und setzt den Status
von Szenarien, bei denen alle Development
Tasks abgeschlossen sind, auf
„Resolved“ und weist diese dem Tester
zu. Der Tester hat sich mithilfe der Project
Alerts eine Benachrichtigung eingestellt
und erhält eine Mail, die ihm anzeigt, dass
ihm ein Work Item zugeordnet wurde.
Während der Entwickler mit der Implementierung
der Anforderungen beschäftigt
ist, entwickelt der Tester die Tests zum
Validieren der Szenarien und QoS-Requirements
[5]. Die Ergebnisse von ausgeführten
Tests, kann er mit Work Items
verknüpfen oder bei fehlgeschlagenen
Tests direkt ein Bug mit vorausgefüllten
Feldern erstellen und einem Entwickler
zuweisen.

In einem täglichen „Triage-Meeting“
wird entschieden, wie mit den neu gefundenen
Bugs (Query: Untriaged Bugs)
verfahren wird. So können einige Bugs
zurückgestellt werden (State: Closed, Reason:
Deferred
), oder es stellt sich heraus,
dass noch mehr Aufwand für die Untersuchung
der Fehlerursache notwendig ist
(Triage: Investigate). Bei Bugs, die nicht
zurückgestellt oder weiter untersucht
werden müssen, wird das Feld Triage auf
„Approved“ gesetzt. Der verantwortliche
Entwickler führt die nötigen Änderungen
am Quellcode durch, um die Ursachen
des Fehlers zu beseitigen und checkt
dann die geänderten Sourcen ein. Beim
Checkin verknüpft er das Changeset mit
dem Bug und wählt als Checkin-Action
„Resolve“ aus. Dadurch wird der Bug automatisch
auf Resolved gesetzt und wieder
dem Tester zugewiesen, der darüber
per Mail benachrichtigt wird. Der Tester
überprüft die Fehlerbeseitigung und
schließt den Bug oder setzt ihn wieder auf
Active, wenn er mit der Lösung nicht einverstanden
ist.

Work Items anpassen

Wenn die Standard Work Item-Typen den
Projektanforderungen nicht genügen,
können diese an die eigenen Bedürfnisse
angepasst oder durch neue Work Item-
Typen ergänzt werden. Das Aussehen
und Verhalten der Work Items wird in einer
XML-Struktur, der Work Item Type
Definition
(WITD), festgelegt (Listing 1):

Includes informaion to track the
task through the MSF Agile lifecycle>

Diese Struktur kann mit einem XML-Editor
oder mit dem Process Template Editor,
der in den TFS Power Tools [6] enthalten
ist, bearbeitet werden. Zum Bearbeiten
der WITD ist die Berechtigung Edit Domain-
Level Information
erforderlich,
die standardmäßig der Team Foundation
Server-Gruppe Project Administrators
zugewiesen ist. Hier wird auf die Anpassung
mithilfe des Process Template Editors
eingegangen. [7] beschreibt die Anpassung
direkt in XML.

Wenn der Process Template Editor
installiert ist, lässt sich die Work Item
Type-Definition aus einem vorhandenen
Teamprojekt oder aus einer gespeicherten
Datei öffnen. Abbildung 5 zeigt den
Editor mit der Definition eines Task Work
Items und der Liste aller Felder, die mit
diesem Work Item-Typ verknüpft sind.

Abb. 5: Work Item Type-Definition

Es lassen sich neue Felder hinzufügen
und die vorhandenen Felder verändern
oder löschen. Die Liste aller Felder, die
bereits im TFS definiert sind, können mit
dem Work Item Field Explorer angezeigt
werden. Beim Anlegen eines neuen Feldes
werden Name, Type, RefName, Help
Text, Reportable
und Formula abgefragt.
Der Name ist ein serverweit eindeutiger,
für den Benutzer sichtbarer Bezeichner
für das Feld. Der Type gibt den Datentyp
des Feldes an. Mit RefName wird das
Feld global eindeutig referenziert und
kann somit auch auf andere TFS portiert
werden. RefName sollte die Form My-
Company.UseCase.Complexity
haben.
Es muss mindestens ein Punkt im Namen
sein und die Wörter „Microsoft“
und „System“ dürfen nicht verwendet
werden. Mit Help Text kann dem Benutzer
eine Hilfestellung für das Ausfüllen
des Feldes gegeben werden. Reportable
gibt an, ob und wie das Feld in die TFS
Warehouse-Struktur übernommen wird.
Details dazu in [7] und [8].

Bei der Definition
eines Feldes lassen sich weiterhin
Rules angeben, die beispielsweise vorgeben,
dass ein Feld Read Only ist, oder
dass Werte für ein Feld nur aus einer vorgegebenen
Werteliste ausgewählt werden
dürfen (Allowed Values). Solche Wertelisten
können aus Global Lists oder aus
Benutzergruppen des Active Directories
stammen. Global Lists sind Wertelisten,
die pro Team Foundation Server angelegt
werden können. Diese können auch
mit dem Process-Editor gepflegt werden.
Im Register Layout der Work Item
Type-Definition lässt sich das Aussehen
des Work Item-Formulars anpassen. Die
Bedienung ist intuitiv und gelingt bereits
nach wenigen Versuchen. Die Design-Ergebnisse
lassen sich über eine Vorschau
sehr gut beurteilen. …

Kommentare

Schreibe einen Kommentar

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