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.
Inhaltsverzeichnis
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 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
- ↑ eXtreme Programming: Ein Überblick, TU Wien (November 2011)
Mvhl72 10:01, 16. Feb. 2012 (CET)