Softwareentwicklung durch Zusammenarbeit von Wasserfall- und agilen Methoden

Es ist unmöglich.

Alle agilen Methoden sollten iterativ sein. Andernfalls entsprechen sie nicht dem ersten und dritten Grundsatz des Manifests :

Unsere höchste Priorität ist es, den Kunden durch frühzeitige und kontinuierliche Lieferung wertvoller Software zufrieden zu stellen.

...

Stellen Sie häufig funktionierende Software bereit, von ein paar Wochen bis zu ein paar Monaten, wobei Sie kürzere Zeiträume bevorzugen.

Wasserfall ist per Definition ein nicht iterativer Ansatz :

Das Wasserfallmodell ist ein linear sequentieller (nicht iterativer) Designansatz für die Softwareentwicklung, bei dem der Fortschritt in einer Richtung nach unten (wie ein Wasserfall) durch die Phasen Konzeption, Initiierung, Analyse, Design, Konstruktion, Test, Bereitstellung und Wartung fließt .

Sie können also nicht gleichzeitig iterative und nicht iterative Ansätze verwenden.

Update: Es gibt mehrere Methoden, die weder ein klassischer Wasserfall noch agil sind (z. B. RUP- oder Spiral-Modell). Sie können von beiden Ansätzen etwas mitnehmen, aber sie sind weder das eine noch das andere.

Dafür gibt es einen Begriff, Wagile :

Wagile-Softwareentwicklung ist eine Gruppe von Softwareentwicklungsmethoden, die daraus resultieren, dass man von agil zurück in Wasserfall rutscht, viele kurze Wasserfälle macht und denkt, es sei agil, Wasserfallmodell, das sich als agile Softwareentwicklung tarnt usw.

Und es ist so schlimm wie es klingt...

Ich habe einen schönen Artikel für diese Art von Prozess gefunden ...

Sergey Kudryavtsev hat Recht, es ist nicht möglich.

Das grundlegende Prinzip dahinter waterfallist, dass die Arbeit des Produktmanagements im Voraus durchgeführt wird: Der Markt wird recherchiert, das Konzept erstellt, die Kunden befragt, das gesamte Produkt entworfen und dann eine umfassende und vollständige PRD an das Engineering weitergeleitet, das dann das Produkt entwickelt , testet es und stellt es dann bereit. Alle Fortschritte fließen in eine Richtung und die PRD stellt eine Richtlinie vom Produkt bis zum Engineering dar.

Mit agilewird das Produkt weiterhin den Markt recherchieren, ein Konzept erstellen und Kunden befragen, aber das gesamte Produkt wird nicht spezifiziert, bevor die Entwicklung beginnt. Eine PRD oder mehrere PRDs werden mit Engineering geteilt, aber dies sind kleinere, lebendige Dokumente. Die Technik wird mit ihrem Feedback und ihren Bedenken antworten, und die PRD wird entsprechend aktualisiert. Das Gleiche gilt, wenn Feedback und Bedenken von Kunden eingehen. Der Prozess ist iterativ und diese Dokumente stellen ein Verständnis des Kunden dar, das zwischen Produkt und Engineering geteilt wird.

Anders betrachtet sind die agile Anti-Patterns quasi die Definition von waterfallAnforderungen:

Anti-Patterns, auf die man achten sollte

• Das gesamte Projekt ist bereits bis ins kleinste Detail spezifiziert, bevor mit den Engineering-Arbeiten begonnen wird
• Eine gründliche Überprüfung und eiserne Freigabe aller Teams sind erforderlich, bevor die Arbeit überhaupt beginnt
• Designer und Entwickler wissen nicht, wann Anforderungen aktualisiert wurden
• Anforderungen werden von vornherein nie aktualisiert (weil alle sie unterschrieben haben, erinnerst du dich?)
• Der Product Owner schreibt Anforderungen ohne Beteiligung des Teams

Das Problem wird besonders akut zu spüren sein, wenn ein Teil der Organisation implementiert, agilewährend der andere waterfall. Wenn Product agileand Engineering verwendet waterfall, wird sich Product fragen, warum die Dinge so lange dauern, und Engineering wird sich darüber beschweren, dass die PRDs „unausgegoren“ sind. Wenn es umgekehrt ist, fragt sich das Engineering, woran sie arbeiten sollen, und das Produkt beschwert sich, dass das Engineering warten muss. Ein verletztes Gefühl wird folgen.

Update : Steve Blank hat gerade einige Gedanken zum Thema in AgileFall – When Waterfall Sneaks Back Into Agile veröffentlicht :

AgileFall ist ein ironischer Begriff für Programmmanagement, bei dem Sie versuchen, agil und schlank zu sein, aber weiterhin Wasserfallentwicklungstechniken verwenden. Es führt oft zu einem Ergebnis, das dem Kombinieren von Bohnerwachs und Dessertbelag ähnelt.

Anschließend beschreibt er, wie der Prozess optimiert werden kann, um wieder auf Kurs zu kommen

Waterfall basiert auf der Prämisse, dass es billiger ist, Fehler frühzeitig zu erkennen – bevor viel investiert wird – als Fehler spät zu erkennen. So planen Sie besser im Voraus, um spätere Überraschungen zu vermeiden.

Agile basiert auf der Prämisse, dass das Obige ein guter Schritt zur Vermeidung von Fehlern ist, Sie aber nicht vor Änderungen und Komplikationen schützt. Iterativ und auf einem kleineren Umfang zu arbeiten, erreicht also dasselbe wie Wasserfall und noch mehr.

Sie könnten versuchen, etwas zu argumentieren wie „Scrum ist wirklich nur ein iterativer, überlappender Wasserfall“ oder „Agile befürwortet einfach viel kürzere Wasserfall-Teilprojekte, eines nach dem anderen“, und je nachdem, wer fragt und was sie wollen, könnten Sie erfolgreich sein.

Sie können mehrere agile Prinzipien wie enge Zusammenarbeit, Priorisierung, Kundeneinbindung, kontinuierliches Testen, Werte wie Offenheit, Mut und Respekt in ein Wasserfallprojekt integrieren und diese Mission als erfüllt betrachten.

Das Problem ist, dass sowohl Wasserfall als auch Agilität mit bestimmten Erwartungen einhergehen. Es sind meist eher die Erwartungen, die miteinander kollidieren, als die von den „Modellen“ vertretenen Praktiken. Und es sind im Allgemeinen die Erwartungen, die mit dem Wasserfall einhergehen, die den Wasserfall problematisch machen. Wie die Erwartung, dass das Wasserfall-Gantt-Diagramm prophetische Eigenschaften hat. Oder die Erwartung, dass Sie, weil Sie am Ende etwas Pufferzeit hinzugefügt haben, leicht ein paar weitere Funktionen oder "Klarstellungen" von Funktionen hinzufügen können. Wo agil diesen rigoros entgegentritt...

Sie können mit Wasserfall genauso erfolgreiche Projekte durchführen wie mit Agilität. Der Versuch, beide in dasselbe Projekt zu stecken, ist im Allgemeinen ein Zeichen dafür, dass nicht jeder in Ihrer Gruppe den Sinn von Agilität versteht. Und Sie versuchen, Funktionsstörungen zu lösen, die die Leute noch nicht loslassen wollen.