zurück zum Artikel

Anlässlich der ALM Days 2012 sprachen Holger Schwichtenberg und Thomas Schissler mit Sam Guckenheimer über wichtige Änderungen in der Entwicklung von und mit Team Foundation Server und Visual Studio, deren "Product Owner" er bei Microsoft ist.

Anlässlich der ALM Days 2012 sprachen Holger Schwichtenberg und Thomas Schissler mit Sam Guckenheimer über wichtige Änderungen in der Entwicklung von und mit Team Foundation Server und Visual Studio, deren "Product Owner" er bei Microsoft ist.

heise Developer: Herr Guckenheimer, was sind denn aus Ihrer Sicht die Highlights in Team Foundation Server 2012?

Sam Guckenheimer: An erster Stelle möchte ich darauf hinweisen, dass wir jetzt zwei Versionen des TFS haben: eine für die Cloud – Team Foundation Service – und den lokalen Server [im Folgenden TFS; Red.]. Durch den Team Foundation Service können Teams gleich loslegen. Und wir sehen, dass auch schon größere Teams Versuchsprojekte mit dem Service beginnen. Wo beim TFS die Installation Minuten gedauert hat, benötigt man bei der gehosteten Variante jetzt nur noch Sekunden. Für unsere Kunden mit MSDN-Zugang und Premium-Lizenz für Visual Studio bleibt der Team Foundation Service inklusive. Kleine Teams mit fünf und weniger Leuten können ihn ebenfalls kostenlos nutzen.

Zweitens: Wir haben agile Softwareentwicklung zwar immer unterstützt, jetzt aber haben wir in der neuen Version diese mit Visual Studio und TFS zu einer stimmigen Sache gemacht. Das ist am Task Board und Product Backlog im TFS Web Access zu erkennen oder etwa daran, dass die persönliche Homepage des Entwicklers mit allen wichtigen Sachen und Aktionen in nur einem Klick erreichbar ist. Das ist etwas ganz Neues und, glaube ich, Einmaliges und außerdem einer der größten Vorteile der neuen Benutzeroberfläche.

Als dritten Punkt haben wir auch in Visual Studio jetzt mit "My Work" eine Ansicht, die alles anzeigt, was für den Entwickler wichtig ist. Außerdem unterstützt sie den Wechsel zwischen Aktivitäten, der normalerweise ziemlich kompliziert ist. Eigentlich sollte es laut der Scrum-Philosophie keine Unterbrechungen geben, aber wir leben in einer Welt mit Live-Systemen. Sie genießen immer den Vorrang, das heißt, wir müssen unsere Arbeit plötzlich unterbrechen, um anderweitig aktiv zu werden. Hierbei wird durch "suspend" augenblicklich alles, was gerade in Visual Studio da ist, "zusammengerollt" und für den Nutzer gespeichert. Danach kann man etwas anderes tun, um schließlich durch "resume" wieder mit der ursprünglichen Arbeit fortzufahren.

heise Developer: Da möchten wir kritisch nachhaken: Warum gibt es dieses Feature nur in Verbindung mit TFS? Es wäre doch wünschenswert, wenn man die IDE in einem bestimmten Zustand speichern und diesen dann wieder aufnehmen könnte, ohne das mit einem TFS Work Item zu verbinden.

Guckenheimer: Ich verstehe das Argument. Das Wichtigste ist für uns, einen Arbeitsstil zu unterstützen, bei dem TFS zum Einsatz kommt und Work Items alle Aktivitäten beschreiben. Diese lassen sich benutzen, um Verbindungen zu Quellcodeänderungen, Status, Builds et cetera herzustellen. Viele zukünftige Szenarien erfordern, dass wir Work Items als zentrale Verbindung nutzen.

Und weil TFS mittlerweile kostenlos für kleine Teams sowie "fast" kostenlos für große Teams ist und es den Team Foundation Service gibt, ist die Hürde nicht mehr so groß. Zu Anfang brauchte man ja zwei Jahre Studium, um TFS aufzusetzen. Das ändert sich jetzt. Microsofts Vision ist, dass jeder Visual-Studio-Benutzer auch den TFS benutzt.

Kosten- und Release-Strategie

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.

Qualitätssicherung

Im Sinne der Qualitätssicherung

heise Developer: Die Hauptbedenken auf dem Weg zu kürzeren Zykluszeiten liegen vor allem im Bereich Testing. Man hat zwar Testautomatisierung, führt aber zusätzliche Tests für ein echtes Release durch, weil man meint, dass diese nicht ausreicht. Wie sieht das bei Microsoft aus?

Guckenheimer: Das wird für Cloud-Service und On-Premise-Produkt ein wenig unterschiedlich gehandhabt. Aber für beide gilt, dass wir versuchen, Quellcode für beide gemeinsam zu entwickeln. Und während des Sprints versuchen wir, den Code durch die Tests rein zu halten. Wir benutzen zum Beispiel Gated Check-ins, um unsauberen Code auszuschließen. Danach gibt es sogenannte Rolling Builds, die beispielsweise stundenweise weitertesten, und schließlich längere automatische Tests jede Nacht. Dafür haben wir eigens eine Test-Cloud aufgebaut.

Am Ende des dreiwöchigen Sprints stellen wir das Ergebnis dann ins Live-System. In der ersten Woche des nächsten Sprints beobachten wir es, dabei ist jeder Entwickler dafür verantwortlich, dass seine Arbeit auch im Live-System keine Probleme bereitet. Sollte es doch welche geben, muss er sogleich aktiv werden und fixen. Wir messen in solchen Fällen dann die Minuten. Es handelt sich nun um ausgelieferte Software, und an dieser Stelle wird ohne die Berücksichtigung zwischengeschalteter Hierarchiestufen direkt der Entwickler als der Verantwortliche angesprochen.

Wir können so vorgehen, da beim Team Foundation Service eben nur eine Variante vorliegt, und wir so, wenn wir ein Problem behoben haben, direkt weiterarbeiten können. Wir greifen (nach der Auslieferung), aber auch in die Produktion ein. Das heißt, wir testen, ob das Programm mit unseren Daten auch wirklich läuft.

Für den TFS haben wir natürlich ein Testlabor, in dem wir die Konfigurationen unserer Kunden nachgebaut haben. Hier brauchen wir viel Zeit und viele Maschinen, um alle denkbaren Konfigurationen – auch mit den Testdaten der Kunden – auszutesten. Auf diese Weise sollten insbesondere zum Ende eines Quartals auch exotische Konfigurationen fehlerfrei laufen. Und es gibt Hunderte dieser Exoten.

Schließlich benutzen wir im Team Foundation Service auch Twitter als Teil des Monitorings. Jeder, der bei uns einen Account auf dem Service besitzt, kann uns dann mitteilen, dass er ein Problem hat. Wir fragen dann zurück, ob wir eingreifen dürfen, und wenn der Kunde das bejaht, messen wir die Dauer der Problemlösung buchstäblich in Minuten. Und dabei korrigieren wir das Problem von Grund auf, es darf nicht noch einmal vorkommen.

Hinter den Kulissen

heise Developer: Wie sieht das Team hinter TFS und hinter Visual Studio aus?

Guckenheimer: Es kommt darauf an, wie man es sieht. Alles, was bei Visual Studio und TFS geliefert wird, kommt von vielen Divisionen und vielen Leuten. Es gibt Teile von Windows und Teile von SQL Server et cetera, die alle in den Quellcode mit einfließen. Die Anzahl der beteiligten Personen kann man dann nach den Check-ins am Server messen, man kann es aber auch von der organisatorischen Warte aus betrachten. Es ist aber auch möglich, allein die TFS-Gruppe in den Blick zu nehmen. Diese umfasst 120 bis 150 Personen, die einen Teil der Developer Division ausmachen, die für Visual Studio, .NET, Expression und alles Derartige verantwortlich ist. Das sind insgesamt etwa 1500. Als ich es das letzte Mal nachgeprüft habe, waren an der Developer Division Server Instance 3400 Leute registriert.

Amortisierung trotz geringen Preises

heise Developer: Der TFS wird zunehmend günstiger angeboten, für kleine Gruppen unter fünf Personen ist er gar umsonst. Sinkt deshalb auf der Ebene des Microsoft-Konzerns das Investment in das TFS-Team, weil man ja geringere Erlöse erzielt? Mit anderen Worten: Heuert Microsoft wegen der geringeren Erlöse deshalb weniger Leute an?

Guckenheimer: Nein, die Entscheidungsfindung ist viel komplizierter. Würde es allein um den Umsatz pro Person gehen, hätten wir überhaupt niemanden in der Developer Division sitzen. Wir glauben, dass Entwickler für Microsoft wie das Blut zum Leben sind. Dieses hat die Firma schon von ihrer Geburt an gelebt. TFS spielt in dem Zusammenhang eine zentrale Rolle. Ein Teil bemisst sich hier nicht nach seinem Umsatz, sondern nach seiner Wichtigkeit für die Strategie. Wir wollen, gerade jetzt in der neuen Welt, in der die Applikationen komplizierter sind und mehrere Techniken erfordern, dass die Entwickler eine Präferenz für Microsoft haben. Wir wissen, dass sie mit vielen Techniken arbeiten, wie Java (zum Beispiel für Android), und auch andere Sprachen als die .NET-Sprachen benutzen werden. Auch die Lebenszyklen werden sich transformieren. Wir wollen aber immer noch eine zentrale Rolle spielen. Dafür müssen wir durchgehend die besten Szenarien, die besten Erfahrungen und die besten Services anbieten. So versteht es Steve Ballmer. Und wenn jemand die Frage stellt, warum wir zum Beispiel eine Developer Division haben, erklärt er, dass sie eine zentrale Strategie für Microsoft war, ist und bleiben wird.

heise Developer: Ist es nicht so, dass Microsoft zurzeit sehr stark auf agile Themen fokussiert ist und dabei das klassische Wasserfallmodell ein bisschen vernachlässigt? Es fällt schwer, ein mehrere hundert Seiten starkes Anforderungsprofil in einem TFS unterzubringen.

Guckenheimer: Wir haben in den ersten vier, fünf Jahren sehr viel in die formale Entwicklung des TFS investiert. In der letzten Zeit sind wir zur Überzeugung gelangt, dass wir mehr in "Agile" investieren müssen. Wir wissen, dass wir für formale Methoden mehr tun können, was wir wahrscheinlich zukünftig auch tun werden. Allerdings liegt unsere aktuelle Priorität in den modernen Applikationen und den agilen Teams.

heise Developer: Liegt dem Ganzen auch zugrunde, dass Microsoft selbst die Überzeugung teilt, dass Softwareentwicklung über agile Methoden besser funktioniert? Und dass die formalen Entwicklungsprojekte zunehmend mehr zurückgehen werden?

Guckenheimer: Ja. Ich glaube, dass das Wachstum auf Seiten der agilen Methoden ist. Und wir arbeiten definitiv auf diese Weise. Ich sage allerdings nicht, dass die regulierenden formalen Methoden verschwinden werden. Allerdings ist die Differenz zwischen den derzeitigen Möglichkeiten und dem, was man auf der modernen Seite tun sollte oder zu tun wünscht, größer, und auch das Marktwachstum ist hier größer als auf der anderen Seite. Und deshalb genießt es bei uns Priorität.

heise Developer: Vielen Dank für das Gespräch.

Das Interview führten Dr. Holger Schwichtenberg (www.IT-Visions.de [1]) und Thomas Schissler (artiso AG [2]). (ane [3])

URL dieses Artikels:
https://www.heise.de/-1805711

Links in diesem Artikel:
[1] http://www.it-visions.de/start.aspx
[2] http://www.artisoag.com/
[3] mailto:ane@heise.de

Copyright © 2013 Heise Medien