|
|
# Überblick
|
|
|
## Überblick
|
|
|
|
|
|
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.
|
|
|
Der Ablauf spiegelt einen ersten Draft wieder und wir nach entstehenden Bedürfnissen am [Miro Board](https://miro.com/app/board/uXjVMYJ3HW4=/#tpicker-content) aktualisiert.
|
|
|
|
|
|
## Organisatorische Artefakte
|
|
|
### Organisatorische Artefakte
|
|
|
|
|
|
//TODO ...
|
|
|
![image](uploads/c19636520607a6ec07f3dbdaac02dc9f/image.png)
|
|
|
<small>[Quelle](https://www.atlassian.com/de/agile/project-management/epics-stories-themes)</small>
|
|
|
|
|
|
# Planung und regelmäßige Meetings
|
|
|
### 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 finest du im [AEP Template](%link%)</mark>
|
|
|
|
|
|
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.
|
|
|
|
|
|
<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>
|
|
|
|
|
|
### 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:
|
|
|
|
|
|
> 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.
|
|
|
|
|
|
## Planung und regelmäßige Meetings
|
|
|
|
|
|
Wir plannen unsere Entwicklung in Zyklen nach der [Shape Up](https://basecamp.com/shapeup/2.2-chapter-08) Methologie von 37 Signals.
|
|
|
|
... | ... | @@ -21,28 +53,28 @@ Während dieser zwei Wochen werden zumindest folgende Meetings abgehalten: |
|
|
- Roadmap Planung
|
|
|
- Zyklusplanung
|
|
|
|
|
|
## Retrospektive
|
|
|
### Retrospektive
|
|
|
|
|
|
Die frischen Learnings aus dem letzten Zyklus werden besprochen und auf einem Retrospektive Board festgehalten.
|
|
|
|
|
|
## Release & Roadmap Planung
|
|
|
### Release & Roadmap Planung
|
|
|
|
|
|
Bevor die Konkrete Zyklusplanung durchgeführt wird, machen wir eine Metaplanung der Roadmap. Hier sehen wir uns zumindest die bevorstehenden Releases an. Wenn genug Zeit ist, kann es auch einen weiteren Ausblick geben.
|
|
|
|
|
|
Die Roadmap Planung wird mit Hilfer eines eigenen Boards gemacht. Die Ergebnise werden im [Roadmap Dokument](https://gitlab.servus.at/aura/aura/-/wikis/Roadmap) für die weitere Orientierung dokumentiert.
|
|
|
|
|
|
## Zyklusplanung
|
|
|
### Zyklusplanung
|
|
|
|
|
|
- Im Planungstreffen werden Tasks eines Zyklus mit dem jeweiligen Label versehen (z.B. `Cycle [1/23]`) und in die `TODO` Spalte des Boards gezogen.
|
|
|
- Spätestens im Planungstreffen werden **den Tickets Prioritäten zugewiesen**.
|
|
|
- Wir achten darauf **nur soviele Tasks zu planen welche realistisch innerhalb des Zyklus abgeschlossen werden**. Hier wollen wir lieber genügend Buffer für unerwartete Arbeiten wie Bugfixes einplanen. Wenn ein Task im darauf folgenden Zyklus weitergeführt wird, wird hier auch das neue Label ergänzt (z.B. `Cycle [1/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 entspricht einem Jahr. Das jeweils siebente, also älteste wird dann gelöscht.
|
|
|
|
|
|
# GitLab
|
|
|
## 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
|
|
|
### Board
|
|
|
|
|
|
Das [Board](https://gitlab.servus.at/groups/aura/-/boards "Board") zeigt den Entwicklungsstand und wird immer aktuell gehalten.
|
|
|
|
... | ... | @@ -57,7 +89,7 @@ Am Board gibt es folgende Spalten: |
|
|
| Review | Tickets, die gerade durch peer review getestet / geprüft werden. |
|
|
|
| Closed | Geschlossene Tickets. |
|
|
|
|
|
|
## 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**. Entweder als mehrere Tickets oder Checklisten innerhalb der Ticketbeschreibung.
|
... | ... | @@ -66,7 +98,7 @@ Am Board gibt es folgende Spalten: |
|
|
- **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>
|
|
|
- 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>
|
|
|
|
... | ... | @@ -78,7 +110,7 @@ Am Board gibt es folgende Spalten: |
|
|
|
|
|
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.
|
|
|
|
... | ... | @@ -86,7 +118,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
|
|
|
|
... | ... | |