Daily-Meeting

Das Daily-Meeting dient der täglichen Absprache von zu bearbeiteten Themen und der Klärung von offenen Fragen. Diese Diese Themen sind im aktuellen aktuellen Sprint abgebildet.

Vorbereitung

1. Überlegen, ob ob generelle generelle Themen  angesprochen werden müssen, die unabhängig vom vom Gitlab  relevant sind.
2. Anschauen der der selbst erstellten Bug-Issues vom Vortag. Es sollte darauffolgend eine eine kurze Erklärung möglich sein.
3. Überblick über das eigene eigene Issue  Board Board für den aktuellen Sprint verschaffen (Iteration=Current).
   
   • Die Issues sollten selbständig zwischen den Phasen:  Open,  Analysis,  Development,  Review,  verschoben werden, sodass sich ein grober Überblick über die die potenzielle Auslast Auslast verschafft werden kann.
   • Review: Welche Issues sind gemerged und können ins ins Testing  übergehen oder oder geschlossen geschlossen werden.  Muss noch der der Documentation Status  gesetzt werden?
   • Development:  Kurzen Überblick über den den Entwicklungsstand 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?
   • Gibt es Issues, die neu dazugekommen sind und innerhalb des des Sprints priorisiert werden müssen?

Vorgehensweise

1. Ansprechen von von generellen Themen, die unabhängig vom vom Gitlab erwähnt werden sollten.
2. Mit aktuellem aktuellem Sprint  über das das Issue board board schauen und besprechen (Raindancer Raindancer Gruppe).
   • Filter auf auf Iteration=Current setzen.  
   • Review:  Welche Issues sind gemerged und können ins ins Testing  übergehen oder oder geschlossen geschlossen werden. Muss noch der der Documentation Status  gesetzt werden?
   • Development:  Kurzen Überblick über den 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 des Sprints  Issues hinzugefügt, durch die die maximale maximale Gewichtung des  des Sprints  überschritten wurde, weshalb andere andere Issues  wieder aussortiert werden müssen?
   • Wie Wie hoch  ist das aktuelle aktuelle Gewicht des  des Sprints? Damit kann identifziert werden, ob ob neue Issues  dem Sprint hinzugefügt werden können.
3. Betrachten aller aller neuen Bug-Issues, die am Vortag in der in der Raindancer  Gruppe erstellt wurden. Zur Zeit sind hier nur Issues aus dem dem Server-Projekt  relevant.
   • Assignee=None,  Milestone=None und  und Parent=None None mit absteigender Sortierung nach nach Created Date.
   • Es muss das das Bug-Label  und eine Priorisierung Priorisierung durch Sterne vergeben werden.
   • Das Issue muss muss anhand der der Fibonacci-Reihe Reihe gewichtet  werden. Wird die die 21 21 vergeben, muss das Issue auf jeden Fall in in kleinere Issues  und z.B. einen einen Epic Epic unterteilt werden. Bei der der 13 13 sollte in Erwägung gezogen werden, das Issue zu unterteilen, da dieses dieses Gewicht Gewicht auch auch nicht nicht innerhalb eines eines Sprints  abgearbeitet werden kann. Kann kein Gewicht festgelegt werden, muss das Label Label RFE  (Request for estimate) gesetzt werden, sodass das Gewicht nachträglich hinzugefügt und das Issue ggf. neu zugeteilt werden kann.
     
   • Bugs sollen in der Regel sofort einem Sprint  zugewiesen werden. Ist die Auswirkung so gering, können sie auch einem einem Backlog-Milestone zugewiesen werden, jedoch besteht hier die Gefahr, dass sie erst spät wieder zugeteilt werden.
     
   • Optional: Es können weitere weitere labels  wie z.B.  Quick Quick vergeben werden.
     
   • Wichtig:  Ist es es nicht  möglich, das Issue aufgrund von fehlenden Personen zu zu erklären ren oder zu zu bewerten, so so muss  das Issue ein ein Due Date erhalten und wird im nächsten Daily oder oder Montags-Meeting  besprochen.