Teams

Ein Team ist die Einheit, in der kanman arbeitet. Jedes Team ist an ein Tracker-Projekt und ein oder mehrere Repositories gebunden, hat eigene Grenzen und ein eigenes Budget und zeigt seine Arbeit auf einem schlanken Board. Die meisten Unternehmen beginnen mit einem Team und nehmen weitere dazu, sobald andere Engineering-Teams einsteigen (siehe Ein zweites Team einführen).

Jedes Team hat seinen eigenen Chat mit kanman, neben Persönlich, der Unterhaltung über alle Teams. Du wechselst mit dem Chip unter dem Nachrichtenfeld; dort richtest du auch ein Neues Team ein. Alles zu einem Team, seine Runs, Entscheidungen, Berichte, Incidents und die Einrichtung, landet im Chat des Teams, und eine Anforderung für das Team, die du in Persönlich schreibst, wandert nach deiner Zustimmung dorthin. Siehe Persönlich und deine Team-Chats.

Team-Mitglieder

Alle in deinem Workspace sehen jedes Team: sein Board, seinen Chat, seine Runs und seine Berichte. Zu einem Team zu gehören ist ein Schritt mehr. Die Mitglieder eines Teams sind die Menschen, mit denen kanman dort arbeitet:

• Sie bekommen die Fragen, Entscheidungen, Hinweise und Neuigkeiten des Teams (jeweils in der Stufe, die sie wählen, siehe Deine Stufe pro Team).
• Sie beantworten die Entscheidungen des Teams.
• kanman nimmt im Chat des Teams Anweisungen von ihnen an.

Leads sind Mitglieder, die das Team zusätzlich wie ein Admin einrichten: seine Einstellungen, wer dazugehört und wer beitreten darf. Wer das Team eingerichtet hat, ist sein erster Lead. Owner und Admins des Workspaces können jedes Team einrichten, bekommen die Fragen eines Teams aber nur, wenn sie Mitglied sind. Wer als Führungskraft mehrere Teams im Blick behält, tritt ihnen mit der Stufe Nur Updates, keine Fragen bei.

Beitreten. Ein Team ist standardmäßig offen: Öffne es und klicke auf Beitreten (im Chat des Teams, im Team-Wechsler oder unter Team > Team, Zeile Personen). Ein Lead kann das Team auf Nur über eine Leitung oder Einladung umstellen; dann fügt ein Lead die Personen hinzu. Verlassen kann jede Person ein Team auf derselben Karte.

Mitglieder verwalten. Unter Team > Team, Zeile Personen, fügen Leads Kolleginnen und Kollegen aus dem Workspace hinzu, machen ein Mitglied zum Lead oder entfernen jemanden. Eine Einladung kann die Teams nennen, in denen die neue Person Mitglied wird, und die Teams, die sie leitet; sie gehört ihnen ab dem ersten Tag an (siehe Personen einladen). Betrachter lesen jedes Team, treten aber keinem bei.

Mitlesen. Wer kein Mitglied ist, kann trotzdem im Chat eines Teams schreiben, und das Team sieht es, aber kanman behandelt es nicht als Anweisung. Das Nachrichtenfeld sagt dann Tritt bei, um hier mit kanman zu arbeiten.

Deine Teams finden. Überall, wo Teams aufgelistet sind, im Team-Wechsler unter dem Nachrichtenfeld und auf der Teamseite, stehen Meine Teams zuerst. Alle anderen Teams liegen eingeklappt unter Alle Teams, mit einem Suchfeld.

Was zu einem Team gehört

Ein Team hat einen Slug, der in seiner URL erscheint, zum Beispiel app.kanman.ai/acme/teams/sandbox-team, und ein Schlüsselpräfix für seine Stories, zum Beispiel SBX für SBX-12.

kanman als Team oder für dein Team

Teams arbeiten auf eine von zwei Arten mit kanman, und Team-Admins (Owner oder Admins des Workspaces sowie die Person, die das Team eingerichtet hat) wählen unter Team > Team, Zeile Wie ich mit diesem Team arbeite, welche:

Unter Wem was gehört benennst du Bereiche: ein Repository (oder jedes Repository des Teams), optional einen Ordner wie services/billing, und wem er gehört, kanman oder einem Mitglied deines Workspaces. Ein Ordner umfasst alles, was darin liegt, und jeder Bereich hat genau eine Zuständigkeit. kanman baut in seinen eigenen Bereichen und überlässt Bereiche einer Person dieser Person, solange sie kanman nicht fragt. Das Kreuz an einem Bereich entfernt ihn; jede Änderung wird sofort gespeichert und lässt sich rückgängig machen.

Darunter zeigt Aus den letzten Änderungen, wer in den Repositories des Teams was am häufigsten geändert hat, gelesen aus den Merge Requests etwa stündlich. So siehst du, wer schon wo arbeitet, bevor du Bereiche benennst; kanman ändert diese Liste nie von sich aus.

Desktop Mobile

Das Board spiegelt deinen Tracker

Dein Tracker bleibt die maßgebliche Quelle. kanman verlangt von niemandem, die Arbeit aus GitHub, Jira oder GitLab herauszuholen. Es spiegelt die für kanman markierten Issues des verbundenen Projekts auf die Team-Seite und hält sie in beide Richtungen synchron:

• Wenn jemand im Tracker ein markiertes Issue anlegt, bearbeitet oder verschiebt, folgt die Team-Seite, über die Webhooks des Trackers und einen regelmäßigen Abgleich alle paar Minuten. Jetzt synchronisieren in der Zeile Tracker unter Team > Repositories startet einen sofort.
• Verliert ein Issue seine Markierung, während es in Bereit wartet, verschiebt kanman es zurück ins Backlog. Ein im Tracker gelöschtes Issue verschwindet von der Team-Seite.
• Wenn kanman freigegebene Stories schreibt, ein Issue kommentiert oder eine Story verschiebt, wird die Änderung in den Tracker geschrieben und im Aktivitätsprotokoll festgehalten.

Die Team-Seite ist bewusst schlank. Sie zeigt die Spalten und die Story-Karten mit ihrem Run-Status. Braucht etwas Aufmerksamkeit, steht es als Hinweis über dem Nachrichtenfeld im Chat des Teams (siehe Hinweise über dem Nachrichtenfeld). Das Team öffnet sich neben seinem Chat mit kanman, der das Team nennt, und sein Kopf bleibt auf jeder Seite des Teams: eine Zeile mit den Reitern Mind (mit dem Board), Habits (was kanman von selbst weiter tut), Stories (die laufende Woche und ihre Erfolgsgeschichten) und Team (die Einstellungen des Teams) und rechts einem Status wie Arbeitet · 1 läuft · 3 im Review. Auf dem Smartphone sind die Reiter eine Leiste am unteren Bildschirmrand. Neue Arbeit beschreibst du im Chat des Teams, nicht auf der Teamseite. Siehe Rundgang durch die App. Karten verschiebst du per Ziehen oder über das Menü Verschieben nach.

Das Board ist bewusst ruhig: Jede Story-Karte zeigt ihren Titel und darunter eine leise Zeile mit dem Schlüssel, wie weit ihre Checkliste ist (2/5), ihren Notizen und wer daran arbeitet. Nur was einen Menschen braucht, bekommt eine eigene Zeile, etwa was eine Story blockiert, und während kanman an einer Story arbeitet, was es gerade tut. Zeig auf eine Karte oder geh mit der Tastatur zu ihr, um daneben ihre Kurzbeschreibung, ihre Labels und kanmans letzten Schritt zu sehen; die Story-Seite hat alles. Die Schaltfläche Verschieben nach erscheint, wenn du auf eine Karte zeigst (auf dem Smartphone ist sie immer da).

Fertig und Spalten ohne Karten sind schmale Leisten mit Name und Anzahl, so passen die Spalten mit Arbeit nebeneinander. Wähle eine Leiste, um die Spalte zu öffnen, und die Einklappen-Schaltfläche in ihrem Kopf, um sie wieder zur Leiste zu machen. Während du eine Karte ziehst, öffnet sich eine Leiste, sobald du sie erreichst, und eine Spalte, die eine Karte bekommt, öffnet sich von selbst.

Desktop Mobile

kanman bei der Arbeit zusehen

Solange das Board offen ist, siehst du kanman so arbeiten, wie du eine Kollegin in einem gemeinsamen Dokument sehen würden: Sein Mauszeiger mit dem Namensschild kanman erledigt die Arbeit vor deinen Augen.

• Eine Story verschieben. kanmans Mauszeiger nimmt die Karte auf, zieht sie in ihre neue Spalte und legt sie dort ab, wo sie bleibt.
• Eine Story schreiben. Die Karten darunter machen Platz, kanman tippt den Titel dort, wo die neue Karte hinkommt, und die Karte erscheint um ihn herum. Outcomes, die kanman vorschlägt, erscheinen genauso.
• Eine Story abschließen. Der Mauszeiger trägt die Karte auf die Leiste Fertig, wo sie hineingleitet und die Anzahl steigt.
• Fortschritt bei einem Outcome. Der Mauszeiger zeigt auf den Fortschrittsbalken der Outcome-Karte, während er sich füllt.
• Eine Story weiterbringen. Erreicht kanmans Arbeit an einer Story den nächsten Schritt (etwa von Planung zu Umsetzung), zeigt der Mauszeiger zuerst auf den Status der Story, dann wechselt der Status unter ihm.

Deine eigenen Verschiebungen passieren sofort, und du hast immer Vorrang: Sobald du auf dem Board klickst, scrollst oder tippst, beendet kanman seinen Schritt sofort und zeigt alles, was sich geändert hat. Passiert viel auf einmal, zeigt kanman die neueste Änderung und den Rest sofort, sodass das Board nie mehr als ein paar Sekunden hinterherhinkt. Ist der Tab im Hintergrund oder hast du reduzierte Bewegung gewählt, erscheinen Änderungen ohne Mauszeiger. Der Mauszeiger scrollt den Chat nie für dich: Ist die Anfrage nicht auf deinem Bildschirm, siehst du einfach kanmans Antwort. Auf dem Handy arbeitet kanmans Mauszeiger in der Spalte, die du gerade siehst; Änderungen in anderen Spalten erscheinen dort einfach.

Spaltenrollen

Wie deine Spalten heißen, ist kanman egal. Entscheidend ist, was sie bedeuten. Jede Spalte des Tracker-Projekts wird einer von sechs Rollen zugeordnet:

Deutsche Jira-Boards funktionieren ohne Nacharbeit: Bereit, In Arbeit, QS und Fertig werden beim Verbinden des Projekts erkannt. Jede Zuordnung kannst du später unter Team > Repositories ändern: Die Zeile Tracker zeigt jeden Tracker-Status mit einem Pfeil zu dem Schritt von kanman, auf den er abgebildet ist, und daneben die Schritte von kanman mit der Anzahl der Status, die dorthin führen. Ein Schritt, zu dem kein Status führt, trägt eine Warnung.

Die Rollen machen den Ablauf deterministisch. kanman rät nie, welche Spalte gemeint ist: Es verschiebt Stories zwischen Spalten allein anhand dieser Rollen.

Wann eine Story übernommen wird

Eine Story wird übernommen, wenn beide Bedingungen erfüllt sind:

1. Sie ist für kanman markiert: Sie trägt das Übernahme-Label (standardmäßig kanman) oder ist dem Konto zugewiesen, das unter Team > Repositories in der Zeile Tracker steht. Die Zeile zeigt auch eine Vorschau, welche Issues übernommen würden.
2. Sie liegt in einer Spalte mit der Rolle ready.

Mehr braucht es nicht: Karte nach Bereit ziehen. kanman bemerkt die Verschiebung, schaut auf das ganze Board und beginnt die Story, wenn sie in den Plan passt: außer das Team ist pausiert, das Tagesbudget ist aufgebraucht oder die Story ist einer Person zugewiesen. Siehe So läuft eine Story.

kanman entscheidet anhand dessen, was auf dem Board liegt, wie viele Stories es nebeneinander bearbeitet und in welcher Reihenfolge: Stories, die dieselben Dateien berühren, warten aufeinander, und dringende Arbeit kommt zuerst.

Ein Team pausieren

Admins pausieren ein Team mit dem Pause-Knopf neben der Statuszeile des Teams im Team-Kopf. Die Pause gilt sofort, und Rückgängig in der Meldung nimmt sie zurück. Du kannst auch kanman in der Unterhaltung darum bitten, zum Beispiel mit “pausiere das Team, bis das Token getauscht ist”; kanman zeigt die Änderung auf einer Karte und pausiert, wenn du Team pausieren klickst. Eine Pause stoppt neue Arbeit, was bereits läuft, läuft normal zu Ende, und der Team-Kopf zeigt Pausiert · Fortsetzen. Um die Pause zu beenden, klicke im Team-Kopf auf Fortsetzen oder auf der Karte in der Unterhaltung auf Team fortsetzen. Nach dem Fortsetzen übernimmt kanman wieder Stories aus Bereit. Solange das Team pausiert, zeigt Team > Zeiten, seit wann. Jede Pause und jedes Fortsetzen steht im Audit-Log.

Alle Runs im Notfall stoppen

Eine Pause lässt laufende Arbeit zu Ende laufen. Wenn etwas sofort anhalten muss, zum Beispiel bei einem geleakten Token oder einer Änderung, die deine Repositories nicht erreichen darf, nutzen Owner und Admins Alle Runs stoppen unter Workspace-Einstellungen > Runs und Runner. Nach deiner Bestätigung wirkt der Stopp auf jedes Team des Workspaces, in der kanman Cloud und auf deinen eigenen Runnern:

• jeder Run, der gerade arbeitet, hält innerhalb einer Minute an, und nichts davon wird gepusht;
• kein Pull- oder Merge-Request wird geöffnet oder gemergt, und kein neuer Run startet;
• wartende Runs bleiben in der Warteschlange, und Schritte, die auf einen Runner warten, werden abgebrochen.

Der Stopp wartet weder auf kanman noch darauf, dass ein Run fertig wird. Der Team-Kopf jedes Teams zeigt Runs gestoppt, die Chats zeigen oben Alle Runs sind gestoppt, und kanman sagt in Persönlich, wer die Runs gestoppt hat. Um den Stopp zu beenden, klicke auf derselben Karte auf Runs fortsetzen (oder direkt nach dem Stopp in der Meldung auf Runs fortsetzen). Die angehaltenen Runs starten dann ab ihrem zuletzt gepushten Stand neu, und neue Runs starten wie gewohnt. Jeder Stopp und jedes Fortsetzen steht im Audit-Log.

kanman hält außerdem von selbst an, wenn dein Git-Host oder Tracker nicht antwortet: Es startet keine neuen Runs, bis der Dienst wieder erreichbar ist, und die Team-Seite sagt das in ihrer Gesundheitszeile.

Der Wochenbericht

Wenn kanman eine Story oder einen Rollout abschließt, erzählt es das im Team-Chat, wie es ein Kollege tun würde: was es erreicht hat und warum das für dich oder deine Kunden zählt, mit dem Nachweis darunter (Merges und Repositorys, freigegebene Reviews, der Browser-Nachweis zum Abspielen und Links zur Story und zum Reiter Stories). Auch der Rückblick vom Freitag erscheint im Team-Chat. In Persönlich nennt jeder davon sein Team.

Der Reiter Stories des Teams (/teams/<team>/stories) zeigt immer die laufende Woche, von Montag bis jetzt. Er beginnt mit der Woche in den Worten von kanman: Jeden Freitagnachmittag (15:00 in der Zeitzone deines Workspaces) schreibt kanman einen kurzen Rückblick, wie es ein Teammitglied tun würde: was es erreicht hat und warum das für dich gut ist, was als Nächstes kommt und was es von wem braucht. Er bleibt als “Diese Woche, in kanmans Worten” oben, bis der nächste kommt; vor dem ersten Rückblick steht die neueste Erfolgsgeschichte von kanman vorn. Danach kommt die Woche auf einen Blick: die Merges und die Repositorys, die sie berührt haben, mit einem Balken pro Tag, die nach Done verschobenen Storys, die freigegebenen Reviews und ihre Einwände, die Pipelines, die nach einem Merge rot wurden, und wie viele wieder grün sind, und die Fragen, die auf Personen warten. Darunter zeigt eine Aktivitätsübersicht die Arbeit von kanman im letzten Jahr (auf dem Smartphone ein halbes Jahr), ein Feld pro Tag: Zeig auf einen Tag oder wähle ihn mit den Pfeiltasten, um seine Merges, Reviews und Browser-Nachweise zu lesen. Danach kommen die Erfolgsgeschichten der Woche: eine Karte pro Story, die kanman erzählt hat, egal wie viele Repositorys sie berührt hat, sodass eine Änderung, die an 237 Konnektoren ausgerollt wurde, eine Geschichte ist. Jede Karte sagt in den Worten von kanman, was es erreicht hat und warum es zählt, und zeigt den Nachweis: Merges und Repositorys, Reviews und die Einwände, die sie abgefangen haben, ob der Hauptzweig nach den Merges grün blieb, die Zeit vom ersten bis zum letzten Merge, den Browser-Nachweis (direkt auf der Karte abspielbar) und wer beteiligt war. Die größte Geschichte der Woche steht vorn. Die übrige Arbeit der Woche folgt als kurze Liste unter Weitere Arbeit dieser Woche, eine Zeile pro Story. Zuletzt kommt Im Blick: was jetzt noch offen ist, etwa eine Pipeline, die nach einem Merge noch rot ist, oder ein Einwand, den niemand geklärt hat. Gespeicherte Wochenberichte öffnen sich weiter unter ihren eigenen Links (/teams/<team>/stories/weeks/<woche>). Stories, die ohne Lieferung geschlossen wurden (von einer anderen Story abgedeckt, Duplikate oder solche, die das Team nicht umsetzt), zählen nicht als geliefert; siehe Eine Story ohne Lieferung schließen.

Unter den Lieferzahlen sagt ein Satz, wie kanman dem Team in dieser Woche gedient hat, gemessen an der eigenen Geschichte des Teams statt an einem festen Ziel: wie viele abgeschlossene Versuche bestätigt wurden (gemergt, main grün, nicht zurückgenommen, Prüfungen bestanden) im Vergleich zum üblichen Bereich des Teams der letzten acht Wochen, wie lange es bis zum ersten Pull Request oder zur ersten Frage dauerte, wie viele Fragen kanman pro gemergter Änderung gestellt hat und wie viele Versuche von der Infrastruktur blockiert wurden, etwa durch ein Anbieterlimit oder einen Ausfall. Zum Beispiel: „Service diese Woche: 7 von 9 abgeschlossenen Versuchen bestätigt (78 %, üblich sind 70-90 %), erstes Ergebnis nach 2.5 h, 1 Versuch von der Infrastruktur blockiert.“ Teile ohne Daten fallen weg. In einer Woche, in der kanman eine Story nach der anderen bearbeitet hat, weil die Bestätigungsquote unter dem üblichen Bereich lag, endet der Satz mit „solange die Bestätigungsquote unter meinem üblichen Bereich lag, habe ich eine Story nach der anderen bearbeitet“. Wie der ganze Bericht beschreibt er das Team, nie eine Person.

Ein zweiter Satz verfolgt die Arbeit der Woche vom Start bis zum Merge: wie viele Stories hereinkamen, wie viele Runs starteten, wie viele einen Merge Request erreichten und wie viele gemergt wurden, und wie viele der Änderungen, die zwei Wochen davor gemergt wurden, nach 14 Tagen noch grün sind. Hat das Team in der Woche Retro-Notizen festgehalten („Retro-Notiz: …“ im Team-Chat), listet der Bericht sie unter Retro-Notizen, ohne Namen.

Frag im Chat des Teams nach der Woche. „Welche Stories brauchten diese Woche Nacharbeit?“ nennt die Stories, die mehr als einen Versuch brauchten, mit Schlüssel, Titel und Anzahl der Versuche; „Was hat die Woche gekostet?“ nennt die Ausgaben der Woche, wie sie im Bericht stehen, und das Budget des Teams, wenn es eines hat. kanman antwortet aus den Zahlen des Teams und hängt die Karte des Berichts an, sodass du den Bericht direkt aus der Antwort öffnen.

Sind die Berichte einer neuen Woche da, sagt Persönlich das beim nächsten Öffnen („Die Berichte für KW 40 sind da: …“), mit der Berichtskarte jedes Teams. Frag in Persönlich nach der Woche, um sie für alle Teams auf einmal zu hören: „Wie lief die Woche bei den Teams?“ nennt gemergte Stories, Nacharbeit und Ausgaben pro Team, „Warum ist die Nacharbeit gestiegen?“ die Stories, die in jedem Team Nacharbeit brauchten, und „Sind wir im Budget?“ ein Ja oder Nein pro Team: gemessen am Wochenbudget des Teams (aus seinem Tages- oder Monatsbudget) oder, wenn es nur ein Budget pro Run hat, daran, ob ein Run der Woche dieses Limit erreicht hat, dazu, was die Woche gekostet hat. Gibt es noch keinen Bericht, sagt „Zeig mir den Wochenbericht“ das, statt zu fragen, welches Team du meinst.

Die Berichtskarte in der Unterhaltung zeigt die gemergten Stories, die Nacharbeitsquote, die Kosten pro gemergtem PR (die Ausgaben der Woche geteilt durch die in dieser Woche gemergten Stories, dieselbe Zahl wie auf der Berichtsseite) und die Zeit von Bereit bis zum Pull Request. Eine Woche ohne gemergte Story zeigt keine Kosten pro gemergtem PR; kanmans Zusammenfassung nennt dann, was die Woche ausgegeben hat.

Um einen Bericht weiterzugeben, öffne ihn und klicke auf Link kopieren. Alle in deinem Workspace, die den Link öffnen, sehen dieselbe Woche. Auf dem Telefon öffnet Link kopieren das Teilen-Menü.

Sobald ein Team einen Bericht hat, zeigt seine Statuszeile im Team-Kopf den letzten Zustand, zum Beispiel Gesund; ein Klick öffnet diesen Bericht.

Hintergrundbild und Icon

Jedes Team kann ein eigenes Hintergrundbild von Unsplash und ein Icon haben. Beides erscheint auf der Team-Seite, im Kopf jeder Run-Seite und im Einrichtungsassistenten, damit man ein Team auf einen Blick erkennt. Siehe Dein Team gestalten.

Verwandte Seiten

• Ein Team einrichten
• Stories und Akzeptanzkriterien
• GitHub verbinden und Jira und GitLab verbinden
• Grenzen und Regeln