Dokumentation Technische Dokumentation im Scrum-Team

Auch die Technische Dokumentation lässt sich in die agile Softwareentwicklung mit Scrum einbeziehen. Dieser Beitrag erläutert, was dabei bedacht werden sollte.

Anbieter zum Thema

Vogel IT-Akademie

OutSystems

people text - Technische Dokumentation GmbH

Sobald sich ein Unternehmen dazu entschließt, nach der Scrum-Methode zu entwickeln, betrifft dies auch die Kollegen aus der Technischen Dokumentation. In diesem Zusammenhang stellen sich einige Fragen: Sollen die Technischen Redakteure auch mit dieser Methode arbeiten? Wie sieht die Zusammenarbeit aus? Welche Vorteile hat es, wenn Technische Redakteure im Team mitarbeiten und an den regelmäßigen Scrum-Meetings teilnehmen?

Wie sieht die Zusammenarbeit im Team aus?

Ein Scrum-Team besteht aus ungefähr neun Kollegen mit unterschiedlichen Qualifikationen, die zusammen für Design, Entwicklung, Test und Technische Dokumentation verantwortlich sind. Teamwork steht dabei im Vordergrund: Alle erledigen ihre Aufgaben in enger Abstimmung mit den anderen Teammitgliedern. Das gilt auch für die Technische Dokumentation. Im Rahmen von agiler Entwicklung ist die Dokumentation ein integraler Bestandteil des Produkts. Ohne Dokumentation gibt es kein Produkt.

Technische Redakteure sind jetzt Teil des Teams

Für Technische Redakteure, die früher der Marketingabteilung oder einer eigenen Abteilung angehörten, bedeutet dies eine gravierende Veränderung. Die Redakteure haben im Scrum-Team mehr Einblick in die Produktentwicklung und kommunizieren öfter mit den Entwicklern, auch informell. Der Rückhalt des Doku-Teams fehlt, die Redakteure müssen selbstständig arbeiten und Entscheidungen treffen. Da diese Arbeitsweise hohe Eigenverantwortung erfordert, kann Scrum für Mitarbeiter, die an hierarchische Strukturen gewöhnt sind, schwierig umzusetzen sein.

Durch die tägliche Kommunikation im Scrum-Meeting erhalten alle Teammitglieder einen Einblick in die Arbeit der anderen. Dadurch können Redakteure unkompliziert weitere Aufgaben übernehmen, beispielsweise User-Interface-Texte korrigieren oder Verbesserungen vorschlagen. Wenn regelmäßiger Kundenkontakt vorgesehen ist, können auch Redakteure davon profitieren: Sie bekommen ein direktes Feedback auf ihre Dokumentation und können diese dann anpassen, um die User Experience zu verbessern.

Spezielle Werkzeuge helfen den Teams dabei, die Arbeitspakete zu planen und jederzeit nachzuvollziehen. Die Arbeit ist transparent im Backlog eingetragen und in einzelne Items aufgeteilt, so dass Entwickler und Redakteure ihre Aufwände gut einplanen können.

Agile Entwicklung an verschiedenen Standorten

Wenn nicht alle Teammitglieder vor Ort zusammenarbeiten, bieten heutige Informationstechnologien effiziente Kommunikationsmöglichkeiten wie zum Beispiel Videokonferenzen oder Web-Meetings, um nur zwei zu nennen. Dies ist auch für Redakteure wichtig, weil sie meistens nicht auf die Entwicklungsumgebung zugreifen können und darauf angewiesen sind, am Informationsfluss teilzuhaben.

Im Rahmen der agilen Entwicklung stehen den Redakteuren nur noch wenige Spezifikationen als Informationsquelle zur Verfügung. Deshalb ist es wichtig, dass alle vorhandenen Informationen verfügbar sind. Ein Dokumentenmanagement-System hilft dabei, Dokumente mit Kommentaren, Webinare und andere Formate zu verwalten.

Darüber hinaus ist das Scrum-Meeting die ideale Gelegenheit, um auf dem Laufenden zu bleiben. Aus diesem Grund sollten Technische Redakteure von Sprint 1 an im Scrum-Team integriert sein. Die regelmäßige Durchsicht der Backlog-Items liefert Redakteuren ebenfalls Statushinweise für ihre Dokumentation. Redakteure sollten jederzeit Zugriff auf den aktuellen Build oder das Produkt haben, um die eigene Dokumentation zu testen und zu verifizieren.

Wie ändert sich die Arbeitsweise?

Durch die Prozesse der Scrum-Methode können Redakteure das Arbeitspensum besser einschätzen, weil sie nicht auf einen einzigen Abgabetermin hinarbeiten, sondern entlang von Backlog-Items dokumentieren. Unter Umständen ist es sinnvoll, das Dokumentieren einer Funktion in einen späteren Sprint zu verschieben, wenn beispielsweise die Entwicklung noch nicht so weit fortgeschritten ist, dass die Software lauffähig ist und getestet und beschrieben werden kann. Das Produkt und die Dokumentation werden zeitnah getestet, so dass Fehler schneller entdeckt werden und die Arbeit der Redakteure kalkulierbar ist.

Iterative Entwicklung: Zu den Prinzipien agiler Entwicklung gehört es, besonders früh und kontinuierlich Ergebnisse an den Kunden zu liefern. Änderungswünsche von Kundenseite setzt das Team so schnell wie möglich um.

Diese Anforderungen der iterativen Entwicklung machen deutlich, dass es nicht nur darum geht, innerhalb eines festgelegten Zeitraums regelmäßig zu liefern, sondern dass der Entwicklungsprozess selbst diesen Anforderungen folgen muss. Die technische Redaktion muss sich ebenso an diese Arbeitsweise anpassen.

Projektplanung: Die Projektleitung entwickelt einen Projektplan, der Sprints, Meilensteine und Deadlines umfasst. Dazu gehört beispielsweise ein Redaktionsschluss für die Dokumentation. An den regelmäßigen Scrum-Meetings sollten auch die Redakteure teilnehmen. So erfahren sie, welche Aufgaben abgeschlossen sind, welche verschoben werden müssen und wo eventuell Probleme aufgetreten sind, die auch sie betreffen.

Arbeitspakete schnüren: Bei der Arbeit nach dem Wasserfallprinzip haben die Entwickler oft keine Möglichkeit, ihre Besprechungen mit den Redakteuren zeitlich zu erfassen. Oft genug fällt diese Zeit einfach unter den Tisch. Im Scrum-Modus ist die Erstellung einzelner Texte ein Backlog-Item, mit dem auch die Position des Redakteurs im Team gestärkt wird: Review, Test und Aktualisierung der Dokumentation sollte in jedem Sprint berücksichtigt werden.

Die Erstellung der anfallenden Dokumentation kann nicht immer innerhalb eines Sprints abgedeckt werden. Es fallen Arbeiten an, die komplett unabhängig von zu programmierenden Funktionen sind, etwa die Informationsarchitektur der Dokumentation zu entwickeln oder organisatorische Aufgaben, die das Publizieren, Ausliefern oder Archivieren betreffen. Diese Aufwände sollten ebenfalls als Backlog-Item in den Projektplan aufgenommen werden.

Es kann jederzeit zu kurzfristigen Änderungen kommen, die berücksichtigt werden müssen. Die Zeit für ein Backlog-Item sollte so bemessen sein, dass die Redakteure diese Änderungen noch in ihre Dokumentation einarbeiten können.

Folgende Dokumentationsaufgaben müssen erledigt sein, damit ein Backlog-Item geschlossen werden kann:

• Die Funktion ist beschrieben.

• Software sowie Dokumentation sind getestet.

• Fehler, die vom Systemtest gemeldet wurden, sind entweder behoben oder die Behebung ist geplant.

Dann ist zu überlegen, welche Stände an den Kunden geliefert werden, so dass dieser optimale Informationen erhält. Für das Publizieren der Dokumentation werden Backlog-Items zum Ende eines Sprints angelegt, so dass korrekte Inhalte an den Kunden ausgeliefert werden.

Fortschritte machen und dabei den Überblick behalten

Redakteure müssen Inhalte auf eine Art und Weise erstellen und verwalten, die es erlaubt, die Dokumentation jederzeit anzupassen und zu liefern. Wenn Redakteure jedoch einzelne Kapitel oder Abschnitte aus dem Gesamtzusammenhang des Handbuchs an den Kunden abliefern, dann erscheinen diese oft zusammenhanglos. Darüber hinaus ist es mit einigem Aufwand verbunden, ein solches Handbuch überhaupt in einen akzeptablen Zustand zu bringen, um auch nur einen Draft zu liefern.

In der Praxis legen Redakteure leere Kapitel oder Bausteine an, die dann im Laufe der Sprints mit Inhalten gefüllt werden. Mit Statuszuweisungen können Redakteure den Überblick darüber behalten, welche Themen erledigt sind und welche noch nicht. Folgende Status sind denkbar:

• Leer

• In Arbeit

• Im Review

• Final

• In Übersetzung

Hier bietet sich der Einsatz eines Redaktionssystems an, das den gesamten Lebenszyklus Technischer Dokumentationen vielfältig unterstützt.

Gut organisiert im Redaktionssystem

Ein Redaktionssystem bietet spezielle Funktionen, die Redakteure bei der Erstellung, Verwaltung und Publikation unterstützen. Um diese Funktionen bei der Erstellung von Inhalten im Scrum-Modus sinnvoll zu nutzen, sollte eine Informationsarchitektur entwickelt werden. Eine Informationsarchitektur ist eine Struktur, die Informationen sinnvoll gestaltet und damit im Ergebnis die Nutzung der Information für eine bestimmte Zielgruppe vereinfacht.

Im Zusammenhang mit Scrum sind die folgenden Funktionen, die agile Anforderungen umsetzen, besonders interessant:

• Single Source Publishing: Wiederverwendbare Bausteine werden in einer Datenbank abgelegt. Diese Bausteine erlauben es, Dokumente flexibel zusammenzustellen und zeitnah zu publizieren.

• Variantenmanagement: Bausteine, Grafiken und andere Medien wie Videos werden klassifiziert und mit den entsprechenden Metadaten versehen. So können Redakteure einem Baustein einen Status zuweisen, zum Beispiel eine länderspezifische Zuordnung. Eine zielgruppenorientierte Publikation ist so jederzeit möglich.

• Versionsmanagement: Pro Sprint wird eine Version generiert und archiviert, so dass zu jeder Zeit nachvollziehbar ist, welche Funktionen dokumentiert sind und an den Kunden geliefert wurden.

Heike Bath

Der Einsatz von Metadaten bei Single Source Publishing und Variantenmanagement erfordert ein Konzept, das alle Anforderungen an den Lebenszyklus von Dokumentationen oder anderen Inhalten abbildet. Solch ein Konzept garantiert zudem den sicheren Einsatz von wiederverwendbaren Bausteinen und den dazugehörigen Metadaten. Mit einer Filterfunktion können Sie zudem jederzeit einen aktuellen Draft publizieren.

* Heike Bath ist Mitinhaberin von people text – Technische Dokumentation. Im Team ist sie Spezialistin für Business-Kommunikation.

Dieser Beitrag ist ursprünglich auf unserem Schwesterportal Embedded-Software-Engineering.de (eine Publikation von Elektronikpraxis.de) erschienen.

Quellen:

• Baker, Mark: Toward an Agile Tech Comm, in: intercom November/December 2014, Seiten 25-28

• Burkhardt, Remo Aslak, Informationsarchitektur, Januar 2008, DOI: 10.1007/978-3-540-69818-0_12 Source: OAI, https://www.researchgate.net/publication/36381063

• Gale, P. & Smith, K., Agile for Technical Communication, in: intercom November/December 2014, Seiten 7-9

• http://agilemanifesto.org/iso/de/principles.html, (abgerufen 20.12.2016)

• International Standard ISO/IEC/IEEE 26515:2012(E): Systems and software engineering – Developing user documentation in an agile environment.

(ID:44530988)