Team Foundation Services – Scrum-Template im Einsatz

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:

Team Foundation Services - Product Backlog

Die Spalten der Liste können nach eigenem Bedarf angepasst werden. Es stehen zahlreiche Möglichkeiten zur Verfügung:

Team Foundation Services - Product Backlog Columns

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:

Team Foundation Services - Item Detail

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:

Team Foundation Service - Prognose/Forecast

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:

Team Foundation Services - Product Backlog Board

Auch hier können die einzelnen Listen (Spalten) konfiguriert werden.

Team Foundation Services - Product Backlog Board Einstellungen

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:

Team Foundation Services - Sprint

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:

Team Foundation Services - Ressourcenplanung

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:

Team Foundation Services - Configure Schedsule and Iterations

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):

Team Foundation Services - Task hinzufügen

Aus den vorhandenen Backlog-Einträgen und den dazugehörigen Tasks wird automatisch ein Board generiert:

Team Foundation Services - Sprint Board

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:

Visual Studio - Add Team Foundation Server

Im Anschluss ist das gewünschte Team Project auszuwählen:

Visual Studio - Team Project auswählen

Nun kann via TeamNew Query eine Abfrage auf den aktuell geplanten Sprint vorgenommen werden:

Visual Studio - Work Items des aktuellen Sprints

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.

Visual Studio 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.

Veröffentlicht von Norbert Eder

Ich bin ein leidenschaftlicher Softwareentwickler. Mein Wissen und meine Gedanken teile ich nicht nur hier im Blog, sondern auch in Fachartikeln und Büchern.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Cookie-Einstellungen
Auf dieser Website werden Cookie verwendet. Diese werden für den Betrieb der Website benötigt oder helfen uns dabei, die Website zu verbessern.
Alle Cookies zulassen
Auswahl speichern
Individuelle Einstellungen
Individuelle Einstellungen
Dies ist eine Übersicht aller Cookies, die auf der Website verwendet werden. Sie haben die Möglichkeit, individuelle Cookie-Einstellungen vorzunehmen. Geben Sie einzelnen Cookies oder ganzen Gruppen Ihre Einwilligung. Essentielle Cookies lassen sich nicht deaktivieren.
Speichern
Abbrechen
Essenziell (1)
Essenzielle Cookies werden für die grundlegende Funktionalität der Website benötigt.
Cookies anzeigen