Wśród licznych pytań, które powstają w każdym projekcie, jedno zagadnienie wyróżnia się: jaki jest najlepszy sposób zarządzania procesem rozwoju produktu? Co szczególnie przychodzi na myśl, to Waterfall – jedna z opcji, która przez lata okazała się skuteczna (lub model kaskadowy do zarządzania rozwojem oprogramowania).
W rzeczywistości ta metodologia jest obecnie surowo krytykowana, ale czy naprawdę jest tak zła, czy po raz kolejny przekonamy się, że historia się powtarza?
Cykl życia oprogramowania
Każdy zespół programistów może stworzyć swój własny model cyklu życia oprogramowania lub skorzystać z czegoś, co jest powszechnie uznawane. Jedną z opcji jest Waterfall. Amerykanin V.U.Royce jest uważany za twórcę tego modelu. Plotkowano, że pożyczał wiele rzeczy od swoich kolegów, przypisując sobie ich prace. Miało to miejsce w 1970 roku. Do dnia dzisiejszego metoda przedstawiona przez Royce'a jest stosowana w wielu projektach, zarówno w swojej oryginalnej wersji, jak i w wersji zmodyfikowanej.
Pewni insiderzy IT twierdzą jednak, że taka metodologia nigdy nie istniała:
„Jako profesjonalista IT i nauczyciel, przez ponad 40 lat słyszałem wiele mitów na temat branży IT. Ale to, co nadal mnie zaskakuje, to powód, dla którego słowo „Waterfall” jest nadal używane do opisania nieistniejącej metodologii, a także dlaczego twórcy metod i systemów rozwoju używają go jako obiektu do porównań.”
David Dischave, Profesor Szkoły Studiów Informacyjnych, Uniwersytet Syracuse, USA
Dziwnie słyszeć takie rzeczy o metodologii, która była stosowana przez dekady w rozwoju oprogramowania w różnych dziedzinach, takich jak przemysł motoryzacyjny, budownictwo, finanse i księgowość, medycyna oraz elektronika.
Waterfall w IT
Główną zasadą modelu Waterfall w rozwoju oprogramowania jest to, że każdy kolejny krok nie może być rozpoczęty, chyba że poprzedni został zakończony. Jednocześnie nie są dozwolone żadne arbitralne ruchy naprzód lub wstecz, a etapy nie powinny się nakładać. To podstawowa rzecz, która wyróżnia metodologię kaskadową spośród jej zwinnych rówieśników (lub rywali), takich jak Agile, DSDM, Scrum czy FDD.
Algorytm działania w Waterfall
Aby zrozumieć pomysły Royce'a, które leżą u podstaw modelu, możesz zapoznać się z jego oryginalną pracą:
Royce, Winston (1970), Zarządzanie rozwojem dużych systemów oprogramowania.
Praca oparta na kaskadzie
Formułowanie i omawianie pomysłu
Ten etap zasadniczo nie obejmuje rozwoju. Rozważany jest jedynie pewien nowy pomysł interesujący jedną lub więcej osób.
Analiza wymagań
Ten etap obejmuje najbardziej szczegółową specyfikację wymagań klienta dotyczących projektu. Określane są sposoby osiągnięcia celu; wyznaczane są terminy operacji wraz z aspektem finansowym. Jednocześnie pewna rezerwa czasu i pieniędzy zostaje przeznaczona na każdą jednostkę roboczą. Po zakończeniu analizy wymagań gotowe są zadanie techniczne dla programistów i budżet.
Projektowanie oprogramowania
Ten etap obejmuje określone kroki:
- wybór platformy programistycznej (Python, PHP, JS itd.)
- ustalenie szczegółów technicznych (np. interakcja między usługą lub produktem a serwerami, użycie API lub nie, logika interfejsów zewnętrznych i wewnętrznych itd.)
- rozwiązywanie problemów związanych z bezpieczeństwem projektu (np. użycie HTTPS, szyfrowanie SSL itd.)
- wytyczenie ról użytkowników oprogramowania (administrator, klient, menedżer itd.)
- finalizacja kwestii niezawodności, efektywności i dalszego wsparcia technicznego docelowego produktu.
- ustanowienie odpowiedniego zespołu.
Rozwój oprogramowania
Ten etap obejmuje pisanie kodu zgodnego z wcześniej sporządzonymi dokumentami.
Testowanie oprogramowania
Specjaliści testują finalną wersję produktu w warunkach zbliżonych do rzeczywistości, zapisując w nim błędy. Najbardziej krytyczne błędy wpływające na ogólne działanie oprogramowania są naprawiane, mniej istotne mogą pozostać niepoprawione, jeśli czas minie lub budżet się wyczerpie.
Wsparcie techniczne oprogramowania
Uzyskany działający produkt oprogramowania jest używany zgodnie z jego przeznaczeniem z zapewnieniem wsparcia. Oznacza to, że zapewnia się jego działanie, naprawia usterki, planuje aktualizacje funkcjonalności na podstawie opinii użytkowników.
Wszystkie powyższe etapy są realizowane w ściśle określonej kolejności, a ich wyniki są dokumentowane.
Aby zrozumieć ewolucję klasycznej metodologii Waterfall opisanej powyżej, możesz zapoznać się z Zasadami Zarządzania Projektem. Wersje 3. i 4. mają szereg nieścisłości, które pomogą zrozumieć „kaskadową” ścieżkę.
Zalety i wady modelu kaskadowego rozwoju oprogramowania
Niestety, nic nie jest doskonałe w naszym świecie, więc metodologia kaskadowa ma zarówno mocne, jak i słabe strony.
| Mocne strony modelu kaskadowego rozwoju oprogramowania | Słabe strony modelu kaskadowego rozwoju oprogramowania |
|
|
|
|
| |
|
|
|
|
|
Jak korzystać z modelu rozwoju kaskadowego i w jakich przypadkach?
Z doświadczeń wynika, że model Waterfall w rozwoju oprogramowania jest dość trafny w następujących przypadkach:
- klient uczestniczy w projekcie tylko w pierwszej fazie, a następnie akceptuje gotowy produkt;
- wymagania dotyczące produktu nie podlegają zmianom;
- projekt jest wysoce skomplikowany, długoterminowy i kosztowny;
- jakość jest głównym priorytetem, nawet kosztem czasu;
- brak zespołu składającego się z programistów z najwyższej półki;
- można zlecić specjalistów do realizacji projektu.
Aby zrozumieć możliwe motywy porzucenia metodologii kaskadowej, możesz przeczytać książkę
Scrum. Rewolucyjna Metoda Zarządzania Projektem autorstwa Jeffa Sutherland.
Przykłady użycia Waterfall
Czysty model kaskadowy nie jest obecnie zbyt szeroko stosowany w nowoczesnym rozwoju, a bardzo często
to, co nie może być zaklasyfikowane jako Agile, nazywane jest Waterfall, w związku z czym trudno jest określić, gdzie ta konkretna metodologia jest stosowana.
Zgodnie z opinią ekspertów, znaczna część systemów ERP oraz programów przewidzianych dla budownictwa, medycyny, operacji w ramach kontraktów rządowych, przemysłowego użytku lub podobnych zasadniczych aplikacji, jest rozwijanych z użyciem z pewnością zmodyfikowanej wersji Waterfall.
Specyficzne cechy obsługi takich projektów lepiej zrozumieć można w książce „Rozwój wzorcowego systemu przedsiębiorstw” autorstwa Siergieja Zykowa.
Co też jest logicznie uzasadnione. Opisał to także Chuck Cobb, mentor, trener oraz autor książek poświęconych metodom Agile w zarządzaniu projektami.
Jeśli budujesz most przez rzekę, byłoby zabawne powiedzieć: „Zbudujemy pierwszą superstrukturę, potem zobaczymy, jaki będzie wynik, a następnie zdecydujemy, czy dokończyć resztę superstruktur!”
Wśród firm, w których Waterfall jest lub był stosowany, można wymienić:
| Nazwa firmy | Cel stosowania modelu Waterfall | Czy metodologia jest obecnie stosowana | Komentarz przedstawiciela firmy |
| Wüstenrot & Württembergische (W&W) | Rozwój systemu ERP dla sektora finansowego | Brak danych | — |
| Cisco | Rozwój systemów bezpieczeństwa | Tak | — |
| EPAM | Różne produkty lub rozwiązania lub ich części | Tak | Aleksey Ionov: „...nie jest konieczne realizowanie całego dużego projektu w Agile — elastyczny rozwój może być stosowany w niektórych fazach lub przepływach pracy...” |
| IBM | Różne produkty lub rozwiązania lub ich części | Tak | Rosalind Radcliffe: „Teraz jest czas, kiedy zespoły rozwojowe pracujące w Waterfall nie mogą spełnić wymagań biznesowych, więc takie projekty i produkty wymagają więcej pracy serwisowej ... Waterfall będzie stopniowo zastępowany przez nowe technologie i nowe zespoły zaangażowane w wprowadzanie nowych praktyk biznesowych”. |
| Microsoft IT | Różne produkty lub rozwiązania lub ich części | Nie | |
| AT Consulting | Różne produkty lub rozwiązania lub ich części | Tak | Wasilij Korablew: „Aby rozwijać systemy „od podstaw”, stosujemy lub elastyczne (Agile), lub kaskadowe (Waterfall) podejście do rozwoju, lub kombinację oba z nich.” |
| Parallels | Różne produkty lub rozwiązania lub ich części | Tak | Nikolay Dobrovolskiy: „W różnych projektach stosujemy różne podejścia — w niektórych przypadkach Agile z jedno- lub dwutygodniowymi sprintami, w innych przypadkach — quasi-Waterfall z milestones, które mogą trwać kilka miesięcy. Przez wiele lat ukształtowaliśmy pogląd, że im większy projekt lub zespół nad nim pracujący, tym bardziej złożona i mniej efektywnie jest próbować zmieścić rozwój w procesie zwinności”. |
| SAP | Różne produkty lub rozwiązania lub ich części | Tak | Evgeniy Arnautov: „Na etapie tworzenia produktu często możemy zobaczyć warianty Agile, a czasami są one łączone z podejściem Waterfall”. |
| Toyota | Różne produkty lub rozwiązania lub ich części | Nie | Satoshi Ishii: „...próbujemy nauczyć się, jak stosować TPS (Lean na Zachodzie) w rozwoju oprogramowania. |
Aplikacje i programy do zarządzania rozwojem na podstawie modelu kaskadowego
Aby obsługiwać Waterfall, można skorzystać z szeregu produktów ułatwiających śledzenie czasu i zdolnych do tworzenia wykresów Gantta.
Worksection
To atrakcyjna ukraińska usługa saas, która oferuje wygodną wersję mobilną.
Jest odpowiednia do starannego planowania dzięki następującym dostępnym funkcjom:
- Wykres Gantta z powiązaniami między zadaniami a terminami
- podział obowiązków między wykonawcami o różnych uprawnieniach
- system zróżnicowanych form raportowania
- zachowywanie komentarzy, emotikonów i całej historii działań w ramach projektu
- ograniczony dostęp klienta/konsumenta dla przejrzystości procesu rozwoju
- możliwość wskazania budżetów i wydatków
- listy kontrolne для małych etapów zadań w celu ułatwienia wykonywania zgodnie z poleceniem.
Werdykt
Waterfall to metodologia stosowana przez dość długi czas i niezależnie od tego, co mówią krytycy, jest skuteczna
w licznych przypadkach.
Jednocześnie, to podejście jest nieodpowiednie w czystej formie dla wielu projektów, które wymagają szybkiej reakcji na zmieniające się wymagania rynku. Na podstawie tego, co mówią przedstawiciele w dużej mierze zróżnicowanych firm, możemy stwierdzić, że Waterfall zasługuje na rolę w współczesnych projektach. Jednak stosowanie Waterfall jest uzasadnione tam, gdzie wymagania są stałe i z pewnością pozostaną takie do terminu ukończenia projektu.