Ablauf: Unterschied zwischen den Versionen
Aus Das Sopra Wiki
Keine Bearbeitungszusammenfassung |
Keine Bearbeitungszusammenfassung |
||
| Zeile 94: | Zeile 94: | ||
#* Wo muss etwas verändert oder verbessert werden, damit besser gearbeitet werden kann? | #* 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. | #* Plan erstellen, wie diese Änderungen im nächsten Sprint umgesetzt werden können. | ||
<!-- | |||
Zu Beginn eines [[Sprint|Sprints]] findet ein [[Scrum-Meeting]] statt. Hier wird das [[Product Backlog]] gereviewed, es werden die Ziele besprochen und das Team wählt [[Item|Items]] aus dem [[Product Backlog]] aus, die bis zum Ende des [[Sprint|Sprints]] abgeschlossen werden sollen. Hierbei wird die Priorität der [[Item|Items]] berücksichtigt. | |||
Wichtig hier (und ein Kernkonzept in [[Scrum]]): '''Das Team entscheidet, wie viel es im nächsten Sprint erledigen wird.''' | |||
Zuerst wird abgeschätzt, wie viel Zeit jedes Teammitglied für den aktuellen [[Sprint]] bereitstellen kann. Danach werden die in diesem Sprint zu erledigenden [[Item|Items]] ausgewählt (in der Regeln nach Priorität) und in individuelle Aufgaben (kleinere [[Item|Items]]) aufgesplittet, welche dann im [[Sprint Backlog]] festgehalten werden. | |||
Wenn die Aufgaben identifiziert sind werden sie den Teammitgliedern, unter Berücksichtigung von Abhängigkeiten etc., zugeteilt. Jede Aufgabe erhält eine Abschätzung für die Umsetzungsdauer (in [[ETC]]) um sicher zu stellen, dass das Arbeitspensum gleichmäßig verteilt wird. | |||
Am Ende des Meetings kommt man somit zu einer Liste von Aufgaben und jeweils einer Zuteilung an einen Verantwortlichen. | |||
Die Aufgaben sollten mit Bedacht herausgearbeitet und verteilt werden, da sie in der Regel für den Rest des [[Sprint|Sprints]] festgehalten und nicht mehr geändert werden. | |||
Sollte eine unvermeidbare Änderung im Plan nötig sein, so kann man den aktuellen [[Sprint]] stoppen und mit der Planung neu beginnen. Da das aber einen großen Störfaktor darstellt sollte dies nur in extremen Situationen in Betracht gezogen werden. | |||
[[Scrum]] bringt auch diverse Herausforderungen mit sich: Zum Beispiel ist es zu Beginn schwierig, die Menge an Arbeit, die man in einem [[Sprint]] schaffen kann, einzuschätzen. So kann es passieren dass ihr es nicht schafft, alles was ihr euch für den ersten [[Sprint]] vorgenommen habt, fertig zu stellen. Der Rest des Teams kann das als Versagen werten, aber genau diese Erfahrung ist ein notwendiger Schritt um realistischere und durchdachtere Annahmen über seine Leistungen treffen zu können. | |||
--> | |||
[[Kategorie:Organisation]] | [[Kategorie:Organisation]] | ||
[[Kategorie:Scrum]] | [[Kategorie:Scrum]] | ||
Version vom 28. April 2014, 16:15 Uhr
Das Softwarepraktikum verwendet Scrum als Vorgehensmodell für die Softwareentwicklung und ist daher in insgesamt 13 Sprints (1 Sprint pro Woche) unterteilt.
wöchentliches 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)
- 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)
- 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)?
Wiederkehrende Aufgaben
Während des Semesters gibt es die folgenden wiederkehrenden Aufgaben, deren Bearbeitung jede Woche von einem oder mehreren Gruppenmitgliedern übernommen werden sollte:
- 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
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.
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.
- 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?
- Organisation der Aufgaben im Trac nach Scrum
- Mailinglisten?
...
High-Level Ablauf im Sopra
- 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"
- 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)
- 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
- Deisgn
Hier soll geklärt werden:
- 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?
- 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.
- 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)?
- 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.
