Ihre Browserversion ist veraltet. Wir empfehlen, Ihren Browser auf die neueste Version zu aktualisieren.

Scrum

 

Scrum (englisch für Gedränge) ist ein schlanker, agiler Prozess für Projektmanagement u. a. in der Softwareentwicklung. Der Ansatz von Scrum ist empirisch,inkrementell und iterativ.

Scrum versucht die Komplexität durch  vier Prinzipien zu strukturieren

  1. Zerlegung:  Der Weg zur Lösung wird in einzelne gut überprüfbare Schritte zerlegt.
  2. Transparenz:  Der Fortschritt und die Hindernisse eines Projektes werden täglich und für alle sichtbar festgehalten.
  3. Überprüfung: In regelmäßigen Abständen werden Produktfunktionalitäten geliefert und beurteilt.
  4. Anpassung: Die Anforderungen an das Produkt werden nicht ein und für alle mal festgelegt, sondern nach jeder Lieferung neu bewertet und bei Bedarf angepasst.

 Scrum reduziert die Komplexität der Aufgabe nicht, strukturiert sie aber in kleinere und weniger komplexe „Häppchen“, den Inkrementen.

 

Geschichte (UR-Scrum )

Von Jeff Sutherland im Jahr 1993 erfunden und unter Mithilfe von Ken Schwaber weiterentwickelt und Anlässlich der OOPSLA-Konferenz im Jahr 1995 veröffentlicht

Besteht aus 3 Phasen

 

Planung: Definition eines neuen Release auf Basis des aktuell bekannten Backlog

Development: Entwicklung der neue Release-Funktionalität, mit konstante Bezug auf die Variablen: Zeit, Funktionalität, Kosten und Qualität.

Abschluss: Vorbereitung der Freigabe mit Abschluss-Dokumentation, Test und Freigabe

 

 

 

 

Grundlegendes

 Scrum verkörpert die Werte der agilen Software-Entwicklung, die 2001 im Agilen Manifest von Ken Schwaber, Jeff Sutherland und anderen formuliert wurden

 

Individuen und Interaktionen gelten mehr als Prozesse und Tools.


Funktionierende Programme gelten mehr als ausführliche Dokumentation.


Die stetige Zusammenarbeit mit dem Kunden steht über Verträgen.


Der Mut und die Offenheit für Änderungen steht über dem Befolgen eines festgelegten Plans.

 

 

In Scrum

 ist das eigentliche Artefakt „der Plan selbst“, relativ unwichtig 
essenziell ist die aber die Aktivität: „das Planen“

-> responding to Change over following a plan

 

Scrum besteht  aus

Einfachen Regeln
Wenigen Rollen
Mehrere Meetings
Einige Artefakte / Werkzeuge
Iteratives Vorgehen
Selbstorganisierte, interdisziplinäre Teams

Das Scrum-Vorgehensmodell kennt ursprünglich explizit drei Rollen mit jeweils verschiedenen Verantwortungen: Product Owner, Entwicklungsteam und Scrum Master sowie drei Zeremonien: Sprint Planning, Sprint Review undDaily Scrum, und drei Artefakte: Product Backlog, Sprint Backlog und Burndown Chart.

In den Jahren 2005 bis 2011 hat sich jedoch herausgestellt, dass diese Vereinfachung nicht zutreffend ist, und verschiedene Autoren, darunter auch Ken Schwaber selbst, machten klar, dass weitere Rollen, „Zeremonien“ und Artefakte erwähnt werden müssen, wenn man Scrum als Management Framework verstehen will.

 

Rollen

Bei Scrum gibt es insgesamt sechs Rollen, von denen drei (Entwicklungsteam, Product Owner und Scrum Master) zum Scrum-Team (nicht zu verwechseln mit dem Entwicklungsteam) gehören. Die übrigen drei (Management, Customer und User) sind externe Rollen, aber dennoch für das Gelingen von Scrum von großer Bedeutung.

 

Produkt-Owner

Der Product Owner ist für die strategische Produktentwicklung zuständig. Seine Verantwortung beinhaltet die Konzeption und Mitteilung einer klaren Produktvision, die Festlegung und Priorisierung der jeweils zu entwickelnden Produkteigenschaften sowie die Entscheidung darüber, ob die vom Entwicklungsteam am Ende jedes Sprints gelieferte Funktionalität akzeptabel ist. Der Product Owner gestaltet das Produkt mit dem Ziel, den wirtschaftlichen Nutzen für das eigene Unternehmen zu maximieren.Ihm allein obliegt die Entscheidung über Auslieferungszeitpunkt, Funktionalität und Kosten. Als „oberster Produktentwickler“ hält der Product Owner Rücksprache mit dem Kunden und versucht, dessen Bedürfnisse und Wünsche in die Produktentwicklung einfließen zu lassen.

Entwicklungsteam

Das Entwicklungsteam ist für die Lieferung der Produktfunktionalitäten in der vom Product Owner gewünschten Reihenfolge verantwortlich. Zudem trägt das Entwicklungsteam die Verantwortung für die Einhaltung der zuvor vereinbarten Qualitätsstandards. Das Entwicklungsteam ist insofern autonom, als es allein entscheidet, wie viele Funktionalitäten es in einem Sprint liefern will. Hierzu geht es im Sprint Planning  ein „Commitment“ ein, in dem es sich zum Erreichen der freiwillig ausgewählten Ziele verpflichtet.
Zu den weiteren Aufgaben eines Entwicklungsteams zählt die Schätzung des Umfangs einer jeden User Story (im Estimation Meeting) sowie das Herunterbrechen der für einen Sprint ausgewählten User Stories in technische Arbeitsschritte (so genannte Tasks), deren Bearbeitung in der Regel nicht länger als einen Tag dauert.

Scrum Master

Der Scrum Master ist dafür verantwortlich, dass Scrum gelingt. Dazu arbeitet er mit dem Entwicklungsteam zusammen, gehört aber selber nicht zu ihm. Er führt die Scrum-Regeln ein und überprüft deren Einhaltung, moderiert die Meetings und kümmert sich um jede Störung des Scrum-Prozesses. Arbeitsmittel des Scrum Master ist das Impediment Backlog. Darin festgehalten sind alle Hindernisse („Impediments“), die das Entwicklungsteam an effektiver Arbeit hindern. Der Scrum Master ist verantwortlich für die Beseitigung dieser Hindernisse.
Ein Scrum Master ist gegenüber dem Entwicklungsteam eine Führungskraft, aber kein Vorgesetzter. Weder kann er einzelnen Team-Mitgliedern konkrete Arbeitsanweisungen geben, noch kann er diese beurteilen oder disziplinarisch belangen. Der Scrum Master sichert sich Anerkennung und Gefolgschaft, indem er sich der Bedürfnisse der Team-Mitglieder annimmt.

Customer (externe Rolle)

Mit Customer (Kunde) ist der Auftraggeber gemeint, dem das Produkt nach Fertigstellung zur Verfügung gestellt wird. Customer kann je nach Situation sowohl die interne Fachabteilung als auch ein externer Kunde sein. Es ist Aufgabe des Product Owners, seinen Customer durch Lieferung des Wunschproduktes zu begeistern. Deshalb sollten Product Owner und Customer für die Dauer des Projektes im engen Austausch stehen. Vor Beginn der Entwicklung sollte der Product Owner ein möglichst genaues Verständnis von der Wunschvorstellung seines Customers gewinnen. Und der Customer sollte schon nach den ersten Sprints Gelegenheit haben, sich die neuen Funktionalitäten anzuschauen und hierzu Feedback zu geben. Schließlich ist Scrum explizit darauf ausgerichtet, dass sich die Liste der gewünschten Produktfunktionalitäten während der Entwicklungsphase ändert.

User (externe Rolle)

Die Rolle des Users (Anwender) umfasst diejenigen Personen, die das Produkt benutzen. Der User kann, muss aber nicht zugleich der Kunde sein. Die Rolle des Users ist für das Team von besonderer Bedeutung, denn nur der User kann das Produkt aus der Perspektive des Benutzers beurteilen, der die eigentliche Zielgruppe darstellt. Der User sollte beim Sprint Planning sowie beim Sprint Review hinzugezogen werden, um ihn das Produkt ausprobieren zu lassen und Feedback darüber einzuholen.

Management (externe Rolle)

Das Management gehört ebenso wenig zum Scrum-Team wie der User und der Customer. Doch trägt es Verantwortung dafür, dass die Rahmenbedingungen für gelingendes Scrum stimmen. Dazu gehören die Bereitstellung von materiellen Ressourcen (Räumlichkeiten, Arbeitsmittel), aber auch genereller die Unterstützung für den eingeschlagenen Kurs. Das Management ist dafür verantwortlich, das Scrum-Team vor externen Arbeitsanforderungen zu schützen, adäquate personelle Besetzungen zu finden sowie den Scrum Master dabei zu unterstützen, Hindernisse auszuräumen.

 

Meetings

 

Spring Plannings Meeting

Die Arbeit, die während des Sprints zu erledigen ist, wird im Sprint Planning geplant. Der Arbeitsplan wird in gemeinschaftlicher Arbeit durch das gesamte Scrum Team erstellt. Das Sprint Planning ist für einen einmonatigen Sprint auf ein Zeitfenster von acht Stunden begrenzt (time-box). Für kürzere Sprints wird die Dauer des Sprint Plannings proportional angepasst. Zum Beispiel dauert das Sprint Planning für einen zweiwöchigen Sprint vier Stunden. Das Sprint Planning ist in zwei Teile aufgegliedert, von denen jeder Teil die Hälfte der Dauer einnimmt, die für die gesamte Besprechung zur Verfügung steht. Jeder der beiden Teile liefert eine Antwort auf eine spezifische Fragestellung:

Was wird im Produktinkrement als Ergebnis des aktuellen Sprints ausgeliefert?

Wie wird die Arbeit umgesetzt, um das gewünschte Ergebnis zu erreichen?

Am Ende des Sprint Plannings sollte das Entwicklungs-Team in der Lage sein, dem Product Owner und dem Scrum Master zu erläutern, wie es beabsichtigt, das Sprint-Ziel selbstorganisiert zu erreichen und wie das erwartete Produktinkrement erstellt werden soll.

Daily Scrum

Zu Beginn eines jeden Arbeitstages trifft sich das Scrum-Team zu einem max. 15-minütigen Daily Scrum. Zweck des Daily Scrums ist der Informationsaustausch. Im Daily Scrum werden keine Probleme gelöst – vielmehr geht es darum, sich einen Überblick über den aktuellen Stand der Arbeit zu verschaffen. Dazu hat sich bewährt, dass jedes Teammitglied mit Hilfe des Taskboards sagt, was es seit dem letzten Daily Scrum erreicht hat, was es bis zum nächsten Daily Scrum erreichen möchte, und was dabei im Weg steht.
Beim Daily Scrum kann offensichtlich werden, dass die Erledigung eines Task länger als geplant, also länger als einen Tag dauert. Dann ist es sinnvoll, den Task in kleinere Aufgaben herunterzubrechen, die dann auch von anderen Mitgliedern des Entwicklungsteam übernommen werden können.
Treten beim Daily Scrum inhaltliche Fragen auf, die sich nicht innerhalb der strikten 15-Minuten-Vorgabe beantworten lassen, notiert der Scrum Master diese und geht sie entweder selber an (z. B. bei der Beseitigung von Hindernissen) oder vertagt deren Beantwortung auf ein späteres Meeting. 

Sprint Review

Das Sprint Review steht am Ende des Sprints. Das Entwicklungsteam präsentiert seine Ergebnisse und es wird überprüft, ob das zu Beginn gesteckte Ziel erreicht wurde. Es ist Aufgabe des Product Owners, die entwickelten Funktionalitäten zu begutachten und anhand der im Sprint Planning festgelegten Bedingungen zu entscheiden, ob sie abgenommen werden können oder nicht. Dabei sollten keine Kompromisse eingegangen werden: Ein Team hat auch dann sein Ziel verfehlt, wenn es eine „fast fertige“ (aber z. B. noch nicht getestete) Funktionalität liefert. In diesem Fall kehren die nicht fertiggestellten User Stories in das Product Backlog zurück und werden vom Product Owner neu priorisiert.
Im Sprint Review ist die Beteiligung des Users besonders wichtig, da dieser nun zum ersten Mal eine fertige Funktionalität benutzen kann. Hieraus kann sich wichtiges Feedback für die weitere Produktgestaltung ergeben. Es kann sogar passieren, dass die Funktionalität technisch einwandfrei umgesetzt wurde (sie erfüllt alle Abnahmekriterien) und dennoch aus der Perspektive des Benutzers unbrauchbar ist. Häufig entsteht während des Reviews ein lebhafter Dialog, in dem den Anwesenden neue Funktionalitäten einfallen. Diese werden vom Scrum Master notiert und an den Product Owner als mögliche neue Einträge für das Product Backlog weiter gereicht. Die Dauer eines Sprint Reviews hängt von der Dauer eines Sprints ab. So soll das Sprint Review bei einem Sprint von einem Monat maximal vier Stunden betragen.

 Retrospektive

Die Retrospektive steht zwischen Review und dem neuen Sprint Planning Meeting. Sie soll dem Team Gelegenheit und Zeit geben, über die gemachten Erfahrungen zu reflektieren und Verbesserungsmöglichkeiten zu identifizieren.Sinn der Retrospektive ist nicht, Kritik an Personen zu üben und Schuldige zu suchen, sondern aus den Ereignissen zu lernen. Die Retrospektive sollte in einem geschützten Raum ablaufen, um ein Gefühl der Sicherheit zu vermitteln.
Die Retrospektive steht nur dem Entwicklungsteam und dem Scrum Master offen, alle anderen Rollen dürfen nur auf Einladung dazukommen. Als Vorgehensweise bietet es sich an, zunächst alle relevanten Ereignisse der vergangenen Sprints auf einem Zeitstrahl festzuhalten (ohne Bewertungen vorzunehmen), um anschließend auf zwei separaten Flipcharts aufzuschreiben, was gut lief bzw. was verbessert werden könnte. Hinsichtlich der Verbesserungsmöglichkeiten lassen sich die identifizierten Punkte in teamspezifische Belange (z. B. Testumgebung,klare Formulierung der Stories, bessere Absprache mit dem Kunden) und in organisationsweite Belange (z. B. zu kleiner Raum, mangelnde Hardware, Störungen von außen) trennen. Anschließend empfiehlt es sich, die Liste der Hindernisse nach Dringlichkeit zu priorisieren. Hindernisse, die das Team allein betreffen, werden von diesem selbst gelöst. Die anderen Hindernisse werden vom Scrum Master in seinem Impediment Backlog aufgenommen. Die allein das Team betreffenden Impediments werden im darauf folgenden Sprint Planning  dem Product Owner zusammen mit dem für ihre Lösung geschätzten Aufwand vorgestellt. Der Product Owner entscheidet dort, welche Hindernisse vom Team im kommenden Sprint angegangen werden dürfen.
Die Dauer einer Retrospektive beträgt drei Stunden für einen Sprint von einem Monat. Wird für die Retrospektive und deren Vorbereitung nicht genug Zeit eingeräumt, bleiben die Erkenntnisse und Ergebnisse oberflächlich und die Beobachtungen nach jedem Sprint ähneln sich. Dann läuft man Gefahr, dass die Retrospektiven an Stellenwert verlieren oder ganz gestrichen werden, weil die Retrospektiven keinen Mehrwert ergeben.

 

Artefakte

 

Product-Backlog

Das Product Backlog ist eine priorisierte Liste, die alles enthält, was im zu entwickelnden Produkt enthalten sein sollte. Es ist zudem der einzige Ort, in dem Änderungsanforderungen aufgenommen werden. Der Product Owner ist für alle Eintragungen ins Product Backlog verantwortlich. Er verantwortet auch deren Priorisierung. Das Product Backlog ist nie vollständig und erhebt auch nicht diesen Anspruch. Zu Beginn eines Projektes enthält es die bekannten und am besten verstandenen Anforderungen. Die Priorisierung der Eintragungen erfolgt unter Gesichtspunkten wie wirtschaftlicher Nutzen, Risiko und Notwendigkeit. Eintragungen mit der höchsten Priorisierung werden als erste im Sprint umgesetzt. Das Product Backlog verändert sich zusammen mit dem Produkt und der Arbeitsumgebung.
Die im Product Backlog eingetragenen Anforderungen sollten nicht technik-, sondern fachlich- und anwenderorientiert sein. Eine etablierte Möglichkeit, um diese Sichtweise zu unterstützen, ist die Arbeit mit sogenannten User Stories. Eine gute User Story sollte die Antwort auf folgende drei Fragen liefern :

Als User (Wer?) möchte ich diese Funktionalität (Was?), damit ich folgenden Nutzen habe (Wozu?).

 

 

 

 

 

 

 

 

Sprint Backlog

Das Sprint Backlog dient zur Übersicht der für einen Sprint zu erledigenden Aufgaben. Zu diesem Zweck kann ein Taskboard eingesetzt werden. Es besteht aus vier Spalten. In der ersten Spalte („Stories“) werden die User Stories aufgehängt, für die sich das Entwicklungsteam zu diesem Sprint verpflichtet hat (in der vom Product Owner priorisierten Reihenfolge). Die drei weiteren Spalten enthalten die Aufgaben oder Tasks, die sich aus den einzelnen User Stories ergeben (und die im Sprint Planning 2 festgelegt worden sind). Je nach Bearbeitungsstand sind die Tasks entweder offen („Tasks to Do“), in Bearbeitung („Work in Progress“) oder erledigt („Done“). Im Daily Scrum erklärt jedes Mitglied des Entwicklungsteams anhand des Taskboards, an welcher Aufgabe es am Vortag gearbeitet

 

Burndown-Charts

Burndown-Charts dienen der Visualisierung bereits geleisteter und noch verbleibender Arbeit.

 

 

 

 

 

 

 

 

 

 

Impediment Backlog

Der Scrum Master führt ein Impediment Backlog, in dem alle aktuell identifizierten Hindernisse eingetragen werden.
Neben einer kurzen Beschreibung des Problems sollte das Impediment Backlog das Datum enthalten, an dem das Problem zum ersten Mal aufgetreten ist. Zudem trägt der Scrum Master am Ende eines Daily Scrum das Datum ein, an dem das Hindernis beseitigt wurde.

 

Definition of Done

Die Definition of Done (DoD) ist eine Checkliste von Aktivitäten, die zur Implementierung einer User Story gehören und die Qualität der Software beeinflussen. Dazu gehört beispielsweise das Schreiben von Kommentaren, Unit Tests und Design-Dokumenten. Die DoD wird von den Beteiligten zu Beginn eines Projektes festgelegt, kann aber im Laufe der Entwicklung angepasst werden. Die DoD hilft zu Beginn eines Sprints, die Anzahl und den Umfang der Tasks festzulegen.
Es müssen aber nicht alle Aktivitäten der DoD auf jede User Story zutreffen. Am Ende des Sprints dient die DoD neben den detaillierten Anforderungen für eine spezifische User Story dazu, zu entscheiden, ob eine User Story als done akzeptiert wird.

 

Literatur

Rolf Dräther, Holger Koschek und Carsten Sahling: Scrum – kurz & gut. 1. Auflage. O’Reilly, 2013, ISBN 978-3-86899-833-7
Boris Gloger: Scrum-Produkte zuverlässig und schnell entwickeln. 3. Auflage. Hanser Verlag, 2011, ISBN 978-3-446-42524-8
Holger Koschek: Geschichten vom Scrum: Von Sprints, Retrospektiven und agilen Werten. dpunkt.verlag, 2009, ISBN 978-3-89864-640-6
Ken Schwaber: Scrum Development Process, Advanced Development Methods, 131 Middlesex Turnpike Burlington, MA01803
Ken Schwaber: Agiles Projektmanagement mit Scrum. Microsoft Press Deutschland, Oktober 2007, ISBN 978-3-86645-631-0.
Ken Schwaber: Scrum im Unternehmen. Microsoft Press Deutschland, April 2008 , ISBN 978-3-86645-643-3.
Ken Schwaber, Jeff Sutherland: Software in 30 Tagen. dpunkt Verlag, Dezember 2013 , ISBN 978-3864900747.

Weblinks

http:// www. scrumalliance. org
http:// www. scrum. org
http:// www. agile42. com
https://www.scrum.org/Scrum-Guide
http:// www. scrum-plakat. de

Cookie-Regelung

Diese Website verwendet Cookies, zum Speichern von Informationen auf Ihrem Computer.

Stimmen Sie dem zu?