Ablauf

Das Softwarepraktikum verwendet Scrum als Vorgehensmodell für die Softwareentwicklung und ist daher in insgesamt 13 Sprints (1 Sprint pro Woche) unterteilt.

"offizielles" Gruppentreffen

Jeder Sprint 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. Dazu ist das Treffen in 3 Teile unterteilt.

Sprint Review (max. 30min)

1. • Product Owner sagt, was fertig und was nicht fertig ist.
   • Team zeigt, was alles fertig geworden ist und beantwortet Fragen zum Fortschritt.
   • Team erklärt dabei, was es für Probleme gab und wie diese gelöst worden sind.
   • Product Owner erklärt den aktuellen Stand des Product Backlogs und speziell Änderungen an der Aufwandsabschätzung.

Sprint Planning (max. 60min)

1. • Was wird im nächsten Sprint gemacht? Product Backlog anschauen, von oben nach unten (PO sollte es geordnet haben). An die Recurring Tasks denken.
   • Wer erledigt von den ausgewählten Dingen was (Arbeitsverteilung)?

Sprint Retrospective (max. 15min)

1. • Diskutieren, was im letzten Sprint im Hinblick auf Menschen, Beziehungen, Prozesse, Tools gut bzw. schlecht gelaufen ist.
   • Wo muss etwas verändert oder verbessert werden, damit besser gearbeitet werden kann?
   • Plan erstellen, wie diese Änderungen im nächsten Sprint umgesetzt werden können.

Arbeitsorganisation

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.

1. Daily Scrum (max. 15min)
   • 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?

...

High-Level Ablauf im Sopra

1. 13 Wochen, organisiert nach Scrum
   • Wöchentliche Scrum-Meetings (Tutorentreffen)
   • Regelmäßige Präsentationen (Vorführung des Produkts beim Kunden)
     • Spielidee (Verkauf der Idee and die Kunden: warum macht das Spiel Spaß, Was ist das Alleinstellungsmerkmal, Wie kann man gewinnen/verlieren?)
     • Beta (Aktueller Zwischenstand, Vergleich mit anderen Gruppen)
     • Final (Endabnahme durch Kunden)
   • Dozenten sind Kunden, Tutoren sind "Sub-Kunden"
2. Zusätzlich zum Kunden-Schema: Begleitende Vorlesungen, um Wissen zu vermitteln
   • GDD (Was ist das? Wie schreibt man das? Was gehört da rein?)
   • Architektur (Wie funktioniert UML, was muss man bei Spielearchitekturen beachten?)
   • Code Reviews (Verbesserung der eigenen Codequalität)
3. 2 Phasen
   • Deisgn
     • Festigen der Spielidee, Mechaniken, etc.
     • Formalisieren und Aufschreiben
     • Finden von Widersprüchen im Design, Unlogischen Abläufen, etc.
   • Implementierung
     • Entwicklung des Spiels
     • Einhalten der getroffenen Designentscheidungen (auch im Bezug auf Architektur)
     • Einhalten von Clean-Code Prinzipien

Hier soll geklärt werden:

1. Scrum Meeting / Daily Scrum (max. 15min)
   • 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?
2. Sprint Review (max. 30min)
   • Product Owner sagt, was fertig und was nicht fertig ist.
   • Team zeigt, was alles fertig geworden ist und beantwortet Fragen zum Fortschritt.
   • Team erklärt dabei, was es für Probleme gab und wie diese gelöst worden sind.
   • Product Owner erklärt den aktuellen Stand des Product Backlogs und speziell Änderungen an der Aufwandsabschätzung.
3. Sprint Planning (max. 60min)
   • Was wird im nächsten Sprint gemacht? Product Backlog anschauen, von oben nach unten (PO sollte es geordnet haben). An die Recurring Tasks denken.
   • Wer erledigt von den ausgewählten Dingen was (Arbeitsverteilung)?
4. Sprint Retrospective (max. 15min)
   • Diskutieren, was im letzten Sprint im Hinblick auf Menschen, Beziehungen, Prozesse, Tools gut bzw. schlecht gelaufen ist.
   • Wo muss etwas verändert oder verbessert werden, damit besser gearbeitet werden kann?
   • Plan erstellen, wie diese Änderungen im nächsten Sprint umgesetzt werden können.

Wiederkehrende Aufgaben

Während des Semesters sind die folgenden wiederkehrenden Aufgaben zusätzlich zu den anderen Aufgaben jede Woche zu erledigen:

• Product Owner (ab Woche 2)
  • Pflegen und Anpassen von Requirements und User Stories im Product Backlog.
  • Verfeinern von Requirements zu User Stories.
  • Requirements nach Entwicklungsreife ordnen.
  • Gruppentreffen vorbereiten (was ist fertig, wie war die Aufwandsabschätzung).
• Architektur (ab Woche 3)
  • Schnittstellen definieren
  • Architekturbeschreibungen pflegen
  • Einhaltung der Architektur sicherstellen
• Qualitätssicherung (ab Woche 6)
  • Code auf Clean-Code Richtlinien prüfen.
  • Code Reviews vorbereiten
  • ReSharper Konformität herstellen

Definition of Done

Die Definition of Done (DoD) ist eine Checkliste von Zielen, die beschreiben, wann die Bearbeitung eines Items abgeschlossen ist.

Beispiele für solche Ziele sind:

• Gitea-Status des Items ist closed.
• 1 (2, alle) Teammitglieder haben die Erfüllung bestätigt.
• Der Tutor hat die Erfüllung bestätigt.
• Alle relevanten Teile der Implementierung sind dokumentiert.
• Alle relevanten Teile der Implementierung enthalten keine ReSharper-Fehler.
• Es wurden Unit-Tests geschrieben, die die relevanten Teile der Implementierung testen.
• Die Architekturbeschreibung wurde gepflegt.
• etc.

Die DoD wird zu Beginn des Projektes schriftlich und für alle einsehbar (z.B. im Gitea Wiki, als Textdatei im Git-Repository) festgelegt, kann aber zwischen Sprints immer wieder verändert und den aktuellen Gegebenheiten angepasst werden.

DoD im Softwarepraktikum

Im Softwarepraktikum regelt die DoD auch die Vergabe der wöchentlichen Punkte. Während des Sprint Reviews wird durch das Team und den Tutor für jede verteilte Aufgabe entschieden, ob sie nach der aktuellen DoD erfüllt wurde. Falls das nicht der Fall ist, werden Punkte abgezogen.

Ihre DoD muss mindestens die folgenden Ziele enthalten:

• Das Item ist in Gitea geschlossen.
• Im Item sind die geschätzte und die tatsächliche Arbeitszeit eingetragen.
• Alle für das Item relevanten Dateien sind im aktuellen Stand des remote release Branch integriert.
• Der Tutor hat die Fertigstellung des Items im Sprint Review anhand des aktuellen Standes des remote release Branch bestätigt.

Darüber hinaus darf die DoD von der Gruppe angepasst und erweitert werden. Änderungen an der DoD müssen vom Tutor erlaubt werden.

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.