HOCHSCHULE für Angewandte Wissenschaften LANDSHUT UNIVERSITY of Applied Sciences

FAKULTÄT Informatik

HOCHSCHULE LANDSHUT

FAKULTÄT INFORMATIK

Konstruktion eines Referenzmodells zum Vorgehensmodell Extreme Programming

Masterarbeit

vorgelegt von Nour Al Dares aus München

eingereicht am: .......................

Betreuer: Prof. Dr. rer. oec. Christian Seel

– II –

Erklärung zur Masterarbeit

Name, Vorname des Studierenden: ………………………...…………………………….

Hiermit erkläre ich, dass ich die Arbeit selbständig verfasst, noch nicht anderweitig für Prüfungszwecke vorgelegt, keine anderen als die angegebenen Quellen oder Hilfsmittel benutzt sowie wörtliche und sinngemäße Zitate als solche gekennzeichnet habe.

München, den ……………. …..…………………………………. (Unterschrift des Studierenden)

– III –

Inhaltsverzeichnis

Erklärung zur Masterarbeit ............................................................................................... II Inhaltsverzeichnis ............................................................................................................ III Abbildungsverzeichnis ..................................................................................................... V Tabellenverzeichnis ........................................................................................................ VI Abkürzungsverzeichnis ................................................................................................. VII 1 Exposition ..................................................................................................................... 1

1.1 Ausgangssituation und Motivation ........................................................................ 1 1.2 Zielsetzung ............................................................................................................. 2 1.3 Forschungsmethodik .............................................................................................. 3

1.3.1 Literaturrecherche ........................................................................................ 3 1.3.2 Design Science ............................................................................................. 6

1.4 Aufbau der Arbeit .................................................................................................. 7 2 Grundlagen zur Konstruktion eines Extreme Programming Referenzmodells .......... 10

2.1 Extreme Programming (XP) ................................................................................ 10 2.1.1 Grundidee ................................................................................................... 10 2.1.2 Komponenten ............................................................................................. 13

2.1.2.1 Werte .............................................................................................. 13 2.1.2.2 Prinzipien ........................................................................................ 16 2.1.2.3 Praktiken ......................................................................................... 20

2.1.2.3.1 Primärpraktiken ........................................................................ 22 2.1.2.3.2 Korollarpraktiken ...................................................................... 27

2.1.2.4 Rollen ............................................................................................. 31 2.1.3 Prozessablauf .............................................................................................. 31

2.2 Referenzmodellierung .......................................................................................... 35 2.2.1 Modell ........................................................................................................ 36

2.2.1.1 Allgemeiner Modellbegriff ............................................................. 36 2.2.1.2 Abbildungsorientierter Modellbegriff ............................................ 37 2.2.1.3 Konstruktionsorientierter Modellbegriff ........................................ 38

2.2.2 Referenzmodellierung ................................................................................ 40 2.2.2.1 Referenzmodellbegriff .................................................................... 41 2.2.2.2 Konstruktionsprozessorientierter Referenzmodellbegriff .............. 43 2.2.2.3 Ordnungsrahmen ............................................................................ 46

2.2.3 Modellierungstechnik ................................................................................. 48 2.2.3.1 Modellierungssprache..................................................................... 49 2.2.3.2 Business Process Model and Notation (BPMN) ............................ 50

2.2.4 Camunda Modeler als Modellierungswerkzeug ......................................... 51 3 Konstruktion eines Extreme Programming Referenzmodells .................................... 53

3.1 XP Ordnungsrahmen ........................................................................................... 53 3.2 XP Referenzprozesse ........................................................................................... 54

3.2.1 Verhandlung ............................................................................................... 54 3.2.2 Ökonomische Organisation ........................................................................ 55 3.2.3 Technische Organisation ............................................................................ 57 3.2.4 Projektplanung ........................................................................................... 58 3.2.5 Entwicklung ............................................................................................... 59

– IV –

3.2.6 Bereitstellung ............................................................................................. 63 3.2.7 Gesamtprozess ............................................................................................ 64

4 Evaluierung des konstruierten Extreme Programming Referenzmodells ................... 69 4.1 Exemplarische Anwendung ................................................................................. 69

4.1.1 CoachProfile ............................................................................................... 69 4.1.2 XP Referenzmodell anhand von CoachProfile ........................................... 71

4.1.2.1 Verhandlung ................................................................................... 72 4.1.2.2 Ökonomische Organisation ............................................................ 73 4.1.2.3 Technische Organisation ................................................................ 74 4.1.2.4 Projektplanung ................................................................................ 75 4.1.2.5 Entwicklung .................................................................................... 76 4.1.2.6 Bereitstellung .................................................................................. 79 4.1.2.7 Gesamtprozess ................................................................................ 80

4.2 Kritische Würdigung ........................................................................................... 86 5 Zusammenfassung ...................................................................................................... 87 Literaturverzeichnis ......................................................................................................... 88 Anhang ............................................................................................................................ 91

– V –

Abbildungsverzeichnis

Abbildung 1: Rahmen für die Literaturprüfung nach vom Brocke et al. .................... 5 Abbildung 2: Aufbau der Arbeit ................................................................................. 9 Abbildung 3: Iteratives, inkrementelles Vorgehensmodell nach Ruf und Fittkau .... 11 Abbildung 4: Gesamtbild der XP Komponenten ...................................................... 32 Abbildung 5: Push- und Pull-Modelle nach Beck und Andres ................................. 33 Abbildung 6: Schichtenmodell der Kategorisierung und Zuordnung aller 24 XP

Praktiken ............................................................................................. 35 Abbildung 7: Elemente des abbildungsorientierten Modellbegriffs nach Seel ......... 38 Abbildung 8: Elemente des konstruktionsorientierten Modellbegriffs nach Seel ..... 40 Abbildung 9: Problemfelder des Referenzmodellbegriffs nach vom Brocke ........... 43 Abbildung 10: Elemente des konstruktionsprozessorientierten

Referenzmodellbegriffs nach vom Brocke .......................................... 45 Abbildung 11: Y-CIM-Modell nach Scheer und Handels-H-Modell nach Becker und Schütte (v. l. n. r.) ......................................................................... 47 Abbildung 12: Komponenten einer Modellierungstechnik nach Seel ......................... 49 Abbildung 13: XP Ordnungsrahmen ........................................................................... 53 Abbildung 14: XP Referenzprozess Verhandlung ...................................................... 55 Abbildung 15: XP Referenzprozess Ökonomische Organisation ............................... 56 Abbildung 16: XP Referenzprozess Technische Organisation ................................... 57 Abbildung 17: XP Referenzprozess Projektplanung ................................................... 58 Abbildung 18: XP Referenzprozess Entwicklung ....................................................... 60 Abbildung 19: XP Referenzprozess Paarprogrammierung ......................................... 61 Abbildung 20: XP Referenzprozess Ursachenanalyse ................................................ 62 Abbildung 21: XP Referenzprozess Bereitstellung ..................................................... 64 Abbildung 22: XP Gesamtprozess .............................................................................. 68 Abbildung 23: CoachProfile User Stories ................................................................... 70 Abbildung 24: CoachProfile Oberflächenentwurf Landing Page ............................... 71 Abbildung 25: XP Referenzprozess Verhandlung adaptiert auf CoachProfile ........... 72 Abbildung 26: XP Referenzprozess Ökonomische Organisation adaptiert auf

CoachProfile ........................................................................................ 73 Abbildung 27: XP Referenzprozess Technische Organisation adaptiert auf

CoachProfile ........................................................................................ 74 Abbildung 28: XP Referenzprozess Projektplanung adaptiert auf CoachProfile ........ 75 Abbildung 29: XP Referenzprozess Entwicklung adaptiert auf CoachProfile ............ 77 Abbildung 30: XP Referenzprozess Paarprogrammierung adaptiert auf CoachProfile ........................................................................................ 78 Abbildung 31: XP Referenzprozess Ursachenanalyse adaptiert auf CoachProfile ..... 79 Abbildung 32: XP Referenzprozess Bereitstellung adaptiert auf CoachProfile .......... 80 Abbildung 33: XP Gesamtprozess adaptiert auf CoachProfile ................................... 85

– VI –

Tabellenverzeichnis

Tabelle 1: Taxonomie zur Literaturprüfung nach Cooper ..................................... 5 Tabelle 2: Richtlinien zur Design Science Forschung nach Hevner et al. ............. 7 Tabelle 3: Kategorisierung und Zuordnung aller 24 XP Praktiken in sechs

Schichten ............................................................................................. 34 Tabelle 4: Schicht der Verhandlung ..................................................................... 54 Tabelle 5: Schicht der Ökonomischen Organisation ............................................ 56 Tabelle 6: Schicht der Technischen Organisation ................................................ 57 Tabelle 7: Schicht der Projektplanung ................................................................. 58 Tabelle 8: Schicht der Entwicklung ..................................................................... 59 Tabelle 9: Schicht der Bereitstellung ................................................................... 64

– VII –

Abkürzungsverzeichnis

BPM Business Process Management BPMI Business Process Management Initiative BPMN Business Process Model and Notation bspw. beispielsweise BW Betriebswirtschaft bzw. beziehungsweise C3 Chrysler Comprehensive Compensation System CASE Computer Aided Software Engineering CMMN Case Management Model and Notation DMN Decision Model and Notation eEPK Erweiterte Ereignisgesteuerte Prozesskette et al. et alii ggf. gegebenenfalls IEC International Electrotechnical Commission IF Informatik ISO International Organization for Standardization max. maximal OMG Object Management Group sog. sogenannt u. a. unter anderem v. l. n. r. von links nach rechts XML Extensible Markup Language XP Extreme Programming z. B. zum Beispiel

– 1 –

1 Exposition

1.1 Ausgangssituation und Motivation

Die Referenzmodellierung hat die Wirtschaftlichkeitsförderung der modellgestützten Gestaltung von Informationssystemen zum Ziel. Dies soll mithilfe der Bereitstellung vorgefertigter Modelle, die im Kontext der Konstruktion von Informationsmodellen wiederverwendet werden, geschehen.1 Aufgrund der Möglichkeit der Wiederverwen-dung von Informationsmodellen, hat die Konstruktion dieser den Anspruch, von unter-nehmensspezifischen Charakteristiken abzusehen. Sie lassen sich aufgrund dessen wie folgt kategorisieren – in unternehmensspezifische Informationsmodelle sowie in Refe-renzmodelle.2

Die Referenzmodellierung dient der Unterstützung von u. a. Konstruktionsprozessen. Dabei sollen Informationsmodelle konstruiert werden, die repräsentative Inhalte, in Stellvertretung einzelner Anwendungen bzw. Anwendungsfällen, beschreiben, um diese in eben bspw. Konstruktionsprozessen wiederzuverwenden. So lässt sich für die Wis-senschaft der Wirtschaftsinformatik sowie für die Praxis in Unternehmen ein kostbarer Beitrag zur Lösung des formulierten Problems leisten. Durch die Konstruktion von Re-ferenzmodellen für Unternehmensklassen mit homogenen Bedarfen von Informationen, lässt sich das unternehmensübergreifende Wiederverwenden dieser realisieren. Inner-halb der Wirtschaftsinformatik lässt sich mithilfe von Referenzmodellen, die zur Prä-sentation reproduzierbarer und allgemeiner Ergebnisse von Entwicklungen dienen, zur Beherrschung der Komplexität beitragen.3 Auch lassen sich so für Anwender des Mo-dells einerseits Ressourcen wie Zeit sowie Kosten einsparen, andererseits durch das Verwenden von Referenzmodellen eine Qualitätssteigerung erzielen.4

Agilität ist in aller Munde. Sucht man heute5 auf Google nach dem Stichwort „agile“, erhält man ungefähr 136.000.000 Ergebnisse. Agilität etabliert sich immer mehr als das Paradigma des 21. Jahrhunderts. Vor allem Unternehmen müssen sich in der heutigen Zeit „in einer volatilen, unberechenbaren, chronisch unsicheren und erratischen Sys-temumwelt bewegen“6, innerhalb dieser nur der Anerkennung findet und Erfolg hat, der fähig, affin und offen ist, sich zu wandeln. Agilität ermöglicht Unternehmen erfolgskri-tische Wandlungen „schnell und flexibel, antizipativ und initiativ, effektiv und effizient,

1 Vgl. Delfmann (2006), Abstract 2 Vgl. Thomas (2006), S. 5 3 Vgl. Vom Brocke (2015), S. 2-3 4 Vgl. Thomas (2006), S. 7 5 Stand 09. November 2018 6 Prodoehl (2019), S. 11

– 2 –

proaktiv und reaktiv“7 zu realisieren. Sie ermöglicht so Unternehmen, kontinuierlich im Konsens mit den Systemumweltveränderungen zu agieren.8

Das agile Projektmanagement steht für eine Vorgehensweise in Projekten, innerhalb dieser sich die Parameter während der Laufzeit des Projektes dynamisch anpassen las-sen. Kennzeichnend sind die interaktive und enge Zusammenarbeit zwischen dem Auf-traggeber und dem Projektteam des Auftragnehmers sowie die kurzen Zeitintervalle, nach denen neue bzw. geänderte Anforderungen mit in das Projekt integriert werden können.9

Eines der ersten und somit grundlegendsten agilen Vorgehensmodelle, stellt das Extre-me Programming dar. Da das Vorgehensmodell von dessen Begründer KENT BECK10 relativ frei formuliert ist und keine wirkliche Struktur erkennbar ist, die ein konkretes Vorgehen erlaubt, ist es nun die in dieser Arbeit zugrunde liegende Aufgabe, ein Refe-renzmodell für das Vorgehensmodell des Extreme Programmings zu konstruieren.

Hieraus ergeben sich die beiden folgenden Forschungsfragen, die es mit dieser Arbeit zu beantworten gilt.

• Inwiefern ist es für das Projektmanagement wichtig Referenzmodellierung zu betreiben?

• Wie muss ein Referenzmodell für das Extreme Programming gestaltet sein?

1.2 Zielsetzung

Aus den beiden formulierten Forschungsfragen ergeben sich die Ziele dieser Arbeit. Das erste Ziel besteht darin die dieser Arbeit zugrunde liegenden Begrifflichkeiten einzufüh-ren und zu diskutieren. Somit stellt sich die Vorstellung des Vorgehensmodells des Ext-reme Programmings sowie sämtlicher aus diesen bestehenden Komponenten als erstes Ziel heraus. Das darauffolgende Ziel liegt in der Einführung des übergeordneten Be-griffs der Referenzmodellierung. Damit einher geht die Aufspaltung der Terme sowie der Erörterung aller aus dieser Aufspaltung hervorgehenden Begrifflichkeiten. Eines der zentralen Zielsetzungen hier ist die Vorstellung des dieser Arbeit zugrunde liegenden konstruktionsprozessorientierten Referenzmodellbegriffs. Als letzter Teil dieses Ab-

7 Prodoehl (2019), S. 11 8 Vgl. Prodoehl (2019), S. 11 9 Vgl. Urbach, http://www.enzyklopaedie-der-wirtschaftsinformatik.de/lexikon/is-management/Software-

Projektmanagement/agiles-it-projektmanagement/agiles-it-projektmanagement. Zuletzt geprüft am 09. November 2018.

10 Beck (2000)

http://www.enzyklopaedie-der-wirtschaftsinformatik.de/lexikon/is-management/Software-Projektmanagement/agiles-it-projektmanagement/agiles-it-projektmanagementhttp://www.enzyklopaedie-der-wirtschaftsinformatik.de/lexikon/is-management/Software-Projektmanagement/agiles-it-projektmanagement/agiles-it-projektmanagement

– 3 –

schnittes ist es das Ziel eine für das Vorhaben dieser Arbeit geeignete Modellierungs-sprache sowie -werkzeug zu selektieren und vorzustellen.

Folgend ist das nächste große Ziel die Konstruktion und Erläuterung von Referenzpro-zessen für das Vorgehensmodell des Extreme Programmings sowie allen zur Referenz-modellierung zählenden Komponenten, wie der Konstruktion eines Ordnungsrahmens.

Zum Ende dieser Arbeit liegt das Ziel in der Evaluierung des konstruierten Referenz-modells. So ist hier die Zielsetzung, die Konstruktion exemplarisch anzuwenden sowie daraufhin diese kritisch zu würdigen.

1.3 Forschungsmethodik

Die Wahl der Forschungsmethodik steht stets in Relation zu den definierten For-schungsfragen sowie zu den aus diesen abgeleiteten Zielen. Sie muss sich zur Erfüllung dieser eignen und ist somit nicht von vornherein vorgegeben. Vielmehr stellt sie eine Entscheidung dar, die man stets eigens für jede neu definierte Forschungsfrage treffen muss. Die Wahl der Forschungsmethodik ist zwangsläufig. Sie legt das Vorgehen sowie den Aufbau einer Arbeit fest.11

SEEL sagt, dass sich in der Wirtschaftsinformatik im Grundsatz zwei Klassen von For-schungsfragen unterscheiden lassen. Forschungsfragen der einen Klasse zielen darauf ab, „den gegenwärtigen Einsatz und die Entwicklung von Informationssystemen sowie der dazu eingesetzten Methoden zu untersuchen, wozu auch die Analyse der bestehen-den Literatur zu zählen ist“12. Forschungsfragen der zweiten Gruppe haben zum Ziel, neue Lösungen hervorzubringen.13

Die erste Forschungsfrage hat zum Ziel, bereits zu dieser Thematik existierende Litera-tur zu analysieren, weshalb im nächsten Abschnitt die Literaturrecherche als erste For-schungsmethodik ausgeführt wird. Die zweite Forschungsfrage hat zum Ziel ein Refe-renzmodell zu konstruieren, weshalb im darauffolgenden Abschnitt das Design Science Paradigma als zweite Forschungsmethodik erläutert wird.

1.3.1 Literaturrecherche

VOM BROCKE et al. definieren die Literaturrecherche als den ersten wesentlichen Schritt, wenn es darum geht, sich mit einer Forschungsthematik auseinander zu setzen.14 11 Vgl. Seel (2010), S. 7 12 Seel (2010), S. 7 13 Vgl. Seel (2010), S. 7 14 Vgl. Vom Brocke et al. (2009), S. 3

– 4 –

Die Literaturrecherche trägt signifikant dazu bei, dass einerseits die Bedeutung und Wichtigkeit eines Forschungsfeldes zunimmt, andererseits die logische Richtigkeit der Thematik bestätigt wird, indem bereits erforschtes und somit vorhandenes Wissen sinn-voll genutzt wird.15 Fachgebiete lassen sich so zusammenfassen, wodurch das Definie-ren genauer Forschungsfragen unterstützt wird.16 Im Grunde umfasst eine Literatur-recherche die Ergebnisse zweier Prozedere. Zum einen das Durchsuchen von wissen-schaftlichen Datenbanken mithilfe von Stichwörtern, zum anderen die Rückwärts- bzw. Vorwärtssuche anhand relevanter Publikationen. Gemäß VOM BROCKE et al. ist die Be-deutung einer Rückwärtssuche, die Recherche der Referenzen der gefundenen Artikel, die aus der Stichwortsuche resultieren. Hingegen beschäftigt sich die Vorwärtssuche mit der Überprüfung zusätzlicher Quellen – zusätzlich zu den, die in den gefundenen Publi-kationen angegeben sind.17 Eine Literaturrecherche lässt sich nach VOM BROCKE et al. zusammenfassen als eine Ermittlung und Auswertung von Fachliteratur.18 Die durchaus unterschiedlichen Ziele von Literaturrecherchen reichen von der Gewinnung neuer bzw. dem Zusammenführen vorhandener Forschungsergebnisse, bis hin zur Eruierung ge-bräuchlicher Forschungstechniken oder -methoden.19

Im Gegensatz zu anderen empirischen Analysen, existieren für die Literaturrecherche nur einige wenige ausführliche Methoden bzw. standardisierte Vorgehensweisen.20 VOM BROCKE et al. haben deshalb einen eigenen Rahmen für den Prozess der Literaturprü-fung entwickelt, der sich besonders auf den Teilprozess der Literaturrecherche fokus-siert. Der Rahmen ist als zirkulärer Fünf-Phasen-Prozess dargestellt. Der Grund hierfür ist das stetige Wachstum von Wissen, was dazu führen kann, dass bisherige Literatur-prüfungen veralten und infolgedessen neu geprüft und aktualisiert werden müssen.21 Die folgende Abbildung 1 veranschaulicht den Prozess.

15 Vgl. Vom Brocke et al. (2009), S. 4 16 Vgl. Vom Brocke et al. (2009), S. 5 17 Vgl. Vom Brocke et al. (2009), S. 4 18 Vgl. Vom Brocke et al. (2009), S. 6 19 Vgl. Vom Brocke et al. (2009), S. 9 20 Vgl. Vom Brocke et al. (2009), S. 7 21 Vgl. Vom Brocke et al. (2009), S. 8

– 5 –

Quelle: In Anlehnung an vom Brocke et al. (2009), S. 9

Abbildung 1: Rahmen für die Literaturprüfung nach vom Brocke et al.

Neben dem Einhalten der Vorgehensweise zur Literaturprüfung, ist es gemäß VOM BROCKE et al. ebenso relevant auf ein etabliertes Klassifikationsschema zurückzugrei-fen, um den Überprüfungsumfang stringent zu determinieren. Sie schlagen hierfür die Taxonomie nach COOPER22 vor. Diese umfasst sechs Charakteristiken, von denen jedes Charakteristikum aus bestimmten Kategorien besteht – einige schließen sich gegenseitig aus (Perspektive und Abdeckung), während andere kombiniert werden können (Ziel-gruppe, Organisation, Ziel und Fokus).23 Die folgende Tabelle 1 legt das Klassifikati-onsschema dar.

Tabelle 1: Taxonomie zur Literaturprüfung nach Cooper24

Charakteristik Kategorien Fokus Forschungsergebnisse

Forschungsmethoden Theorien Praktiken oder Anwendungen

Ziel Integration Kritik Identifizierung zentraler Probleme

Perspektive Neutrale Repräsentation Eintreten für eine Position

Abdeckung Vollständig Erschöpfend mit selektivem Zitat Repräsentativ Wesentlich oder grundlegend

22 Cooper (1988), S. 109 23 Vgl. Vom Brocke et al. (2009), S. 9 24 Cooper (1988), S. 109

– 6 –

Organisation Historisch Konzeptionell Methodologisch

Zielgruppe Spezialisierte Forscher Allgemeine Forscher Anwender oder Entscheidungsträger Öffentlichkeit

1.3.2 Design Science

Mithilfe des Design Science Paradigmas soll anhand der Entwicklung neuer und inno-vativer Artefakte das Ausdehnen der Grenzen der anthropomorphischen und organisato-rischen Fähigkeiten ermöglicht und vorangetrieben werden. Dafür haben HEVNER et al. einen konzeptionellen Rahmen25 entwickelt sowie sieben klare Richtlinien definiert, um die designwissenschaftliche Forschung in Informationssystemen hinsichtlich des Ver-ständnisses, der Durchführung sowie der Auswertung der Forschung zu beschreiben. Das Design Science Paradigma soll also anhand der Entwicklung und der Anwendung des konstruierten Artefaktes dazu beitragen, Wissen und Verständnis für ein abgegrenz-tes Problemfeld sowie dessen Lösungskonzept zu erreichen.26 Aus informationstechni-scher Sicht können Artefakte Konstrukte (Vokabular und Symbole), Modelle (Abstrak-tionen und Repräsentationen), Methoden (Algorithmen und Praktiken) und Instanziie-rungen (implementierte Systeme und Prototypsysteme) sein.27

Der konzeptionelle Rahmen spiegelt einen Entwicklungsprozess wieder, der eine Ab-folge von Aktivitäten darstellt und es zum Ziel hat ein innovatives Produkt – das Arte-fakt – zu erzeugen. Die Evaluation des Artefaktes liefert dann Rückinformationen, um ein besseres Problemverständnis zu generieren. Dies soll zur Folge haben, dass sowohl die Produktqualität als auch der Entwicklungsprozess optimiert werden. HEVNER et al. sprechen hierbei von einer iterativen Entwicklungs-und-Evaluations-Schleife, die mehr-fach durchlaufen wird, bevor das endgültige Design-Artefakt erzeugt wird.28

Darauf aufbauend haben HEVNER et al. sieben adaptive und prozessorientierte Richtli-nien definiert.29 Das Grundprinzip aus der die Richtlinien abgeleitet sind, besteht darin, dass Wissen und Verständnis einer Problematik und dessen Lösung bei der Entwicklung

25 Hevner et al. (2004), S. 80 („Figure 2. Information Systems Research Framework”) 26 Vgl. Hevner et al. (2004), S. 75 27 Vgl. Hevner et al. (2004), S. 77 28 Vgl. Hevner et al. (2004), S. 78 29 Vgl. Hevner et al. (2004), S. 81

– 7 –

und Anwendung eines Artefaktes erworben werden.30 Die folgende Tabelle 2 listet die Richtlinien nach HEVNER et al. auf und beschreibt diese.

Tabelle 2: Richtlinien zur Design Science Forschung nach Hevner et al.31

Richtlinie Beschreibung Entwickeln eines Artefaktes

Es muss ein innovatives und zielgerichtetes Artefakt32 in Form eines Konstrukts, eines Modells, einer Methode oder einer Instanziierung entwickelt werden.

Problemrelevanz Es müssen Lösungen für wichtige und relevante Problemstel-lungen entwickelt werden.

Evaluation Es muss der Nutzen, die Qualität sowie die Anwendbarkeit eines Artefaktes durch passende Methoden evaluiert werden.33

Forschungsbeitrag Es müssen klare und verifizierbare Beiträge in Form von Arte-fakten, Methoden und/oder grundlegenden Lösungen bereitge-stellt werden.

Forschungsstringenz Es müssen stringente Methoden bei der Entwicklung und der Evaluation eines Artefaktes angewandt werden.

Entwicklung als Suchprozess

Es muss bei der Entwicklung eines Artefaktes in Form eines effektiven Lösungssuchprozesses vorgegangen werden.34

Verbreitung von Forschungsergebnissen

Es müssen Forschungsergebnisse mit sowohl technologie-orientierten als auch mit betriebswirtschaftlich-orientierten Zielgruppen kommuniziert werden.

1.4 Aufbau der Arbeit

Nach dem einführenden Kapitel der Exposition, folgt im zweiten Kapitel die Ausarbei-tung der Grundlagen. Das Grundlagen-Kapitel ist eingeteilt in zwei Abschnitte. Begin-nend mit dem Punkt des Extreme Programmings, geht es in der zweiten Hälfte um die Referenzmodellierung. Zum Extreme Programming wird zu Beginn die Grundidee des Vorgehensmodells erläutert. Daraufhin werden sämtliche, dem Extreme Programming zugehörige, Komponenten eingeführt und näher betrachtet, bevor die erste Hälfte des Kapitels der Grundlagen mit einer Gesamtübersicht zum Vorgehensmodell des Extreme Programmings abschließt. Im Kapitel der Referenzmodellierung werden zu Beginn die verschiedensten Möglichkeiten des Verständnisses des Modellbegriffs eingeführt und definiert, bevor darauffolgend näher auf die Referenzmodellierung eingegangen wird. Hier wird mit einer näheren Betrachtung des Referenzmodellbegriffs begonnen, ehe der dieser Arbeit zugrunde liegende Term des konstruktionsprozessorientierten Referenz-modellbegriffs vorgestellt wird. Die zweite Hälfte des Grundlagen-Kapitels schließt mit

30 Vgl. Hevner et al. (2004), S. 82 31 Hevner et al. (2004), S. 83 32 Vgl. Hevner et al. (2004), S. 82 33 Vgl. Seel (2010), S. 13 34 Vgl. Zelewski (2007), S. 78

– 8 –

der Einführung der in dieser Arbeit zur Konstruktion verwendeten Modellierungsspra-che sowie des Modellierungswerkzeugs ab.

Das dritte Kapitel beschäftigt sich mit der eigentlichen, dieser Arbeit zugrunde liegen-den Zielsetzung – der Konstruktion eines Extreme Programming Referenzmodells. In diesem wird zu Beginn ein Ordnungsrahmen entworfen und vorgestellt, ehe im darauf-folgenden Abschnitt die Referenzprozesse zum Vorgehensmodell konstruiert und näher betrachtet werden. Das Vorgehensmodell des Extreme Programmings wird im Vorfeld in sechs Schichten kategorisiert, wodurch sich hier dementsprechend sechs Unterkapitel ergeben. Das siebte und letzte Unterkapitel thematisiert den Gesamtprozess, der sich aus den einzelnen Referenzprozessen ergibt.

Das vierte Kapitel dient der Evaluierung des im vorherigen Kapitel konstruierten Refe-renzmodells. Eingeteilt in zwei Abschnitte, werden die einzelnen Referenzprozesse zu Beginn exemplarisch auf ein an der Hochschule Landshut im Sommersemesters 2017 und Wintersemesters 2017 / 2018 durchgeführten Studienprojekt angewendet. Der zwei-te Teil dieses Kapitels dient der kritischen Würdigung des konstruierten Referenzmo-dells.

Das fünfte und letzte Kapitel fasst die Arbeit noch einmal abschließend zusammen. Die folgende Abbildung 2 gibt einen grafischen Überblick über den Aufbau der Arbeit.

– 9 –

Exposition

Zusammenfassung

Grundlagen

Extreme Programming Referenzmodellierung

Grundidee

Komponenten

Prozessablauf

Modellbegriff

Referenzmodellbegriff

Sprache Werkzeug

Konstruktion des Extreme Programming Referenzmodells

Ordnungsrahmen

Referenzprozesse

Verhandlung

Ökonomische Organisation

Technische Organisation

Projektplanung

Entwicklung

Bereitstellung

Evaluierung

Exemplarische Anwendung Kritische Würdigung

Gesamtprozess

Quelle: Eigene Darstellung

Abbildung 2: Aufbau der Arbeit

– 10 –

2 Grundlagen zur Konstruktion eines Extreme Programming Refe-renzmodells

In diesem Kapitel werden die dieser Arbeit zugrunde liegenden Gegenstände diskutiert. Eingeteilt in zwei Unterkapitel, thematisiert das erste der beiden das Vorgehensmodell des Extreme Programmings. Die zweite Hälfte beschäftigt sich mit der Thematik der Referenzmodellierung.

2.1 Extreme Programming (XP)

In seinem Buch „Extreme Programming Explained: Embrace Change”35 stellt BECK im Jahr 2000 erstmals sein eigens entwickeltes agiles Vorgehensmodell Extreme Pro-gramming, kurz XP, öffentlich vor. Gemeinsam mit ANDRES veröffentlichte BECK 2004 die zweite Auflage des Buches unter dem selbigen Titel36, in dem sie XP komplettüber-arbeitet neu vorstellen. XP entstand Ende der 1990er Jahre und geht auf Arbeiten von Kent Beck, Ward Cunningham und Ron Jeffries zurück.37 Das Modell kam erstmals während des Chrysler-Projektes Chrysler Comprehensive Compensation System38, kurz C3, vor, in dem es um die Entwicklung einer einzigen Anwendung ging, die Chryslers bisherige Lohnbuchhaltungssysteme ersetzen sollte.

Im Folgenden wird zu Beginn die Grundidee XPs erläutert. Daraufhin werden sämtliche Komponenten, aus denen sich das Vorgehensmodell zusammensetzt, vorgestellt – von Werten, über Prinzipien und Praktiken, hin zu Rollen. Am Ende des Kapitels zeigt der Abschnitt Prozessablauf einen Gesamtüberblick über XP auf.

2.1.1 Grundidee

XP zählt in der agilen Softwareentwicklung zu den iterativen, inkrementellen Vorge-hensmodellen. Der Softwareentwicklungsprozess wird hier als ein evolutionärer Prozess formuliert. Ausgehend von einer ersten Softwareversion wird sich über mehrere Weiter-entwicklungen dem Endprodukt genähert.39 Die folgende Abbildung 3 veranschaulicht das Vorgehensmodell.

35 Beck (2000) 36 Beck, Andres (2004) 37 Vgl. Wikipedia, https://de.wikipedia.org/w/index.php?title=Extreme_Programming&oldid=180841379.

Zuletzt geprüft am 12. September 2018. 38 Vgl. Wikipedia,

https://en.wikipedia.org/w/index.php?title=Chrysler_Comprehensive_Compensation_System&oldid=799769369. Zuletzt geprüft am 12. September 2018.

39 Vgl. Ruf, Fittkau (2008), S. 34

https://de.wikipedia.org/w/index.php?title=Extreme_Programming&oldid=180841379https://en.wikipedia.org/w/index.php?title=Chrysler_Comprehensive_Compensation_System&oldid=799769369https://en.wikipedia.org/w/index.php?title=Chrysler_Comprehensive_Compensation_System&oldid=799769369

– 11 –

Quelle: Ruf und Fittkau (2008), S. 35

Abbildung 3: Iteratives, inkrementelles Vorgehensmodell nach Ruf und Fittkau

Durch die frühe Einbindung des Kunden in den Entwicklungsprozess, wird hier das Entwicklungsrisiko reduziert. Der Zeitraum zwischen dem Projektstart und der Auslie-ferung eines ersten Teilproduktes ist im Vergleich zu sequentiellen oder rein inkremen-tellen Vorgehensmodellen verkürzt.40

40 Vgl. Ruf, Fittkau (2008), S. 34

– 12 –

Agile Methoden wie XP zielen darauf ab schnell zur Verfügung stehende Ergebnisse zu realisieren, um so den Zeitraum bis zur Markteinführung zu dezimieren.41 XP fokussiert sich hierbei vor allem auf den Quellcode. Das Programmieren ist die Schlüsselaktivität und somit der zentrale Punkt sämtlicher Aufgaben rund um die Codeerstellung. Neben technischen Faktoren werden im Vorgehensmodell auch verschiedene soziale Aspekte, wie die Teamorientierung, berücksichtigt.42

Die Grundidee bei XP liegt wie bei sämtlichen agilen Softwareentwicklungsmethoden darin, den Prozess der Entwicklung schlanker, flexibler sowie effizienter zu gestalten. Dies soll hier einerseits mithilfe von Bürokratisierungsabbau, sowie andererseits durch das intensivere Berücksichtigen menschlicher Aspekte geschehen.43

Auf der Basis von Werten, Prinzipien und Praktiken, die XP grundlegend definieren, soll die bloße Entwurfsphase auf ein Minimum dezimiert werden und im Prozess der Entwicklung frühestmöglich zu einer ausführbaren Software gelangt werden. Diese wird dem Kunden in kurzen, regelmäßigen Releasezyklen zur gemeinsamen Abstimmung und dem Testen der Software vorgelegt. XP eignet sich jedoch lediglich für Projekte mit überschaubarem Umfang.44 Auch sollte das Projektteam aus nicht mehr als einer guten Handvoll Beteiligter bestehen. Vor Vertragsabschluss müssen die Projekteigenschaften zwischen dem Dienstleister und dem Kunden ausreichend diskutiert worden sein. Die Ausarbeitung eines Lasten- sowie eines Pflichtenhefts zur genauen Klärung der Anfor-derungen und wie diese seitens des Dienstleisters realisiert werden sollen, ist nur schwerlich möglich, da die Ausarbeitung und Formulierung der Anforderungen, gemäß der Definition XPs, erst während des laufenden Projektes geschieht. So können sich auch die Anforderungen während des gesamten Projektzeitraums stetig ändern oder kurzerhand neue Anforderungen hinzukommen.45

XPs größter Vorteil liegt in dessen Agilität. Aufgrund der kurzen Iterationszyklen be-sitzt XP die Fähigkeit Anforderungsänderungen schnell begegnen zu können.46

Als Anwender von XP muss man sich mit dessen Fundament – den Werten sowie den Prinzipen – identifizieren können, um einen erfolgreichen Einsatz des Vorgehensmo-dells zu garantieren. Auch sind die Praktiken XPs teils aufwändig bzw. gewöhnungsbe-

41 Vgl. Ruf, Fittkau (2008), S. 36 42 Vgl. Ruf, Fittkau (2008), S. 36-37 43 Vgl. Schwarzer, Krcmar (2014), S. 153 44 Vgl. Schwarzer, Krcmar (2014), S. 154 45 Vgl. Schwarzer, Krcmar (2014), S. 154 46 Vgl. Schwarzer, Krcmar (2014), S. 155

– 13 –

dürftig und müssen vom Team vorab eingeübt werden. Die Einführungsphase kann demzufolge aufwendiger sein als bspw. bei Scrum.47

2.1.2 Komponenten

Das Gesamtgerüst rund um XP besteht aus fünf Werten, 14 Prinzipien, 24 Praktiken – 13 Primär- und elf Korollarpraktiken – sowie neun Rollen.

Praktiken sind die Dinge, die tagtäglich gemacht werden. Das Angeben von Praktiken ist nützlich, weil sie klar und objektiv sind. Praktiken sind auch deshalb nützlich, weil sie einem einen Punkt zum Beginnen geben. Werte sind die Wurzeln der Dinge, die einem in einer Situation gefallen und nicht gefallen. Werte sind die Maßstabskriterien, anhand derer man beurteilt, was gesehen, gedacht und getan wird. Werte ausdrücklich festzulegen, ist wichtig, denn ohne Werte werden Praktiken schnell zu Routinen – zu Aktivitäten, die um ihrer selbst willen ausgeführt werden, aber keinen Zweck oder Rich-tung haben. Das Zusammenführen von Werten mit Praktiken bedeutet, dass man eine Praktik zeiteffektiver und aus einem bestimmten Grund durchführt. Werte bringen Prak-tiken einen Zweck ein. Praktiken sind ein Beweis für Werte. Praktiken schreiben Wer-ten Verantwortungen zu. Werte sind universell, Praktiken jedoch strikt festgelegt. Werte und Praktiken liegen weit auseinander. Prinzipien, domänenspezifische Richtlinien, schließen die Lücke zwischen Werten und Praktiken.48

Im Folgenden werden die sämtlichen, dem Vorgehensmodell zugrunde liegenden Kom-ponenten erörtert. Beginnend mit den Werten, geht es über die Prinzipien und Praktiken, abschließend zu den Rollen.

2.1.2.1 Werte

Eine einheitliche Wertestruktur sowie eine gemeinsame Wertevorstellung sollen den langfristigen Erfolg eines Projektes sichern.49 BECK und ANDRES haben daher fünf grundlegende sowie einige weitere Werte für XP definiert.50 Im Folgenden werden diese Werte beschrieben.

Kommunikation

Bei Projekten kommt es insbesondere auf die Kommunikation an. Kommunikation ist vor allem wichtig, um ein Teamgefühl zu schaffen und eine effektive Zusammenarbeit 47 Vgl. Schwarzer, Krcmar (2014), S. 155 48 Vgl. Beck, Andres (2004), S. 13-15 49 Vgl. Ruf, Fittkau (2008), S. 37 50 Vgl. Beck, Andres (2004), S. 17-22

– 14 –

zwischen allen Projektbeteiligten zu garantieren.51 Die Kommunikation ist entscheidend für den Projekterfolg. Es wird zwischen der internen Kommunikation innerhalb des Pro-jektteams und der Kundenkommunikation unterschieden.52

Die interne Teamkommunikation bildet die Grundlage für die kollektive Vorgehenswei-se im Projekt. Kommunizieren alle Teammitglieder miteinander, sind allen die gemein-samen Ziele bekannt. Auch lässt sich so effizienter auf neue Anforderungen und abwei-chende Projektziele reagieren. Eine reibungslose Teamkommunikation kann nur mithil-fe eines räsonablen psychologischen Prozesses erreicht werden. Dies lässt sich allein durch eine entsprechende Zusammenstellung des Projektteams erreichen.53

Die Kundenkommunikation soll so einfach und effektiv wie möglich gestaltet sein. Deshalb soll der Kunde einen Teil des Projektteams darstellen und sich stets vor Ort beim Entwicklerteam aufhalten. Dies stellt sich allerdings oft als schwierig dar, da sich Teams davor sträuben können den Kunden als Teammitglied zu akzeptieren. Werden Kunden in die Projektteams aufgenommen, fühlen diese sich aber ernst genommen und können schon in frühen Phasen von Projekten am Erfolg und Misserfolg dieser beteiligt werden. Durch die Nähe zum Projekt entwickeln Kunden auch ein grundsätzlich besse-res Verständnis für aufkommende Probleme und können deutlich effektiver auf Fragen des Teams reagieren und eingehen.54

Trivial ist die Anforderung, dass es sich bei dem Kunden um einen späteren Anwender des Systems handeln muss, der die entsprechenden Kompetenzen mitbringt, fachlich und verantwortlich über den Funktionsumfang entscheiden zu können.55

Einfachheit

Ein System so einfach zu gestalten, dass nur das derzeitige Problem elegant gelöst wer-den kann, ist harte Arbeit. Einfachheit ist nur im Kontext sinnvoll – es ist immer abhän-gig von dem zu lösenden Problem. Die einzelnen Werte in XP sollen sich gegenseitig ausgleichen und unterstützen. So trägt eine Verbesserung der Kommunikation auch zu einer Vereinfachung bei, indem unnötige oder aufschiebbare Anforderungen aus den derzeitigen Belangen eliminiert werden. Erreicht man Einfachheit, kann deutlich weni-ger kommuniziert werden.56

51 Vgl. Beck, Andres (2004), S. 18 52 Vgl. Hanser (2010), S. 14 53 Vgl. Hanser (2010), S. 14 54 Vgl. Hanser (2010), S. 14 55 Vgl. Hanser (2010), S. 15 56 Vgl. Beck, Andres (2004), S. 18-19

– 15 –

Eine einfache Lösung eines Problems ist immer einer komplexeren Lösung vorzuzie-hen. Diese können schneller interpretiert und realisiert werden. Es muss sich also fort-laufend die Frage gestellt werden, was zum aktuellen Zeitpunkt die einfachste Lösung ist.57

Feedback

Feedback ist ebenfalls aus mehreren Perspektiven zu betrachten. Einerseits braucht das Entwicklerteam Feedback vom System. Dieses Feedback holt es sich in Form von Tests. Andererseits ist das Team auf das Feedback des Kunden über das System angewiesen. Weshalb es umso effektiver ist, den Kunden vor Ort im Projektteam zu haben. Auch erhält der Kunde vom Entwicklerteam in kurzen und regelmäßigen Abständen Feedback zum aktuellen Stand des Projektes.58

Das Feedback soll genutzt werden, um den Projektzielen Schritt für Schritt näher zu kommen. Es kann in vielen verschiedenen Formen vorkommen, sei es als Meinung über eine Idee, in Form von Quellcode, Feedback darüber ob Tests einfach zu schreiben wa-ren oder überhaupt laufen. XP Teams sollen in kürzester Zeit den höchstmöglichen Output an Feedback generieren. Der Feedback-Zyklus soll von Wochen oder Monaten auf Minuten oder Stunden verkürzt werden. Umso früher man Feedback erhält, desto schneller lässt es sich umsetzen. Es ist möglich zu viel Feedback zu bekommen. Bei einer zu hohen Menge an Feedback, kann es passieren, dass das Team anfängt wichtiges Feedback zu ignorieren. In solch einem Fall muss das Team die Geschwindigkeit ver-ringern, bis es wieder auf sämtliches Feedback effektiv reagieren kann. Das Team kann so auch auf die zugrundeliegenden Probleme eingehen, die das Übermaß an Feedback verursacht haben. Feedback ist ein ausschlaggebender Teil der Kommunikation und trägt auch zur Einfachheit bei. Je einfacher ein System ist, desto einfacher ist es, Feed-back darüber zu erhalten.59

Mut

Dazu bereit zu sein, das Projekt ständig zu verbessern, erfordert Mut.60 Mut kann sich als eine Tendenz zum Handeln offenbaren. Weiß man wo das Problem liegt, muss man etwas dagegen tun. Mut kann sich aber auch als Geduld offenbaren. Wenn man weiß, dass ein Problem existiert, es aber nicht genau kennt, bedarf es Mut, darauf zu warten, dass das eigentliche Problem deutlich hervortritt. Mut als primärer Wert ohne einen

57 Vgl. Ruf, Fittkau (2008), S. 38 58 Vgl. Hanser (2010), S. 15 59 Vgl. Beck, Andres (2004), S. 19-20 60 Vgl. Ruf, Fittkau (2008), S. 38

– 16 –

ausgleichenden Wert kann Gefahren hervorrufen. Etwas ohne Rücksicht auf die Konse-quenzen zu tun, hat nichts mit effektiver Teamarbeit zu tun. Die Teamarbeit muss ermu-tigt werden, indem man in Angst- und Stresssituationen auch auf die restlichen Werte achtet. Wenn Mut allein gefährlich ist, ist er in Übereinstimmung mit den anderen Wer-ten stark. Den Mut zu haben, Wahrheiten an- und auszusprechen, fördert Kommunikati-on und Vertrauen. Den Mut zu haben, erfolglose Lösungen zu verwerfen und neue zu suchen, fördert die Einfachheit. Den Mut zu haben, echte und konkrete Antworten zu suchen, schafft Feedback.61

Respekt

Respekt zählt als der grundlegendste der fünf Werte in XP. Der vertrauens- und res-pektvolle gegenseitige Umgang innerhalb des Teams, mit dem Kunden und dem gesam-ten Projekt ist die Voraussetzung für den Erfolg. Die Beiträge aller der am Projekt betei-ligten Personen müssen respektiert werden.62

Weitere

Die oben genannten fünf Werte Kommunikation, Einfachheit, Feedback, Mut und Res-pekt bilden das Grundgerüst und sind die treibenden Werte für ein erfolgreiches Projekt in XP. Jedes Unternehmen, jedes Team und man selbst kann sich zusätzliche Werte definieren. BECK und ANDRES sagen, das wichtigste sei, das Teamverhalten auf die Teamwerte abzustimmen. Sie nennen Sicherheit, Vorhersehbarkeit und Lebensqualität als weitere wichtige Werte.63

2.1.2.2 Prinzipien

Werte allein geben keine konkreten Hinweise darüber, was im Projekt genau zu tun ist. Um die Lücke zwischen den Werten und den Praktiken zu schließen, bedarf es Prinzi-pien. Diese sind das Werkzeug – domänenspezifische Richtlinien für das Ausmachen von Praktiken, die im Einklang mit den Werten stehen.64 Die Prinzipien sollen nicht nur dabei helfen die Praktiken besser zu verstehen, vielmehr sollen mithilfe der Prinzipien für jedes Projekt individuell ergänzende Praktiken hinzudefiniert werden, sollte dies nötig sein. Die Prinzipien sollen dazu beitragen eine bessere Vorstellung darüber zu erhalten, was mithilfe der Praktiken erreicht werden soll.65

61 Vgl. Beck, Andres (2004), S. 20-21 62 Vgl. Beck, Andres (2004), S. 21 63 Vgl. Beck, Andres (2004), S. 21-22 64 Vgl. Beck, Andres (2004), S. 22 65 Vgl. Beck, Andres (2004), S. 34

– 17 –

Aus den Wertevorstellungen haben BECK und ANDRES 14 Grundprinzipien abgeleitet, die sie handlungsanleitend formuliert haben.66 Im Folgenden werden diese Prinzipien beschrieben.

Menschlichkeit

Es handelt sich um Menschen, die in den Teams an den Projekten arbeiten. Die Arbeits-bedingungen müssen dementsprechend auch menschenwürdig sein. Jeder hat das Recht darauf, sich weiterzuentwickeln. Es muss jeder im Team integriert und akzeptiert sein. Es muss gewährleistet sein, dass sich alle in der Projektumgebung wohlfühlen.67

Wirtschaftlichkeit

Das Projekt muss immer wirtschaftlich sein.68 Es muss sichergestellt sein, dass das Pro-jekt einen geschäftlichen Mehrwehrt erzeugt, die Geschäftsziele und die geschäftlichen Anforderungen erfüllt. Außerdem ist auf den Zeitwert des Geldes sowie den Options-wert von Systemen und Teams zu achten. Einerseits soll im Laufe des Projektes frü-hestmöglich Geld verdient und spätestmöglich Geld ausgegeben werden. Andererseits ist der Wert des Projektes als Option für die Zukunft bestmöglich zu gestalten – sowohl für die mehrfache Wiederverwendung des Systems, als auch des Teams.69

Gegenseitiger Nutzen

Sämtliche Projektaktivitäten sollen allen Beteiligten nützen. BECK und ANDRES legen den gegenseitigen Nutzen als das wichtigste Prinzip in XP fest, das aber zugleich auch das am schwersten einzuhaltende ist, da es immer eine Lösung für ein Problem gibt – zugunsten einer Person und zuungunsten einer anderen. Mithilfe von automatisierten Tests, sorgfältiger Refaktorisierung – „manueller oder automatisierter Strukturverbesse-rung von Quelltexten unter Beibehaltung des beobachtbaren Programmverhaltens“70 – sowie der richtigen Namensgebung lassen sich zukünftig auftuende Probleme häufig vermeiden und erzeugen somit einen gegenseitigen Nutzen.71

66 Vgl. Ruf, Fittkau (2008), S. 38 67 Vgl. Hanser (2010), S. 17 68 Vgl. Hanser (2010), S. 17 69 Vgl. Beck, Andres (2004), S. 25 70 Wikipedia, https://de.wikipedia.org/w/index.php?title=Refactoring&oldid=181443193. Zuletzt geprüft

am 13. November 2018. 71 Vgl. Beck, Andres (2004), S. 26

https://de.wikipedia.org/w/index.php?title=Refactoring&oldid=181443193

– 18 –

Selbstähnlichkeit

Ist man im Besitz einer bereits existierenden und funktionierenden Struktur einer Lö-sung, verwendet man diese immer wieder in unterschiedlichen Zusammenhängen – auch in unterschiedlichen Maßstäben. Das muss allerdings nicht heißen, dass die in ei-nem Kontext funktionierende Struktur auch automatisch in einem anderen Kontext ebenfalls auf Anhieb anwendbar ist – jedoch ist dies ein guter Anfang.72

Verbesserung

Auf Anhieb können kein Prozess oder Softwaredesign gut oder gar perfekt sein – es muss stetig an einer Verbesserung gearbeitet werden. Es geht darum, das bestmögliche zu tun, dass man zu dem Zeitpunkt in der Lage ist zu erbringen und nach dem Bewusst-sein und dem Verständnis zu streben, besser werden zu wollen. Es bedeutet nicht, auf Perfektion zu warten, um zu beginnen.73 Prozesse in agilen Projekten sind stets in Be-wegung und liegen auf dem Pfad der kontinuierlichen Verbesserung. Das iterative Vor-gehen in agilen Projekten bietet die Möglichkeit der kontinuierlichen Verbesserung ei-ner Lösung.74

Vielfältigkeit

Projektteams müssen aus Mitgliedern bestehen, die verschiedenartige Charakteristiken, Fähigkeiten, Einstellungen und Perspektiven mitbringen. Dies kann zu Konflikten füh-ren, aber auch dazu beitragen, komplett neue Lösungen zu erarbeiten. Die Konstellation eines Teams entscheidet letztendlich mit über den Erfolg und Misserfolg eines Projek-tes.75

Reflexion

Es soll nicht nur darum gehen, seine Arbeit im Team zu machen. Das Team muss ge-meinsam verstehen warum und wie sie arbeiten. Gemeinsam müssen Erfolg und Misser-folg analysiert und reflektiert werden. Fehler müssen offengelegt und aus ihnen gelernt werden. Zur gemeinsamen Reflexion im Team dienen neben regelmäßigen Besprechun-gen auch Gespräche im inoffiziellen Rahmen, wie gemeinsame Essens- oder Kaffeepau-sen, Gespräche mit Freunden oder dem Lebenspartner, aber auch Auszeiten in Form von Urlaub können effektiv zur Reflexion beitragen. Praktiken, die Zeit für Teamreflexion enthalten sind bspw. die wöchentlichen oder vierteljährlichen Zyklen, die Paarpro- 72 Vgl. Beck, Andres (2004), S. 27-28 73 Vgl. Beck, Andres (2004), S. 28 74 Vgl. Hanser (2010), S. 18-19 75 Vgl. Hanser (2010), S. 18

– 19 –

grammierung oder die kontinuierliche Integration. Die Reflexion kommt stets nach der Aktion. Das Lernen ist eine reflektierte Aktion. Um das Feedback zu maximieren, ist die Reflexion in XP Teams mit dem Tun verbunden.76

Fluss

Die Praktiken in XP – sowie iterative Entwicklungsmethoden im Allgemeinen – sind mehr auf einen kontinuierlichen Fluss von Aktivitäten, als auf diskrete Phasen ausge-richtet. Das Prinzip des Flusses besagt, dass man zur stetigen Verbesserung, häufig kleinere Inkremente dem Kunden bereitstellen sollen. Nur so lässt sich effektiv kontinu-ierliches Feedback generieren, um den Projektzielen Schritt für Schritt näher zu kom-men.77

Gelegenheit

Probleme sollen als eine Gelegenheit für Veränderungen und Verbesserungen gesehen werden. Stärken sollen maximiert und Schwächen minimiert werden. Sämtliche Prob-leme als Gelegenheiten wahrzunehmen, soll auch als Gelegenheit für persönliches Wachstum, vertiefende Beziehungen und verbesserter Projektergebnisse dienen.78

Redundanz

Kritische Probleme sollen mehrfach angegangen werden. Aus den entwickelten Lösun-gen kann nun die beste herausgewählt werden. Auf diese Weise können verschiedenste Design-Konzepte erstellt werden, um so das effektivste Konzept auszuwählen.79 Ob-wohl Redundanz verschwenderisch sein kann, sollte man darauf achten, keine Redun-danz zu entfernen, die einem gültigen Zweck dient. Eine Testphase nach Abschluss der Entwicklung sollte redundant sein und erst zu dem Zeitpunkt entfernt werden, wenn sich die Redundanz in der Praxis nach mehreren fehlerfreien Deployments hintereinan-der als Redundanz erweist.80

Fehlschlag

Fehlschläge müssen hingenommen und akzeptiert werden, um letztendlich die Lehren aus ihnen zu ziehen. Damit ist nicht gemeint, Fehler zu entschuldigen, wenn man es eigentlich besser wüsste. Wenn man jedoch an einer Stelle wirklich nicht weiß was zu

76 Vgl. Beck, Andres (2004), S. 29-30 77 Vgl. Beck, Andres (2004), S. 30 78 Vgl. Beck, Andres (2004), S. 30-31 79 Vgl. Hanser (2010), S. 19 80 Vgl. Beck, Andres (2004), S. 31-32

– 20 –

tun ist und somit nicht weiterkommt, kann das Risiko eines Scheiterns der kürzeste und sicherste Weg zum Erfolg sein.81

Qualität

Projektziele werden nicht schneller erreicht, nur weil man auf eine niedrigere Qualität setzt. Andersherum genauso, das Erreichen der Projektziele verzögert sich nicht, nur weil man auf eine höhere Qualität setzt. Auf eine höhere Qualität zu setzen, führt oft zu einer schnelleren Auslieferung. Auf eine niedrigere Qualität zu setzen führt oft zu einer verzögerten Auslieferung. Jede Qualitätssteigerung führt zu Verbesserungen bei ande-ren wünschenswerten Projekteigenschaften, wie der Produktivität oder der Effektivität.82 Eine qualitativ hochwertige Arbeit führt auch zur Stärkung des Selbstvertrauens und des Stolzes eines Einzelnen und des Teams.83

Kleine Schritte

In kleinen und regelmäßigen Schritten sollen Probleme gelöst werden, Iterationen erfol-gen und Zwischenergebnisse dem Kunden bereitgestellt werden. Nur so lässt sich effek-tiv Feedback generieren und der Arbeitsaufwand verringern.84

Akzeptierte Verantwortung

Verantwortung kann keinem zugewiesen werden – man kann ausschließlich für sich selbst entscheiden ob man Verantwortung akzeptiert oder nicht. Im Projekt muss Ver-antwortung von jedem einzelnen und dem Team in der Gesamtheit akzeptiert werden. Verantwortung bringt Autorität mit sich.85 Übernimmt niemand Verantwortung, schei-tert das Projekt.86

2.1.2.3 Praktiken

Die Aussage der jeweiligen Praktiken soll klar und objektiv sein – allerdings kann das Verständnis darüber, wie die Praktiken im jeweiligen Kontext anzuwenden sind, nicht immer auf Anhieb offensichtlich sein. Die Liste aller situierten, kontextabhängigen Praktiken eines agilen Vorgehensmodells kann nie sämtliche Bereiche aller Projekte

81 Vgl. Beck, Andres (2004), S. 32 82 Vgl. Beck, Andres (2004), S. 32-33 83 Vgl. Hanser (2010), S. 20 84 Vgl. Hanser (2010), S. 20 85 Vgl. Beck, Andres (2004), S. 34 86 Vgl. Hanser (2010), S. 20

– 21 –

abdecken. Es ist durchaus plausibel neue, auf das jeweilige Team und Projekt zuge-schnittene Praktiken zu entwickeln.87

Praktiken allein, ohne der Vorgabe von Werten, können wertlos sein und zur stumpfen Routine werden. Die Praktik der Paarprogrammierung bspw. erfüllt nicht ihren Zweck, wenn man diese allein als ein To Do betrachtet, das am Ende abgehakt werden soll, um den Vorgesetzten glücklich zu machen. Die Paarprogrammierung als Praktik zu betrei-ben, um die Kommunikation zu verbessern, Feedback zu erhalten, das System zu ver-einfachen, Fehler zu finden und zu beheben sowie den eigenen Mut zu stärken, erfüllt einen viel größeren Zweck.88

Praktiken sind situationsabhängig – ändert sich also die Situation im Projekt, lässt sich aus unterschiedlichen Praktiken die richtige wählen, um die neuen Bedingungen zu er-füllen. Die grundlegenden Werte müssen sich nicht ändern, um sich an eine neue Situa-tion anzupassen – es können sich aber mit der geänderten Situation einige neue Prinzi-pien auftuen.89

BECK und ANDRES möchten, dass die Praktiken als Hypothesen verwendet werden, mit-hilfe derer an XP im Projekt herumexperimentiert werden soll, um Projekte effektiver zu gestalten.90

Die 24 XP Praktiken sind unterteilt in 13 Primär- und elf Korollarpraktiken. Die Pri-märpraktiken sind immer nützlich, unabhängig davon ob man mehrere Praktiken mitei-nander vermischt oder wie die genauen Anforderungen an ein Projekt definiert sind. Jede der Primärpraktiken kann zu einer direkten Verbesserung beitragen. Die Korollar-praktiken hingegen können sich wahrscheinlich als komplizierter herausstellen, hat man die Primärpraktiken zu Beginn nicht richtig eingesetzt.91 Es gibt keine genau festgelegte Reihenfolge, mit welcher der Praktiken gestartet werden soll. Dies soll voll und ganz von der jeweiligen Projektumgebung sowie dem Team abhängig gemacht werden.92 Im Folgenden werden die XP Praktiken beschrieben.

87 Vgl. Beck, Andres (2004), S. 34 88 Vgl. Beck, Andres (2004), S. 35 89 Vgl. Beck, Andres (2004), S. 35 90 Vgl. Beck, Andres (2004), S. 35 91 Vgl. Beck, Andres (2004), S. 36 92 Vgl. Beck, Andres (2004), S. 37

– 22 –

2.1.2.3.1 Primärpraktiken

Räumliches Zusammensitzen

Es soll in einem offenen Raum, der groß genug für das gesamte Team ist, am Projekt gearbeitet werden. Es sollen aber dennoch kleinere Arbeitsbereiche bzw. Einzelbüros in der Nähe vorhanden sein, um das Bedürfnis nach Privatsphäre eines jeden erfüllen zu können. Ist ein Team allerdings nicht gewohnt in Großraumbüros zu arbeiten, kann dies kontraproduktiv sein und eher zu Groll und Widerstand im Team führen. Das Team muss dazu bereit sein – es muss darauf eingestellt werden. Ein Team, das weiß, dass physische Nähe die Kommunikation verbessert und den Wert der Kommunikation ver-innerlicht hat, wird sich hierbei deutlich leichter tun. Das bedeutet allerdings nicht, dass räumlich verteile Teams XP nicht anwenden könnten. Die Praktik des räumlichen Zu-sammensitzens des Projektteams besagt nur, dass sich das Projekt als deutlich humaner und produktiver herausstellen wird, wenn das Projektteam in unmittelbarer Nähe ge-meinsam am Projekt arbeitet.93

Gesamtes Team

Das Team in der Gesamtheit muss aus funktionsübergreifenden Mitgliedern bestehen, die gemeinsam sämtliche Fähigkeiten und Perspektiven vereinen, die für den Erfolg des Projektes erforderlich sind. Der Zweck dieser Praxis ist es, ein Gefühl der Ganzheitlich-keit im Team zu erzeugen sowie der schnellen Verfügbarkeit aller für den Erfolg not-wendigen Ressourcen. Das gegenseitige und gemeinsame Unterstützen, Wachsen und Lernen stärkt das Teamgefühl. Das Team muss dynamisch sein – es ist vollkommen akzeptabel Teammitglieder im laufen Projekt auszutauschen. Die Größe des Teams spielt allerdings eine kritische Rolle. BECK und ANDRES empfehlen die Schwelle von zwölf Teammitgliedern nicht zu überschreiten, um Vertrauen innerhalb des Teams zu wahren – Vertrauen ist für eine effektive Zusammenarbeit erforderlich. Auch empfehlen sie, dass die einzelnen Projektbeteiligten nicht an mehreren Projekten gleichzeitig arbei-ten sollten, um die Produktivität eines Projektes höchstmöglich zu halten.94

Informative Arbeitsumgebung

Die Arbeitsumgebung sollte das Projekt optisch zum Ausdruck bringen. Eine projektun-abhängige Person sollte laut BECK und ANDRES in der Lage sein innerhalb von 15 Se-kunden nachdem sie den Raum betreten hat, eine allgemeine Vorstellung davon zu er-halten, wie das Projekt läuft. Nach genauerem Hinsehen sollte die Person dann in der 93 Vgl. Beck, Andres (2004), S. 37-38 94 Vgl. Beck, Andres (2004), S. 38-39

– 23 –

Lage sein, mehr Informationen über reale oder potentielle Probleme erhalten zu können. Dabei können an die Wand geheftete User Story Karten sehr hilfreich sein – mehr zu dieser Spezifikationstechnik in der Praktik User Stories. Das Sortieren der Karten nach bestimmten Kriterien – bspw. nach noch offenen oder schon erledigten Aufgaben –, hilft diese leichter zu verstehen. Zu einer informativen Arbeitsumgebung können auch große, sichtbare Diagramme beitragen. Die Visualisierung eines Problems kann auch dem eigenen Team dabei helfen das Problem besser zu verstehen. Selbstverständlich sollten Diagramme und andere offensichtlich angebrachte Visualisierungen wieder ab-gehangen werden, sollten diese nicht mehr auf dem aktuellsten Stand sein.95

Energiegeladene Arbeit

Alle Projektmitglieder sollen nur so viele Stunden arbeiten, wie sie produktiv sein kön-nen. Sich zu überarbeiten macht nur die eigene Arbeit zu Nichte und gefährdet das ei-gene Wohl und die Gesundheit sowie das gesamte Projekt. Setzt man sich ein zeitliches Limit, wird man in der Zeit deutlich produktiver sein. Einsicht schützt auch das Team und das Projekt vor Produktivitätsverlust. Bei Krankheit sollte man die Situation schlichtweg akzeptieren und sich Zeit zum Ausruhen und wieder Gesundwerden neh-men. Sich um sich selbst zu kümmern ist der schnellste Weg zu einer energiegeladenen Arbeit. Um nicht von heute auf morgen seine Verhaltensweisen zu ändern, gilt es in-krementelle Verbesserungen vorzunehmen. Es gilt für dieselbe Arbeitszeit eine Opti-mierung dieser Zeit vorzunehmen. Beispielsweise können Ablenkungen wie Telefon- oder Email-Benachrichtigungen für festgelegte Zeiten ausgeschalten werden, um sich voll und ganz dem Projekt widmen zu können.96

Paarprogrammierung

Der gesamte Quellcode soll in Zweierpaaren an einem Rechner geschrieben werden – dies beinhaltet auch das Analysieren, Designen und Testen des Programmcodes. BECK und ANDRES sagen, dass die Paarprogrammierung dazu beiträgt, die Konzentration zu fördern, über Systemverbesserungen und Ideen zu diskutieren, die Frustration zu ver-mindern, sollte einer der beiden Programmierer an einem Punkt nicht weiterkommen und sich gegenseitig daran zu erinnern, die Teampraktiken einzuhalten. Das Bedürfnis nach Privatsphäre ist menschlich – es ist äußerst legitim sich auch mal für eine Zeit zu-rückzuziehen und in eigener Gesellschaft zu arbeiten. Die Resultate können dem gesam-ten Projekt zugutekommen und sollten im Nachhinein auch mit dem Team geteilt wer-den. Es sollen nicht immer dieselben Programmierpartner zusammenarbeiten. Im Ge-

95 Vgl. Beck, Andres (2004), S. 39-41 96 Vgl. Beck, Andres (2004), S. 41-42

– 24 –

genteil, BECK und ANDRES sagen, dass es sinnvoll sein kann in regelmäßigen Zyklen den Partner zu wechseln.97 Einer der beiden Programmierer übernimmt immer den takti-schen Part und macht sich hauptsächlich Gedanken rund um die aktuelle Implementie-rung, während der Partner die strategische Komponente widerspiegelt und sich Gedan-ken zur Funktionsweise bzw. Vereinfachung der aktuellen Implementierung macht.9899

User Stories

User Stories definieren die Anforderungen des Kunden an das System in kurzen infor-mations- und restriktionsreichen Sätzen oder mithilfe von Grafiken. User Stories erhal-ten einen kurzen aussagekräftigen Titel und werden auf Karteikarten niedergeschrieben, die an eine Wand geheftet werden, an der täglich möglichst viele Projektbeteiligte vor-beikommen. Die User Story Karten können auch in unternehmensintern-vertraute For-mate konvertiert werden. Ist eine User Story definiert, wird der Entwicklungsaufwand für die Implementierung geschätzt. Die Schätzung soll dazu beitragen, dass jeder dar-über nachdenkt, wie sich aus dem kleinstmöglichen Input, der höchstmögliche Output generieren lässt. Die Schätzung soll auch den betriebswirtschaftlichen und technischen Perspektiven des Projektes eine Möglichkeit zur Interaktion geben. Dies schafft einen frühzeitigen Stellenwert für Anforderungen mit hohem Potenzial. Dafür müssen sowohl die Kosten als auch die beabsichtigte Verwendung des jeweiligen Features bekannt sein. Kennt das Projektteam den Implementierungsaufwand eines Features, lässt sich der Umfang dafür teilen, kombinieren oder erweitern – abhängig davon was sie über den Stellenwert der jeweiligen Anforderung wissen.100

Wöchentlicher Zyklus

Jede einzelne Woche nach der anderen muss geplant werden. Zu jedem neuen Wochen-beginn soll es eine Teambesprechung geben. In den Besprechungen sollen die bisheri-gen Fortschritte der jeweils letzten Woche, als auch des Gesamtprojektes, überprüft werden. Der Kunde soll die User Stories auswählen, die in der vorliegenden Woche vom Projektteam implementiert werden. Diese sollen in einzelne Aufgabenpakete ein-geteilt werden, damit sich die Teammitglieder Aufgabenbereiche heraussuchen und eine Schätzung für diese abgeben können. Die Arbeitswoche beginnt mit der Entwicklung automatisierter Tests, die nach der Implementierung der User Stories ausgeführt wer-den. Der Rest der Woche wird daraufhin damit verbracht, die User Stories fertigzustel-

97 Vgl. Beck, Andres (2004), S. 42-43 98 Vgl. Hanser (2010), S. 33 99 Vgl. Ruf, Fittkau (2008), S. 43 100 Vgl. Beck, Andres (2004), S. 44-45

– 25 –

len und den Quellcode so zu verbessern, dass alle Tests bestanden werden. Das Ziel ist es am Ende jeder Woche bereitstellbare Softwareteile vorweisen zu können.101

Vierteljährlicher Zyklus

Jedes einzelne Quartal nach dem anderen muss geplant werden. Es soll vierteljährlich über das Team, das Projekt, den Progress des Projektes und die Ausrichtung des Projek-tes auf größere Ziele reflektiert werden. Zur Quartalsplanung zählt die Identifikation von Engpässen, die Einleitung von Reparaturen, das Auswählen der User Stories, die in dem Quartal implementiert werden sollen sowie das Fokussieren auf das Gesamtbild des Projektes. Die Quartalsplanung ist auch oft zur Synchronisierung mit anderen inter-nen Geschäftsaktivitäten, die ebenfalls vierteljährlich stattfinden sinnvoll.102

Puffer

Jeder Plan sollte kleinere Aufgabenbereiche enthalten, die weggelassen werden können, sollte man zeitlich in Rückstand geraten. Im Nachgang lassen sich immer noch weitere User Stories implementieren und somit mehr liefern als vereinbart. Nicht nur dem eige-nen Team und dem Kunden gegenüber ist es wichtig das Commitment – selbstgetroffe-ne Verpflichtungen – einzuhalten. Ein häufig vorkommendes Overcommitment, also die Übernahme zu vieler Verpflichtungen, kann zu nicht mehr zu beherrschenden Mängeln, schlechter Moral und feindseligen Beziehungen führen. Die Einhaltung der Commit-ments beseitigt Unannehmlichkeiten. Eine klare und ehrliche Kommunikation und Selbsteinschätzung löst Spannungen und erhöht die Glaubwürdigkeit.103

Zehn-Minuten-Build

Die automatisierte Erzeugung eines Builds des gesamten Systems sowie die automati-sierte Durchführung aller Tests soll nicht länger dauern als zehn Minuten. Ein Build, das zur Erzeugung mehr als zehn Minuten benötigt, wird viel seltener verwendet, da hier die Gelegenheit des Feedbacks verloren geht. Bei längerem Warten reduziert sich folglich auch die Anzahl der Builds.104 Die zehn Minuten sollen als Richtwert gelten. Benötigt man aktuell mehr Zeit zur Erzeugung des Builds, muss der Prozess dahingegen optimiert werden. Wird das Build aktuell noch nicht automatisiert erzeugt, muss dies zu Beginn in Angriff genommen werden. Automatisierte Builds erzeugen einen viel höhe-ren Wert als Builds, die manuelle Eingriffe erfordern. Steigt der allgemeine Stresspegel

101 Vgl. Beck, Andres (2004), S. 46-47 102 Vgl. Beck, Andres (2004), S. 47-48 103 Vgl. Beck, Andres (2004), S. 48 104 Vgl. Hanser (2010), S. 39

– 26 –

im Projekt an, werden manuelle Builds seltener und schlechter ausgeführt, was zu einer erhöhten Fehlerrate und noch mehr Stress führen kann.105

Kontinuierliche Integration

Es soll nicht länger als ein paar Stunden am Quellcode gearbeitet werden, bevor dieser getestet und integriert werden soll. Die Integration kann mehr Zeit in Anspruch nehmen als die eigentliche Entwicklung – umso länger man sich mit der Integration Zeit lässt, desto teurer kann der Prozess werden und desto unberechenbarer können die Kosten werden. Die asynchrone Integration ist die wohl geläufigste Art. Sobald das Build-System Änderungen zur Kenntnis nimmt, beginnt es damit das Build zu erstellen und dieses zu testen. BECK und ANDRES bevorzugen allerdings ein synchrones Modell. Die Integration soll regelmäßig nach jeder Paarprogrammierungs-Periode vom Programmie-rer-Paar vorgenommen werden – alle paar Stunden. Infolgedessen wird darauf gewartet bis der Build-Erstellungsprozess abgeschlossen ist und sämtliche Tests fehlerfrei ausge-führt wurden, bevor fortgefahren werden kann.106

Test-First-Entwicklung

Bevor Quellcode geändert wird, muss im Vorfeld ein automatisierter Test fehlgeschla-gen sein. Die Test-First-Entwicklung geht gleichzeitig mehrere Probleme an – Scope Creep, also den schleichenden Inhalts- und Umfangszuwachs eines Projektes, Kopplung und Kohäsion, Vertrauen und Rhythmus. Es kann leicht passieren, mit der Programmie-rung über die Stränge zu schlagen und faktisch unnötigen Programmcode zu schreiben. Indem explizit und objektiv angegeben wird, was das System machen soll, lässt sich überschüssiger Code vermeiden. Wenn es einem schwer fällt einen Test zu schreiben, kann es ein Hinweis darauf sein, dass ein Design-Problem vorliegt. Lose gekoppelter und äußerst kohäsiver Programmcode ist einfach zu testen. Es kann einem durchaus schwerfallen, einem Programmierer, der nicht funktionierenden Code geschrieben hat, das Vertrauen zu schenken. Bei sauber geschriebenem und funktionierendem Code, der Tests besteht, gibt man seinen Teamkollegen und dem Kunden einen Grund einem zu vertrauen. Es kann schnell passieren, sich im Programmieren für Stunden zu verlieren. Arbeitet man nach dem Test-First-Prinzip, weiß man stets, was als Nächstes zu tun ist – entweder man schreibt den nächsten Test oder man verbessert den durch den Test gefal-lenen Programmcode. Es sollte sich auf lange Sicht ein Testen-Entwickeln-Refaktorisieren-Rhythmus einstellen. Eine weitere Verbesserung der Test-First-Entwicklung kann durch das kontinuierliche Testen zustande kommen. Beim kontinu-

105 Vgl. Beck, Andres (2004), S. 49 106 Vgl. Beck, Andres (2004), S. 49-50

– 27 –

ierlichen Testen laufen Tests durch jede Programmänderung, ähnlich wie ein inkremen-teller Compiler, der durch jede Änderung des Quellcodes läuft. Testfehler werden im selben Format wie Compilerfehler gemeldet. Das kontinuierliche Testen reduziert die Zeit, um Fehler zu beheben, indem die Zeit zur Erkennung dieser Fehler reduziert wird. Die Tests müssen schnell durchlaufen.107

Inkrementelles Design

Es soll täglich am Design des Systems gearbeitet werden. Es soll sich darum bemüht werden, das Design auf die Bedürfnisse des Systems an diesem Tag optimal anzupas-sen. Es muss darauf geachtet werden, dass der Fokus nicht allein auf der Implementie-rung der User Stories liegt. Ohne die tägliche Aufmerksamkeit für das Design, können die Kosten für spätere Änderungen sprunghaft ansteigen sowie nur dürftig entworfene und nur mühevoll zu ändernde Systeme das Resultat sein. Statt im Vorfeld schon ver-tiefter am Design zu arbeiten, ist es effizienter, dies erst dann zu unternehmen, wenn es gebraucht wird. Mit der Zeit wird die Expertise darüber, in kleinen, sicheren Schritten Änderungen an einem laufenden System vorzunehmen, steigen. Daraufhin wird man es sich leisten können, immer mehr der Investition in das Design aufzuschieben. Das Re-sultat daraus wird ein unkompliziertes System sein, ein früher eintretender Fortschritt, einfacher zu schreibende Tests und aufgrund des schmaleren Systems, kann weniger mit dem Team kommuniziert werden. Die Refaktorisierung ist eine Design-Disziplin, die wiederkehrende Änderungsmuster aufzeichnet. Dies kann hilfreich sein, wenn umso mehr Teams in das tägliche Design investieren und es so zu ähnlichen Änderungen kommen kann. Refaktorisierungen können auf jeder Skalenebene stattfinden. Das Er-gebnis sind Systeme, die klein anfangen und bei Bedarf ohne übermäßige Kosten wach-sen können.108

2.1.2.3.2 Korollarpraktiken

Projekteinbeziehung realer Anwender

Die Personen, die das fertige Produkt zukünftig in ihre tägliche Arbeit integrieren wer-den, sollen ein Teil des Projektteams und des Entwicklungsprozesses sein. Die Einbe-ziehung des Kunden zielt darauf ab, verschwendeten Arbeitsaufwand zu reduzieren, in dem die Personen mit den Bedürfnissen – der Kunde – in direkten und ständigen Kon-takt mit denen gebracht werden, die eben diese Bedürfnisse erfüllen können – dem ge-samten Projektteam. Der Vorteil dieser Praktik ist, dass nicht unnötige Features entwi-ckelt und implementiert werden, die nicht gebraucht und nicht genutzt werden, dass 107 Vgl. Beck, Andres (2004), S. 50-51 108 Vgl. Beck, Andres (2004), S. 51-53

– 28 –

Tests spezifiziert werden, die die tatsächlichen Akzeptanzkriterien darstellen sowie die Möglichkeit besteht eine solide Kunden-Lieferanten-Beziehung aufzubauen. Die Einbe-ziehung des Kunden kann die Produktivität des Teams sowie das gegenseitige Vertrau-en fördern und zukünftige Projekte begünstigen.109

Inkrementelles Deployment

Hat man mit dem Projekt vor ein Altsystem zu ersetzen, sollte man in schon sehr frühen Phasen des Projektes die Arbeitsaufträge des Altsystems sukzessive übertragen. Im Ge-gensatz zu einem großen Deployment – Bereitstellung und Installation – des Gesamt-systems, sollen Funktionalitäten oder Datensätze schrittweise bereitgestellt werden. Die Gefahr bei Deployments, die selten durchgeführt werden und aus großen Arbeitspakten bestehen, liegt in der Gefahr des Scheiterns. Schnell können dann die Kosten – ökono-mische sowie Personenkosten – rasant ansteigen. Um das Risiko der Kostenexplosion zu minimieren und eine agile Arbeitsweise zu pflegen, empfiehlt sich das inkrementelle Deployment. Solange noch nicht alle Funktionen, und somit das Gesamtsystem, bereit-gestellt wurden, muss auf eigene Weise ein Weg gefunden werden, um beide Systeme parallel laufen zu lassen. Laut BECK und ANDRES ist dieses Balancieren der Preis, den man übergangsweise als eine Art Versicherung für die Risikominimierung zahlen muss.110

Teamkontinuität

Projektteams, die effektiv und effizient zusammenarbeiten sollen zusammengehalten werden. Wie ein Projekt letztendlich verläuft ist nicht nur davon abhängig wie gut die einzelnen Teammitglieder sind – es hängt vielmehr davon ab, wie die Beziehungen un-tereinander sind. Harmonisiert ein Team, werden sie gemeinsam bessere Projektergeb-nisse vorweisen können. Ein solches Team zusammenzustellen, kann sich oft als kom-plex erweisen. Eine Organisation kann allerdings von der vorherrschenden Stabilität sowie von konsistent verbreitetem Wissen und Erfahrungen deutlich profitieren.111

Teams verkleinern

Mit voranschreitender Projektdauer gewinnt das Team an Fähigkeiten hinzu. Um die Kontinuität zu wahren, sollte die Auslastung im Team allerdings dieselbe bleiben. Auf-

109 Vgl. Beck, Andres (2004), S. 61-62 110 Vgl. Beck, Andres (2004), S. 62-63 111 Vgl. Beck, Andres (2004), S. 63-64

– 29 –

grund dessen können Teamgrößen inmitten eines Projektes schrittweise reduziert wer-den.112

Ursachenanalyse

Es soll jedes Mal, wenn ein Fehler nach der Entwicklung entdeckt wird, eine tiefgründi-ge Analyse durchgeführt werden, um den Fehler und die Ursache, die zu diesem Fehler geführt hat, zu beseitigen. BECK und ANDRES geben folgenden vierstufigen Prozess an, um auf einen Fehler zu reagieren. Zuerst soll ein automatisierter Test auf Systemebene geschrieben werden, der den Fehler einschließlich des gewünschten Verhaltens aufzeigt. Daraufhin soll ein Komponententest im kleinstmöglichen Umfang geschrieben werden, der ebenfalls den Fehler aufzeigt. Infolgedessen soll der Fehler behoben werden. Schritt zwei und drei werden solange wiederholt bis das System den Komponenten- und Sys-temtest besteht. Sind die Tests bestanden und somit der Fehler behoben, sollen die Fra-gen geklärt werden, warum es zu diesem Fehler kam und weshalb dieser nicht erkannt wurde. Schlussendlich sollen die notwendigen Änderungen in die Wege geleitet werden, um diese Art von Fehlern in Zukunft zu vermeiden.113

Gemeinsamer Quellcode

Zu jeder Zeit soll jeder aus dem Projektteam auf den Quellcode zugreifen und an diesem arbeiten können – und dies auch tun. Es soll über den Tellerrand geblickt werden. Fin-det man in Codeteilen, an denen man nicht selbst aktiv mitgewirkt hat, Fehler, sollte man sich nicht davor scheuen diese zu beheben. Es muss kollektiv Verantwortung ge-nommen werden.114

Quellcode und Tests

Allein der Quellcode und die Tests sollen als dauerhafte Artefakte gepflegt werden. Aus dem Quellcode und den Tests sollen weitere Dokumente generiert werden können, um die zukünftige Aufrechterhaltung und Pflege des Systems zu gewährleisten und diese unkompliziert zu gestalten. Das Produzieren von redundanten bzw. überflüssigen Arte-fakten soll minimiert werden.115

112 Vgl. Beck, Andres (2004), S. 64 113 Vgl. Beck, Andres (2004), S. 64-66 114 Vgl. Beck, Andres (2004), S. 66 115 Vgl. Beck, Andres (2004), S. 66-67

– 30 –

Eine Quellcodebasis

Während des gesamten Projektes soll ausschließlich eine Quellcodebasis existieren und gepflegt werden. Es soll zwar paarweise am eigenen Quellcode entwickelt werden, dies aber stets nicht länger als ein paar Stunden – danach muss regelmäßig eine Synchroni-sierung mit der eigentlichen Quellcodebasis stattfinden. So soll verschwenderische Mehrarbeit vermieden werden.116

Tägliches Deployment

Es soll jede Nacht ein neues Build der Software generiert werden, um Integrationsrisi-ken zu vermeiden117 Es soll so das Risiko minimiert werden, dass Entscheidungen vom Entwickler getroffen werden, ohne sich im Vorfeld konstruktives Feedback eingeholt zu haben.118

Vertrag mit verhandelbarem Umfang

Die Verträge, die zwischen dem Kunden und dem Dienstleister vereinbart werden, sol-len die Zeit, Kosten und Qualität festlegen, aber eine fortlaufende Verhandlung über den genauen Umfang des zu entwickelnden Systems erfordern. Es sollen mehrere fortlau-fende Verträge vereinbart und unterzeichnet werden, anstelle eines großen Vertrages. So ein Vertragsmuster soll dazu dienen, die beiderseitigen Interessen – die des Kunden sowie die des Dienstleisters – effizienter aufeinander abstimmen zu können, die Kom-munikation sowie das Einholen von Feedback zu fördern und Kosteneffizienz und -transparenz zu wahren.119 Bei dieser Praktik handelt es sich um die stringente Umset-zung des agilen Gedankens.120

Nutzungsbasierte Abrechnung

Es können Systeme nach dem Pay-Per-Use-Ansatz entworfen werden. Hierbei fällt nach jeder Nutzung des Systems ein Geldbetrag an. Das hieraus generierte konkrete Feed-back des Systems soll dazu beitragen das System kontinuierlich zu verbessern. Dies kann bspw. durch Informationen über die Systemverwendung geschehen, um Informati-onen über die Genauigkeit der Umsatzschätzungen zu liefern. Mithilfe dieser lassen sich letztendlich dann die Kosten und die Rentabilität optimieren. Sollte eine nutzungsba-sierte Abrechnung nicht implementiert werden können, empfehlen BECK und ANDRES

116 Vgl. Beck, Andres (2004), S. 67-68 117 Vgl. Hanser (2010), S. 42 118 Vgl. Beck, Andres (2004), S. 68-69 119 Vgl. Beck, Andres (2004), S. 69 120 Vgl. Hanser (2010), S. 42

– 31 –

ein Abonnementmodell. Dieser lizenzbasierte Ansatz ist heute im Zeitalter cloudbasier-ter Lösungen weitverbreitet. Bei diesem Modell kann die Retention Rate – die Anzahl der Kunden, die weiterhin subskribieren – als Informationsquelle dienen.121

2.1.2.4 Rollen

Für ein effektiv gestaltetes Projekt müssen die Perspektiven vieler verschiedener Perso-nen betrachtet und berücksichtigt werden. Um Erfolg zu gewährleisten, muss sich jedes Teammitglied als Teil des Ganzen sehen – das Team muss als Einheit fungieren. BECK und ANDRES definieren neun verschiedene Rollen, die einem XP Projektteam angehö-ren: Tester, Designer, Architekten, Projektmanager, Produktmanager, Führungskräfte, Technische Redakteure, Anwender und Entwickler. Die einzelnen Rollen sind aller-dings nicht fest zugewiesen und starr. Nach BECK und ANDRES können die neun Rollen zu einem XP Projektteam beitragen – es soll aber nach ihnen nicht heißen, dass es eine konkrete Zuordnung von einer Person zu einer Rolle geben muss. So können bspw. ebenso gut Programmierer User Stories schreiben, statt ausschließlich der Produktma-nager oder Projektmanager auch architektonische Verbesserungen vorschlagen, statt ausschließlich der Architekten. Anwender können auch Produktmanager sein und Tech-nische Redakteure auch Tester. Das Ziel ist es, dass jeder Projektbeteiligte konstruktiv und effektiv sein bestmögliches zum Projekterfolg beiträgt.122

2.1.3 Prozessablauf

Aus den im vorherigen Kapitel 2.1.2 aufgezeigten fünf Werten, 14 Prinzipien, 13 Pri-mär- und elf Korollarpraktiken sowie neun Rollen ergibt sich das in der folgenden Ab-bildung 4 dargestellte Gesamtbild der XP Komponenten.

121 Vgl. Beck, Andres (2004), S. 69-70 122 Vgl. Beck, Andres (2004), S. 73-83

– 32 –

Rollen

PraktikenWerte

Kommunikation

Einfachheit

Feedback

Mut

Respekt

Prinzipien

Menschlichkeit

Wirtschaftlichkeit

Gegenseitiger Nutzen

Selbstähnlichkeit

Akzeptierte Verantwortung

Verbesserung

Vielfältigkeit

Reflexion

Fluss

Gelegenheit

Redundanz

Fehlschlag

Qualität

Kleine Schritte

Primärpraktiken

Räumliches ZusammensitzenGesamtes Team

Informative Arbeitsumgebung

Inkrementelles Design

Energiegeladene Arbeit

Kontinuierliche Integration

Paarprogram-mierung

User StoriesWöchentlicher

Zyklus

Test-First-Entwicklung

Puffer

Vierteljährlicher Zyklus

Zehn-Minuten-Build

Korollarpraktiken

Projekteinbeziehung realer Anwender

Inkrementelles Deployment

Nutzungsbasierte Abrechnung

Teamkontinuität

Tägliches Deployment

Teams verkleinern

Ursachenanalyse

Gemeinsamer Quellcode

Vertrag mit verhandelbarem

Umfang

Eine Quellcodebasis

Quellcode und Tests

TesterDesigner Architekten

ProjektmanagerProduktmanager

Führungskräfte

Technische RedakteuereAnwender Entwickler

Quelle: Eigene Darstellung in Anlehnung an Beck und Andres (2004), S. 15

Abbildung 4: Gesamtbild der XP Komponenten

Anders als im klassischen Entwicklungsprozess des Wasserfallmodells, das nach einem Push-Modell vorgeht, setzt XP auf ein Pull-Modell.123 Die folgende Abbildung 5 zeigt die Vorgehensweise der beiden Modelle.

123 Vgl. Beck, Andres (2004), S. 87-88

– 33 –

Quelle: In Anlehnung an Beck und Andres (2004), S. 87-88

Abbildung 5: Push- und Pull-Modelle nach Beck und Andres

Im Push-Modell werden die zu erfüllenden Anforderungen, die zu implementierenden Designs sowie der zu entwickelnde und zu testende Quellcode in ihren jeweiligen Silos angehäuft.124

Das in XP zur Verwendung kommende Pull-Modell, beginnt mit der detaillierten Spezi-fikation der User Stories erst unmittelbar vor der Implementierung dieser. Aus diesen Spezifikationen entstehen daraufhin die Tests. Das Design der Programmierschnittstelle wird so entworfen, dass diese den Anforderungen der Tests entspricht. Der Quellcode wird so entwickelt, dass dieser den Tests sowie der Schnittstelle entspricht. Das Design wird daraufhin so präzisiert, dass es den Anforderungen des entwickelten Quellcodes entspricht. Dieser Prozess führt zur Entscheidung darüber, welche User Story als nächs-tes zu spezifizieren ist. Die restlichen User Stories bleiben in der Zwischenzeit an der Wand hängen, bis mit ihrer Implementierung begonnen werden kann.125

Um sich nun ein Gesamtbild des XP Prozesses machen zu können, ist es notwendig die 24 Praktiken zu kategorisieren und zu ordnen. Die folgende Tabelle 3 spiegelt die ei-gens vorgenommene Zuordnung der 24 XP Praktiken in sechs Kategorien bzw. Schich-ten.

124 Vgl. Beck, Andres (2004), S. 87-88 125 Vgl. Beck, Andres (2004), S. 88

– 34 –

Tabelle 3: Kategorisierung und Zuordnung aller 24 XP Praktiken in sechs Schich-

ten

Schichten XP Praktiken Verhandlung Vertrag mit verhandelbarem Umfang

Nutzungsbasierte Abrechnung Ökonomische Organisation Räumliches Zusammensitzen

Gesamtes Team Informative Arbeitsumgebung Energiegeladene Arbeit Projekteinbeziehung realer Anwender Teamkontinuität Teams verkleinern

Technische Organisation Gemeinsamer Quellcode Quellcode und Tests Eine Quellcodebasis

Projektplanung Wöchentlicher Zyklus Vierteljährlicher Zyklus Puffer

Entwicklung Paarprogrammierung User Stories Zehn-Minuten-Build Kontinuierliche Integration Test-First-Entwicklung Inkrementelles Design Ursachenanalyse

Bereitstellung Inkrementelles Deployment Tägliches Deployment

Aus dieser Einteilung der XP Praktiken lässt sich nun ein erstes Gesamtbild über den XP Prozess zeichnen. Die folgende Abbildung 6 verdeutlicht und veranschaulicht diese Kategorisierung sowie die Zuordnung aller XP Praktiken als sechsschichtiges Modell.

– 35 –

Bereitstellung

Entwicklung

Projektplanung

Technische Organisation

Ökonomische Organisation

User Story

Design

Paarpro-grammierung

Test-First-Entwicklung

Ursachen-analyse

- Vertrag mit verhandelbarem Umfang- Nutzungsbasierte Abrechnung

- Räumliches Zusammensitzen- Gesamtes Team- Informative Arbeitsumgebung- Energiegeladene Arbeit- Projekteinbeziehung realer Anwender- Teamkontinuität- Teams verkleinern

- Gemeinsamer Quellcode- Quell