27.10.2020

Agile Dokumentation in Scrum-Projekten

Das Agile Manifest als Grundlage auch von Scrum-Projekten benennt es doch glasklar: „Funktionierende Software ist wichtiger als umfassende Dokumentation.“ Warum dann über Dokumentation noch groß reden? Weil das Agile Manifest Kommunikation im Projekt besonders hervorhebt.

Scrum

Zwar bevorzugen agile Ansätze den direkten persönlichen Austausch. Dennoch soll jede Zeile Code im Team aus Vertretern der Stakeholder, im Scrum-Team also durch den Product-Owner, und den Entwicklern kommunikativ reflektiert werden.

Doch eine solche Art der Qualitätssicherung, die Kommunikation letztendlich bewirken soll, kann nur durch Dokumentation intersubjektiv nachvollzogen werden. Und Benutzerdokumentation als Bestandteil der User-Experience (UX) ist damit einerseits noch nicht definiert und andererseits im Agilen Manifest gar nicht angesprochen.

Für die schriftlich festgehaltene Kommunikation im Projekt definiert Scrum das sogenannte Product-Backlog als im Prinzip beliebig große Anzahl von Anforderungen an das zu entwickelnde Produkt. Für die Rolle von Dokumentation im Scrum-Framework müssen wir uns also insbesondere die Funktion des Product-Backlogs näher anschauen.

Das Scrum-Framework
Das Scrum-Framework

Scrum definiert als Framework drei Rollen, drei Artefakte und fünf Events.

Drei Rollen Drei Artefakte Fünf Events
  • Product-Owner (1 Person, definiert Anforderungen, priorisiert, kann Sprints vorzeitig beenden)
  • Development-Team (3–9 Personen cross-functional, selbstorganisierend!)
  • Scrum-Master (1 Person „Servant-leader“, moderiert, coacht, implementiert Scrum)
  • Product-Backlog (Plan grob), laufend weiter verfeinert und priorisiert (Refinement)
  • Sprint-Backlog (Teilplan, detailliert, bewertet)
  • Product-Increment (auslieferbare Produkteinheit)
  • Sprint als Container: ≤ 30 Tage
  • Sprint-Planning
  • Daily Scrum
  • Sprint-Review
  • Sprint-Retrospektive

Scrum, Backlogs und Dokumentation

Aus dem Agilen Manifest und dem Framework Scrum lassen sich nun mit Blick auf die Dokumentation sehr wohl kritische Fragen ableiten:

  • Gibt es weitergehende Spezifikationen an die Dokumentations-/Informationsartefakte „Product-Backlog“ und „Sprint-Backlog“?
  • Thematisiert Scrum Anwenderdokumentation als Produktkomponente, die Bestandteil eines Produktinkrements sein muss?
  • Auf welchen Teilaspekt bezieht sich das Prinzip „Funktionierende Software ist wichtiger als umfassende Dokumentation“?

Scrum legt für das Sprint-Backlog keine Details fest. Zwar ist das Sprint-Backlog als weiteres Artefakt genannt, tatsächlich ist es nur eine Widerspiegelung von Teilen des Product-Backlogs. Änderungen an den Backlog-Einträgen während eines Sprints werden als Änderungen in das Product-Backlog eingepflegt und werden als „Product-Backlog-Refinement“ bezeichnet. Ein Sprint-Backlog „überlebt“ einen Sprint nicht, um den „Single Source of Truth“ (eine einzige gültige Quelle) zu erhalten.

Keine eindeutige Spezifikation der Dokumentation …

Um es klar zu sagen: Scrum ist ein Rahmenwerk und spezifiziert weder die eigentliche Produktgestaltung noch die externe Dokumentation (Benutzerdokumentation). Die interne Dokumentation (Entwicklerdokumentation) besteht aus dem Product-Backlog, nur lässt der Scrum-Guide offen, wie das Backlog im Detail aussieht.

… auch nicht in Normen

Auch in der klassischen Softwareentwicklung gibt es kein allgemein akzeptiertes Rahmenwerk, das Dokumentation eindeutig spezifiziert. Es sind die Begriffe „Lastenheft“ (fachliche Orientierung) und „Pflichtenheft“ (technologische Orientierung) sowie „Benutzerdokumentation“, die im klassischen Entwicklungsumfeld als allgemein bekannt angesehen werden können. Zwar gibt es Normen, die die Begriffe Lasten- und Pflichtenheft aufgreifen:

  • DIN 69901-5:2009-01 Projektmanagement – Projektmanagementsysteme – Teil 5: Begriffe
  • VDI 2519 Blatt 1:2001-12 Technische Regel Vorgehensweise bei der Erstellung von Lasten-/Pflichtenheft
  • Zahlreiche anwendungsspezifische Normen zu Lasten- und Pflichtenheften
  • ISO/IEC/IEEE 26511:2018-12 Software und System-Engineering – Anforderungen an Manager von Informationen für Benutzer von Systemen, Software und Services
  • ISO/IEC/IEEE 26512:2018-06 Software und System-Engineering – Anforderungen an Erwerber und Lieferanten von Informationen für Benutzer
  • ISO/IEC/IEEE 26513:2017-10 Software und System-Engineering – Anforderungen an Tester und Gutachter der Benutzerdokumentation
  • IEEE 26514:2010 Software und System-Engineering – Anforderungen an Designer und Entwickler von Benutzerdokumentationen
  • ISO/IEC/IEEE 26515:2018-12 Software und System-Engineering – Entwickeln von Informationen für Benutzer in einer agilen Umgebung

Allen Normen gemeinsam ist, dass eine festgelegte Struktur und Sequenz für interne Dokumentation und deren Rolle als Input für eine Benutzerdokumentation nicht festgelegt werden. Insbesondere die Norm 26515 für agile Entwicklungen zeigt nun einen möglichen revolutionären Weg: „In order to minimize unnecessary work and duplication of effort, technical writers may be asked to produce or contribute to life cycle documentation. The user documentation may itself become the design specification for the product under development […].“

Die überwiegende Praxis zeigt, dass die klassische Idee der aufeinander abgestimmten Dokumente mit den jeweils unterschiedlichen Zielgruppen Stakeholder und Entwickler in einer Welt der permanenten Änderungen (Volatilität) und der zunehmenden Komplexität einfach nicht mehr effizient umsetzbar ist. So akzeptiert selbst das aktuelle V-Modell als bekanntestes öffentlich zugängliches Framework für Software-Entwicklungen zumindest in der Erweiterung „V-Modell XT Bund“ auch agile Ansätze.

Für Scrum findet man auf der Website www.scrum.org mit dem kostenlosen Scrum-Guide „die Bibel“ von Scrum.

Product-Backlog ist Dreh- und Angelpunkt

Der Scrum-Guide beschreibt das Product-Backlog als Dreh- und Angelpunkt jeglicher Entwicklung, vermeidet aber eine weitergehende Spezifizierung: „Im Product-Backlog werden alle Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen aufgelistet, die die Änderungen an dem Produkt in zukünftigen Releases ausmachen. Ein Product-Backlog-Eintrag enthält als Attribute eine Beschreibung, die Reihenfolge, die Schätzung und den Wert. Product-Backlog-Einträge enthalten oft Testbeschreibungen, die ihre Vollständigkeit nachweisen, wenn sie fertig [,Done‘] sind.“

Definition of Done: Was bedeutet „FERTIG“?

Als einzig weiteren Aspekt verlangt der Scrum-Guide, sogenannte Definition-of-Done-Kriterien (DoD) festzulegen.

Ein Beispiel für Definition-of-Done-Kriterien:

  • Immer wenn Änderungen am Code vorgenommen werden, müssen Tests definiert werden, die die fehlerfreie Funktionalität prüfen.
  • Alle User-Stories sind gegen das Produktglossar geprüft. Das Produktglossar definiert alle Fachbegriffe (Aufgabengebiet, Funktionsbezeichnungen, Handlungen), die zur Kommunikation rund um das Produkt benötigt werden.
  • Das Produkt ist auf allen Systemvarianten des vorgesehenen Systems (z.B. PC, Windows 10 ab Version 2004) getestet.
  • Die Endbenutzerdokumentation spiegelt den aktuellen Stand des Produktinkrements wider.

Kriterien müssen festgelegt und dokumentiert werden.

Eine DoD-Liste muss von einem Unternehmen und/oder dem Entwicklungsteam als Qualitätsrahmen verabschiedet werden. Es sei noch einmal gesagt: Die Festlegung von DoD-Regeln ist Projektaufgabe und kein Bestandteil des Scrum-Guides.

Die weiteren Ausführungen zu diesem spannenden Thema finden Sie in unserem Praxismodul „Technische Dokumentation“.

Autor: Dieter Gust (Senior Consultant und Leiter Forschung und Entwicklung bei der itl AG)