Extreme Programming (XP): gute Praktiken bis zum Äußersten
https://bildung.social/@oerinformatik/
https://oer-informatik.de/extreme-programming
Extreme Programming, XP, Vorgehensmodelle, Kent Beck, Pair Programming, testgetriebene Entwicklung, kontinuierliche Integration, Refactoring, User Stories, agile Softwareentwicklung
tl/dr; (ca. 13 min Lesezeit): Extreme Programming (XP) ist ein agiles Vorgehensmodell, das bewährte Entwicklungspraktiken konsequent auf die Spitze treibt: Wenn Tests gut sind, wird immer zuerst getestet; wenn Code-Reviews gut sind, wird ständig zu zweit programmiert. Der Artikel erklärt Herkunft, Werte und Praktiken von XP, den Ablauf mit Release- und Iterationsplanung, die Rollen, den Testansatz und die Grenzen des Modells [AI-Assisted]. (Zuletzt geändert am 30.10.2026)
Disclaimer: Teile des Textes stammen von einer KI. Inhalte sind nicht automatisch zuverlässig; überprüfe Fakten und zitiere vertrauenswürdige Quellen.
Dieser Artikel ist Teil einer Artikelreihe über Vorgehensmodelle: Überblick: klassisch und agil / Wasserfallmodell / V-Modell / Spiralmodell / Scrum / Extreme Programming / Kanban / SAFe / DevOps / Übungsaufgaben
Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast.
Dieser Artikel baut auf der Kann-Liste des Artikels Vorgehensmodelle: klassisch und agil auf.
Als Projektmanagement-Grundlagen kann ich nach Durchlesen des Artikels…
… die Grundidee von Extreme Programming erklären und seine fünf Werte nennen.
… zentrale XP-Praktiken (Pair Programming, testgetriebene Entwicklung, kontinuierliche Integration, Refactoring, kleine Releases) beschreiben.
… den Ablauf von XP mit Release- und Iterationsplanung darstellen.
… die Rollen Kunde, Entwickler*innen und Coach im XP-Team unterscheiden.
Darüber hinaus kann ich als Projektmanagement-Expertenwissen…
… die Feedback-Schleifen von XP auf unterschiedlichen Zeitskalen erläutern.
… XP von Scrum abgrenzen und begründen, warum beide oft kombiniert werden.
… Voraussetzungen und Grenzen von XP beurteilen.
In einem Satz: Extreme Programming zeichnet sich dadurch aus, dass ein kleines Team mit ständig anwesender Kundschaft in sehr kurzen Zyklen kleine Releases liefert und dabei technische Praktiken wie testgetriebene Entwicklung, Pair Programming und kontinuierliche Integration konsequent anwendet.
Der Kern von XP sind Rückmeldungen auf allen Zeitskalen: von der zweiten Person am selben Rechner nach Sekunden bis zur Releaseplanung nach Monaten.
Herkunft: das C3-Projekt bei Chrysler
XP entstand Mitte der 1990er Jahre in einem Lohnabrechnungsprojekt des Autoherstellers Chrysler (Chrysler Comprehensive Compensation, C3). Kent Beck übernahm dort 1996 die Leitung und entwickelte gemeinsam mit Ward Cunningham, Ron Jeffries und anderen eine Arbeitsweise, die bewährte Praktiken „bis zum Äußersten“ (extreme) treibt. 1999 erschien sein Buch „Extreme Programming Explained: Embrace Change“, 2004 eine stark überarbeitete zweite Auflage (mit Cynthia Andres). Beck und Jeffries gehörten 2001 zu den Verfassern des Agilen Manifests. Ziel von XP ist, mit sich ändernden Anforderungen umzugehen, ohne dass die Qualität leidet: Änderungen sollen jederzeit möglich und billig bleiben. Typische Einsatzbereiche sind kleine bis mittlere Softwareprojekte mit unklaren oder sich schnell ändernden Anforderungen.
Grundprinzipien: Werte, Prinzipien, Praktiken
XP ist in drei Ebenen aufgebaut: Werte geben die Richtung, Prinzipien übersetzen sie, Praktiken machen sie konkret. Die fünf Werte sind:
Kommunikation: Probleme entstehen oft, weil jemand etwas nicht weiß; also wird viel und direkt miteinander gesprochen.
Einfachheit: Es wird die einfachste Lösung gebaut, die heute funktioniert (You Aren’t Gonna Need It, YAGNI).
Feedback: Rückmeldungen von Tests, Kundschaft und Team kommen möglichst früh und oft.
Mut: Code wird verbessert, Probleme werden offen angesprochen, Unnötiges wird weggeworfen.
Respekt (seit der zweiten Auflage): Alle im Team respektieren sich und die gemeinsame Arbeit.
Prinzipien wie kleine Schritte (baby steps), Qualität, Reflexion, gegenseitiger Nutzen und Flow verbinden Werte und Praktiken. Besonders an XP ist der Schwerpunkt auf technischer Exzellenz: Anders als Scrum sagt XP sehr genau, wie programmiert werden soll.
Ablauf: Releases, Iterationen, Tests
XP arbeitet auf zwei Planungsebenen und mit kurzen technischen Zyklen:
Releaseplanung (Planning Game, in der zweiten Auflage quarterly cycle): Kundschaft und Team legen fest, welche User Stories in den nächsten Wochen oder Monaten als Release ausgeliefert werden. Die Kundschaft priorisiert, die Entwickler*innen schätzen.
Iterationsplanung (weekly cycle): Für die nächste Iteration von meist ein bis zwei Wochen werden Stories ausgewählt und in Aufgaben (Tasks) zerlegt, die sich die Entwickler*innen selbst nehmen.
Entwickeln in kurzen Zyklen: Test schreiben, Code im Paar schreiben, bis der Test grün ist, refaktorieren, integrieren – oft mehrmals pro Stunde.
Akzeptanztests: Die Kundschaft legt für jede Story Akzeptanztests fest; eine Story ist fertig, wenn ihre Akzeptanztests bestehen.
Kleine Releases: Lauffähige Software geht so oft wie möglich in Betrieb.
Feste Treffen sind das tägliche Stand-up-Meeting und die Planungsrunden zu Beginn von Iteration und Release; Reflexionen nach jeder Iteration sind üblich. Das Aktivitätsdiagramm zeigt den Ablauf mit seinen Ergebnissen:
Rollen: das ganze Team an einem Ort
XP setzt auf ein ganzes Team (whole team) an einem Ort (sit together). Typische Rollen sind:
| Rolle | Aufgabe |
|---|---|
| Kunde (on-site customer) | sitzt beim Team, schreibt und priorisiert Stories, legt Akzeptanztests fest, beantwortet Fragen sofort |
| Entwickler*innen | schätzen Stories, programmieren im Paar, schreiben Tests, refaktorieren, besitzen den Code gemeinsam |
| Tester*innen | helfen der Kundschaft, Akzeptanztests zu formulieren und zu automatisieren |
| Coach | achtet darauf, dass die Praktiken gelebt werden, unterstützt das Team (ähnlich einem Scrum Master) |
| Tracker | verfolgt den Fortschritt (z. B. Velocity) und macht ihn sichtbar |
Die Teamkultur ist geprägt von gemeinsamer Verantwortung (collective code ownership: jede Person darf jeden Code ändern), einem nachhaltigen Tempo (keine Dauer-Überstunden, früher 40-Stunden-Woche) und einem informativen Arbeitsplatz, an dem Story-Karten und Fortschritt für alle sichtbar sind.
Artefakte: Karten, Tests, Code
| Artefakt | Inhalt |
|---|---|
| Story Cards | User Stories auf Karten, mit Schätzung und Priorität |
| Task Cards | technische Aufgaben einer Iteration |
| Release- und Iterationsplan | ausgewählte Stories je Release bzw. Iteration |
| Unit-Tests | automatisierte Tests jeder Funktion, entstehen vor dem Code |
| Akzeptanztests | automatisierte Tests der Stories aus Sicht der Kundschaft |
| Quellcode | einfach, refaktoriert, nach gemeinsamen Codierrichtlinien |
Die Dokumentation ist sehr leichtgewichtig: Der Code und die Tests gelten als wichtigste und immer aktuelle Dokumentation. Anforderungen stehen als kurze Karten bereit und werden im Gespräch mit der Kundschaft geklärt.
Qualität und Test: Test zuerst, immer
Der Testansatz ist das Herz von XP:
Testgetriebene Entwicklung (Test-First, TDD): Zuerst wird ein Test geschrieben, der fehlschlägt, dann genau so viel Code, dass er besteht, dann wird aufgeräumt (Red – Green – Refactor).
Kontinuierliche Integration: Alle integrieren ihren Code mehrmals täglich; ein automatischer Build mit allen Tests soll höchstens zehn Minuten dauern (ten-minute build).
Pair Programming: Zwei Personen arbeiten an einem Rechner, eine schreibt, eine prüft und denkt voraus – ein laufendes Code-Review.
Refactoring und einfaches Design: Der Code wird laufend verbessert, ohne sein Verhalten zu ändern; die Tests sichern dabei ab.
Akzeptanztests der Kundschaft prüfen, ob die Stories fachlich richtig umgesetzt sind.
Die automatisierte Testsuite ist damit das Sicherheitsnetz, das häufige Änderungen erst möglich macht.
Stakeholder: Kundschaft im Team
Keine andere Methode bindet die Kundschaft so eng ein: Im Idealfall sitzt eine fachkundige Person der Auftraggebenden täglich beim Team, beantwortet Fragen sofort, schreibt Stories und Akzeptanztests und sieht nach jeder Iteration lauffähige Software. Feedback kommt so in Stunden statt Monaten. Ist das nicht möglich, wird eine Stellvertretung (z. B. ein Product Owner) benannt, was aber die Rückmeldewege verlängert.
Planung und Kontrolle: Velocity und kleine Schritte
Geplant wird nur so weit wie nötig: grob für das Release, genau für die nächste Iteration. Die Kundschaft entscheidet über Umfang und Priorität, die Entwickler*innen über Schätzungen. Für Prognosen nutzt XP die Velocity: Was das Team in der letzten Iteration geschafft hat, plant es auch für die nächste ein (yesterday’s weather). Transparenz entsteht über die sichtbaren Story-Karten und den Tracker. Weitere Kennzahlen sind der Anteil bestandener Akzeptanztests, die Build-Dauer und die Anzahl gefundener Fehler.
Skalierung und Anpassbarkeit: am besten im kleinen Team
XP ist für kleine, an einem Ort arbeitende Teams gedacht (etwa zwei bis zwölf Entwickler*innen). Größere Vorhaben werden meist in mehrere Teams geteilt, die über einen Rahmen wie Scrum, Nexus oder SAFe koordiniert werden. Sehr häufig werden einzelne XP-Praktiken in andere Modelle übernommen: Scrum-Teams nutzen TDD, Pair Programming und CI, um am Sprintende ein wirklich fertiges Increment zu haben; in SAFe sind XP-Praktiken ausdrücklich Teil der Teamebene. Pair Programming wird heute oft zu Mob bzw. Ensemble Programming erweitert, bei dem das ganze Team an einem Bildschirm arbeitet.
Häufig genutzte Techniken
Diese Techniken gehören zum Kern von XP (Praktiken der ersten Auflage, teils umbenannt): Planning Game, kleine Releases, System-Metapher, einfaches Design, Testen (TDD und Akzeptanztests), Refactoring, Pair Programming, gemeinsames Code-Eigentum, kontinuierliche Integration, nachhaltiges Tempo, Kunde vor Ort und Codierrichtlinien. Häufig mit XP kombiniert, aber nicht Kern des Modells sind:
User Stories nach dem INVEST-Schema und Story Points,
Behavior Driven Development (BDD) für lesbare Akzeptanztests,
Continuous Delivery als Fortsetzung der kontinuierlichen Integration bis in den Betrieb (siehe DevOps),
Mob Programming.
Risiken, Stärken und Grenzen
Häufige Stolpersteine: Die Kundschaft kann nicht dauerhaft beim Team sein; Pair Programming wird als Verschwendung empfunden; Praktiken werden einzeln weggelassen, obwohl sie sich gegenseitig stützen (ohne Tests ist Refactoring riskant, ohne CI zerfällt gemeinsames Code-Eigentum); die Dokumentation reicht später für Wartung oder Nachweise nicht aus.
Typische Gegenmaßnahmen: eine Stellvertretung mit Entscheidungsbefugnis, Pair Programming schrittweise einführen und Paare wechseln, die Praktiken als Paket einführen, ergänzende Dokumentation dort, wo sie gefordert ist.
Stärken: sehr hohe Codequalität, schnelle Reaktion auf Änderungen, frühe und häufige Rückmeldungen, Wissen im ganzen Team verteilt, wenige Fehler im Betrieb.
Grenzen: verlangt Disziplin und Erfahrung, eine sehr engagierte Kundschaft und ein Team an einem Ort; schwer skalierbar; ungeeignet, wenn umfangreiche Vorab-Dokumentation oder formale Nachweise gefordert sind.
Praxisbeispiele und Anwendungsfelder
XP passt zu kleinen bis mittleren Softwareprojekten mit sich schnell ändernden Anforderungen, etwa interne Fachanwendungen mit ansprechbarer Fachabteilung, Webanwendungen oder Produktentwicklung in Start-ups. Beispiel: Ein Team aus vier Entwickler*innen baut für die Werkstatt der CSB-Rad eine Terminverwaltung; Werkstattleiter Bastian Ludwig sitzt zwei Tage pro Woche beim Team, testet jede Woche die neue Version und formuliert die nächsten Stories. Teamgröße: etwa zwei bis zwölf Personen.
Leitfragen
- Was ist die Grundidee von Extreme Programming, und welche fünf Werte gehören dazu?
XP treibt bewährte Praktiken auf die Spitze (z. B. immer zuerst testen, ständig zu zweit programmieren), damit Änderungen jederzeit billig bleiben. Die Werte sind Kommunikation, Einfachheit, Feedback, Mut und Respekt, siehe Abschnitt „Herkunft“ und Abschnitt „Grundprinzipien“.
- Wie läuft ein XP-Projekt ab?
In der Releaseplanung wählen Kundschaft und Team Stories für ein Release, in der Iterationsplanung für ein bis zwei Wochen; dann wird in kurzen Zyklen getestet, im Paar programmiert, refaktoriert und integriert. Die Kundschaft prüft mit Akzeptanztests, und kleine Releases gehen häufig in Betrieb, siehe Abschnitt „Ablauf“.
- Welche Praktiken sichern in XP die Qualität?
Testgetriebene Entwicklung (Red – Green – Refactor), kontinuierliche Integration mit schnellem automatischem Build, Pair Programming als laufendes Review, Refactoring mit einfachem Design und Akzeptanztests der Kundschaft, siehe Abschnitt „Qualität und Test“.
- Welche Rollen gibt es im XP-Team, und welche Rolle spielt die Kundschaft?
Kunde vor Ort, Entwickler*innen, Tester*innen, Coach und Tracker. Die Kundschaft sitzt im Idealfall beim Team, schreibt und priorisiert Stories, legt Akzeptanztests fest und beantwortet Fragen sofort, siehe Abschnitt „Rollen“ und Abschnitt „Stakeholder“.
- Was bedeuten die Feedback-Schleifen von XP?
XP sorgt auf allen Zeitskalen für Rückmeldung: Pair Programming nach Sekunden, Unit-Tests nach Minuten, Stand-up täglich, Akzeptanztests nach Tagen, Iterationsplanung wöchentlich, Releaseplanung nach Monaten – je kürzer die Schleife, desto billiger ein Fehler, siehe Grafik am Artikelanfang und Abschnitt „Ablauf“.
- Wie unterscheidet sich XP von Scrum, und warum werden beide oft kombiniert?
Scrum regelt Verantwortlichkeiten, Ereignisse und Artefakte, sagt aber nicht, wie programmiert wird; XP legt dagegen genau die technischen Praktiken fest. Scrum-Teams nutzen deshalb oft TDD, Pair Programming und CI aus XP, siehe Abschnitt „Skalierung und Anpassbarkeit“.
- Wo liegen die Grenzen von XP?
XP verlangt Disziplin, Erfahrung, eine dauerhaft verfügbare Kundschaft und ein kleines Team an einem Ort; es skaliert schlecht und passt nicht, wenn umfangreiche Dokumentation oder formale Nachweise gefordert sind, siehe Abschnitt „Risiken, Stärken und Grenzen“.
Links und weitere Informationen
Vorgehensmodelle: klassisch und agil (Überblick und Vergleich)
zum Weiterlesen: Kent Beck, Cynthia Andres: Extreme Programming Explained: Embrace Change. 2. Auflage, Addison-Wesley, 2004
historisch: Kent Beck: Extreme Programming Explained: Embrace Change. Addison-Wesley, 1999
für den Einstieg: Kent Beck: Test-Driven Development: By Example. Addison-Wesley, 2002
Hinweis zur Nachnutzung als Open Educational Resource (OER)
Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Extreme Programming (XP): gute Praktiken bis zum Äußersten” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/extreme-programming veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/vorgehensmodelle/vorgehensmodelle. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 30.10.2026.
[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]
