„Mein wichtigstes Programmierwerkzeug ist der Thesaurus, um gute Namen zu finden“ – Ward Cunningham
„Ich programmiere niemals, ohne leo.org offen zu haben“ – Frank Westphal
Archiv der Kategorie: Agilit
Testgetriebene Entwicklung und traditionelles Testen
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
Testfall-Erosion
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.
Auslastung optimieren oder Ergebnisse optimieren?
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.
Über Projektgrößen
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
Globale versus lokale Optimierung
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.
SEE 2008 auf der Suche nach agilen Beiträgen!
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!
Agile Entwicklung bei Google
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.
„Damit sind nicht alle unter Dampf“ – Übergang zu agiler Planung
„Die Planung ist ja ganz nett, aber einige hier sind jetzt überlastet und andere haben nichts zu tun.“ Diese Aussage hört man mit Sicherheit irgendwann, wenn man ein Team auf agile Planung umstellt. Zur Erinnerung: Bei agiler Planung versucht man nicht, sämtliche „Ressourcen“ voraus zu planen, sondern sammelt Arbeitspakete mit direktem Geschäftsnutzen (in der Regel in Form sogenannter Anwender Geschichten oder User Stories) und priorisiert sie vollständig. Die Pakete werden geschätzt und der Umfang abgeschöpft, der in dem Monat geleistet werden kann. So wird immer an den wichtigsten Aufgaben gearbeitet.
In der besten aller agilen Welten funktioniert das auch: Wenn das Team von Anfang an konsequent die Entscheidungen im Team getroffen hat und immer in Paaren gearbeitet hat, ist das Wissen über das System ungefähr gleich verteilt und jeder kann jede Aufgabe übernehmen. Wenn man allerdings ein bestehendes Vorhaben (oder Produkt) auf Agilität umstellt oder die Entstehung von Kopfmonopolen toleriert hat, wird man die daraus entstehenden Probleme spätestens bei der Planung bemerken.
Zunächst möchte ich betonen, dass dies kein Problem der Planung ist, sondern Symptom für ein anderes Problem: Wenn man einmal voraussetzt, dass die Prioritäten richtig gesetzt sind, ist das Grundproblem hier die mangelnde Flexibilität im Team. Oft haben sich Kopfmonopole gebildet, die von den einzelnen Entwicklern nur ungern verlassen werden – Schließlich sichert einem das Kopfmonopol Bedeutung und Anerkennung. Es kann aber auch inhaltliche Gründe geben, solche Kopfmonopole zu erzeugen. Zum Beispiel kann es aus Sicherheitsgründen sinnvoll sein, wenn nur wenige Entwickler über bestimmte Kernkonzepte informiert sind. Und auch im Kundenkontakt sind viele Kunden (mich eingeschlossen!) dankbar, wenn sie feste Ansprechpartner haben und nicht wie im Call-Center von Pontius zu Pilatus weiter gereicht werden. Aber abgesehen von solchen Spezialfällen sind Kopfmonopole ineffizient und sollten abgebaut werden.
Weiterlesen
Refactoring von C++
Programmiersprachen spielen keine wesentliche Rolle habe ich einst gelernt, es kommt vor allem auf die Qualität der Entwickler an. Diese Aussage stammt aus den frühen 80er Jahren, als Barry Boehm sein „Software Engineering Economics“ veröffentlicht hat. Und tatsächlich kann die beste Programmiersprache der Welt wenig ausrichten, wenn das Team inkompetent ist – und ein kompetentes Team wird auch mit altertümlichen Programmiersprachen noch etwas ausrichten können. Also alles in Butter? Gebt mir eine turingvollständige Sprache und ich wuppe Euch das Projekt? Wohl kaum.
Nur in wenigen Bereichen hat sich so viel in den letzten 25 Jahren verändert, wie bei Programmiersprachen und ihren Entwicklungsumgebungen. In den frühen 80ern hatte man im Wesentlichen noch die Auswahl zwischen C, COBOL, Pascal, PL/I und Assembler und bei den Entwicklungsumgebungen die Wahl zwischen vi, emacs und dem Host-Editor. Heute führen die Unterschiede zwischen den verschiedenen Sprachen und Umgebungen durchaus zu Produktivitätsunterschieden von einer Größenordnung, also um den Faktor 10; beim gleichen Team, wohlgemerkt.
Besonders fallen mir diese Unterschiede auf, wenn ich – wie heute einmal wieder – einem Kunden beim Umbauen einer C++ Anwendung helfe. Zur Erinnerung: C++ war der Versuch, dem guten alten C einige Konzepte überzustülpen, die bei flüchtiger Betrachtung als objektorientiert verkauft werden konnten. „Die C-Programmierer müssen dann nicht umlernen“ war die häufigste Begründung für diese Sprache. Ohne das belegen zu können, vermute ich, dass genau dieser Umstand – unreflektierter Einsatz objektorientierter Techniken von Programmierern, die nur in prozeduraler Programmierung ausgebildet sind – zu den häufigsten technischen Gründen für gescheiterte Projekte zählt.
Weiterlesen