Arbeitsweise, DoR und DoD

Die gemeinsame Arbeitsweise soll Entscheidungen sichtbar machen, ohne für ein kleines Team unnötige Prozesslast zu erzeugen. Das GitLab-Issue ist nach seiner Anlage die verbindliche Aufgaben- und Kommunikationsquelle.

Workflow

Der sichtbare Arbeitsfluss für Mitentwickler:innen bleibt bewusst kurz:

Backlog → In Arbeit → Abnahme

Maintainer:innen steuern davor die Vorbereitung und danach die Veröffentlichung:

Vorschlag ohne Status
        │
        ▼
     Triage → DoR → Bereit → Backlog → In Arbeit → Abnahme → Release
                                                               │
                                                               ▼
                                                         dev → main

Ein Issue trägt immer nur den Status, der seinen aktuellen Platz im Ablauf beschreibt. Blockiert ist ein vorübergehender Ausnahmestatus; das Issue nennt den Blocker und den Schritt, in den es nach der Auflösung zurückkehrt.

Vorschlag ohne Status

Neue Vorschläge werden als offene Issues ohne Statuslabel angelegt. Dafür muss noch keine Definition of Ready erfüllt sein. So können auch externe Mitwirkende Ideen, Fehler oder Bedarfe unkompliziert einreichen.

Triage

Maintainer:innen prüfen, ob der Vorschlag zum Projekt gehört, ob bereits ein Issue existiert und ob weitere Informationen benötigt werden. Wird der Vorschlag übernommen, kommt er in die inhaltliche Vorbereitung. Nicht übernommene Vorschläge werden mit einer nachvollziehbaren Begründung geschlossen oder beantwortet.

DoR

Das Issue wird so vorbereitet, dass Ziel, Umfang, Akzeptanzkriterien, Abhängigkeiten und benötigte Inputs klar sind. Die unten stehende Definition of Ready ist die Prüfliste für diesen Schritt.

Bereit

Die Definition of Ready ist erfüllt, das Issue ist aber noch nicht für die unmittelbare Entwicklung eingeplant. Bereit ist damit der vorbereitete Vorrat für die nächste Planung, beispielsweise für einen kommenden Monatssprint.

Backlog

Das vorbereitete Issue ist für die Entwicklung vorgesehen und darf von Mitentwickler:innen übernommen werden. Der Backlog enthält damit nicht alle Ideen, sondern die von Maintainer:innen priorisierte nächste Arbeit.

In Arbeit

Die Umsetzung läuft auf einem eigenen Branch. Die bearbeitende Person hält Erkenntnisse, Abweichungen und Blocker im Issue fest und verlinkt den Merge Request mit Zielbranch dev.

Abnahme

Die Umsetzung ist aus Sicht der mitentwickelnden Person abgeschlossen. Vor dem Verschieben wurden Akzeptanzkriterien, relevante Tests und Definition of Done selbst geprüft. Maintainer:innen prüfen Ergebnis, Diff, Tests und Dokumentation.

Ist die Abnahme erfolgreich, mergen Maintainer:innen den Merge Request in dev und verschieben das Issue nach Release. Bei offenen Punkten geht es mit konkretem Feedback zurück nach In Arbeit.

Release

Die abgenommene Änderung ist in dev integriert und wartet dort auf den vorgesehenen Release-Zeitpunkt. Zum Release werden die freigegebenen Stände von dev nach main übernommen. Nach erfolgreichem Produktions-Smoke-Test kann das Issue geschlossen werden.

Definition of Ready

Ein Issue darf von DoR nach Bereit wechseln, wenn mindestens Folgendes feststeht:

• Ziel und erwarteter Nutzen sind verständlich beschrieben.
• Prüffähige Akzeptanzkriterien sind vorhanden.
• Priorität und ggf. Meilenstein sind gesetzt.
• Das Repository mit dem wesentlichen Ergebnis ist benannt.
• Abhängigkeiten und blockierte Folgeaufgaben sind verlinkt.
• Notwendige Inputs wie Texte, Designs, Testdaten oder Entscheidungen liegen vor oder sind ausdrücklich nicht erforderlich.
• Sicherheits-, Datenschutz-, Daten- oder Accessibility-Risiken sind benannt.
• Der Umfang ist klein genug für einen überprüfbaren Merge Request oder in Teilaufgaben zerlegt.

Definition of Done

Eine Umsetzung darf von In Arbeit nach Abnahme wechseln, wenn:

• alle issue-spezifischen Akzeptanzkriterien erfüllt sind;
• relevante automatisierte Tests lokal und in CI erfolgreich sind;
• notwendige manuelle Prüfungen durchgeführt wurden;
• der eigene Diff auf unbeabsichtigte Änderungen und Secrets geprüft wurde;
• Nutzer-, Entwicklungs- und Betriebsdokumentation aktualisiert wurden oder im Issue nachvollziehbar „nicht betroffen“ festgehalten ist;
• bekannte Einschränkungen und Folgearbeiten im Issue dokumentiert sind;
• ein Merge Request mit Zielbranch dev erstellt und mit dem Issue verknüpft ist;
• das Ergebnis in der vorgesehenen Entwicklungsumgebung selbst geprüft wurde.

Die Maintainer-Abnahme ergänzt anschließend Review, Merge nach dev und die Entscheidung, ob die Änderung nach Release wechseln kann. Der produktive Smoke-Test erfolgt erst nach dem späteren Merge von dev nach main.

Prioritäten

Eine hohe Priorität ersetzt keine erfüllte DoR. Bei einem akuten Vorfall kann der Umfang bewusst auf einen sicheren Hotfix reduziert werden; diese Abweichung wird im Issue dokumentiert.

Repository und repoübergreifende Arbeit

• App, TTS-Wiedergabe und Accessibility: digeko-app
• CMS, Inhalte, Daten, TTS-Erzeugung und KI-Redaktionsfunktionen: digeko-cms
• Dokumentation, Arbeitsweise, Betrieb und Release: digeko-docs

Ein repoübergreifendes Issue liegt dort, wo das Hauptergebnis entsteht, und verlinkt notwendige Folgeissues oder Merge Requests der anderen Repositories.

Blocker

Ein Blocker nennt im Issue:

1. die konkrete fehlende Entscheidung oder Abhängigkeit;
2. welche Arbeit dadurch nicht fortgesetzt werden kann;
3. wer oder was den Blocker auflösen kann;
4. welche sicheren Teilaufgaben weiterlaufen können.

Akzeptanzkriterien bleiben issue-spezifisch. DoR und DoD werden nur verlinkt und nicht vollständig in jedes Issue kopiert. Mitentwickler:innen müssen die Maintainer-Schritte Triage, DoR, Bereit und Release nicht selbst verwalten.