Extreme Programming

Extreme Programming (XP, im Deutschen auch selten Extremprogrammierung) ist eine Methode der Softwareentwicklung, die das Lösen von Programmieraufgaben in den Vordergrund stellt. Sie definiert ein Vorgehensmodell, das sich den Kundenanforderungen Schritt für Schritt annähert. Streng formale Vorgehensweisen spielen hierbei nur eine untergeordnete Rolle. Extreme Programming gehört zu den agilen Softwareprozessen und soll helfen, während der Entwicklung auf vage oder sich schnell ändernde Anforderungen angemessen reagieren zu können.

Geschichte

Extreme Programming wurde von Kent Beck, Ward Cunningham und Ron Jeffries bei Chrysler entwickelt. Sie waren im Projekt Chrysler Comprehensive Compensation System (C3) zur Erstellung einer Software für den Lohnabrechnungsbereich eingesetzt. Kent Beck wurde im März 1996 Projektleiter und passte die verwendeten Entwicklungsmethoden im Projekt an. Er schrieb ein Buch darüber, welches im Oktober 1999 unter dem Namen Extreme Programming Explained veröffentlicht wurde. Das Projekt C3 wurde im Jahr 2000 nach der Übernahme von Chrysler durch die Daimler-Benz AG eingestellt.

Obwohl diese Methode relativ jung ist finden sich deren Wurzeln teilweise bedeutend früher. So beschreibt Leo Brodie in seinem 1984 veröffentlichten Buch beispielsweise Praktiken wie Refactoring, Modularität oder Bottom-Up-Design. Weiterhin benutzte die NASA Methoden zum Softwaretest bereits 1960 im Mercury-Projekt.

Grundlagen

Extreme Programming: Spiral-Modell

Extreme Programming definiert verschiedene Einzelmethoden, die zur Projektlaufzeit iterativ durchlaufen werden. Es handelt sich um bewährte Methoden (sog. Best Practices) aus verschiedenen Disziplinen der Softwareentwicklung. Neue Features werden laufend entwickelt, integriert und getestet. Nacheinander werden die Schritte Risikoanalyse, Nutzeranalyse, Bereitstellung einer Testversion (Prototyping) und ein Akzeptanztest durchgeführt. Am Ende steht die zu entwickelnde Funktionalität, was gleichzeitig wieder der Beginn des nächstes Zyklus ist.

Extreme Programming ist somit ein sehr praxisorientiertes Vorgehensmodell in dem Teamarbeit, Offenheit und stete Kommunikation einen großen Stellenwert besitzen. Kommunikation wird als eine Grundvoraussetzung für Extreme Programming betrachtet.

Das Vorgehensmodell geht davon aus, dass der Kunde zu Beginn eines Softwareprojektes nicht alle Anforderungen kennt bzw. nicht präzise genug formulieren kann. Daraus folgt, dass das Entwicklungsteam zu Beginn keine verlässliche Abschätzung zu Kosten und Dauer des Projektes machen kann. Darüberhinaus ändern sich Prioritäten und Anforderungen häufig zur Projektlaufzeit, so dass bspw. zu Projektbeginn geforderte Features in veränderter Form oder sogar überhaupt nicht mehr benötigt werden.

Werden die Methoden des Extreme Programming konsequent angewandt, so wird das Softwareprojekt schneller abgeschlossen und erreicht eine höhere Softwarequalität als in traditionellen Ansätzen. Die Kundenzufriedenheit ist gegenüber herkömmlichen Vorgehensmodellen höher, er soll ein funktionierendes Produkt erhalten an dessen Entwicklung er aktiv beteiligt war.

Techniken

für das Team

Extreme Programming stellt das Teamwork in den Vordergrund. Ein XP-Team besteht aus zwei bis etwa zwölf Programmierern, dem Management und einem Kunden, wobei zu beachten ist dass die Rolle des Kunden in diesem Vorgehensmodell meist weder vom Geldgeber noch vom Endanwender ausgefüllt wird. Zudem erfordert das Modell die Rollen eines Trainers und eines Verfolgers. Der Trainer bestimmt mit dem Team die Regeln, die eingehalten werden sollen und weist das Team auf Regelverletzungen hin. Der Verfolger dokumentiert in regelmäßigen Abständen den Status des Projektes.

Offene Arbeitsumgebung

Das Team arbeitet auch räumlich eng zusammen: idealerweise in einem Großraumbüro, alternativ können es aber auch eng aneinander grenzende Einzelbüros sein. Wandtafeln und Flipcharts schaffen Möglichkeiten für schnelle Visualisierungen von Ideen oder Problemlösungen. Meist stehen die Schreibtische dicht beieinander im Kreis. Die Monitore sind nach außen gerichtet und die Arbeitsplätze so gestaltet, dass zwei Entwickler bequem daran arbeiten können (s. Programmieren in Paaren).

Kurze Iterationen

Die Zykluszeit der Entwicklungsperioden beträgt typischerweise ein bis drei Wochen. Am Ende jeder Iteration steht ein getestetes und funktionsfähiges Produkt, das dem Kunden neue Funktionen bietet.

Retrospektiven

Nach jeder Iteration betrachtet das Team rückblickend seine Arbeitsweise und reflektiert kritisch, was gut gelaufen ist und was nicht. Aus dieser Reflexion werden Regeln generiert, die vom Team akzeptiert und auf Poster geschrieben werden. Diese werden dann im Projektraum aufgehängt, so dass diese Ziele nicht aus dem Fokus geraten.

Tägliche Standup-Meetings

Zu Beginn eines jeden Arbeitstages wird ein Meeting im Stehen abgehalten. Das führt dazu, dass das Meeting kurz und lebendig bleibt. Jedes Teammitglied berichtet, was es gestern getan hat und was es heute machen wird. Probleme werden hier nur genannt, nicht gelöst. Üblicherweise treffen sich die Teams vor der Wandtafel ihrer Iterationsplanung.

für die Kunden

Benutzergeschichten

Die Kunden schreiben ihre Anforderungen in Form einfacher Geschichten auf Karteikarten nieder. Der genaue Funktionsumfang jeder Karte wird zum rechten Zeitpunkt mit dem Programmierer verhandelt und verfeinert.

Iterationsplanung

Am Anfang jeder Iteration steht ein Planungsmeeting, in dem das Kundenteam seine Geschichten erzählt. Das Programmiererteam gibt daraufhin eine grobe Zeitabschätzung zu jeder Geschichte ab. Das Kundenteam wählt schließlich diejenigen Geschichten aus, die abhängig von der Zeitabschätzung für sie den größten Geschäftsgegenwert bringen. Vom Programmiererteam werden die ausgewählten Geschichten nun in technische Aufgaben zerlegt und an Programmierer verteilt, die ihrerseits auf Basis früherer Aufgaben eine nun genauere Zeitabschätzung liefern können. Die Programmierer übernehmen nun genau soviele Aufgaben, wie sie in der bevorstehenden Iteration bewältigen können. Mit Hilfe dieser Planspiele sollen geschäftliche und technische Verantwortung voneinander getrennt werden.

Anforderungsdefintion im Dialog

Während der Implementierung der Software überprüfen und vertiefen die Programmierer ihr Verständnis von den Programmieraufgaben im ständigen Dialog mit dem Kunden. Der Kunde dient während des gesamten Entwicklungsprozesses als direkter Ansprechpartner für fachliche Fragen.

Akzeptanztests

Während der Iteration spezifiziert der Kunde die Abnahmekriterien. Üblicherweise wird von den Programmierern ein Werkzeug zur Verfügung gestellt, das die Verifikation der Software automatisch durchführt. Am Ende der Iteration müssen alle Testkriterien erfüllt sein.

kurze Releasezyklen

Das in der Entwicklung befindliche System wird nach ein bis drei Monaten Entwicklungszeit bereits an den wirklichen Endanwender geliefert. Aus dem Feedback werden Erkenntnisse für die Weiterentwicklung abgeleitet.

für die Entwicklung

Programmieren in Paaren

Während der gesamten Iteration arbeiten die Entwickler in Paaren am Code. Problemlösungen und Alternativen werden intensiv diskutiert. Die Partner wechseln sich minütlich an der Tastatur ab, die Partner werden im Stundenzyklus gewechselt. Dieses Vorgehen soll eine höhere Codequalität, größere Produktivität und bessere Wissensverbreitung sicherstellen.

Gemeinsame Verantwortlichkeit

Der gesamte Code gehört dem gesamten Team. Jedes Paar ist verpflichtet, jede Möglichkeit zur Codeverbesserung des gesamten Codes jederzeit wahrzunehmen.

Erst Testen

Jede Codezeile wird durch einen Testfall motiviert, der zunächst fehlschlägt. Die Unit-Tests werden gesammelt, gepflegt und nach jedem Kompilieren ausgeführt.

Design für heute

Jeder Testfall wird auf möglichst einfache Weise erfüllt. Es werden keine unnötig komplexen Features eingebaut, die zum gegenwärtigen Zeitpunkt nicht gefordert sind.

Refactoring

s. Hauptartikel: Refactoring

Das Softwaredesign wird permanent in kleinen Schritten verbessert, so dass die Gesamtfunktionalität jederzeit erhalten bleibt. Befindet ein Programmierer-Paar einen Teil im Code zu kompliziert, so vereinfachen sie den Code. Nach jedem Schritt werden Unit-Tests durchgeführt, so dass die Funktionalität nicht gefährdet wird.

Fortlaufende Integration

Mehrmals täglich wird das Softwaresystem automatisiert neu gebaut. Der Code wird mindestens einmal täglich in Inkrementen in eine Versionsverwaltung eingegeben. Zur erfolgreichen Integration müssen die Unit-Tests zu 100% laufen.

für das Management

Akzeptierte Verantwortung

Das Management macht dem Team keine Vorschriften, sondern zeigt nur Probleme auf (vgl. Information durch Metriken). Diese werden vom Team selbstständig gelöst.

Information durch Metriken

Zu den wichtigsten Aufgaben des Managements zählt es, dem Team den Spiegel vorzuhalten und so zu zeigen, wo es steht. Hierzu gehören z.B. einfache Metriken, die den Fortschritt des Teams zeigen, oder wo bestehende Probleme zu lösen sind (vgl. Akzeptierte Verantwortung). Daneben gilt es, einzelne Teammitglieder zu beobachten und herauszufinden, wo Hilfe gebraucht wird.

Ausdauerndes Tempo

Softwareprojekte gleichen einem Marathon. Schieben sich Refactorings oder Akzeptanztests auf, so ist es die Aufgabe des Managers seinem Team den Rücken freizuhalten, sonst wird es immer langsamer. Überstunden sind keine Lösung für zuviel Arbeit und wenn ein Teammitglied müde und zerschlagen wirkt muss es nach Hause geschickt werden.

Probleme und Schwierigkeiten

Das Alles-oder-Nichts-Prinzip

Die Methoden von Extreme Programming sind so eng miteinander verzahnt, dass sie immer möglichst ganzheitlich eingesetzt werden sollten. Das Auslassen einzelner Methoden kann die Wirksamkeit des Ansatzes bereits massiv einschränken und den Projekterfolg so gefährden.

Der ideale Kunde

Extreme Programming stellt erhebliche Anforderungen an den Kunden. Er muss experimentierfreudig sein und selbst erhebliche Ressourcen aufwenden, da er eng im Entwicklungszyklus eingebunden ist. Das Vorgehensmodell erfordert zudem Präsenzzeit des Kunden beim Entwicklungsteam.

Der ideale Programmierer

An die Programmierer des XP-Teams werden ebenso zahlreiche implizite Anforderungen gestellt. So müssen die eingesetzten Entwickler über ausgeprägte Fähigkeiten verfügen, da die Praxis häufiger Refactorings nur schwer ohne umfangreiche Programmiererfahrung und Kenntnis der dafür nötigen Tools umgesetzt werden kann. Einige Methoden des Modells erfordern hohe Disziplin (z. B. regelmäßige Refactorings oder Programmieren in Paaren), andere erfordern eine gewisse Disziplinlosigkeit (z. B. das Auslassen von Dokumentation). Es besteht die Gefahr, dass letzteren Aspekten mehr Aufmerksamkeit beigemessen wird. In jedem Fall bedingen diese gegensätzlichen Ansätze eine funktionierende Selbstregulierung des Teams. Extreme Programming lässt sich nicht mit beliebigen Teams realisieren.

Beschränkte Teamgröße

Extreme Programming setzt auf Kommunikation und erfordert einen hohen Grad an gegenseitiger Informiertheit. Ein Refactoring zentraler Softwarekomponenten erfordert zum Beispiel das Wissen aller Teammitglieder. Der quadratisch wachsende Kommunikationsaufwand beschränkt die Teamgröße von vorneherein auf etwas über zehn Mitglieder. Die Teamgröße beschränkt ihrerseits wieder die Projektgröße, so dass mit XP-Teams keine umfangreiche Softwareprojekte entwickelt werden können.

Feste Fertigstellungstermine

Der iterative Ansatz und das Fehlen eines festen Projektplanes führen dazu, dass eine bestimmte Funktionalität zu einem bestimmten Zeitpunkt nur sehr schwer garantiert werden kann. Es lässt sich nur garantieren, dass etwas funktioniert, da jede Iteration mit einer getesteten und funktionierenden Software abgeschlossen wird. Welche genauen fachlichen Aspekte abgedeckt sind lässt sich jedoch nur schwer vorhersagen, umsoweniger als Überstunden im Extreme Programming verpönt sind.

Personalpolitik

Da das Team beim Extreme Programming im Vordergrund steht, gestaltet sich eine angemessene Bezahlung der einzelnen Teammitglieder schwierig. Insbesondere der Honorarvertrag ist kein geeignetes Beschäftigungsverhältnis für dieses Vorgehensmodell.

Anhang

Weblinks

Extreme Programming in der deutschen Wikipedia

Extreme Programming in der englischen Wikipedia

Extreme Programming von Frank Westphal

Quellen

Mvhl72 10:01, 16. Feb. 2012 (CET)