Allgemein Für Administratoren Für Architekten Für Entwickler Für Projektleiter Für Tester News Produkte Publikationen
X
Sven Hubert

Sven Hubert

Die Work Item Felder “Triage” und “Reason” beleuchtet

Dienstag, 01. Juli 2008

Die meisten Unternehmen, die sich für das Visual Studio Team System entscheiden, nutzen nicht nur die Source-Code-Verwaltung, sondern auch die Prozessunterstützung. Dabei werden überwiegend die vordefinierten Prozessvorlagen, wie z.B. "MSF for CMMI Process Improvement" verwendet. Eine eigene Vorlage zu erstellen kostet Zeit und ist keine einfache Aufgabe. Da ist es einfacher, die vorgegebenen Prozessmodelle an die eigenen Bedürfnisse anzupassen. Aus eigener Erfahrung muss man sich aber auch an den Umgang mit Work Items und Berichten gewöhnen. Meist zu Anfang wenig beachtete Work Item Felder sind dabei "Triage" und "Reason". Dieser Artikel soll zeigen, wie sich diese Felder nutzen lassen und worin sie sich unterscheiden.

Viele Benutzer von Visual Studio Team System klagen über zu wenige mögliche Zustände der Work Items. "Da fehlen die Zustände ‚Zu Planen‘ und ‚Bereit für Review‘ und ‚Zu Testen‘ und…"

Nun kann der Ruf nach mehr Zuständen direkt durch Anpassung der Prozessvorlagen und das Hinzufügen von neuen Work Item Zuständen realisiert werden. Von Vorteil ist dabei die Rule Engine. Jeder Zustand kann mit Regeln versehen werden und die Zustandsübergänge über Berechtigungen gesichert werden. Das hat allerdings auch Nachteile, die in einigen Fällen die Vorteile überwiegen. Zum einen müssen die in den Prozessvorlagen vorhandenen Standardberichte aufwändig angepasst werden, damit auch die neuen Zustände reflektiert werden. Hört sich einfach an, gestaltet sich aber häufig aufwändig. Zum anderen resultieren viele Zustände in einer unnötigen Klickerei, vor allem, wenn es viele unterschiedliche Handlungsabläufe gibt. Allzu oft wird ein Work Item eben gleich zum implementieren freigegeben. Dann muss man sich unter Umständen erst über die Zustände ‚Zu Planen‘, ‚Geplant‘ usw. ‚durchklicken‘.

Eine sinnvolle Ergänzung zu den Zuständen bieten andere Work Item Felder, wie z.B. ‚Reason‘ und ‚Triage‘. Diese können auch einen entsprechenden Ersatz für ‚Unterzustände‘ darstellen, da diese vom Zustandsautomaten nicht unterstützt werden.

So lässt sich zum Beispiel der Fall abbilden, dass eine Aufgabe in Form eines Work Items vom Typ Task angelegt wird und zunächst z.B. auf die entstehenden Aufwände hin untersucht werden soll. Dazu wird das Work Item erstellt, zugewiesen und der Status unter Angabe der Reason ‚Investigate‘ auf ‚Active‘ gesetzt. Der verantwortliche Entwickler – der das Work Item unter seinen aktiven Aufgaben findet – untersucht es nun und erfragt z.B. mittels Triage ‚More Info‘ mehr Informationen, um die Aufgabe erledigen zu können. Dabei kann auch das History Feld hilfreich sein, in dass sich auch Kommentare eintragen lassen. Dort würde in unserem Beispiel ein Hinweis auf fehlende Informationen eingetragen werden. Dabei ändert sich der Zustand des Work Item nicht, es bleibt aktiv.

Sind die Informationen nachgetragen und ausreichend, wird Triage z.B. auf ‚Triaged‘ gesetzt und die Untersuchung abgeschlossen. Dies kann in einer Abschätzung des Umsetzungsaufwand enden, die im Feld ‚Estimate‘ eingetragen wird. Das Work Item wird dazu zurück in den Zustand ‚Proposed‘ gesetzt. Der Reason ist dabei ‚Investigation Complete‘.

Es kann nun über die tatsächliche Umsetzung entschieden und das Work Item eingeplant werden. Dabei wird der Zustand des Work Item auf ‚Active‘ und der Reason auf ‚Accepted‘ gesetzt. Der Entwickler kann nun die Aufgabe umsetzen und nach Fertigstellung das Work Item auf Resolved setzen. Dabei steht ihm offen, ob er die Reason auf ‚Complete‘ oder ‚Requires Review/Test‘ setzt. So lässt sich die Entscheidung über das weitere Vorgehen offen halten. Nach entsprechenden Maßnahmen – also z.B. einem Test – wird das Work Item im Erfolgsfall geschlossen (Zustand ‚Closed‘) bzw. bei Nichterreichen der Qualitätsziele reaktiviert (Zustand ‚Active‘). Hier zeigt die Reason wieder den Grund für den Zustandswechsel, also ‚Review/Test passed‘ bzw. ‚Review/Test failed‘. Die folgende Abbildung stellt das Beispiel zum besseren Verständnis noch einmal grafisch dar.

Das Beispiel zeigte, wie man sich die Work Item Felder ‚Triage‘ und ‚Reason‘ zu Nutze macht, um die Anzahl der Zustände eines Work Items möglichst gering und damit überschaubar zu halten.

Verwandte Artikel:

Benötigen Sie Unterstützung bei der Software-Entwicklung und Architektur von .NET basierten Lösungen oder bei Einführung und Anpassung von Visual Studio / Microsoft Test Manager / Team Foundation Server?

Wir stehen Ihnen unter info(at)aitgmbh.de gerne zur Verfügung.

Hinterlasse eine Antwort