|
|
## Überblick
|
|
|
|
|
|
Das Diagramm gibt einen Überblick über Ort der Planung und Organisation.
|
|
|
Das Diagramm gibt einen Überblick über Orte der Planung, Organisation und Aufbereitung von Anforderungen.
|
|
|
|
|
|
![image](uploads/9219f4754d11b27d03d7d9cdde8f3068/image.png)
|
|
|
|
|
|
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
|
|
|
|
|
|
//TODO ...
|
|
|
|
|
|
## 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
|
|
|
|
|
|
Das [Board](https://gitlab.servus.at/groups/aura/-/boards "Board") zeigt den Entwicklungsstand und wird immer aktuell gehalten.
|
... | ... | @@ -32,14 +38,14 @@ Wir plannen unsere Entwicklung in Zyklen nach der [Shape Up](https://basecamp.co |
|
|
- 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 entsprecht einem Jahr. Das jeweils siebente, also älteste wird dann gelöscht.
|
|
|
- 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 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**. **Zusätzlich muss noch das Label EPIC zugewiesen werden**, damit diese Tickets auch in entsprechenden Filtern aufscheinen.
|
|
|
- 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.
|
|
|
- Im Idealfall kann nur durch das Review von Ticketlisten eine **Grobabschätzung der Gesamtaufwände** (z.B. für ein Release) gemacht werden.
|
|
|
|
... | ... | @@ -72,7 +78,7 @@ Neben den oben genannten Labels sind folgende in Verwendung |
|
|
| **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. |
|
|
|
| **EPIC** | Tasks die länger als 3 Tage Aufwand benötigen. Neben dem Label EPIC, startet der Titel des Tickets mit \[EPIC\]. Dadurch wird die Sichtbarkeit von großen Tasks erhöht. Siehe auch Kapitel _Tickets_ oben. |
|
|
|
| **P1, P2, P3** | Priorität des Tickets. Siehe Kapitel _Priorisierung_ oben. |
|
|
|
| **STORY** | User Stories die aus Requirements von Radios stammen (ProKo, RM, IT) |
|
|
|
|
|
|
| **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. | |