Welche Baumstruktur eignet sich für die Gliederung eines Wikis

Wir haben in diesem Blog gelernt, dass es es mindestens drei unterschiedliche Arten von Dokumentation gibt. Diese Erkenntnis findet sich optimalerweise auch in der Baumstruktur des Wikis wider. Wie das gehen kann, versuche ich in diesem Beitrag zu skizzieren.

Für ein einzelnes Scrum-Team liegt es auf der Hand. Die drei Dokumentationsarten Prozess-, Projekt- und Produktdokumentation (mehr) werden auf der obersten Ebene angelegt:

1. Organisatorisches
   1. Email-Verteiler
   2. Ansprechpartner
   3. How-to
   4. …
2. Projektdokumentation
   1. Konzepte
   2. Protokolle
   3. …
3. Produktdokumentation
   1. Architektur
   2. Features
   3. …

Über die Sortierung kann man natürlich noch streiten. Ich bin chronologisch vorgegangen. Ein neuer Kollege muss zunächst wissen, wie er arbeiten soll. Dann benötigt er unterstützende Dokumente für seine Arbeit, bevor er schließlich die erledigte Arbeit langfristig dokumentiert.

Nun arbeiten die meisten von euch wahrscheinlich nicht in einem Scrum-Team, das allein auf der Welt ist. Ich befinde mich z.B. in einem Programm, dass sich in verschiedene Projekte mit unterschiedlichen Scrum-Teams aufteilt und nach SAFe zusammenarbeitet. Da ist die Baumstruktur schon etwas komplizierter. Aber fangen wir einfach an: Egal, wie die Struktur bei euch aussieht, für ein Produkt darf es auch nur eine Produktdokumentation geben. Sie sollte sich also in jedem Fall auf der obersten Hierarchieebene befinden. Anders sieht es bei der Projekt- und Prozessdokumentation (Organisatorisches) aus. Hier muss sich jeder Dokumenteur fragen, für welchen Leserkreis (Persona) die Information relevant ist. „Organisatorisches“ und „Projektdokumentation“ kann somit auf allen Ebenen (Programm, Projekt, Team) stattfinden. Die Struktur für ein Projekt mit zwei Scrum-Teams kann dann wie folgt aussehen:

1. Organisatorisches
   1. Email-Verteiler
   2. Ansprechpartner
   3. How-to
   4. …
2. Projektdokumentation
   1. Konzepte
   2. Protokolle
   3. …
3. Scrum-Team A
   1. Organisatorisches
      1. Definition of Done
      2. Team Charta
   2. Projektdokumentation
      1. Technische Konzepte
4. Scrum-Team B
   1. Organisatorisches
      1. …
   2. Projektdokumentation
      1. …
5. Produktdokumentation
   1. Architektur
   2. Features
   3. …

Werden neue Dokumente erstellt, muss man sich jetzt immer fragen:

1. Beschreibt es den IST-Zustand des Produkts nachhaltig? Dann wird es wahrscheinlich ein Teil der Produktdokumentation sein.
2. Brauche ich es, um mein Produkt weiterzuentwickeln? Dann könnte es sich um Projektdokumentation handeln?
3. Beschreibt es die Art und Weise wie wir zusammenarbeiten oder handelt es sich um Informationen, die den Arbeitsalltag erleichtern? Dann könnte es etwas Organisatorisches sein.
4. Wer braucht diese Information? Ist es relevant für das gesamte Programm oder Projekt? Oder hat es außerhalb des Teams keinen Mehrwert?