Seite 3: Qualitätssicherung

Inhaltsverzeichnis

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) und Thomas Schissler (artiso AG). (ane)