Das klassische Projektmanagement, bzw. das wasserfallartige Projektvorgehen ist Dokumentgetrieben. Es werden Lasten- und Pflichtenhefte erstellt und über den Fortschritt wird in Form von Statusberichten in diversen Gremien berichtet. Im agilen Kontext wertschätzen wir dagegen den echten Fortschritt der Software. Dieser wird präsentiert und es wird nichts gezeigt, was nicht wirklich fertig ist. Keine Mockups, Dokumente die Konzepte beschreiben, isoliert fertiggestellte (nicht integrierte) Module, …
Die agile Entwicklung fokussiert grundlegend auf den Nutzen von Software und dessen Weiterentwicklung. Der Fortschritt der Produktentwicklung wird deshalb in „Nutzen der funktionierenden Software“ gemessen. Da es fortlaufend funktionierende Software gibt, kann zu dieser auch kontinuierlich und schnell Feedback eingeholt werden, was wiederum die Priorisierung und damit Fokussierung auf die wichtigsten Funktionen unterstützt.
Meine Erfahrung ist allerdings nicht, dass in agilen Projekten deshalb nicht dokumentiert wird. Im Gegenteil. Da in agilen Projekten kontinuierlich funktionierende Software produziert und ausgeliefert wird, wird auch die Dokumentation kontinuierlich gepflegt, da diese ja auch für die Entwicklung, den Betrieb und die Benutzer benötigt wird. Wo ich bei klassischen Projekten eher erlebe, dass die Dokumentation vernachlässigt wird und hinten runterfällt. Selbstverständlich müssen auch die Anforderungen an die Dokumentation im Zusammenhang mit der Compliance erfüllt werden. Allen Beteiligten fällt es leichter, die Dokumentation kontinuierlich aktuell zu halten und als Unterstützung der gemeinsamen Entwicklung zu nutzen, als das lästige übel, was zum Schluss noch erstellt werden muss – oder angepasst werden muss, weil das Endprodukt nichts mehr mit der vorher geplanten Dokumentation zu tun hat.
Schreibe einen Kommentar