Ohne Anforderungen kein Projekt

Haben Sie schon einmal G- oder F-Junioren beim Fußballspielen zugeschaut, also Kindern im Alter zwischen sieben und neun Jahren? Wenn ja, dann wissen Sie, dass das mit Raumaufteilung auf dem Platz nicht viel zu tun hat. 22 Kinder laufen, wie magnetisch angezogen, hinter dem Ball her und bilden eine Art komprimierte Wolke um das lederne Rund, wie Wespen um eine stehengebliebene Sommerlimonade. Und wenn dann ein Kind einmal den Ball hat, so dauert es nur den Bruchteil von Sekunden, bis das Bein des Gegners oder auch des eigenen Mitspielers im Wege steht, um jedes sinnvolle Weiterkommen im Keim zu ersticken. Mit anderen Worten, es herrscht völliges Chaos. 

Ungefähr so muss man sich das vorstellen, wenn in einem Software-Projekt mit der Entwicklung begonnen wird, obwohl noch keine oder nur unzureichende Anforderungen vorliegen. Nur, dass der Ball hier ein nebulöses Ziel ist, von dem jeder zu wissen glaubt, wie es eigentlich aussieht. 

Ohne Ziel ans Ziel? 

Als Testmanager frage ich mich dann immer, wie habt ihr es geschafft, auch nur eine einzige Zeile Code zu schreiben, ohne zu wissen, wohin der Weg führt? Wenn es dann auch noch heißt: „Testet mal!", ist die Verwunderung immer groß, wenn die Tester:innen mit der Gegenfrage antworten: „Wogegen denn?".

Egal ob man in einem klassischen Projekt von Anforderungen oder in einem agilen Projekt von User Storys spricht, ohne sie braucht man gar nicht erst zu beginnen. Trotzdem wird auch heute noch gegen diese goldene Regel verstoßen – man fängt mit dem Dach an, obwohl noch nicht einmal das Fundament gegossen ist. Das Verrückte daran ist, dass die Leute sogar der Meinung sind, dass dieses Chaos bereits ein Projekt sei. Ist es aber nicht! Bereits ein Blick ins Internet (zum Beispiel bei agile-master.de) genügt, um das klarzustellen:

„Ein Projekt ist ein Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen in ihrer Gesamtheit gekennzeichnet ist, wie z. B.: Zielvorgabe, zeitliche, finanzielle, personelle oder andere Bedingungen, Abgrenzungen gegenüber anderen Vorhaben und projektspezifische Organisation."

agile-master.de

Eine Reise ins Nirgendwo

Ohne Anforderungen/User Storys kann aber schwerlich von Zielvorgaben gesprochen werden. Ergo, dann ist es auch kein Projekt. Nur eine grobe Idee/Absicht zu haben, ist kein Projekt. Enthusiastisch aber völlig orientierungslos loszurennen, ist kein Projekt. Es wird auch kein Projekt daraus, nur weil man Entwickler, Qualitätssicherer und eine (Projekt-)leitung und diverse andere Rollen definiert. Solange man nicht zielgerichtet arbeitet und weiß, wohin die Fahrt gehen soll, nützt das alles nichts. Nur etwas als „Projekt" zu bezeichnen, macht es nicht automatisch auch dazu.

Das Alles klingt wie eine Binsenweisheit, denn das, so sollte man jedenfalls meinen, weiß doch jeder. Leider können wir überall erkennen, dass dem nicht so ist. Immer wieder werden wir mit „Projekten" konfrontiert, wo man gegen diese goldene Regel verstoßen hat, sich aber gleichzeitig wundert, warum das alles viel länger dauert als gedacht (mit Absicht vermeide ich hier das Wort „geplant"). Auch im täglichen Leben begegnen wir dem Problem fehlender Vorarbeit immer wieder: Städte versinken durch unzählige Baustellen in Verkehrsstaus, aber nur an einer wird gearbeitet. Eine Straße wird neu asphaltiert, nur, um sie nach einem halben Jahr wieder aufzureißen, weil darunter die Kanalisation saniert werden muss. Ja, selbst die mittlerweile mehr als 2 Jahre anhaltende Pandemie ist ein gutes Beispiel. Im ersten Jahr war man unvorbereitet, was nachvollziehbar war. Im zweiten Jahr kannte man die Probleme/Anforderungen genau – aber geholfen hat es nichts. Man hat im zweiten Jahr genauso kopflos agiert, wie im ersten. Gründe dafür gibt es sicherlich viele, zu entschuldigen sind sie dennoch kaum.  

Lange Rede kurzer Sinn - Ein Fazit

Aus Fehlern lernen bedeutet, dieselben Fehler nicht noch einmal zu machen (Lessons Learned). Insbesondere wenn es um grundlegende Regeln geht. Und eine davon lautet, dass in einem Software-Entwicklungsprojekt nicht mit Entwicklungstätigkeiten begonnen wird, wenn noch keine Anforderungen existieren. Obwohl das rein technisch auch gar nicht möglich sein sollte, wird genau das, mit sehr viel Kreativität immer wieder getan. Ergebnis: Chaos, Zeitverzug und extrem hohe Kosten! Das muss doch nicht sein.

Seminarempfehlung