Nachbarn: Wissen über Teams hinweg

Teams in einem Workspace arbeiten oft nebeneinander: in derselben Gruppe von Repositories, am selben Service, an denselben Tickets. kanman weiß, wer woran arbeitet, damit eine Frage nie mit „Das kann ich nicht“ endet. Liegt etwas außerhalb deines Teams, nennt kanman das Team, das daran arbeitet, und bietet an, es zu fragen.

Du: Warum kannst du das C4-Modell nicht lesen?

kanman: Es liegt in arc/platform-design, und das ist kein Repository dieses Teams. Das Team Architects arbeitet in dieser Gruppe (Lead: Ada). Soll ich sie bitten, es hinzuzufügen oder diesem Team Zugriff zu geben?

Wo du es findest

Öffne im Team den Tab Mind, klick auf Gedächtnis und dann auf Nachbarn (/<workspace>/teams/<team>/mind/memory/neighbours). Du siehst:

Teams in der Nähe: jedes Team, das an denselben Repositories, Gruppen, Services oder Ticketgruppen arbeitet, warum (zum Beispiel Arbeitet in arc oder Service Engage), wer es leitet, ob es sein Gedächtnis teilt, und die Titel seiner Gedächtnisseiten.
Teilen: ob dieses Team sein Gedächtnis mit den anderen Teams teilt.
Anfragen: was kanman andere Teams für dieses Team gefragt hat, was sie dein Team gefragt haben, und die Antworten.
Im ganzen Workspace (nur Owner und Admins): alle Teampaare, die sich überschneiden.

Was kanman von einem anderen Team nutzen darf

Fakten sind im Workspace offen: welches Team an welchen Repositories, Gruppen und Services arbeitet, wer es leitet und wie seine Gedächtnisseiten heißen.
Den Inhalt des Gedächtnisses eines anderen Teams nur, wenn dieses Team es teilt oder die fragende Person zu beiden Teams gehört. kanman nennt immer das Team, das es zitiert („aus den Notizen von Architects: …“).
Code nur über den Zugriff deines eigenen Teams. Dass ein anderes Team ein Repository hat, lässt kanman es nie lesen.

Teilen ist anfangs aus. Ein Lead des Teams schaltet es unter Nachbarn > Teilen ein. Dann darf kanman die Notizen deines Teams zitieren, wenn es einem anderen Team hilft, und nennt immer dein Team. Du kannst es jederzeit wieder ausschalten; andere Teams sehen dann wieder nur die Titel.

Ein anderes Team fragen

kanman fragt ein anderes Team erst, wenn du zustimmst. Es stellt den Leads dieses Teams eine kurze Anfrage als Karte in ihrem Team-Chat: wer fragt, was und warum. Ein Lead antwortet mit Zustimmen oder Ablehnen und optional einer Notiz. Die Antwort kommt als Antwort auf deine Frage in deinen Chat zurück.

Eine Anfrage gibt selbst keinen Zugriff: Das andere Team fügt das Repository oder den Zugriff selbst hinzu. Solange die Anfrage offen ist, zeigen die Storys, die sie brauchen, auf wen sie warten, und die offene Anfrage steht auch im Lead-Brief des anderen Teams. So wartet nichts still.

Zusagen zwischen Teams

Alles, worauf ein Team bei einem anderen wartet, ist eine Zusage mit einem Namen, einer Frist und einem Stand, egal woher sie kommt:

eine Anfrage, die kanman mit deinem OK gestellt hat,
eine Story, die das Repository oder den Service eines anderen Teams braucht,
ein Link in deinem Tracker, zum Beispiel ein Jira-Issue wird blockiert durch OTHER-123, wenn ein anderes Team des Workspaces in diesem Tracker-Projekt arbeitet. kanman bemerkt den Link selbst; niemand muss fragen.

Jede Zusage hat eine verantwortliche Person im anderen Team: die Person, der das verlinkte Issue zugewiesen ist, sonst den Lead des Teams. Die wartende Story zeigt sie an („Wartet auf Ada (Platform): OTHER-123“), die Chats beider Teams sagen es einmal, und die Person sieht es in ihrem Lead-Brief. Unter Nachbarn > Anfragen steht bei jeder Zusage, wer sie schuldet, ihre Frist, das verlinkte Issue und sein Stand.

Der Stand des verlinkten Issues im Tracker hält die Zusage aktuell. Ist das Issue erledigt oder der Link entfernt, ist die Zusage erfüllt: Die Story geht weiter, und dein Chat erfährt es.

Ist eine Zusage überfällig, erinnert kanman die verantwortliche Person, höchstens alle zwei Tage und insgesamt dreimal. Eine Person bekommt eine Nachricht, egal wie viele Teams auf sie warten, und dein Chat sieht jede Erinnerung. Nach der dritten hört kanman auf und schlägt vor, direkt mit ihr zu sprechen.

Änderungen, die andere Teams nutzen

Wenn dein Team etwas ändert, auf dem andere Teams aufbauen, sagt kanman es ihnen, bevor es ausgeliefert wird: eine API-Route oder OpenAPI-Spezifikation, eine Protobuf-Nachricht, eine gemeinsame Bibliothek, eine Datenbanktabelle, ein Event- oder Topic-Format, einen Konfigurationsschlüssel. Das prüft kanman bei jedem Merge Request deines Teams (bei seinen eigenen und bei denen, die es für dich reviewt) und wenn ein Issue oder Epic in deinem Tracker so eine Änderung ankündigt.

kanman durchsucht die Repositories der anderen Teams mit deren Zugriff und gibt nur weiter, wo die Änderung genutzt wird: das Team, die Datei und die Zeile, als Links. Code eines anderen Teams kopiert kanman nie in deinen Chat.

Nutzt ein anderes Team sie, bekommen beide Team-Chats eine Karte, Änderung über Teams hinweg:

was sich ändert und ob alter Code weiter funktioniert,
jedes betroffene Team mit den Stellen in seinem Code,
die Reihenfolge: erst die Nutzer (sie stellen um, dann wird gemergt), kompatibel (alt und neu nebeneinander) oder erst die Änderung,
eine vorgeschlagene Story für jedes betroffene Team.

Der Lead des betroffenen Teams entscheidet: Story annehmen legt die Story auf sein Board (dort trägt sie einen kleinen Chip, der die Karte wieder öffnet), Ablehnen sagt nein, beides mit einer optionalen Notiz, die beide Teams lesen. Eine Änderung, die zuerst bei den Nutzern ankommen muss, wartet, bis jedes betroffene Team entschieden hat, außer dein eigener Lead tippt Jetzt mergen lassen. kanman ändert nie das Board oder den Code eines anderen Teams, und die Karte sagt, auf wen sie wartet und bis wann.

Releases über Teams hinweg

Manchmal müssen mehrere Teams zusammen ausliefern: verknüpfte Merge Requests, eine Fix-Version oder ein Epic in deinem Tracker, das mehrere Teams umfasst. Dann führt kanman eine Karte Release über Teams hinweg im Chat jedes Teams:

die Reihenfolge, in der die Teams ausliefern,
eine Checkliste pro Team, die die Mitglieder dieses Teams auf der Karte abhaken,
die verknüpften Merge Requests, Issues und Fix-Versionen,
was das Release gerade aufhält.

Der Lead jedes Teams tippt Bereit, Anhalten (mit einem kurzen Grund, den die anderen Teams lesen) oder Ausgeliefert. Ein Merge Request des Releases wird erst gemergt, wenn sein Team bereit ist und die Teams davor auch. kanman mergt oder deployt nie für ein anderes Team; wenn jedes Team ausgeliefert hat, sagt die Karte es. Stories des Releases tragen denselben Chip auf dem Board.

Wo es von selbst hilft

Incidents und Tickets: kanman erwähnt, wenn ein anderes Team am selben Service arbeitet, und verknüpft Incidents mehrerer Teams, die ein Incident sind (gemeinsame Incidents).
Sicherheitshinweise: Betrifft ein Advisory mehrere Teams, sagt kanman das einmal und zeigt, wie ein anderes Team es behoben hat.
Ein neues Team: kanman schaut zuerst in die geteilten Notizen und Konventionen der Nachbarn.
Setup-Reviews: kanman kann eine Praxis vorschlagen, die ein Nachbarteam nutzt.