|
|
### Organisatorische Artefakte
|
|
|
|
|
|
![image](uploads/c19636520607a6ec07f3dbdaac02dc9f/image.png)
|
|
|
<small>[Quelle](https://www.atlassian.com/de/agile/project-management/epics-stories-themes)</small>
|
|
|
![image](uploads/c19636520607a6ec07f3dbdaac02dc9f/image.png) [<small>Quelle</small>](https://www.atlassian.com/de/agile/project-management/epics-stories-themes)
|
|
|
|
|
|
### Theme
|
|
|
|
|
|
Ein **Theme** oder Initiative ist das größte Strukturelement. Vergleiche Themes im [agilen Produktmanagement](https://www.atlassian.com/de/agile/project-management/epics-stories-themes).
|
|
|
|
|
|
Themes werden je nach Bedarf in **AEPs (Aura Enhancement Proposals)** definiert und spezifiziert. Diese Dokumente können sowohl als Schnittstelle zu Stakeholdern (überblicksmäßige, nicht-technische Abschnitte), Mockups und Designsketches, als auch Architekturdokument für komplexe, bereichsübergreifende Abläufe dienen (inklusive Technische Details). <mark>TODO David: Mehr zur Struktur von AEPs findest du im [AEP Template](%link%)</mark>
|
|
|
Themes werden je nach Bedarf in **AEPs (Aura Enhancement Proposals)** definiert und spezifiziert. Diese Dokumente können sowohl als Schnittstelle zu Stakeholdern (überblicksmäßige, nicht-technische Abschnitte), Mockups und Designsketches, als auch Architekturdokument für komplexe, bereichsübergreifende Abläufe dienen (inklusive Technische Details). Mehr zur Struktur von AEPs findest du im [AEP Template](https://gitlab.servus.at/aura/aura/-/wikis/AEP-Template)
|
|
|
|
|
|
Ein Theme besteht aus einem oder mehreren Epics.
|
|
|
|
|
|
### Epic
|
|
|
|
|
|
Ein Epic Ist eine thematisches Bündel mehrerer Stories. Ein oder mehrere Epics können auch ein Theme bilden. Epics werden im GitLab Repository `aura` abgelegt.
|
|
|
Ein Epic Ist eine thematisches Bündel mehrerer Stories oder auch Tasks. Ein oder mehrere Epics können auch ein Theme bilden. Epics werden im GitLab Repository `aura` abgelegt.
|
|
|
|
|
|
<mark>TODO David: 1. Schauen welche (legacy) Epics als Story formuliert werden sollen 2. Ansehen, welche Epics noch übrig sind und wie es weiterhin sinnvoll ist diese Abstrkationsebene von Epics zu behalten.</mark>
|
|
|
Wenn die Umsetzung eines Tasks mehr drei Tage dauert erstellen wir einen Epic mit den Untertasks entweder als Inline Tasks mit Checkboxen oder als eigenes Ticketst die referenziert werden.\
|
|
|
\
|
|
|
Wenn sich eine Aufgabe über mehrere Repositories erstreckt (und somit mehrere Personen betrifft), dann wird ebenfalls ein Epic erstellt und die Sub Tasks den entsprechenden Personen zugewiesen. Der Epic selbst wird niemand zugewiesen, aber Board aber trotzdem "in progress" gesetzt.
|
|
|
|
|
|
Siehe auch die Verwendung von Labels für Epics weiter unten.
|
|
|
|
|
|
### Story
|
|
|
|
|
|
Stories werden in folgendem Format formuliert:
|
|
|
|
|
|
> "Als (Rolle) möchte ich (Funktionalität), um (Nutzen) zu erreichen"
|
|
|
|
|
|
Es wird auf eine gewisse [Mindestgröße und Nutzen von Stories](https://www.allankelly.net/archives/646/what-is-right-size-for-user-story/#:~:text=Short%20answer%3A%20there%20isn't,both%20are%20the%20right%20answer.) geachtet:
|
|
|
```plaintext
|
|
|
> "Als (Rolle) möchte ich (Funktionalität), um (Nutzen) zu erreichen"
|
|
|
```
|
|
|
|
|
|
Es wird auf eine gewisse [Mindestgröße und Nutzen von Stories](https://www.allankelly.net/archives/646/what-is-right-size-for-user-story/#:\~:text=Short%20answer%3A%20there%20isn't,both%20are%20the%20right%20answer.) geachtet:
|
|
|
|
|
|
> It should be big enough to represent business value in its own right – it might build on something that has been done before (e.g. a lower fidelity version of the same story, the new one increasing fidelity)
|
|
|
> It is big enough to be deliverable in its own right – you might not want to do so but if you needed to you could
|
|
|
> It should be big enough to represent business value in its own right – it might build on something that has been done before (e.g. a lower fidelity version of the same story, the new one increasing fidelity) It is big enough to be deliverable in its own right – you might not want to do so but if you needed to you could
|
|
|
|
|
|
Wenn eine Story für sich zu groß wird, kann sie auf Sub-Stories verweisen. Oder umgekehrt betrachtet können mehrere Stories in Epics zusammengefasst werden. Stories werden im GitLab Repository `aura` abgelegt.
|
|
|
|
|
|
### Task
|
|
|
|
|
|
Tasks dienen Entwickler*innen als Basis für die Implementierung. Vor oder während des Zyklusplanungstreffens werden die Stories des Scope in Sub Tasks runtergebrochen. Diese Tasks werden in den entsprechenden Repositories abgelegt und zur Story verlinkt & im Story Beschreibungstext eingetragen.
|
|
|
Tasks dienen Entwickler\*innen als Basis für die Implementierung. Vor oder während des Zyklusplanungstreffens werden die Stories des Scope in Sub Tasks runtergebrochen. Diese Tasks werden in den entsprechenden Repositories abgelegt und zur Story verlinkt & im Story Beschreibungstext eingetragen.
|
|
|
|
|
|
## Planung und regelmäßige Meetings
|
|
|
|
... | ... | @@ -41,6 +45,7 @@ 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 und Warmup Phase von insgesamt **2 Wochen**.
|
|
|
|
|
|
Während dieser zwei Wochen werden zumindest folgende Meetings abgehalten:
|
|
|
|
|
|
- Retrospektive
|
|
|
- Roadmap Planung
|
|
|
- Zyklusplanung
|
... | ... | @@ -86,7 +91,7 @@ Am Board gibt es folgende Spalten: |
|
|
- 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 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>
|
|
|
- **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. Nachdem eine Person zugewiesen wurde, kann diese gerne nochmal im Ticket Kommentar oder per PM angestupst und informiert werden, damit sie weiß, worum es geht.
|
|
|
- Im Idealfall kann nur durch das Review von Ticketlisten eine **Grobabschätzung der Gesamtaufwände** (z.B. für ein Release) gemacht werden.
|
|
|
|
|
|
### Priorisierung
|
... | ... | @@ -120,5 +125,6 @@ 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. |
|
|
|
| **P1, P2, P3** | Priorität des Tickets. Siehe Kapitel _Priorisierung_ oben. |
|
|
|
| **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. | |
|
|
| **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. |
|
|
|
|