eXtreme Programming

eXtreme Programming — meist einfach XP — ist das anspruchsvollste Mitglied der agilen Familie. East Agile Tracker ist in erster Linie für XP gebaut; alles andere folgt daraus.

Diese Seite behandelt, was XP ist, warum es funktioniert und wie man es mit dem Tracker als Planungsoberfläche praktiziert.

Was XP ist

XP wurde von Kent Beck Ende der 1990er Jahre geschaffen. Das erste Buch — Extreme Programming Explained: Embrace Change — wurde 1999 veröffentlicht. Es begann, wie viele Dinge, mit einem frustrierten Team, das versuchte, ein Lohnabrechnungssystem bei Chrysler auszuliefern.

XPs Wette ist, dass der richtige Weg, mit Unsicherheit in der Software umzugehen, darin besteht, die Dinge zu tun, die funktionieren, und sie öfter zu tun. Testen? Ständig testen. Integrieren? Stündlich integrieren. Reden? Ständig reden. Planen? Jede Iteration planen und neu planen, während man lernt.

„XP ist eine leichtgewichtige Methodologie für kleine bis mittelgroße Teams, die Software angesichts vager oder sich schnell ändernder Anforderungen entwickeln.” — Kent Beck

Die fünf Werte

XP benennt fünf Werte, von denen alles andere abhängt:

1. Kommunikation — Das Team redet. Täglich. Über die Arbeit, das Design, die Hindernisse. Von Angesicht zu Angesicht, wenn möglich. Silos sind der Feind.
2. Einfachheit — Tu das Einfachste, was möglicherweise funktionieren könnte. Komplexität kannst du später hinzufügen, wenn du sie wirklich brauchst. Wahrscheinlich wirst du es nicht.
3. Feedback — Vom Code (Tests), vom Team (Pair Programming, Reviews), vom Benutzer (häufige Releases). Hol es dir schnell.
4. Mut — Sag die Wahrheit über Fortschritt, Schätzungen und Design. Wirf Code weg, der nicht funktioniert. Refaktoriere, was dich aufhält.
5. Respekt — Jeder im Team — und jetzt jeder Agent im Team — trägt Wert bei. Behandelt einander entsprechend.

Die Praktiken

XP ist berühmt für seine zwölf ursprünglichen Praktiken, organisiert in vier Bereichen:

Planung

• Planning Game — Das Team und der Kunde planen gemeinsam: was als Nächstes kommt, in welcher Reihenfolge, wie groß jedes Stück ist.
• Small Releases — Liefere oft aus. Tage, nicht Monate. Hol dir Feedback zu etwas Konkretem.
• User Stories — Anforderungen sind Gespräche, festgehalten als kurze Stories aus Sicht des Benutzers. „Als Benutzer möchte ich X, damit Y.”

Design

• Simple Design — Das einfachste Design, das die Tests besteht und jedes benötigte Konzept ausdrückt. Nicht mehr.
• Refactoring — Verbessere das Design von Code, der bereits funktioniert. Ständig.
• System Metaphor — Eine gemeinsame Erzählung darüber, wie das System funktioniert, verwendet, um Designentscheidungen konsistent zu treffen.

Coding

• Pair Programming — Zwei Entwickler, eine Tastatur. Einer fährt, einer navigiert. Häufig wechseln.
• Collective Code Ownership — Jeder kann jeden Code verbessern. Keine Lehnsgüter.
• Continuous Integration — Integriere und teste Code viele Male am Tag. Fange Brüche sofort ab.
• Coding Standards — Vereinbarter Stil, damit der Code sich liest, als hätte eine Person ihn geschrieben.

Testing

• Test-Driven Development (TDD) — Schreibe zuerst den fehlschlagenden Test, dann den Code, der ihn bestehen lässt.
• Acceptance Tests — Der Kunde definiert in Code oder ausführbarer Form, was „fertig” für jede Story bedeutet.

Warum XP funktioniert

XP ist unbequem. Pair Programming zwingt dich, laut zu denken. TDD zwingt dich zu wissen, wie Erfolg aussieht, bevor du den Code schreibst. Continuous Integration killt deine geliebten langlebigen Branches. Small Releases bedeuten, dass du dich nicht hinter einer Sechs-Monats-Roadmap verstecken kannst.

Es funktioniert, weil all diese Dinge die Feedback-Schleifen verkürzen. Je schneller du herausfindest, dass du dich geirrt hast, desto billiger ist die Korrektur. XP geht im Kern darum, die Feedback-Schleife so eng wie möglich zu machen.

Es geht auch um Mut und Respekt. Man kann XP nur in einem Team praktizieren, das einander genug vertraut, um sich laut zu irren.

Das disziplinierte Story-Modell

East Agile Tracker kodiert eine bestimmte Theorie der Planung. Behandeln Sie diesen Abschnitt als Betriebsanleitung dafür, warum das Datenmodell so aussieht, wie es aussieht — und als Feldführer dafür, was man in der Praxis tun (und nicht tun) sollte.

Warum die vier Story-Typen wichtig sind

Alles ist eine Story, aber es gibt vier Arten, und die Unterscheidung ist der ganze Punkt:

• Features tragen Punkte und sind das Einzige, was zur Velocity „zählt”. Das zwingt Sie dazu, Arbeit in für den Benutzer sichtbaren Wert zu zerlegen.
• Bugs sind unbepunktet (null). Defekte verdienen keine Anerkennung, was die Kosten von Nacharbeit sichtbar macht, anstatt sie zu belohnen.
• Chores sind ebenfalls unbepunktet — notwendige Arbeit ohne direkten Benutzerwert (Infrastruktur, Refactorings, Setup). Sie bei null zu halten, setzt das Team unter Druck, sie wo immer möglich in Features zu bündeln, damit die Wertorientierung ehrlich bleibt.
• Releases sind Markierungen mit null Punkten, die verwendet werden, um Meilensteine zu verankern und dem Werkzeug zu erlauben, ein Datum zu prognostizieren.

Der Verhaltenseffekt ist das, was zählt: Wenn Bugs und Chores nicht punkten, drängt ein Team von Natur aus dazu, Arbeit als benutzerorientierte Funktionalität auszudrücken, und es wird sich der Defektkosten akut bewusst. Das ist eine Planungsdisziplin, die im Datenmodell kodiert ist.

Der einzelne geordnete Backlog

Drei Zonen, eine Regel.

• Die Icebox ist der unpriorisierte Ideen-Pool.
• Der Backlog ist eine streng geordnete Liste mit einziger Priorität — keine Gleichstände, kein „P1/P1/P1”.
• Die Current-Zone hält die aktive(n) Iteration(en).

Der Product Owner verantwortet die Reihenfolge von oben nach unten, und die Invariante ist, dass die Spitze des Backlogs immer das Wichtigste und am besten Spezifizierte ist, wobei die Klarheit legitimerweise abnimmt, je weiter Sie nach unten gehen. Eine Story nahe der Spitze mit vagen Akzeptanzkriterien ist ein Planungsfehler. Die Icebox darf ein Friedhof sein; der Backlog nicht.

Velocity-getriebene automatische Planung

Das ist der Teil, den die meisten Teams anderswo schlecht nachbauen. Tracker-artige Planung berechnet eine gleitende durchschnittliche Velocity aus kürzlich akzeptierten Punkten und zieht automatisch so viele Punkte an Stories in die nächste Iteration — Sie „committen” sich nicht manuell auf einen Sprint, die empirischen Daten erledigen das für Sie. Zwei bewahrenswerte Konsequenzen:

• Sie schätzen nur Features, mit relativen Punkten (Fibonacci 1/2/3/5/8 oder unsere engere 0/1/2/3), nicht Stunden. Schätzung ist ein Sizing-Gespräch, kein Versprechen.
• Sie manipulieren die Velocity nicht. Punkte aufzublähen, um „schnell auszusehen”, oder Chores zu bepunkten, durchbricht die Prognose, die das gesamte System ehrlich macht. Velocity ist ein Messinstrument, und Sie manipulieren nicht Ihr eigenes Instrument.

Der Lohn ist, dass die Prognose des Release-Datums zu einer Berechnung statt zu einer Verhandlung wird und sich das Gespräch mit Stakeholdern von „Kannst du dich verpflichten, X bis Freitag zu liefern” zu „Bei aktueller Velocity landet dieses Release etwa um Datum Y — hier ist der Scope/Datum-Kompromiss” verschiebt.

Der Story-Lebenszyklus und die Acceptance-Schleife

Die Zustandsmaschine ist Start → Finish → Deliver → Accept / Reject. Der kritische Zustand ist Deliver: Ein Entwickler markiert eine Story als delivered, aber sie ist erst fertig, wenn der Product Owner sie ausdrücklich gegen ihre Akzeptanzkriterien akzeptiert — oder ablehnt und sie zurückschickt. Das verankert eine Kunden-Feedback-Schleife in jeder einzelnen Story, anstatt die Akzeptanz auf eine Demo am Sprintende zu verschieben.

Akzeptanzkriterien gehören auf die Story, bevor sie gestartet wird, idealerweise in Given/When/Then-Form, damit sie direkt auf Akzeptanztests abgebildet werden können. INVEST ist die Plausibilitätsprüfung dafür, ob eine Story gut geformt ist:

• Independent (Unabhängig) — kann ohne andere Stories ausgeliefert werden.
• Negotiable (Verhandelbar) — erfasst die Absicht, keine eingefrorene Spezifikation.
• Valuable (Wertvoll) — für einen Benutzer oder Stakeholder.
• Estimable (Schätzbar) — das Team kann sie dimensionieren.
• Small (Klein) — passt bequem in eine Iteration.
• Testable (Testbar) — hat Akzeptanzkriterien, die ausgeführt werden können.

Kadenz

Die Planungs-Zeremonien sind leicht und regelmäßig:

• Ein wöchentliches Iteration Planning Meeting, um neue Stories zu bepunkten und Akzeptanzkriterien an der Spitze des Backlogs festzunageln.
• Ein kurzes tägliches Standup, fokussiert auf Flow und Blocker.
• Eine Retrospektive pro Iteration, um den Prozess anzupassen.

Iterationen dauern üblicherweise eine oder zwei Wochen — kurz genug, dass eine schlechte Schätzung billig zu entdecken ist.

Die Engineering-Praktiken, die Planung funktionieren lassen

Tracker-artige Planung ist die sichtbare Hälfte von XP; sie bricht ohne die Engineering-Hälfte zusammen.

• Test-first / TDD und eine echte Akzeptanztest-Suite sind das, was „delivered” eine Bedeutung gibt.
• Continuous Integration und kleine, häufige Releases halten die Cycle Time kurz, sodass die Velocity stabil statt sprunghaft ist.
• Pair Programming (oder starkes Review) hält die Work-in-Progress niedrig — fertig werden, bevor du beginnst — was der größte Hebel für die Cycle Time ist.
• Ein verfügbarer Product Owner ist das, was die Accept/Reject-Schleife am Stocken hindert.

Anti-Patterns, auf die man achten sollte

Die wiederkehrenden Fehlschläge:

• Den Backlog als Parkplatz behandeln statt als echte Prioritätsreihenfolge.
• Bugs und Chores schätzen, um die Velocity besser aussehen zu lassen.
• Riesige Stories mit sich herumtragen, die in einer Iteration nicht fertig werden können. Aufteilen, bis jede unabhängig auslieferbar ist.
• Stories in Delivered stapeln lassen, weil niemand akzeptiert.

Jeder dieser Punkte verwandelt still und leise ein empirisches System wieder in Wunschplanung. Der Tracker kann Sie nicht davon abhalten, sie zu tun; er kann sie nur sichtbar machen. Schauen Sie sich am Ende jeder Iteration Ihre Delivered-Spalte an — wenn sie wächst, ist das Ihr Signal.

XP mit East Agile Tracker

Der Tracker ist die Planungsoberfläche, die sich XP-Teams seit den Pivotal Tracker Tagen gewünscht haben. Jedes Konzept wird direkt abgebildet:

User Stories → Stories

XP-User-Stories sind East Agile Tracker Stories. Schreiben Sie sie im Typ Feature. Verwenden Sie die Beschreibung für das Gespräch; verwenden Sie Kommentare für die laufende Diskussion. Die Akzeptanzkriterien gehören in die Beschreibung.

Planning Game → Das Board

Das Planning Game in XP ist ein Gespräch zwischen Business und Team über Priorität und Größe. In East Agile Tracker:

1. Die Produktperson schreibt Stories in den Backlog und ordnet sie nach Priorität.
2. Das Team schätzt Features in Punkten (Fibonacci- oder East Agile Skala).
3. Das System plant Iterationen automatisch aus der Velocity.
4. Das Team startet Stories von der Spitze der Current-Spalte.

Das ist alles. Das „Spiel” lebt im Gespräch; der Tracker hält nur den Spielstand.

Small Releases → Releases (der Story-Typ)

XP sagt: release oft. Release ist einer der vier Story-Typen in East Agile Tracker. Erstellen Sie ein Release für jeden Auslieferungs-Meilenstein; ziehen Sie es in die Iteration, in der es ausgeliefert wird. Releases überspringen Started/Finished/Delivered und gehen direkt zu Accepted, wenn Sie ausliefern.

Continuous Integration → Story-Zustandsmaschine

Die Zustandsmaschine ist nicht CI an sich — das ist Ihr Build-System — aber der Pfad Finished → Delivered → Accepted spiegelt die Kunden-Akzeptanz-Schleife wider, die XP beschreibt. Beenden Sie die Arbeit, liefern Sie sie an den Kunden, akzeptieren Sie, wenn sie als funktionierend bestätigt ist.

Velocity → „Yesterday’s weather”

XP nennt es yesterday’s weather: Wie viel Sie letzte Iteration geschafft haben, ist die beste Vorhersage dafür, wie viel Sie diese schaffen werden. East Agile Tracker berechnet die Velocity automatisch — Durchschnitt der jüngsten Iterationen, konfigurierbare Strategie — und nutzt sie, um die Kapazität der nächsten Iteration automatisch zu planen.

Acceptance Tests → Reviews

Story-Reviews im Tracker bilden die Akzeptanz ab. Weisen Sie einen Reviewer zu (den Kunden, den Product Owner oder sogar einen Agenten, der als einer agiert). Er genehmigt oder lehnt ab. Eine Ablehnung schickt die Story zurück auf Started.

Pair Programming → Co-Ownership

XP-Teams pairen am Code. Im Tracker zeigt sich das als mehrere Owners auf einer Story. Weisen Sie beide Paarpartner der Story zu; beide Namen erscheinen auf der Karte.

XP mit Agenten — die neue Praxis

XP wurde geschrieben, bevor KI-Agenten sinnvoll zur Software beitragen konnten. Wir halten dies für das wichtigste Update von XP seit fünfundzwanzig Jahren.

In unserer Praxis — und wofür der Tracker gebaut ist — ist ein Agent ein benanntes XP-Teammitglied. Er hat seine eigene Rolle, seinen eigenen Paarpartner (Mensch oder Agent) und seinen eigenen Audit-Trail. Er kann alles tun, was ein menschliches Teammitglied in der Planungsoberfläche tun kann: schätzen, Stories besitzen, kommentieren, wechseln, Reviews akzeptieren.

Die XP-Werte gelten weiterhin. Kommunikation: Agenten kommunizieren, indem sie den Event-Stream lesen und Kommentare posten. Einfachheit: Agenten sind auf die Rollen beschränkt, die Sie ihnen gewähren. Feedback: Jede Agenten-Aktion steht im Audit-Log, sofort überprüfbar. Mut: Seien Sie ehrlich darüber, was Ihre Agenten richtig gemacht haben und was nicht. Respekt: Agenten-Teammitglieder tragen Wert bei — erkennen Sie ihn an.

Wir setzen die Agenten nicht in den Tracker, um das Coding zu erledigen. Wir geben die Planungsoberfläche Menschen und Agenten, die zusammenarbeiten. Sie bringen den Coding-Agenten mit — Claude Code, Codex, Ihren eigenen — und verbinden ihn über die API mit dem Tracker. Der Agent nimmt Stories auf, erledigt die Arbeit, kommentiert, wechselt. Sie überprüfen die Spur und akzeptieren.

Das ist Inclusive Agile Planning. Es ist XP, mit dem Team, das es tatsächlich hat.

Weiterführende Literatur

• Extreme Programming Explained — Kent Becks grundlegendes Buch, 1999.
• Das Agile Manifest — Wo die Familie begann.
• Agile Entwicklung — Das größere Bild.
• Bedienungsanleitung — Praktischer Leitfaden zum Tracker.
• API-Leitfaden — Den Coding-Agenten anschließen.