Extreme
Programming wird oft vorgeworfen, dass es lediglich eine
Legitimation für planloses Hacken darstellt und somit dem
,,Code and Fix`` Vorgehen entspricht. Es wird nun dargestellt, wie
der Ablauf eines Extreme Programming Projektes gestaltet wird und
wie die 12 Grundpraktiken zur Anwendung kommen. Eine grafische
Veranschaulichung findet sich in Abbildung 11 auf Seite .
Zu Beginn eines Projektes muss dessen Umfang bestimmt werden. Dazu wird zunächst die Metapher gebildet und eine Vision für das Projekt aufgestellt. (vgl. BF01, S. 33ff) In dieser Phase, bezeichnet auch als Erforschung (Bec00, S. 131ff), wird untersucht, welche Technologien zur Umsetzung der Vision verwendet werden können. Es muss das Budget und die großen Aufgabenbereiche festgelegt werden. Es erfolgt eine Grobschätzung des Aufwandes für die Realisierung der großen Aufgabenbereiche. Weiterhin wird die zur Realisierung notwendige Infrastruktur, wie Testwerkzeug und Codeverwaltung, aufgebaut.
Im nächsten Schritt findet die Versionsplanung (vgl. BF01, S. 39ff) erstmalig statt. Aus den groben Aufgabenbereichen entwickelt der Kunde konkrete Anforderungen in Form von Geschichten. Der Umfang der Geschichten wird von den Entwicklern geschätzt. Eine Geschichte darf dabei zwischen ein bis drei Wochen Entwicklungszeit in Anspruch nehmen. Lässt sich eine Geschichte nicht in diesem Zeitraum realisieren, muss sie aufgeteilt werden bzw. mehrere kleinere Geschichten müssen zu einer großen Geschichte zusammengezogen werden. Die Formulierung der Geschichten erfolgt in der Sprache des Kunden. Es werden alle technischen Details ausgespart. Eine Geschichte sollte aus wenigen Sätzen bestehen. Weiterhin muss der Kunde für jede Geschichte einen Test beschreiben (Funktionstest), mit dem die Erfüllung der Geschichte geprüft werden kann.
Die Geschichten werden durch den Kunden nach deren Geschäftswert geordnet. Es findet somit das Setzen von Prioritäten statt. Dabei spielen technische Abhängigkeiten eine untergeordnete Rolle. Weiterhin werden die Termine für die Versionen bestimmt. Die Entwickler legen aus Erfahrungswerten fest, wie viel Entwicklungsarbeit zwischen zwei Versionen geleistet werden kann. Anhand dieser Zahl wird festgelegt, welche Geschichten bis zu welchen Versionen zu realisieren sind. Als Ergebnis der Versionsplanung steht am Ende der Versionsplan sowie die zu realisierenden Geschichten geordnet nach deren Priorität.
Während eine Produktversion (Release) aller ein bis zwei Monate veröffentlicht werden soll, erfolgt die Arbeit in Iterationen. Eine Iteration hat dabei eine Länge von ein bis drei Wochen. Zur Erreichung einer Produktversion sind mehrere Iterationen nötig. Am Anfang jeder Iteration steht die Iterationsplanung. (vgl. BF01, S. 85ff) Während der Iterationsplanung werden die Geschichten in Aufgaben aufgeteilt. Die Aufgaben stellen eine technische Spezifikation dar, die in Zusammenarbeit mit dem Kunden erarbeitet wird. Die Entwickler übernehmen die einzelnen Aufgaben und verteilen somit die Aufgaben unter sich. Jeder Entwickler schätzt, wie lange er für die Realisierung der einzelnen übernommenen Aufgaben benötigt. Die Summe der geschätzten Aufgaben stimmt nicht zwangsläufig mit der Grobschätzung für die Geschichten überein. Bei einer sich abzeichnenden Überlastung der aktuellen Iteration, erfolgt eine Rücksprache mit dem Kunden. Dieser entscheidet, welche Geschichten in eine spätere Iteration verschoben werden. Die Iterationsplanung erfolgt jeweils nur für die aktuelle Iteration. Sie stellt die Feinplanung im Rahmen von Extreme Programming dar.
Nun beginnt die eigentliche Iteration, dargestellt in Abbildung
12 auf Seite . Dazu sucht sich ein Programmierer
für die Realisierung einer übernommenen Aufgabe einen
Partner. Die Koordinierung erfolgt selbstorganisiert und nicht
durch den Projektleiter. Das Programmierpaar
formuliert zuerst die Tests für diese Aufgabe und bei
Unklarheiten bezüglich der Aufgabe findet eine
Rücksprache mit dem Kunden statt. Erst dann wird der
eigentliche Code durch das Programmierpaar implementiert. Dabei
kann eine Überarbeitung des vorhandenen Codes nötig sein.
In diesem Fall kommt die Refaktorisierung zur
Anwendung. Nach wenigen Stunden wird dann der getestete Code in das
Gesamtsystem integriert. Dabei wird die Erfüllung aller Tests
nach der Integration sichergestellt.
Während der Iteration wird der aktuelle Fortschritt gemessen. Dadurch kann festgestellt werden, mit welcher Wahrscheinlichkeit die für die Iteration geplanten Geschichten realisiert werden können. Bei größeren Abweichungen wird eine neue Iterationsplanung durchgeführt.
Wie bereits mehrfach betont wurde, kann der Kunde jederzeit Geschichten ändern bzw. hinzufügen. Die Entwickler schätzen den Umfang der neuen bzw. geänderten Geschichte. Unter Umständen muss der Kunde entscheiden, welche Geschichten anstatt der neuen bzw. geänderten Geschichte nicht realisiert werden sollen.