Risiken der Agilen Software-Entwicklung reduzieren Ein bisschen Wasserfall muss sein

Ein bisschen Wasserfall muss sein

Sowohl agile als auch konventionelle Vorgehensweisen wollen dem Kunden eine Software liefern, die optimal dessen Anforderungen erfüllt und Nutzen erzeugt. Allerdings stehen sich diese beiden Ansätze meist kontrovers gegenüber, denn während das Wasserfallmodell mit einer ausführlichen Spezifikation startet, entsteht diese bei Scrum erst im Lauf des Projekts. Eva Maria Schielein und Dorian Gloski wollen hingegen die Vorteile der beiden Ansätze kombinieren. Anhand eines Beispiels, in dem ihre umfangreichen Praxiserfahrungen einfließen, zeigen sie Risiken beider Vorgehensweisen für Zeit, Budget, Umfang, Qualität und Kundennutzen auf, wenn sie puristisch umgesetzt werden. Mit konkreten Handlungsempfehlungen geben sie Hinweise, wie agiles Projektmanagement mit "ein bisschen Wasserfall" die Vorteile beider Ansätze vereinen kann.

Management Summary

Risiken der Agilen Software-Entwicklung reduzieren Ein bisschen Wasserfall muss sein

Ein bisschen Wasserfall muss sein

Sowohl agile als auch konventionelle Vorgehensweisen wollen dem Kunden eine Software liefern, die optimal dessen Anforderungen erfüllt und Nutzen erzeugt. Allerdings stehen sich diese beiden Ansätze meist kontrovers gegenüber, denn während das Wasserfallmodell mit einer ausführlichen Spezifikation startet, entsteht diese bei Scrum erst im Lauf des Projekts. Eva Maria Schielein und Dorian Gloski wollen hingegen die Vorteile der beiden Ansätze kombinieren. Anhand eines Beispiels, in dem ihre umfangreichen Praxiserfahrungen einfließen, zeigen sie Risiken beider Vorgehensweisen für Zeit, Budget, Umfang, Qualität und Kundennutzen auf, wenn sie puristisch umgesetzt werden. Mit konkreten Handlungsempfehlungen geben sie Hinweise, wie agiles Projektmanagement mit "ein bisschen Wasserfall" die Vorteile beider Ansätze vereinen kann.

Management Summary

Wir empfehlen zum Thema Scrum
3 x 4 Stunden
07.11.2024
1.295,00,-
User Story Mapping - Die Nutzer im Blick mit der Produkt-Landkarte

Stellen Sie Kundenanforderungen – ohne endlose Dokumentationen – strukturiert dar und behalten Sie mit diesem Seminar die Kontrolle über den gesamten Entwicklungsprozess. Mit vielen Praxisübungen und direkt anwendbar. Mehr Infos

Agile Vorgehensweisen erfreuen sich zunehmender Popularität. Sie gelten als das richtige Mittel, um in einem dynamischen Umfeld qualitativ hochwertige Software zu entwickeln, die die Anforderungen der Anwender erfüllt. Traditionelle Vorgehensweisen wie das Wasserfallmodell gelten hingegen als unflexibel, "von gestern" und den Erfordernissen moderner Softwareprojekte nicht mehr gewachsen. Wir meinen allerdings, dass in traditionellen Vorgehensweisen bewährte Mechanismen zur Einhaltung von Zeit und Budget entwickelt wurden, die auch bei agilen Vorgehensweisen vorteilhafte Anwendung finden können.

Wir geben zunächst einen kurzen Überblick über die charakteristischen Eigenschaften der Vorgehensweisen nach dem Wasserfallmodell und nach Scrum. Anschließend analysieren wir anhand eines einfachen Fallbeispiels mögliche Auswirkungen der beiden Vorgehensweisen auf Zeit, Budget und Qualität in einem Projekt. Schließlich betrachten wir die möglichen Risiken detaillierter und geben Handlungsempfehlungen, wie sich diese vermindern lassen.

Wasserfallmodell: In Phasen vom Lastenheft zum fertigen Produkt

Die Umsetzung eines Projekts nach dem Wasserfallmodell erfolgt in einzelnen Phasen, wie sie in Bild 1 beispielhaft dargestellt sind. Jede Phase kann erst begonnen werden, nachdem die vorherige erfolgreich abgeschlossen wurde.

Spezifikation als Vertragsgrundlage

Zu Beginn des Projekts legen Auftraggeber und Auftragnehmer den Liefergegenstand in einer Spezifikation fest, die typischerweise Bestandteil eines Werkvertrags ist. Die gemeinsam von Auftraggeber und Auftragnehmer akzeptierte Spezifikation bietet eine gute Grundlage für die im Projekt zu erbringenden Leistungen. Der Auftragnehmer muss alle in der Spezifikation enthaltenen Anforderungen innerhalb der Vorgaben von Zeit, Budget und Qualität erfüllen.

Umsetzung: Entwurf, Realisierung, Test, Inbetriebnahme

Nachdem die Spezifikation von beiden Seiten abgenommen wurde, wird das IT-System entworfen, erst dann beginnt die Realisierung. Anschließend erfolgen Test und Installation in die Betriebsumgebung, d.h. die Inbetriebnahme. Der Auftraggeber bekommt die von ihm beauftragte Software erst sehr spät zu sehen, normalerweise in der Testphase. Dadurch kann er erst zu einem sehr späten Projektzeitpunkt erkennen, ob die gelieferte Software seinen Anforderungen entspricht.

Sind die Anforderungen in der Spezifikation hinreichend genau beschrieben und nur wenigen Änderungen unterworfen, so lassen sich Projekte nach dem Wasserfallmodell erfolgreich gemäß den Vorgaben umsetzen.

Bild 1: Schematische Darstellung des Wasserfallmodells. In der Regel erfolgt der Übergang von einer Phase in die nächste von oben nach unten. Der Weg zurück ist nur in Ausnahmefällen möglich.

Regelmäßig ergibt sich während der Projektdurchführung jedoch Änderungsbedarf an der Spezifikation. Möglicherweise wurden Anforderungen übersehen, wie z.B. die Schnittstelle zu einem anderen System. Auch kommt es vor, dass Anforderungen zu Widersprüchen führen, die erst bei der Implementierung deutlich werden: Wenn zum Beispiel für eine Benutzerinteraktion sowohl eine extrem kurze Antwortzeit als auch eine aufwendige Plausibilitätsprüfung gefordert wird. Bei der Implementierung stellt sich dann möglicherweise heraus, dass die Berechnung der Plausibilitätsprüfung so lange dauert, dass die geforderte Antwortzeit nicht eingehalten werden kann.

Durch das starre Prozessmuster sind Projekte nach dem Wasserfallmodell im Anforderungsmanagement wenig flexibel. Änderungen des Leistungsumfangs können nur über formale Änderungsanträge (Request for Change = RFC) berücksichtigt werden. Es ist nicht unüblich, dass die Änderungsrate eines durchschnittlichen Projekts ca. 25% des Gesamtumfangs der Spezifikation beträgt. Bei einem traditionellen Vorgehen ist deshalb ein entsprechender Aufwand für die Erstellung und Bearbeitung von RFCs einzuplanen.

Durch die verhältnismäßig langen Phasen und die späte Auslieferung der Software wird Änderungsbedarf oft erst sehr spät erkannt. Damit ergeben sich häufig Konflikte mit Zeit- und Budgetzielen. Möglicherweise sinkt auch die Akzeptanz der Software bei den Anwendern, wenn sich erst bei der Inbetriebnahme herausstellt, dass die umgesetzten Anforderungen nicht ihren tatsächlichen Bedürfnissen entsprechen.

Agile Software-Entwicklung: Anforderungen iterativ umsetzen

Ein bisschen Wasserfall muss sein


Gleich kostenlos weiterlesen!

  • Zum Newsletter anmelden und diesen Artikel freischalten

  • Jede Woche neue Inhalte, Tipps und Tools per E-Mail
Gratis Newsletter bestellen & sofort weiterlesen

 

Hiermit melde ich mich zum Newsletter an. Ich habe die Datenschutzrichtlinien gelesen und akzeptiere diese. Ihre Daten nutzen wir ausschließlich zum Newsletter-Versand und der Messung von Öffnungs- und Klickraten. Sie können sich jederzeit abmelden, indem Sie auf den Link in der Fußzeile unserer E-Mails klicken. Informationen zu unserem Datenschutz finden Sie hier.

Alle Kommentare (10)

Profile picture for user thols@gmx.de
Steffen
Thols

Vielen Dank Fr. Schielein und Herr Gloski für den interessanten Artikel! Den nach meiner Meinung wichtigsten Aspekt hinsichtlich erfolgreicher Projektdurchführung haben Sie am Ende aufgegriffen, nämlich das Vertrauensverhältnis zwischen Auftraggeber und Auftragnehmer. Solange dieses nicht besteht, kann jedes Projekt mit welcher Vorgehensweise auch immer sehr schnell in Schieflage geraten, denn unvorhergesehene Dinge treten in einem Projekt immer auf. Und da nun einmal Menschen zusammen arbeiten (keine Ressourcen, wie viele Projektmanager annehmen!) ist das gegenseitige Verständnis und Vertrauen das A und O. Agile Vorgehensweisen versuchen ja durch die Konzentration auf die entsprechenden Werte diese Art der Zusammenarbeit zu betonen. Noch ein paar Gedanken zu den dargestellten Ereignissen in dem Fallbeispiel: Fall 1: Umstellung der Entwicklungsplattform Das Problem der mangelnden Abstimmung zwischen Entwicklung und Betrieb konnte in der Vergangenheit häufig angetroffen werden. Hier hat sich eine Lösung entwickelt, die unter der Bezeichnung „DevOps“ mittlerweile einen großen Bekanntheitsgrad erreicht hat. Der Grundgedanke ist hier das Zusammenrücken der beiden in der traditionellen Wahrnehmung grundverschiedenen Bereiche Softwareentwicklung und IT-Betrieb. Ich habe selbst erlebt, wie erfolgreich ein direktes Mitwirken eines Kollegen aus dem Betrieb in einem Scrum-Team sein kann, um unangenehme Überraschungen hinsichtlich Rollout zu vermeiden. Fall 2: Aufnahme neuer Anforderungen während der Entwicklung Wie Sie später in dem Artikel ausführen, ist ein Relaseburndown-Chart ein wichtiges Werkzeug, um den möglichen Releasetermin in Abhängigkeit von neu hinzugekommenen oder geänderten Funktionalitäten anzuzeigen. Darüber hinaus ist es sehr wichtig, dass der Product Owner in der Lage ist, den Zeithorizont versus Features im Auge zu behalten und gemeinsam mit dem Entwicklungsteam die Auswirkungen von Änderungen im Product Backlog auf „sein“ Produkt/Projekt abzuschätzen. Hier ist das gesamte Projektteam, d.h. das Entwicklungsteam und der Product Owner gefordert! Fall 3: Komplexe Anforderungen umsetzen Bislang war die Auffassung von „puren Agilisten“ ja so, dass die Architektur nicht mehr vor Beginn der Entwicklung festgelegt wird, sondern sich im Laufe der Programmierung „emergent“ entwickelt. Aber wie Sie in Ihrem Fallbeispiel dargestellt haben, benötigen auch agile Projekte in komplexeren Umfeldern und je nach Erfahrungsstand des Entwicklungsteams und der weiteren Beteiligten einen Architekten. Zu diesem Thema zitiere ich mal einen Kollegen von mir aus einer Publikation: „Die Hauptaufgabe eines Architekten ist es, alle diese unterschiedlichen Interessen und Anforderungen gegeneinander abzuwägen und auszubalancieren sowie Widersprüche aufzulösen und geeignete Kompromisse zu finden. Das ist in erster Linie keine technische oder konzeptionelle Aufgabe, sondern hat sehr viel mit dem Verstehen der verschiedenen Anforderungsdomänen sowie mit Kommunikation, Moderation und Konfliktmanagement zu tun, also mit dem Umgang mit Menschen und ihren Bedürfnissen.“ Und diese Aufgaben sind erst einmal mit keinem Vorgehensmodell verbunden… In diesem Sinne Steffen Thols

 

Andreas
Heilwagen

Für mich beruhen die genannten Schwächen der agilen Welt auf der Annahme dass ein Product Owner nur eine sehr schwache Rolle hat. Dies stimmt nicht mit dem Scrum Guide und der gelebten Praxis erfolgreicher agiler Organisationen nicht überein. Mit Übernahme vieler Projektmanagementaufgaben durch den Product Owner in Scrum und seiner Aufgabe den Grundwert von Scrum "Transparenz" umzusetzen, u.a. durch proaktive Information des Auftraggebers über Risiken, löst man die meisten Schwächen ohne Anleihen im klassischen Projektmanagement. Ich sehe keinen wirklichen Bezug zum Wasserfallmodell im Artikel, vielmehr sollen agile Methoden um Elemente des klassischen Projektmanagements angereichert werden. Meine Lösungsvorschläge für die genannten Schwächen sprengen den Umfang eines Kommentars an dieser Stelle so dass die Details in meinem Blog zu finden sind: http://unlocking-potential.de/2012/04/18/scrum-mit-ein-bisschen-wasserfall-klar-und-popeye-wird-stark-dank-spinat

 

Dorian
Gloski

Herr Heilwagen, ich denke unsere Meinungen sind gar nicht so verschieden. Wir sind uns offenbar einig, das gute Product Owner und Scrum Master ihre agilen Projekte auch durch die Verwendung klassischer Projektmanagementmethoden zum Erfolg führen werden. Darüber, ob man hier lieber von "klassischem Projektmanagement" oder "traditionellen Vorgehensweisen" sprechen, brauchen wir nicht zu diskutieren: Nennen wir es halt "klassisches Projektmanagement". Uns geht es in den Artikel darum aufzuzeigen, wo die Risiken liegen, wenn die Rollen des Scrum Masters und des Product Owners nicht so stark genug besetzt sind. Soll das Projekt dann in agiler Schönheit sterben? Oder kann man die dadurch enstehenden Risiken durch klassische Projektmanagementmethoden verringern? Wir tendieren zu Letzterem. Uns liegt die erfolgreiche Umsetzung von Projekten am Herzen. Dabei glauben wir dem Autor Winston Royce die Aussage "Das Wasserfallmodell hat noch nie funktioniert" genauso wenig wie einem Autor, der behauptet, dass "Agil noch nie funktioniert hat".

 

Guest

Der Artikel enthält leider einige grundlegende und weit verbreitete Missverständnisse über agile Entwicklung, die dann anschließend als Problem erkannt werden. Die gravierendsten Missverständnisse möchte ich hier richtig stellen. 1. „Die Kontrolle von Zeit und Budget für das Gesamtprojekt spielt eine geringere Rolle“ Richtig ist, dass Zeit und Budget für das Gesamtprojekt spätestens nach jeder Iteration auf Basis der aktuellen Anforderungslage verfolgt wird. 2. „Zu Konflikten kommt es regelmäßig dann, wenn Anforderungen nicht umgesetzt wurden, die für die Inbetriebnahme der Software essenziell sind.“ Richtig ist, für die Inbetriebnahme der Software essenzielle Anforderungen zuerst und mit höchster Priorität umgesetzt werden. 3. Das Entwicklungsteam kann ohne Rücksprache von einer vertraglich festgeschrieben technischen Anforderung abweichen. Das Entwicklungsteam ist darauf verpflichtet alle Vorgaben einzuhalten. Änderungen dieser Vorgaben sind nur durch den Auftraggeber (Product Owner) möglich. 4. „Das Zusammenspiel von Software und Produktivumgebung trägt, führt unserer Erfahrung nach bei agilen Projekten häufig zu Projektrisiken“ Das Zusammenspiel von Software und Produktivumgebung wird nach jeder Iteration sichergestellt. 5. „Technische und nicht funktionale Anforderungen können [..] aus dem Blickfeld geraten“ Technische und nichtfunktionale Anforderungen sind Bestandteil der Vorgaben und werden genauso verfolgt. 6. „Ob ein Team einen hohen Qualitätsstandard vertritt oder einen eher laxen Umgang mit Softwarequalität pflegt, kann der Auftraggeber den bei einem Sprintreview präsentierten Features in der Regel nicht ansehen.“ Der Qualitätsstandard wird bei Projektbeginn festgelegt („Definition of Done“) und mit allen Beteiligten abgestimmt. Dabei sind z.B. Testabdeckungsgrad, Dokumentation, Betriebsvorgaben, Codequalität, Regressionstests etc. Bestandteile. Iterative Prozesse dienen dazu, die Frequenz der Qualitäts- und Fortschrittskontrollen sehr hoch zu halten, um so die Zielerreichung sicherzustellen. Insofern möchte ich mich dem Fazit der Autoren nicht anschließen.

 

Dorian
Gloski

Herr Dahlke, wir behaupten in unserem Artikel nicht, dass Zeit, Budget und Qualität in agilen Projekten keine Rolle spielen. Natürlich werden diese Aspekte bei agilen Vorgehensweisen adressiert. Und wenn die Vorgehensweise genau erfüllt wird, so lässt sich ein agiles Projekt in Zeit, Budget und Qualität umsetzen. Dies gilt allerdings genauso für ein Projekt nach traditioneller Vorgehensweise. Leider entspricht die Wirklichkeit nicht immer der Theorie (was ja mit ein Grund für die Entstehung agiler Vorgehensweisen ist). In der Praxis kann die Festlegung eines "Definition of Done" genauso wenig Qualitätsprobleme verhindern wie die Festlegung, dass sich eine Spezifikation nicht ändern darf Change Requests verhindert. Bei einem gut laufenden Projekt spielen die hier beschriebenen Risiken keine Rolle. Uns geht es darum aufzuzeigen was passieren kann, wenn es nicht so gut läuft und welche Gegenmaßnahmen man treffen kann.

 

Thomas
Pleschinger

Ein sehr schöner Artikel, der mich unmittelbar zu einer alten, zentralen Frage führt. Ist es überhaupt sinnvoll sich einer einzigen Methode zu Unterwerfen? Alle Projektmanagementmethoden gemeinsam, dass sie unzureichend sind, um alle Umweltbedingungen und Befindlichkeiten abzudecken. Ihr Artikel greift das gut auf. Ein komkretes Ziel muss bereits zu Beginn eines Vorhabens anvisiert werden. Allerdings gibt es kaum eine Umgebung, die so stark kontrolliert wird, dass die Planung ápriori deterministisch sein könnte. Die so unweigerlich auftretende Notwendigkeit Plan, Vorgehen oder Methode anzupassen, wird aber in den wenigsten Methoden vorgesehen. Agiles Projektmanagement wid praktiziert, seit es Projekte giebt. Erst seit kurzer Zeit ist es salonfähig geworden, weil es Methoden giebt, die explizit Agilität auf der Fahne. Daran ist wie gesagt nur neu, dass Anpassungsfähigkeit zur Methode erhoben wurde. Projekterfolge erzielen wir aber nicht durch die Methode, Sondern mit und durch die Menschen, die die Projekte erarbeiten.Beginn Insofern bin und war ich immer ein Freund davon, Methoden als Werkzeuge zu sehen, die den jeweiligen Bedürfnissen entsprechend gewechselt werden. Würden Sie eine Schraube mit dem Hammer anzehen, weil sie damit ihr Vorhaben begonnen Hatten?

 

Guest

„Endlich ein Artikel, der auch mir als Marketing-Fachfrau klar macht, was denn Scrum und Wasserfall eigentlich wirklich bedeutet. Und vor allem: Exzellent ausgesuchte Fotos, die auf den Punkt veranschaulichen.“

 

Janko
Böhm

Vielen Dank Fr. Schielein und Herr Gloski. Aus meiner Sicht ein sehr gelungener Artikel. Ich bin selbst ein großer Anhänger einer Mischform von Agilen und "traditionellem" Vorgehen. Mit einem Kollegen habe ich vor kurzem einen Guide für den Einsatz Agiler Methoden in einem speziellen Unternehmen entwickelt und wir sind auf genau auf den Fakt gekommen dass spezielle Fakten mit großer Tragweite (Architektur, Anzahl-/Unfang von Schnittstellen, Entwicklungsumgebung, Sprache, ..) auch bei einem Agilen Ansatz festgelegt werden müssen. Somit ergibt sich ein "abgestecktes" Spielfeld für den Agilen Teil des Projektes an den Teilen wo das Team agil auf Veränderungen des Product Owners eingehen kann - z.B. Abläufe, Farben, Grafik .. Aber eben nicht mal eben ein ganz neues System einzubeziehen oä. Das würde dann zu einem RFC führen und klassisch auch zusammen mit dem Betrieb bewertet.

 

Janko
Böhm

Guter Artikel - ich habe die Bewertung vergessen.

 

Janko
Böhm

Eine Zusammenstellung wann ein Scrum Projekt in der Praxis gut funktioniert hat Roland Baldenhofer im folgenden Beitrag von Open PM gut herausgearbeitet https://www.openpm.info/display/openPM/Projekte+mit+Scrum+zum+Festpreis Auszug: "Die wichtigsten Architekturentscheide, Frameworkdefinitionen und Businessprozesse waren bekannt" Das passt meiner Meinung auch gut zu den Erfahrungen und Thesen von Fr. Schielein und Herr Gloski in diesem Projekt Magazin Artikel.