Kapitel 1
Einführung in Scrum
Am Ende dieses Kapitels werden Sie in der Lage sein, die folgenden Aufgaben durchzuführen:
Zuweisen von Rollen an die wichtigsten Stakeholder des Projekts
Beschreiben der unterschiedlichen Dokumente und anderer Artefakte, die Scrum benötigt und produziert
Messen des Fortschritts eines Scrum-Projekts im Lauf seiner Entwicklung
Diagnostizieren von Problemen bei Scrum-Projekten und Vorschlagen von Gegenmitteln
Abhalten von produktiven Scrum-Meetings, die allen Beteiligten nützen
Begründen, warum Scrum und nicht andere agile oder rigide Methodologien eingesetzt werden
Scrum ist eine Methodologie für die Projektverwaltung. Genauer gesagt handelt es sich um eine agile Methodologie. Das zentrale Konzept von Scrum beruht darauf, den Nutzen eines Softwareprodukts iterativ, also phasenweise, zu steigern. Der gesamte Scrum-Prozess wird mehrmals wiederholt (die Iterationen), bis das Softwareprodukt als vollständig beurteilt oder der Prozess abgebrochen wird. Diese Iterationen werden als Sprints bezeichnet. Sie münden in einer Software, die als fertiges Produkt freigegeben werden kann. Die gesamte Arbeit wird im sogenannten Produkt-Backlog (Produkt-Rückstand) in Prioritäten eingestuft, und bei Beginn jedes Sprints legt das Entwicklungsteam fest, welche Arbeiten es in der aktuellen Iteration erledigen wird, indem es diese Arbeiten im Sprint-Backlog festhält. Eine Arbeitseinheit innerhalb von Scrum wird als Story (Geschichte) bezeichnet. Das Produkt-Backlog ist eine nach Prioritäten sortierte Liste abzuarbeitender Stories, und jeder Sprint wird durch die Stories definiert, die während einer Iteration entwickelt werden. Abbildung 1–1 zeigt einen Überblick des Scrum-Prozesses.
Abb. 1–1 Scrum ähnelt einer Fertigungsstraße für kleine Features eines Softwareprodukts
Scrum umfasst verschiedene Dokumentationsartefakte, Rollen, die von Personen innerhalb und außerhalb des Entwicklungsteams übernommen werden, und Zeremonien, das heißt Meetings, an denen die relevanten Gruppen teilnehmen. Ein einziges Kapitel reicht nicht aus, um alle Vorteile von Scrum als Projektverwaltungsmethode aufzuzeigen, aber dieses Kapitel sollte Ihnen einen ausreichenden Überblick vermitteln, damit Sie sich bei Bedarf tiefer in bestimmte Teilbereiche einarbeiten können und die Bedeutung der üblichen Scrum-Verfahren durchblicken.
Scrum ist agil
Unter dem Begriff agil (engl. agile) wird eine Familie schlanker Softwareentwicklungs-methoden zusammengefasst, die es ermöglichen, auf geänderte Anforderungen der Kunden auch dann noch zu reagieren, wenn das Projekt bereits läuft. Agile Methoden sind die Antwort auf die Nachteile von Verfahren, die rigider strukturiert sind. Das Agile-Manifest macht diesen Gegensatz deutlich, Sie finden es unter www.agilemanifesto.org.
Das Agile-Manifest wurde von 17 Softwareentwicklern unterzeichnet. Die Agile-Methode hat in den letzten Jahren so stark an Einfluss gewonnen, dass Erfahrung in einer agilen Umgebung zur unverzichtbaren Voraussetzung für einen Posten im Rahmen der Softwareentwicklung geworden ist. Scrum ist eine der am häufigsten genutzten Implementierungen eines agilen Prozesses.
Scrum und Wasserfall
Ich habe die Erfahrung gemacht, dass in der Softwareentwicklung der agile Ansatz besser funktioniert als das Wasserfallmodell (engl. waterfall), daher empfehle ich grundsätzlich nur agile Prozesse. Das Problem bei der Wasserfallmethode ist ihre Inflexibilität. Abbildung 1–2 zeigt die Abläufe bei einem Wasserfallprojekt.
Abb. 1–2 Der Entwicklungsprozess bei der Wasserfallmethode
Die Ergebnisse jeder Phase werden dabei zur Basis der nächsten Phase, und jede Phase wird vollständig abgeschlossen, bevor die nächste in Angriff genommen wird. Das setzt voraus, dass keine Fehler, Probleme, ungelösten Fragen oder Missverständnisse mehr auftauchen, nachdem eine Phase abgeschlossen ist. Die Pfeile zeigen nur in eine Richtung.
Der Wasserfallprozess geht außerdem davon aus, dass nach Abschluss einer Phase keine Änderungen mehr vorgenommen werden. Diese Annahme lässt sich angesichts der eigenen Erfahrung und zahlreicher Untersuchungen einfach nicht aufrechterhalten. Änderungen gehören einfach zum Leben dazu, nicht nur bei der Softwareentwicklung. Wasserfallansätze behandeln Änderungen als etwas, das teuer und unerwünscht ist und daher unbedingt vermieden werden sollte. Wasserfallmethoden basieren auf dem Konzept, dass sich Änderungen vermeiden lassen, wenn man mehr Zeit auf die Ausarbeitung von Anforderungen und Entwurf verwendet. In diesem Denkkonzept tauchen Änderungen während der nachfolgenden Phasen schlicht nicht auf. Das ist natürlich lächerlich, weil sich immer Änderungen ergeben.
Das Agile-Konzept begegnet diesem Problem, indem es einen fundamental anderen Ansatz verwendet, in dem Änderungen als etwas Positives betrachtet werden und jeder die Gelegenheit erhält, sich an alle auftretenden Änderungen anzupassen. Das Agile-Konzept und somit auch Scrum lassen zwar Änderungen auf Prozessebene zu, aber auf das Ziel künftiger Änderungen hin zu programmieren ist eine der schwierigsten und gleichzeitig wichtigsten Ziele moderner Softwareentwicklung. Dieses Buch will Ihnen zeigen, wie Sie Code erstellen, der so agil und adaptiv ist, dass er Änderungen übersteht.
Wasserfallmethodologien sind außerdem dokumentzentriert, das heißt, sie produzieren große Mengen an Dokumentation, die nicht direkt das Softwareprodukt verbessert. Bei den Agile-Methoden wird dagegen die lauffähige Software als wichtigstes Dokument eines Softwareprodukts betrachtet. Das Verhalten der Software wird schließlich durch ihren Quellcode gesteuert, nicht durch die Dokumente, die begleitend zum Code verfasst wurden. Und weil die Dokumentation vom Quellcode getrennt ist, kann es leicht passieren, dass sie nicht mehr mit der Software übereinstimmt.
Scrum definiert einige Kennzahlen, die Rückmeldungen zum Fortschritt eines Projekts und seinem Gesamtzustand liefern, aber das ist etwas anderes als eine erklärende Dokumentation über das Produkt. Agile-Methoden empfehlen im Allgemeinen, nur so viel Dokumentation zu produzieren, dass das Projekt nicht ins Unverantwortliche abkippt, aber sie schreiben eine solche Dokumentation meist nicht vor. Es gibt durchaus Code, der von ergänzender Dokumentation profitiert, sofern sie nicht einmal geschrieben und dann nie wieder gelesen wird. Aus diesem Grund sind lebendige, einfach zu nutzende Dokumente, wie beispielsweise Wikis, wichtige Werkzeuge in Scrum-Teams.
Der Rest dieses Kapitels behandelt die wichtigsten Aspekte von Scrum genauer. Dabei konzentrieren wir uns nicht auf pures Scrum, sondern auf eine beliebte Variante. Das Ziel von Scrum als Prozess besteht nicht nur darin, das Softwareprodukt iterativ zu verbessern, sondern auch den Entwicklungsprozess. Das animiert die Teams, kleine Änderungen vorzunehmen und so dafür zu sorgen, dass sich der Prozess optimal für ihre konkrete Situation eignet.
Nachdem die folgenden Abschnitte die Elemente von Scrum vorgestellt haben, analysiert der Rest des Kapitels ihre Schwächen. Dieses Kapitel bildet die Basis für das übrige Buch, das genauer ausführt, wie Sie Code so implementieren, dass er adaptiv ist und somit Änderungen ermöglicht, die im Scrum-Prozess als etwas Positives aufgefasst werden. Es wäre sinnlos, einen Prozess zu nutzen, in dem Sie den Anspruch erheben, Änderungen problemlos implementieren zu können, wenn in Wirklichkeit jegliche Änderung auf Codeebene unglaublich schwierig zu implementieren ist.
Unterschiedliche Formen von Scrum
Wenn ein Entwicklungsteam behauptet, eine Scrum-Methodologie umzusetzen, heißt das meist, dass sie eine Variante von Scrum einsetzen. Pures Scrum umfasst nur wenige Verfahren, die aus anderen Agile-Methoden übernommen wurden, zum Beispiel Extreme Programming (XP). Es gibt drei Unterkategorien von Scrum, die sich jeweils weiter von der reinen Lehre entfernen.
Scrum und …
Verfahrensempfehlungen wie die, zuerst die Unit-Tests zu schreiben und paarweise zu programmieren, sind nicht Bestandteil von Scrum. Viele Teams betrachten sie aber als nützliche Ergänzungen des Prozesses, daher werden sie oft als ergänzende Verfahren übernommen. Werden bestimmte Verfahren aus anderen Agile-Methoden wie XP oder Kanban übernommen, wird der Prozess zu »Scrum und …« (engl. »Scrum and«), das heißt: Scrum plus zusätzliche Verfahren, die den Scrum-Standardprozess erweitern, aber nicht beeinträchtigen.
Scrum, aber …
Manche Entwicklungsteams behaupten zwar, Scrum einzusetzen, lassen aber Kernaspekte außen vor. Ihre Arbeit wird durch ein Backlog bestimmt, das in iterative Sprints eingeht, und sie halten Retrospectives und tägliche Stand-Up-Meetings ab. Aber sie nehmen keine Einstufung in Story-Punkte vor, sondern bevorzugen Echtzeiteinstufungen. Solche...