Einführung in eXtreme Programming

eXtreme Programming, XP

eXtreme Programming wurde von Kent Beck, Ward Cunningham und Ron Jeffries während ihrer gemeinsamen Arbeit an einem Softwareprojekt bei Chrysler zwischen 1995 und 2000 entwickelt. 

XP …

  • ist ein agiles Framework zur hochwertigen Softwareentwicklung
  • öffnet verschränkte Feedback-Loops für die ständige Verbesserung und gemeinsames Lernen
  • bietet 5 Werte, 14 Prinzipien und 12 Praktiken an

Funktionierende XP-Teams arbeiten gemeinsam und in hoher psychologischer Sicherheit und wechselseitigem Vertrauen in die individuelle Fähigkeiten.

Die Abbildung zeigt die drei Autoren blau markiert in der Gruppe der siebzehn Erstunterzeichner des Agilen Manifest.

Die Autoren von XP im Kreise der Erstunterzeichner des Agilen Manifest

XP war radikal neu und zeigte sich als wirksam. Um 2000 begann eine atemberaubende Adoptionskurve, ein Hype.

Es werden zwölf Praktiken vorgeschlagen, mit denen die Programmierung von Software mit mehreren Entwicklern besser geschehen kann. Die eingeführten Rollen sind denen in Scrum ähnlich.
 
Diese Praktiken wurden breit angenommen, die meisten bilden heute den Grundkonsens für Agile Softwareentwicklung:
  • Pair Programming
  • Test Driven Development
  • Continuous Integration
  • Coding Standards
  • Refactoring
  • schnelles Nutzerfeedback

Auf einem Wimmelbild: die XP Werte, Praktiken und Prinzipien:

Die sich wiederholenden Schleifen aus Planung, Implementierung, Test und Feedback gehen bei XP bis auf die Ebene des Pair Programming: XP integriert Planung, Feedback und Entwicklung.

XP Praktiken

Pair Programming

Zwei Entwickler sitzen vor einem Bildschirm und arbeiten gemeinsam, der “Driver” und der “Pilot”. Der Pilot schreibt Code, der Pilot denkt mit und denkt voraus, z.B. schlägt Informationen nach, überprüft Querbeziehungen und Abhängigkeiten. Beide sprechen über ihre Beobachtungen, diskutieren Lösungen und denken so gemeinsam an einem Problem. Die Rollen werden regelmäßig getauscht.

Durch das gemeinsame Arbeiten und offenes Denken entsteht Wissenstransfer und Lernen, der Code wird robuster. Im Vier-Augen-Verfahren geschieht kontinuierlicher Codereview.

Test Driven Development, TDD

Vor der Implementierung von Funktionalität wird ein Test geschrieben. Das Feature wird so programmiert, dass der Test erfolgreich durchlaufen wird. Es wird ‘gegen den Test programmiert’.

Der Effekt ist eine Konzentration auf das Wesentliche und ein durch stetiges Refactoring gut pflegbarer Code. 

Wenn die Testfälle aus vielen Features automatisch als Regressionstest fungieren, entsteht so ein Software-System, das sich bei Fehlern robust verhalten wird. Jeder Bestandteil ist in sich schlüssig und funktionierend.

Continuous Integration, CI

Ständige Integration bedeutet, dass nicht z.B. einmal monatlich alle in den letzten vier Wochen von allen Entwicklern programmierten Features in ihrem Zusammenspiel geprüft werden — sondern ständig. Wird Code produziert, dann ist bereits getestet, die koninuierliche Integration stellt damit sofort fest, wenn im Zusammenspiel von Features andere Reibungen entstehen, die zuvor nicht bedacht wurden. Diese werden sofort korrigiert, so dass jederzeit lauffähige Software zur Verfügung steht.

So wird eine hohe Routine erreicht. Die Integration von neuem Code wird zu einem täglichen, stabilen und vollautomatisierten Schritt.

Coding Standards

Das Entwicklungsteam hält sich an gemeinsam gesetzte und getragene Standards.

Entwickler können so in allen Bereichen der Softwareentwicklung am Produkt arbeiten, nicht nur in ihrem Spezialbereich.

Refactoring

Refactoring ist die manuelle oder automatisierte Strukturverbesserung von Architektur, Design und Code ohne Änderung der Eigenschaften des Features. Die strukturelle und syntaktische Qualität wird laufend gesichtet und optimiert.

Erreicht wird so eine bessere Lesbarkeit und Verständlichkeit des Code, bessere Pflegbarkeit und Erweiterbarkeit. Aufwände für Fehleranalysen und funktionalen Erweiterungen sinken mit sauberem Code deutlich. Software wird so robust und kann schneller operativ gestellt werden. 

Der ROI (return on investment) kann schneller erreicht werden. Refactoring geschieht in ständigem Wechsel mit Neuerstellung von Code, die Entwickler tragen immer einen von Kent Back’s “zwei Hüten”:

  • Neue Funktionalitit erstellen: einen Test schreiben und dann den Produktivcode schreiben, der die durch den Test definierte Funktionalität implementiert, bis der Test und alle bisherigen Tests erfolgreich laufen – zunächst mit so wenig Aufwand wie möglich
  • Refactoring: Verbesserungen, das Auffinden von Redundanzen, wobei die Tests bei jedem Zwischen schritt erfolgreich bleiben müssen.

Der Effekt des ständigen Refactoring ist eine gleichbleibend gute Codebase und Komplexitätsreduktion.