Migrate all repos into monorepo context folders

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.

bahn/Analyse-O2C-C2S/sources/c2s/C2S-Kommunikation/teams/DoD-Team-Io.md

@@ -0,0 +1,15 @@
+# DoD - Team Io
+
+Version: 1 | Last modified: 2026-01-06T15:53:01.522+01:00
+Source: confluence page ID 528184498
+
+---
+
+Der Product Owner/BA hat die Änderungen überprüft und freigegeben.
+Alle Akzeptanzkriterien sind fachlich richtig auf der IEU deployed (PO/BA).
+Änderungen am Interface wurden durch UX geprüft und abgenommen.
+Alle Akzeptanzkriterien wurden auf der IEU getestet, wenn möglich automatisiert (Devs).
+Fachliche Dokumentation ist erstellt/gepflegt: Benutzerhandbuch, Lösungsversion in Story / Enabler hinterlegt, fachliches Datenmodell (BKE, SN)
+Technische Dokumentation ist erstellt/gepflegt: Schnittstellenbeschreibung, Architekturbeschreibung, Umgebungen, Betriebsführungshandbuch und Migrationguide
+Für die Sicherung der Codequalität ist mindestens die Prüfung durch einen zweiten Entwickler erforderlich.
+Im Kommentar steht wer bei der Abnahme anwesend war, um sicherzustellen, dass alle wissen wen sie dazu im Zweifel nochmal ansprechen können

bahn/Analyse-O2C-C2S/sources/c2s/C2S-Kommunikation/teams/Draft-Release-Train-Technisches-Umsetzungskonzept-Automatisiertes-Multi-Team-Rel.md

@@ -0,0 +1,104 @@
+# Draft - Release Train - Technisches Umsetzungskonzept: Automatisiertes Multi-Team Release Management
+
+Version: 1 | Last modified: 2026-06-16T11:47:54.778+02:00
+Source: confluence page ID 603274912
+
+---
+
+Status | YellowDRAFT
+ | 
+Rolle | Release Manager / System Architek | 
+Zielgruppe | DevOps / Devs | 
+
+1. Einleitung & Strategischer Hintergrund In einer modernen Microservice- oder lose gekoppelten Systemlandschaft, in der mehrere autonome Entwicklerteams parallel Features entwickeln, entstehen ohne klare Strukturen zwei Kernprobleme:
+Das Integrations-Chaos: Teams deployen unkoordiniert. Stille Abhängigkeiten zwischen Services brechen erst auf höheren Umgebungen oder – im schlimmsten Fall – auf der Produktion.
+Der Dokumentations-Overhead: Entwickler verbringen wertvolle Zeit damit, Excel-Listen zu pflegen, Jira-Tickets manuell zu schieben und Confluence-Release-Notes händisch zu tippen. Das ist fehleranfällig und intransparent.
+Unsere VisionWir entkoppeln die Entwicklungsgeschwindigkeit von der Produktions-Governance.
+Auf den vorderen Umgebungen (DEV bis TEST) gilt das Prinzip der maximalen Autonomie: Teams dürfen und sollen so oft, so frei und so schnell wie möglich deployen, um schnelles Feedback zu generieren.
+Auf den hinteren Umgebungen (ABNAHME bis PRODUKTION) gilt das Prinzip der eisernen Stabilität, vollständigen Transparenz und rigorosen Automatisierung. Wir führen das „Release Train“-Modell ein. Die Produktion wird nicht mehr ad hoc bespielt, sondern ausschließlich in zwei festen Wartungsfenstern: Dienstag und Donnerstag. Wer die automatisierten und fachlichen Qualitätskriterien (Quality Gates) bis zum jeweiligen Stichtag nicht erfüllt, verpasst den „Zug“ und wartet automatisch auf den nächsten (z.B. von Dienstag auf Donnerstag). Es gibt keine künstlichen Verzögerungen für die Gesamtheit des Systems, nur weil eine einzelne Komponente verzögert ist.
+2. Die Kubernetes Stage-Infrastruktur & Quality GatesWir betreiben fünf dedizierte Kubernetes-Cluster (oder logisch strikt getrennte Namespaces), die als fortlaufende Stufen unserer Pipeline dienen. Jede Stufe besitzt ein definiertes Einlasskriterium (Quality Gate).
+2.1 DEV (Development)Zweck: Kontinuierliche Integration (CI) für Entwickler-Feedback.
+Auslösung: Jeder Push auf einen Feature-Branch oder offenen Merge Request (MR).
+Automatisches Quality Gate:Erfolgreicher Build des Docker-Images.
+Code-Linting bestanden.
+Unit-Tests erfolgreich (Coverage > 80%).
+Statische Codeanalyse (SAST / SonarQube) ohne kritische Befunde.
+
+Verhalten: Automatisches Deployment in den Dev-Namespace nach erfolgreichem Gate.
+2.2 IEU (Integrierte Entwicklungsumgebung)Zweck: Erste technische Validierung des Zusammenspiels loser gekoppelter Services.
+Auslösung: Automatischer Trigger nach einem erfolgreichen Merge auf den Hauptzweig (main / master).
+Automatisches Quality Gate:Consumer-Driven Contract Testing (CDCT): Ausführung von Verträgen (z.B. via Pact). Wenn Team A eine API-Schnittstelle so verändert, dass der Konsumenten-Service von Team B bricht, scheitert diese Pipeline sofort. Der Merge wird blockiert.
+Technische API-Integrationstests (z.B. automatisierte Postman/Newman-Kollektionen).
+
+2.3 INT (Integrierte Testumgebung mit Drittsystemen)Zweck: Vollwertige Fach- und End-to-End-Tests in einer verketteten Umgebung, die mit echten externen Drittsystemen (z.B. Zahlungsanbieter-Sandboxen, ERP-Testsystemen) kommuniziert.
+Auslösung: Automatisch nach erfolgreicher INT-Stage oder als periodischer Nightly-Build.
+Quality Gate (Hybrid):Automatisch: Umfassende End-to-End (E2E) Test-Suiten (z.B. via Playwright oder Cypress).
+Manuell/API: QA-Verantwortliche im jeweiligen Team können optionale manuelle Abnahmen via GitLab Manual Action bestätigen.
+
+Jira-Automatisierung: In Jira muss ein entsprechendes Label gesetzt werden
+2.4 ABNAHME (Staging / Produktionsnah)Zweck: Letzte Bastion vor der Produktion. Die Umgebung spiegelt die Datenmenge, Skalierung und Konfiguration der Produktion wider (inkl. replica counts, ingress-Routen etc.).
+Auslösung: Manuell durch das Erstellen eines Release-Tags (z.B. v2.4.0-rc1) im Git-Repository.
+Quality Gate (Fachliches Sign-Off):Automatisierte Last- und Performance-Tests.
+Das fachliche Go: Die Product Owner (POs) müssen die User Stories auf dieser Umgebung prüfen und im Jira-Ticket das Custom-Feld Fachliche Abnahme auf Approved setzen.
+
+2.5 PRODUKTION (Live-System)Zweck: Auslieferung des stabilen Wertes an den Endkunden.
+Auslösung: Ausschließlich Dienstag und Donnerstag innerhalb der definierten Wartungsfenster.
+Striktes Quality Gate:Alle vorherigen Stages sind vollständig grün.
+Automatischer API-Check: Gibt es offene Blocker-Tickets in Jira? Ist das Confluence-Readiness-Board im Status "GO"?
+Vier-Augen-Prinzip: Das Deployment ist als geschützte manual action in GitLab hinterlegt. Nur die Rolle Release Manager (oder explizit autorisierte Lead Engineers) hat die Berechtigung, den finalen Deploy-Knopf in der Pipeline zu drücken.
+
+3. Der BPMN-Prozessfluss im DetailDie Orchestrierung über die Teams hinweg folgt einem klaren zeitlichen und prozessualen Rhythmus.
+[Mo / Mi 15:00 Uhr] [Mo / Mi 16:00 Uhr] [Di / Do Wartungsfenster]
+ │ │ │
+ ▼ ▼ ▼
+Pipeline scannt Jira ───> Confluence-Ampel ───> Release-Sync ───> Finales Deploy
+& prüft Abhängigkeiten wird generiert (Go/No-Go) (RM Freigabe)
+
+Montag & Mittwoch 15:00 Uhr (Einsendeschluss / Feature Freeze für den Release Train): Die Entwickler müssen alle Tickets, die am Folgetag live gehen sollen, im Jira-Projekt ihres Teams mit der entsprechenden fixVersion versehen haben (z.B. Release-2026-W24-Di). Alle zugehörigen MRs müssen gemerged und auf der Abnahmeumgebung erfolgreich getestet sein.
+Montag & Mittwoch 16:00 Uhr (Der automatisierte Readiness-Scan): Ein zentral gesteuerter GitLab-Pipeline-Job (Chron-Job) startet ein automatisiertes Skript. Dieses Skript aggregiert alle Jira-Daten, validiert Abhängigkeiten und schreibt einen visuellen Statusbericht (Ampelsystem) per REST-API direkt nach Confluence.
+Montag & Mittwoch 16:15 Uhr (Das 15-Minuten-Release-Sync-Meeting): Ich als Release Manager lade die Lead-Entwickler oder Tech Leads der Teams zu einem ultrakurzen Sync ein. Wir öffnen das automatisch generierte Confluence-Board. Wir diskutieren ausschließlich Komponenten, die gelb oder rot markiert sind (z.B. weil Team B eine API-Abhängigkeit für Team A nicht rechtzeitig fertiggestellt hat).
+Entscheidung: Entweder wird das Feature per Feature-Flag deaktiviert, oder die Komponente wird für diesen "Zug" ausgehängt (fixVersion wird auf das nächste Fenster verschoben). Das fehlerfreie System der anderen Teams fährt planmäßig ab.
+Dienstag & Donnerstag (Das Deployment): Zum Start des Fensters gebe ich das GitLab-Deployment manuell frei. Nach dem erfolgreichen Kubernetes-Rollout schließt die Pipeline den Kreis, informiert die Stakeholder und setzt die Jira-Tickets automatisiert auf Done.
+4. GitLab Pipeline Konzept & ArchitekturDie Pipelines der einzelnen Team-Repositories müssen standardisiert werden, um die beschriebene Logik abzubilden. Für die Kommunikation mit Jira und Confluence wird ein zentrales Skript (z.B. in Python) genutzt, das als Docker-Image in die Pipelines eingebunden wird.
+
+4.1 Fehler- und Rollback-Strategie (One-Click-Rollback)Sollte nach dem Prod-Deployment ein kritischer Fehler im Kubernetes-Cluster auftreten (erkannt durch Prometheus-Alerts oder Sentry), sieht das Pipeline-Design eine sofortige Schadensbegrenzung vor:
+In der GitLab-Oberfläche existiert neben dem fehlgeschlagenen/problematischen Produktions-Job ein „Rollback“-Button (technisch ein helm rollback Befehl auf die vorherige stabile Revisionsnummer).
+Das Auslösen des Rollbacks triggert über das API-Skript sofort einen automatisierten Kommentar in allen zugehörigen Jira-Tickets: ⚠️ ACHTUNG: Rollback auf Produktion durchgeführt. Feature vorerst wieder deaktiviert.
+Ich als Release Manager werde sofort alarmiert, um die Task Force mit dem betroffenen Team zu koordinieren.
+5. Jira & Confluence API-Schnittstellen-KonzeptDie Pipeline-Engineers müssen das Automatisierungsskript (check_jira_and_build_confluence_table.py) so programmieren, dass es folgende Endpunkte anspricht:
+5.1 Jira REST API v3Das Skript nutzt JQL (Jira Query Language), um den Status aller Tickets einer Release-Version zu ermitteln.
+Szenario 1: Tickets auslesenEndpunkt: GET /rest/api/3/search
+Query: jql=fixVersion="Release-2026-W24-Di"
+Validierungsschleife im Code:# Pseudo-Code zur Prüfung von Blockern und Sign-Offs
+for ticket in response['issues']:
+ # Prüfe fachliche Abnahme
+ if ticket['fields']['customfield_10021']['value'] != "Approved":
+ set_status_yellow(ticket['key'], "Fehlende fachliche Abnahme durch PO")
+
+ # Prüfe verknüpfte Blocker
+ for link in ticket['fields']['issuelinks']:
+ if link['type']['name'] == "Blocks" and link['inwardIssue']['fields']['status']['name'] != "Done":
+ set_status_red(ticket['key'], f"Blockiert durch unfertiges Ticket {link['inwardIssue']['key']}")
+
+Szenario 2: Status-Update nach erfolgreichem DeploymentEndpunkt: POST /rest/api/3/issue/{issueIdOrKey}/transitions
+Payload: {"transition": {"id": "ID_FUER_STATUS_DONE"}}
+Zweck: Verschiebt alle Tickets vollautomatisch auf "Done", sobald das K8s-Deployment erfolgreich war.
+
+5.2 Confluence REST APIDas Skript übersetzt die gesammelten Jira-Zustände in ein valides XHTML-Format, das von Confluence nativ interpretiert werden kann. Um optisch ansprechende Status-Makros (die bekannten farbigen Status-Inseln) zu erzeugen, muss das Skript Confluence-Storage-Format-Tags generieren.
+Endpunkt: PUT /wiki/rest/api/content/{pageId} (Update der existierenden Release-Wochenseite)
+XHTML-Struktur für die Status-Ampel:<ac:structured-macro ac:name="status">
+ <ac:parameter ac:name="title">GO</ac:parameter>
+ <ac:parameter ac:name="colour">Green</ac:parameter>
+</ac:structured-macro>
+
+<ac:structured-macro ac:name="status">
+ <ac:parameter ac:name="title">NO-GO</ac:parameter>
+ <ac:parameter ac:name="colour">Red</ac:parameter>
+</ac:structured-macro>
+
+Das Skript baut aus diesen Bausteinen eine übersichtliche Matrix-Tabelle aller Services und lädt den HTML-Body via API hoch.
+6. Zusammenfassung & Nächste Schritte für die Pipeline-EntwicklerMit diesem System beenden wir das Zeitalter der manuellen Berichterstattung. Entwickler tun das, was sie am besten können: Code schreiben und Git pflegen. Die Pipeline erledigt den bürokratischen Rest. Arbeitspakete für das DevSecOps- / Pipeline-Team:
+Paket 1: Erstellung des zentralen Python/Node-Docker-Images, das die Logik für die Jira- und Confluence-API-Kommunikation beinhaltet.
+Paket 2: Einbau der CDCT/Pact-Test-Schritte in die test-Stage der Standard-Pipeline.
+Paket 3: Konfiguration der geschützten Variablen (API-Tokens für Jira/Confluence) in den globalen GitLab-CI-Einstellungen.
+Paket 4: Implementierung der when: manual Schranke für die Produktions-Infrastruktur-Pipelines mit Benutzerrollen-Einschränkung.

bahn/Analyse-O2C-C2S/sources/c2s/C2S-Kommunikation/teams/Refinement-Prozess-Team-IO.md

@@ -0,0 +1,8 @@
+# Refinement-Prozess Team IO
+
+Version: 5 | Last modified: 2026-01-29T13:40:32.184+01:00
+Source: confluence page ID 517781117
+
+---
+
+trueRefinement-Prozess Iofalse600autotoptrue12566216

bahn/Analyse-O2C-C2S/sources/c2s/C2S-Kommunikation/teams/Team-Dia-KOMBau.md

@@ -0,0 +1,17 @@
+# Team Dia - KOMBau 💎
+
+Version: 4 | Last modified: 2026-03-19T09:36:52.354+01:00
+Source: confluence page ID 540794334
+
+---
+
+Das Team:
+Name | Rolle | E-Mail | 
+Debora Heimer
+ | UX | Debora.Heimer@deutschebahn.com | 
+Emil Vanselow | PO | Emil.Vanselow@deutschebahn.com  | 
+Ferdinando De Meo | UX | Ferdinando.De-Meo@deutschebahn.com  | 
+Josephine Leusman | UX | Josephine.Leusman@deutschebahn.com  | 
+Kim Leah Reibnitz | SM/TC | Kim-Leah.Reibnitz@deutschebahn.com  | 
+Milena M Kunz | UX | Milena.M.Kunz@deutschebahn.com  | 
+Tabea Lessing | UX | Tabea.Lessing@deutschebahn.com  |

bahn/Analyse-O2C-C2S/sources/c2s/C2S-Kommunikation/teams/Team-Europa-KOMBau.md

@@ -0,0 +1,41 @@
+# Team Europa - KOMBau 🌕
+
+Version: 9 | Last modified: 2026-02-24T08:54:03.195+01:00
+Source: confluence page ID 428928125
+
+---
+
+Wir sind Team Europa. (ehemals Team AQuA)
+Ende 2023 sind wir in IFP gestartet und haben den AGS von (ehemals) Team Y übernommen. Nach knapp einem Jahr im ART DaS sind wir seit PI 35 Teil vom ART.KOM. Anfang Oktober 2025 ist der AGS zum ART ujK übergangen nun fokussieren wir uns auf den Auth-Service sowie Export-Service für die KOMBau, als ein Shared Services Team.
+Aktuell befinden wir uns noch in der Umstellung des Teamnamens auf allen Umgebungen, sowie die Erstellung eines neuen Logos.
+Mailverteiler: C2S.KOM.Europa@deutschebahn.com 
+
+Wer | Schwerpunkte
+ | 
+ 
+ | Product Owner
+ | 
+ 
+ | Scrum Master
+ | 
+ 
+ | BE
+PO-Vertretung
+ | 
+
+ | Entwicklung
+Grafana
+ | 
+
+ | Entwicklung
+DevOps
+ | 
+
+ | Entwicklung
+ | 
+
+ | Entwicklung
+ | 
+
+ | Entwicklung
+ |

bahn/Analyse-O2C-C2S/sources/c2s/C2S-Kommunikation/teams/Team-Europa-Naming-Conventions.md

@@ -0,0 +1,58 @@
+# Team Europa: Naming Conventions
+
+Version: 11 | Last modified: 2026-02-02T11:46:28.363+01:00
+Source: confluence page ID 402097097
+
+---
+
+Branch-ConventionstrueAQuA Branch rulesfalse600autotoptrue14024091
+Dauerhafte Branchesdevelopment enthält zu jedem Zeitpunkt den letzten Stand der abgeschlossenen Issues, d.h. Arbeit an Features, Enablern und Bugs werden nach Abschluss per Merge Request auf diesen Branch gebracht. Im Fall von Hotfixes werden diese auch nach Abschluss über release zurück nach development gebracht.
+Von release (früher main) erstellen wir am Ende jeder Iteration ein Release durch Setzen eines Tags, nachdem wir den Stand von development dorthin gemergt haben.
+
+Regeln für temporäre BranchesBranches für Hotfixes zweigen von release ab und tragen das Präfix hotfix/. Auf diese Weise sind sie nicht nur als Hotfixes leichter erkennbar, es lässt sich auch im GitLab konfigurieren, dass Merge Requests für Hotfixes per Default zurück nach release gehen. Von dort mergen wir dann weiter zurück nach development.
+Branches für die Arbeit an Jira-Issues (Features, Enablers oder Bugs, die keine Hotfixes sind) verwenden das Präfix ticket/ und werden von development abgezweigt. In GitLab konfigurieren wir, dass Merge Requests von diesen Branches per Default zurück nach development gehen. Die Information, um welche Art von Issue es sich handelt, ist nun nicht mehr redundant im Branchnamen enthalten, ist an der Stelle aber auch nicht nötig.
+Branches für Arbeiten ohne Issue verwenden als Präfix no-ticket/. Sie werden wie Issue-Branches von development abgezweigt und per Default dorthin gemergt.
+Durch Tools erstellte Branches, wie z.B. durch den Renovate Bot, erhalten einen Bezeichner des Tools als Präfix, wie z.B. renovate/, und werden per Merge Request nach development gemergt.
+
+Auf das Präfix folgt bei Branches, die sich auf ein Issue beziehen, die ID des Issues sowie eine durch Bindestriche gekoppelte kurze Beschreibung des Inhalts, also z.B. IFPRPR-112-map-calendar-attributes. Bei Branches ohne Issue verwenden wir nach dem Präfix aussagekräftigen Kurzbezeichnung, z.B. add-ktlint
+Wichtig: Bei Commits auf den temporären Branches beachten wir die AQuA: Konventionen für Commit-Messages.
+Suffixe für API-KlassenDer AGS verwendet diverse Schemata für JSON-Daten, z.B. Produktions- und Vertriebsaufträge jeweils in den Domänen Vertrieb und Fahrplan, die wir umgangssprachlich APIs nennen und die in Form von OpenAPI-Spezifikationen vorliegen. Für die Verarbeitung der Daten nutzen wir Code, der mit einer ifpGenerateApiClient Gradle-Task generiert wird (siehe z.B. Submodul produktionsauftrag-api-fahrplan). Bei der Konfiguration der Task kann ein modelNameSuffix angegeben werden, der an alle Namen von generierten Klassen angehängt wird. Dieses Suffix sollten wir für alle APIs durchgängig einheitlich gestalten, so dass am Namen einer Klasse ihr Ursprung abgelesen werden kann, mit dem Ziel, den Code, der API-Klassen nutzt, leichter verständlich zu machen, und um Fehlern vorzubeugen.
+Ein Suffix sollte deshalb im Regelfall aus zwei Teilen bestehen:
+Einem Kürzel für die Gesamtmenge der enthaltenen Nachrichten. Aktuell verwenden wir Pa für Produktions- und Va für Vertriebsaufträge. Künftig wäre z.B. Bpe oder Pe für (Bau-)Planungsergebnisse im unterjährigen Bau denkbar.
+Einem Bezeichner für den Kontext - i.d.R. die Domäne - dem die API entstammt. Aktuell verwenden wir Vertrieb und Fahrplan für eben diese beiden Domänen.
+Als Kombination ergeben sich dann insgesamt z.B. ErstanmeldungMessagePaVertrieb und PathInformationVaFahrplan als Klassennamen.
+Dies sollte im Allgemeinen alles sein, ein weiteres Anhängsel wie Dto fügt nur unnötiges Rauschen hinzu, da das Vorhandensein eines Suffixes ohnehin schon signalisiert, dass es sich um eine API- und damit DTO-Klasse handelt.
+Commit Messages und Titel von Merge-Requestssiehe 
+Tests und TestvariablenVariablen innerhalb von Tests folgen diesen Konventionen:
+Test-Inputs bekommen den Präfix given
+Erzeugte Ergebnisse (typischerweise der Rückgabewert der getesteten Methode) bekommen den Präfix actual
+Erwartete Ergebnisse (typischerweise das, wogegen die actual-Werte verglichen werden) bekommen den Präfix expected
+Das zu testende System (typischerweise ein Service oder eine anderweitige Spring-Komponente, aber möglicherweise auch eine (Extension- oder statische) Funktion) bekommt den Präfix tested.
+Gemockte Komponenten bekommen den Präfix mock. Dies wird sinnvoll adaptiert für mock-ähnliche Komponenten (Spys, ...)
+Der Mehrwert, der hierdurch gewonnen werden soll, ist, dass innerhalb eines Tests eindeutig auf einen Blick identifiziert werden kann, welches das getestete System und welches nur Hilfestellungen für den Test sind.
+Codebeispiel(exemplarisch, nicht realer Code mit vielen Auslassungen)
+java
+ @Spy
+ var spyAngebotstrasseMessageService : MessageService 
+
+ fun `receiving Fertigmeldung should trigger sending Angebotrasse`(
+ val givenFertigmeldung: Fertigmeldung, // or string of JSON
+ val givenZugtrasse: Zugtrasse,
+ val expectedAngebotstrasse: Angebotstrasse
+ ) {
+ // Arrange
+ when(mockAngebotstrassenRepository.getByFertigmeldung(givenFertigmeldung)).thenReturn(givenZugtrasse)
+
+ // Act
+ spyFertigmeldungMessageService.send(givenFertigmeldung)
+ 
+ // Assert
+ assertEquals(true, spyAngebotstrasseMessageService.hasNext())
+ val actualAngebotstrasse = spyAngebotstrasseMessageService.receive()
+        assertEquals(false, spyAngebotstrasseMessageService.hasNext())
+ assertEquals(expectedAngebotstrasse, actualAngebotstrasse)
+
+ val actualAllAngebotstrassen = testedAngebotstrassenService.getAllAngebotstrassen()
+ assertEquals(1, actualAllAngebotstrassen.size)
+ }
+}]]>

bahn/Analyse-O2C-C2S/sources/c2s/C2S-Kommunikation/teams/Team-Europa-Scrum-Events.md

@@ -0,0 +1,65 @@
+# Team Europa: Scrum Events
+
+Version: 3 | Last modified: 2026-02-02T11:45:51.789+01:00
+Source: confluence page ID 490592987
+
+---
+
+42
+Team Sync / Daily 
+Ziel: Das Daily dient dazu, den Fortschritt zu überprüfen, Hindernisse zu identifizieren und die Arbeit für den Tag zu planen.
+Dauer: Max. 15 Minuten
+Ablauf: 
+Was habe ich seit dem letzten Daily erreicht?
+Was werde ich bis zum nächsten Stand-up tun?
+Welche Hindernisse stehen mir im Weg?
+
+Anti-Patterns:
+Statusbericht an ScM oder PO: Das Daily ist kein Reporting-Meeting, sondern ein Austausch unter den Teammitgliedern.
+Zu lange Diskussionen: Detaildiskussionen sollten nach dem Meeting separat geführt werden - z.B. im "Meet-after"
+Fehlender Fokus auf Hindernisse: Hindernisse sollten klar benannt und nicht verschwiegen werden.
+Multitasking während des Meetings: Alle Teilnehmer sollten aufmerksam und fokussiert sein.
+Backlog RefinementZiel: Abhängigkeiten und Probleme identifizieren, die sich auf
+die nächste Iteration auswirken könnten. Fertiges Backlog für die Iterationsplanung erstellen.
+Dauer: 70 Minuten
+Ablauf: (Muster)
+PO stellt ein Set von potentiellen Stories / Enablern vor und führt durch das Backlog
+PO und Team besprechen jede Story.Erstellen u. a. AKs und decken Abhängigkeiten auf
+-> letztlich sollten die Stories / Enabler die DoR erfüllen.
+
+Anti-Patterns:
+Fehlende Priorisierung: Wenn die Backlog Items nicht klar priorisiert sind, kann das Team Schwierigkeiten haben, sich auf die wichtigsten Aufgaben zu konzentrieren.
+Unklare Akzeptanzkriterien: Wenn die Akzeptanzkriterien nicht klar definiert sind, kann es zu Missverständnissen und Nacharbeit kommen.
+ReviewZiel: Das Sprint Review dient dazu, die während des Sprints erzielten Ergebnisse zu präsentieren und Feedback innerhalb des Teams einzuholen. Es hilft, den Fortschritt zu bewerten und Anpassungen für zukünftige Sprints zu planen.
+Dauer: 50 Minuten
+Ablauf: (Muster)
+Blick auf die Objectives, haben wir sie erreicht?
+Demonstration der Ergebnisse und Feedback
+
+Anti-Patterns:
+Fehlende Vorbereitung: Unvorbereitete Präsentationen können den Wert des Reviews mindern.
+RetrospektiveZiel: Die Retrospektive dient dazu, die Zusammenarbeit und Prozesse im Team zu reflektieren und kontinuierlich zu verbessern. Es sollen Maßnahmen zur Optimierung identifiziert und beschlossen werden.
+Dauer: 80 Min
+Ablauf: (Muster)
+Check-in
+Daten sammeln: Was lief gut? Was könnte verbessert werden? 
+Erkenntnisse gewinnen: Diskussion der gesammelten Daten und Identifikation von Mustern oder Problemen.
+Maßnahmen planen: Konkrete Maßnahmen zur Verbesserung festlegen und Verantwortlichkeiten zuweisen.
+Check-out
+
+Anti-Patterns:
+Schuldzuweisungen: Die Retrospektive sollte nicht dazu genutzt werden, Schuld zuzuweisen, sondern konstruktiv zu bleiben.
+Keine Maßnahmen: Ohne konkrete Maßnahmen verliert die Retrospektive an Wert.
+Dominanz einzelner Personen: Wenn nur wenige Personen sprechen und andere nicht zu Wort kommen, kann das die Qualität der Diskussion beeinträchtigen.
+Sprint PlanningZiel: Das Sprint Planning dient dazu, die Arbeit für den kommenden Sprint zu planen und sicherzustellen, dass das Team versteht, was zu tun ist und wie es erreicht werden soll.
+Dauer: 70 Min
+Ablauf: (Muster)
+Zielsetzung: Der Product Owner stellt das Sprint-Ziel vor.
+Backlog-Durchsicht: Das Team bespricht die priorisierten Backlog-Items und wählt die aus, die im Sprint bearbeitet werden sollen.
+Aufgabenplanung: Das Team plant die Umsetzung der ausgewählten Items und schätzt den Aufwand.
+Abschluss: Zusammenfassung und Sicherstellung, dass alle Teammitglieder die Ziele und Aufgaben verstehen.
+
+Anti-Patterns:
+Überladung des Sprints: Zu viele Items in den Sprint zu packen, kann zu Überlastung und Frustration führen.
+Fehlende Priorisierung: Wenn die wichtigsten Aufgaben nicht priorisiert werden, kann das Team an weniger wichtigen Dingen arbeiten und die Sprint-Ziele verfehlen.
+Fehlende Teambeteiligung: Das gesamte Team sollte aktiv am Planning teilnehmen und nicht nur der PO oder der Scrum Master.

bahn/Analyse-O2C-C2S/sources/c2s/C2S-Kommunikation/teams/Team-IO-KOMBau.md

@@ -0,0 +1,31 @@
+# Team IO - KOMBau 🫏
+
+Version: 21 | Last modified: 2026-06-01T08:35:16.363+02:00
+Source: confluence page ID 322190978
+
+---
+
+Wer wir sind Rolle | Vorname, Name  | 
+PO  |  
+ | 
+SM / TC  |   | 
+BA |  
+ | 
+BA |  
+ | 
+
+ | 
+
+ | 
+DEV |  
+ | 
+DEV | 
+ | 
+DEV |  
+ | 
+DEV |  
+ | 
+DEV |  
+ | 
+
+Team Kalender5d6d71c6-ea45-4c43-be4a-ee73de2eadd9

bahn/Analyse-O2C-C2S/sources/c2s/C2S-Kommunikation/teams/Team-Metis-KOMBau.md

@@ -0,0 +1,23 @@
+# Team Metis - KOMBau🦉
+
+Version: 13 | Last modified: 2026-01-08T10:48:13.023+01:00
+Source: confluence page ID 322196220
+
+---
+
+Rolle
+ | Name
+ | 
+PO |  
+ | 
+Scrummaster |  
+ | 
+BAs |  
+ | 
+Devs |  
+ 
+ 
+ 
+ 
+ 
+ |

bahn/Analyse-O2C-C2S/sources/c2s/C2S-Kommunikation/teams/Team-Metis-Sicherstellen-der-korrekten-LÃ-sungsversion.md

@@ -0,0 +1,11 @@
+# Team Metis - Sicherstellen der korrekten Lösungsversion
+
+Version: 3 | Last modified: 2026-04-08T14:56:40.202+02:00
+Source: confluence page ID 573777764
+
+---
+
+Generell legt der PO (in Vertretung auch der BA) die entsprechende Lösungsversion und damit die gewünschte Lieferung bei der Abnahme der jeweiligen Story/Enabler/Bug fest.
+Diese Lösungsversion sollte in der Regel die nächste geplante Regel-Lieferung treffen.
+Um sicher zu gehen, dass keine Tickets ohne Lösungsversion bleiben und daher in der Abfrage unerkannt bleiben, werden spätestens nach Sprintstart vom PO alle in Arbeit befindlichen Tickets mit der Lösungsversion nextRelease versehen.
+Sollte es abgearbeitete Tickets geben, welche keine richtige Lieferung benötigen (Kafka-Change, Karate-Test Anpassung oder ähnliches), dann wird bei der Abnahme des Tickets dies in den Kommentaren vermerkt.

bahn/Analyse-O2C-C2S/sources/c2s/C2S-Kommunikation/teams/Team-Metis-Umgang-mit-DoD-und-Abnahme.md

@@ -0,0 +1,29 @@
+# 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

bahn/Analyse-O2C-C2S/sources/c2s/C2S-Kommunikation/teams/Team-Metis-Umgang-mit-technischen-Schulden.md

@@ -0,0 +1,28 @@
+# Team Metis - Umgang mit technischen Schulden
+
+Version: 2 | Last modified: 2026-01-28T09:59:12.267+01:00
+Source: confluence page ID 493880248
+
+---
+
+Technische Schulden in der Software-Entwicklung sind bewusste oder unbewusste Kompromisse bei der Code-Qualität oder Systemarchitektur, die kurzfristig die Entwicklung beschleunigen, aber langfristig zu erhöhtem Wartungsaufwand und möglichen Problemen führen.
+Hier geht es um den Umgang mit technischen Schulden im Team Metis, sodass sie geplant und abgearbeitet werden können.
+Erkennung technischer Schulden 
+Fallen während der Entwicklung Verbesserungsmöglichkeiten auf, prüft derdie Entwicklerin, ob diese direkt mit erledigt werden können. Gegebenenfalls wird dies im Daily angesprochen. Es gilt weiterhin, dass das Erreichen des Sprintziels Vorrang vor der Abarbeitung bestehender technischer Schulden hat.
+Werden technische Schulden direkt abgearbeitet, wird ggf. eine Unteraufgabe zum aktuellen Entwicklungsticket erstellt.
+Sollten erkannte oder bekannte technische Schulden aufwändiger sein und daher in der aktuellen Entwicklung nicht ohne Weiteres abgearbeitet werden können, legt derdie jeweilige Entwicklerin ein Ticket an.
+Dieses Ticket enthält mindestens:
+Den passenden Typ (Enabler oder Story)
+Eine aussagekräftige Überschrift (verständlich auch für Nicht-Entwickler*innen)
+Die betroffene Komponente
+Das Stichwort "TechDebt"
+Eine Beschreibung, mindestens in Stichpunkten
+Dem PO (oder stellvertretend dem BA) fallen die neuen Tickets im Backlog auf. Eventuell wird der PO auch im Daily auf das neue Ticket hingewiesen.
+Einplanung technischer Schulden
+Der PO sorgt dafür, dass das Ticket nach der Erstellung bis zum nächsten Refinement alle weiteren notwendigen Angaben enthält (wie Akzeptanzkriterien usw.).
+Im Refinement wird das Ticket geschätzt und in den Status "Erfüllt DoR" (Definition of Ready erfüllt) gebracht.
+Die Top-of-Backlog-Philosophie soll konsequent gelebt werden!
+Das Ticket wird vom PO entsprechend im Backlog eingeordnet.
+Ziel ist es, diese technischen Schulden priorisiert abzuarbeiten.
+Sollte eine Entwicklerin mit seinen Aufgaben im laufenden Sprint fertig sein und auch seine Kolleg*innen nicht unterstützen können, greift er oder sie auf das Backlog zurück.
+Technische Schulden und/oder Bugs aus dem Backlog haben Vorrang vor dem Vorziehen von Aufgaben aus Folgesprints!

bahn/Analyse-O2C-C2S/sources/c2s/C2S-Kommunikation/teams/Team-Metrics.md

@@ -0,0 +1,85 @@
+# Team Metrics
+
+Version: 3 | Last modified: 2026-02-24T15:38:26.440+01:00
+Source: confluence page ID 553943905
+
+---
+
+Die folgenden Kennzahlen dienen der Transparenz über unseren Arbeitsfluss und unsere Zusammenarbeit auf Teamebene.
+Sie unterstützen uns dabei, Muster zu erkennen, Engpässe sichtbar zu machen und fundierte Entscheidungen zur kontinuierlichen Verbesserung zu treffen.
+Dabei gilt:
+Kennzahlen sind Systemindikatoren, keine Leistungsbewertung einzelner Personen oder Teams.
+
+Sie zeigen Trends und Muster – keine isolierten Wahrheiten.
+
+Ihre Aussagekraft entsteht erst durch regelmäßige gemeinsame Reflexion.
+
+Einzelne Werte sind weniger relevant als Entwicklungen über mehrere Iterationen hinweg.
+
+Unser Ziel ist nicht maximale Geschwindigkeit, sondern ein stabiler, nachhaltiger und vorhersagbarer Arbeitsfluss.
+Kennzahlen helfen uns insbesondere dabei:
+Fokus und Priorisierung zu reflektieren
+
+Engpässe frühzeitig zu erkennen
+
+Qualität und Stabilität im Blick zu behalten
+
+Entscheidungsprozesse zu verbessern
+
+Transparenz gegenüber Stakeholdern herzustellen
+
+Wir nutzen diese Kennzahlen bewusst als Gesprächsgrundlage in Reviews, Retrospektiven und strategischen Abstimmungen.
+Sie sind ein Instrument zur Verbesserung unseres ARTs – nicht zur Kontrolle von Teams.
+
+Kennzahl | Beschreibung der Kennzahl | Anwendungsbeispiele | Typische Muster und Interpretation | 
+Flow Distribution | Flow Distribution zeigt die prozentuale Verteilung der erledigten Arbeit nach Arbeitstypen (z. B. Feature, Bug, Enabler/Technical Debt, Support, Spike) innerhalb eines definierten Zeitraums (Sprint, Monat, Quartal).
+Sie macht sichtbar, wofür das Team seine Kapazität tatsächlich verwendet und welche impliziten Prioritäten im Arbeitsalltag entstehen.
+Die Kennzahl dient der Reflexion des Arbeitsfokus und ist keine Leistungskennzahl.
+ | Strategischen Fokus überprüfen: Entspricht die tatsächliche Verteilung unserer geplanten Ausrichtung?
+ Qualitätsentwicklung beobachten: Steigt der Bug-Anteil über mehrere Sprints hinweg? 
+Balance diskutieren: Wie viel Kapazität investieren wir in neue Features vs. Wartung oder technische Verbesserungen?
+Transparenz gegenüber Stakeholdern schaffen: Warum liefern wir weniger Features, wenn Support oder Stabilisierung dominieren?- Nachhaltigkeit prüfen: Investieren wir ausreichend in Enabler und technische Schulden?
+ | Hoher Bug-Anteil: mögliches Qualitätsproblem, instabile Architektur oder fehlende Testautomatisierung. 
+Kaum Enabler/Tech Debt: kurzfristiger Lieferdruck, Risiko für langfristige Wartbarkeit.
+Hoher Support-/Maintenance-Anteil: hohe Betriebslast oder unklare Produktverantwortung.
+Stark schwankende Verteilung: fehlender Fokus oder häufige Prioritätswechsel.
+Sehr hoher Feature-Anteil bei gleichzeitig steigender Bug-Quote: Qualitätsrisiko durch Lieferdruck.
+ | 
+Lead Time | Lead Time misst die Zeit vom Start der Bearbeitung eines Vorgangs bis zu dessen Fertigstellung (z. B. von „In Progress“ bis „Done“).Sie zeigt, wie schnell Arbeit durch das System fließt und wie stabil der Lieferprozess ist.
+Lead Time ist eine Systemkennzahl zur Prozessverbesserung und keine Bewertung einzelner Personen.
+ | Lieferfähigkeit verbessern und realistische Forecasts ableiten.
+Vorhersagbarkeit erhöhen: Wie stabil ist unsere durchschnittliche Durchlaufzeit?
+Engpässe und Wartezeiten identifizieren (in Kombination mit Status-Verweildauer).
+Wirkung von Prozessänderungen messen (z. B. WIP-Limits, Pair Programming, Automatisierung).
+Ticket-Zuschnitt prüfen: Sind Stories zu groß oder unklar geschnitten?
+ | Kontinuierlicher Anstieg: Systemüberlastung oder zu viel parallele Arbeit (WIP).
+Hohe Streuung: stark unterschiedliche Ticketgrößen oder wechselnde Prioritäten.
+Viele Ausreißer mit sehr langer Dauer: Blockaden, Abhängigkeiten oder externe Freigaben.
+Sinkender und stabiler Trend: verbesserter Flow und klarere Übergaben.
+Sehr kurze Lead Time bei hoher Fehlerquote: möglicher Qualitätskompromiss.
+ | 
+Umgesetzte vs. verworfene Ideen | Diese Kennzahl zeigt das Verhältnis zwischen realisierten und bewusst gestoppten bzw. nicht weiterverfolgten Produktideen im gewählten Zeitraum.
+Als „Idee“ gelten z. B. Initiativen, Epics oder größere Features – nicht einzelne User Stories.Die Kennzahl macht sichtbar, wie konsequent priorisiert wird und ob bewusste Entscheidungsprozesse stattfinden.
+ | Fokus prüfen: Setzen wir alles um oder priorisieren wir konsequent?
+Entscheidungsqualität reflektieren: Werden Ideen früh validiert oder erst spät verworfen?-
+Stakeholder-Transparenz schaffen: Produktentwicklung bedeutet auch bewusstes Nicht-Umsetzen.
+Discovery-Prozess verbessern: Hypothesen, Erfolgskriterien und Experimente klarer definieren.
+ Ressourcensteuerung prüfen: Wie viel Aufwand investieren wir in Ideen, die später gestoppt werden?
+ | Fast alle Ideen werden umgesetzt: fehlende Priorisierung oder Strategieunschärfe.
+Viele späte Abbrüche: zu geringe frühe Validierung oder unklare Zieldefinition.
+Viele frühe Stopps mit klarer Begründung: gesunder Filtermechanismus.
+Sehr hoher Verwerfungsanteil: möglicherweise zu strenge Kriterien oder fehlende Kapazität.- Kaum verworfene Ideen trotz hoher Auslastung: Risiko von Überfrachtung.
+ | 
+Average Days in Status | Average Days in Status zeigt die durchschnittliche Verweildauer von Vorgängen in einzelnen Workflow-Status (z. B. „In Progress“, „Code Review“, „Testing“, „Waiting for Approval“).
+Die Kennzahl macht sichtbar, in welchen Prozessschritten Arbeit besonders lange verbleibt und wo Wartezeiten entstehen.
+Sie dient der Identifikation von Engpässen und Prozessineffizienzen.
+ | Engpassanalyse: Welcher Status hat die längste Verweildauer?
+Wartezeiten sichtbar machen (z. B. Review, Abnahme, Deployment).
+WIP-Management reflektieren: Lange „In Progress“-Zeiten als Hinweis auf zu viel Parallelität.
+Kapazitätsungleichgewichte erkennen (z. B. Test- oder Review-Engpässe).- Wirkung von Prozessverbesserungen messbar machen.
+ | Ein Status sticht deutlich heraus: lokaler Engpass im System. 
+Lange Review- oder Testing-Phasen: fehlende Kapazität, zu große Tickets oder unklare Übergabekriterien.
+Lange „In Progress“-Zeit: zu viel parallele Arbeit und Kontextwechsel.
+Mehrere lange Warte-Status: viele Übergaben oder externe Abhängigkeiten.-
+Sehr geringe Verweildauer in allen Status: kleine, gut geschnittene Arbeitspakete und stabiler Flow.
+ |

bahn/Analyse-O2C-C2S/sources/c2s/C2S-Kommunikation/teams/Team-Pandia-KOMBau.md

@@ -0,0 +1,49 @@
+# Team Pandia - KOMBau 🐼
+
+Version: 36 | Last modified: 2026-03-30T12:40:46.593+02:00
+Source: confluence page ID 256705809
+
+---
+
+🐼
+
+Wir sind ein Entwicklungsteam für das Produkt KOMBau.
+Wir teilen mit den anderen Teams eine gemeinsame Vision:
+"Wir sind der „Single Point of Truth“ in Sachen Stellungnahme, Rückmeldung und Historisierung. Dazu kommunizieren wir alle relevanten Bauauswirkungen fristgerecht und Annex VII-konform."
+Aus <https://arija-confluence.jaas.service.deutschebahn.com/display/C2SK/ART+Kommunikation> 
+
+Mailverteiler: C2S.KOM.Pandia <C2S.KOM.Pandia@deutschebahn.com>
+Das Team:
+Name | Rolle | E-Mail | 
+Adriana D’Ambrosio
+ | Product Owner | Adriana.DAmbrosio@deutschebahn.com | 
+Anja Niemann | Scrum Master | anja.niemann@deutschebahn.com | 
+Leutrim Maliqi | Business Analyst | Leutrim.L.Maliqi-extern@deutschebahn.com | 
+Björn Baumgarten | BE-Developer | Bjoern.Baumgarten-extern@deutschebahn.com | 
+Dominique Dorscheid | BE-Developer | Dominique.Dorscheid-extern@deutschebahn.com | 
+Stefan Kacarevic | BE-Developer | Stefan.Kacarevic-extern@deutschebahn.com | 
+Alexander Kantak | FS-Developer | Alexander.Kantak-extern@deutschebahn.com | 
+Abdelaziz Akkad | FS-Developer | Abdelaziz.Akkad-extern@deutschebahn.com | 
+Nicola Hanna | FS-Developer | Nicola.Hanna@deutschebahn.com | 
+Martina Hunfeld | FE-Developer | Martina.M.Hunfeld@deutschebahn.com | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+ | 
+ | 
+ | 
+
+Links:
+AriJa Board
+Teamplace Pandia
+etc...

bahn/Analyse-O2C-C2S/sources/c2s/C2S-Kommunikation/teams/Team-Pandia-Meetings-ART.md

@@ -0,0 +1,272 @@
+# Team Pandia - Meetings (ART)
+
+Version: 52 | Last modified: 2025-12-04T08:39:49.014+01:00
+Source: confluence page ID 265523953
+
+---
+
+Oberste Regel: Sprintziele stehen über Termintreue!
+
+Besprechungsname
+ | Frequenz/Termin
+ | Ziel des Meetings
+ | Inhalt
+ |  Teilnehmer
+ | Kommentar / Agenda
+ | Status aktualisiert
+Stand 23.01.25
+ | 
+Dev-Termine: |   | 
+ |   | 
+
+ | 
+ | 
+ | 
+ART.KOM: State of the ART
+ | alle 4 Wochen Mi. 11:35 - 12:00 Uhr | Infos und Neuigkeiten aus dem ART und für den ART | Standardagenda:
+Personelles
+Einblick in aktuelle Themen
+Blick auf Risiken und Impediments
+Sonstige Themen (wer ein Thema hat, meldet sich bitte beim ART-Trio)
+ | Alle ART-Mitglieder
+Moderation: RTE
+ | Protokoll:
+ART.KOM Allgemein Kanal in MS Teams
+ | 
+
+22
+complete
+Status aktualisiert
+
+ | 
+ARTKOM-Entwicklerrunde
+ | 1mal/Woche - Fr. 10:30 - 11:30 Uhr | Austausch zwischen Softwareentwicklern mit unterschiedlichen und meist technischen Themen.
+
+ | 
+ | Devs:
+ 
+ 
+ 
+im wöchentlichen Wechsel
+ 
+ | 
+ | 
+
+27
+complete
+Status aktualisiert
+
+ | 
+PO/BA-Termine: |   |   | 
+
+ | 
+
+ |  
+ |  
+ | 
+ART-Sync / PO-Sync | 2mal/Woche - Mo/Do 13:00 -13:30 Uhr | Fachliche Steuerung des ARTs und der Teams | Aktueller Status des ARTs und der Teams
+Impediments
+=> was klemmt gerade und wer kümmert sich darum?
+Vertiefende Diskussion aktueller Themen mit den betroffenen
+Aufnahme neuer Themen
+Rückmeldung zu erarbeiteten Ergebnissen
+Priorisierungsempfehlung 
+ | POs/PM
+ 
+oder BA-Vertretung
+ 
+SM (zum ART-Sync)
+ 
+ | Vertreterbenennung erforderlich 
+PO-Sync Sharepoint
+ | 
+
+33
+complete
+Status aktualisiert
+
+ 
+ | 
+PM aktuell - KOMBau | 1mal/Woche - Do 14:05-15:55 | Austauschtermin zwischen PM und BA's | Statusaustausch über aktuelle Themen
+ | PM/BAs
+ 
+ |  
+ | 
+
+44
+complete
+Status aktualisiert
+
+ 
+ | 
+KOMBau - I.NBF22 - regelmäßiger Austausch | alle 2 Wochen Mi. 09:00 - 09:55 Uhr | Fachliche Abstimmung mit I.NBF 22 | Aufnahme und Durchsprache von Anforderungen
+ | PM/POs/BAs
+ 
+ 
+ |  
+ | 
+
+48
+complete
+Status aktualisiert
+
+ | 
+KOMBau - I.IBF 4 - regelmäßiger Austausch | alle 2 Wochen Mi. 09:00 - 09:55 Uhr | Fachliche Abstimmung mit I.NBF 4 | Aufnahme und Durchsprache von Anforderungen
+ | PM/POs/BAs
+ 
+ 
+ 
+ |  
+ |   | 
+KOMBau Austausch Betrieb Projekt/Ops4I/FBF/CIO | 1mal/Woche - Do 11:00-11:30 |   | 
+
+ | SA/POs/BAs
+Devs
+ 
+ 
+ 
+ |  
+ |   | 
+Feature Refinement  | 1mal/Woche - Do 14:05-15:55 | Die Feature fürs nächste PI vorbereiten | Damit wir wissen was für Arbeit auf uns zukommen wird. Und das fachliche Verständnis 
+
+dieser Termin findet jeden Donnerstag statt und dient dazu ein gemeinsames Verständnis für anstehenden Features zu schaffen und die Features für das PI-Planning vorzubereiten.
+Um die Relevanz der Beteiligung beurteilen zu können wird es jeweils eine Agenda für diesen Termin geben.
+ | PM/POs/BAs/SAs/ ggf. Devs
+ 
+ 
+ 
+ | Vertreterbenennung erforderlich 
+Roadmap
+Themensammlung
+ | 
+
+34
+complete
+Status aktualisiert
+
+ 
+ | 
+MakSi/ BKE-Verwaltung Austausch zur Schnittstelle | alle 2 Wochen Di. 11:00 - 11:30 Uhr | Austausch zur Schnittstelle BKE-Verwaltung – KOMBau und BAKO - BKE-Verwaltung – KOMBau.
+ |  Wir besprechen jeweils neue Anforderungen und Umsetzungen zur Schnittstelle. | PM/SA/POs/BAs
+ 
+ 
+ein Dev zusätzlich aus den Teams sinnvoll? 
+ | 
+ | 
+
+35
+complete
+Status aktualisiert
+
+ | 
+Fachlicher Austausch mit Ulrich Taxen / KOMBau  | 1mal/Woche - Mi. 13:00 - 13:30 Uhr | Austausch zur KP2 | 
+
+ | Ulrich Taxen/PM/POs/BAs
+ 
+Vertretung: 
+ 
+ | 
+ | 
+
+36
+complete
+Status aktualisiert
+
+ | 
+KOMBau WS 2 und 3 KP | 1mal/Woche - Fr. 11:30 - 12:30 Uhr | Fachlicher Austausch zu KPen
+ | Bis auf weiteres gilt folgende Agenda:
+Themen 2 KP
+Themen 3 KP
+Bei Bedarf (wird vor dem Termin bekanntgegeben) Themen Netzfahrplan
+ | Ulrich Taxen/PO/BAs
+ 
+ 
+ | Confluenceseite:
+
+ | 
+
+37
+complete
+Status aktualisiert
+
+ | 
+BA Austausch | Mo-Fr 09:30 - 09:45 Uhr | Fachlicher Austausch BAs | Austausch zu neuen Anforderungen an den ART.KOM
+ | BAs
+ 
+ | 
+ | 
+
+38
+complete
+Status aktualisiert
+
+ | 
+ScM-Termine: |   |   | 
+ |  
+ | 
+ | 
+ | 
+SM/RTE Austausch & Organisation | 1mal/Woche - Mo 08:35 - 09:55 Uhr | Startschuss in die Woche
+Synchronisation und Austausch zum Wochenstart
+ | Wichtige Themen, über die wir sprechen müssen
+Blick auf Team-Sprints, Impediments, Risiken
+Wie steht es um die Teams?
+Blick auf die Termine dieser Woche
+News aus den Produktkontexten
+Blick auf die methodischen Meilensteine in dieser Woche
+News aus der Solution
+ | RTE/ScM
+ 
+ | Confluence | 
+
+39
+complete
+Status aktualisiert
+
+ | 
+SM/RTE Lernen & Helfen
+ | alle 2 Wochen Di. 14:05 - 15:55 Uhr | Austausch zum Stand unserer aktuellen Fokusthemen
+Bearbeitung unserer aktuellen Fokusthemen
+ | Agenda:
+Agile Clique & Friends: Impulsvorträge
+Agile Clique: Blick auf die Sprint Health
+
+ | RTE/ScM
+ 
+ | 
+
+ | 
+
+40
+complete
+Status aktualisiert
+
+ | 
+SM/RTE Fokusthemen | 1mal/Woche Do. 09:05 - 09:55 Uhr | Unser Termin für gemeinsames Lernen und gegenseitiges Helfen.
+ |  Gibt es neue Tickets und ist die Beschreibung vollständig? Dann werden sie vorgestellt und gemeinsam priorisiert.
+Sync zum Stand unserer aktuellen Fokusthemen (max. 5 Minuten pro Ticket, es ist KEIN Arbeitstermin)
+2.1. Gibt es Hindernisse oder Fragen?
+2.2. Wird ein Arbeitstermin zur Weiterarbeit benötigt?
+ | RTE/ScM
+ 
+ | Kanban Board | 
+
+41
+complete
+Status aktualisiert
+
+ | 
+CoP: Coaches & Tooling | alle 2 Wochen Do. 14:00 - 15:00 Uhr | Die Community of Practice richtet sich an alle, die agiles Arbeiten im Unternehmen fördern und vertiefen möchten. 
+ | halten Teilnehmende Vorträge zu interessanten und “neuen” agilen Themen.
+beraten und unterstützen wir uns bei Problemstellungen mit konkreten Lösungsvorschlägen. Diese können auch AdHoc eingebracht werden.
+ | ein Vertreter aus jedem Team
+ 
+ | iObeya Board zum Termin
+Teams-Kanal: Coaches und Tooling
+ | 
+
+42
+complete
+Status aktualisiert
+
+ |

bahn/Analyse-O2C-C2S/sources/c2s/C2S-Kommunikation/teams/Team-Pandia-Meetings-Intern.md

@@ -0,0 +1,49 @@
+# Team Pandia - Meetings (Intern)
+
+Version: 12 | Last modified: 2025-12-04T08:49:27.885+01:00
+Source: confluence page ID 256706699
+
+---
+
+Team-Event / Meeting
+ | Timeslot
+ | Remote/in Präsenz
+ | Frequenz
+ | Teilnehmer
+ | 
+Daily | Mo - Do 10:00 - 10:15 Uhr
+Fr 10:00 - 10:30 Uhr
+ | Remote | Täglich | Developer- und 
+UX Team (di. und Fr.)
+ | 
+Iteration Planning  
+ | Dienstag, (Sprintwechsel)
+13:00 bis 15:55 Uhr
+ | Remote | 2-wöchentlich | Developer- und UX Team | 
+KOMBau Sprint-Review (alle)
+ | Dienstag,
+Sprintende,
+9:00 - 10:25 Uhr
+ | Remote | 2-wöchentlich | alle Teams und Stakeholder | 
+Retrospective
+
+ | Dienstag, Sprintende,
+10:30 bis 12:00 Uhr
+ | Remote | 2-wöchentlich | Developer- und UX Team | 
+Refinement | Montags
+10:30 - 11:55 Uhr
+ | Remote | wöchentlich | Developer  Team | 
+UX-Refinement | Freitags
+10:30 - 11:30 Uhr
+ 
+ | Remote | wöchentlich | UX Team | 
+UX- Abnahmetermine | jeden zweiten Montag
+11:30 - 12:00 Uhr
+jeden zweiten Dienstag
+10:15 - 11:00 Uhr
+jeden Donnerstag
+11:00 - 11:55 Uhr
+ | Remote |   | UX Team | 
+Sprintwechsel vor Ort | Dienstag, Sprintende,
+09:00 bis 17:00 Uhr
+ | Vor Ort | einmal im Monat, wenn kein PIP stattfindet | Developer- und UX Team |

bahn/Analyse-O2C-C2S/sources/c2s/C2S-Kommunikation/teams/Team-Pandia-Wichtige-Links.md

@@ -0,0 +1,15 @@
+# Team Pandia - Wichtige Links
+
+Version: 7 | Last modified: 2025-12-04T08:50:16.128+01:00
+Source: confluence page ID 256706703
+
+---
+
+Review Unterlagen
+ariJa Board Team Pandia
+Onboarding-Checkliste
+
+In Confluence halten wir unsere Arbeitsweise und wichtige Informationen zur Arbeitsbefähigung fest und aktualisieren diese regelmäßig. →  Confluence
+In MS Teams legen wir unsere Dateien entweder im Team Pandia-Ordner oder im internen Team Pandia-Ordner ab. → Teamplace
+
+Verlinkung zu der Sammlung wichtiger Links für den ART.KOM: Sammlung wichtiger Links

bahn/Analyse-O2C-C2S/sources/c2s/C2S-Kommunikation/teams/Team-TriPoSm-á-â-Ì-á-á.md

@@ -0,0 +1,18 @@
+# Team TriPoSm ᘛ⁐̤ᕐᐷ
+
+Version: 1 | Last modified: 2026-05-20T10:37:49.810+02:00
+Source: confluence page ID 591123939
+
+---
+
+Hallo liebes Trio, liebe POs und SMs,
+lasst uns als Führungsteam diesen Bereich nutzen, um teamübergreifende Themen im ART an einem Sammelpunkt sichtbar zu machen, Inhalte und Ergebnisse aus Terminen festzuhalten und alles zu sammeln, was uns fachlich, architektonisch und methodisch temübergreifend weiterbringt.
+Die Seite soll uns dabei helfen, transparenter zusammenzuarbeiten, offene Themen frühzeitig sichtbar zu machen und den ART gemeinsam kontinuierlich weiterzuentwickeln. Sie lebt durch uns alle. Lasst uns zusammen dafür sorgen, dass hier so wenig Infos wie möglich, aber so viele wie nötig übersichtlich zusammengetragen werden. Gerne auch in Form von Verlinkungen auf andere Confluence-Seiten, dass wir keine doppelte Doku führen müssen.
+Mögliche Inhalte:
+Best Practices und gemeinsame Standards
+gemeinsame wichtigste Metriken für einen besseren Überblick
+teamübergreifende Themen
+wichtige Ergebnisse und Entscheidungen aus PO, Trio oder SM-Meetings
+Erkenntnisse aus Workshops und gemeinsamen Arbeitsthemen
+Optimierungsideen und Maßnahmen
+Ziel ist keine zusätzliche Dokumentation um der Dokumentation willen, sondern eine zentrale Stelle für Austausch, Transparenz und kontinuierliche Verbesserung als Führungsteam im ART.Â

bahn/Analyse-O2C-C2S/sources/c2s/C2S-Kommunikation/teams/Teamvereinbarungen-vom-Team-Europa.md

@@ -0,0 +1,71 @@
+# Teamvereinbarungen vom Team Europa
+
+Version: 11 | Last modified: 2026-05-13T07:40:20.043+02:00
+Source: confluence page ID 490590530
+
+---
+
+1{"header":{},"headline":{},"base":{"backgroundColor":{"color":{"light":"#f9f9ff"}},"borderRadius":{"radius":4},"border":{"width":2,"color":"#2888F8","top":true,"right":true,"bottom":true,"left":true,"style":"solid"},"size":{},"boxShadow":{"shadows":[{"color":"rgba(0, 0, 0, 0.08)","x":0,"y":1,"blur":1,"spread":0},{"color":"rgba(0, 0, 0, 0.16)","x":0,"y":1,"blur":3,"spread":1}]}},"body":{"text":{"color":"#000038","fontSize":16,"fontWeight":"normal","textAlign":"left"}}}Unser PurposeAls Shared Services Team stellen wir zentrale Komponenten bereit und betreiben sie, damit im ART.KOM andere Teams entlastet und Effizienzen gehoben werden.
+Wir bereichern den ART.KOM durch den Transfer unseres Know-Hows. (ggf. ergänzen, spezifizieren)
+Wir ergänzen die Architektur der KOMBau durch wiederverwendbare Komponenten.
+
+Werte 1. Qualität„Für uns bedeutet Qualität, dass wir richtige und zukunftsorientierte Lösungen schaffen, damit unsere Lösungen nachhaltig, wartbar, stabil und verlässlich sind.
+2. Kommunikation„Für uns bedeutet Kommunikation, dass wir Informationen und Ideen miteinander austauschen, damit Potentiale optional ausschöpfen und das Miteinander zu stärken.“
+3. Transparenz„Wir sind transparent, indem wir sagen, was ist (Hindernisse, Arbeitsfortschritt, Entscheidungen), damit wir Vertrauen, Klarheit und die Voraussetzungen für Zusammenarbeit schaffen – auch nach außen.
+4. Verbindlichkeit / Zuverlässigkeit„Für uns bedeutet Verbindlichkeit / Zuverlässigkeit, dass wir unsere Zusagen einhalten, damit sowohl im großen als auch im kleinen Rahmen Planungssicherheit besteht.
+Working Agreements (keine Reihenfolge)TransparenzWir kommunizieren regelmäßig miteinander, um einen transparenten Blick in unsere jeweilige Arbeit zu haben (Arbeitsfortschritte + Hindernisse).
+
+Wir machen Abhängigkeiten klar und dokumentieren diese an einem Ort an dem ihn alle Beteiligten sehen. 
+
+Alle Änderungen sollten am Ende vom Tag in "git" sein. 
+
+Wir aktualisieren und dokumentieren Arbeitsstände regelmäßig und zwar so, dass Notfalls ein anderer Kollege übernehmen könnte.
+
+FeedbackkulturWir gehen offen miteinander um.
+
+Wir scheuen nicht davor, uns auch mal spontan direktes und konstruktives Feedback zu geben.
+
+Wir sind mutig, Dinge anzusprechen und zu verändern.
+
+KommunikationskulturWir machen (mindestens) in der Retro unsere Kamera an. 
+
+Wir fragen nach, wenn etwas unklar ist.
+
+Wir beteiligen uns aktiv in Terminen / Diskussionen.
+
+Informationen nicht nur bekommen, sondern auch aktiv beschaffen. (Pull-Prinzip)
+
+Bei teamrelevanten Informationen, werden diese umgehend mit dem Team geteilt.
+
+"No spam in Chat" Wenn sich eine Diskussion anbahnt, wird ein themenbezogener Diskussionskanal gesucht.
+
+Ideen / Wissen werden in das Team / Projekt eingebracht und geteilt.
+
+Um produktive Arbeitsslots zu haben, dürfen wir uns auf "nicht stören" stellen. (zeitlich begrenzt, z.B. 1h)
+
+Andere Teams haben andere Prozesse. Wenn etwas unklar ist, sollten wir einfach auf kurzem Dienstweg nachfragen, ohne lange zu warten. Und die Unterschiede der Prozesse auch dem anderen Team transparent machen.
+
+Qualität + WissenstransferWir haben das Gesamtziel vor Augen und unterstützen wenn nötig andere Teams.
+Wir arbeiten qualitätsbewusst und sorgfältig. Manche Dinge benötigen Zeit, wir verlieren uns aber auch nicht im Detail.
+Wir arbeiten zukunftsorientiert und nachhaltig.
+Bei komplexen / neuen Themen, arbeiten zwei Personen zusammen. 
+Wir tauschen Erkenntnisse und Erfahrungen aus und geben auch Experimenten einen Raum, um Lernen zu fördern.
+Bei Tickets mit Unsicherheitsfaktor, Sensibilisierung im Team, während der Bearbeitung kritisch auf die ausreichende Beschreibung und AKs zu achten, im Rahmen der Bearbeitung. Die Erkenntnisse werden kommentiert und im Daily geteilt. Anschließend werden als Maßnahme ggf. Folgetickets abgeleitet oder es muss zusätzlich notwendige Arbeit als "Zwischenticket" erstellt werden, letzteres sollte eine Ausnahme sein.
+
+TeamverantwortungGrößere Änderungen / Entscheidungen werden als Team getroffen.
+Wir sind immer als Team verantwortlich und schieben Verantwortungen nicht auf eine Person (Schuldzuweisung).
+Wir vertreten nach außen eine einheitliche Teammeinung. Intern können wir diskutieren.
+
+User StoriesBeim Anlegen von User Stories erfassen wir mindestens eine kurze Beschreibung, Ausarbeitung kann später folgen.
+
+Technisches Review / Merge RequestWir nutzen Merge Requests aktiv für Wissenstransfer.
+Bei komplexeren Änderungen empfiehlt sich ein gemeinsamer Call; für kleinere Anpassungen reicht das Review im System aus.
+
+Teamreview / PO AbnahmeIst ein Ticket fertig, wird ein zeitnaher Termin vom Bearbeiter zur gemeinsamen Abnahme mit PO, + 1 Dev als erforderlich und weiteren optional ausgemacht. 
+
+TermineTermine starten um 5 nach, für ausreichend Puffer zu vorherigen Terminen.
+Auf Termine reagieren wir immer mit RSVP: Zusage oder Absage (ggf. unter Vorbehalt), niemals keine Antwort.
+
+Auf die obenstehenden Standards haben wir uns initial bei unserem Teamtag am 26.11.2025 committed. Teamtag Aqua_Europa 2025 November.pptx
+Neben den Grundstandards finden sich auf den folgenden Seiten Details und Regelungen zu weiteren wichtigen Themen wie Abwesenheiten, methodische Grundlagen, etc.
+true