Ich weiß, dass ich mich zuerst an die Wasserfallmethode des Projektmanagements gewöhnt habe und gleichzeitig mit dem prädiktiven Ansatz zum Software-Design gegangen bin. In diesem Sinne hatten wir riesige Pakete von Dokumentation, UML, Datenbankschemata, Datenwörterbüchern, Workflows, Aktivitätsdiagrammen usw.
Nachdem ich über 10 Jahre in Software gearbeitet habe, finde ich es viel realistischer, Software-Design von einem reaktiven Ansatz aus zu betrachten. Ich folge häufig einem Scrum-Ansatz für das Projektmanagement und mit dieser sehr geringen Menge an Dokumentation wird immer generiert. Wir haben sehr wenig Workflow-Spezifikation (obwohl sie immer noch dort verwenden). Dies ist ein viel dynamischer Ansatz für die Erstellung von Software. Natürlich kommt es mit der Zeit immer häufiger zu Refactoring, da wir im Laufe der Zeit neue Features entdecken, die, wenn wir es geplant hätten, die Dinge dramatisch verändert hätten.
Der große Unterschied für uns ist, dass der erste Ansatz länger dauert, in einer Software-Konstruktionswelt häufiger ausfällt und nicht annähernd so flexibel ist. Der zweite Ansatz bietet mehr Flexibilität, macht uns Fehler schneller bewusst (so können wir natürlich schneller korrigieren) und bietet am Ende jeder Iteration eine Form von Funktionalität.
Wenn ich beide Seiten aus Erfahrung kenne, finde ich immer noch viele Leute, die den Wasserfall-Ansatz über den agilen Ansatz der Softwareentwicklung LIEBEN. Ich verstehe es nicht.
Frage: Warum sollte jemand Wasserfall über irgendeine Form von Agile mit all der Forschung unterstützen agil? Was sind starke Argumente für die Verwendung von Wasserfall über agile?
Ich denke, dass ein Teil des Grundes, warum Menschen immer noch oft am Wasserfall festhalten, darin besteht, dass sie die Illusion von Kontrolle erzeugt. In einem Wasserfall können Sie genug Arbeit leisten, um einen schönen Zeitplan zusammenzustellen, der alle denkbaren Eventualitäten berücksichtigt, und dann einen detaillierten Fahrplan für die Zukunft an jeden auf der Geschäftsseite geben, der fragt, wann Feature X sein wird verfügbar.
Das Problem ist, dass Sie diesem Plan fast nie folgen können, und Sie sind fast immer zu spät / Funktionen fallen lassen. Von Anfang an sieht es jedoch sehr kontrolliert und überschaubar aus.
Ich bin ein großer Agile-Fan, aber mit dem ich schon immer zu kämpfen hatte, ist die Long-Range-Roadmap / Prognose, die oft von den Vertriebs- und Marketingleuten verlangt wird. Ich denke, dass die Illusion der Gewissheit des Wasserfalls Manager und Geschäftsleute sehr tröstet.
Als ich mit der Programmierung begann (mit COBOL nicht weniger), war Wasserfall der "neue" Ansatz. Heute würde ich Ihnen sagen, dass ich eine wasserfallartige agile Methode verwende. Bei größeren Systemen finde ich einen Wasserfall-Start am besten. Keine großen Dokumente erstellen (das ist Zeitverschwendung IMO), sondern einige Schritte wie das Erstellen eines UI-Prototyps und / oder die Verwendung von Fällen, um uns mit dem Geschäftsproblem vertraut zu machen. Sobald wir uns wohl fühlen, haben wir das Problem im Visier und wir haben ein solides Verständnis, wir bewegen uns in einen agilen Entwicklungsmodus.
Um Ihre Frage zu beantworten, denke ich, dass der große Grund, warum der Wasserfall herumliegt, viele Leute sind, die Änderungen nicht mögen. Es ist unheimlich, sich zu verändern und vom Wasserfall zum Agilen zu wechseln ist eine große Veränderung.
Nicht auf der Seite, aber so ziemlich jede Forschung wäre bestenfalls unwissenschaftlich.
Sie sagen (Betonung ist meins)
Frage: Warum würde jemand Wasserfall über irgendeine Form von agiler mit all der Forschung unterstützen agil verwenden? Was sind starke Argumente für die Verwendung von Wasserfall über agile?
, aber verlinke nicht auf irgendwelche Studien.
Es ist eines dieser Dinge, von denen man weiß, dass sie extrem schwierig zu testen sind. Sie können nicht zwei identische Teams gleichzeitig am selben Projekt arbeiten lassen, da es zwei identische Teams nicht gibt. Sie können nicht dasselbe Team zweimal hintereinander die gleiche Aufgabe mit zwei verschiedenen Methoden ausführen lassen, ohne dass der erste Durchgang die zweite tangiert. Ich habe noch nie von jemandem gehört, der eine experimentelle (oder sogar statistische) Studie entworfen hat, die überzeugend für irgendeine Softwareentwicklungsmethodik argumentieren kann. Ich würde mich interessieren, wenn Sie einen Link haben.
Ohne wirkliche Beweise, es läuft auf persönlichen Vorlieben hinaus. Was sind die starken Argumente für Schokolade über Vanille?
Ich werde den Advocatus des Teufels spielen und sagen, dass Agile fehlerhaft ist, sind fast so viele Möglichkeiten wie die Wasserfall-Methode. Ich bin keiner von denen, die die Wasserfallmethode lieben, aber ich mag auch keine Agilität.
Meine Erfahrung mit Agile war nicht sehr positiv. Um fair zu sein, habe ich es in einem Unternehmensumfeld eingesetzt, das Lippenbekenntnisse gegenüber "agil" abgegeben hat, während wir immer noch erwarten, dass unser Manager im Voraus langfristige Meilensteine und Ergebnisse liefert.
Ich habe jedoch festgestellt, dass agile (insbesondere Scrum) Methodologien oft große Probleme mit dem Design verschleiern. Während der Wasserfall den Managern die Illusion der Kontrolle gibt, scheint Agile dasselbe für Entwicklungsteams zu tun. Ich habe Teams gesehen, in denen jedes Problem angesprochen wird, das nicht im aktuellen Sprint / Iteraton ist, in der Erwartung, dass es "rechtzeitig" gehandhabt wird. Es erfordert nur einige wichtige Designentscheidungen, die ignoriert werden müssen, damit das Projekt in Zukunft in die Knie geht, während die aktuellen Iterationen reibungslos ablaufen und das Projekt auf Kurs ist.
Sie können argumentieren, dass das Team daran schuld ist, dass es den Geist von agil nicht verstanden hat, aber ich würde gerne bessere Methoden sehen, die die besten Teile von agile beinhalten.
Einer der Prämissen von (mindestens) XP ist, dass Veränderung billig ist. Das Wasserfallmodell wurde nach den Prinzipien gebaut, die sich ändern, jede Veränderung ist teuer. Die Annahme in dem Wasserfallmodell ist, dass, wenn einmal Software geschrieben wurde, eine Änderung teurer ist, als die Zeit im Voraus zu investieren, um zu einem "vollständigen" Verständnis des Problems zu kommen.
Die Erfahrung scheint darauf hinzudeuten, dass es sehr schwer ist, das Problem vollständig zu verstehen, und dass, wenn einige Vorkehrungen getroffen werden (z. B. Unit Testing), Änderungen viel billiger werden können. Wenn also ein Problem auftritt, bei dem einige der agilen Prämissen nicht wahr sind, könnten andere Ansätze wieder möglich werden. Zwischen Waterfall und Agile gibt es zumindest eine Spiralentwicklung, die - sozusagen - wir praktizieren.
Sie müssen präditiv genug sein, um die Waren zu liefern. Sie müssen reaktiv genug sein, um mit den Problemen umzugehen.
Ich war einmal mit sechs Monaten fest, um ein Projekt zu vollenden, das schätzungsweise ein Jahr dauert, und basierend auf Erfahrungen aus der Vergangenheit würde die Erfahrung zwei erfordern. Also habe ich drei Monate lang Methoden studiert. Wir haben pünktlich (in drei Monaten) fertig mit den entsprechenden Teilen eines Wasserfallprozesses.
Einige Punkte, die die methodoly funktionieren ließen: - Erstellen Sie eine Nutzungsstandards, aktualisieren Sie sie bei Bedarf. - Erstellen Sie Bibliotheken: Tun Sie es einmal, machen Sie es gut, reparieren Sie es, ohne bestehenden Code zu brechen. - Machen Sie gerade genug Dokumentation. - Versionskontrolle alles was du kannst. - Teile die Dinge zusammen; Eine Methode sollte entweder die Arbeit verwalten oder arbeiten. - Kohäsion erhöhen, Kopplung verringern, Wiederverwendung. - Kaufen oder bauen Sie die Werkzeuge, die Sie benötigen. - Verfolgen Sie Ihre Probleme und Fortschritte.
Ein weiteres Projekt, an dem ich beteiligt war, war ein sechsmonatiges Projekt. Ich habe mich erst anderthalb Jahre nach dem Start beteiligt. Der Entwicklungsleiter war zu einem extremen Preisaufschlag eingestellt worden, als er eine Laufbahn mit einem Pensionsplan verließ. Zu Beginn des Projekts fragte er den Projektleiter: "Soll ich es richtig machen oder reaktiv sein?" Kannst du die Antwort erraten? Die Woche, in der ich involviert war, wurde am Montag, Mittwoch und Freitag implementiert. Raten Sie, was am Dienstag und Donnerstag passiert ist?
Die Stärke von Agile ist die Betonung gerade genug, gerade noch rechtzeitig. Die Stärke der Wasserfallmethode ist, dass sie alle Dinge abdeckt, über die Sie nachdenken müssen. Ich muss noch an einem Projekt arbeiten, das alle Schritte gemacht hat oder hätte machen sollen. Ich habe an vielen Projekten gearbeitet, die Schritte unternahmen, die auf Unternehmensebene durchgeführt werden sollten.
Der Titel sagt alles. (Eigentlich: proaktiv vs reaktiv). Warum den reaktiven Weg wählen und die Kontrolle aufgeben, wenn Sie es nicht müssen? Wasserfall ist nicht die einzige Alternative, Sie können jede Art von Entwicklungsprozess haben, den Sie verfeinern, wenn Sie möchten. Kontrolle ist der Schlüssel.
Es ist ein Spektrum, der Wasserfall an einem Ende und die völlig reaktiven, Null-Dokumentationsmethoden am anderen Ende. Wenn Sie in der Beraterbranche für leistungsstarke (und in der Regel unentschlossene) Kunden arbeiten, müssen Sie auf reaktive Methoden zurückgreifen. Wenn Sie eine Schrumpffoliensoftware entwickeln, können Sie vorausplanen und Wissen verwalten. Einige Projekte erfordern auch eine Menge Spezifikationen und Regeln, wo der Code- und Fix-Ansatz es nicht schneidet. Software-Engineering geht für mich in erster Linie um Wissensmanagement und Design, Codierung kommt an zweiter Stelle.
P. s. So etwas wie agilen und festen Preis gibt es nicht. Nicht in der klassischen Weise verkaufen sie die Methode normalerweise. Siehe Ссылка
Wenn Sie genau die Anforderungen kennen, die nie chagen, wenn Sie wissen, wie lange jeder Schritt dauern wird, und wenn Sie wissen, dass alle Ressourcen zu der Zeit verfügbar sind, können Sie einen Wasserfall machen und es wird funktionieren. Aber in der Tat sind diese Art von Projekten ziemlich selten und ich denke, dass ich nie ein Teil davon sein werde.
Bei der Entwicklung von Systemen, die von Endbenutzern verwendet werden, funktioniert Agile oft gut, weil die Anforderungen wahrscheinlich nicht korrekt sind und ein großer Teil des Prozesses Rückmeldungen von Benutzern in Form einer verwendbaren Version erhält.
Bei der Erstellung von Software, die mit anderer Software zusammenarbeitet, können die Anforderungen jedoch oft sehr klar formuliert werden. In diesem Fall ist es oft produktiver, sicherzustellen, dass Sie eine sehr klare und genaue Spezifikation haben, Komponententests. In diesem Modell können Sie auch ziemlich gute Arbeitsschätzungen erstellen und es würde sehr viel mehr kosten, das agile Modell zu verwenden. p>
Wenn Sie ein Team von ein paar Dutzend Leuten haben, die im Verlauf eines Jahrzehnts haben, verfeinerte die Wasserfall-Strategie bis zu dem Punkt, dass es gut für sie funktioniert, wer kommen Sie und sagen Sie: "Sie tun es ist falsch ... "? Wirklich, wenn es für sie arbeitet, warum Dinge ändern? Ja, das ist nur die Frage umdrehen, aber ich denke, es kann ein gültiger Punkt sein.
In meinem Team haben wir festgestellt, dass es bei Wartungsprojekten (die den Großteil unserer Arbeit ausmachen), wo wir genau wie mit "Gefällt mir" vorgehen, nicht immer so viel Benutzereingaben gibt wie bei einigen UI-Prototypen .
In diesem Fall kann der Waterfall-Ansatz auf Makroebene, insbesondere angesichts der Tatsache, dass es kommerzielle Geschäfte gibt, gut passen. Auch dann mögen wir inkrementelle / agile Ansätze auf der Implementierungsebene.
Es ist erwähnenswert, dass die meisten unserer Kunden große schwerfällige Organisationen sind, die ihren Papierkram lieben, was uns sogar noch mehr Ansporn gibt, ihnen zumindest traditionell zu erscheinen.
Die Dokumentation, die während des Wasserfallprozesses erzeugt wird, ermöglicht eine Menge von CYA. Sie können mit den Fingern zeigen, wenn ein Projekt von den Schienen verschwindet. Sehr wenige Führungskräfte werden OK sein mit "na ja, ich denke, das Projekt ist von uns weggekommen! Nun, zumindest haben wir es früh herausgefunden, kein Schaden, kein Foul!"
Außerdem können Design-Dokumente automatisch Testpläne erstellen, was für die Qualitätssicherung nützlich ist.
Es ist ziemlich üblich, wenn Sie für einen Vertrag bieten, dass einer der eisernen Bedingungen ist, dass Sie ihrem "Prozess" folgen, der bei der Inspektion Wasserfall ist.
Tags und Links agile waterfall software-design scrum