|
|
## Überblick
|
|
|
# Überblick
|
|
|
|
|
|
Das Diagramm gibt einen Überblick über Orte der Planung, Organisation und Aufbereitung von Anforderungen.
|
|
|
|
... | ... | @@ -6,15 +6,43 @@ Das Diagramm gibt einen Überblick über Orte der Planung, Organisation und Aufb |
|
|
|
|
|
Der Ablauf spiegelt einen ersten Draft wieder und wir nach entstehenden Befürfnissen ggf. am [Miro Board](https://miro.com/app/board/uXjVMYJ3HW4=/#tpicker-content) aktualisiert.
|
|
|
|
|
|
### Organisatorische Artefakte
|
|
|
## Organisatorische Artefakte
|
|
|
|
|
|
//TODO ...
|
|
|
|
|
|
## GitLab
|
|
|
# Planung und regelmäßige Meetings
|
|
|
|
|
|
Wir plannen unsere Entwicklung in Zyklen nach der [Shape Up](https://basecamp.com/shapeup/2.2-chapter-08) Methologie von 37 Signals.
|
|
|
|
|
|
Ein Entwicklungszyklus dauert **6 Wochen**. Nach/vor jedem Zyklus gibt es eine Cooldown und Warmup Phase von insgesamt **2 Wochen**.
|
|
|
|
|
|
Während dieser zwei Wochen werden zumindest folgende Meetings abgehalten:
|
|
|
- Retrospektive
|
|
|
- Roadmap Planung
|
|
|
- Zyklusplanung
|
|
|
|
|
|
## Retrospektive
|
|
|
|
|
|
Die frischen Learnings aus dem letzten Zyklus werden besprochen und auf einem Retrospektive Board festgehalten.
|
|
|
|
|
|
## 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 Hilfer eines eigenen Boards gemacht. Die Ergebnise werden im [Roadmap Dokument](https://gitlab.servus.at/aura/aura/-/wikis/Roadmap) für die weitere Orientierung dokumentiert.
|
|
|
|
|
|
## 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.
|
|
|
- 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.
|
|
|
|
|
|
# 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.
|
|
|
|
|
|
### Board
|
|
|
## Board
|
|
|
|
|
|
Das [Board](https://gitlab.servus.at/groups/aura/-/boards "Board") zeigt den Entwicklungsstand und wird immer aktuell gehalten.
|
|
|
|
... | ... | @@ -29,27 +57,16 @@ Am Board gibt es folgende Spalten: |
|
|
| Review | Tickets, die gerade durch peer review getestet / geprüft werden. |
|
|
|
| Closed | Geschlossene Tickets. |
|
|
|
|
|
|
### Zyklusplanung
|
|
|
|
|
|
Wir plannen unsere Entwicklung in Zyklen nach der [Shape Up](https://basecamp.com/shapeup/2.2-chapter-08) Methologie von 37 Signals.
|
|
|
|
|
|
- Ein Entwicklungszyklus dauert **6 Wochen**
|
|
|
- Nach/vor jedem Zyklus gibt es eine Cooldown/Warmup Phase von **2 Wochen**
|
|
|
- Im Planungstreffen werden Tasks eines Zyklus mit dem jeweiligen Label versehen (z.B. <span dir="">\~</span>"Cycle \[1/23\]")
|
|
|
- Spätestens im Planungstreffen werden **den Tickets Prioritäten zugewiesen**. Siehe Abschnitt Priorisierung unten.
|
|
|
- Wir achten darauf **nur soviele Tasks zu planen welche realistisch innerhalb des Zyklus abgeschlossen werden**. Wenn ein Task im darauf folgenden Zyklus weitergeführt wird, wird hier auch das neue Label ergänzt (z.B. <span dir="">\~</span>"Cycle \[2/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.
|
|
|
|
|
|
### Tickets
|
|
|
## Tickets
|
|
|
|
|
|
- Tickets sollten im Idealfall **keine Aufwände länger als 3 Tage** benötigen (1 Tag = 6h)
|
|
|
- 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.
|
|
|
- **Beim Erstellen des Tickets soll immer eine Person zugewiesen werden**. Am Besten jene Person, die für das jeweilige Repository verantwortlich ist. Wenn unklar ist wer für das Ticket am ehesten verantwortlich ist, bitte nachfragen. Dadurch bleiben Tickets leichter im Blickfelt und entsprechende Filter gehen nicht ins Leere.
|
|
|
- **Beim Erstellen des Tickets soll immer eine Person zugewiesen werden**. Am Besten jene Person, die für das jeweilige Repository verantwortlich ist. Wenn unklar ist wer für das Ticket am ehesten verantwortlich ist, bitte nachfragen. Dadurch bleiben Tickets leichter im Blickfeld und entsprechende Filter gehen nicht ins Leere. <mark>_Bei der Retrospektive im Februar 23 kam auf, dass Leute bei neuen Tickets angestupst werden sollen. Hier ist noch zu klären wie das gemeint ist._</mark>
|
|
|
- Im Idealfall kann nur durch das Review von Ticketlisten eine **Grobabschätzung der Gesamtaufwände** (z.B. für ein Release) gemacht werden.
|
|
|
|
|
|
### Priorisierung
|
|
|
## 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>
|
|
|
|
... | ... | @@ -61,7 +78,7 @@ Wir plannen unsere Entwicklung in Zyklen nach der [Shape Up](https://basecamp.co |
|
|
|
|
|
Bei oder nach Planungstreffen werden die Prioritäten gegebenenfalls aktualisiert.
|
|
|
|
|
|
#### Milestones
|
|
|
### Milestones
|
|
|
|
|
|
Neben der Prioritätslabels gibt es noch die Möglichkeit einen Milestone zuzuweisen. Tickets sollen nie ohne Milestone existieren, damit sie bei entsprechenden Filtern nicht verborgen bleiben.
|
|
|
|
... | ... | @@ -69,7 +86,7 @@ Wenn komplett unklar ist, wann oder ob ein Ticket überhaupt gemacht wird, dann |
|
|
|
|
|
Bei oder nach Planungstreffen werden die Milestones gegebenenfalls aktualisiert.
|
|
|
|
|
|
### Labels
|
|
|
## Labels
|
|
|
|
|
|
Neben den oben genannten Labels sind folgende in Verwendung
|
|
|
|
... | ... | |