Agile Dokumentation - funktioniert das? Ein Praxisbericht Teil 2

Das Stichwort agil ist in der Softwareentwicklung mindestens so beliebt wie DITA in der Technischen Dokumentation. Kein Wunder: Agil und DITA konzentrieren sich auf Modularisierung und die Anforderungen der Nutzer. Dieser Artikel beleuchtet, wie agiles Dokumentieren in der Praxis funktioniert.
Im ersten Teil des Artikels stellten wir Scrum mit ein paar Kernelementen vor. Im zweiten Teil erläutern wir weitere Kernelemente und was diese für die Redaktion bedeuten.

Scrum-Meetings

Regelmäßig stattfindende Scrum-Meetings (Dailys, Planning, Retrospektiven) stellen sicher, dass alle Teammitglieder jederzeit über den Stand der Entwicklung und die weitere Planung informiert sind. Die Technischen Redakteure nehmen an so vielen dieser Meetings teil wie möglich, da sie hier die meisten Informationen für die Dokumentation erhalten und direkte Ansprechpartner für Rückfragen und Reviews verfügbar sind. Kann der Redakteur an diesen Meetings nicht teilnehmen, gibt es idealerweise einen Stellvertreter, z.B. den Scrum Master, der die Belange der Redaktion vertritt und Informationen weitergibt.

Darüber hinaus haben die Redakteure häufig weitere Regelmeetings mit den anderen Redakteuren (horizontales Team). In diesen Meetings berichten die Technischen Redakteure aus ihren Projektteams und verständigen sich z.B. auf Formulierungen, Benennungen, Struktur und Layout.

Daily Standups, Demos und Backlogs ermöglichen einen direkten Informationsfluss. Feedback fließt in alle Richtungen (Reviews, Retrospektiven). Als Mitglieder der Scrum-Teams haben die Technischen Redakteure Einfluss auf das Design der Software und geben Usability-Beratung. Gleichzeitig stehen sie von Anfang an für sprachliche Fragen zur Verfügung und können z.B. beim Benennen der Bedienelemente helfen (Stichwort Konsistenz).

Häufige Reviews innerhalb des Teams stellen sicher, dass alle Technischen Redakteure auf demselben Wissensstand sind. Eine stetige Anpassung der Herangehensweise ist in einer lebendigen Scrum-Umgebung essentiell.

Wichtig: Viele Teams und viele Meetings erfordern ein hohes Maß an Zeit- und Organisationsmanagement. Oft muss ein Redakteur mehrere Entwicklungsteams betreuen. Das ganze System kommt außerdem schnell aus dem Gleichgewicht, wenn die Redakteure neben dem Schreiben zusätzliche Aufgaben haben, die parallel anfallen und z.B. die Teilnahme an Teammeetings verhindern.

 

Räumliche Anordnung

Für die räumliche Anordnung gibt es viele verschiedene Modelle. Manche Scrum-Teams sitzen im selben Raum, während andere über verschiedene Zeitzonen und Kontinente hinweg kommunizieren. Als Redakteur hat man das Dilemma, dass man sich einerseits mit den Kollegen aus der Redaktion und andererseits mit den Scrum-Teams eng austauschen muss. Ob man dazu direkt nebeneinander sitzt oder nicht, ist eine individuelle Entscheidung. Wichtig ist, dass eine direkte und einfache Kommunikation jederzeit gewährleistet ist.

Häufige Änderungen

Die Akzeptanz von Änderungen ist ein wesentlicher Bestandteil agiler Methoden. Daher lässt es sich nie ganz vermeiden, Texte neu zu schreiben. Allerdings kann man diese Fälle auf ein Minimum beschränken, indem z.B. in den Teams darauf geachtet wird, dass die User-Interface-Designer frühzeitig in die Entwicklung neuer Features eingebunden werden und grafische Konzepte in Form von Wireframes u.Ä. erstellen, auf deren Grundlage die Dokumentation geplant wird. Geht man außerdem davon aus, dass ein Feature am Ende eines Sprints auch wirklich fertig ist und dass die Tragfähigkeit des Konzepts laufend überprüft wird, sollte die Dokumentation ebenso final schreibbar sein.

Aufgrund der sequentiellen Fertigstellung von Features können die Technischen Redakteure grundsätzlich schon früh mit dem Dokumentieren beginnen. Die im ersten Teil beschriebenen Doc Tasks und das Verschieben der eigentlichen Dokumentation auf den nächsten Sprint helfen vielen Redaktionen dabei, auch in Bezug auf die Dokumentation agil zu bleiben.
Einige Scrum-Teams bereiten im Sprint neue Features konzeptionell so gut vor, dass die Redakteure die Dokumentation anhand der Konzepte schreiben können, während parallel implementiert wird. Diese Vorgehensweise stellt die Königsklasse der agilen Entwicklung dar und sollte das Idealziel aller Scrum-Teams sein.

Übersetzung

Die zeitnahe Fertigstellung von Übersetzungen ist und bleibt ein Problem, für das man gegebenenfalls die Anforderungen anpassen muss. Moderne Redaktionssysteme auf XML-Grundlage und professionelle Übersetzungstools ermöglichen die sequentielle Übersetzung einzelner Module (Topics). Topics, die zu einer bestimmten User Story geschrieben wurden, können dann gleich in die Übersetzung gehen. Dennoch: Was noch nicht geschrieben wurde, kann auch nicht übersetzt werden. Daher erfolgt die Übersetzung in der Regel mindestens einen Sprint später als das Schreiben der Dokumentation. Allerdings haben die Übersetzer dann das Problem, dass sie einzelne Topics ohne Zusammenhang bekommen, worunter möglicherweise Qualität und Konsistenz leiden. Daher ist es durchaus legitim, mit der Übersetzung erst gegen Ende des Entwicklungsprozesses zu beginnen, sofern ausreichend Zeit dafür vorhanden ist.

Fazit

Agile Entwicklungsumgebungen bieten Technischen Redakteuren die Chance, sich gleichberechtigt in den Entwicklungsprozess einzubringen und das Produkt mitzugestalten. Dies funktioniert aber nur, wenn die Dokumentation als fester Produktbestandteil in der Unternehmenskultur verankert ist. Manchmal dauert es Jahre, bis sich eine Redaktion diesen Status erkämpft hat. Gleichzeitig werden die Redakteure durch die modulare und hoch agile Vorgehensweise vor neue Herausforderungen gestellt, für die mitunter sehr individuelle Lösungen gefunden werden müssen. Wer die Technische Redaktion als echte Schnittstellenfunktion begreift, wird sich in einer gut geölten Scrum-Umgebung wohl fühlen und ergreift vielleicht sogar die Chance, seine oder ihre vielfältigen Talente in der Rolle eines Product Owners oder Scrum Masters gewinnbringend einzusetzen.

Die Autorin:

Marion Knebel, Technical Communicator bei der parson AG