Extreme Programming: Softwareentwicklung extrem gedacht

Es gibt mittlerweile die verschiedensten Auswüchse von agiler Softwareentwicklung. Neben Scrum und Kanban wird auch immer wieder Extreme Programming besprochen und angewendet. Was ist an dieser Entwicklungsart so extrem?

Extreme Programming (XP) gilt – und das ist das namensgebende Extrem – als die radikalste Umsetzung der agilen Softwareentwicklung. Soll heißen: Agiler als XP ist vermutlich keine andere Methode, schon gar nicht traditionelle Programmierweisen. Extreme Programming grenzt sich daher beispielsweise auch konkret vom Wasserfallmodell ab, das laut den Erfindern von XP zahlreiche Probleme mit sich bringt. Mitte der 1990er-Jahre haben sich die Entwickler Kent Beck, Ward Cunningham und Ron Jeffries entschieden, die klassische Arbeitsweise umzukrempeln und einen neuen Weg zu gehen.

Grundsätzlich ist Extreme Programming auf die Anforderungen des Kunden ausgerichtet. Das klingt zunächst selbstverständlich, doch klassische Softwareentwicklung kann nur in einem begrenzten Maße auf Kundenwünsche eingehen – schwierig wird es besonders dann, wenn sich diese Wünsche regelmäßig ändern. XP versucht zudem die Kreativität von Entwicklern zu fördern und akzeptiert Fehler als einen selbstverständlichen Faktor bei der Arbeit.

Gleichzeitig geht XP – wie andere agile Methoden auch – von iterativen Prozessen aus. Ein großes Projekt von Anfang bis Ende durchzuziehen und mehrere Monate zu investieren, nur um am Ende festzustellen, dass das Ergebnis nicht passt – damit bricht XP. Stattdessen wird in kurzen Zyklen ständig geprüft, besprochen und veröffentlicht. So können Fehler schnell festgestellt und beseitigt werden.

Um den Anforderungen zu begegnen, hat man ein recht deutliches Framework entwickelt. Es geht von verschiedenen Werten, Prinzipien und Techniken aus. Darüber hinaus werden konkrete Rollen vergeben, damit Aufgaben klar zugeteilt werden können.

Mit fünf Werten versucht XP die grundsätzliche Einstellung bei der Programmierarbeit zu verändern. Das Team soll als Ganzes eine bestimmte Mentalität verfolgen, um so bestmöglich miteinander arbeiten zu können und ein erstklassiges Produkt zu erstellen.

Kommunikation ist bei XP sowohl zwischen den Teammitgliedern als auch zwischen Entwicklern und Kunden wichtig. Ein permanenter Austausch soll dafür sorgen, dass Probleme direkt adressiert werden können. Nur wenn alle Beteiligten jederzeit miteinander im Gespräch sind, können Missstände kurzfristig aufgedeckt werden. Kommunikation sorgt außerdem dafür, dass alle mit dem gleichen Wissensstand arbeiten und sich dem Projekt verpflichtet fühlen. Ein richtiges Gespräch vor Ort wird dabei dem Austausch von schriftlichen Nachrichten vorgezogen.

Bei XP strebt man immer nach der einfachsten Lösung. Das bringt gleich mehrere Vorteile mit sich: Wenn man sich nur auf die notwendigen Faktoren konzentriert, hält man sich nicht mit Unwichtigem auf. Dazu gehört auch, nur die im Moment benötigten Features zu entwickeln und nicht bereits für eventuelle, zukünftige Anforderungen vorzuarbeiten. So beschleunigt das Team die Entwicklung. Ein schlankes Produkt ist zudem sehr viel einfacher zu handhaben – sowohl bei der Weiterentwicklung als auch bei der Wartungsarbeit. Zusätzlich erleichtert ein möglichst simpler Programmcode das Verständnis, was auch im Sinne des Werts Kommunikation ist: Wenn das komplette Team den Quelltext verstehen kann, fällt es leichter, sich darüber auszutauschen.

Auch dieser Wert ist eng verbunden mit der hohen Wertschätzung direkter Kommunikation. Der Kunde soll möglichst oft seine Kritik äußern können. Beim Extreme Programming werden allerdings auch Meldungen des Systems (Logs) als Feedback behandelt. Damit man eine Feedbackkultur im Sinne von XP realisieren kann, ist es wichtig, kleinschrittig zu denken: Das Team arbeitet in kurzen Zyklen, testet den Code immer wieder und stellt die Weiterentwicklung auch dem Kunden in kurzen Abschnitten vor. So lassen sich Änderungen und Fehlerbehebungen kurzfristig vornehmen.

Extreme Programming versteht unter Mut die Bereitschaft, die Wahrheit zu sagen – selbst wenn diese eher unangenehm ist. Gibt es Fehler im Produkt, müssen sie benannt werden, auch wenn man selbst dafür verantwortlich ist. In einem Team, das nach XP-Werten arbeitet, spielen auch Entschuldigungen keine Rolle. Kein Teammitglied sollte versuchen, seine Beteiligung an einem Fehler kleinzureden, da dies nicht zielfördernd ist. Überdies versteht man unter dem Wert in diesem Kontext auch, den Mut zu haben, Organisationsstrukturen zu ändern, eigene Arbeitsweisen zu hinterfragen, Kritik anzunehmen und Code u. U. auch komplett neu zu schreiben.

Damit das Team untereinander harmoniert und ausgezeichnete Leistungen vollbringen kann, ist gegenseitiger Respekt notwendig. Dies schlägt sich auch darin nieder, dass ein Entwickler nicht durch Änderungen die Arbeit eines anderen sabotiert. Auch über das Team hinaus bis zum Kunden ist die Wertschätzung wichtig. Nur wenn man die Belange des anderen ernst nimmt, kann man auch angemessen darauf reagieren. Schließlich soll auch die Geschäftsleitung dem Entwicklungsteam Respekt entgegenbringen und die Mitarbeiter mit den benötigten Kompetenzen und Ressourcen ausstatten.

Beim Extreme Programming stehen die Prinzipien zwischen den Werten und Praktiken, sie verbinden damit das Abstrakte mit dem Konkreten. Die Prinzipien leiten sich mehr oder weniger aus den zuvor definierten Werten ab.

Feedback soll so frühzeitig wie möglich eingeholt und dann gleichfalls möglichst schnell umgesetzt werden. Dabei sollen Rückmeldungen durch das System selbst (beim Testen des Codes) binnen von Sekunden oder Minuten umgesetzt werden – statt das Feedback beispielsweise zunächst zu sammeln. Feedback der Kunden soll man hingegen innerhalb von Tagen oder Wochen einholen und berücksichtigen.

Das Prinzip der Einfachheit entspricht in der Grundlage dem gleichnamigen Wert, erhält aber konkretere Umsetzungshinweise. Dafür wendet man zwei Methoden an:

• You ain’t gonna need it (YAGNI): Solange eine Funktionalität nicht konkret verlangt wird, sollte sie auch nicht implementiert werden, um keine unnötige Arbeit durchzuführen.
• Don’t repeat yourself (DRY): Man soll doppelte Arbeit vermeiden und auch den Code so gestalten, dass eine Änderung nicht an mehreren Stellen vorgenommen werden muss, sondern immer nur einmal.

Beim Extreme Programming werden Änderungen immer kleinschrittig vollzogen. Statt große Updates zur Eliminierung mehrerer Fehlerquellen auf einmal auszuspielen, wird nur ein Problem nach dem anderen angegangen. Das sorgt dafür, dass das Team schneller reagiert und man die Änderungen besser nachvollziehen kann. Das Prinzip bezieht sich allerdings nicht nur auf den Programmcode. Auch Änderungen im Design oder gar in der Teamstruktur selbst sollen in kleinen, inkrementellen Schritten vonstattengehen.

Da Extreme Programming den Kunden ins Zentrum stellt, werden dessen Änderungswünsche auch hoch bewertet. Deshalb muss das komplette Team solchen Änderungen positiv entgegensehen, statt sich ihnen in den Weg zu stellen. Man soll den Kunden also sogar eher dazu anregen, Änderungswüsche zu äußern, statt ihm solche auszureden.

Klingt banal, ist aber – weitergedacht – sehr wichtig für das Funktionieren von Extreme Programming: Das Team soll hochwertige Arbeit leisten. Was hochwertig ist, entscheidet der Kunde. Um Qualitätsarbeit zu ermöglichen, ist allerdings das Management gefragt. Wenn die Faktoren stimmen, das Team also zufrieden mit der geleisteten Arbeit sein kann, wirkt sich das wiederum positiv auf die Moral aus.

XP-Praktiken sind ganz konkrete Handlungsanweisungen und Arbeitsmethoden. Während die vorgestellten Werte und Prinzipien auch in anderen agilen Arbeitsmethoden Anwendung finden, sind die konkreten Techniken des Extreme Programming Alleinstellungsmerkmale. Auch sie haben sich über die Zeit leicht verändert und sind von Quelle zu Quelle verschieden. Generell werden die Techniken in vier verschiedene Bereiche eingeteilt.

Entwicklerteams arbeiten bei Extreme Programming in äußerst kurzen Zyklen. Dies erlaubt es, den geschriebenen Code immer wieder zu testen. Das Test-Driven Development geht so weit, dass Entwickler eine Testumgebung schreiben, bevor der eigentliche Quellcode erstellt wird. Code, der diesen Test nicht besteht, kann nicht weitergeführt werden. An dieser Stelle kommt das Feedback also aus dem System selbst heraus.

Das sogenannte Planning Game ist ein Meeting, das zu Beginn jeder Entwicklungsphase stattfindet. Das Team und der Kunde finden sich zusammen, um die bisherige Arbeit zu besprechen, Feedback zu geben und künftige Funktionen zu diskutieren. Daraufhin werden Aufgaben vergeben.

Auch die Idee eines On-Site Customers sorgt für regelmäßige Feedbacks. Im besten Fall soll wenigstens ein Repräsentant des Kunden fester Teil des Teams sein, um schnell auf Fragen antworten oder Ideen und Prioritäten einbringen zu können.

Das Pair Programming schließlich sorgt für ein Vier-Augen-Prinzip: Zwei Personen arbeiten immer gleichzeitig am Code. Während ein Kollege den Code schreibt, überprüft der andere den Quelltext, gibt Verbesserungsvorschläge und weist auf Fehler hin. Zwar ist diese Methode sehr kostenintensiv, da gleich zwei Mitarbeiter für eine Aufgabe eingesetzt werden müssen, doch der entstehende Code ist ultimativ besser und sorgt für weniger Nacharbeit.

XP-Teams überarbeiten ihren Code ständig. Dieses Refactoring soll dafür sorgen, den Quelltext zu verbessern sowie Wiederholungen und unnötige Bestandteile zu entfernen. Ein solch optimierter Code ist verständlicher, auch für externe Leser, und zudem weniger fehleranfällig.

Mit Continuous Integration sorgen Teams beim Extreme Programming und anderen agilen Arbeitsweisen für ständige Integration von neuem Code in das Gesamtprojekt. Mehrmals täglich schiebt ein Entwickler seine Arbeit in das Projekt. So werden die einzelnen Beiträge durchgängig überprüft und alle Beteiligten arbeiten mit einem aktuellen Stand.

Funktionierende Programme und Updates werden im Sinne von XP so früh wie möglich veröffentlicht. Small Releases erhöhen auch die Frequenz von Feedbacks. Fehler kann man so schneller feststellen und schon mit dem nächsten Update wieder ausmerzen. Der Kunde hat fortwährend die Gelegenheit, den neuesten Stand der Entwicklung direkt auszuprobieren und Kritik und Vorschläge anzubringen.

Mit einer einfachen Gestaltung (Simple Design) ist der Code für alle Beteiligten verständlich. Alles, was den Quelltext daher unnötig komplex macht, muss entfernt werden. Für Entwickler, die nach Extreme Programming arbeiten, gilt es, jegliche Duplikationen zu vermeiden. Außerdem sollte aus dem Quelltext heraus klarwerden, was das Ziel des jeweiligen Programmierers ist.

Damit das komplette Team Hand in Hand arbeiten kann, werden grundsätzlich Coding-Standards festgelegt. Diese Vorgaben beziehen sich auf die Herangehensweise und auf das Format. Kollegen sollen sich auch im Code der anderen zurechtfinden können, und gleichzeitig soll immer nachvollziehbar sein, wer welche Änderungen vorgenommen hat.

Die Möglichkeit, gemeinsam am Code zu arbeiten, stärkt die Collective Code Ownership: Statt darauf hinzuweisen, wer welchen Anteil – und damit auch enthaltene Fehler – zu verantworten hat, begreift man den Code als gemeinsames Produkt. Das komplette Team trägt damit die Verantwortung, sowohl für Fehler als auch für Erfolge. Diese Technik lädt zudem dazu ein, an Code von anderen weiterzuarbeiten und Ideen einzubringen.

Um das Verständnis in Bezug auf den Quelltext noch weiter zu steigern, verwendet man bei Extreme Programming die Technik System Metaphor. Diese Praktik besteht darin, das Projekt möglichst einfach – auch unter der Verwendung von Metaphern – zu beschreiben. Das bezieht sich auch auf Konventionen bei der Benennung von Objekten, Klassen oder Funktionen im Code, die möglichst selbsterklärend sein müssen. Neue Mitarbeiter, die zum Projekt hinzustoßen, sollen dieses dadurch schnell verstehen können. Auch Nicht-Programmierer bekommen so einen Einblick in den Quelltext.

Das Wohlergehen des Teams ist wichtig für den Erfolg des Projekts: Nur Mitarbeiter, die ausgeruht und motiviert sind, können auch hochwertige Ergebnisse liefern. Um dies zu garantierten, schreibt Extreme Programming die 40-Stunden-Woche (40-Hour Week) vor. Überstunden sind um jeden Preis zu vermeiden und nur dann erlaubt, wenn in der Woche darauf keine weiteren aufgebaut werden.

Rollen dienen beim Extreme Programming dazu, Aufgaben und Kompetenzen an alle Beteiligten – sowohl die Entwickler als auch die Kunden – zu verteilen.

Extreme Programming agiert sehr kundenorientiert, was so weit geht, dass der Kunde als Teil des Teams wahrgenommen wird und zumindest ein Vertreter sich auch immer vor Ort befindet (On-Site Customer). Der Kunde stellt die Anforderungen an das Produkt, gibt allerdings nur bedingt vor, wie die Ziele zu erreichen sind. Einzig die Priorisierung der Teilbereiche fällt in seinen Kompetenzbereich. Dazu gehört allerdings auch, die eigenen Wünsche verständlich zu machen.

Die Rolle des Kunden kann durch eine Person oder durch ein Team verschiedener Vertreter des Kunden ausgefüllt werden. In der Praxis nehmen oftmals Produkt-Manager oder auch Mitarbeiter aus dem Marketing-Bereich (immer passend zum Ziel des Projekts) die Aufgaben wahr.

Das Entwicklerteam wird nicht weiter unterteilt. Das heißt: Jeder, der aktiv das Produkt erstellt, fällt unter die Rolle Entwickler. Daher gehören mitunter nicht nur Programmierer dazu, sondern auch andere an der Erstellung beteiligte Personen – ganz nach den Ansprüchen des Projekts. Neben der eigentlichen Entwicklungsarbeit ist es auch Aufgabe der Entwickler, auf die Wünsche des Kunden zu reagieren: Aufwand einschätzen, Zeitplan aufstellen, Umsetzung planen.

Zu den Rechten der Entwickler zählt, sich benötigte Hilfe zu suchen, also z. B. weitere Kapazitäten bei der Geschäftsleitung anzufordern. Außerdem gilt laut den Techniken von XP für Entwickler die 40-Stunden-Woche. Es ist im Sinne des Projekts, dass Entwickler nicht überarbeitet sind. Dafür legt das Entwicklerteam seinen Zeitplan selbst fest.

Die Rolle des Managers stellt das Bindeglied zwischen Entwicklern und Kunden dar. Personen dieser Gruppe bringen die beiden anderen an einen Tisch und moderieren beispielsweise auch das Planning Game. Dabei achtet der Manager darauf, dass vorher festgelegte Regeln sowie allgemeine Konventionen einer konstruktiven Diskussion eingehalten werden. Der Manager übernimmt auch die Aufgabe eines Mediators, sollte dies nötig sein.

Die Rolle wird manchmal auch als Tracker bezeichnet. Grund dafür ist, dass es zu den Aufgaben des Managers gehört, wichtige Kennzahlen (z. B. die Zeit, die jeder Mitarbeiter für das Projekt aufwendet) zu notieren.

Das komplette Team (inklusive Kunde) muss mit Extreme Programming umgehen können und diese Arbeitsmethode konsequent umsetzen. Damit alle die gleichen Vorstellungen von den Vorgängen haben, kann ein Coach helfen. Dieser hat mit der eigentlichen Produktentwicklung nichts zu tun, sondern steht nur als externer Helfer zur Seite – ganz ähnlich einem Scrum Master. In Vorgesprächen können mit dieser Person die Regeln und Praktiken durchgegangen werden. Der Coach begleitet das Team im besten Fall über die komplette Entwicklungsstrecke, steht für Fragen zur Verfügung und hilft bei Unklarheiten.

Oftmals setzt man hierfür einen externen Dienstleister ein. Es ist aber auch möglich, dass der Coach aus dem Unternehmen kommt, dann allerdings aus einem anderen Bereich. Doppelrollen (ein Entwickler übernimmt zusätzlich die Rolle des Coaches) sollten vermieden werden.

Extreme Programming hat wichtige Impulse für die Art der Softwareentwicklung gesetzt, ist aber nicht in allen Szenarien und für alle Teams geeignet. XP geht davon aus, dass der Kunde zu Beginn des Projekts selbst noch keine genaue Vorstellung vom fertigen Produkt hat. In einem solchen Fall kann die Software agil, also nach und nach geplant und entwickelt werden.

Auf diese Weise wird zum einen der Kunde zufriedengestellt: Man sucht gemeinsam mit ihm nach der passenden Lösung und er ist in jeden Schritt involviert. Zum anderen können die Entwickler Projekte so umsetzen, wie sie es für angemessen halten, statt ständig Kompromisse eingehen zu müssen. Kommt der Kunde allerdings mit einer fertigen Produktbeschreibung und einer Liste von Funktionen auf das Entwicklerteam zu, lässt sich XP nur noch sehr schwer einsetzen.

Gerade das Pair Programming kann kleine Teams vor Probleme stellen, da die dafür benötigten Kapazitäten nicht verfügbar sind. Auch die regelmäßigen Meetings mit den Kunden kosten Zeit, die wiederum nicht in die eigentliche Programmierarbeit fließen kann. In einer idealen Situation spielt das keine Rolle: Das Ergebnis wird eindeutig ein besseres sein, wenn sich das Team die benötigte Zeit und die gewünschten Ressourcen nehmen kann.

Doch in der Praxis werden Entwickler sowohl durch ein begrenztes Budget als auch durch klare Deadlines unter Druck gesetzt. Zudem können dem Kunden das Interesse oder die Möglichkeiten fehlen, sich in dem Maße in das Projekt einzubringen, wie XP es verlangt.

Sind die Gegebenheiten aber so, dass sie ein Vorgehen im Sinne von Extreme Programming erlauben, kann ein Team mit dieser Methode ein ausgezeichnetes Ergebnis liefern. Durch die ständigen Tests entstehen stabile Systeme, und das iterative Vorgehen sorgt in Kombination mit dem minimalistischen Ansatz dafür, dass auch wirklich nur Funktionen erstellt werden, die für das Projekt wichtig sind.