Kent Beck, Ward Cunningham und Ron Jeffried hatten mit ihren Theorien zur agilen Software-Entwicklungsmethode Extreme Programming (XP) viel Staub aufgewirbelt. Zum fünften Geburtstag seiner XP-Bibel «Extreme Programming Explained» hat Kent Beck nun eine neue Auflage des Buches publiziert, welche die aktuellen Entwicklungen und Bedürfnisse in der agilen Software-Entwicklung berücksichtigt.
Zu Beginn galten Becks Ideen zur Software-Entwicklung als unglaublich extrem. Doch heute sind viele der Extreme-Programming-Praktiken akzeptiert. In seiner von Grund auf neu geschriebenen, zweiten Auflage seines Bestsellers zeichnet Kent Beck ein aktuelles Bild: Die vielleicht effektivste und zugleich menschlichste Software-Entwicklungsmethodik ist mit der Zeit noch effektiver und menschlicher geworden.
So schlägt das neue Extreme Programming leisere Töne an. Die Kinderkrankheiten hat es hinter sich gebracht, es ist erwachsen geworden. Im Kern finden sich nach wie vor die vier grossgeschriebenen Werte: Einfachheit, Kommunikation, Feedback und Mut. Schon seit frühesten Tagen lag XP mit dem Respekt ein fünfter Wert zu Grunde. In der neuen Fassung hält der Respekt nun explizit Einzug ins Wertesystem.
Durch die gesammelten Erfahrungen der vergangenen Jahre sind die ursprünglichen XP-Praktiken sowohl verbessert, vereinfacht und konkretisiert als auch verallgemeinert worden. Fanden sich früher nur ein Dutzend Praktiken, hat sich die Anzahl mit der Überarbeitung verdoppelt. Der Grund für die scheinbare Zunahme der schlanken Methode ist, dass die Praktiken jetzt in Pflicht und Kür aufgeteilt sind: Während die primären Praktiken meist isoliert anwendbar sind und deshalb in jedem Prozess zu einer sofortigen Verbesserung führen können, setzen die weiterführenden Praktiken auf den Grundstock auf und führen den agilen Prozess schliesslich an seine Leistungsgrenzen. Nicht zuletzt durch diese Abschwächung gelingt es dem runderneuerten XP, einerseits die Eingangsschwelle für jedermann zu senken und andererseits in Anwendungsbereiche vorzudringen, für die es ursprünglich nicht geeignet schien. Als Beispiele seien hier nur grosse und verteilte Projekte genannt.
Vieles hat sich durch XP in den letzten Jahren verändert: Einige Praktiken werden mittlerweile in der Ausbildung vermittelt, automatisiertes Testen ist zum festen Bestandteil der Entwicklungskultur geworden. Zur inkrementellen Verbesserung des Softwaredesigns stehen Entwicklungsumgebungen mit automatisierter Refactoring-Unterstützung zur Verfügung, und Pair Programming ist heute viel breiter akzeptiert. Während sich das leichtgewichtige XP bislang nicht gegen schwergewichtige Prozesse in grossen Organisationen durchsetzen konnte, scheint es vor allem in kleineren Unternehmen Erfolg zu haben. Der Grund dafür ist sicherlich, dass dem vorherrschenden chaotischen «Code und Fix»-Vorgehen vieler Softwareunternehmen mit dem gesunden Menschenverstand von XP schnell zu einem massiven Produktivitätsgewinn verholfen werden kann.
War XP auch die erste agile Methode, die von einer breiten Masse wahrgenommen wurde, so steht ihr Bekanntheitsgrad heute in keinem Verhältnis zu ihrem Verbreitungsgrad. Ganz anders sah dies noch aus, als das erste Buch erschien. Zu Zeiten der Dotcom-Ära gedieh XP überaus prächtig, schliesslich passte seine Philosophie hervorragend in die damalige Projektlandschaft von kleinen schnellen Teams in einer Welt mit sich rapide verändernden Anforderungen. Mit dem Ende dieser Ära ging aber teils auch der für innovative, sich selbst organisierende Projektteams nötige kulturelle Nährboden verloren. Die Verbreitung von XP fand so ihre organisatorischen Grenzen. Und während der Name gerade in Programmiererkreisen grosse Aufmerksamkeit erzeugte, stiess er im Management schon damals übel auf. XP war aus Sicht der Programmierer beschrieben, so dass die Änderungen in der Projektabwicklung aus Management- und Kundensicht nicht als Chancen, sondern lediglich als Risiken wahrgenommen wurden. Dieses Bild soll mit dem neuen XP korrigiert werden. Denn mit seinem erweiterten Rollenmodell werden auch Nicht-Programmierer in die XP-Teams eingebunden.
Auffällig ist, dass viele Anleihen aus dem Lean Manufacturing herausgearbeitet wurden. Gerade die Parallelen zum Toyota-Produktionssystem, der Just-in-Time-Fertigungsstrategie des führenden japanischen Autobauers, können ein Weg sein, um den XP-Ideen im Management zu einer höheren Akzeptanz zu verhelfen. Bisher standen nur Fragen wie die Effizienz von Pair Programming, testgetriebener Entwicklung oder eines Kunden vor Ort im Zentrum der Diskussion. Dabei nützt es in der heutigen Zeit des Kostendrucks für die Akzeptanz weit mehr, wenn sich die Aufmerksamkeit auf übergeordnete Themen wie Wertschöpfungsketten, Return on Investment, Zero Defects und Time to Market verlagert. Denn durch die Einführung neuer Praktiken wie der Ursachenforschung zur Fehlerprävention sowie der Anwendung der Theory of Constraints zur Vermeidung von Flaschenhälsen gelingt es XP, die nötige, am japanischen Kaizen orientierte Philosophie der kontinuierlichen Prozessverbesserung zu etablieren. Wie weit man jedoch mit dem extremen Programmieren gehen will, bleibt insbesondere nach Aufweichung der Praktiken jedermann selbst überlassen. XP stellt in sich sowieso kein Ziel dar, sondern ist und bleibt ein Weg zur Verbesserung der Software-Entwicklung.
Die zweite Auflage der Extreme-Programming-Bibel «Extreme Programming Explained» wurde von Autor Kent Beck, einem der Erfinder der Methode zur agilen Entwicklung von Software, von Grund auf neu geschrieben. In dem Buch zeichnet er nun das Bild einer Theorie, die durch die Einflüsse aus fünf Jahren Entwicklungspraxis zum Teil sehr stark verändert hat und auch erwachsener geworden ist.
Kent Beck,
Cynthia Andres
Addison-Wesley
ISBN: 0-3212-7865-8
Frank Westphal (business@frankwestphal.de) ist Softwareentwicklungscoach aus Hamburg.
Tammo Freese (freese@acm.org) ist Softwareentwickler und Berater aus Oldenburg.
