Kerstin Dittert - OOcon - extreme programming

Eine umfangreiche Übersicht und Beschreibung der Methodik findet sich im im Wiki XP-Forum. Die wichtigsten Bestandteile sind:

Einbindung des Kunden

Die Iterationsplanung wird gemeinsam mit dem Entwicklungsteam und dem Kunden durchgeführt. discussion

Der Kunde legt den gewünschten Funktionsumfang fest und die Entwickler geben eine Schätzung für die Realisierung ab. Falls der Aufwand für die Iteration zu groß ist, muss der Funktionsumfang reduziert werden. Im anderen Fall wird weitere Funktionalität hinzugefügt. Dieser Prozess fördert die Priorisierung von Anforderungen ("Business value first") und führt auf Grund der Diskussion zwischen Fachabteilung und Entwicklern zu einem gemeinsamen fachlichen und technischen Verständnis. Nach der Iterationsplanung sollte Konsens herrschen, was am Ende der Iteration abgeliefert wird.

Pair programming

Jeweils zwei Programmierer bilden ein Team, welches sich einen Rechner teilt. Dies führt bereits während der Entwicklung zu einen ausgeprägten Qualitätssicherungseffekt. pair

Design- und Realisierungsentscheidungen werden vom Partner kritisch hinterfragt, was einem permanenten Code- und Design-Review gleich kommt. Die Paarkonstellationen wechseln regelmässig, so dass jeder Entwickler an verschiedenen Bereichen der Anwendung arbeitet. Das Wissen über spezielle Implementierungen und Designdetails ist also nicht mehr an einzelne Personen gebunden. Dies reduziert die Gefahr grösserer Produktivitätseinbußen, wenn einzelne Mitarbeiter das Team verlassen

Refactoring

In jedem Projekt werden irgendwann "fast-hacks" eingebaut, weil die Zeit bis zur nächsten Präsentation zu knapp ist, oder die Schnittstellen noch unklar sind, oder ... . wate

Oft gewinnt man auch im Projektverlauf neue Erkenntnisse, welche eine Umstrukturierung einiger Klassen oder Methoden sinnvoll erscheinen läßt. Wenn niemals Zeit für die Bereinigung solcher "Baustellen" vorhanden ist, führt dies einerseits zur Unzufriedenheit bei den einzelnen Entwicklern und andererseits zu einem immer schwieriger zu verstehenden System. Am Ende jeder Iteration sollte deshalb Zeit für das Refactoring (Redesign und Bereinigung der "fast-hacks") eingeplant werden werden. Der Refactoring-Prozess sollte durch automatische Tests unterstützt werden, um Seiteneffekte zu vermeiden.

Test before coding

Parallel zur Entwicklung einer Klasse sollte die Implementierung eines Test-Case erfolgen. Die test

Tests müssen nicht vollständig sein, sollten aber die wichtigsten 80% aller Anwendungsfälle umfassen. Durch Einsatz geeigneter Frameworks können die Testfälle automatisch verifiziert werden, so daß jederzeit ein vollständiger Test des Systems durchgeführt werden kann. Neue Versionen einer Klasse werden vom Konfigurationsmangement nur dann angenommen, wenn alle Tests fehlerfrei durchgeführt wurden. Ein vollständiger Test sollte mindestens täglich durchgeführt werden, da hierdurch die Anzahl der Fehlerquellen leichter einzugrenzen ist und nicht zu lange "in die falsche Richtung" entwickelt wird.

JUnit - Test Framework

Kent Beck und Erich Gamma haben gemeinsam das Framework JUnit zur Test-Unterstützung entwickelt. Mittlerweile wird es als OpenSource-Projekt weitergeführt. Neben der Java-Version JUnit existieren weitere Implementierungen für andere objektorientierte Programmiersprachen (z.B. für Smalltalk und C++).

Case Studie - Projekt C3 (Chrysler)

Im Chrysler Comprehensive Compensation (C3) - Projekt wurde XP zum ersten Mal von Kent Beck erprobt. Das Projekt war zuvor mit einer anderen Methodik aufgesetzt worden, es entpuppte sich jedoch als VDW-Projekt (vor die Wand ...) und wurde schließlich von Chrysler als gescheitert erklärt. Die gesamten bisherigen Ergebnisse wurden wegeworfen, als Kent Beck 1997 das Projekt übernahm und mit seinem Team nach der XP-Methode durchführte. In einer Case-Studie wird über das Projekt und seine Rahmenbedingungen berichtet.

Extreme Programming (XP)

Was ist XP?