Lean Management – Schlanke Prozesse auch in der technischen Dokumentation

Bei der Umstellung auf agile Software-Entwicklung (zu den Grundbegriffen siehe „Agile Software-Entwicklung“) definiert jedes Unternehmen seine Prozesse anders. Es gibt keine vorgeschriebenen Methoden, sondern nur Prinzipien, die – unter Anwendung unterschiedlicher Methoden – auf verschiedene Weise umgesetzt werden können. Dadurch ergeben sich für Technikredakteure in jedem Unternehmen anders geartete Arbeitsumfelder und Anforderungen. Die Dokumentationsabteilungen müssen folglich unternehmensspezifische Antworten auf bestimmte Fragestellungen finden. Das können Fragen nach Umfang und Art des Inputs sein, aber auch zum zeitlichen Ablauf:

Sollte die Dokumentation bereits zum Ende einer Iteration (Planungseinheit) fertig sein?
Ist es überhaupt möglich und nötig, die Dokumentation gleichzeitig mit der Software fertigzustellen, oder kann erst danach abgeschlossen werden? Wenn ja, wie viele Iterationen später?
Welche Dokumentation sollte wann verfügbar sein?

Fragen können sich aber auch auf organisatorische Aspekte beziehen:

Sollen bei den Backlog-Items (gekapselte, in sich abgeschlossene Entwicklungseinheiten) neuer Software-Funktionen Tasks für die Dokumentation ergänzt werden?
Soll für die Dokumentation ein eigenes Backlog-Item erstellt werden?
Wird die Übersetzung integriert, und wenn ja, wie? Ist es sinnvoll, die Dokumentation, die zum Ende einer Iteration verfügbar ist, zu übersetzen? Wenn Dokumentationsanpassungen in späteren Iterationen notwendig werden, entstehen dann möglicherweise zusätzliche Kosten?

Ganz gleich wie verschieden die Unternehmen und wie speziell die Fragen im Einzelnen sind: Beim Lean Management können alle auf dieselben Instrumente zurückgreifen, um ihre Prozesse zu optimieren.

Mündlicher Input

Das Konzept des Lean Managements sieht vor, dass alle Aktivitäten eliminiert werden, die keinen Mehrwert in Bezug auf das Produkt bieten. Dadurch ändert sich auch die Art des Inputs. Verzichtet wird auf umfangreiche Spezifikationen, die veralten, sobald sie in der Entwicklung umgesetzt worden sind, sich aufgrund technischer Einschränkungen als nicht umsetzbar herausstellen oder sich aufgrund mittlerweile geänderter Marktanforderungen als nicht mehr umsetzbar erweisen. Interne Design-Dokumente werden zwar häufig nach wie vor als notwendig angesehen, um Wissen für das Projektteam und insbesondere für personelle Neuzugänge schriftlich festzuhalten und verfügbar zu machen; dennoch wird der Input vornehmlich mündlich übermittelt, so zum Beispiel bei Software-Demonstrationen und Besprechungen. Dieses Vorgehen macht es notwendig, dass die Redakteure ins Entwicklungsteam integriert sind, so dass sie auch am Informationsaustausch innerhalb der Entwicklung sowie zwischen Entwicklung und Produktmanagement teilhaben.

Modulares Arbeiten

Weil bei der agilen Software-Entwicklung in sich geschlossene Einheiten (Backlog-Items) geplant und entwickelt werden, ergibt sich die Notwendigkeit, auch die Dokumentation zu modularisieren und in sich geschlossene Informationseinheiten zu erstellen. So hat sich einerseits das topicorientierte Schreiben vielerorts durchgesetzt, andererseits hat sich die Software-Dokumentation weitgehend auf Online-Publikationen verlagert. Diese Trends werden sich im Zuge agiler Software-Entwicklung weiter verstärken.
Die modulare Software-Entwicklung beeinflusst aber nicht nur die Struktur von Dokumenten, sondern häufig auch ihre Erstellungsreihenfolge. In traditionellen Prozessen wurden unterschiedliche Dokumente in der Regel nacheinander und unabhängig voneinander erstellt, so beispielsweise die GUI-Texte, die Release-Notes, die kontextsensitive Hilfe, die Online-Hilfe und das Handbuch. Wird agil entwickelt und dokumentiert, arbeiten Redakteure innerhalb einer Iteration für jede neue Funktion die gesamte Palette an Dokumenten parallel oder zumindest zeitnah ab, also Funktion für Funktion beziehungsweise Modul für Modul.

Transparente Aufgaben

Die Umstellung auf agile Software-Entwicklung und Lean Management ist für alle Beteiligten ein Lernprozess, nicht zuletzt aufgrund der geforderten Transparenz, die aber viele Vorteile mit sich bringt. Sie soll für jedes Team-Mitglied unter anderem ersichtlich machen, wer gerade an welchen Funktionen arbeitet und wie der aktuelle Entwicklungs- beziehungsweise Dokumentationsstand ist. Dies zu recherchieren, kann in traditionellen Prozessen sehr viel Zeit kosten. Um diese Zeit einzusparen, finden unterschiedliche Arten von Besprechungen und Treffen statt. Darüber hinaus zeigt die Praxis, dass sowohl Entwickler als auch Technikredakteure es schätzen, wenn jeder seine Aufgaben schriftlich fixiert und transparent darstellt. Wie die Entwickler müssen demnach auch die Technikredakteure lernen, ihre Aufgaben und Tätigkeiten als Tasks zu definieren und den Zeitaufwand dafür zu schätzen (Wie lange brauche ich zum Dokumentieren einer bestimmten Funktion?). Das ist in jedem Fall sinnvoll; denn es hilft, Dokumentationsarbeiten und aufwand sichtbar zu machen, damit sie im Team als Aufgaben wahrgenommen werden, die verglichen mit den Entwicklungsaufgaben gleichwertig sind.

Ergiebiges Miteinander am Beispiel Scrum

Eine Methode der agilen Entwicklung sind Scrums. Sie erfordert regelmäßige, aufeinander abgestimmte Besprechungen, bestimmte Planungsverfahren und charakteristische Artefakte wie beispielsweise den Backlog, für den die Tasks schriftlich fixiert werden. Der gegenseitige Informationsaustausch steht im Vordergrund, weswegen Scrums auch für Technikredakteure von großem Nutzen sind. Die unterschiedlichen Besprechungen tragen dazu bei, den Informationsfluss zu optimieren und das Miteinander von Technikredaktion und Entwicklung effizienter zu gestalten:

Sprint-Planung

Technikredakteure können die Sprint-Planung (Planung für die aktuelle Iteration) nutzen, um festzulegen, welche Dokumente erstellt werden sollen und für welche Software-Funktionen welche Dokumentation benötigt wird. Auf dieser Basis lassen sich dann Tasks für die Dokumentation definieren. Im Idealfall erfolgt die Planung gemeinsam mit dem Produktmanagement, um die Funktionen besser verstehen und somit die Dokumentationserfordernisse besser einschätzen zu können.

Daily Scrum

Im Daily Scrum, einem täglichen Team-Treffen, können sich Redakteure über den aktuellen Entwicklungsstand informieren. Es wird ersichtlich, wann bestimmte Funktionen fertiggestellt werden und die Anschluss-Tasks, wie zum Beispiel Software-Tests, beginnen können. Sollte für die Dokumentation noch Input fehlen, kann dies zur Sprache gebracht und im Team geklärt werden. Eine aktive Teilnahme an Daily Scrums regt den gegenseitigen Austausch an, sodass Redakteure an Informationen kommen können, die sonst vielleicht an ihnen vorbeigegangen wären. Wurde beispielsweise die GUI geändert, kann die Begegnung mit den Redakteuren die Entwickler daran erinnern, gemeinsam neue GUI-Texte abzustimmen.

Review-Meeting

Im Review-Meeting kann die Entwicklung neue Funktionen vorführen, was als Input für die Erstellung oder Anpassung der Dokumentation hilfreich ist. Im Gegenzug können die Redakteure dem Team ihre Dokumentation präsentieren.

Retrospektive

Die Besprechungsform der Retrospektive dient vornehmlich dazu, Prozesse zu verbessern. Bisherige Erfahrungen zeigen, dass Teams ausgesprochen aufgeschlossen sind, aktiv an Verbesserungen mitzuarbeiten. Die Redakteure können Retrospektiven nutzen, um beispielsweise Verbesserungsvorschläge für die Zusammenarbeit einzubringen.

Fazit

Das Lean Management ist eine Managementform, die im Zuge der agilen Software-Entwicklung mehr und mehr auch in die Software-Dokumentation Einzug halten wird. Das gezielte Verschlanken von Prozessen bringt natürlich für die Technikredakteure neue Aufgaben, neue Arbeitsabläufe und neue Denkweisen mit sich. Die erforderliche Umstellung mag zunächst abschrecken, die Vorzüge des Lean Managements machen den Umstellungsaufwand aber wieder wett. Denn das zugehörige Organisations- und Verwaltungsinstrumentarium erleichtert den Redakteuren die Dokumentationserstellung und trägt dazu bei, die Tätigkeiten in der Technikredaktion transparent und effizient zu gestalten. Den größten Nutzen bringt das Lean Management dann, wenn die Technikredakteure weitestmöglich in das Entwicklungsprojekt eingebunden und somit integraler Bestandteil eines multifunktionalen Teams werden.