Ablauf: Unterschied zwischen den Versionen

Aus Das Sopra Wiki
← Zum vorherigen Versionsunterschied
VisuellWikitext
Dietsch (Diskussion | Beiträge)
Bürokraten, sopra, sopra17, sopradozenten, soprapre17, Administratoren
2.806 Bearbeitungen
LeonH (Diskussion | Beiträge)
sopra
126 Bearbeitungen
 
(48 dazwischenliegende Versionen von 5 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
{{Stub}}
{{review}}
{{Interna}}
__TOC__
__TOC__


Zeile 7: Zeile 6:
== Wöchentliches Gruppentreffen  mit Tutor ==
== Wöchentliches Gruppentreffen  mit Tutor ==
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 in 3 Teile unterteilt.  
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.  


=== Sprint Review ('''max. 30min''') ===
=== Sprint Review (max. 30min) ===
*  Product Owner gibt basierend auf [[DoD]] Einschätzung ab, was fertig und was nicht fertig ist.
Im Sprint Review werden die Ergebnisse des vergangenen [[Sprint]]s demonstriert und besprochen und bestimmt, ob alle Ziele erreicht worden sind.  
*  Team zeigt, was alles fertig geworden ist und beantwortet Fragen zum Fortschritt.
*  Team erklärt dabei, was es für Probleme gab und wie diese gelöst worden sind.
*  Product Owner erklärt den aktuellen Stand des Product Backlogs und speziell Änderungen an der Aufwandsabschätzung.  


=== Sprint Planning ('''max. 60min''') ===
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:
*  Was wird im nächsten Sprint gemacht? Product Backlog anschauen, von oben nach unten (PO sollte es geordnet haben). An die Recurring Tasks denken.
* War die Abschätzung für die einzelnen [[Item]]s im letzten [[Sprint]] richtig oder hat man sich nach oben oder unten verschätzt?
*  Wer erledigt von den ausgewählten Dingen was (Arbeitsverteilung)?
* 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.
 
Die Ergebnisse aus dem Sprint Review können dann direkt im nächsten Teil des Gruppentreffens verwendet werden.
 
=== Sprint Retrospective (max. 15min) ===
 
 
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 sollte man feststellen, wo etwas verändert werden muss, damit die gemeinsamen Ziele besser erreicht werden können. Dabei sollte man einen schriftlichen Plan erstellen, wie man diese Änderungen im nächsten [[Sprint]] umsetzen kann.
Im Speziellen sollte während der Sprint Retrospektive auch die [[DoD]] diskutiert und im Bedarfsfall angepasst werden.
 
Dieser Schritt finde '''vor''' dem nächsten Sprintplanning statt, da Änderungsvorschläge direkt im anschließenden Sprint umgesetzt werden sollen.
 
=== Sprint Planning (max. 60min) ===
In diesem Teil des Treffens werden die Ziele für den nächsten Sprint geplant.
 
==== Ablauf ====
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.     
Diesen Vorgang wiederholt man nun so lange, bis man die Zeit, die das Team für den nächsten [[Sprint]] zur Verfügung hat, aufgebraucht hat. Erst danach werden die einzelnen [[Item]]s im [[Sprint Backlog]] unter den Teammitgliedern aufgeteilt.  
Am Ende diesen Teils kommt man somit zu einem neuen [[Sprint Backlog]] mit einer Liste von [[Item]]s die jeweils einem Verantwortlichen zugeteilt sind.


==== Wiederkehrende Aufgaben ====
==== Wiederkehrende Aufgaben ====
Während des Semesters kann es sinnvoll sein, folgende Aufgaben in jedem Sprint immer wieder neu zu verteilen:
Während des Softwarepraktikums müssen bestimmte organisatorische Aufgaben in jedem [[Sprint]] ab Woche 2 erledigt werden. Diese Aufgaben können immer vom gleichen Teammitglied, oder abwechselnd ausgeführt werden. Aufgaben können auch von mehr als einer Person erledigt werden, sofern der Umfang der Aufgaben dies zulässt und Bedarf besteht.


* Product Owner (ab Woche 2)
Die folgenden wiederkehrenden Aufgaben gibt es:
** Pflegen und Anpassen von Requirements und User Stories im Product Backlog.
* [[Product_Owner|Product Owner]] (ab Woche 2)
** Verfeinern von Requirements zu User Stories.
** Pflegen und Anpassen von User Stories und Tasks im [[Product Backlog]].
** Requirements nach Entwicklungsreife ordnen.
** Verfeinern von User Stories zu Tasks.
** User Stories mit Prioritäten versehen und Prioritäten aktualisieren.
** Gruppentreffen vorbereiten (was ist fertig, wie war die Aufwandsabschätzung).
** Gruppentreffen vorbereiten (was ist fertig, wie war die Aufwandsabschätzung).
** 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]]).
* Qualitätssicherung (ab Woche 3)
** Code auf [[CleanCode|Clean-Code]] Richtlinien prüfen.
** Code Reviews vorbereiten und durchführen.
** ReSharper-Konformität im ganzen Projekt überprüfen und ggf. herstellen.
* Architektur (ab Woche 3)
* Architektur (ab Woche 3)
** Schnittstellen definieren
** Schnittstellen definieren.
** Architekturbeschreibungen pflegen
** Architekturbeschreibungen pflegen.
** Einhaltung der Architektur sicherstellen
** Einhaltung der Architektur im Projekt sicherstellen und beides ggf. anpassen.
* Qualitätssicherung (ab Woche 6)
** Einen Überblick über die Gesamtarchitektur behalten und bei der Umsetzung verschiedener Tasks stets die Abhängigkeiten innerhalb der Architektur berücksichtigen.
** Code auf Clean-Code Richtlinien prüfen.
** Code Reviews vorbereiten
** ReSharper Konformität herstellen


==== Aufgabe schwieriger als gedacht ====
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 '''muss''' man seine Teammitglieder und den Tutor über ein Kommentar im entsprechenden Ticket '''rechtzeitig''' informieren, dass eine Aufgabe nicht mehr innerhalb des aktuellen [[Sprint]]s erledigt werden kann.


=== Sprint Retrospective ('''max. 15min''') ===
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]]).
*  Diskutieren, was im letzten Sprint im Hinblick auf Menschen, Beziehungen, Prozesse, Tools gut bzw. schlecht gelaufen ist.
 
*  Wo muss etwas verändert oder verbessert werden, damit besser gearbeitet werden kann?
== Hinweise zur Arbeitsorganisation ==  
*  Plan erstellen, wie diese Änderungen im nächsten Sprint umgesetzt werden können.
'''Gemeinsam arbeiten'''


== Arbeitsorganisation ==
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 (Skype, IRC, Instant Messaging,...) erreichen kann.  
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 (Skype, IRC, Instant Messaging,...) erreichen kann.  


Zeile 52: Zeile 73:
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|Alleine arbeiten: Auf Code-Qualität achten [[Clean Code]], Abschätzungen korrigieren und kommunizieren (auch wegen Punkten), ... }}
Während des offiziellen Gruppentreffens sucht sich jedes Gruppenmitglied Aufgaben aus dem Product-Backlog heraus, die er/sie im kommenden Sprint bearbeiten wird. Eine Grundregel in Scrum ist es, dass '''alle''' der ausgesuchten Aufgaben innerhalb des Sprints abgeschlossen werden müssen. Daher sollte man beim Aussuchen der Aufgaben bereits abschätzen, wie lange man für jede der Aufgaben brauchen wird und sich ggf. mehr oder weniger Aufgaben zuweisen, je nach dem, in wie weit das Arbeitspensum bereits ausgeschöpft ist.
Natürlich kann es vorkommen, dass man sich im Scrum-Meeting überschätzt und sich während der Bearbeitung der Aufgaben abzeichnet, dass man einen Teil der Aufgaben innerhalb des aktuellen Sprints nicht erledigen kann. In diesem Fall '''muss''' dies den anderen Gruppenmitgliedern und dem Tutor über die Gruppenliste rechtzeitig (sobald man merkt, dass die Zeit für eine Aufgabe nicht reicht) vor Ende des Sprints mitgeteilt werden. Versäumt man diese Mitteilung, zählt die jeweilige Aufgabe als nicht abgeschlossen und führt zu Punkteverlust bei den wöchentlich erreichbaren Punkten der Eigenleistung (siehe [[Formalien#Benotung|Benotung]]).
== High-Level Ablauf im Sopra ==
# 13 Wochen, organisiert nach Scrum
#* Wöchentliche Scrum-Meetings (Tutorentreffen)
#* Regelmäßige Präsentationen (Vorführung des Produkts beim Kunden)
#** Spielidee (Verkauf der Idee and die Kunden: warum macht das Spiel Spaß, Was ist das Alleinstellungsmerkmal, Wie kann man gewinnen/verlieren?)
#** Beta (Aktueller Zwischenstand, Vergleich mit anderen Gruppen)
#** Final (Endabnahme durch Kunden)
#* Dozenten sind Kunden, Tutoren sind "Sub-Kunden"
# Zusätzlich zum Kunden-Schema: Begleitende Vorlesungen, um Wissen zu vermitteln
#* GDD (Was ist das? Wie schreibt man das? Was gehört da rein?)
#* Architektur (Wie funktioniert UML, was muss man bei Spielearchitekturen beachten?)
#* Code Reviews (Verbesserung der eigenen Codequalität)
# 2 Phasen
#* Deisgn
#** Festigen der Spielidee, Mechaniken, etc.
#** Formalisieren und Aufschreiben
#** Finden von Widersprüchen im Design, Unlogischen Abläufen, etc.
#* Implementierung
#** Entwicklung des Spiels
#** Einhalten der getroffenen Designentscheidungen (auch im Bezug auf Architektur)
#** Einhalten von Clean-Code Prinzipien
Hier soll geklärt werden:
# Scrum Meeting / Daily Scrum ('''max. 15min''')
#*  Was wurde seit dem letzten Meeting gemacht?
#*  Was wird bis zum nächsten Meeting gemacht?
#*  Was für Probleme gibt es, die die aktuellen Aufgaben behindern?
# Sprint Review ('''max. 30min''')
#*  Product Owner sagt, was fertig und was nicht fertig ist.
#*  Team zeigt, was alles fertig geworden ist und beantwortet Fragen zum Fortschritt.
#*  Team erklärt dabei, was es für Probleme gab und wie diese gelöst worden sind.
#*  Product Owner erklärt den aktuellen Stand des Product Backlogs und speziell Änderungen an der Aufwandsabschätzung.
# Sprint Planning ('''max. 60min''')
#*  Was wird im nächsten Sprint gemacht? Product Backlog anschauen, von oben nach unten (PO sollte es geordnet haben). An die Recurring Tasks denken.
#*  Wer erledigt von den ausgewählten Dingen was (Arbeitsverteilung)?
# Sprint Retrospective ('''max. 15min''')
#*  Diskutieren, was im letzten Sprint im Hinblick auf Menschen, Beziehungen, Prozesse, Tools gut bzw. schlecht gelaufen ist.
#*  Wo muss etwas verändert oder verbessert werden, damit besser gearbeitet werden kann?
#*  Plan erstellen, wie diese Änderungen im nächsten Sprint umgesetzt werden können.
<!--
Zu Beginn eines [[Sprint|Sprints]] findet ein [[Scrum-Meeting]] statt. Hier wird das [[Product Backlog]] gereviewed, es werden die Ziele besprochen und das Team wählt [[Item|Items]] aus dem [[Product Backlog]] aus, die bis zum Ende des [[Sprint|Sprints]] abgeschlossen werden sollen. Hierbei wird die Priorität der [[Item|Items]] berücksichtigt.
Wichtig hier (und ein Kernkonzept in [[Scrum]]): '''Das Team entscheidet, wie viel es im nächsten Sprint erledigen wird.'''
Zuerst wird abgeschätzt, wie viel Zeit jedes Teammitglied für den aktuellen [[Sprint]] bereitstellen kann. Danach werden die in diesem Sprint zu erledigenden [[Item|Items]] ausgewählt (in der Regeln nach Priorität) und in individuelle Aufgaben (kleinere [[Item|Items]]) aufgesplittet, welche dann im [[Sprint Backlog]] festgehalten werden.
Wenn die Aufgaben identifiziert sind werden sie den Teammitgliedern, unter Berücksichtigung von Abhängigkeiten etc., zugeteilt. Jede Aufgabe erhält eine Abschätzung für die Umsetzungsdauer (in [[ETC]]) um sicher zu stellen, dass das Arbeitspensum gleichmäßig verteilt wird.
Am Ende des Meetings kommt man somit zu einer Liste von Aufgaben und jeweils einer Zuteilung an einen Verantwortlichen.
Die Aufgaben sollten mit Bedacht herausgearbeitet und verteilt werden, da sie in der Regel für den Rest des [[Sprint|Sprints]] festgehalten und nicht mehr geändert werden.
Sollte eine unvermeidbare Änderung im Plan nötig sein, so kann man den aktuellen [[Sprint]] stoppen und mit der Planung neu beginnen. Da das aber einen großen Störfaktor darstellt sollte dies nur in extremen Situationen in Betracht gezogen werden.
[[Scrum]] bringt auch diverse Herausforderungen mit sich: Zum Beispiel ist es zu Beginn schwierig, die Menge an Arbeit, die man in einem [[Sprint]] schaffen kann, einzuschätzen. So kann es passieren dass ihr es nicht schafft, alles was ihr euch für den ersten [[Sprint]] vorgenommen habt, fertig zu stellen. Der Rest des Teams kann das als Versagen werten, aber genau diese Erfahrung ist ein notwendiger Schritt um realistischere und durchdachtere Annahmen über seine Leistungen treffen zu können.


-->
{{BA|Dietsch|Hier könnte man noch andere Dinge erzählen. Z.B.
* Kommunizieren
* Auch für sich selbst den Sprint planen
* Abhängigkeiten berücksichtigen
* Gitea richtig benutzen
* Richtig abschätzen (vlt. auch Abschätzungsmethoden?) Abschätzungen korrigieren
* Wie geht Code Review? Vlt. Code Review Artikel.
* Alleine arbeiten: Auf Code-Qualität achten [[CleanCode]]
}}




[[Kategorie:Organisation]]
[[Kategorie:Organisation]]
[[Kategorie:Scrum]]
[[Kategorie:Scrum]]

Aktuelle Version vom 15. Oktober 2020, 11:29 Uhr

Das Softwarepraktikum verwendet Scrum als Vorgehensmodell für die Softwareentwicklung und ist daher in insgesamt 13 Sprints (1 Sprint pro Woche) unterteilt.

Wöchentliches Gruppentreffen mit Tutor

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.

Sprint Review (max. 30min)

Im Sprint Review werden die Ergebnisse des vergangenen Sprints demonstriert und besprochen und bestimmt, ob alle Ziele erreicht worden sind.

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 Wiederkehrende Aufgabe "Product Owner") oder jedes Teammitglied einzeln, welche Aufgaben aus dem letzten Sprint im Sinne der 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 Items 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?

Zum Schluss sollte noch geklärt werden, ob mit der aktuellen Arbeitsweise der nächste Milestone erreicht werden kann.

Die Ergebnisse aus dem Sprint Review können dann direkt im nächsten Teil des Gruppentreffens verwendet werden.

Sprint Retrospective (max. 15min)

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 sollte man feststellen, wo etwas verändert werden muss, damit die gemeinsamen Ziele besser erreicht werden können. Dabei sollte man einen schriftlichen Plan erstellen, wie man diese Änderungen im nächsten Sprint umsetzen kann. Im Speziellen sollte während der Sprint Retrospektive auch die DoD diskutiert und im Bedarfsfall angepasst werden.

Dieser Schritt finde vor dem nächsten Sprintplanning statt, da Änderungsvorschläge direkt im anschließenden Sprint umgesetzt werden sollen.

Sprint Planning (max. 60min)

In diesem Teil des Treffens werden die Ziele für den nächsten Sprint geplant.

Ablauf

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 Items, 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 Items sollte nun der Arbeitsaufwand (ETC) abgeschätzt werden. Danach werden die atomaren Items in das neue Sprint Backlog verschoben. Diesen Vorgang wiederholt man nun so lange, bis man die Zeit, die das Team für den nächsten Sprint zur Verfügung hat, aufgebraucht hat. Erst danach werden die einzelnen Items im Sprint Backlog unter den Teammitgliedern aufgeteilt. Am Ende diesen Teils kommt man somit zu einem neuen Sprint Backlog mit einer Liste von Items die jeweils einem Verantwortlichen zugeteilt sind.

Wiederkehrende Aufgaben

Während des Softwarepraktikums müssen bestimmte organisatorische Aufgaben in jedem Sprint ab Woche 2 erledigt werden. Diese Aufgaben können immer vom gleichen Teammitglied, oder abwechselnd ausgeführt 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:

  • Product Owner (ab Woche 2)
    • Pflegen und Anpassen von User Stories und Tasks im Product Backlog.
    • Verfeinern von User Stories zu Tasks.
    • User Stories mit Prioritäten versehen und Prioritäten aktualisieren.
    • Gruppentreffen vorbereiten (was ist fertig, wie war die Aufwandsabschätzung).
    • 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 release pushen (siehe Sprint Abschließen).
  • Qualitätssicherung (ab Woche 3)
    • Code auf Clean-Code Richtlinien prüfen.
    • Code Reviews vorbereiten und durchführen.
    • ReSharper-Konformität im ganzen Projekt überprüfen und ggf. herstellen.
  • Architektur (ab Woche 3)
    • Schnittstellen definieren.
    • Architekturbeschreibungen pflegen.
    • Einhaltung der Architektur im Projekt sicherstellen und beides ggf. anpassen.
    • Einen Überblick über die Gesamtarchitektur behalten und bei der Umsetzung verschiedener Tasks stets die Abhängigkeiten innerhalb der Architektur berücksichtigen.

Aufgabe schwieriger als gedacht

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 Sprints 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 Sprints mit Aufgaben zu beginnen, die andere für die Erledigung ihrer Aufgaben brauchen). Zum anderen muss man seine Teammitglieder und den Tutor über ein Kommentar im entsprechenden Ticket rechtzeitig informieren, dass eine Aufgabe nicht mehr innerhalb des aktuellen Sprints erledigt werden kann.

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

Hinweise zur Arbeitsorganisation

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 (Skype, IRC, Instant Messaging,...) 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:

  • Was wurde seit dem letzten Meeting gemacht?
  • Was wird bis zum nächsten Meeting gemacht?
  • Was für Probleme gibt es, die die aktuellen Aufgaben behindern?

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.

Abgerufen von „https://staging.sopranium.de/index.php?title=Ablauf&oldid=9445“