Risikostufen

Nicht jede Änderung braucht dieselbe Sorgfalt. Mit Risikostufen legst du einmal fest, was jede Art von Änderung braucht, bevor sie live geht. kanman ordnet jede Änderung einer Stufe zu und arbeitet nach ihren Regeln.

Womit du startest

Jedes Team startet mit kanmans drei Standardstufen. Zuerst werden sie nur angezeigt: kanman ordnet jede Änderung einer Stufe zu und notiert, was es zurückgehalten hätte, hält aber nichts zurück.

Zwei Regeln gelten von Anfang an: Ist die Stufe unklar, gilt die höhere, und kanman hat keinen Zugriff auf Produktivsysteme.

Eigene Stufen festlegen

Sag kanman im Team-Chat in deinen eigenen Worten, wie deine Organisation Änderungen behandelt haben will. kanman macht daraus Stufen und schlägt sie als eine Karte vor, die Zeile für Zeile zeigt, was sich gegenüber heute ändert. Ein Workspace-Admin übernimmt sie für den ganzen Workspace, eine Leitung für ein Team, jeweils mit einem Tipp, und genauso nimmst du sie zurück. Ein Team kann die Stufen des Workspace verschärfen, nie lockern.

Ein Beispiel: Example Corp sagt kanman: „Zwei Ebenen. Alles unter ops/ oder was Infrastruktur berührt, ist geschützt: kanman schlägt nur vor, zwei Personen geben frei und ein Mensch mergt. Alles andere ist normal.“ kanman schlägt eine Richtlinie mit zwei Stufen vor, Normal und Geschützt, und den Pfad- und Infrastruktursignalen, die eine Änderung auf Geschützt setzen.

Jede Stufe kann festlegen:

• Was kanman darf: selbstständig arbeiten, nach einem freigegebenen Plan beginnen oder nur vorschlagen (ein Merge Request als Entwurf oder ein Runbook).
• Wer den Plan freigibt: ein Teammitglied, eine Leitung, ein Admin oder eine bestimmte Person, und ob der Plan auf eine dokumentierte Designentscheidung verweisen muss.
• Wie viele Personen den Merge Request freigeben, und ob das Review von jemand anderem kommen muss als die Planfreigabe.
• Ob jemand prüft, was die Tests wirklich testen, oder was Nutzer sehen werden (mit kanmans Screenshots).
• Ob Menschen mergen und deployen statt kanman.
• Was eine Änderung mindestens auf diese Stufe setzt: Pfade, und was die Änderung zeigt, etwa eine Migration, Anmeldecode, Kryptografie, Geheimnisse, Infrastruktur, einen abgeschwächten oder leeren Test oder eine Änderung an dem, was Nutzer sehen.

Auch Regeln für jede Änderung stehen bereit und sind aus, bis du sie einschaltest: Ein Mensch gibt jede Änderung frei, jeder Merge Request erklärt die Änderung in einfachen Worten, Änderungen für Kunden bestehen zuerst ihre Bereitschaftsprüfungen, und ein Prototyp-Label für Repositories, Branches oder Storys.

Was du siehst

• An jeder Story ein ruhiger Chip mit ihrer Stufe. Fahr darüber oder tipp darauf, um zu sehen warum: kanmans Gründe und was die Änderung gezeigt hat.
• Im Merge Request die Stufe mit ihren Gründen und ein Label, für die Stufen, bei denen du es willst.
• Im Chat kanmans Plan als Frage, angeheftet für die Menschen, die ihn freigeben dürfen. Hält kanman etwas zurück, sagt es, was als Nächstes nötig ist.
• In den Team-Einstellungen unter Budget und Grenzen › Risikostufen deine Stufen als kurze Leiter.

Wie die Stufen halten

kanman liest jede Änderung selbst. Zeigt eine Änderung mehr als zuerst gedacht, steigt ihre Stufe, und die Arbeit pausiert, bis der Plan wieder freigegeben ist. Sobald deine Stufen in Kraft sind, beginnt kanman keine Programmierarbeit vor einem freigegebenen Plan, wo eine Stufe einen verlangt, mergt nur mit den Freigaben, die die Stufe braucht (von verschiedenen Menschen, nie Bots), und überlässt Menschen, was eine Stufe ihnen vorbehält. Der Nachweis jeder Änderung, mit Stufe, Gründen, Freigaben und Prüfungen, bleibt für deine Audits erhalten. Siehe Audit-Export.

Verwandte Seiten

• KI-Regeln für Agenten-Setups
• Grenzen und Regeln
• So prüft kanman seine Arbeit