Extreme Programming: XP Revisited

Erweiterungen von XP

Einen Teil seines Erfolgs verdankt XP seiner knappen und klaren Formulierung. In mancherlei Hinsicht ist es aber auch schlicht unterspezifiziert. Schon sehr bald wurden darum ergänzende Techniken und Anpassungsvorschläge veröffentlicht (siehe z. B. [6]). Einige davon sind:

  • Standup Meeting: Tägliches kurzes Team-Meeting im Stehen, mit den Punkten: Was habe ich gemacht? Woran arbeite ich? Was plane ich zu tun? Welche Probleme habe ich?
  • Tuning Workshops: Regelmäßige Workshops, bei denen das Team seinen Entwicklungsprozess reflektiert und ggf. Änderungen beschließt
  • On-Demand Customer: Weil ein Kunde, der dauerhaft beim Entwicklungsteam sitzt, mit der Zeit auch fachliche Qualifikation verliert, wird als Abschwächung ein zeitweise vor Ort befindlicher, aber stets kurzfristig erreichbarer Kunde vorgeschlagen.
  • Produktmanager: Wenn verschiedene Kundengruppen existieren oder Anwender und Kunde nicht identisch sind, muss die Kundenrolle als Produktmanager mit der expliziten Aufgabe der Aushandlung und Bündelung für die Stakeholder interpretiert werden.
  • Releaseplanung/Etappenplanung: XP sagt ursprünglich wenig zur Planung „im Großen“, muss aber genau darin eingebettet werden.
XP 2.0

Kent Beck überarbeitete sein XP-Buch nach dem ersten Erscheinen noch einmal grundlegend und brachte es im Jahr 2004 neu heraus [7]. Es handelt sich dabei nicht einfach um eine überarbeitete Auflage mit ein paar Korrekturen; die Bezeichnung Extreme Programming 2.0 wird dem Buch eher gerecht. Etliche Techniken sind hinzugekommen, einige alte wurden verändert und umbenannt (z. B. wurde aus „40-Hour Week“ „Sustainable Pace“). XP 2.0 präsentiert sich nachdenklicher, durchdachter, differenzierter als das ursprüngliche XP, aber auch weniger frisch, komplizierter und unübersichtlicher. Darum hat das neue Buch das alte auch nicht ersetzt: beide bleiben in Druck. Man kann sie lesen als „Teil 1: Die Grundidee von Extreme Programming“ und „Teil 2: Weiterführende Überlegungen zu XP“. Aus diesem Grund konzentriere ich mich in diesem Artikel auch auf das „klassische“ XP.

Die Einführung von XP in Projekten und Unternehmen

Die Begeisterung für XP in Teilen der Entwicklergemeinde wurde im Management im Allgemeinen nicht geteilt. Hier wirkte sich nachteilig aus, dass XP sehr entwicklerzentriert formuliert ist. Viele Entscheider entdecken in XP zunächst vor allem Gefahren und Nachteile:

  • „Kein fixiertes Pflichtenheft – Wie sollen wir da wissen, ob wir genug für unser Geld bekommen?“
  • „Pair Programming – Hört sich an, als bekäme das Business in Zukunft für das gleiche Budget nur noch die halbe Leistung.“
  • „Story Cards – Eine Ausrede für Schreibfaule!“
  • „Das viele Testen und Refaktorisieren – Teuer…“

Wenn man XP in ein Projekt einführen will, braucht man aber die Rückendeckung des Managements, schon allein, weil die Zusammenarbeit mit Kunden und Testern stark verändert wird. Ein klassisches Entwicklungsteam kann also sein Vorgehen nicht einfach als „interne Angelegenheit“ behandeln und im Alleingang auf XP umstellen. Entscheider kann man am besten für XP gewinnen, indem man aufzeigt, dass es sich um eine hochdisziplinierte Methode handelt, die eine hohe Transparenz und viele kontinuierliche Steuerungsmöglichkeiten für das Management bietet, und das in einem geeigneten Pilotprojekt auch unter Beweis stellt.

Meine Erfahrung ist, dass in den meisten gelebten Prozessen die Kommunikation und die Rückkopplung zwischen Kunde, Entwicklern und Test die größte Schwachstelle darstellt. Darum ist es empfehlenswert, die Techniken an dieser Schnittstelle (On-Site Customer, Planning Game, Small Releases…) als erste einzuführen und dabei Kunden und Tester auf das grundsätzlich geänderte Verfahren einzustellen und dort „abzuholen“. Die anderen Techniken können dann Schritt für Schritt folgen.

XP und Scrum – zwei Seiten, eine Medaille?

XP hat nach seiner Veröffentlichung große Resonanz sowohl in der Industrie als auch in der Wissenschaft gefunden und ist in beiden Bereichen in zahllosen Büchern, Artikeln und auf Konferenzen untersucht und weiter entwickelt worden. Gleichwohl ist XP in größeren Unternehmen meist nicht beim Management angekommen; die Anerkennung und Rückendeckung, die das Vorgehen bei Chrysler erhalten hatte, blieb ihm später meist versagt. Die Ursachen habe ich in diesem Artikel schon angesprochen. Wegen dieser Schwäche von XP hat sich in den letzten Jahren Scrum immer mehr in den Vordergrund geschoben und wirkt heute wie der dominierende agile Entwicklungsansatz – und in der Tat ist Scrum das Label, unter dem heute viele XP-Techniken ihren Weg in die Projekte finden. Mit etwas gutem Willen kann man Scrum und XP als zwei verschiedene Perspektiven auf denselben Prozess betrachten: XPs Iterationen sind Scrums Sprints, das Planning Game entspricht dem Sprint Planning, XPs Tracking ist Scrums Burndown Chart, Stories und Backlog kennen beide. Scrum betrachte ich darum als die Managementsicht auf XP und XP als die Konkretisierung von Scrum aus Sicht der Entwickler. Auch die Softwarewerkzeuge, die heute agile Entwicklung unterstützen, von XPlanner über VersionOne bis Jira/GreenHopper, passen (natürlich) mit beiden Vorgehensweisen gut zusammen.

Fazit

Extreme Programming stellt die Essenz der Entwicklungsphilosophie von Kent Beck dar, die er mit dem C3-Team bei Chrysler konsequent umsetzen konnte. XP kam vor über zehn Jahren zum rechten Zeitpunkt in die Öffentlichkeit und traf einen Nerv bei Softwareentwicklern, die von der zunehmenden Bürokratisierung der Softwareentwicklung frustriert waren. Das Echo und die Zuwendung aus Wissenschaft und Industrie waren schnell sehr groß. Im Management größerer Unternehmen allerdings hat XP nur wenig Akzeptanz erfahren; erst Scrum, das als eine Managementsicht auf XP verstanden werden kann, hat es ermöglicht, dass beide Ansätze in Kombination einen Platz in den IT-Strategien der Unternehmen gefunden haben. Das ist zu begrüßen, weil es für viele Unternehmen heute lebenswichtig ist, kurzfristig auf Veränderungen reagieren zu können und kurze Time-to-Market-Zeiträume zu realisieren. Während sich XP weiter entwickelt und die Kombination Scrum/XP mehr und mehr zum Mainstream wird, sollten wir bei aller Abgeklärtheit eins nicht vergessen: Den Enthusiasmus, mit dem XP über die IT-Welt kam und uns heute und in Zukunft auffordert: „Turn all the knobs to 10!“

Holger Breitling ist Senior Software-Architekt und Mitglied der Geschäftsleitung der C1 WPS GmbH. Er besitzt langjährige Erfahrung in der Einführung agiler Entwicklungsmethodiken und der Leitung agiler Projekte, insbesondere mit Extreme Programming und Scrum.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.