Extreme Programming

Extreme Programming wurde von Kent Beck entwickelt und gilt als sehr

„leichtgewichtige“ Methode zur agilen Softwareentwicklung [Be00][BA04]. XP beschreibt einen Ansatz, welcher auf „(…) Wesentliches fokussiert und auf organisatorischen Ballast soweit wie möglich verzichtet.“ [Ru01, S.2]. Beispielsweise verzichtet XP auf die Erstellung von Dokumentationen. Beck unterteilt XP in drei Kategorien: Werte, Prinzipien und Praktiken.⁸⁶ Die Werte bilden die Basis von XP und werden durch die Prinzipien zu detaillierteren Handlungsempfehlungen verfeinert. Die Praktiken beschreiben Techniken, welche direkt während des Softwareentwicklungsprozesses angewendet werden.

Die fünf Werte von XP sind in der Tabelle 8 dargestellt.

Tabelle 8: Werte in XP [BA04]

1 Communication 2 Simplicity 3 Feedback 4 Courage 5 Respect

Der Begriff der Kommunikation wird als erster Wert von Beck genannt. Ein kontinuierlicher Informationsaustausch aller Projektbeteiligten dient zur Vermeidung von Problemen. Beispielsweise werden Fehlinterpretationen von Anforderungen durch eine intensive Diskussion vermieden. Zudem beschreibt der zweite Wert das Bedürfnis nach Einfachheit. Mit Hilfe von XP soll Software entwickelt werden, welche auf einfachen, schlanken Konzepten basieren. Insbesondere Anforderungen, die in der Zukunft möglicherweise auftreten könnten müssen nach Beck ignoriert werden. Feedback ist der dritte Wert von XP. Durch die Durchführung von kurzen Iterationen muss kontinuierlich

86 Die in dieser Arbeit dargestellte Einteilung beruht auf der zweiten Ausgabe von XP, vgl. [BA04]. In dieser zweiten Ausgabe erweiterte bzw. veränderte Beck die Methode und deren Werte, Prinzipien und Praktiken auf Basis von neuen Erfahrungen. In der ersten Veröffentlichung wurden beispielsweise nur vier Prinzipien genannt (communication, simplicity, feedback, courage), vgl. [Be00].

Feedback des Kunden eingeholt und analysiert werden. Des Weiteren fordert XP die Durchführung von Tests über den ganzen Softwareentwicklungsprozess (z.B. Unit-Test durch Entwickler, Akzeptanztest durch Kunden,...) zur Erfassung von Feedback. Die abstrakten Begriffe Mut und Respekt stellen die vierten und fünften Werte dar. Nur durch die mutige (und ehrliche) Umsetzung der XP-Prinzipien -und Praktiken kann ein erfolgreiches Projekt entstehen. Respekt gegenüber allen Projektbeteiligten ist hierbei essentiell. Zusätzlich zu den Werten werden vierzehn Prinzipien definiert. Die Prinzipien verfeinern die abstrakten Werte und sollen zur leichteren Ein –und Durchführung von XP dienen, indem alle angewendeten Praktiken auf die Einhaltung dieser Prinzipien geprüft werden [Ha10a]. Die Tabelle 9 listet die XP Prinzipien auf.

Tabelle 9: Liste der XP Prinzipien [BA04]

1 Humanity 2 Economics 3 Mutual Benefit 4 Self-Similarity 5 Improvement 6 Diversity 7 Reflection

8 Flow

9 Opportunity 10 Redundancy 11 Failure 12 Quality 13 Baby steps

14 Accepted Responsibility

An erster Stelle der Prinzipien steht der Begriff der Menschlichkeit. Der Softwareentwicklungsprozess wird von Menschen durchlebt. Alle XP-Projektbeteiligten sollen menschenwürdige Arbeitsbedingungen vorfinden (z.B. Integration im Team, Respekt gegenüber anderen,…). Zudem wird von allen Projektbeteiligten das Bewusstsein zum wirtschaftlichen Handeln gefordert. Das dritte Prinzip beschreibt die Anforderung entstandene Vorteile (z.B. Einführung von neuen Techniken) zu teilen.

Durch das Prinzip der Selbstgleichheit (viertes Prinzip) werden die Projektbeteiligten motiviert bereits angewendete Problemlösungen auch für neue Probleme einzusetzen.

Redundanz (zehntes Prinzip), beispielsweise durch parallel entwickelte Problemlösungen, wird in XP dennoch akzeptiert.

Eine ständige Verbesserung (fünftes Prinzip) durch Reflexion (siebtes Prinzip) stellen weitere Prinzipien von XP dar. Zum Beispiel werden in einer Planungsphase Fehler von vergangenen Iterationen berücksichtigt und somit das Vorgehen verbessert. Jedes Problem ist aus der Perspektive von XP auch eine Gelegenheit der Verbesserung (Prinzip neun). Innerhalb von XP wird versucht, ein vielfältiges (sechstes Prinzip) Projektteam in einen einheitlichen Fluss (achtes Prinzip) zu bringen. Diese Vielfältigkeit fördert kreative Lösungsansätze, welche in kleinen Schritten (dreizehntes Prinzip) iterativ implementiert werden können. Das implementierte Produkt muss hierbei einem hohen Qualitätsanspruch genügen (zwölftes Prinzip), wobei das Projektteam die Verantwortung annimmt und akzeptiert (vierzehntes Prinzip).

Die an die Prinzipien anschließenden Praktiken sind in primäre und begleitende Praktiken unterteilt⁸⁷. Beispielsweise dürfen in XP-Projekten keine Überstunden entstehen. Nach Beck sind Überstunden zu vermeiden, um Konzentrationsfähigkeit, Qualität und die Freunde an der Arbeit zu gewährleisten. Eine weitere Praktik ist die Paarprogrammierung. Hierbei wird die Implementierung von Software durch zwei Entwickler durchgeführt. Während der erste Entwickler programmiert, überprüft der zweite Entwickler die Implementierung fortlaufend. Mit Hilfe dieses Vier-Augen-Prinzips können Fehler schneller entdeckt oder direkt vermieden werden. Als weiteres Beispiel einer Praktik kann das Verfolgen eines „einfachen Designs“ genannt werden.

Die in XP entwickelte Software soll auf einer möglichst einfachen Lösung basieren.

87 Für eine weitere ausführliche Beschreibung aller Praktiken sei auf [Be00][BA04][Ha10a] verwiesen.

Anforderungen die zum Zeitpunkt des Design noch nicht bekannt sind werden ignoriert:

„Was noch nicht bekannt ist, kann auch nicht designt werden.“ [Ha10a, S.27].

Die Werte, Prinzipien und Praktiken werden während den Softwareentwicklungs-typischen Phasen von Planung, Design, Implementierung und Testen anwendet. In welcher Reihenfolge die Praktiken zum Einsatz kommen ist in XP nicht spezifiziert und kann agil festgelegt werden [Ha10a]. Die Abbildung 21 visualisiert ein XP-Vorgehensmodell nach [We00].

Abbildung 21: Vorgehensmodell in XP [We00]

In einem Architektur-Meeting und möglichen prototypischen Akzeptanztests werden die Vision, das Budget und die Zeitplanung (vgl. [BA04]) der zu entwickelnden Software definiert. Die nachfolgende Phase der Planung dient neben der Detailierung der Vision zur Analyse und Strukturierung der Anforderungen. Zusätzlich können aus der Planungsphase heraus sogenannte Spikes⁸⁸ gestartet werden. Mit Hilfe eines Spikes können beispielsweise einzelne Anforderungen auf prinzipielle Machbarkeit geprüft werden. Als weiteres Element der Vorgehensweise wird eine Iteration gestartet. Jede Iteration⁸⁹ besteht aus einer Planungs- ,entwicklungs- und testphase, wobei die zu verwendeten Tests bereits vor der Implementierung erstellt werden.

Treten Unsicherheiten in Bezug auf die zu implementierende Anforderung auf wird der Kunde befragt. Kommt es hierbei zu einer geänderten Anforderung ist ein Rücksprung in die Planungsphase (vgl. Abbildung 21) möglich. Als weitere Phase schließt sich die Prüfung der Akzeptanz an. Während dem Akzeptanztest wird die aktuelle Version der zu entwickelnden Software getestet. Auftretende Fehler oder Änderungen der

88 Vgl. dazu Beck [Be99, S.289f]: „(…) I call this a „spike“ because we are driving a spike through the entire design. We are not searching for completeness. Instead, we want to illustrate the kinds of responsibilities accepted by all the major objects in the system.”.

89 Vgl. http://www.extremeprogramming.org/map/iteration.html

Anforderungen haben einen Rücksprung in die vorgelagerte Phase zur Folge.

Abschließend wird die fertiggestellte Software ausgeliefert (Release).

Ein Rollenkonzept wird in XP nicht expliziert vorgegeben. Im Allgemeinen werden die Rollen des Kunden, Entwicklers und Managers festgelegt (vgl. [JAH00][Pr12]). Der Kunde ist Auftraggeber des Projekts und verantwortet die Formulierung der Anforderungen. Insbesondere durch die von XP geforderte ständige Anwesenheit des Kunden im Projektteam kann dieser fortlaufend Einfluss auf die Entwicklung (z.B. durch Beantwortung von fachlichen Fragen) nehmen. Die Rolle des Entwicklers übernimmt sowohl das Design der Software, als auch die Entwicklung von (automatisierten) Tests und der eigentlichen Software. Auf Basis der ständigen Kommunikation und Interaktion (z.B. Paarprogrammierung) aller Projektbeteiligten können Fragen und Probleme direkt gemeinschaftlich gelöst werden. Die Koordination des Projekts (z.B. Zeit –oder Ressourcenplanung) wird von der Rolle des Managers übernommen. Des Weiteren verantwortet der Manager den Kommunikations- und Interaktionsprozess aller Projektbeteiligten und unterstützt bei möglichen Komplikationen (z.B. Auflösung von Konflikten innerhalb des Projektteams).