Ein Team einrichten
Die Team-Einrichtung Schritt für Schritt: Tracker wählen, Projekt und Repositories benennen, Spalten zuordnen, Preset und Executor wählen, das Team gestalten und einen Probelauf starten.
Ein Team ist der Ort, an dem kanman mit Ihren 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.
Rechnen Sie bei einem typischen Repository mit etwa 20 Minuten. Sie brauchen Admin-Rechte im Workspace.
Bevor Sie beginnen
- Tracker: GitHub Issues eines Repositorys, GitLab-Issues eines Projekts oder ein Jira-Projekt. kanman liest Stories daraus und schreibt freigegebene Stories zurück.
- 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: Der Tracker muss bereits mit Ihrem Workspace verbunden sein. Siehe GitHub verbinden oder Jira und GitLab verbinden.
- CI: Ihre bestehende CI läuft weiter auf kanmans Pull Requests. kanman wartet im Rahmen der Prüfung auf sie.
- Akzeptanz-Manifest (empfohlen): eine
.kanman/acceptance.jsonim Repository, damit kanman jedes Ergebnis belegen kann. Sie können es später ergänzen, siehe Ein Akzeptanz-Manifest anlegen.
Einrichtung starten
Öffnen Sie Teams und klicken Sie auf Neues Team, oder drücken Sie Strg+P (Cmd+P auf dem Mac) und wählen Sie Neues Team. 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 Sie festlegen |
|---|---|
| Tracker | Welche Tracker-Verbindung das Team spiegelt |
| Repositories | Teamname, Tracker-Projekt, Repositories und Basis-Branch |
| Spalten | Welcher Tracker-Status Backlog, Refining, Ready, In Progress, Review und Done ist |
| Richtlinie | Das Preset, mit dem das Team startet |
| Ausführung | Welcher Coding-Agent den Code schreibt und wie Rechenleistung bezahlt wird |
| Aussehen | Hintergrundbild und Icon (optional) |
| Probelauf | Eine Vorschau, wie kanman bis zu drei Ihrer offenen Issues behandeln würde |
Bis Sie das Team anlegen, können Sie zu jedem Schritt zurück. Ihr Entwurf bleibt erhalten, während Sie zwischen den Schritten wechseln. Alles lässt sich später in den Team-Einstellungen ändern.
Schritt 1: Tracker
Wählen Sie die Tracker-Verbindung, die das Team spiegelt. Die Liste zeigt die Tracker-Verbindungen des Workspaces und Ihre eigenen GitHub- und GitLab-Verbindungen. Um eine hinzuzufügen, führt GitHub oder GitLab verbinden zu Einstellungen > Git und Jira verbinden zu Einstellungen > Tracker. Ihr Entwurf bleibt erhalten, während Sie verbinden, und Team-Einrichtung fortsetzen auf diesen Seiten bringt Sie zurück.
Details und Berechtigungen:
Verbindungen gehören zum Workspace, ein zweites Team nutzt sie also mit.
Schritt 2: Projekt und Repositories
- Tragen Sie 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 Ihres Jira vor; wählen Sie eines, werden seine Workflow-Status zu den Spalten des Teams für den nächsten Schritt.
- Prüfen Sie den Teamnamen. kanman schlägt einen aus dem Projekt vor, zum Beispiel “Sandbox Team”.
- Ist Ihr Tracker Jira, wählen Sie den Code-Host: GitHub oder GitLab (gitlab.com oder Ihr eigener GitLab-Server). Bei GitHub- oder GitLab-Issues ist der Code-Host der des Trackers.
- Fügen Sie ein oder mehrere Repositories hinzu: Wählen Sie sie aus der Liste der Repositories, die Ihre Verbindung erreicht, oder geben Sie
besitzer/nameein (bei GitLabgruppe/projekt, auch mit Untergruppen) und drücken Sie Enter. Ist Ihr Code-Host noch nicht verbunden, führt ein Link zu Einstellungen > Git. - Legen Sie den Basis-Branch fest, gegen den kanman Pull Requests öffnet. Standard ist
main.
Repositories, die Sie nicht eintragen, sind tabu. kanman prüft das vor jedem Run und noch einmal am fertigen Diff. Weitere Repositories und Branches ergänzen Sie später in den Team-Einstellungen unter Repositories.
Schritt 3: Spalten
kanman kennt sechs Spaltenrollen. Die Einrichtung liest die Statusnamen Ihres Trackers und schlägt für jeden eine Rolle vor (Schaltfläche Vorgeschlagene Rollen übernehmen), die Sie bestätigen oder ändern:
| Rolle | Bedeutung |
|---|---|
| Backlog | Stories, die existieren, aber noch nicht umsetzbar sind |
| Refining | Stories, die kanman klärt oder für die gerade die Akzeptanz-Spec entsteht |
| Ready | Stories, die aufgegriffen werden können. Eine Story hier mit dem Übernahme-Label (standardmäßig kanman) startet einen Run |
| In Progress | Ein Run arbeitet an der Story |
| Review | Die Prüfung ist bestanden; ein Pull Request mit Nachweispaket wartet auf einen Menschen |
| Done | Gemergt |
Genau ein Status muss Ready sein, und mindestens je ein Status muss In Progress, Review und Done sein. Die übrigen Rollen können sich mehrere Status teilen. In der deutschen Oberfläche heißen die Rollen Backlog, Verfeinerung, Bereit, In Arbeit, Review und Fertig. Boards mit deutschen Statusnamen behandelt Jira und GitLab verbinden.
Schritt 4: Richtlinie
Wählen Sie das Preset, mit dem das Team startet. Jede Karte zeigt, wie viele Runs gleichzeitig arbeiten dürfen:
| Preset | Kurz gesagt |
|---|---|
| Testphase | Eine Story zur Zeit, nur von Menschen. Funktioniert ohne Akzeptanz-Spec, Sie können kanman also an jedem Repository ausprobieren. |
| Fokussiert | Eine Story zur Zeit, nur von Menschen, jede Story durch eine Akzeptanz-Spec belegt. |
| Ausgewogen | Zwei Stories parallel. kanman darf auch Stories vorschlagen. Vorausgewählt. |
| Autonom | Bis zu vier Stories parallel mit weniger gesperrten Pfaden. |
| Härtung | Wie Ausgewogen, dazu täglich kleine Wartungsarbeit wie Abhängigkeits-Updates. |
Welches Preset Sie auch wählen, ein neues Team startet mit einem Run-Budget von 2,00 EUR, Plan-Freigabe always (Sie geben jeden Plan frei, bevor Code entsteht) und einem Merge durch einen Menschen. Alle Presets außer Autonom sperren infra/**, **/*.tf und .github/workflows/**; Autonom sperrt nur .github/workflows/**.
Jede Einstellung ist unter Richtlinien-Einstellungen beschrieben. Die Wahl zwischen den Presets behandelt Ein Preset wählen und anpassen.
Schritt 5: Ausführung
Wählen Sie den Coding-Agenten, der den Code schreibt: Claude Code oder Codex. Wählen Sie dann, wie Rechenleistung bezahlt wird:
- Ü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 Ihres Workspaces bei einem Modellanbieter. Wählen Sie ihn unter Schlüssel, oder fügen Sie mit Schlüssel verwalten einen hinzu (Einstellungen > KI-Anbieter). 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, läuft auf einem Modell eines anderen Anbieters als der Executor. So bewertet nie dasselbe Modell seine eigene Arbeit. Einen Ausweich-Executor und das Modell pro Story-Größe legen Sie später in den Team-Einstellungen unter Executor fest.
Schritt 6: Aussehen (optional)
Wählen Sie ein Hintergrundbild von Unsplash und ein Icon. Beides erscheint auf der Teamseite und bei jedem Run des Teams, was hilft, wenn Sie mehrere Teams betreiben. Sie können den Schritt überspringen. Siehe Ihr Team gestalten.
Schritt 7: Probelauf
Klicken Sie 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” oder “Einen Vorführschritt ergänzen”. In Ihrem Tracker und Ihren Repositories ändert sich nichts.
Kommt in einem späteren Release
Manifest-Erkennung im Probelauf: kanman prüft das Repository auf .kanman/acceptance.json und bietet einen Pull Request an, der eines hinzufügt.
Am Probelauf sehen Sie, ob Ihre Issues so geschrieben sind, dass kanman sie erledigen kann. Sind die Bereitschaftswerte niedrig, lesen Sie vor dem Start Anforderungen schreiben, die kanman erledigen kann.
Team anlegen
Klicken Sie auf Team anlegen. Sie landen auf der Teamseite, zum Beispiel app.kanman.ai/acme/teams/billing. Die Kopfzeile zeigt Bereit, 0 Runs und das Richtlinien-Badge.
Weiter mit: Ihre erste Story.
Die Einrichtung später ändern
Alles aus der Einrichtung finden Sie in den Team-Einstellungen (Reiter Einstellungen auf der Teamseite, /teams/<team>/settings/<bereich>):
| Bereich | Enthält |
|---|---|
| Richtlinie | Preset, gesperrte Pfade, Diff-Grenzen, Befugnis-Anhebungen |
| Budgets | Budgets pro Run, Tag und Monat sowie die Abrechnungsart |
| Freigaben | Plan-Freigabe und Merge-Richtlinie |
| Arbeitszeiten | Arbeitszeiten, Zeitzone und das Pausieren des Teams |
| Executor | Executor, Ausweich-Executor und das Modell pro Story-Größe |
| Tracker | Status-Zuordnung, Übernahme-Label, Jetzt synchronisieren und Übernahme ansehen |
| Repositories | Repositories und Branches |
| Wartung | Wartungsmodus und Befunde |
| Gestaltung | Hintergrundbild und Icon |
Nur Workspace-Admins können die Einstellungen ändern; Mitglieder sehen sie schreibgeschützt. Jede Änderung wird im Audit-Log festgehalten.
Zuletzt aktualisiert: January 1, 0001
kanman öffnen