Das Konzept eXtreme Programming. Werte, Prinzipien und Praktiken

Inhaltsverzeichnis

Abbildungsverzeichnis

1 Einleitung
1.1 Was ist eXtreme Programming?
1.2 Anmerkung zur Literatur

2 Bestandteile
2.1 Werte
2.2 Prinzipien
2.3 Praktiken
2.3.1 Primärpraktiken
2.3.2 Begleitpraktiken

3 Nutzen
3.1 Kundensicht
3.2 Entwicklersicht
3.3 Projektsicht
3.4 Wirtschaftliche Sicht

4 Kritik

5 Schlussbemerkung

Literaturverzeichnis

Abbildungsverzeichnis

2.1 eXtreme Programming Werte (2. Auflage)¹

2.2 eXtreme Programming Prinzipien (2. Auflage)²

4.1 eXtreme Programming Risiken [Rumpe and Schröder, 2001, S. 70]

Kapitel 1 Einleitung

Die nachfolgende Hausarbeit wurde im Rahmen des Moduls Software Engineering erar- beitet und hat das Ziel, die grundlegenden Bestandteile von eXtreme Programming (XP) darzustellen.

Als Kern der Ausarbeitung dient das Kapitel 2, in dem die Werte, Prinzipien und Praktiken - aufgeteilt in Primär- und Begleitpraktiken - nach der Definition von Kent Beck erläutert werden.

Die kritische Betrachtung und die Schlussbemerkung vervollständigen die Hausarbeit.

1.1 Was ist eXtreme Programming?

Was ist XP? Wird Software unter extremen Bedingungen entwickelt? Wird von Entwicklern gefordert extrem schnell zu Programmieren? XP ist eine agile Softwareentwicklungsmethode, die eine klar strukturierte Herangehensweise fordert (vgl. [Paulk, 2001, S. 1]). Dabei spielt die Disziplin der Entwickler und Kunden eine wichtige Rolle, denn beide Parteien sind für die Entwicklung von qualitativ hochwertiger Software gleichermaßen verantwortlich.

Die Grundlage von XP, nämlich die Entwicklung als einen kontinuierlichen Prozess zu sehen, der ständig verbessert und analysiert wird, lehnt an die japanische Philosophie „Kaizen“ an. Der Begriff Kaizen wird aus den beiden japanischen Wörtern Kai (Veränderung) und Zen (zum Besseren) zusammengesetzt. Das Bestreben liegt nicht darin, von Grund auf Perfektion zu fordern sondern die permanente Verbesserung. Dieser in Kaizen nie endende Prozess wird dabei von allen Beteiligten gefordert. (vgl. [o. V., o J])

1.2 Anmerkung zur Literatur

Zur Erstellung der Hausarbeit wurden diverse Quellen verwendet. Es wurden sowohl Bücher als auch Artikel und Internetquellen verwendet. Der Zeitpunkt der Einsicht für die Internetquel- len ist im Literaturverzeichnis für jede Internetquelle einzeln aufgeführt. Zudem befinden sich die verwendeten Internetquellen im beiliegenden ZIP-Archiv.

Für die wesentlichen Bestandteile von XP wurden [Beck, 1999] und [Beck and Andres, 2004] zur Hilfe genommen. Die beiden Bücher von Kent Beck stellen somit die Grundlage für die in dieser Hausarbeit beschrieben Eigenschaften von XP dar.

Abbildung in dieser Leseprobe nicht enthalten

Kapitel 2 Bestandteile

Die drei Hauptbestandteile von XP sind Werte (Values), Prinzipien (Principles) und Praktiken

(Practices). Nach Kent Beck, der diese Bestandteile maßgeblich geprägt hat, ist es wichtig auf die Werte genau hinzuweisen und diese zu verdeutlichen (vgl. [Beck and Andres, 2004, S. 45]).

2.1 Werte

Die vier ursprünglichen Werte Einfachheit, Kommunikation, Feedback und Mut wurden in der zweiten Auflage des Buches Extreme Programming Explained: Embrace Change (2nd

Edition) von Kent Beck, wie in der Abbildung 2.1 dargestellt, um Respekt erweitert.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.1: eXtreme Programming Werte (2. Auflage)¹

Einfachheit

Um Lösungen schnell und betriebswirtschaftlich effizient zu entwickeln, wird eine einfache Lö- sung bevorzugt, denn nur so lässt sich die Komplexität minimieren (vgl. [itemis AG, 2015, Kap. Werte von XP]). Während komplexe Lösungen oft Defizite in der Dokumentation aufweisen, bedarf eine einfache Lösung viel weniger Dokumentationsaufwand.

Kommunikation

Die Wichtigkeit des Wertes Kommunikation beschreibt Beck mit dem Satz „I wrote this one- thousend-page document because I value communication“ (vgl. [Beck and Andres, 2004, S. 46]). Um das Wissen aller Projektmitglieder vollständig nutzen können, muss Kommuni- kation stattfinden. Oft können Probleme durch einfache Kommunikation gelöst werden, da einer der Beteiligten die Lösung des Problems bereits kennt. Bevor Missverständnisse ent- stehen oder mehrere Entwickler nach einer Lösung für das gleiche Problem suchen, können sogenannte Daily Stand Up Meetings durchgeführt werden. Inhalt dieser kurzen täglichen Gesprächsrunden sind die Klärung der folgenden drei Fragen (vgl. [Wells, 1999]):

- Was wurde gestern fertiggestellt?
- Was wird heute bearbeitet?
- Welche Probleme hatten Verzögerungen als Folge?

Feedback

Rückmeldungen vom Kunden erhöhen nicht nur die Qualität sondern fördern auch die Zu- sammenarbeit und die Zufriedenheit. Das Feedback gibt dem Entwickler nicht nur Vertrauen in die persönlich erbrachte Leistung sondern verringert zudem die Wahrscheinlichkeit von Fehlentwicklungen. Zusätzlich zu Rückmeldungen in persönlichen Gesprächen werden auch durch Tests Feedback an die Entwickler und Kunden vermittelt. (vgl. [itemis AG, 2015]) Mut Die Werte Einfachheit, Kommunikation und Feedback können nur dann zum Tragen kommen, wenn sowohl die Entwickler als auch die Kunden Mut beweisen. Während einer Kommuni- kation können auch Themen behandelt werden, die die Anforderungen des Kunden oder Entwicklungen des Programmierers in Frage stellen. Auch kann ein Feedback negative Aspekte beinhalten, die einzelne Projektmitglieder auf Fehler hinweisen. Die Ablehnung von unmöglichen Anforderungen erfordert ebenfalls Mut. (vgl. [Klein et al., 2011, Kap. 4.2 Werte])

Respekt

Der in der 2. Auflage hinzugekommene Wert Respekt beschreibt die zwischenmenschliche Be- ziehung der jeweiligen Projektmitglieder. Jedes Projektmitglied respektiert sowohl die Meinun- gen als auch die Projektmitglieder in Person. Der respektvolle Umgang sollte nicht nur im Team sondern auch mit dem Kunden berücksichtigt werden. (vgl. [Select Business Solutions, 2015, Kap. XP Values])

2.2 Prinzipien

Aus den Werten in Kapitel 2.1 leiteten sich in der 1. Auflage [Beck, 1999] 15 Prinzipien ab, die in der 2. Auflage [Beck and Andres, 2004] grundlegend überarbeitet wurden. Im folgenden Abschnitt werden die 14 Prinzipien, wie in der Abbildung 2.2 dargestellt, aus der Neuauflage erläutert (vgl. [Beck and Andres, 2004, S. 58 ff.]).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.2: eXtreme Programming Prinzipien (2. Auflage)²

Menschlichkeit

Da die Software von Menschen entwickelt wird, darf die Menschlichkeit nicht außer Acht gelas- sen werden. Ein gesundes Verhältnis zwischen Berufs- und Privatleben fördern nicht nur die Arbeitsmoral sondern steigern auch die Effizienz eines jeden Projektmitgliedes. Jedoch sollte eine strikte Trennung zwischen Privatem und Beruflichen herrschen. Wie in 2.1 beschrieben, sollen Projektmitglieder untereinander nicht nur die projektspezifischen Aspekte sondern auch die menschlichen Bedürfnisse respektieren. (vgl. [Beck and Andres, 2004, S. 59-60])

Wirtschaftlichkeit

Mit dem Prinzip der Wirtschaftlichkeit beschreibt Beck die eigentliche Absicht von Softwa- reprojekten, die Absicht Software gewinnbringend zu entwickeln. Dabei spielt die betriebs- wirtschaftliche Denkweise der Softwareentwickler die Hauptrolle, denn bei der Entwicklung entstehen Kosten. Das Ziel soll nicht nur die Deckung der entstandenen Kosten sondern auch die Erzielung von Gewinnen sein, die den wirtschaftlichen Zielen des Unternehmens entsprechen. Der Erfolg von Unternehmen ist gleichermaßen von der Kundenbindung und der Kundenzufriedenheit abhängig, zu der die Softwareentwickler den Hauptbeitrag leisten, da sie mit dem Kunden in direktem Kontakt stehen. (vgl. [Beck and Andres, 2004, S. 61])

Beidseitiger Vorteil

Zusätzlich zur betriebswirtschaftlichen Denkweise der Softwareentwickler ist auch der beidsei- tige Vorteil ein fundamentaler Aspekt der Wirtschaftlichkeit, denn die entwickelte Software soll sowohl die Anforderungen des Kunden erfüllen als auch dem beauftragten Unternehmen Vorteile verschaffen. Somit trägt auch der beidseitige Vorteil dazu bei Kunden langfristig zu binden. (vgl. [Beck and Andres, 2004, S. 62])

Selbstähnlichkeit

Damit das Rad nicht immer wieder neu erfunden wird, sollte versucht werden Ansätze oder Strukturen von bereits entwickelten Lösungen zu recyclen. Die Wiederverwertung bietet in dem neuen Kontext nicht zwangsläufig auch eine Lösung, kann aber als Anhaltspunkt verwendet werden. (vgl. [Beck and Andres, 2004, S. 63-64])

Verbesserungen

Software kann nicht von Grund auf perfekt und fehlerfrei entwickelt werden. Ursache hierfür können Änderungen von Anforderungen, Fehler oder Seiteneffekte sein, die zunächst nicht bekannt waren. Hinzu kommt die ständige Weiterentwicklung der Technologie, die von den Entwicklern beachtet und umgesetzt werden muss. Ein Beispiel hierfür ist die Weiterentwick- lung der Prozessorarchitektur von 32 Bit auf 64 Bit. Weder der Kunde noch die Entwickler sollten die Erwartungshaltung haben, von Grund auf perfekt entwickelte Software zu erhalten. Durch die ständige Verbesserung der Software und der Behebung von Problemen entsteht ein kontinuierlicher Prozess, die zur Qualität der Entwicklung einen erheblichen Beitrag leisten. Verbesserungen können jedoch nur dann entstehen, wenn, wie in 2.1 beschrieben, die Werte Kommunikation und Feedback gelebt werden. (vgl. [Beck and Andres, 2004, S. 65])

Vielfältigkeit

Wie schon [Baginski, 2014] in ihrem Artikel „Homogene vs. Heterogene Teams“ schreibt, stellen heterogene Teams eine höhere Effektivität dar, denn sie bringen unterschiedliche Kenntnisse und Fähigkeiten in die Teams ein. Die Vielfältigkeit unterstützt den Prozess der Problemlösung, erhöht dabei aber das Konfliktpotential, da mehrere Lösungsvorschläge für das gleiche Problem herangetragen werden könnten. Beck sieht darin aber eine Bereicherung, da hier die Möglichkeit besteht, sich für die beste und effektivste Lösung zu entscheiden. (vgl. [Beck and Andres, 2004, S. 66])

Reflexion

Eingespielte Teams hinterfragen und analysieren ihre Arbeitsweise. Sie reflektieren über Aufgaben und Herangehensweisen mit der Absicht aus den Erkenntnissen zu lernen. Die Erkenntnisse sollten jedoch um den emotionalen Aspekt erweitert werden, denn auch die Emotionen der Teammitglieder spielen bei der Reflexion eine große Rolle. Emotionen können die Teammitglieder an ihrer Arbeit hindern. Reflexion sollte jedoch immer mit Aktion in Ver- bindung stehen, denn oft wird mehr reflektiert als gehandelt. (vgl. [Beck and Andres, 2004, S. 67])

Fluss

Durch den ständigen und direkten Kontakt mit den Kunden werden die Entwicklungen laufend verändert, angepasst oder verbessert. Dies erfordert kürzere Zeitabstände und kleinere Entwicklungsabschnitte, in denen die in direkter Absprache mit dem Kunden besprochenen Entscheidungen umgesetzt werden. Hierbei entsteht ein kontinuierlicher Lauf, in der die Entwicklung stetig verbessert wird. (vgl. [Beck and Andres, 2004, S. 68])

Gelegenheit

Probleme, die in der Softwareentwicklung auftreten, sollten als Gelegenheit angesehen werden, denn diese Gelegenheiten bieten die Chance zur Verbesserung und treiben den Lernprozess voran. Diese Art der Problemlösung maximiert die Stärken und minimiert die Schwächen der Teammitglieder. Ähnlich wie aus Kritik in Feedback-Runden, die zur Verbes- serung beitragen, können auch Probleme als positiv eingestuft werden, da auch diese zur positiven Entwicklung beitragen. (vgl. [Beck and Andres, 2004, S. 69])

Redundanz

Da es mehrere Lösungen oder Lösungsansätze für Probleme gibt und geben kann, sollen diese auch mit in den Entwicklungsprozess einfließen. Wenn ein Lösungsansatz oder Vor- schlag nicht zum gewünschten Erfolg führt, gibt es mindestens eine weitere Lösung, die eine erfolgreiche Problemlösung darstellen könnte. Redundanz sorgt dafür, dass Probleme gelöst werden, ohne Verzögerungen entstehen zu lassen. (vgl. [Beck and Andres, 2004, S. 70])

Fehlschlag

Ein offensichtlicher Fehlschlag in der Entwicklung sollte akzeptiert und die Entwicklung abge- brochen werden. Dies bedeutet nicht, dass dieser Fehlschlag als Verschwendung angesehen werden sollte, eher als Erkenntnis, den selben Fehler im nächsten Ansatz zu vermeiden. Ein Fehlschlag kann also auch als Gelegenheit zur Verbesserung gesehen werden. Fehlschläge zu riskieren kann den potentiellen Erfolg bedeuten. (vgl. [Beck and Andres, 2004, S. 71])

Qualität

Der Grundgedanke von agilen Methoden ist durch Flexibilität qualitativ hochwertige Software zu entwickeln. Qualität kann jedoch durch Kosteneinsparmaßnahmen beeinträchtigt werden. Um dies zu verhindern, dürfen in XP die Kosten nicht als Maßstab gelten. Anders als bei klassischen Methoden wird aus Sicht der Qualität kein Endtermin festgelegt, denn durch diese Festlegung werden zeitliche Barrieren gebildet, die die Qualität beeinflussen können. Die Entwickler hätten dadurch nicht die zeitliche Flexibilität Verbesserungen vorzunehmen oder den Anforderungen des Kunden gerecht zu werden. (vgl. [Beck and Andres, 2004, S. 72])

Kleine Schritte

Die grundlegende Herangehensweise in XP sollte die Entwicklung in kleinen Teilabschnitten sein, die sowohl den Umfang der Entwicklung als auch der Tests minimieren. Der dadurch entstehende kontinuierlicher Fluss bietet zudem die Flexibilität agil auf Veränderungen oder Anforderungen des Kunden eingehen zu können. Kleine Schritte reduzieren auch die Anzahl der darin enthaltenen Fehler, deren Beseitigung deutliche Zeitersparnisse bedeuten, und minimieren die Risiken von Fehlentwicklungen. (vgl. [Beck and Andres, 2004, S. 73]).

Akzeptierte Verantwortung

Ein Entwickler, der für die Bearbeitung einer Story zuständig ist, trägt für diese auch die Verantwortung. Die Verantwortung kann nicht übertragen werden. Sie muss vom jeweiligen Entwickler akzeptiert werden. Der Entwickler hat somit die alleinige Verantwortung über das Design, der Implementierung und des Testens der Story. (vgl. [Beck and Andres, 2004, S. 74])

2.3 Praktiken

Die folgenden 13 Primär- und 11 Begleitpraktiken von Beck in der 2. Auflage von „Extreme Programming Explained - Embrace Change 2nd Edition“ [Beck and Andres, 2004] ersetzen die in der 1. Auflage [Beck, 1999] vorgeschlagenen Praktiken vollständig. Das Ersetzen der ehemals aufgestellten Praktiken bedeutet nicht die Obsoleszenz dieser, denn diese werden weiterhin in Projekten aktiv umgesetzt bzw. gelebt. Die Publikation der neuen Praktiken unterstreicht die Weiterentwicklung von XP durch neue Erkenntnisse und aus der Praxis gewonnenen Erfahrungen (vgl. [Hanser, 2010, S. 37-38]).

Die zuvor erwähnten Werte und Prinzipien von XP sollen durch den Einsatz der Praktiken gefestigt werden, wobei die Primärpraktiken zuerst umgesetzt werden sollen. Die Begleitprak- tiken finden in XP erst Verwendung, wenn die Primärpraktiken von allen Teammitgliedern gelebt werden (vgl. [Hanser, 2010, S. 40]).

2.3.1 Primärpraktiken

Zusammen sitzen

XP erfordert die räumliche Nähe der Entwickler zueinander, bietet aber gleichzeitig durch abgetrennte Bereiche genügend Freiraum für Privatsphäre. Durch die räumliche Nähe wird der aktive Austausch gefördert. Zudem minimiert diese Praktik die Entstehung von Missver- ständnissen, die beispielsweise durch falsche Interpretation von Emails entstehen könnten. (vgl. [Hanser, 2010, S. 38])

Komplettes Team

Entsprechend den Anforderung eines Projektes wird über die Zusammensetzung der Teams entschieden, denn nur so kann sichergestellt werden, dass alle Teammitglieder über die nötigen Voraussetzungen bzw. Qualifikationen verfügen und zur Erreichung der Projektziele beitragen können (vgl. [Hanser, 2010, S. 38]). Vertrauen ist ein wichtiges Kriterium für die Zusammenarbeit in Teams. Um Vertrauen unter den Entwicklern zu schaffen, empfiehlt XP die Größe der Teams im Rahmen zu halten. Ab 150 Teammitgliedern ist sowohl der Aufbau von Vertrauen als auch die Zusammenarbeit kaum noch möglich, da es nahezu unmöglich ist, dass sich alle Teammitglieder untereinander persönlich kennen (vgl. [Beck and Andres, 2004, S. 83-84]).

Informative Arbeitsumgebung

Die Arbeitsumgebung sollte als Hilfsmittel genutzt werden. User-Stories können beispielsweise an Tafeln oder Wänden angebracht werden, damit alle Teammitglieder diese zu jeder Zeit einsehen können. Dies macht nicht nur den aktuellen Stand des Projektes sichtbar sondern bietet den einzelnen Mitgliedern auch die Möglichkeit sich User-Stories anzunehmen und diese zu bearbeiten. Auch können Kunden, die vor Ort mit den Entwicklern agieren, sich ein Bild vom Projekt machen und dessen Fortschritt erkennen. (vgl. [Beck and Andres, 2004, S. 39])

Energievolle Arbeit

Energievolle Arbeit ist nur dann möglich, wenn es einen Ausgleich zwischen Arbeits- und Freizeit gibt. Die Leistung von Überstunden wird in XP nicht befürwortet, denn Überstunden sind mitverantwortlich für das Auftreten von Fehlern, die aus unkonzentrierter Arbeitsweise resultieren. Der Ausgleich fördert zudem die Motivation der Entwickler und sorgt für eine gute Arbeitsatmosphäre. (vgl. [Beck and Andres, 2004, S. 87])

Programmieren in Paaren

Das Programmieren in Paaren bietet die Möglichkeit, dass sich einer der Entwickler den inhaltlichen Teil der Entwicklung annimmt, während der Zweite die Zeit dafür nutzt Ver- besserungsvorschläge zu entwickeln oder mögliche Fehler zu erkennen. Diese Art der Zu- sammenarbeit bietet beiden Entwicklern eine Gesamtübersicht über die Entwicklung und minimiert das Risiko Lücken entstehen zu lassen, wenn ein Entwickler das Projekt verlässt. (vgl. [Sampaio et al., 2004, S. 4])

Stories

Um die Anforderungen des Kunden zunächst aus rein fachlicher Sicht aufzunehmen, werden Karteikarten verwendet, auf den die Systemeigenschaften in Prosaform formuliert werden. Die technischen Aspekte werden hierbei völlig ausgeblendet. Im Anschluss an die Formu- lierung schätzen die Entwickler den zeitlichen Aufwand für die Realisierung der User-Story. Diese Schätzung ist für den Realisierungszeitpunkt innerhalb des Gesamtprojektes rele- vant. Um die Entwicklung zu validieren, werden gemeinsam mit den Kunden Akzeptanztests durchgeführt, die die Anforderung und die Entwicklungsergebnisse gegenüberstellen. (vgl. [Loos and Fettke, 2001, S. 17])

Wöchentlicher Zyklus

Die in [Beck, 1999] vorgeschlagenen zwei bis drei Wochen andauernden Iterationen werden in [Beck and Andres, 2004] auf eine Woche reduziert. Der zeitliche Rahmen sollte sich von Montag bis Freitag erstrecken, wobei am letzten Arbeitstag die Implementierung der User- Stories beendet sein muss. Vor Beginn der Implementierung müssen zu Beginn die zu realisierenden Stories identifiziert werden, zu denen auch die Tests entwickelt werden müssen. Im Anschluss an die Vorarbeit beginnt die eigentliche Implementierung auf Basis der bereits entwickelten Tests. (vgl. [Hanser, 2010, S. 40])

Vierteljährlicher Zyklus

Releasezyklen sollen vierteljährlich eingeplant werden, um Feedback vom Kunden zu erhalten und kürzere Reaktionszeiten für Fehlerbeseitigung zu haben. In den Releases sind alle bisher lauffähigen Teilabschnitte vorhanden und können vom Kunden getestet und geprüft werden. Die vierteljährlichen Zyklen werden auch für Gesprächsrunden mit allen Projektbeteiligten genutzt, um sowohl über das bisher Erreichte als auch über Probleme und deren möglicher Lösung zu sprechen. (vgl. [Hanser, 2010, S. 40])

Freiraum

Die Entwickler sollen ohne das Projekt aus den Augen zu verlieren auch Freiraum erhalten, in denen sie sich unabhängig vom Projektgeschehen beschäftigen können. XP erwartet durch diese gewährten Freiräume, dass die Entwickler mit neuen Ideen, die in dieser Zeit entstehen könnten oder entstanden sind, das Projekt voranbringen. (vgl. [Beck and Andres, 2004, S. 96])

[...]

---

¹ Bild Quelle: https://de.wikipedia.org/wiki/Extreme_Programming#/media/File: XP-Werte.png

² Bild Quelle: https://de.wikipedia.org/wiki/Extreme_Programming#/media/File: XP-Evolution-Prinzipien.png