Ablauf: Unterschied zwischen den Versionen
Aus Das Sopra Wiki
K Änderungen von Langenfeld (Diskussion) wurden auf die letzte Version von LeonH zurückgesetzt Markierung: Zurücksetzung |
mergen mit scrum-im-sopra |
||
| Zeile 1: | Zeile 1: | ||
{{review}} | __TOC__{{review}}Im Softwarepraktikum wird das Vorgehensmodell [[Scrum]] in angepasster Form angewendet. Die Anpassungen sollen vor allem den Verwaltungsaufwand reduzieren, die in Scrum beschriebenen Artefakte auf [[Gitea]] übertragen, und mehr Raum für Fehler lassen und die auf den Prozess aufgesetzten [[Formalien|Zulassungskriterien]] unterstützen. Die gesamtdauer des Softwarepraktikum ist in [[Sprint|Sprints]] von je einer Woche Dauer unterteilt. | ||
== Scrum-Artefakte im Sopra == | |||
Da [[Gitea]] keine direkte Unterstützung für Scrum bietet, werden die von Scrum verwendeten Artefakte wie folgt auf Giteakonstrukte abgebildet: | |||
== Wöchentliches Gruppentreffen mit Tutor == | * Ein '''[[Sprint]]''' wird in [[Gitea]] durch einen Milestone (<code>Issues -> Milestones</code>) dargestellt. Die Gitea-Milestones bekommen dann den Namen <code>Sprint<woche> (Beschreibung)</code> also zum Beispiel <code>Sprint00 (Hausaufgabe)</code>. | ||
* Das '''Product Backlog''' besteht in Gitea aus allen [[Item|Items]] (<code>Issues</code>) die noch keinem Sprint zugeordnet wurden. In Scrum ist es üblich, Aufgaben mit verschiedener Detailtiefe zu beschreiben, darunter die Beschreibungen einzelner Funktionen aus der Benutzersicht, die sogenannten User Stories, die wiederum in einzelne Teilaufgaben, die Tasks zerlegt werden. Um den Prozess im Softwarepraktikum möglichst überschaubar zu halten nehmen wir für das Sopra an, dass das [[GDD]] alle Spielfeatures ausreichend gut beschreibt, um daraus im ''[[Ablauf#Sprint%20Planning%20.28max.%2060min.29|Sprint Planning]]'' direkt Issues von Taskgröße abzuleiten. Sollte eine weitere Unterteilung nötig oder erwünscht sein, schlagen wir folgende Aufteilung vor: | |||
** Eine '''User Story''' ist ein Issue dem das Label <code>user story</code> zugewiesen wurde. Zu jedem ''[[Ablauf#Sprint%20Planning%20.28max.%2060min.29|Sprint planning]]'' sollten alle User Stories außerdem ein Label für die Priorität (<code>prioritiy: high</code>,...) haben. | |||
** Ein '''Task''' ist ein Issue ohne spezielle Labels. | |||
* Ein '''[[Sprint Backlog]]''' besteht aus allen [[Item|Items]], die einem [[Sprint]] zugewiesen wurden (<code>Issues -> Milestones -> <Sprintname></code>). Alle Items im Sprint Backlog müssen eine Priorität (normalerweise <code>prioritiy: high</code>) und eine [[ETC|Aufwandsabschätzung]] haben (z.B.: <code>estimate: 2</code>,...). | |||
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 [[Gitea#Pull%20Request|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]] 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. | 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 normalerweise in die drei Teile Sprint Review, Sprint Planning und Sprint Retrospective unterteilt. Bei den ersten zwei Treffen kann es aber sinnvoll sein, sich erst einmal langsam an diese Vorgehensweise heranzutasten und die Aufteilung nicht so streng zu verfolgen. Erst wenn die eigentliche Implementierungsphase beginnt sollte man sich möglichst eng an diese Aufteilung halten. | Dazu ist das Treffen normalerweise in die drei Teile Sprint Review, Sprint Planning und Sprint Retrospective unterteilt. Bei den ersten zwei Treffen kann es aber sinnvoll sein, sich erst einmal langsam an diese Vorgehensweise heranzutasten und die Aufteilung nicht so streng zu verfolgen. Erst wenn die eigentliche Implementierungsphase beginnt sollte man sich möglichst eng an diese Aufteilung halten. | ||
| Zeile 12: | Zeile 23: | ||
Zu Beginn dieses Teils des Treffens führt das Team zuerst vor, was für neue Features im letzten [[Sprint]] fertiggestellt worden sind. Danach erklärt entweder der [[Product Owner]] (siehe [[Ablauf#Wiederkehrende Aufgaben|Wiederkehrende Aufgabe "Product Owner"]]) oder jedes Teammitglied einzeln, welche Aufgaben aus dem letzten [[Sprint]] im Sinne der [[DoD|Definition of Done]] abgeschlossen wurden, bzw. welche übrig geblieben sind. Dann wird die Aufwandsabschätzung überprüft. Dabei sollten zwei Punkte geklärt werden: | Zu Beginn dieses Teils des Treffens führt das Team zuerst vor, was für neue Features im letzten [[Sprint]] fertiggestellt worden sind. Danach erklärt entweder der [[Product Owner]] (siehe [[Ablauf#Wiederkehrende Aufgaben|Wiederkehrende Aufgabe "Product Owner"]]) oder jedes Teammitglied einzeln, welche Aufgaben aus dem letzten [[Sprint]] im Sinne der [[DoD|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 [[Item]]s im letzten [[Sprint]] richtig oder hat man sich nach oben oder unten verschätzt? | * War die Abschätzung für die einzelnen [[Item]]s 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? | * 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. | Zum Schluss sollte noch geklärt werden, ob mit der aktuellen Arbeitsweise der nächste Milestone erreicht werden kann. | ||
| Zeile 60: | Zeile 71: | ||
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 [[Formalien#Benotung|Benotung]]). | 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 [[Formalien#Benotung|Benotung]]). | ||
== Organisieren der gemeinsamen Arbeit als Items im Sprint- und Product-Backlog == | |||
Die Arbeit im Softwarepraktikum wird durch [[Item|Items]] im [[Product Backlog]] und [[Sprint Backlog]] organisiert. Jedes Item im Sprint Backlog wurde im [[Ablauf#Sprint%20Planning%20.28max.%2060min.29|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.: [[Ablauf#Wiederkehrende%20Aufgaben|wiederkehrende Aufgaben]] wie [[CleanCode|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) | |||
Nur Vorlesungen, [[Formalien#Pr.C3.A4sentationen|Präsentationen]] und die [[Ablauf#W.C3.B6chentliches%20Gruppentreffen%20mit%20Tutor|wöchentlichen Treffen]] sind bereits von der vorgesehenen Arbeitslast abgezogen und sollen ''nicht'' als Backlog Items erstellt werden. | |||
=== Gemeinsame Tickets und Unterstützung === | |||
[[Item|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 [[Item|Items]] können von mehreren Studenten gleichzeitig bearbeitet werden. Dabei ist zu beachten: | |||
* Die [[ETC|geschätzte Zeit]] ist die ''Gesamtarbeitszeit'' und wird jedem zugewiesenen Gruppenmitglied zu gleichen Teilen gutgeschrieben, nachdem das Item erfolgreich geschlossen ist. Bei mehreren <code>estimate</code> Labels wird nur das höchste ausgewertet, die Labels werden also insbesondere nicht aufsummiert. | |||
* Jedes auf einem [[Item]] zugewiesene Gruppenmitglied muss am Ende des [[Sprint|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 [[ETC|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 [[Ablauf#Sprint%20Planning%20.28max.%2060min.29|Sprint Planning]] nicht vorhergesehen wurden. Insbesondere Bugs, die nicht die eigene Arbeit behindern, aber zu reparieren sind, sollten als [[Item|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 <code>bug</code> 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 [[ETC|Zeitschätzung]] eintragen (ebenfalls mit einer kurzen Begründung, damit der Tutor die Zeitschätzung im [[Ablauf#Sprint%20Review%20.28max.%2030min.29|Sprint Review]] nachvollziehen kann), und das Ticket bearbeiten. Die Zeitschätzung zählt dann auch für die in den [[Formalien|Zulassungskriterien]] notwendige geschätzte Arbeitszeit. | |||
== Hinweise zur Arbeitsorganisation == | == Hinweise zur Arbeitsorganisation == | ||
| Zeile 72: | Zeile 107: | ||
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. | 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. | ||
{{BA|Dietsch|Hier könnte man noch andere Dinge erzählen. Z.B. | {{BA|Dietsch|Hier könnte man noch andere Dinge erzählen. Z.B. | ||
