Beschreibung und Analyse von Extreme Programming

Aus Winfwiki

Fallstudienarbeit
Hochschule:	Hochschule für Oekonomie & Management
Standort:	Düsseldorf
Studiengang:	Bachelor Wirtschaftsinformatik
Veranstaltung:	Fallstudie / Wissenschaftliches Arbeiten
Betreuer:	Prof._Dr._Uwe_Kern
Typ:	Fallstudienarbeit
Themengebiet:	Agile Softwareentwicklung
Autor(en):	Christian Klein, Monika Klein, Markus Günther
Studienzeitmodell:	Abendstudium
Semesterbezeichnung:	SS11
Studiensemester:	2
Bearbeitungsstatus:	begutachtet
Prüfungstermin:
Abgabetermin:

Inhaltsverzeichnis 1 Abkürzungsverzeichnis 2 Abbildungsverzeichnis 3 Einleitung 3.1 Problemstellung 3.2 Zielsetzung 3.3 Aufbau 4 Grundlagen 4.1 Einordnung und historischer Hintergrund 4.2 Werte 4.3 Prinzipien 4.4 Praktiken 4.4.1 Primärpraktiken 4.4.2 Begleitpraktiken 4.5 Prozess 4.5.1 Rollen 4.5.1.1 Programmierer 4.5.1.2 Kunde 4.5.1.3 Tester 4.5.2 Planung 4.5.3 Durchführung 5 Analyse 5.1 Betriebswirtschaftliche Betrachtung 5.2 Nutzen 5.2.1 Kundensicht 5.2.2 Entwicklersicht 5.2.3 Projektsicht 5.3 Risiken 5.4 Voraussetzungen für ein ideales XP-Projekt 6 Anwendungsbeispiele 6.1 Extreme Programming in Projekten 6.1.1 Studie zum Erfolg von XP 6.1.2 Projekt "Scooter" 6.2 Extreme Programming in der Lehre 7 Schlussbetrachtung 8 Fußnoten 9 Literatur- und Quellenverzeichnis

1 Abkürzungsverzeichnis

Abkürzung	Bedeutung
XP	Extreme Programming
IT	Informationstechnik
OO	Objektorientierung

2 Abbildungsverzeichnis

Abb.-Nr.	Abbildung
1	Extreme Programming
2	XP-Brücke
3	XP-Zyklen
4	Workflow eines Releases
5	Workflow einer Iteration
6	XP-Planungsstruktur
7	Refactoring
8	Änderungskostenkurve
9	Warum wurde für XP entschieden?
10	Gründe für den Projekterfolg

3 Einleitung

3.1 Problemstellung

Die elektronische Informations- und Datenverarbeitung ist in der heutigen Gesellschaft von großer Bedeutung. Der technische Fortschritt trägt viel dazu bei, dass heutzutage in fast allen Lebensbereichen für verschiedenste Funktionen der Computer benutzt werden kann. Aber auch in der Wirtschaft hat die Entwicklung der IT viele Bereiche verändert. Diese Entwicklung trägt dazu bei, dass immer mehr Software verwendet und somit auch gebraucht wird. Für die Entwicklung der Software ist es wichtig zu wissen, welche Methoden und Verfahren es gibt, zusammen mit Mitarbeitern eine qualitativ hochwertige Software herzustellen, die allen Ansprüchen gerecht wird und bzgl. Kosten und Zeit im Rahmen der unternehmerischen Vorgaben bleibt.

Extreme Programming beschäftigt sich mit einer Vorgehensart, wie Software entwickelt werden soll. Es ist ein relativ junges Verfahren und wird noch nicht oft eingesetzt. Interessant ist deshalb auch, die Potenziale von XP zu erkennen und Vermutungen aufzustellen, warum es sich noch nicht richtig in der Softwareentwicklung etabliert hat.

„Softwareentwicklung kann die Erwartungen nicht erfüllen. Dieses Scheitern hat weitreichende Auswirkungen im geschäftlichen und menschlichen Bereich. Wir müssen einen neuen Weg finden, Software zu entwickeln.“ ^[1]

Eine zunehmende Unzufriedenheit bei Kunden und Entwicklern mit Software macht sich bemerkbar. Die herkömmlichen Softwareentwicklungsprozesse können mit den Ansprüchen und Forderungen der Kunden und der Umsetzung dieser von den Entwicklern nicht mehr mithalten. Die klassischen Modelle wie das Wasserfallmodell können der zunehmenden Komplexität der Softwareentwicklungsprozesse nicht mehr gerecht werden. Außerdem können sie nur eingesetzt werden, wenn am Anfang des Projektes schon alle Anforderungen und Wünsche feststehen und sich während des Projektverlaufes nicht mehr ändern. Dadurch sind sie sehr unflexibel in ihren Einsatzmöglichkeiten. Änderungen, die ggf. vorgenommen werden müssen, sind mit einem erheblichen Aufwand verbunden und können deshalb sehr teuer werden^[2].

Die Softwareentwicklung benötigt somit ein Verfahren, welches mit diesen Problemen umgehen kann und zu einer zufriedenstellenden und erfolgreichen Lösung führt. Agile Softwareentwicklungsprozesse versuchen den Problemen aus klassischen Entwicklungsverfahren entgegen zu wirken. Das oberste Ziel ist die Kunden- und Entwicklerzufriedenheit. Deshalb soll während des Projektes ständig Rücksprache mit dem Kunden gehalten werden, denn es ist nicht mehr erforderlich alle Anforderungen vollständig vorher festzulegen. Der Kunde nimmt aktiv an der Entwicklung seines Produkts teil und spezifiziert es während der Entwicklung immer mehr. Ebenso können Probleme und Änderungen schneller und mit geringen Kosten gelöst werden.

3.2 Zielsetzung

In dieser Fallstudie soll erörtert werden, warum es seit einigen Jahren eine weitere Vorgehensweise bei der Entwicklung von Software gibt, um erfolgreich Software entwickeln zu können. Wieso ist XP so anders und warum soll es besser sein? Es wird untersucht, ob XP wirklich einen großen Erfolg verspricht und was die Gründe für diese Annahmen sind. Des Weiteren soll festgestellt werden, ob XP wirklich eine Revolution in der Softwareentwicklung darstellt oder ob das Thema von den Befürwortern zu positiv und erfolgreich dargestellt wird. Außerdem möchten wird die Nachteile von XP darstellen und herausfinden, wo in diesem Softwareentwicklungsprozess Risiken und Probleme liegen.

Darüber hinaus möchten wir auch einen Einblick in den praktischen Einsatz von XP vermitteln. Verspricht XP wirklich in jedem Projekt einen Erfolg oder scheitern Projekte auch trotz XP? Ist XP für alle Projekte geeignet oder gibt es Einschränkungen? Gibt es bekannte Projekte und eine Beurteilung der Zufriedenheit und des Erfolges? In einer betriebswirtschaftlichen Betrachtung soll XP aus der Sicht der Unternehmen in Bezug auf Kosten, Zeit, Umfang und Qualität beurteilt werden.

3.3 Aufbau

Zunächst wird XP von der theoretischen Seite betrachtet und es werden einige Grundlagen erläutert. XP beruht auf speziellen Werten, Prinzipien und Praktiken, welche einst vom Begründer von XP, Kent Beck, definiert wurden. Des Weiteren werden die drei wichtigsten Rollen in einem XP-Projekt kurz vorgestellt und der Prozess, wie ein XP-Projekt verläuft und welche Phasen es durchlaufen sollte, erklärt. Anschließend werden wir XP im Hinblick auf verschiedene Punkte analysieren. Hier wird zunächst eine betriebswirtschaftliche Betrachtung der vier Variablen Kosten, Qualität, Zeit und Umfang durchgeführt. Des Weiteren soll der Nutzen aus Sicht des Kunden, des Entwicklers und des Projektes beschrieben werden. Hier sollen vor allem die Vorteile und die positiven Aspekte von XP herausgestellt werden. Jedoch gibt es auch bei einem XP-Projekt Nachteile und Probleme, welche ebenso näher erläutert werden. Da XP nicht für jedes Projekt geeignet ist, werden im Kapitel Einsatzmöglichkeiten die Grenzen und Voraussetzungen für die erfolgreiche Durchführung eines XP-Projektes beschrieben. Zum Schluss werden noch konkrete Einsatzbeispiele in der Praxis genannt. So wird eine Studie zum Erfolg von XP sowie ein durchgeführtes XP-Projekt vorgestellt. Ebenso wird der Einsatz von XP im Studium erläutert.

4 Grundlagen

4.1 Einordnung und historischer Hintergrund

XP ist eine sogenannte „leichtgewichtige“ Softwareentwicklungsmethode, die auf eine Reihe von klassischen Elementen verzichtet, um so eine schnellere und effizientere Kodierung zu erlauben^[3]. Sie gehört zu den agilen Softwareentwicklungsverfahren, welche den Softwareentwicklungsprozess flexibler und schlanker gestalten^[4].

Die Begründung der Extreme Programming-Methode ist den drei Entwicklern Kent Beck, Ward Cunningham und Ron Jeffries zuzuschreiben. 1996 begannen sie mit ihrem ersten XP-Projekt beim Automobilhersteller Chrysler, welches jedoch fünf Jahre später, nach der Übernahme von Chrysler durch Daimler, eingestellt wurde^[5]. Kent Beck veröffentlichte 1999 den ersten Teil seines Extreme Programming Manifests. Er beschrieb die wesentlichen Werte, Prinzipien und Praktiken und definierte den Prozess sowie die Vorgehensweise. Diese wurde allerdings nach einigen Jahren überarbeitet und 2004 erschien sein zweites Werk. Extreme Programming ist noch sehr jung und entwickelt sich stetig weiter.

XP „ist ein Ansatz der Softwareentwicklung, der verschiedene, bereits etablierte Verfahren der Softwareentwicklung neu miteinander kombiniert.“^[6] Die Ziele sind „die Qualität zu verbessern und Kosten bei der Herstellung zu reduzieren“^[7], dabei steht das Lösen der Programmieraufgabe und die Kundenzufriedenheit im Vordergrund^[5].

4.2 Werte

Kent Beck beschreibt in der 2. Auflage des XP-Manifests „eXtreme Programming explained: Embrace Change, 2nd Edition“ fünf Werte: Kommunikation, Einfachheit, Feedback, Mut, Respekt. Diese Werte streben eine gegenseitige Unterstützung und Balance an^[8].

Kommunikation (engl. Communication)

Bei der Entwicklung im Team ist Kommunikation am wichtigsten. Wenn ein Entwickler Probleme während der Entwicklung bekommt und nicht in der Lage ist, ein Problem zu lösen, sollte er mit den anderen Teammitgliedern kommunizieren. Ohne Kommunikation findet kein Austausch des Wissens statt und das Problem bleibt bestehen. Deswegen ist es wichtig, mit Teammitgliedern zu sprechen, die in der Vergangenheit ähnliche Probleme hatten und somit zur Lösung beitragen können. Im Team wird besprochen, wie sichergestellt werden kann, dass das Problem nicht wiederkehrt. Zudem ist Kommunikation entscheidend für die Entstehung eines Teamgefühls und einer erfolgreichen Zusammenarbeit, jedoch reicht es nicht alleine für eine effektive Softwareentwicklung aus^[8].

Einfachheit (engl. Simplicity)

Es ist kompliziert, ein System so einfach zu halten, dass das Team sich heute nur mit dem aktuellen Problem auseinandersetzen muss. Eine einfache Lösung von gestern kann heute immer noch gut sein, oder schon wieder komplex wirken. Um die Einfachheit wiederzuerlangen, muss das Team einen Weg finden von dem Punkt an dem es steht zu dem Punkt an dem es sein möchte. Ziel ist es, nur kleine Teilaufgaben zu erarbeiten und somit keine unnötige Zeit in komplexe Lösungen zu vergeuden. Eine besser werdende Kommunikation hilft Einfachheit zu erlangen, indem unnötige und verschiebbare Anforderungen des heutigen Anliegens aussortiert werden^[8].

Feedback (engl. Feedback)

In der Softwareentwicklung haben Entscheidungen nur eine kurze Halbwertzeit, sodass Veränderungen unvermeidbar sind. Aus Veränderungen entsteht die Notwendigkeit von Feedback. Es wird genutzt um immer näher an die bestmögliche Lösung zu gelangen. Feedback erscheint in verschiedenen Formen:

• Meinungen über ein Idee
• Das Aussehen des Codes nach der Implementierung
• Ob es leicht war, die Tests zu schreiben
• Ob die Tests funktionieren
• Wie die Idee funktioniert wenn sie eingesetzt wird

XP Teams haben das Bestreben so viel Feedback wie sie verarbeiten können so schnell wie möglich zu geben. Umso früher Feedback gegeben wird, desto eher kann es angewendet werden^[8].

Mut (engl. Courage)

Leute, die in Softwareentwicklung involviert sind, fühlen Angst. Ob es sich um ein effektives Teammitglied handelt zeigt, wie es damit umgeht. Mut kann sich in einer Neigung zum Handeln manifestieren. Wenn das Problem bekannt ist, sollte es angegangen werden. Auf der anderen Seite kann Mut auch Geduld bedeuten. Wenn bekannt ist, dass es ein Problem gibt, aber nicht genau dessen Ursprung kennt, benötigt es den Mut zu warten, bis das eigentliche Problem zum Vorschein kommt und es behoben werden kann. Der Mut, die Wahrheit zu sagen, fördert die Kommunikation und das Vertrauen. Der Mut, gescheiterte Lösungen fallen zu lassen und neu anzufangen, unterstützt die Einfachheit. Der Mut, reale und konkrete Antworten zu suchen, erzeugt Feedback^[8].

Respekt (engl. Respect)

Die vorherigen vier Werte unterliegen dem Respekt. Wenn Teammitglieder ihre Arbeit untereinander nicht wertschätzen, kann XP nicht funktionieren. Wenn Teammitglieder sich nicht um ein Projekt sorgen, wird es zwingend scheitern. Deswegen hat jede Person in der Softwareentwicklung denselben Stellenwert als Mensch. Niemand ist mehr Wert als ein Anderer. Für ein besseres Miteinander und eine bessere Produktivität gilt, dass jeder Beitrag eines Teammitglieds respektiert wird^[8].

4.3 Prinzipien

Die Prinzipien stellen eine Verbindung zwischen den abstrakten Werten und den konkret anwendbaren Praktiken von XP her. Diese Prinzipien sollten immer beachtet und angewendet werden. Jedoch gibt es neben den von Kent Beck definierten Prinzipien auch weitere mögliche, welche in der Softwareentwicklung durchaus angewendet werden können^[9].

Kent Beck beschrieb in seiner ersten Auflage von „eXtreme Programming explained: Embrace Change“ fünf Grundprinzipien

• Unmittelbares Feedback (engl. Rapid Feedback)
• Einfachheit anstreben (engl. Assume Simplicity)
• Inkrementelle Veränderung (engl. Incremental Change)
• Veränderung wollen (engl. Embracing Change)
• Qualitätsarbeit (engl. Quality Work)

Neben diesen gab es noch zehn weitere XP-Prinzipien^[10].

Ende 2004 hat Kent Beck die zweite Auflage des XP-Manifests „eXtreme Programming explained: Embrace Change, 2nd Edition“ veröffentlicht. Die Prinzipien wurden fast vollständig neu formuliert.

Menschlichkeit (engl. Humanity)

Menschen entwickeln die Software^[9]. Die Mitglieder des Softwareentwicklungsteam stehen also in sozialen Beziehungen, die bei der Entwicklung der Software eine entscheidende Rolle spielen^[11]. Der Mensch braucht aber auch Zeit außerhalb des Teams um Energie und Motivation zu erhalten und um anderen menschlichen Bedürfnisse zu befriedigen^[9]. In einem Projektteam muss deswegen neben den geschäftlichen und wirtschaftlichen Interessen auch auf die Bedürfnisse der Projektmitglieder geachtet werden^[11]. Privates muss privat bleiben, nur dann kann eine effektivere Kommunikation im Job erfolgen^[9]. Es ist demnach wichtig eine Balance zwischen diesen Einflüssen auf das Privatleben und die Arbeit zu finden.

Wirtschaftlichkeit (engl. Economics)

Softwareprojekte kosten sehr viel Geld und somit müssen sie Geld bringen, indem sie einen Erfolg für das Unternehmen darstellen. Die Softwareentwickler müssen wirtschaftlich denken und ihre Tätigkeit sollte einen betriebswirtschaftlichen Wert haben und die wirtschaftlichen Ziele des Unternehmens verfolgen^[9]. Weitere Aspekte der Wirtschaftlichkeit sind, dass der Kunde langfristig am Unternehmen gebunden wird und dass sich dem Unternehmen neue Marktsegmente erschließen. „Softwareprojekte, die sich nicht rechnen, sind niemals ein Erfolg“^[11].

Gegenseitiger Vorteil (engl. Mutual benefit)

Gegenseitiger Vorteil ist das wichtigste Prinzip und das am schwersten einzuhaltende. Jede Aktivität sollte jedem Beteiligten einen Vorteil verschaffen. Auch im Hinblick auf die Wirtschaftlichkeit sollte ein Projekt nicht nur dem Unternehmen, sondern auch dem Kunden von Vorteil sein, um somit durch die Kundenzufriedenheit die Bindung des Kunden am Unternehmen zu erhöhen. Entwickler sollten die Software so entwickeln, dass sie nicht nur heute einen Vorteil bringt, sondern auch in der Zukunft^[9].

Selbstständigkeit (engl. Self-Similarity)

In der Softwareentwicklung sollte versucht werden, Strukturen von einer Lösung in einem neuen Kontext wiederzuverwenden, auch in einer ganz anderen Größenordnung. Es ist aber nicht garantiert, dass es dort auch funktioniert, es bietet aber Möglichkeiten und einen Ansatz zum Starten. Auch, nur weil eine Lösung einzigartig ist, heißt es nicht, dass diese unbrauchbar ist. Manche Probleme erfordern einzigartige Lösungen^[9].

Mannigfaltigkeit (engl. Diversity)

Softwareentwicklungsteams, in denen jedes Mitglied gleich ist, sind nicht effektiv. Teams müssen eine Vielfalt an Fähigkeiten, Einstellungen und Perspektiven zusammenbringen. So können sie auf eine vielseitige Weise Probleme lösen. Konflikte entstehen nur, wenn es mehrere Wege gibt, Probleme zu lösen und das Team sich daraufhin entscheiden muss, welche Lösung die beste ist. Dennoch darf dieser Konflikte nicht als eine Schwierigkeit oder als ein Problem betrachtet werden, denn die Möglichkeit, aus mehreren Lösungsvarianten zu wählen, ist keinesfalls schlecht^[9].

Fluss (engl. Flow)

Im Gegensatz zu Phasenmodellen, in denen Ergebnisse in großen Stücken und in langen Zeitabständen geliefert wird, sollen in einem XP-Projekt die Ergebnisse in einem ständigen Fluss an wertvoller und nützlicher Software geliefert werden. Diese stellen eine Basis dar, die anschließend laufend verbessert werden kann^[11]. Es genügt nicht, dass die Software jeden Tag kompiliert und verknüpft wird, sie sollte auch jeden Tag korrekt funktionieren, besser sogar zu jedem Zeitpunkt am Tag^[9]. Eine Voraussetzung, um Fluss in der Software zu gewährleisten ist das Arbeiten in kleinen Schritten und das permanente Erhalten und Geben von Feedback.

Verbesserungen (engl. Improvement)

Dass die Entwickler eines Projektes immer sofort alles richtig und gut machen, ist nicht zu erwarten. Auch Software wird stetig durch Weiterentwicklungen und neue Erkenntnisse der Technologien angepasst und verbessert. Dennoch sollte ein Entwickler, der vor einem Problem steht, bei dem er nicht weiß, wie die Lösung aussieht, versuchen Schritt für Schritt eine zu finden. Da dies allen Beteiligten klar ist, wird nicht verlangt, dass diese perfekt ist. Denn „durch das Umsetzen von nicht perfekten Lösungen lernt man viel, und dadurch kommt ein kontinuierlicher Verbesserungsprozess in Gang“^[12]. Um das zu erreichen, ist es wichtig, dass in dem Team miteinander kommuniziert wird. Nur so kann aus Feedback und selbst gewonnenen, neuen Erkenntnissen die Lösung ständig verbessert werden.

Reflexion (engl. Reflection)

Ein gutes und eingespieltes Team macht nicht nur gute Arbeit, sondern sie reflektieren auch über ihre Arbeit. Sie denken darüber nach, wie und warum sie ihre Arbeit machen. Sie analysieren ihre Erfolge und ihr Scheitern. Ein weiter Aspekt ist, dass ein Entwickler auch auf seine Emotionen achten sollte, denn auch unser Körper reflektiert über unsere Arbeit. Trotzdem sollte Reflexion nicht zu weit betrieben werden. Viele sind sehr damit beschäftigt über die Softwareentwicklung nachzudenken, so dass sie gar keine Zeit haben, um die Software überhaupt zu entwickeln. Ein Team sollte die Reflexionen immer auch mit Taten verknüpfen^[9].

Gelegenheit (engl. Opportunity)

Probleme werden in XP als Chancen für Veränderungen angesehen. Das bedeutet nicht, dass es keine Probleme in der Softwareentwicklung gibt. Deshalb müssen Probleme in Chancen des Lernens und des Fortschritts gewandelt werden. Das Drehen von Problemen in Gelegenheiten zieht sich durch den gesamten Entwicklungsprozess. Es maximiert Stärken und minimiert Schwächen^[9]. So besteht die Möglichkeit, aus Problemen, die für die meisten Schwierigkeiten darstellen, einen positiven Nutzen zu ziehen^[11].

Redundanz (engl. Redundancy)

Im Entwicklungsprozess sollten Redundanzen nicht vermieden werden. Kritische und schwierige Probleme sollten auf mehrere verschiedene Wege gelöst werden können. Selbst wenn eine Lösung gänzlich fehlschlägt oder ausfällt, wird eine andere Lösung ein Desaster verhindern^[9]. Es dient also auch der Risikominimierung und auf diese Weise kann ein Fluss garantiert werden. Die Kosten für diese Redundanzen lohnen sich aber. „In XP wird bspw. Das Problem von Programmfehlern durch Komponententests, Akzeptanztests, Programmieren in Paaren adressiert“^[11].

Fehlschlag (engl. Failure)

Fehschläge dürfen sich nicht negativ auf die Entwicklung auswirken, sondern müssen eine Möglichkeit bieten, aus diesen etwas wertvolles zu lernen, selbst wenn eine Lösung für ein und dasselbe Problem mehrmals fehlschlägt^[9]. Fehlschläge bei der Entwicklung oder Rückschläge im Team müssen hingenommen und als Gelegenheit zur Verbesserung wahrgenommen werden. Ebenfalls soll dieser Gedanke den Entwickler dazu motivieren, womöglich auch ein Scheitern zu riskieren anstatt nichts zu machen. Das kann der kürzeste und sicherste Weg zum Erfolg sein,^[9].

Kleine Schritte (engl. Baby Steps)

XP empfiehlt, die Implementierung der Software in kleinen Schritten vorzunehmen, denn dadurch bleibt das Team flexibler und kann sich schneller neuen Rahmenbedingungen anpassen, ohne dass Veränderungen schwerwiegende negative Folgen für das gesamte Projekt haben. Auf Feedback von anderen Beteiligten kann schneller reagiert werden, so dass Veränderungen schneller in das Projekt eingebracht und umgesetzt werden können. Außerdem werden durch kleine Schritte Risiken reduziert, denn ein nicht erfolgreicher Schritt kann leichter durch einen neuen Schritt ersetzt werden, mit weniger Aufwand und weniger Änderungen an anderen Teilbereichen, als dies bei einem wesentlich größeren Einzelschritt der Fall wäre. Die Schritte „erfolgen in schneller Folge, sodass trotzdem eine hohe Entwicklungsgeschwindigkeit daraus resultiert.“^[11].

Qualität (engl. Quality)

Es darf nie zur Diskussion stehen, die Qualität zu senken, um Kosten zu sparen oder einen frühen Endtermin einzuhalten. „Ganz im Gegenteil führen Investitionen in Qualität häufig zu schnellerer Entwicklung, während Abstriche bei der Qualität i. d. R. die Entwicklung verlangsamen“^[11]. In vielen anderen Softwareentwicklungsmethoden muss die Software zu einem bestimmten Zeitpunkt und in einem definierten Funktionsumfang fertiggestellt werden. Das hat meistens eine geringere Qualität zur Folge. Gerade die Qualität ist allerdings wichtig, um das Produkt einsatzfähig, fehlerfrei und erweiterbar zu halten.

Akzeptierte Verantwortung (engl. Accepted Responsibility)

Verantwortung kann nicht zugewiesen werden, sie muss akzeptiert werden^[9] Zusammen mit der Verantwortung kommt die Autorität. Eine Abweichung führt zu Kommunikationsproblemen. Ein Entwickler, der sich einer Story annimmt, akzeptiert die Verantwortung für das Design, die Programmierung und das Testen dieser Story. Gleichzeitig hat er die Autorität, über das Design für diese Story zu entscheiden.

4.4 Praktiken

Kent Beck formuliert 24 Praktiken, die beim Extreme Programming zum Einsatz kommen. Sie sorgen dafür, dass bei der Entwicklung die Werte und Prinzipien eingehalten werden. Dabei wird zwischen Primär- und Begleitpraktiken unterschieden. Die Begleitpraktiken sollen erst angewendet werden, wenn zuvor die Primärpraktiken eingesetzt wurden.^[13]

4.4.1 Primärpraktiken

Zusammen sitzen (engl. Sit Together)

Alle Entwickler sitzen zusammen in einem genügend großen Raum. In unmittelbarer Nähe befinden sich auch abgetrennte Bereiche, falls eine Person den Wunsch nach Privatsphäre hat. Durch die direkte Kommunikation wird der Informationsfluss wesentlich verbessert und es entstehen weniger Missverständnisse und daraus resultierende Fehler^[13].

Vollständiges Team (engl. Whole Team)

Es werden funktionsübergeifende Teams gebildet, in denen sich die Mitglieder gegenseitig unterstützen. In den Teams sind alle nötigen Ressourcen (Wissen, Know-How) für die Zielerreichung vorhanden. Bei Bedarf werden die Teams an die aktuelle Problemstellung angepasst^[13].

Bei der Teambildung sind zwei Werte zu beachten: zwölf und 150. Zwölf Menschen können innerhalb eines Arbeitstages bequem miteinander agieren. Bei mehr als 150 Mitgliedern ist es einem Mitglied nicht mehr möglich, jeden zu erkennen. Diese Grenzen sollten zwecks einer guten Zusammenarbeit (basierend auf Vertrauen und Verlass) nicht überschritten werden^[13].

Informativer Arbeitsplatz (engl. Informative Workspace)

Am Arbeitsplatz sind alle wichtigen Informationen zum Projekt sichtbar. Darunter fallen z. B. der aktuelle Status des Projekts, die aktuellen Aufgaben für das Team und die Stories (s. Primärpraktik "Stories"). Diese Informationen werden z. B. gut sichtbar an Flipcharts geschrieben^[13].

Energievolle Arbeit (engl. Energized Work)

Um die Motivation für die Arbeit aufrecht zu halten sowie eine entspannte und angenehme Atmosphäre zu schaffen, arbeiten die Entwickler ohne Überstunden. Dadurch wird verhindert, dass sich einzelne Entwickler verausgaben. Überstunden sind verantwortlich für das vermehrte Auftreten von Fehlern, welche das Team letztlich verlangsamen^[13].

Programmieren in Paaren (engl. Pair Programming)

Dies ist eine zentrale Praktik des Extreme Programmings. Jegliche Programmierarbeit (Entwurf, Kodierung und Test) wird immer von zwei Entwicklern gemeinsam durchgeführt.Beide Programmierer sitzen dabei nebeneinander vor dem gleichen Computer. Einer der Entwickler schreibt den Programmcode, während der zweite diesen auf Syntax- und Logikfehler überprüft. Aufgefallene Fehler werden sofort angesprochen und im Gespräch beseitigt. Außerdem wird die Einhaltung der im Entwurf definierten Ziele überwacht. In regelmäßigen Abständen tauschen die beiden Entwickler die Rollen, ebenso wechselt die Zusammensetzung der Paare. Dadurch entsteht ein Wissenstransfer, da Programmieranfänger von erfahrenen Kollegen lernen können. Beim Ausscheiden einzelner Programmierer geht dann nicht das komplette Wissen verloren. Diese Vorgehensweise erscheint auf den ersten Blick ineffizient. Durch die permanente und gegenseitige Kontrolle weist der Programmcode jedoch sehr wenige Fehler auf^[13].

Wöchentlicher Zyklus (engl. Weekly Cycle)

Die Dauer einer Iteration beträgt eine Woche. Zu Beginn wird in einem Meeting kurz der aktuelle Projektstatus besprochen und entschieden, welche der Stories als nächstes umgesetzt werden. Die Stories werden in Aufgaben unterteilt und an die Entwicklerpaare verteilt. Vor der eigentlichen Programmierung werden die Tests für die Story geschrieben. Am Ende der Woche werden die fertigen Programmteile getestet^[13].

Quartalsweiser Zyklus (engl. Quarterly Cycle)

In quartalsweisen Abständen werden Releases der Software erstellt. Der Kunde erhält ein lauffähiges System und gibt Feedback. Durch diesen kurzen Zyklus wird sichtbar, ob sich die Zielvorstellungen auseinander bewegen und es kann rechtzeitig gegengesteuert werden (Risikominimierung)^[13].

Stories

Die Anforderungen des Kunden für das nächste Release werden (im Idealfall durch ihn selber) in sog. Stories auf Karteikarten notiert. Dabei wird keine konkrete Technik beschrieben, sondern die Anforderung aus rein fachlicher Kundensicht. Der Entwicklungsaufwand wird vom Entwicklerteam geschätzt, welches auch entscheidet, zu welchem Zeitpunkt innerhalb einer Iteration bzw. eines Releases eine Story abgearbeitet wird. Details zu den einzelnen Anforderungen werden erst während der Entwicklung mit dem Kunden besprochen. Mit Hilfe von Akzeptanztests mit dem Kunden wird geprüft, ob die Anforderungen erfüllt wurden^[13].

Freiraum (engl. Slack)

Während der Projektdurchführung bekommen die Entwickler Freiräume, um sich über Dinge zu informieren, die nicht unmittelbar mit dem Projekt verknüpft sind. Dadurch bekommen Sie Abstand zum Projekt und können womöglich neue Ideen einbringen^[14].

10-Minuten-Build (engl. Ten-Minute Build)

Das automatisierte Erstellen des gesamten Programms und die Durchführung aller Tests darf maximal zehn Minuten dauern. Dadurch bleibt die Aufmerksamkeitsspanne der Entwickler erhalten, sodass unmittelbares Feedback erfolgen kann. Es ist wichtig, dass beim Build das gesamte Programm erstellt und getestet wird. Dadurch werden auch etwaige negative Auswirkungen auf bereits fertigen und getesteten Code sichtbar^[13].

Kontinuierliche Integration (engl. Continuous Integration)

Beim XP hat jeder Entwickler die Möglichkeit, in jedem Teil des Programmcodes Änderungen durchzuführen. Dazu müssen geänderte Quelltexte schnell dem gesamten Entwicklerteam zur Verfügung gestellt werden. Dies geschieht mit Hilfe der kontinuierlichen Integration. Geänderte Quelltexte werden mehrmals am Tag in die gemeinsame Codebasis integriert. Dafür steht ein "Integrationsrechner", der nur für die Integration neuer Quellen genutzt wird, bereit. Sobald ein Entwickler einen neuen Quelltext in das System eingespielt hat, wird das Gesamtsystem mit den zuvor festgelegten Testfällen automatisiert getestet. Erst bei erfolgreichem Bestehen aller Tests darf die Quelltextänderung auf dem Integrationssystem belassen werden. Bei einem negativen Ergebnis müssen die Entwickler wieder für ein ordnungsgemäßes Gesamtsystem sorgen. Entweder sie ändern erneut den Quelltext und testen bis alle Tests erfolgreich abgeschlossen wurden oder sie machen sämtliche Änderungen rückgängig. Dadurch wird sichergestellt, dass sich auf dem Integrationsrechner zu jeder Zeit eine lauffähige Version des Gesamtsystems befindet^[15].

Test-First-Programmierung (engl. Test-First Programming)

Vor dem eigentlichen Erstellen des Programmcodes werden automatisierte Tests geschrieben. Eine Programmieraufgabe ist erst abgeschlossen, wenn die Tests fehlerfrei ausgeführt werden. Anschließend werden mit dem Kunden Akzeptanztests durchgeführt^[13].

Inkrementelles Design (engl. Incremental Design)

Die Software wird schrittweise anhand der Kundenanforderungen erstellt. Dabei wird auf Features, die u. U. doch nicht zum Einsatz kommen, verzichtet. Es werden nur die konkret bekannten Anforderungen berücksichtigt^[16]. Außerdem wird kein Gesamtentwurf vor der eigentlichen Programmierarbeit erstellt. Refaktorisierung spielt in diesem Zusammenhang eine wichtige Rolle. Damit ist die schrittweise Optimierung des Codes anhand von Kundenfeedback und neuen Anforderungen gemeint^[13].

4.4.2 Begleitpraktiken

Echte Kundenbeteiligung (engl. Real Customer Involvement)

Der Kunde wird in die Entwicklungsarbeit einbezogen indem er an den wöchentlichen und quartalsweisen Meetings teilnimmt. Ein Vertreter des Kunden ist im Idealfall 100% seiner Arbeitszeit beim Entwicklerteam vor Ort. Er schreibt die Stories und die Akzeptanztests selber und dient den Entwicklern als Ansprechpartner für fachliche Fragen^[17].

Inkrementelle Verteilung (engl. Incremental Deployment)

Die Verteilung der Software-Releases soll schrittweise erfolgen. Es geht dabei insbesondere um die Ablösung existierender Systeme. Dort soll nicht auf einen einzigen großen Tag für die Systemumstellung hingearbeitet werden, sondern Teile des existierenden Systems sollen schrittweise durch das neue ersetzt werden. Auch diese Praktik dient der Risikominimierung, indem durch frühe Integration eines Teil des neuen Systems und den damit verbundenen Tests Fehlentwicklungen reduziert werden. Außerdem kann der Geschäftswert der Anwendung früh genutzt werden^[16].

Team-Kontinuität (engl. Team Continuity)

Effektiv arbeitende Entwicklerteams sollten zusammen bleiben. In vielen großen Organisationen ist es üblich, dass Entwickler gleichzeitig an mehreren Projekten arbeiten. Dies verringert die Produktivität des einzelnen Entwicklers, da beim Projektwechsel ein Kontextwechsel durchgeführt werden muss. Des Weiteren ist eine hohe personelle Fluktuation auf Grund der erforderlichen Kommunikations- und Einarbeitungsaufwände zu vermeiden^[18].

Schrumpfende Teams (engl. Shrinking Teams)

Sobald einzelne Entwickler Freiräume haben, ist es Zeit, das Team zu verkleinern. Die dadurch freigesetzten Entwickler können wiederum neue Teams formen und an anderen Projekten mitwirken. Dadurch wird die Arbeitslast eines Entwicklerteams auf einem konstanten Niveau gehalten, da sich mit der Zeit eine gesteigerte Produktivität einstellt. Der freigesetzte Mitarbeiter muss jedoch vollständig entbehrlich sein, bevor er sich einem neuen Team bzw. Projekt zuwenden darf^[18].

Urpsrungsursachen-Analyse (engl. Root-Cause Analysis)

Bei der Urpsrungsursachen-Analyse wird ein Problem hinsichtlich der Ursache detailliert analysiert. Es wird fünf Mal die Frage „Warum?“ gestellt. Lt. Beck stellt sich in den meisten Fällen eine menschliche Ursache für das Problem dar^[17]. Das Verfahren eignet sich jedoch nur bei ausgesuchten Problemen^[18].

Gemeinsamer Code (engl. Shared Code)

Jeder Entwickler darf den kompletten Code verändern und die Verantwortung für den Code liegt beim gesamten Team. Ohne eine gemeinsame Verantwortung machen Entwickler Codeänderungen, ohne Rücksicht auf Konsequenzen für das gesamte Team^[17]. Damit dies funktioniert, sollten die einzelnen Entwickler einen Überblick über das Projekt haben und eine ungefähr gleiche Qualifikation vorweisen.

Code und Tests (engl. Code and Tests)

Die einzigen Artefakte, die erstellt und gepflegt werden, sind der Code und die Tests. Eine Dokumentation bspw. wird nicht explizit erstellt. Sie soll vielmehr aus dem aussagekräftigen Code (dank ausreichender Kommentierung) und den Tests generiert werden^[17].

Eine Codebasis (engl. Single Code Base)

Es existiert lediglich eine Codebasis, sodass die Entwicklung mit mehreren Entwicklungszweigen vermieden wird. Temporäre Entwicklungszweige sind allenfalls für ein paar Stunden erlaubt. Da sich die verschiedenen Zweige in unterschiedliche Entwicklungsstadien befinden ist eine Zusammenführung sehr aufwändig, wodurch viel Zeit verloren geht. Das Vorhandensein von Entwicklungszweigen ist meist ein Anzeichen für grundlegende Designfehler, die zunächst behoben werden sollten^[17].

Tägliche Verteilung (engl. Daily Deployment)

Der aktuelle Entwicklungsstand sollte täglich an die Anwender verteilt werden. Auf Grund der hohen Anforderung (hoher Aufwand mit erhöhtem Stressrisiko) muss diese Praktik bereits in der Projektplanung berücksichtigt werden. Gelingt diese Verfahrensart wird die Verbreitung zur Routine und es werden Kosten minimiert. Der Entwickler bekommt sofort Feedback durch den Anwender, wodurch das Risiko durch Fehlentwicklungen verringert wird. Der Anwender muss jedoch wissen, dass er womöglich täglich ein geändertes System vorfindet^[19].

Vertrag mit verhandelbarem Umfang (engl. Negotiated Scope Contract)

Verträge werden mit fixen Kosten, fixem Termin und Qualität festgelegt, jedoch mit verhandelbarem Funktionsumfang. Es ist auch ratsam mehrere kleine aufeinander aufbauende Verträge abzuschließen, anstatt einem großen. Dadurch wird der Kunde ermutigt, Feedback zu geben und überflüssige (nicht benötigte) Entwicklungen werden vermieden^[17].

Zahlung pro Benutzung (engl. Pay-Per-Use)

Das System (typischerweise Release) wird nicht zu einem Festpreis verkauft, sondern der Kunde bezahlt pro Nutzung einzelner Funktionen. Entwickler versuchen, die Software so zu gestalten, dass die profitabelsten Funktionen noch häufiger genutzt werden. Um die Nutzungshäufigkeit zu erhöhen, steht die Kundenzufriedenheit an erster Stelle. Für beide Parteien bedeutet dies einen Vorteil: für den Kunden erhöht sich der Geschäftswert, für den Entwickler erhöhen sich die Umsätze^[19].

4.5 Prozess

4.5.1 Rollen

4.5.1.1 Programmierer

Programmierer sind anders als bei klassischen Vorgehensmodellen, z. B. dem Wasserfallmodell, nicht nur an der Umsetzung eines Systems in Quellcode beteiligt, sondern auch an dessen Entwurf, der Dokumentation und dem Testen des Systems. Der Entwurf des Kunden in Form einer Story-Card wird in logische Einheiten der Softwareentwicklung übersetzt. Dabei verfolgt der Programmierer das Ziel, die Vorgaben in ein leicht testbares, strukturiertes und funktionsfähiges System umzusetzen. Die Dokumentation ist bei der Codierung ein fester Bestandteil des Quellcodes, damit gewährleistet ist, dass der Quelltext und die Dokumentation konsistent und aktuell sind. Zudem gehört das Testen zu den Aufgaben des Programmierers. Dies sind zum einen regelmäßige Komponententests und Akzeptanztests, die vom Anwender vorgegeben werden^[20].

Wichtigste Qualifikationen des Programmierers:

• Kenntnisse über alle eingesetzten Mittel, z. B. der Programmiersprache oder Server
• Eine gute Kommunikations- und Kritikfähigkeit

4.5.1.2 Kunde

Obwohl XP für möglichst einfache Lösungen steht, können die Rollen des Auftraggebers und des Anwenders nicht von ein und derselben Person übernommen werden. Diese Variante hat den Vorteil, dass nur eine Person die Entscheidungen trifft und es weniger Kommunikationsaufwand und somit ein Zeitersparnis gibt. Da diese Person häufig aus dem fachlichen Bereich stammt, würde die Seite der finanziellen Verantwortung nicht mehr vor Ort an der Projektplanung und der Projektführung teilnehmen können. Aus verschiedenen Projekten hat sich gezeigt, dass dies zu Problemen führen kann, sodass die Rolle des Kunden in Auftraggeber und Anwender aufgeteilt wird^[21].

Auftraggeber

Der Auftraggeber präsentiert die finanzielle Verantwortung, indem er einerseits die finanziellen Mittel zur Verfügung stellt und andererseits die geschäftspolitischen Ziele vorgibt, z. B. eine Kostenreduzierung für einen bestimmten Teilbereich. Da der Projekterfolg von der Rolle des Auftraggebers abhängig ist, muss diese einigen Verpflichtungen nachkommen^[21].

Verpflichtungen:

• Für Rückfragen zur Verfügung stehen
• Er muss den Entwicklern Vertreter des fachlichen Bereichs zur Verfügung stellen
• Teilnahme am Planungsspiel des Releaseplans und an den Iterationen

Anwender

Der Anwender präsentiert den fachlichen Bereich mit Kenntnissen von den alltäglichen Arbeitsschritten und muss diese den Programmierern vermitteln, sodass ein wirklich nützliches System entstehen kann. Seine Hauptaufgabe liegt darin, die Anforderungen an das System verständlich, umsetzbar und testbar in Stories zu definieren. Da der Anwender häufig das Schreiben der Stories noch erlernen muss, wird dieser von den Entwicklern unterstützt und erhält Feedback um seine Fähigkeiten zu verbessern. Zudem steht er den Entwicklern bei Unklarheiten und fachlichen Fragen zur Verfügung. Um die fehlerfreie Umsetzung der Stories zu überprüfen, definiert er in Zusammenarbeit mit dem Tester Akzeptanztests^[21].

Wichtigste Qualifikationen des Anwenders:

• Kenntnisse über den Ablauf und die Erledigung der Aufgaben im Anwendungsbereich
• Aufgeschlossenheit gegenüber neuen Technologien
• Motivation durch eigene Vorteile (Gehaltserhöhung, leichtere Arbeitsabläufe dank neuer Software)

4.5.1.3 Tester

Obwohl in der Literatur empfohlen wird, dass Entwickler ihren eigenen Quellcode nicht selber Testen sollen, ist dies bei XP aufgrund der Test-First-Programmierung nicht anders möglich. Zudem sind die Komponententests so eng mit der Kodierung verbunden, dass diese von den Programmieren selbst übernommen werden. Die Hauptaufgabe des Testers ist es, den Kunden bei der Formulierung und Umsetzung von Akzeptanztests zu unterstützen. Er ist in der Lage, zusammen mit dem Kunden die Tests zu definieren und anschließend mit geeigneten Werkzeugen zu implementieren. Zudem ist er dafür verantwortlich, dass die Akzeptanztests regelmäßig ausgeführt werden und somit der Projektfortschritt überwacht werden kann. Um Tests sinnvoll durchführen zu können, muss der Tester einen detaillierten Überblick von dem Entwicklungsprozess und dem zu entwickelnden System haben, damit er sich nicht an Kleinigkeiten, wie z. B. der Ausrichtung von Textfeldern, stören lässt, sondern die Gesamtfunktionalität im Auge behält^[22].

4.5.2 Planung

Selbst bei XP wird geplant, obwohl, anders als bei anderen Prozessmodellen, es keine umfangreiche Planung am Anfang des Projekts gibt. Auf Grund der ständig wechselnden Kundenanforderungen muss die Planung von Iteration zu Iteration stattfinden. Falls nötig, kann dies sogar mehrmals am Tag vorkommen^[23].

Release (Version)

Bei XP wird die Projektdauer in mehrere Releases eingeteilt, die in der Regel zwischen einem und drei Monaten dauern. Welche Funktionen in welchem Release umgesetzt werden, wird mit Hilfe eines Planungsspiels vom Kunden und den Entwicklern festgelegt. Am Ende eines jeden Releases steht ein funktionsfähiger Prototyp, der es dem Kunden erlaubt, frühzeitig Feedback zu geben. Durch die ständigen Releases steigt das Vertrauen gegenüber den Entwicklern, da der Kunde die Zwischenstände ihrer Arbeit begutachten kann. Releases werden ihrerseits nochmal unterteilt in eine oder mehrere Iterationen^[24].

Iterationen

Um während eines Releases weiter flexibel auf die Änderungen durch den Kunden reagieren zu können, werden diese in ein oder mehrere Iterationen aufgeteilt, die in der Regel eine Woche dauern. In einem weiteren Planungsspiel werden aus den formulierten Stories Aufgaben definiert, die von den Programmierern während einer Iteration umgesetzt werden sollen^[24].

Planungsspiel

Am Anfang eines jeden Zyklus, sowohl eines Releases als auch bei jeder Iteration, findet das Planungsspiel statt. Zunächst werden die Anforderungen des Kunden auf Kärtchen, so genannten Story-Cards, schriftlich notiert, damit lediglich genug Platz vorhanden ist, um die Kernpunkte heraus zustellen. Im Anschluss werden die Stories vorgestellt und die Programmierer schätzen, welcher Aufwand mit der Umsetzung der einzelnen Stories verbunden ist. Aufgrund dieser Einschätzung und der Analyse, welche Story den größten Nutzen und das größte Risiko birgt, über den größten Nutzen und dem geringsten Risiko bis hin zum geringsten Nutzen und dem geringsten Risiko, legt der Kunde fest, welche Story in dem kommenden Release umgesetzt werden soll oder verschiebt sie auf eine späteres Release. Somit werden nur Ressourcen gebunden, die für das nächste Release benötigt werden. Falls im weiteren Verlauf eine Anforderung hinzukommt, wird eine neue Story-Card erstellt. Sollte eine Umsetzung einer Story unnötig werden, wird die Karte einfach zerrissen. Für die einzelnen Iterationen werden die Story-Cards in mehrere Aufgaben (Tasks) aufgeteilt und die Programmierer verteilen diese untereinander auf und übernehmen die Verantwortung für deren Umsetzung^[23].

Stand-up-Meeting

Das Stand-up-Meeting dient zum einen der Planung, bzw. dem aktuellen Entwicklungsstand, als auch um Feedback zu erhalten. Dieses Treffen findet täglich im Stehen statt, damit jedes Teammitglied nur kurz berichten kann, welche Aufgaben er am Vortag bearbeitete, ob es Probleme gab und mit welchen Aufgaben er heute beschäftigt sein wird. Damit soll außerdem die Dauer auf maximal fünf Minuten begrenzt werden^[25].

4.5.3 Durchführung

Nicht anders als bei klassischen Entwicklungsprozessen, besteht die Durchführung mit XP auch aus einem Design, dem Programmieren und dem Testen. Jedoch gibt es in der Umsetzung große Abweichungen^[25].

Design

Das Design wird einfach gehalten und mit bildhaften Metaphern umschrieben, damit die Wünsche des Kunden schnell verstanden und umgesetzt werden können. Da sich die Kundenwünsche ständig ändern und immer neue Anforderungen hinzukommen, wird im Vorfeld nur das einfachste Design anhand von vier Regeln erstellt^[26].

Regeln:

• Es müssen alle Tests erfolgreich beendet werden, die gewährleisten, dass die Kundenanforderungen in der Praxis fehlerfrei umgesetzt wurden
• Idee des Entwicklers muss zum Ausdruck kommen
• Kein doppelter Programmcode
• Es hat die wenigsten Klassen und Methoden

Durch ständiges Refactoring wird das Design im Entwicklungsprozess mitentwickelt und entspricht immer der einfachsten Lösung, sodass das Testen, die Wartung oder ein weiteres Refactoring unkompliziert sind^[26].

Refactoring

Falls die vier Regeln des einfachsten Designs nicht mehr eingehalten werden, findet ein Refactoring des Quellcodes statt. Dabei werden keine neuen Funktionen implementiert, sondern bestehende Abschnitte werden verbessert um den Code unkomplizierter und verständlicher zu machen. Im Anschluss müssen die Komponententests wiederholt werden, damit nicht unbeabsichtigt einzelne Funktionen fehlerhaft wurden. Der Aufwand hält sich aber in Grenzen, da die Tests automatisiert ablaufen. Das Ziel eines Refactoring ist, dass der Quellcode und das Design ständig optimiert werden^[27].

Programmieren

Beim XP ist die Programmierung auf verschiedene Praktiken und darüber hinausgehende Methoden aufgebaut. Dies ist zum Ersten, das Programmieren in Paaren. Dabei sind die jeweiligen Partner für verschiedene Aufgaben eingeteilt. Während der Eine programmiert, kontrolliert der Zweite ob Fehler auftreten, eine einfachere Lösung möglich ist oder steht für Nachfragen zur Verfügung. Diese beiden Rollen werden regelmäßig getauscht, sodass ein Wissensaustausch zwischen den beiden Partnern stattfindet. Des Weiteren hat das den positiven Effekt, dass die Software wenige Fehler enthält und damit Zeit bei einer möglichen Korrektur eingespart wird^[28].

Zum Zweiten wird die Praktik der echten Kundenbeteiligung genutzt, da die Kundeneinbeziehung in den Entwicklungsprozess sehr wichtig beim XP ist. Der Kunde steht zur Beantwortung kurzzeitig aufgetretener Fragen zur Verfügung und ist in der Lage, wichtige Entscheidungen ohne längere Verzögerung des Prozesses zu treffen^[28].

Zum Dritten gibt es den gemeinsamen Code. Darunter versteht XP, dass jeder Programmierer auf den gesamten Quellcode zugreifen kann, Veränderungen durchführen darf und das ganze Team die Verantwortung für einen fehlerfreien Quellcode trägt. Dies wird möglich, da nach einem Refactoring die automatisierten Tests erfolgreich durchlaufen werden müssen^[29].

Des Weiteren wird auf eine kontinuierliche Integration geachtet. Sobald eine Aufgabe fertig gestellt wurde, wird diese zum Gesamtsystem hinzugefügt. Dies passiert stündlich. Um Komplikationen bei der Integration zu vermeiden, wird extra ein separater Computer eingerichtet, an dem immer nur ein Team seine Änderungen vollziehen kann^[29].

Damit die Entwickler sich in fremden Quellcode schnell zurecht finden können, ist es sehr wichtig, Programmierstandards zu definieren und das diese strikt eingehalten werden. Darüber hinaus kommt eine Dokumentation zum besseren Verstehen des Quellcodes hinzu. Diese ist ein fester Bestandteil des Quellcodes, da somit alle wichtigen Informationen an einer Stelle zusammen kommen und häufige Abänderungen an einer separaten Dokumentation zu viel Zeit in Anspruch nehmen würden^[29].

Testen

Um eine möglichst hohe Qualität gewährleisten zu können, nimmt das Testen eine sehr wichtige Rolle im Entwicklungsprozess ein. Es wird zwischen Komponententests, die vom Programmierer definiert werden, und den vom Kunden formulierten Akzeptanztests unterschieden^[30].

Komponententests werden verfasst, bevor die eigentliche Programmierung einer Aufgabe beginnt. Im Wechsel wird nun für jedes Code-Fragment erst der Test geschrieben und im Anschluss solange implementiert, bis der dafür verantwortliche Test bestanden wurde. Somit erhält der Programmierer in kürzester Zeit ein Feedback und spart Zeit, da eine zeitraubende Fehlereingrenzung dank der kleinschrittigen Tests entfällt. Dahingegen kontrollieren Akzeptanztests, ob die neu implementierte Funktionalität den Kundenanforderungen entspricht^[30].

5 Analyse

5.1 Betriebswirtschaftliche Betrachtung

Jedes Softwareprojekt verfügt über vier Variablen:

• Kosten
• Qualität
• Zeit
• Umfang

Zwischen diesen Variablen besteht ein Zusammenhang, da sie sich gegenseitig beeinflussen. Beim Extreme Programming werden drei der vier Variablen extern festgelegt (durch den Kunden oder durch das Management), wodurch sich die verbleibende vierte Variable ergibt. Das bedeutet, die verbleibende Variable wird vom Entwicklerteam festgelegt, wodurch das Enwicklerteam die Arbeitsbedingungen beeinflussen kann. Die Variablen können während der Projektdurchführung verändert werden, sie beeinflussen sich dabei gegenseitig. Diese Auswirkungen sind allerdings verzögert und nicht linear. Bspw. ist es nicht möglich, durch eine Kostenverdoppelung (während die anderen Faktoren unangetastet bleiben) die Zeit zu halbieren^[31].

Die Zufriedenheit der einzelnen Entwickler ist ein zentraler Aspekt beim XP. Die Programmierer sollen ein möglichst optimales Arbeitsumfeld vorfinden. Das bedeutet, es müssen ggf. Anfangsinvestitionen in neues Arbeitsequipment wie z. B. große Monitore und schnellere Computer getätigt werden^[32]. Außerdem muss eine Umgebung für die kontinuierliche Integration und die Durchführung der automatisierten Tests verfügbar sein. Diese Faktoren fließen selbstverständlich in die Projektkosten mit ein.

Extreme Programming setzt ausschließlich auf Paarprogrammierung, was rechnerisch zunächst doppelten Personalaufwand bedeutet. Es gibt jedoch (wenige) Untersuchungen zur Auswirkung von Paarprogrammierung. Dort wurde festgestellt, dass dieser Programmierstil nach einer gewissen Einarbeitungszeit zwar insgesamt den Aufwand gegenüber der Einzelprogrammierung erhöht, sich aber positiv auf die Softwarequalität und die Projektdauer ausgewirkt hat^[33]. Auf der anderen Seite wäre es ebenso denkbar, dass ein einzelner Entwickler zum selben Ergebnis gekommen wäre (doppelter Personalaufwand). Bei dieser Programmiertechnik entsteht durch Wissenstransfer ein kooperativer Lerneffekt. Die Zusammensetzung der Paare wechselt regelmäßig. Dadurch arbeiten erfahrene Programmierer auch mit weniger erfahrenen Programmierern oder Anfängern zusammen, die davon stark profitieren. Der erfahrenere Programmierer muss sich jedoch auf diese Technik einlassen können und sich dem langsameren Tempo anpassen. Aus Sicht des Personalmanagements können so Kosten für die Weiterentwicklung der Mitarbeiter eingespart werden.

Bei konsequenter Einhaltung der Praktiken ist ein fachlich qualifizierter Mitarbeiter des Kunden permanent bei den Entwicklern vor Ort, um an den regelmäßigen Meetings und den Akzeptanztests mitzuwirken. Auch sollen die Stories und Akzeptanztests durch den Kunden selber formuliert werden. Dieser abgestellte Mitarbeiter ist während der Entwicklungszeit nicht für die reguläre Arbeit im Betrieb verfügbar bzw. er kann dieser nur teilweise nachkommen. Ggf. ist die Einarbeitung einer Vertretung erforderlich. Dies bedeutet hohe Kosten und einen hohen zeitlichen Aufwand, was bei der Berechnung des Projekts beachtet werden muss.

Eine weitere Annahme von Extreme Programming besagt, dass sich der Kunde selber zu Beginn noch nicht vollständig über die Anforderungen an die Software im Klaren ist. Außerdem werden im Projektverlauf sehr viele Änderungswünsche durch den Kunden geäußert^[33]. Unter Berücksichtigung dieser Umstände gestaltet es sich schwierig, zum unmittelbaren Projektbeginn den Aufwand für das gesamte Projekt einzuschätzen. Im Verlauf der Projekts werden neue Stories hinzugefügt bzw. verworfen, was den Aufwand und die Dauer jedes Mal beeinflusst. Erschwerend kommt hinzu, dass die Stories zunächst nur sehr grob formuliert sind und erst später bei den regelmäßigen Meetings mit dem Kunden präzisiert werden. Die Aufwandsschätzung findet daher bei den Planungen des nächsten Releases bzw. der nächsten Iteration statt^[34]. Die Schätzgenauigkeit basiert auf Erfahrungen der Entwickler mit abgeschlossenen Stories und erhöht sich über den Projektverlauf^[35]. Verbindliche Aussagen zur Dauer und Aufwand von Entwicklerseite sind auf Grund des kurzfristigen Planungshorizonts nur für das nächste Release möglich. Aussagen zur Gesamtlaufzeit sind gerade zu Beginn nur als Größenordnung zu sehen^[35].

Generell ist der Aufwand bei einem Extreme Programming Projekt recht groß. Das ständige Testen und die Implementierung der Änderungswünsche des Kunden erfordern Zeit, Disziplin der Entwickler und verursachen Kosten. Dem gegenüber steht die Qualität des Projekts. Beck unterscheidet zwischen innerer und äußerer Qualität. Die innere Qualität des Codes spiegelt die Güte des Designs und der Tests wieder. Die äußere Qualität ist jene, welche der Kunde wahrnimmt. Dazu gehören Bugs und nicht-funktionale Elemente, wie z. B. das GUI-Design und die Geschwindigkeit der Software^[36]. Durch die ständigen Tests und die kontinuierliche Integration wird eine hohe Codequalität gewährleistet. Das zeitnahe Feedback des Kunden ermöglicht es dem Entwickler, Fehlentwicklungen frühzeitig zu verhindern und damit wertvolle Zeit einzusparen. Somit sind grundlegende Änderungen am Code selten nötig und – da nicht besonders umfangreich – nicht sehr kostenintensiv. Auf Grund dessen stellt Extreme Programming "wesentliche Erkenntnisse klassischen Softwareengineerings in Frage: nämlich dass Kosten für Änderungen oder Fehlerbehebung exponentiell über die Projektlaufzeit steigen."^[33] (siehe Abb. 8: Änderungskostenkurve.) Bei einer klassischen Entwicklungsmethode findet die Überleitung ins Produktivsystem beim Anwender nur an den weit auseinander liegenden Releaseterminen statt. Dadurch erfolgt das Feedback durch den Kunden erst sehr spät und im schlechtesten Fall wurden Elemente programmiert, die den Vorstellungen des Kunden überhaupt nicht entsprechen und geändert werden müssen. Hohe Kosten sind die Folge, da u. U. tief ins System eingegriffen werden muss. Die Richtigkeit dieser Annahme kann allerdings nicht bewiesen werden. In Zeiten der objektorientierten Programmierung, die zum Ziel hat, Code mittels Abkapselung und Vererbung voneinander unabhängiger zu machen und universell einsetzen zu können, ist diese These umstritten^[37]. Interessant ist auch die These von Dornberger und Habegger, dass durch die Fokussierung auf das nächste Release eine Softwarearchitektur entsteht, die zwar zu den bis dato umgesetzten Kundenwünschen passt, aber für zukünftige noch zu implementierende Elemente schlecht geeignet ist^[37].

Extreme Programming sieht selbst kein explizites Risikomanagement vor. Vielmehr beinhaltet die gesamte Herangehensweise ein implizites Risikomanagement, indem Risiken frühzeitig erkannt und vermieden werden. Die Gründe hierfür sind: Entwicklung mit dem Kunden, hohe Codequalität durch ständiges Testen und die Möglichkeit, Krankheitsfälle im Entwicklerteam durch Wissenstransfer zu kompensieren. Dennoch fehlt dem gesamten Prozess eine langfristige Planung, die kritische Faktoren für den Projekterfolg identifiziert, da der Schwerpunkt hauptsächlich auf den einzelnen Releases bzw. Iterationen liegt. Dies ist klassischerweise die Aufgabe einer Risikoanalyse. Es gibt Empfehlungen, dennoch ein Risikomanagement für die strategische und langfristige Planung einzubinden. Bemängelt wird auch, dass politische und strategische Risiken, die sich aus dem Projektumfeld (bspw. die Organisation und das Management) ergeben, generell bei der agilen Softwareentwicklungsmethoden unberücksichtigt bleiben^[38].

5.2 Nutzen

5.2.1 Kundensicht

Durch die echte Kundenbeteiligung an der Entwicklung ist der Kunde in der Lage, regelmäßig den Fortschritt zu überwachen und zu überprüfen, ob seine Anforderungen, die er in den Stories formuliert hat, auch von den Entwicklern verstanden und nach seinen Vorstellungen umgesetzt wurden. Somit werden Kundenängste gemindert, da anders als bei anderen Vorgehensmodellen, der Kunde jederzeit eine Einsicht in den Entwicklungsstand hat und nicht mit einem fertigen Produkt konfrontiert wird. Darüber hinaus besteht während des Entwicklungsprozesses die Möglichkeit, Änderungswünsche zu äußern, sodass das entstehende Produkt komplett den Vorstellungen des Kunden entspricht. Durch die Beteiligung des Kunden wird auch sichergestellt, dass nur die Funktionalität umgesetzt wird, die benötigt wird. Somit verläuft die Entwicklung schneller und Kosten werden eingespart^[39].

Dadurch, dass der Kunde auch zum Projektteam gehört und eine völlige Projekt-Transparenz herrscht, findet eine Stärkung des Entwickler-Kunden-Verhältnisses statt, wodurch letztendlich auch das gegenseitige Vertrauen gesteigert wird^[40]. "In Zeiten schwindender Kundenloyalität ist dieses Vertrauen ein wertvolles Gut, das nicht leichtfertig auf das Spiel gesetzt werden darf, und das eine längerfristige Beziehung mit dem Kunden begünstigt"^[41]. Durch die ständige Anpassung an die Wünsche des Kunden, entsteht eine höhere Qualität des Systems, da wenig Zeit mit dem Entwickeln falscher Funktionalitäten verschwendet wird. Letzendlich resultiert daraus eine hohe Kundenzufriedenheit

5.2.2 Entwicklersicht

Beim Programmieren in Paaren wird deutlich, dass es keine strikte Rollenverteilung gibt und dass Programmierer mit wechselnden Aufgabengebieten beauftragt werden. Zudem wird durch die Änderung der Einsatzgebiete auch die Bildung von Wissensmonopolen verhindert, da sich jeder Programmierer mit allen eingesetzten Mitteln des Projekts auskennen muss. Ein weiterer Vorteil des Programmieren in Paaren ist, dass durch die gegenseitige Kontrolle während der Kodierung und der Einhaltung des Test-Driven Development die Qualität des entstehenden Produkts verbessert wird und es Zeit und Kosten bei der späteren Fehlerbehebung einspart. Damit die Motivation, Kreativität und Produktivität hoch bleiben, verzichtet XP auf Überstunden der Programmierer^[42]. Durch die ständige Kommunikation sollen Probleme innerhalb der Entwickler verhindert werden, so dass sich alle Entwickler in dem Team wohlfühlen und es keine einzelnen Konflikte gibt. XP soll den Entwicklern Spaß machen, was z. B. durch das Nichtvorhandensein von strikten Regeln und das Nichterstellen einer Dokumentation gewährleistet wird. Des Weiteren fördert ständiges Feedback die Motivation der Entwickler weiter zu arbeiten oder kleine Fehler schnell zu beheben.

Wöchentliche Standup-Meetings sowie ständiges Integrieren der Quellcodes tragen dazu bei, dass alle Entwickler immer auf dem gleichen Stand sind, so bildet das Team immer eine Einheit und keiner wird ausgeschlossen. Ist ein Entwickler einige Zeit abwesend, so kann seine Arbeit durch einen anderen Entwickler erledigt werden. Das Arbeiten wird somit leichter und angenehmer gestaltet. Ständiges Testen führt dazu, dass Programmierfehler schnell erkannt und behoben werden können, sodass während der Fehlersuche keine Frustration bei den Entwicklern entsteht. Der Code erreicht dadurch eine gute Qualität und neben Kunden- auch Entwicklerzufriedenheit.

5.2.3 Projektsicht

Selbst wenn das Projekt aus verschiedenen Gründen scheitern sollte, wird aufgrund der XP-Methoden immer noch eine Wertschöpfung erzielt. Dies liegt vor Allem daran, dass in der Entwicklung zunächst die Funktionen umgesetzt werden, die das größte Risiko bergen und für den Kunden den größten Nutzen haben. Hinzu kommt der quartalsweise Zyklus, der dem Kunden in regelmäßigen Abständen ein lauffähiges System präsentiert und die Möglichkeit bietet, gegen auseinander laufende Zielvorstellungen rechtzeitig Korrekturmaßnahmen vorzunehmen. Somit ist zum Zeitpunkt des Abbruchs des Projekts ein unvollständiges, lauffähiges und mit den Hauptfunktionen ausgestattetes Produkt erhältlich, dass sich auch zum Verkauf eignet. Des Weiteren wird das Risiko eines Scheiterns durch den Ausfall wichtiger Mitarbeiter minimiert, da das Wissen gleichmäßig auf das gesamte Team verteilt ist^[42].

5.3 Risiken

Im Abschnitt "Betriebswirtschaftliche Betrachtung" wurden bereits einige Kritikpunkte in Bezug auf eine betriebswirtschaftliche Betrachtungsweise von Extreme Programming erläutert. Beim XP finden sich jedoch weitere Punkte, die, kritisch betrachtet, Risiken bergen. Diese werden im Folgenden näher erläutert.

Extreme Programming verzichtet bewusst auf jegliche klassische Dokumentation. Als Dokumentation dienen der Code und die Tests. Das bedeutet, die Entwickler müssen den Code während der Erstellung mit ausreichender Kommentierung versehen. Dies könnte zu Problemen bei Personalwechseln im Entwicklerteam bzw. bei wichtigen Designentscheidungen führen. Es wird in Frage gestellt, ob es Neuzugängen im Entwicklerteam gelingt, sich in angemessener Zeit in das Projekt einzuarbeiten. Da grundlegende Designentscheidungen nicht dokumentiert werden besteht die Gefahr, das Grundsatzdiskussionen unnötig oft wiederholt werden^[43]. Eine Kontinuität im Entwicklerteam ist folglich von Vorteil.

Rumpe spricht von einer Erosion des Codes, was später zu Wartungsproblematiken führen kann. Das Softwaremodell befindet sich lediglich in den Köpfen der Entwickler, die u. U. das ursprüngliche Entwicklerteam bereits verlassen haben. Erschwerend kommt hinzu, dass keine Dokumentation existiert. Die Weiterentwicklung einer Software nach jahrelanger Nutzung wird dadurch immens erschwert^[44].

Die einzelnen Programmmodule können nicht einem bestimmten Entwickler zugeordnet werden, da auf Grund der gemeinsamen Codebasis alle Entwickler das Recht haben, jeden Teil des Programmcodes zu verändern. Dies könnte u. A. dazu führen, dass sich die Entwickler gegenseitig ihre „Code-Struktur“ zerstören^[45]. Entwickler müssen also damit rechnen, dass der eigene Code am nächsten Arbeitstag stark abgeändert wurde, was ggf. wieder erneute Einarbeitungszeit erfordert. Im schlechtesten Fall ändern zwei Entwickler dasselbe Modul ständig ab, um den jeweils eigenen Wünschen zu entsprechen, ohne dass letztlich ein produktive Arbeit geleistet wurde. Die Entwickler müssen daher über eine gewisse soziale Kompetenz verfügen, die es ihnen ermöglicht, offen für die Ideen anderer Entwickler zu sein, mit ihnen zu kommunizieren und in Paaren zu programmieren.

Auf dem Kunden (dem Vertreter vor Ort) lastet eine große Verantwortung. Zu den Aufgaben gehören u. A. die Stories zu präzisieren (dazu muss er alle Anforderungen kennen), er muss regelmäßig Kontakt zum Management (auf Kundenseite) halten und den aktuellen Fortschritt einschätzen können. Er muss einen vollständigen Überblick über die Anforderungen haben, den Entwicklern jederzeit zur Verfügung stehen, die Bedenken der Entwickler nachvollziehen können, wozu er über ein gewisses technisches Verständnis verfügen muss, und im Konfliktfall zwischen Kundenmanagement und Projektmanagement bzw. Entwicklerteam vermitteln. Darüber hinaus ist er für die Spezifizierung und Validierung der Tests verantwortlich und muss bei der Planung der Iterationen und Releases mitwirken. Die Menge an Aufgaben und Verantwortung macht deutlich, dass die Wahl des Kundenvertreters für den Projekterfolg entscheidend ist und dieser quasi zum „Single-Point-of-Failure“ wird^[46]. Gleichzeitig findet sich in vielen Erfahrungsberichten zu Extreme Programming die Aussage, das der 'Kunde vor Ort' häufig nur sehr schwer realisierbar ist, was die Problematik verstärkt.

Ebenso stellt XP besondere Anforderungen an die Entwickler. Diese haben nicht ausschließlich die Aufgabe, den Quellcode für das Programm zu schreiben, ihnen kommt u. A. die wichtige Aufgabe zu, den Aufwand zu schätzen. Eine Aufgabe, die bei der klassischen Projektarbeit dem Projektmanager zuteil kommt. Des Weiteren sind sie an der Releaseplanung und den Tests beteiligt. Dabei müssen sie mit dem Kunden zusammenarbeiten, wobei die Kommunikationsfähigkeit sehr wichtig ist. XP setzt folglich nicht auf den klassischen Entwickler.

Auf Grund der Tatsache, dass sich die Anforderungen im Projektverlauf verändern sind solche Projekte nicht als Festpreisprojekte bzw. als Projekte mit festem Endtermin zu realisieren. Es gibt jedoch Erfahrungsberichte, nach denen dies trotzdem erfolgreich durchgeführt werden konnte, wofür aber Anpassungen am Prozess erforderlich waren^[47].

5.4 Voraussetzungen für ein ideales XP-Projekt

XP kann nicht für alle Projekte und in jedem Unternehmen eingesetzt werden. Es ist aber auch nicht immer sinnvoll dies zu tun, denn es verspricht nicht immer ein erfolgreich durchgeführtes Projekt. Das Projektteam sollte, bevor es eine Softwareentwicklungsmethode wählt, sich genaue Gedanken über die Ziele, Anforderungen und Gegebenheiten des Projektes machen und einige Voraussetzungen für ein XP-Projekt erfüllen. „Verzichtet man darauf, verschlechtert sich drastisch die Arbeitsqualität oder wird das Arbeiten gar verunmöglicht“^[48].

XP ist eine Softwareentwicklung, bei der Kommunikation zwischen den Mitgliedern eine wichtige Voraussetzung ist, damit die Entwickler ständig in Kontakt stehen. Dementsprechend müssen die Arbeitsplätze der Teammitglieder gestaltet werden. XP empfiehlt, dass die Tische im Arbeitszimmer zu einem großen Tisch zusammengestellt werden. Dadurch haben alle Mitglieder zu jedem anderen Blickkontakt, sodass die Kommunikation flüssiger und ruhiger läuft^[49]. Werden mehrere Büroräume genutzt, so sollten diese nicht weit voneinander entfernt sein^[50]. Durch das Programmieren in Paaren wird die informelle Verständigung innerhalb der Paare zumindest gefördert und erstreckt sich bei jedem Partnerwechsel weiter^[51], jedoch soll durch die optimale Aufteilung und Gestaltung der Räume auch die Kommunikation außerhalb der Paare gesichert werden, um den Fluss und die ständige Integration nicht zu behindern.

Neben einer guten Software, muss auch die Hardware leistungsfähig sein, damit häufiges Integrieren und Testen möglich ist, denn die Leistungsstärke hängt nicht zuletzt von der eingesetzten Software ab^[49]. Aber auch die Software, die zum Entwickeln benötigt wird, sollte eine gute Qualität aufweisen. So muss die Entwicklungsumgebung schnelles Linken und Kompilieren ermöglichen. Des Weiteren sollte Testsoftware für automatisches Testen einsetzten werden^[49], denn das reduziert zumindest teilweise den Arbeitsaufwand und es werden regelmäßige Feedbacks gegeben, ob die Tests erfolgreich durchlaufen wurden. „Die gesamte Anwendung muss immer allen Tests gerecht werden und dabei gleichzeitig eine Architektur aufweisen, die einfach und nachvollziehbar ist“^[52], dadurch ist eine gute Qualität garantiert.

Es sollte auch immer ein Kunde anwesend sein^[49], um mögliche gerade auftretende Probleme oder Unstimmigkeiten schnell zu besprechen, sodass der Arbeitsprozess nicht durch langes Warten behindert wird. Ebenfalls wird dadurch die Trennung von technischen und geschäftsbedingten Entscheidungen möglich^[53]. Ein regelmäßiges Feedback des Kunden lenkt das Team in die richtige Richtung und verhindert, dass sie unnötige Zeit verschwenden über falsche, nicht brauchbare Funktionen nachzudenken, sondern sich auf das Wesentliche und Geforderte des Kunden zukonzentrieren. Außerdem ist es wichtig, dass es einen Fachexperten in XP gibt, der ebenfalls stets erreichbar ist. Auch sollte das Team mindestens zu 50 % aus erfahrenen Entwicklern bestehen, damit so ein Minimum an Leistungspotenzial gewährleistet wird, XP auch wirklich umzusetzen^[49]. Die Entwicklung würde nämlich still stehen, wenn alle Entwickler sich zunächst in die Materie einarbeiten müssten und viele Vorgänge nicht beherrschen. So können die unerfahrenen Entwickler immer wieder Tipps erlangen und diese direkt umsetzten, so ist nicht nur der Lernerfolg, sondern auch die Qualität höher. Nicht jeder Entwickler wird sich mit XP anfreunden können. Jedoch sollten sie lernbereit und teamfähig sein^[49] und alle Beteiligten müssen bereit dazu sein, die Werte, Prinzipien und Praktiken von XP anzunehmen, umzusetzen und zu leben^[54].

XP sollte nicht in einer Unternehmenskultur, bei der die Teams genaue Vorgaben zum Vorgehensmodell bekommen, z. B. wenn zuerst eine ausführliche Spezifikation erstellt werden muss, eingesetzt werden^[50]. Wenn ein Kunde bspw. ein Problem hat, aber noch keine klaren Vorstellungen, was dieses System im Einzelnen leisten soll^[55] oder am Anfang noch recht wenige Anforderungen und Funktionalitäten feststehen, sollte XP eingesetzt werden, da ein XP-Projekt sich im Laufe seiner Zeit entwickelt und immer weiter wächst. Deshalb sollte das Team auch viel Flexibilität mitbringen und der Zeitdruck sollte so gering wie möglich sein. In einem XP-Projekt ist es nämlich nicht vom Nachteil, wenn Anforderungen sich schnell ändern können, gerade für solche Projekte ist XP sehr gut geeignet. Dadurch, dass der Kunde meistens noch keine klaren Vorstellungen definiert hat, kann es schnell passieren, dass eine bereits entwickelte Funktion nicht den Anforderungen des Kunden entspricht^[55]. Deshalb müssen ständig Änderungen am System vorgenommen werden. Das Ziel ist es, am Ende des Projektes eine lauffähige Software zu haben, es kann jedoch sein, dass die Software nicht zum geplanten Termin fertig wird^[56], da neben der Lauffähigkeit auch eine gewisse Qualität erreicht werden sollte. Des Weiteren sollte XP nicht eingesetzt werden, wenn die Kosten ein entscheidender Faktor sind und nur sehr begrenzt finanzielle Mittel bereit gestellt werden. Wenn z. B. späte Änderungen oder häufiges Testen zu teuer werden, sollte das Team sich für eine andere Vorgehensweise entscheiden.

XP ist besser für kleine Tams geeignet, diese sollten nicht aus mehr als zehn Mitgliedern bestehen^[50], denn sonst wird die Kommunikation schwieriger und viele Praktiken können nicht angewendet und viele Prinzipien nicht eingehalten werden. Bei größeren Projekten kann es manchmal nicht vermieden werden, große Teams zu bilden. Dann sollte das Projektteam in logische kleinere Teilprojekte aufgespalten werden^[56], damit kleinere, relativ unabhängige Teams entstehen.

6 Anwendungsbeispiele

6.1 Extreme Programming in Projekten

6.1.1 Studie zum Erfolg von XP

Auch wenn Extreme Programming im Jahr 1999 publik wurde und die Vermutung nahe liegt, dass es schon eine lange Zeit her ist, um darüber ausreichende Erfahrungsberichte zu finden, ist das leider nicht der Fall. XP brauchte zunächst auch eine Zeit, um sich bekannt und attraktiv für Unternehmen zu machen. Die Zahl der XP-Projekte wächst zwar, jedoch dauert es auch seine Zeit bis XP-Projekte fertiggestellt sind und das Unternehmen benötigt einige Jahre um Erfahrungen mit dem Einsatz der entwickelten Software zu sammeln. Denn nur, wenn ein Projekt sich langfristig bewähren kann, war es ein Erfolg.

Das Virtuelle Software Engineering Kompetenzzentrum (VISEK) der Universität München führte 2001 eine Studie zum Erfolg von XP durch. Die Studie wurde zwar vor einigen Jahren gemacht, dennoch gibt sie hilfreiche und interessante Erkenntnisse, wie XP in der Praxis bei Unternehmen, Entwicklern und Kunden ankommt. Es muss allerdings in Betracht gezogen werden, dass sich diese Daten im Laufe den letzten Jahren verändert haben können. Leider gibt es keine aktuellen Studien zu diesem Thema. An dieser Studie nahmen 45 Unternehmen teil, die schon ein mal mit XP gearbeitet haben oder es noch tun. An die Unternehmen wurden Fragebögen mit speziellen Fragen rund um den Einsatz ihres XP-Projektes gesendet. Diese Fragebögen lieferten die Basis für die Auswertung der Studie^[57]. Es sollen kurz die wichtigsten und bedeutsamsten Ergebnisse vorgestellt und teilweise näher erläutert werden.

Viele Unternehmen entscheiden sich XP zu verwenden, weil sie in der Vergangenheit schlechte Erfahrungen mit klassischen Methoden gemacht haben, was sich in der Unzufriedenheit der Kunden und in Frustration bei den Entwicklern bemerkbar machte. Die Unternehmen erhoffen sich durch den Einsatz von XP einen größeren Projekterfolg und Kundenzufriedenheit^[57].

Die meisten XP-Projekte werden in den USA durchgeführt, an zweiter Stelle steht Deutschland. Aber auch in Ländern wie der Schweiz oder Großbritannien finden sich XP-Projekte^[57].

Des Weiteren sind die Ergebnisse bezüglich der Größe und des Alters der Unternehmen sehr interessant. Ein breites Spektrum ist hier vertreten, Firmen in verschiedenen Größen und Gründungsjahren. Dass XP größtenteils in kleinen und jungen Firmen angewendet wird, haben die Ergebnisse nicht bestätigt. Auch wird XP in Unternehmen mit verschiedenen Mitarbeiterzahlen durchgeführt. Über die Hälfte der Projekte wird in Unternehmen mit einer Größe zwischen zehn und 1000 Mitarbeiter angewendet. Darüber hinaus wird der Einsatz von XP geringer. Dennoch waren die Teams zum größten Teil nicht größer als zehn Personen – dies empfiehlt XP auch. XP hat bereits einen breiten Einzug in Unternehmen aller wichtigen Branchen, Größen und jeden Alters erhalten^[58].

XP ist noch nicht sehr bekannt, macht sich aber mit der Zeit einen Namen. Aus der Studie kam ebenfalls heraus, dass es für mehr als die Hälfte der Unternehmen das erste XP-Projekt war. Nur in einigen wenigen Unternehmen wurden bereits vorher XP-Projekte durchgeführt. Das zeigt sich auch in den Vorerfahrungen mit XP bei den Entwicklern. Mehr als die Hälfte aller Entwickler haben noch nie mit XP gearbeitet. Unternehmen setzen sich sich immer mehr mit XP auseinander und wenn XP weiterhin so viele Kunden und Unternehmen zufriedenstellt, wird es vielleicht bald die klassischen Methoden der Softwareentwicklung ablösen. Eine weitere Auswertung zeigt ebenfalls die langsame Verbreitung von XP. Es werden nämlich im Laufe der Zeit immer mehr Projekte mit XP angefangen. Bis 1999 gab es noch fast keine Projekte, die mit XP arbeiteten. Es ist eine klare Zunahme in den letzten Jahren erkennbar. Es gab Projekte von kurzer und von langer Dauer, sie liegt aber zwischen sechs Monaten und drei Jahren. Auch hier ist noch keine Tendenz, aber der vielseitige Einsatz von XP erkennbar^[59].

Trotz der vielen positiven Kritiken gibt es auch Probleme mit einigen XP-Techniken. Viele äußerten, dass die Metapher und das Vorhandensein des Kunden vor Ort am meisten Mühe bereiteten. Das Problem mit der Metapher bestand vorwiegend darin, dass vielen nicht klar war, wie sie anzuwenden sei und was für einen Vorteil sie bringen solle. Das Planning Game wurde von vielen Teams stark genutzt, jedoch empfanden nur die Hälfte der Befragten es als hilfreich. Das Problem war meist, dass das Planning Game aufgrund des nicht häufig vorhandenen Kunden nicht zufriedenstellend durchgeführt werden konnte. Testen, Refactoring sowie das Programmieren in Paaren waren sehr beliebt und wurden intensiv genutzt und als hilfreich empfunden^[60].

Hierzu muss gesagt werden, dass Kent Beck die Praktiken in seiner zweiten Auflage seines Manifests überarbeitet hat, viele Praktiken neu formuliert wurden und einige neue hinzugekommen sind sowie welche entfernt wurden. Die Metapher und das Planning Game werden demnach von Beck nicht mehr als Praktik empfohlen. Es ist eine Weiterentwicklung auch von Seiten Becks zu erkennen, dass nach einigen praktischen Erfahrungen die Theorie angepasst und verbessert werden mussten.

Letztendlich wurden aber 90% der Projekte als erfolgreich bewertet. Nur in einem Fall wurde der Projektabschluss nur teilweise als erfolgreich bewertet. Alle Unternehmen wollen XP wieder verwenden und sind begeistert von dem Ergebnis. Was aber macht den Erfolg aus? Die Auswertung zeigt, dass es nicht den einen Erfolgsfaktor, sondern eine mehr oder minder ausgewogene Verteilung über drei bis sieben Faktoren gibt. Als die drei wichtigsten Erfolgsfaktoren wurden das Pair-Programming, das Testen und das Streben nach hoher Qualität aufgeführt, gefolgt von guter Kommunikation mit Kunde und Management, Priorisierung von Aufgaben, sehr guten Entwicklerinnern und Entwickler sowie einem motiviertem Team^[61].

6.1.2 Projekt "Scooter"

Henning Wolf, Stefan Roock und Martin Lippert beschreiben in ihrem Buch „eXtreme Programming“ einige von ihnen selbst durchgeführte Projekte und berichten über ihre Erfahrungen mit XP. Im Rahmen dieser wissenschaftlichen Arbeit soll eines der Projekte vorgestellt werden.

Beim Projekt „Scooter“ (Name geändert) wurde ein deutsches Versicherungsunternehmen bzgl. Objektorientierter Technologien und Vorgehen im Projekt beraten. Das Ziel dieses Projektes war, dass existierende Systeme vereinheitlicht sowie neue Anforderungen insbesondere im Bereich Mehrkanalfähigkeit unterstützt werden. Ein kleines Problem stellten die gering vorhandenen Kenntnisse über Java und objektorientierter Programmierung dar^[62].

Dass XP in einer Versicherung eingesetzt wird, ist eher ungewöhnlich. Es schien für einige Mitarbeiter attraktiv, für andere z.B. das Management eher abschreckend. Aus diesem Grunde wurde nicht XP als solches, sondern nur einige XP-Techniken nach Bedarf eingesetzt, mit der dann ein konkretes Problem behoben werden kann. In einer Explorationsphase wurden kleinere Prototypen entwickelt. Diese Zeit wurde ebenfalls benötigt, um sich in das Projekt einzufinden und dann zu starten. Ein Problem beim Einsetzen von kurzen Releasezyklen war, dass evtl. das Hostsystem als Ganzes ablösen werden müsste und kurze Releasezyklen nicht realisierbar seien. Die Lösung dieses Problems war, dass für einige Zeit beide Systeme parallel eingesetzt wurden. Täglich wurden Standup-Meetings von maximal fünfzehn Minuten gemacht. Dabei galten die Regeln wie sich kurzalten, keine Diskussionen und Beschränkung auf das Wesentliche. So sind alle Entwickler immer auf dem gleichen Stand und über Probleme und Erfolge informiert. Zusätzlich wurde auch ein Planungsspiel je nach Schwerpunkt der aktuellen Iteration mit einem Anwendervertreter gespielt und Story-Cards für die jeweils anstehende Etappe erstellt. Es wurde auch das Programmieren in Paaren angewendet. Als Problem hat sich aber herausgestellt, dass Paare, bei denen erfahrene Java-Entwickler mit absoluten OO- und Java-Neulingen zusammenarbeiteten, sich nicht bewährt haben. Die erfahrenen Entwickler waren nämlich nur damit beschäftigt, den Partner zu schulen. Dadurch tendierte der Fortschritt gegen null, da wenig Zeit für die eigentliche Entwicklung blieb. Auch wurden Komponententests und fortlaufende Integration eingesetzt und liefen anfangs gut an, wurden jedoch durch die eingesetzte Entwicklungsumgebung behindert. Das führte letztendlich dazu, dass die Komponententests zu selten ausgeführt wurden und im zentralen Repository häufig eine Codebasis vorlag, die die Tests nicht bestand. „Gemeinsame Verantwortlichkeit bezogen auf den Quellcode war nie ein Problem. Die Kommunikation im Team über Code war stets so gut, dass es in diesem Bereich auch keine Abstimmungsprobleme gab“^[63].

Die ersten Etappen wurden termingerecht fertiggestellt und die XP-Techniken wurden ziemlich vollständig eingeführt. Durch die Iterationsplanung wurde das Projekt immer weiter vorangetrieben. Jedoch gab es auch einige Probleme. Z.B. wurde nicht überall die gewünschte Codequalität erreicht. Es war teilweise eine fehlende Integration der Anwender sowie teilweise extremer Zeitdruck da, der plötzlich vor bestimmten Ereignissen stand. Um schnell noch eine neue Funktion zeigen zu können, wurde die Systemqualität geopfert und schließlich gelang es nicht überall diese Fehler wieder zu beseitigen^[62]. Hier wurde von den Prinzipien von XP abgewichen. Die Qualität ist das wichtigste Kriterium der Software, wenn hier zurückgesteckt werden muss, kann dies große Folgen haben und die Kunden nicht vollständig zufrieden stellen. Deswegen sollte um keinen Preis die Qualität leiden, was hier aber leider der Fall war. Unter Zeitdruck musste bei der Qualität zurückgesteckt werden. Es gab keine gemeinsame Planung, da nicht alle Ansprechpartner miteinbezogen werden konnten. Dadurch hatten verschiedene Akteure unterschiedliche Vorstellungen über den Projektverlauf und es kam zu Problemen. Es konnten sich auch nicht alle Entwickler mit XP anfreunden und mit diesen Konflikten konnte nicht gut umgegangen werden^[62].

6.2 Extreme Programming in der Lehre

An vielen Universitäten wird im Laufe eines Informatikstudiums ein mehrwöchiges praktisches Systementwicklungsprojekt durchgeführt, welches einen ernsthafteren Projektcharakter simuliert ^[64]. Wenn man die Theorie beherrscht, heißt es nicht, dass man sie auch gut anwenden kann. Deswegen sind praktische Projekte im Studium sehr wichtig, denn nur so lernen die Studenten ihre Stärken und Schwächen und können zusätzlich wertvolle Erfahrungen für ihr späteres Berufsleben sammeln. Des Weiteren bietet XP eine Reihe von nützlichen und effizienten Prinzipien und Praktiken. Die Vor- und Nachteile der einzelnen Praktiken kann ein Entwickler nur feststellen, wenn er es selbst ausprobiert. Die Verinnerlichung der Prinzipien kann den Studenten in späteren Projekten helfen^[64].

Zunächst müssen die Studenten den iterativen Ablauf eines XP-Projektes kennen lernen sowie die Begriffe und Rollen kennen. Außerdem müssen sie die einzelnen Praktiken sowie Prinzipien kennen. Erst dann kann mit dem XP-Projekt begonnen werden, in dem sie dann ihr Wissen anwenden sollen^[65]. Wie Extreme Programming empfiehlt, sollte das Team aus wenigen Mitgliedern bestehen. Mehr Teilnehmer z.B. beim Planungsspiel bedeutet einen größeren Kommunikations- und damit auch Zeitaufwand. Es zeigte sich, dass das Lösen abstrakter Probleme in kleineren Teams effektiver ist. Durch den geringeren Kommunikationsaufwand, entsteht eine geringere Hemmschwelle sich zu äußern und dadurch wird die Kommunikation qualitativer^[66]. Programmieren in Paaren wird von Studenten oft sehr positiv bewertet. Es zeigt sich, dass Studenten vom Programmieren in Paaren sehr profitieren. Das Ergebnis ist eine höhere Qualität der erstellten Programme sowie ein größerer Lernerfolg der Beteiligten^[56]. Es bietet sich nämlich der Vorteil, dass der Student von seinem Partner lernen kann, wenn diese unterschiedliche Vorkenntnisse haben ^[66]. Wird zu zweit an einem Programm gearbeitet, so ist man konzentrierter und das führt letztendlich dazu, dass die Qualität des Codes ansteigt. Des Weiteren können Programmierer auf lange Sicht besser mit der Komplexität eines Softwaresystems umgehen^[56], da es leichter ist zu zweit ein Problem zu durchdringen und zu verstehen. Außerdem können durch Programmieren in Paaren Redundanzen leichter vermieden werden^[65]. In einem weiteren Projekt zeigte sich, dass wenn XP eingesetzt wird, arbeitet man weniger Stunden, aber dennoch bei kürzerem und verständlicherem Code ein vergleichbares Produkt entwickeltet^[65], als wenn eine andere Methode eingesetzt wird. Das Testen spielt in der Softwareentwicklung eine wichtige und entscheidende Rolle. Es sollte ständig getestet werden, um sicherzustellen, dass das, was entwickelt wurde, auch gut und lauffähig ist. XP empfiehlt dies auch zu tun und so können Studenten schon in ihrem Studium anfangen, sich daran zu gewöhnen, so dass sie dies auch später in einem richtigen Projekt nicht vergessen. Denn so kann die Qualität des Produktes am Ende besser werden und die Zeit verkürzt werden, wenn man sich nicht lange mit etwas aufhält, was nicht funktioniert.

Durch praktische Erfahrungen lernen die Studenten besser und festigen ihr Wissen für längere Zeit, außerdem bringen sie wertvolles Wissen für den Start in ihr Berufsleben mit. Dennoch ist XP für unerfahrene Entwickler schwierig und es treten öfters Probleme auf. Dennoch sollte ein Entwickler einmal die Erfahrung mit dieser Methode gemacht haben, um sich selbst ein Urteil darüber bilden zu können, denn nicht jeder Entwickler findet die XP-Methode gut und möchte sie anwenden, doch muss der Entwikler dies erst einmal herausfinden.

7 Schlussbetrachtung

Bei der Recherche zum Thema Extreme Programming wurde sehr schnell deutlich, dass es kein objektives Zahlenmaterial über den Erfolg von Projekten, die mit Extreme Programming realisiert wurden, gibt. Des Weiteren beziehen sich viele Arbeiten auf die ersten Definitionen (1999) der Praktiken und Prinzipien von Kent Beck und somit ist es nahezu unmöglich, über die neu verfassten Annahmen qualitative und hilfreiche Aussagen zu machen und diese hinsichtlich des Erfolgs und der Entwickler- bzw. Kundenzufriedenheit zu bewerten. Vergleichende Studien zum Thema sind nur gering vorhanden, welche jedoch auch sehr schwer zu erstellen wären. Für einen Vergleich müssten Softwareprojekte mit einer klassischen und mit der XP-Methode durchgeführt werden und zwar unter gleichen Bedingungen und bei gleichen Fehlern, Änderungen, etc.. Folglich sind die von Kent Beck formulierten Vorteile von XP nicht belegt. Erst in der Zukunft wird sich bspw. zeigen, ob der Ansatz, den gesamten Prozess durch den Verzicht auf eine klassische Dokumentation zu verschlanken, sinnvoll ist.

In der Literatur finden sich zum einen positive Erfahrungsberichte über durchgeführte XP-Projekte, jedoch gibt es ebenso Literatur, die sich sehr negativ zu dem Konzept äußert. Dies sind jedoch Einzelmeinungen, die keineswegs ein objektives Bild über den Erfolg und die Eignung von XP zulassen. Zudem ist die Dunkelziffer der gescheiterten XP-Projekte unbekannt. Die Ergebnisse der Studie zeigen, dass XP erfolgreich funktionieren kann und allgemein wird über XP häufiger positiv als negativ berichtet. Mitarbeiter sowie Kunden waren sehr zufrieden. Trotzdem müssen die Auswertungen der Studie auch kritisch betrachtet werden, denn es nahmen nur einige wenige Projekte teil. Leider ist diese Studie von 2001 und viele Praktiken und Prinzipien wurden von Kent Beck überarbeitet. Somit liefert die Studie nicht für alle Bereiche hilfreiche Erkenntnisse über den aktuellen Einsatz, da daraus nicht zu schließen ist, wie heutzutage der Einsatz von XP bewertet wird. Auch aus betriebswirtschaftlicher Sicht ist es schwer zu sagen, ob es sich letztendlich lohnt XP einzusetzten. Theoretisch soll durch schnelles Feedback und die sofortigen Änderungen der Zeitaufwand nicht erhöht und hohe Änderungskosten vermieden werden. Auf der anderen Seite scheinen das Programmieren in Paaren und der Kunde vor Ort sehr kostenintensiv zu sein, wodurch aber eine höhere Qualität gewährleistet werden soll.

XP ist keinesfalls in jedem Projekt einsetzbar. Projekte sind sehr vielfältig und haben unterschiedliche Ansprüche und Voraussetzungen. Bevor ein Team sich für XP entscheidet, sollten einige Kriterien erfüllt sein, ansonsten ist von Anfang an keine gute Basis für den Erfolg gegeben. Deshalb kann keine Empfehlung für bzw. gegen die Durchführung eines Softwareprojekts mit XP gegeben werden. Vielmehr muss die Eignung im Einzelfall geprüft werden. Es wurde deutlich, dass der Kunde der großen Verantwortung und den hohen Anforderungen gewachsen sein muss. Gleiches gilt für die beteiligten Entwickler, bei denen vor allem soziale Kompetenzen vorhanden sein müssen. Können diese Anforderungen nicht erfüllt werden, ist es fraglich, ob XP die geeignete Methode für ein Projekt ist. Dies wurde beim Projekt "Scooter" deutlich. Nur wenn sich alle Teammitglieder mit ihren Rollen identifizieren können und sich mit Interesse, Ehrgeiz und Spaß am Projekt beteiligen, kann am Ende eine qualitativ wertvolle Software entstehen. Die Entwickler müssen sich mit der Methode anfreunden können.

Nach Beck hängt der Erfolg von einem XP-Projekt von der Einhaltung und dem Zusammenspiel aller Werte, Prinzipien und Praktiken ab. Erfahrungsberichte machen jedoch deutlich, dass es nicht immer gelingt, alle Anforderungen exakt umzusetzen und einzelne Techniken Schwierigkeiten bereiten. Dennoch wurden Projekte, bei denen nur Teile des XP zum Einsatz kamen, als erfolgreich bewertet. Die einzelnen Techniken von XP sollten daher zum Repertoire eines Softwareentwicklungsteams gehören, die bei Bedarf zum Einsatz kommen. Um dieses Handwerkszeug zu verbreiten, ist es durchaus sinnvoll, XP im Studium anzuwenden, denn nur durch praktische Erfahrungen lernen die Studenten die Vor- und Nachteile der XP-Techniken kennen und erlangen somit wertvolles Wissen, welches für die Weiterentwicklung des XP-Prozesses förderlich ist.

8 Fußnoten

1. ↑ Vgl. Beck (2003), S. 3
2. ↑ Vgl. projekt-it (2007)
3. ↑ Vgl. Rumpe (2001), S. 1
4. ↑ Vgl. Vogt (2007)
5. ↑ ^{5,0 5,1} Vgl. Hillert (2011), S. 3
6. ↑ Zivkovik (2003), S. 5
7. ↑ Hillert (2011), S. 3
8. ↑ ^{8,0 8,1 8,2 8,3 8,4 8,5} Vgl. Beck et al. (2004), Chapter 4. Values
9. ↑ ^{9,00 9,01 9,02 9,03 9,04 9,05 9,06 9,07 9,08 9,09 9,10 9,11 9,12 9,13 9,14} Vgl. Beck (2004), Chapter 5. Principles
10. ↑ Vgl. Beck (1999), S. 37 bis 41
11. ↑ ^{11,0 11,1 11,2 11,3 11,4 11,5 11,6 11,7} Vgl. Wolf et al. (2005), S. 146 ff
12. ↑ Wolf et al. (2005), S. 147
13. ↑ ^{13,00 13,01 13,02 13,03 13,04 13,05 13,06 13,07 13,08 13,09 13,10 13,11 13,12} Vgl. Beck et al. (2004), Chapter 7. Primary Practices
14. ↑ Vgl. Wolf et al. (2005), S. 152
15. ↑ Vgl. Wolf et al. (2005), S. 112
16. ↑ ^{16,0 16,1} Vgl. Wolf et al. (2005), S. 153
17. ↑ ^{17,0 17,1 17,2 17,3 17,4 17,5} Vgl. Beck et al. (2004), Chapter 9. Corollary Practices
18. ↑ ^{18,0 18,1 18,2} Vgl. Wolf et al. (2005), S. 154
19. ↑ ^{19,0 19,1} Vgl. Wolf et al. (2005), S. 156
20. ↑ Vgl. Wolf et al. (2005), S. 167 f
21. ↑ ^{21,0 21,1 21,2} Vgl. Wolf et al. (2005), S. 163 bis 166
22. ↑ Vgl. Wolf et al. (2005), S. 168 f
23. ↑ ^{23,0 23,1} Vgl. Dornberger et al. (2004), S. 17
24. ↑ ^{24,0 24,1} Vgl. Dornberger et al. (2004), S. 16 f
25. ↑ ^{25,0 25,1} Vgl. Dornberger et al. (2004), S. 18
26. ↑ ^{26,0 26,1} Vgl. Dornberger et al. (2004), S. 18 f
27. ↑ Vgl. Dornberger et al. (2004), S. 19
28. ↑ ^{28,0 28,1} Vgl. Dornberger et al. (2004), S. 20
29. ↑ ^{29,0 29,1 29,2} Vgl. Dornberger et al. (2004), S. 21
30. ↑ ^{30,0 30,1} Vgl. Dornberger et al. (2004), S. 22
31. ↑ Vgl. Beck et al. (2001), S. 38
32. ↑ Vgl. Beck et al. (2001), S. 29
33. ↑ ^{33,0 33,1 33,2} Vgl. Rumpe et al.(2001), S. 8
34. ↑ Vgl. Wolf et al. (2005), S. 32
35. ↑ ^{35,0 35,1} Vgl. Wolf (2005) S. 33
36. ↑ Vgl. Beck et al. (2001), S. 29
37. ↑ ^{37,0 37,1} Vgl. Dornberger et al. (2004), S. 31
38. ↑ Vgl. Ahrendts et al. (2008), S. 171
39. ↑ Vgl. Hillert (2011), S. 4
40. ↑ Vgl. Ernsting, S. 21
41. ↑ Ernsting, S. 21
42. ↑ ^{42,0 42,1} Vgl. Hillert (2011), S. 5
43. ↑ Vgl. Dornberger et al. (2004), S. 35
44. ↑ Vgl. Rumpe et al.(2001), S. 9
45. ↑ Vgl. Rumpe et al.(2001), S. 8 f
46. ↑ Vgl. Stephens et al. (2003), Chapter 5. The On-site Customer
47. ↑ Vgl. Wolf et al. (2005), S. 308
48. ↑ Zivkovic (2003), S. 54
49. ↑ ^{49,0 49,1 49,2 49,3 49,4 49,5} Vgl. Zivkovic (2003), S. 54 f
50. ↑ ^{50,0 50,1 50,2} Vgl. Göbel (2006), S. 13
51. ↑ Vgl. Ernsting, S. 17
52. ↑ Eckstein (2000), S.7
53. ↑ Vgl. Eckstein (2000), S. 8
54. ↑ Vgl. Ernsting, S. 18
55. ↑ ^{55,0 55,1} Vgl. Zeiger (2003), S. 6
56. ↑ ^{56,0 56,1 56,2 56,3} Vgl. Ernsting, S. 9 f
57. ↑ ^{57,0 57,1 57,2} Vgl. Rumpe et al. (2001), S. 34 ff
58. ↑ Vgl. Rumpe et al. (2001), S. 37
59. ↑ Vgl. Rumpe et al. (2001), S. 38 ff
60. ↑ Vgl. Rumpe et al. (2001), S. 50 ff
61. ↑ Vgl. Rumpe et al. (2001), S. 66 ff
62. ↑ ^{62,0 62,1 62,2} Vgl. Wolf et al. (2005), S. 268 bis 275
63. ↑ Wolf et al. (2005), S. 274
64. ↑ ^{64,0 64,1} Vgl. Rumpe (2001), S. 7 ff
65. ↑ ^{65,0 65,1 65,2} Vlg. Beckmann et al., S.124 f
66. ↑ ^{66,0 66,1} Vgl. Zeiger (2003), S. 18 f

9 Literatur- und Quellenverzeichnis

Verweis	Literatur / Quelle
Ahrendts et al. (2008)	Ahrendts, Fabian; Marton, Anita: IT-Risikomanagement leben! Wirkungsvolle Umsetzung für Projekte in der Softwareentwicklung, Springer-Verlag, 2008
Beck (1999)	Beck, Kent: Extreme Programming Explained: Embrace Change, Addison Wesley Professional, 1999
Beck et al. (2001)	Beck, Kent; Fowler, Martin: Planning Extreme Programming, Addison Wesley Professional, 2000
Beck (2003)	Beck, Kent: Extreme Programming Das Manifest, Addison-Wesley Verlag, 2003, (deutsche Übersetzung von Beck(1999))
Beck et al. (2004)	Beck, Kent; Andres, Cynthia: Extreme Programming Explained: Embrace Change, 2. Auflage, Addison Wesley Professional, 2004
Beckmann et al.	Beckmann, Ingrid; Schmedding, Doris: Experimente mit XP in der Lehre, Technische Universität Dortmund, http://subs.emis.de/LNI/Proceedings/Proceedings51/GI-Proceedings.51-29.pdf (22.05.2011, 17:15)
Dornberger et al. (2004)	Dornberger, Rolf; Habegger, Thomas: Extreme Programming: Eine Übersicht und Bewertung, Fachhochschule Solothurn Nordwestschweiz, 2004
Eckstein (2000)	Eckstein, Jutta: XP – eXtreme Programming: Ein leichtgewichtiger Software-Entwicklungsprozess, Universität Bonn, 2000, http://www.jeckstein.com/papers/basProXP.pdf
Ernsting	Ernsting, Jan: Extreme Programming Agilität in der Softwareentwicklung, Westfälische Wilhelms-Universität Münster, http://www.wi.uni-muenster.de/pi/lehre/ws0809/SeminarSE2/ausarbeitungen/ExtremeProgramming.pdf (16.06.2011 20:44)
Göbel (2006)	Göbel, Albrecht: Extreme Programming (XP), Technische Universität Berlin, 2006, http://swt.cs.tu-berlin.de/lehre/sepr/ws0607/referate/Vorgehensmodelle-XP_Ausarbeitung.pdf (16.06.2011, 21:00)
Hillert (2011)	Hillert, Johannes: Extreme Programming (XP), Fachhochschule Aachen, 2011, http://www.trautwein.fh-aachen.de/Download/SWE/SWE_Ausarbeitungen_WS2010/A_Extreme%20Programming_2010.pdf (16.06.2011, 21:00)
it-agile	it-agile - Die Experten für agile Softwareentwicklung, eXtreme Programming (XP), http://www.it-agile.de/xp.html (11.06.2011, 18:00)
projekt-it (2007)	Wasserfall-Modell, Projektmanagement, 2007, http://www.projekt-it.de/archives/5-Wasserfall-Modell.html (05.06.2011, 16:45)
Rumpe et al. (2001)	Rumpe, Bernhard; Schröder, Astrid: Quantitative Untersuchung des Extreme Programming Prozesses, 1. Auflage, Universität München, 2001
Rumpe (2001)	Rumpe, Bernhard: Extreme Programming – Back to Basics?, in: Engels, Georg (Hrsg.); Oberweis, Andreas (Hrsg.); Zündorf, Albert (Hrsg.): Modellierung 2001, Workshop der Gesellschaft für Informatik e. V. (GI) 28.–30.3.2001, Bad Lippspringe. Bonn :Gesellschaft für Informatik, Köllen Druck + Verlag GmbH, März 2001 (GI-Edition – Lecture Notes in Informatics – Proceedings), S. 121–131. http://www.ham.nw.schule.de/pub/bscw.cgi/d2370491/Rumpe2001.pdf (16.06.2011 20:41)
Stein (2004)	Stein, Sebastian: Emergenz in der Softwareentwicklung – bereits verwirklicht oder Chance?, Diplomarbeit, Hochschule für Technik und Wirtschaft Dresden, 2004, http://emergenz.hpfsc.de/da_sstein.pdf (16.06.2011 22:06)
Stephens et al. (2003)	Stephens, Matt; Rosenberg, Doug: Rumpe, Bernhard: Extreme Programming Refactored: The Case Against XP, 2003
Vogt (2007)	Vogt, Ingo: Agile Softwareentwicklung, ORDIX AG, 2007, http://www.ordix.de/ORDIXNews/3_2007/Projektmanagement/agile_softwareentwicklung.html (29.05.2011, 15:30)
Wikipedia, Extreme Programming (2011)	Wikipedia: Extreme Programming, http://de.wikipedia.org/wiki/Extreme_Programming (13.06.2011, 22:00)
Wolf et al. (2005)	Wolf, Henning; Roock, Stefan; Lippert, Martin: eXtreme Programming: Eine Einführung mit Empfehlungen und Erfahrungen aus der Praxis, 2. Auflage, dpunkt.verlag, Heidelberg 2005
Zeiger (2003)	Zeiger, Björn: eXtreme Programming: Konzepte, Ziele, Methoden - Praktische Erfahrungen aus XP-Projekten, Universität Paderborn, 2003, http://ag-kastens.upb.de/lehre/material/seminar_refactoring/semref-1-ausarbeitung.pdf (22.05.2011, 15:00)
Zivkovic (2003)	Zivkovic, Sini: Extreme Programming - Theorie und praktische Erfahrungen: Vom Apfelkuchen bis zur Datenbank, Diplomarbeit, Universität Fribourg (Schweiz), 2003, http://diuf.unifr.ch/people/fuhrer/studproj/zivkovic/xp_da_public.pdf (22.05.2011, 15:00)