|
|
## Board
|
|
|
## Überblick
|
|
|
|
|
|
Das Diagramm gibt einen Überblick über Ort der Planung und Organisation.
|
|
|
|
|
|
![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.
|
|
|
|
|
|
## GitLab
|
|
|
|
|
|
### Board
|
|
|
|
|
|
Das [Board](https://gitlab.servus.at/groups/aura/-/boards "Board") zeigt den Entwicklungsstand und wird immer aktuell gehalten.
|
|
|
|
... | ... | @@ -13,7 +23,7 @@ Am Board gibt es folgende Spalten: |
|
|
| Review | Tickets, die gerade durch peer review getestet / geprüft werden. |
|
|
|
| Closed | Geschlossene Tickets. |
|
|
|
|
|
|
## Zyklusplanung
|
|
|
### Zyklusplanung
|
|
|
|
|
|
Wir plannen unsere Entwicklung in Zyklen nach der [Shape Up](https://basecamp.com/shapeup/2.2-chapter-08) Methologie von 37 Signals.
|
|
|
|
... | ... | @@ -24,7 +34,7 @@ Wir plannen unsere Entwicklung in Zyklen nach der [Shape Up](https://basecamp.co |
|
|
- 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.
|
|
|
|
|
|
## 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**
|
... | ... | @@ -33,7 +43,7 @@ Wir plannen unsere Entwicklung in Zyklen nach der [Shape Up](https://basecamp.co |
|
|
- **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
|
|
|
### 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>
|
|
|
|
... | ... | @@ -45,7 +55,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.
|
|
|
|
... | ... | @@ -53,7 +63,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
|
|
|
|
... | ... | @@ -64,5 +74,5 @@ Neben den oben genannten Labels sind folgende in Verwendung |
|
|
| **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 Radiomacher:innen stammen |
|
|
|
| **STORY** | User Stories die aus Requirements von Radios stammen (ProKo, RM, IT) |
|
|
|
|