Probleme bei klassisches Vorgehensmodellen in der Softwareentwicklung

Lesetipps

1. “Kunden, die diesen Artikel gekauft haben, kauften auch” in der Softwareentwicklung
2. Warum Scrum funktioniert (Teil 1): Unvorhersehbarkeit
3. 90% Syndrom

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.

10 Kommentare »

• 
  

  Casa Rock!

  am 19. Januar 2012 um 08:47 Uhr

  Mein Zitat des Tages…

  Nils Langner schreibt in seinem Blog PHP hates me über Probleme bei klassisches Vorgehensmodellen in der Softwareentwicklung und spricht mir aus der Seele. Mein Lieblingsabsatz “Misslungene Schätzungen”: Sich das fachliche Feinkonzept zu Ge…

• 
  

  Christoph Batik

  am 19. Januar 2012 um 09:15 Uhr

  Wie wahr … Vor allem der letzte Absatz “Projektabschluss-Hektik” kommt mir irgendwie bekannt vor

• 
  

  Nils Langner

  am 19. Januar 2012 um 09:23 Uhr

  Ich versuch die Probleme übrigens in den nächsten Beiträgen zu lösen. Wird also wieder was über Scrum geben.

• 
  

  nk

  am 19. Januar 2012 um 20:37 Uhr

  Gang und G_ä_be.

  „Die Welt dreht sich weiter“ ist imho eher ein Symptom dafür, dass das Projekt zu groß angelegt wurde.

• 
  

  Nils Langner

  am 20. Januar 2012 um 08:10 Uhr

  @nk: Da würde ich dir widersprechen. Ab wann ist ein Projekt für dich zu groß? Nehmen wir einfach mal ein Webprojekt.

• 
  

  Don Zampano

  am 20. Januar 2012 um 13:34 Uhr

  @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.

• 
  

  Dennis Becker

  am 20. Januar 2012 um 13:43 Uhr

  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

• 
  

  Chris

  am 20. Januar 2012 um 18:19 Uhr

  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.

• 
  

  Nils Langner

  am 21. Januar 2012 um 08:21 Uhr

  @Don Zampano: Dann darf man aber keine Projekte mehr beginnen, die länger dauern als 30 Tage, oder?

• 
  

  Don Zampano

  am 23. Januar 2012 um 10:21 Uhr

  @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….

RSS Feed für Kommentare zu diesem Artikel. TrackBack URL

Hinterlasse einen Kommentar