Was ist Extreme Programming?

Extreme Programming, kurz XP genannt, ist eine neue Art der Softwareentwicklung. XP liegt ein Wertesystem zugrunde, dass essentiell für das Verständnis von XP ist. Auch andere agile Methoden, z.B. Crystal oder Scrum verwenden dieses oder ein ähnliches Wertesystem.

Um zu erklären was XP ist, möchte ich einen typischen Releasezyklus beschreiben.

Benutzergeschichten

Zu Beginn werden die Kundenanforderungen in Zusammenarbeit mit dem Kunden in Benutzergeschichten erfasst.

Akzeptanztests

Zu jeder Benutzergeschichte gibt es einen oder mehrere Akzeptanztests, die der Kunde definiert. Diese Akzeptanztests dienen dem XP-Team und dem Kunden zu entscheiden, ob eine Benutzergeschichte korrekt implementiert worden ist.

Als nächstes schätzt das XP-Team den Aufwand für jede Benutzergeschichte. Manchmal ist dies nicht möglich, weil Informationen fehlen. Dann wird der Kunde befragt. Manchmal ist die Abschätzung nicht möglich, weil eventuell ein Softwareproblem so noch nicht implementiert wurde und deshalb keine Erfahrungswerte existieren. In diesem Falle wird ein Prototyp gemacht, manchmal auch mehrere, wenn mehrere Implementierungsalternative bestehen.

Planungsspiel

Nachdem nun bekannt ist, welcher Aufwand hinter welcher Benutzergeschichte steckt, wird ein Planungsspiel gemacht. Der Kunde bringt in das Spiel sein Wissen um den Nutzwert jeder einzelnen Benutzergeschichte ein. Festgelegt ist der zeitliche Rahmen, die zur Verfügung stehenden Resourcen (Programmierer) sowie die Qualität. Was bleibt, ist die Festlegung des Funktionsumfangs.

Der zeitliche Rahmen für einen Releasezyklus sind typischerweise 3 bis 4 Monate. Der Kunde wählt nun Benutzergeschichten aus, die in das Release eingehen sollen. Dabei kann er nur soviele Benutzergeschichten auswählen, daß die Summe aller Aufwände nicht größer ist als die Entwicklungskapazität, die für den Releasezyklus zur Verfügung steht. Im Regelfall wird der Kunde daher diejenigen Benutzergeschichten wählen, die für ihn den größten Nutzwert darstellen.

Iterationen

Das Release wird nun in mehreren Iterationen zu je zwei bis drei Wochen erarbeitet. Das XP-Team wählt jeweils am Beginn der Iteration Benutzergeschichten. Für jede dieser Geschichten überlegt sich das Team, welche Aufgaben dazu erledigt werden müssen. Eine Aufgabe erfordert typischerweise einen Aufwand von 2 Stunden bis 2 Tagen. Bei einfachen Geschichten kann dies genau eine einzige Aufgabe sein. Im Regelfall gibt es aber mehrere Aufgaben für eine Benutzergeschichte.

Wenn dies für alle Benutzergeschichten gemacht wurde, schätzt das XP-Team den Aufwand für jede einzelne Aufgabe. Das kann dazu führen, daß der Aufwand für alle Aufgaben größer ist als die Menge, die in dieser Iteration geleistet werden kann. In diesem Fall kann entweder eine Benutzergeschichte auf eine spätere Iteration verlegt, oder aber die Benutzergeschichte in zwei Teile zerlegt werden, von denen der erste in der laufenden Iteration und der Rest in der nächsten Iteration implementiert wird.

Programmieren in Paaren

Nachdem die Iterationsplanung abgeschlossen ist, werden die Aufgaben paarweise abgearbeitet. Für Implementierungsaufgaben bedeutet dies Programmieren in Paaren. Dies geschieht immer in der Weise, daß zunächst ein Komponententest erstellt wird, und danach das zu erstellende System in der Weise modifiziert wird, daß der Komponententest erfolgreich ausgeführt werden kann. Ist dies der Fall, wird der Quelltext umgeformt, der XPler spricht von refaktorieren. Dies bedeutet, daß man versucht für einen gegebene Implementierung eine einfachere Formulierung in der Programmiersprache zu finden, die funktional genau dasselbe tut. Ob es wirklich dasselbe tut, entscheiden die Komponententests. Erst wenn wieder alle Komponententests erfolgreich durchlaufen werden, war die Umformung (Refaktorierung) erfolgreich.

In manchen Fällen wird man nicht sofort "losprogrammieren" können. In diesem Fall wird eine schnelle Designsession gemacht. Das bedeutet, daß man z.B. mit CRC-Karten gerade soviel vom Softwaredesign erstellt, wie für die Implementierung erforderlich ist. Flexibilitäten, die nicht unmittelbar zwingend benötigt werden, bleiben unberücksichtigt.

Fortlaufende Integration

Nachdem eine Aufgabe vollständig implementiert wurde - nachweisbar durch erfolgreiches Absolvieren der Testfälle -, wird die Codeänderung in das System integriert. Dafür wird ein separater Arbeitsplatz verwendet, so daß zu einem beliebigen Zeitpunkt immer nur genau eine Änderung in das System integriert werden kann. Danach steht das veränderte System unmittelbar allen Programmierern zur Verfügung. Weil Systemänderungen sofort integriert werden, spricht man auch von fortlaufender Integration.

Zur Integration gehört auch, zugehörige Akzeptanztests durchzuführen. Wenn alle Aufgaben für eine Benutzergeschichte erledigt wurden, muß per Definition der Akzeptanztest funktionieren. Anderenfalls ergibt sich eine zusätzliche Aufgabe, die entweder noch in der laufenden Iteration erledigt werden muß oder aber die Aufgabe wird in die nächste Iteration geschoben. Letzteres läuft de facto auf eine Aufteilung der Benutzergeschichte hinaus. Die Entscheidung für eine der Varianten wird im Dialog mit dem Kunden getroffen.

Am Ende des Releasezyklus steht dem Anwender nun ein System zur Verfügung, daß eine garantierte, weil wiederholbar getestete, Funktionalität hat.

Ein Nebeneffekt dieser Vorgehensweise ist, daß der Kunde auch nach jeder einzelnen Iteration ein leidlich funktionierendes System hat, anhand dessen er feststellen kann, welche Fortschritte das Projekt macht.