Die Ursprünge von XP

1996 wurde Kent Beck engagiert, um ein gescheitertes Gehaltsabrechnungsprojekt bei Chrysler namens C3 (Chrysler Comprehensive Compensation) zu retten. Das Projekt steckte in Schwierigkeiten – klassische Wasserfallentwicklung hatte ein System hervorgebracht, das nicht funktionierte und nicht repariert werden konnte.

Beck hat das Projekt nicht nur gerettet. Er synthetisierte jahrzehntelange Software-Engineering-Weisheit zu einer kohärenten Methodik. Er nahm Praktiken, von denen erfahrene Entwickler wussten, dass sie funktionieren – Testen, Code-Review, iterative Entwicklung – und trieb sie auf ihre logischen Extreme.

Wenn Testen gut ist, teste ständig. Wenn Code-Review gut ist, überprüfe kontinuierlich durch Pair Programming. Wenn Integration gut ist, integriere mehrmals täglich. Wenn kurze Iterationen gut sind, mache sie noch kürzer.

Das C3-Projekt wurde ausgeliefert. Noch wichtiger: Es schuf eine Vorlage, die die Softwareentwicklung neu gestalten sollte.

1999 veröffentlichte Kent Beck „Extreme Programming Explained" – oft „das White Book" wegen seines Einbands genannt. Dies wurde das Gründungsdokument von XP und eines der ersten agilen Manifeste.

Das Buch war kontrovers. Die ganze Zeit Pair Programming? Kein großes Design im Voraus? Kunden vor Ort? Viele in der Branche hielten Beck für verrückt. Aber Teams, die XP ausprobierten, berichteten von bemerkenswerten Ergebnissen:

• Dramatisch weniger Fehler, die die Produktion erreichten
• Nachhaltiges Tempo statt Todesmärschen
• Funktionierende Software statt Dokumentationsversprechen
• Zufriedene Entwickler, die sich in Kontrolle fühlten

Zwei Jahre später, 2001, schloss sich Beck sechzehn anderen Software-Praktikern in Snowbird, Utah, an. Gemeinsam schrieben sie das Agile Manifesto. XPs Einfluss ist durchgehend sichtbar – Individuen über Prozesse, funktionierende Software, Zusammenarbeit mit Kunden, Reagieren auf Veränderungen.

XP war die erste vollständige agile Methodik, und in vielerlei Hinsicht bleibt sie die rigoroseste.

Die traditionelle Sichtweise der Softwareentwicklung war, dass Veränderung teuer ist. Die Kosten für die Behebung eines Fehlers wachsen exponentiell von den Anforderungen über das Design und die Codierung bis zum Testen und zur Produktion. Daher sollte man alles Mögliche tun, um es beim ersten Mal richtig zu machen – daher Wasserfalls Betonung auf umfassendem Design im Voraus.

Beck schlug eine radikale Alternative vor: Was wäre, wenn man die Kurve der Änderungskosten abflachen könnte?

Wenn Sie haben:

• Umfassende automatisierte Tests (Änderungen können sofort validiert werden)
• Einfaches Design (weniger zu ändern)
• Kollektives Code-Eigentum (jeder kann Änderungen vornehmen)
• Kontinuierliche Integration (Änderungen werden sofort integriert)
• Refactoring-Fähigkeiten (Code kann sicher weiterentwickelt werden)

Dann werden die Änderungskosten im Laufe der Zeit ungefähr konstant. Und wenn Veränderung billig ist, müssen Sie die Zukunft nicht vorhersagen. Sie können Veränderung als Wettbewerbsvorteil annehmen.

Das ist XPs fundamentale Erkenntnis: Technische Praktiken können Veränderung billig machen, und billige Veränderung ändert alles.