Scrum im Sopra: Unterschied zwischen den Versionen
Aus Das Sopra Wiki
K Langenfeld verschob die Seite Scrum und Gitea nach Scrum im Sopra: to add more information on how tickets are handled |
Keine Bearbeitungszusammenfassung |
||
| Zeile 1: | Zeile 1: | ||
Im Sopra wird das Vorgehensmodell [[Scrum]] in | 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]]. | ||
== 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>. | * 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. | * Das '''Product Backlog''' besteht in Gitea aus allen Items (<code>Issues</code>) die noch keinem Sprint zugeordnet wurden. | ||
* Eine '''User Story''' ist ein Issue | * 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 '''Task''' ist ein Issue ohne spezielle Labels. | ||
* Ein '''Sprint Backlog''' besteht aus allen Items die einem Sprint zugewiesen | * 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 aktuellsten auslieferbaren Stand des Produkts. | |||
== Zeitschätzung und Kooperation im Sopra == | |||
TBA | |||
== 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 einzlener 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: | In Scrum ist es üblich, Aufgaben in verschiedenen Granularitätsstufen zu beschreiben, darunter die Beschreibungen einzlener 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 | * 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. | ||
== References == | == References == | ||
<references /> | <references /> | ||
Version vom 12. Oktober 2021, 15:41 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 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.
Zeitschätzung und Kooperation im Sopra
TBA
Abweichungen vom Scrum Modell im Sopra
In Scrum ist es üblich, Aufgaben in verschiedenen Granularitätsstufen zu beschreiben, darunter die Beschreibungen einzlener 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.
