Katalog
concept#Software Engineering#Lieferung#Produkt

Extreme Programming (XP)

Agile Software-Entwicklungsmethode mit Fokus auf technische Exzellenz, Kundennähe und iteratives Feedback.

Extreme Programming (XP) ist ein leichtgewichtiges, teamzentriertes Entwicklungsparadigma, das kurze Iterationen, kontinuierliche Integration und enge Zusammenarbeit mit dem Kunden betont.
Etabliert
Mittel

Klassifikation

  • Mittel
  • Organisatorisch
  • Organisation
  • Fortgeschritten

Technischer Kontext

CI/CD-Tools (z. B. Jenkins, GitHub Actions)Versionskontrolle (z. B. Git)Issue-Tracker und Backlog-Tools (z. B. Jira)

Prinzipien & Ziele

Kurze Iterationen und schnelles FeedbackTechnische Exzellenz durch Tests und RefactoringEnge Zusammenarbeit mit dem Kunden
Iteration
Domäne, Team

Use Cases & Szenarien

Kompromisse

  • Übermäßiger Fokus auf Teampraktiken ohne strategische Ausrichtung
  • Unzureichende Architekturpflege bei kurzem Iterationsfokus
  • Abhängigkeit von Schlüsselpersonen trotz Pairing-Versuchen
  • Priorisiere kleine, wertorientierte Stories
  • Automatisiere Tests und Integration frühzeitig
  • Pflege gemeinsame Definitionen von Done und Qualität

I/O & Ressourcen

  • Produkt-Backlog mit priorisierten Stories
  • CI/CD-Pipeline mit automatisierten Tests
  • Routinen für Kundenfeedback und Reviews
  • Regelmäßige, getestete Releases
  • Verbesserte Codequalität und geringer technischer Rückstand
  • Schnelles Nutzerfeedback und Validierung

Beschreibung

Extreme Programming (XP) ist ein leichtgewichtiges, teamzentriertes Entwicklungsparadigma, das kurze Iterationen, kontinuierliche Integration und enge Zusammenarbeit mit dem Kunden betont. Es kombiniert konkrete Praktiken wie Pair Programming und Test-First-Entwicklung, um Qualität und Anpassungsfähigkeit in wechselnden Anforderungen zu sichern.

  • Höhere Qualität durch TDD und Pair Programming
  • Schnellere Reaktion auf geänderte Anforderungen
  • Verbesserte Wissensverteilung im Team

  • Benötigt disziplinierte Teams und stabile Kundenverfügbarkeit
  • Skalierung über viele Teams erfordert zusätzliche Koordination
  • Nicht immer geeignet für stark regulierte Umgebungen ohne Adaptionsspielraum

  • Durchschnittliche Zykluszeit

    Zeit von Anforderung bis zur Auslieferung eines Inkrements.

  • Testabdeckungsrate

    Prozentsatz des Codes, der durch automatisierte Tests abgedeckt ist.

  • Fehlerdichte nach Release

    Anzahl der Fehler pro ausgeliefertem Funktionsumfang nach Release.

Early XP-Projekte (Beispielfirma)

Fallstudien aus frühen XP-Einführungen zeigen erhöhte Lieferqualität bei kurzen Iterationen.

TDD-Einführung in Produktteams

Teams berichten von weniger Regressionen und höherem Vertrauen in Releases nach TDD-Umsetzung.

Pair Programming zur Wissensverteilung

Pair Programming reduzierte Einarbeitungszeiten und erhöhte Codequalität in mehreren Teams.

1

Start mit Pilotteam: Schulung in TDD und Pair Programming

2

Aufbau einer CI/CD-Pipeline und Basis-Test-Suite

3

Iterative Erweiterung der Praktiken auf weitere Teams und Refactoring-Routine etablieren

⚠️ Technische Schulden & Engpässe

  • Unzureichend refaktorierte Codebasen nach schneller Entwicklung
  • Überlastete Test-Suites ohne strategische Pflege
  • Fragmentierte Build- und Deployment-Pipelines
Mangelnde TestinfrastrukturUnklare ProduktpriorisierungFehlende Kundenverfügbarkeit
  • XP-Praktiken eingeführt, aber Produktpriorisierung fehlt
  • Nur tägliche Rituale, keine echte Kundenintegration
  • Vernachlässigung der Architektur bei verkürzten Iterationen
  • Fokus auf Geschwindigkeit statt auf nachhaltige Qualität
  • Unterschätzung des Aufwands für Testwartung
  • Fehlende Unterstützung durch Management bei notwendigen Änderungen
Erfahrung mit Test-Driven DevelopmentFähigkeit zum Paarprogrammieren und kollegialen ReviewKenntnis kontinuierlicher Integration und Deployment
Testbarkeit der KomponentenModularität zur Erleichterung von RefactoringSchnelle Integrationszyklen
  • Regulatorische Anforderungen können Iterationen verlängern
  • Budgetbegrenzungen für Automatisierung
  • Organisatorische Widerstände gegen Pairing oder TDD