ankn
a5f8fb49ab
Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)
Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.
2.3 KiB
Team Metis - Umgang mit DoD und Abnahme
Version: 8 | Last modified: 2026-03-24T13:15:53.514+01:00 Source: confluence page ID 320416827
DoD und DoR des ARTs +++ Die Abnahme erfolgt auf der Umgebung des Entwicklers, wenn möglich. Erst wenn dort die Funktion fehlerfrei funktioniert, erfolgt der finale Merge auf /main Die Implementierung erfolgt mindestens auf dem Dev-Cluster und nicht lokal. Die Abnahme führt der DEV mit Blick auf die DoD / Akzeptanzkriterien durch, damit sichergestellt werden kann, dass der vorher definierte Mehrwert erreicht wird. Nach dem Merge auf /main macht der PO/BA einen weiteren Smoke-Test auf der DEV-Umgebung. Abnahme erfolgt für Stories, die Auswirkungen auf Feature und damit für die Kunden haben. Für Technische Enabler entscheiden die DEV selbst, ob sie untereinander Reviewen oder PO/BE vorführen. Abnahme erfolgt durch den PO. In der Abwesenheit oder per Delegation kann dies auch von den BE wahrgenommen werden. Zur Abnahme vorgesehene Tickets werden von den DEV in die Spalte "Ready for approve" gestellt. Der PO (in Vertretung BA) wird vom bearbeitenden DEV bilateral angesprochen. Es wird (falls Erstellung nötig) die Dokumentation gezeigt und auf geeignete Weise das Ergebnis der Arbeit vorgeführt. Danach wird der Enabler/Story vom Reviewer auf Done gesetzt. Die fachlichen Testcases (X-Ray) werden von BA/PO angelegt. Zusätzliches Vorgehen, das wir für uns festhalten: o. g. Punkte sind nur zu beachten, wenn diese Kriterien bei einer Lieferung greifen DoD-Punkte werden in der übergeordneten Story-Liste von dem jeweiligen Dev. abgehakt, wenn diese durch Unteraufgaben erledigt wurden. DoDs, die nicht abgehakt werden können, werden in dem jeweiligen Kommentarfeld der Story erläutert.Sollte man der Meinung sein, dass kein automatischer Integration-Test möglich/notwendig ist, muss das auch in den Kommentaren festgehalten werden. Wir sprechen nochmal kurz über die Kommentare um noch eine zweite Meinung einzuholen.
Der Letzte setzt den Haken. Darauf achten, dass keine Arbeitsaufgaben oder ToDos in der Kommentarfunktion formuliert, sondern neue Unteraufgaben erstellt werden. TBD: Wie gehen wir mit Reviews und Abnahmen von Stories um, die nicht abgenommen werden können? â Dann finden bilaterale Absprachen zwischen Dev und PO statt