Orchestrator/bahn/project-audit/analysis/iteration-03-team-workflow.md

# Iteration 03 — Team & Workflow Analyse

> Stand: 2026-04-22 | Quellen: Runbook, Confluence, GitLab-Berechtigungen

---

## 1. Team-Struktur (IST)

### Entwicklungsteams

**ACHTUNG: Seit PI 39 neue Struktur! STeam wurde aufgeloest.**

| Team | Subdomaene | Kern-Verantwortung | Aenderung PI 39 |
|------|-----------|-------------------|----------------|
| **Team Zero** | TAF/TAP Schnittstellen | Common Interface, Stammdaten, TAF/TAP-TDM-Konverter | Unveraendert + OPs-Anteil |
| **Team 404** | Bestellportal | Portal UI (Angular), Portal Middleware | Unveraendert + OPs-Anteil |
| **Team CIB** | Prozesse + Backend | Steuerung Vertrieb (Camunda), Auftrags-Verwaltung, IFP-Connector | Unveraendert + OPs-Anteil |
| **~~Team STeam~~** | ~~Infrastruktur~~ | ~~CI/CD, Deployment, Keycloak, Monitoring~~ | **AUFGELOEST seit PI 39** |
| **Team OPs (NEU)** | Infrastruktur / DevOps | CI/CD, Deployment, Monitoring, Security | 2 feste + rotierende Mitglieder aus allen Teams |
| **Team BSSUPPORT (SuBP)** | Support | 2nd Level Support | Unveraendert |
| **Team FbF** | Fachliche Betriebsfuehrung | Fachlicher Betrieb, Konfiguration | Unveraendert |

> **Wichtig**: Die STeam-Aufgaben (47 Infra-Projekte) wurden auf die Entwicklungsteams verteilt. Das OPs-Team hat nur 2 feste Mitglieder und wird durch rotierende Mitglieder aus allen Teams bestueckt. Details zur Verteilung muessen aus Jira (O2CBS, PI 39+) verifiziert werden.

### Uebergreifende Rollen (aus Confluence)

| Rolle | Funktion |
|-------|---------|
| Produktmanagement (PM) | Strategische Produktsteuerung |
| Product Owner (PO) | Pro Team, fachliche Priorisierung |
| Systemarchitekt | Architekturentscheidungen, ADRs |
| Release Train Engineer (RTE) | SAFe-Koordination, PI-Planung |
| QA-Lead / Testmanager | Teststrategie, Testkoordination |
| Scrum Master | Pro Team, Prozessbegleitung |
| Business Engineer | Fachliche Anforderungen |

### Hinweis aus Runbook
> "Es gibt keine 1:1 Entsprechung zwischen den Entwickler-Teams und Domaenen. Ein Grund ist der Wunsch nach einer ausgewogenen Auslastung der Teams."

## 2. Team-zu-Projekt-Mapping

### Team Zero (TAF/TAP Schnittstellen)
**Projekte (geschaetzt basierend auf Subdomaene):**
- apps/common-interface
- apps/stammdaten-bereitstellung
- apps/taftap-tdm-konverter
- apps/tbv-absicherung-konverter
- apis/taftap, apis/data-model, apis/stammdatenEVU, apis/stammdatenPMW
- apis/versandauftrag, apis/versandergebnis, apis/eingangsnachricht
- mocks/bep-mock, mocks/im-mock
- docs/taf-tap-schemas

### Team 404 (Bestellportal)
**Projekte:**
- apps/portal-ui
- apps/portal-middleware
- apis/portal
- apis/auftraege

### Team CIB (Prozesse + Backend)
**Projekte:**
- apps/steuerung-vertrieb
- apps/auftrags-verwaltung-trasse
- apps/Auftrag-Service (NEU, erstellt 19.04.2026!)
- apps/ifp-connector
- apps/kundendaten-bereitstellung
- apps/rabattnummern-bereitstellung
- apps/vertragsdaten-verteiler
- apps/archivierungsservice
- apps/tadef-connector
- apis/auftragsverwaltung, apis/trassenanmeldung, apis/produktionsauftrag
- apis/kundendaten, apis/event-model, apis/camunda-events

### Team STeam (Infrastruktur)
**Projekte (47 infra/ + diverse):**
- infra/bestellsystem-deployment (ZENTRAL)
- infra/bestellsystem-application (Helm Chart)
- infra/ci-files
- infra/Keycloak* (5+ Projekte)
- infra/Database Setup, Kafka Topic Setup, C8 Backup
- infra/staging, infra/testing
- infra/renovate-exec
- infra/infrastruktur-scripte, infrastruktur-basis-container
- infra/fortify-util, token-check, token-rotation
- infra/deployment-sonarqube, deployment-kafka-ui
- tools/camunda-client, kafka-message-replay
- docs/Runbook, docs/installierte-versionen

### Team BSSUPPORT
**Projekte:**
- Primaer Jira-Tickets (BSSUPPORT-Projekt)
- Kein eigenes GitLab-Repo

## 3. Regeltermine und Kommunikation

### ART-Ebene (woechentlich/zweiwoechentlich)
| Termin | Rhythmus | Teilnehmer |
|--------|---------|------------|
| pathOS Product Sync | Woechentlich, Do 10-11 | PM, PO, Architekt, QA-Lead, RTE, FBF |
| PO/PM Sync | Woechentlich, Di | PO, PM, TaskForce |
| BS Trio Sync | Woechentlich, Mi 10-10:45 | RTE, PM, Architekt |
| Trio + Fachbereich | Woechentlich, Mi 10:45-11 | + FBF |
| System Demo | Zweiwoechentlich, Di 11-12 | Alle Teams + Stakeholder |
| Architekturrunde | Zweiwoechentlich, Fr 11-12 | Vertreter aller Teams + Architekt |
| CI/CD Jour Fixe | Zweiwoechentlich, Mo 14-15 | Vertreter aller Teams + Architekt |
| Testing Jour Fixe | Zweiwoechentlich, Mo 14-15 | Testmanager, Tester aller Teams |
| DevOps CoP | Zweiwoechentlich, Mi 13-14 | Entwickler (offen) |

### Team-Ebene (pro Team)
- Daily (taeglich, 15 Min)
- Sprint Planning (zweiwoechentlich)
- Refinement (zweiwoechentlich)
- Sprint Review (zweiwoechentlich)
- Sprint Retro (zweiwoechentlich)
- Test Jour Fixe (zweiwoechentlich)

## 4. Release- und Deployment-Workflow

### Umgebungs-Pipeline (17+ Umgebungen)
```
DEV Stage:
  BU (Build) → EU (Review) → BASE-AT (Integrationstest)
  → IEU (Integrierte Entwicklung, auto-deploy bei Master-Merge)
  → SIT (Systemintegration mit TPN)
  → SIT2 (automatisierte SIT)
  → LUP (Last & Performance)

ABN Stage (TTT-abgestimmt):
  E2E (TTT-ITU1) → SAT1 (Alarm ITU) → SAT2 (Release ITU)
  → ABN1 (TTT-KTU, Kundentests) → ABN2 (Release ABN)
  → ABN4 (Alarm-Patches) → ABN8 (EVU-Tests)
  → PREPROD (Sondertests mit Fahrplan-IT)

PROD Stage:
  PROD (Produktionsumgebung)
```

### Release-Prozess
- **BS-Release** = Bundle aus Microservice-Versionen (z.B. R23.12.00)
- **App-Release** = Einzelner Microservice (Semantic Versioning)
- **Hotfix** = Aus Release-Tag, eigener Branch, Merge zurueck in Master
- **Staging**: DEV → ABN → PROD (mit TTT-Abstimmung)
- **Deployment-Verantwortung**: Rollierend, 1 PO pro Sprint (seit 06/2025)
- **Kommunikation**: MS Teams Kanal "pathOS Release"
- **Dokumentation**: Confluence-Seite pro BS-Release mit Checkliste

## 5. Identifizierte Engpaesse

### E1: Deployment-Bottleneck (KRITISCH)
- 17+ Umgebungen, jede mit eigenem Setup
- Deployment auf TTT-Umgebungen erfordert Abstimmung mit externem TTT-Releasemanagement
- Manuelle Orchestrierung ueber MS Teams
- Kein automatisierter Smoketest nach Deployment (erst seit 03/2026 in Arbeit)
- bestellsystem-deployment Repo ist ZENTRAL und komplex (Smarty 61%, Python 35%, Shell 4%)

### E2: Team STeam als Single Point of Failure (HOCH)
- STeam verantwortet 47 Infra-Projekte
- Keycloak, Deployment, CI/CD, Monitoring, Security, Artifactory, CNP — alles bei einem Team
- DevOps-Wissenstransfer an andere Teams erst seit 02/2025 aktiv
- Rufbereitschaft soll von STeam + Ben/Harram gestellt werden

### E3: Cross-Team Dependencies (HOCH)
- Schnittstellenaenderungen zwischen Teams erfordern Koordination (z.B. SV-API aendert sich → 404 und Zero muessen nachziehen)
- Kein Contract Testing (ADR-50 war geplant, wurde als "Obsolet" markiert)
- 10+ interne APIs mit eigenen Versionen

### E4: TTT-Abhaengigkeit (MITTEL)
- Releases muessen mit TTT-Releasemanagement abgestimmt werden
- Eigene Umgebungen (SAT1, SAT2, ABN1, ABN2) fuer TTT-Integration
- TPN-Anbindung ueber Kafka erfordert Umgebungsverschaltung

### E5: Wissenskonzentration (MITTEL)
- Runbook Kap. 8.36 listet umfangreichen DevOps-Wissensbedarf
- "Meist schlafen reine Betriebler schlecht" — Zitat aus Runbook
- Ziel: "You build it, you run it" — aber noch nicht erreicht

## 6. Reorganisations-Empfehlungen

### Kurzfristig (naechste PIs)
1. **DevOps-Wissen verteilen**: Jedes Team sollte mindestens 2 Personen mit Deployment-Faehigkeit haben
2. **Deployment-Automatisierung**: Smoketests nach jedem Deployment automatisieren
3. **Release-Checkliste digitalisieren**: Confluence-Checkliste in Pipeline integrieren

### Mittelfristig (2-3 PIs)
4. **Infra-Verantwortung aufteilen**: Teams uebernehmen Infra fuer ihre eigenen Services (STeam wird Enabler statt Bottleneck)
5. **Contract Testing einfuehren**: Pact oder aehnliches zwischen den Teams
6. **Umgebungen reduzieren**: 17+ ist zu viel. Pruefen ob SAT1/SAT2/SAT3 konsolidiert werden koennen

### Langfristig (6+ Monate)
7. **Team-Schnitt an Subdomaenen ausrichten**: Klare Ownership pro Bounded Context
8. **Platform Team**: STeam wird zum Platform Team das Self-Service-Tools bereitstellt
9. **TTT-Entkopplung**: Eigene E2E-Tests die TTT-Abhaengigkeit reduzieren