Ich habe mich schon oft gefragt, was wir in unserem agilen Umfeld wirklich dokumentieren wollen und vor allem können. Bei der Frage, was wir dokumentieren, müssen wir Klarheit haben über die Zielgruppen für die Dokumentation. Eine Zielgruppe hat entweder fundamentales Wissen zum Einsatz des Produktes oder benötigt Wissen über das Produkt, um Tätigkeiten im Rahmen des Projektes durchzuführen.

03 Welche Zielgruppen haben wir

Die Stakeholder

Der Auftraggeber und andere Stakeholder des Projektes benötigen einen Überblick – das “Big Picture” – über die fachlichen Probleme, die mit der Software gelöst werden.

Den Überblick braucht der Auftraggeber vor allem auch, damit er die Fachabteilungen über die Leistungsfähigkeit, aber auch über die Grenzen der Software gut informieren kann. Die Systembeschreibung hilft ihm, die Fachabteilungen zu motivieren, Verbesserungen oder Erweiterungen der Software zu beauftragen. Sie können in einer gemeinsamen Sprache diskutieren. Sie erfassen nur die Änderungen mit einer angemessenen Detailtiefe in einer Form, die von den Analysten später gut für die Systembeschreibung verwendet werden können. Sie beschreiben beispielsweise Unternehmensprozesse in einem Topic, Prozessschritte in einem Epic, konkrete Anwendungsfälle in einem Case oder den Entwurf der Benutzeroberfläche in Layouts.

Die Macher

Analysten, Product-Owner und das cross-funktionale Team benötigen die Systembeschreibung in einer Form und Sprache, die alle Beteiligten verstehen und eine Vision des Produktes vermitteln. Die Inhalte der Systembeschreibung müssen eine Brücke schlagen zwischen der domänenspezifischen Sprache der Stakeholder, Analysten und Tester und der techniklastigen Sprache der Entwickler, um ein gemeinsames Verständnis für eine konkrete Umsetzung zu finden.

Entwickler und Tester nutzen die Bausteine des Architekturdefinition, um ihre Produkt zu beschreiben. Dabei geht es nicht so sehr um die Details, sondern vielmehr um die Darstellung der Struktur der Software und der Entscheidungen, die zu dieser Struktur geführt haben. Und sie tun es in ihrer Sprache. Sie profitieren auch sehr stark von einem Benutzer- und Betriebshandbuch, wenn es diese Dokumente bereits als Entwurf während der Entwicklung zur Verfügung stehen.

Die Tester

Tester brauchen eine Systembeschreibung, die erklärt, wie eine Anwendung funktioniert und welche Anwendungsfälle berücksichtigt wurden. Sie entwickeln daraus abnahmerelevante Testfälle und erstellen und pflegen Testpläne für manuell als auch automatisiert durchführbare Testfälle. Vor allem Tester profitieren von einer Systembeschreibung, in der neben den regulären Anwendungsfällen auch Sonderfälle, Ausschlüsse und Fehlerfälle erfasst sind.

Die Qualität der Testfälle für neue Funktionen wird durch das Einbeziehen des Benutzerhandbuches noch wesentlich gesteigert. Nicht nur wird durch die Erstellung der fachlichen Tests das Benutzerhandbuch validiert (was ein sehr positiver Nebeneffekt ist), sondern die Testfälle können sich auf das Benutzerhandbuch beziehen (was den Aufwand gerade bei Testfällen mit vielen Varianten deutlich reduziert).

Wie beim Benutzerhandbuch ist eine frühe Verfügbarkeit des Betriebshandbuches eine Chance, die technischen Tests für das Systems frühzeitig und bereits während der Entwicklung anzupassen oder neu zu erstellen. Auch hier wird das Betriebshandbuch durch die Erstellung der Testfälle für den technischen Test validiert.

Die Betreiber

Die Betreiber der Software erwarten ein Betriebshandbuch, in dem das Vorgehen zur Installation oder Neu-Konfiguration der Software beschrieben ist. Das Betriebshandbuch enthält auch eine Anleitung zur Analyse und Behebung von Fehlern während des Betriebes in Form von Handlungsanweisungen.

Konfigurationsmanager im Projekt und die Betreiber des Systems brauchen außerdem einen Überblick über die Struktur der Software, um Auswirkungen auf den Betrieb von Hardware und Middleware frühzeitig zu erkennen. Dazu müssen vor allem Mengengerüste in der Anwendung und an technischen Schnittstellen und die konzeptionell vorgesehenen Strategien zur Skalierung bekannt sein. Schätzungen für Veränderungen der Mengengerüste basieren auf Erkenntnissen, die sie aus der Systembeschreibung gewinnen.

Die Nutzer

Power-User sind frühzeitig geschulte Nutzer des Systems. Sie brauchen frühzeitig ein Benutzerhandbuch, um Schulungen für die anderen Nutzer rechtzeitig vor der Einführung der Software zu planen und durchzuführen. Im produktiven Betrieb sind die Power-User als Multiplikatoren im Wissenstransfer für alle anderen Nutzer verfügbar – das Wissen beziehen sie auch aus der Systembeschreibung.

Ist ein Produkt einmal eingeführt, versuchen Tester und Power-User anhand der Systembeschreibung herauszufinden, ob Defekte in der Software tatsächlich Fehler oder doch neue Anforderungen an das System sind.  Handelt es sich um Fehler, verwenden Entwickler die Dokumentation, um die Änderung an der Software so risikoarm und so frei von Seiteneffekten wie möglich zu korrigieren.

Anforderungen werden durch das Change-Management des Auftraggebers bewertet. Neue Anforderungen lassen sich anhand der Dokumentation sehr oft mit ähnlichen bereits umgesetzten Anforderungen vergleichen. Das bringt das Projekt in die Lage, für die neuen Anforderungen die Umsetzung und die damit verbunden Risiken besser einzuschätzen.

Fazit

Jede Person im Projekt ist Teil einer Zielgruppe für die Produktdokumentation. Der Bedarf entsteht prozessbedingt zu unterschiedlichen Zeitpunkten mit unterschiedlicher Motivation. Aber wenn sich alle handelnden Personen der gleichen Informationsquelle bedienen, dann gibt es im Projekt auch nur eine Wahrheit über das Produkt.