... | ... | @@ -18,9 +18,9 @@ Wir plannen unsere Entwicklung in Zyklen nach der [Shape Up](https://basecamp.co |
|
|
|
|
|
- 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\]")
|
|
|
- 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. \~"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.
|
|
|
- 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
|
... | ... | @@ -28,7 +28,7 @@ Wir plannen unsere Entwicklung in Zyklen nach der [Shape Up](https://basecamp.co |
|
|
- 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.
|
|
|
- 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.
|
|
|
|
... | ... | @@ -40,7 +40,7 @@ Wir plannen unsere Entwicklung in Zyklen nach der [Shape Up](https://basecamp.co |
|
|
|-------|--------------|
|
|
|
| **P1** | Höchste Priorität, bei Bugs ist es ein Blocker |
|
|
|
| **P2** | Durchschnittliche Priorität |
|
|
|
| **P3** | Niedrige Priorität, kosmetisches |
|
|
|
| **P3** | Niedrige Priorität, Kosmetisches oder kann warten |
|
|
|
|
|
|
Bei oder nach Planungstreffen werden die Prioritäten gegebenenfalls aktualisiert.
|
|
|
|
... | ... | @@ -48,7 +48,7 @@ Bei oder nach Planungstreffen werden die Prioritäten gegebenenfalls aktualisier |
|
|
|
|
|
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_).
|
|
|
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.
|
|
|
|
... | ... | @@ -61,4 +61,6 @@ 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. |
|
|
|
|