Agilität – Die häufigsten Missverständnisse

Falsch: Agil bedeutet, ohne Dokumentation zu entwickeln

Die Aussage, dass in agilen Projekten nichts dokumentiert wird, wird sehr häufig formuliert. Agil und „ohne Dokumentation“ gehören aber nicht zwangsläufig zusammen. In agilen Projekten ist die einzige relevante Regelgröße (Output des Entwicklungsprozesses) die laufende Software. Das ist in traditionellen Projekten oft anders. Dort wird ein erstelltes Dokument als messbares Ergebnis oder Meilenstein angesehen. Ein Dokument ist dann also eine Regelgröße, anhand der man den Zielerreichungsgrad des Projektes ablesen kann. Aber was wurde da wirklich gemessen? Kann der Kunde mit einem Dokument etwas anfangen?

Dokumente sind in agilen Projekten keine Meilensteine, weil sie dem Kunden keinen geschäftlichen Nutzen bringen und weil man in Wahrheit damit auch nicht den Fortschritt des Projektes messen kann. Nur die laufende Software ist relevant. Hier wird ultimativ klar, ob die Anforderungen des Kunden richtig umgesetzt worden sind. Deswegen stehen zum Beispiel Entwurfs- oder Analyse-Dokumente nicht im Mittelpunkt des Interesses, sondern dienen nur als Mittel zum Zweck. Wenn es aber hilft, die Anforderungen aus dem „Backlog“ umzusetzen, dann wird dokumentiert. Wenn es hilft, dem Endbenutzer die neuen Funktionen der Anwendung nahe zu bringen, dann wird auch dokumentiert.

Richtig: Wenn ein Entwickler in einem agilen Team aus Zeitgründen zwischen Kodieren und Dokumentieren auswählen muss – und er auch ohne Dokumentation zum Ziel kommt (laufende Software) -, dann entscheidet er sich für das Kodieren.

Falsch: Agil bedeutet, nicht zu modellieren

Diese Aussage ist genauso falsch wie die Aussage zur Dokumentation. Selbst in Extreme Programming (XP), einer sehr informalen agilen Vorgehensweise, wird vorgeschlagen, komplexe und wichtige Teile des Systems zu modellieren – und zwar immer dann, wenn es hilft, sauber zu implementieren. Dazu wird aber eher Bleistift und Papier oder das Whiteboard vorgeschlagen, anstatt ein UML Tool.

Falsch: In agilen Projekten lässt sich der Fortschritt nicht messen oder kontrollieren

Diese Aussage kann man gut an dem oben eingeführten Regelkreis widerlegen. Der reale Fortschritt eines Projektes lässt sich tatsächlich nirgendwo besser ablesen als in einem agilen Projekt: nämlich durch die laufende Software. Schon ´mal in einem Projekt gearbeitet, das drei Wochen vor Ablieferung drei Monate Verzug anmelden musste? Oder schon ´mal drei Monate an etwas entwickelt, was der Kunde dann später völlig auf den Kopf gestellt hat? Vielleicht lag es daran, dass die falschen Regelgrößen gemessen wurden. Dokumente sind keine verlässlichen Regelgrößen, mit denen man den Fortschritt des Projektes bemessen könnte. Abgekürzt liegt das daran, dass man sich anhand eines Dokuments die beschriebene Anwendung nur (mehr oder weniger gut) vorstellen kann. In agilen Projekten gibt es deswegen nur eine universelle Regelgröße: die laufende Software. Daran kann man definitiv abmessen, ob die Anforderungen des Kunden, die im Backlog standen, wirklich abgearbeitet wurden.

Richtig: Es gibt wahrscheinlich keine bessere Fortschrittskontrolle (Regelgröße im Regelkreis) als laufende Software.

Kein Dokument kann ein laufendes System ersetzen, mit dem der Kunde die ersten Funktionen ausprobieren kann. So früh wie möglich und so schnell wie möglich sollte man deswegen dem Kunden die laufende Software zeigen. In agilen Projekten ist das ein wesentliches Kriterium. Wenn man jetzt noch die hoch priorisierten Anforderungen zuerst bearbeitet (die stehen im Backlog ganz oben!), dann bewegt man sich nahe am Maximum an Planbarkeit in einem Software-Projekt.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.