GitLab-Issues

Alle Aufgaben werden über GitLab-Issues verfolgt. Jedes Issue trägt einen Status, der anzeigt, wo es sich im Workflow befindet.

Status-Workflow

  1. Open — das Issue wurde gemeldet oder angefragt, aber es ist noch nicht geplant oder priorisiert. Jede Person kann ein Issue erstellen; die Squad-Leitung triagiert es.
  2. Awaiting specifications — die Design-, Funktions- und technischen Spezifikationen müssen noch geschrieben werden, bevor mit der Arbeit begonnen werden kann. Dieser Status wird übersprungen, wenn das Issue bereits klar genug ist.
  3. Awaiting development — das Issue ist vollständig spezifiziert (produkt- und technikseitig) und bereit, übernommen zu werden.
  4. In development — das Issue wird untersucht (recherchiert), entwickelt und durchläuft den Code-Review-Prozess.
  5. On hold — die Arbeit ist blockiert, wartet auf jemand anderen (z. B. einen Kunden oder ein anderes Team), oder das Issue hat die Validierung nicht bestanden und benötigt weitere Arbeit. Sobald die Blockade aufgehoben ist, geht das Issue zurück zu In development.
  6. In validation — ein Artefakt (Build oder Staging-Umgebung) ist verfügbar und das Issue wird getestet.
  7. Awaiting deployment — das Issue ist validiert; eine neue Version der Software muss getaggt und für Endnutzer freigegeben werden.
  8. Done — das Issue ist abgeschlossen und bereitgestellt.

Ein Issue kann auch geschlossen werden, ohne erledigt zu sein:

  • Won't do — das Issue wird geschlossen, ohne umgesetzt zu werden.
  • Duplicate — das Issue wird geschlossen, weil ein anderes bereits dasselbe abdeckt.
graph TD
    S0[Open] --> S1[Awaiting specifications]
    S0 --> S2[Awaiting development]
    S1 -->|design, functional, tech| S2
    S2 --> S3[In development]
    S3 <--> S4[On hold]
    S3 --> S5[In validation]
    S5 -->|needs work| S4
    S5 --> S6[Awaiting deployment]
    S6 -->|release| S7[Done]