„Wenn ich etwas von Ihnen will, rede ich ja auch mit Ihnen und fasse Ihnen nicht einfach in’s Hirn!“
Mit diesem einprägsamen Vergleich hat Ruth Leuzinger, ehemalige Chef-Architektin der Zürich Versicherung, vor über zehn Jahren das Prinzip der Kapselung von Daten beschrieben. Ich habe in all den Jahren weder eine einzige Schwäche dieses Vergleichs gefunden, noch eine bessere Beschreibung des Prinzips.
Am 23. Januar 2008 halte ich von 9:00 Uhr bis 10:30 Uhr auf der OOP in München einen Vortrag über die Einführung agiler Entwicklung – wie Sie sich anhand des Titels möglicherweise schon gedacht haben.
Darum geht es: Im ersten Teil berichte ich aus vier verschiedenen Projekten, in denen ich in den letzten zehn Jahren agile Praktiken oder agiles Vorgehen beim Kunden eingführt habe; mal mit mehr, mal mit weniger Erfolg. Die Kunden reichen von mittelständischen Unternehmen bis zu Großkonzernen. Ich analysiere die dabei aufgetretenen Probleme und leite meine ganz persönlichen Lehren aus ihnen ab.
Im letzten Drittel bekommen Sie dann das Wort: Im Rahmen einer „Goldfishbowl“ können Sie mir Fragen stellen, Ihre eigenen Erfahrungen einbringen oder weitere Sichtweisen diskutieren.
Auf den XPDays 2007 habe ich diesen Vortrag bereits gehalten. Die Auswertung der Feedbackbögen finden Sie unter http://www.xpdays.de/2007/auswertung.html
Weitere Informationen über die Konferenz und die Anmeldung erhalten Sie auf der OOP 2008 Web-Site
Häufig wird testgetriebene Entwicklung von jenen in Frage gestellt, die sich eigentlich besonders über vermehrtes Testen freuen müssten: Professionellen Testern und Qualitätssicherer. Es sei widersinnig, wenn Entwickler auch Tests für ihren eigenen Code schrieben, bemerken Sie – korrekter Weise. Das wird von dem agilen Testansatz aber auch gar nicht in Frage gestellt, ebenso wenig, wie agile Ansätze eine eigene Testtruppe obsolet machen würden.
Tatsächlich halten sich die verbreiteten agilen Ansätze eher bedeckt, wenn es um die klassischen Testaufgaben geht. Ich persönlich orientiere mich in diesen Fragen stark an den Ideen von Brian Marick (http://www.exampler.com), der seit langer Zeit als Testconsultant arbeitet und dort agile Ansätze voran treibt. Er ist Co-Autor des agilen Manfiests und war mehrere Jahre Präsident der Agile Alliance Non-Profit Organisation (http://www.agilealliance.org).
Brian Marick kategorisiert die Testarten in agilen Projekten entlang zweier Dimensionen. Zum einen anhand ihrer Intention:
Weiterlesen
Ein kurzer Hinweis auf Martin Fowler’s Blog-Eintrag „Test Cancer“ sei mir hier erlaubt. Er beschreibt das Phänomen, dass man nach einiger Zeit seinen Code einmal wieder sieht und ein guter Teil der Tests auskommentiert sind, oder nicht mehr laufen. Der lesenswerte Eintrag entspricht dem, was auch ich meinen Kunden immer wieder predige: Nur wenn alle Tests zu 100% laufen, sind die Testfälle das Sicherheitsnetz, das man benötigt, um sicher Software zu testen.
In diesem Sinne sind agile Verfahren Hoch-Disziplin-Methoden. Am ehesten erreicht man dieses Ziel, wenn man alle Tests im Buildserver laufen lässt und mehrmals täglich verifziert. Dann kann die Änderung, die zum Brechen des Tests geführt hat, relativ schnell identifziert werden.
Ein Entwickler beschwerte sich neulich bei mir, durch eine Änderung von Kollegen an der Testinfrastruktur habe er sieben Stunden lang die Tests nicht laufen lassen können, das sei die Hölle gewesen und hätte ihn letztlich zwei Überstunden gekostet. Er verlange, dass die Tests in Zukunft lauffähig bleiben. Diese Einstellung ist das beste Mittel gegen Testfall-Erosion, eine der Todsünden agiler Entwicklung.
In der traditionellen Planung wird versucht, die Auslastung der „Ressourcen“ zu optimieren: Die Idee ist, dass man dann am effizientesten arbeitet, wenn jeder voll ausgelastet ist.
Agile Planung versucht Ergebnisse zu optimieren: Das Team bemüht sich, zunächst die wichtigsten Aufgaben abzuschließen, dann die nächst-wichtigen usw. Man konzentriert sich also darauf, Aufgaben abzuschließen, anstatt darauf, Aufgaben anzufangen.
Durch die Optimierung der Ergebnisse ist die Anzahl der zugleich bearbeiteten Aufgaben niedriger, es sind weniger Abstimmungen und Kontextwechsel notwendig, das Team erledigt insgesamt mehr Aufgaben. Die Auslastung einzelner Entwickler mag zwar gelegentlich geringer sein, als bei Auslastungsorientierter Planung – wie auch die Auslastung der Flugbegleiter in meinem gestrigen Eintrag. Aber der Geschäftsnutzen ist größer. Und darauf kommt es an.
Die Diskussion ist in etwa so alt, wie agile Entwicklung alt ist und dennoch haben sich die Fragen (und „Vorwürfe“) kaum geändert: „Ja geht denn das auch für ‚große‘ Projekte?“ Varianten dieser Anmerkung lauten zum Beispiel: „Das mag ja für Spielprojekte funktionieren. Wir dagegen, wir machen Projekte mit hunderten von Mitarbeitern, da funktionieren nur die traditionellen Ansätze!“
Ob die traditionellen Ansätze (wenigstens) bei solchen Teamgrößen funktionieren, sei einmal dahingestellt. Die Projekte oberhalb der 100 Personen, an denen ich bisher mitgearbeitet habe, waren alle weit entfernt von dem ruhigen, sicheren Fahrwasser, das ich aus der agilen Entwicklung kenne. Obwohl sie alle am Ende zumindest vom Management als mehr oder minder erfolgreich dargestellt wurden, hätte das, was dort als Erfolg verkauft wurde, einen agilen Projektleiter vermutlich in die Resignation und in den Vorruhestand getrieben.
Spannender finde ich die Frage, was eigentlich „große“ Projekte sind. Weiterlesen
Wer die Koordination der Flugbegleiter beim Service auf einem Kurzstreckenflug beobachtet, kann ein schönes Beispiel globaler Optimierung entdecken: In dem engen Mittelgang hat nur ein Servicewagen Platz, überholen ist ausgeschlossen. Oft beginnt die erste Flugbegleiterin in Reihe 1 mit ihrem Service und arbeitet sich voran. Sobald der Kollege seinen Wagen bereit hat und aufschließt, überspringt die erste Kollegin einige Reihen, in denen der Kollege dann den Service übernimmt. Das ist zwar sehr naheliegend, zeigt aber, dass hier erst globale Optimierung ein vernünftiges Ergebnis bringt: Würde die erste Kollegin einfach „schneller“ bedienen, sprich ihre eigene Effizienz optimieren, wäre ihr Kollege arbeitslos, die Aufgabe, alle Passagiere zu versorgen wäre in der gebotenen Zeit nicht zu schaffen. Sie muss ihre Arbeit für zwanzig oder dreißig Sekunden einstellen – also ineffizienter werden – damit der Kollege wiederum mit seiner Arbeit beginnen kann.
Warum ich darüber schreibe? Genau das zweite Verhalten, die operative Hektik, sehe ich immer wieder in der Softwareentwicklung: Wenn Entwickler versuchen, ihre persönliche Aufgabe durch Überstunden und besonders „schnelle“ Arbeit so schnell wie möglich „abzuschließen“, geht das in der Regel auf Kosten der Qualität. Nachfolgende Tester oder Entwickler, die später den Code ändern müssen, sind die Leidtragenden, weil ihre Arbeit schwieriger wird. Und vor allem sind die Kunden die Leidtragenden, die nicht selten durch irrationalen Druck gehörige Mitverantwortung tragen. Diese operative Hektik ist nicht einmal Egoismus, weil das sogar den Entwickler selbst treffen kann. Es ist simple Kurzsichtigkeit.
Das gleiche gilt für Tester, die neue Features nicht testen, sobald sie bereit stehen, sondern erst, wenn der Test „an der Reihe ist“. Und natürlich für Manager, die solches Verhalten oft nicht nur dulden, sondern sogar fördern und belohnen.
Warum sind Flugbegleiter dabei so viel besser? Sie trainieren in mehreren Iterationen täglich in ständig wechselnden Teams. Sie haben den direkten Kundenkontakt, der bei ineffizientem Service deutliches Feedback ermöglicht. Und sie haben die notwendige Prozessfreiheit, den Vorgang immer weiter zu optimieren.
Iterationen, direkter Kundenkontakt und Retrospektiven helfen bei agiler Entwicklung, global zu optimieren, anstatt die Mitarbeiter in operativer Hektik auszubrennen.
Ende April 2008 findet in Bern die SEE 2008 statt, eine Konferenz über die „Software Engineering Essentials“. Ziel der Konferenz ist es, ein „Forum für den Austausch zwischen dem Lager der leichtgewichtigen, agilen Entwicklungsprozesse und den Vertretern reichhaltiger Vorgehensmodelle“ zu schaffen, so der Initiator der Konferenz, Andreas Rausch. Um dieses Ziel zu unterstützen, haben sowohl Jutta Eckstein als auch ich unsere Mitarbeit im Programmkomittee zugesagt. Aber das reicht natürlich noch nicht: Um nicht (wie letztes Jahr in München) in die Verlegenheit zu geraten, dass Agilität nur ein Nischenthema zwischen V-Modell XT, SPICE und CMMI bleibt, sondern seine Gegenposition auch klar beziehen kann, brauchen wir von Agilisten Beiträge, Beiträge, Beiträge!
Die Erfahrungen im letzten Jahr haben gezeigt, dass die wenigen Beiträge, die zum Thema Agilität eingericht wurden, recht hohes Niveau hatten und auch die Diskussion im Programm Kommitee habe ich als durchaus fair empfunden. Also: Einreichungsfirst ist der 3. Januar 2008, näheres dazu im offiziellen Aufruf. Wir sollten die Gelegenheit nicht verpassen, auch die Diskussion mit jenen zu suchen, die (noch) nicht von Agilität überzeugt sind!
Ich bin gerade in Stefan Hagen’s PM-Blog über einen ganz interessanten Beitrag zum Thema „Wie entwickelt Google“ gestolpert. Das spannendste waren für mich die Projektgrößen: Google rechnet in „Units“, das sind Teams mit drei Personen, die Projektdauer beträgt drei bis vier Monate. „Große“ Projekte bestehen zum Beispiel aus vier Units, also zwölf Personen. Da hat jemand wirklich verstanden, wie man Projekte klein macht.
Wer meint, solche Projekte seien nicht ernst zu nehmen, werfe noch kurz einen Blick auf den Aktienkurs und die wirtschaftliche und gesellschaftliche Bedeutung von Google weltweit.
Nachdem ich immer wieder auf das Michael Stipe Zitat in meiner E-Mail Signatur angesprochen werde („I don’t believe and never did, that two wrongs make a right“), hier ein paar Hintergründe über das Zitat und warum ich es verwende: Die Zeile stammt aus dem Lied „The Final Straw“ von der CD „Around the Sun“ (2004). Der Song wurde wenige Tage nach dem Beginn des zweiten Golfkriegs von R.E.M. im eigenen Studio aufgenommen und sofort auf die Homepage gestellt – als Protest gegen den Krieg und gegen Bush. Den vollständigen Text findet man z.B. unter http://www.azlyrics.com/lyrics/rem/finalstraw.html.
Ich habe mich damals spontan entschieden, die Zeile in meine Signatur zu übernehmen. Neben dem Protest war mir wichtig, eine amerikanische Stimme sprechen zu lassen, stellvertretend für all meine Freunde und Kollegen in den USA, die ähnlich denken, wie Stipe. Und die wie die meisten Deutschen die Tage zählen, bis der Spuk vorbei ist.