Die XP-Praktiken: Ein Überblick

XP ist keine Speisekarte, bei der Sie Ihre Favoriten auswählen. Die Praktiken sind so konzipiert, dass sie sich gegenseitig verstärken. Entfernen Sie eine, und die anderen werden schwieriger oder weniger effektiv.

Zum Beispiel:

• Refactoring ist sicher, weil Sie umfassende Tests haben
• Einfaches Design ist möglich, weil Sie refactorn können, wenn sich Anforderungen ändern
• Collective Ownership funktioniert, weil Sie Coding Standards haben
• Continuous Integration ist machbar, weil Sie kleine Releases und Tests haben

Diese Verflechtung ist der Grund, warum „TDD machen, aber nicht refactorn" oder „Pair Programming ohne Tests" oft scheitert. Sie entfernen eine tragende Wand.

Allerdings müssen Sie irgendwo anfangen. Wir werden die schrittweise Einführung in Modul 5 besprechen.

Dies sind die Kernpraktiken, die die meisten XP-Teams übernehmen:

Planungspraktiken:

• User Stories: Anforderungen als Gesprächsanstöße
• Planning Game: Das Business wählt was, Entwickler wählen wie
• Kleine Releases: Häufig Wert liefern
• Iterationsplanung: Stories in Aufgaben für jede Iteration aufteilen

Entwicklungspraktiken:

• Test-Driven Development (TDD): Schreiben Sie zuerst den Test
• Pair Programming: Zwei Entwickler, eine Tastatur
• Refactoring: Code verbessern, ohne das Verhalten zu ändern
• Einfaches Design: Das Einfachste, das funktioniert
• Continuous Integration: Viele Male am Tag integrieren und testen

Teampraktiken:

• Ganzes Team: Alle, die für die Lieferung benötigt werden, in einem Raum
• Collective Code Ownership: Jeder kann jeden Code ändern
• Coding Standards: Vereinbarte Code-Konventionen
• Nachhaltiges Tempo: Keine Überstunden als Regel

Wir werden jede davon in den folgenden Modulen ausführlich behandeln.

Diese Praktiken sind wirkungsvoll, erfordern aber mehr Reife oder spezifische Bedingungen:

• Echte Kundeneinbindung: Der tatsächliche Kunde, nicht nur ein Stellvertreter
• Ursachenanalyse: Das System beheben, nicht nur das Symptom
• Gemeinsamer Code: Aller Code ist für alle Entwickler sichtbar
• Code und Tests: Code und Tests sind die einzigen dauerhaften Artefakte
• Einzelne Codebasis: Ein Branch, nicht viele
• Tägliches Deployment: Jeden Tag in Produktion deployen
• Verhandelbarer Umfangsvertrag: Verträge, die Veränderung begrüßen
• Pay-Per-Use: Direktes Feedback von echten Kunden

Dies sind nicht „fortgeschrittenes XP". Es sind Praktiken, die im richtigen Kontext gut funktionieren, aber in anderen unangemessen oder unmöglich sein könnten.

Eine Möglichkeit, XP-Praktiken zu verstehen, ist durch ihre Feedback-Schleifen:

Sekunden: Unit Tests Minuten: Pair Programming Stunden: Continuous Integration Tag: Standup Woche: Iterationsplanung, Kundendemo Monat/Quartal: Release, Retrospektive

Auf jeder Ebene schafft XP Gelegenheiten zum Lernen und Anpassen. Das ist beabsichtigt. Je schneller Sie lernen, desto schneller können Sie den Kurs korrigieren.

Wenn Sie nicht auf jeder dieser Ebenen Feedback erhalten, fehlt etwas.

Das mag überwältigend erscheinen. Versuchen Sie nicht, alles auf einmal einzuführen.

Die meisten Teams beginnen mit:

1. TDD oder zumindest dem Schreiben von Tests
2. Continuous Integration
3. Iterationen (oder Sprints bei Verwendung von Scrum)
4. Retrospektiven

Diese bilden das Fundament. Sobald sie funktionieren, fügen Sie hinzu:

• Pair Programming (beginnen Sie nur bei schwierigen Problemen)
• Refactoring (beginnen Sie mit dem unordentlichsten Code)
• Kleine Releases (beginnen Sie damit, häufiger zu releasen)

Wir werden Einführungsstrategien in Modul 5 behandeln. Verstehen Sie vorerst einfach die Landschaft.