Wann XP passt

XP wurde für Projekte entwickelt, bei denen sich Anforderungen häufig ändern. Wenn Sie nicht genau wissen, was Sie bauen sollen, hilft Ihnen XP dabei, es herauszufinden.

Anzeichen für hohe Unsicherheit:

• Kunden können ihre Bedürfnisse nicht präzise formulieren
• Der Markt verändert sich
• Sie bauen etwas Neues, nicht etwas Bekanntes nach
• Nutzerfeedback ändert regelmäßig die Prioritäten
• Wettbewerber innovieren und zwingen Sie zur Anpassung

In diesen Umgebungen scheitern traditionelle Ansätze. Detailliertes Design im Voraus wird vor der Implementierung obsolet. Große Releases verfehlen das Ziel, weil sich die Anforderungen geändert haben.

XP nimmt Veränderungen an. Kleine Releases liefern schnell Feedback. Einfaches Design vermeidet Überinvestitionen. Das Planning Game passt sich kontinuierlich an. Unsicherheit ist kein Problem – sie wird erwartet.

Wenn Ihre Anforderungen wirklich stabil und gut verstanden sind, funktioniert XP trotzdem, aber das Wertversprechen ist anders. Sie gewinnen Qualität und Teamgesundheit, aber die Vorteile der Anpassungsfähigkeit sind weniger ausgeprägt.

XP glänzt, wenn Code jahrelang leben wird. Die Investition in technische Praktiken zahlt sich im Laufe der Zeit aus.

Warum langlebige Systeme von XP profitieren:

• Tests: Fangen Regressionen ab, während sich das System weiterentwickelt
• Refactoring: Hält das Design sauber, während sich Anforderungen ändern
• Collective Ownership: Verteilt Wissen, wenn Teammitglieder kommen und gehen
• Einfaches Design: Vermeidet die Anhäufung von Komplexität
• CI: Erhält Integrationsdisziplin, während das Team wächst

Wenn Sie einen Prototyp bauen, der weggeworfen wird, zahlt sich XPs Investition in Qualität möglicherweise nicht aus. Aber die meisten „Prototypen" werden zu Produktionssystemen. Der meiste „temporäre" Code lebt jahrelang.

Die Wette: Gehen Sie davon aus, dass Ihr Code länger leben wird, als Sie denken. Investieren Sie von Anfang an in Qualität. Wenn Sie falsch liegen, haben Sie ein wenig Zeit verloren. Wenn Sie richtig liegen (und das sind Sie normalerweise), haben Sie sich Jahre voller Schmerzen erspart.

XP erfordert enge Zusammenarbeit. Pair Programming, Planning Games und Collective Ownership funktionieren nur, wenn Menschen gut zusammenarbeiten.

Anzeichen dafür, dass Ihr Team bereit ist:

• Menschen kommunizieren offen, auch über Probleme
• Es gibt Vertrauen zwischen Teammitgliedern
• Menschen helfen einander, ohne gefragt zu werden
• Meinungsverschiedenheiten werden konstruktiv gelöst
• Das Team hat psychologische Sicherheit

Wenn Ihrem Team diese Qualitäten fehlen, werden sich XP-Praktiken erzwungen und unangenehm anfühlen. Sie müssen möglicherweise zuerst die Teamgesundheit aufbauen, bevor Sie XP einführen – oder XP-Praktiken nutzen, um die Teamgesundheit schrittweise aufzubauen.

XP kann die Zusammenarbeit verbessern, aber es kann sie nicht erzwingen. Ein Team von Menschen, die keinen Code teilen wollen, wird nicht plötzlich Collective Ownership annehmen. Ein Team, das Angst hat, Fehler zuzugeben, wird nicht von Transparenz profitieren.

Die Kultur muss die Praktiken unterstützen – oder zumindest bereit sein, sich zu ändern.

XP erfordert einen verfügbaren Kunden – jemanden, der Fragen beantworten, Prioritätsentscheidungen treffen und Feedback geben kann.

Ohne Kundenverfügbarkeit:

• Entwickler raten bei Anforderungen (oft falsch)
• Prioritäten sind unklar (alles scheint wichtig)
• Feedback kommt zu spät (Features werden falsch gebaut)
• Das Planning Game kann nicht funktionieren

Kundenverfügbarkeit bedeutet:

• Fragen werden in Stunden beantwortet, nicht in Tagen
• Prioritätsentscheidungen werden getroffen, wenn sie gefragt werden
• Regelmäßiges Feedback zu gelieferter Arbeit
• Engagement im Planungsprozess

Wenn Ihre Kunden nicht verfügbar sind, wird XP schwierig. Sie können einen Product Owner als Stellvertreter einsetzen, aber jemand muss die Kundenrolle effektiv spielen.

Organisatorische Dysfunktion verhindert oft die Kundenverfügbarkeit. Der Kunde ist zu beschäftigt, zu politisch oder zu weit entfernt. Das sind organisatorische Probleme, die gelöst werden müssen, keine XP-Probleme.

Einige XP-Praktiken setzen moderne Softwareentwicklungskontexte voraus. Sie müssen möglicherweise in anderen Umgebungen angepasst werden.

TDD setzt voraus:

• Sie können automatisierte Tests schreiben (nicht alle Umgebungen unterstützen dies einfach)
• Tests laufen schnell (langsame Tests machen TDD schmerzhaft)
• Die Testkultur existiert (Team glaubt an Tests)

CI setzt voraus:

• Code kann häufig integriert werden
• Build und Test können automatisiert werden
• Trunk-basierte Entwicklung ist machbar

Pair Programming setzt voraus:

• Arbeit findet am Computer statt
• Zwei Personen können denselben Bildschirm sehen
• Die Arbeit profitiert von Echtzeit-Zusammenarbeit

In den meisten Softwareentwicklungen gelten diese Annahmen. Aber eingebettete Systeme, hardwareabhängiger Code oder stark regulierte Umgebungen erfordern möglicherweise Anpassungen der Praktiken.

Die Prinzipien bleiben. Die spezifischen Praktiken können sich ändern.