Extreme Programming (XP) ist eine agile Softwareentwicklungsmethodik. Wie andere agile Methoden hat XP seine einzigartigen Werkzeuge, Prozesse und Rollen. Der Schöpfer von XP, der amerikanische Entwickler Kent Beck, hat nichts völlig Neues erfunden, sondern die besten Praktiken der agilen Entwicklung aufgegriffen und bis zum Extrem verstärkt, daher der Name Extreme Programming.
Der Autor der Methodik, Kent Beck, leitete Ende der 90er Jahre das Chrysler Comprehensive Compensation System-Projekt, in dem er erstmals XP-Praktiken anwandte. Er dokumentierte seine Erfahrungen und das entstandene Konzept in dem Buch “Extreme Programming Explained”, das 1999 veröffentlicht wurde. Auf dieses Buch folgten weitere, die XP-Praktiken detailliert beschreiben. Zu den Mitentwicklern der Methodik gehören Ward Cunningham, Martin Fowler und andere.
Im Gegensatz zu anderen agilen Methoden wird XP exklusiv in der Softwareentwicklung verwendet. Es kann nicht auf andere Geschäftsfelder oder das tägliche Leben wie Scrum, Kanban oder Lean angewendet werden.
Das Ziel von XP ist es, mit ständig wechselnden Anforderungen an das Softwareprodukt umzugehen und die Entwicklungsqualität zu verbessern. Daher ist XP für komplexe und unsichere Projekte geeignet.
XP dreht sich um vier Kernaktivitäten: Codieren, Testen, Entwerfen und Zuhören. Darüber hinaus hat Extreme Programming grundlegende Werte: Einfachheit, Kommunikation, Feedback, Mut und Respekt.
13 Praktiken des Extreme Programming
1. Das gesamte Team
Alle Projektteilnehmer, die XP verwenden, arbeiten als ein einziges Team. Dieses Team muss einen Kundenvertreter umfassen, vorzugsweise einen echten Endbenutzer, der über die Geschäftswelt informiert ist. Der Kunde legt die Produktanforderungen fest und priorisiert die Funktionalitäten. Business-Analysten können den Kunden unterstützen. Von der Seite der Ausführenden umfasst das Team Entwickler, Tester, manchmal einen Coach, der das Team anleitet, und einen Manager, der Ressourcen bereitstellt.
2. Planungsspiel
Die Planung in XP erfolgt in zwei Phasen: Release-Planung und Iterationsplanung.
- Release-Planung: Das Programmier-Team trifft sich mit dem Kunden, um die gewünschte Funktionalität für das nächste Release zu bestimmen, typischerweise in 2 – 6 Monaten. Da die Anforderungen des Kunden oft vage sind, klären die Entwickler diese und brechen sie in Aufgaben herunter, die in einem Tag oder weniger abgeschlossen werden können. Der Kunde muss das betriebliche Umfeld verstehen, in dem das Produkt arbeiten wird.
Die Aufgaben werden auf Karten festgehalten, und der Kunde priorisiert sie. Die Entwickler schätzen dann die Zeit, die für jede Aufgabe benötigt wird. Sobald die Aufgaben beschrieben und geschätzt sind, überprüft der Kunde die Dokumentation und genehmigt den Beginn der Arbeiten. Für den Projekterfolg ist es entscheidend, dass der Kunde und das Programmier-Team auf demselben Spielfeld spielen: der Kunde wählt tatsächlich notwendige Funktionalitäten innerhalb des Budgets aus, und die Programmierer richten die Anforderungen des Kunden angemessen auf ihre Möglichkeiten aus. - Iterationsplanung: Findet alle zwei Wochen statt, manchmal häufiger oder seltener. Der Kunde ist anwesend, um die Funktionalität für die nächste Iteration zu definieren und Änderungen an den Produktanforderungen vorzunehmen.
3. Kleine Releases
XP-Releases sind häufig, aber mit begrenzter Funktionalität. Dieser Ansatz erleichtert das Testen und die Wartung der Betriebssicherheit des Systems und stellt dem Kunden in jeder Iteration eine funktionale Geschäftswert-Funktionalität zur Verfügung.
Kundentests
Der Kunde legt automatisierte Abnahmetests fest, um die Funktionalität des Produkts zu überprüfen. Das Team schreibt diese Tests und nutzt sie, um den Code zu testen.
Gemeinsame Code-Eigentümerschaft
In XP kann jeder Entwickler jeden Teil des Codes ändern, da der Code nicht dem Autoren gehört, sondern dem gesamten Team.
Kontinuierliche Integration
Neue Code-Teile werden sofort in das System integriert – XP-Teams veröffentlichen alle paar Stunden oder häufiger einen neuen Build. Diese Praxis stellt sicher, dass die Auswirkungen der kürzlich vorgenommenen Änderungen am System sofort sichtbar sind. Wenn ein neuer Code-Teil etwas kaputt macht, ist die Identifizierung und Behebung des Fehlers viel einfacher.
Codierungsstandards
Mit der gemeinsamen Code-Eigentümerschaft ist es entscheidend, gemeinsame Codierungsstandards zu verabschieden, um sicherzustellen, dass der Code aussieht, als wäre er von einem einzigen Fachmann geschrieben worden. Teams können eigene Standards entwickeln oder bestehende annehmen.
Systemmetapher
Die Systemmetapher ist ein Vergleich mit etwas Vertrautem, um eine gemeinsame Vision innerhalb des Teams zu schaffen. Typischerweise erfindet die Person, die die Architektur entwickelt und das System als Ganzes sieht, die Metapher.
Nachhaltiges Tempo
XP-Teams arbeiten mit maximaler Produktivität, während sie ein nachhaltiges Tempo beibehalten. Extreme Programming ermutigt nicht zu Überstunden und fördert eine 40-Stunden-Arbeitswoche.
Testgetriebene Entwicklung (TDD)
Einer der herausforderndsten Praktiken in XP. Programmierer schreiben Tests, bevor sie den zu testenden Code schreiben. Dieser Ansatz stellt sicher, dass jedes Funktionselement vollständig durch Tests abgedeckt ist. Wenn Entwickler Code einpflegen, werden sofort Unit-Tests ausgeführt, und alle Tests müssen bestehen, um sicherzustellen, dass das Team in die richtige Richtung arbeitet.
Pair Programming
Stellen Sie sich zwei Entwickler vor, die an einem Computer an einem einzigen Funktionselement arbeiten. Diese Praxis ist Pair Programming, die umstrittenste Praxis in XP. Das Sprichwort “Zwei Köpfe sind besser als einer” veranschaulicht ihren Kern gut. Von zwei Lösungen eines Problems wird die beste gewählt, der Code wird sofort optimiert und Fehler werden vermieden, bevor sie auftreten, was zu sauberem Code führt, der von beiden Entwicklern verstanden wird.
Einfache Gestaltung
Einfache Gestaltung in XP bedeutet, nur das zu tun, was jetzt benötigt wird, ohne zu versuchen, zukünftige Funktionalitäten vorherzusagen. Einfache Gestaltung und ständige Refaktorisierung erzeugen einen synergistischen Effekt – wenn der Code einfach ist, lässt er sich leichter optimieren.
Refaktorisierung
Refaktorisierung ist der fortlaufende Prozess der Verbesserung des Systemdesigns, um neuen Anforderungen gerecht zu werden. Dazu gehört das Entfernen von Code-Duplikationen, das Erhöhen der Kohäsion und das Reduzieren von Kopplungen. XP erfordert ständige Refaktorisierung, damit das Code-Design immer einfach bleibt.
Vorteile und Nachteile von XP
XP ist umstritten und wird oft von denen kritisiert, die es nicht erfolgreich implementieren konnten. Die Vorteile sind jedoch offensichtlich, wenn das Team mindestens eine XP-Praktik voll ausnutzt.
Zu den Vorteilen des Strebens nach XP gehören:
- Kundenzufriedenheit: Kunden erhalten das Produkt, das sie benötigen, auch wenn sie anfangs keine klare Vision haben.
- Flexibilität: Das Team nimmt schnell Codeänderungen vor und fügt neue Funktionalitäten hinzu, dank einfacher Codegestaltung, häufiger Planung und Releases.
- Zuverlässigkeit: Der Code funktioniert immer aufgrund ständiger Tests und kontinuierlicher Integration.
- Wartbarkeit: Das Team kann den Code problemlos warten, da er nach einem einheitlichen Standard geschrieben und ständig refaktoriert wird.
- Produktivität: Schnelles Entwicklungstempo durch Pair Programming, keine Überstunden und Kundenbeteiligung.
- Hochwertiger Code
- Risikominderung: Entwicklung Risiken werden verringert, da die Verantwortung gleichmäßig verteilt ist und das Projekt nicht durch das Verlassen oder den Eintritt von Teammitgliedern gefährdet wird.
- Kosteneffizienz: Die Entwicklungskosten sind niedriger, da sich das Team auf Code anstelle von Dokumentation und Meetings konzentriert.
Trotz seiner Vorteile funktioniert XP nicht immer und hat mehrere Schwächen:
- Kundenbeteiligung: Der Erfolg hängt von der Kundenbeteiligung ab, was schwierig zu erreichen sein kann.
- Unvorhersehbare Zeitpläne: Es ist schwierig, die zeitlichen Kosten eines Projekts vorherzusagen, da die vollständige Liste der Anforderungen zu Beginn unbekannt ist.
- Abhängigkeit vom Fähigkeitsniveau: XP hängt stark vom Fähigkeitsniveau der Programmierer ab und funktioniert am besten mit erfahrenen Fachleuten.
- Widerstand des Managements: Das Management widerspricht oft Pair Programming und hinterfragt die Notwendigkeit, zwei Programmierer anstelle von einem zu bezahlen.
- Kosten: Häufige Meetings mit Programmierern können für Kunden teuer sein.
- Kulturelle Veränderungen: Die Implementierung von XP erfordert erhebliche kulturelle Veränderungen.
- Fehlende Struktur: Die fehlende Struktur und Dokumentation bei XP macht es ungeeignet für große Projekte.
- Nicht-funktionale Anforderungen: Funktionale Anforderungen sind schwierig als Benutzerstory in agilen Methoden zu beschreiben.
Prinzipien von XP
In seinem ersten Buch skizzierte Kent Beck die folgenden Prinzipien von XP: Einfachheit, Kommunikation, Feedback und Mut. In einer späteren Ausgabe fügte er ein fünftes Prinzip hinzu – Respekt.1. Einfachheit
Die Entwicklung in XP beginnt mit der einfachsten Lösung, die den aktuellen funktionalen Bedarf deckt. Die Teammitglieder berücksichtigen nur das, was jetzt zu tun ist, und integrieren keine Funktionalitäten, die möglicherweise in Zukunft benötigt werden.
2. Kommunikation
Die Kommunikation in XP erfolgt live und nicht durch Dokumentation. Das Team kommuniziert aktiv miteinander und mit dem Kunden.
3. Feedback
Feedback in XP wird auf drei Arten implementiert:
- System-Feedback: Durch ständige Modultests.
- Kunden-Feedback: Der Kunde ist Teil des Teams und beteiligt sich am Schreiben der Abnahmetests.
- Team-Feedback: Während der Planung, hinsichtlich der Schätzungen der Entwicklungszeit.
4. Mut
Einige XP-Praktiken sind so unkonventionell, dass sie Mut und ständige Selbstkontrolle erfordern.5. Respekt
Respekt in XP bedeutet, das Team und sich selbst zu respektieren. Teammitglieder sollten keine Änderungen vornehmen, die die Kompilierung, Modultests oder die Arbeit der Kollegen behindern. Jedes Mitglied strebt nach der höchsten Code- und Designqualität.
Implementierung von XP und der Arbeitsablauf
Kent Beck empfiehlt die Implementierung von XP zur Lösung von Projektproblemen. Das Team wählt das dringendste Problem aus und löst es anhand einer der XP-Praktiken. Dann gehen sie zum nächsten Problem über und verwenden eine andere Praxis. Dieser Ansatz stellt sicher, dass Probleme die Motivation zur Einführung von XP fördern und das Team nach und nach alle Methodenwerkzeuge beherrscht.
Um XP in ein bestehendes Projekt zu implementieren, nehmen Sie die folgenden Praktiken schrittweise an:
- Testen: Das Team erstellt Tests, bevor es neuen Code schreibt, und refaktoriert nach und nach alten Code.
- Design: Das Team refaktoriert ständig alten Code, normalerweise bevor neue Funktionalität hinzugefügt wird.
- Planung: Das Team muss eng mit dem Kunden interagieren.
- Management: Die Manager stellen sicher, dass alle Teammitglieder die neuen Regeln befolgen.
- Entwicklung: Beginnen Sie mit der Organisation von Arbeitsplätzen für Pair Programming und ermutigen Sie Paare, die meiste Zeit zusammen zu programmieren.
Beispiel eines Workflows unter Verwendung von XP
Wer nutzt XP
Nach einer Umfrage von VersionOne aus dem Jahr 2016 verwenden nur 1% der agilen Unternehmen XP in seiner reinen Form. Weitere 10% verwenden eine Hybridform aus Scrum und XP.Obwohl XP nicht die gängigste Methodik ist, werden ihre Praktiken von den meisten Unternehmen, die agile Methoden anwenden, genutzt. So führt Pivotal Software, Inc. seinen Erfolg auf XP zurück.
Pivotal Software, Inc.
Pivotal Software, Inc. entwickelt Geschäftsanalyse basierend auf Big Data und bietet Beratungsdienste an. Ihre Produkte werden von Unternehmen wie Ford, Mercedes, BMW, GAP, Humana, großen Banken, Regierungsbehörden und Versicherungsunternehmen genutzt.
Pivotal unterstützt agile Methoden als entscheidend für moderne Entwicklungen. Unter den agilen Varianten wählten sie XP, einen Win-Win-Ansatz für Kunden und Programmierteams. Ihr Arbeitstag beginnt mit Stand-up-Meetings und endet um 18:00 Uhr — keine Überstunden. Pivotal nutzt Planungsspiele, Pair Programming, ständige Tests, kontinuierliche Integration und andere XP-Praktiken.
Was Sie lesen sollten, um XP zu verstehen
- “Extreme Programming Explained,”, “Planning Extreme Programming”, “Test-Driven Development” von Kent Beck: Diese Bücher des Erfinders von XP bieten ein tiefes Verständnis der Methodik und ihrer Vorteile.
- “Refactoring: Improving the Design of Existing Code” von Martin Fowler: Ein Buch eines XP-Mitschöpfers, das die Prinzipien und Techniken der Refaktorisierung erklärt.
- “Extreme Programming Applied: Playing to Win” von Ken Auer und Roy Miller: Ein praktischer Leitfaden zu XP-Praktiken mit Beispielen.
Werkzeuge zur Implementierung von XP in Teams
Redmine
Ein kostenloses, Open-Source-Aufgabenmanagementsystem mit Funktionen wie Unterstützung für mehrere Projekte, flexible Aufgabeverwaltung, Gantt-Diagramme, Zeitverfolgung, Dokumentationsverwaltung und Aufgabenerstellung per E‑Mail.
Basecamp
Ein einfacher, benutzerfreundlicher Dienst für die kollaborative Projektarbeit, einschließlich eines Aufgabenmanagers, Message Boards, integriertem Chat, Dateispeicherung und Kalender.
Jira
Ein leistungsstarker Dienst, der für agile Projektentwickler konzipiert wurde und einen Fehlerverfolger und ein Projektmanagement-Tool mit vielen Funktionen und Synchronisationsmöglichkeiten kombiniert.
Worksection
Ein sicherer Dienst für Projektarbeit, der das Setzen von Aufgaben und die Prozesskontrolle, die Nachverfolgung von Korrespondenzen, die Anpassung von Filtern, die Zeit- und Finanzverfolgung sowie die Dateiverwaltung ermöglicht.
Fazit
Extreme Programming ist eine agile Methodik, die sich auf die Herstellung von hochwertigem, funktionalem Code mit einer einfachen Architektur konzentriert. Ihr Zweck ist es, Unsicherheiten in Projekten zu reduzieren und flexibel auf sich ändernde Produktanforderungen zu reagieren.
XP ist ausschließlich für die Softwareentwicklung gedacht und lässt sich nicht auf andere Unternehmen anpassen.
Es ist eine der herausforderndsten Methodologien zur Implementierung aufgrund seiner dreizehn Praktiken. Dennoch sind seine Praktiken in agilen Projekten weit verbreitet und beweisen ihre Wirksamkeit.
Die Autoren raten dazu, die XP-Praktiken schrittweise zu beherrschen, während sie Projektprobleme lösen. Wenn Sie die Vorteile sehen, fahren Sie im selben Geist fort. Es besteht keine Verpflichtung, XP entweder vollständig oder gar nicht zu implementieren. Schließlich sollten agile Methoden flexibel in der Anwendung sein – angepasste Lösungen an die Bedürfnisse des jeweiligen Projektteams.