Scrum im Sopra

Im Softwarepraktikum wird das Vorgehensmodell Scrum in angepasster Form angewendet. Unsere Anpassungen sollen vor allem den Verwaltungsaufwand reduzieren, die in Scrum beschriebenen Artefakte auf Gitea übertragen, mehr Raum für Fehler lassen, und die auf den Prozess aufgesetzten Zulassungskriterien unterstützen.

Scrum-Artefakte in Gitea

• Ein Sprint wird in Gitea durch einen Milestone (Issues -> Milestones) dargestellt. Die Gitea-Milestones bekommen dann den Namen Sprint<woche> (Beschreibung) also zum Beispiel Sprint00 (Hausaufgabe).
• Das Product Backlog besteht in Gitea aus allen Items (Issues) die noch keinem Sprint zugeordnet wurden.
• Eine User Story ist ein Issue dem das Label user story zugewiesen wurde. Zu jedem Sprint planning sollten alle User Stories außerdem ein Label für die Priorität (prioritiy: high,...) haben.
• Ein Task ist ein Issue ohne spezielle Labels.
• Ein Sprint Backlog besteht aus allen Items, die einem Sprint zugewiesen wurden (Issues -> Milestones -> <Sprintname>). Alle Items im Sprint Backlog müssen eine Priorität (normalerweise prioritiy: high) und eine Aufwandsabschätzung haben (z.B.: estimate: 2,...).

Das Git-Repository verwendet mindestens zwei Branches:

• Master: Hier wird das Spiel aktiv entwickelt.
• Release: Hier wird jeweils die Arbeit für einen abgeschlossenen Sprint mittels Pull-Request veröffentlicht. Dieser Branch (nur dieser) wird dazu verwendet die Arbeit der Sprints und das Spiel zu bewerten und repräsentiert den aktuell auslieferbaren Stand des Produkts.

Backlog Items und Kooperation im Softwarepraktikum

Die Arbeit im Softwarepraktikum wird durch Items im Product Backlog und Sprint Backlog organisiert. Jedes Item im Sprint Backlog wurde im Sprint Planning für den Sprint ausgesucht und die notwendige Arbeitszeit um das Item gemäß DoD fertig zu stellen wurde geschätzt. Folgende Aufgaben sollten im Sprint Backlog geplant werden:

• Arbeit am Spiel (z.B.: Programmieren, Bugfixing, das Suchen, Erstellen und Integrieren von Assets, Recherche von Algorithmen, usw.)
• Arbeit am Spieldesign (z.B.: Schreiben am GDD und Recherche über die Problemdomäne, gemeinsame Ideenfindung, usw.)
• Qualitätssicherung (z.B.: wiederkehrende Aufgaben wie Clean Code und Architekturplanung, usw.)
• Organisationsaufgaben (z.B.: Product Owner Tasks, Kontakt mit den Kundenvertretern, usw.)
• Coaching (z.B.: Pair Programming, andere Gruppenmitglieder unterstützen, Präsentationen vorbereiten und proben)

Nur Vorlesungen, Präsentationen und die wöchentlichen Treffen sind bereits von der vorgesehenen Arbeitslast abgezogen und sollen nicht als Backlog Items erstellt werden.

Gemeinsame Tickets und Unterstützung

Items für einen Sprint sollten möglichst so angelegt werden, dass sie überschaubar und für eine Person alleine zu bewältigen sind. In manchen Fällen ist dies aber nicht möglich. Zum Beispiel können sich manche Gruppenmitglieder die Aufgabe alleine nicht zutrauen, benötigen Hilfe um schneller mit einem unbekannten Teil des Quellcodes arbeiten zu können, oder die gesamte Gruppe möchte sich zum Testspielen oder Diskutieren treffen. Entsprechende Items können von mehreren Studenten gleichzeitig bearbeitet werden. Dabei ist zu beachten:

• Die geschätzte Zeit ist die Gesamtarbeitszeit und wird jedem zugewiesenen Gruppenmitglied zu gleichen Teilen gutgeschrieben, nachdem das Item erfolgreich geschlossen ist. Bei mehreren estimate Labels wird nur das höchste ausgewertet, die Labels werden also insbesondere nicht aufsummiert.
• Jedes auf einem Item zugewiesene Gruppenmitglied muss am Ende des Sprints auch daran gearbeitet haben (d.h. Zeit verbucht haben), sonst gilt das Item für dieses Mitglied als nicht erfüllt.

Es ist auch möglich, dass Aufgaben nicht zu gleichen Teilen allen beteiligten Gruppenmitgliedern zugeschrieben werden soll. In diesem Fall sollten zwei Tickets mit entsprechenden Estimates und Beschreibungen angelegt werden. Zum Beispiel könnte ein Gruppenmitglied eine größere Programmieraufgabe mit geschätzten acht Stunden wählen, ist sich aber nicht sicher das Prinzip von Komposition, dass für die Aufgabe notwendig erscheint, verstanden zu haben. Ein anderes Gruppenmitglied möchte gerne helfen und würde schätzen, dass Komposition anhand des Beispiels in zwei Stunden erklärbar sein sollte. Es werden also zwei Tickets angelegt, eines für die Programmieraufgabe mit einer Schätzung von acht Stunden und dem ersten Gruppenmitglied zugewiesen; und ein weiteres Ticket für die Unterstützung mit dem zweiten Gruppenmitglied und einer ETC von zwei Stunden.

Tickets während eines Sprints hinzufügen

Es kann vorkommen, dass plötzlich Probleme auftauchen, die beim Sprint Planning nicht vorhergesehen wurden. Insbesondere Bugs, die nicht die eigene Arbeit behindern, aber zu reparieren sind, sollten als Items im Product Backlog dokumentiert werden. Dazu sollte das Gruppenmitglied, das den Fehler gefunden hat, ein Ticket mit einer reproduzierbaren Fehlerbeschreibung anlegen (normalerweise was ist der Fehler und eine ordentliche Beschreibung wie man den Fehler verursacht, nachdem man das Programm gestartet hat) und das bug Label setzen. Im nächsten Sprint Planning kann dieser Bug dann wie andere Aufgaben auch geplant und zugewiesen werden.

Sollte ein Bug dringend, am besten sofort, gefixt werden müssen (da er z.B. die Arbeit an einem anderen Item blockiert), so sollte das Item direkt nach der Erstellung dem aktuellen Sprint zugewiesen werden und die Gruppe benachrichtigt werden. Ein für die Funktion zuständiges Gruppenmitglied kann sich dann das Item zuweisen, eine Zeitschätzung eintragen (ebenfalls mit einer kurzen Begründung, damit der Tutor die Zeitschätzung im Sprint Review nachvollziehen kann), und das Ticket bearbeiten. Die Zeitschätzung zählt dann auch für die in den Zulassungskriterien notwendige geschätzte Arbeitszeit.

Abweichungen vom Scrum Modell im Softwarepraktikum

In Scrum ist es üblich, Aufgaben mit verschiedener Detailtiefe zu beschreiben, darunter die Beschreibungen einzelner Funktionen aus der Benutzersicht, die sogenannten User Stories, die wiederum in einzelne Teilaufgaben, die Tasks zerlegt werden. Um den Prozess im Softwarepraktikum möglichst überschaubar zu halten, weichen wir von diesem Modell wie folgt ab:

• Im Softwarepraktikum liefert das GDD in den allermeisten Fällen eine ausreichende Beschreibung der Spielfeatures (vergleichbar mit einer Menge an User Stories). Im Sprint Planning werden die Tasks deshalb meistens direkt vom GDD abgeleitet.