Ablauf

Im Softwarepraktikum wird das Vorgehensmodell Scrum in angepasster Form angewendet. Die Anpassungen sollen vor allem den Verwaltungsaufwand für die Studenten reduzieren, die in Scrum beschriebenen Artefakte auf Gitea übertragen und die auf den Prozess aufgesetzten Zulassungskriterien unterstützen. Die gesamtdauer des Softwarepraktikum ist in Sprints von je einer Woche unterteilt.

Scrum-Artefakte im Sopra

Scrum unterscheidet eine Reihe von Artefakten, die für die Arbeit mit Scrum notwendig sind. Das sind vor allem, das Product- und Sprint Backlog mit den darin definierten Aufgaben in Form vorn Tasks und User Stories. Da Gitea keine direkte Unterstützung für Scrum bietet, werden die von Scrum verwendeten Artefakte wie folgt auf Giteakonstrukte abgebildet:

• Ein Entwicklungsabschnitt, ein sogenannter 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. In Scrum ist es üblich, Aufgaben mit verschiedener Detailtiefe zu beschreiben. Unter andem durch die Beschreibungen einzelner Funktionen aus der Benutzersicht, die sogenannten User Stories. User Stories sind zu groß um auf einmal bearbeitet zu werden, und werden deshalb wiederum in einzelne Teilaufgaben, die Tasks zerlegt. Um den Prozess im Softwarepraktikum möglichst überschaubar zu halten machen wir für das Sopra folgende Annahme: Das GDD beschreibt alle features des Spiels ausreichend, um daraus im Sprint Planning direkt Aufgaben von der Größe eines Tasks abzuleiten. Sollte eine weitere Unterteilung nötig oder erwünscht sein, schlagen wir folgende Aufteilung vor:
  • Ein Task ist ein Issue ohne ein spezielles Label.
  • Falls Sie diese verwenden möchte, ist eine User Story ein Gitea-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 Sprint Backlog besteht aus allen Items (d.h. User Stories, Issues, Bugtickets...), die einem Sprint zugewiesen wurden (Issues -> Milestones -> <Sprintname>). Alle Items im Sprint Backlog müssen eine Priorität (z.B.: 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.

Wöchentliches Gruppentreffen mit Tutor (Review-, Retro- und Planning-Meeting)

Jeder Sprint im Softwarepraktikum beginnt und endet am wöchentlichen Gruppentreffen, das wie ein Scrum-Meeting organisiert ist. In diesem Treffen wird der letzte Sprint besprochen und der nächste Sprint geplant. Das Treffen ist in drei Teile, das Sprint Review, Sprint Planning und Sprint Retrospective unterteilt.

Sprint Review (max. 30min)

Im Sprint Review werden die Ergebnisse des vergangenen Sprints demonstriert. Dabei wird für jede Aufgabe aus dem Sprint bestimmt, ob diese zur Zufriedenheit des Teams erfüllt wurde.

Zu Beginn dieses Teils des Treffens führt jede Teammitgleid vor, was für neue Features im letzten Sprint fertiggestellt worden sind. Danach erklärt entweder der Product Owner (siehe Wiederkehrende Aufgabe "Product Owner") oder jedes Teammitglied einzeln, welche Aufgaben aus dem letzten Sprint im Sinne der Definition of Done abgeschlossen wurden, bzw. welche übrig geblieben sind. Dann wird die Aufwandsabschätzung überprüft. Dabei sollten zwei Punkte geklärt werden:

• War die Abschätzung für die einzelnen Items im letzten Sprint richtig oder hat man sich nach oben oder unten verschätzt?
• Wurde die dem Team zur Verfügung stehende Zeit richtig eingeschätzt?

Zum Schluss sollte noch geklärt werden, ob mit der aktuellen Arbeitsweise der nächste Milestone erreicht werden kann.

Die Ergebnisse aus dem Sprint Review können dann direkt im nächsten Teil des Gruppentreffens verwendet werden.

Sprint Retrospective (max. 15min)

In diesem Teil des Treffens sollten alle Dinge geklärt werden, die den bisherigen Prozess betreffen. Dazu wird diskutiert, was im letzten Sprint im Hinblick auf Menschen, Beziehungen, Prozesse, Tools gut bzw. schlecht gelaufen ist. Bei Bedarf stellt das Team fest, wo etwas verändert werden muss, damit die gemeinsamen Ziele besser erreicht werden können. Dabei wird schriftlich festgehalten, wie diese Änderungen im nächsten Sprint umgesetzt wird. Im Speziellen sollte während der Sprint Retrospektive auch die DoD diskutiert und im Bedarfsfall angepasst werden.

Dieser Schritt finde vor dem nächsten Sprintplanning statt, da Änderungsvorschläge direkt im anschließenden Sprint umgesetzt werden sollen.

Sprint Planning (max. 60min)

In diesem Teil des Treffens werden die Ziele für den nächsten Sprint geplant.

Ablauf

Zuerst sollte geklärt werden, wie viel Zeit jedes Teammitglied und damit das gesamte Team für den nächsten Sprint bereitstellen kann. Danach wählt man gemeinsam ein Item (unter Berücksichtigung der Priorität) aus dem Product Backlog aus, das im nächsten Sprint umgesetzt werden soll. Das Item sollte nun so lange in kleinere Items, zerlegt werden (z.B. zuerst in User Stories und dann in Tasks, oder auch direkt in Tasks), bis diese direkt als an einzelne Teammitglieder verteilt werden können. Für jedes der so entstandenen atomaren Items sollte nun der Arbeitsaufwand (ETC) abgeschätzt werden. Danach werden die atomaren Items in das neue Sprint Backlog verschoben.

Diesen Vorgang wiederholt man nun so lange, bis man die Zeit, die das Team für den nächsten Sprint zur Verfügung hat, aufgebraucht hat. Erst danach werden die einzelnen Items im Sprint Backlog unter den Teammitgliedern aufgeteilt. Am Ende diesen Teils kommt man somit zu einem neuen Sprint Backlog mit einer Liste von Items die jeweils einem Verantwortlichen zugeteilt sind.

Wiederkehrende Aufgaben

Während des Softwarepraktikums müssen bestimmte organisatorische Aufgaben in jedem Sprint ab Woche 2 erledigt werden. Diese Aufgaben können immer vom gleichen Teammitglied, oder abwechselnd ausgeführt werden. Aufgaben können auch von mehr als einer Person erledigt werden, sofern der Umfang der Aufgaben dies zulässt und Bedarf besteht.

Die folgenden wiederkehrenden Aufgaben gibt es:

• Product Owner (ab Woche 2)
  • Pflegen und Anpassen von User Stories und Tasks im Product Backlog.
  • Verfeinern von User Stories zu Tasks.
  • User Stories mit Prioritäten versehen und Prioritäten aktualisieren.
  • Gruppentreffen vorbereiten (was ist fertig, wie war die Aufwandsabschätzung).
  • Gemeinsam mit der Gruppe bestimmen, was aufgrund der Entwicklungsreife die als nächstes zu bearbeitenden User Stories werden soll.
  • Vor dem Gruppentreffen das Increment nach release pushen (siehe Sprint Abschließen).
• Qualitätssicherung (ab Woche 3)
  • Code auf Clean-Code Richtlinien prüfen.
  • Code Reviews vorbereiten und durchführen.
• Architektur (ab Woche 3)
  • Schnittstellen definieren.
  • Architekturbeschreibungen pflegen.
  • Einhaltung der Architektur im Projekt sicherstellen und beides ggf. anpassen.
  • Einen Überblick über die Gesamtarchitektur behalten und bei der Umsetzung verschiedener Tasks stets die Abhängigkeiten innerhalb der Architektur berücksichtigen.

Aufgabe schwieriger als gedacht

Natürlich kann es vorkommen, dass man eine Aufgabe als zu leicht einschätzt und sich während der Bearbeitung abzeichnet, dass man die Aufgabe innerhalb des aktuellen Sprints nicht erledigen kann. Daher ist es zum einen wichtig, bei den eigenen Aufgaben auf die Abhängigkeiten zu den Aufgaben anderer Teammitglieder zu achten und sich entsprechend abzusprechen (speziell sollte man vermeiden, erst kurz vorm Ende des Sprints mit Aufgaben zu beginnen, die andere für die Erledigung ihrer Aufgaben brauchen). Zum anderen müssen die anderen Teammitglieder und der Tutor über ein Kommentar im entsprechenden Ticket rechtzeitig informiert werden, dass eine Aufgabe nicht mehr innerhalb des aktuellen Sprints erledigt werden kann, und wo die Probleme mit der Aufgabe lagen.

Ohne eine rechtzeitige Mitteilung im Ticket zählt die jeweilige Aufgabe als nicht abgeschlossen und führt zu Punkteverlust bei den wöchentlich erreichbaren Punkten der Einzelleistung (siehe Benotung).

Organisieren der gemeinsamen Arbeit als Items im Sprint- und Product-Backlog

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)

Die 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.

Hinweise zur Arbeitsorganisation

Gemeinsam arbeiten

Außerhalb des offiziellen Gruppentreffens ist es sinnvoll zu versuchen, weitere feste Treffen zu vereinbaren, an denen gemeinsam an der Umsetzung des Spiels gearbeitet werden kann. Oftmals reicht es auch schon, gemeinsame Zeiten zu vereinbaren in denen man von Zuhause aus arbeitet, sich aber gegenseitig über synchrone Kommunikationsmedien (z.B. über Mattermost) erreichen kann.

Bei diesen Treffen ist es sinnvoll, zuerst ein Daily-Scrum zu machen. Ein Daily-Scrum ist ein Scrum-Meeting, das max. 15min dauert und bei dem jeder Teilnehmer folgende Fragen beantwortet, ohne das andere Teilnehmer Rückfragen stellen oder Kommentare abgeben:

• Was wurde seit dem letzten Meeting gemacht?
• Was wird bis zum nächsten Meeting gemacht?
• Was für Probleme gibt es, die die aktuellen Aufgaben behindern?

Probleme werden hierbei nur kommuniziert, jedoch noch nicht gelöst. Dies dient dem Zweck, dass jedes Gruppenmitglied innerhalb von 15 min über die Arbeit und Probleme aller anderen Mitglieder informiert ist. Im Anschluss an das Daily-Scrum können dann die vorhandenen Probleme angegangen und gelöst werden.