Softwaredokumentation – Ein vielschichtiger Begriff

Veröffentlicht am von ckollmeier

Bevor ich in weiteren Blog-Artikeln über Dokumentation im agilen Umfeld schreibe, möchte ich mir zunächst einmal die Grundlagen zur Softwaredokumentation ansehen. Liest man den entsprechenden Wikipedia-Artikel soll eine Dokumentation zeigen, wie die Software funktioniert. Wie geht sie mit Daten um, was ist im Betrieb zu beachten und auf welcher technischen Grundlage wurde entwickelt? Das bedeutet, es kann gar nicht die eine richtige Dokumentation geben.

In ihrem Buch „Software Engineering“ gehen Jochen Ludewig und Horst Lichter noch weiter und beziehen nicht nur das Produkt, sondern auch die Entwicklungsprozesse in ihre Definition von Softwaredokumentation mit ein. Sie haben deshalb vier Kategorien von Dokumentation, die jeweils verschiedene Artefakte beinhalten:

  • Die Prozessdokumentation bildet den Entwicklungsprozess ab.
  • Die Projektdokumentation dient dazu, die Entwicklung zu unterstützen und den Status des jeweiligen Projekts wiederzugeben.
  • Die Systemdokumentation beschreibt, wie das Produkt funktioniert, welche Daten es wie verarbeitet und wie es zu bedienen ist.
  • Die Qualitätsdokumentation beinhaltet Dokumente wie Test-Berichte, Abnahmeberichte oder Audit-Protokolle.

In der agilen Entwicklung gibt es diese Arten von Dokumentation natürlich auch. Allerdings ist vieles im optimalen Fall durch die Wahl der agilen Methoden vorgegeben oder durch den hohen Grad an Kommunikation nur noch implizit vorhanden.

So würde ich die Defintion of Done und die Defintion Ready (sofern man sie als Teil von Scrum sieht) sowie wiederkehrende Ereignisse wie das Daily am Sprintboard als Prozessdokumentation bezeichnen. Sie geben vor, wie das Team bei der Abarbeitung von Anforderungen vorgeht.

In Scrum werden oftmals User Stories verwendet, um die Anforderungen im Backlog zu verwalten. Im Planning werden dann Subtasks abgeleitet und auf das Sprintboard übertragen. Hier kann man jederzeit genau den Status einzelner Anforderungen einsehen. Möchte man den Status des gesamten Sprints betrachten, kann ein Burndown-Chart herangezogen werden. All das sehe ich als Projektdokumentation an, die durch die Verwendung von Scrum vorgegeben ist.

Die Systemdokumentation beschreibt, wie das Produkt funktioniert. Das kann durch fachliche Beschreibungen in einem Wiki, Definition von Testfällen oder dem Programmcode selbst geschehen. Manchmal ist auch ein Benutzerhandbuch für den Endanwender sinnvoll. In wie weit man eine Beschreibung des Produkts jenseits des Codes in der agilen Welt überhaupt braucht, ist nicht durch Scrum vorgegeben. Der Blog wird sich daher zu großen Teilen mit der Produktdokumentation (=Systemdokumentation) beschäftigen.

Im agilen Gedanken ist der Anspruch an Qualität tief verankert. Umfangreiche Qualitätsdokumentation sehe ich dennoch oder besser deshalb nicht. Qualität entsteht durch den ständigen Austausch und durch das interdisziplinäre Team. Man sollte keinen schriftlichen Abnahmebericht mehr benötigen, vielmehr sollte das frühzeitig im Dialog zwischen Productowner und Team geklärt werden. Auch die Ergebnisse aus internen Tests sollten während des Sprints ohne große Dokumentation auskommen. Fallen Fehler außerhalb des Sprint bzw. der betroffenen Story auf, müssen diese natürlich in einer Datenbank oder im Backlog festgehalten werden.

Als Fazit kann man sagen, dass viele Arten der Softwaredokmentation durch ein standardisiertes Vorgehen und einen regelmäßigen Austausch in das agile Arbeiten eingebunden sind. Es muss geklärt werden, in wie weit Produktdokumentation dazugehört. Um das zu klären, sollte man wissen, warum überhaupt dokumentiert wird. Dazu möchte in nächsten Blogbeitrag etwas schreiben.

Referenzen

Autor: