Anforderungen können im Team Foundation Server zum Beispiel als Requirement-Work-Item angelegt werden. Für die Einordnung von Work Items nach zeitlichen und weiteren Kriterien werden verschiedene Möglichkeiten angeboten. Dieser Beitrag soll eine Möglichkeit für die Strukturierung nach geplanter Produktversion, Iteration und Teamzugehörigkeit darstellen und Ihnen helfen, einen besseren Überblick über Ihre Softwareentwicklungsprojekte im Team Foundation Server zu behalten.
Iteration und Area Path
Für hierarchische Strukturen bieten Work Items zwei Standardfelder an – Area und Iteration Path. Diese lassen sich frei als Baum von Textwerten definieren. Eine Möglichkeit, den Iteration Path zu verwenden, ist die Einordnung nach Produktversion/-release und Iteration. So könnte sich der Baum wie folgt darstellen:
Damit lassen sich Releaseplanung für das Produkt und Iterationsplanung zur Umsetzung in verschiedenen Phasen umsetzen.
Für die Zuordnung der Verantwortlichkeiten steht in den Work Items ein Feld namens "Assigned To" zur Verfügung, welches nicht nur eine Zuordnung zu einer Person sondern auch zu Gruppen ermöglicht.
Häufig ist aber auch hier eine Hierarchie gefordert, da die schiere Anzahl der beteiligten Personen oder auch die Unternehmensstruktur einen Baum nach Team, Unterteam und Person erfordert. Dies kann durch eine Kombination aus Area Path und Assigned-To-Feld gelöst werden. So könnte die Area wie folgt aufgebaut werden:
Den Überblick behalten
Die folgende Abbildung bringt die beiden Strukturen zusammen und zeigt, wie im ersten Schritt Anforderungen einem bestimmten Team (ausgewählt zum Beispiel nach fachlichen Gesichtspunkten) zu geordnet werden können. Bei der individuellen Produkt- bzw. Iterationsplanung bestimmt das Team den Zeitpunkt für die Umsetzung je nach Kapazität oder Abhängigkeiten zu anderen Anforderungen. Das obliegt mit Absicht dem einzelnen Team, welches auch die Absprachen zu anderen Teams selbstständig verantwortet. Das sorgt für eine Arbeitsverteilung ohne Micromanagement durch das Produkt- bzw. Projektmanagement. Für die Überwachung des Fortschritts dient der Status der Anforderung, der zum Beispiel die Zustände "Proposed" (blau), "Active" (rot), "Resolved" (Orange) und "Closed" (grün) umfasst.
Das Produktmanagement könnte im obigen Modell aber dennoch den Releasezeitpunkt für eine Anforderung bestimmen. Schließlich müssen zum Beispiel gesetzliche Anforderungen zu einem bestimmten Zeitpunkt im Produkt reflektiert werden. Das könnte noch vor der Zuweisung zu einem Team erfolgen, indem die Anforderung lediglich zu einem Release aber noch nicht zu einer Iteration zugeordnet wird.
Sonderfälle
Dieses Modell ist vereinfacht. Doch gerade darin liegt der Charme. Gerade bei der Einführung eines neuen Application-Lifecycle-Management-System wie dem Visual Studio Team System ist es wichtig einfach zu starten, um sich heranzutasten und genügend Potential für Veränderung und damit Optimierung zu haben.
Mögliche Erweiterungen und damit Erhöhung des Komplexitätsgrades:
- Teamspezifische Iterationen – Nicht alle Teams arbeiten mit den gleichen Iterationen
- Komponentenspezifische Releases – Verwendete, eigenentwickelte Komponenten werden in anderen Zyklen releast
- Trennung von Test und Entwicklung in verschiedene Teams – Entwicklerteam übergibt umgesetzte Anforderungen an Qualitätssicherungsteam, welches diese Umsetzungen testet
- Unterzustände für Einzelaktivitäten – Zusätzlich zu den oben beschriebenen grobgranularen Zuständen werden Aktivitäten wie "Specified", "Planned", "In Development", "System tested" usw. als Unterzustände verwendet
Auch für diese Erweiterungen lassen sich schlanke Lösungen mit dem Visual Studio Team System umsetzen. Diese sind allerdings Gegenstand spezifischer Betrachtungen von Fall zu Fall… zum Beispiel in einem Workshop mit dem AIT TeamSystemPro Team.