Christian Binder von Microsoft Deutschland präsentierte in seinem Vortrag auf der ALMConf 2010 in Stuttgart, wie Microsoft selbst die Entwicklung von Visual Studio und Team Foundation Server 2010 mit den eigenen Tools – eben Visual Studio und Team Foundation Server 2010 – betreibt.
Die harten Zahlen
- 3500 Projektbeteiligte
- 2000 Builds pro Monat
- 700.000 Work Items
- Über 20 TB Repositorygröße
(DevDiv-Instanz. Status 2009)
Produkt und Sprint-Planung
Microsoft verwendet ein Envisioning – eine klare Vision des Ergebnisses – um alle Projektbeteiligten auf ein Ziel hinarbeiten zu lassen. Dies wird durch End-To-End Story Boards zu Beginn der Planung erreicht, in dem klar wird, wie der Benutzer am Ende das Produkt verwenden soll.
Der Entwicklungsprozess ist dabei vierstufig ausgelegt. Die erste Stufe der Planung besteht aus sogenannten Pillars, den Schwerpunkten für das nächste Release – die Investitionsgebiete.
Auf der zweiten Stufe werden Value Propositions abgeleitet, die ausdrücken, welcher Mehrwert den Kunden bzw. den Endnutzern bereitgestellt werden soll.
In den weiteren Stufen werden Feature-Groups abgeleitet – im Prínzip Themengebiete, die verschiedene Funktionalitäten gruppieren und von dedizierten Feature-Crews angegangen und entwickelt werden sollen. Darunter sind Deliverables – die zu lieferenden Artefakte wie zum Beispiel Dialoge, Assemblies oder gar einzelne Klassen und Methoden.
Die Feature-Crews brechen dann die Deliverables in Tasks auf, um die Umsetzung zu steuern und den Status zu bestimmen. Die Feature-Crew committed sich auf Scope, Schedule und Quality. Ebenfalls liegt die Ressourcenplanung und –beschaffung in der Verantwortung der Feature-Crew.
Eine Feature-Crew besteht im Regelfall aus
- 1 Program Manager
- max. 5 Entwickler
- max. 5 Tester
Um die Qualität in derart großen Teams sicherzustellen, verwendet Microsoft eine Branching-Strategie, die die Feature-Crews auf Feature-Branches isoliert. Der Feature-Branch wird vom zentralen Main-Branch abgezweigt. Bei der Rückintegration des fertigen Features auf Main werden definierte Kriterien abgeprüft – die Quality Gates. Diese sogenannten Exit Criteria sind in Form von eigenen Feldern in Work Items hinterlegt. Quality Gates gibt es für die verschiedenen Bereiche wie Dokumentation, Anforderungen, Code-Coverage, Tests, Review-Status, Sicherheit, Lokalisierung, Usability, Copyrights, Performance usw..
Nun ist die globale Branch-Strategie etwas komplexer, beinhaltet diese doch unterhalb der Main-Line die Release-Branches, Team-Branches und unterhalb der Team-Branches die Feature-Branches. So hat die Dev10-Main-Line aus ca. 900 Child-Branches.
Agil oder formal?
Der generelle Prozess zur Entwicklung ist mit einem zentralen Reporting unterlegt, welches bis hin zu den Investitionskosten und geschaffenen Werten nach umgesetzten Features abstrahiert. Die konkreten Prozesse der Teams sind offen. Das Team wählt die konkrete Ausprägung des Prozesses, wie zum Beispiel Scrum, XP, Ruck etc.. Wichtig ist, dass das Team entsprechend nach oben an die definierten Schnittstellen berichtet.
Das Reporting umfasst viele Berichte auf Basis der Deliverables. So stehen Fortschrittsreports bereit, die jederzeit den aktuellen Stand eines Feature aggregiert zeigen. Aber nicht nur den aktuellen Stand, sondern auch den Fortschritt der letzten Tage. Nur so kann frühzeitig auf einen Stillstand eines halbfertigen Features reagiert werden.
Lessons Learned
Feature-Crews
Der Umstieg von einem traditionellen Team-Modell hin zu den Feature-Crews hat zu einer signifikanten Reduktion der offenen Bugs in der Beta 1-Version des Produkts gesorgt (ca. 60% Reduktion).
Allerdings muss beachtet werden, dass die Zusammenarbeit von Features verschiedener Groups – also Cross Scenarios häufiger getestet werden müssen. Hier ergaben sich die meisten Performance-Issues.
Release Schedule
Die Sprints in Dev10 von 6-10 Wochen waren retrospektiv betrachtet zu lang. Diese wurden für die aktuelle Entwicklung der nächsten Version verkürzt. Zudem wurde Start- und Enddatum angeglichen, so dass es parallel laufende Sprints gibt. So haben bisher zu lange Überschneidungen von Iterationen für mehr Probleme bei Übergabe von Ergebnissen und der Planbarkeit der Ressourcen gesorgt.
Kundeneinbindung
Der Umgang mit Kundenfeedback stand im Vordergrund der Verbesserungsanstrengungen in den letzten Jahren. So werden bereits in frühen Phasen Kunden in die Planung der nächsten Version eingebunden. Die Prioritäten im Backlog werden direkt beeinflusst.
Conway’s Law
Zum Umgang mit Conway’s Law – dass die Produkte von Organisationen in Ihrer Struktur der Struktur der Organisation selbst folgen – wird durch den Ansatz “Organize Engineering Around Scenarios” in Form der Feature-Crews adressiert.
Key Learnings
Hier noch eine unkommentierte Auswahl von weiteren Key Learnings:
- Invest in automated infrastructure efficiency
- Isolate major breaking changes
- If it’s not fast, it’s not usable
- Unless we are not using it, it’s not done
- Less is more
- Continuous Improvement (Transparency, Reduction of Waste, Flow of Value)
Was prinzpiell Microsoft’ umtreibt ist die Velocity im Flow-Of-Value. Stellt man die Investionen für die Entwicklung und Wartung von Produkten der Anzahl innovativer, neuer Features gegenüber, so ergibt sich die Velocity. Generell gilt, bei weniger Altlasten kann mit den gleichen Investitionen mehr neues Erschaffen werden. Wobei es sich ab der nächsten Version schon um “Altlasten” handelt.
Fazit
Es ist schon beeindruckend, wie Microsoft 3500 Mitarbeiter dazu bringt, derartig komplexe Produkte wie Visual Studio und Team Foundation Server in dem derzeitigen Tempo zu bauen!
Vielen Dank an Christian Binder für den außergewöhnlich detaillierten und interessanten Vortrag!
1 Kommentar