Dipl.-Inform. Henning Wolf ist Geschäftsführer der it-agileGmbH in Hamburg, bei der er auch als Senior IT-Berater tätig ist.Er leitet und begleitet seit 1999 XP-Projekte. Neben agilenMethoden und Vertragsmodellen gehören agiles Projektmana-gement und Controlling, Aufwandsschätzungen, Software-Architekturen und Qualitätsmetriken zu seinen Arbeitsschwer-punkten. Im Rahmen seiner Beratertätigkeit veröffentlicht erArtikel und hält Vorträge und Schulungen zu diesen und wei-teren Themen.

Dipl.-Inform. Stefan Roock ist Senior IT-Berater bei der it-agileGmbH in Hamburg. Seine Arbeitsschwerpunkte liegen in denBereichen agile Methoden, Projektorganisation sowie Software-Architekturen. Er führt seit 1999 eXtreme-Programming-Pro-jekte durch und berät Entwicklungsorganisationen bei der Ein-führung und Anwendung agiler Entwicklungsmethoden. Er hältregelmäßig Vorträge und führt Tutorials zu seinen Schwer-punktthemen durch. Er ist Autor zahlreicher Artikel sowie einesBuches über Refactorings in großen Softwareprojekten.

Dipl.-Inform. Martin Lippert ist Senior IT-Berater bei derit-agile GmbH in Hamburg. Er studierte Informatik mit denSchwerpunkten Softwaretechnik und Betriebswirtschaft an derUniversität Hamburg. Seit 1999 führt er eXtreme-Programming-Projekte durch und hilft Entwicklungsorganisationen, agileEntwicklungsprozesse einzusetzen. Zu seinen Tätigkeitsschwer-punkten gehören zusätzlich Software-Architekturen, Frame-work-Design und Framework-Implementierung, Refactoring-Techniken und Projektmanagement. Zu diesen Themen hält erregelmäßig Seminare und Vorträge und ist Autor zahlreicherArtikel sowie eines Buches über Refactorings in großen Soft-wareprojekten.

Fotograf: Christian Kalnbach

Henning Wolf · Stefan Roock · Martin Lippert

eXtreme Programming

Eine Einführung mit Empfehlungenund Erfahrungen aus der Praxis

2., überarbeitete und erweiterte Auflage

Henning Wolfhenning.wolf@it-agile.de

Stefan Roockstefan.roock@it-agile.de

Martin Lippertmartin.lippert@it-agile.de

Lektorat: Christa PreisendanzCopy-Editing: Ursula Zimpfer, HerrenbergHerstellung: Verlagsservice Hegele, DossenheimUmschlaggestaltung: Helmut Kraus, www.exclam.de Druck und Bindung: Koninklijke Wöhrmann B.V., Zutphen, Niederlande

Bibliografische Information Der Deutschen BibliothekDie Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie;detaillierte bibliografische Daten sind im Internet über <http://dnb.ddb.de> abrufbar.

ISBN 3-89864-339-5

2. Auflage 2005Copyright © 2005 dpunkt.verlag GmbHRingstraße 1969115 Heidelberg

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen. 5 4 3 2 1 0

v

Vorwort zur 2. Auflage

Wir hatten den ersten Kontakt zu eXtreme Programming (XP) Anfang1999; Kent Beck hat sein XP-Manifest »eXtreme Programming explai-ned« Ende 1999 veröffentlicht. Seitdem sind 6 Jahre vergangen.

In dieser Zeit hat sich herausgestellt, dass XP mehr ist als ein kurz-fristiger Hype. Während viele der Themen der Jahre 1999 und 2000längst auf dem Müllhaufen der Geschichte gelandet sind, ist XP denKinderschuhen entwachsen. Es wird nicht mehr diskutiert, ob XPüberhaupt realisierbar ist. Stattdessen wird nachgefragt, wie man dieVorteile von XP auch für die eigenen Projekte nutzen kann. Ablehnungist Neugier gewichen.

XP hat den Weg bereitet, auf dem auch andere agile Methoden indas Bewusstsein der Fachöffentlichkeit eingezogen sind. Diese »Mar-ketingarbeit« hat sich für XP ausgezahlt. »Agilität« gilt als positiv understrebenswert, und XP ist immer noch die bestimmende Kraft imBereich agiler Entwicklungsmethoden.

Seit 1999 haben wir reichhaltige Erfahrungen mit XP und anderenagilen Entwicklungsmethoden gesammelt. Die erste Auflage diesesBuches hat die Erfahrungen bis 2002 zusammengefasst. Auch mit derhier vorliegenden zweiten Auflage haben wir uns das Ziel gesetzt,unsere Erkenntnisse weiterzugeben. Viele der Erfahrungen aus derersten Auflage haben sich bis heute bestätigt. Wir haben versucht, sienoch klarer darzustellen. An anderen Stellen – wie z. B. beim Projekt-controlling – haben wir einen systematischeren Zugang gewonnen.Hier haben wir das Buch deutlich erweitert.

Nicht nur dieses Buch liegt damit in der zweiten Generation vor.Die Firma Industrial Logic hat ein adaptiertes XP vorgestellt und esIndustrial XP (IXP) genannt (siehe http://industrialxp.org). Kent Beckhat Ende 2004 die zweite Auflage von »eXtreme Programming explai-ned« veröffentlicht. Das Buch ist komplett neu geschrieben und ent-wickelt XP konsequent weiter.

Vorwort zur 2. Auflagevi

Das vorliegende Buch liegt auf einer Linie sowohl mit IXP wieauch mit der zweiten Auflage des XP-Buches von Kent Beck. Dennochorientiert es sich an der Terminologie des ursprünglichen XP; schließ-lich haben wir unsere Erfahrungen im Wesentlichen mit dieser XP-Beschreibung gesammelt. Wir skizzieren IXP und die zweite Auflagedes XP-Buches von Kent Beck daher in einem eigenen Kapitel und stel-len Bezüge zu unseren Erfahrungen her.

Hamburg, Juli 2005

Henning Wolf, Stefan Roock, Martin Lippert

viiVorwort zur 2. Auflage

Leseweg für Leser der 1. Auflage

Wenn Sie bereits die erste Auflage gelesen haben, dann möchten wirIhnen dafür erst einmal danken. Einige Leser haben uns Anregungenund Verbesserungswünsche mitgeteilt. Vor allem aber haben uns vielepositive Stimmen dazu animiert, die Überarbeitung und Aktualisie-rung vorzunehmen, die hiermit vorliegt.

Hier folgt eine kleine Hilfestellung, an welchen Stellen sich loh-nenswerte neue Erfahrungen finden lassen:

■ Die Einleitung in Kapitel 1 wurde nur leicht überarbeitet und ent-hält bis auf einige Verweise auf neue Buchteile nur wenig Neues.

■ Kapitel 2 bringt einige neue Erfahrungen zu den einzelnen XP-Techniken, die meisten in Abschnitt 2.7 beim Testen zu Akzeptanz-tests. Die neu aufgenommenen Techniken »Standup-Meeting«(Abschnitt 2.3) und »Retrospektive« (Abschnitt 2.6) befanden sichzwar auch schon in der ersten Auflage, sind jetzt aber ausführlicherbeschrieben.

■ Kapitel 3 ist komplett neu und behandelt im Überblick die agi-len Methoden Scrum, Feature Driven Development (FDD) undIndustrial XP. Außerdem haben wir einen kurzen Abschnitt überden Eclipse-Entwicklungsprozess und einen längeren Abschnittüber die zweite Auflage des XP-Buches von Kent Beck hinzuge-fügt. Bernd Oestereich hat für dieses Kapitel einen Abschnittzum V-Modell XT beigesteuert.

■ Kapitel 4 haben wir um die Rollen »Produktmanager« (Abschnitt4.1.3), »Business-Coach« (Abschnitt 4.8) und einige Erfahrungenund Empfehlungen erweitert.

■ Kapitel 5 ist bzgl. der im XP-Entwicklungsprozess verwendbarenArtefakte gestrafft und hoffentlich verständlicher geworden.

■ Kapitel 6 über die Organisation von XP-Projekten ist bzgl. Auf-wandsschätzungen (Abschnitt 6.3), Tracking und Projektcon-trolling (Abschnitt 6.4), Skalierung (Abschnitt 6.5) und Vertrags-gestaltung (Abschnitt 6.6) erheblich überarbeitet bzw. ergänztworden.

■ Kapitel 7 über die Bedeutung und Durchführung der Explorations-phase sowie unsere Erfahrungen damit ist komplett neu hinzuge-kommen.

■ Kapitel 8 über die Einführung von XP ist um einige Erfahrungenerweitert worden.

■ Kapitel 9 enthält im Abschnitt 9.5 einen Projektbericht jüngerenDatums, der interessante neue Erfahrungen darstellt.

Vorwort zur 2. Auflageviii

■ Kapitel 10 über spezielle Konstellationen ist in Abschnitt 10.7 umunsere ersten Erfahrungen im Embedded-Bereich ergänzt.

■ Kapitel 11 enthält jetzt neu den Abschnitt 11.3 über die zwölf häu-figsten Fehler, die in XP-Projekten begangen werden.

■ Anhang B (in der ersten Auflage Anhang C) wurde von Grund aufrenoviert und enthält jetzt Beschreibungen und Erfahrungen zuProgrammierwerkzeugen und Tools für XP-Projekte.

Sie können sich gezielt diese Neuerungen und Änderungen heraus-picken, wir empfehlen aber, dass Sie das Buch einfach noch einmalkomplett von vorne bis hinten durchlesen. Vergleichen Sie unsere mitIhren Erfahrungen. Überdenken Sie, warum Sie bestimmte Technikennicht verwenden oder auf größere Widerstände stoßen. Teilen Sie IhreErfahrungen mit uns unter xpbuch.it-agile.de.

Wir wünschen Ihnen beim Lesen und Ausprobieren viel Freude.

ix

Geleitwort zur 1. Auflagevon Frank Westphal

Tom DeMarco erklärt im Vorwort zu Planning Extreme Programming,dass die Prinzipien von XP ein Weg sind, um Prozesse bedeutungsloszu machen. Was hat er damit wohl gemeint?

Jedes Team und jedes Projekt ist einzigartig und benötigt damit sei-nen eigenen maßgeschneiderten Prozess. Tatsächlich will ein Entwick-lungsprozess an die Umgebung angepasst und fortlaufend verbessertwerden. Dies erfordert ständige Reflexion und Reorientierung. DerEntwicklungsprozess selbst durchläuft einen eigenen Entwicklungs-prozess. Deshalb ist es notwendig, dass Sie sich bewusst mit ihm aus-einander setzen. Wobei kann Sie XP unterstützen?

Extreme Programming beschreibt ein Wertesystem sowie eine Mengegenerativer Prinzipien und empfiehlt ein System von Techniken, dieeinander im höchsten Maße unterstützen. Tatsächlich stellen dieseTechniken jedoch noch nicht XP dar. Sie führen erst zu XP. Sie sindwirklich nur die Startlinie. Das Ziel besteht darin, die XP-Technikenanzuwenden, bis sie vollständig in die Gewohnheit übergegangen sind,und mit dieser Basis einen eigenen Prozess zu entwickeln. Wie soll dasfunktionieren?

Regelmäßige Retrospektiven helfen, den Entwicklungsprozessfortlaufend zu verbessern und die Wiederholung von Fehlern zu ver-meiden. Tatsächlich würden Sie kein XP praktizieren, wenn Sie IhrenProzess über mehrere Iterationen hinweg nicht weiterentwickelten.Lernen ist ein ungeschriebener Wert des Extreme Programming undgerade kurze Iterationen erlauben, mit dem Prozess selbst zu experi-mentieren.

Martin, Stefan und Henning sprechen aus praktischer Erfahrung.Sie haben mehrere Projekte erfolgreich durchgeführt mit dem Ziel,dem XP-Ideal möglichst nahe zu kommen. Sie sind nicht blind einemDogma gefolgt. Stattdessen haben sie regelmäßig reflektiert. Was hatfunktioniert? Was nicht? Wo sind Verbesserungen möglich? Was sollte

Geleitwort zur 1. Auflage von Frank Westphalx

nicht vergessen werden? Auf diese Weise sind sie auf sinnvolle Anpas-sungen gestoßen. Ich bin mir sicher, dass die diskutierten TechnikenIhren Werkzeugkasten wertvoll ergänzen werden. Entweder werdendiese Techniken direkt wie beschrieben funktionieren oder Sie müssensie entsprechend für Ihre aktuelle Situation adaptieren. Experimentie-ren Sie einfach, spielen Sie mit Ihrem Prozess!

Hamburg, Dezember 2001

Frank WestphalFreier Berater und Trainer

xi

Inhalt

1 Einleitung 1

1.1 Die XP-Werte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Die XP-Prinzipien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3 Die XP-Techniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3.1 Managementtechniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3.2 Teamtechniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.3.3 Programmiertechniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.4 Projektbeispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.4.1 Kein XP-Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.4.2 Ein XP-Projekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.5 Überblick über das Buch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.6 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2 Die XP-Techniken 25

2.1 Kunde vor Ort (engl. On-Site Customer) . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.1.1 Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.1.2 Beispiel: Kunde vor Ort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.1.3 Erfahrungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.1.4 Beispiel: Angepasste Technik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.1.5 Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.1.6 Bezug zu anderen XP-Techniken . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.2 Planungsspiel (engl. Planning Game) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.2.1 Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.2.2 Erfahrungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.2.3 Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.2.4 Bezug zu anderen XP-Techniken . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.3 Standup-Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.3.1 Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.3.2 Erfahrungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.3.3 Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.3.4 Bezug zu anderen XP-Techniken . . . . . . . . . . . . . . . . . . . . . . . . . 43

Inhaltxii

2.4 Metapher (engl. Metaphor) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.4.1 Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.4.2 Erfahrungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.4.3 Beispiel: WAM-Metaphern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462.4.4 Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472.4.5 Bezug zu anderen XP-Techniken . . . . . . . . . . . . . . . . . . . . . . . . . 47

2.5 Kurze Releasezyklen (engl. Short Releases) . . . . . . . . . . . . . . . . . . . . . . . 482.5.1 Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482.5.2 Beispiel: Kurze Releasezyklen bei der Ablösung eines

Hostsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492.5.3 Erfahrungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512.5.4 Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562.5.5 Bezug zu anderen XP-Techniken . . . . . . . . . . . . . . . . . . . . . . . . . 57

2.6 Retrospektive (engl. Retrospective) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582.6.1 Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 582.6.2 Erfahrungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 602.6.3 Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 612.6.4 Bezug zu anderen XP-Techniken . . . . . . . . . . . . . . . . . . . . . . . . . 61

2.7 Testen (engl. Testing) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622.7.1 Komponententests: Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . 622.7.2 Komponententests: Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632.7.3 Komponententests: Erfahrungen . . . . . . . . . . . . . . . . . . . . . . . . . 662.7.4 Diskussion: Komponententests als Testlabor für erbende

Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682.7.5 Diskussion: Testen und das Vertragsmodell . . . . . . . . . . . . . . . 682.7.6 Akzeptanztests: Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . 702.7.7 Akzeptanztests: Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722.7.8 Akzeptanztests: Erfahrungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 732.7.9 Komponententests: Empfehlungen . . . . . . . . . . . . . . . . . . . . . . 762.7.10 Akzeptanztests: Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . 762.7.11 Bezug zu anderen XP-Techniken . . . . . . . . . . . . . . . . . . . . . . . . . 76

2.8 Einfaches Design (engl. Simple Design) . . . . . . . . . . . . . . . . . . . . . . . . . . 782.8.1 Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 782.8.2 Erfahrungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812.8.3 Diskussion: Einfache Designs etablieren . . . . . . . . . . . . . . . . . . 842.8.4 Diskussion: Einfaches Design und Frameworks . . . . . . . . . . . . 842.8.5 Diskussion: Performance-Optimierungen . . . . . . . . . . . . . . . . . 852.8.6 Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 862.8.7 Bezug zu anderen XP-Techniken . . . . . . . . . . . . . . . . . . . . . . . . . 87

2.9 Refactoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882.9.1 Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 882.9.2 Erfahrungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 892.9.3 Beispiel: Umbenennen einer Operation in einer Oberklasse . . 922.9.4 Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 932.9.5 Bezug zu anderen XP-Techniken . . . . . . . . . . . . . . . . . . . . . . . . . 94

xiiiInhalt

2.10 Programmieren in Paaren (engl. Pair Programming) . . . . . . . . . . . . . 952.10.1 Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 952.10.2 Erfahrungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 972.10.3 Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1052.10.4 Bezug zu anderen XP-Techniken . . . . . . . . . . . . . . . . . . . . . . . 105

2.11 Gemeinsame Verantwortlichkeit (engl. Collective Ownership) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1072.11.1 Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1072.11.2 Erfahrungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1072.11.3 Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1102.11.4 Bezug zu anderen XP-Techniken . . . . . . . . . . . . . . . . . . . . . . . 111

2.12 Fortlaufende Integration (engl. Continuous Integration) . . . . . . . . . 1122.12.1 Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1122.12.2 Erfahrungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1132.12.3 Beispiel: Fortlaufende Integration in einem

Ausbildungsprojekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1162.12.4 Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1172.12.5 Bezug zu anderen XP-Techniken . . . . . . . . . . . . . . . . . . . . . . . 117

2.13 Programmierstandards (engl. Coding Standards) . . . . . . . . . . . . . . . . 1182.13.1 Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1182.13.2 Erfahrungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1192.13.3 Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1202.13.4 Bezug zu anderen XP-Techniken . . . . . . . . . . . . . . . . . . . . . . . 121

2.14 Nachhaltiges Tempo (Sustainable Pace) . . . . . . . . . . . . . . . . . . . . . . . . . 1212.14.1 Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1212.14.2 Erfahrungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1222.14.3 Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1242.14.4 Bezug zu anderen XP-Techniken . . . . . . . . . . . . . . . . . . . . . . . 125

2.15 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

3 Agile Methoden im Überblick 133

3.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1333.1.1 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

3.2 Feature Driven Development (FDD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1373.2.1 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

3.3 Eclipse-Entwicklungsprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1393.3.1 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

3.4 Industrial XP (IXP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1413.4.1 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

3.5 XP (zweite Auflage von Beck) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1453.5.1 Werte (engl. Values) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1463.5.2 Prinzipien (engl. Principles) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1463.5.3 Techniken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1483.5.4 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

Inhaltxiv

3.6 V-Modell XT(Beitrag von Bernd Oestereich, OOSE GmbH) . . . . . . . . . . . . . . . . . . . . . . 157

3.7 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1593.8 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

4 Rollen 163

4.1 Kunde (engl. Customer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1634.1.1 Auftraggeber (engl. Client) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1644.1.2 Anwender (engl. User) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1654.1.3 Produktmanager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1664.1.4 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

4.2 Programmierer (engl. Programmer) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1674.3 Tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1684.4 Verfolger (engl. Tracker) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1694.5 Projektleiter (engl. Project Manager) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1704.6 XP-Trainer (engl. XP Coach) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1714.7 Technologieberater (engl. Consultant) . . . . . . . . . . . . . . . . . . . . . . . . . . 1724.8 Business-Coach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1724.9 Empfehlungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1734.10 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

5 Artefakte 175

5.1 Story-Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1765.1.1 Adaption: Anwendungsfälle (Use Cases) . . . . . . . . . . . . . . . . 178

5.2 Ergänzung: Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1795.3 Ergänzung: Projekttagebuch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1805.4 Task-Cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

5.4.1 Technische Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1825.4.2 Detaillierung von Stories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

5.5 Releaseplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1855.5.1 Adaption: Kernsystem mit Ausbaustufen sowie

Spezialsystemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1865.6 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

6 Organisation 191

6.1 Anforderungsermittlung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1916.2 Projektplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1956.3 Aufwandsschätzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1976.4 Tracking/Projektcontrolling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2026.5 Skalierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

xvInhalt

6.6 Vertragsgestaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2086.6.1 Aufwandsprojekt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2116.6.2 Budget mit fixierter Funktionalität . . . . . . . . . . . . . . . . . . . . . . 2126.6.3 Budget mit fixierten Inkrementen . . . . . . . . . . . . . . . . . . . . . . 2136.6.4 Budget mit variablen Inkrementen . . . . . . . . . . . . . . . . . . . . . 2146.6.5 Design to Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2156.6.6 Mietsoftware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2166.6.7 Pay per Use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

6.7 Softwareprojekte aus Kundensicht (Beitrag von Jürgen Ahting, Ameco GmbH) . . . . . . . . . . . . . . . . . . . . . . . . 218

6.8 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

7 Explorationsphase 227

7.1 Risikominimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2287.2 Das Explorationsteam . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2307.3 Fachliche Erkundung des Feldes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2327.4 Technische Risikominimierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2357.5 Organisatorische Rahmenbedingungen klären . . . . . . . . . . . . . . . . . . 2367.6 Teambildung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2387.7 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238

8 XP einführen 241

8.1 Einführungsstrategien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2428.1.1 XP als Komplettpaket erlernen . . . . . . . . . . . . . . . . . . . . . . . . . 2428.1.2 XP schrittweise erlernen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2438.1.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246

8.2 Der XP-Trainer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2468.3 Wie wird man ein XP-Entwickler? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2478.4 Management für XP-Projekte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2498.5 Anpassung von XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2508.6 Typische Fallen und wie man sie umgeht . . . . . . . . . . . . . . . . . . . . . . . . 2528.7 XP spielerisch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

8.7.1 eXtreme Hour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2568.7.2 eXplanations Game . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256

8.8 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257

9 Projektberichte 259

9.1 Projekt Kermit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2609.1.1 Projektkontext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2609.1.2 XP-Einsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2619.1.3 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

Inhaltxvi

9.2 Projekt Gonzo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2629.2.1 Projektkontext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2629.2.2 XP-Einsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2649.2.3 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

9.3 Projekt Scooter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2689.3.1 Projektkontext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2689.3.2 XP-Einsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2699.3.3 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

9.4 Projekt JWAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2759.4.1 Projektkontext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2759.4.2 XP-Einsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2759.4.3 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280

9.5 Projekt Fozzy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2809.5.1 Projektkontext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2809.5.2 XP-Einsatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2829.5.3 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

9.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289

10 Spezielle Konstellationen 291

10.1 Produktentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29110.2 eXtreme Frameworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29310.3 Migration von Legacy-Systemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29610.4 E-Business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29710.5 Outsourcing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29910.6 Zertifizierung von Entwicklungsprozessen . . . . . . . . . . . . . . . . . . . . . . 30110.7 Technisch eingebettete Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30210.8 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

11 Bewertung und Ausblick 307

11.1 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30711.2 Für Bedenkenträger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307

11.2.1 Für Projektleiter und Manager . . . . . . . . . . . . . . . . . . . . . . . . . . 30811.2.2 Für Entwickler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

11.3 Die Top-12-Fehler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31011.3.1 Agil = schwammig/beliebig . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31011.3.2 Kommunikationsprobleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31111.3.3 Überanpassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31211.3.4 Kein Tracking/Controlling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31311.3.5 Wir stellen uns dumm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31311.3.6 Naives Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31411.3.7 Deployment wird unterschätzt . . . . . . . . . . . . . . . . . . . . . . . . . 31511.3.8 Collective Ownership skaliert nicht . . . . . . . . . . . . . . . . . . . . . 31511.3.9 Falsche Retrospektiven (zu technisch) . . . . . . . . . . . . . . . . . . 31611.3.10 Unechter Kunde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317

xviiInhalt

11.3.11 Grandioser Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31711.3.12 Kunde unterliegt Entwicklern . . . . . . . . . . . . . . . . . . . . . . . . . . 31811.3.13 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

11.4 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31911.5 Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319

Anhang A Häufig gestellte Fragen (FAQ) 323

Anhang B Programmierwerkzeuge 327

B.1 Entwicklungsumgebungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327B.2 Versionsverwaltungssysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328B.3 Testtools für Komponententests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330B.4 Testtools für Akzeptanztests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330B.5 Refactoring-Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332B.6 Make-Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

Glossar 335

Stichwortverzeichnis 345

Inhaltxviii

1

1 Einleitung

■ Kann man Software nicht wesentlich schneller entwickeln,als es heute üblich ist?

■ Führen die gängigen Entwicklungsprozesse sicher zuhochqualitativer Software?

■ Ist das Risiko für gescheiterte Softwareprojekte so gering,wie das in anderen Entwicklungsdisziplinen der Fall ist?

Diese und ähnliche Fragen werden seit über fünf Jahres heiß diskutiert.Ein wesentlicher Auslöser ist die Diskussion um eXtreme Pro-gramming (XP). Wir können diese Fragen natürlich auch nicht endgül-tig beantworten, wollen aber auf Grundlage unserer Erfahrungen mitXP einige Denkanstöße geben. Wir hoffen, dass wir in diesem Buchunsere Erfahrungen so aufbereitet haben, dass sie auch beim Auspro-bieren hilfreich sind. Letztlich kann sich jedes Entwicklungsteam dieoben aufgeführten Fragen nur selbst auf Basis eigener Erfahrungbeantworten.

XP ist eine relativ neue Entwicklungsmethodik, die in den letztenfünf Jahren unglaublich bekannt geworden ist. Dazu haben wesentlichdie provokanten Thesen von XP beigetragen. So verwundert es auchnicht weiter, dass XP in einigen Kreisen regelrecht berüchtigt ist. Neu-erdings reicht es für Entwicklungsmethoden nicht mehr aus, dass siebesonders mächtig und allumfassend sind. Ganz im Gegenteil wirdimmer häufiger ein schlanker, leichtgewichtiger (agiler) Entwicklungs-prozess angestrebt, so dass heute alles ausgiebig gerechtfertigt werdenmuss, was zusätzlich in eine Entwicklungsmethode aufgenommenwird. In einigen Fällen mag der Puritismus zu weit gehen. Fest stehtaber, dass XP viel frischen Wind in die Diskussion um Entwicklungs-methoden gebracht hat.

Kent Beck hat als Vater von XP im Jahr 2000 das erste Buch zudem Thema veröffentlicht (siehe [Beck 00]) und knapp fünf Jahr spätermit der deutlich überarbeiteten Auflage des XP-Manifests (siehe [Beck

1 Einleitung2

04]) die Messlatte noch einmal ein gutes Stück höher gelegt. Wir wer-den uns im Folgenden häufig auf diese Bücher beziehen. XP ist aller-dings nicht ausschließlich von Kent Beck entwickelt worden. EineReihe seiner Kollegen, sowohl aus seinem direkten Umfeld als auchaus der Software-Engineering-Gemeinde, setzt ebenfalls XP ein, undinzwischen hat sich eine ganze Community zu dieser Art der Software-entwicklung zusammengefunden. Prominente Mitglieder sind unteranderem Ron Jeffries, Martin Fowler, Ward Cunnigham und RobertC. Martin, die ebenfalls Bücher zu Themen rund um XP und agileMethoden veröffentlicht haben1. Auf Konferenzen ist das Thema mitentsprechenden Tutorials, Workshops und Panels präsent. Seit demJahr 2000 gibt es sogar eine spezielle Konferenz zum Thema eXtremeProgramming und agile Entwicklungsprozesse.

Unser Hintergrund Wir nutzen XP-Techniken seit Anfang 1999 für die Anwendungs-entwicklung in einer Reihe von kommerziellen Projekten2 (siehe Kapi-tel 9). Wir wissen, dass XP große Potenziale für die Softwareentwick-lung bietet. In diesem Buch wollen wir unsere Erfahrungen mit XPschildern und damit anderen Softwareentwicklern in ihren Projektenhelfen, XP erfolgreich anzuwenden. Wir beschäftigen uns sowohl imRahmen der professionellen Projektarbeit als auch auf den entspre-chenden Konferenzen mit XP und tauschen unsere Erfahrungen mitanderen aus der Community aus. Beide Linien sind in dieses Buch ein-geflossen.

In den letzten Jahren haben wir mit zu vielen Personen XP-Erfah-rungen und -Konzepte diskutiert, als dass wir alle namentlich nennenkönnten. Wir möchten daher stellvertretend denen danken, mit denenwir besonders intensive Diskussionen geführt haben:

Dank ■ Mit den Mitgliedern der deutschsprachigen XP-Mailingliste habenwir einen Teil der hier vorgestellten Erfahrungen und Konzepte dis-kutiert. Die Erfahrungen der Mitglieder der Mailingliste haben uns

1. Die XP-Bücher sind so erfolgreich, dass sie ins Deutsche übersetzt sind oderdie Übersetzung für die nahe Zukunft ansteht.

2. Wir werden manchmal gefragt, wie wir seit Anfang 1999 XP-Techniken ein-setzen können, wenn das XP-Buch von Kent Beck erst Ende 1999 erschienenist. Die Techniken sind allerdings nicht mit dem Buch von Kent Beck zumersten Mal beschrieben und diskutiert worden. Viele der Techniken wurdenschon Jahre vorher in unterschiedlichen Kontexten erörtert. So finden sichviele XP-Ansätze inkl. dem Programmieren in Paaren (engl. Pair Pro-gramming) in [Cunningham 96]. Zudem haben wir bereits im April 1999 aneinem Workshop von Kent Beck zum Thema »eXtreme Programming« teil-genommen.

31 Einleitung

immer wieder neue Perspektiven und Zugangsweisen zu XP eröff-net.

■ In ganz Deutschland existieren XP-User-Groups, die sich mehroder weniger regelmäßig treffen. Die XP-User-Group-Hamburgtrifft sich ca. einmal im Monat. Auch hier haben sich wertvolleDiskussionen ergeben.

■ Mit Jutta Eckstein, Johannes Link, Frank Westphal, TammoFreese, Christian Wege und Hans Wegener haben wir interessanteGespräche auf unterschiedlichen Konferenzen geführt.

■ Auf den XP-Konferenzen haben wir eine Reihe von Artikeln veröf-fentlicht und sowohl von den Reviewern als auch von den Teilneh-mern der Konferenzen wichtiges Feedback erhalten.

■ Jürgen Ahting, Alex Bepple, Jutta Eckstein, Tammo Freese, DierkKönig, Johannes Link, Matthias Lübken, Helmut Neukirchen,Björn Ostermann, Marko Schulz und Frank Westphal haben früheVersionen dieses Buches gelesen und uns detailliertes und kon-struktives Feedback gegeben.

■ Bernd Oestereich hat die Beschreibung des V-Modells XT in Kapi-tel 3 beigesteuert.

■ Olaf Thiel und Sebastian Sanitz waren bereit, sich für Kapitel 2beim Programmieren in Paaren ablichten zu lassen.

■ Jürgen Ahting hat für das Kapitel 6 den Abschnitt 6.7 beigesteuert,der die Sicht des Kunden auf Softwareprojekte beleuchtet.

■ 2000 bis 2004 arbeiteten wir als Berater und Entwickler bei der C1Workplace Solutions GmbH. Die Mitarbeiter standen uns immerwieder als Gesprächspartner für unsere zum Teil recht »spinner-ten« Ideen zur Verfügung; unsere damaligen Chefs haben unsgewähren lassen.

■ Seit 2005 arbeiten wir im Rahmen der it-agile GmbH fokussiert ander Anwendung und Weiterentwicklung agiler Methoden. DenKollegen der it-agile gebührt unser Dank für ihre Unterstützung.

■ Im Rahmen unserer Arbeit haben wir eine Vielzahl von Entwick-lungsprojekten begleitet und selbst durchgeführt. In diesen Projek-ten haben wir die Erfahrungen machen können, die wir hier vor-stellen. Allen Projektpartnern gebührt Dank für die fruchtbareZusammenarbeit.

■ Neben der Arbeit in kommerziellen Projekten arbeiteten wir alswissenschaftliche Mitarbeiter am Fachbereich Informatik der Uni-versität Hamburg. Die Mitarbeiter am Arbeitsbereich Software-technik haben unsere Arbeit nach Kräften unterstützt und uns dieMöglichkeit gegeben, in Seminaren und Praktika XP zu thematisie-ren.

1 Einleitung4

■ Außerdem möchten wir dem dpunkt.verlag und persönlich ChristaPreisendanz für die Betreuung dieses Buchprojektes danken.

■ Nicht zuletzt gehört unser Dank unseren Frauen für mehr, als manhier hinschreiben könnte.

Terminologie XP stammt aus dem englischen Sprachraum. Wir haben deutscheÜbersetzungen verwendet, wo diese in der XP-Szene akzeptiert sind,geben aber jeweils den englischen Originalbegriff mit an. Ist keineakzeptierte Übersetzung vorhanden, verwenden wir den englischenOriginalbegriff.

Überblick über dieses

Kapitel

Im Rest dieses Kapitels geben wir eine Kurzübersicht über XP.Dazu beschreiben wir zuerst die XP-Werte, kommen dann zu den Prin-zipien und schließlich zu den XP-Techniken. Schließlich veranschauli-chen wir den Unterschied zwischen klassischen Vorgehensweisen undXP anhand eines Beispielprojektes. Wir beschreiben zuerst, wie einklassisches Projekt verlaufen könnte, und anschließend, wie ein XP-Projekt ablaufen könnte. Dabei haben wir die Unterschiede auf dieSpitze getrieben, um sie zu kontrastieren.

1.1 Die XP-Werte

Vier Werte XP ruht auf vier Werten: Einfachheit (engl. Simplicity), Kommunika-tion (engl. Communication), Feedback (engl. Feedback) und Mut(engl. Courage) (siehe Abb. 1–1). In diesen Werten liegt der wesent-liche Schlüssel zu XP. Wer diese Werte lebt, kann die XP-Technikeneinfach erlernen und erfolgreich einsetzen. Wer sich mit den Wertennicht identifizieren kann, dem werden die XP-Techniken auch nichtwesentlich weiterhelfen.

Kommunikation (Communication)

Feedback

Einfachheit(Simplicity)

Mut (Courage)

Abb. 1–1:

XP-Werte

51.1 Die XP-Werte

Einfache LösungenXP will möglichst einfache Lösungen finden, weil sie schneller undkostengünstiger zu realisieren sind als komplexe Lösungen. Außerdemlassen sich einfache Lösungen leichter erklären sowie einfacher wartenund weiterentwickeln. Aus dieser Erkenntnis entstammt die Leitlinie,stets die einfachste Lösung zu realisieren (engl. The simplest thing thatcould possibly work). Einfachheit bezieht sich im Übrigen auch aufden Entwicklungsprozess. Daher ist XP selbst einfach gehalten.

FeedbackEin wichtiger Punkt bei jedem Softwareentwicklungsprojekt ist dieQualitätssicherung. In XP-Projekten wird Qualität über Feedbackgesichert. Das Feedback findet dabei auf verschiedenen Ebenen statt.Entwickler schreiben Komponententests, um Feedback über die Kor-rektheit ihrer Software zu erhalten. Neue Systemversionen werden denAnwendern möglichst schnell zur Verfügung gestellt, um von denAnwendern Feedback darüber zu erhalten, ob die Software bei derAufgabenerledigung hilft.

KommunikationAlle Projektmitglieder sollen intensiv miteinander kommunizieren.Dabei steht das persönliche Gespräch im Vordergrund, da auf diesemWege Informationen am effektivsten auszutauschen sind. Insbesonderekönnen Missverständnisse und Unklarheiten direkt ausgeräumt wer-den. Wenn eine intensive Kommunikation der Projektmitgliedersichergestellt ist, kann auf einen Gutteil der sonst üblichen Dokumen-tation verzichtet werden. Eine geschriebene Dokumentation kann ausunterschiedlichen Gründen weiterhin sinnvoll oder notwendig sein(z. B. Revisionssicherheit in Banken und Versicherungen). Allerdingsist diese Dokumentation für den Projekterfolg nicht primär entschei-dend.

MutEinfache Lösungen, Feedback und Kommunikation erfordern eineMenge Mut. Dies gilt vor allem dann, wenn man es nicht gewohnt ist,nach diesen Werten zu handeln. Einfache Lösungen erfordern Mut,weil man etwas weglassen muss. Man muss die Aspekte bewusstabwählen, die weniger wichtig sind und die Lösung komplex machenwürden. In diesem Sinne braucht man für einfache Lösungen den Mutzur Lücke. Feedback erfordert Mut, weil eine negative Bewertung alspersönliche Kritik aufgefasst werden könnte. Entwickler halten sichmanchmal – bewusst oder unbewusst – für unfehlbar und können Kri-tik an der von ihnen entwickelten Software nur schwer ertragen. Kom-munikation erfordert Mut, weil sich herausstellen kann, dass maneinem Missverständnis aufgesessen ist und etwas an der erstellten Soft-ware wieder ändern muss. Bei der Kommunikation mit Kunden undAnwendern müssen sich die Entwickler auf deren Fachsprache einlas-sen. Sie entfernen sich damit von dem festen Boden der ihnen bekann-ten Technologien und müssen Unwissenheit im Anwendungsbereich

1 Einleitung6

eingestehen. Schließlich müssen Entwickler mit ihren Vorgesetztenkommunizieren, um XP in einem Unternehmen einzuführen.

Sprechen wir von einem XP-Projekt oder von eXtreme Pro-gramming allgemein, so sprechen wir immer über die beteiligten Men-schen. Durch die Werte wird deutlich, dass die Projektbeteiligten imMittelpunkt stehen, im Gegensatz zu Werkzeugen, Prozessen oder demProdukt.

1.2 Die XP-Prinzipien

XP-Prinzipien Die 15 XP-Prinzipien leiten sich aus den XP-Werten ab. Die fünf zen-tralen Prinzipien sind

■ Unmittelbares Feedback (engl. Rapid Feedback)■ Einfachheit anstreben (engl. Assume Simplicity)■ Inkrementelle Veränderung (engl. Incremental Change)■ Veränderung wollen (engl. Embracing Change)■ Qualitätsarbeit (engl. Quality Work).

Unmittelbares Feedback Unmittelbares Feedback: Feedback sollte so schnell wie möglich ein-geholt werden. Aus der Lernpsychologie weiß man, dass der zeitlicheAbstand zwischen Aktion und Feedback eine entscheidende Rolle fürden Lernerfolg spielt. Je kürzer die zeitliche Differenz, desto größer derLernerfolg. Gleichzeitig verhindern wir durch unmittelbares Feedback,dass wir unnötig lange in die falsche Richtung denken und arbeiten.

Einfachheit anstreben Einfachheit anstreben: Einfache Lösungen haben eine Reihe wich-tiger Vorteile gegenüber komplizierten Lösungen. Sie sind schneller zuerstellen, so dass wir schneller Feedback bekommen können. EinfacheLösungen sind leichter zu verstehen und damit leichter zu kommuni-zieren. Nicht zuletzt sind einfache Lösungen schneller änderbar,wodurch wir im Entwicklungsprozess flexibler auf geänderte Gege-benheiten reagieren können. Das Streben nach Einfachheit bereitet vie-len Softwareentwicklern zunächst Probleme, da uns (nicht nur) inunserer Ausbildung immer wieder eingebläut wurde, dass wir für dieZukunft planen müssen. Es mag paradox erscheinen, aber geradedurch einfache Lösungen sind wir bestens für die Zukunft vorbereitet.Da wir schlichtweg nicht wissen, welche Anforderungen die Zukunftfür uns bereithält, ist es am effektivsten, nicht über zukünftige Anfor-derungen zu spekulieren. Stattdessen sind wir darauf vorbereitet, jedebeliebige in der Zukunft auftretende Anforderung umzusetzen, weilunsere einfachen Lösungen leicht änderbar sind.

Inkrementelle

Veränderung

Inkrementelle Veränderung: Auch wenn wir Einfachheit anstre-ben, werden Softwaresysteme im Laufe ihrer Entwicklung so komplex,

71.2 Die XP-Prinzipien

dass Änderungen unerwartete Effekte verursachen können. Nur wennwir stets kleine Änderungen vornehmen, bleiben diese Effektebeherrschbar. Jeder so auftretende Seiteneffekt kann leicht in Bezie-hung zu kleinen Änderungen gesetzt werden. Nehmen wir hingegengroße Veränderungen vor, so bedeutet dies ein sehr hohes Risiko, dassnicht beherrschbare Seiteneffekte auftreten. Dann ruft nämlich eineMenge von Änderungen eine Menge von Seiteneffekten hervor und wirkönnen nicht feststellen, in welcher Beziehung diese zueinander stehen.

Veränderung wollenVeränderung wollen: Fortschritt bedeutet Veränderung. Nur, werVeränderungen will, wird mit Fortschritt belohnt. Veränderung bedeu-tet aber auch, dass man seine Komfortzone verlassen muss. Man mussneue Dinge wagen und Fehlschläge riskieren – immer in dem Bewusst-sein, dass man vor allem aus Fehlern lernt.

QualitätsarbeitQualitätsarbeit: Kein Softwareentwickler programmiert gerneschlechte Software. Softwareentwickler liefern gerne Qualitätsarbeit.Das erhöht ihre Arbeitszufriedenheit und damit wiederum ihre Pro-duktivität. In einem XP-Projekt muss daher die Möglichkeit geschaf-fen werden, Qualitätsarbeit abzuliefern. Allerdings muss jeweils klardefiniert sein, wer bestimmt, ob eine hohe oder niedrige Qualität vor-liegt. Mitunter verwechseln Softwareentwickler ihre eigenen Quali-tätsmaßstäbe mit denen der Anwender. Letztlich geht es darum, für dieAnwender hochqualitative Software zu entwickeln. Also definieren dieAnwender zumindest den Maßstab für die Gebrauchsqualität der Soft-ware. Unmittelbares Feedback durch die Anwender hilft, möglichsthäufig die Gebrauchsqualität bewerten zu lassen und Erfolgserlebnissezu produzieren.

Die weiteren XP-Prinzipien sind

■ Lernen lehren (engl. Teach Learning)■ Geringe Anfangsinvestition (engl. Small Initial Investment)■ Auf Sieg spielen (engl. Play to win)■ Gezielte Experimente (engl. Concrete Experiments)■ Offene, aufrichtige Kommunikation (engl. Open, honest Commu-

nication)■ Die Instinkte des Teams nutzen, nicht dagegen arbeiten (engl.

Work with people’s instincts, not against them)■ Verantwortung übernehmen (engl. Accepted Responsibility)■ An örtliche Gegebenheiten anpassen (engl. Local Adaptations)■ Mit leichtem Gepäck reisen (engl. Travel light) ■ Ehrliches Messen (engl. Honest Measurement).

Lernen lehrenLernen lehren: XP wird von einigen Verfechtern dogmatisch vertreten.Allerdings hat XP genau den entgegengesetzten Anspruch. XP will

1 Einleitung8

auch lehren zu lernen. Entwickler sollen z. B. nicht den »Befehl« erhal-ten, eine bestimmte Anzahl von Tests zu schreiben. Stattdessen sollendie Entwickler selbst lernen, wie viele Tests sie benötigen.

Geringe

Anfangsinvestitionen

Geringe Anfangsinvestitionen: Wir leben in einer unsicheren Welt,insbesondere was Softwareentwicklung angeht. Auch wenn ein Projektüber einen längeren Zeitraum geplant wird, kann es sein, dass es vor-zeitig wieder beendet wird. Um den finanziellen Verlust in solchen Fäl-len gering zu halten, sollen die Anfangsinvestitionen möglichst kleinsein. Gleichzeitig werden Entwickler und Anwender gezwungen, sichin einem engen finanziellen Rahmen zu bewegen und sich auf die wirk-lich wichtigen Aspekte des Projektes zu konzentrieren. In der Vergan-genheit wurden einige Projekte mit sehr großen Budgets und finanziel-len Freiheiten durchgeführt. Die meisten endeten in einem Desaster.

Auf Sieg spielen Auf Sieg spielen: XP-Projekte spielen, um zu gewinnen. Vieleandere Projekte spielen, um nicht zu verlieren. Das ist keineswegs dasGleiche. Während das erste Projektteam offensiv die anstehenden Auf-gaben angeht, ist das zweite Projektteam stets darauf bedacht, nurkeine Fehler zu machen. Das erste Team ist dabei klar im Vorteil. Siewerden natürlich Fehler machen. Sie können jedoch aus den Fehlernlernen und so an ihren Aufgaben wachsen. Die zweite Interpretationdieses Prinzips läuft darauf hinaus, keine Ressourcen in toten Projek-ten zu verschwenden. Wenn nicht mehr gewonnen werden kann, soll-ten wir uns dies klar eingestehen und das Projekt lieber beenden.

Gezielte Experimente Gezielte Experimente: Jedes Mal, wenn wir eine Entscheidung fäl-len, könnte diese falsch sein. Um Risiken zu minimieren, versuchenwir, möglichst schnell darüber Klarheit zu erlangen, ob eine Entschei-dung falsch war. Gezielte Experimente können häufig diese Klarheitbringen. Die Experimente können sich sowohl auf das Softwaresystemals auch auf den Entwicklungsprozess beziehen. Im Softwaresystemnutzen wir Tests, um festzustellen, ob eine Entwurfsentscheidunggeeignet ist. Im Entwicklungsprozess führen die Projektmitglieder häu-fig Reviews über den Prozess durch, um zu beurteilen, ob eine Ent-scheidung richtig oder falsch war.

Offene, aufrichtige

Kommunikation

Offene, aufrichtige Kommunikation: Dieses Prinzip ist im Grundeeine Binsenweisheit. Natürlich können Softwareentwicklungsprojektenur dann funktionieren, wenn die Projektmitglieder offen und aufrich-tig sind. Leider ist dies in vielen Entwicklungsprojekten aufgrund vonÄngsten, Eitelkeiten und Rivalitäten nicht gegeben. Diese Defizite inder Kommunikation sind häufig verantwortlich für das Scheitern vonProjekten. Damit wird das Herstellen einer offenen und aufrichtigenKommunikation zu einer zentralen und sehr anspruchsvollen Auf-gabe.

91.2 Die XP-Prinzipien

Die Instinkte des Teams

nutzen,

nicht dagegen arbeiten

Die Instinkte des Teams nutzen, nicht dagegen arbeiten: Einige derXP-Techniken (z. B. Programmieren in Paaren, engl. Pair Program-ming) scheinen ungewöhnlich. Andererseits finden sich Entwickler seitjeher in Paaren zusammen, wenn sie eine besonders schwierige Funk-tionalität realisieren müssen. Das Programmieren in Paaren kann alsoals eine instinktive Technik von Softwareentwicklern verstanden wer-den. Dies gilt für die anderen XP-Techniken in ähnlicher Form. In derPraxis ist dieses Prinzip allerdings nicht einfach umzusetzen, da»Instinkt« und »angelerntes Verhalten« nur schwer zu trennen sind.So kann man in unerfahrenen XP-Teams gelegentlich beobachten, dassdas Programmieren in Paaren unter Zeitdruck ebenso aufgegeben wirdwie das Schreiben von Tests. Ist dies ein instinktives Verhalten oder fal-len die Entwickler zurück in angelernte Verhaltensweisen? Wenn dasganze Team jedoch gemeinsam der Meinung ist, dass etwas Unsinn ist,kann dies ein starkes Indiz dafür sein, dass es tatsächlich Unsinn ist.Diese Erkenntnis findet sich im folgenden Ausspruch wieder: »Wassich wie Quatsch anhört, ist häufig auch Quatsch.«

Verantwortung

übernehmen

Verantwortung übernehmen: Verantwortung soll nicht zugewie-sen, sondern übernommen werden. Wird einem Team die Verantwor-tung zugewiesen, ein unmögliches Projekt durchzuführen, wird dasmit Sicherheit katastrophale Auswirkungen auf die Motivation desTeams und damit auch auf die Projektergebnisse haben. Hat das Teamhingegen die Möglichkeit, Verantwortung zu übernehmen, so fühlensich die Entwickler auch verantwortlich für ihre Aufgaben. Das stei-gert die Motivation im Team und damit die Erfolgschancen des Projek-tes.

An örtliche Gegeben-

heiten anpassen

An örtliche Gegebenheiten anpassen: Es ist höchst unwahrschein-lich, dass sich XP in genau der von Kent Beck beschriebenen Form inIhrem Projekt einsetzen lässt. XP muss wahrscheinlich auf die lokalenGegebenheiten angepasst werden. Schließlich ist das primäre Ziel nichtdie exakte Nachahmung, sondern die erfolgreiche Projektdurchfüh-rung. Jede Anpassung von XP, die dieses Ziel unterstützt, ist gerecht-fertigt.

Mit leichtem Gepäck

reisen

Mit leichtem Gepäck reisen: Mit schwerem Gepäck kann man sichnicht schnell vorwärts bewegen. Daher sollte das »Marschgepäck«sorgfältig ausgewählt werden. Es sollte insbesondere aus wenigen ein-fachen, aber sehr nützlichen Dingen bestehen (z. B. Wiki-Web als Wis-sensbasis im Projekt). Dabei spielt die flexible Kombinierbarkeit dieserDinge eine wichtige Rolle.

Ehrliches MessenEhrliches Messen: Um den Entwicklungsprozess unter Kontrollezu haben, müssen Messungen unterschiedlichster Art vorgenommenwerden. So messen wir mit Komponententests z. B. das korrekte Funk-

1 Einleitung10

tionieren unserer Klassen. Alle diese Messungen haben jedoch nurdann einen Sinn, wenn das Team ehrlich misst. So sehen erfolgreicheTests zwar sehr schön aus. Wenn sie aber nur deshalb erfolgreich sind,weil die Entwickler alle nicht funktionierenden Teile auskommentierthaben, ist die Messung nicht mehr aussagekräftig. Sie kann sogarnegative Auswirkungen auf das Projekt haben, weil sie eine Sicherheitsuggeriert, die so nicht existiert.

1.3 Die XP-Techniken

Die vier XP-Werte und die 15 XP-Prinzipien werden durch 14 XP-Techniken3 unterstützt. Sie helfen den Entwicklern, sich »prinzipien-treu« zu verhalten. Die XP-Techniken sind im Überblick in Abbildung1–2 dargestellt. Sie werden in den folgenden Kapiteln detailliertbeschrieben.

Begriff »Technik« Im englischen Original heißen die Techniken »Practices«. Da imDeutschen der Begriff »Praktik« etwas anders belegt ist, haben wir unsdafür entschieden, den Begriff »Technik« zu verwenden. Damit gehtleider eine Konnotation verloren: »Practice« wie in »Best Practice«bezieht sich immer auch auf Erfahrungen, was beim deutschen Begriff»Technik« nicht automatisch der Fall ist.

3. In ursprünglichen XP-Manifest von Kent Beck sind zwölf XP-Technikenbeschrieben. Inzwischen haben sich Standup-Meetings und Retrospektiven alszusätzliche Techniken etabliert.

111.3 Die XP-Techniken

Eine wichtige Voraussetzung für die Wirksamkeit der XP-Technikenist eine flache Aufwandskurve (siehe Abb. 1–3). Traditionelle Entwick-lungsprozesse gehen häufig von einer steilen Aufwandskurve aus.Demnach wird die Realisierung einer Anforderung mit der Zeit expo-nentiell teurer, wenn die Anforderung erst spät entdeckt wird. Also istdie vollständige Analyse aller Anforderungen zu Projektbeginn eineunabdingbare Notwendigkeit. XP hingegen geht davon aus, dass derAufwand für die Umsetzung einer Anforderung im Wesentlichen unab-hängig vom Zeitpunkt der Umsetzung ist. Insbesondere geht XP davonaus, dass die Aufwandskurve über die Zeit nicht exponentiell wächst.Damit entfällt der Zwang, alle Anforderungen bereits zu Projekt-beginn zu kennen. Aus diesem Grund konzentriert sich XP stets auf dieaktuellen Aufgaben.

Der Verlauf der Aufwandskurve hängt wesentlich von der verwen-deten Technologie ab. So führen die traditionellen imperativen Program-miersprachen häufig zu steilen Aufwandskurven, während objektorien-tierte Technologien zumindest das Potenzial für flache Aufwands-kurven mitbringen. Ob diese flache Aufwandskurve in Projektentatsächlich erreicht werden kann, hängt wesentlich von der Verwendungder eingesetzten Technologien ab. Insbesondere sollte das DRY-Prinzip(DRY: Don’t repeat yourself) beachtet werden, wonach jede Kernideeim System an genau einer Stelle ausgedrückt werden soll.

Abb. 1–2:

XP-Techniken im

Überblick, angelehnt an

www.xprogramming.com

Kunde vor Ort(On-Site Customer)

Planungsspiel(Planning Game)

Metapher(Metaphor)

Nachhaltiges Tempo (Sustainable Pace)

Refactoring

Einfaches Design(Simple Design)

Programmieren in Paaren

(Pair Programming)

Retrospektive

Kurze Releasezyklen(Short Releases)

Programmierstandards(Coding Standards)

Fortlaufende Integration(Continuous Integration)

Gemeinsame Verantwortlichkeit

(Collective Ownership)

Standup-Meeting

Testen(Testing)

1 Einleitung12

Ist die Aufwandskurve nicht flach, können viele XP-Techniken nichtumgesetzt werden (z. B. Refactoring, einfaches Design, kurze Release-zyklen, fortlaufende Integration). Nach unserer Erfahrung sind objekt-orientierte Technologien geeignet, um eine flache Aufwandskurve zuerreichen. Sie geben jedoch keine Garantie. Wir müssen die Technolo-gien auch geeignet anwenden. Insbesondere sollten Kernabstraktionender Anwendung in überschaubar wenigen Systemkomponenten umge-setzt werden. Zusätzlich spielen die verfügbaren Tools eine großeRolle. Java mit Refactoring-Browser à la Eclipse lässt sich viel flexiblerhandhaben als C++ ohne Refactoring-Unterstützung.

1.3.1 Managementtechniken

Kunde vor Ort XP-Projekte sind stets an den fachlichen Anforderungen orientiert undbeziehen Anwender und Kunden4 ins Projekt mit ein (Kunde vor Ort,engl. On-Site Customer, siehe Abschnitt 2.1). Anwender und Kundengeben die fachlichen Anforderungen für das Projekt vor. Entwicklermüssen diese Anforderungen verstehen und bekommen von Anwen-

Steile Aufwandskurve

Zeit

Auf

wan

d je

Fea

ture

Flache Aufwandskurve

Zeit

Auf

wan

d je

Fea

ture

Abb. 1–3:

Steile vs. flache

Aufwandskurve

4. In XP wird keine Differenzierung zwischen Anwendern und Kunden vorge-nommen. Wir werden später argumentieren, dass eine solche Differenzierungin vielen Fällen notwendig und auch mit XP kompatibel ist.