Agile Dokumentation – funktioniert das? Ein Praxisbericht. Teil 1

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.

Was ist Scrum?

Scrum ist ein agiles Vorgehensmodell in der Software-Entwicklung, nach dem ein komplexes Produkt in Inkrementen entwickelt wird. Scrum-Teams können Produkte in kürzeren Zyklen fertigstellen und Feedback schneller einholen und einarbeiten.
Scrum basiert auf drei Grundprinzipien: Transparenz, Überprüfung und Anpassung. An die Stelle einer Feinspezifikation tritt das Product Backlog, eine priorisierte Liste der gewünschten Funktionalitäten (Anforderungen) aus Anwendersicht. Diese werden als User Storys bezeichnet.
Für die Technische Redaktion ergeben sich viele Fragen in Bezug auf den Arbeitsalltag. Das agile Modell als solches liefert keine Antworten auf diese Fragen. Aber es erlaubt individuelle Lösungen, solange diese den Grundprinzipien nicht widersprechen.

Scrum-Projekt (Quelle: parson AG)

 

Iterative Entwicklung: Sprints
Anders als bei einem traditionellen Projekt nach dem Wasserfallmodell wird am Anfang des Projekts nicht davon ausgegangen, dass alle User Storys umgesetzt werden können. Im Laufe eines Scrum-Projekts werden zunächst die hochpriorisierten User Storys umgesetzt und abgeschlossen. Die Produktentwicklung erfolgt in kurzen Iterationen (Sprints). In jedem Sprint werden die verbleibenden User Storys neu betrachtet und mit der verfügbaren Zeit und den Ressourcen der Teams abgeglichen. Der genaue Funktionsumfang des fertigen Produkts steht damit erst gegen Ende des Projekts fest.

Während des Projekts wird immer wieder überprüft, ob die gewählten Konzepte passen. Erweist sich ein Konzept als ungeeignet, wird es geändert, bis die gewünschte Qualität erreicht ist. Erst wenn eine Funktionalität fertig entwickelt, getestet und dokumentiert ist, werden weitere Funktionalitäten in Angriff genommen.

Das Scrum-Team

Im Kern der agilen Softwareentwicklung steht das Entwicklungsteam oder Scrum-Team. Es entscheidet darüber, wie Funktionalitäten aus dem Product Backlog umgesetzt werden.
Mitglieder der Entwicklungs- bzw. Scrum-Teams sollten sein: Product Owner, Scrum Master, Entwickler, Mitarbeiter der Qualitätssicherung (QA) und Technische Redakteure. Je nach Organisation und Art des Produkts kommen gegebenenfalls weitere Rollen wie User-Interface-Designer hinzu.
Die meisten Absprachen im Scrum-Team erfolgen mündlich, z.B. in Plannings und Daily Standups. Am Ende jedes Sprints soll ein release-fähiges Produkt verfügbar sein. Gehört die Endbenutzerdokumentation zum Produkt, muss diese zeitgleich mit der Entwicklung fertig sein.

Idealerweise gibt es mindestens für die Dauer des Projekts feste Teams, sodass sich die Mitglieder aufeinander einspielen können und mit der Zeit immer effizienter als Team werden. Das Team ist als Gruppe verantwortlich für die Umsetzung der User Storys, zu der auch die Dokumentation gehört. Benötigt der Redakteur Unterstützung in Form von Informationen, Demos oder Reviews, müssen diese Aufwände bei der Sprintplanung berücksichtigt werden. Wenn am Ende des Sprints nur noch Test- und Dokumentationsaufgaben übrig sind, können die Entwickler bei diesen Aufgaben helfen statt neue User Storys in Angriff zu nehmen.

Zusätzlich zu den Scrum-Teams gibt es möglicherweise weitere Teamstrukturen, da sich Kollegen derselben Fachrichtung, z.B. QA, Technische Redakteure und User-Interface-Designer, projekt- und teamübergreifend austauschen und über Arbeitsweisen abstimmen. Man kann die Scrum-Teams als vertikale Teams und die fachlichen Teams als horizontale Teams begreifen.

Definition of Done
Elementarer Bestandteil von Scrum ist die Definition of Done (DoD). Die DoD ist eine Art Checkliste der Bedingungen, die erfüllt sein müssen, damit eine User Story abgeschlossen werden darf. Die Dokumentation sollte ein fester Bestandteil der DoD sein. Das heißt, ein Feature ist erst dann fertig, wenn es auch dokumentiert ist. Wenn alle Stakeholder und Teammitglieder diesen Gedanken verinnerlicht haben, ist es viel einfacher, im Team Unterstützung für Dokumentationsaufgaben zu erhalten.

Trotzdem ist es immer möglich, die tatsächliche Endbenutzerdokumentation im selben Sprint fertig zu stellen. Als Workaround kann man für das Schreiben der Endbenutzerdokumentation eigene User Storys anlegen, die von der eigentlichen Entwicklungsaufgabe getrennt sind, aber mit dieser in Zusammenhang stehen. Die ursprüngliche User Story hat dennoch eine Dokumentationsaufgabe (Doc Task), die die Entwickler nutzen, um für die Redakteure Stichpunkte für die Endbenutzerdokumentation vorzuschreiben. Diese Doc Tasks bilden dann die Grundlage für die User Storys, die den Technischen Redakteuren zugewiesen werden, und so zeitnah wie möglich abgearbeitet werden – am besten im nächsten Sprint.

User Storys schreiben und beschreiben
User Storys erleichtern das aufgabenbasierte Dokumentieren von Features. Sie stellen eine wichtige Grundlage für die Endbenutzerdokumentation dar, auch wenn sie sich nicht immer 1:1 in der Dokumentation abbilden lassen. Anders als manche Entwickler sind Technische Redakteure es gewohnt, neue Features aus dem Blickwinkel der Endbenutzer zu betrachten. Je mehr die Redakteure in das Schreiben der User Storys im Backlog eingebunden werden, desto besser eignen sich diese als Grundlage für die Endbenutzerdokumentation.

User Storys (Quelle: parson AG)
Marion Knebel, Technical Communicator bei der parson AG

Die Autorin: 

Marion Knebel, Technical Communicator bei der parson AG
In einem zweiten Teil erläutert Marion Knebel weitere Kernelemente von Scrum und was diese für die Technische Redaktion bedeuten. Diesen können Sie hier lesen.

Zurück