Extreme Programming

Extreme Programming (XP) ist ein iteratives, inkrementelles, evolutionäres und agiles Vorgehensmodell in der Softwaretechnik. Es wurde von Kent Beck, Ward Cunningham und Ron Jeffries während ihrer Arbeit im Projekt Comprehensive Compensation System bei Chrysler entwickelt. Das sogenannte C3-Projekt dauerte von 1995 bis 2000. Die zu entwickelnde Software sollte im Bereich der Lohnabrechnung eingesetzt werden .

XP identifiziert zahlreiche Kerndisziplinen der Softwareentwicklung, und nutzt Best Practices, also sich in der Praxis als nutzbar erwiesene Standards, in einer extremen Art und Weise. Die Methode berücksichtigt, dass der Kunde die wirklichen fachlichen Anforderungen an die zu erstellende Software zum Projektbeginn meist noch nicht komplett kennt bzw. das mit der Realisierung betraute Entwickler-Team nicht über alle (technischen) Informationen verfügt, um eine verlässliche Aufwandsabschätzung über die notwendige Dauer bis zum Abschluss zu geben. Im Laufe eines Projektes ändern sich darüber hinaus nicht selten Prioritäten. Zu Beginn geforderte Funktionen werden möglicherweise in einer anderen Form benötigt oder sind im Laufe der Zeit komplett hinfällig.

XP bejaht die Ungewissheit, mit der die Softwareentwicklung verbunden ist, aber ist kein Freibrief zum Chaos. Es folgt vielmehr einem klaren, strukturierten Vorgehen, und erfordert von allen Beteiligten Offenheit und Disziplin. Es stellt die Teamarbeit und stetige Kommunikation zwischen allen Beteiligten in den Vordergrund. Die auf dem Team lastende Arbeitsbelastung wird gleichverteilt.

Bei einer konsequenten Ausrichtung an XP soll die zu erstellende Software schneller bereitgestellt werden können, als mit traditionellen Ansätzen. Die Softwarequalität soll höher und die Zufriedenheit des Kunden sichergestellt sein. Er bekommt laut Methodik ein einsatzbereites Produkt, an dessen Herstellung er aktiv teilgenommen hat.

XP ist einerseits eine Summe von Werten, Prinzipien und Best Practices, andererseits liefert es auch ein Rahmenwerk für ein strukturiertes Vorgehen, ein Prozessmodell.

Obwohl es auch andere maßgebliche Quellen gibt (siehe Weblinks und Literatur) orientiert sich die Zusammenstellung der Werte, Prinzipien und Praktiken an Kent Beck , dessen noch recht neue, evolutionäre Weiterentwicklungen XPs hier ebenfalls Berücksichtigung findet . Es existiert keine eindeutige Definition von XP, wobei allerdings die Diskussionen und Ausführungen der drei Originalverfasser XP am signifikantesten prägen.

Nutzen

Generell

XP ist gelebtes Risikomanagement. Software-Entwicklungsprojekte sind unterschiedlichen Gefahren ausgesetzt, für die Extreme Programming Lösungen anbietet.

Unnutzbarkeit aufgrund von Programmierfehlern: Programmierfehler sowie fehlerhafte Integration einzelner Komponenten: es werden viele und frühe Tests angestrebt. Jede Komponente besitzt einen Modultest (Unit-Test) (in Java beispielsweise mit JUnit). Falls in einer Komponente während der Entwicklung ein Fehler bemerkt wird, so wird ein Test entwickelt, der diesen Fehler identifiziert. Die Arbeiten der einzelnen projektbeteiligten Entwickler wird sehr häufig integriert. Eine tägliche Integration mit automatischer Ausführung der Tests (Regressionstest) führt zu einer enormen Qualitätssteigerung. Fehler werden früh gefunden. Je später ein Fehler gefunden wird, desto teurer ist dessen Behebung. Die testgetriebene Entwicklung führt zu Code, der ein besseres Design aufweist und wartbarer ist.

Unnutzbarkeit aufgrund von Fehlentwicklung: Eins der größten Risiken der Softwareentwicklung ist, dass dem Kunden ein Produkt bereitgestellt wird, welches er in dieser Form nicht möchte. XP beugt dem vor, indem der Kunde mit in den Entwicklungsprozess einbezogen wird. Häufig weiß zu Beginn der Kunde auch gar nicht genau wie seine Lösung aussehen soll. Es ist deshalb hilfreich, wenn der Kunden ständig in dem Projekt involviert ist. Er kann sich integrierte Zwischenversionen ansehen und frühzeitig Änderungswünsche kommunizieren.

Zeitplan nicht einhaltbar: 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 wird nur das implementiert was tatsächlich einen Nutzen hat. Durch den ständigen Austausch mit dem Kunden wird der aktuelle Entwicklungsstand stetig kommuniziert. Durch Prioritätsanalyse können die unbedingt zu erstellenden Funktionen identifiziert werden. Dabei sollte mit den Funktionen begonnen werden, welche den größten Nutzen haben und das größte (technische) Risiko beinhalten.

XP Kreislauf: Welche Schritte in welchen zeitlichen Abständen.

„Featuritis“: („Vielleicht brauchen wir irgendwann einmal dieses oder jenes Feature …“) XP stellt dem gegenüber: Lass es! (vgl. auch YAGNI). Vor jeder der kurzen Iterationen wird genau festgelegt was entwickelt wird.

Kundensicht

Dem Kunden bietet XP, gerade durch seine kurzen Iterationszyklen jederzeit die Möglichkeit steuernd auf das Projekt einzuwirken. Dieser Nutzen steigt für den Kunden noch mit der Projektgröße oder -dauer. Insbesondere soll dadurch erreicht werden, dass das Produkt sich aktuellen Anforderungen anpasst, statt nicht mehr aktuellen 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 funktionstüchtiges Produkt einsetzen. Der Kunde weiß über den Fortschritt stetig so viel wie das Entwickler-Team.

Programmierersicht

Dem Programmierer bietet XP durch seine ständig wechselnden Paare und den gemeinsamen Austausch und Abschätzungen einen besseren Überblick über das Projekt und damit mehr Fachwissen sowohl über das Fachkonzept als auch die Technologien. Es existiert keine strikte Rollentrennung, die Aktivitäten werden situativ nach Fähigkeiten verteilt. Durch den allgemeinen Wissensaustausch und der stetigen Kommunikation wird einem Wissensmonopol vorgebeugt, was den Einzelnen entlastet (es lastet Druck auf einer Person, wenn Sie sich als einzige an einem Modul auskennt). Durch die gleichmäßige Verteilung auf Iterationen wird die Arbeitsauslastung homogenisiert.

Projektsicht

Der Unternehmung bzw. dem Projekt bietet XP die Möglichkeit Risiken zu minimieren. Mit XP wird der Kunde definitiv Software erhalten dessen Umfang ihn nicht überraschen wird. Weiterer Vorteil ist, dass das Team gegen Krankheit einzelner nicht mehr so anfällig ist. Ein ehrlicher Umgebung mit dem Kunden fordert die Glaubwürdigkeit und Zufriedenheit und minimiert die Angst, die gewöhnlich zwischen Kunde („Was werden die wohl liefern?“ „Haben die mich verstanden?“) 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 einem Review unterzogen werden. Teamgeist wird gefördert, jedem ist klar nur als Einheit kann das Ziel erreicht werden. Sollte ein Projekt, z. B. aus Kostengründen, vorzeitig eingestellt werden, besteht durch die regelmäßigen Iterationen dennoch ein zumeist einsatzfähiges Produkt.

Werte

XP definiert fünf zentrale Werte, abstrakte Elemente, die von zentraler Bedeutung sind. Es sind Kommunikation, Einfachheit, Feedback, Mut und Respekt, wobei Respekt erst später dazugekommen ist. Ohne stetige Beachtung der rudimentären Werte ist es laut XP nicht möglich erfolgreich Software zu entwickeln.

Die zentralen XP-Werte

Das Team kommuniziert stetig, um Informationen auszutauschen. Der Prozess selbst erfordert hohe Kommunikationsbereitschaft. Es existiert ein stetiger Austausch aller Beteiligten, also auch zwischen dem Entwicklungsteam und dem Kunden. Es kommen auch Personen zu Wort, die in einer gerade diskutierten technischen Aufgabenstellung keine Experten sind. So werden sie mit einbezogen, es gibt zusätzliches Feedback und jeder fühlt sich dem Team und dem Produkt verpflichtet. Stetige Kommunikation mit dem Kunden, Aufnahme dessen Feedbacks und Erfüllung dessen Wünsche, also auch ein lauffähiges Produkt, welches den Wünschen des Kunden voll entspricht, ist wichtiger als Vertragsverhandlungen. Die Kommunikation zeichnet sich ferner durch einen respektvollen Umgang miteinander aus, also im Team untereinander und mit dem Kunden. Verschiedene Meinungen werden akzeptiert.

Die Kommunikation ist offen und die Entwickler mutig. Falls eine Anforderung nicht in einer Iteration umgesetzt werden kann wird darauf direkt hingewiesen, in einer ehrlichen Art und Weise. Es muss eine Atmosphäre geschaffen werden, die herkömmliche Strömungen (wie unnatürlichen Konkurrenzkampf innerhalb des Teams zu Lasten des Produktes) minimiert. Um die Offenheit und den Mut zu fördern und gruppendynamische, psychologische Schwierigkeiten entgegenzutreten kann bewusst ein Doomsayer, auch Advocatus Diaboli genannt, eingesetzt werden.

Es soll die einfachste Lösung für eine Problemstellung realisiert werden. In jeder Iteration konzentriert sich das komplette Team auf genau die Anforderungen, die jetzt gerade umgesetzt werden sollen. Die Umsetzungen sollen technisch möglichst einfach sein.

Prinzipien

Die 14 Prinzipien sind eine Brücke zwischen der abstrakten Werten und den konkreten, anwendbaren Praktiken (siehe unten). Die Prinzipien sollten immer Berücksichtigung finden. Es sind Menschlichkeit, Wirtschaftlichkeit, Beidseitiger Benefit, Selbstgleichheit, Verbesserungen, Vielfältigkeit, Reflexion, Lauf, Gelegenheiten wahrnehmen, Redundanzen vermeiden, Fehlschläge hinnehmen, Qualität, Kleine Schritte sowie Akzeptierte Verantwortung.

Software wird von Menschen entwickelt, Menschen bilden also den Faktor, dem besondere Aufmerksamkeit gilt. Durch eine Atmosphäre der Menschlichkeit müssen stetig die Grundbedürfnisse der Entwickler beachtet werden, die da wären: Sicherheit, Vollendung, Identifikation mit der Gruppe, Perspektive, Verständnis.

Die erstellte Software bzw. eine einzelne Funktionalität muss einerseits wirtschaftlich sein, sie muss einen echten Wert bringen, andererseits muss sie einen beidseitigen Benefit bringen, also alle Beteiligten (Enticklungsteam und Kunden) zufrieden stellen.

Die Prinzipien XPs

Eine Wiederverwendung existenter Lösungen ist sehr wichtig, dazu gehören beispielsweise die zahlreichen unterschiedlichen Tests, die stetig, automatisiert durchlaufen werden. Selbstgleichheit zeichnet sich auch dadurch aus, dass Tests immer zusammen mit der Funktionalität entwickelt wird. Wo allerdings Verbesserungspotential identifiziert wird, wird die Lösung angepasst. Es ist jedem klar, dass erste Lösungen nicht optimal sind. Aus Feedback und selbst gewonnenen, neuen Erkenntnissen wird die Lösung stetig verbessert. Immer bessere Lösungen zu erkennen gelingt nur durch stetige Reflexion, ein kontinuierliches Nachfragen im Team, warum etwas so gemacht wird wie es gerade gemacht wird. Dies ist umso produktiver je vielfältiger das Team zusammengestellt ist. Das Team besteht aus Personen mit unterschiedlichen Fähigkeiten und Charakteren. Verschiedene Meinungen werden nicht nur geduldet sondern auch gefördert. Es muss Konfliktmanagement etabliert werden.

Es wird konstant Software entwickelt die jederzeit lauffähig ist. Kurze Iterationen mit permanentem Feedback halten das Projekt in einem Lauf. Dennoch müssen Fehlschläge einkalkuliert werden. Es ist durchaus normal eine Realisierung durchzuführen, die zunächst nicht optimal oder gar fehlerhaft ist. Dies muss akzeptiert werden. Diese Schwierigkeiten müssen als Gelegenheit begriffen werden, also als Chance, die das Produkt und das Team nur noch weiter reifen lassen. Ein offener, konstruktiver Umgang mit den Herausforderungen bei der Softwareentwicklung gelingt am besten, wenn alle Beteiligten ihre Verantwortung akzeptieren. Einem Entwickler eine Aktivität und eine Verantwortung disziplinarisch aufzutragen reicht nicht aus. Er muss die Verantwortung annehmen und leben.

Ein weiterer wichtiger Punkt ist die Qualität. Qualität ist nicht diskutabel. Die zu erstellende Software muss von hoher Qualität sein. Ressourcen und vor allem Funktionsumfang und Endtermin sind eventuell diskutabel. Diese Grundeinstellung unterscheidet sich von vielen anderen Methoden der Softwareerstellung. Wo Software zu einem bestimmten Zeitpunkt und einem definierten Funktionsumfang fertiggestellt werden soll, leidet fast immer die Softwarequalität. Gerade die Qualität ist allerdings sehr wichtig, um das Produkt einsatzfähig, fehlerfrei und erweiterbar zu halten. Software mit gutem Design und hoher Qualität ist mittelfristig kostengünstiger als schnell erstellte Frickelsoftware, ohne ein Mindestmaß an Qualität.

Zu einer guten Qualität gehört auch, dass Redundanzen vermieden werden sollen. Redundanzen sind beispielsweise unnötig mehrfach oder wiederholt ausgeführte Schritte, auch manuelle Schritte welche automatisiert werden könnten. Auch kleine Schritte erhöhen die Qualität. Durch schnelle, kleine Schritte bleibt das Team flexibel, kann sich schnell neuen Rahmenbedingungen stellen und auf Feeback eingehen. Ein einzelner Schritt, der nicht erfolgreich verlief, kann wesentlich schneller durch einen neuen Schritt kompensiert werden, als ein einzelner großer Schritt.

Praktiken

Extreme Programming ist die Summe einzelner Best Practices. Sie sollen alle zusammen eingesetzt werden, um den größten Nutzen zu erzielen. XP definiert sich selbst mit diesen Prinzipien allerdings nicht als Allheilmittel. Da wo es den individuellen Anforderungen nicht genügt soll es angepasst werden. Viele Prinzipien greifen verzahnt ineinander. Einzelne Praktiken sind an sich nicht neu, werden teilweise bereits lange genutzt, oder sind sogar von trivialer, und doch unterschätzer Natur. Die Praktiken sind die greifbaren, konkreten Maßnahmen die sich aus den Werten und den Prinzipien ableiten lassen.

Es lassen sich traditionelle Praktiken unterscheiden von evolutionären Praktiken. Die traditionellen sind in der XP-Welt weit verbreitet und genutzt. Die evolutionären nehmen verschiedene neue Erkenntnisse aus der jahrelangen Anwendung XPs auf. Sie verfeinern die ursprünglichen oder modifizieren sie geringfügig und machen die Nutzung klarer und verständlicher.

XP wird häufig mit den traditionellen Praktiken assoziert bzw. darauf reduziert.

Traditionelle Praktiken

Pair-Programming: Beim Pair-Programming teilen sich zwei Programmierer einen Computer – einer codiert (der Driver)und der andere denkt mit und hat das große Bild im Kopf (der Partner). Die Rollen werden regelmäßig getauscht. Dieses Vorgehen steigert den Wissenstransfer. Anfänger lernen schneller von der Arbeit eines Spezialisten. Das Wissen wird verteilt. Das Projekt ist nicht mehr so anfällig gegen den Ausfall eines einzelnen. Durch ständiges Review der Entwicklung und Kommunikation wird das Design verbessert, und Fehler schneller gefunden (siehe auch Vier-Augen-Prinzip).

Kollektives Eigentum: Aktivitäten werden an das ganze Team verteilt, zunächst nicht an einzelne Personen. Es existiert das Bewusstsein und die Verpflichtung nur als Team erfolgreich sein zu können. Diese Verpflichtung wird täglich gelebt. Einzelne Teammitglieder besitzen kein Wissensmonopol. Pair-Programming und wechselhafte Einsatzgebiete wirken der Strömung entgegen, dass einzelne Personen Teile als ihren Besitz betrachten.

Permanente Integration: Integration der einzelnen Komponenten zu einem lauffähigen Gesamtsystem in kurzen Zeitabständen (z. B. durch CruiseControl). Je häufiger integriert wird, desto höher wird die eintretende Routine. Fehler werden frühzeitig aufgedeckt. Die mit der Integration verbundenen Kosten werden auf fast 0 minimiert gehört denn die Integration zu einem täglichen Schritt, der weitestgehend vollautomatisiert und selbst stabil und durchgetestet ist.

Testgetriebene Entwicklung bzw Permanentes Testen: Bei der testgetriebenen Entwicklung werden erst die Modultests (Unit-Test) geschrieben, bevor die eigentliche Funktionalität programmiert wird. Der Entwickler befasst sich dadurch frühzeit mit dem Design des Codes, und überdenkt seine Programmierarbeit genau. Die Tests werden nach jedem Programmierschritt ausgeführt und liefern Rückmeldung über den Entwicklungsstand. Man spricht in diesem Zusammenhang auch von Grey-Box-Tests. Die Tests sind automatisiert. Im Laufe einer Integration werden Integrationstests durchgeführt. Es wird zwischen Regressionstest und Modultest unterschieden. Während Modultests einzelne Module testen (Unit-Tests) ist ein Regressionstest die kollektive Ausführung aller Tests, um die unveränderte Lauffähigkeit der alten, bereits vor der Iteration existenten Funktionalität zu überprüfen. Auch Performancetests sind üblich. Hier wird überprüft, ob das Produkt bestimmte Leistungs- bzw. Geschwindigkeitsmaßstäbe erfüllt. Der Entwickler bekommt Rückmeldung (Feedback) wie viele und welche Tests nicht erfolgreich waren. Ein Akzeptanztest ist die Präsentation eines Standes des Produktes, um die Zufriedenheit des Kunden und die Nutzbarkeit zu validieren.

XP Best Practices

Kundeneinbeziehung: Enge Einbeziehung des Kunden, d. h. der Kunde gibt das Iterationsziel mit einer Auswahl der zu realisierender User Stories vor und hat zeitnah die Möglichkeit Akzeptanztests durchzuführen. Story-Cards dienen als Medium, um die kurzen Anwendungsfälle in Form von User Stories aufzunehmen. Der Kunde muss immer anwesend oder zumindest greifbar sein. Neben User Stories auf Story-Cards existiert noch der Ansatz CRC-Modelle auf CRC-Karten zu verfassen.

Refactoring: Laufendes Refactoring, ständige Architektur, Design- und Code-Verbesserungen, auch um Anti-Patterns zeitnah zu beheben. XP bejaht die Existenz von Code, der initial nicht perfekt ist. Stattdessen sind sämtliche Teile einem stetigen Review unterzogen. Die Behebung von gefundenen, optimierungsfähigen Stellen werden gewöhnlich zeitnah durchgeführt oder als Fehler (Bug) definiert, der in einer späteren Iteration behoben wird.

Keine Überstunden: 40-Stunden-Woche, d. h. Überstunden sind zu vermeiden, weil darunter die Freude an der Arbeit, mittelfristig die Konzentrationsfähigkeit der Programmierer und somit auch die Qualität des Produktes leidet. Nachweisbar sinkt die Produktivität des Entwicklers durch Überstunden. Arbeit außerhalb des Sweet Spot darf im Einzelfall zwar geduldet werden, aber auf keinen Fall besonders entlohnt oder erwartet werden. Überstunden zeugen gewöhnlich einfach nur von falscher Planung.

Iterationen: Kurze Iterationen, um dem Kunden in regelmäßigen Zeitabständen einen lauffähigen Zwischenstand des Produkts zu liefern. Eine Iteration ist eine zeitlich und fachlich in sich abgeschlossene Einheit. Kurze Iterationen und verbundene Akzeptanztests bieten schnelle Feedbackschleifen zwischen Entwicklung und Kunde.

Metapher: Anforderungen werden mit dem fachlichen Vokabular des Kunden, optimalerweise auch von ihm selbst, in Form von User Stories beschrieben. Alle sprechen eine Sprache, was durch ein Glossar verstärkt werden kann. Häufiges Problem in traditionell aufgesetzten Softwareprojekten ist ein latentes Missverständnis zwischen Kunde und Entwicklungsteam. Der Entwickler hat Schwierigkeiten die Fachsprache des Kunden, der Kunde kann und will auch nicht die technischen Vokabeln des Entwicklers verstehen. Es wird eine Metapher gewählt, eine logisch ähnliche, für jeden verständliche Alltagsgeschichte.

Coding Standards: Das Team hält sich an Standards bei der Realisierung. Coding Standards ermöglichen erst die gemeinschaftliche Verantwortung des Teams. Wechselnder Einsatz der Entwickler in allen Bereichen der Software ist nur durch gemeinsame Standards praktikabel.

Einfaches Design: Es soll die Lösung angestrebt werden, die genau das erreicht was gewünscht ist. Bewusst generische Realisierungen oder vorbereitende Maßnahmen für potentiell zukünftige Anforderungen werden vermieden. Das ganze Design wird möglichst einfach gehalten. Zum Thema Einfachheit sind die umgangssprachlichen Akronyme KISS und YAGNI verbreitet.

Planning Game: Neue Versionen der Software werden in einem Planning Game, auch als Planning Poker bekannt, spezifiziert, und aufwandstechnisch abgeschätzt. Während dieses iterativen Vorgehens sind sowohl Entwicklungsmannschaft als auch Kunde anwesend.

Evolutionäre Praktiken

Die evolutionären Praktiken lassen sich unterteilen in Hauptpraktiken und ergänzend dazu Begleitpraktiken. Generell drücken sie das Gleiche aus wie die traditionellen Praktiken. Teilweise ist der Leitbegriff verständlicher formuliert oder wurde in einzelne Unterpraktiken aufgeteilt. Die Praktik Metapher ist weggefallen, da es für sich genommen zu schwer zu vermitteln war. Coding standards werden als absolut rudimentär vorausgesetzt und werden nicht mehr explizit erwähnt.

Hauptpraktiken

Die Hauptpraktiken sind: Räumlich zusammen sitzen, Informativer Arbeitsplatz, Team, Pair-Programming, Energievolle Arbeit, Entspannte Arbeit, Stories, Wöchentlicher Zyklus, Quartalsweiser Zyklus, 10-Minuten Build, Kontinuierliche Integration, Test-First Programmierung und Inkrementelles Design.

Maximale Kommunikation und optimaler Austausch wird erreicht durch offene, gemeinsame Anordnung der Arbeitsplätze. Dieses Zusammensitzen ist einer Anordnung vorzuziehen in der die Beteiligten räumlich getrennt sind bzw. nur schwer kommunizieren können. Der Arbeitsplatz muss ferner informativ sein: aktuelle Tasks, Status des Projektes und andere wichtige Informationen müssen immer gut sichtbar am Arbeitsplatz verfügbar sein. Es empfiehlt sich beispielsweise die User Stories zentral an eine Wand zu hängen.

Die Hauptpraktiken des evolutionären XPs

Nicht nur räumlich vereint: das ganze Team ist wichtiger als Individuen. Das Team fällt kollektiv Entscheidungen. Das Bewusstsein nur als Gemeinschaft erfolgreich zu sein ist tief verankert. Dies wird dadurch gefördert, dass die einzelnen technischen Aktivitäten in der Planung nicht einzelnen Personen zugeordnet werden. Das ganze Team ist für die gemeinsame, erfolgreiche Realisierung verantwortlich. Probleme löst das Team selbst, der Eingriff eines Managers von außen ist nicht notwendig. Mit dem Thema selbstregulierendes Team befasst sich auch der Essay Die Kathedrale und der Basar. Pair-Programming mit abwechselnden Partnern unterstützen weiter diese Grundeinstellung.

Die Arbeit ist einerseits energievoll, da die Entwickler ohne Überstunden arbeiten, somit maximale Produktivität erlangen, sie ist aber auch entspannt. Es werden Sicherheitspuffer einkalkuliert. Nicht einhaltbare Versprechen werden vermieden. Auf eine entspannte, kollegiale Atmosphäre, auch zum Kunden, wird geachtet.

Die zu entwickelnde Funktionalität wird in Form von Stories beschrieben, beispielsweise User Stories. In einem wöchentlichen Zyklus wird entschieden welche Kundenwünsche als nächstes realisiert werden. Das Projekt selbst wird in einem quartalsweisen Zyklus geplant. Die Zyklen sind Richtwerte, dessen Größen im täglichen Einsatz variieren können.

Die Software bauen und alle Tests laufen lassen soll in maximal 10 Minuten abgeschlossen sein. Durch diesen 10-Minuten Build werden die Kosten für Erstellung und das Testen der Software minimiert. Alle von einem Entwickler gemachten Änderungen sollten ca. alle 2 Stunden bereitgestellt werden. Diese kontinuierliche Integration beugt einem potentiellen Chaos vor, wenn die Entwickler ihre Änderungen und Erweiterungen am Produkt sehr selten in das zentrale Datenhaltungssystem (Repository), beispielsweise CVS, einstellen. Alle Kollegen haben zeitnah die Änderungen zur Verfügung. Sowohl die 10 Minuten beim Build als auch die zwei Stunden bei der Integration sind Zielvorgaben, die sich in konkreten Projekten schwer erreichen lassen. Gerade bei großen Projekten mit viel Quelltext und vielen Entwicklern wird ein Build signifikant länger dauern, und die Integrationsintervalle nicht selten größer sein. Die Praktiken betonen die Richtung und geben einen Idealwert vor, der angestrebt werden sollte. Durch Automatisierung lässt sich die Build-Zeit weitestgehend minimieren.

Die Entwicklung ist ferner gekennzeichnet durch den Test-First Programmierung-Ansatz: vor der Realisierung der Funktionalität muss der Test geschrieben werden. Ein inkrementelles Design verbessert das Design der Software stetig. Neue Erkenntnisse und Feedback werden aufgenommen.

Begleitpraktiken

Die Begleitpraktiken sind: Richtige Kundeneinbeziehung, Inkrementelles Deployment, Team Konstanz, Schrumpfende Teams, Ursachliche Analysen, Geteilter Code, Codierung und Testen, Eine zentrale Codebasis, Tägliches Deployment, Verhandelbarer, vertraglicher Funktionsumfang und Zahlen-pro-Nutzung.

Der Kunde nimmt aktiv an der Entwickler teil. Der Kunde ist Bestandteil der regelmäßigen Treffen, er wird aktiv richtig einbezogen. Die Einbeziehung manifestiert sich auch bei dem zu entwickelnden Funktionsumfang. Der Umfang muss verhandelbar bleiben. Mehrere kleinere Verträge anstatt einem großen können Risiken minimieren und Flexibilität erhöhen. Da iterativ stetig neue Versionen bereitgestellt werden muss die finanzielle Kompensation des Kunden unabhängig sein von der Anzahl der bereitgestellten Versionen. Der Kunde zahlt nicht für jede Version der Software sondern zahlt pro Nutzung.

Die Nebenpraktiken des evolutionären XPs

Das Team lebt einerseits von dessen Konstanz, andererseits kann es auch geschrumpft werden. Das Entwicklerteam muss über mehrere Projekte hinweg das gleiche sein. Das Team erwirbt im Rahmen der Produktentwicklung Fähigkeiten als Team zusammen zu arbeiten. Diese Fähigkeiten müssen für weitere Projekte genutzt werden. Sobald das Team leistungsstärker und produktiver wird, so sollte die Arbeitslast auf dem Team gleich bleiben, aber Ressourcen zu anderen Teams verlagert werden.

Dem Code als das im Zentrum stehende Medium kommt eine zentrale Rolle zu. Es wird in einem zentralen Repository gehalten. Es existiert nur eine offizielle Version des Systems, eine zentrale Codebasis. Dieser Code wird, bildlich gesprochen, zwischen den Entwicklern geteilt. Jeder Entwickler im Team muss jeden Code jederzeit ändern können, siehe Collective Code-Ownership. Neben dem Code existieren immer die Tests. Code und Tests sind die einzigen zu erstellenden Artefakte, also durch die Entwicklungsarbeit bereitgestellte Medien. Alle anderen wie Dokumentation können aus Code und Tests generiert werden.

Um Schwierigkeiten frühzeitig zu identifizieren wird ein inkrementelles Deployment durchgeführt. Wenn Altsysteme durch neue Software ersetzt werden soll, so müssen ein Teil nach dem anderen ersetzt werden. Dieses Vorgehen macht die Umstellung planbar. Das Deployment ist nicht nur inkrementell, es ist auch täglich. Jeden Tag soll eine neue Version der Software produktiv gestellt werden. Dies macht das Deployment zur Routine, minimiert dessen Kosten und Fehler und ermöglicht stetige Integrations- und Akzeptanztests. Falls einmal ein technisches Fehlverhalten eintritt muss eine ursächliche Analyse durchgeführt werden. Um einen Fehler nicht zu wiederholen muss nicht nur ein Defekt sondern auch seine Ursache behoben werden.

Vorgehen

Aufbauorganisation

Neben dem Entwicklungsteam gibt es im Wesentlichen den Kunden und den Product Owner. Wichtig zu betonen ist, dass es innerhalb des Entwicklerteams keine Rollentrennung gibt, so wird nicht unterschieden, wer im Team was für ein Spezialgebiet hat bzw. welche besonderen Fähigkeiten er mitbringt. Jede Person im Team wird als Entwickler bezeichnet.

Die Rollen bei XP

Vorlage:Highlight2|Rolle	Vorlage:Highlight2|Beispiel	Vorlage:Highlight2|Aufgaben
Product Owner	Produktmanagement, Marketing, ein User, Manager des Users, Analyst, Sponsor	Verfolgt gemeinsame Vision, Etabliert Prioritäten, Entscheider für bestes ROI
Kunde	Auftraggeber, kann auch der Product Owner sein, kann, muss aber nicht User sein	Entscheidet was gemacht wird, gibt regelmäßig Feedback, Auftraggeber
Developer	Bestandteil des Teams, das ganze Entwicklungsteam besteht aus Entwickler: Programmierer, Tester, DB-Experten, Architekt, Designer	Entwickelt das Produkt
Projektmanager	Ist gewöhnlich der Product Owner, kann auch Entwickler sein; nicht Manager des Teams	Führung des Teams
User	Der Nutzer des zu erstellenden Produktes	Führung des Teams, nicht Manager des Teams; ist gewöhnlich der Product Owner

Anforderungsmanagement

Der Umgang mit den Anforderungen und dessen Realisierung, also dem Anforderungsmanagement, ist eine zentrale Komponente XPs. Durch eine Mischung verschiedener in den folgenden Kapiteln dargestellten Maßnahmen soll die Qualität und Flexibilität der Software gesteigert werden, so dass der Zusammenhang zwischen dem Zeitpunkt, wann eine Anforderung gestellt wird, und den damit entstehenden Kosten weitgehend linear ist.

Kostenkurve

Bei einem weitgehend linearen Verlauf der Kostenkurve wird auf eine vollständige Erhebung aller Anforderungen zu Beginn des Projektes verzichtet. Stattdessen werden die sich erst im Laufe der Realisierung ergebenden Anforderungen mit berücksichtigt. Dieses Vorgehen resultiert aus den Beobachtungen, dass einerseits der Kunde zu Beginn des Projektes noch gar nicht genau weiß was er möchte, andererseits sich diese Anforderungen im Laufe eines Projektes ändern. Darüber hinaus sind Fehler umso teurer je später man sie findet. Im schlimmsten Fall wird dem Kunden nach einem langen Projekt etwas geliefert was er gar nicht haben möchte. Stetiger Kundenaustausch, Offenheit für Änderungen und stetige Integration wirken diesen Risiken entgegen.

Planung

Im Rahmen der Planung wird gewöhnlich folgende Unterscheidung vorgenommen: ein Release beinhaltet die Funktionen, die insgesamt und für sich geschlossen die Bereitstellung einer neuen Version des Produktes rechtfertigen. Um zu dem Release zu kommen wird ein Release-Plan aufgestellt welcher im wesentlichen aus Iterationen besteht. Unter anderem abhängig von der geschätzten Dauer des Release werden die Iterationen in Anzahl und Dauer festgelegt. Normale Iterationen gehen von 1 Woche bis 4 Wochen. Der Zeitpunkt der Fertigstellung wird als Intervall kommuniziert, dessen Größe im Laufe des Releases aufgrund gewonnener Erkenntnisse und durchgeführten Fortschritts ständig abnimmt.

Risiko-Value Gegenüberstellung und Priorisierung

Die einzelnen Neuerungen, die innerhalb der Iterationen realisiert werden, werden zusammen bzw. durch den Kunden, durch User Stories, einem schlankeren Derivat der Use Cases, beschrieben. User Stories beschreiben was ein Akteur mit dem System machen können soll, um etwas zu erreichen. Eine User Story folgt dem Muster „Als xxx kann ich xxxx, um xxxx'“, wobei das um auch weggelassen werden kann, falls die Intention klar erkennbar ist. Diese Formulierung dient als Template und kann situativ geändert werden.

Das ganze Team ist bei der Erstellung beteiligt. Sie werden auf einzelnen Karten (Story Cards) geschrieben und für alle sichtbar an ein Medium platziert.

Anmerkung: Neben diesem Vorgehen ist es auch üblich CRC-Models auf CRC-Cards zu verfassen. Class Responsibility Collaboration-Models nehmen sich dabei einen Akteur im System vor und beschreiben dessen Verantwortlichkeiten und Interaktionen mit anderen Akteuren.

User Story: Als Arzt kann ich alle Patienten sehen, die ich am Tag habe.

Es werden die User Stories priorisiert. Dazu muss das Team zusammen mit dem Kunden zunächst Klarheit gewinnen welche User Stories das höchste Risiko bezüglich Zeitplan, Kosten oder Funktionalität besitzen und welche User Stories dem Produkt den höchsten respektive den niedrigsten Mehrwert bieten. Hier kann ein Diagramm helfen. Das Release sollte mit den User Stories begonnen werden, welche das höchste Risiko und den höchsten Nutzen auf sich vereinen. Danach werden die User Stories realisiert welche geringes Risiko aber hohen Nutzen haben. Anschließend geht das Team die User Stories an die geringes Risiko und geringen Nutzen haben. Die Realisierung von User Stories mit geringem Nutzen aber hohem Risiko sollte vermieden werden.

Kundenzufriedenheit

Neben einer Abschätzung nach Nutzen und Risiko ist für die Entscheidung welche User Stories in dem Release bzw. in den ersten Iterationen realisiert werden sollen noch eine Analyse der Kundenwünsche von Bedeutung. Dabei bedient sich ein XP-Projekt häufig dem Kano-Modell. In einer systematischen Kundenbefragung werden Fragen in funktionaler Form und in dysfunktionaler Form gestellt. Es lässt sich anschließend bestimmen welche User Stories unbedingt realisiert werden müssen (Must-haves), welche linearer Natur sind (je mehr desto besser, Kundenzufriedenheit steigt linear) und welche Exciters sind (der Kunde rechnet nicht wirklich mit diesen Features, nutzt das Produkt auch ohne. Es lässt sich dadurch der Preis erhöhen.). Die gewonnenen Erkenntnisse werden diskutiert.

XP zeichnet sich dadurch aus, dass die Größe einer Einheit wie Release oder Iteration unabhängig von ihrer Dauer betrachtet wird.

Aufwandsabschätzung

Bei der Release-Planung sind User Stories noch recht grobkörnig. Beschäftigt sich ein Team mit einer User Story genauer so wird sie, zusammen mit dem Kunden, detaillierter beschrieben. User Stories werden gewöhnlich in Story Points abgeschätzt, wobei auch eine Abschätzung in idealen Tagen möglich ist. Story Points sind relative Aufwandsabschätzungen, also der Entwicklungsaufwand für eine Story im Vergleich zu anderen. Dabei kann es sein, dass erste Abschätzungen im Verlaufe des Projektes geändert werden. User Stories werden in einem Planning Poker (auch als Planning Game bekannt) in mehreren Runden vom ganzen Team auf eine Punkte-Anzahl geschätzt.

User Stories werden zu Beginn der Iteration in feinkörnige, technische Tasks zerlegt, welche gewöhnlich einen Umfang von Stunden besitzen. Das Team schätzt die Dauer eines jeden Tasks. Es wird allerdings noch nicht festgelegt wer den Task realisiert. Erst wenn das Team bzw. ein Teammitglied Zeit findet wird der Task begonnen. Eine User Story ist erst abgeschlossen, wenn alle seine Tasks realisiert sind und die Tests geschrieben und alle erfolgreich durchlaufen sind.

User Stories mit Aufwandsabschätzung in Story Points

Vorlage:Highlight2|Story No.	Vorlage:Highlight2|Story	Vorlage:Highlight2|Abschätzung (Story Points)
1	Als Arzt kann ich alle Patienten sehen, die ich am Tage habe.	3
2	Als Arzt kann ich die Gesundheitsgeschichte meiner Patienten beauskunften.	5
3	Als Assistentin kann ich einem Patienten einen Termin geben.	3
4	Als Assistentin kann ich einem Patienten eine Verschreibung ausdrucken.	3

Velocity beschreibt den Durchsatz des Teams, also wieviel Story Points in einer Iteration realisiert werden können. Die Bestimmung der Velocity hilft abzuschätzen wie lange ein Release dauert bzw. wieviele Iterationen notwendig sind. Es ist normal, dass die Velocity des Teams nicht immer die gleiche ist.

Entwicklung und Abschluss

Täglich gibt es ein kurzes Stand-up Meeting. Jeder Entwickler berichtet was er am Vortag geleistet hat, was er heute leisten möchte und wo es ggf. Probleme gab. Ferner werden situativ Paare gebildet (Pair Programming). Im Laufe des Tages gibt es weiteren stetigen Austausch (Pair Negotiations), während die Entwickler die Funktionalität und die Tests programmieren.

Kann eine User Story in einer Iteration nicht abgeschlossen werden (z. B. weil die Tests nicht erfolgreich sind oder sich die Abschätzung als zu knapp bzw. der Umfang als zu groß herausgestellt hat), so wird sie gewöhnlich in mehrere kleinere aufgeteilt oder komplett in die nächste Iteration verschoben. Auch während einer Iteration kann sich durch Umpriorisierung des Kunden oder durch neue Erkenntnisse an der Zusammenstellung der Iteration etwas ändern. Ist die Iteration abgeschlossen schauen sich Vertreter des Managements, der Kunde (Akzeptanztest) oder andere Stakeholder das Produkt in der aktuellen Ausbaustufe an, und geben Feedback. So ist es denkbar, dass der Kunde während des Akzeptanztest neue Prioritäten setzt oder weitere Ideen hat.

Technische Unterstützung muss differenziert betrachtet werden. Einerseits wird bewusst auf technische Hilfsmittel verzichtet, so in etwa bei der Erstellung von User Stories. Diese werden gewöhnlich manuell erstellt. Andererseits wird die Technik aber auch exzessiv genutzt, so in etwa bei der automatisierten Integration und der automatisierten Durchführung von Tests. Darüber hinaus existieren Projektmanagement-Werkzeuge, welche sich auf die speziellen Rahmenbedingungen und Anforderungen XPs konzentriert haben (siehe Tools).

Ursprung und Abgrenzung

In Abgrenzung zu traditionellen Vorgehensmodellen wie dem ab 1970 genutzten Wasserfallmodell durchläuft der Entwicklungsprozess in XP immer wieder in kurzen Zyklen sämtliche Disziplinen der klassischen Softwareentwicklung (zum Beispiel Anforderungsanalyse, Design, Implementierung, Test). Nur die im aktuellen Iterationsschritt benötigten Merkmale werden implementiert. XP ist leichtgewichtiger: es wird keine komplette technische Spezifikation der zu entwickelnden Lösung vorausgesetzt (so gibt es beispielsweise kein Pflichtenheft).

Es waren Kent Beck, Ward Cunningham und Ron Jeffries, die in der Softwareentwicklung im C3-Projekt neue Wege einzuschlugen. Nach Jahren der Anwendung von aus heutiger Sicht traditionellen Vorgehensmodellen wie dem Wasserfallmodell haben es, aus Sicht der XP Vertreter, die Projektverantwortlichen nur unzureichend verstanden die Probleme und Risiken der Softwareentwicklung in den Griff zu bekommen. Viele Projekte kamen nie zu einem Abschluss oder überstiegen zeitlich und/oder kostentechnisch die Planung. Viele, gerade langläufige Projekte, deckten mit Abschluss zwar die zu Beginn spezifizierten Anforderungen ab, berücksichtigten allerdings unzureichend, dass Anforderungen sich ändern können oder erst im Laufe eines Projektes dem Kunden wirklich klar ist, wie das Produkt aussehen soll. Über Erfolg und Schwierigkeiten von Softwareprojekten liefert der Chaos-Report von The Standish Group regelmäßig fundierte Untersuchungen, wie beispielsweise 1994 .

Beigefügte Tabelle enthält eine Auflistung der von XP identifizierten Kerndisziplinen bei der Softwareentwicklung. Neben dem von XP verfolgten Ansatz zeigt die letzte Spalte den historischen, weit verbreiteten Ansatz respektive das Risiko. Nicht XP einsetzende Unternehmungen können ein Vorgehensmodell besitzen welches sich, bewusst oder unbewusst, mit diesen Disziplinen positiv auseinandersetzen.

Verbreitete XP-Kerndisziplinen und Risiken bei herkömmlicher Herangehensweise

Vorlage:Highlight2|Prinzip	Vorlage:Highlight2|XP	Vorlage:Highlight2|Traditionelles Vorgehen/Risiko
Kommunikation	Stetiger Austausch wird gefördert und erwartet.	Jeder muss zunächst mal seine Aufgaben lösen.
Mut	Offene Atmosphäre.	Angst vor versäumten Terminen und Missverständnissen mit Kunden.
Kollektives Eigentum	Alle Artefakte gehören dem Team.	Jeder fühlt sich nur für seine Artefakte verantwortlich.
Pair Programming	Zu Zweit am Rechner.	Jeder will und muss zunächst auf seine ihm zugewiesenen Aufgaben schauen.
Integration	Stetige Integrationen erlauben Feedback und erhöhen Qualität.	Seltene Integrationen da vermeintlich unnütz und Zeitverschwendung.
Testgetriebene Entwicklung	Testen hat sehr hohen Stellenwert.	Testen kostet nur Zeit. Getestet wird wenig, und wenn, dann manuell.
Kundeneinbeziehung	Kunde wird zur aktiven Mitarbeit aufgerufen.	Kunde ist selten Partner sondern nur die andere Seite des Vertrages.
Refactoring	Suboptimales Design und Fehler werden akzeptiert.	Fehler sind verpönt. Erstellte Artefakte laufen angeblich immer direkt perfekt.
Keine Überstunden	Einhaltung der regulären Arbeitszeit.	Stetige, regelmäßige Überschreitung der regulären Arbeitszeit.
Iterationen	Ein Release wird in viele handliche Iterationen unterteilt.	Iterationen sind nicht nötig, es wird an einem Release gearbeitet.
Stand-up Meeting	Täglicher strukturierter Austausch.	Große, lange, seltenere Projektmeetings. Personenanzahl und Inhalt häufig zu aufgebläht.
Dokumentation	Wo es Sinn macht.	Wichtiges Artefakt. Alles muss standardisiert dokumentiert sein. Dokumentation wird aber nicht genutzt.
Metapher	Ein gemeinsames Vokabular.	Kunde und Entwicklung sprechen in zwei Sprachen, häufig aneinander vorbei.
Team	Das Team ist sehr wichtig. Es existieren keine Rollen. Feedback wird von jedem erwartet.	Spezialistentum. Abschottung. Wissensmonopole.
Standards	Standards wo es Sinn macht.	Überregulierung. Starrer Prozess.
Qualität	Inhärenter Bestandteil.	Der Faktor, der als erster vernachlässigt wird, wenn Zeit oder Geld knapp werden.

Die drei XP-Begründer identifizierten die Werte und Prinzipien, und stellten dar, wie diese helfen die Herausforderungen der Softwareentwicklung zu meistern. Heute, über zehn Jahre nach den ersten XP-Schritten, erfreut sich XP und auch andere agile Methoden wachsender Beliebtheit. Untersuchungen von Forrester Research ergaben, dass in Nordamerika und Europa 2005 ca. 14 % aller Projekte mit agilen Methoden durchgeführt wurden und viele über einen Einsatz nachdenken. Neben der bekannten und verbreiteten agilen Methode XP hat auch Scrum eine gewisse Bekanntheit erlangt. Neben vielen Ähnlichkeiten zu XP gibt Scrum in bestimmten Bereichen Vorgaben bzgl. Iterationslänge, Protokollierung und Verfahren. Scrum nutzt ein eigenes Vokabular. Der kleinste gemeinsame Nenner aller agilen Vorgehensmodellen ist das Agile Manifest:

Individuen und Interaktionen haben Vorrang vor Prozessen und Werkzeugen.

Lauffähige Software hat Vorrang vor ausgedehnter Dokumentation.

Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen.

Auf Änderungen eingehen geht vor einen Plan strikt verfolgen.

Eine weitere gerne in diesem Zusammenhang angeführte Disziplin ist das Feature-Based Programming, eine Methodik die den Fokus ebenfalls auf die bereitzustellende Funktionalität setzt.

Gerade aufgrund der wachsenden Nutzung wird XP immer weiter optimiert und in der Praxis für die Praxis angepasst. Der Schritt von dem ursprünglichen XP-Ansatz hin zu der zweiten Evolutionsstufe XPs wird sicherlich nicht die letzte Evolutionsstufe bleiben.

Flexibilitätsgrad vs. Steifheit

Eine der theoretischen Grundlagen des Extreme Programming ist der Flexibilitätsgrad des zu entwickelnden Software-Systems. XP geht von einem mindestens proportionalen Zusammenhang zwischen dem Gegenteil der Flexibilität, der Steifheit, und den Pflege-Kosten zur Fehlerbehebung oder Erweiterung des Systems aus. Je flexibler ein Software-System, desto geringer sind die Pflege-Kosten, je steifer, desto höher.

Einige Steifigkeitskriterien:

• Zahl überflüssiger bzw. ungenutzter Features
• schlechte Dokumentation (fehlend, schwer verständlich, zu umfangreich)
• schwer verständlicher Entwurf
• steifer Entwurf
• fehlende Regressionstests
• schwerfälliges Gesamtsystem

Einige Flexibilitätskriterien:

• gute Dokumentation (vorhanden, leicht verständlich, vollständig aber nicht ausschweifend)
• leicht verständlicher Entwurf
• flexibler Entwurf
• Regressionstests
• leichtgewichtiges Gesamtsystem

Einige der als Bestandteil des Extreme Programming definierten Mechanismen dienen der Erhöhung der Flexibilität:

• Die testgetriebene Entwicklung sorgt für ein ausreichendes Vorhandensein von Regressionstests und eine verbesserte Testbarkeit der Software.
• Die ständigen Refactorings sorgen für eine Entfernung von Fehlern und einen leicht verständlichen, flexiblen Entwurf und trägt zu guter Dokumentation bei.
• Die kontinuierliche Integration erfordert zwangsläufig ein leichtgewichtiges Gesamtsystem.
• Um zu entwickelnde Fachlichkeit zu bestimmen und zwischen Kunde und Entwicklungsteam auszuarbeiten werden User Stories eingesetzt.

Kritik

XP gilt als schwerer einsetzbar in verteilten Umgebungen. Direkter Kontakt mit Entwicklern untereinander und dem Kunden ist problematisch, falls mehrere verschiedene Kunden existieren und/oder die Beteiligten räumlich getrennt arbeiten (z. B. Entwicklung ist teilweise outgesourced). Der „ideale Kunde“ ist manchmal nicht greifbar. Der Einsatz von XP in hoch-sensiblen Bereichen mit genau zu spezifizierenden Merkmalen (wie Automotive) bedarf besonderer Konzentration. Sowohl Eigenheiten in der Aufbauorganisation als auch die Komplexität und Anforderungen an die zu entwickelnde Fachlichkeit lassen sich mit XP dennoch meistern. Auch größere Teams werden als nicht geeignet angesehen nach XP zu entwickeln. Hier hilft eine Aufteilung in viele kleine Teams wobei die optimale Einzelteamgröße bei bis zu ca. 10 Personen liegt. Personen, die nicht gerne kommunizieren bzw. Probleme haben offen und ehrlich über die anfallenden Dinge zu reden werden Schwierigkeiten haben in XP-Projekten zu arbeiten. Es muss eine vertrauenswürdige Atmosphäre geschaffen werden. Einzelne Entwickler dürfen nicht an dem Umfang ihrer entwickelten Funktionalität dynamisch entlohnt werden, da das Team im Vordergrund steht und entscheidet.

Darüber hinaus gibt es spezifische Unternehmensumgebungen, welche auf den ersten Blick die Nutzung von XP erschweren. Dazu gehören:

1. Das Projekt wird weit im voraus geplant.
2. Das Projekt muss eine fixe Deadline halten und dabei eine genaue Anzahl von Funktionalität liefern.
3. Das Projekt geht von einer Unternehmung zu einer anderen über (oder: es wird outgesourced).
4. Anforderungen werden nur ganz oberflächlich verstanden.
5. Das Unternehmen ist recht starr und möchte nicht zu viel Flexibilität erlauben, auch bei Projekten die bezüglich Deadline und Funktionsumfang gar nicht starr sind.

Den Punkten ist gemeinsam, dass sie eine unverhältnismäßig große Unsicherheit beinhalten und/oder eine Ungenauigkeit der Aufwandsschätzungen sehr große Konsequenzen hätte. In einer solchen Umgebung empfiehlt es sich bei der Nutzung von XP sogenannte Feature Buffers und/oder Schedule Buffers einzuplanen, also Puffer im Funktionsumfang respektive beim Fertigstellungstermin. Implizite Funktionspuffer in einer Größenordnung von 30 % werden beispielsweise auch von Dynamic Systems Development Method (DSDM), einer weiteren agilen Entwicklungsmethode, angelegt.

Ein weiterer häufiger Kritikpunkt ist, dass XP für Festpreisprojekte nicht geeignet sei. Ansätze XP mit Festpreisprojekten zu vereinen sind: Versicherungsprämien auf die Schätzung, User Stories (bzw. die Story Cards) werden zum Vertragsgegenstand, Prognosen von Risiken auf Produktivität und Restaufwände oder besondere Preismodelle wie Aufwandspreis mit Obergrenze, Phasenfestpreis oder Anforderungseinheitspreis. Dem Kunden sollte es davon unabhängig wichtiger sein ein lauffähiges Produkt zu haben welches voll seinen Wünschen entspricht. Der ganze Entwicklungsprozess muss durch ständige Kommunikation begleitet werden.

Auch einzelne Praktiken stehen in der Kritik. So ist es teilweise schwer zu vermitteln, dass Pair-Programming laut XP tatsächlich eine Produktivitätssteigerung und besseres Design nach sich zieht. Für viele Personen sind zwei Personen an einem Rechner, wobei einer "nur zuguckt", nicht effizient, und dafür sei "keine Zeit da".

Tools (Auswahl)

• VersionOne Agile Lifecycle Management (proprietär)
• ProjectCards (proprietär)
• XPlanner (Open Source)

Siehe auch

• Wasserfallmodell – Vorgehensmodell
• V-Modell – Vorgehensmodell
• RUP – Vorgehensmodell
• Spiralmodell – Vorgehensmodell
• Agile Softwareentwicklung
• Scrum – Agiles Vorgehensmodell
• Dynamic Systems Development Method – Agiles Vorgehensmodell

Referenzen

Literatur

• Kent Beck: Extreme Programming – das Manifest. Die revolutionäre Methode für Softwareentwicklung in kleinen Teams, Addison-Wesley, 2000, ISBN 3-8273-1709-6
• Alistair Cockburn: Agile Softwareentwicklung, mitp, ISBN 3-8266-1346-5
• Martin Fowler: Refactoring, Addison-Wesley, ISBN 3-8273-1630-8
• Stefan Richter: Feature-based Programming, Addison-Wesley, ISBN 3-8273-2077-1
• Scott W. Ambler, Ronald E. Jeffries: Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process, Wiley, John & Sons, ISBN 0-471-20282-7
• Ronald E. Jeffries: Extreme Programming Adventures in C#, Microsoft Press, 2004, ISBN 0-735-61949-2
• Ronald E. Jeffries et al.: Extreme Programming Installed, Addison-Wesley Professional, 2000, ISBN 0-201-70842-6

Weblinks

• Agiles Manifest (englisch)
• Extreme Programming: A gentle introduction. (englisch)
• XP-Tagebuch, ein Tagebuch von Entwicklern, die Extreme Programming betreiben.
• Podcast zum Thema Extreme Programming vom Chaosradio
• XP (Cunningham) (englisch)
• The New Methodology (englisch)
• xp123.com (englisch)