Żyjemy w świecie, w którym metodyka Agile jest wszechobecna. Od słynnych gigantów technologicznych po małe startupy — wszyscy jej używają do tworzenia swoich produktów. Ucząc się o Agile, być może spotkałeś się z terminem „metodyka kaskadowa”.
Większość kierowników projektów korzystających z Agile uważa metodykę kaskadową za przestarzałą metodykę, która w 2023 roku nie ma już zastosowania. Ale czy rzeczywiście tak jest?
Jako starszy kierownik produktu mam duże doświadczenie zarówno w Agile, jak i w metodyce kaskadowej. W obronie metodyki kaskadowej przyjrzyjmy się bliżej temu, czym jest, jak działa i kiedy warto ją stosować.
Na czym polega metodyka kaskadowa zarządzania projektami?
Metodyka kaskadowa opiera się na koncepcji zarządzania projektami rozwojowymi poprzez podzielenie ich na odrębne fazy i realizowanie każdej z nich kolejno.
Choć dzielenie dużych partii pracy na mniejsze części jest koncepcją stosowaną przez ludzi od zarania dziejów, formalne „narodziny” metodyki kaskadowej nastąpiły znacznie później — w 1970 roku, gdy dr Winston W. Royce, wybitny informatyk tamtej epoki, opisał ją w swojej książce „Zarządzanie tworzeniem dużych systemów programistycznych”.
Od tego czasu był to główny sposób zarządzania projektami przez firmy programistyczne, aż świat na początku lat 2000. zaczął skłaniać się ku Agile.
Jak wygląda cykl życia oprogramowania (SDLC) w metodyce kaskadowej
W przeciwieństwie do iteracyjnej i przyrostowej struktury Agile, SDLC w metodyce kaskadowej ma wyraźny początek i koniec. Dzieli cały proces tworzenia oprogramowania na pięć różnych faz lub kamieni milowych, a praca nad jedną fazą nie rozpoczyna się, dopóki poprzednia faza nie zostanie ukończona. Wizualnie wygląda to tak:
Praca przepływa z jednej fazy do drugiej, a następnie dociera do końca i projekt zostaje uznany za „ukończony” — dzięki temu wizualnie przypomina wodospad (stąd ta nazwa).
Przyjrzyjmy się teraz każdej fazie tego liniowego podejścia i zrozummy, na czym polega.
Faza nr 1: Zbieranie wymagań
Wszystko zaczyna się od zebrania wymagań dotyczących projektu od wszystkich interesariuszy. W fazie wymagań kierownicy projektu tworzą kompleksowy i bardzo szczegółowy dokument obejmujący każdy aspekt projektu — od wymagań funkcjonalnych po plan budżetu i ryzyka.
Have an account? Log In
Faza nr 2: Projektowanie rozwiązania
Na podstawie wymagań zebranych w poprzedniej fazie zespół projektowy zaczyna opracowywać i projektować rozwiązanie. Termin „projektowanie” odnosi się tutaj do technicznej struktury produktu (projekt systemu), wizualnego i interakcyjnego projektu produktu (projekt interfejsu użytkownika i doświadczenia użytkownika, UI/UX) oraz projektu fizycznego (jeśli jest to produkt fizyczny).
Faza nr 3: Implementacja
To właśnie wtedy odbywa się właściwe kodowanie. Członkowie zespołu programistycznego zaczynają tworzyć produkt na podstawie rezultatów pracy przygotowanych w fazie projektowania.
W przeciwieństwie do Agile, gdzie można stale zmieniać zakres projektu i projekt rozwiązania, metodyka kaskadowa zakłada, że będziesz postępować zgodnie z dokumentem projektowym i nie będziesz „rozwijać” produktu w trakcie fazy implementacji.
Faza nr 4: Testowanie
Gdy tylko zespół inżynierii oprogramowania zakończy tworzenie produktu, możemy przejść do kolejnej fazy naszego planu projektu — testowania. Zespół zacznie sprawdzać produkt pod kątem błędów, luk w zabezpieczeniach i problemów z doświadczeniem użytkownika.
W fazie testowania sprawdzisz również, czy funkcjonalność i projekt produktu końcowego odpowiadają wymaganiom projektu opisanym w dokumentach utworzonych podczas dwóch pierwszych faz.
Faza nr 5: Wdrożenie i wsparcie po wydaniu
Zakładając, że zespół znalazł i naprawił wszystkie istotne problemy w produkcie, nadszedł czas na wydanie rozwiązania i przekazanie go klientom oraz użytkownikom końcowym.
Programiści przejdą teraz do fazy utrzymania, stale zbierając opinie klientów, wprowadzając niezbędne poprawki oraz wydając nowe poprawki i aktualizacje produktu.
To wszystko — projekt jest ukończony i możesz przejść do kolejnego!
Czy zatem należy stosować metodykę kaskadową?
Jeśli jako kierownik projektu nastawiony na Agile (a przynajmniej zakładam, że nim jesteś) uważasz, że ta metodyka wyszła z mody i nigdy nie należy rozważać jej zastosowania, to (z całym szacunkiem) się z Tobą nie zgadzam i twierdzę, że podejście kaskadowe jest w rzeczywistości lepszym wyborem dla określonych rodzajów projektów.
Pokażę Ci kilka przykładów, aby udowodnić swoje stanowisko.
Studia przypadków: metoda kaskadowa w praktyce
Podobnie jak w przypadku każdej złożonej koncepcji, kilka konkretnych przykładów może pomóc w zrozumieniu, jak ta metodologia działa w prawdziwym życiu. Oto więc kilka przykładów opartych na rzeczywistych projektach (przy których mogłem, ale nie musiałem osobiście pracować), które pomogą ci lepiej zrozumieć, jak podejście kaskadowe działa w praktyce.
Przypadek nr 1: Platforma odprawy celnej dla rządu Egiptu
Wyobraź sobie, że pracujesz w firmie, która wygrała przetarg na modernizację systemów handlu międzynarodowego i odpraw celnych stosunkowo dużego kraju, na przykład Egiptu.
Rząd Egiptu chce systemu dla władz portowych, który będzie zarządzał manifestami wszystkich statków (dokumentem celnym zawierającym informacje o całym ładunku i wszystkich pasażerach znajdujących się na pokładzie statku) wpływających do różnych portów Egiptu.
Co więcej, chce, aby system ten bezpośrednio integrował się z innym produktem, który masz zbudować i który będzie obsługiwał wszystkie zgłoszenia celne (czyli SAD-y, czyli jednolite dokumenty administracyjne) w kraju. Formularz jest dość skomplikowany do wypełnienia przez zwykłych ludzi, dlatego chcą, abyś go dla nich zautomatyzował.
Egipt ma złożony system podatkowy i celny, w którym stawki zmieniają się w zależności od rodzaju importowanych towarów, ich ilości i innych czynników. Ponieważ zwykli obywatele nie mają pojęcia o tych stawkach, rząd Egiptu chce, aby aplikacja automatycznie obliczała wszystko dla obywateli na podstawie zadeklarowanych przez nich danych i pozwalała im płacić przez internet za pomocą kart kredytowych.
Wygląda to na ogromne przedsięwzięcie, prawda? Cóż, podczas finalizowania szczegółów wdrożenia kierownictwo (a być może nawet rząd Egiptu) przyjdzie do ciebie, kierownika projektu, i zapyta, jak chcesz zorganizować realizację tego projektu.
Dlaczego i jak należy zastosować metodę kaskadową w tym scenariuszu:
Cokolwiek budujesz dla rządu krajowego, najprawdopodobniej będzie oparte na ustawie lub decyzji ratyfikowanej przez parlament. Decyzje te będą obejmować wszystko — od ogólnych warunków projektu (np. jego kosztu i harmonogramu) po najdrobniejsze szczegóły dotyczące sposobu działania całego rozwiązania.
Brzmi i wygląda to jak dokument wymagań z pierwszej fazy metody kaskadowej, prawda? W rzeczywistości tak właśnie jest, a to oznacza również, że nie możesz swobodnie zmieniać szczegółów wdrożenia, projektu ani wymagań w trakcie realizacji, tak jak ma to miejsce w zwinnym tworzeniu oprogramowania.
Kiedyś kierowałem takim produktem. Pewnego dnia zdaliśmy sobie sprawę, że możemy znacznie poprawić komfort użytkowania, wprowadzając kilka drobnych zmian w logice biznesowej. Natychmiast podzieliliśmy się naszym pomysłem z przedstawicielem władz celnych, który z nami pracował.
Cóż, powiedział „nie”. Można by pomyśleć, że odrzucenie takiej propozycji było złym pomysłem, ale miał dobry powód, dla którego nie mogli tego zrobić.
Nasze niewielkie poprawki oznaczałyby zmianę wzoru, którego rząd używał do obliczania podatków dla konkretnego produktu. Wzór był określony w ustawie, więc jego zmiana oznaczałaby zebranie całego parlamentu krajowego i przeprowadzenie głosowania.
More Articles
Przypadek nr 2: System sterowania lotem helikoptera Ingenuity
Ingenuity to nazwa nadana przez NASA zaawansowanemu technologicznie helikopterowi, który zbudowali i wysłali na Marsa w 2021 roku. Tak wygląda ten mały sprzęt.
Wyobraź sobie, że jesteś jednym ze szczęśliwych kierowników projektu odpowiedzialnych za opracowanie oprogramowania dla tego niezwykłego urządzenia. W szczególności twój zespół musiał napisać kod sterujący lotem helikoptera.
Stworzenie systemu sterowania lotem statku powietrznego (zwłaszcza helikoptera) jest bardzo trudne. Musisz uwzględnić wszystkie prawa fizyki oddziałujące na statek powietrzny podczas lotu oraz obliczyć niezbędną prędkość obrotową łopat, kąt ich nachylenia i milion innych rzeczy.
Twoje zadanie jest jednak jeszcze bardziej złożone. Helikopter będzie musiał latać nad powierzchnią innej planety, której atmosfera jest 100 razy rzadsza niż atmosfera Ziemi.
Dlaczego i jak należy zastosować metodę kaskadową w tym scenariuszu:
Moim zdaniem tworzenie oprogramowania metodą kaskadową jest tutaj jedyną opcją. W przeciwieństwie do zarządzania projektami zwinną metodą, w którym budujesz coś małego (swój MVP), wdrażasz to, wykorzystujesz w prawdziwym życiu, zbierasz opinie i stopniowo ulepszasz rozwiązanie na ich podstawie, stawka w przypadku takiego projektu jest zdecydowanie zbyt wysoka.
Czy naprawdę można zaryzykować stworzenie wadliwej wersji MVP urządzenia Ingenuity i wysłanie jej 140 milionów mil na Marsa? Po prostu nie ma mowy, żeby ktokolwiek się na to zgodził.
Dlatego trzeba zbudować jego ostateczną wersję, a następnie rygorystycznie przetestować wszystkie jego systemy, zanim zyska się wystarczającą pewność, by umieścić go w rakiecie lecącej na Czerwoną Planetę.
Model kaskadowy ma się dobrze!
W rzeczywistości jest znacznie popularniejszy, niż można by się spodziewać — połowa wszystkich projektów na całym świecie nadal korzysta z tej metodyki rozwoju.
Chociaż pojawienie się metodyk zwinnych uczyniło świat lepszym miejscem dla wielu kierowników projektów, umożliwiając im znacznie wcześniejsze wprowadzanie produktów na rynek i rozwijanie ich na podstawie opinii użytkowników, model kaskadowy nadal jest niezwykle wartościową metodyką, którą można stosować w projektach o ograniczonej elastyczności i niskiej tolerancji na błędy.
Mam nadzieję, że spodobało Ci się nasze omówienie metodyki kaskadowej. Jeśli chcesz przeczytać nieco więcej o metodykach zwinnych, mogę polecić:
- Nasz przewodnik po zwinnym zarządzaniu produktem.
- Zbiór najlepszych praktyk dotyczących zwinnego zarządzania portfelem produktów.
- Naszą starannie wybraną listę najlepszych narzędzi do zwinnego zarządzania produktami.
To tylko trzy z wielu przewodników i artykułów, które przygotowaliśmy na temat zarządzania produktami i projektami. Aby dowiedzieć się więcej, zapisz się do naszego newslettera.