Einheit 03: Scrum
Last updated
Last updated
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...
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, 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
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.
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.
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
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 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 ]
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 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
...
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.
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.
Scrum â Produkte zuverlässig und schnell entwickeln Boris Gloger, Hanser Verlag, 5. Auflage, 2016, ISBN 978-3-446-44723-3
