7 min
25 września 2023
Agile czy Waterfall - którą metodykę wybrać?
Kluczowym elementem świadomego podejścia do metod zarządzania, jest pojęcie różnicy między tradycyjnym stylem zwanym modelem kaskadowym (Waterfall) a bardziej elastycznym podejściem wprowadzonym i opisanym w manifeście Agile.
Posłuchaj artykułu w wersji audio.
Agile i Waterfall są obecnie najpopularniejszymi i najczęściej stosowanymi metodami zarządzania projektami.
Pierwsza z nich polega na podzieleniu procesu projektowego na wiele krótkich etapów, co umożliwia szybką dostawę częściowego produktu. Dzięki temu, mamy możliwość otrzymania działającego produktu we wczesnej fazie, który następnie jest stopniowo rozbudowywany.
W drugim podejściu, które jest bardziej liniowe, gotowy produkt pojawia się dopiero na końcu procesu rozwojowego. Niestety, istnieje ryzyko, że taki produkt nie spełni aktualnych wymagań klienta, ponieważ został zaprojektowany kilka lub kilkanaście miesięcy wcześniej. To jest jedno z głównych problemów związanych z waterfall.
Przyjrzyjmy się szczegółowo obu metodom.
Agile
Zwinna - po angielsku "agile"- to metodologia projektowa, która została opisana w 2001 roku w "Manifeście Agile", który służył jako deklaracja wspólnych zasad dla nowych metod tworzenia oprogramowania. Zwinny sposób pracy jest stosowany nie tylko w branży IT, ale także w zarządzaniu innymi projektami.
W manifeście znalazły się 4 podstawowe wartości, 12 zasad zwinności i opis kluczowych faz procesu projektowego.
Podstawowe wartości, którymi kieruje się Agile
ludzie oraz wzajemne oddziaływania ponad procesy i narzędzia,
działające oprogramowanie ponad obszerną dokumentację,
współpraca z klientem ponad negocjowanie kontraktów,
reakcja na zmianę ponad realizację planu.
Dwanaście Zasad Manifestu Agile
Najwyższy priorytet ma zadowolenie klienta, dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania.
Zmiany wymagań mogą pojawić się nawet na późnym etapie jego rozwoju. Procesy zwinne wykorzystują zmiany dla zapewnienia klientowi konkurencyjności.
Dostarczajcie funkcjonujące oprogramowanie często, w kilkutygodniowych lub kilkumiesięcznych odstępach. Im częściej, tym lepiej.
Biznes i developerzy muszą codziennie ściśle ze sobą współpracować, przez cały czas trwania projektu.
Twórzcie projekty wokół zmotywowanych ludzi. Zapewnijcie im potrzebne środowisko oraz wsparcie i zaufajcie, że wykonają powierzone zadanie.
Rozmowa twarzą w twarz jest najbardziej efektywnym i wydajnym sposobem przekazywania informacji zespołowi deweloperskiemu i wewnątrz niego.
Podstawową miarą postępu jest działające oprogramowanie.
Procesy zwinne umożliwiają zrównoważony rozwój. Inwestorzy, deweloperzy oraz użytkownicy powinni być w stanie utrzymywać równe tempo pracy.
Ciągłe skupienie na technicznej doskonałości i dobrym projektowaniu zwiększa zwinność.
Kluczowa jest prostota - sztuka minimalizowania ilości koniecznej pracy.
Najlepsze rozwiązania architektoniczne, wymagania i projekty pochodzą od samoorganizujących się zespołów.
W regularnych odstępach czasu zespół analizuje możliwości poprawy swojej wydajności, a następnie dostraja i dostosowuje swoje działania do wyciągniętych wniosków.
Etapy procesu projektowego
planowanie – zebranie i analiza oczekiwań Klienta, informacji o budżecie, opracowanie koncepcji i założeń produktu
projektowanie – określenie kluczowych elementów projektu, sposobu i terminu ich realizacji
faza developerska – programowanie, właściwa praca nad projektem
testy – sprawdzanie zgodności produktu z założeniami i oczekiwaniami
wdrożenie – przekazanie produktu klientowi
feedback (informacja zwrotna) – informacja zwrotna od Klienta dla zespołu developerskiego, pozwala udoskonalić pracę zespołu
Podejście iteracyjne
W podejściu zwinnym, celem zespołu jest tworzenie wartości poprzez otrzymywanie informacji zwrotnej i planowanie postępu projektu w właściwy sposób. Te założenia są realizowane poprzez cykliczne podejście do pracy.
Praca jest podzielona na krótkie okresy (sprinty), w ramach których team koncentruje się na dostarczeniu konkretnej funkcjonalności będącej częścią ostatecznego rozwiązania. W czasie takiego okresu, zespół o różnorodnych umiejętnościach planuje pracę, projektuje rozwiązanie, testuje je i otrzymuje informację zwrotną od klienta. Dopiero na podstawie wyników zakończonego sprintu planuje kolejny. Ważne jest, aby w każdym sprincie (iteracji) dostarczać funkcjonalne ulepszenia (na przykład pojedynczą działającą funkcję aplikacji), które mogą być oceniane i sprawdzane przez klienta. Dzięki temu, że nie planujemy zbyt daleko w przyszłość, wszelkie zmiany mogą być wprowadzane i widoczne w kolejnych iteracjach. To również sprzyja wykrywaniu błędów programistycznych.
Dokumentacja w podejściu zwinnym
W metodzie Agile, projekt rozwija się w trakcie jego trwania, a dokumentacja zawiera tylko istotne elementy, które są uważane za wartościowe do zarejestrowania. Kod tworzony jest stopniowo, implementowany i integrowany, co oznacza, że każda nowa funkcja jest projektowana z uwzględnieniem już zaimplementowanych modułów i dokumentowana z uwzględnieniem istniejących już funkcjonalności.
Waterfall
Na Sympozjum Zaawansowanych Metod Programowania dla Komputerów Cyfrowych, które odbyło się 29 czerwca 1956 roku, Felix Torres i Herbert D. Benington po raz pierwszy zaprezentowali technikę kaskadową. Ten popularny sposób tworzenia oprogramowania, został szczegółowo opisany przez Winstona W. Royce'a w 1970 roku w artykule "Managing the Development of Large Software Systems".
W podejściu kaskadowym planujemy całe przedsięwzięcie z góry. Podobnie jak w spływie wodospadem, woda zmierza w jednym kierunku, przechodząc przez kolejne, ustalone stopnie. W tej metodologii polegamy na wykonaniu projektowych działań w ściśle określonych fazach, które następują po sobie.
Czynności, dzięki którym projekt jest prowadzony od kontrolowanego rozpoczęcia do kontrolowanego zakończenia:
Gromadzenie i ocena wymagań: Etap zbierania informacji (od klientów, interesariuszy) dotyczących funkcjonalności, systemowych lub technicznych, które będą wykorzystane w projekcie.
Projektowanie: Podobnie jak w elastycznym podejściu, także tutaj, w porozumieniu z zamawiającym, ustala się najważniejsze funkcje produktu lub usługi, również w kontekście doświadczeń użytkownika.
Testowanie: Etap testów, mających na celu ocenę jakości i wydajności. Jeśli produkt spełnia wymagania, otrzymuje akceptację zamawiającego. W przypadku wykrycia błędów, zespół projektowy usuwa je przed dostarczeniem produktu.
Przekazanie produktu: Następuje, gdy opracowywany produkt spełnia wszystkie początkowe wymagania ustalone na etapie projektowania.
Utrzymanie / konserwacja: Po otrzymaniu finalnego produktu, klient może zażądać wprowadzenia dodatkowych zmian (co wydłuży czas finalizacji projektu i zwiększy koszty).
Metodyka Waterfall opiera się na skrupulatnym realizowaniu wcześniej ustalonego planu. W ramach tej metodyki musi być ściśle przestrzegany harmonogram oraz prowadzona szczegółowa dokumentacja działań. Do tego celu można wykorzystać np. elektroniczny obieg dokumentów. Metoda Waterfall zakłada również określony budżet, którego nie można przekroczyć. Zespół pracujący w ten sposób musi być ograniczony i nie ma dużo miejsca do improwizacji, przestrzeni na zmiany i reagowania na bieżącą sytuację.
Kaskadowy sposób działania może być skuteczny, gdy ma się ściśle określony budżet oraz potrzebny jest bardziej przewidywalny rozkład czasowy. W ten sposób możemy pomyślnie realizować proste, długotrwałe projekty o niewielkich wymaganiach.
Charakterystyka pracy w modelu kaskadowym
Ważna jest dokumentacja i wytyczne, konieczne jest zapisanie wszystkiego. Pochłania to sporą część pracy developerów.
Następny etap pracy nie zaczyna się dopóki nie zostanie ukończony poprzedni.
Żaden z etapów nie może zostać pominięty.
Jeśli wymagania dotyczące produktu ulegną zmianie po konsultacji, klient musi oficjalnie zgłosić to i lista zadań zostanie dostosowana. Wydłuża to czas realizacji całego projektu.
Nie można powrócić do poprzedniego etapu w celu wprowadzenia zmian.
Brak iteracji - istnieje tylko jeden łączny proces tworzenia produktu.
Identyfikowanie i naprawianie błędów odbywa się wyłącznie na etapie testowania.
Klient nie uczestniczy w tworzeniu produktu po ustaleniu listy zadań i wymagań. Otrzymuje do testowania gotowy produkt.
Z życia wzięte
Dla firmy X wdrażamy nowe layouty całego serwisu. Projekt prowadzony jest metodą kaskadową. Po 3 miesiącach od rozpoczęcia projektu, klient przedstawia nową wizję funkcjonalności i wyglądu koszyka.
W praktyce oznacza to:
ponowną analizę projektu, która również wiąże się z kosztami po stronie klienta
ponowne przeliczenie wartości projektu
ponowne opracowanie, ustalenie i udokumentowanie kolejnych kroków projektu. Przy czym w tej metodzie często okazuje się, że w takiej sytuacji trzeba rozpocząć cały projekt od nowa.
Taka sytuacja nie jest komfortowa ani dla klienta, ani dla developerów pracujących przy projekcie.
W projekcie prowadzonym metodą zwinną, tego typu zmiana byłaby czymś naturalnym, przeprowadzonym płynnie w kolejnej iteracji. Model Agile z góry zakłada ewolucję i zmiany w trakcie, a nie po całkowicie zakończonym projekcie.
Obecnie zaleca się korzystanie z metody kaskadowej tylko w trzech sytuacjach:
1) W przypadku klienta, który wymaga przejrzystości w wykonywanych pracach, a projekt jest do zrealizowania w określonym czasie.
2) Podczas obecności kadr kierowniczych posiadających odpowiednie kwalifikacje.
3) Przy realizacji projektu, który nie posiada konkurencji na rynku.
