Auf ein zweites Team ausweiten | kanman Dokumentation

Hat das erste Team eine Handvoll geprüfter Pull Requests gemergt, lautet die nächste Frage meist: Welches Team ist als Nächstes dran, und was übernehmen wir? Dieser Leitfaden ist die Checkliste für diesen Schritt.

Taugt das erste Team als Vorlage?

Schauen Sie sich die letzten Wochen des ersten Teams an, bevor Sie etwas übernehmen:

Signal	Wo Sie schauen	Gutes Zeichen
Stories erreichen Review mit Nachweis	Nachweispakete	Ergebnisnachweis vorhanden, Kriterien im ersten oder zweiten Versuch bestanden
Wenig Nacharbeit	Run-Seiten, Team-Bericht	Die meisten Runs brauchen keinen Nacharbeitsversuch
Entscheidungen werden beantwortet	Entscheidungen	Wenige lange wartende Entscheidungen, kurze Antwortzeiten
Kosten sind planbar	Kostenanzeige, Team-Bericht	Die Kosten pro gemergtem Pull Request sind stabil
Reviewer vertrauen den Pull Requests	Ihr Code-Review	Review-Kommentare betreffen Design, nicht fehlende Grundlagen

Ist Nacharbeit häufig oder warten Entscheidungen tagelang, beheben Sie das zuerst. Ein Team lässt sich leichter einstellen als zwei.

Was übernommen wird und was nicht

Element	Gültigkeit	Was zu tun ist
Verbindungen zu GitHub, GitLab und Jira	Workspace	Werden wiederverwendet. Stellen Sie sicher, dass das verbundene Konto die neuen Repositories erreicht.
Slack-Verbindung	Workspace	Wird wiederverwendet. Wählen Sie unter Einstellungen > Slack, Team-Kanäle einen eigenen Channel für das neue Team.
Mitglieder und Rollen	Workspace	Werden wiederverwendet. Laden Sie die Entwicklerinnen und Entwickler des neuen Teams unter Einstellungen > Mitglieder ein.
API-Tokens und Webhooks	Workspace	Gelten für alle Teams.
Self-hosted Runner	Workspace	Von allen Teams geteilt. Prüfen Sie die Kapazität, bevor Sie ein Team hinzufügen.
Richtlinie, Budgets, Freigaben, Arbeitszeiten	Team	Werden nicht kopiert. Jedes Team startet mit einer eigenen Richtlinie.
Akzeptanz-Manifest	Repository	Jedes Repository braucht seine eigene `.kanman/acceptance.json`.
Konventionen	Team	Werden nicht kopiert. Jedes Team lernt aus seinen eigenen Reviews.

Schritt 1: Das Team wählen

Das beste zweite Team:

hat eine Engineering-Leitung, die es will und Entscheidungen beantwortet
arbeitet in einem Repository mit CI und Tests, idealerweise mit Docker Compose startbar
hat einen stetigen Fluss kleiner, gut beschriebener Arbeit

Ein Team mitten in einer großen Migration oder ohne Testabdeckung ist ein schlechter zweiter Kandidat, auch wenn es Hilfe am dringendsten braucht.

Schritt 2: Das Repository vorbereiten

Ergänzen Sie das Akzeptanz-Manifest und nehmen Sie das des ersten Teams als Muster: Ein Akzeptanz-Manifest anlegen.
Tragen Sie .kanman/ für die Leitung des neuen Teams in CODEOWNERS ein.
Stellen Sie sicher, dass die CI für Pull Requests von kanman/*-Branches läuft und der Branch-Schutz diese Pushes erlaubt.

Schritt 3: Das Team einrichten

Legen Sie das Team mit Ein Team einrichten an. Gleichen Sie die Einstellungen dann mit den Erfahrungen des ersten Teams ab, bewusst und nicht als blinde Kopie:

Gesperrte Pfade: Beginnen Sie mit der Liste des ersten Teams und ergänzen Sie, was dieses Repository besonders macht, etwa Migrationen oder generierten Code.
Run-Budget: Beginnen Sie mit den typischen Kosten pro Run des ersten Teams, plus Reserve.
Plan-Freigabe: Bleiben Sie in der ersten Woche bei always, auch wenn das erste Team schon by_size nutzt.
Preset: Starten Sie das neue Team eine Stufe vorsichtiger, als das erste Team heute arbeitet.

Schritt 4: Weitergeben, was funktioniert hat

Die Konventionen des ersten Teams werden nicht kopiert, denn jede Codebasis hat ihre eigenen Regeln. Teilen können Sie:

die Anforderungs- und Demonstrate-Beispiele des ersten Teams aus Anforderungen schreiben, die kanman erledigen kann
einen kurzen Rundgang: Eine Person aus dem ersten Team zeigt dem neuen Team eine Run-Seite und ein Nachweispaket
den wöchentlichen Team-Bericht des ersten Teams, damit die neue Leitung weiß, wie “gut” aussieht

Schritt 5: Die ersten zwei Wochen begleiten

Lesen Sie bei den ersten zehn Stories des neuen Teams jedes Nachweispaket.
Beantworten Sie Entscheidungen zügig, damit Runs nicht warten.
Vergleichen Sie nach zwei Wochen Nacharbeit und Kosten mit dem ersten Team. Große Unterschiede deuten meist auf das Manifest oder auf die Art, wie Stories geschrieben sind.

Abrechnung und Grenzen

Tarife gelten pro Team, und jeder Tarif begrenzt, wie viele Runs parallel arbeiten (Pilot 3, Team 5, Self-hosted 20; ein Team ohne Tarif arbeitet einen Run nach dem anderen ab). Ein weiteres Team bringt ein eigenes Abonnement mit; siehe Tarife und Abrechnung. Nutzen beide Teams Self-hosted Runner, erhöhen Sie die Runner-Kapazität, bevor das zweite Team startet.