Auf ein zweites Team ausweiten | kanman Dokumentation

Hat das erste Team eine Handvoll 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?

Schau dir die letzten Wochen des ersten Teams an, bevor du etwas übernimmst:

Signal	Wo du schaust	Gutes Zeichen
Änderungen bestehen die Prüfungen früh	Merge Requests, Aktivitätsprotokoll	CI grün und das unabhängige Review im ersten oder zweiten Anlauf freigegeben
Fragen werden beantwortet	Entscheidungen > Stories	Wenige Stories, die lange auf Menschen warten, kurze Antwortzeiten
Kosten sind planbar	Kostenanzeige, Team-Bericht	Die Kosten pro gemergtem Pull Request sind stabil
Reviewer vertrauen den Pull Requests	Dein Code-Review	Review-Kommentare betreffen Design, nicht fehlende Grundlagen

Kommen Änderungen oft aus dem Review zurück oder warten Stories tagelang auf Menschen, behebe 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. Stell sicher, dass das verbundene Konto die neuen Repositories erreicht.
Slack-Verbindung	Workspace	Wird wiederverwendet. Wähle im Reiter Team > Verbindungen > Chats des neuen Teams einen eigenen Channel und mit seinen Chips, was kanman dort postet.
Mitglieder und Rollen	Workspace	Werden wiederverwendet. Lade die Entwicklerinnen und Entwickler des neuen Teams unter Workspace-Einstellungen > Mitglieder ein.
Webhooks	Workspace	Gelten für alle Teams.
API-Tokens	Persönlich, je ein Workspace	Gelten für alle Teams ihres Workspaces.
Self-hosted Runner	Workspace	Von allen Teams geteilt. Prüf die Kapazität, bevor du ein Team hinzufügst.
Budget und Grenzen, Zeiten	Team	Werden nicht kopiert. Jedes Team startet mit einer eigenen Richtlinie.
Gedächtnis und Skills	Team	Werden nicht kopiert. Jedes Team führt sein eigenes; was ein Repository schon sagt, holst du mit Aus einem Repository importieren.

Schritt 1: Das Team wählen

Das beste zweite Team:

hat eine Engineering-Leitung, die es will und kanmans Fragen beantwortet
arbeitet in einem Repository mit CI und Tests
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

Stell 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

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

Gesperrte Pfade: Beginne mit der Liste des ersten Teams und ergänze, was dieses Repository besonders macht, etwa Migrationen oder generierten Code.
Budget: Beginne mit den typischen Tageskosten des ersten Teams, plus Reserve.
Merge-Freigaben: Soll im neuen Team anfangs eine Person jeden Merge freigeben, verlange das in der Branch Protection des Code-Hosts (siehe Mergen).

Schritt 4: Weitergeben, was funktioniert hat

Gedächtnis und Skills des ersten Teams werden nicht kopiert, denn jede Codebasis hat ihre eigenen Regeln. Teilen kannst du:

die Anforderungsbeispiele des ersten Teams aus Anforderungen schreiben, die kanman erledigen kann
einen kurzen Rundgang: Eine Person aus dem ersten Team zeigt dem neuen Team einen Merge Request mit seinem Review und das Aktivitätsprotokoll
den wöchentlichen Team-Bericht des ersten Teams, damit die neue Leitung weiß, wie “gut” aussieht

Schritt 5: Die ersten zwei Wochen begleiten

Lies das Review jedes der ersten zehn Merge Requests des neuen Teams.
Beantworte kanmans Fragen zügig, damit Stories nicht warten.
Vergleich nach zwei Wochen die Kosten und wie oft Änderungen aus dem Review zurückkommen mit dem ersten Team. Große Unterschiede deuten meist auf die CI des Repositorys oder auf die Art, wie Stories geschrieben sind.

Abrechnung und Grenzen

Tarife gelten pro Team, und jeder Tarif begrenzt, wie viele Runs parallel arbeiten (Starter 2, Team 5, Enterprise bis zu 20; Local führt keine Runs in der Cloud aus). Ein neues Team startet mit einer eigenen 14-tägigen Testphase des Team-Tarifs und braucht danach einen eigenen Tarif; siehe Tarife und Abrechnung. Nutzen beide Teams Self-hosted Runner, erhöhe die Runner-Kapazität, bevor das zweite Team startet.