Scrum - ein kurzer Überblick

Demnächst steht bei uns die Umsetzung eines größeren Drupal-Projekts an. Wir wollen für einen Verlag eine Produktdatenbank auf Basis von Drupal 7 entwickeln und es werden ca. 4 Entwickler bis Mitte Juni beschäftigt sein. Jeder, der sich mit Softwareentwicklung beschäftigt, kennt vermutlich die Probleme, die bei länger laufenden Projekten gerne einmal auftreten: Der Kunde hat oft zu Beginn noch keine 100% konkrete Vorstellung vom gewünschten Endergebnis oder es ergeben sich betriebsbedingt neue Anforderungen und deshalb ändern sich Erfordernisse im Rahmen der Projektumsetzung. Das führt dazu, dass die in einem Pflichtenheft zu Beginn des Projektes definierten und umgesetzten Anforderungen am Ende gar nicht mehr den tatsächlichen Anforderungen des Kunden zu 100% entsprechen.

Um dies wenn möglich zu vermeiden, haben wir (Software-Entwicklung, Projektmanagement und Geschäftsleitung) beschlossen, das Projekt mit Hilfe von Scrum umzusetzen. So können wir flexibel auf Änderungen der Anforderungen reagieren, der Kunde ist sehr nah an den Entwicklungsprozess angebunden und wir vermeiden unliebsame Überraschungen am Ende des Projekts. Im monatlich stattfindenden KnowledgeLab der Cocomore IT hatte ich deswegen gestern die Aufgabe, einen kleinen Einblick in Scrum zu geben. Sicherlich ein sehr großes Thema, das sich nicht in einem 1-stündigen Vortrag abhandeln lässt. Deswegen habe ich mich auf die wesentlichen Aspekte wie Rollen, Meetings und Artefakte von Scrum beschränkt und anschließend mit Hilfe von Lego Scrum versucht, meinen Kollegen die Methode näher zu bringen.

Scrum - ein Vorgehensmodell der agilen Software-Entwicklung

Agile Software-Entwicklung zeichnet sich vor allem durch ein iteratives Vorgehen aus. Planungs- und Entwicklungsphasen wechseln sich ab. Dies hat den Vorteil, dass Teile des zu entwickelnden Systems früh getestet werden können. Dadurch sinkt das Risiko, dass in die falsche Richtung entwickelt wird. Vielmehr kann schnell und flexibel auf Änderungen und Anpassungen reagiert und die Anforderungen neu definiert werden.

Motiviation

Der Begriff "Scrum" kommt eigentlich aus dem Rugby und bedeutet "Gedränge". Die Spieler stehen dabei eng aneinander gedrängt in einem kreisförmigen Gebilde und versuchen den Gegner daran zu hindern, Raum zu gewinnen. Auf den ungeübten Zuschauer mag das wie ein ungeordnetes Geschubse wirken, allerdings stecken dahinter taktische Regeln (so liest man zumindest ;)). Der Vergleich ist recht passend, denn wie beim Rugby gibt es auch bei Scrum ein Team, das zusammenhält und sich streng an die wenigen, dafür aber klar definierten Regeln hält. Überhaupt spielt das Team bei Scrum die wichtigste Rolle. Anders als beim klassischen Vorgehen nach dem Wasserfallmodell entscheidet das Team selbst, wie lange es für die Umsetzung der vom Product Owner vorgegebenen Aufgaben braucht und welche Aufgaben es in einem Sprint umsetzen kann.

Rollen

Womit wir auch gleich bei den Rollen im Scrum wären. Neben externen Rollen wie Kunde, Manager und User gibt es innerhalb des Scrum-Teams drei Rollen: Product Owner, Team und ScrumMaster.
Der Product Owner vermittelt dem Team die Vision des Produkts, das es zu entwickeln gilt. Er steht hierbei im engen Kontakt mit dem Kunden. Er definiert die Produkteigenschaften und priorisiert diese. Nach jedem Sprint ist er dafür zuständig, die vom Team gelieferte Funktionalität abzunehmen.
Das Team liefert die Produktfunktionalität in der vom Product Owner gewünschten Reihenfolge. Es ist verantwortlich dafür, die zuvor vereinbarten Qualitätstandards einzuhalten. Die Dauer eines einzelnen Tasks wird durch das Team gemeinschaftlich bestimmt, ebenso legt das Team fest, wie viele Funktionalitäten es in einem Sprint liefern kann.
Die Aufgabe des ScrumMasters ist es, dem Team bei der Umsetzung seiner Ziele zu helfen. Dies geschieht nicht, in dem er sich an der Entwicklung beteiligt oder Einfluss auf die Entscheidungen des Teams nimmt. Vielmehr ist er dafür verantwortlich, alle Störungen, die die Produktivität des Teams behindern, zu beseitigen. Außerdem muss er darauf achten, dass der Scrum-Prozess eingehalten wird.

Meetings & Artefakte

Zu Beginn der Entwicklung definiert der Product Owner die Tasks, die zur Erreichung des gewünschten Ziels erforderlich sind. Diese Tasks werden in den Product Backlog aufgenommen. Idealerweise werden diese Backlog Items mit Hilfe von User Stories definiert, die Anforderungen sind somit nutzer- und nicht technik-orientiert. Zu jeder User Story sollte es mindestens einen User-Acceptance-Test geben. Dieser hilft nicht nur bei der Entwicklung, sondern auch am Ende eines Sprints bei der Abnahme einer Funktionalität. Im Sprint Planning Meeting 1 stellt der Product Owner die einzelnen Backlog Items vor und erläutert diese. Das Team ist dazu angehalten, Unklarheiten zu hinterfragen und so eine möglichst genaue Vorstellung davon zu bekommen, was der Product Owner von ihnen erwartet. Anschließend schätzt das Team, wie lange es für die Umsetzung eines Items benötigen würde. Nach dieser Schätzung kann der Product Owner die Backlog Items erneut priorisieren und das Sprint Ziel wird definiert.
Im darauffolgenden Sprint Planning Meeting 2 werden die Backlog Items in den Sprint Backlog übernommen. Falls die einzelnen Tasks zu groß sind, werden sie noch einmal in kleinere Tasks herunter gebrochen. Ziel ist es, Aufgaben zu erhalten, deren Erledigung nicht länger als einen Tag dauert. Das Sprint Backlog wird während des Sprints auch dazu genutzt, um zu dokumentieren, welches Teammitglied sich mit welchen Tasks befasst und in welchem Status sich die einzelnen Task befinden. Dazu enthält es die Spalten "ToDo", "Work in Progress" und "Done", in die die Tasks einsortiert werden können.
Der Sprint kann also starten. Ein Sprint hat immer dieselbe Länge, diese sollte zwischen 14 und 30 Tagen liegen. Jeden Tag findet ein Daily Scrum statt. In diesem 15-minütigen Meeting sagt jedes Teammitglied, was es am vorigen Tag erreicht hat und was es für den aktuellen Tag plant. Probleme und Hindernisse werden angesprochen. Wenn deren Klärung allerdings den Zeitrahmen sprengen würde, nimmt der ScrumMaster es in seinen Impediment Backlog auf. Dieser enthält alle Hindernisse, um deren Beseitigung sich der ScrumMaster kümmern muss.
Der Sprint endet mit dem Sprint Review. In diesem Meeting präsentiert das Team die geleistete Arbeit. Der Product Owner prüft, ob die fertiggestellten Tasks seinen Anforderungen entsprechen. Es werden nur solche Tasks akzeptiert, die wirklich fertig sind. Instabile oder ungetestete Items wandern zurück in den Product Backlog. In einem Burndown Chart kann der Fortschritt der Arbeit festgehalten werden. Dazu werden auf der x-Achse der Zeitverlauf und auf der y-Achse die noch offenen Tasks markiert. So kann über alle Sprints hinweg visualisiert werden, wie viel Arbeit bereits erledigt wurde und was noch offen ist.

So viel also zur Theorie. Wie bereits eingangs erwähnt, das Thema ist relative komplex und nicht wirklich dafür geeignet, um in ein paar Sätzen erklärt zu werden. Deswegen nun zum spaßigen Teil..

Lego Scrum

Die Aufgabe war es, eine Stadt zu bauen. Also erst einmal die Legos vom Speicher kramen (ich hoffe, mir hat niemand übelgenommen, dass sie ein wenig eingestaubt waren) und dann überlegt, was ich gerne alles in meiner Stadt hätte. Ich wollte: Häuser, eine Schule, eine Bushaltestelle, ein Simpsons-Denkmal und noch ein paar andere Dinge. Die gewünschten Objekte habe ich auf Zettel geschrieben und an unseren Backlog gepinnt. Zuerst wurde nun vom Team gemeinschaftlich mit Planning Poker die Größe der einzelnen Items definiert. Es wurde natürlich viel diskutiert, ob z.B. eine Grundschule "größer" als eine Kirche ist, nach einigen Durchläufen konnten sie sich aber doch meistens einigen. Danach wurde überlegt, was in einem Sprint umgesetzt werden konnte und die Backlog Items wurden ins Sprint Backlog übertragen.

Ein Sprint dauerte genau 3 Minuten, insgesamt gab es drei Sprints. Nach jedem Sprint durfte ich dann gnadenlos zerreißen, was nicht meinen Anforderungen entsprach ;) Natürlich gab es auch hierbei hitzige Diskussionen darüber, ob ein Gebäude nicht doch schon fertig war und es wurde um Fenster, Türen und Kreuze gefeilscht. Aber am Ende lag die Entscheidung dann eben doch bei mir als Product Owner, und so wanderten einige Objekte wieder zurück in den Product Backlog. Und schon ging es weiter mit der nächsten Sprintplanung und dem nächsten Sprint, und am Ende hatten nur die Kirche und die Grundschule noch kleine Mängel, der Rest der Stadt stand wie gewünscht.

Das Ganze hat auf jeden Fall viel Spaß gemacht, und vielleicht hat es ja auch ein bisschen dazu beigetragen, Teile von Scrum etwas besser zu verstehen.

Und hier das Ergebnis, unsere schöne bunte Lego Stadt