Agile Dokumentation – Wie sich Entwicklung und Technische Redaktion optimal ergänzen

Agile Entwicklung hat sich als Methode für die Steuerung von Software-Projekten in den letzten Jahren zunehmend durchgesetzt. Im Kern der Methode steht dabei, dass die Entwicklung von Software-Komponenten nicht mehr von Anfang bis Ende durchgeplant wird. Stattdessen setzt man auf wiederholte, überschaubare Einzelschritte („Sprints“), an deren Ende Tests stehen. Das Teil-“Ergebnis“ wird dann bewertet und idealerweise Feedback von den Kunden eingeholt. Erst danach wird der nächste Schritt angegangen. So lässt sich bei einem Projekt schnell gegensteuern, wenn sich Anforderungen ändern oder es sich zeigt, dass eine angestrebte Lösung in der ursprünglich geplanten Form nicht umsetzbar ist.

Für agiles Arbeiten gibt es diverse Methoden: Kanban, Extrem Programming oder Scrum. Als vermutlich beliebteste Methode hat sich in den letzten Jahren der Scrum-Ansatz herausgestellt. In Scrum-Entwicklungsteams gibt es im Wesentlichen vier Rollen. Der "Product Owner" ist dafür zuständig, dass das Endprodukt so umgesetzt wird, dass es den Projektzielen entspricht. Dafür muss er (oder sie) auch laufend Feedback des "Kunden" bzw. Endnutzers (der zweiten Rolle) einholen. Denn oft wird erst im Lauf des Entwicklungsprojekts klar, welche Anforderungen sich aus der ursprünglichen Produktvision ergeben. Der "Scrum Master" (Rolle Nummer drei) organisiert das Projektteam nach innen, beseitigt Projekthindernisse und ermöglicht ein weitgehend reibungsloses Arbeiten. Das Projektteam stellt die vierte Rolle eines Scrum-Projekts. Dieses Team sollte möglichst viele verschiedene Fähigkeiten in sich vereinigen und neben den Entwicklern selbst auch Schnittstellen-Fachleute, Tester, 2nd-Level Support oder UX-Designer integrieren.

Technische Redakteure finden deshalb ihren Platz typischerweise im Projektteam. Sie können zusätzlich aber auch die Rolle des Product Owners gut ausfüllen, da sie gewohnt sind, Produkte aus der Perspektive des Anwenders zu betrachten. Allerdings gibt es (unter Entwicklern) immer wieder Diskussionen, ob Technische Redakteure überhaupt eine Rolle im Entwicklungsprozess spielen sollten. Das hat mit einer Forderung des "Agile Manifesto" zu tun. Dort wird nämlich von interner Dokumentation gefordert: „Working software over comprehensive documentation.“

Und das wird gerne so verstanden, dass man theoretisch Software auch ohne Dokumentation benutzen können soll. Allerdings zeigt sich in der Praxis, dass Software ab einem gewissen Komplexitätsgrad grundsätzlich auf Dokumentation angewiesen ist, wenn Benutzer auch die komplette Funktionalität nutzen sollen.

Es ist deshalb sinnvoll, dass Technische Redakteure in den Scrum-Teams eng integriert sind. Dies kann zwar manchmal eine organisatorische Hürde darstellen. Denn oft sind Redakteure nicht nur für eine Programm-Komponente zuständig, sondern für eine ganze Reihe von Anwendungen. Sie müssen deshalb in mehreren Scrum-Teams gleichermaßen Mitglied sein. Das kann im Einzelfall zu Termin- und Ressourcen-Konflikten führen. Hat man aber akzeptiert, dass Technische Redakteure eine wichtige Rolle spielen, dann lassen sich solche Konflikte (gegebenenfalls unter Mithilfe des Scrum-Masters) auch lösen.

Denn umgekehrt gewinnen die Scrum-Teams wertvolles Know-how. Nicht nur, dass Technische Redakteure die Arbeitsweise der Nutzer meist besser im Blick haben als Entwickler. Durch den Fokus ihrer Arbeit auf das Schreiben sorgen sie auch dafür, dass Terminologie aufgebaut und eingehalten wird, z. B. für die Benennung der Oberflächentexte. Letzten Endes helfen sie dadurch, dass die Lokalisierung der Software leichter gelingt, indem die Oberfläche einheitlicher und benutzerfreundlicher gestaltet wird.

Technische Redakteure wiederum gewinnen durch eine enge Einbindung in das Scrum-Team neue Handlungsmöglichkeiten. Sie erfahren direkter, wohin die Entwicklung der Software steuert und können ihre Schreibprozesse entsprechend steuern. In klassischen Entwicklungsprozessen ist die Technische Redaktion oft erst gegen Ende des Entwicklungsprozesses involviert, wo kaum noch Einflussmöglichkeiten bleiben. In agilen Teams können sie dagegen ihre Bedürfnisse einfacher zu Gehör bringen und frühzeitig warnen, wenn Design-Entscheidungen in der Software-Entwicklung zu erhöhtem Dokumentationsaufwand führen.

Dazu ist es aber notwendig, dass die Dokumentation als integraler Bestandteil des Produkts verstanden wird. Am besten geschieht dies dadurch, dass die Dokumentation definiert wird als Teil der „Definition of Done“ (dem Kriterienkatalog, anhand dessen beurteilt wird, ob ein Sprint erfolgreich abgeschlossen wurde). Minimalforderung ist hier, dass zumindest die Dokumentation genannt wird. Wesentlich sinnvoller ist es aber, wenn die verschiedenen Einzelaspekte der Dokumentation als eigene Punkte in der Definition of Done auftauchen, also z. B. „Oberflächentexte sind einheitlich benannt.“

Denn wenn diese enge Integration in die Scrum-Teams gelingt, dann gibt es tatsächlich auch keinen Gegensatz zwischen „agil“ und „dokumentiert“ – dann ist am Ende das Ergebnis nur „einfach gut“.