Agile Entwicklungspraktiken mit Scrum
Roman Pichler ist international renommierter Scrum-Experte und Autor der Bücher»Agile Product Management with Scrum«und»Scrum Agiles Projektmanagement erfolgreich einsetzen«. Er praktiziert agile Softwareentwicklung seit 1999 und coachte sein erstes agiles Projekt 2001. Scrum setzt er seit 2004 ein und arbeitet seit 2006 als selbstständiger Berater, Coach und Trainer. Mehr Informationen finden Sie unter www.romanpichler.com. Dipl.-Inform. Stefan Roock ist Senior IT-Berater bei der it-agile GmbH in Hamburg. Er arbeitet seit 1999 in agilen Softwareprojekten mit Scrum, Extreme Programming, Feature Driven Development und Kanban. Er wirkte als Coach, Trainer, ScrumMaster/ Facilitator und Entwickler mit. Darüber hinaus hat er zahlreiche Artikel und Tagungsbeiträge über agile Softwareentwicklung verfasst und ist Autor der Bücher»Software entwickeln mit extreme Programming«und»Refactorings in großen Softwareprojekten«.
Roman Pichler Stefan Roock (Hrsg.) Agile Entwicklungspraktiken mit Scrum
Roman Pichler roman.pichler@romanpichler.com Stefan Roock stefan@stefanroock.de Lektorat: Christa Preisendanz Vanessa Wittmer Copy-Editing: Ursula Zimpfer, Herrenberg Herstellung: Birgit Bäuerlein 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: Buch 978-3-89864-719-9 PDF 978-3-89864-885-1 epub 978-3-89864-854-7 1. 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
Für Leo und Yasmin Roman Pichler Für die kleinen»roockies«mika und Levi Stefan Roock
vii Geleitwort Ein weiteres Buch über Scrum? Ja! Aber nicht irgendeines, sondern eines, das ganz anders ist als alle anderen. Hier geht es um Technik und Techniken. Während es inzwischen unzählige Bücher auf dem Markt gibt, die sich mit agilen Prinzipien oder Scrum beschäftigen, gibt es nur sehr wenige, die die technischen Aspekte agiler Softwareentwicklung erläutern. Vor mehreren Jahren haben wir Scrum bei der mobile.international GmbH eingeführt. Schnell haben wir gemerkt, dass die Vorteile von Scrum auch Nachteile mit sich bringen. Scrum ist ein sehr leichtgewichtiger und leicht zu beschreibender Prozess. Dafür ist Scrum umso schwerer zu lernen und nur Stück für Stück merkt man, was einem auf dem Weg noch fehlt und wie man seine Organisation und das ganze Umfeld verändern muss. Der Vorteil von Scrum, so dünn und leichtgewichtig zu sein, bringt aber mit sich, dass Scrum sich zu Entwicklungstechniken ausschweigt. Aber schnell wurde uns klar, dass wir auch an unserer technischen Exzellenz arbeiten müssen, um uns kontinuierlich zu verbessern. Agile Softwareentwicklung funktioniert nur gut, wenn man eine fast konstante Aufwandskurve erreicht wenn also ein zu entwickelndes Feature zum Ende eines Projekts nicht wesentlich teurer ist als zu Beginn. Und dazu wird man irgendwann die Fragen beantworten müssen, wie man einen emergenten Architekturbegriff unterstützt, wie man einen inkrementellen Entwurf beherrscht und dies letztlich durch ständige in Teilen automatisierte Refactorings fördert. Wer richtig gut sein will, entwickelt von Anfang an testgetrieben. Aber agile Softwareentwicklung setzt auch kurze Feedbackzyklen voraus und im Ideal dann auch ständige Releases. Und das wiederum ist alles nur zu erreichen mit Continuous Integration inklusive 10-Minuten-Build und letztlich auch automatisierten Akzeptanztests, um die Transaktionskosten für konstantes, schnelles Feedback gering halten zu können und um nicht zu größeren Iterationen oder Arbeitsschritten gezwungen zu werden. Neben Prozess und Tools muss aber auch das Umfeld stimmen. Die Fülle der Themen macht klar, dass jeder von uns ständig neu dazulernen muss, denn die in diesem Buch beschriebenen Themen sind komplex, fordernd und unterliegen einer dynamischen Entwicklung. Am Ende heißt Software mit Scrum zu entwickeln
viii Geleitwort auch, Software auf technisch und handwerklich sehr hohem Niveau zu entwickeln. Und dafür muss das Umfeld stimmen und eine Lernkultur aufweisen, die ständiges Infragestellen des Status quo und Lernen unterstützt. Deswegen freue ich mich besonders über die Kapitel im Buch, in denen es um Themen geht, die uns auf diesem Weg selbst weitergebracht haben:»dojos und Katas«, das wunderbare spielerische Formen des fokussierten Übens erklärt und nachvollziehbar macht, sowie»pair Programming und Collective Ownership«, das alte, aber immer noch aktuelle und immer wieder neu interpretierte Themen frisch präsentiert. Ein Kapitel über den vielleicht schwierigsten Aspekt agiler Softwareentwicklung, nämlich verteilte Teams, rundet das Buch zum Ende hin ab. Verteilte agile Entwicklung ist besonders schwierig, denn der Kern agiler Entwicklung ist Eliminierung von Overhead durch ständige, enge Kommunikation. Wie diese erreicht werden kann, obwohl Teams räumlich getrennt sind, wird in diesem Kapitel nachvollziehbar gemacht. Man muss dieses Buch nicht von vorne bis hinten durchlesen auch wenn dies sehr inspirierend ist und Anhaltspunkte gibt, welche Aufgaben noch zu lösen sind. Aber immer, wenn das ewig zwischen Prozessverbesserung und technischer Verbesserung hin- und herschwingende Pendel wieder bei der Technik landet, kann man sich dieses Buch schnappen und sicher sein, das passende Kapitel zu finden. Und jedes der Kapitel erläutert genau eines der erwähnten Themen grundlegend und praxisnah jeweils geschrieben von einem Autor, der zu den Praktikern und Größen der agilen Szene in Deutschland gehört. Jedes Kapitel beschreibt das Kondensat der praktischen Erfahrung eines Autors erprobte agile Praktiken, die schon vielen Unternehmen geholfen haben, auf dem Weg zu technischer Exzellenz weiterzukommen. Roman Pichler und Stefan Roock ist mit diesem Buch eine wunderbare Sammlung relevanter Aufsätze gelungen, die uns selbst und vielen anderen Agilisten noch lange Jahre helfen wird. Markus Andrezak Potsdam im Februar 2011
ix Inhalt 1 Einleitung 1 Roman Pichler Stefan Roock 1.1 Agile Softwarewicklung und Scrum............................ 1 1.2 Zielgruppe und Zielsetzung.................................. 2 1.3 Überblick über das Buch.................................... 3 1.4 Java als Beispielsprache..................................... 4 1.5 Danke.................................................. 4 2 Architekturvision 5 Stefan Roock Roman Pichler 2.1 Die Architekturvision im Überblick............................ 5 2.2 Wünschenswerte Eigenschaften der Vision...................... 6 2.2.1 Klar (Clear)....................................... 6 2.2.2 Von allen mitgetragen (Accepted)....................... 7 2.2.3 Kurz und bündig (Short)............................. 7 2.3 Beispiel einer Architekturvision............................... 8 2.4 Die Erstellung der Architekturvision........................... 8 2.5 Die Form der Vision...................................... 10 2.6 Architekturvision und Legacy-Systeme........................ 10 2.7 Zusammenfassung........................................ 12 3 Inkrementeller Entwurf 13 Stefan Roock 3.1 Der inkrementelle Entwurf im Überblick....................... 13 3.2 Flache Aufwandskurve.................................... 14 3.3 Qualitätskriterien für den inkrementellen Entwurf............... 15
x Inhalt 3.4 Entwurfsprinzipien....................................... 16 3.4.1 Single Responsibility Principle........................ 17 3.4.2 Open Closed Principle.............................. 17 3.4.3 Liskov Substitution Principle......................... 17 3.4.4 Interface Segregation Principle........................ 18 3.4.5 Dependency Inversion Principle....................... 18 3.5 Inkrementeller Entwurf und agile Entwicklungspraktiken.......... 19 3.6 Zusammenfassung........................................ 19 4 Continuous Integration 21 Andreas Havenstein 4.1 Continuous Integration im Überblick......................... 22 4.2 Ein Beispiel............................................. 23 4.3 Die Continuous-Integration-Umgebung........................ 23 4.4 Kontinuierliches Feedback.................................. 24 4.5 Umgang mit Feedback..................................... 26 4.5.1 Broken-Windows-Theory............................ 26 4.5.2 Stop-the-Line-Prinzip............................... 27 4.6 10-Minuten-Build........................................ 27 4.7 Continuous-Integration-Produkte............................ 28 4.8 Feature-Branches und Feature-Flags.......................... 31 4.9 Continuous Integration und Scrum........................... 32 4.9.1 Offenheit und Mut................................. 32 4.9.2 Definition of Done................................. 32 4.9.3 Sprint-Meetings................................... 33 4.9.4 Feedback für die Scrum-Teammitglieder................. 33 4.10 Einführung von Continuous Integration....................... 34 4.10.1 Einführung zu Projektbeginn......................... 34 4.10.2 Einführung in ein laufendes Projekt.................... 34 4.11 Zusammenfassung........................................ 35 5 Testgetriebene Entwicklung 37 Johannes Link 5.1 Testgetriebene Entwicklung im Überblick...................... 37 5.2 Der Test-Code-Refactor-Zyklus.............................. 38 5.3 Ein Beispiel für testgetriebene Entwicklung..................... 39 5.3.1 Bevor es losgeht................................... 39 5.3.2 Schritt 1: Der fehlschlagende Test..................... 40 5.3.3 Schritt 2: Alles wird grün............................ 42
Inhalt xi 5.3.4 Schritt 3: Wir räumen auf............................ 43 5.3.5 Wir ergänzen den Test.............................. 43 5.3.6 Ein weiterer Testfall................................ 44 5.3.7 Auffinden fehlender Tests............................ 47 5.3.8 Refactoring...................................... 50 5.3.9 Testfälle für existierende Funktionalität................. 50 5.3.10 Testfälle für zufälliges Verhalten...................... 51 5.4 Rhythmus.............................................. 52 5.5 Isoliertes Testen mit Attrappen.............................. 52 5.5.1 Die Falle......................................... 52 5.5.2 Die Alternative.................................... 53 5.5.3 Kleine Typologie der Abhängigkeiten................... 54 5.5.4 Was bisher geschah................................ 55 5.5.5 Notifications..................................... 57 5.5.6 Dependencies alias Services.......................... 59 5.5.7 Adjustments...................................... 61 5.6 Integrationstests......................................... 62 5.7 Heuristiken für gute Tests.................................. 64 5.8 Weiterführende Hinweise.................................. 65 5.9 Zusammenfassung........................................ 66 6 Refactoring 67 Bernd Schiffer 6.1 Refactoring im Überblick.................................. 67 6.2 Refactoring und Tests..................................... 68 6.3 Ein Beispiel............................................. 69 6.4 Kleine Schritte auf dem grünen Pfad.......................... 71 6.5 Nutzen von Refactoring................................... 72 6.6 Risiken von fehlendem Refactoring........................... 72 6.7 Wiederholungen? Niemals!................................. 73 6.8 SOLIDes Design und Entwurfsmuster......................... 74 6.9 Weitere Refactorings...................................... 75 6.10 Refactoring von Tests..................................... 77 6.11 Große Refactorings....................................... 78 6.12 Refactorings und die Definition of Done....................... 79 6.13 Refactoring und Teamarbeit................................ 79 6.14 Refactoring von Legacy-Code............................... 80 6.15 Zusammenfassung........................................ 80
xii Inhalt 7 Automatisierte Refactorings 81 Martin Lippert 7.1 Automatisierte Refactorings im Überblick...................... 81 7.2 Der Klassiker: Rename.................................... 82 7.3 Schritt für Schritt......................................... 82 7.4 Aufspalten.............................................. 84 7.5 Wunderwaffe»Inline«..................................... 86 7.6 Große Refactorings....................................... 89 7.7 Parameter.............................................. 90 7.8 Interfaces und Oberklassen................................. 92 7.9 Refactoring ohne Tests.................................... 93 7.10 Gemischtsprachige Systeme und DSLs......................... 94 7.11 Grenzen................................................ 95 7.12 Zusammenfassung........................................ 95 8 Automatisierte Akzeptanztests 97 Alex Bepple Jens Coldewey 8.1 Akzeptanztests im Überblick................................ 97 8.2 Formulierung guter Akzeptanztests.......................... 101 8.3 Werkzeuge zur Testautomatisierung......................... 103 8.3.1 Auswahlkriterien................................. 103 8.3.2 Werkzeuge zur Formulierung von Akzeptanztests........ 106 8.4 Akzeptanztestgetriebe Entwicklung.......................... 108 8.4.1 Nutzen......................................... 108 8.4.2 Vorgehen....................................... 109 8.5 Zusammenfassung....................................... 110 9 Pair Programming und Collective Ownership 111 Henning Wolf 9.1 Pair Programming im Überblick............................ 111 9.2 Nutzen von Pair Programming............................. 112 9.3 Rollenwechsel.......................................... 114 9.4 Wechsel des Partners..................................... 114 9.5 Einstieg in Pair Programming.............................. 115 9.6 Collective Ownership.................................... 116 9.7 Pair Programming und Collective Ownership.................. 116 9.8 Collective Ownership für große Projekte...................... 117 9.9 Zusammenfassung....................................... 117
Inhalt xiii 10 Dojos und Katas 119 Stefan Roock Bernd Schiffer 10.1 Code-Katas............................................ 119 10.1.1 Überblick....................................... 119 10.1.2 Anwendung..................................... 121 10.2 Coding-Dojos.......................................... 122 10.2.1 Coding-Dojos mit zwei bis vier Teilnehmern............ 122 10.2.2 Coding-Dojos mit drei bis sechs Teilnehmern............ 123 10.2.3 Coding-Dojos mit vier bis 14 Teilnehmern.............. 123 10.3 Code-Katas und Coding-Dojos in Scrum...................... 123 10.4 Weitere Dojos.......................................... 123 10.5 Zusammenfassung....................................... 124 11 Modellgetriebene Entwicklung 125 Peter Friese 11.1 Modellgetriebene Entwicklung im Überblick................... 125 11.2 Ein Beispiel............................................ 127 11.2.1 Vorgehen....................................... 129 11.2.2 Sprint 1: Manuelle Programmierung.................. 129 11.2.3 Entwicklung einer DSL............................. 132 11.2.4 Vom existierenden Code zur DSL..................... 132 11.2.5 Ein Codegenerator................................ 134 11.2.6 Sprint 2: Modellgetriebene Implementierung............ 137 11.2.7 Weitere Nutzung der DSL.......................... 138 11.3 Modellgetriebene Entwicklung und agile Entwicklungspraktiken... 139 11.4 Inkrementelles Vorgehen.................................. 139 11.4.1 Collective Code Ownership......................... 140 11.4.2 Refactoring..................................... 140 11.4.3 Continuous Integration............................ 141 11.5 Zusammenfassung....................................... 141 12 Verteilte Entwicklung 143 Jutta Eckstein 12.1 Verteilte und verstreute Featureteams........................ 143 12.2 Virtuelles Pair Programming............................... 145 12.3 Entwicklertests......................................... 146 12.4 Akzeptanztests.......................................... 147 12.5 Collective Ownership.................................... 148 12.6 Refactoring............................................ 149
xiv Inhalt 12.7 Continuous Integration................................... 149 12.8 Projektstart............................................ 151 12.9 Anpassen der Entwicklungspraktiken........................ 151 12.10 Zusammenfassung....................................... 152 13 Epilog 153 Roman Pichler Stefan Roock Anhang Die Autoren 157 Literatur 161 Index 165
1 1 Einleitung Roman Pichler Stefan Roock»Wenn ich Scrum einführe, begutachte ich die Entwicklungspraktiken. Manchmal sind sie in Ordnung, manchmal behindern sie das Team und manchmal sind sie nicht vorhanden. Ich benutze das Daily Scrum, um Defizite zu ermitteln. Dann arbeite ich mit dem Team und dem Management, um [die Praktiken] zu verbessern.«[schwaber & Beedle 2002, S. 59] 1.1 Agile Softwarewicklung und Scrum Scrum ist ein mächtiges und zugleich einfaches agiles Managementframework, das nicht vorschreibt, wie Software entwickelt wird. Der Fokus von Scrum liegt auf der Bereitstellung des richtigen Prozesses. Über den Einsatz der Entwicklungspraktiken entscheidet das Team. Denn dieses organisiert seine Arbeit selbst und bestimmt, wie hochpriore Product-Backlog-Einträge in Produktinkremente umgewandelt werden. Und das ist auch gut so. Schließlich kennt das Team seine Fähigkeiten am besten und ist für die Erreichung des Sprint-Ziels verantwortlich. 1 Dennoch spielt die Entwicklung qualitativ hochwertiger Software in Scrum eine zentrale Rolle. Wie das oben stehende Zitat zeigt, weist bereits das erste Scrum-Buch Agile Software Development with Scrum [Schwaber & Beedle 2002] auf den Einsatz der richtigen Entwicklungspraktiken hin. Das hat einen guten Grund: Ohne die richtigen Praktiken ist das Team nicht in der Lage, zuverlässig das Sprint-Ziel zu erreichen und solide Produktinkremente zu entwickeln. Letztere bilden aber die Grundlage für die effektive Anwendung von empirischem Management: dem Schaffen von Klarheit über den Entwicklungsfortschritt durch das Vorführen der Software, der Reflexion des Erreichten (engl. inspect) und dem Ableiten von Verbesserungsmaßnahmen (engl. adapt). Ohne ein qualitativ hochwertiges Produktinkrement ist das Einholen von hilfreichem Feedback von Kunden, Anwendern und anderen Interessenvertretern nicht möglich, die Software 1. Wir haben uns bei den Rollennamen am Scrum Guide, http://www.scrum.org/scrumguides, orientiert. Team bezeichnet die Mitarbeiter, die Produktinkremente erstellen, Scrum-Team umfasst Team, ScrumMaster und Product Owner.
2 1 Einleitung lässt sich nicht frühzeitig ausliefern, die Releaseplanung gerät zum Roulettespiel und neue Anforderungen können nur langsam und aufwendig umgesetzt werden. Glücklicherweise haben sich verschiedene agile Entwicklungspraktiken im Scrum-Kontext als besonders hilfreich erwiesen. Hierzu zählen inkrementeller Entwurf, Continuous Integration, testgetriebene Entwicklung und Refactoring Praktiken, die zum großen Teil durch eine andere agile Methode populär wurden: Extreme Programming (XP). Wie die meisten unserer Koautoren sind auch wir durch Extreme Programming zur agilen Softwareentwicklung gekommen. Bereits 1999 entdeckten wir agile Entwicklungspraktiken wie Collective Ownership, Pair Programming und testgetriebene Entwicklung. Scrum haben wir erst danach schätzen und lieben gelernt. Teams, die heute agil arbeiten möchten, starten meist mit Scrum und kennen agile Entwicklungspraktiken oftmals nicht. Dabei muss nicht jeder Entwickler ein Fan sämtlicher agiler Entwicklungspraktiken sein. Auch muss nicht jedes Scrum-Projekt alle Praktiken einsetzen. Agile Entwicklungspraktiken sollten aber zum Handwerkszeug eines Scrum-Entwicklers gehören. Denn nur so ist das Team in der Lage, über den Einsatz der richtigen Praktiken zu entscheiden. Softwareentwickler im Scrum-Team sollten die gängigen agilen Entwicklungspraktiken nicht nur gut beherrschen, sondern auch verantwortlich einsetzen. Dazu zählt, selbst bei Zeitnot auf die Arbeit stolz sein zu können und qualitativ hochwertige Software zu erstellen ohne dabei den Geschäftswert aus den Augen zu verlieren. Diese Kombination aus Berufsehre, Handwerkszeug und Wertorientierung nennt Robert Martin Craftsmanship [Martin 2008]. Kent Beck spricht von Responsible Development [Christensen 2007] und fragt das Team:»Würdet Ihr Euer eigenes Geld in dieses Team investieren?«1.2 Zielgruppe und Zielsetzung Unser Buch richtet sich an Softwareentwickler, Softwarearchitekten, Programmierer, Tester, ScrumMaster und Entwicklungsleiter. Wir setzen voraus, dass der Leser über Softwareentwicklungserfahrung verfügt und Grundkenntnisse in Scrum besitzt. Für eine Einführung in Scrum empfehlen wir die Lektüre von [Schwaber & Beedle 2002] oder [Pichler 2008]. Unser Ziel ist es, dem Leser die gängigen agilen Entwicklungspraktiken zusammen mit ihrem Einsatz in Scrum zu vermitteln. Natürlich ist das Ausprobieren und Anwenden der Praktiken unerlässlich, um diese kompetent handhaben zu können. Denn für agile Entwicklungspraktiken gilt»probieren geht über Studieren«und»Übung macht den Meister«. Das Buch dient außerdem zur Vorbereitung auf eine Zertifizierung wie Certified Scrum Developer (CSD) und Professional Scrum Developer (PSD).
1.3 Überblick über das Buch 3 1.3 Überblick über das Buch Keine Entwicklung beginnt mit der ersten Sprint-Planungssitzung. Kapitel 2 führt in das Konzept der Architekturvision ein und klärt, welche Anteile der Architektur vor Entwicklungsbeginn fixiert werden müssen und welche mithilfe der Techniken dieses Buches während der Entwicklung entstehen sollten. In Kapitel 3 werden die Herausforderungen dargestellt, mit denen das Team, bedingt durch Scrums iterative-inkrementelle Vorgehensweise, konfrontiert wird: der inkrementelle Entwurf. Der größte Teil des Systems samt seiner Architektur, seinem Design, dem Code und den Tests muss inkrementell entworfen und entwickelt werden. Das Kapitel führt in die Qualitätskriterien und Entwurfsprinzipien ein, denen inkrementelle Entwürfe genügen müssen. Kontinuierliche Integration (engl. Continuous Integration) verfolgt den Ansatz, Änderungen am System in kleinen Schritten vorzunehmen und diese Änderungen jeweils sofort in den gemeinsamen Quellcodebestand zu integrieren. Wie klein die Schritte sein können und wie man diese Praktik technisch umsetzt, zeigt Kapitel 4. Kapitel 5 widmet sich der Entwicklungspraktik, die oft als die wichtigste agile Praktik bezeichnet wird: testgetriebene Entwicklung (Test-Driven Development, TDD). In diesem Kapitel wird nicht nur beschrieben, dass die Tests vor dem Code entwickelt werden, sondern auch wie in kleinen Schritten der Entwurf durch Tests vorangetrieben wird. Testgetriebene Entwicklung ohne Refactoring ist undenkbar. Trotzdem haben wir uns entschieden, zwei eigene Kapitel zu Refactoring zu spendieren. Schließlich kann Refactoring auch ohne testgetriebene Entwicklung sinnvoll verwendet werden, um existierenden Code aufzuräumen. Kapitel 6 führt in die Thematik ein und erläutert, wie Refactorings manuell durchgeführt werden können. Automatisierte Refactorings sind Gegenstand von Kapitel 7. Testgetriebene Entwicklung fokussiert die Entwurfseinheiten der Entwickler in objektorientierten Programmiersprachen sind dies die Klassen. Akzeptanztests sind End-to-End-Tests des integrierten Systems aus Anwendersicht. Die heute verfügbaren Technologien erlauben es, Akzeptanztests mit vertretbarem Aufwand zu automatisierten und dabei ebenfalls testgetrieben vorzugehen. Kapitel 8 zeigt, wie das geht. Als Extreme Programming um das Jahr 2000 herum bekannt wurde, wurde es häufig auf eine besonders auffällige Technik verkürzt: das Programmieren in Paaren (engl. Pair Programming). Pair Programming und Collective Ownership (der Code gehört allen) stellen mächtige Werkzeuge dar, die für schnellen Wissensaustausch zwischen den Entwicklern sorgen und Bottleneck-Situationen im Team vermeiden. Kapitel 9 erklärt, wie die beiden Techniken funktionieren. Code-Katas und Coding-Dojos klingen zwar nach asiatischem Kampfsport, helfen dem Team aber, agile Entwicklungspraktiken systematisch einzuüben und effektiver programmieren zu lernen ohne dabei Fauststöße ausführen zu müs-
4 1 Einleitung sen oder sich womöglich eine blutige Nase zu holen. Mehr hierzu finden Sie in Kapitel 10. Kapitel 11 widmet sich der Frage, wie sich modellgetriebene Softwareentwicklung (Model Driven Software Development, MDSD) zu Scrum verhält. Welche Entwicklungspraktiken müssen ggf. angepasst werden? Werden vielleicht sogar Entwicklungspraktiken obsolet? In den letzten Jahren ist ein Trend unübersehbar: Immer mehr Scrum-Teams arbeiten verteilt. Dabei kann Off- oder Nearshoring eine Rolle spielen. Es wird aber auch häufig innerhalb eines Landes verteilt entwickelt. Kapitel 12 stellt dar, welche Entwicklungspraktiken vor dem Hintergrund verteilter Teams in einem anderen Licht erscheinen und wie damit umzugehen ist. 1.4 Java als Beispielsprache Wir haben uns aufgrund ihrer weiten Verbreitung dazu entschieden, alle Codebeispiele in diesem Buch in Java zu schreiben. Die Beispiele sollten sich aber auf andere Programmiersprachen übertragen lassen. Lediglich in Kapitel 7»Automatisierte Refactorings«mag dies aufgrund der Möglichkeiten der verwendeten Entwicklungswerkzeuge nicht immer gelingen. 1.5 Danke Ohne die Zusammenarbeit vieler Experten wäre dieses Buch niemals möglich gewesen. Unser Dank gilt daher den Autoren dieses Buches für ihren Einsatz und das geduldige Eingehen auf unser Feedback zu ihren Texten. Wir möchten uns außerdem beim dpunkt.verlag und unserer Lektorin Christa Preisendanz für die Unterstützung in allen organisatorischen Belangen bedanken. Ganz herzlich bedanken wir uns bei Markus Gärtner, Heiko Hahn und Manuel Küblböck, die das komplette Buch einem Review unterzogen und wertvolles Feedback geliefert haben. Vielen Dank auch an Markus Andrezak für das Schreiben des Geleitworts. Softwareentwicklung hat für uns auch eine ethische Komponente. Das Autorenhonorar dieses Buches spenden wir daher an die Wohltätigkeitsorganisation Oxfam.