Gestern habe ich über verschiedene Techniken in der agilen Softwareentwicklung gebloggt. Dabei fiel mir erst am Ende auf, dass ich einen wesentlichen Punkt vergessen habe: Wieso sollte ich mich nicht mit 80% durchlaufenden Tests zufrieden geben?
Im Extreme Programming gibt es eine weitere Praktik, auf die ich gestern gar nicht eingegangen bin: die sog. Zero-Bug Policy. Beim Bestellen in einem Restaurant fiel mir vor kurzem auf, dass der Kellner einen Fehler bei der Aufnahme der Bestellung gemacht hat, den obersten Zettel seines Notizblocks abriss, und alles noch mal von vorne aufschrieb. Das nennen wir in der agilen Softwareentwicklung die Zero-Bug Policy. Wir geben uns nicht mit „wenig“ Fehlern zufrieden, sondern wir legen unseren Maßstab so hoch, dass wir null Fehler zulassen.
Von dieser Denkweise ausgehend bekomme ich Sorgenfalten (und graue Haare, die ich dann auf meine Frau schieben kann), wenn mich jemand danach fragt, ob dann nicht 80% durchlaufende Tests in Ordnung sind. Nein, das sind sie nicht. 80% Tests bedeutet, dass wir 20% Risiko eingehen, dass etwas an unserer Software nicht funktioniert. Für ein 5 Euro Projekt wären das 20 cent, aber für ein 5 Million Euro-Projekt stehen immerhin 200.000 Euro auf dem Spiel. Für diesen Betrag kann ich als Privatperson ein ganzes Haus kaufen! Das Risiko ist es mir als professioneller Softwareentwicklung nicht wert einzugehen.
Die Messlatte für unsere Unittests sollte bei 0 insgesamt liegen. Jeder Test, der fehlschlägt, weist uns sehr deutlich auf ein Problem hin. Wenn wir diese Anzeichen ignorieren, weil wir neue Funktionalität bauen wollen, dann hilft uns das nur kurzfristig weiter. Langfristig wissen wir nach wie vor nicht, wo wir mit unserem Projekt überhaupt stehen. Das ist nicht nur schlecht, sondern führt auch den Sinn von Continuous Integration ad absurdum. Transparenz ist einer der höchsten agilen Werte, und wir sollten nicht die Augen davor verschließen, was uns diese Transparenz versucht mitzuteilen.
Entweder geht es darum, dass die fehlschlagenden Tests uns mitteilen wollen, dass wir ein Problem in unserer Software haben. Dann sollten wir das so schnell wie möglich im Sinne einer Zero-Bug Policy lösen, und wieder zu einem potentiell auslieferbaren Zustand kommen. Das schaffen wir nur, wenn wir das Problem auch beheben.
Vielleicht liegt es aber auch daran, dass unsere Tests auf Deutsch gesagt sch… sind. Hurra! Wir können was lernen! Dann sollten wir uns auch daran setzen, dass wir uns überlegen, was wir daraus schließen können. Lag es daran, dass unsere Tests auf einem Anfängerniveau geschrieben wurden? Dann sollten wir überlegen, ob wir die Tests jetzt neu schreiben, wo wir mehr Erfahrung bekommen haben, oder sie ganz und gar entsorgen. Derzeit scheinen sie uns nur echte Probleme zu verschleiern, aber den Build bei 80% erfolgreich laufen zu lassen erscheint mir da die falsche Reaktion zu sein.
Zu guter Letzt könnte es noch sein, dass unsere Tests nicht gepflegt werden. Dann ist aber doch ein erfolgreicher Build nur eine Verschleierungstaktik, um von den wirklichen Problem abzulenken. Letzten Endes wird dann Pareto CI nur dazu ausgenutzt, dass ich auf meine Probleme nicht mehr hören muss. Für mich verstösst das grob gegen die Prinzipien von Offenheit und Transparenz in agilen Projekten. Ich würde sogar so weit gehen, und eine derartige Taktik alles andere als agil nennen. Das Team nimmt sich jede Chance sinnvoll aus Fehlschlägen zu lernen. Schade.
Doch wo liegen die Vorteile für einen ProductOwner bei 100% durchlaufenden Tests, TDD und Pair-Programming? 2009 hörte ich von Elisabeth Hendrickson die Geschichte eines Projektes, in dem 60% Staff-Rotation vorherrschte. Dort war es normal, dass jemand anderes in den nächsten zwei Wochen in das Projekt kam. Wie haben die überlebt? Durch test-getriebene Entwicklung und Pair-Programming!
Durch langfristigen Einsatz von CI, TDD und Pairing erhalte ich eine Code-Basis, die von allen verstanden werden kann. TDD und Pairing führen mittelfristig dazu, dass ich ein gemeinsames Verständnis von gutem Code erhalte, und ein gemeinsames Verständnis einer testbaren Code-Basis entsteht. Dabei spielen Wechsel von Teammitglieder irgendwann anscheinend nur noch eine untergeordnete Rolle.
