Seite 2: Kosten- und Release-Strategie

Inhaltsverzeichnis

Rolle und Bedeutung der Power Tools

heise Developer: Die überwiegende Mehrheit der Entwickler kennt die Power Tools gar nicht, die es für Visual Studio und TFS als kostenlose Ergänzung gibt. Wann wird ein Power Tool in das Produkt integriert? Gibt es dafür Akzeptanzkriterien? Warum ist ein Feature wie das automatische Einfügen einer schließenden geschweiften Klammer nicht in das fertige Produkt gewandert, sondern weiterhin ein Power Tool?

Guckenheimer: Zunächst ist dazu zu sagen, dass wir für die Version 2012 eine Änderung vorgenommen haben: Wir liefern jetzt quartalsweise Aktualisierungen und benutzen dafür Visual-Studio-Updates als Mechanismus. Es gibt einen Unterschied hinsichtlich der Support-Politik zwischen Visual Studio, Visual-Studio-Updates und den Power Tools. Es dreht sich hierbei um die Frage nach den Ansprüchen auf Support, die Unternehmen zehn Jahre lang für alles genießen, was im Produkt gelandet ist. Mit den Power Tools können wir mehr Funktionen liefern, ohne dass wir verpflichtet wären, auch dafür zehn Jahre lang Support leisten zu müssen

Die Entscheidungen, in welchen Fällen wir mehr Funktionen bringen und die Support-Kosten auf uns nehmen wollen, unterliegen menschlichen Entscheidungen: Wir wollen immer ein Maximum an Funktionen bieten, und wir wollen auch beim Support vernünftig sein. Es gibt jedoch Fälle, in denen die Kosten für die Tests und den Support zu hoch wären und wegen denen wir keine Funktionen liefern können. Das heißt dann, dass diese Fälle Power Tools bleiben. Wie beim TFS, bei dem es schon von Anfang an Funktionen gibt, die ein Power Tool sind und es auch bleiben. Das stellt dann, wie im Fall des Process Template Editor, auch kein Problem dar. Damit hatten einige Leute zu Anfang Probleme, jetzt allerdings nicht mehr. Das ist eine Frage der Praxis.

heise Developer: Versuchen Sie die Support-Kosten in dem Sinn zu quantifizieren, dass Sie bei Features wie der schließenden geschweiften Klammer sagen, das würde in den nächsten Jahren soundso viel Geld kosten, wenn Sie es als Funktion ins Produkt einbauen würden?

Guckenheimer: Testkosten würden sicherlich anfallen. Es gibt hierbei einen großen Unterschied zwischen Service- und On-Premise-Produkten. Bei Serviceprodukten gibt es nur eine Version, die immer aktuell ist. Bei On-Premise-Produkten sind wir gezwungen, alle Varianten zu unterstützen, mit allen Umgebungen, Betriebssystemen und Sprachen und so weiter. Dabei multiplizieren sich die Testkosten sehr schnell. Für jede neue Version sind alle Konfigurationen zu testen. Zudem wird die Anzahl der Konfigurationen für On-Premise-Produkten zunehmend größer. Es gibt hierbei fortwährend die Debatte, wie viel wir da hineinstecken sollen.

Neue Release-Strategie

heise Developer: Uns interessiert die neue Strategie von Microsoft, bei den On-Premise-Angeboten, etwa bei TFS und Visual Studio, in Dreimonatszyklen Updates bereitzustellen. Was war hier die Hauptmotivation, von der alten Vorgehensweise wegzukommen, bei der alle zwei Jahre ein großes Release und zwischendrin ein bis zwei Service Packs herausgebracht wurden?

Guckenheimer: Der Hauptgrund ist, dass wir es dem Kunden einfacher machen wollten. Wir haben sonst rund 100 kleine Sachen im Jahr herausgebracht, was für die Kunden unübersichtlich wurde. Jetzt haben wir das in einem schnellen gemeinsamen Rhythmus standardisiert, in dem quartalsweise alles zusammengeführt wird. Dadurch ist alles einfacher geworden, und der Kunde hat sogar die Möglichkeit auszuwählen, ohne Gefahr zu laufen, wichtige Dinge zu verpassen.

heise Developer: Zurzeit werden viel mehr Funktionen in kleinen Schritten ausgeliefert, bei denen nicht gewartet wird, bis das Feature in seiner Gesamtheit fertig ist. Jetzt aber, über die Updates, ist zu erwarten, dass die Nutzer in kurzer Zeit mehr Funktionen bekommen als bisher über das Instrument der Feature Packs.

Guckenheimer: Oh ja, obwohl das mehr für die Cloud gilt, bei der allerdings alle drei Wochen neue Updates geliefert werden und wir am schnellsten Feedback bekommen. Aber auch bei den Quartals-Updates erhalten wir jetzt schneller eine Rückmeldung. Es herrscht die Idee vor, dass wir kontinuierliches Feedback bekommen und wir in kleinen Schritten fortschreiten wollen, statt sehr große Sachen zu liefern, die nur als Ganzes genommen werden konnten. Da musste man oft auf sehr erfahrene Experten warten, die die neuen Sachen erklärt haben. Dann war es aber oft schon zu spät, um damit etwas anzufangen. Das ist jetzt mit den kleinen Sachen anders, bei denen wir kontinuierlich Feedback bekommen, um dann mit kleinen Korrekturschritten fortzufahren.

heise Developer: Erhöht dieses Verfahren nicht wieder die Support-Kosten? Wenn etwa ein Update 1 herauskommt, das eventuell nicht ganz das Richtige war, und dann ein Update 2, das dieses verbessert. Wäre dann nicht wiederum das Update 1 zehn Jahre zu unterstützen? Und steht das nicht im Widerspruch dazu, dass Sie die Support-Kosten niedrig halten wollen?

Guckenheimer: Nein, das ist eine Frage, wie viel technische Schuld wir tragen. Wir befinden uns zurzeit auf einer Qualitätsstufe, auf der es kein Problem mehr mit dem Grundprodukt gibt. Es gibt sehr viel Test-Automatisierung und eine höhere Qualität als je zuvor. Und wir entscheiden, was zum Grundprodukt oder was zu den Power Tools gehört und was unter welchem Support-Vertrag unterstützt wird. So bekommen wir auch Rückmeldungen dazu, ob etwas den Kunden hilft oder nicht. Und wenn wir demnach etwas richtig gemacht haben, dann sind die Support-Kosten auf lange Sicht viel geringer.

heise Developer: Diese kontinuierliche Lieferung wird von vielen Entwicklerteams, selbst solche, die Scrum leben, abgelehnt. Sie sagen, dass das mit ihrer Organisation oder mit ihrem Produkt nicht möglich sei. Aber jetzt geht Microsoft hierin voran. Können Sie beschreiben, was die größte Herausforderung dabei war, die Organisation und die Prozesse auf die kontinuierliche Lieferung umzustellen? Und wie lange hat es gedauert?

Guckenheimer: (lacht) Das kommt darauf an, wie man es sieht. Wir versuchen, uns mit jeder Produktwelle zu verbessern. Zunächst waren die Punkte technische Schuld und Transparenz zu meistern. In der zweiten Welle haben wir uns auf den Wertzuwachs konzentriert. Als Drittes haben wir uns dann auf die Zykluszeiten fokussiert, das heißt das Arbeiten in kürzeren Zyklen, um öfter Rückmeldung zu erhalten. Jetzt können wir vom Feedback im Sinne des Prinzips "Build, Measure, Learn" lernen. Der gesamte Prozess fing grob gesehen etwa 2006 an. Die Fokussierung auf die Zykluszeiten begann ungefähr 2010, kurz bevor wir auch mit der Cloud anfingen. Es ist eine Mentalitätsfrage. Man kann das alles nur durchführen, wenn man eine bestimmte Einstellung der technischen Schuld gegenüber mitbringt. Die Frage ist, wie viel Schuld können wir tragen? Dabei gilt, dass wir nachher, also wenn es sich gelohnt hat, die Schulden zurückzahlen. Es ergibt zum Beispiel bei bestimmten Anforderungen keinen Sinn, Experimente mit allen Arten von Browsern durchzuführen. Wir wollen ein Experiment zu den niedrigsten Kosten durchführen.