In diesem Beitrag möchte ich mich damit beschäftigen, warum wir überhaupt dokumentieren. Dokumentation sollte kein Selbstzweck sein. Wir könnten sonst unsere wertvolle Zeit voll und ganz in die Entwicklung funktionierender Software investieren. Glaubt man dem IEEE-Standard 1471-2000 ist es die Kernaufgabe von Dokumentation, Fragen der Stakeholder zu beantworten. Kennt ihr die Fragen eurer Stakeholder? Kennt ihr eure Stakeholder?
Schauen wir uns zunächst mal die folgenden Abbildung an. Es gibt verschiedene Stakeholder, die je nach Rolle unterschiedliche Sichtweisen auf das Produkt haben und demnach auch unterschiedliche Fragen beantwortet wissen wollen. Sie benötigen also auch unterschiedliche Arten von Dokumentation oder zumindest eine individuelle Sicht darauf.
Damit lässt sich auch erklären, warum kein Patentrezept für agile Dokumentation im Internet zu finden ist und es so viele unterschiedliche Arten wie
- Benutzerhandbuch,
- Betriebshandbuch,
- Code-Kommentare,
- Architekturdefinitionen,
- Schnittstellenbeschreibungen,
- Prozesse,
- Informationen über die Nutzung von Tools,
- Fachwissen
und vieles mehr gibt. Jedes Produkt hat unterschiedliche Stakeholder, die unterschiedliche Bedürfnisse haben. Bevor wir anfangen zu dokumentieren, sollten wir also wissen für wen wir das eigentlich machen und welche Bedürfnisse (Fragen) dieser Stakeholder an unsere Dokumentation hat.
Fangen wir mit dem Team selbst an. Zwar wird hier viel implizit über Kommunikation und standardisierte Verhaltensmuster geregelt, aber hier gibt es sicherlich die meisten Fragen, was das Produkt und dessen Weiterentwicklung und Wartung betrifft.
Der Entwickler
- Ist der Code verständlich geschrieben? Weiß ich noch, was und wie ich da vor drei Jahren entwickelt haben?
- Was wird in diesem Sprint entwickelt? Was hat der Kunde davon? Benötige ich dafür eine neue Technologie?
- Wie spreche ich Schnittstellen fremder Systeme an?
- Wie hatten wir uns vor ein paar Monaten entschieden, Buttons auf externe Seiten zu kennzeichnen?
Der Entwickler hat vor allem seinen Code als Informationsquelle. Dennoch muss auch er wissen, welche Kundenbedürfnisse das Produkt zukünftig erfüllen soll. Je komplexer das Produkt ist, desto wichtiger ist auch eine Produktdokumentation, um auch vergangene Entscheidungen und Umsetzungen nachvollziehen zu können. Ähnliche Fragen wie der Entwickler hat der Tester.
Der Tester
- Was sind die Besonderheiten bei neuen Funktionalitäten? Wie kann ich sie testbar machen?
- Wo finde ich die Testfälle, die sicherstellen, dass meine Hauptfunktionalitäten auch nach den Folgeversionen weiterhin so funktionieren wie sie sollen? Was sind überhaupt die Hauptfunktionalitäten des Produkts?
Die Fragen nach der Hauptfunktionalitäten des Produkts kann sicherlich ein Productowner im Schlaf beantworten, aber auch er hat Fragen, die konkrete Use Cases betreffen.
Der Productowner
- Was passiert, wenn der Benutzer eingeloggt ist, aber das Passwort abgelaufen ist?
- Wie stellen wir sicher, dass wir keinem Betrug zum Opfer fallen und kann man das durch neue Technologien verbessern?
Der Scrum-Master hat Fragen, die weniger mit dem Produkt als mit der Performance des Teams zusammenhängen. Diese können durch eine entsprechende Dokumentation beantwortet werden.
Der Scrum-Master
- Wie hat sich die Velocity des Teams über die letzten Sprints verändert?
- Welche Maßnahmen sind aus den letzten Retrospektiven entstanden? Wie sind wir damit umgegangen?
Aber zurück zum Produkt selbst, denn es gibt auch Fragen außerhalb des Teams, die einem auf den ersten Blick vielleicht gar nicht bewusst waren. So kann sich ein Jurist fragen, ob vertragliche Verpflichtungen eingehalten wurden. Die Betriebsführung muss wissen, wie die einzelnen Features sich in der produktiven Umgebungen verhalten und verwalten lassen. Der Endanwender kann sich fragen, wie das Produkt überhaupt funktioniert. Auch wenn das eine Warnung dafür sein sollte, dass man kein intuitives Produkt auf den Markt gebracht hat, denn im Idealfall ist das Produkt selbsterklärend.
Um ein Fazit zu ziehen: Die Dokumentation soll Stakeholdern Fragen beantworten. Davon gibt es nicht gerade wenige, besonders wenn der Mitarbeiter neu im Unternehmen ist. Bevor man Dokumentationen blind schreibt, sollte man sich bewusst machen, wer die Stakeholder sind, welche Fragen sie haben und dann überlegen wie die Antwort gegeben werden können. In einem Sprint ist oft nicht viel Zeit die unzähligen Fragen aufwendig zu beantworten. Deshalb ist es wichtig fokussiert zu antworten und keine redundante oder unwichtige Sachen aufzuschreiben. Oft reicht auch regelmäßige Kommunikation aus, zumindest was Projektdokumentation betrifft, also dazu dient den Sprint erfolgreich zu bewältigen und nicht in notwendig ist, um zukünftig noch relevante Zusammenhänge zu verstehen (Softwaredokumentation – Ein vielschichtiger Begriff).
Referenzen
Agile Dokumentation 
Ein Kommentar zu „Warum dokumentieren wir überhaupt?“
Kommentare sind geschlossen.