Dokumentation

Technische Dokumentation im Scrum-Team

Seite: 2/3

Firmen zum Thema

Wie ändert sich die Arbeitsweise?

Durch die Prozesse der Scrum-Methode können Redakteure das Arbeitspensum besser einschätzen, weil sie nicht auf einen einzigen Abgabetermin hinarbeiten, sondern entlang von Backlog-Items dokumentieren. Unter Umständen ist es sinnvoll, das Dokumentieren einer Funktion in einen späteren Sprint zu verschieben, wenn beispielsweise die Entwicklung noch nicht so weit fortgeschritten ist, dass die Software lauffähig ist und getestet und beschrieben werden kann. Das Produkt und die Dokumentation werden zeitnah getestet, so dass Fehler schneller entdeckt werden und die Arbeit der Redakteure kalkulierbar ist.

Iterative Entwicklung: Zu den Prinzipien agiler Entwicklung gehört es, besonders früh und kontinuierlich Ergebnisse an den Kunden zu liefern. Änderungswünsche von Kundenseite setzt das Team so schnell wie möglich um.

Bildergalerie

Diese Anforderungen der iterativen Entwicklung machen deutlich, dass es nicht nur darum geht, innerhalb eines festgelegten Zeitraums regelmäßig zu liefern, sondern dass der Entwicklungsprozess selbst diesen Anforderungen folgen muss. Die technische Redaktion muss sich ebenso an diese Arbeitsweise anpassen.

Projektplanung: Die Projektleitung entwickelt einen Projektplan, der Sprints, Meilensteine und Deadlines umfasst. Dazu gehört beispielsweise ein Redaktionsschluss für die Dokumentation. An den regelmäßigen Scrum-Meetings sollten auch die Redakteure teilnehmen. So erfahren sie, welche Aufgaben abgeschlossen sind, welche verschoben werden müssen und wo eventuell Probleme aufgetreten sind, die auch sie betreffen.

Arbeitspakete schnüren: Bei der Arbeit nach dem Wasserfallprinzip haben die Entwickler oft keine Möglichkeit, ihre Besprechungen mit den Redakteuren zeitlich zu erfassen. Oft genug fällt diese Zeit einfach unter den Tisch. Im Scrum-Modus ist die Erstellung einzelner Texte ein Backlog-Item, mit dem auch die Position des Redakteurs im Team gestärkt wird: Review, Test und Aktualisierung der Dokumentation sollte in jedem Sprint berücksichtigt werden.

Die Erstellung der anfallenden Dokumentation kann nicht immer innerhalb eines Sprints abgedeckt werden. Es fallen Arbeiten an, die komplett unabhängig von zu programmierenden Funktionen sind, etwa die Informationsarchitektur der Dokumentation zu entwickeln oder organisatorische Aufgaben, die das Publizieren, Ausliefern oder Archivieren betreffen. Diese Aufwände sollten ebenfalls als Backlog-Item in den Projektplan aufgenommen werden.

Es kann jederzeit zu kurzfristigen Änderungen kommen, die berücksichtigt werden müssen. Die Zeit für ein Backlog-Item sollte so bemessen sein, dass die Redakteure diese Änderungen noch in ihre Dokumentation einarbeiten können.

Folgende Dokumentationsaufgaben müssen erledigt sein, damit ein Backlog-Item geschlossen werden kann:

  • Die Funktion ist beschrieben.
  • Software sowie Dokumentation sind getestet.
  • Fehler, die vom Systemtest gemeldet wurden, sind entweder behoben oder die Behebung ist geplant.

Dann ist zu überlegen, welche Stände an den Kunden geliefert werden, so dass dieser optimale Informationen erhält. Für das Publizieren der Dokumentation werden Backlog-Items zum Ende eines Sprints angelegt, so dass korrekte Inhalte an den Kunden ausgeliefert werden.

Artikelfiles und Artikellinks

(ID:44453375)