Hasko Heinecke und Christian Noack veröffentlichten im Jahr 2001 den Artikel Raus dem Programmier-Alltag - Extreme Programming gewinnt an Fahrt in der Computerwoche. Auch wenn die genannten Technologien und Verfahren mitunter nicht mehr aktuell sind, bleibt der Artikel interessant, da er klar macht, warum Anfang der 2000er Jahr die traditionellen Vorgehensmodelle der Softwareentwicklung durch die Agilen Methoden abgelöst wurden.
Auszüge aus dem Artikel
Softwareentwicklung in kleinen Schritten ist in der Theorie eine attraktive Alternative zum Big-Bang-Verfahren. Projektteilnehmer berichten von ihren guten Erfahrungen.
Angesichts der Schwierigkeiten, Software termingerecht und in guter Qualitat 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 Zeitraumen von wenigen Wochen jeweils funktionsfähige Softwarepakete ausgeliefert werden sollen. In einem iterativen Prozess legt das Team nach jeder Entwicklungsschleife die Prioritaten für die nachste 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 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 werden. Der Kunde kann sich dadurch jederzeit nach Bedarf einen Eindruck vom momentanen Entwicklungsstand verschaffen und steuernd eingreifen.
Vor einigen Jahren von Kent Beck entwickelt, kann XP (in 2001) bereits eine große Gemeinde von IT-Profis zu seinen Unterstützern zählen. Ursprünglich konzipierte Chrysler die Methode für die Entwicklung eines Lohnbuchhaltungssystems. Heute (2001) 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 den gesamten Lebenszyklus zu reduzieren. Die rasche Verfügbarkeit einsatzfähiger Produkte bedeutet zudem, dass sich die eingesetzten Mittel schneller amortisieren.
Fazit
Die Autoren kamen seinerzeit zum dem Fazit, dass die von eXtreme Programming vorgeschlagenen Praktiken, erheblich zum Projekterfolg beitragen können - ein Ergebnis, dass sicher auch im Jahr 2013 für die aktuellen Agilen Methoden (wie SCRUM) zutrifft. Einige der genannten Verfahren sind heute glücklicherweise in den Arbeitsalltag von Softwareenwicklern integriert.
Der Artikel schließt mit der Warnung, dass das unüberlegte Abweichen von den durch eXtreme Programming definierten Werten und Praktiken zu einer Beliebigkeit im Vorgehen führt, die Vorteile der Agilen Methode zunichten machen und ganze Projekt gefährden kann - ein Problem, dem man auch heute in SCRUM-Projekten häufiger begegnen kann.