Spätestens wenn man sich für Confluence (oder ein anderes Wiki) als Tool für die Produktdokumentation entschieden hat, stellt sich die Frage, wie man die angelegten Seiten strukturieren soll. Dafür gibt es bei Anwendungen mit hohem User-Interface-Anteil zwei offensichtliche Möglichkeiten: entweder man gliedert nach Feature-Schnitt oder nach den einzelnen Seiten in der Anwendung.
Intuitiv ist die Wahl der Seiten. Man kann einfache Schnitte wählen und die Seitenstruktur der Dokumentation entspricht ggf. der Menüstruktur der Anwendung. Allerdings vermischen sich so oftmals Fachlichkeiten, wenn sie nämlich auf der gleichen Seite stattfinden oder eine Fachlichkeit auf unterschiedlichen Seiten verteilt ist. Das macht eine Dokumentation unleserlich und dementsprechend schwierig zu erfassen. Diese Sicht ist sicherlich spannend für jemanden, der eine konkrete Seite neudenken will, aber für jemanden, der an fachlichen Abläufen interessiert ist, gehen Informationen verloren oder er muss sie sich mühsam zusammensuchen.
Für letzteren ist also eine Gliederung nach Featuren sinnig. Hier stellt sich sofort die Frage, wie man Feature schneiden sollte. Diese Fragestellung sollte aber nicht erst bei der Dokumentation aufkommen, sondern schon viel früher diskutiert werden. Außerdem fragt man sich wie eine Gliederung von Featuren aussehen kann. Hierzu verweise ich auf den Blogbeitrag: Story Map als Projekt- und Produktdokumentation.
Zwar würde ich immer die Gliederung nach Fachlichkeit bevorzugen, aber beide Sichten haben ihre Berechtigung und es geht auch eine Hybrid-Lösung. Man kann die Confluence-Seite nach Featuren aufbauen und jede Confluence-Seite einen Tag mit dem Seitennamen vergeben. Möchte jemand wissen, was sich auf bestimmten Seiten abspielt, muss dieser nur noch nach dem Tag suchen und findet alle Feature, die in irgendeiner Form mit dieser Seite interagieren. Natürlich geht das auch andersrum.
Agile Dokumentation 