Czy metodologia tworzenia oprogramowania Waterfall jest nadal opłacalna?

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?

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.

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.

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.

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.

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.

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.