ALM mit dem Team Foundation Server 2010: Weniger ist manchmal mehr

Application Lifecycle Management (ALM) ist die Zusammenführung von Business-Management und Softwareentwicklung. Es zielt auf eine Erhöhung der Produktivität, eine verbesserte Zusammenarbeit zwischen allen Beteiligten sowie eine gesteigerte Qualität ab. Seit 2010 stellt Microsoft dafür den Team Foundation Server 2010 (TFS) als Werkzeug und eine schlanke Prozessvorlage für Scrum zur Verfügung. Aber genügen die zur Verfügung gestellten Funktionalitäten den Anforderungen? Welche Funktionen kann und soll man verwenden?

 

Dieser Artikel setzt Grundkenntnisse in Scrum voraus und verwendet die englischen Begriffe für die bekannten Rollen, Meetings und Artefakte. Als Einstieg in Scrum dient beispielsweise „Scrum and XP from the Trenches“ von Henrik Kniberg [1].

 

TFS-Unterstützung

 

Eine grosse Stärke des TFS ist die Integration in Visual Studio 2010 (VS 2010), die Entwicklungsumgebung von Microsoft. Grundsätzlich unterstützt TFS ein Scrum-Team bei folgenden Aufgaben:

 

• Verwaltung von Anforderungen, Fehlern und Änderungswünschen
• Source-Control-Management
• Automatisierte Builds mit Qualitäts-überprüfung
• Erstellen von Reports (zum Beispiel Burndown-Charts)
• Nachvollziehen von Änderungen über den gesamten Lifecycle 

Ein TFS-Artefakt ist ein Requirement, ein Bug oder ein Akzeptanz- oder Systemtest. Artefakte werden in TFS „Work Items“ genannt. Sowohl die Struktur als auch die Zustände oder das Layout eines Artefakttyps können geändert und neue Artefakttypen erstellt werden. Um eine optimale Nachvollziehbarkeit zu gewährleisten, können die diversen Artefakte untereinander verlinkt werden. Ausgehend von einem Artefakt kann zu anderen Artefakten oder zu externen Dokumenten navigiert werden. Jede Änderung eines Artefakts wird automatisch versioniert und kann bei Bedarf nachverfolgt werden.

 

Durch diese automatische Versionierung und mit Hilfe der TFS-API lassen sich Informationen exportieren und mit Unternehmensstammdaten aus anderen Systemen kombinieren. Somit sind Leistungskennzahlen (KPI) wie Kostentransparenz per Feature, Change Request Impact oder objektive Kundenzufriedenheit einfach abrufbar.

 

Anwendung des TFS während eines Sprints 

 

Nachfolgend wird die exemplarische Anwendung von TFS in Scrum-Projekten anhand eines Sprints chronologisch aufgezeigt. 

 

Sprintvorbereitung durch Product Owner (PO) 

Das Product-Backlog bildet die Grundlage für die Entwicklung der einzelnen Softwarefunktionen. Am Anfang des Sprints steht die Verwaltung der Anforderungen in Form von User-Stories und Epics und deren Priorisierung. Epics sind grosse User-Stories, die noch nicht aufgeteilt und nicht ausreichend detailliert beschrieben sind. Typischerweise werden Epics nicht direkt umgesetzt, sondern werden zuerst in User-Stories aufgeteilt und näher spezifiziert.

 

Der Product Owner (PO) verwaltet die User-Stories und Epics als Work Items direkt in VS 2010. In der Praxis hat es sich bewährt, User-Stories bei Bedarf in eine Excel-Datei zu exportieren, diese zu bearbeiten und wieder in TFS zu importieren. Damit lassen sich UserStories sehr effizient priorisieren und einem Sprint zuweisen. Das vorhandene Web-Interface zu TFS lässt dabei noch zu wünschen übrig, und bisher konnten die Autoren keinen wesentlichen Nutzen daraus ziehen.

 

Sprintvorbereitung

Der Scrum Master klärt vor dem Planungsmeeting die Abwesenheiten der Entwickler ab und berechnet aufgrund der bisherigen Velocity die Story-Points, eine Schätzgrösse für den Arbeitsaufwand innerhalb von Scrum, die für das nächste Commitment möglich sind. Diese Anzahl Story-Points dient für das folgende Planungsmeeting in erster Linie als Richtwert. Die Berechnung der Velocity und des Richtwerts kann mit Papier und Bleistift erfolgen. Der Einsatz von TFS eignet sich dafür nicht. Für das Planungsmeeting hat es sich bewährt, die Stories auf kleine, etwa im Format A6 große Karten auszudrucken.

 

Planungsmeeting

Nachdem die Stories auf Karten ausgedruckt und gemäss ihrer Priorisierung geordnet sind, kann das Planungsmeeting stattfinden.

 

Der PO stellt zuerst die Stories vor und beantwortet Fragen und löst Unklarheiten auf. Falls nötig kann er auf die im TFS zur jeweiligen Story angehängten Dokumente und Zusatzinformationen zugreifen. Es hat sich aber gezeigt, dass dies in den meisten Fällen für das Verständnis nicht notwendig ist und der Einsatz des TFS während des Planning Meetings eine Ablenkung darstellt. Es ist einfacher, nur mit den ausgedruckten Karten zu arbeiten.

 

Im zweiten Teil des Planungsmeetings teilt das Team die einzelnen Stories in Tasks auf. Jeder Task wird einzeln auf einem Post-it festgehalten. Die einzelnen Tasks in TFS zu erfassen, bietet einen erhöhten Aufwand und eine Tendenz zum Mikromanagement. Da die Tasks nach dem Sprint sowieso nicht mehr relevant sind, empfiehlt es sich nicht, sie in TFS zu erfassen.

 

Die einzelnen Stories oder auch die einzelnen Tasks werden vom Team mittels Planning-Poker geschätzt [2]. Danach gibt das Team ein Commitment dafür ab, wie viele Stories im Sprint umgesetzt werden sollen. Der Scrum Master achtet dabei darauf, dass der zuvor berechnete Richtwert weder massiv unter- noch massiv überschritten wird.

 

Bevor der Sprint starten kann, müssen das Sprintboard aktualisiert und die Stories und die Tasks übersichtlich aufgehängt werden – manche Teams bestimmen dafür ein Teammitglied (Tracker).

 

Daily Scrum

Am Daily Scrum versammelt sich das Team vor dem Scrumboard und bespricht den aktuellen Stand der Fortschritte. Es ist entscheidend, dass das Scrumboard nach dem Meeting wieder den aktuellen Fortschritt der Arbeiten zeigt. Der Burndown-Chart, eine grafische Repräsentation der geleisteten Arbeit, kann anschliessend aktualisiert werden.

 

Softwareentwicklung

Als wichtigstes Element von TFS für die Entwicklung gilt sicherlich die Verwaltung des Source-Codes. Der TFS-Build-Server kann jedoch mehr und bietet mit der Unterstützung für Continuous Integration weitere wichtige Funktionen an. Dazu gehören die automatische Ausführung von Unit-Tests und die Berechnung verschiedener Metriken wie CodeCoverage. Es empfiehlt sich dabei, sich auf die notwendigen Metriken zu beschränken, um die Zeitdauer eines Builds nicht unnötig zu verlängern.

 

Im Zuge der Clean-Code-Bewegung ist es zudem ratsam, die Einhaltung der Clean-Code-Regeln von Anfang an automatisch zu überprüfen. Erst dadurch werden diese Regeln konsequent angewendet. TFS unterstützt dabei sowohl StyleCop und FxCop (auch CodeAnalysis), deren Regeln sich anpassen lassen.

 

Bei jedem Check-in kann zudem direkt angegeben werden, welche Story oder welcher Bug durch die Änderung betroffen ist. Dadurch bietet TFS eine wichtige Unterstützung für die Nachvollziehbarkeit von Änderungen.

 

Sprint-Review

Das Team präsentiert während des Sprint-Review-Meetings die geleistete Arbeit und erhält direkt Feedback von den anwesenden Stakeholdern und Benutzern. Oft passiert es, dass die Sprint-Review auf einem Rechner eines Entwicklers und nicht auf einer Integrations- oder Produktionsumgebung stattfindet. Dies kann dazu führen, dass die vorgestellte Software nicht den von Scrum geforderten Stand von „potentiell lieferbar“ hat. Die Software kann dann später nicht mehr ohne Weiteres in ein größeres System integriert oder tatsächlich geliefert werden.

 

Als Maßnahme hat es sich bewährt, schon sehr früh eine Umgebung für Continuous Deployment/Continuous Delivery aufzubauen. Wiederkehrende Aufgaben zu automatisieren ist ein wichtiger Bestandteil jedes agilen Vorgehens, und deshalb darf das entsprechende Wissen in keinem erfolgreichen Scrum-Team fehlen.

 

Retrospektive

Die Retrospektive dient dem Team dazu, Verbesserungsmöglichkeiten zu identifizieren. Diese Erkenntnisse aus der Retrospektive müssen zwingend festgehalten werden. Vor allem wenn mehrere Teams zusammen an einem Projekt arbeiten, helfen die Protokolleaus der Retrospektive das Verständnis zwischen den Teams zu fördern. Persönliche Themen sollten unseres Erachtens nicht in TFS gespeichert und ausschliesslich mündlich und teamintern gehalten werden.

 

Bugs

Auch mit dem besten Vorgehen können Bugs nicht verhindert werden. Folgendes hat sich bewährt: Bugs, welche im Zusammenhang mit dem laufenden Commitment stehen, sollten direkt am Taskboard notiert und nicht digital gespeichert werden. Im Gegensatz dazu werden Bugs, die zu früheren User-Stories gehören, in TFS erfasst. Diese Bugs fliessen in die Planung des nächsten Sprints mit ein.

 

Grundsätzlich gilt, dass Bugs so schnell wie möglich zu beheben sind. Insbesondere deshalb, weil Bugs zu früheren, sprich höher priorisierten User-Stories gehören. Letzten Endes liegt diese Entscheidung jedoch beim PO.

 

Fazit

 

Das reine Vorhandensein einer Funktionalität in TFS bedeutet nicht, dass es sinnvoll und effizient ist, diese auch einzusetzen.Weniger ist eben auch in der Softwareentwicklung oft mehr, und so ist das analoge Bearbeiten des Scrumboards schneller und intuitiver als das digitale Abarbeiten mit TFS. Der Team Foundation Server ist, richtig angewendet, ein sehr gutes Werkzeug für Application Lifecycle Management im Scrum-Umfeld.

 

Alain C. Boss und Roland Simon, www.bbv.ch

 

Diesen Artikel lesen Sie auch in der it management , Ausgabe 11-2011, Spezial it fokus  "Application Lifecycle Management".