eXtreme Programming in der Praxis


Studienarbeit, 2003
29 Seiten, Note: 1,3

Leseprobe

Inhaltsverzeichnis

1 Motivation

2 eXtreme Programming

3 Der XP-Entwicklungsprozess

4 Der Kunde vor Ort

5 User Stories

6 Akzeptanz-Tests

7 Releaseund Iterations-Planung
7.1 Release-Planung
7.2 Iterations-Planung

8 Programmierung

9 Programmieren in Paaren

10 Testen, Testen, Testen

11 Fortlaufende Integration

12 Abschließende Betrachtung

Endnoten

Literaturverzeichnis

Index

Eidesstattliche Erklärung

1 Motivation

Stellen Sie sich vor, Sie sind der Leiter einer neuen Lebensmittel-Handelskette. Ihre qualitativ hochwertigen Produkte finden bei der Kundschaft so reißenden Absatz, dass Sie seit mehreren Monaten stark expandieren. Dabei hat natürlich auch die Anzahl Ihrer Mitarbeiter beträchtlich zugenommen. Doch mit Ihrem eingesetzten Gehaltsabrechnungssystem (GAS) stoßen Sie langsam an Grenzen. Um Ihre weitere Planung einhalten zu können, benötigen Sie bis zum Jahresende ein für Sie adäquates GAS, das sich durch genauso hohe Qualität wie Ihre Produkte auszeichnet. Unter hoher Qualität verstehen Sie in diesem Kontext Software, die sowohl (nahezu) intuitiv bedienbar und (möglichst) fehlerfrei ist, als auch funktional das bietet, auf was Sie wirklich angewiesen sind. Auf überflüssige Funktionalität verzichten Sie gerne, denn Sie erhöht nur das Risiko einer Terminverzögerung und damit nicht nur die Gefahr eines Budgetüberzugs... Weiterhin würde es Ihnen sehr entgegenkommen, wenn Sie in regelmäßigen Zeitabständen eine funktionierende (Vorab-)Version des GASs erhielten. Schließlich könnten Sie auf diese Weise sehen, was aus Ihrem investierten Kapital geworden ist und Sie könnten die Software teilweise schon einsetzen und dabei gleich auch noch testen! Gäbe es eine Software-Schmiede, die Ihre Wünsche und Vorstellungen bezüglich des GASs umsetzen würde, dann wären Sie auch dazu bereit, den Entwicklern Ihre Mitarbeiter über die gesamte Projektdauer vor Ort zur Verfügung zu stellen.

Ein u.a. für diese Ansprüche geeigneter Ansatz zur Softwareentwicklung entstand, als Kent Beck, Ward Cunningham und Ron Jeffries im Jahre 1996 mit der Entwicklung von Extreme Programming (XP) begannen [11]. Nach der Vollendung von XP beschrieb Beck dessen Prinzipien in seinem Manifest [1]. Da ein Manifest jedoch eine Erklärung von Grundsätzen darstellt, befasst es sich nicht mit einer Umsetzung dieser. Der folgende Text zeigt deshalb Möglichkeiten auf, wie XP in der Praxis realisiert werden kann. Zuvor soll sich aber noch eine Erläuterung von XP im nächsten Kapitel anschließen.

2 eXtreme Programming

... deliver the software that is needed when it is needed.

- Don Wells, [10]

Durch XP wird ein agiler Softwareentwicklungsprozess1 beschrieben, der speziell auf kleine Teams (i.d.R. bis zu zwölf Entwickler) ausgerichtet ist, die vagen oder sich schnell ändernden Anforderungen gegenüberstehen. Ziel dabei ist es, mit Hilfe des Kunden effizient und termingerecht qualitativ hochwertige Software zu entwickeln, die dem Kunden die Funktionalität bietet, die er wirklich benötigt. Was bedeutet dies im Einzelnen? Den jeweils in Paaren zusammenarbeitenden Programmierern stellen sich während des gesamten Entwicklungsprozesses zahlreiche systemspezifische Fragen, die „mit Hilfe des Kunden“ vor Ort schneller und besser beantwortet werden können. Damit die Fertigstellung des System „termingerecht“ erfolgen kann, orientiert sich die Planung fortwährend an der aktuellen Produktivität des Teams. Auf

„qualitativ hochwertige Software“ wird ein besonderes Augenmerk gelegt: Anhand einer stets wachsenden Anzahl von Tests wird das System während der Entwicklung immer wieder auf seine Validität geprüft. Mit der Veröffentlichung vieler Kleiner Releases2 (s. Kapitel 7) erhält der Kunde zudem einen hohen Geschäftswert3.

Doch wie lässt sich dieses Ziel erreichen? Eine Antwort gibt Kent Beck bereits durch den Untertitel seines Manifestes [1]: Embrace Change - umarme die Veränderung, denn oftmals ist die ständige Veränderung die einzige Konstante in einem Software-Projekt. So ändern sich beispielsweise die Anforderungen und Wünsche des Kunden, das Software-Umfeld und -Design, die Team-Zusammensetzung, die eingesetzte Technologie oder der finanzielle Rahmen [8]. Um mit diesem Problem besser zurechtzukommen, ist eine Verinnerlichung der vier Werte von XP

- Einfachheit, Kommunikation, Feedback und Courage - erforderlich. Dabei erfolgt die Umsetzung der vier Werte durch zwölf Hauptverfahren. Im Folgenden sollen diese Werte kurz beschrieben und die zugehörigen Hauptverfahren genannt werden [4]. Auf Letztere wird später ausführlich eingegangen.

Einfachheit bedeutet, die einfachste Lösung zu erstellen, die den aktuellen Anforderungen des Kunden entspricht. Durch diese Konzentration auf das nur heute Benötigte bleibt das System schlank. Die Entwicklung eventuell überflüssiger Funktionalität für zukünftige Zwecke wird vermieden und der Fokus auf die Schöpfung von Geschäftswert gerichtet. Der Wert Einfachheit wird durch die Hauptverfahren Einfaches Design, Metapher und Refactoring realisiert. Kommunikation zwischen den Projektbeteiligten in offener und konstruktiver Form ist essenziell für die Produktivität des Teams und damit auch für den erfolgreichen Abschluss des Projekts. Sie ist wichtig für die Vermeidung von Vermutungen und Missverständnissen, die üblicherweise zu frustrierten und unmotivierten Teammitgliedern führen. Die Hauptverfahren Kunde vor Ort, Kurze Releasezyklen4, Metapher, Planungsspiel, Programmieren in Paaren und Programmierstandards können ohne Kommunikation nicht funktionieren.

Feedback ist für die Entwickler notwendig, weil sie genau wissen müssen, was der Kunde möchte und wie sich das System zu jedem Zeitpunkt verhält. Aber auch für den Kunden ist Feedback unerlässlich, damit er z.B. eine Vorstellung über den Aufwand seiner Systemanforderungen bekommt. Feedback sollte stets sofort und ununterbrochen erfolgen - und zwar in folgenden Hauptverfahren: Fortlaufende Integration, Kunde vor Ort, Kurze Releasezyklen, Planungsspiel und Testen.

Courage ist immer dann vonnöten, wenn schwierige Entscheidungen zu treffen sind. In gewissen Situationen ist es beispielsweise sinnvoll, sich für einen kompletten Neubeginn zu entscheiden. Obwohl dies auf den ersten Blick der eindeutig „härtere Weg“ ist, stellt er bei genauerem Hinsehen möglicherweise die bessere Lösung dar. Doch für eine solche Entscheidung bedarf es einer guten Portion Courage. Courage findet sich in den Hauptverfahren Gemeinsame Verantwortlichkeit und 40-Stunden Woche.

Die zwölf erwähnten Hauptverfahren bestimmen zu einem großen Teil den Entwicklungsprozess bei XP, auf den ein Ausblick im nachstehenden Kapitel gegeben wird. Eine Beantwortung der Fragen, was die einzelnen Hauptverfahren bedeuten und welche Wege es zu ihrer Realisation in der Praxis gibt, liefern dann die noch offen gebliebenen Kapitel.

3 Der XP-Entwicklungsprozess

Der XP-Entwicklungsprozess lässt sich im Vergleich zu anderen Softwareentwicklungsprozessen (wie z.B. dem V-Modell oder dem Rational Unified Process) weder in einzelne Phasen gliedern noch existiert für ihn ein „Leitfaden“ zur Vorgehensweise. Aufgrund dieser Gegebenheiten und der Tatsache, dass XP ein agiler und Code5-zentrierter Prozess ist [9], liegt es nahe, sich in das Entwicklungsprojekt zu stürzen und ohne weiteres mit dem Codieren zu beginnen.

Doch würde dieses Vorgehen nicht den kompletten Entwicklungsprozess überflüssig machen? Ja, denn wer nur drauflos codiert ohne zu planen, zu entwerfen, zu testen, zu dokumentieren usw. und vor allem, ohne zu kommunizieren, der benötigt keinen Entwicklungsprozess. Deshalb ist es durchaus im Sinne von XP, vor jeder Release einige Planungen durchzuführen. Dazu sollte der Kunde vor Ort sein und die mit den Programmierern analysierten Anforderungen in Form von User Stories dokumentieren. Im Anschluss daran sollte der Kunde für die User Stories entsprechende Akzeptanz-Tests spezifizieren, um ein Feedback über deren richtige Implementierung zu erhalten. Hat der Kunde genügend User Stories geschrieben, ist bereits der erste Schritt für eine Releaseund Iterations-Planung vollbracht. Wurden die Releaseund Iterationspläne erstellt, steht dem Code-zentrierten Part von XP, also der Programmierung, nichts mehr im Wege. Da bei XP u.a. Kommunikation, Feedback, Produktivität und Qualität in den Vordergrund treten, findet das Programmieren in Paaren statt, die so viel wie möglich Testen, Testen, Testen. Damit letztendlich eine Release entstehen kann, muss der Code der Entwickler zusammengeführt und in einen ausführbaren Zustand versetzt werden. Diese Aktion wird jedoch mit großer Wahrscheinlichkeit zu Schwierigkeiten führen. Durch eine regelmäßige und Fortlaufende Integration können die Programmierer allerdings solche Fehler rechtzeitig ausmerzen.

Wo aber bleiben die (u.a. zeitverschlingenden) Projekt-Meetings? Sie werden bei XP durch ein

„Tägliches Kurztreffen“ ersetzt. Ein Tägliches Kurztreffen (engl. Stand Up Meeting) ist, wie der Name schon sagt, ein kurzes Treffen der Projektbeteiligten, um Probleme und deren Lösungen zu besprechen, den „Projektfortschritt zu kontrollieren“ [7] und um die Verbundenheit im Team zu fördern. Dabei stellen sich alle Teammitglieder jeden Morgen in einem Kreis auf. Tägliche Kurztreffen sind effizienter, weil jeder bereit ist, an einem kurzen Meeting teilzunehmen, alle über den aktuellen Projektstatus informiert bleiben, keine aufwendigen Meeting-Planungen mehr durchgeführt werden müssen und zahlreiche Meetings mit unterschiedlichen Personen entfallen können. Falls zusätzliche, speziellere Meetings notwendig sind, können sich die entsprechenden Teammitglieder z.B. spontan vor einem Rechner versammeln und dabei gleich den Code ansehen. [10]

Der Weg von der Planung zur Release sollte also gar kein allzu langes Unterfangen darstellen. Um die Produktivität der Projektbeteiligten trotzdem noch ein wenig zu steigern, bietet es sich an, das System durch eine Metapher zu beschreiben. Eine Metapher ist eine für jedermann verständliche Erklärung der Funktionsweise des Systems [5]. Sie „lenkt“ die Entwicklung und Kommunikation [6] durch den Prozess und unterstützt die Projektbeteiligten, das Wesentliche des Systems nicht aus den Augen zu verlieren. Wie eine gute und treffende Metapher für eine Applikation gefunden werden kann, ist bisher noch nicht bekannt.

Aber wer sind eigentlich die Projektbeteiligten? Welche Aufgaben kommen ihnen zu und wer kommuniziert mit wem? Zu den Projektbeteiligten zählen (hauptsächlich) der Kunde, die Entwickler und der Manager. Der Kunde und die Programmierer „bilden“ durch ihre Aktivitäten den Prozess, während der Manager dafür sorgt, dass dies reibungslos bewerkstelligt werden kann. Eine Verdeutlichung der spezifischen Aufgaben des Kunden und der Entwickler erfolgt in den noch ausstehenden Kapiteln. Die Manager-Aufgaben können hier wegen des eingeschränkten Umfangs jedoch nur kurz dargestellt werden: Der Manager bringt den Kunden und die Programmierer zusammen und sorgt jederzeit dafür, dass beide effektiv arbeiten können. Er achtet auf Schwierigkeiten, die das Team ausbremsen, und setzt sich für deren Beseitigung ein. Der Manager sorgt für die Erledigung der Aufgaben, koordiniert diese und berichtet die Resultate. Er trägt Verantwortung gegenüber seinem Personal und schlichtet Konflikte, die zwischen den Projektbeteiligten auftreten. Das Team unterstützt er voller Engagement und belohnt stets dessen Erfolg, z.B. mit Gehaltserhöhungen oder neuen „Spielsachen“, die zur Auflockerung und Motivation einen erheblichen Beitrag leisten [5]. Der Manager kommuniziert somit eine Menge bei seinen Tätigkeiten - genauso wie alle anderen Projektbeteiligten. Jeder kommuniziert mit jedem, die ganze Zeit über... besonders, wenn der Kunde vor Ort ist.

4 Der Kunde vor Ort

Wie bereits in Kapitel 2 ersichtlich wurde, bringt ein Kunde vor Ort den Vorteil mit sich, die Entwickler jederzeit mit zusätzlich benötigten Informationen versorgen zu können. Dank der verbesserten Kommunikation und dem Feedback des Kunden werden Missdeutungen verhindert. Es wird sichergestellt, dass die Programmierer die Anforderungen wie gewünscht implementieren. Dies beschleunigt das Vorankommen und führt im gleichen Zuge zu einer Kostensenkung. Außerdem reduziert sich das zeitverschlingende und kostenproduzierende Schreiben einer Spezifikation auf ein Minimum [6]. Der dadurch bedingte Informationsverlust wird mit Akzeptanz-Tests wieder ausgeglichen [5].

Der Kunde vor Ort trägt also in nicht zu unterschätzendem Maße zu einem produktiveren Arbeitsfluss bei. Aber wie kann der Kunde seinen eigentlichen Arbeitsaufgaben und Tätigkeiten nachkommen, wenn er über die komplette Dauer des Projekts bei seinem Auftragnehmer verweilt? Die Antwort ist einfach und lautet: Er verrichtet seine (gewohnte) Arbeit direkt vor Ort ! Aus technischer Sicht sollte dies in der heutigen Zeit keine zu große Hürde mehr darstellen, denn für eine Vielzahl der Berufe ist der Rechner - ob gewünscht oder nicht - ohnehin das primär genutzte Arbeitsmittel6. Ist der Kunde aufgrund seiner Kompetenzen zu kostbar, um vor Ort zu agieren (z.B. Aktienhändler), gilt es, folgende Schritte in Erwägung zu ziehen [5]:

1. Es sollte ein lokaler Repräsentant für den Kunden gefunden werden. Dies könnte z.B. ein Projekt Manager oder Trainer sein oder aber ein Mitarbeiter, der besonders gute Kenntnisse in diesem Gebiet besitzt. Wichtig hierbei ist, dass er mit dem Kunden auf der gleichen Wellenlänge liegt. Die alltäglichen Projekt-Aufgaben werden dann mit dem Repräsentanten erarbeitet, wobei die Überprüfung der Vorgehensweisen mit dem Kunden selbst und regelmäßig stattfindet.
2. Der Kunde sollte zumindest bei den Planungs-Meetings vor Ort sein, damit er durch die Festlegung seiner Prioritäten stets den höchsten Geschäftswert erhält (s. Kapitel 7). Dies bietet dem lokalen Repräsentanten auch eine gute Möglichkeit, sich mit dem Kunden erneut abzugleichen.
3. Falls realisierbar, sollte der Kunde mit allen Entwicklern so oft wie möglich besucht werden, um Fragen besprechen, die Applikation diskutieren und Einigungen herstellen zu können.
4. Die Frequenz der Releases sollte erhöht werden, so dass sich beim Kunden trotz seiner Abwesenheit ein Bild über die entstehende Anwendung formen kann.
5. Missverständnisse, die häufig durch schriftliche Kommunikation zustande kommen, sollten erwartet werden. Sie können zum Teil mit Hilfe von Telefon-Konferenzen ausgeglichen oder umgangen werden. Durch diese erinnern sich zudem die Beteiligten daran, dass sie - auch wenn sie nicht zusammen sind - alle gemeinsam demselben Team angehören.

Unabhängig davon, ob der Kunde vor Ort sein kann oder nicht, muss er seine Anforderungen spezifizieren - und zwar mit User Stories.

[...]


1 Ein agiler Softwareentwicklungsprozess ist ein adaptiver und menschenorientierter Prozess, d.h. er ist für Änderungen gut geeignet, nicht sonderlich dokumentationslastig, arbeitet nicht gegen die Natur des Menschen und betont, dass die Entwicklung von Software eigentlich genießbar sein sollte (vgl. Fowler, Martin: The New Methodology, „Online im Internet“, http://www.martinfowler.com/articles/newMethodology.html v. Juni 2002, Abfrage v. 20.01.2003).

2 dt. Versionen

3 Der Ausdruck Geschäftswert weicht in diesem Text von seiner gewohnten, betriebswirtschaftlichen Bedeutung ab - der Geschäftswert (engl. Business Value) soll hier im Sinne des Wertes für das Geschäft verstanden werden.

4 später als Kleine Releases bezeichnet

5 kurz für Source Code; auf das deutsche Wort Quelltext wird in diesem Text verzichtet, weil der Gebrauch von Code geläufiger ist.

6 Auf die Problematik des (sicheren) Zugriffs auf unternehmensinterne Daten (von außen) kann hier nicht weiter eingegangen werden.

Ende der Leseprobe aus 29 Seiten

Details

Titel
eXtreme Programming in der Praxis
Hochschule
Duale Hochschule Baden Württemberg Mosbach  (Wirtschaftsinformatik)
Note
1,3
Autor
Jahr
2003
Seiten
29
Katalognummer
V13378
ISBN (eBook)
9783638190510
Dateigröße
422 KB
Sprache
Deutsch
Anmerkungen
Diese Arbeit zeigt Möglichkeiten auf, wie XP in der Praxis realisiert werden kann. 204 KB
Schlagworte
Extreme Programming XP Software Engineering Praxis Umsetzung Kent Beck
Arbeit zitieren
Bastian Helfert (Autor), 2003, eXtreme Programming in der Praxis, München, GRIN Verlag, https://www.grin.com/document/13378

Kommentare

  • Noch keine Kommentare.
Im eBook lesen
Titel: eXtreme Programming in der Praxis


Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden