next up previous contents index
Nächste Seite: 7.2.6 Zusammenfassung Extreme Programming Aufwärts: 7.2 Agiler Vertreter: Extreme Vorherige Seite: 7.2.4.12 40-Stunden-Woche:   Inhalt   Index

7.2.5 Planung und Anforderungsverwaltung

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 [*].

Abbildung 11: globaler Ablauf eines Extreme Programming Projektes (nach Wel99)
Image ablauf

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.

Abbildung 12: Ablauf einer Iteration in Extreme Programming (nach Wel99)
Image ablauf-iter

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.


next up previous contents index
Nächste Seite: 7.2.6 Zusammenfassung Extreme Programming Aufwärts: 7.2 Agiler Vertreter: Extreme Vorherige Seite: 7.2.4.12 40-Stunden-Woche:   Inhalt   Index
Sebastian Stein 2004-08-30