Extreme Programming (XP) — Agile Engineering-Praktiken für Software
Wenn Code-Qualität nicht verhandelbar ist — Engineering-First-Agile
Extreme Programming ist eine agile Software-Methode mit Fokus auf technische Exzellenz: Pair Programming, Test-Driven Development, Continuous Integration und Refactoring.
Über Extreme Programming (XP)
Extreme Programming wurde 1996 von Kent Beck entwickelt und ist die radikalste der agilen Methoden für Software-Entwicklung. Während Scrum primär Prozess-Framework ist, definiert XP konkrete Engineering-Praktiken: Pair Programming (zwei Entwickler an einem Computer), Test-Driven Development (TDD — erst Test schreiben, dann Code), Continuous Integration (jeder Commit triggert Build und Test), Refactoring (kontinuierliche Code-Verbesserung), Simple Design (KISS-Prinzip) und Collective Code Ownership (jeder darf jeden Code ändern). Iterationen sind kurz (1-2 Wochen). XP ist besonders einflussreich in der Tech-Community und hat Praktiken wie TDD und CI in den Mainstream gebracht — auch wenn die volle Methode heute seltener komplett eingesetzt wird.
Herkunft
Kent Beck bei Chrysler C3 Projekt, 1996. Buch 'Extreme Programming Explained' 1999. Aktuell: zweite Edition 2004 mit erweiterten Praktiken.
Prinzipien
Pair Programming
Zwei Entwickler arbeiten an einem Computer. Einer schreibt, der andere reviewt in Echtzeit. Reduziert Bugs um 15-50 Prozent, erhöht Wissens-Transfer drastisch.
Test-Driven Development (TDD)
Zuerst den Test schreiben, dann den Code der ihn besteht. Red-Green-Refactor-Zyklus. Code-Coverage typisch über 90 Prozent.
Continuous Integration
Jeder Code-Commit triggert automatischen Build und Test. Integration-Probleme werden sofort sichtbar.
Refactoring
Code wird kontinuierlich verbessert ohne neue Features hinzuzufügen. Technische Schuld wird laufend abgebaut.
Simple Design
Einfachste mögliche Lösung — YAGNI (You Ain't Gonna Need It). Komplexität nur wenn wirklich nötig.
Collective Code Ownership
Jeder Entwickler darf jeden Code ändern. Kein 'das ist mein Code'-Denken.
Wann Extreme Programming (XP) passt — und wann nicht
Passt für:
- Software-Entwicklungs-Teams mit hoher Code-Qualitäts-Ansprüchen
- Teams die TDD und Pair Programming praktizieren wollen
- Startups und Scale-Ups mit kleinen, hochqualifizierten Teams
- Open-Source-Projekte mit verteilten Maintainern
- Legacy-Code-Refactoring-Projekte
Nicht ideal für:
- Hardware-Projekte oder nicht-Software-Domänen
- Sehr grosse Teams (XP skaliert nicht über 12-15 Entwickler)
- Regulierte Umgebungen mit umfangreichen Dokumentations-Pflichten
Extreme Programming (XP) im Vergleich zu anderen Methoden
vs Scrum
Scrum ist Prozess-Framework ohne Engineering-Praktiken. XP definiert konkrete Engineering-Disziplinen. Viele Teams kombinieren beide (Scrum-Prozess + XP-Engineering).
vs Kanban
Kanban ist Workflow-Visualisierung. XP geht tiefer in Programmier-Praktiken.
vs Wasserfall
XP ist radikal iterativ (1-2 Wochen), Wasserfall sequenziell (Monate). XP hat keine Big Design Up Front.
Wie Flenio Extreme Programming (XP) unterstützt
Flenio integriert XP-Praktiken: GitHub-Webhook für CI-Trigger, Code-Review-Workflows mit Pair-Annotations, Velocity-Tracking pro Story-Point, TDD-Status pro Task (Test geschrieben, grün, refactored), Refactoring-Backlog separat von Feature-Backlog.
Häufige Fragen zu Extreme Programming (XP)
Ist Pair Programming nicht ineffizient?
Studien zeigen das Gegenteil: Pair Programming reduziert Bugs um 15-50 Prozent und Knowledge-Silos drastisch. Die kurzfristig doppelte Personen-Stunde wird langfristig durch weniger Bugs und besseren Wissens-Transfer überkompensiert.
Funktioniert XP auch in Remote-Teams?
Ja, aber anders. Remote Pair Programming via VS Code Live Share, JetBrains Code With Me oder Tuple ist heute Standard. Mob Programming (mehr als 2 Personen) ist Remote ebenfalls möglich.
Was kostet eine XP-Einführung?
Wenig in Software, viel in Mindset. TDD-Schulung kostet typisch CHF 2'000 pro Entwickler. Größerer Aufwand: Team-Kultur-Wandel zu Pair Programming und Collective Ownership.
Andere Methoden
HERMES 2022
Schweizer Standard für öffentliche und IT-getriebene Projekte
SIA-Phasenmodell
Schweizer Norm für Architektur- und Bauprojekte
Scrum
Iterativ, transparent, empirisch — das agile Framework Nr. 1
Kanban
Pull-System statt Push — Arbeit fliesst durch das System
Agile
Werte statt Prozesse — Iteration statt grosser Pläne
Wasserfall
Sequenziell, geplant, dokumentiert — der klassische Ansatz