Ein Kanban-Board kann eine Sache sehr gut: Es zeigt, was sich bewegt. Wer woran arbeitet. Was wartet. Was erledigt ist. Schwach ist es bei allem, was länger gilt: wie Ihr ein Release macht, warum Ihr Euch für einen Anbieter entschieden habt, was eine neue Kollegin in der ersten Woche lesen sollte.
Die meisten Teams legen dieses Wissen woanders ab: in einem Doku-Tool, auf einem geteilten Laufwerk, in einem Chat-Kanal. Mit der Zeit driften Board und Doku auseinander. In der Aufgabe steht „siehe Spezifikation“. Die Spezifikation ist umgezogen. Und die Person, die wusste, wo sie liegt, ist im Urlaub.
Dieser Beitrag zeigt, wie Du die Arbeit zwischen Board und Wiki aufteilst und beides verknüpft hältst. Die Beispiele stammen aus Kanroo, das ein Wiki mitbringt. Die Ideen funktionieren aber mit jeder Kombination aus Board und Wiki.
Board oder Wiki: Wohin damit?
Eine einfache Regel hilft: Das Board hält fest, was sich diese Woche ändert. Das Wiki hält fest, was nächsten Monat noch gilt.
| Auf dem Board | Im Wiki |
|---|---|
| „Login-Timeout beheben“ | Wie die Anmeldung funktioniert, mit Diagramm |
| „Kunden-Workshop vorbereiten“ | Die Workshop-Agenda, die Ihr jedes Mal wiederverwendet |
| „Release 2.4“ | Die Release-Checkliste und die Release Notes |
| „Über den neuen Mail-Anbieter entscheiden“ | Die Entscheidung, das Datum und die Gründe |
| „Lisa einarbeiten“ | Der Onboarding-Leitfaden für alle neuen Kolleginnen und Kollegen |
Eine Aufgabe ist kurzlebig. Sie wandert durch Eure Listen, dann ist sie erledigt. Eine Seite bleibt. Du aktualisierst sie, und die nächste Aufgabe verlinkt wieder darauf.
Fünf Zeichen, dass ein Wiki fehlt
- Aufgabenbeschreibungen werden sehr lang. Ausführliche Anleitungen stecken in Aufgaben, die irgendwann in der Erledigt-Liste landen. Dort findet sie niemand wieder.
- Jeden Monat kommt dieselbe Frage. „Wie deployen wir?“ „Wo ist der Brand Guide?“ Die Antwort gehört auf eine Seite, nicht in einen Kommentar.
- Neue im Team lesen alte Aufgaben, um sich einzuarbeiten. Das klappt, aber langsam. Ein kurzer Leitfaden geht schneller.
- Entscheidungen gehen verloren. Sechs Monate später weiß niemand mehr, warum das Team Option B gewählt hat.
- Du schickst jedem Kunden dasselbe Dokument. Und jeder Kunde bekommt eine leicht andere Version.
Wenn Dir zwei dieser Punkte bekannt vorkommen, spart Dir ein Wiki Zeit.
So funktioniert es in Kanroo
In Kanroo ist das Wiki Teil des Produkts, kein Zusatzmodul. Es liegt direkt neben Deinen Boards, kennt dieselben Personen und Rollen und ist in beide Richtungen mit Aufgaben verlinkt.
Spaces und Seiten
Ein Space (ein Bereich im Wiki) enthält die Seiten eines Teams oder Themas, etwa „Entwicklung“ oder „Kunde A“. Die Rollen Betrachter, Bearbeiter und Verwalter vergibst Du an die ganze Organisation, an ein Team oder an einzelne Personen, genau wie bei Boards.
Seiten lassen sich bis zu fünf Ebenen tief verschachteln, in der Reihenfolge, die Du wählst. Jede Seite hat außerdem eine feste Nummer in ihrem Space.
Schreiben
Du schreibst in einem visuellen Editor, der Markdown speichert. Seiten können Tabellen, Aufgabenlisten, Überschriften, Bilder, Code und Infoboxen für Notizen und Warnungen enthalten. Du kannst auch Mermaid-Diagramme einfügen: Du schreibst das Diagramm als Text oder bearbeitest es visuell, und die Seite zeigt es als Grafik.
Gespeichert wird nur, wenn Du es willst. Bis dahin bleibt Dein Entwurf im Browser. So geht kein halb fertiger Gedanke aus Versehen raus. Hat jemand anderes in der Zwischenzeit gespeichert, zeigt ein Dialog den Konflikt. Du kannst gespeicherte Versionen öffnen und später eine davon wiederherstellen. Wie viele Versionen pro Seite gespeichert werden, hängt von Deinem Plan ab.
Links zwischen Aufgaben und Seiten
Hier werden Board und Wiki zu einem System.
- Eine Seite aus einer Aufgabe verlinken. Nutze in der Aufgabenbeschreibung Seite verlinken und wähle die Seite über die Suche. Der Link erscheint als Chip mit dem Seitentitel.
- Eine Aufgabe aus einer Seite verlinken. Nutze im Seiteneditor genauso Aufgabe verlinken. Eine Release-Seite kann so jede Aufgabe des Release auflisten.
- Links verraten nichts. Darf jemand das Ziel nicht öffnen, sieht er statt des Titels nur den Hinweis „Kein Zugriff“.
Um etwas zu finden, drück Shift + K. Die Suche durchsucht Aufgaben, Boards und Seiten auf einmal.
Seiten nach außen teilen
Manchmal ist eine Seite für einen Kunden oder Partner gedacht. Eine Freigabe ist ein schreibgeschützter Link auf eine Seite, auf Wunsch mit allen Unterseiten.
- Versieh den Link mit einem Passwort (4 bis 64 Zeichen) und einem Ablaufdatum.
- Leg so viele Freigabelinks an, wie Du brauchst. Zum Beispiel einen pro Kunde: So kannst Du einem Kunden den Zugriff entziehen, ohne die anderen anzufassen.
- Suchmaschinen erhalten die Anweisung, freigegebene Seiten nicht zu indexieren.
- Links auf einer freigegebenen Seite senden keinen Referrer. Andere Websites sehen also nicht, woher der Besuch kam.
Ein Aufbau zum Nachmachen
Ein einfaches Beispiel: ein kleines Team, das Websites für Kunden baut. Der Anwendungsfall für Agenturen zeigt denselben Aufbau mit Screenshots.
Boards
- Ein Board pro Kundenprojekt, mit den Listen Backlog, Diese Woche, Im Review und Erledigt.
- Labels für die Art der Arbeit: Design, Inhalt, Entwicklung.
Wiki-Spaces
- Team-Handbuch: Onboarding, Tools, wie wir Aufwände schätzen, wie wir Releases machen.
- Ein Space pro Kunde: das Briefing, Kontakte, Entscheidungen und der Übergabe-Leitfaden.
Links
- Jede Projektaufgabe, die Kontext braucht, verlinkt auf das Briefing oder auf eine Entscheidungsseite.
- Die Release-Seite verlinkt auf die Aufgaben des Release.
- Den Übergabe-Leitfaden bekommt der Kunde über einen eigenen Freigabelink.
Nach einem Monat gibt es für die meisten Fragen eine Seite. Neue Aufgaben werden kürzer, weil sie auf diese Seiten verlinken, statt deren Inhalt zu wiederholen.
Damit Seiten nützlich bleiben
Ein Wiki hilft nur, wenn die Leute ihm vertrauen. Diese Gewohnheiten halten es aktuell:
- Eine Seite, eine Frage. „Wie wir deployen“ ist eine Seite. „Entwicklungsnotizen“ ist eine Rumpelkammer.
- Datiere Deine Entscheidungen. Schreib das Datum, die Optionen und den Grund auf. Dein späteres Ich dankt es Dir.
- Verlinke in beide Richtungen. Ändert eine Aufgabe eine Seite, verlinke die Seite in der Aufgabe. Beschreibt eine Seite Arbeit, verlinke die Aufgaben.
- Halte Anleitungen kurz. Nutze nummerierte Schritte und höchstens einen Screenshot pro Schritt.
- Archivieren statt löschen. Archivierte Seiten lassen sich wiederherstellen. Altes Wissen kann später noch eine Frage beantworten.
Was das Kanroo-Wiki noch nicht kann
Damit Du die Lücken kennst, bevor Du anfängst:
- Zwei Personen können nicht gleichzeitig an derselben Seite schreiben.
- Es gibt keine Seitenkommentare, keine Seitenvorlagen, keine Tags und keine Backlinks.
- PDFs entstehen über den Druckdialog Deines Browsers, nicht auf dem Server.
Das kann kommen, wenn die Community es sich wünscht. Ist Dir einer dieser Punkte wichtig? Sag es uns über das Feedback-Formular.
Bestehende Doku mitbringen
Du musst nicht bei null anfangen. Kanroo importiert Markdown-Dateien oder ein ZIP davon in einen Space oder unter eine Seite: bis zu 500 Dateien und 25 MiB pro Import, entpackt gerechnet und mit Bildern und Anhängen. Exportieren kannst Du eine Seite, eine Seite mit ihren Unterseiten oder einen ganzen Space, jeweils als ZIP mit Markdown-Dateien und Anhängen. Deine Seiten bleiben einfaches Markdown. Du kannst sie also mitnehmen.
Kurz gesagt
- Das Board zeigt, was sich bewegt. Das Wiki hält fest, was gilt.
- Verlinke Aufgaben und Seiten in beide Richtungen, damit der Kontext nur einen Klick entfernt ist.
- Gib Seiten über eigene Links für Kunden frei, mit Passwort und Ablaufdatum.
- Fang klein an: ein Handbuch-Space und ein Space pro Projekt oder Kunde.
Mehr Screenshots und Details findest Du auf der Funktionsseite zum Wiki. Oder lies, wie Boards und Seiten zusammenspielen.