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.
2026-06-30 20:39:52 +02:00
parent 2f2b295531
commit a5f8fb49ab
1717 changed files with 447332 additions and 0 deletions
@@ -0,0 +1,340 @@
+# Team-Reorganisation pathOS — Optionen und Bewertung
+
+> Stand: 2026-04-30 | Status: Entwurf zur Diskussion
+
+---
+
+## 1. Ausgangslage
+
+### Aktuelle Struktur (seit PI 39)
+| Team | Personen | Verantwortung | Services |
+|------|----------|---------------|----------|
+| Team 404 | ~10 | Portal UI + Middleware | 2 Services (68K LoC) |
+| Team CIB | ~13 | Prozesse, Backend | ~15 Services (122K LoC), Camunda |
+| Team Zero | ~9 | TAF/TAP Schnittstellen | ~9 Services (38K LoC) |
+| OPs Squad | 2 fest + rotierend | Infrastruktur, Betrieb | Infra-Repos, Deployment |
+| DevOps | ~7 | CI/CD, Tooling | Pipelines, Helm, Monitoring |
+| BSSUPPORT | ? | 2nd Level Support | — |
+
+### Probleme der aktuellen Struktur
+1. **SPOF**: Jan Lubenow (39% DevOps), Steven Meixner (Zero + OPs)
+2. **Ungleiche Last**: CIB hat 15 Services + Camunda + Abrechnung, Zero hat 9 Services aber rotiert staendig in OPs
+3. **Bug-Qualitaet**: 404 hat 33% Bug-Rate — systematisches Problem, nicht personenbezogen
+4. **OPs-Rotation belastet Zero**: 3 von 5 Rotatoren kommen aus Zero
+5. **Abhaengigkeiten**: CIB braucht 404 fuer Portal-Features, Zero braucht CIB fuer Prozess-Aenderungen
+6. **Kein klarer Feature-Owner**: Wer ist verantwortlich fuer ein Feature das Portal + Backend + Schnittstelle braucht?
+
+---
+
+## 2. Ziele der Reorganisation
+
+### Primaere Ziele
+- Schnelle Umsetzungsgeschwindigkeit
+- Weniger Komplexitaet
+- Weniger Abhaengigkeiten zwischen Teams
+- Bessere Qualitaet
+- Bessere Verantwortlichkeit (Ownership)
+
+### Nachrangige Ziele
+- Entwickler, BAs, POs, Scrummaster/TeamCoaches staerkenorientiert einsetzen
+- Wissen breiter verteilen (SPOF abbauen)
+- Flexibilitaet bei wechselnden Prioritaeten
+
+---
+
+## 3. Option A: OpsDev + Feature-Pool
+
+### Modell
+```
+┌─────────────────────────────────────────────────────────┐
+│  OpsDev Team (permanent, ~8-10 Personen)                │
+│  Lead: OpsDev-Lead (kein PO)                            │
+│  Aufgaben: Betrieb, Bugs, kleine Features, Monitoring   │
+│  Besetzung: 2 feste Ops + rotierende Devs aus Pool      │
+└─────────────────────────────────────────────────────────┘
+
+┌─────────────────────────────────────────────────────────┐
+│  Feature-Pool (~20-25 Personen)                         │
+│  Entwickler + BAs + Feature-POs                         │
+│                                                         │
+│  ┌──────────┐  ┌──────────┐  ┌──────────┐              │
+│  │Feature A │  │Feature B │  │Feature C │  ...          │
+│  │3-5 Pers. │  │3-5 Pers. │  │3-5 Pers. │              │
+│  │PO + Devs │  │PO + Devs │  │PO + Devs │              │
+│  └──────────┘  └──────────┘  └──────────┘              │
+│                                                         │
+│  Nach Feature-Abschluss: 1 Dev → OpsDev (Hypercare)     │
+└─────────────────────────────────────────────────────────┘
+```
+
+### Vorteile
+- **Klare Verantwortung**: Feature-Team ownt das Feature end-to-end (Portal + Backend + Schnittstelle)
+- **Keine Cross-Team-Abhaengigkeiten** fuer Features: Ein Team macht alles
+- **Flexibilitaet**: Pool kann nach Prioritaet umgeschichtet werden
+- **Wissenstransfer**: Hypercare-Phase zwingt Feature-Devs in den Betrieb
+- **Qualitaet**: Wer baut, betreibt (You build it, you run it — zeitversetzt)
+
+### Nachteile
+- **Kontextwechsel**: Entwickler muessen mehrere Services kennen (Portal + Backend + CI)
+- **Onboarding-Aufwand**: Jedes Feature-Team braucht Einarbeitung in fremde Codebasis
+- **Kein stabiles Team**: Teambildung leidet wenn Teams staendig neu zusammengesetzt werden
+- **OpsDev wird Muellhalde**: Alle Bugs landen dort, kein Ownership fuer Ursachenbekaempfung
+- **PO-Overhead**: Jedes Feature braucht einen PO — bei 3-4 parallelen Features braucht man 3-4 POs
+- **Risiko**: Wenn Feature-Teams aufgeloest werden, geht Wissen verloren
+
+### Bewertung gegenueber Zielen
+| Ziel | Bewertung | Begruendung |
+|------|-----------|-------------|
+| Geschwindigkeit | ⭐⭐⭐⭐ | Feature-Teams koennen autonom liefern |
+| Weniger Komplexitaet | ⭐⭐ | Pool-Management ist selbst komplex |
+| Weniger Abhaengigkeiten | ⭐⭐⭐⭐⭐ | Feature-Team hat alles was es braucht |
+| Bessere Qualitaet | ⭐⭐⭐ | Hypercare hilft, aber kein langfristiger Code-Owner |
+| Bessere Verantwortlichkeit | ⭐⭐⭐ | Gut fuer Features, schlecht fuer langfristige Service-Pflege |
+
+---
+
+## 4. Option B: Fachlicher Schnitt in 2 Teams
+
+### Moegliche Schnitte
+
+#### B1: Bestellung vs. Abwicklung
+
+```
+Team "Bestellen"                    Team "Abwickeln"
+─────────────────                   ─────────────────
+Portal UI + MW                      Steuerung Vertrieb (Camunda)
+Common Interface (Eingang)          Auftrags-Verwaltung
+Stammdaten-Bereitstellung           IFP-Connector
+Kundendaten-Bereitstellung          Vertragsdaten-Verteiler
+TAF/TAP-TDM-Konverter              Archivierungsservice
+                                    Abrechnung/AC-Anbindung
+
+Fokus: Alles was der Kunde          Fokus: Alles was nach der
+sieht und eingibt                   Bestellung passiert
+```
+
+**Vorteile B1:**
+- Klarer Kundenfokus im Team "Bestellen" (Portal + Schnittstelle = Kundenkontakt)
+- Team "Abwickeln" kann sich auf Prozess-Korrektheit konzentrieren (Camunda, Abrechnung)
+- Natuerliche Grenze: Bestellung ist abgeschickt → Uebergabe an Abwicklung
+
+**Nachteile B1:**
+- SV (93K LoC, 2214 Smells) ist ein Monolith — schwer zu teilen
+- Aenderungswesen (NAÄ) betrifft BEIDE Teams (Kunde bekommt Aenderung UND Prozess muss reagieren)
+- Team "Bestellen" hat Portal + CI + Stammdaten — sehr heterogener Tech-Stack (Angular + Java + SOAP)
+
+#### B2: Netzfahrplan vs. Gelegenheitsverkehr
+
+```
+Team "Netzfahrplan"                 Team "GelV + ujBau"
+─────────────────                   ─────────────────
+NEP1/NEP2 Prozesse                  Gelegenheitsverkehr
+Langfristige Bestellungen           Click&Ride
+Koordinierungsverfahren             ujBau (Baufahrplan)
+Kapazitaetsmanagement               Ad-hoc Verkehre
+                                    Kurzfristige Aenderungen
+```
+
+**Vorteile B2:**
+- Fachlich sauberer Schnitt (unterschiedliche Fristen, Prozesse, Kunden)
+- GelV hat andere Anforderungen (Geschwindigkeit) als Netzfahrplan (Korrektheit)
+- Passt zu den TTT-Meilensteinen (NEP2 vs. GelV sind separate Streams)
+
+**Nachteile B2:**
+- Technisch teilen sich beide denselben Code (SV, Portal, CI) — kein sauberer Service-Schnitt
+- Kleine Features betreffen oft beide Bereiche
+- GelV-Team waere deutlich kleiner (weniger Volumen)
+- NAÄ und Abrechnung betreffen beide
+
+#### B3: Extern (Kundenschnittstelle) vs. Intern (Prozesse)
+
+```
+Team "Aussen" (Kundenkontakt)      Team "Innen" (Prozesse)
+─────────────────                   ─────────────────
+Portal UI + MW                      Steuerung Vertrieb
+Common Interface                    Auftrags-Verwaltung
+Click&Ride                          IFP-Connector
+Stammdaten (fuer Kunden)            Vertragsdaten-Verteiler
+BSSUPPORT (2nd Level)               Archivierungsservice
+                                    Monitoring/Alerting
+
+Fokus: Alles was Kunden             Fokus: Alles was intern
+sehen und nutzen                    verarbeitet wird
+```
+
+**Vorteile B3:**
+- Aehnlich wie B1, aber mit Support integriert → schnellere Bug-Behebung
+- Team "Aussen" kann Kundenfeedback direkt umsetzen
+- Team "Innen" kann sich auf Korrektheit und Performance konzentrieren
+
+**Nachteile B3:**
+- Gleiche Probleme wie B1 (NAÄ betrifft beide, SV ist Monolith)
+- Support im Team "Aussen" bindet Kapazitaet
+
+#### B4: Domäne "Trasse" vs. Domäne "Vertrag"
+
+```
+Team "Trasse"                       Team "Vertrag"
+─────────────────                   ─────────────────
+Trassenanmeldung (Portal+CI)        Angebot + Vertrag (SV)
+Trassenkonstruktion (IFP)           Abrechnung
+Stammdaten                          Stornierung
+TAF/TAP Konvertierung               Rahmenvertraege
+                                    Vertragsdaten-Verteiler
+
+Fokus: Vom Kundenwunsch             Fokus: Vom Angebot bis
+bis zum Konstruktionsauftrag        zur Rechnung
+```
+
+**Vorteile B4:**
+- Sauberster fachlicher Schnitt entlang des Geschaeftsprozesses
+- Klare Uebergabe: Trasse ist konstruiert → Vertrag wird erstellt
+- Abrechnung (das groesste Risiko) hat ein dediziertes Team
+- Passt zur INB-Struktur (Bestellung vs. Entgelt)
+
+**Nachteile B4:**
+- SV muesste aufgeteilt werden (Bestelleingang vs. Vertragsabschluss) — technisch schwierig
+- Portal zeigt sowohl Bestellungen als auch Vertraege — wo gehoert es hin?
+- Aenderungswesen (NAÄ) ist ein Querschnittsthema
+
+---
+
+## 5. Option C: Hybridmodell (OpsDev + 2 fachliche Teams)
+
+### Modell
+```
+┌─────────────────────────────────────────────────────────┐
+│  OpsDev Team (~6 Personen, permanent)                   │
+│  Lead: OpsDev-Lead                                      │
+│  Betrieb, Deployment, Monitoring, Infrastruktur         │
+│  Bug-Triage (weist Bugs an fachliche Teams zu)          │
+└─────────────────────────────────────────────────────────┘
+
+┌──────────────────────────┐  ┌──────────────────────────┐
+│  Team "Bestellen"        │  │  Team "Verarbeiten"      │
+│  ~12 Personen            │  │  ~12 Personen            │
+│  PO + BA + Devs          │  │  PO + BA + Devs          │
+│                          │  │                          │
+│  Portal UI + MW          │  │  Steuerung Vertrieb      │
+│  Common Interface        │  │  Auftrags-Verwaltung     │
+│  Stammdaten              │  │  IFP-Connector           │
+│  Kundendaten             │  │  Archivierung            │
+│  TAF/TAP Konverter       │  │  Vertragsdaten           │
+│  Click&Ride              │  │  Abrechnung              │
+│                          │  │  Rabattnummern           │
+│  Bugs: Portal, CI, STB   │  │  Bugs: SV, AV, IFP      │
+└──────────────────────────┘  └──────────────────────────┘
+```
+
+### Vorteile
+- **Klare Ownership**: Jedes Team ownt seine Services dauerhaft (kein Wissensverlust)
+- **OpsDev entlastet**: Fachliche Teams fixen ihre eigenen Bugs, OpsDev nur Infrastruktur
+- **Fachlicher Schnitt**: "Bestellen" = Kundenkontakt, "Verarbeiten" = Backend-Prozesse
+- **Stabile Teams**: Teambildung moeglich, Wissen bleibt
+- **Skalierbar**: Bei Bedarf kann ein drittes Team abgespalten werden
+
+### Nachteile
+- **NAÄ/Aenderungswesen**: Betrifft beide Teams — braucht Abstimmung
+- **Portal zeigt Vertragsdaten**: Team "Bestellen" muss fuer Anzeige auf Team "Verarbeiten" warten
+- **SV bleibt Monolith**: Gehoert komplett zu "Verarbeiten" — dort konzentriert sich die Komplexitaet
+
+### Bewertung gegenueber Zielen
+| Ziel | Bewertung | Begruendung |
+|------|-----------|-------------|
+| Geschwindigkeit | ⭐⭐⭐⭐ | Zwei autonome Teams + OpsDev |
+| Weniger Komplexitaet | ⭐⭐⭐⭐ | Klare Zustaendigkeiten, weniger Koordination |
+| Weniger Abhaengigkeiten | ⭐⭐⭐ | Besser als heute, aber NAÄ bleibt Querschnitt |
+| Bessere Qualitaet | ⭐⭐⭐⭐ | Ownership = Verantwortung fuer Qualitaet |
+| Bessere Verantwortlichkeit | ⭐⭐⭐⭐⭐ | Jeder Service hat genau ein Team |
+
+---
+
+## 6. Option D: Spotify-Modell (Squads + Chapters + Guild)
+
+### Modell
+- **Squads** (3-4): Feature-orientiert, temporaer zusammengesetzt
+- **Chapters**: Fachliche Heimat (Frontend, Backend, QA, Ops)
+- **Guild**: Uebergreifende Themen (Security, Performance, Architektur)
+
+### Bewertung
+Fuer pathOS mit ~35 Personen ist das Spotify-Modell **zu komplex**. Es lohnt sich erst ab 50+ Personen. Die Overhead-Kosten (Chapter Leads, Guild Meetings) ueberwiegen den Nutzen.
+
+**Nicht empfohlen.**
+
+---
+
+## 7. Gesamtbewertung
+
+| Option | Geschwindigkeit | Komplexitaet | Abhaengigkeiten | Qualitaet | Ownership | Empfehlung |
+|--------|----------------|--------------|-----------------|-----------|-----------|------------|
+| **A: OpsDev + Pool** | ⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | Gut fuer Feature-Sprints, schlecht fuer Langfrist |
+| **B1: Bestellen/Abwickeln** | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | Solide, aber NAÄ-Problem |
+| **B4: Trasse/Vertrag** | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | Bester fachlicher Schnitt |
+| **C: Hybrid (OpsDev + 2)** | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | **Empfohlen** |
+| D: Spotify | ⭐⭐⭐ | ⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | Zu komplex fuer 35 Personen |
+
+### Empfehlung: Option C (Hybrid) mit Elementen aus A
+
+**Kernstruktur**: OpsDev (permanent) + 2 fachliche Teams (permanent)
+**Element aus A**: Fuer grosse Features (GelV, ujBau) temporaer 2-3 Personen aus beiden Teams zusammenziehen → nach Abschluss zurueck + 1 Person in Hypercare
+
+---
+
+## 8. Hinweise fuer weiteren Research
+
+### Zu klaeren
+1. **SV aufteilen?** — Ist der Monolith (93K LoC) technisch teilbar? Oder muss ein Team ihn komplett ownen?
+2. **NAÄ als Querschnitt** — Braucht es ein dediziertes "NAÄ-Feature-Team" (temporaer) oder eine feste Zuordnung?
+3. **Portal-Ownership** — Portal zeigt Daten aus allen Services. Gehoert es zu "Bestellen" oder ist es ein eigener Querschnitt?
+4. **Abrechnung** — Ist AC Trasse ein eigenes Team wert? Oder bleibt es bei "Verarbeiten"?
+5. **Personelle Passung** — Wer kann/will wohin? Staerken-Mapping der 35 Personen.
+6. **Uebergangsphase** — Wie lange dauert die Umstellung? Produktivitaetsverlust waehrend Transition?
+7. **PO-Struktur** — 1 PO pro Team oder 1 uebergreifender PO + Feature-POs?
+8. **Metriken** — Wie messen wir ob die Reorg erfolgreich war? (Bug-Rate, Durchlaufzeit, Deployment-Frequenz)
+
+### Daten die noch fehlen
+- Git-Contributions pro Person/Service (wer kennt welchen Code?)
+- Abhaengigkeits-Graph zwischen Services (Kafka-Topics, REST-Calls)
+- Kundenfeedback: Welche Features werden am meisten nachgefragt?
+- Camunda-Prozess-Instanzen: Wie oft laeuft welcher Prozess?
+
+
+---
+
+## 9. Faktor TrassenOrder (Team TraPo)
+
+### Was ist TrassenOrder?
+- **Neues Produkt** innerhalb SAB (gleiche Einheit wie pathOS)
+- **Zweck**: Modernisiert den Bestellprozess fuer Gelegenheitsverkehr — medienbruchfreier Workflow
+- **Entwicklungsstart**: Januar 2026
+- **Livegang**: voraussichtlich Q4 2026
+- **Phase**: EXPLORE
+- **Team**: TraPo (eigenes Team in SAB)
+- **Jira**: TRAPO-Projekt (systelone)
+
+### Ueberschneidung mit pathOS
+- pathOS hat bereits **Click&Ride** (Anlage 4.2.2 INB) fuer kurzfristigen GelV
+- ADR-72 (Click&Ride Anbindung) ist ein aktives CIB-Thema
+- GelV-Erweiterungen sind ein TTT-Meilenstein (ab Sep 2026)
+- TrassenOrder adressiert denselben Bereich — aber als separates Produkt
+
+### Implikationen fuer die Reorganisation
+
+**Fragen die geklaert werden muessen:**
+1. **Abgrenzung**: Was macht TrassenOrder, was macht pathOS/Click&Ride? Gibt es eine klare Grenze oder Ueberlappung?
+2. **Integration**: Wird TrassenOrder ein Frontend fuer pathOS-Backend? Oder ein komplett separates System?
+3. **Team-Zuordnung**: Gehoert GelV kuenftig zu TraPo oder zu pathOS? Oder beides?
+4. **Schnittstelle**: Braucht pathOS eine API fuer TrassenOrder? Wer baut/pflegt die?
+5. **Kannibalisierung**: Ersetzt TrassenOrder langfristig Click&Ride?
+
+**Auswirkung auf Optionen:**
+- **Option A (Pool)**: TrassenOrder-Devs koennten Teil des Pools sein
+- **Option B (2 Teams)**: GelV-Schnitt (B2) wird fragwuerdig wenn TrassenOrder GelV uebernimmt
+- **Option C (Hybrid)**: Team "Bestellen" muesste Schnittstelle zu TrassenOrder definieren
+- **Generell**: Wenn TrassenOrder den GelV-Bereich uebernimmt, kann sich pathOS auf Netzfahrplan + ujBau konzentrieren — das vereinfacht den fachlichen Schnitt erheblich
+
+### Empfehlung
+Vor der Reorg-Entscheidung **unbedingt mit TraPo-Team abstimmen**:
+- Roadmap-Abgleich (was baut wer bis wann?)
+- Schnittstellen-Definition (API-Vertrag zwischen pathOS und TrassenOrder)
+- Langfristige Vision: Ein System oder zwei?