Scrum

Aus Das Sopra Wiki

Wechseln zu: Navigation, Suche



Inhaltsverzeichnis

Was ist Scrum?

Der Scrum-Prozess im Überblick

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 Dingen (Sprint Backlog) aus einer priorisierten Liste von Anforderungen (Product Backlog) auswählen, welche bis zum Ende des Sprints abgeschlossen werden sollen.

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.

Rollen

Product Owner

Der Product Owner - typischerweise ein Vertriebsmitarbeiter des Kunden / in der Spielbranche ein Analyst des Publishers / bei uns Evren, Stephan und Daniel - 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 in Form einer priorisierten Liste von Anforderungen (Items). 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 jemals machen könnte bzw. sollte.

Das Product Backlog umfasst eine Vielfalt von Inhalten, wie 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").

Anforderungen können als User Stories verfasst werden: prägnante, klare Beschreibung der Funktionalitäten aus der Sicht des Endbenutzers. Das Product Backlog wird kontinuierlich geupdated 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.

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.

Implement Log (auch: Impediment Backlog)

Impediment Backlog

Links und Ressourcen

Hier finden sich einige Artikel über Scrum, die von Menschen bzw. Firmen geschrieben wurden, die damit ihr Geld verdienen.

Referenzen und Quellen

  1. Scrum bei Wikipedia
Persönliche Werkzeuge