XP-Praktiken Zwölf Techniken für Code, der hält

XP ist nicht nur eine Philosophie — es ist ein Werkzeugkasten. Zwölf Praktiken bilden den Kern, und jede einzelne verstärkt die anderen. Das Besondere: Keine dieser Praktiken ist wirklich neu. Code-Reviews, Tests, kurze Releases — alles bekannt. XP dreht sie nur konsequent auf Maximum und kombiniert sie so, dass sie sich gegenseitig absichern.

XP-Praktiken auf einen Blick

Anzahl
12 Kernpraktiken (+ ergänzende Praktiken)
Prinzip
Einzeln nützlich, zusammen stark
Kategorien
Programmierung, Team, Planung, Integration
Besonderheit
Alle Praktiken hängen zusammen wie ein Sicherheitsnetz

Welche Praktiken gehören zu XP?

Kent Beck hat die XP-Praktiken in seiner ersten Auflage von „Extreme Programming Explained" definiert. Hier sind die zwölf Kernpraktiken — aufgeteilt in vier Bereiche:

Programmierung • Pair Programming • Test-Driven Development (TDD) • Refactoring • Einfaches Design Integration • Continuous Integration • Collective Code Ownership • Coding Standards Team • Gemeinsamer Kunde vor Ort • Metapher (gemeinsame Sprache) • Nachhaltige Geschwindigkeit Planung • Planning Game • Kleine Releases
Die 12 XP-Praktiken — aufgeteilt in vier Kategorien

Programmierung: Pair Programming, TDD, Refactoring und einfaches Design bilden den technischen Kern. Sie sorgen dafür, dass der Code sauber bleibt — auch unter Zeitdruck.

Integration: Continuous Integration, gemeinsamer Codebesitz und einheitliche Standards verhindern, dass das Team in Silos arbeitet. Jeder kann jeden Code anfassen und verbessern.

Team: Ein Kunde vor Ort beantwortet Fragen sofort. Eine gemeinsame Metapher gibt dem System einen Namen, den alle verstehen. Und nachhaltige Geschwindigkeit bedeutet: Keine Überstunden — weil müde Entwickler schlechten Code schreiben.

Planung: Das Planning Game bringt Entwickler und Kunden zusammen, um Aufgaben zu schätzen und zu priorisieren. Kleine Releases sorgen dafür, dass der Kunde früh echte Software in der Hand hat — nicht erst nach sechs Monaten.

Warum funktionieren die Praktiken nur zusammen?

Jede Praktik hat eine Schwäche — die eine andere Praktik abfängt. Ein paar Beispiele:

  • Refactoring ohne Tests? Gefährlich. TDD liefert das Sicherheitsnetz, das mutiges Refactoring erst möglich macht.
  • Collective Code Ownership ohne Coding Standards? Chaos. Wenn jeder anders formatiert, wird gemeinsamer Code zum Albtraum.
  • Kleine Releases ohne Continuous Integration? Unmöglich. Ohne automatisierten Build kannst du nicht mehrfach pro Woche deployen.
  • Pair Programming ohne Respekt? Eine Qual. Nur wenn sich beide Partner ernst nehmen, entsteht besserer Code statt Frust.

Kent Beck vergleicht es mit einem Seil: Einzelne Fasern sind schwach. Zusammengedreht halten sie Tonnen.

Wie fängst du an, ohne alles auf einmal einzuführen?

Die gute Nachricht: Du musst nicht alle zwölf Praktiken gleichzeitig starten. Die meisten Teams beginnen mit drei Einstiegspraktiken:

  1. TDD: Sofort messbarer Effekt auf Codequalität und Vertrauen ins eigene Produkt.
  2. Continuous Integration: Technisch einfach aufzusetzen, riesiger Nutzen für die Teamkoordination.
  3. Pair Programming: Erfordert Überwindung, bringt aber den schnellsten Wissenstransfer.

Wenn diese drei laufen, kommen Refactoring und Coding Standards fast von selbst. Die Planungspraktiken ergänzt du, sobald das Team den Rhythmus gefunden hat. Wichtig ist: Starte nicht mit allem — aber bleib nicht bei einer Praktik stehen. Die Stärke liegt in der Kombination.