Probleme bei klassisches Vorgehensmodellen in der Softwareentwicklung

Herangehensweisen wie das Wasserfall- und V-Modell wurden die letzten Jahre häufig eingesetzt und sie können auch funktionieren. Aber leider nicht in der Softwareentwicklung bei Webanwendungen. Das Internetbusiness ist viel zu schnelllebig und unberechenbar, dass starre Modelle zum Erfolg führen würden. Betrachtet man die Gesamtheit der begonnenen Anwendungen so erkennt man diverser Muster, die immer wieder bei gescheiterten Projekten auftreten.

Die Welt dreht sich weiter

Baut man ein Haus, so ist das Vorgehen klar. Man engagiert einen Architekten, dieser entwirft das Anwesen und es wird im Anschluss von der Baufirma erstellt. In einem solchen Fall würde Wasserfall das Projekt zum Ziel bringen. Es ist verständlich, dass man nach dem Abschluss des Kellers nicht mehr auf die Idee kommen sollte, dass man vielleicht doch einen Indoor-Pool haben möchte.
Bei Internetanwendungen ist dies aber Gang und Gäbe. Sobald ein Feature fertig ist, stürzen sich die Projektmanager und Konzepter darauf und verbessern bzw. erweitern es. Und das ist auch gut so, denn die Welt hat sich in der Zwischenzeit weitergedreht. Neue Ideen sind entstanden und die Konkurrenz ist mittlerweile auch ein Stück weitergekommen. Alles gute Gründe auch weiter zu denken.
Im klassischen Wasserfall sind Änderungen während der Entwicklung nicht geplant. Kostspielige Änderungsanforderungen müssen eingekippt werden und wahrscheinlich muss auch der Auftrag geändert werden, da der Umfang, der am Anfang geplant wurde, nicht mehr aktuell ist.

80-Prozent-Syndrom

Projekte haben viele Teilaufgaben. So viele Teilaufgaben, dass es eine gute Idee erscheint, zu parallelisieren. Dies ist auch bedingt richtig. Wenn man viele Teammitglieder hat, dann kann man es probieren. Die Bedeutung für das Projekt ist leider häufig sehr ähnlich. Von den 20 gleichzeitig angegangenen Aufgaben sind 15 offen, aber zu 80 Prozent fertig. Leider kann man erst wirklich was damit anfangen, wenn es 100 Prozent sind.

Misslungene Schätzungen

Sich das fachliche Feinkonzept zu Gemüte zu ziehen und danach eine präzise Schätzung abzugeben hat noch nie geklappt. Trotzdem passiert es immer wieder, dass ein Projektmanager oder ein einzelner Entwickler diese Aufgabe zugeschustert bekommt, dass dies im Normalfall bis zu 500 Prozent danebenliegen kann, ist empirisch belegt. Bei besonders hartnäckigen Projektleitern, kann es auch vorkommen, dass diese Schätzung bereits in einem frühen Projektstadium in Stein gemeißelt wird und die TV-Werbung für den Launch sozusagen schon auf den Tag genau gebucht wird. Eine Anpassung des Zeitplans ist somit nicht mehr möglich.

Priorisieren

Fragt man den Auftraggeber, welches Feature besonders wichtig für den Erfolg des Projektes ist, dann ist die Antwort oft die gleiche. Alle. Viele. Für das Priorisieren ist dies recht kontraproduktiv. Das Team muss entscheiden was zuerst angegangen wird. Wenn dann aber dann an einem bestimmten Meilenstein das falsche fertig ist, wird es den Entwicklern vorgeworfen.

Projektabschluss-Hektik

Das Gute an klassischen Projekten ist, dass auch sie irgendwann mal ein Ende finden. Nur leider ist das Ende meist mit Überstunden, Druck und Stress verbunden. Alles was man bis kurz vor dem Abschluss noch nicht implementiert bekommen hat, muss jetzt in kürzester Zeit nachgeholt werden.  Meist wird in einer solchen Phase auch auf Qualität keinen großen Wert mehr gelegt. Erfahrungsgemäß sind Unit Tests das erste was gestrichen wird, wenn ein Projekt  unter Stress zu Ende geführt wird.