Die Techniken des XP

Folgende Techniken finden in XP Verwendung:

• Planungsspiel

• Kleine Releases

• Systemmetapher

• Einfaches Design

• Pair-Programming

• Refactoring

• Ständiges Testen

• Collective Code-Ownership

• Vor-Ort-Kunde

• Programmierrichtlinien

• 40 Stunden Woche

• Ständige Integration

Planungsspiel: Im Planungsspiel werden die verfügbaren Entwicklerressourcen mit den Kundenwünschen in Einklang gebracht. Hier wird entschieden, welche Funktionalität als nächstes umgesetzt wird. Funktionen sind dabei als "User Story" beschrieben und werden priorisiert. Die Entwickler schätzen den Aufwand für die User Stories. Auf dieser Basis wird entschieden, welche Funktionen neu umzusetzen sind.

Kleine Releases: Beginne mit dem kleinsten sinnvollen Funktionsumfang. Liefere früh und häufig aus und ergänze jedes Mal neue Funktionen.

Systemmetapher: Unter der Systemmetapher wird die Grundarchitektur des Systems verstanden. Gemeint ist das Gesamtbild, das alle Entwickler vor Augen haben. Alle Entwickler kennen nicht nur den Teilbereich oder das Subsystem, an dem sie selbst arbeiten, sondern auch das Gesamtziel und die Grundarchitektur, die das System bestimmen.

Einfaches Design: Es wird immer das einfachst mögliche Design, das die aktuellen Anforderungen abdeckt, gewählt. Die Anforderungen ändern sich täglich, darum sollte man heute nichts machen, was man vielleicht morgen benötigen könnte.

Pair-Programming: Zwei Entwickler arbeiten zusammen an einem Rechner. Dabei ist der eine der "Driver", also derjenige, der entwickelt, und der andere der "Follower", der seine Überlegungen mit einfließen lässt. Diese Rollen werden ständig getauscht. Dadurch findet parallel zur Entwicklung ein Review des Codes statt.

Refactoring: Durch ein Refactoring wird die interne Struktur des Programms verbessert, ohne sein Verhalten oder die Funktionalität zu ändern.

Ständiges Testen: Bevor ein Entwickler eine neue Funktion implementiert schreibt er zunächst einen Test dafür ("Test first"). Typischerweise handelt es sich dabei um Unittests. Diese Unittests werden zu Test-Suiten zusammengefasst, die nach jeder Integration automatisch ablaufen.

Collective Code-Ownership: Der Sourcecode gehört dem ganzen Team. Jeder Entwickler sollte jederzeit jede Stelle des Codes bearbeiten können.

Vor-Ort-Kunde:

Das Entwicklungsteam arbeitet beim Kunden vor Ort. Dadurch ist eine intensive Zusammenarbeit und Kommunikation möglich. Ebenso erhalten die Entwickler schnell Feedback zu den bereitgestellten Releases.

Programmierrichtlinien: Die vorgegebenen Programmierrichtlinien (zum Beispiel Namenskonventionen) müssen von allen eingehalten werden. Dadurch wird der Sourcecode einheitlicher, was es einfacher macht, dass alle Entwickler überall arbeiten können.

40 Stunden Woche:

Überstunden verringern auf Dauer die Motivation und die Leistungsfähigkeit der Entwickler. In Ausnahmesituationen sind Überstunden erlaubt. Handelt es sich allerdings um einen Dauerzustand, ist mit dem Prozess etwas nicht in Ordnung.

Ständige Integration:

Alle Änderungen werden mindestens einmal täglich in die Codebasis eingespielt. Die Tests müssen sowohl vor als auch nach der Integration vollständig und fehlerfrei laufen.