Wann verwende ich Wasserfall, wann verwende ich Scrum?

Zunächst einmal ist es kein Entweder-Oder-Problem. Sie finden sowohl reine Implementierungen beider Ansätze (ein reiner Wasserfall ist heutzutage eher selten) als auch eine Mischung aus beiden Ansätzen oder einiges davon, einiges davon und viel Chaos.

Dann wäre es besser, schwergewichtige formale Ansätze versus leichtgewichtige agile Ansätze zu diskutieren, als Wasserfall versus Scrum, da es sich nur um spezifische Fälle handelt.

Möglicherweise möchten Sie formale Ansätze verwenden, wenn:

• Sie arbeiten für einen großen Kunden, der Lieferanten einen sehr formellen Ansatz auferlegt.

• Sie arbeiten mit Verträgen mit festem Umfang und Festpreis und der Kunde erwartet (aus welchen Gründen auch immer) keine schnellen Änderungen des Umfangs.

• Ihr Projektteam hat Erfahrung mit einem spezifischen, schwergewichtigen Ansatz – sie wissen, wie man damit umgeht, sie wissen, wie man damit umgeht, um ein qualitativ hochwertiges Projekt zu liefern.

Sie sollten einen agilen Ansatz in Betracht ziehen, wenn:

• Sie arbeiten an Inhouse-Projekten oder Projekten für flexiblere Kunden, bei denen Sie sich nicht an die Prozesse des Kunden anpassen müssen.

• Sie arbeiten an einem Projekt, bei dem sich der Umfang (aus welchen Gründen auch immer) schnell ändert, und Sie neigen dazu, die Tatsache zu akzeptieren.

• Ihr Team beherrscht keinen bestimmten Projektmanagementansatz fließend, da allgemein agile Methoden die Lernkurven in Bezug auf die Einführung von Best Practices ziemlich glatt machen.

Sie können jedoch gerne verschiedene Ansätze mischen - was für das Team und das Projekt funktioniert, kann und sollte verwendet werden. Sie erhalten keine Punkte dafür, dass Sie mit einem bestimmten Ansatz orthodox sind – Sie erhalten Punkte für die Durchführung von Projekten.

Als letzten Ratschlag ist es besser, potenziell schlechtere Methoden zu verwenden (wobei schlechter bedeutet, dass sie nicht so gut zu Ihrer spezifischen Projektumgebung passen), aber sie gut zu verwenden, als potenziell beste Methoden zu verwenden, aber ihre Implementierung zu vermasseln. Siehe: Guter Wasserfall ist besser als schlechte Agilität

Verwenden Sie Agile (Scrum, XP, Kanban), wenn:

• Sie von schnellem Feedback und brennender Sichtbarkeit objektiver Daten profitieren möchten
• Sie verstehen den Wert und die Definition dessen, was Sie bauen, nicht vollständig
• Ihre Auszahlungs-/Abwärtskurven können stark variieren
• ein Team haben, das sich dafür begeistert, oder einen Trainer, der ihnen hilft
• Haben Sie ein kompliziertes Projekt ohne alle Experten, die Sie benötigen, oder ein komplexes Projekt

Verwenden Sie Wasserfall, wenn:

• Das Projekt ist einfach
• Das Projekt ist kompliziert, aber Sie haben das Know-how, um es umzusetzen
• es ist alles, was Sie wissen, und Sie haben keine Unterstützung für Veränderungen
• Die Vorabinvestition ist nicht riskant
• Sie fokussieren Ihre Leistungskennzahlen auf Liefertermin und Budget

Großartiger Beitrag von Dean Leffingwell zum gleichen Thema – MACHEN SIE DAS QUIZ – Picking Agile vs. Waterfall „Projects“: a Ten Point Quiz.

Sie sollten Wasserfall nur für die einfachsten Projekte verwenden, was effektiv etwa 90 % aller Softwareprojekte ausschließt. Wieso den? Denn Softwareprojekte sind in drei Dimensionen komplex: Anforderungen, Technologie und Menschen.

Zur Veranschaulichung ist dies ein Stacey-Graph, der in den 1980er Jahren von Ralph Stacey von der University of Hertfordshire entwickelt wurde – er studierte Komplexität und menschliches Verhalten in Organisationen und Unternehmen und wie man Managementpraktiken anpasst, um ihren Auswirkungen entgegenzuwirken. Ich habe es basierend auf dem Diagramm angepasst, das Ken Schwaber in seinen Scrum-Büchern und -Klassen verwendet:

Wasserfallprojekte passen in Szenarien, die in die einfachen Zonen auf dem Diagramm abgebildet werden, in denen wir die Anforderungen unserer Kunden und die Technologie(n), die wir verwenden müssen, um sie in eine funktionierende Softwarelösung zu implementieren, zusammen mit einer kleinen Teamgröße fast perfekt verstehen 1- 3. Wie Sie sich vorstellen können, sind diese Szenarien nur wenige.

Typische Softwareprojekte befinden sich jedoch tendenziell im komplexen Bereich in der Mitte des Diagramms, wo Anforderungen entlang eines Kontinuums verlaufen, wo sie nicht vollständig verstanden oder vereinbart werden (weil sie noch implementiert werden müssen) und die erforderlichen Technologien entlang laufen ein ähnliches Kontinuum, bei dem wir uns nicht 100 % sicher sind, wie sie funktionieren.

Bisher ist dies die gute Nachricht. Wir können "komplexe" Projekte bewältigen. Was jedoch die Komplexität in die Zone der Anarchie treibt, ist, wenn wir Menschen hinzufügen und sie in einen hochkreativen Prozess wie ein Softwareprojekt versetzen, in dem sie zusammenarbeiten müssen, um die oben genannten Mehrdeutigkeiten zu bewältigen. Wasserfallmethoden, die die Befolgung eines starren Plans über die Reaktion auf Veränderungen (innerhalb und außerhalb des Projekts) erzwingen, verschärfen diese Spannung und tragen zum Scheitern bei.

In diesen Situationen (d. h. in über 90 % der Fälle) müssen Sie einen iterativen/inkrementellen Prozess verwenden, um die Komplexität einzudämmen und das Risiko innerhalb eines definierten Zeitfensters (der Iteration oder des Sprints) zu mindern, damit Sie dies kontinuierlich überprüfen und anpassen können Lösung nach den Realitäten von Anforderungen + Technologie + Menschen.

Sie haben drei Faktoren:

• Geld
• Zeit
• Anforderungen

Wenn Geld und Zeit festgelegt sind und sich die Anforderungen ändern können, dann entscheiden Sie sich für SCRUM .

Wenn die Anforderungen festgelegt sind , würden Sie sich für Wasserfall entscheiden .

Wird sich die Software nach ihrer ersten Veröffentlichung jemals ändern?

Waterfall ist für den Bau von Brücken und Häusern gedacht – physische, starre Dinge, von denen Sie nicht erwarten, dass sie sich im Laufe der Zeit stark ändern.

Agile und iterative Ansätze passen natürlich zur Softwareentwicklung und ihrer Fluidität.

Sie sollten Veränderungen erwarten und annehmen .

Ich verstehe, dass nicht jeder damit einverstanden ist, aber die Verwendung eines Wasserfallprozesses ist die Nummer 1 in meinem Beitrag über die Top 5 Fehler im Softwareprojektmanagement .

Es überrascht mich, dass die Wasserfall-Softwareentwicklung nach all den Jahren immer noch so umfassend gelehrt und praktiziert wird.

Der Wasserfall sollte verwendet werden, wenn dies vom Kunden oder den Aufsichtsbehörden gefordert wird. Nicht, dass ich irgendwelche Aufsichtsbehörden kenne, die das verlangen.

Sonst hätte ihn sein Originalpapier als Strohmann umwerfen müssen; dann nahmen die Leute es als gute Praxis.

Es gibt eine Reihe von Faktoren zu berücksichtigen.

Zum Beispiel den Umfang des Projekts, die Dauer des Engagements, die Art des Engagements (ob Sie am gesamten Lebenszyklus des Projekts oder nur an der Entwicklung beteiligt sind), die bisherige Erfahrung des Kunden und was für Sie am besten funktioniert und dein Team.

Hier ist ein Beitrag zur Auswahl einer PM-Methodik , die hilfreich sein könnte.

„Waterfall“ ist weitaus überlegen, wenn der Kunde genau weiß, was er will und sich außer Bugfixes nichts ändert. Es wird sehr diskreditiert, weil die überwiegende Mehrheit der Kunden nicht weiß, was sie wollen. Daher sind iterative Prozesse weitaus effektiver, um herauszufinden, was diese Kunden wollen – und es ihnen zu geben.

Stören Sie die Entwicklungsmethodik hat ihre eigenen Vorteile und Grenzen. Es hängt also ganz von Ihnen ab, in welche Richtung Sie sich bewegen oder beides kombinieren möchten, um die Entwicklungsmethodik neu zu definieren. Das Wasserfallmodell eignet sich immer noch gut für die Entwicklung vieler großer Projekte, bei denen alle Schritte zunächst klar definiert sind. Agile Entwicklung wird heutzutage übernommen, hat aber das Wasserfallmodell nicht ersetzt, das hilft, ein Projekt mit klar definierten Projektschritten zu entwickeln, und es besteht keine Notwendigkeit, zurückzugehen.

Der Wasserfall ist perfekt für Projekte, bei denen alle Anforderungen bis ins kleinste Detail im Voraus bekannt sind und sich nicht ändern und das gesamte Design von vornherein gemacht werden kann, ohne dass etwas falsch wird, und bis zum Ende nichts getestet werden muss. weil die Tests nur eine Formsache sind und keine Änderungen erfordern.

Das Problem ist, dass dies niemals passieren kann, insbesondere bei großen Projekten oder Projekten, die neue Aspekte haben (aus Sicht der Kunden oder der Implementierer).

Selbst wenn dasselbe Produkt in einer bestehenden Fertigungskette immer wieder hergestellt wird, können mechanische, elektrische und menschliche Fehler Fehler verursachen, und diese Fehler sollten am besten so schnell wie möglich erkannt und behoben werden.

Die meisten Unternehmen, die Wasserfall offiziell praktizieren, verwenden hinter den Kulissen eine Art inkrementelle oder, realistischer, iterative Methode.

Die Fragen sind:

1. Verwenden sie eine formale iterative Methode wie UP, Scrum, Kanban usw. oder erfinden sie diese im Laufe der Zeit?

2. Müssen Verträge nach jedem Änderungsbedarf neu verhandelt werden oder sieht der Vertrag bereits Kontrollpunkte für Änderungen oder Projektstopps vor?

Wenn die Unsicherheit (in Anforderungen, Technologie, Personal usw.) groß ist, können agile Methoden zu einem effizienteren Prozess führen als größere Iterationen (z. B. UP).

Aus Erfahrung mit der Verwendung von beiden gibt es ehrlich gesagt keinen wirklichen Vorteil, Wasserfall zu verwenden, es sei denn, das Projekt ist so klein, dass es in einen kurzen Zeitraum passt, z. Ein Monat. Scrum wiederholt ohnehin Mini-Wasserfall-Phasen in jedem Sprint. Der Wert von Scrum besteht darin, dass keine Zeit mit großen Vorabanalysen und -designs verschwendet wird, während sich Prioritäten und Marktbedingungen ändern. Eine Übersicht gibt es [hier] ( http://www.pashunconsulting.co.uk/what_is_scrum_blog.html )

Die Scrum-Methodik erfordert ein Umdenken gegenüber traditionellen Methoden. Der zentrale Fokus hat sich vom Anwendungsbereich in Wasserfallmethoden hin zum Erreichen des maximalen Geschäftswerts in Scrum verlagert. Während in Waterfall Kosten und Zeitplan geändert werden, um sicherzustellen, dass der gewünschte Umfang erreicht wird, können in Scrum Qualität und Einschränkungen geändert werden, um das Hauptziel zu erreichen, den maximalen Geschäftswert zu erreichen.

Das Wasserfallmodell eignet sich für geordnete und vorhersehbare Projekte, bei denen alle Anforderungen klar definiert und genau abgeschätzt werden können, und in den meisten Branchen sind solche Projekte rückläufig. Veränderte Kundenanforderungen haben zu einem erhöhten Druck auf Unternehmen geführt, ihre Liefermethoden anzupassen und zu ändern.

Weitere Informationen finden Sie unter: http://www.scrumstudy.com/blog/advantages-of-using-scrum-listed-down-by-scrumstudy-2/

Ich finde Pawels Antwort großartig und würde dir +1 geben, wenn ich könnte!

Zu seiner Liste hinzufügen. Sie würden Wasserfall verwenden, wo:

• Sie haben einen feindlichen Kunden oder einen, der sich weigert, sich zu engagieren
  • Ich sage das nur, weil es manchmal vorkommt. Der Kunde möchte nicht wirklich eine Änderung und diese wird ihm von einem Eigentümer oder einer Gruppe aufgezwungen, aber er hat die Verantwortung für das Projekt. Es ist selten, aber Agile braucht Engagement.

Wasserfall ist keine Methodik an sich. Wasserfall ist nur ein Lebenszyklusmodell.

Scrum ist eine agile Methodik. Eine Methodik kann einen Lebenszyklus beschreiben und stellt einen Prozess bereit, um diesen Lebenszyklus zu unterstützen.