eXtreme Programming (XP)

Veranstaltung des Vereins Colo.net der Universität Köln zum Thema Agile Softwareentwicklung, Juli 2002

Vortrag von Kerstin Dittert

XP ist ein leichtgewichtiger Prozess zur Durchführung objektorientierter Softwareentwicklungs-Projekte. Die Methode wurde von Kent Beck entwickelt und von ihm im Projekt C3 zum ersten Mal durchgängig eingesetzt.

Kern der Vorgehensweise sind

 Einbindung des Kunden

Die Iterationsplanung wird gemeinsam mit dem Entwicklungsteam und dem Kunden durchgeführt. 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.

nach oben

pair-programming

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.

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 („Truck-Faktor“).

nach oben

Refactoring

In beinahe jedem Entwicklungsprojekt wird irgendwann quick-and-dirty programmiert: Weil die Zeit bis zur nächsten Präsentation zu knapp ist, weil die Schnittstellen noch unklar sind oder aus einem anderen guten Grund. 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 muß deshalb Zeit für das Refactoring (Redesign und Bereinigung der schnellen Lösungen) eingeplant werden werden. Dabei werden die „fast hacks“ durch ausgereifte Lösungen ersetzt. Der Refactoring-Prozess sollte durch automatische Tests unterstützt werden, um Seiteneffekte zu vermeiden.

nach oben

Test first

Parallel zur Entwicklung einer Klasse sollte die Implementierung eines Test-Case erfolgen. Die 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.

nach oben