Ablauf: Unterschied zwischen den Versionen

Aus Das Sopra Wiki
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
Zeile 10: Zeile 10:
#** Final (Endabnahme durch Kunden)
#** Final (Endabnahme durch Kunden)
#* Dozenten sind Kunden, Tutoren sind "Sub-Kunden"
#* Dozenten sind Kunden, Tutoren sind "Sub-Kunden"
# Zusätzlich zum Kunden-Schema: Begleitende Vorlesungen, um Wissen zu vermitteln
# Zusätzlich zum Kunden-Schema: Begleitende Vorlesungen, um Wissen zu vermitteln
#* GDD (Was ist das? Wie schreibt man das? Was gehört da rein?)
#* GDD (Was ist das? Wie schreibt man das? Was gehört da rein?)
#* Architektur (Wie funktioniert UML, was muss man bei Spielearchitekturen beachten?)
#* Architektur (Wie funktioniert UML, was muss man bei Spielearchitekturen beachten?)
#* Code Reviews (Verbesserung der eigenen Codequalität)
#* Code Reviews (Verbesserung der eigenen Codequalität)
# 2 Phasen
# 2 Phasen
#* Deisgn
#* Deisgn

Version vom 25. April 2014, 15:16 Uhr


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

Scrum-Meeting

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


Phasen

Organisation

Entwurf

Implementierung

Milestones