Im Beitrag “Team Foundation Services – Unterstützung für Git unter der Lupe” habe ich mich bereits mit den Team Foundation Services beschäftigt – genauer gesagt mit der Unterstützung für Git. Dieser Beitrag wendet sich nun der Scrum-Prozessvorlage zu. Die Team Foundation Services bieten mehrere Prozess-Vorlagen, für mich ist zum aktuellen Zeitpunkt jedoch nur die Scrum-Vorlage wirklich interessant. Zu den weiteren Vorlagen wird es daher in diesem Beitrag keine zusätzlichen Informationen geben. Dabei ist für mich von Interesse, welche Funktionalitäten diese Vorlage tatsächlich anbietet und wie der Umgang damit hinsichtlich Verwendbarkeit ist.
Im Menüpunkt WORK finden sich die Zugänge zum Product Backlog, zum aktuellen Board und der mir zugeordneten Work Items.
Product Backlog
Im Product Backlog können sämtliche User Stories verwaltet werden. Dieses ist sehr einfach gehalten und zeigt neben der Reihenfolge auch den Titel, den Status, den Aufwand, den Iterationspfad und gesetzte Tags an:
Die Spalten der Liste können nach eigenem Bedarf angepasst werden. Es stehen zahlreiche Möglichkeiten zur Verfügung:
Einträge können in dieser Liste der Drag & Drop verschoben und so die Reihenfolge angepasst werden. Über das Zeilenmenü kann ein gewähltes Element geöffnet werden um Detailinformationen erfassen zu können:
Die Möglichkeiten an dieser Stelle sind vielfältig. Erfasst werden kann:
- Iteration
- Zugewiesene Person
- Status
- Grund
- Aufwand
- Business-Wert
- Backlog Priorität
- Beschreibung
- Storyboards
- Testfälle
- Aufgaben
- Akzeptanzkritierien
- Historie
- Links
- Anhänge
Bei der Eingabe von neuen Items wird eine Unterscheidung zwischen Backlog-Eintrag und Bug vorgenommen.
Auf Basis der eingetragenen Aufwände (Schätzungen whatever) kann auch eine Prognose erstellt werden. Diese ist in der Standardeinstellung deaktiviert, lässt sich jedoch durch einen einzigen Klick sofort aktivieren:
Im Standard wird eine Velocity (also Teamgeschwindigkeit) von 10 angenommen (in meinem Fall mit einer Person im Team des Tests). Dieser Wert kann entsprechend angepasst werden. Alle Backlog-Einträge werden daher entsprechend ihrer Reihenfolge in Sprints unterteilt. Dadurch ergibt sich natürlich auch eine schöne Sicht, wie viele Sprints für die gesamte Umsetzung des Backlogs benötigt werden.
Für das Product Backlog steht ebenfalls eine Board-Ansicht zur Verfügung. Diese zeigt die Einträge aus dem Backlog und ihren Status an:
Auch hier können die einzelnen Listen (Spalten) konfiguriert werden.
Auf diese Einstellungen sollte unbedingt ein Blick geworfen werden, da wohl nicht sehr viele mit einem vordefinierten WIP-Limit arbeiten wollen.
Sprints verwalten
Über das Kontextmenü oder aber das Zeilenmenü können einzelne Einträge bestimmten Iterationen zugeordnet werden (eine Mehrfachauswahl scheint nicht möglich zu sein). Die Änderung wird sofort im Product Backlog ersichtlich. Gleichzeitig wird der gewünschte Sprint aktualisiert. Ein mögliches Ergebnis kann wie folgt aussehen:
In der Headerleiste ist nun zu sehen, dass noch keine Sprintdaten erfasst wurden. Unter Set Date können nun das Start- und Enddatum des aktuellen Sprints gesetzt werden. Ebenfalls ist zu beachten, dass diese Liste eine weitere Ausprägung Capacity hat. Darunter können die Ressourcen für diesen Sprint geplant werden:
In diesem Beispiel ist schön zu sehen, dass die Ressourcen für die Umsetzung nicht ausreichen. Dies wird sofort zur Ansicht gebracht und kann für die Anpassung der Planung verwendet werden.
Eine Gesamtplanung der Releases und dazugehörigen Sprints ist auf der Overview unter dem Menüpunkt Configure schedule and iterations verfügbar. Dies sieht dann so aus:
In der ersten Liste besteht nun die Möglichkeit, jedem Backlog-Item Tasks hinzuzufügen, dies erfolgt über das + Icon. Die auszufüllenden Felder entsprechen denen eines Backlog-Eintrages, anstatt eines Aufwandes wird der verbleibende Aufwand eingetragen (diese erfolgen in Stunden):
Aus den vorhandenen Backlog-Einträgen und den dazugehörigen Tasks wird automatisch ein Board generiert:
Dieses zeigt übersichtlich den aktuellen Stand an und kann natürlich dazu verwendet werden, den Status der einzelnen Punkte zu verändern.
Eine für mich interessante Frage ist nun: Muss ich als Entwickler die Punkte im Board verschieben, oder funktioniert das auch direkt via Visual Studio. Der Vorteil läge natürlich darin, dass ich mein Hauptwerkzeug nicht verlassen muss. Ein weiterer Vorteil läge darin, dass dieser Schritt bei einer automatischen Durchführung nicht vergessen werden kann und das Board somit tatsächlich immer aktuelle sein würde.
Team Foundation Services via Visual Studio
Um nun mit den Work Items etc. der Team Foundation Services arbeiten zu können, ist das Service zu verbinden. Hierzu ist ein “Team Foundation Server” hinzu zu fügen. Die URL entspricht dem Link zum eigenen Workspace:
Im Anschluss ist das gewünschte Team Project auszuwählen:
Nun kann via Team – New Query eine Abfrage auf den aktuell geplanten Sprint vorgenommen werden:
Alle relevanten Work Items können damit abgegriffen werden.
Es werden automatisch Shared Queries angelegt, welche über Visual Studio abgegriffen werden können. Diese betreffen den aktuellen Sprint, d.h. eine obige Query muss nicht zwingend vorgenommen werden. Zu den Queries gelangt man via Team Explorer und Work Items.
Mit den Work Items kann nun direkt aus Visual Studio gearbeitet werden.
Änderungen werden nicht automatisch an ein Changeset gehängt, dies kann aber sehr einfach durch einen Link vom Work Item auf das jeweilige Changeset (oder mehrere) vorgenommen werden.
Alle gemachten Änderungen sind sofort online ersichtlich.
Fazit
An einigen Stellen hakt es schon noch ein wenig. So würde ich mir wünschen, dass sich ein Work Item automatisch an das jeweilige Changeset (oder an die Changesets) hängt. Auch die Git-Integration im Team Explorer braucht definitiv noch Verbesserungen hinsichtlich der Usability. Insgesamt lässt es sich aber ganz gut damit arbeiten. Jetzt fehlt noch ein Test mit einer Real-World-Solution und der Preview Funktionen hinsichtlich Build und Test Cases. Bis jetzt sehe ich jedoch keinen Grund der gegen die Nutzung der Team Foundation Services mit Git-Repository spricht.