EXtremely Dangerous - eine Polemik
von Karl Banke
Kent Beck's EXtreme Programming - XP - findet in letzter
Zeit ein starkes aber durchaus kontroverses Echo.
XP nimmt für sich in Anspruch eine
Art der Softwarentwicklung zu sein, die sich durch
schnelle Releasezyklen, gute Wartbarkeit und große
Robustheit der Lösungen auszeichnet. Wesentliche und
unabdingbare Bestandteile von XP sind u.a. Unit Tests,
Acceptance Tests, inkrementelle Entwicklung und Paarprogrammierung.
Aber XP hat eine radikale Schwäche - es gibt keinen Prozess, keine
Struktur. Programmierer finden das erst mal toll. Sie fühlen
sich befreit. Kent Beck ist so eine Art Jeanne d'Arc der Cybersklaven.
Danach kommt oft die große Ernüchterung. Die Kunden ziehen oft
nicht mit bei XP. Es klappt nicht im Team. Es gibt Streit. Die
Intelligenz verläßt das Land. Die Revolution frisst ihre Kinder.
Dass es sich bei XP weniger um eine Softwareentwicklungstechnik
als um eine Art revolutionäre Ideologie handelt, läßt sich
leicht anhand der Argumentation seiner Fürsprecher feststellen.
Großer Wert wird darauf gelegt, dass man
XP nur ganz oder gar nicht machen kann. Diese fundamentalistische
Geisteshaltung erinnert sehr an die Altsozialisten, die eine
strukturelle Schwäche ihres Gesellschaftsentwurfs beharrlich leugnen
und darauf bestehen, es wäre alles nur die Schuld der kompromittierten
Führungskader gewesen, die die Theorie nicht korrekt umsetzen wollten
oder konnten.
Sollte XP also bei Ihnen
nicht funktioniert haben und Sie die ein oder andere Million
dabei verblasen haben, können Sie Sich damit trösten, dass
nicht etwa ein grundsätzliches Problem von XP besteht,
sondern dass Sie XP eben nicht "ganzheitlich" betrieben
haben. Tröstlich. Aber Sie können auch Glück im Unglück haben.
Wenn Sie in einem großen Beratungsunternehmen arbeiten bekommen
Sie den Hosenbandorden, weil Sie das Projekt mit doppelt so viel
fakturierten Mitarbeitern an die Wand gefahren haben. Finanziell
nicht uninteressant, aber irgendwie trotzdem unbefriedigend -
besonders für Ihren Kunden.
Natürlich kann XP auch bei Ihnen funktioniert
haben. Ich wette, bei Ihnen im Team ist dann gute Stimmung und
alle sind zufrieden. Aber ich vermute, dass dies nicht an XP liegt,
sondern dass die gute Stimmung und der kollegiale Umgang
miteinander die wesentliche Voraussetzung dafür sind, dass XP
überhaupt funktionieren kann.
Allein - Sie brauchen immer noch
fachliche Kompentenz. Insbesondere liefert XP keine Strukturen, die es Ihnen
ermöglichen qualifizierte Spezialisten zu integrieren, die nicht
ins soziale Umfeld passen.
Der Superentwickler der sich nie wäscht, keine Socken trägt
und nach Alkohol riecht läßt sich schwer in ein XP Team integrieren.
Er arbeitet ja auch von vier Uhr Morgens bis drei Nachmittags und
geht dann Heim. Leider ist er der einzige, der überhaupt objektorientierte
Strukturen und Client/Server Entwurfsmuster halbwegs durchdrungen
hat. Oder der pedantische Spezialist der
Spezifikationen als Nachtlektüre verschlingt und diese
besserwisserisch seinen Kollegen unter die Nase reibt. Wollen Sie Ihn
in Ihrem XP Team in der Paarprogrammierung haben? - kaum, oder?
Aber Ihre Entwickler haben von Ihm mehr gelernt als aus allen
Seminaren des letzten Jahres zusammengenommen.
Unit Tests
Eins der wesentlichen Elemente von XP sind Unit Tests. Wenn
Sie jemals komplexe Softwaresysteme entwickelt haben, dann
wissen Sie, dass es sich dabei um eine sinnvolle Sache handelt.
In einem kürzlich erschienenen XP-Artikel verstieg sich der Autor
zu der Feststellung, er schreibe Tests aus Genuss-Sucht. Jedem
das Seine. Aber einige Probleme werden regelmäßig ignoriert. Es wird nämlich
unterschlagen, dass es mindestens zwei Arten von Tests gibt: Einfache Tests
und komplexe Tests. Einfache Tests sind doof. Sie werden kaum einen
Praktikanten finden, der aus Genuss-Sucht einfache Tests schreibt.
Einfache Tests werden - wenn überhaupt - von Männern und Frauen
in unscheinbaren grauen Anzügen geschrieben, die schon zu viele
Projekte haben Scheitern sehen. Diese Leute haben
eingesehen, dass es einfache Tests geben muss, oder es geht gar
nichts. Sie sind ein bißchen wie verbitterte Techniker der
sowjetischen Eisenbahn. Ihre Arbeit ist nicht anspruchsvoll
und ihr Material ist nicht modern. Aber ohne sie würde der Staat
vollends zusammenbrechen.
Und glauben Sie, dass solche Leute in typischen XP Teams
vertreten sind? Ich bin skeptisch.
Schwierige Tests, oh ja, da kann
schon Genuss-Sucht aufkommen. Schwierige Tests gehören aber nicht
in die Hände von Anfängern. Warum werden Sie fragen, geneigter Leser?
Weil niemand die Tests testet! Hier macht übrigens Paarprogrammierung
absolut Sinn. Das Erstellen der Unit Tests soll ja halbwegs schnell
gehen. Schließlich entwickeln Sie ja Software und sind keine
Testdebugorganisation.
Ach Tests, was könnte man nicht alles dazu schreiben. XP soll ja für
kleinere und mittlere Projekte eingesetzt werden. Bei vielen Projekten
ist das Erstellen einer Testumgebung erforderlich. Idealerweise dann
aber auch für jede(n)s Programmierer(paar). Der Overhead dazu ist
ggf. beträchtlich. Entwickelt man z.B. ein datenbankbasiertes
3-Tier System, so muss insbesondere der Persistenztier für jeden Entwickler
auf einen definierten Stand initialisierbar sein. Dabei müssen die
Entwickler Datenbestände für die komplexen Probleme emulieren
und deren Initialisierung planen. Stellen Sie Sich nun vor, das Team,
das die grafische Oberfläche entwickelt, will testen. Was tun wenn
der Test fehlschlägt? Liegt es am 2nd oder 3rd Tier? Aber die sind
doch getestet. Aber vielleicht nicht genau für die vorliegende
Konfiguration. Da muss wohl jemand einen neuen Test schreiben,
um die anderen Systemteile zu debuggen.
Das Paar, das den 2nd Tier entwickelt hat, macht aber etwas anderes.
Und das Paar vom 3rd Tier ist in Urlaub.
Und sich in die Softwareteile einzuarbeiten fällt schon aufgrund
der fehlenden Designdokumentation schwer.
Paarprogrammierung
Oje, die Paarprogrammierung. Oben haben wir ja schon einige Charaktere
kennengelernt, für die es schwer wird, den richtigen Partner zu
finden. Aber OK, angenommen die Leute können miteinander:
Paarprogrammierung macht Spass. Es gibt grundsätzlich
zwei Konstellationen. Entweder sind beide auf dem gleichen
Leistungsniveau oder eben nicht. Nach XP Doktrin sollte der
eine nun vom anderen lernen können. Aber Programmierer sind
ungeduldig. Und stur. Und manchmal ganz schön begriffstutzig.
Dabei sind Unterschiede im Temperament und Charakter noch gar
nicht berücksichtigt. Verletzungen und Streit sind unvermeidbar.
Dabei kann ein Konflikt ja durchaus produktiv sein. Erinnern Sie sich
noch an den letzten Streit im Büro? War ganz positiv oder? Aber
erinnern Sie Sich auch noch an den letzten größeren Streit, mit jemandem,
dem Sie immer sehr nahe sind, mit dem sie täglich intensiv
diskutieren? Zuhause? Sehen Sie, XP ist eben auch verdammt nah am
Ehekrach und die meisten Morde werden ja im Bekanntenkreis...aber
lassen wir das.
Paarprogrammierung bedingt eine engere Zusammenarbeit als die meisten
Programmierer sie gewohnt sind. Sie erfordert eine ständige
Auseinandersetzung nicht nur mit dem Problem und dem Kunden
- komplex genug - sondern auch mit dem Programmierpartner. Finden
die Partner hier in entsprechende Rollen, - bei Respekt vor der Person
und Arbeit des jeweils anderen - werden sie ausgezeichnete Ergebnisse
erzielen. Aber gewöhnlich scheitert dies an einfachen Dingen, die noch
nicht mal etwas mit der eigentlichen Aufgabe zu tun haben. Vielleicht
ist einer von beiden Raucher, einer hat unangenehmen Körpergeruch,
eine dem anderen unangenehme Stimme usw. Dann gehen Sie mal zu Peter und
erklären, dass sie ihn, Dipl.-Inf., beeindruckende
Projekthistorie, nicht in Ihrem Team haben wollen, weil sie keine
Raucher brauchen können. Da wird er sich freuen.
Aber nun fängt das Konfliktpotenzial erst an so richtig zu brodeln.
Vielleicht können Hans und Hilde ja ganz gut zusammen arbeiten. Aber
Hilde ist fachlich besser und Hans kann sich von einer Frau nichts
erklären lassen - auch nicht, dass eine Klasse mit nur einer Methode
und zehntausend Codezeilen einfach nicht ganz richtig sein kann.
Hilde fühlt sich jetzt - zurecht - frauenfeindlich behandelt. Außerdem
wird ihre Kompetenz in Frage gezogen. Sie muss das Problem eskalieren.
In einem klassischen Projekt hätte man Hans vielleicht ein
Softwaredesign zum Ausimplementieren gegeben. Er hätte dann die
Vorteile des gewählten Ansatzes erkennen können, anstatt sich jetzt
mit Hilde zu streiten.
Der Projektmanagers
Der Projektmanager wird in der XP Mythologie von den technischen
Aufgaben entlastet und kann sich ganz seiner Hauptaufgabe - der
Pflege der Schnittstelle zum Kunden und der Auswahl des Personals-
widmen.
Dies ist möglich, da ja die unittestenden und paarprogrammierenden
Entwickler sowieso allererste Qualität abliefern.
Die Realität sieht
allerdings heute schon so aus, dass ein Großteil der Projekte große
Schwierigkeiten haben, weil der Projektmanager seine
Tätigkeiten auf den obengenannten Bereich beschränkt.
Jedes Projekt braucht auch
einen technischen Schiedsrichter. Wäre dem nicht so, könnte
man ja auch in einem Bundesligaspiel auf die Einsichten der Betroffen
vertrauen.
Der Schiedsrichter ist notwendig, weil es immer wieder
verschiedene Meinungen und Vorlieben gibt, die
sich nicht abwägen lassen, sondern die entschieden werden
müssen. Denken Sie an Teams in denen wochenlang diskutiert wurde, ob
denn in C++ oder Java, mit Corba oder Enterprise Java Beans, mit oder ohne
Microsoft entwickelt werden soll. Denken Sie an nicht endenwollende
Diskussionen über Architekturmuster. Ich selber war einmal an einer
mehrwöchigen Auseinandersetzung über die richtige Einrücktiefe
für Quellcode beteiligt.
Alles in allem ist der Projektmanager meiner Überzeugung nach in einem
XP Projekt sogar stärker gefordert, als in einem klassischen, sich mit
den technischen Einzelheiten des Systems auseinanderzusetzen. Der
Grund ist einfach der, dass wesentliche Designentscheidungen
dezentralisiert auf die Programmierpaare verlagert werden.
Ein Schiedsrichter kann vielleicht ein Fußballspiel pfeifen, aber
keine fünf Tennisdoppel gleichzeitig! Ich finde es übrigens sogar
recht positiv, wenn sich Projektmanager verstärkt mit technischen
Fragen auseinandersetzen müssen. Meine diesbezügliche Überzeugung ist
seit langem, dass jedes Projekt zwei Projektmanager braucht,
die sich für die "technischen" und die "fachlichen" Richtungen
vertiefen, aber jederzeit einander vertreten können müssen.
Is Change Your Friend?
"Make change your friend" schallt es freimütig aus den Reihen der
XP-Jünger zu uns herüber. Und sie haben ja auch das Werkzeug an der
Hand, mit dem dies einfach wird. Genau, die bestehenden Unit Tests. Das ist
natürlich Quatsch. Die Existenz von Tests verbessert nicht die
Änderbarkeit von Software. Sie verbessert nur die formalisierte
Testbarkeit von Änderungen.
Kritisch wird es allerdings, wenn der Test selbst, seine
Initialdaten usw. aufgrund einer Änderung der Software geändert werden
müssen. Kommt nicht vor? Kommt fast immer vor!
Hier stellt sich auch die Frage, was denn der zentrale Aspekt ist,
der ein Software System gut änderbar macht. Es ist das Design der
Software ("designed for flexibility"), die vorhandene Dokumentation
und idealerweise der Zugriff auf die ursprünglichen Entwickler.
Allein: XP kennt kein zentrales Softwaredesign. Sicher - alle
benutzen Architektur- und Designmuster. Dann fangen Sie schon mal
an zu beten, dass sie sie auch verstehen und richtig benutzen.
Und einen weiteren Stolperstein hält XP für uns bereit. Es fordert
Einfachheit. Was das sein soll, bleibt einigermaßen unklar.
Erfahrungsgemäß ist einfache Software aber immer hochspezialisierte
Software. Da sie für genau einen Zweck geschrieben wurde - einfach
ist - ist sie vielleicht einfach zu verstehen, einfach und schnell
zu schreiben aber typischerweise gerade nicht einfach
zu ändern.
Einfachheit zu einem zentralen Element von XP zu machen zeugt schon
von ziemlicher Chuzpe. Stellen Sie Sich vor, alle Fahrkartenautomaten
wären mit maximaler Einfachheit konstruiert worden. Schade, das mit dem
Euro....
Meet the customer
XP verlangt den On Site Customer. Er arbeitet eng mit dem Team
zusammen, plant die Iterationen mit und wirkt bei den Acceptance Tests
mit. Sie bekommen alle Abnahmen. Der Kunde ist da, um Ihnen zu sagen,
welche Beschaffenheit die Daten haben. Er weiß es. Er weiß
im Zweifel wen er fragen kann. Und der weiß es. Ihr On Site Customer
ist in der Lage Entscheidungen zu treffen oder zumindest diese
herbeizuführen. Nach einer Übergabe
bekommen Sie klare und eindeutige Mängellisten, die sie abarbeiten können.
Wenn Sie einen solchen Kunden haben, ist Ihr Entwicklungsprozeß
egal. So sind die Kunden aber selten. Nicht aus bösem Willen, sondern
aus Arbeitsüberlastung, aus (aus Ihrer Sicht) falscher Priorisierung oder
aus Unvermögen.
Sie erhalten oft einfach keine korrekten Daten, noch ist es möglich sie
zu beschaffen. Der On Site Customer ist einfach nicht verfügbar. Oder
er weiß es nicht. Oder er weiß nicht, wen er fragen soll. Oder der
weiß es nicht.
Die Reklamationen kommen tröpfchenweisen Monate nachdem das System
in Produktion ist. XP scheitert mit solchen Kunden sozusagen
per Definition. Andere Projektmethodiken haben Prozesse, um damit umzugehen.
Zusammenfassung
Zusammenfassend kann gesagt werden, dass XP nicht nur keine
neuen Erkenntnisse bietet. Es ist eine kontraproduktive Technik.
Sicherlich bedient sie sich Methoden, die für sich genommen
sinnvoll sein sind oder sein können,
wie Paarprogrammierung, Unit Tests, Kundennähe, iterative Entwicklung
usw. Sie bietet aber nicht nur keinen organisatorischen Rahmen, keinen
Prozeß, sondern leugnet auch noch die Sinnfälligkeit eines
solchen. Darüber hinaus stellt XP extreme Anforderungen an das
Arbeitsumfeld und die Kundeninteraktion. Sind diese Anforderungen
aber im XP Sinne erfüllt, so wird vermutlich auch jede andere Methodik
erfolgreich sein.
Manchmal braucht es aber große ideologische Entwürfe, um
Fehlentwicklungen zu begegnen. Ohne das kommunistische Manifest
gäbe es vielleicht keine bürgerliche Mittelschicht. Aber in der
EDV sind wir aufgrund hervorragender formalisierter und iterativer
Softwareentwicklungsprozesse, wie OPEN oder RUP schon recht weit
entfernt vom Pendant des Manchesterkapitalismus. Insofern ist es
sicherlich sinnvoll sich erst mit deren Katechismus zu befassen,
bevor man falschen Propheten nachläuft.
Literatur
- Kent Beck. Extreme Programming Explained: Embrace
Change. Addison-Wesley. 1999.
- Ronald E. Jeffries et al., Extreme Programming Installed
Addison Wesley (30. November 2000)
- Extreme Programming: Pro und Contra
iX 01/2002, S. 94
Karl Banke
2004-01-21