eXtreme Programming

eXtreme Programming (XP) ist die bekannteste agile Software-Entwicklungsmethode. Schon viele Teams konnten durch XP-Techniken deutliche Produktivitätsgewinne erzielen. Für einen erfolgreichen Einsatz muss XP aber auf die Besonderheiten eines jeden Projekts zugeschnitten werden. Die Autoren dieses Buches haben mehrjährige XP-Erfahrungen als Projektleiter, Entwickler und Berater. Auf dieser Basis stellen sie die Thematik anschaulich und praxisorientiert dar und geben außerdem Tipps und Hinweise, welche Anpassungen bei welchen Randbedingungen angezeigt sind. Die 2. Auflage berücksichtigt die Neuerungen bei agilen Methoden und XP, wie Retrospektiven, Aufwandsschätzung für große Projekte und Projektcontrolling. Darüber hinaus wurden aktuelle Projekterfahrungen aufgenommen.

Die Autoren über ihr Buch: Leidvolles Lernen

Als wir zuerst von XP hörten, waren wir fasziniert und gleichzeitig verwundert. Wie kann denn sowas funktionieren? Und tatsächlich geht XP vielfach von vereinfachenden Annahmen aus. Das ist berechtigt, weil es den Prozess auf das Minimum reduziert. Es erfordert allerdings in fast jedem Projekt Adaptionen. Wir haben in verschiedenen Projekten XP an die spezifischen Bedürfnisse angepasst und dabei (mitunter leidvoll) lernen müssen, welche Anpassungen gut funktionieren und welche nicht. Wir haben daher versucht, typische Adaptionen und die daraus erwachsenen Konsequenzen darzustellen. Klappentext

eXtreme-Programming (XP) ist die bekannteste agile Software-Entwicklungsmethode. Schon viele Teams haben und können durch XP-Techniken deutliche Produktivitätsgewinne erzielen. Für einen erfolgreichen Einsatz muss XP aber auf die Besonderheiten jedes Projektes zugeschnitten werden.

Die Autoren dieses Buches haben mehrjährige XP-Erfahrungen als Projektleiter, Entwickler und Berater. Auf dieser Basis stellen sie die XP-Thematik anschaulich und praxisorientiert dar.

Alle XP-Techniken werden erläutert, zu jeder Technik wird neben einer kurzen Beschreibung vor allem auf konkrete Erfahrungen und Empfehlungen fokussiert. Das beinhaltet auch Tipps und Hinweise, welche Anpassungen bei welchen Randbedingungen angezeigt sind. Weiter werden spezielle Themen erörtert, die sich nicht direkt einzelnen XP-Techniken zuordnen lassen, z.B. Rollen, die im Rahmen eines XP-Projektes zu besetzen sind, oder wie XP-Projekte organisiert werden müssen bzw. welche organisatorische Randbedingungen dabei erfüllt werden müssen. Ein eigenes Kapitel widmet sich der Einführung von XP in Projekten und in Unternehmen, u.a. anhand von realen Projektberichten. Auch das Anpassen von XP an unterschiedliche Kontexte wie Outsourcing, Zertifizierung, eingebettete Systeme wird behandelt.

Die 2. Auflage berücksichtigt die Neuerungen an agilen Methoden (z.B. Scrum, Crystal, FDD - Feature Driven Development) und XP, wie die Techniken StandUp-Meeting und Retrospektive sowie Aufwandsschätzung für große Projekte und Projektcontrolling. Auch ein Kapitel zum XP-Ableger "Industrial-IX " (IXP) ist hinzugekommen. Weiter wurden aktuelle Projekterfahrungen aufgenommen.

Die Autoren

Henning Wolf ist Geschäftsführer der it-agile GmbH. Er beschäftigt sich schwerpunktmäßig als Software-Architekt und mit agiler Softwareentwicklung und XP.

Stefan Roock ist Senior-IT-Berater und Coach bei der it-agile GmbH. Er berät Entwicklungsorganisationen bei der Einführung und Anwendung agiler Entwicklungsmethoden und hilft Teams, neue Wege in der Softwareentwicklung zu bestreiten.

Martin Lippert ist Senior-IT-Berater und Coach bei der it-agile GmbH in Hamburg und beschäftigt sich schwerpunktmäßig mit agiler Softwareentwicklung, Refactoring, Entwicklung von Systemen auf Basis der Eclipse-Plattform und Aspektorientierter Programmierung.

Die Autoren halten regelmäßig Seminare/Vorträge zu XP, objektorientierte Programmierung, Java, Rahmenwerke.   


Leseprobe:

7 Explorationsphase (S. 227-228)

Manchmal erwecken Beschreibungen zum eXtreme Programming den Eindruck, ein XP-Projekt würde mit der ersten Releaseplanung beginnen. Das ist aber nur in den seltensten Fällen sinnvoll möglich. Meistens muss der ersten Releaseplanung eine Explorationsphase vorweggeschaltet werden. Projekte, die sofort mit der ersten Releaseplanung beginnen, haben i.d.R. schon nach kurzer Zeit massive Probleme im Projekt.

Wie soll ein Projektteam auch hochqualitative Software entwickeln, ohne dass es Zeit gehabt hätte, sich über die grundlegende Struktur des Systems (Metapher) zu einigen? Wie sollen die Entwickler Aufwände schätzen, wenn das System mit bisher unbekannten Technologien realisiert werden soll? Wie soll irgendjemand seriös argumentieren können, dass sich das Projekt überhaupt lohnt?

Dieses Kapitel beschreibt die Inhalte der Explorationsphase. Es beginnt mit einer Betrachtung von Projektrisiken und deren Management. Anschließend wird das Explorationsteam thematisiert. Es wird beleuchtet, wer mit welchen Aufgaben am Explorationsteam teilnehmen sollte. Die fachliche Erkundung des Projektumfeldes ist ein zentraler Aspekt der Explorationsphase. Es muss den Projektbeteiligten klar werden, welche fachlichen Konzepte im Kern des Projektes stehen werden.

Während der Explorationsphase wird auch festgelegt, welche Technologien eingesetzt werden sollen. Neue Technologien werden evaluiert, um ihren Nutzen für das Projekt abschätzen zu können. Zentral für das Projekt wird außerdem seine organisatorische Einbettung sein. Wer stellt die Schnittstelle zwischen Projekt und Anwenderorganisation dar? Wie ist das Projekt vertraglich aufgestellt? Schließlich müssen sich die Projektmitglieder als Gruppe finden. Die Teambildung ist ebenfalls Teil der Exploration.

7.1 Risikominimierung

Die Explorationsphase eines XP-Projektes ist eine erste Entwicklungsphase, die Risikominimierung zum Ziel hat. Während der Explorationsphase muss geklärt werden, welches fachliche Umfeld bearbeitet wird und wie man mit wem gemeinsam an benötigte fachliche Informationen kommt. Außerdem sollten die wesentlichen technischen Risiken wie z. B. der Einsatz neuer Technologien oder der Anschluss von Drittsystemen abgeklärt werden. Schließlich ist es in der Regel auch Ziel der Explorationsphase, eine erste grobe Gesamtschätzung für ein Projekt abzuliefern. Diese Schätzung ist häufig noch so grob, dass sie eher eine Größenordnung als genaue Aufwände angibt. Die Explorationsphase hat Aspekte der klassischen Analyse und klassischer Vorprojekte. Es werden aber keinesfalls alle Unklarheiten in der Explorationsphase bis ins letzte Detail geklärt. Wir versuchen, die Risiken für das Projekt zu reduzieren. Ganz eliminieren lassen sie sich aber nie.

Zu Beginn einer Explorationsphase muss das Explorationsteam gemeinsam mit dem Kunden eine Risikoliste aufstellen und die Risiken grob bewerten und priorisieren. Diese Liste wird aber nicht zu Beginn gleich vollständig sein, so dass sie während der Exploration ständig angepasst werden muss; natürlich auch dann, wenn durch die Exploration Risiken minimiert oder eliminiert werden konnten. Die Risikoliste sollte die Aktivitäten während der Explorationsphase treiben. Typische Fragen, die es während der Explorationsphase zu klären gilt:

• Sind die Projektbeteiligten mit XP vertraut und weiß jeder, was seine Rolle bedeutet?

• Was soll fachlich umgesetzt werden? Was gehört noch dazu, wo liegt die Grenze des Projektes? Welches gemeinsame Verständnis vom fachlichen Kern haben wir?

• Wenn die Fachlichkeit zu groß wird: Wie und nach welchen Kriterien teilen wir die Fachlichkeit in Subprojekte auf?

• Wer verfolgt welches Projektziel?

• Mit welcher Technologie soll das Projekt umgesetzt werden? Ist sie verfügbar? Ist sie angemessen? Kennt das Team die Technologie ausreichend?

• Welche Drittsysteme spielen eine Rolle? Wie werden sie fachlich und technisch eingebunden?

• Wie sieht der Business Case für das Projekt aus? Unter welchen Randbedingungen lohnt sich das Projekt? Wie sieht die Kosten-Nutzen-Relation aus?