|
|
### Organisatorische Artefakte
|
|
|
|
|
|
![image](uploads/c19636520607a6ec07f3dbdaac02dc9f/image.png) [<small>Quelle</small>](https://www.atlassian.com/de/agile/project-management/epics-stories-themes)
|
|
|
![image](uploads/c19636520607a6ec07f3dbdaac02dc9f/image.png){width=33%} [<small>Quelle</small>](https://www.atlassian.com/de/agile/project-management/epics-stories-themes)
|
|
|
|
|
|
### Theme
|
|
|
|
|
|
Ein **Theme** oder Initiative ist das größte Strukturelement. Vergleiche Themes im [agilen Produktmanagement](https://www.atlassian.com/de/agile/project-management/epics-stories-themes).
|
|
|
|
|
|
Themes werden je nach Bedarf in **AEPs (Aura Enhancement Proposals)** definiert und spezifiziert. Diese Dokumente können sowohl als Schnittstelle zu Stakeholdern (überblicksmäßige, nicht-technische Abschnitte), Mockups und Designsketches, als auch Architekturdokument für komplexe, bereichsübergreifende Abläufe dienen (inklusive Technische Details). Mehr zur Struktur von AEPs findest du im [AEP Template](https://gitlab.servus.at/aura/aura/-/wikis/AEP-Template)
|
|
|
~~Themes werden je nach Bedarf in **AEPs (Aura Enhancement Proposals)** definiert und spezifiziert. Diese Dokumente können sowohl als Schnittstelle zu Stakeholdern (überblicksmäßige, nicht-technische Abschnitte), Mockups und Designsketches, als auch Architekturdokument für komplexe, bereichsübergreifende Abläufe dienen (inklusive Technische Details). Mehr zur Struktur von AEPs findest du im [AEP Template](https://gitlab.servus.at/aura/aura/-/wikis/AEP-Template)~~
|
|
|
|
|
|
Ein Theme besteht aus einem oder mehreren Epics.
|
|
|
~~Ein Theme besteht aus einem oder mehreren Epics.~~
|
|
|
|
|
|
**Update**: Um die komplexität der Organisation to vereinfachen, werden bestehende Themes/AEPs nach und nach in Epics umgewandelt. Je nach Notwendigkeit werden nun Parent-Child Epics erstellt.
|
|
|
|
|
|
### Epic
|
|
|
|
|
|
Ein Epic Ist eine thematisches Bündel mehrerer Stories oder auch Tasks. Ein oder mehrere Epics können auch ein Theme bilden. Epics werden im GitLab Repository `aura` abgelegt.
|
|
|
Ein Epic Ist eine thematisches Bündel mehrerer Stories oder auch Tasks. Ein oder mehrere Epics können auch ein Theme bilden. Epics werden meist im GitLab Repository `aura` abgelegt. Ausnahme sind Epics die nur ein Repository betreffen.
|
|
|
|
|
|
Wenn die Umsetzung eines Tasks mehr drei Tage dauert erstellen wir einen Epic mit den Untertasks entweder als Inline Tasks mit Checkboxen oder als eigenes Ticketst die referenziert werden.\
|
|
|
**Wenn die Umsetzung eines Tasks mehr drei Tage dauert erstellen wir einen Epic** mit den Untertasks entweder als Inline Tasks mit Checkboxen oder als eigenes Ticketst die referenziert werden.\
|
|
|
\
|
|
|
Wenn sich eine Aufgabe über mehrere Repositories erstreckt (und somit mehrere Personen betrifft), dann wird ebenfalls ein Epic erstellt und die Sub Tasks den entsprechenden Personen zugewiesen. Der Epic selbst wird niemand zugewiesen, aber Board aber trotzdem "in progress" gesetzt.
|
|
|
|
... | ... | @@ -46,27 +48,40 @@ Ein Entwicklungszyklus dauert **6 Wochen**. Nach/vor jedem Zyklus gibt es eine C |
|
|
|
|
|
Während dieser zwei Wochen werden zumindest folgende Meetings abgehalten:
|
|
|
|
|
|
- Retrospektive
|
|
|
- Roadmap Planung
|
|
|
- Zyklusplanung
|
|
|
- Retrospektive: In der Cooldown oder Warm-up Phase
|
|
|
- Roadmap Planung: In der Cooldown oder Warm-up Phase
|
|
|
- Zyklusplanung: In der Cooldown oder Warm-up Phase
|
|
|
- Mid-Zyklus Meeting: Abgleich zum Entwicklungsstand etwa nach 3 Wochen
|
|
|
|
|
|
### Retrospektive
|
|
|
|
|
|
Die frischen Learnings aus dem letzten Zyklus werden besprochen und auf einem Retrospektive Board festgehalten.
|
|
|
Die frischen Learnings aus dem letzten Zyklus werden besprochen und auf einem Retrospektive Board festgehalten. Wir wollen darauf achten nicht zu viele Themen zu besprechen um am Ende nichts zu lösen. Wir wählen uns zumindest ein Thema was schwerwiegend ist oder viele im Team betrifft und entwickeln entsprechende Lösungen.
|
|
|
|
|
|
### Release & Roadmap Planung
|
|
|
|
|
|
Bevor die Konkrete Zyklusplanung durchgeführt wird, machen wir eine Metaplanung der Roadmap. Hier sehen wir uns zumindest die bevorstehenden Releases an. Wenn genug Zeit ist, kann es auch einen weiteren Ausblick geben.
|
|
|
|
|
|
Die Roadmap Planung wird mit Hilfe eines eigenen Boards gemacht. Die Ergebnise werden im [Roadmap Dokument](https://gitlab.servus.at/aura/aura/-/wikis/Roadmap) für die weitere Orientierung dokumentiert.
|
|
|
Die Roadmap Planung wird mit Hilfe eines eigenen Boards gemacht. Die Ergebnise werden im [Roadmap Dokument](https://gitlab.servus.at/aura/aura/-/wikis/Roadmap) für die weitere Orientierung dokumentiert. Der jeweilige, geplante Letztstand steht under https://roadmap.aura.radio zur Verfügung.
|
|
|
|
|
|
### Zyklusplanung
|
|
|
|
|
|
- Im Planungstreffen werden Tasks eines Zyklus mit dem jeweiligen Label versehen (z.B. `Cycle [1/23]`) und in die `TODO` Spalte des Boards gezogen.
|
|
|
- Spätestens im Planungstreffen werden **den Tickets Prioritäten zugewiesen**.
|
|
|
- Wir achten darauf **nur soviele Tasks zu planen welche realistisch innerhalb des Zyklus abgeschlossen werden**. Hier wollen wir lieber genügend Buffer für unerwartete Arbeiten wie Bugfixes einplanen. Wenn ein Task im darauf folgenden Zyklus weitergeführt wird, wird hier auch das neue Label ergänzt (z.B. `Cycle [1/23]`). In diesem Fall bitte das Label des vorherigen Zyklus nicht entfernen, damit nachvollziehbar ist, wie oft ein Task schon von Zyklus zu Zyklus verschoben wurde.
|
|
|
- Im Planungstreffen werden Tasks eines Zyklus mit dem jeweiligen Label versehen (z.B. `Cycle [1/23]`) und in die `TODO` Spalte des Boards gezogen.
|
|
|
- Wenn ein Task im darauf folgenden Zyklus weitergeführt wird, wird hier auch das neue Label ergänzt (z.B. `Cycle [1/23]`). In diesem Fall bitte das Label des vorherigen Zyklus nicht entfernen, damit nachvollziehbar ist, wie oft ein Task schon von Zyklus zu Zyklus verschoben wurde.
|
|
|
- Damit nicht zu viele Labels entstehen **behalten wir nur die jeweils 6 aktuellsten Zyklus Labels**. Das entspricht einem Jahr. Das jeweils siebente, also älteste wird dann gelöscht.
|
|
|
|
|
|
#### Priorisierung beim Abarbeiten der Tasks
|
|
|
|
|
|
- Spätestens im Planungstreffen werden den Tickets Prioritäten zugewiesen (P1-P3). Tickets mit hoher Priorität P1 werden zuerst gemacht.
|
|
|
- Tickets die Abhängigkeiten zu anderen Projektbereichen/Tickets haben werden zuerst gemacht. Abhängigkeiten werden zwischen den Devs kommuniziert. Beim Planungstreffen wird auch nochmal darauf hingewiesen. Manche Tickets weisen nochmal über den "Dependencies" Abschnitt darauf hin, auf was gewartet werden muss.
|
|
|
|
|
|
#### Estimates und Zeitmanagement
|
|
|
|
|
|
- Jede Person im Team gibt an, wieviel Zeitbudget sie im kommenden Zyklus zur Verfügung hat. Zum Beispiel 15h/Woche x 6 = 90h. Handelt es sich um einen Release Zyklus, dann sind nur 5 Wochen Entwicklungszeit zur Verfügung. Unbedingt auch Urlaubszeit und andere Abwesenheiten selbstbestimmt einplanen!
|
|
|
- Alle Devs sehen sich für sich die Tasks an, die an sie assigned sind und geben ein entsprechendes "Estimate" beim Ticket an. Hier kann eine Faustregel sein den persönliche Abschätzung gleich mit genügend Buffer einzutragen (z.B. Faktor 2).
|
|
|
- Danach Runde im Team ob sich der Workload für alle ausgeht; oder ob noch wo was zu viel oder zu wenig geplant ist. Wenn es zu viel ist, entscheiden wir gemeinsam, was eventuell verschoben oder dazu genommen werden kann.
|
|
|
|
|
|
Wir achten darauf **nur soviele Tasks zu planen welche realistisch und gut getestet innerhalb des Zyklus abgeschlossen werden können**. Hier wollen wir lieber genügend Buffer für unerwartete Arbeiten wie Bugfixes einplanen. Lieber zu wenig als zu viel planen! :-)
|
|
|
|
|
|
## GitLab
|
|
|
|
|
|
Gitlab mit seiner [Issue Liste](https://gitlab.servus.at/groups/aura/-/issues), [Board](https://gitlab.servus.at/groups/aura/-/boards) und [Wiki](https://pm.aura.radio) ist die sogenannte _Single Source of Truth_ für Planungsangelegenheiten.
|
... | ... | @@ -81,13 +96,14 @@ Am Board gibt es folgende Spalten: |
|
|
|--------|--------------|
|
|
|
| Open | Der Product Backlog. Hier wird alles gelistet, was vielleicht auch nur eine Idee ist oder irgendwann mal gemacht wird. |
|
|
|
| To Do | Tickets die für den kommenden Zyklus. Klärung offen: Sobald es für alpha2 eine Planung gibt, werden wir hier wahrscheinlich Tickets für den jeweiligen Milestone listen. |
|
|
|
| Pending | Das Ticket ist "on hold". Das bedeutet die zugewiesene Person wartet auf externen Input um die Arbeiten fortführen zu können. Hier ist mit Wahrscheinlichkeit die Aufmerksamkeit des Product Management gefragt. |
|
|
|
| Doing | Tickets an denen aktuell gearbeitet wird. |
|
|
|
| Blocked | Das Ticket ist "on hold". Das bedeutet die zugewiesene Person wartet auf externen Input um die Arbeiten fortführen zu können. Hier ist mit Wahrscheinlichkeit die Aufmerksamkeit des Product Management gefragt. Wenn ein Ticket blockiert ist, informiere auch die Personen auf die gewartet wird. Blockaden gilt es so schnell wie möglich aufzulösen. |
|
|
|
| Read-for-testing | Der letzte Schritt bevor das Ticket geschlossen wird, signalisiert dass es getestet werden kann. Schreib ein Ticket Kommentar über mögliche Testinstruktionen und tagge die testende Person. Assigne das Ticket **nicht** der Testperson. Wenn der Test erfolgreich ist, wird das Ticket durch die Testperson geschlossen, andernfalls wieder in die TODO Spalte gezogen. |
|
|
|
| Closed | Geschlossene Tickets. |
|
|
|
|
|
|
### Tickets
|
|
|
|
|
|
- Tickets sollten im Idealfall **keine Aufwände länger als 3 Tage** benötigen (1 Tag = 6h)
|
|
|
- Tickets sollten im Idealfall **<mark>keine Aufwände länger als 3 Tage</mark>** benötigen (1 Tag = 6h). Vergleiche Epics weiter oben.
|
|
|
- Ist ein Ticket aufwändiger, so empfiehlt es sich dieses **in mehrere kleinere Tasks runterzubrechen**. Entweder als mehrere Tickets oder Checklisten innerhalb der Ticketbeschreibung.
|
|
|
- Stories zeichnen sich dadurch aus, dass der **Titel des Tickets mit dem Präfix `[STORY]` beginnt**. **Zusätzlich muss noch das Label `STORY` zugewiesen werden**, damit diese Tickets auch in entsprechenden Filtern aufscheinen.
|
|
|
- Epics zeichnen sich dadurch aus, dass der **Titel des Tickets mit dem Präfix `[EPIC]` beginnt**. **Zusätzlich muss noch das Label `EPIC` zugewiesen werden**, damit diese Tickets auch in entsprechenden Filtern aufscheinen.
|
... | ... | @@ -96,8 +112,6 @@ Am Board gibt es folgende Spalten: |
|
|
|
|
|
### Priorisierung
|
|
|
|
|
|
<mark>_(hier gibt es noch Klärungsbedarf, wann und wie priorisiert wird. Tickets sollen aber spätestens zum Zeitpunkt der Zyklus Planung ein Priority label haben)._</mark>
|
|
|
|
|
|
| Label | Beschreibung |
|
|
|
|-------|--------------|
|
|
|
| **P1** | Höchste Priorität, bei Bugs ist es ein Blocker |
|
... | ... | @@ -112,7 +126,7 @@ Neben der Prioritätslabels gibt es noch die Möglichkeit einen Milestone zuzuwe |
|
|
|
|
|
Wenn komplett unklar ist, wann oder ob ein Ticket überhaupt gemacht wird, dann wird ein Milestone in ferner Zukunft zugewiesen (z.B. _Version 2.0_).
|
|
|
|
|
|
Bei oder nach Planungstreffen werden die Milestones gegebenenfalls aktualisiert.
|
|
|
Milestone Zuordnungen werden durch Maggie und David anhand der Roadmap vorgeplant. David achtet dabei darauf, dass Roadmap und Gitlab Issues abgeglichen bleiben. Bei oder nach Planungstreffen werden die Milestones gegebenenfalls mit Personen aus dem Team aktualisiert.
|
|
|
|
|
|
### Labels
|
|
|
|
... | ... | @@ -120,10 +134,25 @@ Neben den oben genannten Labels sind folgende in Verwendung |
|
|
|
|
|
| Label | Beschreibung |
|
|
|
|-------|--------------|
|
|
|
| **discuss** | Hier gibt es noch Dinge zu besprechen. Wird auich gern in Kombination mit der Board Spalte **_Pending_** verwendet. |
|
|
|
| **discuss** | Hier gibt es noch Dinge zu besprechen. Wird auch gern in Kombination mit der Board Spalte **_Blocked_** verwendet. |
|
|
|
| **bug** | Mit diesem Label werden Fehlfunktionen ausgezeichnet |
|
|
|
| **Radio Name** | Wenn ein Radio in einem Gespräch oder Workshop spezifische Anforderungen geäußert hat, dann wird dafür ein Ticket erstellt und das Label des jeweiligen Radios zugewiesen. |
|
|
|
| **P1, P2, P3** | Priorität des Tickets. Siehe Kapitel _Priorisierung_ oben. |
|
|
|
| **STORY** | User Stories die aus Requirements von Radios stammen (ProKo, RM, IT). Neben dem Label `STORY`, startet der Titel des Tickets mit `[STORY]`. Dadurch wird die Abgrenzung zu normalen Tasks sichtbar gemacht. |
|
|
|
| **EPIC** | Damit werden Epics gekennzeichnet. Neben dem Label `EPIC`, startet der Titel des Tickets mit `[EPIC]`. Dadurch wird die Abgrenzung zu normalen Tasks sichtbar gemacht. |
|
|
|
| **AEP--** | Damit werden Themes gekennzeichnet. "--" ist eine Platzhalter für die Nummer des Dokuments im Wiki. Neben dem Label `AEP--`, startet der Titel des Tickets mit `[AEP--]`. Dadurch wird die Abgrenzung zu normalen Tasks sichtbar gemacht. | |
|
|
| **EPIC** | Damit werden Epics gekennzeichnet. Neben dem Label `EPIC`, startet der Titel des Tickets mit `[EPIC]`. Dadurch wird der Aufwand und die Abgrenzung zu normalen Tasks klar sichtbar gemacht. |
|
|
|
| **AEP--** | Damit werden Themes gekennzeichnet. "--" ist eine Platzhalter für die Nummer des Dokuments im Wiki. Neben dem Label `AEP--`, startet der Titel des Tickets mit `[AEP--]`. Dadurch wird die Abgrenzung zu normalen Tasks sichtbar gemacht. Siehe oben, AEPs sind als Konzept deprecated. |
|
|
|
|
|
|
|
|
|
## Andere Rituale
|
|
|
|
|
|
### Wöchentliche my2ct Reports
|
|
|
|
|
|
Alle Team-Mitglieder posten einmal wöchentlich einen Mini `my2ct` Status im entsprechenden Matrix Kanal. Dies ermöglicht dem restlichen Team einen Einblick, was dich gerade bewegt, woran du gerade arbeitest oder ob du wo blockiert bist. Gerne können jegliche Dinge von Interesse geteilt werden um in unserem Remote Team ein wenig by the water-cooler / Kaffeplauschaustausch zu ermöglichen. Wenn du kommende Woche auf Urlaub bist, dann teil das bitte auch hier.
|
|
|
|
|
|
> ⬅️ was ist bei mir letzte woche passiert.
|
|
|
|
|
|
> ➡️ was plane ich nächste woche.
|
|
|
|
|
|
> 🍕 was beschäftigt mich gerade besonders, wo komme ich nicht weiter, was interessiert mich gerade oder möcht ich einfach teilen.
|
|
|
|
|
|
<mark>Die my2ct werden immer Freitags geteilt</mark>. Wenn das kein AURA Arbeitstag ist, dann am entsprechenden Arbeitstag davor. |
|
|
\ No newline at end of file |