Einheit 03: Scrum
In Wirklichkeit...
Sind Anforderungen schwer abzuschätzen
Ändern sich Anforderungen fortwährend
Ändern sich Anforderungen (zu) spät im Projekt
Ist die Kommunikation mit dem Auftraggeber bzw. Kunden schwer
Daher ist ein Vorgehensmodell für die Software-Entwicklung erforderlich, dass es uns erlaubt mit sich ständig ändernden Parametern in Projekten umzugehen...
Woher stammt Scrum?
First Things First: Scrum ist kein Acronym
A scrummage, commonly known simply as a scrum, is a method of restarting play in rugby football that involves players packing closely together with their heads down and attempting to gain possession of the ball [Scrum, abbreviated form of scrummage, Oxford English Dictionary Online]
The New New Product Development Game
The New New Product Development Game, Hirotaka Takeuchi and Ikujiro Nonaka, Harvard Business Review, 1986 [1]
Bei der Entwicklung der Entwicklung der Canon AE-1 (Canon, 1976) wurde die Idee des Scrum das erste Mal eingeführt (https://hbsp.harvard.edu/product/86116-PDF-ENG).
Erfolgsfaktoren für die Umsetzung waren u.a.
Cross-Functional Teams
Selbstorganisierende Teams
Autonome Teams
Agiles Manifest
Das Agile Manifest wurde im Februar 2001 von einer Gruppe von 17 Softwareentwicklern in Utah verfasst, um leichtgewichtige Entwicklungsmethoden für agiles Projektmanagement festzulegen.
Individuen und Interaktionen mehr als Prozesse und Werkzeuge Funktionierende Software mehr als umfassende Dokumentation Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung Reagieren auf Veränderung mehr als das Befolgen eines Plans
Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.
12 Prinzipien
Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
Heise Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
Funktionierende Software ist das wichtigste Fortschrittsmaß.
Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
Einfachheit - die Kunst, die Menge nicht getaner Arbeit zu maximieren - ist essenziell.
Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.
Der Der Scrum Prozess im Detail
Scrum Rollen
Product Owner
Verantwortlich für »Business Value«, setzt die Prioritäten für höchstmöglichen ROI
Traditionell: Projektmanager, der die Arbeit kontrolliert
Team
Verantwortlich für das kontinuierliches Ausliefern von Arbeitsergebnissen/Teilergebnissen
Traditionell: Bekommt Arbeitsanweisungen vom Projektmanager
ScrumMaster
Achtet auf das Einhalten des Scrum-Prozesses und hält Störungen vom Team fern
Traditionell: kein Äquivalent
Hinweis: Ein agiler Coach ersetzt keinen ScrumMaster
Einfache Berechnung des Release-Termins
Neuberechnung bei Änderung des Umfangs
Zusätzliche Anforderungen haben immer einen neuen Release-Termin zur Folge
Soll der ursprüngliche Termin gehalten werden müssen, sind die am niedrigsten priorisierten Anforderungen zu streichen
Die Neupriorisierung bzw. Neuordnung von Anforderungen hat keine Auswirkungen auf den Release-Plan
Sprint-Planung - Planning 1
Sprint-Planung legt Arbeitsvorrat für kommende Iteration (Sprint) fest
Reihenfolge wird durch Product Owner vorgegeben (Priorisierung)
Die Menge der Aufgaben wird durch das Team festgelegt (Pull Prinzip)
Erfahrungswerte
Empirische Daten
Kann auch mal daneben gehen
Eventuell wir Zeit für Refactoring, Schulungen etc. eingeplant
Ergebnis der Sprintplanung ist das Sprint Backlog + Sprint Ziel
Commitment durch das Team? Seit 2011 kein Bestandteil des Scrum Guide mehr. [https://www.scrum.org/resources/commitment-vs-forecast ]
Sprint-Planung - Planning 2
Es ist Aufgabe des Teams, wie die Funktionalität geliefert werden kann
Planning 2 ist eine Arbeitssitzung in der das Design, die Spezifikation und die Architektur erarbeitet werden
Verständnis wie Ziel gemeinsam bewältigt werden kann
Ergebnis des Planning 2 sind Aufgaben (engl. tasks)
Praxistipp: Jeder Task sollte einen maximalen Umfang von maximal 8 Stunden (≈ 1 Personentag) haben
Schätzen
Schätzen ist eine der schwersten Aufgaben im Prozess
Unterscheidung
Schätzen von Komplexität
Schätzen von Aufwand/Dauer
Keine Korrelation zwischen Aufgabengröße und wie lange ein Entwickler dafür benötigt
Produktivitätsunterschied zwischen Entwicklern bis Faktor 25
Schätzen auf Basis von Story Punkten (engl. Story Points)
Planning Poker
Magic Estimation
...
User Stories
In der agilen Welt werden oftmals »User Stories« (oder kurz Stories) verwendet
Basierend auf Mike Cohen (User Stories Applied, 2004)
User Stories sind in der folgenden Form aufgebaut:
As a <user role> I need <functionality> so that I get <business value>
bzw. in Deutsch:
Als <Anwender mit der Rolle> benötige ich eine <Funktionalität> damit ich <den Nutzen> bekommen
Jede User Story steht dabei für ein Feature oder eine Funktionalität im System, das aus der Sicht des Anwenders mit der entsprechenden Rolle beschrieben ist.
User Stories dienen der Kommunikation zwischen Product Owner und Team bzw. innerhalb des Teams. Sie werden in verschiedenen Meetings im Scrum Prozess als Grundlage zur Kommunikation verwendet. Ergänzend kann man Akzeptanzkriterien angeben, anhand derer der Product Owner dies Story abnehmen kann.
Personas
Warum Personas?
Stellvertretend für eine spezielle Benutzerrolle (engl. user role) können Personas in User Stories verwendet werden.
Personas sind sog. Archetypen eines typischen Anwenders.
Meist ist es eine fiktive Person, die eine Gruppe von Anwender repräsentiert, die man sich gut merken kann und Eigenheiten und Merkmale aufweist, die diese Gruppe repräsentieren.
Personas helfen den Anwender besser zu verstehen und eigenen sich daher besonders eine User Story aus deren Sicht zu beschreiben.
Weiterführende Literatur
Scrum – Produkte zuverlässig und schnell entwickeln Boris Gloger, Hanser Verlag, 5. Auflage, 2016, ISBN 978-3-446-44723-3
Last updated
