Ablauf: Unterschied zwischen den Versionen
Aus Das Sopra Wiki
Keine Bearbeitungszusammenfassung |
|||
| (5 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
{{TOCRight}}{{review}}Im Softwarepraktikum wird das Vorgehensmodell [[Scrum]] in angepasster Form angewendet. Die Anpassungen sollen vor allem den Verwaltungsaufwand für die Studenten reduzieren, die in Scrum beschriebenen Artefakte auf [[Gitea]] übertragen und die auf den Prozess aufgesetzten [[Formalien|Zulassungskriterien]] unterstützen. Die gesamtdauer des Softwarepraktikum ist in [[Sprint|Sprints]] von je einer Woche | {{TOCRight}}{{review}}Im Softwarepraktikum wird das Vorgehensmodell [[Scrum]] in angepasster Form angewendet. Die Anpassungen sollen vor allem den Verwaltungsaufwand für die Studenten reduzieren, die in Scrum beschriebenen Artefakte auf [[Gitea]] übertragen und die auf den Prozess aufgesetzten [[Formalien|Zulassungskriterien]] unterstützen. Die gesamtdauer des Softwarepraktikum ist in [[Sprint|Sprints]] von je einer Woche unterteilt. | ||
==Scrum-Artefakte im Sopra== | ==Scrum-Artefakte im Sopra== | ||
| Zeile 6: | Zeile 6: | ||
* Ein Entwicklungsabschnitt, ein sogenannter '''[[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 Entwicklungsabschnitt, ein sogenannter '''[[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. Unter andem durch die Beschreibungen einzelner Funktionen aus der Benutzersicht, die sogenannten ''User Stories''. User Stories sind zu groß um auf einmal bearbeitet zu werden, und werden deshalb wiederum in einzelne Teilaufgaben, die ''Tasks'' zerlegt. Um den Prozess im Softwarepraktikum möglichst überschaubar zu halten machen wir für das Sopra folgende Annahme: Das [[GDD]] beschreibt alle features des Spiels ausreichend, um daraus im ''[[Ablauf#Sprint%20Planning%20.28max.%2060min.29|Sprint Planning]]'' direkt Aufgaben von der Größe eines ''Tasks'' abzuleiten. Sollte eine weitere Unterteilung nötig oder erwünscht sein, schlagen wir folgende Aufteilung vor: | * 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. Unter andem durch die Beschreibungen einzelner Funktionen aus der Benutzersicht, die sogenannten ''User Stories''. User Stories sind zu groß um auf einmal bearbeitet zu werden, und werden deshalb wiederum in einzelne Teilaufgaben, die ''Tasks'' zerlegt. Um den Prozess im Softwarepraktikum möglichst überschaubar zu halten machen wir für das Sopra folgende Annahme: Das [[GDD]] beschreibt alle features des Spiels ausreichend, um daraus im ''[[Ablauf#Sprint%20Planning%20.28max.%2060min.29|Sprint Planning]]'' direkt Aufgaben von der Größe eines ''Tasks'' abzuleiten. Sollte eine weitere Unterteilung nötig oder erwünscht sein, schlagen wir folgende Aufteilung vor: | ||
** Ein '''Task''' ist ein Issue ohne ein spezielles Label. | ** Ein '''Task''' ist ein Issue ohne ein spezielles Label. | ||
* Ein '''[[Sprint Backlog]]''' besteht aus allen [[Item|Items]] (d.h. User Stories, | ** Falls Sie diese verwenden möchte, ist eine '''User Story''' ein Gitea-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 '''[[Sprint Backlog]]''' besteht aus allen [[Item|Items]] (d.h. User Stories, Issues, Bugtickets...), die einem [[Sprint]] zugewiesen wurden (<code>Issues -> Milestones -> <Sprintname></code>). Alle Items im Sprint Backlog müssen eine Priorität (z.B.: <code>prioritiy: high</code>) und eine [[ETC|Aufwandsabschätzung]] haben (z.B.: <code>estimate: 2</code>,...). | |||
Das [[Git]]-Repository verwendet mindestens zwei Branches: | Das [[Git]]-Repository verwendet mindestens zwei Branches: | ||
| Zeile 21: | Zeile 21: | ||
Im Sprint Review werden die Ergebnisse des vergangenen [[Sprint]]s demonstriert. Dabei wird für jede Aufgabe aus dem Sprint bestimmt, ob diese zur Zufriedenheit des Teams erfüllt wurde. | Im Sprint Review werden die Ergebnisse des vergangenen [[Sprint]]s demonstriert. Dabei wird für jede Aufgabe aus dem Sprint bestimmt, ob diese zur Zufriedenheit des Teams erfüllt wurde. | ||
Zu Beginn dieses Teils des Treffens führt | Zu Beginn dieses Teils des Treffens führt jedes Teammitgleid 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? | ||
| Zeile 44: | Zeile 44: | ||
====Wiederkehrende Aufgaben==== | ====Wiederkehrende Aufgaben==== | ||
Während des Softwarepraktikums müssen bestimmte organisatorische Aufgaben in jedem [[Sprint]] ab Woche 2 erledigt | Während des Softwarepraktikums müssen bestimmte organisatorische Aufgaben in jedem [[Sprint]] ab Woche 2 erledigt werden. Aufgaben können auch von mehr als einer Person erledigt werden, sofern der Umfang der Aufgaben dies zulässt und Bedarf besteht. | ||
Die folgenden wiederkehrenden Aufgaben gibt es: | Die folgenden wiederkehrenden Aufgaben gibt es: | ||
| Zeile 54: | Zeile 54: | ||
**Gemeinsam mit der Gruppe bestimmen, was aufgrund der Entwicklungsreife die als nächstes zu bearbeitenden User Stories werden soll. | **Gemeinsam mit der Gruppe bestimmen, was aufgrund der Entwicklungsreife die als nächstes zu bearbeitenden User Stories werden soll. | ||
** Vor dem Gruppentreffen das Increment nach <code>release</code> pushen (siehe [[GitWorkflow#Sprint Abschließen| Sprint Abschließen]]). | ** Vor dem Gruppentreffen das Increment nach <code>release</code> pushen (siehe [[GitWorkflow#Sprint Abschließen| Sprint Abschließen]]). | ||
*Qualitätssicherung (ab Woche 3) | *Qualitätssicherung (zwei Personen je Woche, ab Woche 3; wird in der Gruppe druchrotiert) | ||
**Commitmessages und Kommentare überprüfen. | |||
**Code auf [[CleanCode|Clean-Code]] Richtlinien prüfen. | **Code auf [[CleanCode|Clean-Code]] Richtlinien prüfen. | ||
**Architektur und Schnittstellen überprüfen und pfelgen. | |||
**Code Reviews vorbereiten und durchführen. | **Code Reviews vorbereiten und durchführen. | ||
====Aufgabe schwieriger als gedacht==== | ====Aufgabe schwieriger als gedacht==== | ||
| Zeile 96: | Zeile 92: | ||
'''Gemeinsam arbeiten''' | '''Gemeinsam arbeiten''' | ||
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. Oftmals reicht es auch schon, gemeinsame Zeiten zu vereinbaren in denen man von Zuhause aus arbeitet, sich aber gegenseitig über synchrone Kommunikationsmedien ( | 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. Oftmals reicht es auch schon, gemeinsame Zeiten zu vereinbaren in denen man von Zuhause aus arbeitet, sich aber gegenseitig über synchrone Kommunikationsmedien (z.B. über [[Dienste|Mattermost]]) erreichen kann. | ||
Bei diesen Treffen ist es sinnvoll, zuerst ein ''Daily-Scrum'' zu machen. Ein Daily-Scrum ist ein [[Scrum-Meeting]], das max. 15min dauert und bei dem jeder Teilnehmer folgende Fragen beantwortet, ohne das andere Teilnehmer Rückfragen stellen oder Kommentare abgeben: | Bei diesen Treffen ist es sinnvoll, zuerst ein ''Daily-Scrum'' zu machen. Ein Daily-Scrum ist ein [[Scrum-Meeting]], das max. 15min dauert und bei dem jeder Teilnehmer folgende Fragen beantwortet, ohne das andere Teilnehmer Rückfragen stellen oder Kommentare abgeben: | ||
