Software wird zunehmend in agilen Prozessen entwickelt, die zum Beispiel auf Scrum basieren. Das agile Prinzip beinhaltet unter anderem, dass die Entwicklungsarbeit in kleinere Aufgaben unterteilt wird, die in sich abgeschlossen sind und in regelmäßigen Zeitabständen präsentiert werden. Zum Zeitpunkt der Präsentation soll die Software die jeweils geplanten neuen Features enthalten und lauffähig sein. Das Team ist relativ klein, organisiert sich selbst, arbeitet eng zusammen und tauscht sich oft aus.
Wenn ein Team die Software agil entwickelt, wird das oft nur auf die Entwickler und Tester bezogen. Die Benutzerdokumentation bleibt manchmal außen vor, und wird nachgelagert geschrieben, eventuell auch von externen Dienstleistern, die erst spät dazu kommen. Die Benutzerdokumentation ist jedoch Teil des Produkts, der Dokumentationsexperte ist Teil des Entwicklungsteams, auch wenn das in Scrum nicht explizit gemacht wird:
„Scrum never defines more specific roles than Development Team as the products being developed by any Development Team are never the same. Scrum only tells you that everyone who is involved in developing the software is within the Development team. And bear in mind that software development includes design, documentation and QA — NOT only coding/programming.“ aus: https://www.scrum.org/resources/blog/who-are-professional-scrum-developers (Stand Februar 2018).
„Ein Entwicklungsteam sollte in der Lage sein, das Ziel eines jeweiligen Sprints ohne größere äußere Abhängigkeiten zu erreichen. Deshalb ist eine interdisziplinäre Besetzung des Entwicklungsteams wichtig, z. B. mit Architekt, Entwickler, Tester, Dokumentationsexperte und Datenbankexperte.“ Aus: https://de.wikipedia.org/wiki/Scrum (Stand Februar 2018).
Informationen, die im Laufe der Entwicklung entstehen, wie die Beschreibung von User Stories, können für die Benutzerdokumentation genutzt werden. Typischerweise werden die Anforderungen an die Software – die Akzeptanzkriterien – aus der Perspektive der Anwender beschrieben.
„Akzeptanzkriterien sind Bedingungen, die die Software erfüllen muss, um die Bedürfnisse der Kunden zu befriedigen. Der Product Owner schreibt Aussagen aus Sicht des Kunden auf, die erklären, wie eine User Story oder ein Feature funktionieren sollte. “ Aus: https://www.scrumakademie.de/scrum-lexikon/akzeptanzkriterien-2/ (Stand Februar 2018).
Damit kann eine gut formulierte Anforderung schon die Grundlage der Benutzerdokumentation sein. Je besser hier die Beschreibung ist, desto weniger Aufwand gibt es später bei der Wissensvermittlung.
Erfahrungsgemäß funktioniert das nicht immer so gut; manchmal werden die Anforderungen nur angerissen und nicht detailliert beschrieben. Umso wichtiger ist dann die Integration des Dokumentationsexperten in das Team und die Teilnahme an den Treffen.
- Während des Sprint Planning erfährt der Dokumentationsexperte, welche Aufgaben im nächsten Sprint anstehen. In der Diskussion über die Anforderungen und deren Umsetzung kann der Dokumentationsexperte Wissen beitragen und die Benutzerperspektive vertreten. Außerdem erweitert er/sie hier die eigenen Produktkenntnisse und bekommt bereits den ersten Input für die Dokumentation. Bei großer Detailtiefe in der Diskussion kann anschließend schon mit dem Schreiben begonnen werden.
- Beim Sprint Review sieht der Dokumentationsexperte, wie die Anforderung tatsächlich umgesetzt wurde und kann anschließend die Dokumentation zum Thema abschließen. Die iterativ erstellte Dokumentation wiederum kann für Testfälle genutzt werden.
Wir haben die Erfahrung gemacht, dass eine konsequente Einbindung der technischen Redaktion in das Scrum-Team die Dokumentation sehr erleichtert und auch zur Qualität der Software beiträgt.
Konsequente Einbindung in das Team bedeutet die aktive Teilnahme an allen Treffen wie Standup, Planning, Review, Retrospective. Der technische Redakteur wird als vollwertiges Team-Mitglied betrachtet.
Gegen die Einbindung des Dokumentationsexperten und Teilnahme an Treffen spricht bei den Geldgebern die dafür verwendete Zeit. Auch das Argument, dass es zu technisch ist und der Dokumentationsexperte das alles nicht wissen muss, wird gerne genannt.
In Wirklichkeit spart die Einbindung des Dokumentationsexperten jedoch Zeit und Nerven, auch bei den anderen Team-Mitgliedern, und erhöht die Qualität:
- Der Dokumentationsexperte kennt das Produkt genauso gut wie die anderen Mitglieder und braucht nur minimale Wissensvermittlung durch die anderen Team-Mitglieder.
- Der Dokumentationsexperte kennt die Anwenderperspektive und trägt so zu einer benutzerfreundlichen Software bei. Er/sie ist in der Regel sprachlich versiert und sorgt für eine durchgängige Terminologie.
Links
https://de.wikipedia.org/wiki/Agile_Softwareentwicklung
https://de.wikipedia.org/wiki/Scrum