Agile-Entwicklung

Verwenden von Agile in TFS 2010

Chris Adams

In diesem Artikel wird beschrieben, wie ein Team mit TFS (Team Foundation Server) 2010 zu Agile wechselt.

Im Agile-Manifest werden mehrere Stichwörter genannt, die die angestrebte Zusammenarbeit in Agile-Teams charakterisieren. Zu den agilen Werten gehört, dass Einzelpersonen und deren Interaktionen wichtiger als Prozesse und Tools sind. Diese Werte sind einer der Gründe dafür, dass Teams sich für einen Wechsel zur Agile-Entwicklung entscheiden. In den zehn Jahren, die ungefähr seit dem Manifest vergangen sind, haben sich verschiedene Arten von Agile entwickelt. Ich gehe später auf einige Optionen in TFS 2010 ein, die Ihnen die Möglichkeit bieten, eine der zwei Arten von Agile-Prozessvorlagen zu übernehmen, und erläutere deren Verwendung durch unser Team bei Microsoft.

Ein Hauptziel bei der Neuorganisation unseres Softwareentwicklungsteams hier bei Microsoft vor einigen Jahren war die Nutzung von Tools, die von Ihnen, unseren Kunden, verwendet werden können. Deshalb kamen interne, schon seit Jahren bei Microsoft genutzte Tools nicht in Betracht. Das Entwicklungsteam ist Bestandteil der Management & Security Division (MSD). Hauptaufgabe des Teams ist das Erstellen von Software, die es Microsoft ermöglicht, Dienste für eine Vielzahl von Benutzern bereitzustellen: IT-Benutzer, IT-Administratoren und -Techniker sowie Onlinedienstanbieter. Kurz gesagt, unser Team ist möglicherweise genau wie Ihres. Es stellt Software zur Erweiterung oder Verbesserung der Geschäftsvorgänge her, auf die die Kunden sich verlassen.

Vor der Einführung von Agile maßen wir den Kundenrückmeldungen zu geringe Bedeutung bei, im Team bestanden aufgrund von Titeln künstliche Grenzen zwischen den Mitgliedern, und wir konnten dem Managementteam keinen genauen Status melden. Ohne eine Veränderung wäre unsere Gesamteffektivität bis zu einem vollständigem Misserfolg gesunken.

Bei unserem Übergang zu Agile sollten daher unsere Interaktionen miteinander sowie mit unseren Kunden und zum Schluss unser Prozess im Mittelpunkt stehen. Vor diesem Wechsel waren wir auf die umgekehrte Reihenfolge ausgerichtet: Prozess, Kunden und anschließend Interaktionen. Als Ergebnis der letzten zwei Jahre steht heute die Leistungsfähigkeit unseres Teams im Vordergrund. Wir richten unsere Aufmerksamkeit wieder auf die Kunden und auf die Ausführung von optimalen Lösungen zum richtigen Zeitpunkt. Ich möchte Ihnen das erläutern.

Es kann bei Ihnen genauso gut funktionieren wie bei uns

Wir sind ein normales Softwareteam. Wir sind ein junges Team, und wir möchten Software mit hoher Qualität entwickeln, die einen direkten Unternehmenswert generiert. Keiner von uns ist länger als drei Jahre in diesem Team. Und wie schon erwähnt, hatten wir mit Problemen zu kämpfen.

Im März 2010 beschlossen wir, Änderungen in Angriff zu nehmen. Wir benötigten ein System, das für uns anstatt gegen uns arbeitete. Es sollte uns ermöglichen, uns auf das Schaffen von Werten für die Kunden zu konzentrieren. Das System sollte außerdem über das gesamte Team und die größere Organisation hinweg auf verschiedenen Ebenen Möglichkeiten zur Fortschrittsüberwachung und -verfolgung bereitstellen.

Wir wollten mit der Agile-Methode entwickeln, wussten aber nicht, wie.

Einführung in MSF Agile, Version 5.0

Wir lernten TFS 2010 bereits im Betastadium kennen und entschieden uns, eines unserer Projekte mit Microsoft Solutions Framework Agile, Version 5.0, zu erstellen (im Folgenden kurz als MSF bezeichnet). Wir benötigten eine Prozessvorlage, die uns bei der Ausführung unserer Kernziele unterstützte: effektive Produktplanung und Sprintplanung, ein Arbeitsrhythmus für die Entwicklung und, was am wichtigsten ist, mehr Interaktion zwischen den Entwicklern, Testern und Programmmanagern (PMs). Der Lebenszyklus (siehe Abbildung 1) in MSF Agile war genau, was wir suchten.

Abbildung 1 Der MSF Agile-Prozess

MSF Agile bietet verschiedene Arbeitsaufgabentypen (Work Item Type, WIT) zur Unterstützung in Agile. Wir untersuchten zunächst jeden WIT (wie in Abbildung 2 definiert), um herauszufinden, wie diese effizient verwendbar sind. Alle im Artikel genannten Optionen beziehen sich auf Versionen in englischer Sprache.

Abbildung 2 Definitionen von Arbeitsaufgabentypen in MSF Agile

Arbeitsaufgabentyp	Zweck
User Story	Verfolgt eine Aktivität, die die Benutzer mit dem Produkt ausführen können.
Task	Verfolgt Aufgaben, die erledigt werden müssen.
Bug	Beschreibt eine Abweichung zwischen dem erforderlichen und tatsächlichen Verhalten, erfasst die durchgeführten Schritte zur Korrektur des Fehlers und überprüft die Korrektur.
Issue	Erfasst ein Hindernis für den Fortschritt.
Test Case	Beschreibt eine Reihe von Schritten und erwarteten Ergebnissen, die getestet werden sollen.
Shared Steps	Definiert eine wiederverwendbare Reihe von Testschritten und -ergebnissen.

Ein wichtiger Aspekt ist, dass wir zwar jeden WIT untersuchten, zunächst aber nicht alle davon verwendet haben. Wir haben uns stattdessen auf die Typen User Story, Task und Bug konzentriert. Erst mehrere Monate oder sogar ein Jahr später haben wir weitere WITs eingeführt, zum Beispiel den Test Case. Den Issue-WIT verwendet unser Team bis heute noch nicht, aber deshalb kann er sich trotzdem für Sie eignen. Wie viele Teams, die sich Agile aneignen, haben wir verwendet, was uns gefiel, und andere Typen verworfen. Das Wesentliche dabei ist, dass nicht jeder die Agile-Softwareentwicklung in vollem Umfang verwendet, und TFS 2010 stellt mit der MSF Agile-Vorlage die entsprechende Flexibilität bereit.

Nutzen des User Story-WITs zur Steigerung des Geschäftswerts

Wir machten nach einiger Zeit die Erfahrung, dass sich ein Agile-Team intensiv mit User Storys beschäftigen muss. Unsere User Storys waren ziemlich lang und umfassten mehrere Iterationen. Es gab mehr durch Themen begründete Aufgaben als durch einen inkrementellen Wert begründete User Storys.

Wir stellten dann fest, dass eine gute User Story drei Hauptelemente aufweist. Zuerst beschreibt der Titel kurz, wovon die User Story handelt. Die Verwendung eines kurzen Titels erleichtert das Stapeln der User Storys nach Rang, da das Scannen kurzer Titel einfacher ist. Als zweites folgt die Beschreibung, die den Kontext für die User Story in folgendem Format enthält: „Als ein <Benutzertyp> möchte ich <ein Ziel>, damit <ein Grund>“. Also: Warum und für wen wird ein Wert hinzugefügt? Dies ist der Wert für den Kunden! Drittens folgen die Akzeptanzkriterien. Diesen Wert lernten wir erst später, als wir zur Prozessvorlage von Microsoft Visual Studio Scrum 1.0 wechselten (im Folgenden kurz als Scrum 1.0 bezeichnet). Durch die Akzeptanzkriterien erhält das Team Klarheit darüber, was als Lieferung geplant ist.

Während wir mit der Einführung von Agile fortfuhren, erwarben wir mehr Wissen über User Storys und die Kommunikation mit den Beteiligten und Kunden. Wir konnten uns nicht einfach auf das Schreiben tragfähiger User Storys beschränken. Wir mussten auch diskutieren, ob unser Team diese korrekt nach Rang gestapelt hatte. Das Ergebnis hiervon war, dass wir uns durch produktive Gespräche mit den Kunden über die Arbeitsreihenfolge als Team weiterentwickelten.

Softwareteams wie unseres entscheiden oft selbst, was wichtig ist. Im Gegensatz dazu wird im Agile-Manifest betont, dass sich alles um den Kunden dreht. Zum Schließen dieser Lücke dient das Stapelrangfeld in dem User Story-WIT, welches die Reihenfolge definiert, in der wir daran arbeiten, Werte zu erstellen. Wir sprechen mit den Kunden und Partnern über dieses Feld, um die Rangfolge abzustimmen. Die Beteiligten und Kunden verwenden eine einfache TFS-Abfrage, um eine geordnete Liste der Arbeiten anzuzeigen, die zur Erfüllung der Anforderungen des Kunden geliefert werden müssen. Ich gehe später darauf ein, dass die Liste auch auf dem Dashboard veröffentlicht wird.

Planen von Iterationen in MSF Agile

In der Vergangenheit gab es keine oder kaum eine Vorwarnung für das Team, wenn Größe und Umfang von Features zunahmen. Dieses Problem wollten wir überwinden. Wir wollten uns außerdem auf Werte anstatt auf Features konzentrieren. Wir mussten die Arbeit genau planen, die richtige Menge an Ressourcen zuordnen und Unterbrechungen effektiv berücksichtigen.

In Agile-Teams wird die Arbeit in Iterationen mit einer festen Länge aufgeteilt. Aber wie lang soll eine Iteration sein? Nach einigen Diskussionen entschieden wir uns für vierwöchige Iterationen, da wir davon ausgingen, sozusagen auslieferungsbereite Software nicht in kürzerer Zeit liefern zu können. Einige Iterationen später stellten wir fest, dass es schwierig war, so viel Arbeit innerhalb einer Iteration zu leisten, daher wechselten wir versuchsweise zu sechs Wochen. Dabei wurde allerdings die Rückmeldungsschleife mit den Kunden zu lang, woraufhin wir zurück zu den vierwöchigen Iterationen wechselten. Vor ungefähr 10 Monaten gingen wir zu zweiwöchigen Sprints über, um schneller Rückmeldungen zu erhalten.

Nachdem wir die User Storys mit dem größten Wert für die Kunden ausgewählt hatten, wiesen wir sie zu Iterationen zu. Das Team musste sich auf die Erstellung kleiner, inkrementeller Komponenten anstelle von großen, häufig monolithischen Features einstellen. Durch die kleineren Komponenten konnte die Arbeit genauer geschätzt werden, beispielweise in 5-10 Stunden dauernden Schritten. Auch die Effektivität der Tester wurde gesteigert, da sie aufgrund der kleineren Komponenten häufig kurze Testzyklen hatten.

Mit dem Blick auf die Ressourcen verwandte das Team gewöhnlich viel Zeit für den „Entwurf“ der Features und die nachfolgend für deren Erstellung anfallenden Kosten. In MSF Agile ersetzten wir diese Vorgehensweise dadurch, dass wir Story Points für jede Story und anschließend das Original Estimate-Feld verwenden, um einen Wert für die Arbeit festzulegen. Wir haben diese Schätzungen in unserer Sprintplanung mithilfe von Planning Poker durchgeführt. Weitere Informationen zu Planning Poker erhalten Sie unter planningpoker.com. Für den täglichen Vergleich der Fortschritte mit den Iterationszielen mussten die Teammitglieder jeden Tag die Completed Work- und Remaining Work-Felder aktualisieren (siehe Abbildung 3).

Abbildung 3Verwalten von Planungsschätzungen in MSF Agile

MSF Agile-Feld	Zweck
Original Estimate	Initialwert für die verbleibende Arbeit. Wird bei Arbeitsbeginn einmalig festgelegt.
Remaining Work	Geschätzte Anzahl der bis zum Abschluss einer Aufgabe verbleibenden Arbeitsstunden.
Completed Work	Die Anzahl der für eine Aufgabe verwendeten Arbeitsstunden.

Dies ist die Basis für die genaue Erfassung der täglichen Arbeit, und wir stellten fest, dass wir uns verbesserten und effizienter wurden, während wir uns als Agile-Team weiterentwickelten.

Im weiteren Verlauf wurde die tägliche Aktualisierung der Arbeitsschätzwerte zur Gewohnheit und Bestandteil des normalen Prozesses.

MSF Agile-Überwachungstools für die Produktplanung und den Iterationsrückstand

Mithilfe der Arbeitsmappe zur Produktplanung und der Arbeitsmappe „Iteration Backlog“ in MSF Agile (siehe Abbildung 4) konnten wir die Arbeitsmenge, die wir annehmen und erfolgreich abschließen konnten, besser einschätzen.

Abbildung 4Arbeitsmappenvorlagen für die Planung in MSF Agile

Wir ließen uns von Fehlschlägen während der ersten Iterationen nicht entmutigen, sondern konzentrierten uns auf die Verbesserung. Während der Planung der Iterationen im Team verwendeten wir die Arbeitsmappe zur Produktplanung, um User Storys zu Iterationen zuzuordnen. Um Zeit zu sparen, legten wir die Iterationen möglichst vor dem Beginn der Sprintplanung fest. Weitere Informationen zum Erstellen von Iterationen erhalten Sie unter bit.ly/lakyZA. Durch unsere Erfahrungen mit der durchschnittlichen Geschwindigkeit des Teams (wie viele Story Points wir in früheren Iterationen abgeschlossen hatten) verbesserten wir das Ausgleichen von Storys zwischen Iterationen im Hinblick auf die Fertigstellung zu einem bestimmten Datum.

Einer der wertvollsten Aspekte unseres Übergangs zu Agile hängt direkt mit der Verwendung der Arbeitsmappe „Iteration Backlog“ zusammen. Diese Arbeitsmappe enthält mehrere Microsoft Excel-Registerkarten zur Unterstützung der Iterationsplanung, deren jeweiligen Zweck ich nun erläutere.

Die Arbeitsmappe zeigt auf der ersten Registerkarte, „Iteration Backlog“, die User Storys und alle zu diesen gehörenden Folgeaufgaben. Die Registerkarte ist mit einer TFS-Strukturabfrage verbunden. So können Sie die User Story und alle Aufgaben als untergeordnete Elemente in einer vertrauten Strukturansicht ansehen. Weitere Informationen zu Strukturabfragetypen erhalten Sie unter bit.ly/l0tv1K. Sie müssen die Abfrage für jeden Sprint aktualisieren, damit auf der ersten Registerkarte alle Elemente angezeigt werden, die einer Iteration aktuell zugeordnet sind. Sie können Daten auf der Registerkarte ändern und erneut auf dem TFS-Server veröffentlichen, ohne Excel zu beenden, und so haben wir die Aufgaben unter einer User Story während der Sprintplanung erstellt. Weitere Informationen hierzu erhalten Sie unter bit.ly/lmPN4k.

Auf der zweiten Registerkarte, „Area & Iteration“, können Start- und Enddatum und der Iterationspfad für die Iteration festgelegt werden, wie in Abbildung 5 gezeigt.

Abbildung 5 Start- und Enddatum in der Arbeitsmappe „Iteration Backlog“ in MSF Agile

Sie können den Bereichspfad bei komplexen Projekten nutzen, um den Umfang der Arbeitsmappe zu bestimmen. Wir als kleineres Team machen auf dieser Ebene selten davon Gebrauch. In einem größeren Team mit mehreren Bereichen verfügen Sie wahrscheinlich über Kopien der Arbeitsmappe für jeden Bereichspfad.

Die dritte Registerkarte ist „Interruptions“. Hier können Sie freie Tage wie Urlaubstage oder Feiertage berücksichtigen, an denen die Teammitglieder nicht am Projekt arbeiten. Sie können hier aber nur Unterbrechungen für Teammitglieder festlegen, die derzeit zu einer Arbeitsaufgabe in der Iteration zugeordnet sind. Sie sollten also vor dem Bearbeiten dieser Registerkarte sicherstellen, dass Sie die Arbeit korrekt in Aufgaben unterteilt haben und die Teammitglieder auf der ersten Registerkarte, „Iteration Backlog“, zugeordnet haben, andernfalls ist die Dropdownliste der Teammitglieder leer.

Die vierte Registerkarte ist für unser Team sehr nützlich. Diese Registerkarte namens „Capacity“ stellt anhand der verbleibenden Arbeit und Tage Informationen zu Über- und Unterkapazitäten für jedes Teammitglied bereit. Die bereits erwähnte Registerkarte „Interruptions“ wird auf dieser Registerkarte berücksichtigt.

Mithilfe der Registerkarte „Capacity“ wird ein Ausgleich der Belastungen viel einfacher, indem Aufgaben zwischen Teammitgliedern verschoben werden. Vor Agile hatte uns als Team die Möglichkeit gefehlt, diese Neuzuordnung zu einem frühen Zeitpunkt vorzunehmen, anstatt in letzter Minute darum zu ringen, wenn es oft schon zu spät war.

Die Arbeitsmappe verwendet zum Berechnen der Kapazität die gesamte tägliche Kapazität (Stunden pro Tag) jedes Teammitglieds und multipliziert diesen Wert mit der Anzahl der in der Iteration verbleibenden Tage. Wie in Abbildung 6 gezeigt, wissen wir als Ergebnis vom ersten Tag der Iteration an (zum Beispiel der Iterationsplanung), wo wir stehen.

Abbildung 6 Teamkapazitätsplanung in MSF Agile

Wir berücksichtigen die dynamische Ansicht in unseren täglichen Einsatzbesprechungen. Im Falle von Abbildung 6 ist jedes Teammitglied über seiner Kapazität. Für das Team wird deutlich, dass nicht die gesamte in dieser Iteration geplante Arbeit abgeschlossen werden kann.

Ich habe eine exemplarische Vorgehensweise zur Verwendung der Arbeitsmappe erstellt und weitere Informationen in meinem Blog unter bit.ly/fZpzWx veröffentlicht.

Teamspezifische Anpassungen

Die Softwareerstellung beschränkt sich nicht immer auf ein einziges Team. In der Praxis arbeiten normalerweise mehrere Teams zusammen. Bei der Softwareentwicklung in mehreren Teams stellen die verschiedenen Teamprozesse eine Herausforderung dar. Manche Teams gehen bei der Softwareentwicklung nach dem Wasserfallmodell vor, während andere Scrum verwenden. Die Einmaligkeit jedes Teams führt oft zu Problemen, was auch unser Team betraf. Es war kein isoliertes Team. Stattdessen erforderte eines unserer ersten Projekte mit MSF Agile Interaktionen zwischen zwei Teams, die verschiedene Iterationslängen und verschiedene Formatvorlagen verwendeten, obwohl beide Agile-basiert waren. An diesem Punkt wurde unser Team durch die Flexibilität von TFS 2010 unterstützt, das eine umfangreiche und leistungsstarke Möglichkeit zur Anpassung jedes WITs und sogar zur Neuerstellung eines WITs bietet. Wir mussten keinen neuen WIT erstellen, sondern nur einen vorhandenen optimieren.

Wir entwickelten in Zusammenarbeit mit dem Microsoft Deployment Toolkit (MDT)-Team ein neues Feature namens „User-Driven Installation“ (bit.ly/kjySZk). Es versetzt Endbenutzer in die Lage, ihre Windows 7-Desktops oder Laptops zu ändern. Das MDT-Team nutzte Scrum und hatte systemeigene, nur intern bei Microsoft verfügbare Tools im Einsatz, während unser Team TFS 2010 verwendete. Des Weiteren handelte es sich bei einem großen Teil der Interaktionen zwischen den Teams um Fehler, da unser Team neue Features und Fehlerbehebungen lieferte und das MDT-Team für alle Tests zuständig war.

Die Teams arbeiteten während mehrerer Iterationen zusammen, aber bei den ersten paar Iterationen erwies es sich als schwierig, das festgelegte Ergebnis (zum Beispiel auslieferbare Software) zu erreichen. Unsere Geschwindigkeit war niedrig. Unser Team hatte Agile vor der Zusammenarbeit mit unserem Partner seit mehreren Monaten verwendet, und wir hatten einen Rhythmus, in dem wir unsere Iterationen mit vollständig abgeschlossenen Arbeiten fertigstellten. Warum produzierten wir plötzlich nicht mehr alles, was wir für den Sprint geplant hatten?

Die Veränderung bestand ironischerweise darin, dass unsere Sprintplanung keine Schätzungen für Fehler enthielt. Wir übernahmen daher häufig neue Features mit all den Fehlern, mit deren Behebung das Partnerteam uns beauftragte. Da der Bug-WIT keine zeitbasierten Felder wie „Remaining Work“ und „Completed Work“ aufwies, enthielt unser Burndowndiagramm nie einen Hinweis auf die Arbeiten, die nicht abgeschlossen werden würden.

Mit den Anpassungsfeatures in TFS 2010 wurde die Optimierung dieses WITs für unsere Bedürfnisse ziemlich einfach. Wir änderten unseren Bug-WIT so, dass er die Zeitfelder enthielt, fügten sie dem Bug-Formular hinzu und konnten anschließend sowohl Fehler als auch Aufgaben im Burndowndiagramm der Iterationen verfolgen. Weitere Informationen darüber, wie Sie benutzerdefinierte Felder wie beispielsweise Planungsfelder zu einem WIT hinzufügen, erhalten Sie in meinem Blog unter bit.ly/gb1BOb.

Integration von TFS und Windows SharePoint Services

Wie Sie wissen, mussten wir die Fähigkeit unseres Teams verbessern, Fortschritte zu verfolgen und an das Team, unsere Partner und unser Management zu berichten.

TFS 2010 bietet integrierte Funktionen zur Nutzung eines neuen oder vorhandenen Windows SharePoint Service (WSS). Beim Erstellen eines MSF Agile-Projekts ist auf Wunsch die Erstellung einer SharePoint-Website mit einem nützlichen und anpassbaren Dashboard enthalten. Wir nutzten die mit TFS gelieferten integrierten Dashboards zur weiteren Verbesserung unserer Kommunikation innerhalb des Teams und mit den Kunden. Der überzeugende Aspekt des Dashboards und der SharePoint-Integration war die Flexibilität. Zum Beispiel bot das Dashboard, das im TFS-Standardprojekt inbegriffen war, nicht jeden Aspekt, den wir uns in der Dashboardansicht wünschten. Wir wollten weitere Informationen anzeigen.

Mit den Dashboards konnten wir uns von den täglichen E-Mails mit Fortschrittsberichten zu den Themen Burndown, Geschwindigkeit und Fehleranzahl trennen und statt dessen unserem Management und den Partnern Zugriff auf unsere SharePoint-Website geben, wo sie unsere Fortschritte fast in Echtzeit verfolgen konnten.

Wie in jeder Organisation wünschen sich bei uns verschiedene Mitarbeiter ihren Interessen entsprechend unterschiedliche Informationen in den Ansichten. Wir haben unserem Dashboard bei der Anpassung zusätzliche Berichte hinzugefügt, die standardmäßig nicht auf dem Dashboard aktiviert waren. Zum Beispiel besprechen sich das Managementteam und unser Team während des Lebenszyklus der Agile-Projekte monatlich, um die von uns erledigte Arbeit durchzugehen und uns eine Rückmeldung zu geben. Bei einer dieser Besprechungen äußerte ein wichtiger leitender Mitarbeiter den Wunsch, die von uns bearbeiteten User Storys, unseren Fortschritt und User Storys im Rückstand, die derzeit nicht im Sprint enthalten waren, zu sehen. Wie wir das Dashboard nutzten, um dieser Anforderung der Leitung zu entsprechen, erfahren Sie in meinem Blogbeitrag unter bit.ly/jJ6XUp.

Profitieren Sie von der Leistungsfähigkeit von SharePoint und TFS 2010-Projekten

Wenn Sie oder Ihr Unternehmen bereits eine Enterprise-Version von Microsoft Office SharePoint Server (MOSS) besitzen, dann können Sie eine neue, leistungsfähige Funktionalität nutzen, indem Sie mit MOSS verknüpfte MSF Agile-Projekte verwenden. Wie bereits erwähnt, wird TFS 2010 mit WSS geliefert, aber in WSS sind einige nützliche Funktionen für Unternehmen nicht enthalten.

Wir wollten einige der großartigen Excel-Berichte verwenden, die im Umfang von MSF Agile enthalten sind. Die in Abbildung 7 gezeigten Berichte stellen viele Funktionen bereit, darunter auch die Excel-Webdienste (Excel Web Services, EWS). Diese dienen dazu, die Berichte und deren Daten in Webparts auf den Projektdashboards zu hosten.

Abbildung 7 Excel-Berichte in MSF Agile

Diese Funktionalität ist nur verfügbar, wenn Ihr Team für das Teamprojekt mindestens einen SharePoint 2007- oder SharePoint 2010 Enterprise-Server nutzen kann.

Wenn TFS 2010 während der Erstellung eines MSF Agile-Projekts einen SharePoint Enterprise-Server erkennt, erstellt es ein Dashboard, das sowohl EWS-Berichte als auch SQL Server Reporting Services (SSRS)-Berichte enthält. Durch diese Flexibilität konnten wir von vielen Funktionen profitieren. Wir hatten die Möglichkeit, Berichte wie beispielsweise „Code Churn“ und „Bugs by Assignment“ zusammen mit MSF Agile-Berichten wie „Burndown“ und „Burn Rate“ zu verwenden.

Ein Hauptthema für unser Team während der Verwendung des SharePoint-Dashboards war die Verwaltung, insbesondere, wer die Aufgabe übernehmen sollte, die Berichte auf dem Dashboard auf dem neuesten Stand zu halten. Als beispielsweise das Team mit Iterationen im Zweiwochenintervall arbeitete, mussten Start- und Enddaten für den Burndown alle zwei Wochen aktualisiert werden, damit das Dashboard aktuell war. Wir verwalteten das Dashboard mehrere Monate lang. Mit der Zeit suchten wir aber nach Lösungen zur Automatisierung der Erstellung dieser Berichte oder nach einer einfacheren Methode zum Verfolgen der Iterationen. Seit dem Beginn unserer Umstellung war fast ein Jahr vergangen, als Scrum 1.0 veröffentlicht wurde. Scrum kann unter bit.ly/fdojaD heruntergeladen werden.

Agile: Retrospektiven sind von großer Bedeutung

Während wir uns mit der Zeit als Agile-Team weiterentwickelten, verbrachten wir unzählige Stunden zusammen, in denen es darum ging, unser Team, den Prozess und die Ausführung zu verbessern. Das geschah normalerweise, wenn wir die Iterationen abgeschlossen hatten, und endete mit dem Sprintrückblick (im Vergleich mit den Sprintzielen) und den Retrospektiven. Agile-Teams können Retrospektiven leicht übersehen. Das kam in unserem Team manchmal vor, und wir mussten uns den Retrospektiven erneut zuwenden.

In MSF Agile bietet TFS die Möglichkeit, Retrospektiven über eine Iterationsrückstandsvorlage auf der SharePoint-Website des Projekts zu überwachen. Mit dieser Arbeitsmappe können Sie verfolgen, wie schnell die Arbeit voranging, was gut ausgeführt wurde und was in Zukunft verbessert werden kann (siehe Abbildung 8).

Abbildung 8 MSF Agile-Iterationsrückstandsvorlage

Unser Team war stolz darauf, nicht nur in Retrospektiven die Verbesserung im Blick zu haben, sondern auch kontinuierlich alle Arbeiten erneut zu bewerten. Wir lernen zwar viel im Rückblick, optimieren aber auch die Agile-Prozesse im Zuge der weiterentwickelten Technologie. In unserem Fall entwickelte sich TFS weiter, als Microsoft eine neue Prozessvorlage namens Scrum 1.0 veröffentlichte, die wir unmöglich ignorieren konnten, sondern gerne verwendeten.

Unser Übergang zu Scrum 1.0

Unser Team strebt zwar nicht danach, strikt nach dem Scrummodell zu arbeiten, ähnelt aber in vieler Hinsicht einem Scrumteam. Bevor wir MSF Agile einsetzten, nutzten wir Begriffe wie beispielsweise „Product Backlog Items“ (PBIs) und gingen dann zu User Storys über.

Wie vorher wählten wir zur Evaluierung der neuen Scrum 1.0-Prozessvorlage ein kürzeres Projekt aus. Ähnlich wie bei der Einführung von MSF Agile machten wir uns mit den WITs vertraut, die in der Scrum 1.0-Vorlage verfügbar waren. Wie Sie in Abbildung 9 sehen können, unterscheidet sich die Terminologie ein wenig, aber viele der Konzepte sind ähnlich.

Abbildung 9 Definitionen von Arbeitsaufgabentypen in Scrum 1.0

Arbeitsaufgabentyp	Zweck
Product Backlog Item	Verfolgt eine Aktivität, die die Benutzer mit dem Produkt ausführen können.
Task	Verfolgt Aufgaben, die erledigt werden müssen.
Bug	Beschreibt eine Abweichung zwischen dem erforderlichen und tatsächlichen Verhalten, erfasst die durchgeführten Schritte zur Korrektur des Fehlers und überprüft die Korrektur.
Impediment	Erfasst ein Hindernis für den Fortschritt.
Test Case	Serverseitige Daten für eine Reihe von Schritten, die getestet werden sollen.
Shared Steps	Serverseitige Daten für eine wiederverwendbare Reihe von Testschritten.
Sprint	Ein Sprint mit festen Start- und Enddaten, bei dem Arbeit aus dem Produktrückstand ausgeführt wird.

Eine wesentliche Veränderung in Scrum 1.0 war der Sprint-WIT. Mit diesem können Scrum 1.0-Teams Start- und Enddaten für die Sprints definieren, Ziele für den entsprechenden Sprint verfolgen und Notizen aus Retrospektiven in TFS 2010 speichern. Wie bereits erwähnt, bot MSF Agile eine ähnliche Funktionalität in der Arbeitsmappe „Iteration Backlog“ und einer Microsoft Word-Vorlage für Retrospektiven. Die Fähigkeit, Sprints, deren Ziel und die Retrospektiven als eine Arbeitsaufgabe zu verwalten, der anschließend Arbeit zugeordnet wird, stellte für uns eine überzeugende Änderung dar. Für uns war dies der Hauptgrund für den Wechsel von MSF Agile zu Scrum 1.0.

Die PMs in unserem Team, die die Featuredashboards, Berichte und andere Iterationsartefakte verwalten, verbrachten oft viel Zeit mit der Aktualisierung von Berichten, um für das Team und die Partner aktuelle Ansichten zu einem bestimmten Zeitpunkt zu reflektieren. Andererseits verfügt Scrum 1.0 über einen Sprint-WIT, in dem wir Daten für den Sprint zuordnen. Der Burndown-Bericht verwendet dann die Informationen in den Sprint-Arbeitsaufgaben, um den richtigen Datumsbereich anzuzeigen (siehe Abbildung 10).

Abbildung 10 Burndown-Beispielbericht für einen Sprint in Scrum 1.0

Eine einfache und nahtlose Lösung, die sich genau in die Arbeit einfügte, die wir während der Sprintplanung ausführen konnten. Wir mussten die Berichte nicht länger anpassen, um das Start- oder Enddatum festzulegen. Dies geschah jetzt automatisch beim Erstellen der Sprint-Arbeitsaufgabe vor der Sprintplanung.

Kurz zusammengefasst, MSF Agile und Scrum 1.0 bieten verschiedene Optionen für Agile-Teams. Wie bei unserem Team liegt die Entscheidung, was Sie verwenden, natürlich bei Ihnen. In der Tabelle in Abbildung 11 werden die WITs aus den jeweiligen Prozessvorlagen einander gegenübergestellt. Wie bereits erwähnt, empfehle ich jedem neuen Team, das die Agile-Softwareentwicklung mit TFS 2010 einführt, sich ausführlich mit der Verwendungsweise jedes WITs zu befassen.

Abbildung 11 Vergleich von Arbeitsaufgabentypen in MSF Agile und Scrum 1.0

MSF Agile	Scrum 1.0
User Story	Product Backlog Item
Task	Task
Bug	Bug
Issue	Impediment
Test Case	Test Case
Shared Steps	Shared Steps
	Sprint

Weitere Informationen zu den Unterschieden zwischen den Prozessvorlagen erhalten Sie in meinem Blog unter bit.ly/i5tF2G.

Verwenden der Iterationsarbeitsmappe in Scrum 1.0-Projekten

Während unser Team vorankam und mehr Projekte in TFS 2010 erstellt wurden, stellten wir fest, dass uns die Iterationsarbeitsmappe fehlte. Sie hatte großen Anteil an unseren Informationen über Unterbrechungen und, noch wichtiger, über die Kapazität des Teams auf Sprintebene. Unser Team passte daher die Arbeitsmappe an, damit sie mit Scrum 1.0 kompatibel war.

Die zentrale Aussage dieser Änderung ist nicht, dass Scrum 1.0 für uns nicht funktionierte. Es ist vielmehr so, dass uns viele Funktionen fehlten, die in der Arbeitsmappe bereitgestellt wurden. Mein Teamkollege John Socha-Leialoha (blogs.msdn.com/b/jsocha) hat beschrieben, wie die Arbeitsmappe „Iteration Backlog“ für die Verwendung mit der Scrum 1.0-Vorlage geändert werden kann. Die Arbeitsmappe funktioniert nicht eigenständig, zum Teil da sie Daten aus Feldern verwendet, die in Scrum nicht verfügbar sind. In seinem Beitrag erläutert Socha-Leialoha, wie unser Team die Arbeitsmappe veränderte, damit sie mit den Scrum 1.0-Projekten funktionierte. Das Ergebnis war, dass das Team die Arbeitsmappe während der Planung und bei den Einsatzbesprechungen verwenden konnte, um die Kapazität zu verfolgen. Wir stellten einen Nachteil fest: Standardmäßig ordnet Scrum 1.0 während der Planung keine Arbeiten zu Einzelpersonen zu. Stattdessen wird die Arbeit nach Rang gestapelt und der Reihe nach direkt aus dem Rückstand genommen. Um die Kompatibilität mit der Arbeitsmappe herzustellen, mussten wir die gesamte Arbeit zu Einzelpersonen zuordnen, damit wir die Kapazität anzeigen konnten.

Verfolgen auf Basis der Disziplin im Vergleich zur Einzelzuordnung in Scrum 1.0

Wie bereits erwähnt, ist die Zuordnung von Arbeit zu Teammitgliedern problematisch. Die Zuordnung von Arbeit zu Einzelpersonen funktionierte gut bei Projekten mit einem Entwickler, einem Tester und einem PM. Schwierig wurde es bei Projekten mit Kapazität, die abhängig von der Dynamik des Teams variierte. Zum Beispiel konnte ein Feature drei Entwickler, zwei Tester und einen PM haben. Wie soll man Arbeit aufteilen, wenn dies von der aktuellen Verfügbarkeit der Teammitglieder abhängt?

Beim Wechsel zur Scrum 1.0-Vorlage nahm das Team eine große Änderung vor, indem wir Arbeit nicht länger Einzelpersonen zuordneten, sondern eine Zuordnung anhand von Disziplinen ausführten. In den ersten Projekten, die wir mit Scrum 1.0 ausführten, waren wir nicht erfolgreich, da wir Arbeiten zu Einzelpersonen anstatt zu Disziplinen zuordneten. Wir besprachen dies im Team und entschieden uns für die Verwendung eines Disziplinfelds namens „Activity“, das wir in der Arbeitsaufgabe allerdings in „Discipline“ umbenannten (siehe Abbildung 12).

Abbildung 12 Disziplinbasierte Zuordnung in Scrum 1.0

Wir erhielten dadurch die Möglichkeit, auf einen Blick die Kapazität der Entwickler, Tester und PMs anzuzeigen. Wenn wir also Ressourcen zu Featureteams hinzufügten oder aus diesen entfernten, konnten wir Anpassungen vornehmen.

Zusammenfassung

Unser Übergang zu Agile dauert an. Es gibt viele weitere Möglichkeiten für uns, unsere Prozesse zu optimieren. Es trifft nicht zu, dass Agile-Teams über wenig Disziplin verfügen. Wir als Team finden, dass eine solche Behauptung völlig falsch ist. Wir stellten vielmehr fest, dass Agile-Teams sehr diszipliniert sind. Vor dem Umstieg auf Agile hatte das Team keinen effektiven Prozess und leider zu wenig Disziplin. Durch den Wechsel zu TFS 2010 und die MSF Agile-Prozessvorlage begannen wir unsere Weiterentwicklung und bauten eine Einstellung auf, die das Lernen und Adaptieren fördert.

Die Adaption unterstützte unser Fortschreiten von der Verwendung der MSF Agile-Prozessvorlage bis zu unserem aktuellen Stand: Wir nutzen derzeit die Scrum 1.0-Prozessvorlage und sind als Team der Meinung, dass wir es fast „geschafft haben“. Ich hoffe, unsere Wandlung war interessant für Sie und hat Sie motiviert, mit Ihrem Team zu TFS 2010 und einer der Prozessvorlagen zu wechseln.

Ohne TFS 2010 wären wir mit unserem Team nicht da angekommen, wo wir heute stehen. Letztlich ist dies daher ein Bericht über den erfolgreichen Übergang eines Teams zu Agile mithilfe von TFS 2010.

Chris Adams ist Group Program Manager bei Microsoft. Er leitet ein Softwareentwicklungsteam, das Software auf Basis von Microsoft-Tools zur Unternehmensverwaltung entwickelt. Er widmete sich vorher sieben Jahre lang IIS (blogs.iis.net/chrisad) und war in dieser Zeit als Program Manager in Aufgabenbereichen wie Bereitstellung, Unterstützbarkeit, Benutzeroberfläche und Kernarchitektur tätig. Chris Adams ist ein engagierter Autor von Blogbeiträgen unter blogs.technet.com/chrad, hauptsächlich zu Windows, System Center und Visual Studio. Er ist zu erreichen unter chrad@microsoft.com.

Unser Dank gilt den folgenden technischen Experten für die Durchsicht dieses Artikels: Aaron Bjork und John Socha-Leialoha