Steht die Struktur des Wikis fest, ist das ein wichtiger Schritt. Allerdings muss auch jeder, der das Wiki nutzt, verstehen, wo er oder sie neue Dokumente anlegen darf und wo nicht. Aus diesem Grund habe ich eine kleine Entscheidungshilfe gebastelt.
„Wo muss ich das dokumentieren? – Ein Cheat Sheet“ weiterlesen
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.
„Welche Baumstruktur eignet sich für die Gliederung eines Wikis“ weiterlesen
Als ich über Weihnachten verschiedene Blogbeiträge zu Agiler Dokumentation gelesen habe, sind mir drei Zitate besonders in Erinnerung geblieben, die mit „Documentation is like…“ anfingen. Viele sagen, dass Dokumentation langweilig und nervig ist, aber in diesen Zitaten und in diesem Beitrag geht es um Sex, Tamagotchis und den Tod.
„Was haben Sex, Tamagotchis und der Tod mit Dokumentation zu tun?“ weiterlesen
Es klingt schon ziemlich altbacken, wenn am Anfang eines Projektes der Vorschlag zu einem gemeinsamen Glossars im Raum steht, aber gerade in einem agilen Umfeld ist ein Glossar durchaus sinnvoll. Hier wird mehr Wert auf schlanke Kommunikation, als auf umfangreichen Definitionen gelegt. Durch ein gemeinsames Verständnis kommt man schneller zum Ziel, ohne über Äpfel und Birnen zu diskutieren. „Das belächelte Glossar lacht zurück“ weiterlesen
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. „Unterschiedliche Sichten auf die Produktdokumentation ermöglichen“ weiterlesen
Wenn man über agile Dokumentation schreibt, kommt man zwangsläufig zu der Fragestellung wie man den zeitlichen Aufwand des Dokumentierens so gering wie möglich halten kann. Ein Sprint dauert oft nur zwei oder drei Wochen und da kommt das unliebsame Dokumentieren allein schon aus Zeitnöten oft zu kurz.
Story Mapping ist ein Tool, das mit Hilfe der User Journey einen guten Überblick an Funktionalitäten und Anforderungen der Software darstellt. Der Product Owner kann so ein gemeinsames Verständnis mit seinen unterschiedlichen Stakeholdern schaffen. Die Story Map eignet sich außerdem gut, um der Dokumentation Struktur zu geben.
„Story Map als Projekt- und Produktdokumentation“ weiterlesen
Gerade in der Softwareentwicklung wird immer wieder von Personas gesprochen, wenn man kundenzentriert arbeiten möchte. Sie helfen die Rolle des Nutzers einzunehmen und so die Lösung bedarfsgerecht umzusetzen. Auch für die Dokumentation ist es wichtig zu wissen, für wen man schreibt, wenn man sich fokussieren möchte. „Bedarfsgerechte Dokumentation mit Personas“ weiterlesen
Dokumentation hat verschiedene Dimensionen. Man muss nicht nur wissen, was man wie dokumentiert und in welchem Umfang, sondern sollte auch mit verschiedenen Ausprägungen umgehen können. Eine App, die mit einer ähnlichen Fachlichkeit auf z.B. Android und iOS läuft, kann dabei schon zur unlösbaren Herausfoderung werden.
„Der Umgang mit Versionen und Varianten muss gelernt sein“ weiterlesen
In den letzten Blog-Beiträgen haben wir gesehen wann, welche Art, von wem dokumentiert werden muss. Aber wie bekommen wir Qualität in die Dokumentation und ist das überhaupt zwingend notwendig?
„Wie sich das Agile Mindset auf die Qualität der Dokumentation auswirkt“ weiterlesen
Agile Dokumentation 