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. Ein möglichst simpel gestalteter Programmcode erleichtert darüber hinaus das Verständnis und den Austausch im Team.
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. Auch Meldungen des Systems (Logs) werden als Feedback verstanden. Für diese Feedbackkultur ist es wichtig, kleinschrittig zu denken: kurze Iterationen (üblicherweise zwischen einer und vier Wochen) liefern dem Kunden einen Zwischenstand des Produkts.
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. Auch den Mut haben Organisationsstrukturen und Arbeitsweisen zu hinterfragen, sind Teil dieses Werts.
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.
Daneben gibt es bei XP sogenannte Prinzipien, die zwischen den abstrakten Werten und konkreten Praktiken stehen. Sie leiten sich mehr oder weniger von den bereits definierten Werten ab, geben aber spezielle Umsetzungshinweise. So geht es zum Beispiel darum, Feedback unmittelbar zu äußern, Einfachheit anzustreben, Änderungen immer kleinschrittig zu vollziehen, Veränderungen anzunehmen und hochwertige Arbeit zu leisten.
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. Sie haben sich mit der Zeit leicht verändert, können aber grundsätzlich in vier verschiedene Bereiche eingeteilt werden.
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. Das Feedback ist in diesem Fall also systemimmanent.
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. Im Anschluss daran, werden die Aufgaben verteilt. Neue Versionen der Software werden auch als Planning-Poker bezeichnet.
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, sodass es zu einem Wissenstransfer kommt. Obwohl diese Methode relativ kostenintensiv ist, sorgt der entstehende Code für weniger Nacharbeit.
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. Beim nächsten Update können eventuelle Fehler behoben werden.
Gemeinsames Verständnis:
Simple Design: Der Code soll für alle Projektbeteiligten verständlich sein, sodass dieser möglichst einfach gehalten wird. Alles, was den Quelltext unnötig komplex macht, muss daher entfernt werden. Jegliche Duplikation gilt es zu vermeiden. Darüber hinaus sollte aus dem Quelltext das Ziel des Programmierens deutlich werden.
Coding Standards: Damit das gesamte Team zusammenarbeiten kann, werden sogenannte Coding-Standards festgelegt, die sich auf die Herangehensweise und das Format beziehen. Das Ziel: Für alle Teammitglieder soll der Code nachvollziehbar sein.
Collective Code Ownership: Bei XP wird der Code als gemeinsames Produkt verstanden. So tragen nicht bestimmte Mitglieder, sondern das gesamte Team die Verantwortung für die Funktionsfähigkeit des Codes. Zudem wird dadurch vermieden, dass das Wissensmonopol allein bei einer Person liegt.
System Metaphor: Die Technik System Metaphor besteht darin, das Projekt möglichst einfach und in Metaphern (sogenannte User-Storys: eine für beide Seiten begreifbare Alltagsgeschichte) zu beschreiben, um den Quelltext noch verständlicher zu machen. Grund dafür ist, dass häufig ein unterschwelliges Missverständnis zwischen Kunde und Entwicklungsteam besteht, da verschiedene (Fach-) Sprachen gesprochen werden. Auch neue Mitarbeiter können so schneller eingearbeitet werden.
Wohlergehen der Entwickler:
40-Hour-Week: Das Wohlergehen des Teams ist essentiell für ein erfolgreiches Projekt. Nur ausgeruhte und motivierte Mitarbeitende können gute Ergebnisse liefern. XP schreibt deshalb die 40-Stunden-Woche vor (40-Hour-Week). Überstunden sind in jedem Fall zu vermeiden bzw. möglichst rasch auszugleichen.
Wie werden Rollen beim Extreme Programming definiert?
Bei XP werden Aufgaben und Kompetenzen verteilt. Jedes Teammitglied – vom Entwickler bis zum Kunden – hat eine bestimmte Rolle. Angefangen beim sogenannten Produktbesitzer über den Kunden, Entwickler und Projektmanager bis hin zum Benutzer.
Produktbesitzer: Der Produktbesitzer entscheidet über die genaue Vorgehensweise und trägt die Verantwortung für das Projekt. Dies kann zum Beispiel ein Vertreter des Produktmanagements, ein Kunde oder ein Nutzer des Produkts sein.
Kunde: Der Kunde wird nicht als übergeordnete Instanz, sondern als Teil des Teams verstanden. Er stellt zwar Anforderungen an das Produkt, gibt aber nicht vor, auf welchem Weg diese zu erreichen sind. Im besten Fall ist der Kunde immer auf dem aktuellen Stand des Projekts und kann so steuernd darauf einwirken. Damit wird vermieden, dass am Ende ein Produkt entsteht, dass dieser so nicht möchte. Häufig übernehmen Produktmanager oder Mitarbeitende aus dem Marketing-Bereich diese Rolle.
Entwickler: Jeder, der das Produkt aktiv erstellt, gilt als Entwickler. Das betrifft nicht zwangsläufig nur die Programmierer. Die Aufgabe des Entwicklers – neben der eigentlichen Entwicklungsarbeit – ist den Aufwand einzuschätzen, einen Zeitplan zu erstellen sowie die Umsetzung zu planen. Dazu gehört auch, weitere Kapazitäten bei der Geschäftsleitung anzufordern, sofern Hilfe benötigt wird.
(Projekt-)Manager: Der Manager ist die Schnittstelle zwischen Entwicklern und Kunden. So moderiert dieser beispielsweise das Planning Game und achtet darauf, dass eine konstruktive Diskussion entsteht. Sofern es Probleme im Team geben sollte, übernimmt der Manager auch die Aufgabe eines Mediators. Gelegentlich wird er auch als Tracker bezeichnet, da es zu seiner Rolle gehört, wichtige Kennzahlen, wie zum Beispiel den Zeitaufwand, zu notieren.
Coach: Das gesamte Team sollte mit XP umgehen und die Methode konsequent umsetzen können. Um dies zu gewährleisten, kann ein Coach helfen. In die eigentliche Produktentwicklung ist er nicht involviert, sondern steht nur beratend zur Seite. Häufig handelt es sich dabei um externe Dienstleister.
Benutzer: Der Benutzer ist der Nutzer des zu erstellenden Produktes.
