|
|
## Board
|
|
|
|
|
|
Das [Board](https://gitlab.servus.at/groups/aura/-/boards "Board") zeigt den Entwicklungsstand und wird immer aktuell gehalten.
|
|
|
|
|
|
Am Board gibt es folgende Spalten:
|
|
|
|
|
|
| Spalte | Beschreibung |
|
|
|
|--------|--------------|
|
|
|
| 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 Aufmerksumkeit des Product Management gefragt. |
|
|
|
| In Progress | Tickets an denen aktuell gearbeitet wird. |
|
|
|
| Closed | Geschlossene Tickets. |
|
|
|
|
|
|
## Zyklus Planung
|
|
|
|
|
|
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. \~"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. \~"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 entsprecht einem Jahr. Das jeweils siebente, also älteste wird dann gelöscht.
|
|
|
|
|
|
## 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**
|
|
|
- Diese **Sub Tasks werden der übersichthalber in einem Epic zusammengefasst** und beschrieben. Neben der Verlinkung im Epic Text sollten alle Sub Tasks auch als "Linked Issues" verlinked werden.
|
|
|
- Epics zeichnen sich dadurch aus, dass der Titel des Tickets mit dem **Präfix `\[EPIC\]`** beginnt.
|
|
|
- **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.
|
|
|
- Im Idealfall kann nur durch das Review von Ticketlisten eine **Grobabschätzung der Gesamtaufwände** (z.B. für ein Release) gemacht werden.
|
|
|
|
|
|
## 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 |
|
|
|
| **P2** | Durchschnittliche Priorität |
|
|
|
| **P3** | Niedrige Priorität, kosmetisches |
|
|
|
|
|
|
Bei oder nach Planungstreffen werden die Prioritäten gegebenenfalls aktualisiert.
|
|
|
|
|
|
### 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.
|
|
|
|
|
|
Wenn komplett unklar ist, ob überhaupt und wann ein Ticket gemacht wird, dann wird ein Milestone in ferner Zukunft zugewiesen (z.B. _Version 2.0_).
|
|
|
|
|
|
Bei oder nach Planungstreffen werden die Milestones gegebenenfalls aktualisiert.
|
|
|
|
|
|
## Labels
|
|
|
|
|
|
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. |
|
|
|
| **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. |
|
|
|
|