Extreme Programming (XP, auch Extremprogrammierung) ist eine Methode, die das Lösen einer Programmieraufgabe in den Vordergrund der Softwareentwicklung stellt und dabei einem formalisierten Vorgehen geringere Bedeutung zumisst. Diese Vorgehensweise definiert ein Vorgehensmodell der Softwaretechnik, das sich den Anforderungen des Kunden in kleinen Schritten annähert.

Grundlagen mini|400px|XP-Lebenszyklus

XP ist ein durch fortlaufende Iterationen und den Einsatz mehrerer Einzelmethoden strukturierendes Vorgehensmodell. XP entstand durch die Synthese verschiedener Disziplinen der Softwareentwicklung und basiert auf in der Praxis bewährten Methoden, auch Best practices genannt.

XP folgt einem strukturierten Vorgehen und stellt die Teamarbeit, Offenheit und stetige Kommunikation zwischen allen Beteiligten in den Vordergrund. Kommunikation ist dabei eine Grundsäule.

Die Methode geht davon aus, dass der Kunde die Anforderungen an die zu erstellende Software zu Projektbeginn noch nicht komplett kennt und nicht hinreichend strukturieren kann, beziehungsweise dass ein mit der Realisierung betrautes Entwicklerteam nicht über alle Informationen verfügt, um eine verlässliche Aufwandsschätzung über die notwendige Dauer bis zum Abschluss zu geben. Im Laufe eines Projektes ändern sich nicht selten Prioritäten und Gewichte. Zu Beginn geforderte Funktionen der Software werden möglicherweise in einer anderen Form benötigt oder im Laufe der Zeit sogar komplett hinfällig.

Bei einer konsequenten Ausrichtung an XP soll die zu erstellende Software schneller bereitgestellt werden sowie eine höhere Softwarequalität und Zufriedenheit des Kunden als mit traditionellen Ansätzen zu erreichen sein. Der Kunde soll ein einsatzbereites Produkt erhalten, an dessen Herstellung er aktiv teilgenommen hat.

Neue Funktionalitäten werden permanent entwickelt, integriert und getestet. Für die zu entwickelnden Funktionalitäten werden jeweils die Schritte Risikoanalyse, Nutzenanalyse, die Bereitstellung einer ersten ausführbaren Version (Prototyping) und ein Akzeptanztest durchgeführt.

Nutzen Nach Vertretern dieses Vorgehensmodells ist XP Risikomanagement. Es bejaht das Risiko, geht aktiv darauf ein und versucht, es zu minimieren. Dieser implizite Umgang mit dem Faktor Risiko steht im Gegensatz zu eher expliziten Vorgehensweisen, wie der Aufstellung einer Risikoliste.Tom DeMarco, Timothy Lister: Bärentango, Hanser Fachbuch, März 2003, ISBN 3-446-22333-9. Softwareentwicklungsprojekte sind unterschiedlichen Gefahren ausgesetzt, für die Extreme Programming Lösungen anbieten soll.

Kundensicht Dem Kunden bietet XP, gerade durch seine kurzen Entwicklungszyklen, jederzeit die Möglichkeit, steuernd auf das Projekt einzuwirken. Dadurch soll erreicht werden, dass sich das Produkt aktuellen Anforderungen anpasst, statt überholten Anforderungen aus einer längst vergangenen Analysephase zu genügen und damit bereits bei Einführung veraltet zu sein. Zudem kann der Kunde bereits nach kurzer Zeit ein unvollständiges aber zumindest funktionstüchtiges Produkt einsetzen. Der Kunde ist im besten Fall jederzeit auf demselben aktuellen Informationsstand bezüglich des Projektes wie das Entwicklerteam.

Ein häufiger Ansatz traditioneller Softwareerstellung ist: Vielleicht brauchen wir irgendwann einmal diese oder jene Programmfunktionen, auch Feature genannt. XP stellt dem gegenüber: Lass es! (vgl. auch YAGNI – „You Ain’t Gonna Need It“). Vor jedem der kurzen Entwicklungsschritte wird zusammen mit dem Kunden genau festgelegt, was wirklich sinnvoll ist, entwickelt zu werden. Die sogenannte „Featuritis“ soll damit vermieden werden.

Eines der größten Risiken der Softwareentwicklung ist, dass dem Kunden ein Produkt bereitgestellt wird, das er in dieser Form nicht möchte. XP möchte dem durch ständige, aktive Einbeziehung des Kunden in den Entwicklungsprozess vorbeugen. Er kann sich Zwischenversionen ansehen und direkt Änderungswünsche äußern.

Um diese Vorteile nutzen zu können, muss der Kunde im Gegenzug auch eine Reihe von Einschränkungen und Forderungen hinnehmen. So fordert XP von ihm, dass er während der gesamten Entwicklungszeit mit dem Entwicklungsteam zusammenarbeitet. Des Weiteren muss er auf eine formale Festlegung der Projektinhalte (Spezifikation) verzichten (siehe auch Der ideale Kunde).

Programmierersicht Es existiert keine strikte Rollentrennung, da die Aufgabenverteilung abhängig von Situation und Fähigkeiten geschieht. Der allgemeine Wissensaustausch und die stetige Kommunikation beugen einem Wissensmonopol vor. Dies soll den Einzelnen entlasten, da ansonsten der Druck auf einer Person lastet, wenn diese sich als Einzige in einem Modul auskennt.

Um Unbenutzbarkeit aufgrund von Programmfehlern sowie fehlerhafte Integration einzelner Komponenten zu vermeiden, werden bei XP viele und möglichst frühe Tests angestrebt. Jede Komponente besitzt einen Modultest (Unit-Test); in Java beispielsweise mit JUnit. Bei Feststellung eines Fehlers in einer Komponente während der Entwicklung wird ein Test entwickelt, der diesen lokalisiert. Eine tägliche Einbeziehung der einzelnen am Projekt beteiligten Entwickler mit automatischer Ausführung der Tests (Regressionstest) soll zu einer erheblichen Qualitätssteigerung führen. Fehler sollen so früher gefunden werden, denn je später ein Fehler gefunden wird, desto teurer ist meist dessen Korrektur. Außerdem soll die testgetriebene Entwicklung zu einem leichter wartbaren Programmcode mit besserem Design führen.

Da die meisten Einzelmethoden gerade auf den Alltag der Programmierer ausgerichtet sind, bedeutet XP zugleich auch ein hohes Maß an Herausforderung und ggf. Umstellung der Beteiligten. Auf diese Aspekte wird ausführlicher im Abschnitt Der ideale Programmierer eingegangen.

Projektsicht Dem Projekt bietet XP die Möglichkeit, Risiken zu minimieren. Unter richtiger Anwendung von XP soll der Kunde Software erhalten, deren Umfang ihn nicht überrascht. Das Team soll ferner gegen Ausfall (Krankheit, Unfall, Stellenwechsel) Einzelner nicht mehr so anfällig sein. Ein ehrlicher Umgang mit dem Kunden soll die Glaubwürdigkeit und Zufriedenheit steigern und die Angst minimieren, die unter Umständen zwischen Kunde („Haben die mich verstanden?“, „Was werden sie wohl liefern?“) und Entwicklung („Was will er eigentlich genau?“, „Ob er zufrieden sein wird mit dem, was wir liefern?“) vorherrscht.

Aufwandsabschätzungen werden verlässlicher, da sie im Team getroffen und ständig einer kritischen Überprüfung (Review) unterzogen werden. Teamgeist wird laut XP gefördert. Jedem im Team sollte klar sein, dass das Ziel nur als Einheit erreichbar ist. Sollte ein Projekt, zum Beispiel aus Kostengründen, vorzeitig eingestellt werden, besteht durch die regelmäßigen Iterationen dennoch ein zumeist einsatzfähiges Produkt.

In vielen Projekten gelingt es nicht, das Produkt in der gewünschten Zeit im gewünschten Umfang und mit den geplanten Ressourcen fertigzustellen. In XP soll nur das verwirklicht werden, was tatsächlich einen Nutzen für den Kunden hat. Durch ständigen Austausch mit dem Kunden sowie Prioritätsanalysen sollen die unbedingt zu erstellenden Funktionen identifiziert werden. Dabei sollte mit den Funktionen begonnen werden, die den größten Nutzen haben und das größte (technische) Risiko beinhalten.

Betriebswirtschaftliche Sicht Extreme Programming stellt aus wirtschaftswissenschaftlicher Sicht eine Form der Organisation dar, die direkt die Prozesse der Wertschöpfung beschreibt. In den Wirtschaftswissenschaften werden zur Bewertung von Extreme Programming auch Erkenntnisse anderer Sozialwissenschaften, insbesondere der Soziologie, genutzt.

Dem Risikomanagement dient diese Alternative vor allem zur Steuerung von Risiken. Wie bei vielen Prozessen der Wertschöpfung sind besonders in der Softwareentwicklung Risiken meist operative Risiken: Die Wertschöpfung ist ineffektiv, wenn die Kundenwünsche nicht getroffen und gesteckte Ziele somit verfehlt wurden. Die Wertschöpfung ist ineffizient, wenn zum Erreichen des Ergebnisses ein zu hoher Aufwand entstand. Risikoverminderung, und dadurch Effektivität und Effizienz, soll bei Extreme Programming durch die Art des Umgangs mit Fehlern, mit Mitarbeitern und mit Kunden erreicht werden: Kompensation von Krankheitsausfällen Kundennahe Entwicklung Weniger Fehler im Ergebnis

Ein möglichst genaues Erkennen von Risiken durch das Verfahren selbst soll über angepasste Aufwandsschätzungen eine Bewertung des zu akzeptierenden Risikos ermöglichen. Extreme Programming kann dagegen eine Risikoverlagerung erschweren. Aus der Sicht des Risikomanagements ist Extreme Programming also nur eine Möglichkeit, mit Risiken umzugehen, und zwar eine Möglichkeit, die Vor- und Nachteile besitzt.

Das Personalwesen in Unternehmen betrachtet Extreme Programming insbesondere im Hinblick auf seine Auswirkungen auf die Mitarbeiterzufriedenheit. Extreme Programming soll dabei bewusst oder unbewusst zum kooperativen Lernen beitragen. Für das Personalwesen ist dieses Verfahren also besonders aus Sicht der Personalentwicklung interessant. Durch höhere Mitarbeiterzufriedenheit und durch die Vermeidung von Überstunden soll die gesamte Produktivität erhöht werden. Die Praktik des Pair-Programming lässt allerdings – rein mathematisch betrachtet – Gegenteiliges vermuten. Die Vermeidung von Spezialistentum und individuellem Besitz von Wissen über Teile der Software dient der kollektiven Wissenskonstruktion und kann die Ersetzung von Entwicklern vereinfachen.

Die gesamte Betriebswirtschaftslehre ist in den letzten Jahren von der prozess- bzw. wertschöpfungsorientierten zur kunden- bzw. marktorientierten Unternehmensführung übergegangen. Auch wenn Extreme Programming die Wertschöpfung beschreibt, bietet es Möglichkeiten zu kundennaher Vorgehensweise. Über Extreme Programming soll – wie in anderen Branchen schon länger üblich – eine größere Einbindung des Kunden in den Wertschöpfungsprozess möglich sein. Wichtig wird dies umso mehr, wenn Software weniger als Faktorgut, sondern mehr als Vorprodukt erstellt und vertrieben wird.

Ebenfalls muss in Extreme Programming und dessen Aufwand aus Sicht des Informationsmanagements betrachtet werden, dass der Aufwand den unbedingt notwendigen Informationsaustausch festlegt, der ökonomisch bewertet wird. Genutzt werden dazu Erkenntnisse der Informations- und Kommunikationswissenschaft. Dabei kann insbesondere die Medienreichhaltigkeitstheorie eingesetzt werden: Weil die zu diskutierenden und kommunizierenden Sachverhalte in der Regel komplex sind, werden auch komplexe, reichhaltige Kommunikationsmedien gewählt: direkte, persönliche Gespräche. Kritisch zu hinterfragen ist hierbei die schwierige räumliche Verteilbarkeit der Entwicklungsprozesse sowie die Einbindung des Kunden, da unter Umständen eine räumliche Trennung zwischen Entwicklern und Kunden besteht.

Vorgehen Vereinzelt wird Extreme Programming als informelle (und damit unverbindliche) Methode bezeichnet. Das trifft jedoch weder den Ansatz noch das Ziel. Tatsächlich ist die Formalisierung der Methode des Extreme Programming bewusst flach und schlank gehalten. Hingegen muss ein Einvernehmen zwischen Kunden und Programmierern hinsichtlich der Verbindlichkeit der erstellten Unterlagen hergestellt werden, solange diese noch nicht durch neuere Fassungen ersetzt wurden. Weiter muss der Vorgang des Ersetzens einer Fassung einer Unterlage durch eine neuere Fassung dieser Unterlage soweit formalisiert sein, dass beide Parteien Kenntnis von dieser Ersetzung haben und diese Ersetzung annehmen.

Aufbauorganisation