Scrum: Unterschied zwischen den Versionen
Schaef (Diskussion | Beiträge) |
Schaef (Diskussion | Beiträge) |
||
Zeile 19: | Zeile 19: | ||
==== Scrum Master ==== | ==== 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 ==== | ==== Team ==== |
Version vom 5. Mai 2009, 11:18 Uhr
Was ist Scrum?
![](/images/thumb/4/42/Scrum-Prozess.gif/400px-Scrum-Prozess.gif)
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
Ein Scrum-Meeting ist ein Treffen, an dem alle Teammitglieder anwesend sind, das eine fest definierte Zeitschranke (Timeboxed) hat, und dessen Ziele klar definiert sind. Daily-Scrum, Sprint Planning Meeting, Sprint Review, Sprint Retrospektive sind Beispiel für Scrum-Meetings.
Sprint
Bei Scrum wird die Entwicklung eines Produkts in Zyklen unterteilt, welche Sprints genannt werden. Ein Sprint ist ein fester Zeitraum (im Softwarepraktikum eine Woche) in dem entwickelt wird. Zu Beginn eines Sprints wird in einem Sprint Planning Meeting durch das Team eine Liste von Items aus einer priorisierten Liste von Anforderungen (Product Backlog) ausgewählt, die bis zum Ende des Sprints abgeschlossen werden sollen. Bei der Auswahl wird für jedes Item der benötigte Aufwand zur Fertigstellung geschätzt um nicht zu viele Items für den aktuellen Sprint zu wählen. Wenn die Kapazität des Teams erreicht wurde, werden keine neuen Items mehr in das Sprint Backlog aufgenommen.
Am Ende des Sprints werden die Ergebnisse in einem Sprint Review Meeting allen Beteiligten demonstriert und basierend auf dem tatsächlich benötigten Aufwand die Kriterien zur Aufwandsabschätzung modifiziert.
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 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 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 Gitea geführt werden (siehe auch Scrum und Gitea)
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 Gitea geführt werden (siehe auch Scrum und Gitea)
Implement Log (auch: Impediment Backlog)
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.