Ist Ihnen schon einmal das Schlagwort „Agile Dokumentation“ über den Weg gelaufen? Seit gut zwei Jahren höre ich es in der Doku-Community immer öfter. Jeder – so scheint es – möchte gerne agil sein; nach den Entwicklern jetzt auch die Redakteure.
Agile Dokumentation ist kein Buzzword
Geistert mit „Agiler Dokumentation“ nur ein neues Buzzword durch die Doku-Welt, das mangels anderer interessanter Themen für ein bisschen künstliche Aufmerksamkeit sorgen soll?
Nein, das glaube ich nicht. Denn hinter dieser Diskussion steckt ja ein berechtigtes Bedürfnis: Man möchte den in der Softwareentwicklung immer beliebteren agilen Entwicklungsprozessen einen entsprechenden Dokumentationsprozess zur Seite stellen. Einen Dokumentationsprozess, der einen produktiven Umgang schafft mit der genuinen Flexibilität und dem erhöhten Maß an Unsicherheit, die die agile Softwareentwicklung ganz automatisch mit sich bringt.
Wie reagieren wir als Doku darauf, dass noch weniger als bisher vorhersagbar ist, was in einer Software wirklich drin steckt und was die letztlich realisierten Features für Software-Hilfen und andere Benutzerdokumente bedeuten? Wie sorgen wir unter diesen Rahmenbedingungen dafür, dass wir nicht für den Mülleimer schreiben und (wenigstens einigermaßen) rechtzeitig fertig werden? – So würde ich ganz grob die Herausforderung an die Technische Dokumentation rund um das Thema Agilität zusammenfassen.
Ein Wiki alleine reicht nicht
Und da war ich dann doch sehr überrascht, als ich vor Kurzem ein Fachbuch in die Hand bekommen habe. Es heißt „agile documentation“ und ist zugegebenermaßen nicht mehr das jüngste (Erscheinungsjahr 2003). Die Aufmachung und das dezidierte Versprechen, Antworten zu diesem Themenfeld zu geben, haben mich aber erst einmal angesprochen.
Gelesen habe ich darin viel Gutes. Dinge, die sich technische Redakteure auf jeden Fall zu Herzen nehmen sollten (So gibt es ein richtig gutes Kapitel über Layout und Typografie; und wer als Nicht-Muttersprachler Dokumentation auf Englisch schreibt, wird von diesem Buch ganz sicher profitieren). Nichts aber – und das hat mich erst überrascht und dann zunehmend enttäuscht – im Grunde genommen nichts dazu, wie man agile Redaktionsprozesse intelligent organisiert. Dass man prinzipiell auch Wikis für die Doku-Erstellung verwenden kann, ist ein netter Hinweis; aber insgesamt fehlt mir in diesem Buch (und auch in so mancher aktuellen Diskussion) eine Perspektive, die das Thema agile Dokumentation stärker auf die tatsächlichen Tätigkeiten von technischen Redaktionen herunterbricht.
Hier muss man ansetzen
Wenn ich so in die Historie der Software-Projekte schaue, die ich bisher betreut habe, sehe ich ein paar gute Ansatzpunkte für agiles Projekt- und Redaktionsmanagement:
- Direkte Beteiligung
Wo volle Flexibilität verlangt ist, braucht es möglichst vollständige Information. Deswegen ist es in agilen Projekten wichtig, dass diejenigen, die schreiben, von Anfang an ganz eng in das Entwicklungsteam eingebunden sind. Und das nicht in Form von Whitepapers, Spezifikationen oder Änderungslisten, sondern als vollwertige Teammitglieder, die an allen Besprechungen teilnehmen. - Gewissheit über die Zielgruppen
Bevor ich mir Gedanken über den Prozess oder die Inhalte einer Dokumentation mache, muss ich wissen, an welche Adressaten sich die Inhalte richten. Wenn ich das weiß, habe ich über das ganze Projekt hinweg ein Auswahlkriterium, welche Dinge ich von vornherein weglassen kann. Das bringt ein ganzes Stück Entspannung für die Doku-Arbeit. - Flexibel befüllbare Dokumentarchitektur
Auch wenn ich die Details noch nicht kenne, kann ich als Redakteur bereits wichtige Teile der Schreibarbeit erledigen. Ich kann festlegen, für welche Punkte ich welche Arten von Informationen brauche (z. B. Funktionsbeschreibungen, Anleitungen, Referenzen, Beispiele etc.). Auf diese Weise entsteht eine Dokumentarchitektur, die ich nach und nach mit Inhalt befülle. Wenn diese Architektur steht, kann ich auch gegen Ende des Projekts noch relativ schnell viel bewegen. - Sorgfältig durchdachte und dokumentierte Schreibstandards
Womit ich beim letzten Punkt wäre: Das alles funktioniert natürlich nur, wenn man ganz genau weiß, was man in seinen Dokumenten wie umsetzt. Sprich: Für agile Redaktionsprozesse ist ein Redaktionsleitfaden essenziell. Er nimmt die Redakteure dabei an die Hand, sinnvolle Dokumentstrukturen für die benötigten Inhalte aufzubauen. Und er liefert das Handwerkszeug dafür, wie man diese Platzhalter verständlich für die Leser und effizient für den Redakteur befüllt bekommt. Auch dann, wenn die Zeit knapp wird.
Werden Technische Redakteure auf diese Weise zu Übermenschen? Nein, natürlich nicht. Und ganz sicher sind diese Punkte nicht die Lösung aller Probleme im agilen Projektmanagement. Und trotzdem: Hier liegen Effizienzpotenziale, die noch sehr selten genutzt werden – und die selbstredend auch vielen nicht-agilen Projekten guttäten.
Und Ihre Erfahrungen?
Haben Sie schon redaktionell in agilen Projekten gearbeitet? Welche Ansatzpunkte sehen Sie? Was hat sich bewährt? – Nutzen Sie gerne unsere Kommentarfunktion, um Ihre Erfahrungen zu schildern.
Meine Erfahrung ist, dass es in der Realität fast unmöglich ist, dass die Dokumentation bis zum Ende eines Entwicklungssprints fertig ist. Eine Dokumentationsstruktur zu planen geht in der Regel schon, aber diese dann auch komplett zu befüllen muss eher verschoben werden, da bis zur letzten Sekunde heftigst entwickelt wird.
Ich habe mal in einem Blog (ich weiß bloß nicht meht wo…) von einem Ansatz gelesen, bei dem die Dokumentation zu einem Sprint quasi immer erst einen Sprint später tatsächlich erstellt wurde und das kann ich mir sehr gut vorstellen. Da hat man dann einen solideren Stand und muss nicht zu viel Angst haben, dass einen Tag später alles anders ist. Wobei man vor diesem Szenario nie so ganz sicher ist 😉
Als Redakteur bei allen Besprechungen dabei zu sein ist so eine Sache. Einerseits ist man so am besten eingebunden und die anderen Projektmitglieder “vergessen” einen nicht. Andererseits werden da häufig so entwicklungsspezifische Dinge besprochen, dass man auch ziemlich viel Däumchen dreht. Man muss je nach Projekt ein gutes Mittelmaß finden, so dass man oft genug präsent ist, aber eben auch keine Zeit verschwendet.
100%ige Zustimmung zu dem Blog-Artikel. Ich möchte noch 3 Punkte ergänzen:
1. Das Abliefern der Dokumentation könnte zu den DONE-Kriterien von Lieferleistungen gehören. Damit ist allen klar, dass die Arbeit nicht fertig ist, wenn die Doku fehlt. Der Empfehlung von Redakteuse kann ich mich auch anschließen. Wir haben z. B. die Benutzertests in den Folgesprint geschoben und etwas Zeit für Bugfixing reserviert.
2. Agile Entwickler haben gern eine visuelle Fortschrittskontrolle im Blick (Story Boards, Burndown Charts). Das könnte man für die Doku auch machen.
3. Agile Entwickler lagern stupide Tätigkeiten an die Maschine aus (“Automate the pain away”). Deswegen baut man die Tests anders auf, damit sie automatisch im Hintergrund laufen können. Es ist sicher denkbar, mit den Entwicklern Code-Standards abzusprechen, sodass in den Quelltexten schon Hinweise auftauchen, was dokumentiert werden muss. Hier kann ich das Buch “Der pragmatische Programmierer” (siehe http://www.amazon.de/Der-Pragmatische-Programmierer-David-Thomas/dp/3446223096/) empfehlen. (Ist auch für technische Redakteure interessant.) Ich habe ganz gute Erfahrungen mit NaturalDocs (http://www.naturaldocs.org/) gemacht.
Beste Grüße, Jan