Agile Entwicklungspraktiken mit Scrum

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 . . . . . . . . . . . . . . . . . . . . .

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 Manage- ment, 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 Entwicklungs- praktiken 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. Letz- tere 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 hoch- wertiges Produktinkrement ist das Einholen von hilfreichem Feedback von Kun- den, 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 Entwick- lungspraktiken sollten aber zum Handwerkszeug eines Scrum-Entwicklers gehö- ren. Denn nur so ist das Team in der Lage, über den Einsatz der richtigen Prakti- ken zu entscheiden. Softwareentwickler im Scrum-Team sollten die gängigen agilen Entwicklungs- praktiken 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 Wertorien- tierung 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, Program- mierer, 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 Auspro- bieren und Anwenden der Praktiken unerlässlich, um diese kompetent handha- ben 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 Certi- fied 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 Architek- tur vor Entwicklungsbeginn fixiert werden müssen und welche mithilfe der Tech- niken 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 entwi- ckelt 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 Develop- ment, 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 ver- wendet werden, um existierenden Code aufzuräumen. Kapitel 6 führt in die The- matik 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. Akzeptanz- tests 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. Kapi- tel 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 Wissens- austausch 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 Softwareent- wicklung (Model Driven Software Development, MDSD) zu Scrum verhält. Wel- che 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 Code- beispiele in diesem Buch in Java zu schreiben. Die Beispiele sollten sich aber auf andere Programmiersprachen übertragen lassen. Lediglich in Kapitel 7 »Automa- tisierte 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 wert- volles Feedback geliefert haben.