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.
4.9 KiB
Team FaMe / Team Fuse - Zusammenarbeitsregeln - final
Version: 24 | Last modified: 2026-02-27T11:08:57.453+01:00 Source: confluence page ID 553962107
link10#e2e2e2200coverflex-startcenter center Zusammenarbeitsregeln erarbeitet am 25.02.2026 mit jeweils 4 mandatierten Vertretern pro Team. Ãberprüfung und Anpassung der Ergebnisse kontinuierlich bei Bedarf, spätestens nach 6 Monaten.Â
link10#d0d0d0900coverflex-startcenter centerKommunikation/MeetingsFür die Abstimmungsthemen existiert ein Teams-Chat für die beiden Teams. Zusätzlich gibt es einen Sync-Termin zwischen den BEs beider Teams (Montag 10-10.30, 2-wöchentlich in der Refinement-Woche) "Planning 3" mit ausgewählten Teamvertretern aus beiden Teams (Prüfung von ggf. kollidierenden Themen für den kommenden Sprint) - Mittwoch, Sprintwechselwoche 13.00 Uhr - 15 Min. RegelmäÃiges, kurzes wöchentliches Meeting, 15 Min., mit harter Timebox und Agenda (Dev-Runde FaMe/Fuse) - Mi-Vormittag (11.30)Inhalte/Themen:Abstimmung von Abhängigkeiten Prüfung der Themen auf Konfliktpotenziale (wird z.B. an gleichen Modulen oder Codestellen gearbeitet) Abstimmung möglicher Breaking Changes
Umsetzen/TestingBreaking Changes (API) sind abzustimmen und möglichst Teamübergreifend in den Iterationen zu sammeln und gemeinsam an Team Flux zu kommunizieren Die umgesetzten Features sollen auch Qualitätsgesichert werdenUnittestabdeckung soll das aktuelle Niveau von mind. 90 % halten Thunderclienttests sollen bedarfsabhängig erstellt werden (lokal auszuführen)
Vor dem Merge in den Main müssen alle Tests erfolgreich durchgelaufen sein Fuse und FaMe halten sich an die Coding Guidlines (falls vorhanden) & Architekturrichtlinien (z.B. modulare Struktur) Die Arbeiten finden in dem Repository in der C2S (SIC OP) Gruppe statt Technische Entscheidungen werden in kurzen ADRs dokumentiert (Decision, Kontext, Optionen, Impact). link10#d0d0d0900coverflex-startcenter centerAbnahme/Review/DokuDie MRs von Fuse bzw. FaMe werden im jeweiligen Team gereviewed und freigegeben. Nur bei konkreter Anfrage schaut das andere Team mit drauf. Technische und Fachliche Doku ist pro Story/Feature zeitnah, bis zur Abnahme des betreffenden Features, zu erstellen Möglichkeit zur gegenseitigen Teilnahme an den Reviews von Fuse bzw. FaMeaktuelle Slots ... Team FaMe - Sprintwechsel-Woche Dienstag 9-10 Uhr ... Team Fuse 10.30 - 11.30 Uhr sind konfliktfrei Â
Die DoD/DoR Kriterien beider Teams wurden von den BEs beider Teams verglichen und es wurde eine einheitliche Linie definiert. Spezialregeln ...Git-Repo / Umgang mit Merge-KonfliktenTests müssen grün durchlaufen
Jedes Team macht selbstständig Reviews
Vorhergehende Absprachen sollten die Konflikte insgesamt reduzieren
Deployment-RegelnFertige Storys direkt bis INT ausrollen (bei Freeze bis IEU)
Sync-Chat nutzen bei koordinierten Rollouts
Alignment mit Release-Prozess (Team BEAT)
Hot FixesTransparenz über aktuelle Situation in beiden Teams herstellen über entsprechende Posts
Finger weg von Main-Umgebung für alle Devs, die nicht am Fix arbeiten
Gemeinsames Arbeiten am Fix im "virtuellen Büro" - z.B. über den Teams-Chat
Umfassende Code-ÃnderungenVorherige Abstimmung mit dem anderen Team, um Effekte/Auswirkungen zu verdeutlichen und ggf. MaÃnahmen ableiten
Deep-Dive nach Review bei Bedarf
Doku zeitnah, bis spätestens zur Featureabnahme, glattziehen
 link10#d0d0d0900coverflex-startcenter center Ownership Beide Teams dürfen alle Bereiche ändern; Verantwortungen sind klar definiert. Unsicherheiten werden in den Regelterminen abgestimmt. Repo-Struktur und DomänenschnitteModularer Zuschnitt (Ordner/Packages) Monorepo-Policies (keine zirkulären Abhängigkeiten, interne APIs statt Querschnitten).
CI/CD und âStop-the-lineâDie Absprache zu Pipeline-Phasen und Ownership (wer pflegt welche Jobs?) erfolgt in den gemeinsamen Regelterminen. âAlways green mainâ: bei Rot sofort stoppen und fixen; Rotation âBuild Sheriffâ ist als Standard definiert. Artifact Management (Registry, Retention), Wiederholbarkeit (Deterministic Builds), wird durch die SIC OP Pipelines gelöst. Deployment-Policies: Wenn DoD erfolgt ist, weitere Prozessierung
ReleaseDeployments werden untereinander abgestimmt OPS-ThemenVerantwortlichkeit für Security/Renovate-Themen und Findings rollierend pro PI. Beginnend mit PI 40 und Team Fuse. Sollte Unterstützung notwendig sein, kann diese beim jeweils anderen Team angefragt werden. Naming ConventionsKeine "Naming-Conventions", Einzelfallentscheidungen, die in den Austauschrunden geklärt werden Eskalationen/EntscheidungenLetztinstanzlich liegen Entscheidungen zum KDS beim PO von Team FaMe. Grundsätzliche können Entscheidungen auf Arbeitsebene getroffen werden. Kommt es zum Konflikt wird das Thema zwischen den POs der beiden Teams diskutiert.