Agil schneller zum Ziel

Software wird heutzutage häufig agil entwickelt. Das agile Versprechen, Software schneller entwickeln und bereitstellen zu können, betrifft auch die Technische Dokumentation von Softwareprodukten und -dienstleistungen. Agile Methoden ändern zwar nicht die Inhalte und Anforderungen an Softwaredokumentation an sich, sie können aber die Struktur, den Erstellungsprozess und die Auslieferung beeinflussen.

Dieser Artikel widmet sich den Besonderheiten der Softwaredokumentation im agilen Umfeld: Wie kann man Prozesse für eine agile Softwaredokumentation aufsetzen? Wie kann sich ein Redaktionsteam auf ein agiles Umfeld einstellen? Zur agilen Softwareentwicklung gibt es inzwischen jede Menge Informationen, aber für die entsprechende Dokumentation sieht es schlecht aus.

Selbst auf zwei offensichtliche, konkrete Fragen scheint es keine eindeutigen Antworten zu geben: Kann agile Dokumentation mit der Entwicklung Schritt halten oder ist es in Ordnung, einen Sprint hinterherzuhinken? Und wie viele agile Teams kann eine Person in der Technischen Redaktion eigentlich bedienen?

Die Antwort auf beide Fragen lautet: Es kommt darauf an. (Spoiler: Ob synchron oder einen Sprint versetzt, ist beides möglich, je nachdem, wie Sprints und Veröffentlichungszyklen organisiert sind. Und viele Technische Redakteure und Redakteurinnen können ihre Teams an einer Hand abzählen.)

Außerdem zeigt dieser Artikel, wie die Technische Redaktion ihre Prozesse anpassen und ihre Teams auf agile Softwaredokumentation ausrichten kann. Nach dem Einstieg über das agile Mindset der engen Teamarbeit lesen Sie über agile Konzepte wie Flow-Kontrolle, Minimum Viable Product und agile Meetings. Zum Schluss folgen einige Gedanken zur agilen Weiterentwicklung eines Dokumentationsteams.

Wir können keine Gedanken lesen!

Wenn Sie erstmals in einer agilen Umgebung oder mit einem agilen Team arbeiten, sind Sie vielleicht überrascht, dass Informationen für Ihre Technische Dokumentation so vage und fragmentiert sind, dass sie nutzlos erscheinen. Wenn Ihre Kollegen und Kolleginnen ansonsten hilfsbereit sind, dann könnte das am agilen Ansatz liegen. Dabei schreitet die Entwicklung in kleinen, überschaubaren Aufgaben voran und schiebt Entscheidungen oft auf, bis die anstehende Aufgabe sie erfordern. Daher sagt Ihnen eine Entwicklerin womöglich, dass sie gerade ein neues Feld in einem Fenster erstellt hat, aber wie genau dieses Feld funktioniert und wo die Ergebnisse zu sehen sind, ist noch nicht entschieden.

In solchen Fällen würde Ihnen auch Gedankenlesen nicht helfen. Sie können sich jedoch die inkrementelle agile Arbeitsweise zu eigen machen: Begleiten Sie das Team bei der Erforschung und den Verbesserungen während des agilen Entwicklungsprozesses. Festgelegte Richtlinien und Abläufe wie im Wasserfall-Modell funktionieren agil nicht so gut. Eine enge Zusammenarbeit mit dem Team ist meistens konstruktiver – auch wenn die sich von Team zu Team unterscheiden kann.

In einem Team ist vielleicht der agile Product Owner, der sich auf den funktionalen Mehrwert konzentriert, Ihr Hauptansprechpartner für Informationen und Freigabe der Dokumentation. In einem anderen Team kann das eine Testerin mit einem Auge für technische Details sein. Egal, mit wem Sie eng zusammenarbeiten, die Aufgabe bleibt dieselbe, nämlich sicherzustellen, dass die Dokumentation für alle Teams und Features letztendlich vollständig ist.

Agile Dokumentationserstellung

Die Aufteilung der Softwareentwicklung in kleine Häppchen wird durch den agilen Prozess unterstützt. Das Arbeitspensum wird in Sprints von beispielsweise zwei Wochen organisiert, um die anstehende Arbeit an die verfügbaren Kapazitäten in Entwicklung und Test anzupassen. Tägliche Stand-up-Meetings ermöglichen eine gleichmäßige Verteilung der Aufgaben und zielen darauf ab, Wartezeiten und Verschwendung zu reduzieren.

Sie können zum Beispiel Input aus den Stand-up- und Sprint-Review-Meetings des Teams und aus dem Ticket-Tracking-System sammeln, das von den Entwicklern verwendet wird. Dies hilft Ihnen, alle Entwicklungs- und Design-Entscheidungen im Auge zu behalten, sobald sie getroffen werden. Wenn ein Feature fertig ist, können Sie die Technische Dokumentation schreiben, überprüfen, genehmigen lassen, bearbeiten und veröffentlichen. Das entspricht weitgehend dem Wasserfall-Modell. Ein Vorteil ist, dass Sie für jedes Feature nur einmal Hand an die Dokumentation zu legen brauchen. Möglicherweise sind auch Ihre Prozesse und Systeme für diesen Ansatz optimiert.

Der Nachteil ist, dass die Dokumentation zeitlich aus dem Takt gerät. Wenn Sie Ihre Inhalte zur Überprüfung und Freigabe zurückspielen, ist das Team bereits weitergezogen. Möglicherweise wurde eine Version der Software auch schon veröffentlicht – gegebenenfalls ohne die passende Dokumentation. Oder die Veröffentlichung verzögert sich, weil die Dokumentation „mal wieder nicht fertig ist“.

Synchron im Fluss

Ein alternativer, agiler Ansatz zur Dokumentationserstellung kann diese Risiken mindern, wenn Sie die Dokumentation für jede Teilaufgabe erstellen, während sie gerade bearbeitet wird. Ein Feature, das in mehrere kleine „Development Stories“ aufgeteilt ist, können Sie pro Story dokumentieren, so wie auch jede Story einzeln getestet wird (und manche Stories brauchen gegebenenfalls auch gar keine Dokumentation). Die Teams unterstützen diesen Prozess in ihrem eigenen Interesse, indem sie die Features in sinnvolle Stories aufteilen. Und wenn eine Story lediglich ein Kontrollkästchen, zunächst ohne weitere Funktionalität, erstellt, dann wird Ihre Technische Dokumentation auch kaum mehr als einen Satz über die Existenz des Kontrollkästchens enthalten.

Dieser Ansatz stellt sicher, dass Entwicklung, Test und Dokumentation synchron bleiben. Die Zusammenarbeit mit dem Entwicklungsteam wird einfacher, da Sie alle gleichzeitig an derselben Story arbeiten. Und wenn eine Story fertig ist, ist sie auch tatsächlich fertig und kann sofort ausgeliefert werden, natürlich zusammen mit der passenden Technischen Dokumentation. Dies ist für manche Software unerlässlich, wie beim Continuous-Delivery-Ansatz, zum Beispiel von webbasierten Diensten.

Der agile Ansatz bringt ein paar Besonderheiten mit sich: Erstens werden alle Umwege der Entwicklung auch von Test und Dokumentation mitvollzogen. Wenn sich die Funktion oder das Format eines Feldes nach zwei Wochen ändert, muss es auch neu getestet und dokumentiert werden. Solche unnötigen Aufwände können aber oft durch enge Zusammenarbeit im gesamten Team, einschließlich Test und Technischer Redaktion, vermieden werden.

Zweitens erfordert der agile Ansatz, dass Dokumentationsprozesse und -systeme ebenso schnell sind wie die Auslieferung der Software an sich. Continuous Delivery-Prozesse werden in der Regel durch eine DevOps-Pipeline unterstützt. Durch Automatisierung beschleunigt sie die Softwareentwicklung und -bereitstellung und reduziert Risiken. Die Dokumentation benötigt dann eine ähnliche oder die gleiche Pipeline.

Der gewählte Ansatz entscheidet dann auch darüber, ob Sie synchron mit der Softwareentwicklung bleiben oder ob die Technische Dokumentation hinterherhinkt. Wird die verzögerte Fertigstellung der Dokumentation in Kauf genommen, dann ist es sehr empfehlenswert, sich auf einen stabilen Versatz zu einigen. Damit wird gewährleistet, dass die Dokumentation beispielsweise einen Sprint von zwei Wochen hinterherhinkt, aber nicht länger. Andernfalls wird ein zuverlässiges Management von Dokumentationsaufwänden und -terminen unwägbar.

Möglichst früh ein Minimum

Das Konzept eines „Minimum Viable Product“ (MVP) passt sehr gut zum inkrementellen Arbeiten, und viele agile Unternehmen nutzen es, um die Produktentwicklung zu staffeln. Ziel ist es, so früh wie möglich eine erste Version eines Produkts oder einer Funktionalität mit minimalem Umfang zu veröffentlichen, um Feedback vom Markt einholen zu können. Gängige Metaphern sehen in der ersten Ausbaustufe ein Skateboard vor. Als nächstes wird ein Tretroller ausgeliefert, dann ein Fahrrad, dann ein Motorrad, bis man schließlich ein Auto anbieten kann (Abb. 01).

Abb. 01 Das Konzept des "Minimum Viable Product" vereinfacht dargestellt. [1]

Wie andere agile Konzepte beeinflussen auch MVPs die Art und Weise, wie Dokumentation erstellt wird. Glücklicherweise kennt die Technische Redaktion ein entsprechendes Konzept, nämlich den Minimalismus. Dieser Ansatz bedeutet nicht nur, kurz und präzise zu schreiben, sondern auch, Nutzer zu ermutigen, schnell selbst Hand anzulegen und zu lernen, mit dem Vorhandenen umzugehen. Minimalismus ergänzt daher perfekt den Ansatz, schnell ein MVP auf den Markt zu bringen.

Das MVP-Konzept legt auch eine Struktur für agile Softwaredokumentation nahe. MVPs verwenden oft wiederkehrende Module. Im Sinne der Metaphern sind das zum Beispiel ein Kettenantrieb, der von Fahrrad und Motorrad gemeinsam genutzt wird. Oder ein Motor, der sowohl das Motorrad als auch das Auto antreibt. Um die Erstellung und Pflege von Inhalten entlang der inkrementellen Entwicklung überschaubar zu halten, eignet sich ein modularer Ansatz wie das Topic-basierte Schreiben sehr gut. Die Organisation von Inhalten in diskreten, eigenständigen Modulen macht es viel einfacher, die Dokumentation für eine Iteration fertigzustellen und später weitere Topics für die nächste Version hinzuzufügen.

Kriterien für den Meeting-Besuch

Agile Entwicklung erfordert scheinbar viele Meetings mit all den Stand-ups oder auch den Sprint-Review-Meetings zur Demonstration der entwickelten Software. Wenn Sie die Zeit all dieser Meetings multiplizieren mit der Anzahl der Entwicklungsteams, die Sie betreuen, stellt sich die Frage, wann noch Zeit für irgendeine Inhaltserstellung bleiben soll? Denken Sie dann daran, dass der Grund für diese Meetings ist, die Kommunikation zwischen allen Beteiligten zu ermöglichen und zu fördern – und wenn das nicht gegeben ist, gibt es auch keinen Grund, daran teilzunehmen.

Welche der agilen Meetings für die Technische Redaktion einen Besuch wert sind, hängt davon ab, wie ein Team sie durchführt. Die folgenden Meetings können hilfreich sein:

• Es lohnt sich, mindestens ein- oder zweimal pro Woche am Stand-up eines Teams teilzunehmen, um zu erfahren, welches Feature gerade dran ist und welche Erwartungen das Team und Sie an die erforderliche Dokumentation haben.
• In Sprint-Planning-Meetings erfahren Sie, an welchen Features demnächst gearbeitet werden soll, so dass Sie die erforderlichen Dokumentations­aufwände abschätzen können. (Allerdings können sich diese Pläne spontan ändern; aber das würden Sie dann im Stand-up erfahren.)
• Sprint-Review-Meetings können Ihnen zeigen, wie und wie weit das Team ein Feature entwickelt hat. So können Sie überprüfen, ob die Dokumentation angemessen beschreibt, was gebaut wurde und wie es verwendet werden soll.
• Team-Retrospektiven können hilfreich sein, um die Zusammenarbeit mit dem Team anzupassen oder zu verbessern, zum Beispiel, wenn Kommunikation oder Prozesse nicht so gut funktionieren, wie sie sollten.

Die Anzahl der Entwicklungsteams pro Person hängt von verschiedenen Fragen ab. Einige sind recht offensichtlich: Wie viel Dokumentationsarbeit fällt in den einzelnen Teams an? Und wie komplex und langwierig sind diese Aufgaben? Die Schwierigkeit besteht darin, eine zuverlässige Schätzung aufzustellen. Manchmal arbeitet ein Team an Features „unter der Motorhaube“, die wenig oder gar keine Dokumentation erfordern. In einem anderen Team kann ein neues Produkt ein komplett neues Handbuch für einen neuen Markt erfordern, was größeren Arbeitsaufwand bedeutet. Wenn Ihre Teams regelmäßig und zuverlässig zur Dokumentation beitragen, kann das Ihre Schätzungen verbessern und Ihre Recherche- und Schreibaufwände reduzieren.

Ein weiterer Faktor ist umso wichtiger, je mehr Teams beteiligt sind: die Zeit für den Kontextwechsel. Das ist die mentale Belastung, wenn Sie zwischen verschiedenen Teams, Produkten und Teamkulturen hin- und herschalten. Da gibt es keine allgemeingültige Empfehlung. Eine oft genannte Größe ist jedoch, dass viele Technische Redakteure und Redakteurinnen zwei bis vier agile Teams betreuen.

Auf dem Weg zur agilen Redaktion

Jenseits der Anpassung von Redaktionsprozessen und -systemen an das agile Umfeld ist es sinnvoll, sich als Team aller Technischen Redakteure und Redakteurinnen agile Prinzipien anzueignen. Das gilt unabhängig davon, ob Sie in einem Redaktionsteam organisiert sind oder in einer Abteilung oder ob einzelne Mitarbeiter und Mitarbeiterinnen verschiedenen Teams zugeordnet sind.

Es ist auf jeden Fall empfehlenswert, sich zu organisieren, und sei es nur als informelle „Community of Practice“ (CoP), also eine Gemeinschaft, die ähnliche Aufgaben und Interessen hat. Wichtig ist, dass Technische Redakteure und Redakteurinnen eine Möglichkeit haben, gemeinsame Standards und Praktiken zu entwickeln und zu teilen. Schließlich sind ein Redaktionsleitfaden, eine zuverlässige Systemlandschaft sowie robuste Erstellungs- und Veröffentlichungsprozesse auch im agilen Umfeld die unerlässliche Stütze der Redaktionsarbeit.

Ein paar Tipps können der agilen Technischen Redaktion nützen:

• Erwägen Sie den Einsatz agiler Zyklen und Meetings für Ihre eigene CoP, um im Austausch miteinander zu bleiben: Im Stand-up, und sei es nur wöchentlich, erfahren Sie, was die andern tun und wer Hilfe gebrauchen oder anbieten kann. Eine eigene Retrospektive, vielleicht monatlich, kann Ihnen helfen, Prozesse oder Fragestellungen mit Entwicklungsteams oder untereinander zu verbessern.
• Schaffen Sie sich professionelle Entwicklungsmöglichkeiten: Agiles Arbeiten kann wie ein Hamsterrad erscheinen, insbesondere für Technische Redakteure und Redakteurinnen, die viele Teams betreuen. Stellen Sie sicher, dass Sie Ihre berufliche Entwicklung nicht vernachlässigen. Sie können zum Beispiel Zeit reservieren, um Ihre Prozesse zu verbessern oder weiter­zuentwickeln und um gemeinsam voneinander zu lernen. Die Möglichkeit, sich ein- oder zweimal im Jahr zu einem Workshop zu treffen, um zu diskutieren, sich weiterzuentwickeln und einfach nur Zeit miteinander zu verbringen, kann ebenfalls sehr fruchtbar sein.

Zusammenfassend lässt sich sagen, dass ein agiles Umfeld vielfältige Anforderungen an die Technische Redaktion stellt. Größtenteils betreffen sie die Prozesse und die Kommunikation, das heißt, wie Technische Redakteure und Redakteurinnen mit den Entwicklungsteams zusammenarbeiten. Je nach der Taktung von Entwicklungs- und Veröffentlichungszyklen für die Software stellen agile Methoden auch neue Anforderungen an die Automatisierung und den Durchsatz von Redaktionssystemen. Erfolgreiche agile Softwaredokumentation zeichnet sich dadurch aus, dass sie all diese Aspekte berücksichtigt.

Link zum Artikel

[1] Teemu/Own work: CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=65494330