... 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):
<WITD application=“Work item type editor“ version=“1.0“><WORKITEMTYPE name=”Task”><DESCRIPTION>Includes informaion to track thetask through the MSF Agile lifecycle</><FIELDS><FIELD refname=“System.Title“ name=“Title“ type=“String“ reportable=“dimension“><REQUIRED /></FIELD></FIELDS><WORKFLOW><STATES><STATE value=“Active“ /></STATES><TRANSITIONS><TRANSITION from=““ to=“Active“ /><REASONS><DEFAULTREASON value=“New“></REASONS></TRANSITIONS></WORKFLOW><FORM><LAYOUT><Control Type=“FieldControl“ FieldName=“Title“/></LAYOUT></FORM></WORKITEMTYPE></WITD>
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.
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. ...
