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 leitet 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 diesen und weiteren Themen.
Dr. Wolf-Gideon Bleek leitet für die Firma blueCarat AG die Beratung im Bereich Norddeutschland. Er führt seit 1999 agile Projekte durch und berät Organisationen beim Einsatz agiler Softwareentwicklungsprozesse. Zu seinen Schwerpunkten gehören neben agilen Entwicklungsmethoden Softwareinfrastrukturen, Softwarearchitekturen, 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 Lehrveranstaltungen zu Softwarearchitektur und Softwareentwicklung.
Werte, Konzepte und Methoden
2., aktualisierte und erweiterte Auflage
Henning Wolf
henning.wolf@it-agile.de
Wolf-Gideon Bleek
kontakt@wolf-gideon-bleek.de
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 Nationalbibliothek
Die 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
Danke!Erst einmal möchten wir uns bei allen Lesern der 1. Auflage dieses Buches bedanken, die es übesrhaupt 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 verkauft 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 Schwierigkeiten mit einer Methode aufkommen.
Rückmeldungen berücksichtigtIn den vergangenen Monaten haben uns auch immer wieder Rückmeldungen 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 unseren aktuellen Projekten aufgegriffen und deswegen einige Aspekte (beispielsweise zur Klärung von Anforderungen, zum Messen von Fortschritt 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 Softwareschreiben) 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 Bereicherung 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 angesprochen? 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
Seit Ende der 90er-Jahre agilWir beschäftigen uns seit vielen Jahren in ganz unterschiedlichen Kontexten mit agiler Softwareentwicklung. Begonnen haben wir gemeinsam 1998 als Mitarbeiter des Fachbereichs Informatik an der Universität Hamburg damit, in studentischen Projekten Praktiken des eXtreme Programming einzuführen. Es blieb aber bei Weitem nicht bei studentischen Projekten. Seit Ende 1999 entwickeln wir professionell Software nach agilem Vorgehen. Dabei haben wir in Projekten ganz unterschiedliche Rollen wahrnehmen dürfen: Entwickler, Kundenberater, Softwarearchitekt, Methodenberater, XP-Coach, ScrumMaster, Projektleiter und Kunde. Auf unseren hierdurch gesammelten Erfahrungen baut dieses Buch auf.
Warum wir dieses Buch geschrieben habenFü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 Softwareentwicklungsprojekten: das Programmieren. Aber zu erfolgreichen Projekten gehört mehr als nur das Programmieren. Man braucht einen organisatorischen Rahmen, Vereinbarungen mit dem Management 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 werden 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 Projektkonstellation finden können.
DankeUnser 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 konstruktiven 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 Zusammenarbeit 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 ebenfalls 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
1 Einleitung
1.1 Unser Ziel
1.2 Unser Vorgehen in diesem Buch
1.3 Der Aufbau dieses Buches
1.4 Das Buch einsetzen
2 Einführung
2.1 Unsere Sicht auf Softwareentwicklung
2.2 Werte hinter agiler Softwareentwicklung
2.3 Das agile Manifest
2.4 Grundsätzliches agiles Vorgehen
2.5 Begriffsklärung
2.6 Weiter im Text
3 Management, Team, Entwicklung: Wie lernen wir kontinuierlich?
3.1 Agile Sichtweise
3.2 Agile Lösung
3.3 Bezüge zu anderen agilen Praktiken
3.4 Übungsaufgaben
4 Management und Team: Wie schätzen wir Aufwände?
4.1 Agile Sichtweise
4.2 Agile Lösung
4.3 Bezüge zu anderen agilen Praktiken
4.4 Übungsaufgaben
5 Management: Wie schreiben wir Anforderungen auf?
5.1 Agile Sichtweise
5.2 Agile Lösung
5.3 Bezüge zu anderen agilen Praktiken
5.4 Übungsaufgaben
6 Management: Mit welchen Anforderungen fangen wir an?
6.1 Agile Sichtweise
6.2 Agile Lösung
6.3 Bezüge zu anderen agilen Praktiken
6.4 Übungsaufgaben
7 Management: Wie organisieren wir uns zeitlich?
7.1 Agile Sichtweise
7.2 Agile Lösung
7.3 Bezüge zu anderen agilen Praktiken
7.4 Übungsaufgaben
8 Management: Wer entscheidet beim Kunden?
8.1 Agile Sichtweise
8.2 Agile Lösung
8.3 Bezüge zu anderen agilen Praktiken
8.4 Übungsaufgaben
9 Management: Wie können Details geklärt werden?
9.1 Agile Sichtweise
9.2 Agile Lösung
9.3 Bezüge zu anderen agilen Praktiken
9.4 Übungsaufgaben
10 Team: Wie transportieren wir Wissen zwischen allen Teammitgliedern?
10.1 Agile Sichtweise
10.2 Agile Lösung
10.3 Bezüge zu anderen agilen Praktiken
10.4 Übungsaufgaben
11 Team: Wie und wo setzt sich ein Team zusammen?
11.1 Agile Sichtweise
11.2 Agile Lösung
11.3 Bezüge zu anderen agilen Praktiken
11.4 Übungsaufgaben
12 Entwicklung: Wer darf an welchem Quelltext Änderungen vornehmen?
12.1 Agile Sichtweise
12.2 Agile Lösung
12.3 Bezüge zu anderen agilen Praktiken
12.4 Übungsaufgaben
13 Team: Wer macht eigentlich gerade was?
13.1 Agile Sichtweise
13.2 Agile Lösung
13.3 Bezüge zu anderen agilen Praktiken
13.4 Übungsaufgaben
14 Team: Wo, wann und wie diskutieren wir Design und Architektur?
14.1 Agile Sichtweise
14.2 Agile Lösung
14.2.1 Quick Design Sessions
14.2.2 Testgetriebener Entwurf
14.2.3 Design und Architektur bei Feature Driven Development
14.3 Bezüge zu anderen agilen Praktiken
14.4 Übungsaufgaben
15 Entwicklung: Wie können technische Details geklärt werden?
15.1 Agile Sichtweise
15.2 Agile Lösung
15.3 Bezüge zu anderen agilen Praktiken
15.4 Übungsaufgaben
16 Management: Wie wird Projektfortschritt ehrlich messbar?
16.1 Agile Sichtweise
16.2 Agile Lösung
16.3 Bezüge zu anderen agilen Praktiken
16.4 Übungsaufgaben
17 Management: Wann ist eine Anforderung erledigt?
17.1 Agile Sichtweise
17.2 Agile Lösung
17.3 Bezüge zu anderen agilen Praktiken
17.4 Übungsaufgaben
18 Entwicklung: Wie häufig liefern wir Software aus?
18.1 Agile Sichtweise
18.2 Agile Lösung
18.3 Bezüge zu anderen agilen Praktiken
18.4 Übungsaufgaben
19 Entwicklung: Wie häufig integrieren wir unsere Entwicklung?
19.1 Agile Sichtweise
19.2 Agile Lösung
19.3 Bezüge zu anderen agilen Praktiken
19.4 Übungsaufgaben
20 Entwicklung: Wie halten wir die Qualität im Sinne von Wartbarkeit hoch?
20.1 Agile Sichtweise
20.2 Agile Lösung
20.3 Bezüge zu anderen agilen Praktiken
20.4 Übungsaufgaben
21 Management: Wie gehen wir mit Anforderungsmengen um?
21.1 Agile Sichtweise
21.2 Agile Lösung
21.2.1 Product Backlog vs. Sprint Backlog
21.2.2 Gruppierung über Feature-Sets (FDD)
21.2.3 Speziallösung für Festpreisprojekte
21.2.4 Umgehen mit widersprüchlichen Anforderungen
21.3 Bezüge zu anderen agilen Praktiken
21.4 Übungsaufgaben
22 Management: Wer hilft uns bei Problemen mit dem agilen Vorgehen?
22.1 Agile Sichtweise
22.2 Agile Lösung
22.3 Bezüge zu anderen agilen Praktiken
22.4 Übungsaufgaben
23 Ausgewählte agile Methoden
23.1 eXtreme Programming
23.1.1 Die fünf Werte des eXtreme Programming
23.1.2 Die 14 Prinzipien des eXtreme Programming
23.1.3 Die 13 Primärpraktiken
23.1.4 Die 11 Folgepraktiken
23.1.5 Rollen in eXtreme Programming
23.1.6 Projektablauf bei eXtreme Programming
23.2 Scrum
23.2.1 Die Rollen bei Scrum
23.2.2 Projektablauf bei Scrum
23.3 Feature Driven Development
23.3.1 Erstelle das Gesamtmodell
23.3.2 Erstelle die Feature-Liste
23.3.3 Plane je Feature
23.3.4 Entwirf je Feature
23.3.5 Entwickle je Feature
23.3.6 Gesamtüberblick über FDD
23.3.7 Diskussion: Ist FDD agil?
23.4 Kanban
23.4.1 Prinzipien von Kanban
23.4.2 Kanban als Change-Management-Methode
24 Kontraindikation und Indikation
24.1 Kontraindikation
24.1.1 Kontraindikationen im Bereich des Kunden
24.1.2 Kontraindikationen im Bereich der Entwickler
24.1.3 Kontraindikationen im Bereich von Technologien
24.2 Indikation
24.2.1 Indikationen im Bereich des Kunden
24.2.2 Indikationen im Bereich der Entwickler
24.2.3 Indikationen im Bereich von Technologien
24.3 Zusammenfassung
25 Rückblick
Anhang
A Übersetzungen
Literaturverzeichnis
Index
Dieses Buch wendet sich an alle, die sich für agile Softwareentwicklung interessieren. Einleitend möchten wir unser mit diesem Buch verbundenes Ziel, unseren Erfahrungshintergrund, das dem Buch zugrunde liegende Vorgehen und den von uns für das Thema gewählten Aufbau des Buches vorstellen.
Wir wollen Ihnen näher bringen, was agile Softwareentwicklung ausmacht. Dabei wollen wir bewusst darauf verzichten, Ihnen das agile Vorgehen an einer konkreten agilen Methode wie eXtreme Programming (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, wollen Ihnen aber die agile Denkweise so weit näher bringen, dass Sie offen bleibende Fragen selbst in einem agilen Sinne beantworten können.
Es gibt noch einen weiteren Grund, warum wir uns für diese Einführung von den konkreten Methoden gelöst haben: In unseren Projekten 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 wollen 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.
EinführungNach 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 KapitelAb dem dritten Kapitel orientieren wir uns dann an unterschiedlichen 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 MethodenDie 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 Programmierebene starke Entwicklungsmethode.
Scrum als eine vor allem auf agiles Projektmanagement und -organisation abgestellte Methode, die bei Weitem nicht nur für Softwareentwicklungsprojekte eingesetzt werden kann. Sie bietet allerdings 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 ersten Blick klassisch daherkommt, aber trotzdem den agilen Grundwerten und Grundsätzen genügt. Gerade weil FDD nicht auf selbstorganisierte Teams setzt, ist es unserer Einschätzung nach für viele Organisationen interessant und bietet Ihnen eine sinnvolle agile Alternative 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) entstammt. Kanban interpretiert das agile Manifest anders als Scrum oder XP. Als Methode ist Kanban für all jene Kontexte besonders gut geeignet, in denen schnell und häufig geliefert werden soll. Deshalb ist Kanban eine hervorragende Methode zur Organisation der Betriebsführung oder Wartung, aber auch in Softwareentwicklungskontexten gut einsetzbar.
Kontraindikation und IndikationSind 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 gemeinsam 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 Übungsaufgaben formuliert, die Sie am Ende des jeweiligen Kapitels finden.
Nicht nach Methoden strukturiertFür den Aufbau des Buches haben wir uns bewusst gegen eine Strukturierung nach den vorgestellten Methoden entschieden, denn dies widerspricht den gesammelten Erfahrungen: In den uns bekannten agilen Projekten wurde und wird nicht streng nach einer agilen Methode vorgegangen.
PerspektivenDer Erfahrung nach sind im Projekt die unterschiedlichen Perspektiven viel bestimmender. Wir unterscheiden deshalb bei der Vorstellung der agilen Praktiken zwischen den Perspektiven Team, Management 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 Projekten 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ösungsbausteine ein.
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 Industriekontexten und Lehrveranstaltungen an Hochschulen.
Der einfachste und sicherlich naheliegendste Weg verläuft entlang der normalen Kapitelreihenfolge. Diese ist von uns bereits so vorgegeben, dass Sie sich schrittweise und zyklisch den Praktiken der agilen 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 aufgeführt, und am Ende jedes Kapitels sind die Bezüge zu anderen agilen Praktiken angegeben.
Für das SelbststudiumDas Buch eignet sich auch zum Selbststudium; wir raten Ihnen hier zu einem realen Projekt, in dem Sie sich mit agilen Praktiken auseinandersetzen. Die Praktiken und die damit verbundene Haltung sind leichter nachzuvollziehen, wenn sie in einer konkreten Projektsituation praktiziert werden. Das mag aber nicht immer möglich sein.
Arbeit im IndustriekontextFür die Arbeit in einem Industriekontext empfehlen wir ein reales Projekt, in dem Sie agile Methoden einsetzen wollen. Wenn es Ihr erster 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 hinaus 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önnen 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 HochschulenFür Lehrveranstaltungen an Hochschulen empfehlen wir eine projektartige Veranstaltungsform. Wir wissen, dass insbesondere Softwareentwicklungsmethoden gerne im Rahmen von Vorlesungen unterrichtet werden. Aus unserer eigenen Erfahrung lässt sich aber sagen, dass die Inhalte dabei nur schwer vermittelbar sind und wenig Eindruck hinterlassen. Gute Rückmeldung haben wir dagegen in Projekten oder Praktika erhalten, in denen sich die Studierenden aktiv und bezogen auf eine Problemstellung selbst mit den Praktiken beschäftigen mussten.
Die Reihenfolge der Kapitel ist bereits eine brauchbare Reihenfolge 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 Schwerpunkte ergeben. Die Studierenden werden deshalb die Texte so lesen, 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 vorgegebene Kapitelreihenfolge an, denn die Themen und die damit verbundenen Praktiken ergeben in der vorliegenden Reihenfolge einen organischen Zusammenhang. Sind Sie in der glücklichen Lage, an einem konkreten Projekt zu arbeiten, empfehlen wir Ihnen dieselbe Lesestrategie wie bei Industrieprojekten.
Agil sein bedeutet im Allgemeinen, dass jemand körperlich oder geistig wendig oder flink ist. Und sowohl Wendigkeit als auch Flinkheit treffen auf agile Softwareentwicklung gut zu: Wir wollen angepasst (wendig) vorgehen und schnell (flink) vorzeigbare Ergebnisse erzielen. Um dieses Ziel erreichen zu können, wollen wir uns die Wendigkeit bewahren, die Mittel zu wählen, mit denen wir dieses Ziel erreichen können. Sie werden feststellen, dass es bei agiler Softwareentwicklung immer wieder genau um diese Flexibilität geht, die notwendig ist, wenn Sie zu den schnell vorgelegten (Zwischen-)Ergebnissen Rückkopplungen erhalten. Dazu später mehr.
In dieser Einführung wird Ihnen zu Beginn in Abschnitt 2.1 Unsere Sicht auf Softwareentwicklung kurz der Gegenstand der Betrachtung erläutert, also die Sicht der Autoren auf Softwareentwicklung im Allgemeinen.
Daraus ergibt sich für uns als logische Konsequenz der Einsatz agiler Methoden. Deren Werte betrachten wir in Abschnitt 2.2 Werte hinter agiler Softwareentwicklung im Detail.
Schließlich befassen wir uns in Abschnitt 2.3 mit dem agilen Manifest. Es bringt die Gedanken hinter den aktuell relevanten agilen Methoden gut auf den Punkt und wurde von den Erschaffern und Befürwortern agiler Methoden unterzeichnet.
Diesen Ausführungen folgt eine knappe Zusammenfassung, was agiles Vorgehen im Kern bedeutet, in Abschnitt 2.4 Grundsätzliches agiles Vorgehen. Dieser Abschnitt gibt Ihnen eine handlungsanleitende Vorstellung davon, was zu beachten ist, wenn agil Software entwickelt werden soll.
Bei der Softwareentwicklung gibt es ein klares Ziel: Es soll ein einsetzbares Softwaresystem entstehen. Dabei soll aber keinesfalls irgendein Softwaresystem erstellt werden, sondern dieses System muss bestimmten projektspezifischen Anforderungen entsprechen.
Abb. 2–1 Wie kommt man zu Softwaresystemen?
Aber diese projektspezifischen Anforderungen fallen nicht vom Himmel. Sie sind vor dem Hintergrund von Geschäftszielen entworfen, also zur Erreichung von Geschäftszielen erstellt.
In Abbildung 2–1 ist dies schematisch dargestellt: Das System entsteht durch eine Transformation aus den Anforderungen. Die Anforderungen entstehen durch eine Transformation aus den Geschäftszielen. Die eigentliche Arbeit, also die Softwareentwicklung, scheint in diesen Transformationsprozessen anzufallen. Sie stellen gleichzeitig die Herausforderungen in der Softwareentwicklung dar, denn es ist alles andere als trivial, für ein Geschäftsziel die exakten Anforderungen an ein diesem Ziel förderliches System zu stellen und die gegebenen Anforderungen in ein softwaretechnisches Artefakt zu überführen.
Es stellt sich die spannende Frage, wie und wann wir die Ergebnisse der Transformationsprozesse überprüfen können (siehe Abb. 2–2).
Abb. 2–2 Wie überprüft man die Transformationsprozesse?
Der Transformationsschritt von den Anforderungen zum Softwaresystem kann mittels Tests überprüft werden. Es kann hier eine Vielzahl von Testverfahren zum Einsatz kommen, die teilweise später in diesem Buch vorgestellt werden. Fürs Erste dürfte ein ganz intuitiver Begriff davon genügen, dass man das System und die Anforderungen hernehmen und systematisch überprüfen kann, ob alle Anforderungen vom System erfüllt werden (oder nicht). Es ist möglich, sich ebenfalls intuitiv vorzustellen, dass damit ein gewisser Aufwand verbunden ist und sich die interessante Frage stellt, was die Projektbeteiligten bei der Softwareentwicklung machen wollen, wenn noch nicht alle Anforderungen erfüllt sind. Diese Frage ist für das Management des Softwareentwicklungsprozesses interessant, und gleichzeitig ahnen Sie an dieser Stelle vielleicht schon, dass sich diese Frage nicht erst am vermeintlichen Ende eines Entwicklungsprojektes stellen sollte.
Für eine direkte Überprüfung des Transformationsprozesses zwischen Geschäftszielen und Anforderungen ist uns kein systematischer Weg bekannt. Natürlich könnte eine entsprechende Überprüfung von Experten vorgenommen werden. Wie viel Sicherheit diese letztlich erbringt, ist aber fraglich.
Der beste uns in diesem Zusammenhang bekannte Weg der Überprüfung ist der indirekte Weg über den Systemeinsatz, wie er in Abbildung 2–3 dargestellt ist.
Abb. 2–3 Systemeinsatz als Überprüfung
Statt also die Anforderungen direkt gegen das Geschäftsziel zu prüfen, wird das auf Grundlage der Anforderungen erstellte System eingesetzt und damit gegen das Geschäftsziel geprüft.
Es wäre äußerst ungünstig, wenn diese Überprüfung erst am Projektende erfolgt, weil es dann für Korrekturen und Umstellungen zu spät wäre. Stattdessen fordern wir, dass diese Überprüfung so früh wie möglich geschehen sollte, damit ggf. bei Fehlentwicklungen noch während der Projektlaufzeit eingegriffen und umgesteuert werden kann.
Hinter dieser hier von uns vertretenen Sichtweise steckt ein Wertesystem, das von Folgendem ausgeht:
1. Softwareentwicklung wird als Ganzes betrachtet. Softwareentwicklungsprozesse sind für die Umsetzung von Geschäftszielen mittels Softwaresystemen verantwortlich.
2. Die Software wird im Einsatz von Anwendern und deren Managern beurteilt und kann grundsätzlich nicht ausschließlich von Entwicklern beurteilt werden.
3. Bei der Softwareentwicklung ist Rückkopplung notwendig, um zu überprüfen, ob man auf dem richtigen Weg ist, und um ggf. noch während der Projektlaufzeit eingreifen und korrigieren zu können.
Das nächste Kapitel widmet sich genauer dem Wertesystem, das hinter agiler Softwareentwicklung steht.
Vor allem zwei wesentliche Werte finden sich als Grundlage agiler Methoden: Kommunikation und Einfachheit. Später in diesem Kapitel wird zusätzlich noch auf die Werte Rückkopplung (Feedback), Mut und Respekt eingegangen.
Es mutet auf den ersten Blick schon ein wenig merkwürdig an, Kommunikation als einen Wert zu verstehen. Im Zusammenhang mit Softwareentwicklungsmethoden ist allerdings zu bedenken, dass viele Methoden dem Traum nach einer ingenieurmäßigen oder noch schlimmer fabrikmäßigen Herstellung von Software anhängen. Die Folge aus dieser Sichtweise ist dann ein Verzicht auf direkte Kommunikation zwischen Menschen, die ersetzt wird durch eine klar definierte Menge an Dokumenten oder Artefakten wie Lastenheft, Pflichtenheft, Spezifikationen usw.
Agile Softwareentwicklungsmethoden sehen dagegen einen hohen Wert in direkter Kommunikation zwischen allen Projektbeteiligten. Die Kundenmanager sollen mit den Anwendern über ihre Ziele der Softwareentwicklung sprechen. Die Anwender müssen ihrem Management und den Entwicklern ihre Bedürfnisse kommunizieren und sollen sich darüber untereinander möglichst einig werden. Schließlich müssen gerade die Entwickler gegenseitig und mit allen anderen Projektbeteiligten viel kommunizieren, um ein gemeinsames Ziel verfolgen zu können und sich über Entscheidungen, Probleme und gewählte Lösungswege auszutauschen.
Nur um es explizit klarzustellen: Es geht nicht um möglichst viel Kommunikation, sondern um direkte, offene und ehrliche Kommunikation. Direkt bezieht sich dabei sowohl auf möglichst kurzfristige Kommunikation bei Bedarf als auch auf Kommunikation, die im Optimalfall direkt von einer Person zu einer anderen erfolgt. Offen und ehrlich ist die Kommunikation dann, wenn über alles gesprochen wird, ohne z. B. unangenehme Themen auszusparen, und die Dinge beim Namen genannt werden dürfen.
Wir werden später noch erläutern, dass direkte Kommunikation eine wesentliche Voraussetzung für direkte Rückkopplung ist.
Softwareentwicklung ist für gewöhnlich nicht einfach, sondern komplex. Das hängt sowohl mit der Materie Softwareentwicklung, mit der Zusammenarbeit verschiedener Berufsgruppen, mit Teamgrößen und unterschiedlichen Zielen und Qualifikationen als auch mit der Komplexität der abzubildenden Geschäftsprozesse zusammen. Wenn Komplexität also Softwareentwicklung ausmacht, wie kann dann Einfachheit als Wert gewählt werden?
Gerade weil die Komplexität sowieso schon hoch ist, wollen wir sie mit agilen Methoden überall reduzieren, wo uns dies möglich scheint. Wir streben allerdings nicht an, dass Softwareentwicklung so einfach werden soll wie Frühstücken, sondern wir wollen auf allen Ebenen so wenig Komplexität wie möglich und suchen technisch, organisatorisch und methodisch nach einfachen Lösungen:
Technisch wollen wir nur das bauen, was wirklich benötigt wird. Die technischen Lösungen sollen einfach sein, damit sind sie dann einfacher zu verstehen, einfacher zu warten und später einmal einfacher zu erweitern oder zu ändern.
Organisatorisch wollen wir so wenig Überbau wie möglich. Was die Anwender oder Entwickler selbst organisieren können, das sollen sie selbst organisieren und dafür nicht unnötig neue Rollen oder Posten erschaffen.
Methodisch wollen wir einfach vorgehen, sodass das Vorgehen allen verständlich bleibt und von allen umgesetzt und gelebt werden kann. Wir wollen mit der gewählten Methode nicht für unnötige zusätzliche Komplexität sorgen. Methodisch gehört dazu, dass wir je nach Projektsituation ggf. noch einfacher vorgehen, als unsere Standardmethode dies vorsieht, wenn das im Projekt möglich ist.
Die Vorteile einfacher Lösungen leuchten ein, Einfachheit ist aber gar nicht so leicht herzustellen. Wir zeigen in diesem Buch aber noch eine ganze Reihe von einfachen Lösungen für verschiedene Problemstellungen bei der Softwareentwicklung.
RückkopplungRückkopplung oder Feedback wird zuweilen als Wert für agile Softwareentwicklung genannt. Uns scheint Rückkopplung ein Wert zu sein, der vor allem im direkten Zusammenhang mit Kommunikation steht. Darüber hinaus gibt es aber weitere Ebenen, auf denen agile Softwareentwicklung einen empirischen Ansatz verfolgt und Zwischenergebnisse einführt, die einer Bewertung unterzogen werden können.
Wir haben das schon für das Softwaresystem in Abschnitt 2.1 Unsere Sicht auf Softwareentwicklung aufgezeigt. Möglichst frühe und häufige Systemauslieferungen fördern die Rückkopplung, ob die entwickelte Software den angestrebten Geschäftszweck erfüllt. Wir werden in diesem Buch noch einige Rückkopplungsmechanismen kennenlernen, u. a. Komponententests, Projektfortschrittsmessungen und Retrospektiven.
MutMut ist ein Wert, der vor allem dort benötigt wird, wo agile Softwareentwicklung auf Widerstände trifft. Dort bedarf es mutiger Menschen, die sich entscheiden, einmal einen anderen Weg auszuprobieren. Es gehört Mut dazu, offen und ehrlich und direkt zu kommunizieren, denn wir haben ja nicht immer nur Positives zu berichten, sondern zuweilen zu erklären, was in einem bestimmten Zeitraum oder mit einem bestimmten Aufwand eben nicht möglich ist.
RespektIn Softwareentwicklungsprojekten ist ein respektvoller Umgang aller Projektbeteiligter miteinander hilfreich. Respekt ist wesentliche Voraussetzung dafür, dass die Beteiligten offen und ehrlich und angstfrei miteinander kommunizieren können. Nur wer sich respektiert fühlt, der kann offen sprechen. So müssen die Entwickler die Anwender respektieren, selbst wenn diese sich in den Augen der Entwickler vermeintlich merkwürdig organisiert haben sollten. Es gilt, über Kommunikation die Gründe herauszubekommen und nicht eine Bewertung abzugeben. Der Respekt unter den Entwicklern ist wichtig, um alle im Team produktiv einzubinden und nicht Außenseiter zu schaffen, deren technische Lösungen nicht akzeptiert werden. Zum Respekt gehört dazu, dass jeder zuerst sein Gegenüber verstehen muss, bevor er Rückkopplung gibt.
Im Februar 2001 trafen sich Vertreter vieler agiler Methoden; unter ihnen waren Kent Beck, Mike Beedle, Alistair Cockburn, Ward Cunningham, Martin Fowler, Jim Highsmith, Ron Jeffries, Robert C. Martin, Ken Schwaber und Dave Thomas. Damit waren u. a. die Methoden eXtreme Programming, Scrum, Crystal und Feature Driven Development vertreten. Die Teilnehmer einigten sich als Grundlage aller agilen Methoden auf das folgende Manifest:
Abb. 2–4 Das agile Manifest
Schauen wir uns das agile Manifest im Detail an:
Bessere Wege