Team gewinnt – das Work Item Tracking

… Zum Erfassen der Szenarien liegt eine
Excel-Liste bereit, die entweder aus
dem Projekt-Portal oder über den Team
Explorer geöffnet werden kann (siehe
Abbildung 2).

Abb. 2: Szenarien erfassen mithilfe von Excel

Ein Add-in, das bei der Installation
des Team Foundation-Clients
mitkommt, macht es möglich, Excel-Listen
und MS Project-Dateien mit Work
Item-Listen des TFS zu synchronisieren.
Die Szenarien-Liste ist mit der All Scenarions
Query
des aktuellen Team Projects
verbunden und bereits im TFS vorhandene
Work Items werden hier angezeigt.
Sollten durch das Hinzufügen neuer Szenarien
Konflikte entstehen, werden diese
angezeigt und können manuell behoben
werden. Gleichzeitig werden mit der Ermittlung
der Szenarien zugehörige Quality
of Service Requirements
erfasst. Das
können beispielsweise das Antwortverhalten
oder Sicherheitsanforderungen
sein. Dafür gibt es ebenfalls schon eine
Excel-Liste (Qos Requirements.xls) im
Projekt-Portal.

Wenn der größte Teil der Szenarien
und QoS-Requirements erfasst wurde,
werden in einem Schätzworkshop deren
Komplexitäten, die dem Aufwand der
Umsetzung entsprechen, ermittelt. Die
Komplexität (Rough Order of Magnitude)
wird als Zahl zwischen 0 und 3 festgelegt.
Dabei bedeutet 0, dass kein Aufwand
erforderlich ist und 3, dass mehr
als ein Dutzend ein- bis zweitägige Tasks
erforderlich sind, um dieses Szenario umzusetzen.
Wenn der Aufwand wesentlich
größer geschätzt wird, sollten die Szenarien
geteilt werden. Als nächstes wird die
Priorität festgelegt, die für die Reihenfolge
der Umsetzung wichtig ist. Dafür ist
das Feld Rank vorgesehen, das beliebige
Zahlenwerte erlaubt, um nicht nur High
Priority-Szenarien zu erhalten, sondern
eine absteigende Liste. Bei der Festlegung
können der Geschäftswert, das Risiko
und die Kosten einfließen. Wichtig ist,
dass das Team sich auf ein einheitliches
Modell zur Priorisierung festlegt. Die
Listen der Szenarien und QoS-Requirements
werden mit den ermittelten Werten
vervollständigt und auf dem Server veröffentlicht.

Am Anfang einer Iteration werden
die am höchsten priorisierten und noch
nicht umgesetzten Szenarien sowie QoSRequirements
in Aufgaben heruntergebrochen.
Die Aufgaben werden als Task
Work Items erfasst, deren Aufwand nicht
größer als zwei Tage sein sollte. Nach
dem Ausführen der Query All Scenarios
wird in der Ergebnisliste ein Szenarium
ausgewählt und mit der rechten Maustaste
eine neue Aufgabe hinzugefügt, die
automatisch mit dem Szenarium verlinkt
ist. Der für diese Aufgabe geschätzte Aufwand
wird im Task-Formular im Bereich
Details im Feld Remaining Work in Stunden
eingetragen und der verantwortliche
Mitarbeiter mit Assigned To festgelegt.
Für die in dieser Iteration umzusetzenden
QoS-Requirements kann genauso vorgegangen
werden. Alternativ kann MS Project
verwendet werden, um Szenarien und
Requirements in Aufgaben zu zerlegen
und zeitlich zu planen. Statt die Query in
Visual Studio auszuführen, wird diese
im Team Explorer selektiert und über das
Kontextmenü in MS Project geöffnet. Das
Mapping von Work Item-Feldern zu Project-
Spalten ist in der jeweiligen Prozessvorlage
definiert und kann nachträglich
geändert werden [4]. Die in Project angelegten
Aufgaben müssen nachträglich
mit den übergeordneten Szenarien verknüpft
werden. Das geschieht im Work
Item-Formular im Register Links (Abbildung
3).

Abb. 3: Query All Scenarios und Scenario Details

Hier können außerdem Changesets,
eine bestimmte Version einer Datei
aus dem Source Code Control (Versioned
Item
), auf dem TFS veröffentlichte Testergebnisse
(Test Result) sowie Dokumente,
die über einen URL referenziert sind,
mit dem Work Item verknüpft werden.

Anhand der Query My Tasks sieht jedes
Teammitglied seine anstehenden Aufgaben.
Ein Entwickler wird hauptsächlich
Development-Tasks in seiner Aufgabenliste
haben und diese nacheinander abarbeiten.
Wenn er mit der Implementierung
einer Aufgabe fertig ist, checkt er den
Sourcecode ein und kann beim Checkin
die Sourcen mit dem entsprechenden Task
Work Item verknüpfen. Er kann als Checkin
Action Resolve angeben, was den Task
auf den Status „Closed“ setzt (siehe Abbildung
4).

Abb. 4: Der Checkin-Dialog

Für ein Team Project lassen
sich sog. Checkin-Policies aktivieren, die
vorschreiben, dass ein Changeset mindestens
einem Work Item zugeordnet werden
muss, damit dieses eingecheckt werden
kann. Beim nächsten Team Build werden
die Changesets, die zwischen dem letzten und dem aktuellen Build-Lauf eingecheckt
wurden, mit dem Build verknüpft.
Über den Pfad Scenario, Task, Changeset,
Build
kann nachverfolgt werden, in welchem
Build welche Anforderungen integriert
wurden. …

Kommentare

Schreibe einen Kommentar

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