Lean Documentation Teil 2

Dokumentation zur rechten Zeit

Effiziente und zeitnahe Dokumentation bei stabilem Zustand

Wie bereits in Teil 1 erwähnt hat sich die Konkretisierung von Anforderungen kurz vor der Berücksichtigung in einem Sprint bewährt. Aber auch bei den übrigen Dokumenten gilt: Dokumentiere das Umgesetzte - also die Ergebnisse - dann, wenn ein stabiler Zustand erreicht ist und dokumentiere nicht auf Verdacht.

Sobald ein stabiler Zustand erreicht ist, sollte dieser zeitnah dokumentiert werden. Das hat meiner Meinung nach die Vorteile, dass

  • es „nebenbei“ erledigt werden kann; regelmäßig und fortlaufend zu dokumentieren als am Ende alles, sollte effizienter sein. Es ist außerdem einfacher sich täglich für 10 Minuten für das Aufräumen zu motivieren als sich das ganze Haus (inkl. Garten) an einem Wochenende vorzunehmen.
  • das Wissen aktuell noch frisch in den Köpfen ist und nicht später „mühsam“ zusammengesucht werden muss (vermeide Verschwendung). Damit ist zwar auch die Gefahr gegeben, dass Dokumentation aufgrund von Änderungen auch mal wieder über den Haufen geworfen werden muss. Aber mal ehrlich – in einer agilen Welt heißen wir Änderungen willkommen und ändern Programme auch ohne zu murren
  • Kollegen während der Entwicklung von der Dokumentation profitieren können
  • am Ende des Projekts kein großer Block „Dokumentation“ in der Aufgabenliste steht, der dann auch noch Gefahr läuft gestutzt oder sogar gestrichen zu werden
  • die Möglichkeit besteht, durch die erstellte Dokumentation auf Lücken in der aktuellen Entwicklung zu stoßen
  • die Dokumentation als Bestandteil des Produktes wahrgenommen und die Identifikation mit der Dokumentation größer wird.

Redundanzen vermeiden

In Projekten sollte es verschiedene Ergebnistypen von Dokumentationen geben, die für ein dediziertes Ziel erstellt werden. Zwischen den Ergebnistypen sollte es keine Redundanzen geben. Das vermeidet Verschwendung indem es z.B. die Pflege erleichtert oder auch Informationen leichter auffindbar macht. Ein Betriebshandbuch sollte nicht über fachliche Hintergründe informieren, sondern lediglich die für den Betrieb notwendigen Details beinhalten. Sollte ein Operator an der Fachlichkeit interessiert sein, so kann die Produktbroschüre für einen schnellen Überblick oder auch das Anwenderhandbuch für einen tieferen Einblick herangezogen werden.

Kurze Feedbackschleifen

In Scrum sieht jeder Sprint ein Review vor. Die Entwickler präsentieren die Ergebnisse des Sprints und die Stakeholder geben Feedback und Input für die kommenden Sprints. Dieses sollte auch für Dokumentation gelten: Im Rahmen der Dokumentation können regelmäßige Reviews dafür sorgen, dass die Inhalte den Anforderungen der Adressaten frühzeitig angepasst werden können. Mit jedem Review wird die Qualität erhöht.

Berücksichtigung in agilen Projekten

In agilen Projekten sollte die fortlaufende Dokumentation von Ergebnissen per Definition zu einem Entwicklungszyklus gehören. Zu einem Produktinkrement gehört die aktuelle Dokumentation dazu, wenn es potentiell ausrollbar sein soll.

In der DoD (Definition of Done) könnte vereinbart werden, wie die Dokumentation in einem Sprint zu berücksichtigen ist.

Was wäre wenn …? Nur ein Denkanstoß!

Die Wichtigkeit einer angemessenen Anforderungsdokumentation wurde bereits in diesem Artikel erwähnt.

Wie kann die Anforderungsdokumentation im Sinne des Lean Gedanken noch mehr Wert schaffen?

Die Anforderungen werden so verfasst, dass diese als Grundlage für die Produkt- und Systemdokumentation verwendet werden können. Beispiele:

  • Die Akzeptanztests könnten so verfasst werden, dass diese direkt in den Testkatalog übernommen werden können.
  • Die Anforderungen sind bereits in einer Form erfasst, dass diese als Grundlage des Anwenderhandbuchs dienen.
  • Oder - warum nicht gleich in Form des Anwenderhandbuchs die funktionalen Anforderungen dokumentieren?

6% aller Entwickler dokumentieren gerne

Ehrlich gesagt, habe ich die 6% nur in den Raum geworfen.

Wer dokumentiert gerne? Und kann das vielleicht auch Spaß machen? Auf der Suche nach der Antwort auf diese Frage bin ich im Internet fündig geworden. Allerdings in einem komplett anderen Kontext. Zufällig bin ich auf einer Seite gelandet, die Tipps zum Aufräumen gibt. Damit ist nicht das Aufräumen von Programmsourcen gemeint, sondern das Aufräumen einer Wohnung oder eines Hauses. Sieben dieser Tipps habe ich versucht auf das Thema Dokumentation zu übertragen:

  • Tipp 1: Plane jeden Tag 10 Minuten für das Aufräumen ein

Dokumentiere jeden Tag 10 Minuten – in dieser Zeit schafft man tatsächlich mehr als man glaubt. Und – sich für etwas zu motivieren, dass nur 10 Minuten dauert ist leichter, als wenn man mehrere Stunden dafür einplant. Und – wenn man erst einmal begonnen hat, dann werden aus 10 Minuten auch gerne mal mehr, weil es doch irgendwie Spaß macht etwas zu schaffen.

  • Tipp 2: Lade Dir jemanden nach Hause ein

Bezogen auf die Dokumentation könnte das heißen, dass ich jemanden um ein regelmäßiges Feedback zu einer Dokumentation bitte. Das sollte Motivation genug sein, die Doku zu pflegen. Außerdem bekommt man umgehend Feedback zur Qualität.

  • Tipp 3: Räume auf, bevor Du am Morgen das Haus verlässt

Dieser Tipp adressiert mehrere Punkte gleichzeitig: erledige die unliebsamen Aufgaben (die Dokumentation) als Erstes, damit Du für den Tag den Kopf frei hast und Du Dich auf die schöneren Aufgaben konzentrieren kannst. Außerdem sollte früh am Tag der Energielevel noch entsprechend hoch sein.

  • Tipp 4: Starte dort, wo es am meisten bringt

Erstelle die Dokumentation als erstes, die den meisten Nutzen bringt (z. B. weil es Wildwuchs verhindert oder vielen Kollegen zusätzliche Arbeit erspart)

  • Tipp 5: Wechsel die Räume nie ohne leere Hände

Ergänze sofort fehlende Dokumentation, wenn sie dir in einem Dokument auffällt.

  • Tipp 6: Alles hat seinen Platz und kehrt nach der Verwendung auch dort wieder zurück

Sobald eine neue Funktionalität erstellt wurde, wird die Auswirkung auf die verschiedenen Dokumente umgehend festgehalten.

  • Tipp 7: Ordnung halten heißt auch wegwerfen

Fallen bei der Dokumentation Passagen auf, die nicht mehr gültig sind, dann müssen diese bereinigt werden.

 

Fazit

Das Anforderungsmanagement und die Bedeutung der Dokumentation in agilen Projekten haben mich motiviert das Thema Dokumentation weiter zu vertiefen und einige Aspekte davon in diesem Artikel zu teilen. Es gibt sicherlich zahlreiche weitere Aspekte.

Wie eingangs erwähnt: Dokumentation ist wertvoll, wenn sie tatsächlich von jemandem gebraucht wird, zur rechten Zeit verfügbar, leicht auffindbar, richtig und verständlich und so kurz wie möglich ist. Diese Zusammenfassung sollte man bei der Dokumentation stets im Hinterkopf haben.

Und jetzt wo die Arbeit erledigt ist, fällt mir noch ein Aufräum-Tipp ein, der immer geht:

Tipp 8: Belohnung - Nach getaner Arbeit darf auch gerne eine Belohnung her. Wie wäre es mit einer besonders interessanten User Story, die Sie sich ziehen. Kaffee und Süßigkeiten gehen natürlich auch.

 


Jetzt teilen:

Kommentare

Einen Kommentar schreiben

Bitte rechnen Sie 1 plus 8.

Wir verarbeiten Ihre personenbezogenen Daten, soweit es für die Bereitstellung des Kommentars sowie zur Sicherstellung der Integrität unserer informationstechnischen Systeme erforderlich ist. Sie sind zur Bereitstellung dieser Daten nicht verpflichtet, eine Nutzung der Kommentarfunktion ist ohne die Bereitstellung jedoch nicht möglich. Weitere Hinweise zum Datenschutz finden Sie in der Datenschutzerklärung.