Foto: Berger, OVGU-Pressebild

Methode für die Dokumentation in agilen Projekten

Kritiker und Befürworter der agilen Vorgehensweisen diskutieren über die „richtige“ Interpretation der Leitsätze, Werte und Prinzipien des Agilen Manifestes. Ein häufiges Missverständnis agiler Methoden ist die Verkürzung des zweiten Leitsatzes des Agilen Manifestes, wonach Dokumentation in agilen Verfahren keine Rolle spielt. Dokumentation wird teilweise von agilen Vertretern als unnötig angesehen. Dabei besteht kein zwingender Widerspruch zwischen agilen Methoden und Dokumentation. Auch agile Entwicklung benötigt ein gewisses Maß an Modellierung und Dokumentation.

In Forschung und Praxis fehlen bisher Methoden, die die Dokumentation der Entwicklungsartefakte unterstützen und dennoch mit den Grundsätzen der agilen Entwicklung vereinbar sind. Entsprechend der häufig geäußerten Kritik an agilen Methoden, sie seien nur für kleine Projekte geeignet, wurde bei der Konzeption der Methode vor allem auf deren Skalierbarkeit geachtet. Anhand einer Morphologie von Projekteigenschaften können ein geeigneter Agilitätsgrad und eine passende Dokumentationsstufe zur Skalierung der Dokumentationsmethodik abgeleitet werden.

Die Beschreibung der Methode erfolgt entlang der Fragen: Warum wird dokumentiert? Für wen (Zielgruppe) wird dokumentiert? Was wird dokumentiert? Welche Dokumente entstehen? Wieviel wird dokumentiert? Woher kommen die Informationen? Wie wird dokumentiert? Womit wird dokumentiert? Wer dokumentiert? Wann werden Dokumentationsschritte angestoßen?

Zusammenhänge der durch die Methode beantworteten Fragen
Zusammenhänge der durch die Methode beantworteten Fragen

Wird die Zielstellung der Dokumentation (WARUM) als Ausgangspunkt angenommen, beeinflusst dies direkt die Zielgruppe (FÜR WEN) und damit die zu dokumentierenden Inhalte (WAS). Die Zielgruppe bestimmt sowohl die Inhalte als auch den Umfang und das Werkzeug mit dem dokumentiert werden soll. Entwickler benötigen bspw. andere Inhalte in einer Dokumentation als Führungskräfte in einem unterschiedlichen Detailierungsgrad. Manager erwarten ggf. andere Formate der Aufbereitung (z.B. in Form von PowerPoint-Folien) als Entwickler, so dass die Zielgruppe auch Einfluss auf die Wahl des geeigneten Dokumentationswerkzeugs hat. Die festgelegten Dokumentationsartefakte (WELCHE) bestimmen die Quellen aus denen sie sich speisen (WOHER), bspw. wird ein Dokument zur Anforderungsspezifikation aus dem Product- bzw. Sprint-Backlog generiert werden. Aus der Art des Dokumentes (WELCHE) lassen sich Rückschlüsse auf den Umfang (WIEVIEL) der zu dokumentierenden Informationen schließen. So ist ein Projektüberblick eher kurz und knapp gehalten, ein Architekturdokument besteht hingegen aus einem Überblick aller Komponenten und Detailbeschreibungen aller Komponenten.

Die Wahl der Inhalte der Dokumentation (WAS) hat direkten Einfluss auf die Art und Weise ihrer Ausgestaltung (WIE). Beispielsweise bieten sich für die Beschreibung der Architektur Diagramme zur Verdeutlichung an, während Testergebnisse automatisch erstellte Dokumente sein können. Die Art und Weise der Dokumentation (WIE) hat direkten Einfluss auf die Wahl des geeigneten Dokumentationswerkzeuges (WOMIT).

Die Ausgestaltung der Dokumentationsrolle (WER) beeinflusst den Prozess der Dokumentation (WANN) und die Art und Weise (WIE). Dokumentiert der Entwickler selbst, so kann er parallel zur Programmierung Informationen niederschreiben, die für die Dokumentation relevant sind. Wird ein Dokumentationsverantwortlicher gewählt, ist diese Person auf Zuarbeiten der Entwickler angewiesen und wird wahrscheinlich erst nach Fertigstellung von Funktionalität mit der Dokumentation beginnen können. Ein spezialisierter Dokumentar wird wiederum anders dokumentieren als ein Entwickler, wodurch die Art und Weise der Dokumentation beeinflusst wird.

Das im sprintDoc-Projekt entstehende integrierte Konzept zur Dokumentation in agilen Softwareprojekten besteht sowohl aus einer Methode als auch aus einem unterstützenden Werkzeug. Die Methode muss daher im Werkzeug abgebildet werden. Dazu gehört zum einen, dass die Methode als Beschreibung im Werkzeug enthalten ist (siehe nachfolgende Abbildung sowie im sprintDoc-Demosystem). Zum anderen gehört auch die Unterstützung des Anwenders begleitend zur Dokumentation dazu. Um die Methode anzuwenden muss das Werkzeug von den Nutzern akzeptiert werden.

Methodenbeschreibung innerhalb des sprintDoc-Werkzeugs
Methodenbeschreibung innerhalb des sprintDoc-Werkzeugs

Den Entwickler bei Dokumentationsaufgaben zu unterstützen und den Weg zu einer guten Dokumentation zu ebnen, ist eine wichtige Funktion des Dokumentationswerkzeugs. Da das Werkzeug die Dokumentation von agilen Softwareprojekten unterstützen soll, kommt das Werkzeug spätestens beim Projektstart zum Einsatz. Zum Projektbeginn sollte auch ein Dokumentationsprojekt im Werkzeug angelegt werden. In der Methode sind zwei Wege vorgesehen, um den Projektverantwortlichen (z.B. Projektleiter oder Scrum-Master) bei der Konfiguration des Dokumentationsprojektes zu unterstützen. Die Dokumentationsziele oder die Projekteigenschaften bestimmen den Grad der Dokumentation (Stufe 1 bis 3). Das Werkzeug soll daher diesen Prozess unterstützen und auf Basis entweder der Dokumentationsziele oder der Projekteigenschaften eine Dokumentationsstruktur vorschlagen.

Konfiguration einer Projektdokumentation in Abhängigkeit der Dokumentationsziele oder Projekteigenschaften
Konfiguration einer Projektdokumentation in Abhängigkeit der Dokumentationsziele oder Projekteigenschaften

(Anmerkung: Der vorliegende Text ist der Dissertation Entwicklung eines integrierten Konzeptes für die Dokumentation in agilen Softwareprojekten“ von Stefan Voigt entnommen, die in Kürze veröffentlicht wird.)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.