Agile Entwicklungspraktiken mit Scrum

Von Roman Pichler und Stefan Roock

Scrum ist ein agiles Management-Framework, das keine Entwicklungspraktiken empfiehlt oder gar vorschreibt. Auswahl und Einsatz der richtigen Praktiken fallen unter die Selbstorganisation des Teams. Ohne den Einsatz geeigneter Entwicklungspraktiken und -tools ist der Einsatz von Scrum in der Softwareentwicklung jedoch nicht dauerhaft erfolgreich. Dieses Buch beschreibt praxisnah die wichtigsten Praktiken wie Architekturvision, inkrementeller Entwurf, Continuous Integration, testgetriebene Entwicklung, Refactoring, Akzeptanztests sowie modellgetriebene und verteilte Entwicklung mit Scrum.

• Sprache: Deutsch
• Herausgeber: dpunkt.verlag
• Erscheinungsdatum: 2. Dez. 2011
• ISBN: 9783898648547

Buchvorschau

Agile Entwicklungspraktiken mit Scrum

f00ii-01

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.

f00ii-02

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

pub

Roman Pichler

[e-mail]

Stefan Roock

[e-mail]

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

f000v-01

Für die kleinen »Roockies« Mika und Levi

Stefan Roock

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

Inhalt

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

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

Rezensionen für Agile Entwicklungspraktiken mit Scrum

[rrestout · Bewertung: 3 von 5 Sternen]

The book doesn't add much to the current literature.Most of it can be found in most other agile project management books. During all the time I was reading it, i was wondering whether the target audience was product managers/owners or scrum masters!What is not in other agile development books can be found in other product management books/blogs/articles or even in the Pragmatic Marketing framework.To summarize I fully agree with TadAd: There just isn't enough to justify purchasing this

[tadad_1 · Bewertung: 2 von 5 Sternen]

The book is 118 pages long. When I think about the duplication in various sections of it, there's probably around half that many pages of content. I'd divide that content into two type of material. The first is the same introductory information that you'd get if you downloaded Schwaber and Sutherland's overview of Scrum from scrum.org. The second type of material consists of discussions about pitfalls in implementing Scrum, pitfalls in management practices, as well as a very brief look at things like burndown charts and different ways of slicing a development project.That first type of material is available for free; this book is $35...you do the math on that one. The second type of material isn't weighty enough to carry the price load—I really see it as a 25 page introductory chapter in a larger book that provides some real meat.There just isn't enough here to justify purchasing this. Put the money toward something that provides more depth.