# 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.
