Zum Inhalt springen

Blogeintrag

Jeder will eine Doku, keiner will sie schreiben... warum?

Qualitätsmanager  Prozessmanager  Consulting  Prozessoptimierung 

Uns fällt bei Kundenprojekten immer wieder auf, dass zwar der Wunsch nach Dokumentation in den Teams vorhanden ist aber zu wenig Bereitschaft existiert, diese auch umzusetzen. Woran das liegen könnte, und wie man das einfach ändern kann, wollen wir hier zeigen.

Dokumentation in Softwareprojekten ist wichtig. Bietet eine gute Dokumentation doch die Möglichkeit der Einarbeitung und ist eine Basis für die gemeinsame Analyse. Die Dokumentation ist also ein Mittel der Kommunikation. Oft jedoch, wird der Nutzen der Dokumentation in den Hintergrund gestellt und lediglich der Aufwand gesehen. Bei den Aufwänden in Bezug auf die Dokumentation sollte man jedoch zwei Dinge unterscheiden: Zum Einen das Herausarbeiten der Dinge, die ich dokumentieren möchte, zum Anderen die reine Verschriftlichung dessen, was ich erarbeitet habe. Ersteres darf man jedoch nicht dem Dokumentationsaufwand zurechnen, das das ja unabhängig davon sowieso geschehen muss. Ist das Bild dann klar, so ist die reine Verschriftlichung, also die Dokumentation in engerem Sinne, der eher kleinere Teil.

Ein weiteres Missverständnis ist die häufige Annahme, dass eine Dokumentation nur dann Sinn macht, wenn sie "viel" Information enthält , was dann viele abschreckt, sie umzusetzen. "Viel"  und „Vollständigkeit“ sind aber keine Ziele von Dokumentation und auch keine Qualitätsmerkmale, denn letztlich kann eine Dokumentation zweckunabhängig nie vollständig sein. Wo sollte man auch aufhören, wie weit sollte man z.B. bei einer Architekturdokumentation auch zurückgehen? Bis zu Modellierungsprinzipien, bis zur Turingmaschine, bis zur 0/1 Codierung usw. ?

 

Welchen Umfang, Struktur, Inhalt und Sprache eine Dokumentation hat bzw. verwendet, hängt vielmehr von der Zielgruppe und dem Zweck ab, den die Zielgruppe mit der Dokumentation verfolgen möchte. Ein "Big Picture", das dem Management präsentiert wird und z.B. die wesentlichen Konzepte, Umfänge, Kosten Zeiten und Ziele einer Architektur zum Ausdruck bringt, sieht anders und vor allem kleiner aus, als eine umfassende Architekturdokumentation, die bestimmte ISO Normen in hoch kritischen Fachdomänen erfüllt und Modelle enthält, die eine direkte und vollständige Generierung von Code ermöglichen. Daher sollte die erste Frage, bevor man mit einer Dokumentation startet, immer sein: "Für wen und zu welchem Zweck?". Erst dann entscheidet sich, welcher Umfang dafür notwendig ist. Weitere Qualitätsmerkmale, die dann als Bewertungsrahmen dienen können, sind:

  • Verständlichkeit: Welches Wissen kann man bei der Zielgruppe voraussetzen, wo muss man sich an den Wissensgrad anpassen?
  • Wartbarkeit: Wie und wo ist in Zukunft mit Änderungen zu rechnen, und wie (einfach) muss die Dokumentation anpassbar sein?
  • Effizienz: Was erwartet die Zielgruppe von mir, dass sie die Information aus den Dokumenten zum Erreichen des Zwecks effizient erhalten kann?
  • Angemessenheit: Ist der Umfang dem Zweck entsprechend angepasst?
  • Korrektheit: Sind und bleiben die Informationen korrekt? Und wie kann ich sicherstellen, dass keine Fehler enthalten sind bzw. in zukünftigen Versionen entstehen?

Behält man diese Aspekte im Auge, ist die Motivation eine Dokumentation zu erstellen und zu warten, deutlich höher. Die Anfangshürde wird deutlich geringer, da der Anspruch bzw. die Annahme „viel“ dokumentieren zu müssen, um eine qualitativ hochwertige und praktisch brauchbare Dokumentation zu schreiben, so nicht mehr haltbar ist. Richtig zu dokumentieren ist also der Schlüssel zum Erfolg, weshalb es z.B. auch entsprechende Lehrpläne der ISAQB bei den Advanced Leveln gibt, dies zu erlernen.

Kontakt für Anfragen

Johannes Bergsmann Profilbild

Johannes Bergsmann

johannes.bergsmann@software-quality-lab.com

 +43 676 840072 420

Fachlicher Kontakt

Stephan Christmann Profilbild

Stephan Christmann

stephan.christmann@software-quality-lab.com

 +43 732 890072-160
 +43 676 840072-160