Produktdokumentationen - Sind sie in agilen Projekten überflüssig?

17. September 2020 von Wolfgang Krug

In unserem ausführlichen Whitepaper „5 Empfehlungen zur Erstellung der Produktdokumentation in agilen Vorgehensmodellen“ (welches Sie hier downloaden können) erläutern wir ausführlich, warum wir in agilen Vorgehensmodellen eine Produktdokumentation erstellen. Wir geben Empfehlungen zu Inhalt und Erstellung der Produktdokumentation.

Nachfolgend geben wir einen kurzen Überblick zu der Frage: Sind Produktdokumentationen in agilen Projekten überflüssig?

Nein - wir benötigen Dokumentation, gerade in agilen Projekten, weil viele sorgfältig formulierte User Stories alleine noch kein sinnvolles Ganzes ergeben.

 

 

Produktdokumentation-nach-Scrum

Erstellen einer Produktdokumentation nach Scrum

 

 

Agiles Arbeiten ist heute zum Standard der Projektabwicklung geworden. Durch kürzere Auslieferungszyklen und häufigeres Feedback entstehen bessere Produkte und Anwendungen. Aber aus unserer Sicht wird in agilen Projekten oftmals das Thema „Produktdokumentation“ vernachlässigt.

Möglicherweise liegt das daran, dass im Manifest für agile Softwareentwicklung (www.agilemanifesto.org) funktionierende Software höher als umfassende Dokumentation bewertet wird.

 

Warum ist eine Produktdokumentation unverzichtbar?

Die Produktdokumentation ermöglicht:

  • die Investitionssicherung für den Auftraggeber und
  • die Sicherung des fachlichen Wissens.

Sie ist Grundlage für:

  • den kostengünstigen Betrieb und
  • die Wartung und Weiterentwicklung des Produkts

Je komplexer eine Anwendung ist, desto wichtiger ist der Gesamtüberblick in der Produktdokumentation. Dieser Überblick trägt bei Nutzern und Entwicklern zum Verständnis der Aufteilung, des Inhalts und des Zusammenspiels der Komponenten bei.

In der Produktdokumentation wird sichergestellt, dass:

  • fachliche und technische Entscheidungen
  • in gleicher oder ähnlicher Weise über den gesamten Produktlebenszyklus getroffen werden.

Damit wird eine tragfähige und stabile Anwendung über mehrere Jahre bereitgestellt. Außerdem ermöglicht eine detaillierte, vollständige Dokumentation der Funktionalität die schnelle und vollständige Einarbeitung neuer Mitarbeiter.

Unsere Erfahrung zeigt, dass ohne dokumentierte Betriebskonzepte ein langjähriger störungsfreier Betrieb des Produkts nicht machbar ist.

 

 

Produktdokumentation-vs-Projektdokumentation

 

Unterschied zwischen der Produkt- von der Projektdokumentation

Die Durchführung eines Projekts im agilen Projektmanagement bedeutet nicht die Abschaffung jeglicher Dokumentation. Es bedeutet die Chance, die Dokumentation fokussiert auf den betrachteten Kontext und insgesamt leichtgewichtig zu erstellen. Zur Erstellung der Produktdokumentation unterscheiden wir zwischen Projekt- und Produktdokumentation.

 

 

Produktdokumentationen in agilen Projekten

 

 

Bestandteile der Produktdokumentation

Alles was Bestand hat, sind Bestandteile der Produktdokumentation. Dazu gehören beispielsweise:

  • die treibende Vision,
  • fixierte Prämissen und Rahmenbedingungen,
  • abgestimmte Anforderungen,
  • Entscheidungen,
  • Prozesse,
  • Schnittstellen,
  • Geschäftslogik und
  • die Daten- und die fachliche Modellierung.

 

Bestandteile der Projektdokumentation

Zur Projektdokumentation gehören Elemente die temporär zur Erstellung / Pflege des Produkts benötigt werden, z.B.:

  • die Dokumente zur Verwaltung und Steuerung des Projekts,
  • fachliche Dokumente wie Epics oder Stories,
  • Protokolle,
  • Abstimmungs- und Entscheidungsvorlagen.

Lassen Sie uns das anhand eines Beispiels verdeutlichen:

Für ein Meeting erstellen Sie i.d.R. kein Gesprächsprotokoll, in dem steht, wer wann was gesagt hat. Sie erstellen ein Ergebnisprotokoll, das die Anforderungen, Beschlüsse und Aufgaben des Meetings widergibt. Die Produktdokumentation entspricht in diesem Beispiel dem Ergebnisprotokoll. Die Projektdokumentation enthält die im Meeting verwendeten Unterlagen, Abstimmungen und Gespräche.

 

Epics und Stories bei agilen Vorgehensweisen

Die vage, noch wenig konkrete Vorstellung wird oftmals in einem Epic formuliert und in zugeordneten Stories aufgegliedert und eindeutig beschrieben. Dabei kommt es vor, dass der Inhalt einer Story für eine „erste Umsetzung“ nochmals konkretisiert wird.

Nach ein paar Iterationen verteilt sich die umgesetzte Fachlichkeit auf viele einzelne Stories. Aber hundert sinnvolle User Stories ergeben nicht automatisch ein sinnvolles Ganzes. Die Produktdokumentation enthält in komprimierter Form ausschließlich das, was konkret umgesetzt wurde und Bestand hat. Niemanden interessiert später, wie und auf welchen Wegen das Ziel erreicht wurde.

Daher gehören Epics und Stories zu den Projekt-Arbeitsmitteln und damit zur fachlichen Projektdokumentation. Sie sind damit Grundlage für die Erstellung der Produktdokumentation.

 

 

Produktdokumentation auf dem Prüfstand

 

Produktdokumentation auf dem Prüfstand

Wir haben die Inhalte unserer Produktdokumentationen auf den Prüfstand gestellt und verschlankt. Was nicht zwingend benötigt wird, haben wir entfernt. Inhalte, die bisher wichtig waren, haben wir gestrafft. Die Reihenfolge und die Tiefe der Inhalte in der Produktdokumentation sind neu.

 

Wann wird die Produktdokumentation erstellt?

Es gibt verschiedene Möglichkeiten, die Produktdokumentation zu erstellen:

Vor der Realisierung

Das hat den Vorteil, dass Testfälle aus der Produktdokumentation abgeleitet werden. Dieses Vorgehen ist beispielsweise in Off-Shore-Projekten hilfreich. Allerdings bremst dieses Vorgehen die Agilität.

Während der Realisierung

Mit dieser Methode, existiert am Ende der Iteration die Dokumentation. Der Aufwand für die Erstellung nach Themen wird in Story-Points geschätzt.

Dies erhält die Agilität und wird auf Grund dessen als der ideale Zeitpunkt angesehen. Diese Methode wird angewendet, wenn es neben dem Realisierungs-Team ein kleines Spezifikations-Team gibt.

Nach der Realisierung

Bei dieser Methode wird ausschließlich das dokumentiert, was final umgesetzt ist. Unserer Erfahrung nach, wird das „Nachdokumentieren“ oftmals aus Ressourcengründen unvollständig oder überhaupt nicht durchgeführt.

 

Wer schreibt die Stories und wer die Produktdokumentation?

Der Kollege aus dem Fachbereich liefert Epics und Stories. Nur er weiß, was der Fachbereich benötigt. Die Erfahrung zeigt, dass es für den Fachbereich nicht schwer ist, die fachlichen Anforderungen und Prozesse aufzuschreiben.

Auf Basis der Inhalte der User Stories wird die Produktdokumentation durch die Spezifikateure / Analysten aktualisiert.

Das Schreiben der Produktdokumentation und das Schreiben der Stories beeinflussen sich gegenseitig positiv: Der Spezifikateur / Analyst hat eine Vorstellung davon, welche Informationen in der Produktdokumentation abzulegen sind. Bei der Strukturierung und Erweiterung der Beschreibungen in den Stories hat er die Möglichkeit, gezielt diese Informationen zu hinterfragen und zu dokumentieren.

 

Bestandteile der Produktdokumentation und deren Inhalte

Die Produktdokumentation besteht im Wesentlichen aus den folgenden Teilen:

Anwendungsbeschreibung

Sie enthält widerspruchsfrei das vollständige, fachliche Produktwissen. Anwendungsfälle, Sonderfälle und Fehlerfälle der Funktionalität der Anwendung sind hier beschrieben.

Glossar

Das ist eine alphabetisch sortierte Sammlung relevanter Fachbegriffe, die für das Verständnis des Produkts wesentlich sind.

Architekturbeschreibung

Sie enthält eine Beschreibung der Architektur-Entscheidungen und -Konzepte im Kontext der fachlichen Anwendungsbeschreibung. Dazu gehören:

  • Überblick und Zusammenhänge zu den technischen Komponenten der Anwendung,
  • Details zu den technischen Komponenten der Anwendung,
  • Dokumentation der übergreifenden technischen Entscheidungen und der Architektur-Konzepte,
  • Beschreibung und Generierung des DB-Schemas,
  • Qualitätsmerkmale des Produkts

Benutzerhandbuch

Das Handbuch beschreibt die (geführte) Bedienung des Produkts aus Anwendersicht. In der Regel geschieht dies strukturiert nach Anwendungsfällen.

Betriebshandbuch

Die technischen Voraussetzungen und Zusammenhänge sind im Betriebshandbuch beschrieben. Dies umfasst Aufgaben und Maßnahmen, die für den Betrieb des Produkts im Regel- und Fehlerfall notwendig sind.

Source-Code

Im Source-Code sind die fachlichen Anforderungen auf Basis der definierten Architektur implementiert. Er enthält Kommentare, mit denen der Code der Anwendungsbeschreibung zugeordnet wird. Mit Hilfe der Kommentare wird die Gliederung und das Zusammenspiel des Codes leicht verständlich dokumentiert.

Testfälle

Bei den Testfällen handelt es sich um eine Sammlung von fachlich relevanten Tests. Diese prüfen die Funktionalität der Anwendung mit gängigen und besonderen Berechtigungs- und Datenkonstellationen. Das Ziel der Testfälle ist es, die Funktionsfähigkeit getesteter Software sicherzustellen und die Kommunikations- und Schnittstellenfehler aufzudecken.

 

Zum Schluss

In unserem ausführlichen Whitepaper „5 Empfehlungen zur Erstellung der Produktdokumentation in agilen Vorgehensmodellen“ erläutern wir ausführlich, warum wir in agilen Vorgehensmodellen eine Produktdokumentation erstellen. Wir geben Empfehlungen zu Inhalt und Erstellung der Produktdokumentation. Das Whitepaper können Sie hier herunterladen:

Download"Sind Produktdokumentationen in agilen Projekten überflüssig?"

 

Weitere Informationen

Haben Sie Fragen rund um die Themen Scrum und agile Produktdokumentation im Spezifischen oder Projektmanagement im Allgemeinen?

 

Schreiben Sie mir eine E-Mail, ich freue mich auf Ihre Kontaktaufnahme:

emailwolfgang.krug@exxcellent.de

telefon+49 731 55 026 0

 

Lernen Sie auch unser gesamtes Beratungsportfolio kennen unter:

bubble-chat-information-2-1www.eXXcellent.de

Über Wolfgang Krug

Der Autor Wolfgang Krug ist Senior Managing Consultant bei der eXXcellent solutions in München. Seine 30-jährige Berufserfahrung bringt er vor allem im Anforderungsmanagement, Design der Facharchitektur, Prozessmodellierung und -Optimierung sowie im Qualitätsmanagement und Test ein. Seine Freizeit verbringt er gerne mit seiner Familie und beim Fliegen von Modellhubschraubern schaltet er vom Tagesgeschäft ab.

Tags: Alle Blogbeiträge, Methodik/Vorgehen, Scrum, Agiles Projektmanagement

Diesen Artikel teilen:


Newsletteranmeldung