Was sind dpunkt.ebooks? Was darf ich mit dem...

Was sind dpunkt.ebooks?Die dpunkt.ebooks sind Publikationen im PDF-Format, die es Ihnen erlauben, Inhalte am Bildschirm zu lesen, gezielt nach Informationen darin zu suchen und Seiten daraus auszudrucken. Sie benötigen zum Ansehen den Acrobat Reader (oder ein anderes adäquates Programm).

dpunkt.ebooks koennen Bücher (oder Teile daraus) sein, die es auch in gedruckter Form gibt (bzw. gab und die inzwischen vergriffen sind). (Einen entsprechenden Hinweis auf eine gedruckte Ausgabe finden Sie auf der entsprechenden E-Book-Seite.)

Es können aber auch Originalpublikationen sein, die es ausschließlich in E-Book-Form gibt. Diese werden mit der gleichen Sorgfalt und in der gleichen Qualität veröffentlicht, die Sie bereits von gedruckten dpunkt.büchern her kennen.

Was darf ich mit dem dpunkt.ebook tun?Die Datei ist nicht kopiergeschützt, kann also für den eigenen Bedarf beliebig kopiert werden. Es ist jedoch nicht gestattet, die Datei weiterzugeben oder für andere zugänglich in Netzwerke zu stellen. Sie erwerben also eine Ein-Personen-Nutzungslizenz.

Wenn Sie mehrere Exemplare des gleichen E-Books kaufen, erwerben Sie damit die Lizenz für die entsprechende Anzahl von Nutzern.

Um Missbrauch zu reduzieren, haben wir die PDF-Datei mit einem Wasserzeichen (Ihrer E-Mail-Adresse und Ihrer Transaktionsnummer) versehen.

Bitte beachten Sie, dass die Inhalte der Datei in jedem Fall dem Copyright des Verlages unterliegen.

Wie kann ich dpunkt.ebooks kaufen und bezahlen? Legen Sie die E-Books in den Warenkorb. (Aus technischen Gruenden, können im Warenkorb nur gedruckte Bücher ODER E-Books enthalten sein.)

Downloads und E-Books können sie bei dpunkt per Paypal bezahlen. Wenn Sie noch kein Paypal-Konto haben, können Sie dieses in Minutenschnelle einrichten (den entsprechenden Link erhalten Sie während des Bezahlvorgangs) und so über Ihre Kreditkarte oder per Überweisung bezahlen.

Wie erhalte ich das dpunkt.ebook?Sobald der Bestell- und Bezahlvorgang abgeschlossen ist, erhalten Sie an die von Ihnen angegebene Adresse eine Bestätigung von Paypal, sowie von dpunkt eine E-Mail mit den Downloadlinks für die gekauften Dokumente sowie einem Link zu einer PDF-Rechnung für die Bestellung.

Die Links sind zwei Wochen lang gültig. Die Dokumente selbst sind mit Ihrer E-Mail-Adresse und Ihrer Transaktionsnummer als Wasserzeichen versehen.

Wenn es Probleme gibt?Bitte wenden Sie sich bei Problemen an den dpunkt.verlag: Frau Karin Riedinger (riedinger (at) dpunkt.de bzw. fon 06221-148350).

Agile Softwareentwicklung

Dipl.-Inform. Henning Wolf ist Geschäftsführer der it-agile GmbH in Hamburg, bei der er auch als Agiler Senior-Berater tätig ist. Er lei-tet und begleitet seit 1999 agile Projekte. Neben agilen Methoden und Vertragsmodellen gehören agiles Projektmanagement und Controlling, Aufwandsschätzungen und agile Organisationen zu seinen Arbeitsschwerpunkten. Im Rahmen seiner Beratertätigkeit veröffentlicht er Artikel und hält Vorträge und Schulungen zu die-sen und weiteren Themen.

Dr. Wolf-Gideon Bleek leitet für die Firma blueCarat AG die Bera-tung im Bereich Norddeutschland. Er führt seit 1999 agile Projekte durch und berät Organisationen beim Einsatz agiler Softwareent-wicklungsprozesse. Zu seinen Schwerpunkten gehören neben agi-len Entwicklungsmethoden Softwareinfrastrukturen, Software-architekturen, Open-Source-Software und Softwarequalität. Er ist Autor zahlreicher Artikel und Konferenzbeiträge. An der Universität Hamburg und der IT Universität Kopenhagen gibt er Lehrveranstal-tungen zu Softwarearchitektur und Softwareentwicklung.

Henning Wolf · Wolf-Gideon Bleek

Agile Softwareentwicklung

Werte, Konzepte und Methoden

2., aktualisierte und erweiterte Auflage

Henning Wolf [email protected]

Wolf-Gideon Bleek [email protected]

Lektorat: Christa Preisendanz Copy-Editing: Ursula Zimpfer, Herrenberg Herstellung: Nadine Thiele Umschlaggestaltung: Helmut Kraus, www.exclam.de Druck und Bindung: Media-Print Informationstechnologie, Paderborn

Bibliografische Information der Deutschen NationalbibliothekDie Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN 978-3-89864-862-2

2., aktualisierte und erweiterte Auflage 2011 Copyright © 2011 dpunkt.verlag GmbH Ringstraße 19 B 69115 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

Danke!Erst einmal möchten wir uns bei allen Lesern der 1. Auflage dieses Buches bedanken, die es überhaupt erst ermöglicht haben, dass wir eine 2., aktualisierte und erweiterte Auflage schreiben konnten. Wir haben uns sehr gefreut zu hören, dass die 1. Auflage in kurzer Zeit ver-kauft war.

Seit der Fertigstellung der Texte zur 1. Auflage haben wir natürlich in Projekten und der täglichen Arbeit weitere Erfahrungen in agiler Projektarbeit gesammelt. Wir haben dazugelernt, in welchen Teams welche Praktiken gut funktionieren und wann in einem Team Schwie-rigkeiten mit einer Methode aufkommen.

Rückmeldungen

berücksichtigt

In den vergangenen Monaten haben uns auch immer wieder Rück-meldungen zum Buch erreicht, und wir haben diese ausgewertet und bei der Überarbeitung der Kapitel berücksichtigt.

Uns hat der Austausch mit anderen Anwendern agiler Praktiken und Methoden bestärkt, den Zuschnitt des Buches im Groben zu belassen, wie er ist. Gleichzeitig haben wir die Erfahrungen aus unse-ren aktuellen Projekten aufgegriffen und deswegen einige Aspekte (bei-spielsweise zur Klärung von Anforderungen, zum Messen von Fort-schritt und zum Schätzen) stärker herausgearbeitet.

Feedback ist ja genau eines der wesentlichen agilen Mittel, um sich zu verbessern. Ein sinnvoller Einsatz (nicht nur beim Bücher- und Soft-wareschreiben) setzt aber voraus, dass man sich von klassischen Grundannahmen verabschiedet wie z. B. einer möglichst langen und möglichst exakten Vorhersagbarkeit, die nur mit möglichst geringen Änderungen machbar ist. Dabei lehrt uns die Erfahrung, dass es mit der agilen Vorhersagbarkeit gar nicht so schlecht bestellt ist, sie spielt sich nur eben auf einer weniger detaillierten Ebene ab.

Software-KanbanEine wesentliche Ergänzung in unserem Kapitel über ausgewählte agile Methoden ist Software-Kanban. Wir sind der Meinung, dass diese Methode stark an Bedeutung gewonnen hat und eine Bereiche-

Vorwortvi

rung für viele Softwareentwicklungsprojekte darstellt. Für den Text dieses Kapitels möchten wir uns bei unserem Kollegen Arne Roock bedanken!

Auch zu dieser Auflage freuen wir uns natürlich weiterhin über Ihr Feedback: Wie gefällt Ihnen dieses Buch? Was hat Sie besonders ange-sprochen? Welche Teile gefallen Ihnen nicht? Was hätten Sie sich zusätzlich gewünscht? Dafür schon einmal vielen Dank im Voraus!

Henning Wolf und Wolf-Gideon Bleek

Hamburg, im August 2010

Blogs der Autoren:

www.henningwolf.de

www.wolfgideonbleek.de

vii

Vorwort zur 1. Auflage

Seit Ende der 90er-Jahre agil

Wir beschäftigen uns seit vielen Jahren in ganz unterschiedlichen Kon-texten mit agiler Softwareentwicklung. Begonnen haben wir gemein-sam 1998 als Mitarbeiter des Fachbereichs Informatik an der Universi-tät Hamburg damit, in studentischen Projekten Praktiken des eXtreme Programming einzuführen. Es blieb aber bei Weitem nicht bei studen-tischen Projekten. Seit Ende 1999 entwickeln wir professionell Soft-ware nach agilem Vorgehen. Dabei haben wir in Projekten ganz unter-schiedliche Rollen wahrnehmen dürfen: Entwickler, Kundenberater, Softwarearchitekt, Methodenberater, XP-Coach, ScrumMaster, Pro-jektleiter und Kunde. Auf unseren hierdurch gesammelten Erfahrun-gen baut dieses Buch auf.

Warum wir dieses Buch

geschrieben haben

Für uns stellt agile Softwareentwicklung genau die pragmatische Herangehensweise an Softwareentwicklungsprojekte dar, die wir uns immer gewünscht haben. Dabei ist es für uns persönlich nicht ohne Bedeutung, dass wir als Entwickler mit der agilen Methode eXtreme Programming (XP) begonnen haben. XP konzentriert sich eben auf die für uns wichtigste und tatsächlich wertschaffende Tätigkeit in Soft-wareentwicklungsprojekten: das Programmieren. Aber zu erfolgrei-chen Projekten gehört mehr als nur das Programmieren. Man braucht einen organisatorischen Rahmen, Vereinbarungen mit dem Manage-ment und Kommunikationsmöglichkeiten mit dem Kunden. Besonders wichtig aber für pragmatische Menschen ist es, dass das Vorgehen den aktuellen Gegebenheiten an Projekt, Team und Umfeld angepasst wer-den kann. Deshalb reicht es eben nicht aus, nur eine agile Methode zu kennen. Wir wollen mit diesem Buch erreichen, dass Sie erkennen, was hinter allen agilen Methoden an gemeinsamen Vorstellungen steckt und wie auch Sie flexibel Ihre agile Methode für Ihre Projektkonstella-tion finden können.

Vorwort zur 1. Auflageviii

Danke Unser herzlicher Dank gilt u. a. vielen unserer Kollegen, Christa Preisendanz vom dpunkt.verlag und den Reviewern. Letzteren danken wir auch und gerade dafür, dass Sie unsere erste Buchversion und -strukturierung so wenig mochten. Wir sind mit der jetzt vorliegenden Buchstruktur selbst ebenfalls viel zufriedener. Allen Reviewern dieser zweiten Version danken wir für die zahlreichen konkreten und kon-struktiven Hinweise zur Verbesserung. Sie sind nahezu alle in dieses Buch eingeflossen. Von den Reviewern sind uns namentlich bekannt Jutta Eckstein und Johannes Link, bei denen wir uns hiermit herzlich bedanken wollen.

Stefan Roock gilt unser Dank für lange Jahre agiler Zusammenar-beit und für Textteile im Überblickskapitel, insbesondere zu XP und FDD, und viele wichtige Hinweise zum Kapitel über Kontraindikation und Indikation für agile Softwareentwicklung.

Wir wünschen uns, dass dieses Buch Ihren Einstieg in die agile Softwareentwicklung erleichtert und dass Sie nach der Lektüre eben-falls agil vorgehen wollen (und können).

Wir haben dieses Buch für Sie geschrieben und hoffen, dass es Ihnen gefällt. Für Anregungen, weitere Diskussionen, Fragen und Rückkopplungen zu diesem Buch oder Ihre Erfahrungen mit agiler Softwareentwicklung sind wir offen und freuen uns schon auf Ihre E-Mails.

Wolf-Gideon Bleek und Henning Wolf

Hamburg, im Februar 2008

ix

Inhaltsverzeichnis

1 Einleitung 1

1.1 Unser Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Unser Vorgehen in diesem Buch . . . . . . . . . . . . . . . . . . . . . 2

1.3 Der Aufbau dieses Buches . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.4 Das Buch einsetzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Einführung 7

2.1 Unsere Sicht auf Softwareentwicklung . . . . . . . . . . . . . . . . 8

2.2 Werte hinter agiler Softwareentwicklung . . . . . . . . . . . . . 10

2.3 Das agile Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 Grundsätzliches agiles Vorgehen . . . . . . . . . . . . . . . . . . . . 16

2.5 Begriffsklärung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.6 Weiter im Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Management, Team, Entwicklung: Wie lernen wir kontinuierlich? 21

3.1 Agile Sichtweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 Agile Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3 Bezüge zu anderen agilen Praktiken . . . . . . . . . . . . . . . . . 24

3.4 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4 Management und Team: Wie schätzen wir Aufwände? 25


4.2 Agile Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26


4.4 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Inhaltsverzeichnisx

5 Management: Wie schreiben wir Anforderungen auf? 37


5.2 Agile Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38


5.4 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6 Management: Mit welchen Anforderungen fangen wir an? 45


6.2 Agile Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46


6.4 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7 Management: Wie organisieren wir uns zeitlich? 51


7.2 Agile Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52


7.4 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

8 Management: Wer entscheidet beim Kunden? 57


8.2 Agile Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58


8.4 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

9 Management: Wie können Details geklärt werden? 63


9.2 Agile Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64


9.4 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

xiInhaltsverzeichnis

10 Team: Wie transportieren wir Wissen zwischen allen Teammitgliedern? 69


10.2 Agile Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70


10.4 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

11 Team: Wie und wo setzt sich ein Team zusammen? 77


11.2 Agile Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78


11.4 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

12 Entwicklung: Wer darf an welchem Quelltext Änderungen vornehmen? 81


12.2 Agile Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82


12.4 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

13 Team: Wer macht eigentlich gerade was? 87


13.2 Agile Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88


13.4 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

14 Team: Wo, wann und wie diskutieren wir Design und Architektur? 93


14.2 Agile Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

14.2.1 Quick Design Sessions . . . . . . . . . . . . . . . . . . . . . 9614.2.2 Testgetriebener Entwurf . . . . . . . . . . . . . . . . . . . 9814.2.3 Design und Architektur bei Feature

Driven Development . . . . . . . . . . . . . . . . . . . . . 10014.3 Bezüge zu anderen agilen Praktiken . . . . . . . . . . . . . . . . 102

14.4 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Inhaltsverzeichnisxii

15 Entwicklung: Wie können technische Details geklärt werden? 103

15.1 Agile Sichtweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

15.2 Agile Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

15.3 Bezüge zu anderen agilen Praktiken . . . . . . . . . . . . . . . . 106

15.4 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

16 Management: Wie wird Projektfortschritt ehrlich messbar? 107


16.2 Agile Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108


16.4 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

17 Management: Wann ist eine Anforderung erledigt? 115


17.2 Agile Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118


17.4 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

18 Entwicklung: Wie häufig liefern wir Software aus? 121


18.2 Agile Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122


18.4 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

19 Entwicklung: Wie häufig integrieren wir unsere Entwicklung? 127


19.2 Agile Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129


19.4 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

xiiiInhaltsverzeichnis

20 Entwicklung: Wie halten wir die Qualität im Sinne von Wartbarkeit hoch? 133


20.2 Agile Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135


20.4 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

21 Management: Wie gehen wir mit Anforderungsmengen um? 137


21.2 Agile Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

21.2.1 Product Backlog vs. Sprint Backlog . . . . . . . . . . 13821.2.2 Gruppierung über Feature-Sets (FDD) . . . . . . . . 13921.2.3 Speziallösung für Festpreisprojekte . . . . . . . . . . 14021.2.4 Umgehen mit widersprüchlichen

Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . 14121.3 Bezüge zu anderen agilen Praktiken . . . . . . . . . . . . . . . . 142

21.4 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

22 Management: Wer hilft uns bei Problemen mit dem agilen Vorgehen? 145


22.2 Agile Lösung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146


22.4 Übungsaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

23 Ausgewählte agile Methoden 149

23.1 eXtreme Programming . . . . . . . . . . . . . . . . . . . . . . . . . . 149

23.1.1 Die fünf Werte des eXtreme Programming . . . . 15023.1.2 Die 14 Prinzipien des eXtreme Programming . . 15123.1.3 Die 13 Primärpraktiken . . . . . . . . . . . . . . . . . . 15323.1.4 Die 11 Folgepraktiken . . . . . . . . . . . . . . . . . . . . 15623.1.5 Rollen in eXtreme Programming . . . . . . . . . . . . 15923.1.6 Projektablauf bei eXtreme Programming . . . . . 160

23.2 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

23.2.1 Die Rollen bei Scrum . . . . . . . . . . . . . . . . . . . . 16123.2.2 Projektablauf bei Scrum . . . . . . . . . . . . . . . . . . 162

Inhaltsverzeichnisxiv

23.3 Feature Driven Development . . . . . . . . . . . . . . . . . . . . . . 164

23.3.1 Erstelle das Gesamtmodell . . . . . . . . . . . . . . . . . 16523.3.2 Erstelle die Feature-Liste . . . . . . . . . . . . . . . . . . 16523.3.3 Plane je Feature . . . . . . . . . . . . . . . . . . . . . . . . . 16623.3.4 Entwirf je Feature . . . . . . . . . . . . . . . . . . . . . . . 16623.3.5 Entwickle je Feature . . . . . . . . . . . . . . . . . . . . . . 16623.3.6 Gesamtüberblick über FDD . . . . . . . . . . . . . . . . 16723.3.7 Diskussion: Ist FDD agil? . . . . . . . . . . . . . . . . . . 167

23.4 Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

23.4.1 Prinzipien von Kanban . . . . . . . . . . . . . . . . . . . . 17023.4.2 Kanban als Change-Management-Methode . . . . 173

24 Kontraindikation und Indikation 175

24.1 Kontraindikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

24.1.1 Kontraindikationen im Bereich des Kunden . . . . 17624.1.2 Kontraindikationen im Bereich

der Entwickler . . . . . . . . . . . . . . . . . . . . . . . . . . 18024.1.3 Kontraindikationen im Bereich

von Technologien . . . . . . . . . . . . . . . . . . . . . . . 18124.2 Indikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

24.2.1 Indikationen im Bereich des Kunden . . . . . . . . . 18324.2.2 Indikationen im Bereich der Entwickler . . . . . . . 18424.2.3 Indikationen im Bereich von Technologien . . . . 185

24.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

25 Rückblick 187

Anhang

A Übersetzungen 189

Literaturverzeichnis 193

Index 199

1

1 Einleitung

Dieses Buch wendet sich an alle, die sich für agile Softwareentwicklung interessieren. Einleitend möchten wir unser mit diesem Buch verbun-denes Ziel, unseren Erfahrungshintergrund, das dem Buch zugrunde liegende Vorgehen und den von uns für das Thema gewählten Aufbau des Buches vorstellen.

1.1 Unser Ziel

Wir wollen Ihnen näher bringen, was agile Softwareentwicklung aus-macht. Dabei wollen wir bewusst darauf verzichten, Ihnen das agile Vorgehen an einer konkreten agilen Methode wie eXtreme Program-ming (XP), Scrum, Feature Driven Development (FDD) oder Software-Kanban vorzustellen.

Nach unserer Erfahrung beantwortet nämlich keine agile Methode alle Fragen, die sich bei der Softwareentwicklung methodisch stellen. Wir können auch in diesem Buch nicht alle Fragen beantworten, wol-len Ihnen aber die agile Denkweise so weit näher bringen, dass Sie offen bleibende Fragen selbst in einem agilen Sinne beantworten kön-nen.

Es gibt noch einen weiteren Grund, warum wir uns für diese Ein-führung von den konkreten Methoden gelöst haben: In unseren Pro-jekten setzen wir eine Vielzahl agiler Praktiken (im Sinne von »Best Practices«) ein und kombinieren nach Projektbedarf. Wir haben ein ähnliches Vorgehen von einer Vielzahl anderer Projekte gehört und vermuten deshalb, dass Sie es in Ihren Projekten ebenso machen wol-len und werden.

Trotzdem bietet Ihnen dieses Buch eine kleine Auswahl bekannter Vertreter agiler Methoden. Eine davon kann der Startpunkt werden für Ihre eigenen agilen Projekte.

1 Einleitung2

1.2 Unser Vorgehen in diesem Buch

Einführung Nach dieser kurzen Einleitung wollen wir Ihnen im zweiten Kapitel eine Einführung in das agile Vorgehen geben. Wir stellen das agile Manifest und die Grundwerte aller agilen Methoden vor. Gepaart mit den dort eingeführten grundlegenden agilen Herangehensweisen haben Sie schon das nötige Handwerkszeug, um agil vorzugehen.

Je Fragestellung

ein Kapitel

Ab dem dritten Kapitel orientieren wir uns dann an unterschiedli-chen Fragestellungen, die sich bei der Softwareentwicklung ergeben. Wir wollen jeweils ausgehend von einem konkreten Problem bei der Softwareentwicklung zeigen, wie Sie mit agiler Herangehensweise und Betrachtung zu einer Lösung kommen. Diese Lösungen finden sich so oder ähnlich in agilen Methoden wieder, und wir haben sie selbst in Projekten beobachtet oder eingesetzt.

Ausgewählte agile

Methoden

Die zwei aus unserer Sicht wichtigsten Vertreter agiler Methoden stellen wir Ihnen in Kapitel 23 Ausgewählte agile Methoden vor:

■ Extreme Programming (XP) als eine recht umfassende und im Bereich der konkreten Entwicklung auf Design- und Programmier-ebene starke Entwicklungsmethode.

■ Scrum als eine vor allem auf agiles Projektmanagement und -orga-nisation abgestellte Methode, die bei Weitem nicht nur für Soft-wareentwicklungsprojekte eingesetzt werden kann. Sie bietet aller-dings bezogen auf Softwareentwicklung für Umsetzung, Design und Programmierung keine Handlungsanleitung. Sie werden erkennen, dass XP und Scrum gut kombinierbar sind.

Zusätzlich betrachten wir mit Feature Driven Development (FDD) eine agile Methode, die gezielt für Festpreiskonstellationen entwickelt wurde und durch ihr Rollenmodell und ihre Hierarchien auf den ers-ten Blick klassisch daherkommt, aber trotzdem den agilen Grundwer-ten und Grundsätzen genügt. Gerade weil FDD nicht auf selbstorgani-sierte Teams setzt, ist es unserer Einschätzung nach für viele Organisationen interessant und bietet Ihnen eine sinnvolle agile Alter-native zu den am meisten verwendeten Vertretern XP und Scrum.

Mit Software-Kanban beschreiben wir zudem noch eine Methode, die direkt aus der leichtgewichtigen Produktion (Lean Production) ent-stammt. Kanban interpretiert das agile Manifest anders als Scrum oder XP. Als Methode ist Kanban für all jene Kontexte besonders gut geeig-net, in denen schnell und häufig geliefert werden soll. Deshalb ist Kan-ban eine hervorragende Methode zur Organisation der Betriebsfüh-rung oder Wartung, aber auch in Softwareentwicklungskontexten gut einsetzbar.

31.3 Der Aufbau dieses Buches

Kontraindikation und

Indikation

Sind agile Methoden für alle Projekte geeignet? Für wen ist welche agile Methode am besten geeignet? Diesen Fragen gehen wir in Kapitel 24 Kontraindikation und Indikation nach.

Im letzten Kapitel fassen wir kurz zusammen und blicken gemein-sam auf die Inhalte dieses Buches zurück. Außerdem wollen wir Ihnen einen Ausblick geben, wie es für Sie mit agiler Softwareentwicklung weitergehen kann.

ÜbungsaufgabenZur Vertiefung des Stoffes haben wir zu einigen Themen Übungs-aufgaben formuliert, die Sie am Ende des jeweiligen Kapitels finden.

1.3 Der Aufbau dieses Buches

Nicht nach Methoden

strukturiert

Für den Aufbau des Buches haben wir uns bewusst gegen eine Struktu-rierung nach den vorgestellten Methoden entschieden, denn dies widerspricht den gesammelten Erfahrungen: In den uns bekannten agi-len Projekten wurde und wird nicht streng nach einer agilen Methode vorgegangen.

PerspektivenDer Erfahrung nach sind im Projekt die unterschiedlichen Perspek-tiven viel bestimmender. Wir unterscheiden deshalb bei der Vorstel-lung der agilen Praktiken zwischen den Perspektiven Team, Manage-ment und Entwicklung. Nach diesen haben wir die agilen Praktiken sortiert und führen sie teilweise kombiniert, aber unabhängig von ihrer Zuordnung zu einer agilen Methode ein.

Zyklischer AufbauWir gehen beim Aufbau des Buches zyklisch vor; so, wie es in Pro-jekten nach agilen Vorgehensweisen ebenfalls üblich ist. Das hat die Reihenfolge der Kapitel bestimmt. Wir erkunden die agilen Praktiken, indem wir immer wieder auf die drei Perspektiven eingehen. Die von den Methoden angebotenen Praktiken fließen dabei als Lösungsbau-steine ein.

1.4 Das Buch einsetzen

Sie können verschiedene Gründe haben, sich mithilfe dieses Buches mit agilen Methoden vertraut zu machen. Wir möchten an dieser Stelle darauf eingehen, wie das Ihren Umgang mit dem Buch und vor allem die Lesereihenfolge der Kapitel beeinflussen könnte. Dabei können wir uns insbesondere drei Kontexte vorstellen, in denen wir dieses Buch vorwiegend eingesetzt sehen: Selbststudium, Projekte in Industriekon-texten und Lehrveranstaltungen an Hochschulen.

Der einfachste und sicherlich naheliegendste Weg verläuft entlang der normalen Kapitelreihenfolge. Diese ist von uns bereits so vorgege-ben, dass Sie sich schrittweise und zyklisch den Praktiken der agilen

1 Einleitung4

Methoden nähern. Wir haben bei der Anordnung der Kapitel darauf geachtet, dass jedes Kapitel für sich genommen einzeln gelesen werden kann. Notwendige Verweise auf andere Kapitel sind explizit aufge-führt, und am Ende jedes Kapitels sind die Bezüge zu anderen agilen Praktiken angegeben.

Für das Selbststudium Das Buch eignet sich auch zum Selbststudium; wir raten Ihnen hier zu einem realen Projekt, in dem Sie sich mit agilen Praktiken auseinan-dersetzen. Die Praktiken und die damit verbundene Haltung sind leich-ter nachzuvollziehen, wenn sie in einer konkreten Projektsituation praktiziert werden. Das mag aber nicht immer möglich sein.

Arbeit im Industriekontext Für die Arbeit in einem Industriekontext empfehlen wir ein reales Projekt, in dem Sie agile Methoden einsetzen wollen. Wenn es Ihr ers-ter Kontakt mit agilen Methoden ist, sollten Sie das Projekt sorgfältig auswählen, sodass es Ihnen Freiräume für das Experimentieren mit einer neuen Vorgehensweise erlaubt. Wir würden Ihnen darüber hin-aus vorschlagen, dass Sie sich zumindest zu einem späteren Zeitpunkt einen Berater hinzuziehen, der Ihnen bei eventuellen Problemen hilft.

Die Reihenfolge der Kapitel unterstellt, dass Sie frisch mit dem Projekt anfangen. Genauso, wie sich das Projekt schrittweise vor Ihnen mit seinen Facetten entfaltet, werden die agilen Praktiken eingeführt und adressieren weitere neue Details und Herausforderungen. Sie kön-nen daraufhin nach einigen Kapiteln überlegen, ob es sinnvoller ist, ein späteres Kapitel direkt auszuwählen, weil Sie gerade auf die in der Überschrift genannte Frage in Ihrem Projekt gestoßen sind. Sollten Sie mit dem Entwicklungsprojekt bereits begonnen haben, raten wir Ihnen, das Buch erst einmal vollständig zu lesen, damit Sie abschätzen können, wie Sie die Vorgehensweise im laufenden Projekt wechseln.

Lehrveranstaltungen an

Hochschulen

Für Lehrveranstaltungen an Hochschulen empfehlen wir eine pro-jektartige Veranstaltungsform. Wir wissen, dass insbesondere Soft-wareentwicklungsmethoden gerne im Rahmen von Vorlesungen unter-richtet werden. Aus unserer eigenen Erfahrung lässt sich aber sagen, dass die Inhalte dabei nur schwer vermittelbar sind und wenig Ein-druck hinterlassen. Gute Rückmeldung haben wir dagegen in Projek-ten oder Praktika erhalten, in denen sich die Studierenden aktiv und bezogen auf eine Problemstellung selbst mit den Praktiken beschäfti-gen mussten.

Die Reihenfolge der Kapitel ist bereits eine brauchbare Reihen-folge für die Auseinandersetzung mit den agilen Themen im Rahmen einer Lehrveranstaltung. Darüber hinaus ist es naheliegend, dass die Teilnehmer in einem Projekt Rollen einnehmen. Diese Rollen bringen bestimmte Perspektiven mit sich, durch die sich wiederum Schwer-punkte ergeben. Die Studierenden werden deshalb die Texte so lesen,

51.4 Das Buch einsetzen

wie sie ihnen direkt Fragen im Projektkontext aus ihrer Perspektive beantworten. Genau das ist beim Aufbau des Buches beabsichtigt gewesen.

Und sonst?Sollten Sie kein konkretes Projekt haben, bietet sich die vorgege-bene Kapitelreihenfolge an, denn die Themen und die damit verbunde-nen Praktiken ergeben in der vorliegenden Reihenfolge einen organi-schen Zusammenhang. Sind Sie in der glücklichen Lage, an einem konkreten Projekt zu arbeiten, empfehlen wir Ihnen dieselbe Lesestra-tegie wie bei Industrieprojekten.

1 Einleitung6

Was sind dpunkt.ebooks? Was darf ich mit dem...

Documents

Transcript of Was sind dpunkt.ebooks? Was darf ich mit dem...