Czy metodologia tworzenia oprogramowania Waterfall jest nadal opłacalna?

14

Z mojego doświadczenia wynika, że model Waterfall okazał się zbyt mało elastyczny i nie reaguje na zmiany wymagań, aby uznać go za realną metodę we współczesnym świecie tworzenia oprogramowania. Rozwój i udokumentowane osiągnięcia bardziej zwinnych, iteracyjnych metod wydają się wskazywać, że nie ma powodu, dla którego ktoś powinien postępować zgodnie z procesem sztywnych bloków, który zakłada niewielkie lub żadne zmiany od początku projektu do dostawy produktu.

Czy metodologia opracowywania wodospadu jest nadal opłacalna w zakresie dostarczania systemów oprogramowania pod względem czasu, kosztów i jakości?

CFL_Jeff
źródło
3
Więc jeśli tego nie doświadczyłeś i nie chcesz tego doświadczyć, to czyni go martwym? Nie dlatego, że jestem za tym, ale wydaje się to dziwną przesłanką.
Czwartek,
9
Nie jest martwy. To po prostu nie jest obecny trend / trend / „akceptowalny”
Paul
2
@GrandmasterB Przez „martwy” miałem na myśli „wystarczająco udowodniony, że nie jest najlepszym sposobem”
CFL_Jeff
3
@Rachel Nie czytaj dalej znacznika rozwoju oprogramowania. Jest to metatag, który ma zostać oczyszczony w przyszłości .
Thomas Owens
3
Nie jest martwy, po prostu odpoczywa. Pining do fiordów. ;)
FrustratedWithFormsDesigner

Odpowiedzi:

20

Model wodospadu, o którym mowa, nigdy nie miał być modelem procesu stosowanym w prawdziwym projekcie. Zamiast tego jest sławiakiem. Identyfikuje kluczowe fazy i działania istniejące w projektach oprogramowania oraz najbardziej podstawowy przepływ między nimi. To nadmierne uproszczenie sposobu tworzenia oprogramowania jest wadliwe, a nawet tak zostało przedstawione.

Z artykułu w Wikipedii:

Pierwszy formalny opis modelu wodospadu jest często cytowany jako artykuł Winstona W. Royce'a z 1970 roku, chociaż Royce nie użył w tym artykule terminu „wodospad”. Royce przedstawił ten model jako przykład wadliwego, niedziałającego modelu.

Omawiany artykuł zatytułowany jest Zarządzanie rozwojem dużych systemów oprogramowania . W nim Royce przedstawia ten model na drugiej stronie. Jednak tekst znajdujący się bezpośrednio pod obrazkowym przedstawieniem dalej brzmi:

Wierzę w tę koncepcję, ale opisana powyżej implementacja jest ryzykowna i zachęca do niepowodzenia.

Następnie omawia problemy związane z testowaniem po „zakończeniu” fazy programowania oraz o tym, w jaki sposób niepowodzenia mogą prowadzić do poważnych zmian w projektach i zmianach kodu, a także w jaki sposób mogą one prowadzić do poważnych przekroczeń kosztów i harmonogramu. W całym artykule udoskonala oryginalny model, który jest rzeczywiście wykonalny w projekcie. W końcu opracował model, który wprowadza prototypowanie, interakcję z klientem i udoskonalanie artefaktów - pomysły, które ostatecznie staną się kluczowe dla zwinnego ruchu, który rozpoczął się na przełomie lat 90. i 2000.

Aby odpowiedzieć na twoje pytanie: Wodospad, o który pytasz, nie jest i nigdy nie był opłacalną metodą dostarczania projektów oprogramowania o rozsądnej jakości i terminowości i budżecie. Istnieją jednak inne metodologie oparte na planach, które są przeciwne do zwinnych, które mogą i wykonują prace nad projektami.

Thomas Owens
źródło
Wiele artykułów na temat zwinności używa „tradycyjnych metod”, aby wspomnieć o wodospadzie, a ten domniemany wodospad był używany przez cały XX wiek. Teraz wiem, że się mylę.
Ming-Tang,
@ThomasOwens Czy mógłbyś zacytować kilka z nich other plan-driven methodologies that lie opposite of agile that can and do work on project?
Laiv
@Laiv Model spiralny jest bardziej oparty na planach niż podejście zwinne - przed opracowaniem działającego oprogramowania wykonujesz więcej planowania i analiz. Cap Gemini SDM to kolejny przykład, chociaż późniejsze wersje dodały w cyklu planowania do sprawdzenia, ale znowu ma przyzwoitą ilość wstępnego planowania i analiz wbudowanych w ten proces. Wiele z nich może być pewną odmianą wodospadu, ale z wbudowanym rodzajem pętli sprzężenia zwrotnego. Jeśli dobrze rozumiesz domenę i stosunkowo stabilne wymagania, możesz nie potrzebować ciasnych pętli sprzężenia zwrotnego metod zwinnych i lepiej planować.
Thomas Owens
9

Ludzie nie używają tekstowego modelu wodospadu i prawdopodobnie nigdy go nie mają.

Jest to wyidealizowana teoretyczna konstrukcja, której celem jest nakłonienie użytkownika do zastanowienia się nad etapami rozwoju systemu. Chodzi o to, że chcesz, aby większe zmiany miały miejsce tak wcześnie, jak to możliwe, ponieważ nigdy nie będziesz miał czasu ani pieniędzy na dokonanie dużych zmian, gdy zbudujesz dużo kodu.

Pomimo tego, że jest to raczej sposób myślenia niż proces, wciąż jest to sposób, w jaki wiele - prawdopodobnie większość organizacji zajmuje się budowaniem oprogramowania (domów, łodzi podwodnych lub cokolwiek innego ...).

W prawdziwym świecie nie ma całkowicie ścisłych granic między fazami i czasami powracasz do poprzednich faz w przypadku małych podprojektów. Metodologia mówi ci, że „te rzeczy są niedozwolone”. Mówi ci, że „te rzeczy kosztują cię pieniądze i / lub czas” - staraj się tego unikać w przyszłości.

Dla Agile Snobs (TM) wszystko dobrze i dobrze spogląda w dół na „staroświeckich” programistów i ich osobliwą, niewykonalną metodologię wodospadu, ale faktem jest, że Agile też nie jest panaceum. Niektórych projektów nie można zbudować przy użyciu zwinnego, a wiele zespołów, które uważają, że są zwinne, są po prostu niechlujne i niezorganizowane.

Metodologia nie jest istotna. Chodzi o to, aby pomyśleć o tym, co robisz i dlaczego robisz to w ten sposób - i jak najlepiej wykorzystać klienta w jak najkrótszym czasie.

Joel Brown
źródło
Najwyraźniej miałeś dla mnie zupełnie inne doświadczenie „ludzi”. W ciągu ostatnich 30 lat pracowałem w szeregu firm, które wszystkie stosowały (i nadal używają) metodę wodospadu z podręcznika. Nic dziwnego, że to nie działa.
David Arno,
@DavidArno Najbliżej kiedykolwiek widziałem „na wolności” podręcznik Wodospad w kontekście oprogramowania było w oprogramowaniu do budowy firmy, które kontrolowało zmianę pociągów. Motywacją było to, że ktoś nie dosłownie umarł w wyniku błędu. Wyobrażam sobie, że może się to zdarzyć także w miejscach, w których programowanie osadzone nie jest możliwe, ponieważ nie chcesz zbudować miliona czegoś, aby dowiedzieć się, że nie udaje się to z powodu błędu. Wydaje mi się, że nawet w tych przypadkach Wodospad jest bardziej ideałem niż praktyką, którą osiąga się perfekcyjnie. Jak zauważyłeś - wyniki są nieuchronnie porażką na pewnym poziomie.
Joel Brown,
8

Mityczny proces wodospadu, który jest najczęściej porównywany ze zwinnym, nigdy nie istniał i dlatego nie można go uznać za martwy. Procesy prawdziwego wodospadu są nadal żywe i mają się dobrze, a ich terminowość polega na dostarczaniu oprogramowania budżetowego, które spełnia oczekiwania użytkowników.

Ryathal
źródło
5
Nie jestem pewien, jaka jest różnica między „mitycznym” procesem wodospadu a „prawdziwym” procesem. Czy możesz to wyjaśnić?
CFL_Jeff
6
Często proces wodospadu opisany przez zwolenników Agile to strawman en.wikipedia.org/wiki/Straw_man
jfrankcarr
11
To byłaby lepsza odpowiedź, gdybyś wyjaśnił w swojej odpowiedzi, w jaki sposób zwinni zwolennicy tworzą proces słomy, który nie będzie działał, ale nie jest właściwie Wodospadem.
Robert Harvey,
4
-1 dla stwierdzenia: „Są doskonałe w dostarczaniu ...” Prawda jest taka, że ​​to pranie. Jak wszystkie metodologie oprogramowania, czasem działa, a czasem nie. Widziałem oba w przypadku metody prawdziwego wodospadu.
riwalk
2
Muszę powiedzieć: [potrzebne źródło] na temat tej odpowiedzi. I -1, dopóki nie zostanie podany. Zwłaszcza „przodujący w terminowym dostarczaniu oprogramowania budżetowego spełniającego oczekiwania użytkowników” Raport CHAOS nie zgadza się z tobą.
Malfist
5

Być może lepszym sposobem zadawania pytań jest „kiedy jest mniej iteracyjny i bardziej formalny lepszy?”

Są sytuacje, w których tak jest:

  • Kiedy wymagania się nie zmienią.

  • Spełnienie nowych wymagań jest mniej ważne niż trafienie w 100% oryginalnych.

  • Kiedy wszystkie komponenty technologii są dojrzałe i dobrze zrozumiane.

W pewnym sensie możesz przyjąć przeciwieństwo tego, co może doprowadzić cię do zwinności.

Wszędzie stosuje się bardzo niewiele technik. Bardzo niewielu nie ma zastosowania.

MathAttack
źródło
1
Co na świecie jest „mniej napisane” lub „bardziej formalne”?
Aaronaught,
1
@Aaronaught - „mniej iteracyjny” i „bardziej formalny” wpisany grubymi kciukami na iPhonie. :-)
MathAttack,
1
Nigdy nie pracowałem nad projektem, który spełniłby choćby jeden z tych warunków. :)
Theodor
3

Tak, jest bardzo żywy, choć dziś jest to bardziej popularny „ model V ”, który jest używany.

W obu przypadkach problem Agile polega na tym, że rozwiązanie prawie nigdy się nie kończy, klient może nadal żądać zmian, a programowanie będzie je iteracyjnie rozwiązywać. W przypadku projektu opartego na kosztowaniu czasu i materiałów działa to bardzo dobrze. W przypadku projektu, który ma stały koszt, nie ma go.

W przypadku projektów o stałych kosztach klient prawie zawsze oczekuje, że z góry określone kamienie milowe wykażą postępy, jednak są one bardziej formalną odmianą pisaną niż działającym kodem. Dla takich klientów pisemne specyfikacje stają się projektem, w którym opracowanie oprogramowania jest kwestią drugorzędną (jak zakładają, jeśli masz dobrze zdefiniowany projekt, oprogramowanie powinno być łatwe do opracowania). Firmy te są również tymi, które intensywnie korzystają z tanich, zlecanych na zewnątrz zasobów programistycznych.

Tak więc, jeśli masz stałą pulę pieniędzy lub czasu, nie oczekuj zmian wymagań lub nie możesz zmieniać żadnych wymagań i oczekuje się, że dostarczy silny zestaw pisemnej dokumentacji, to modele wodospadu są jedynymi, które ma sens.

Zwinność można wprowadzić w środku tych projektów w celu opracowania, ale nadal istnieje faza rozruchu, w której specyfikacje są tworzone na podstawie wymagań, oraz faza rozruchu, w której oprogramowanie jest instalowane i testowane na miejscu. Zwinny nie reaguje dobrze na te przypadki.

gbjbaanb
źródło
Zwinny może działać bardzo dobrze z ustaloną pulą pieniędzy lub czasu, pod warunkiem, że zakres nie jest również ustalony. Inną kwestią jest to, że klient / wykonawca może wybrać rodzaj umowy (T&M, stały koszt lub coś pośredniego), aby zachować zgodność z określoną metodologią rozwoju (zwinną lub wodospadową) - nie jest to z góry określone.
DNA
1

Do kogo? Większość menedżerów, z którymi miałem do czynienia, nadal korzysta z procesu tworzenia oprogramowania Waterfall do planowania, a poziomy wydają się lubić w celu ułatwienia planowania.

Praktycznie niewielu programistów, o których wiem, wierzy, że to działa, a nawet jest prawidłowe.

jwernerny
źródło