Montags-Meeting

Das Montags-Meeting dient der Absprache, Einteilung und ggf. Zuweisung von neu erstellten Git-Issues und der Planung der Woche. Alle zwei Wochen startet ein neuer Sprint der mithilfe eines Milestones abgebildet wird. Diese Milestones enden am Freitag vor einem Update, sodass die letzten bearbeiteten Themen zumindest über das Wocheende noch im Test-System sind. Dort enthaltene Issues sollen bestmöglich in diesem Zeitraum abgearbeitet werden.

Vorbereitung

Die Vorbereitung auf das Montags-Meeting sollte von jeder Person einzeln durchgeführt werden. Nur wenn jede Person sich damit beschäftigt, können wir die Dauer des Meetings reduzieren.

1. Überlegen, ob generelle Themen angesprochen werden müssen, die unabhängig vom Gitlab relevant sind.
2. Anschauen der selbst erstellten Issues in den letzten sieben Tagen. Es sollte darauffolgend eine kurze Erklärung möglich sein.
3. Überblick über das eigene Issue board verschaffen.
   • Die Issues sollten selbständig zwischen den Phasen: Open, Analysis, Development, Review, verschoben werden, sodass sich ein grober Überblick über die potenzielle Auslast verschafft werden kann.
   • Review: Welche Issues sind gemerged und können ins Testing übergehen oder geschlossen werden. Muss noch der Documentation Status gesetzt werden?
   • Development: Kurzen Überblick über den Entwicklungsstand verschaffen, Issues ggf. ins Review schieben und offene Fragen ansprechen.
     
   • Analysis: Werden noch weitere Informationen zu Issues benötigt, die bisher noch nicht geliefert wurden?

Vorgehensweise

1. Ansprechen von generellen Themen, die unabhängig vom Gitlab erwähnt werden sollten.
2. Wenn bereits ein Sprint gestartet wurde, kann direkt zu 3. gesprungen werden. Ansonsten muss eine Sprint-Review und Sprint-Retrospective durchgeführt werden. In der Sprint-Review schauen wir uns kurz an, welche Issues erledigt wurden. Bei der Sprint-Retroperspective wird geprüft, wie der letzte Sprint abgelaufen ist und welche Verbesserungen für zukünftige Sprints abgeleitet werden können. Außerdem werden offene Issues in den nächsten Sprint oder das Backlog verschoben.
3. Mit aktuellem Sprint (Iteration) über das Issue board schauen und besprechen (Raindancer Gruppe).
   • Filter auf Iteration=Current setzen. 
   • Review: Welche Issues sind gemerged und können ins Testing übergehen oder geschlossen werden. Muss noch der Documentation Status gesetzt werden?
   • Development: Kurzen Überblick über den Entwicklungsstand geben und offene Fragen ansprechen.
     
   • Analysis: Werden noch weitere Informationen zu Issues benötigt, die bisher noch nicht geliefert wurden?
   • Wurden während des Sprints Issues hinzugefügt, durch die die maximale Gewichtung des Sprints überschritten wurde, weshalb andere Issues wieder aussortiert werden müssen?
   • Wie hoch ist das aktuelle Gewicht des Sprints? Damit kann identifziert werden, ob neue Issues dem Sprint hinzugefügt werden können.
4. Betrachten aller neuen Issues, die in den letzten sieben Tagen in der Raindancer Gruppe erstellt wurden. Zur Zeit sind hier nur Issues aus dem Server-Projekt relevant.
   • Assignee=None, Milestone=None und Parent=None mit absteigender Sortierung nach Created Date.
   • Jedes Issue muss dabei ein label (Bug, Feature Request, Tech Issue oder Rework) und eine Priorisierung durch Sterne erhalten.
   • Jedes Issue muss gewichtet werden.
   • Nun muss das Issue einem Epic (Parent), Sprint (Iteration) oder Backlog-Milestone hinzugefügt werden.
     
   • Optional: Es können weitere labels wie z.B. Quick vergeben werden.
     
   • Wichtig: Ist es nicht möglich, das Issue aufgrund von fehlenden Personen zu erklären oder zu bewerten, so muss das Issue ein Due Date erhalten und wird im nächsten Daily oder Montags-Meeting besprochen.
5. Überprüfen von offenen Issues, die aufgrund von fehlenden Person ein Due Date erhalten haben (Derzeit nur Server-Projekt der Raindancer Gruppe).
   
   • Absteigende Sortierung nach Due Date.
   • Bearbeitung erfolgt analog zum vorherigen Schritt.
6. Anschauen der Issue boards innerhalb der Raindancer Gruppe.
   • Es müssen die Boards von allen relevanten Personen geöffnet werden. Person sind nicht relevant, wenn diese nicht anwesend sind oder einer externen Firma angehören.
   • Review: Welche Issues sind gemerged und können ins Testing übergehen oder geschlossen werden. Muss noch der Documentation Status gesetzt werden?
   • Development: Kurzen Überblick über den Entwicklungsstand geben und offene Fragen ansprechen.
     
   • Analysis: Werden noch weitere Informationen zu Issues benötigt, die bisher noch nicht geliefert wurden?
     
   • Open: Sortieren der Issues, sodass bei Bedarf neue Issues ohne Rückfragen genommen werden können.
     
7. Issues aus dem derzeitigen Backlog-Milestone in den aktuellen Sprint übertragen, sofern noch ausreichend Kapazität vorhanden ist. Das kann mit der Milestone-Overview gemacht werden, wobei der Milestone Backlog wechseln kann.