Wenn XP an Grenzen stößt

Viele Softwareprojekte haben Verträge, die Umfang, Termin und Preis festschreiben. XPs iterativer Ansatz steht dazu im Widerspruch.

Die XP-Position: Man kann nicht alle drei Faktoren (Umfang, Termin, Ressourcen) fixieren. Etwas muss flexibel bleiben. XP bevorzugt flexiblen Umfang bei fester Qualität.

Die Vertragsrealität: Kunden wollen genau wissen, was sie wann und für wie viel bekommen. Traditionelle Verträge versprechen das.

Spannungen:

• XP sagt „wir finden gemeinsam die beste Lösung." Verträge sagen „baue genau das."
• XP sagt „Änderungen sind willkommen." Verträge sagen „Änderungen kosten extra."
• XP sagt „liefere früh und iteriere." Verträge sagen „liefere am Ende alles."

Optionen:

• Bessere Verträge aushandeln: Zeit-und-Material, ergebnisorientiert oder umfangsflexible Vereinbarungen
• XP intern nutzen: Auch bei Festpreisvertrag können interne Praktiken XP sein
• Erwartungen managen: Kommunizieren, dass frühe Lieferung von Teilumfang möglich ist

XP in Vertragsumgebungen ist nicht unmöglich, erfordert aber Kundenaufklärung und Vertragsverhandlung.

XP wurde für Teams am gleichen Ort konzipiert. Es kann remote funktionieren, aber nur mit guten Kommunikationswerkzeugen und -kultur.

Herausforderungen:

• Pair Programming ist schwieriger (Latenz, Zeitzonen)
• Kundenverfügbarkeit ist schwieriger (kein kurzer Weg zum Fragen)
• Collective Ownership ist schwieriger (weniger organische Wissensverbreitung)
• Vertrauen ist schwieriger (weniger persönlicher Kontakt, weniger Beziehung)

Wenn dein verteiltes Team hat:

• Stark asynchrone Kultur (Tage zwischen Antworten)
• Zeitzonenunterschiede, die Überschneidungen verhindern
• Zurückhaltung bei Video oder synchroner Kommunikation
• Kein etabliertes Vertrauen zwischen Teammitgliedern

...werden XP-Praktiken Schwierigkeiten haben.

Damit es funktioniert, braucht es:

• Überschneidende Arbeitszeiten (mindestens einige Stunden pro Tag)
• Starke schriftliche Kommunikationsnormen
• Bewussten Beziehungsaufbau
• Werkzeuge, die Echtzeit-Zusammenarbeit ermöglichen

Manche verteilten Teams machen XP sehr gut. Andere schaffen es nicht. Der Unterschied ist meist die Kommunikationskultur, nicht die Geografie.

Branchen wie Gesundheitswesen, Finanzen und Luftfahrt haben regulatorische Anforderungen, die mit XP-Praktiken kollidieren können.

Spannungen:

• Continuous Deployment vs. Change Control Boards
• Collective Ownership vs. individuelle Freigabepflichten
• Einfache Dokumentation vs. Compliance-Nachweise
• Refactoring vs. Re-Validierungsanforderungen

Jedoch: XP ist in regulierten Umgebungen nicht unmöglich. Viele regulierte Teams nutzen XP erfolgreich.

Anpassungen:

• Tests werden zu Compliance-Nachweisen (jedes Verhalten ist validiert)
• Change Control gilt für Releases, nicht für Commits
• Dokumentation wird aus Code und Tests automatisiert
• Risikobasierte Validierung (nicht jeder Code erfordert dieselbe Strenge)

Die zentrale Erkenntnis: XPs Qualitätspraktiken übertreffen oft regulatorische Mindestanforderungen. Umfassende Tests, Code-Review (Pairing) und Nachvollziehbarkeit sind Dinge, die Regulatoren wollen.

Was XP ablehnt, ist Verschwendung: Dokumentation um ihrer selbst willen, lange Freigabeprozesse, Formalitäten, die Qualität nicht verbessern.

XPs Engineering-Praktiken sind nicht verhandelbar. Wenn das Team sich weigert, sie zu übernehmen, funktioniert XP nicht.

Häufige Widerstände:

• „TDD ist zu langsam" (Missverständnis über Produktivität)
• „Wir haben keine Zeit zum Pairen" (Milchmädchenrechnung)
• „Refactoring ist Goldrandlösung" (Verwechslung mit Wartung)
• „CI ist Overhead" (Wert wird nicht erkannt)

Wenn Widerstand von Entwicklern kommt:

• Es kann mangelnde Erfahrung sein (sie wissen nicht wie)
• Es kann vergangenes Trauma sein (schlechte Umsetzung, die sie gesehen haben)
• Es kann Identitätsbedrohung sein (Herausforderung ihrer Expertise)
• Klein anfangen, Wert demonstrieren, Fähigkeiten schrittweise aufbauen

Wenn Widerstand vom Management kommt:

• „Pairing bedeutet halbe Produktivität" (über Qualitätsvorteile aufklären)
• „TDD ist verschwendete Zeit" (Bug-Reduktion, schnelleres Debugging zeigen)
• „Wir können uns die Investition nicht leisten" (langfristige Kosteneinsparungen zeigen)

XP erfordert Commitment. Man kann Praktiken schrittweise einführen, aber wenn Team oder Organisation sich weigern, sich mit technischer Exzellenz zu befassen, wird XP nicht Fuß fassen.

Manche Domänen machen TDD deutlich schwieriger:

UI-lastige Anwendungen: Testen von visuellem Erscheinungsbild und Interaktion kann knifflig sein. (Moderne Tools wie React Testing Library haben das aber verbessert.)

Machine-Learning-Modelle: Testen probabilistischer Ergebnisse passt nicht zum assert-equals-Modell.

Hardware-abhängige Systeme: Physisches Geräteverhalten ist schwer zu simulieren.

Hochgradig nebenläufige Systeme: Timing-abhängiges Verhalten ist schwer deterministisch zu testen.

Für diese Domänen:

• TDD kann auf Teile des Systems (Geschäftslogik) anwendbar sein, aber nicht auf andere (UI, ML-Training)
• Andere Teststrategien können nötig sein (Property-based Testing, Visual Regression, Hardware-Simulation)
• Das Prinzip (schnelles Feedback zur Korrektheit) bleibt, auch wenn die Praktik sich anpasst

Nutze diese nicht als Ausreden, um Tests ganz zu überspringen. Jedes System hat testbare Teile. Treibe TDD so weit wie möglich; passe an, wo du musst.