Ein Team einrichten
Die Team-Einrichtung Schritt für Schritt: Tracker wählen, Projekt und Repositories benennen, die Ausführung festlegen, das Team gestalten und Spalten und Probelauf prüfen.
Ein Team ist der Ort, an dem kanman mit deinen Entwicklerinnen und Entwicklern arbeitet. Es ist an ein Tracker-Projekt und ein oder mehrere Repositories gebunden und hat eine eigene Richtlinie, ein eigenes Budget und ein eigenes Board. Die meisten Unternehmen beginnen mit einem Team pro Produkt oder Service. Diese Seite führt durch die Einrichtung.
Rechne bei einem typischen Repository mit etwa 20 Minuten. Inhaber, Admins und Mitglieder des Workspace können ein Team einrichten; Betrachter nicht, ihnen sagt kanman, wer es kann. Schlägt beim Anlegen etwas fehl, bleibt nichts zurück: Deine Angaben bleiben in der Einrichtung erhalten und du kannst es noch einmal versuchen.
Bevor du beginnst
- Tracker: GitHub Issues eines Repositorys, GitLab-Issues eines Projekts oder ein Jira-Projekt. kanman liest Stories daraus und schreibt freigegebene Stories zurück. Du kannst auch ohne Tracker beginnen: siehe kanman ohne Tracker nutzen.
- Code: die GitHub- oder GitLab-Repositories, an denen das Team arbeitet, und der Basis-Branch, gegen den kanman Pull Requests öffnet (meist
main). - Eine Verbindung: GitHub, GitLab oder Jira verbindest du direkt im ersten Schritt der Einrichtung. Die Berechtigungen beschreiben GitHub verbinden und Jira und GitLab verbinden.
- CI: Deine bestehende CI läuft weiter auf kanmans Pull Requests, und kanman beurteilt jede Änderung mit ihr. Siehe Wie kanman seine Arbeit prüft.
Einrichtung starten
Bitte kanman in der Unterhaltung darum, zum Beispiel mit „Neues Team anlegen“, und kanman öffnet die Einrichtung. Du kannst auch Neues Team im Chip unter dem Nachrichtenfeld wählen, oder du tippst /neues team ins Nachrichtenfeld und drückst Enter (Strg+Umschalt+B, auf dem Mac Cmd+Umschalt+B, tut dasselbe). Die Einrichtung liegt unter /teams/new/<schritt>, jeder Schritt hat also eine eigene Adresse, und die Zurück-Taste des Browsers wechselt zwischen den Schritten. Sie hat diese Schritte:
| Schritt | Was du festlegst |
|---|---|
| Tracker | Welche Tracker-Verbindung das Team spiegelt |
| Repositories | Teamname, Tracker-Projekt, Repositories und Basis-Branch |
| Ausführung | Welches Coding-Werkzeug den Code schreibt und wie Rechenleistung bezahlt wird |
| Aussehen | Hintergrundbild und Icon (optional) |
| Probelauf | Deine Spalten und eine Vorschau, wie kanman bis zu drei deiner offenen Issues behandeln würde |
Spalten ordnest du nicht selbst zu: kanman richtet sie für dich ein (siehe Spalten). Das Team startet mit den Standard-Limits und -Budgets, die für ein erstes Team passen. Bis du das Team anlegst, kannst du zu jedem Schritt zurück. Dein Entwurf bleibt erhalten, während du zwischen den Schritten wechselst. Alles lässt sich später im Reiter Team ändern.
Schritt 1: Tracker
Wähle die Tracker-Verbindung, die das Team spiegelt. Die Liste zeigt die Tracker-Verbindungen des Workspaces und deine eigenen GitHub- und GitLab-Verbindungen.
Um eine hinzuzufügen, nutze Verbindung hinzufügen unter der Liste, ohne die Einrichtung zu verlassen:
- GitHub oder GitLab: Verbinden öffnet die Anmeldung des Anbieters in einem kleinen Fenster. Hast du kanman autorisiert, schließt sich das Fenster, und die neue Verbindung erscheint ausgewählt in der Liste. Blockiert dein Browser das Fenster, führt In diesem Tab öffnen dieselbe Anmeldung im aktuellen Tab aus und bringt dich mit allen Eingaben zu diesem Schritt zurück.
- Jira: Verbinden klappt das Jira-Formular direkt im Schritt auf (Jira Cloud mit Site, E-Mail und API-Token, oder Jira Server / Data Center mit persönlichem Zugriffstoken). Nach Verbindung speichern ist die Verbindung ausgewählt.
Bereits verbundene Anbieter erscheinen als Chip verbunden. Ein selbst betriebenes GitLab mit Zugriffstoken fügst du einmalig unter Workspace-Einstellungen > Verbindungen hinzu.
Details und Berechtigungen:
Verbindungen gehören zum Workspace, ein zweites Team nutzt sie also mit.
Kein Tracker? Wähle kanman-Board (kein externer Tracker). Die Option steht auch dann zur Wahl, wenn der Workspace keine Verbindung hat, und die Stories des Teams liegen dann auf seinem eigenen Board. Repositories werden optional, und Entwicklerinnen und Entwickler können aus ihrem eigenen Claude Code mit den Stories arbeiten. Siehe kanman ohne Tracker nutzen und kanman in Claude Code oder Codex nutzen.
Schritt 2: Projekt und Repositories
- Trag das Tracker-Projekt ein: bei GitHub- oder GitLab-Issues das Repository, dessen Issues die Stories enthalten, bei Jira den Projektschlüssel. Bei Jira schlägt kanman die Projekte deines Jira vor; wählst du eines, werden seine Workflow-Status zu den Spalten des Teams.
- Prüf den Teamnamen. kanman schlägt einen aus dem Projekt vor, zum Beispiel “Sandbox Team”.
- Ist dein Tracker Jira, wähle den Code-Host: GitHub oder GitLab (gitlab.com oder dein eigener GitLab-Server). Bei GitHub- oder GitLab-Issues ist der Code-Host der des Trackers.
- Füge ein oder mehrere Repositories hinzu: Wähle sie aus der Liste der Repositories, die deine Verbindung erreicht, oder gib
besitzer/nameein (bei GitLabgruppe/projekt, auch mit Untergruppen) und drück Enter. Ist dein Code-Host noch nicht verbunden, führt ein Link zu Workspace-Einstellungen > Verbindungen. - Leg den Basis-Branch fest, gegen den kanman Pull Requests öffnet. Standard ist
main.
Repositories, die du nicht einträgst, sind tabu. kanman prüft das vor jedem Run und noch einmal am fertigen Diff. Weitere Repositories und Branches ergänzt du später unter Team > Repositories.
Schritt 3: Ausführung
Wähle das Coding-Werkzeug, das den Code schreibt: Claude Code oder Codex. Wähle dann, wie Rechenleistung bezahlt wird. Die Auswahl startet mit dem, was dein Workspace unter Neue Teams nutzen in Workspace-Einstellungen > Modellzugang festgelegt hat:
- Über kanman abrechnen: Die Nutzung wird zum Selbstkostenpreis plus 15 Prozent abgerechnet. Kein Schlüssel nötig.
- Eigenen Schlüssel verwenden: Runs nutzen einen Schlüssel deines Workspaces bei einem Modellanbieter. Wähle ihn unter Schlüssel, oder füge mit Schlüssel verwalten einen hinzu (Workspace-Einstellungen > Modellzugang). Claude Code arbeitet mit Schlüsseln von Anthropic und Amazon Bedrock, Codex mit Schlüsseln von OpenAI und Azure OpenAI.
Der Reviewer, der das Ergebnis prüft, ist ein eigener Helfer, der die Änderung nicht geschrieben hat. Den Ersatz legst du später unter Team > Modelle, Coding-Werkzeug fest.
Schritt 4: Aussehen (optional)
Wähle ein Hintergrundbild von Unsplash und ein Icon. Beides erscheint auf der Teamseite und bei jedem Run des Teams, was hilft, wenn du mehrere Teams betreibst. Du kannst den Schritt überspringen. Siehe Dein Team gestalten.
Schritt 5: Probelauf
Hat dein Tracker eigene Status (ein Jira-Projekt), zeigt der Schritt zuerst Deine Spalten: jeden Status mit der kanman-Spalte, als die er gilt. Mit Ändern passt du das an: Das legt das Team an und öffnet seine Status-Zuordnung unter Team > Repositories.
Klicke auf Probelauf starten. kanman liest bis zu drei offene Issues, die es aufgreifen würde (im Status Ready mit dem Übernahme-Label), und zeigt, wie es sie einschätzen und verfeinern würde: eine Größe, einen Bereitschaftswert und Hinweise wie “Akzeptanzkriterien im Format Gegeben/Wenn/Dann schreiben”. In deinem Tracker und deinen Repositories ändert sich nichts.
Am Probelauf siehst du, ob deine Issues so geschrieben sind, dass kanman sie erledigen kann. Sind die Bereitschaftswerte niedrig, lies vor dem Start Anforderungen schreiben, die kanman erledigen kann.
Spalten
kanman arbeitet mit sechs Spaltenrollen:
| Rolle | Bedeutung |
|---|---|
| Backlog | Stories, die existieren, aber noch nicht umsetzbar sind |
| Verfeinerung | Stories, die kanman klärt |
| Bereit | Stories, die aufgegriffen werden können. Eine Story hier mit dem Übernahme-Label (standardmäßig kanman) greift kanman auf |
| In Arbeit | kanman oder eine Person arbeitet an der Story |
| Review | Ein Pull Request ist offen und wird von der CI und dem unabhängigen Reviewer geprüft |
| Fertig | Gemergt |
So bekommt das Team seine Spalten:
- Ohne Tracker mit eigenen Status (kanman-Board, GitHub- oder GitLab-Issues): Das Team bekommt die sechs Standardspalten, eine pro Rolle.
- Mit einem Jira-Projekt: Seine Status werden zu den Spalten, und kanman gibt jedem eine Rolle, zuerst nach seinem Namen (auf Deutsch, Englisch, Französisch oder Spanisch, zum Beispiel ist „Bereit“ die Rolle Bereit und „QS“ Review), dann nach seiner Jira-Statuskategorie. Status, die beides nicht unterscheidet, beurteilt kanmans Modell, wenn dein Workspace einen eigenen Modellschlüssel hat; sonst starten sie im Backlog.
- Hat eine Rolle keinen Status, ergänzt kanman dafür eine eigene Spalte an ihrer Stelle im Ablauf. Jiras „To Do, In Progress, Done“ bekommt zum Beispiel auf kanmans Board die Spalten Bereit und Review dazu. Wären mehrere Status Bereit, ist der letzte Bereit und die früheren sind Verfeinerung.
Der Probelauf zeigt das Ergebnis. Du änderst es jederzeit unter Team > Repositories. Boards mit deutschen Statusnamen behandelt Jira und GitLab verbinden.
Team anlegen
Klicke auf Team anlegen. Das Board des neuen Teams öffnet sich neben deiner Unterhaltung mit kanman, zum Beispiel app.kanman.ai/acme/teams/billing, mit dem Status des Teams in seinem Kopf. Mit einem Tracker liest kanman das Projekt sofort, die Stories erscheinen also nach wenigen Sekunden auf dem Board.
Oben in deiner Unterhaltung zeigt die angeheftete Karte Einrichtung, wie weit das Team ist: Workspace, Verbindung und Team sind erledigt; erste Story, erster Run und der gemergte Pull Request folgen. Zum nächsten Schritt gibt es immer eine Schaltfläche, die dich hinführt (Beschreiben setzt dich ins Eingabefeld, um Arbeit zu beschreiben, Story auswählen hebt die Spalte Bereit hervor). Ein Team ohne Repositories (kanman-Board mit Claude Code) zeigt Claude Code verbunden statt des ersten Runs und Fertig statt gemergt. Die Karte wird beim Team gespeichert: Alle im Workspace sehen in jedem Browser denselben Fortschritt, und Ausblenden entfernt sie für alle.
Der letzte Schritt der Einrichtung zeigt Wo du das später änderst: jede Wahl der Einrichtung und die Seite des Reiters Team, auf der sie liegt.
Was kanman als Erstes sagt
kanman liest die Repositories des Teams und wie das Team auf seinem Code-Host arbeitet; die Arbeit von Menschen zählt es getrennt von seiner eigenen, von Bots und von Skripten. Dann sagt es einmal im Chat des Teams, was es gefunden hat:
- In einem Team, in dem Menschen ihre Arbeit schon selbst mergen, beschreibt es das Team, statt Arbeit vorzuschlagen: die Repositories, wie oft ihr mergt und reviewt, eure Releases, Merge Requests, die seit Wochen warten, und die Konventionen und Werkzeuge, die es gefunden hat (Anleitungsdateien wie
CLAUDE.mdoderAGENTS.md, eure eigenen Commands, Skills und Werkzeug-Repositories). Es sagt, wie es jedes davon nutzt und wie du das änderst („sag mir, wenn du lieber …“). Stories schlägt es nur vor, wenn du darum bittest. - In einem Team, in dem kanman die Arbeit macht, schlägt es zusätzlich drei kleine erste Stories vor, die du mit einem Klick annimmst.
Kann kanmans Konto einige Repositories des Teams nicht erreichen, sagt es, welche, und was ein Workspace-Admin dafür tun muss.
Weiter mit: Deine erste Story.
Die Einrichtung später ändern
Alles aus der Einrichtung findest du im Reiter Team im Team-Kopf (/teams/<team>/team/<bereich>): sieben kurze Seiten in zwei Gruppen, links in einer Liste. Jede Einstellung ist eine Zeile mit kurzer Erklärung, ihrem aktuellen Wert und der Markierung Standard; ein Klick öffnet ihren Editor in einem Seitenbereich. Selten genutzte Optionen stehen unter Weitere Optionen. Jede Änderung wird sofort gespeichert, mit einem Häkchen Gespeichert und Rückgängig.
| Gruppe | Seite | Enthält |
|---|---|---|
| Spielregeln | Team | Wie kanman mit dem Team arbeitet, die Personen im Team und seine Labels; unter Name, Kürzel und Aussehen Teamname, Story-Schlüssel, das Aussehen des Teams und das Team löschen |
| Zeiten | Arbeitszeiten und Zeitzone auf einem Wochenstreifen, Ruhe im Chat und Antwortzeiten unter Erreichbarkeit | |
| Budget und Grenzen | Stories gleichzeitig, Ausgabengrenzen mit dem bisher Ausgegebenen, Freigabe vor dem Merge und was kanman nicht ändern darf (geschützte Pfade und die größte Änderung); mehr unter Weitere Optionen | |
| Einrichtung | Modelle | Das Coding-Werkzeug und sein Ersatz, Modellzugang und wer bezahlt, Modelle für Helfer und das Wochentempo |
| Umgebung | Die Variablen jedes Runs (Modell-Login, Code-Host-Tokens, weitere Variablen, Registry-Logins, Workspace-Secrets), Image und Setup und der Internetzugang | |
| Repositories | Repositories, Branches und Branch-Namen; der Tracker mit Status-Zuordnung, Übernahme-Label, Jetzt synchronisieren und Übernahme ansehen; bei einem kanman-Board Tracker verbinden (siehe kanman ohne Tracker nutzen) | |
| Verbindungen | Die Systeme, die das Team nutzt, kanmans Konten und Erwähnungen, die Slack- und Microsoft-Teams-Kanäle, in denen kanman mit dem Team spricht, die Werkzeuge, die kanman nutzen darf, Alarmquellen und, für Entwickler, Webhooks |
Was kanman weiß (Gedächtnis, Skills und die Dokumente, die es lesen darf) und die Services des Teams stehen im Reiter Mind des Teams unter Gedächtnis, siehe Gedächtnis und Skills. Die Stories des Teams aus Claude Code oder Codex bearbeiten richtest du unter Deine Einstellungen > API-Tokens ein, siehe kanman in Claude Code oder Codex nutzen.
Merge Requests reviewen, Wartung, main im Blick behalten, der Wochenrückblick, der Retro-Impuls, das Tagesupdate und das Antworten auf Erwähnungen sind eingebaute Habits im Reiter Habits des Teams und ändern sich im Chat. Die Regeln für kanmans eigene Merge Requests (Freigabe durch einen Menschen vor dem Merge, eine Person um ein Review bitten) stehen unter Budget und Grenzen.
Pausiert und fortgesetzt wird das Team mit der Pause-Schaltfläche neben seiner Statuszeile im Team-Kopf, nicht in den Einstellungen. Alte Links auf zusammengelegte Seiten funktionieren weiter und öffnen die neue Seite.
Nur Workspace-Admins können die Einstellungen ändern; Mitglieder sehen sie schreibgeschützt. Unter Mind > Gedächtnis legen auch Mitglieder Einträge an und bearbeiten sie. Jede Änderung wird im Audit-Log festgehalten.
Zuletzt aktualisiert: January 1, 0001
kanman öffnen