Angesichts der Schwierigkeiten, Software termingerecht und in guter Qualität herzustellen, gewinnen formale Entwicklungsmethoden wieder an Bedeutung. Dabei lassen sich zwei Strömungen unterscheiden: Auf der einen Seite gibt es Verfahren wie das "V-Modell" oder den "Rational Unified Process", bei denen die Nachvollziehbarkeit von Design- und Implementierungsentscheidungen große Bedeutung hat. Dazu gibt es ausführlichste Dokumentationen. Dem stehen die so genannten leichtgewichtigen oder agilen Prozesse gegenüber, unter anderem "Feature Driven Development", "Adaptive Software Process" und als Vorreiter "Extreme Programming" (XP).
Charakteristisch für XP ist, dass weniger Gewicht auf die Dokumentation des Projektverlaufs gelegt wird. Stattdessen steht die zu entwickelnde Software im Vordergrund - die eigentliche Implementierung also. XP setzt dazu Rahmenbedingungen für diszipliniertes und kontrolliertes Arbeiten und legt seinen Schwerpunkt auf die mündliche Kommunikation der Projektbeteiligten. Dokumentation auf Papier wird reduziert, aber nicht abgeschafft. Das soll Mehrarbeit aufgrund veralteter Unterlagen verringern.
Ein weiteres Merkmal von XP ist, dass in kurzen Zeiträumen von wenigen Wochen jeweils funktionsfähige Softwarepakete ausgeliefert werden sollen. In einem iterativen Prozess legt das Team nach jeder Entwicklungsschleife die Prioritäten für die nächste Schleife neu fest. Dabei hat der Kunde jeweils auch die Möglichkeit, neue Anforderungen einfließen zu lassen und den Stellenwert von alten zu ändern. Die Regeln hierfür bestimmt das "Planning Game".
Die fachlichen Anforderungen legt man bei XP in so genannten "User Stories" fest - kurzen, informellen Beschreibungen von Elementen der Systemfunktionalität. Sie sind vergleichbar mit Ivar Jacobsons "Use Cases", aber weniger formal und bilden die Grundlage der Planung und der Entwicklung. Die Implementierung der dargestellten Funktionalität, geprüft durch Akzeptanztests, markiert schließlich den Projektfortschritt.
Für die interne Code-Qualität sorgen automatisch ausführbare "Unit Tests", die das erwünschte Verhalten einzelner Softwarekomponenten widerspiegeln. Diese Tests dienen außerdem zu einem guten Teil als Design-Dokumentation. Unit Tests schreibt man im Allgemeinen bereits vor der zu testenden Implementation und führt sie während der Entwicklung regelmäßig - mehrmals täglich - automatisch aus.
Auch durch "Pair Programming" lässt sich eine hohe Code-Qualität erreichen: Die Entwickler arbeiten paarweise und führen so ein kontinuierliches Code-Review durch. XP erfordert an vielen Stellen von den Programmierern ein hohes Maß an Disziplin. Das Entwickeln zu zweit macht vielen mehr Spaß, als allein zu arbeiten, und ist gleichzeitig ein gutes Mittel, um die benötigte Disziplin aufrechtzuerhalten.
In XP-Projekten geht es darum, täglich zu integrieren, das heißt, lauffähige Bausteine zu bauen. Die Unit Tests müssen zu 100 Prozent erfolgreich durchlaufen. Der Kunde kann sich dadurch jederzeit nach Bedarf einen Eindruck vom momentanen Entwicklungsstand verschaffen und steuernd eingreifen.
Praxistauglich
Vor einigen Jahren von Kent Beck entwickelt, kann XP bereits eine große Gemeinde von IT-Profis zu seinen Unterstützern zählen. Ursprünglich konzipierte Chrysler (damals noch ohne Daimler) die Methode für die Entwicklung eines Lohnbuchhaltungssystems. Heute setzen Unternehmen jeder Größenordnung das Verfahren prototypisch in einzelnen Projekten ein. In Vorhaben, deren Rahmenbedingungen unsicher sind oder in denen die Anforderungen sich im Laufe der Zeit ändern und somit ein permanentes Feedback vom Kunden notwendig ist, verspricht der Einsatz von Extreme Programming, die Kosten der Softwareentwicklung über
Rasch amortisieren
den gesamten Lebenszyklus zu reduzieren. Die rasche Verfügbarkeit einsatzfähiger Produkte bedeutet zudem, dass sich die eingesetzten Mittel schneller amortisieren.
Davon, wie sich XP in der Praxis bewährt, berichten Christian Wege, bei Daimler-Chrysler zuständig für IT Strategic Planning & Enterprise Technology/Software Development Environments, Hans Wegener, der sich bei der Crédit Suisse mit Data Warehousing beschäftigt, Peter Gassmann vom Schweizer Sun Java Center und Dierk König, verantwortlich für Geschäftsleitung und Coaching bei der Canoo Engineering AG in Basel. Die Projekte der Unternehmen sind sehr unterschiedlich: Während Canoo Softwareprodukte entwickelt und verkauft, setzt Daimler-Chrysler XP ein, um Web-basierte Anwendungen für eine kleine, europaweit verteilte Zielgruppe zu bauen. Die Crédit Suisse hat ein Metadaten-Management-System für Data Warehousing geschaffen, und Gassmann sammelte Erfahrungen mit der Entwicklung einer Außendienstanwendung für ein Versicherungsunternehmen.
Umfang und Dauer der betrachteten Projekte liegen in dem von XP vorgesehenen Rahmen. Mit drei bis zehn Entwicklern und einer Laufzeit von drei Monaten bis drei Jahren sind sie aber eher am unteren Ende der Komplexitätsskala anzusiedeln.
Warum Extreme Programming?
"Wir haben auf XP gesetzt, da uns bei unserem geplanten Vorhaben das Geld knapp geworden wäre, wenn wir einen klassischen Entwicklungsweg eingeschlagen hätten", erklärt Daimler-Chrysler-Mitarbeiter Wege. In Gassmanns Projekt waren dagegen "schwammige, nicht klar definierte Anforderungen" der Grund, die extreme Methode zu wählen. Finanz- und Zeitnot verbunden mit unklaren und unvollständigen Spezifikationen und Zielen sind die meistgenannten Merkmale großer Softwareprojekte.
Die Entscheidung für XP traf zunächst häufig das Entwicklungsteam, und es trug sie dann an den Auftraggeber - etwa die Fachabteilungen - heran. Entgegen der Befürchtung, dort auf "ideologische Barrieren" zu stoßen, fand XP Zustimmung. Dazu müsse allerdings eine Vertrauensbasis zwischen Projektteam und Auftraggeber bestehen, berichtet Canoo-Geschäftsführer König aus eigener Erfahrung.
Einig sind sich die Befragten, dass sich mit XP auf wandelnde Anforderungen in Projekten flexibel reagieren lässt, doch gewichten die Unternehmen die einzelnen Merkmale von XP unterschiedlich: Während bei dem einen die Praktiken wie Refactoring und Unit Testing im Vordergrund stehen, nennen andere dahinter stehende "Werte" wie Einfachheit, Kommunikation, Feedback und Mut. In keinem der untersuchten Projekte verwendet man XP jedoch in Reinform, also strikt"nach dem Buch". Stattdessen werden in den meisten Fällen einige der Techniken weggelassen, abgewandelt oder ergänzt.
Problematisch war für alle Befragten, dass bei XP ein Kundenvertreter ständig beim Projektteam anwesend sein soll ("On site Customer"), um Fragen der Entwickler zu beantworten und Unklarheiten zu beseitigen. Die Gründe: Die verschiedenen Kundengruppen hätten unterschiedliche Anforderungen an das System, und die Kunden seien geografisch verteilt oder hätten zu viel mit ihrem Tagesgeschäft zu tun, um sich im notwendigen Maß dem Projektteam widmen zu können. Deshalb gibt es hier oft Abweichungen von der reinen Lehre.
So auch bei Gassmanns Außendienstanwendung: "Wir haben den On Site Customer durch ein Mehr an Dokumentation und einen Proxy (Vermittler) ersetzt, dessen Funktion die Projektleitung übernahm." Dieser Vermittler sammelte die Fragen an die Auftraggeber und reichte sie gebündelt weiter, um die Kunden zu entlasten.
Weniger problematisch ist das Prinzip des Pair Programming - der Arbeit zu zweit vor dem Rechner: "Die Unit Tests sowie Refactoring, also die permanente Restrukturierung des Code, führten zur Qualitätsverbesserung", erklärt Gassmann. Für König ist kontinuierliches Refactoring so in die Arbeit integriert, dass es zum untrennbaren Bestandteil des Programmierens wird: "Wo Refactoring stattfindet, gilt Unit Testing als unabdingbare Voraussetzung", betont er. Dabei werden für jede Klasse, für jede nicht-triviale Methode automatisierte Tests geschrieben.
Laut König und Gassmann folgt daraus in der Summe über die Projektdauer aber kein Mehraufwand. "Im Gegenteil, konsequentes Schreiben von Unit Tests beschleunigt die Arbeit", lautet das einstimmige Urteil. Denn durch das Schreiben der Tests entstehe gleichsam das Design des Codes, und darüber hinaus erlaubten die Tests die ständige Fehlerkontrolle. Ferner ließen sich Unit Tests als exzellente Dokumentation für den eigentlichen Programm-Code verwenden.
Allen Befragten war Dokumentation in XP-Projekten wichtig. Diese müsse allerdings nicht immer auf dem Papier stehen, hieß es. Zur Dokumentation zählten neben den Unit Tests technische Kochbücher und nötigenfalls Architekturdokumente, besonders wenn das Projekt zu einem späteren Zeitpunkt weitergeführt werden müsse, erklärt Credit-Suisse-Mann Wegener.
Ein wichtiger Bestandteil der Dokumentation seien die User Stories. Die darin formulierte Anforderungsspezifikation anhand von praktischen Anwendungsszenarien entsteht in XP-Projekten während des Planning Game.
User erzählen Stories
Dieses immer wiederkehrende Planungsspiel mit Kunden und Entwicklern halten alle Befragten für das wichtigste Instrument zur Projektplanung. "Hier bekommen die Entwickler Sicherheit über den Umfang und den Zeitplan des Projekts, und die Abnehmer gewinnen Sicherheit über die Kosten der Softwareentwicklung", sind sich die vier einig.
Zusammenfassend bleibt festzustellen, dass Extreme Programming sowohl realen betriebswirtschaftlichen als auch sozialen Bedürfnissen in Softwareprojekten gerecht wird. Dabei ist schwierig zu messen, wie viel XP in einem Projekt tatsächlich gemacht wird und wie sehr es sich nach der reinen Lehre richtet. Ein solcher Maßstab, gleich wie gewählt, würde aber wohl eine starke Schwankungsbreite der konkreten Ausprägungen von Extreme Programming offenbaren.
So besteht auch die Gefahr, XP in der Flut der individuell angepassten und untereinander unähnlichen Umsetzungen zu verlieren. Scheitern Projekte mit modifizierten Varianten von XP, kreidet man den Misserfolg leicht der Methode an, statt ihn auf die Modifikationen zurückzuführen. Dies sollte für alle ein Grund sein, ein erstes XP-Projekt durch einen erfahrenen Coach betreuen zu lassen.
* Hasko Heinecke ist Consultant der Daedalos Schweiz, und Christian Noack ist Projektleiter bei Daedalos Consulting in Witten.