Wie funktioniert SCRUM?

Share on FacebookShare on Google+Share on LinkedInTweet about this on TwitterShare on TumblrEmail this to someone

SCRUM ist eine Entwicklungsmethode für Software und momentan aus der Entwicklerlandschaft kaum wegzudenken. Jedoch stellt sich die Frage: was ist Scrum eigentlich? Was unterscheidet es von anderen herkömmlichen Methoden und vor allem wie funktioniert es?

scrum

scrum

Kurz gesagt glänzt SCRUM mit dem Begriff Agilität. Damit soll klar werden, dass Scrum eine nicht plangetriebene Vorgehensweise ist. Denn es passt sich der Situation an. Anforderungen können hinzukommen, neue Schwierigkeiten adäquat eingeplant werden und zeitnah reagiert werden – undenkbar bei plangetriebenen Methoden.

Plangetriebene Methoden: plangetriebene Methoden sind die Klassiker. Am Punkt Null der Entwicklungsphase ist das komplette Projekt vorgeplant und somit relativ starr und fest. Eben so ist es nicht bei Scrum!.

Für wen ist Scrum geeignet?

Im Vorfeld möchte ich noch einen wichtigen Punkt hervorheben: Scrum lässt sich nicht einfach auf jedes Team anwenden. Entgegen klassischer Methoden eignet sich Scrum lediglich für kleine Entwicklerteams.

Der Schwerpunkt liegt darauf, dass sich Scrum-Teams selber organisieren. Dazu ist es essentiell, dass das Team Kommuniziert und komplett im Bilde ist wie der Entwicklungsstand der Kollegen ist, wo es Probleme gibt usw. Dies wäre in Großen Teams schlicht unmöglich.

Möchte man die Scrum-Methode trotzdem auf große Teams anwenden, so kann man probieren aus einem großen Projekt mehrere Einheit bzw. Teilprojekte zu bilden. Ein Team könnte dann auf eines dieser Subprojekte angesetzt werden.

Scrum Rollen und Zuständigkeiten

Product Owner

Der Product Owner vertritt u.a. die Auftragsgeberseite. Er legt fest was das Projekt können soll und hat die Projekt Verantwortung. Er verwaltet die Anforderungen und pflegt und priorisiert somit das Product Backlog (wird später erklärt). In Meetings nimmt er eine sehr passive Rolle ein, denn er macht Vorschläge hat aber keine Weisungsbefugnis.

Scrum Master

Der Scrum Master ist wenn man so will der Manager des Teams. Jedoch hat er auf den Entwicklungsprozess eine ebenfalls sehr passive Rolle. Er unterstützt das Team bei der Eigenorganisation, stellt den Fluss des Prozesses sicher und schützt vor allem das Team vor äußere Einflüsse in dem er Hindernisse/Trouble beseitigt. Ebenfalls ist er der Prozess verantwortliche!

Scrum Team

Die Scrum Teams sind die Maker, die eigentlichen Produzenten. Ein Team ist idealerweise mit 5 bis 10 Personen besetzt und organisiert sich selbst. Das heißt, Anforderungen werden in Aufgaben zerlegt und selber zugeteilt. Ebenfalls sind die Teams interdisziplinär zusammengesetzt und kümmern sich um Entwicklung, Dokumentation und Tests. Jedes Mitglied des Teams kennt die große und ganze Vision des Projekts und kennt den Entwicklungsstand.

Sprint

Der Sprint ist der zentralste Punkt in Scrum und stellt die eigentliche Ablaufeinheit dar. Im Sprint werden die zugeteilten Aufgaben ausgeführt und klare Ergebnisse zum Ende des Sprints sind definiert. Idealerweise dauert der Sprint zwei bis vier Wochen. Das gesamte Projekt ist in eine Vielzahl von Sprints aufgeteilt.

Scrum Diagramm

Scrum Diagramm

Scrum Meetings

Sprint Planing

Im Sprint Planing wird festgelegt was im nächsten Sprint gemacht wird. Es findet vor dem Beginn des Sprints statt. Dabei legt der Prodoct Owner die Prioritäten fest und das Team bewertet die Machbarkeit. Das Team entscheidet demokratisch darüber wie lang eine Aufgabe (ToDo) dauern wird und auch wer diese Aufgabe übernimmt.

Daily Sprint Meeting

Das Daily Sprint Meeting ist ein reines Infomeeting (auch bekannt als Stand-Up Meeting). Es dient dazu alle Teammitglieder auf den neusten Stand zu bringen, kurz zu informieren was jeder einzelne gerade macht und wo es evtl. Schwierigkeiten gibt. Hier soll nicht über Lösungen diskutiert werden. Das gesamte Meeting soll nicht länger als 15 Minuten dauern.

Sprint Review/Retrospektive

Die Sprint Review wird am Ende des Sprints durchgeführt und stellt eine Art kleine Abnahme vom Product Owner dar. Ebenfalls soll hier darüber gesprochen werden, was im letzten Sprint gut bzw. schlecht lief, da Scrum von einer ständigen Prozessverbesserung getrieben wird.

Die Sprint Review kann auch als Meilenstein verstanden werden, in Bezug auf die kleine Abnahme. Denn hier sind klare Ergebnisse für einen bestimmten Zeitpunkt (Ende des Sprints) definiert

Scrum Artefakte

Scrum bringt einige Artefakte hervor. Damit sind im eigentlichen Abbildungen des Prozesses, Anforderungen und ToDo’s gemeint.

Product Backlog

Das Product Backlog stellt eine Liste mit gewünschten Anforderungen dar. Dieser wird vom Product Owner gepflegt und priorisiert. Auch erweiterte und geänderte Anforderungen finden hier Platz. Im Grunde stellt es das Lastenheft dar. Üblicherweise wird in Scrum das Product Backlog an einer Tafel/Pinnwand mit Kärtchen und Zetteln dargestellt.

Sprint Backlog

Das Sprint Backlog stellt dann die Anforderungen dar die für den nächsten Sprint aus dem Product Backlog rausgepickt wurden und erledigt werden sollen.

Burn Down Chart

Das Burn Down Chart basiert auf den Anforderungen des Sprint Backlogs und wird täglich aktualisiert. Damit wird dargestellt welche Aufgaben des Sprints noch zu machen sind und vor allem welche schon erledigt sind. Dieses ist in Scrum essentiell da es eine einfache Methode darstellt, wie alle Scrum-Mitglieder über den aktuellen Stand des Sprints informiert werden können.

Woher kommt der SCRUM-Begriff?

Der Begriff Scrum kommt eigentlich aus der Sportart Rugby. Er bezeichnet das Gedränge bei dem beide Teams auf den Ball stürzen.

Ich Zitiere eine interessierte Google+ Leserin

Ein ganz wichtiger Erfolgsfaktor ist auch der stabile Scope während eines Sprints. Gewünschte Features und Prioritäten ändern sich gerne mal während der Laufzeit eines Projekts. Mit längeren Laufzeiten umso mehr. Wenn vom Entwicklungsteam erwartet wird, auf solche Änderungen sofort zu reagieren, ergeben sich viele Task-Wechsel, sowie Feature-Creep, und die Produktivität und Planbarkeit sinkt. Im Scrum-Prozess dürfen zwar jederzeit neue Features und Prioritäten in das Produkt-Backlog eingelastet werden, aber niemals in das laufende Sprint-Backlog.

Danke Christa für den guten Einwurf.

Share on FacebookShare on Google+Share on LinkedInTweet about this on TwitterShare on TumblrEmail this to someone

MrKnowing

Programmierer und Wissensnerd! Kontaktiere mich auf Google+ oder einfach per Mail danny@mrknowing.com

You may also like...

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>