Scrum🔖

Scrum ist eine agile Methode, die in der Wirtschaft hauptsächlich für die Softwareentwicklung eingesetzt wird. Sie setzt auf kurze Entwicklungszyklen (Sprints), die dabei helfen, sich Schritt für Schritt einem finalen Produkt zu nähern.

Ihr werdet an Euren Spielen in sogenannten Scrum Teams arbeiten.

Ablauf🔖

Die einzelnen Arbeitsphasen heißen Sprints. In den Sprints arbeitet ihr selbständig und teil Euch Eure Aufgaben ein. Im Sprint arbeitet ihr an den Epics, User Stories und Fehlerbeschreibung (siehe unten) auf Eurem Kanbanboard. Ein Sprint dauert in der Regel eine Doppelstunde.

Sprint Planning🔖

Im Sprint Planning besprecht Ihr im Scrum Team die nächsten Arbeitsschritte für die kommende Doppelstunde.

In dieser Phase füllt Ihr die Spalte "Sprint" Eures Kanbanboards. Anschließend sortiert Ihr die User Stories nach der Reihenfolgen, in der Ihr diese Bearbeitung wollt.

Am Ende des Sprint Plannings erläutert Ihr der Klassen/dem Lehrer, wie das Team vorgehen möchte, und holt sich Feedback ein.

Daily Stand-up🔖

Ihr besprecht Euch am Anfang des Sprints und zu Beginn jeder Arbeitsphase, bevor Ihr mit der Weiterarbeit am Produkt beginnt, im Scrum Team - am besten mit den folgenden drei W-Fragen:

1. Was habe ich getan, um das Team beim Erreichen des Ziels zu unterstützen?
2. Was werde ich heute tun, um das Team beim Erarbeiten des Ziels zu unterstützen?
3. Welche Schwierigkeiten gibt es aktuell, die es uns erschweren, das Ziel fertigzustellen?

Sprint Review🔖

Am Ende jedes Sprints beantwortet Ihr die Leitfragen oder stellt Eure Ergebnisse dem Kurs vor. Der Lehrer aktualisiert ggfs. Euer Kanbanboard entsprechend Eures heutigen Fortschritts.

Leitfragen:

• Was haben wir heute geschafft?
• Wo stehen wir?
• Wie hat die Zusammenarbeit heute geklappt?
• Inwieweit sind wir mit dem Ergebnis des heutigen Sprints zufrieden?

Kanbanboard🔖

Das Kanbanboard dient dem Scrum Team zur Strukturierung. Auf dem Board dokumentiert Ihr eure Planung mit den einzelnen Arbeitsschritten. Auf Kabanboard seht Ihr immer gleich auf einen Blick, was noch zu tun ist, woran Euer Scrum Team gerade arbeitet und was Ihr bereits erledigt habt. Auf dem Kanbanboard werden sich Epics, User Stories und Fehlerbeschreibungen befinden.

Spielidee🔖

Die Spielidee ist der zentrale Ausgangspunkt von Eurem Spiel. Sie repräsentiert eine Karte auf dem Kanbanboard. Die Spielidee kann sich mit der Zeit verändern und muss immer wieder reflektiert werden. Die Spielidee dient Euch auch neue Epics zu formulieren und den Fokus des Spiels nicht aus den Augen zu verlieren.

Beispiel:

Ein Hase names Bugs soll automatisch von links nach rechts laufen.

Dabei soll er auf einem Untergrund laufen, der ab und zu verschwindet. Bugs kann in diese Lücken fallen und das Spiel ist verloren. Bugs kann springen, um über Feinde zu springen und den Lücken zu entkommen.

Die Feinde sollen sich unterschiedlich bewegen und wenn Bugs einen Feind berührt ist das Spiel verloren. Um sich gegen Feinde zu schützen, kann Bugs eine Fähigkeit einsetzen, dafür muss er eine Karotte einsetzen. Karotten sollen im Verlauf des Spiels eingesammelt werden können.

Ziel des Spiels ist es so weit wie möglich nach rechts zu laufen.

Epics🔖

Epics sind größere Aufgabeneinheiten, die in mehrere kleinere Aufgaben (names User Stories) unterteilt werden können.

Zum Beispiel könnten Epics so lauten:

Grundlagen eines Endless-Runners mit einem Hasen.

User Stories🔖

User Stories verfeinern ein Epic in kleinere überprüfbare Aufgaben, die innerhalb einer kurzen Zeit umgesetzt werden können (z.B. in einer Unterrichtsstunde). User Stories werden immer aus der Perspektive einer Rolle geschrieben. Außerdem ist es nützlich, wenn die User Story einen Zweck enthält.

Rolle in der Spieleprogrammierung können sein:

• Der reale Spieler
• Das Spielerobjekt im Spiel
• Die Feindobjekte im Spiel

Bezogen auf das Beispiel für ein Epic (siehe oben) könnten folgende User Stories definiert werden:

• Als Hase möchte ich springen können, um Feinden auszuweichen.
• Als Spiel möchte ich die zurückgelegte Distanz des Hasen anzeigen, um den Benutzer über sein Fortschreiten zu informieren.
• Als Feind möchte ich den Hasen verletzen, um das Spiel schwieriger zu machen.
• Als Plattform möchte ich bei Berührung nach einer kurzen Zeit verschwinden, um das Spiel schwieriger zu machen.

Fehlerbeschreibungen🔖

Eine Fehlerbeschreibung besteht aus einem Titel, den Schritten zum Reproduzieren des Fehlers und einer Beschreibung des Fehlers. Wenn ein Fehler gefunden wird, sollte er sofort im Kanbanboard aufgenommen werden. Der Fehler muss nicht direkt behoben werden. Beispiel:

Titel

Plattformen verschwinden direkt bei der ersten Berührung

Schritte zum Reproduzieren

Es ist nicht ganz klar, wann der Fehler auftritt.

Fehlerbeschreibung

Wenn es passiert, dann verschwindet die Plattform bereits kurz nach der Landung und es besteht keine Möglichkeit erneut zu springen.