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.
Kommentare
Einen Kommentar schreiben