Suche

Extreme Programming: XP Revisited

Der extreme Ansatz: “All knobs to ten”

Das Adjektiv “extrem” in “Extreme Programming” leitet sich direkt aus dem Vorgehen im C3-Projekt ab. Die von Kent Beck dort ausgebrachte Parole lautete, “all knobs to ten” (alle Regler auf Maximum) zu drehen. Wenn etwas – eine entwicklungsnahe Vorgehensweise – gut erschien, dann trieb das Team sie auf die Spitze und führte sie mit extremer Intensität durch, beispielsweise:

  • “If testing is good, everybody will test all the time (unit testing), even the customers (functional testing)”
  • “If design is good, we’ll make it part of everybody’s daily business (refactoring)” usw.

Dieser Ansatz kennzeichnet einen großen Teil der XP-Techniken. So sind, auch nach eigener Aussage von Beck, die meisten XP-Techniken selbst nichts Neues, sondern eben nur in der extremen Anwendung und Kombination neu.

Zwölf Techniken

Mit den zwölf XP-Techniken (Practices) wird die Umsetzung von XP sehr konkret festgelegt. Im Kasten “XP-Techniken” gebe ich eine kurze Erläuterung zu jeder der Techniken. Fast alle Techniken haben einen Nutzen im Sinne der Rückkopplung.

XP-Techniken (klassisch) im Überblick
  • Planning Game: Der Kunde beschreibt Anforderungen in Form von Story Cards, die dann von Entwicklern geschätzt und wieder vom Kunden priorisiert werden. Der Kunde bestimmt die Stories für die jeweils nächste Iteration – im Rahmen der Kapazität des Teams, die auf Basis der in der Vergangenheit gemessenen Teamgeschwindigkeit errechnet wird (“Yesterday’s Weather Principle”).
  • Small Releases: Das Team erzeugt in möglichst kleinen, aber sinnvollen Abständen Releases der Software, um häufige Rückkopplung zu ermöglichen.
  • Metapher: Das Team charakterisiert die Software durch eine oder mehrere Metaphern (Beispiele: die Schreibtisch- und die Postkorb-Metapher).
  • Simple Design: Konstruiert wird stets die einfachste Lösung, die a) alle Tests besteht, b) die Absicht des Entwurfs kommuniziert und c) möglichst wenige Klassen und Methoden umfasst – “The simplest thing that could possibly work”.
  • Testing: Die Entwickler schreiben für jede Klasse einen Unit Test und praktizieren Test-driven Design.
  • Refactoring: Die Entwickler verbessern das Design des Systems entlang den Anforderungen im Wechsel von kleinschrittigem Refactoring und kleinen funktionalen Erweiterungen.
  • Pair Programming: Jeweils zwei Entwickler arbeiten für eine Aufgabe gemeinsam an einem Rechner und wechseln sich dabei an der Tastatur ab. Die Entwicklung erfolgt also mit “eingebautem” Peer Review. Diese Technik ist viel effizienter als man zunächst denkt. Die beiden Entwickler, die zusammen arbeiten müssen, werden oft zu Höchstleistungen angespornt und können sich kein “Durchhängen” leisten.
  • Collective Ownership: Alle Entwickler tragen Verantwortung für den gesamten Code. Alle Entwickler dürfen prinzipiell Änderungen an allen Teilen des Systems vornehmen. Eine Abstimmung mit den jeweiligen Know-how-Trägern wird dennoch empfohlen.
  • Continuous Integration: Die Entwickler checken neuen oder geänderten Code mindestens einmal am Tag wieder in ein zentrales Code Repository ein. Der Stand im Repository muss dabei stets kompilierbar bleiben, die automatischen Tests sollten keinen Fehler ausweisen. Auf der Integrationsmaschine läuft ein automatischer Build.
  • 40-Hour Week: Regelmäßig mehr als ≈40 Stunden pro Woche konzentriert zu arbeiten, ist nicht nachhaltig möglich. Das Team achtet darauf, dies nicht zu tun.
  • On-Site Customer: Der Kunde hat seinen Platz beim Entwicklungsteam, arbeitet eng mit ihm zusammen und steht ihm jederzeit für Rückfragen zur Verfügung.
  • Coding Standards: Das Team legt möglichst pragmatische Coding Standards fest und hält sie ein.

Die Techniken bilden darüber hinaus Cluster um bestimmte Themen:

  • Coding Standards, Continuous Integration und Testen sind primär für die Qualitätssicherung des Codes relevant.
  • Pair Programming und Collective Code Ownership fokussieren zusätzlich auf den Wissensaustausch und eine Kultur des wechselseitigen Reviews.
  • Die Techniken On-Site Customer, Small Releases, Planning Game sind entscheidend für die Projektsteuerung. In diesen Techniken wird unmissverständlich formuliert, dass XP ein Vorgehensmodell ist, das in Iterationen mit einer Länge von ein bis vier Wochen getaktet ist und dabei in jeder Iteration Anforderungsermittlung, Entwurf, Implementierung und Test betreibt. Anhand der Small Releases vollzieht sich dabei die zentrale Rückkopplung vom Kunden an das Entwicklungsteam.
  • Simple Design und Refactoring sind die Grundlage für Emergent Design (Design, das “im Prozess entsteht”).
  • Die Technik 40-Hour Week steht allein für ein nachhaltiges Arbeiten.
  • Metapher ist die einzige Technik, die von den XP-Projekten kaum angenommen und auch nicht verstanden wurde. In der überarbeiteten Version von XP aus dem Jahr 2004 ist diese Technik sogar ersatzlos gestrichen wurde.

Eine wichtige Eigenschaft der Gesamtheit der XP-Techniken ist, dass sie einander gegenseitig unterstützen: Beispielsweise ermöglicht Refactoring, die mit Simple Design geschaffenen, einfachen Architekturen bedarfsgerecht weiter zu entwickeln, und automatisierte Tests sichern wiederum das Refactoring ab. Dies sind nur zwei von vielen vergleichbaren Beziehungen zwischen den XP-Techniken.

Kommentare

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>