Scrum
Aus Das Sopra Wiki
Inhaltsverzeichnis |
Was ist Scrum?
Scrum ist ein iteratives Vorgehensmodell das zu den agilen Prozessen gezählt wird und das aus Meetings, Artefakten, Rollen, Werten und Grundüberzeugungen besteht.
Teammitglieder organisieren ihre Arbeit weitgehend selbst und wählen auch die eingesetzten Software-Entwicklungswerkzeuge und -Methoden. Ken Schwaber, Jeff Sutherland und Mike Beedle haben Scrum erfunden und etabliert. Als Software-Entwicklungsmethode wird Scrum das erste Mal in dem Buch “Wicked Problems, Righteous Solutions” beschrieben. Scrum in Produktionsumgebungen wird zum ersten Mal in dem Artikel “The New New Product Development Game” erläutert und später in “The Knowledge Creating Company” weiter ausgeführt von Ikujiro Nonaka und Hirotaka Takeuchi.[1]
Scrum-Meeting
Zu Beginn eines Sprints findet ein Scrum-Meeting statt. Hier wird das Product Backlog gereviewed, es werden die Ziele besprochen und das Team wählt Items aus dem Product Backlog aus, die bis zum Ende des Sprints abgeschlossen werden sollen. Hierbei wird die Priorität der Items berücksichtigt.
Wichtig hier (und ein Kernkonzept in Scrum): Das Team entscheidet, wie viel es im nächsten Sprint erledigen wird.
Zuerst wird abgeschätzt, wie viel Zeit jedes Teammitglied für den aktuellen Sprint bereitstellen kann. Danach werden die in diesem Sprint zu erledigenden Items ausgewählt (in der Regeln nach Priorität) und in individuelle Aufgaben (kleinere Items) aufgesplittet, welche dann im Sprint Backlog festgehalten werden.
Wenn die Aufgaben identifiziert sind werden sie den Teammitgliedern, unter Berücksichtigung von Abhängigkeiten etc., zugeteilt. Jede Aufgabe erhält eine Abschätzung für die Umsetzungsdauer (in ETC) um sicher zu stellen, dass das Arbeitspensum gleichmäßig verteilt wird.
Am Ende des Meetings kommt man somit zu einer Liste von Aufgaben und jeweils einer Zuteilung an einen Verantwortlichen.
Die Aufgaben sollten mit Bedacht herausgearbeitet und verteilt werden, da sie in der Regel für den Rest des Sprints festgehalten und nicht mehr geändert werden. Sollte eine unvermeidbare Änderung im Plan nötig sein, so kann man den aktuellen Sprint stoppen und mit der Planung neu beginnen. Da das aber einen großen Störfaktor darstellt sollte dies nur in extremen Situationen in Betracht gezogen werden.
Scrum bringt auch diverse Herausforderungen mit sich: Zum Beispiel ist es zu Beginn schwierig, die Menge an Arbeit, die man in einem Sprint schaffen kann, einzuschätzen. So kann es passieren dass ihr es nicht schafft, alles was ihr euch für den ersten Sprint vorgenommen habt, fertig zu stellen. Der Rest des Teams kann das als Versagen werten, aber genau diese Erfahrung ist ein notwendiger Schritt um realistischere und durchdachtere Annahmen über seine Leistungen treffen zu können.
Sprint
Bei Scrum wird die Entwicklung eines Produkts in Zyklen unterteilt, welche Sprints genannt werden. Ein Sprint ist eine Iteration, die üblicherweise einen Monat (im Sopra eine Woche) dauern soll. Ein Sprint hat einen festen Zeitraum und endet, egal ob die Arbeit abgeschlossen wurde oder nicht, ohne verlängert zu werden. Zu Beginn eines Sprints müsst ihr eine Liste von Items aus einer priorisierten Liste von Anforderungen (Product Backlog) auswählen, welche bis zum Ende des Sprints abgeschlossen werden sollen. Diese Auswahl bildet das anfängliche Sprint Backlog. Im Verlauf des Sprints werden die Items des Sprint Backlogs verfeinert, in dem ihnen detailierte bzw. konkretisierte Items untergeordnet werden.
Wenn der Sprint zu Ende ist, demonstriert ihr im Scrum-Meeting eurem Scrum-Master (im Sopra der Tutor) was ihr entwickelt habt, könnt Fragen oder Probleme klären und erhaltet Feedback (bei Fragen/Problemen etc. könnt ihr euch natürlich auch zwischendurch melden). In der Regel wird der Code der während eines Sprints erzeugt wurde als "fertig" angesehen, was bedeutet, dass dieser keine Änderungen/Korrekturen mehr erfordern sollte, sofern sie nicht durch ein anderes, noch nicht bearbeitetes Item bedingt werden.
Die neuen Items und ihre Zuordnung werden am Ende eines Sprints wieder in das Product Backlog überführt.
Rollen
Product Owner
Der Product Owner - typischerweise ein Vertriebsmitarbeiter des Kunden / in der Spielbranche ein Analyst des Publishers / bei uns die Dozenten - priorisiert die einzelnen Punkte des Product Backlogs und legt damit fest, welche Features des Spiels zuerst zu implementieren sind und welche unter Zeitmangel wegfallen dürfen.
Scrum Master
Der Scrum-Master (euer Tutor) ist für das (geistige) Wohl des Scrum-Teams zuständig. Er achtet darauf, dass sich das Team an den Ablauf des Scrum-Prozesses hält. Er sorgt dafür, dass das Team sich nicht in einzelnen Sprints überschätzt. Weiter sucht der Scrum-Master nach Lösungen für Probleme, die sich in den Scrum-Meetings ergeben haben, während das Team sich weiter auf den aktuellen Sprint konzentrieren kann.
Team
Das seid ihr.
Artefakte
Product Backlog
Der erste Schritt in Scrum ist das Festhalten der Produktfeatures. Dies geschieht anfangs in Form einer priorisierten Liste von Anforderungen (Items), die im Softwarepraktikum aus dem GDD extrahiert werden können. Diese Liste ist das Product Backlog, welches über die gesamte Projektzeit existiert und sich auch im Projektverlauf noch iterativ weiterentwickeln kann. Das Product Backlog hält, in priorisierter Reihenfolge, alles fest, was das Team machen sollte. Im Verlauf der Entwicklung sollten die einzelnen Items nach und nach (d.h. im Verlauf eines Sprints) verfeinert werden, wodurch sich aus den anfänglichen Anforderungen konkretere Beschreibungen bis hin zu Spezifikationen entwickeln. Das Product Backlog umfasst in seinem Endzustand alle Inhalte des Produkts, z.B. Features ("der Spieler kann ein Auto steuern"), Entwicklungsanforderungen ("Menüs überarbeiten um sie flexibler zu gestalten"), Untersuchungen ("Konzepte untersuchen um die Kollisionsabfragen zu beschleunigen") oder bekannte Fehler ("Fehler in der Wegpunkt-Befahrung der KI diagnostizieren und beheben").
Items sollten entsprechend ihrer aktuellen Abstraktion strukturiert verfasst werden. Das kann z.B. in Anlehnung an User Stories[2] oder Anwendungsfälle[3] geschehen. Die Struktur sollte für Ihr Team und Ihr Produkt sinnvoll sein. Ihr Tutor bzw. die Sopra-Crew kann Sie dabei unterstützen. Mindestens jedoch sollte jedes Item eine Priorität und einen Verantwortlichen besitzen. Das Product Backlog sollte kontinuierlich aktualisiert werden, um Änderungen in den Anforderungen, neue Ideen oder Erkenntnisse, technische Hürden etc. zu erfassen.
Neben der Priorität wird jedes Item im Product Backlog mit einer groben Abschätzung des erforderlichen Aufwands versehen. Diese Werte können auch für die Priorisierung der einzelnen Items hilfreich sein. Da die Abschätzungen relativ sind, könnten sie in einer beliebigen Einheit angegeben werden, anstatt "echte" Zeiten für Aufwand wie Personenstunden zu verwenden. Jedoch ist es meistens sinnvoll, konkrete Zeitangaben zu haben, da sich diese besser zur Verfeinerung der Selbsteinschätzung eignen. Wir empfehlen daher, ETC als Einheit zu verwenden.
Die Items im Product Backlog können, was ihre Komplexität angeht, stark variieren. Daher werden größere Items bei der Planung eines Sprints in kleinere Items unterteilt.
Die generelle Richtlinie besagt, dass man das was wichtig ist auf dem kleinsten Raum zusammenfassen soll der benötigt wird. In anderen Worten muss man nicht jedes mögliche Detail eines Items beschreiben, sondern nur klar machen, was benötigt wird um das Item als abgeschlossen ansehen zu können.
Im Softwarepraktikum sollte das Product Backlog wie auch das Sprint Backlog im Trac geführt werden.
Sprint Backlog
Das Sprint Backlog ist eine für den anstehenden oder laufenden Sprint ausgewählte Teilmenge des Product Backlogs und besteht wie dieses aus Items.
Typischerweise werden bei der Auswahl (im Scrum-Meeting) die aus dem Product Backlog entnommenen Items weiter verfeinert und falls nötig in kleinere Items unterteilt.
Im Softwarepraktikum sollte das Product Backlog wie auch das Sprint Backlog im Trac geführt werden.
Links und Ressourcen
Hier finden sich einige Artikel über Scrum, die von Menschen bzw. Firmen geschrieben wurden, die damit ihr Geld verdienen.
- Scrum Primer von GoodAgile, einem Scrum-Trainingsprovider aus dem asiatischen Raum.
- Scrum Alliance, eine NPO, die Scrum propagiert.
- Mountain Goat Software, ein Unternehmen das wie GoodAgile Scrum-Zertifizierungen und Trainings anbietet.
- Scrum-Master, eine deutschsprachige Scrum-Seite, die von einem Freiberufler namens Alexander Kriegisch erstellt wurde.
