XP-Prinzipien

Werte sagen dir, was wichtig ist. Praktiken sagen dir, was zu tun ist. Aber wie verbindet man sie? Hier kommen Prinzipien ins Spiel.

Prinzipien sind die Brücke. Sie sind konkreter als Werte, aber abstrakter als Praktiken. Wenn du entscheidest, ob du eine Praktik übernimmst oder sie für deinen Kontext anpasst, geben Prinzipien die Richtung vor.

XP hat viele Prinzipien, aber wir konzentrieren uns auf die wichtigsten.

Software wird von Menschen für Menschen gemacht.

Dieses Prinzip erinnert uns daran, dass Entwickler keine austauschbaren Ressourcen sind. Menschen haben Bedürfnisse:

• Sicherheit (physisch und psychologisch)
• Erfüllung (sinnvolle Arbeit leisten)
• Zugehörigkeit (Teil eines Teams sein)
• Wachstum (lernen und sich verbessern)
• Nähe (enge, vertrauensvolle Beziehungen)

XP-Praktiken sollten diese Bedürfnisse erfüllen. Pair Programming erfüllt Bedürfnisse nach Zugehörigkeit und Nähe. Testgetriebene Entwicklung erfüllt Bedürfnisse nach Erfüllung und Sicherheit. Nachhaltiges Tempo schützt physische und mentale Gesundheit.

Wenn sich eine Praktik falsch anfühlt, frage: „Verletzt dies menschliche Bedürfnisse?"

Geld zählt. Zeit hat einen Wert. Optionen haben einen Wert.

XP nimmt Wirtschaftlichkeit ernst:

• Zeitwert des Geldes: Ein heute geliefertes Feature ist mehr wert als dasselbe Feature in sechs Monaten
• Optionen: Wahlmöglichkeiten offen zu halten hat einen Wert (daher die Vermeidung von Über-Verpflichtung)
• Kosten der Verzögerung: Das Warten auf die Lieferung von Wert hat reale Kosten

Dieses Prinzip unterstützt kleine Releases (Wert früh liefern), inkrementelles Design (nicht im Voraus überinvestieren) und iterative Planung (auf das reagieren, was man lernt).

Es unterstützt auch nachhaltiges Tempo: erschöpfte Entwickler machen teure Fehler.

Jede Praktik sollte allen Beteiligten nutzen.

Die besten XP-Praktiken sind Win-Win-Win:

• Tests helfen dem Entwickler (Vertrauen), dem Team (Dokumentation) und zukünftigen Entwicklern (Sicherheitsnetz)
• Pair Programming hilft beiden Partnern (Lernen, Fehler erkennen) und dem Code (Qualität)
• Einfacher Code hilft dem Autor (schneller zu schreiben) und Lesern (leichter zu verstehen)

Vermeide Praktiken, die einer Gruppe auf Kosten einer anderen helfen. Dokumentation, die nur für Compliance geschrieben wird und nie von Entwicklern gelesen wird, verfehlt gegenseitigen Nutzen. Code, der geschrieben wird, um clever statt klar zu sein, verfehlt ihn ebenfalls.

Wenn eine Praktik Unmut erzeugt, verletzt sie wahrscheinlich den gegenseitigen Nutzen.

Muster, die auf einer Ebene funktionieren, funktionieren oft auch auf anderen.

XP wendet dieselben Muster auf verschiedenen Ebenen an:

• Rot-Grün-Refaktorieren (Tests): Zum Scheitern bringen, zum Laufen bringen, sauber machen
• Planen-Tun-Prüfen-Handeln (Iterationen): Die Arbeit planen, die Arbeit tun, die Ergebnisse prüfen, anpassen
• Sammeln-Gruppieren-Abstimmen (Retros): Daten sammeln, Muster finden, Maßnahmen beschließen

Wenn du etwas findest, das funktioniert, probiere es auf verschiedenen Ebenen aus. Das Planning Game funktioniert für Release-Planung und Iterationsplanung. Code-Review-Prinzipien funktionieren für Design-Review und Architektur-Review.

Beginne dort, wo du bist, und werde kontinuierlich besser.

XP verlangt nicht von Tag eins an Perfektion. Es verlangt Bewegung. Beginne mit dem, was du heute tun kannst, und verbessere dich von dort aus.

• Keine Tests? Schreibe einen Test für den nächsten Bug, den du behebst.
• Kein Pair Programming? Probiere es morgen für eine Stunde aus.
• Keine Continuous Integration? Committe häufiger.

Das Ziel ist nicht, „XP zu machen". Das Ziel ist, sich zu verbessern. XP ist eine Richtung, kein Ziel.

Dieses Prinzip unterstützt auch sicheres Scheitern. Experimente, die nicht funktionieren, sind Lernmöglichkeiten, keine Misserfolge.

Liefere Wert kontinuierlich, nicht in großen Chargen.

Dieses Prinzip bringt XP mit Lean Thinking und Kanban in Einklang. Große Chargen verbergen Probleme. Kleine Chargen bringen sie schnell ans Licht.

• Kleine Stories (Tage, nicht Wochen)
• Häufige Releases (wöchentlich, nicht quartalsweise)
• Continuous Integration (Stunden, nicht Tage)
• Sofortiges Testen (Sekunden, nicht Stunden)

Flow reduziert laufende Arbeit, was Kontextwechsel reduziert, was Fokus und Qualität verbessert. Es gibt Kunden auch früher Wert und schneller Feedback.

Qualität ist nicht verhandelbar.

Das scheint offensichtlich, aber die Implikationen sind tiefgreifend. XP sagt, du kannst Umfang oder Zeitplan verhandeln, aber niemals Qualität.

Das bedeutet:

• Tests sind nicht optional, wenn die Zeit knapp ist
• Refaktorieren ist kein Luxus
• Technische Schulden sind nicht akzeptabel
• „Jetzt ausliefern, später reparieren" ist kein Plan

Warum? Weil Qualität die Grundlage für Geschwindigkeit ist. Schlechte Qualität erzeugt Bugs, die dich verlangsamen. Schlechte Qualität erzeugt Code, der schwer zu ändern ist. Schlechte Qualität erzeugt Systeme, die teuer zu warten sind.

Qualität ist der schnellste Weg, schnell zu sein.

Mache den kleinsten Schritt, der Fortschritt bringt.

Große Änderungen sind riskant. Kleine Änderungen sind sicher. XP bevorzugt immer kleine Schritte:

• Schreibe einen fehlschlagenden Test, bevor du Code schreibst
• Refaktoriere eine Sache nach der anderen
• Integriere nach kleinen Änderungen, nicht nach großen
• Release kleine Inkremente, nicht große Releases

Kleine Schritte bedeuten nicht langsamen Fortschritt. Tausend kleine Schritte können mehr Strecke zurücklegen als zehn große Sprünge – und mit geringerer Sturzgefahr.

Wenn du feststeckst, frage: „Was ist das Kleinste, das ich jetzt tun kann, um Fortschritt zu machen?"