Der Microsoft Team Foundation Server 2013 zusammen mit Visual Studio unterstützt Sie bei der agilen Planung und Entwicklung einer Lösung mit Scrum. Ich zeige Ihnen die neuen Features und wie sie im Prozess eingesetzt werden können.

Scrum ist der De-Facto-Standard bei den agilen Entwicklungsmethoden. In den Schulungen und Kursen wird immer noch viel mit Flipcharts und Whiteboards gearbeitet. Dies ist zwar sehr haptisch und mag pädagogisch sinnvoll sein – in der Praxis hat es aber mehr Nach- als Vorteile. So eignen sich Whiteboards nicht für die Verwendung in agilen Teams, die Archivierung ist nur bedingt möglich und eine langfristige Zuordnung von Code, Metadaten und Anforderungen ist nicht möglich.

Der Microsoft Team Foundation Server (TFS) zusammen mit der Visual Studio Prozessvorlage für Scrum bringt alles mit, um Scrum in elektronische Form durchzuführen. Mit einem großen Touch-Display können Sie sogar das Kanban-Task-Board, das normalerweise mit dem Whiteboard umgesetzt wird, in elektronischer Form nutzen.

Dieser Post wird eine Serie und geht den ganzen Scrum-Prozess um dabei die entsprechenden Features vorzustellen, die Sie bei der Arbeit unterstützen können. Die Serie wird sich dabei in drei Teile mit folgendem Inhalt gliedern:

Part 1:

• Agiles Anforderungsmanagement
• Strukturierung der Anforderungen
• Portfoliomanagement

Part 2:

• Scrum-of-Scrums (SoS)
• Estimation / Backlog-Grooming
• Planning 1 und 2
• Daily Scrum
• Team-Room

Part 3:

• Monitoring / Reporting Progress
• Sprint-Review-Meeting
• Sprint-Retrospective-Meeting
• User Feedback

Alle Screenshots sind auf der Virtuellen Maschine der Visual Studio 2013 Application Lifecycle Management Virtual Machine and Hands-on-Labs / Demo Scripts gemacht worden. Diese virtuelle Maschine – zusammen mit den Hands-on-Labs – ist auch ein guter Startpunkt, wenn Sie einzelnen Features selber ausprobieren wollen.

Agiles Anforderungsmanagement

Zu Beginn jeden Projektes steht der Aufbau des Anforderungskatalogs, dem sogenannten Product-Backlog. Im Scrum erfolgt dies in sogenannten UserStories durch den Product-Owner. In der Prozessvorlage wird immer der Terminus „Product Backlog Item“ (PBI) verwendet. Dies ist allgemeiner und ermöglicht auch die Verwendung von anderen Arten der Anforderungsdokumentation (z.B. „Use Cases“). Dieser Artikel bleibt bei UserStories, da dies der Standard bei Scrum Projekten darstellt. Am bequemsten kann man diese im Portal hinzufügen (siehe Abbildung 1). Neue Anforderungen werden standardmäßig über der markierten Zeile eingefügt. Außer bei der letzten Zeile: ist diese markiert, wird die neue UserStory ans Ende gestellt. Nach dem Anlegen der UserStory kann diese per Drag & Drop an die gewünschte Stelle im Backlog geschoben werden. Das Backlog wird dabei immer so sortiert, dass die Anforderungen mit der höchsten Priorität ganz oben stehen.

Abbildung 1: Hinzufügen einer UserStory zum Backlog

Über einen Doppelklick können die Details der UserStory angezeigt werden (siehe Abbildung 2). Für die Verfeinerung der Anforderungen wird das Feld „Description“ verwendet. Dies beginnt bei UserStories standardmäßig mit dem Satz „Als <Rolle> möchte ich <Ziel>, damit <Nutzen>“. Darunter kann beliebig viel Freitext erfolgen und die Funktionalität zu beschreiben. Um die Anforderungen zu visualisieren können Mock-Ups in Form von StoryBoards mit PowerPoint erstellt und mit der User Story assoziiert werden. Außerdem können über „Attachments“ Dokumente wie Styleguiedes oder Wireframes anhängt werden. Wichtig sind die Akzeptanzkriterien (Acceptance Criteria). Sie beschreiben alle funktionales und nichtfunktionalen Anforderungen, die erfüllt sein müssen, damit die UserStory als abgenommen gilt.

Abbildung 2: Details einer UserStory

Eine UserStory kann während des Projektes von allen Beteiligten eingestellt werden. Der Product Owner – oder das Prodcut Owner Team – entscheidet, ob die UserStory angenommen wird oder nicht. Dies geschieht über den Status. Wird dieser von New auf Approved gesetzt, dann wird die User Story zur Umsetzung vorgesehen. Die bequemste Art zu tun, ist über das Kanban-Board (siehe Abbildung 3). Dieses Board ist auch Touch-Fähig und eignet sich für die Verwendung auf einem großen Touch-Display. Es ersetzt damit perfekt das Whiteboard.

Abbildung 3: Das Kanban-Board für das Product Backlog

Ist eine User Story freigegeben, dann muss der Product Owner einen Geschäftswert (Business Value) angeben. Dies hilft ihm auch bei der Priorisierung des Backlogs. Der Geschäftswert wird üblicherweise mit den Ziffern einer normalisierten Fibonacci-Folge analog den Aufwänden dargestellt (siehe capturing business value).

Ist die UserStory vom Product Owner soweit fertig gestellt, muss das Team die Aufwände schätzen. Dazu gibt es unterschiedliche Methode. Die wohl bekannteste ist das Planning Poker. Den Vorgang der Aufwandsschätzung nennt man auch Estimation. Wie beim Geschäftswert, ist bei allen Methoden das Ergebnis ein Wert einer normalisierten Fibonacci-Folge. Der Wert wird normal als StoryPoints bezeichnet. In der Aktuellen Prozessvorlage wird er als Effort bezeichnet. Es bietet sich an die Estimation mit dem Kanban-Board (siehe Abbildung 3) vorzunehmen. Die Zahlen auf den Kacheln sind der Effort. Er kann direkt auf dem Board ohne öffnen der UserStory editiert werden.

Vor jedem Sprint wird das komplette ProductBacklog geschätzt. Nach der Schätzung kann der Product Owner die Priorisierung erneut per Drag & Drop in der Backlog-View vornehmen.

Strukturierung der Anforderungen

In vergangen Versionen des TFS und bei Verwendung der „MSF for Agile“ Prozessvorlage, war es üblich, die UserStories nach Themen und Epen über Parent-Child-Beziehungen zu Strukturieren. Dadurch gewann das Backlog sehr an Übersichtlichkeit und zusammenhängende Anforderungen konnten als Block behandelt werden. Mit der aktuellen Version und der Scrum Prozessvorlage ist davon jedoch abzuraten. Parent-Child-Beziehungen führen im ProductBacklog zu merkwürdigen Effekten, wenn sie sich über mehrere Sprints oder Teams verteilen. Besser ist es jetzt mit Tags zu arbeiten (siehe Abbildung 2). Jeder Anforderung können beliebig viele Tags zugeordnet werden. Nach diesen Tags kann dann das Backlog gefiltert werden (siehe Abbildung 4). Die Filter können auch kombiniert werden, wenn in den Ergebnis weitere Tags enthalten sind. Die Tags helfen sehr dabei, große ProductBacklogs zu verwalten Anforderungen zu gruppieren.

Ab Visual Studio 2013 Update 2 (bei Erstellung des Artikel gerade als CTP2 verfügbar) kann man die Tags auch in WorkItem-Abfragen in Visual Studio und WebAccess verwenden.

Abbildung 4: Filtern des Backlogs nach Tags

Portfoliomanagement

Eine weitere Möglichkeit das Backlog zu strukturieren ist über das Portfoliomanagement (Features). Features existieren außerhalb eines Backlogs und können deshalb zur Strukturierung verwendet werden. Außerdem können über die Modifizierung der Prozessvorlage Features umbenannt oder um weitere Kategorien erweitert werden. Abbildung 5 zeigt eine mögliche Struktur eines Portfoliobacklogs. Es wird von Microsoft eine Struktur bis zu 5 Ebenen unterstützt. Für jede Ebene kann dabei frei der Name und die Farbe vergeben werden.

Abbildung 5: Möglicher Aufbau Portfolio-Backlog

Das Portfoliobacklog erreichen Sie, wenn Sie über Backlog auf „Features“ klicken. Über die Balken rechts neben „Backlog items“ und „Features“ können Sie wählen, welche Ebenen im Backlog angezeigt werden (siehe Abbildung 6). Sie können Features, Backlogitems und Tasks anzeigen. Auf allen Ebenen können Sie Tags zum Filtern der Daten verwenden. Über das Plus links neben einem Feature können Sie diesem direkt ein neues PBI zuordnen.

Features stellen eine gute Möglichkeit dar das Backlog zu strukturieren und Gruppen von Anforderungen zu verwalten.

Abbildung 6: Navigation im Portfolio Backlog

So viel erst mal zum Erfassen uns Strukturieren der Anforderungen. Im zweiten Teil wird es dann noch um die Aufteilung der Anforderungen auf mehrere Teams gehen. Außerdem geht es dann um die Gestaltung der ersten Meetings (Plannung, Daily und Estimation) und den Team Room.