Ablauf: Unterschied zwischen den Versionen

{{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 unterscheidet eine Reihe von Artefakten, die für die Arbeit mit Scrum notwendig sind. Das sind vor allem, das Product- und Sprint Backlog mit den darin definierten Aufgaben in Form vorn Tasks und User Stories. Da [[Gitea]] keine direkte Unterstützung für Scrum bietet, werden die von Scrum verwendeten Artefakte wie folgt auf Giteakonstrukte abgebildet:

* 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:

** Ein '''Task''' ist ein Issue ohne ein spezielles Label.

** 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>,...).

Jeder [[Sprint]] im Softwarepraktikum 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. Das Treffen ist in drei Teile, das Sprint Review, Sprint Planning und Sprint Retrospective unterteilt.  

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 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:

In diesem Teil des Treffens sollten alle Dinge geklärt werden, die den bisherigen Prozess betreffen. Dazu wird diskutiert, was im letzten Sprint im Hinblick auf Menschen, Beziehungen, Prozesse, Tools gut bzw. schlecht gelaufen ist. Bei Bedarf stellt das Team fest, wo etwas verändert werden muss, damit die gemeinsamen Ziele besser erreicht werden können. Dabei wird schriftlich festgehalten, wie diese Änderungen im nächsten [[Sprint]] umgesetzt wird. Im Speziellen sollte während der Sprint Retrospektive auch die [[DoD]] diskutiert und im Bedarfsfall angepasst werden.

Zuerst sollte geklärt werden, wie viel Zeit jedes Teammitglied und damit das gesamte Team für den nächsten [[Sprint]] bereitstellen kann. Danach wählt man gemeinsam ein [[Item]] (unter Berücksichtigung der Priorität) aus dem [[Product Backlog]] aus, das im nächsten [[Sprint]] umgesetzt werden soll. Das [[Item]] sollte nun so lange in kleinere [[Item]]s, zerlegt werden (z.B. zuerst in User Stories und dann in Tasks, oder auch direkt in Tasks), bis diese direkt als an einzelne Teammitglieder verteilt werden können. Für jedes der so entstandenen ''atomaren'' [[Item]]s sollte nun der Arbeitsaufwand ([[ETC]]) abgeschätzt werden. Danach werden die atomaren [[Item]]s in das neue [[Sprint Backlog]] verschoben.  

 

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.

*Qualitätssicherung (zwei Personen je Woche, ab Woche 3; wird in der Gruppe druchrotiert)

Natürlich kann es vorkommen, dass man eine Aufgabe als zu leicht einschätzt und sich während der Bearbeitung abzeichnet, dass man die Aufgabe innerhalb des aktuellen [[Sprint]]s nicht erledigen kann. Daher ist es zum einen wichtig, bei den eigenen Aufgaben auf die Abhängigkeiten zu den Aufgaben anderer Teammitglieder zu achten und sich entsprechend abzusprechen (speziell sollte man vermeiden, erst kurz vorm Ende des [[Sprint]]s mit Aufgaben zu beginnen, die andere für die Erledigung ihrer Aufgaben brauchen). Zum anderen '''müssen''' die anderen Teammitglieder und der Tutor über ein Kommentar im entsprechenden Ticket '''rechtzeitig''' informiert werden, dass eine Aufgabe nicht mehr innerhalb des aktuellen [[Sprint]]s erledigt werden kann, und wo die Probleme mit  der Aufgabe lagen.

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]]).

Die 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.

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.