Extreme Programming gewinnt an Fahrt

Raus aus dem Programmier-Alltag

10.12.2001
Softwareentwicklung in kleinen Schritten ist in der Theorie eine attraktive Alternative zum Big-Bang-Verfahren. Projektteilnehmer berichten von ihren guten Erfahrungen. von Hasko Heinecke und Christian Noack*

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.