Direkt zum Hauptinhalt

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-Milestone über das Issue board schauen und besprechen (Raindancer Gruppe).
    • Issue board mit Milestone=[Release-Datum], also z.B. Milestone=2026-01-20. 
    • 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.
    • Das Issue muss anhand der Fibonacci-Reihe gewichtet werden. Wird die 21 vergeben, muss das Issue auf jeden Fall in kleinere Issues und z.B. einen Epic unterteilt werden. Bei der 13 sollte in Erwägung gezogen werden, das Issue zu unterteilen, da dieses Gewicht auch nicht innerhalb eines Sprints abgearbeitet werden kann. Kann kein Gewicht festgelegt werden, muss das Label RFE (Request for estimate) gesetzt werden, sodass das Gewicht nachträglich hinzugefügt und das Issue ggf. neu zugeteilt werden kann.
    • Nun muss das Issue einem Epic (Parent), Sprint-Milestone 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).
    • Assignee=None, Milestone=None und Parent=None mit absteigender 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.

nach oben