Scrum im Sopra: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
K typo Markierung: 2017-Quelltext-Bearbeitung |
||
| Zeile 1: | Zeile 1: | ||
{{TOCRight}} | |||
Im Sopra wird das Vorgehensmodell [[Scrum]] in leicht vereinfachter Form angewendet. Anpassungen des Prozesses sind vor allem Vereinfachungen um für die Projektgröße übertriebenen Verwaltungsaufwand zu vermeiden, Änderungen um die in Scrum beschriebenen Artefakte auf [[Gitea]] zu übertragen, und die auf den Prozess aufgesetzten [[Formalien|Zulassungskriterien]]. | |||
== Scrum-Artefakte in Gitea<ref>https://github.com/jvandemo/github-scrum-workflow</ref><ref>https://zube.io/blog/agile-project-management-workflow-for-github-issues/</ref> == | |||
* 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 Items (<code>Issues</code>) die noch keinem Sprint zugeordnet wurden. | |||
* Eine '''User Story''' ist ein Issue dem das Label <code>user story</code> zugewiesen wurde. Zu jedem ''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 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 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_Request|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. | |||
== Backlog Items und Kooperation im Sopra == | |||
Die Arbeit im Sopra wird durch items im Product Backlog und Sprint backlog organisiert. Jedes Item im Sprint Backlog wurde im 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 Sprintbacklog geplant werden: | |||
* Arbeit am Spiel (z.B.: programmieren; 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.: wiederkehrende Aufgaben wie Clean Code und Architekturplanung usw.) | |||
* Organisationsaufgaben (z.B.: Product Owner taks, kontakt mit den Kundenvertretern usw.) | |||
* Coaching (z.B.: [https://de.wikipedia.org/wiki/Paarprogrammierung Pair Programming], andere Gruppenmitglieder unterstützen, Präsentationen vorbereiten und proben) | |||
Einzig Vorlesungen, Präsentationen und die wöchentlichen Treffen sind bereits von der vorgesehenen Arbeitslast abgezogen und sollen ''nicht'' als Backlog Items erstellt werden. | |||
=== Gemeinsame Tickets und Unterstützung === | |||
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, Gruppenmitglieder trauen sich die Aufgabe alleine nicht zu oder benötigen Hilfe um zum Beispiel schneller mit einem unbekannten Teil des Quellcodes arbeiten zu können, oder weil sich die gesamte Gruppe zum Testspielen oder Diskutieren treffen möchte. Entsprechende Items können von mehreren Studenten gleichzeitig bearbeitet werden. Dabei ist zu beachten: | |||
* Die geschätzte Zeit ist die ''Gesamtarbeitszeit'', und wird jedem zugewiesenen Gruppenmitglied zu gleichen Teilen gutgeschrieben (bei mehreren <code>estimate</code> Labels wird nur das höchste ausgewertet, die Labels werden also nicht aufsummiert oder Ähnliches) | |||
* Jedes auf einem Item zugewiesene Gruppenmitglied muss am Ende des Sprints auch daran gearbeitet haben (d.h. Zeit verbucht haben) | |||
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 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 [https://gameprogrammingpatterns.com/component.html Komposition], dass für die Aufgabe notwendig erscheint, verstanden zu haben. Ein anders 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 einem Estimate von zwei Stunden.) | |||
=== Tickets während eines Sprints hinzufügern === | |||
Es kann vorkommen, dass plötzlich Fehler auftauchen, die beim Sprint Planning vorhergesehen wurden, und dringend, am Besten sofort gefixt werden müssen (da sie Arbeit an einem andere Item blockieren). Um dies sinnvoll veralten zu können, 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), das <code>bug</code> Label setzen, und dem Sprint zuweisen. | |||
Ein für die Funktion zuständiges Gruppenmitglied kann sich dann das Item zuweisen, eine Zeitschätzung eintragen (ebenfalls mit einer kurzen Begründung, damit der Tutor die Zeitschätzung im Sprint Review nachvollziehen kann) und das Ticket bearbeiten. Die Zeitschätzung zählt dann für die [[Formalien|Zulassungskriterien]] notwendige geschätzte Arbeitszeit. | |||
Bugs die nicht im selben Sprint gefixt werden müssen können (und sollten) ebenfalls, aber als Items im Product Backlog, dokumentiert werden. | |||
== Abweichungen vom Scrum Modell im Sopra == | |||
In Scrum ist es üblich, Aufgaben in verschiedenen Granularitätsstufen zu beschreiben, darunter die Beschreibungen einzelner Funktionen aus der Benutzersicht, die sogenannten [https://de.wikipedia.org/wiki/User_Story User Stories], die wiederum in einzelne Teilaufgaben, die Tasks zerlegt werden. Um den Prozess im Sopra möglichst überschaubar zu halten, weichen wir von diesem Modell wie folgt ab: | |||
* Im Sopra liefert das das [[GDD]] in dem allermeisten Fällen eine Ausreichende Beschreibung der Spielfeatures (vergleichbar mit einer Menge an User Stories). Im ''Sprint Planning'' werden die Tasks deshalb meistens direkt vom GDD abgeleitet. | |||
== References == | |||
<references /> | |||
{{TOCRight}} | {{TOCRight}} | ||
Im Sopra wird das Vorgehensmodell [[Scrum]] in leicht vereinfachter Form angewendet. Anpassungen des Prozesses sind vor allem Vereinfachungen um für die Projektgröße übertriebenen Verwaltungsaufwand zu vermeiden, Änderungen um die in Scrum beschriebenen Artefate auf [[Gitea]] zu übertragen, und die auf den Prozess aufgesetzten [[Formalien|Zulassungskriterien]]. | Im Sopra wird das Vorgehensmodell [[Scrum]] in leicht vereinfachter Form angewendet. Anpassungen des Prozesses sind vor allem Vereinfachungen um für die Projektgröße übertriebenen Verwaltungsaufwand zu vermeiden, Änderungen um die in Scrum beschriebenen Artefate auf [[Gitea]] zu übertragen, und die auf den Prozess aufgesetzten [[Formalien|Zulassungskriterien]]. | ||
| Zeile 6: | Zeile 52: | ||
* Das '''Product Backlog''' besteht in Gitea aus allen Items (<code>Issues</code>) die noch keinem Sprint zugeordnet wurden. | * Das '''Product Backlog''' besteht in Gitea aus allen Items (<code>Issues</code>) die noch keinem Sprint zugeordnet wurden. | ||
* Eine '''User Story''' ist ein Issue dem das Label <code>user story</code> zugewiesen wurde. Zu jedem ''Sprint planning'' sollten alle User Stories außerdem ein Label für die Priorität (<code>prioritiy: high</code>,...) haben. | * Eine '''User Story''' ist ein Issue dem das Label <code>user story</code> zugewiesen wurde. Zu jedem ''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 '''Task''' ist ein Issue ohne spezielle Labels. | ||
* Ein '''Sprint Backlog''' besteht aus allen 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 Aufwandsabschätzung haben (z.B.: <code>estimate: 2</code>,...). | * Ein '''Sprint Backlog''' besteht aus allen 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 Aufwandsabschätzung haben (z.B.: <code>estimate: 2</code>,...). | ||
Das Git-Repository verwendet mindestens zwei Branches: | Das Git-Repository verwendet mindestens zwei Branches: | ||
| Zeile 32: | Zeile 78: | ||
=== Tickets während eines Sprints hinzufügern === | === Tickets während eines Sprints hinzufügern === | ||
Es kann vorkommen, dass plötzlich Fehler auftauchen, die beim Sprint Planning nicht bekannt waren, und dringend, am Besten jetzt gefixt werden müssen (da sie Arbeit an einem andere Item blockieren). Um dies sinnvoll veralten zu können, sollte das Gruppenmitglied das den Fehler gefunden hat ein Ticket mit einer sinvollen Fehlerbeschreibung anlegen (normalerweise ''was'' ist der Fehler und eine ordentliche Beschreibung ''wie'' man den Fehler verursacht nachdem man das Programm gestartet hat), <code>bug</code> Label setzen, und dem Sprint zuweisen. | Es kann vorkommen, dass plötzlich Fehler auftauchen, die beim Sprint Planning nicht bekannt waren, und dringend, am Besten jetzt gefixt werden müssen (da sie Arbeit an einem andere Item blockieren). Um dies sinnvoll veralten zu können, sollte das Gruppenmitglied das den Fehler gefunden hat ein Ticket mit einer sinvollen Fehlerbeschreibung anlegen (normalerweise ''was'' ist der Fehler und eine ordentliche Beschreibung ''wie'' man den Fehler verursacht nachdem man das Programm gestartet hat), <code>bug</code> Label setzen, und dem Sprint zuweisen. | ||
Ein für die Funktion zuständiges Gruppenmitglied kann sich dann dem Item zuweisen, eine Zeitschätzung eintragen (ebenfalls mit einer kurzen Begründung, damit der Tutor die Zeitschätzung im Sprint Review nachvollziehen kann) und das Ticket bearbeiten. Die Zeitschätzung zählt dann für die, für die Zulassungskriterien notwendige geschätzte Arbeitszeit. | Ein für die Funktion zuständiges Gruppenmitglied kann sich dann dem Item zuweisen, eine Zeitschätzung eintragen (ebenfalls mit einer kurzen Begründung, damit der Tutor die Zeitschätzung im Sprint Review nachvollziehen kann) und das Ticket bearbeiten. Die Zeitschätzung zählt dann für die, für die Zulassungskriterien notwendige geschätzte Arbeitszeit. | ||
| Zeile 39: | Zeile 85: | ||
== Abweichungen vom Scrum Modell im Sopra == | == Abweichungen vom Scrum Modell im Sopra == | ||
In Scrum ist es üblich, Aufgaben in verschiedenen Granularitätsstufen zu beschreiben, darunter die Beschreibungen | In Scrum ist es üblich, Aufgaben in verschiedenen Granularitätsstufen zu beschreiben, darunter die Beschreibungen einzelner Funktionen aus der Benutzersicht, die sogenannten [https://de.wikipedia.org/wiki/User_Story User Stories], die wiederum in einzelne Teilaufgaben, die Tasks zerlegt werden. Um den Prozess im Sopra möglichst überschaubar zu halten, weichen wir von diesem Modell wie folgt ab: | ||
* Im Sopra liefert das das [[GDD]] in dem allermeisten Fällen eine Ausreichende Beschreibung der Spielfreatures (vergleichbar mit User Stories). Im ''Sprint Planning'' werden die Tasks deshalb meistens direkt vom GDD abgeleitet. | * Im Sopra liefert das das [[GDD]] in dem allermeisten Fällen eine Ausreichende Beschreibung der Spielfreatures (vergleichbar mit User Stories). Im ''Sprint Planning'' werden die Tasks deshalb meistens direkt vom GDD abgeleitet. | ||
Version vom 13. Oktober 2021, 11:09 Uhr
Im Sopra wird das Vorgehensmodell Scrum in leicht vereinfachter Form angewendet. Anpassungen des Prozesses sind vor allem Vereinfachungen um für die Projektgröße übertriebenen Verwaltungsaufwand zu vermeiden, Änderungen um die in Scrum beschriebenen Artefakte auf Gitea zu übertragen, und die auf den Prozess aufgesetzten Zulassungskriterien.
Scrum-Artefakte in Gitea[1][2]
- Ein Sprint wird in Gitea durch einen Milestone (
Issues -> Milestones) dargestellt. Die Gitea-Milestones bekommen dann den NamenSprint<woche> (Beschreibung)also zum BeispielSprint00 (Hausaufgabe). - Das Product Backlog besteht in Gitea aus allen Items (
Issues) die noch keinem Sprint zugeordnet wurden. - Eine User Story ist ein Issue dem das Label
user storyzugewiesen wurde. Zu jedem Sprint planning sollten alle User Stories außerdem ein Label für die Priorität (prioritiy: high,...) haben. - Ein Task ist ein Issue ohne spezielle Labels.
- Ein Sprint Backlog besteht aus allen Items die einem Sprint zugewiesen wurden (
Issues -> Milestones -> <Sprintname>). Alle Items im Sprint Backlog müssen eine Priorität (normalerweiseprioritiy: high) und eine Aufwandsabschätzung haben (z.B.:estimate: 2,...).
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 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.
Backlog Items und Kooperation im Sopra
Die Arbeit im Sopra wird durch items im Product Backlog und Sprint backlog organisiert. Jedes Item im Sprint Backlog wurde im 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 Sprintbacklog geplant werden:
- Arbeit am Spiel (z.B.: programmieren; 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.: wiederkehrende Aufgaben wie Clean Code und Architekturplanung usw.)
- Organisationsaufgaben (z.B.: Product Owner taks, kontakt mit den Kundenvertretern usw.)
- Coaching (z.B.: Pair Programming, andere Gruppenmitglieder unterstützen, Präsentationen vorbereiten und proben)
Einzig Vorlesungen, Präsentationen und die wöchentlichen Treffen sind bereits von der vorgesehenen Arbeitslast abgezogen und sollen nicht als Backlog Items erstellt werden.
Gemeinsame Tickets und Unterstützung
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, Gruppenmitglieder trauen sich die Aufgabe alleine nicht zu oder benötigen Hilfe um zum Beispiel schneller mit einem unbekannten Teil des Quellcodes arbeiten zu können, oder weil sich die gesamte Gruppe zum Testspielen oder Diskutieren treffen möchte. Entsprechende Items können von mehreren Studenten gleichzeitig bearbeitet werden. Dabei ist zu beachten:
- Die geschätzte Zeit ist die Gesamtarbeitszeit, und wird jedem zugewiesenen Gruppenmitglied zu gleichen Teilen gutgeschrieben (bei mehreren
estimateLabels wird nur das höchste ausgewertet, die Labels werden also nicht aufsummiert oder Ähnliches) - Jedes auf einem Item zugewiesene Gruppenmitglied muss am Ende des Sprints auch daran gearbeitet haben (d.h. Zeit verbucht haben)
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 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 anders 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 einem Estimate von zwei Stunden.)
Tickets während eines Sprints hinzufügern
Es kann vorkommen, dass plötzlich Fehler auftauchen, die beim Sprint Planning vorhergesehen wurden, und dringend, am Besten sofort gefixt werden müssen (da sie Arbeit an einem andere Item blockieren). Um dies sinnvoll veralten zu können, 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), das bug Label setzen, und dem Sprint zuweisen.
Ein für die Funktion zuständiges Gruppenmitglied kann sich dann das Item zuweisen, eine Zeitschätzung eintragen (ebenfalls mit einer kurzen Begründung, damit der Tutor die Zeitschätzung im Sprint Review nachvollziehen kann) und das Ticket bearbeiten. Die Zeitschätzung zählt dann für die Zulassungskriterien notwendige geschätzte Arbeitszeit.
Bugs die nicht im selben Sprint gefixt werden müssen können (und sollten) ebenfalls, aber als Items im Product Backlog, dokumentiert werden.
Abweichungen vom Scrum Modell im Sopra
In Scrum ist es üblich, Aufgaben in verschiedenen Granularitätsstufen 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 Sopra möglichst überschaubar zu halten, weichen wir von diesem Modell wie folgt ab:
- Im Sopra liefert das das GDD in dem allermeisten Fällen eine Ausreichende Beschreibung der Spielfeatures (vergleichbar mit einer Menge an User Stories). Im Sprint Planning werden die Tasks deshalb meistens direkt vom GDD abgeleitet.
References
Im Sopra wird das Vorgehensmodell Scrum in leicht vereinfachter Form angewendet. Anpassungen des Prozesses sind vor allem Vereinfachungen um für die Projektgröße übertriebenen Verwaltungsaufwand zu vermeiden, Änderungen um die in Scrum beschriebenen Artefate auf Gitea zu übertragen, und die auf den Prozess aufgesetzten Zulassungskriterien.
Scrum-Artefakte in Gitea[1][2]
- Ein Sprint wird in Gitea durch einen Milestone (
Issues -> Milestones) dargestellt. Die Gitea-Milestones bekommen dann den NamenSprint<woche> (Beschreibung)also zum BeispielSprint00 (Hausaufgabe). - Das Product Backlog besteht in Gitea aus allen Items (
Issues) die noch keinem Sprint zugeordnet wurden. - Eine User Story ist ein Issue dem das Label
user storyzugewiesen wurde. Zu jedem Sprint planning sollten alle User Stories außerdem ein Label für die Priorität (prioritiy: high,...) haben. - Ein Task ist ein Issue ohne spezielle Labels.
- Ein Sprint Backlog besteht aus allen Items die einem Sprint zugewiesen wurden (
Issues -> Milestones -> <Sprintname>). Alle Items im Sprint Backlog müssen eine Priorität (normalerweiseprioritiy: high) und eine Aufwandsabschätzung haben (z.B.:estimate: 2,...).
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 Pull-Request veröffentlicht. Dieser Branch (nur dieser) wird dazu verwendet die Arbeit der Sprints und das Spiel zu bewerten und repräsentiert den aktuellsten auslieferbaren Stand des Produkts.
Backlog Items und Kooperation im Sopra
Die Arbeit im Sopra wird durch items im Product Backlog und Sprint backlog organisiert. Jedes Item im Sprint Backlog wurde im 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 Sprintbacklog geplant werden:
- Arbeit am Spiel (z.B.: programmieren; 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ätsicherung (z.B.: wiederkehrende Aufgaben wie Clean Code und Architekturplanung usw.)
- Organisationsaufgaben (z.B.: Product Owner taks, kontakt mit den Kundenvertretern usw.)
- Coaching (z.B.: Pair Programming, andere Gruppenmitglieder unterstützen, Präsnetationen vorbereiten und üben)
Einzig Vorlesungen, Präsentationen und die wöchentlichen Treffen sind bereits von der notwendigen Stundenzahl abgezogen und sollen nicht noch zusätzlich als Backlog Items erstellt werden.
Gemeinsame Tickets und Unterstützung
Items für einen Sprint sollten möglichst so angelegt werden, dass sie überschaubar und für eine Person alleine zu bewältigen sind. Oft ist dies aber nicht möglich, Gruppenmitglieder trauen sich die Aufgabe alleine nicht zu oder benötigen Hilfe um zum Beispiel schneller mit einem unbekannten Teil des Quellcodes abreiten zu können, aufgrund mangelnder Erfahrung mit Werkzeugen, oder weil sich die gesamte Gruppe zum Testspielen trifft. Entsprechende Items können von mehreren Studenten gleichzeitig bearbeitet werden. Dabei ist zu beachten:
- Die geschätzte Zeit ist die Gesamtarbeitszeit, und wird jedem verantwortlichenen Gruppenmitglied zu gleichen Teilen zugeschrieben (bei mehreren
estimateLabels wird nur das höchste ausgewertet, die Labels werden als nicht aufsummiert o.ä.) - Jedes auf dem Ticket eingtetragene Gruppenmitglied muss am Ende des Sprints auch am Ticket gearbeitet haben (d.h. Zeit verbucht haben)
Es ist auch möglich, dass Aufgaben nicht zu gleichen Teilen allen verantwortlichen Gruppenmitgliedern zugeschrieben werden soll. In diesem Fall sollten zwei Tickets mit entsprechenden Estimates und Beschreibungen angelegt werden (zum Beispiel könnte ein Gruppenmitglied eine größere Programmieraufgabe mit geschätzten acht Studen wählen, ist sich aber nicht sicher das Prinzip von Komposition, dass für die Aufgabe notwendig erscheint, verstanden zu haben. Ein anders 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 mit dem ersten Gruppenmitglied als einzige verantwortliches Gruppenmitglied; und ein weiteres Ticket für die Unterstützung mit dem zweiten Gruppenmitglied und einem Estimate von zwei Stunden.)
Tickets während eines Sprints hinzufügern
Es kann vorkommen, dass plötzlich Fehler auftauchen, die beim Sprint Planning nicht bekannt waren, und dringend, am Besten jetzt gefixt werden müssen (da sie Arbeit an einem andere Item blockieren). Um dies sinnvoll veralten zu können, sollte das Gruppenmitglied das den Fehler gefunden hat ein Ticket mit einer sinvollen Fehlerbeschreibung anlegen (normalerweise was ist der Fehler und eine ordentliche Beschreibung wie man den Fehler verursacht nachdem man das Programm gestartet hat), bug Label setzen, und dem Sprint zuweisen.
Ein für die Funktion zuständiges Gruppenmitglied kann sich dann dem Item zuweisen, eine Zeitschätzung eintragen (ebenfalls mit einer kurzen Begründung, damit der Tutor die Zeitschätzung im Sprint Review nachvollziehen kann) und das Ticket bearbeiten. Die Zeitschätzung zählt dann für die, für die Zulassungskriterien notwendige geschätzte Arbeitszeit.
Bugs die nicht im selben Sprint gefixt werden müssen können (und sollten) ebenfalls, aber als Items im Product Backlog, dukumentiert werden.
Abweichungen vom Scrum Modell im Sopra
In Scrum ist es üblich, Aufgaben in verschiedenen Granularitätsstufen 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 Sopra möglichst überschaubar zu halten, weichen wir von diesem Modell wie folgt ab:
- Im Sopra liefert das das GDD in dem allermeisten Fällen eine Ausreichende Beschreibung der Spielfreatures (vergleichbar mit User Stories). Im Sprint Planning werden die Tasks deshalb meistens direkt vom GDD abgeleitet.
