Extreme Programming (XP)

Was ist Extreme Programming (XP)?

Wie der Name bereits andeutet, gilt Extreme Programming (XP) als die radikalste Umsetzung der agilen Softwareentwicklung. Als Reaktion auf das sogenannte Wasserfallmodell, entschieden die Entwickler Kent Beck, Ward Cunningham und Ron Jeffries einen neuen Weg zu gehen, der sich von der klassischen Arbeitsweise abhob. Allesamt sind ebenfalls Erstunterzeichner des Agile Manifesto, das Anfang der 2000er Jahre formuliert wurde.

Charakteristisch für Extreme Programming ist, dass der Entwicklungsprozess immer wieder in kurzen Zyklen sämtliche Disziplinen der klassischen Softwareentwicklung durchläuft (Anforderungsanalyse, Design, Implementierung und Test). Dadurch ist die Methode insgesamt leichtgewichtiger.

Was sind die Grundlagen für Extreme Programming?

Extreme Programming ist generell auf die Anforderungen des Kunden ausgerichtet. Das klingt erst einmal nicht neu, doch die klassische Softwareentwicklung kann nur begrenzt auf sich ständig ändernde Kundenwünsche eingehen.

XP setzt demnach voraus, dass die Anforderungen an die Software zu Projektbeginn noch nicht klar definiert sind, das heißt: sich im Laufe der Zusammenarbeit regelmäßig ändern. Wie andere agile Methoden auch, wird die Software deshalb in kurzen Zyklen (iterativen Prozessen) immer wieder geprüft und besprochen, um Fehler schnell beseitigen zu können. Am Ende erhält der Kunde ein funktionsfähiges Produkt, an dessen Entwicklung er aktiv teilgenommen hat.

Extreme Programming basiert auf verschiedenen Werten, Prinzipien und Techniken, um den verschiedenen Anforderungen der Softwareentwicklung zu begegnen. Dabei sind fünf Werte von zentraler Bedeutung: Kommunikation, Einfachheit, Rückmeldung, Mut und Respekt.

Kommunikation: Teamarbeit sowie eine regelmäßige, offene und respektvolle Kommunikation sind eine wichtige Säule bei XP. Die Methode erfordert demnach eine hohe Kommunikationsbereitschaft von allen Projektbeteiligten.

Einfachheit: Grundsätzlich strebt XP nach der einfachsten Lösung, das heißt: es werden nur die im Moment benötigten Features entwickelt. Eventuelle Anforderung, die sich zukünftig ergeben könnten, werden vorerst ausgeblendet. So wird die Softwareentwicklung beschleunigt und das Resultat ist ein schlankes Produkt, das einfach zu handhaben ist.

Rückmeldung: Essentiell beim Extreme Programming ist, dass der Kunde regelmäßig Feedback gibt. Kritik ist zu jedem Zeitpunkt erwünscht, denn nur daraus resultiert ein zufriedenstellendes Produkt.

Mut: Unter Mut versteht Extreme Programming die Bereitschaft Probleme anzusprechen, das heißt: Fehler im Produkt müssen benannt werden. Dazu gehört ggf. auch, das jedes Teammitglied die Verantwortung für seine Fehler übernimmt.

Respekt: Für eine gute Teamarbeit ist gegenseitiger Respekt notwendig. Diese Wertschätzung reicht sogar bis zum Kunden, der die Mitarbeitenden mit den nötigen Kompetenzen und Ressourcen ausstatten soll.

Mit welchen Techniken wird Extreme Programming umgesetzt?

Während die vorgestellten Werte und Prinzipien auch in anderen agilen Methoden angewendet werden, gibt es ganz konkrete Handlungsanweisungen und Arbeitsmethoden, die XP charakterisieren.

Feinstufiges Feedback

Test-Driven-Development: Beim Test-Driven-Development (TTD) schreiben die Entwickler eine Testumgebung, bevor der Quellcode erstellt wird. Ein Code, der diesen Test nicht besteht, kann nicht weitergeführt werden. Erfahren Sie hier mehr zum Test-Driven-Development.

Planning Game: Das sogenannte Planning-Game ist ein Meeting, das zu Beginn jeder Entwicklungsphase stattfindet. Team und Kunde kommen dabei zusammen, um den aktuellen Arbeitsstand und zukünftige Funktionen zu besprechen.

On-Site-Customer: Bestenfalls sollte mindestens ein Repräsentant des Kunden fester Bestandteil des Teams sein, um als Schnittstelle zu fungieren und schnell auf eventuelle Probleme reagieren zu können.

Pair-Programming: Das Pair-Programming basiert auf dem Vier-Augen-Prinzip, das heißt: zwei Personen arbeiten immer gleichzeitig am Code. Einer schreibt den Code (Driver), der andere überprüft den Quelltext und weist ggf. auf Fehler hin (Partner). Die Rollen werden regelmäßig getauscht.

Kontinuierlicher Prozess

Refactoring: XP-Teams überarbeiten ihren Code ständig. Dieses sogenannte Refactoring soll dafür sorgen den Quelltext stetig zu verbessern und ihn weniger fehleranfällig zu machen.

Continuous Integration: In kurzen Zeitabständen wird der Code durch einen Entwickler in das Gesamtprojekt integriert. Die einzelnen Beiträge können so durchgehend auf Fehler überprüft werden.

Small Releases: Funktionsfähige Programme werden so früh wie möglich veröffentlicht. Durch diese Small Releases wird die Feedbackfrequenz erhöht.

Gemeinsames Verständnis

Simple Design: Der Code soll für alle Projektbeteiligten verständlich sein, sodass dieser möglichst einfach gehalten wird.

Coding Standards: Damit das gesamte Team zusammenarbeiten kann, werden sogenannte Coding-Standards festgelegt, die sich auf die Herangehensweise und das Format beziehen.

System Metaphor: Die Technik System Metaphor besteht darin, das Projekt möglichst einfach und in Metaphern zu beschreiben, um den Quelltext noch verständlicher zu machen.

Wohlergehen der Entwickler

40-Hour-Week: Das Wohlergehen des Teams ist essentiell für ein erfolgreiches Projekt. XP schreibt deshalb die 40-Stunden-Woche vor. Überstunden sind in jedem Fall zu vermeiden.

Welche Vorteile hat Extreme Programming?

• Refactoring: Der Code wird ständig überarbeitet, um ihn weniger fehleranfällig zu machen.
• Ein möglichst simpel gestalteter Programmcode erleichtert das Verständnis und den Austausch im Team.
• Gute Work-Life-Balance: XP schreibt die 40-Stunden-Woche vor.
• Funktionsfähige Software wird so früh wie möglich veröffentlicht.
• Feedbackkultur: Kunde ist Teil des Teams und wird zu jedem Zeitpunkt in das Projekt integriert.

Wo setzen wir Extreme Programming ein?

XP-Techniken prägen unsere Arbeit in Projekten wie Formfix und Plantronic, wo Pair-Programming, Continuous Integration und Test-Driven Development feste Bestandteile des Entwicklungsprozesses sind. Auch in unseren Cloud-Projekten nutzen wir XP-Prinzipien wie Small Releases und Refactoring, um Infrastructure-as-Code iterativ und zuverlässig weiterzuentwickeln.