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.
Wie wahr … Vor allem der letzte Absatz „Projektabschluss-Hektik“ kommt mir irgendwie bekannt vor 🙂
Ich versuch die Probleme übrigens in den nächsten Beiträgen zu lösen. Wird also wieder was über Scrum geben.
Gang und G_ä_be.
„Die Welt dreht sich weiter“ ist imho eher ein Symptom dafür, dass das Projekt zu groß angelegt wurde.
@nk: Da würde ich dir widersprechen. Ab wann ist ein Projekt für dich zu groß? Nehmen wir einfach mal ein Webprojekt.
@Nils
nk schrieb „… Projekt zu groß angelegt wurde“.
So wie ich das verstehe, ist zu viel bereits vorab geplant worden, was sich nachher nicht als praktikabel oder machbar hearusstellte.
Also nicht iterativ.
Dann passt die Aussage IMHO.
An dieser Stelle nochmals der Hinweis, dass das Waterfall eigentlich als nicht funktionierendes Entwicklungsmodell vorgestellt wurde, aber in der ersten Hälfte des ursprünglichen Vortrages als „super“ dargestellt wurde. Nur durch einen groben Fehler gibt es das Wasserfallmodell.
Näheres dazu: https://gist.github.com/710960
Aus purer Erfahrung heraus behaupte ich mal daß 1. Entwickler und Projektmanager allgemein viel viel viel mehr planen & diskutieren sollten (anstatt sich gleich an den Rechner zu setzen), 2. Projektmanager generell einfach viel mehr Ahnung vom Entwickeln haben müssen (ihr würdet mir nicht glauben was ich in den letzten 10 Jahren alles so erlebt hab) und 3. Projekte einfach viel viel besser schriftlich definiert werden sollten.
Fast alles, was ich in den letzten 10 Jahren in der Entwicklung so erlebt hab hätte unfassbar viel besser laufen können, wenn sich alle Beteiligten mehr zusammengesetzt hätten.
@Don Zampano: Dann darf man aber keine Projekte mehr beginnen, die länger dauern als 30 Tage, oder?
@Nils
Ich verstand „zu groß“ nicht quantitativ, sondern qualitativ.
Also „das und das und das müssen wir machen“ (und stellen fest, dass wir die Hälfte davon nicht brauchen….