Która metoda jest lepsza dla zespołu: Agile czy Waterfall? Właściwy wybór pozwoli uniknąć straty czasu i pieniędzy. Ale żeby go dokonać, trzeba ocenić mocne i słabe strony każdej z metodologii. W naszym artykule porównamy elastyczny i kaskadowy model rozwoju i powiemy, co warto wziąć pod uwagę przy wyborze taktyki pracy nad projektem.

WATERFALL

Waterfall — technologia tworzenia oprogramowania znana już od 1970 roku. Opisał ją Winston Royce. Podzielił proces tworzenia produktu na logiczne etapy, które mogą nakładać się na siebie w czasie, aby nadać technologii nieco elastyczności. Jednak ich kolejność pozostaje niezmienna. Jeśli to wszystko zwizualizować, otrzymamy model przypominający wodospad — zgodnie z nazwą metodologii.

Struktura i specyfikacja techniczna na czele procesu

Waterfall — sztywna struktura, która jest zapisana na papierze i której nie można zmieniać. Kolejny etap można rozpocząć dopiero po zakończeniu poprzedniego. Dlatego dokumenty zawierające wymagania i instrukcje w tej metodologii są praktycznie święte. Klient nie ingeruje w tworzenie produktu po zatwierdzeniu specyfikacji technicznej. Musi ona być przemyślana, a dokumentacja sporządzona w sposób profesjonalny. Im bardziej szczegółowa dokumentacja, tym większa pewność co do wyniku.

Metodologia ta do dziś ma swoich zwolenników — są to ludzie, którzy cenią sobie stabilność i kontrolę. Spodobało im się raz na zawsze określenie kolejności czynności w procesie tworzenia oprogramowania. Dzięki temu model Waterfall zapewnił ścisłą kontrolę jakości i przejrzysty proces. Od samego początku będziesz wiedzieć, czego potrzebujesz. A na koniec otrzymasz pełnoprawny produkt, a nie tylko jego działającą część (ale o tym później). Z kolei klient będzie dokładnie wiedział, kiedy projekt zostanie ukończony i jaki budżet jest potrzebny. Dzięki systemowi raportowania będzie można przeanalizować poświęcony czas, budżet i zasoby.

Jednak powrót do wcześniejszych etapów projektu nie jest możliwy. System surowo zabrania takich cofnięć: należy poczekać na zakończenie prac rozwojowych, wprowadzić produkt do eksploatacji, sprawdzić go, a następnie w razie potrzeby zmodyfikować. Tak więc błędy mają tutaj szczególną cenę w postaci czasu i pieniędzy. 

Kurs z zakresu zarządzania projektami w IT: IT Project Management

Etapy rozwoju w modelu Waterfall:

• Analiza wymagań, sporządzanie specyfikacji technicznej i planowanie procesów.
• Projektowanie. Na tym etapie opracowuje się prototyp oprogramowania. 
• Przygotowanie projektu.
• Integracja. Połączenie części w jeden produkt.
• Testowanie. Gotowy produkt jest sprawdzany pod kątem błędów programowych i niedociągnięć funkcjonalnych. Następnie należy naprawić wykryte błędy.
• Wprowadzenie produktu na rynek. Premiera gotowego projektu i zakończenie prac rozwojowych. Możliwe jest również dostosowanie projektu do innych systemów.
• Pomoc techniczna. 

Popularne metody Waterfall:

• Sashimi — etapy pracy przebiegają po kolei i nakładają się na siebie w czasie. Oznacza to, że kończąc pracę na pierwszym etapie, już zaczynasz pracować nad drugim.

• Waterfall z podprojektami — metoda pracy obejmująca trzy duże etapy: opracowanie koncepcji, projektowanie i strukturyzacja produktu. Każdy z tych bloków ma swoje etapy. Po zakończeniu prac na każdym etapie są one integrowane ze sobą.
• Model ograniczania ryzyka — projekt dzieli się na mniejsze projekty, które mają na celu wykrycie niedociągnięć przed wydaniem oprogramowania. 

„Potrzebowaliśmy łyżki – więc ją zrobiliśmy. Lubię konkretność”.

© Damian, kierownik projektu

„Uff, wow. Po roku otrzymaliśmy gotowy produkt. Czy ktoś nadal go potrzebuje?”.

© Agata, menedżer produktu

AGILE

Agile (z angielskiego „elastyczny”) to termin łączący szereg współczesnych metodologii elastycznego zarządzania projektami. Istotą elastycznego zarządzania jest to, że opiera się ono nie na zasadach, ale na zasadach, którymi kieruje się zespół przy podejmowaniu decyzji. W Agile istnieje plan, ale nie ma ścisłej struktury wewnętrznej. Ludzie decydują, w jakim kierunku będzie zmierzał projekt, dlatego zachęca się tu do kreatywności. Do elastycznych metod zarządzania należą popularne frameworki Scrum i Kanban. 

Najważniejszy jest tutaj produkt. Ważniejsze jest osiągnięcie rezultatu niż tygodnie pisania dokumentacji. Lepiej zrobić coś niedoskonale, ale zrobić. W Agile proces tworzenia i wprowadzania zmian nie kończy się, cykl po cyklu poprawiane są niedociągnięcia i wdrażane są nowe pomysły. 

Za najważniejszą książkę uważa się Agile Manifesto, opracowaną w lutym 2001 roku. W manifeście opisano 4 wartości i 12 zasad, którymi należy się kierować podczas tworzenia oprogramowania.

4 wartości dla metodologii Agile

• Komunikacja jest ważniejsza niż narzędzia. 

Agile opiera się na żywej komunikacji. Podejście Scrum zakłada codzienne spotkania z klientami i zespołem, omawianie wyników pracy i wyrażanie pomysłów. Dzięki komunikacji zespół staje się monolitycznym organizmem, choć utrudnia to przekazanie projektu innemu zespołowi.  

• Współpraca z klientem jest ważniejsza niż warunki umowy.

Chodzi tu o zaspokojenie rzeczywistego popytu, a nie o walkę o literę. To klient określa wizję, zna całościowy obraz sytuacji. Zespół dąży do jakości i współpracuje z klientem, aby zrealizować jego pomysł i wizję. 

• Działający produkt jest ważniejszy niż szczegółowa dokumentacja.

Agile nie opiera się na szczegółowym planowaniu. Na początek wystarczy krótka rozmowa i podjęcie decyzji, co należy zrobić w ciągu kilku iteracji. Na końcu każdej z nich powinien być mierzalny wynik. Wynik jest ważny, ponieważ daje możliwość wejścia na rynek, zbadania reakcji użytkowników i przetestowania nowych pomysłów.

• Gotowość do zmian jest ważniejsza niż trzymanie się pierwotnego planu.

Plan jest potrzebny, aby określić kierunek działania, ale rzeczywistość stawia ostateczny punkt. Często zespół widzi, że rozwiązanie po prostu nie działa i nie ma sensu poświęcać mu czasu. Bez gotowości do zmian istnieje ryzyko wypadnięcia z rynku. 

Ale jest też druga strona medalu: obliczenie ostatecznych kosztów jest praktycznie niemożliwe — wymagania dotyczące projektu mogą się stale zmieniać. Należy pamiętać, że zbyt radykalne zmiany mogą zniweczyć projekt. Potrzebna jest tu umiar.

Jak działa Agile

Ponieważ ludzie i spójność zespołu są jedną z wartości podejścia Agile, porozmawiajmy o rolach w zespole. Kierownik projektu (który gdzieś może być nazywany właścicielem produktu lub menedżerem produktu) wyznacza kierunek. Widzi projekt oczami interesariuszy i przekazuje tę wizję zespołowi. Ponadto bierze pod uwagę opinie użytkowników i określa kolejny celowy krok. Mówiąc prościej, przekłada informacje zwrotne na zadanie techniczne. 

Zarządzanie produktami w IT uczymy na kursie IT Product Management

Kolejną ważną postacią w projekcie Agile jest kierownik projektu. Planuje on iteracje, koordynuje pracę zespołu i odpowiada za terminowe i wysokiej jakości wykonanie zadań. Osoba ta pomaga utrzymać atmosferę na takim poziomie, aby każdy członek zespołu był świadomy znaczenia swojej roli, rozumiał etap, na którym znajduje się projekt, i był ogólnie zmotywowany.

Oczywiście proces rozwoju produktu nie jest możliwy bez zespołu. W jego skład mogą wchodzić programiści, projektanci, copywriterzy, testerzy, specjaliści ds. UX, analitycy itp. Liderzy i zespół to wzajemnie powiązany system, który musi działać wspólnie. 

Tu kryje się jeszcze jedno zagrożenie — produkt jest bardzo zależny od zespołu. Agile wymaga dużego zaangażowania w proces, dlatego do wyboru zespołu należy podchodzić odpowiedzialnie.

Stosunek do ryzyka

Elastyczne metodyki pomagają pracować w całkowitej niepewności. W większości z nich rozwój odbywa się w krótkich cyklach — iteracjach trwających 2–3 tygodnie. Każda iteracja pozwala stworzyć projekt w miniaturze, przetestować go i ocenić jego możliwości. I choć nie każda iteracja pozwala na wydanie pełnoprawnej nowej wersji, to jednak dają one możliwość szybkiego dostosowania się, poznania rynku i dopracowania projektu tak, aby stał się on opłacalny. Agile pomoże uczynić produkt silnym, ale trzeba zdać sobie sprawę, że wyścig będzie trwał bardzo długo. A podczas tej drogi mogą wystąpić zarówno przełomy, jak i regresy. Ogólnie rzecz biorąc, wielu menedżerów zgadza się, że ryzyko wypalenia w Agile jest znacznie wyższe niż w Waterfall. 

„Tak, to wyścig, ale na pewno nie będzie nudno. Rynek się zmienia i nie możemy pozostawać w tyle”.

© Natalia, Scrum Master

„Chłopaki, zmieniłem zdanie. Zróbmy to jeszcze raz”. 

© Piotr, klient

Które podejście będzie odpowiednie dla Twojego projektu?

Nie ma dobrej lub złej metodologii. Jest metodologia, która jest dobrze dobrana i zastosowana właśnie do Twojego projektu. Przeanalizowaliśmy zalety i wady obu podejść. Biorąc pod uwagę ich cechy, można powiedzieć, że Agile jest dobre dla produktów IT, start-upów, które działają w niepewnym, często zmieniającym się środowisku. Jest to podejście dla Ciebie, jeśli nie wiesz, gdzie znajdziesz się jutro. Waterfall natomiast nadaje się do małych projektów o wysokim stopniu pewności. Jeśli dokładnie wiesz, jaki projekt jest potrzebny w rezultacie, lub jeśli realizowałeś już podobny projekt, możesz przemyśleć jasną sekwencję etapów.

Waterfall jest potrzebny w przypadku projektów o stałej cenie, gdzie jest czas i zasoby, aby wszystko przygotować i uniknąć błędów. W przypadku podejścia Agile łatwiej jest manewrować. W projekcie Waterfall kluczowy jest termin realizacji produktu. W Agile — sam produkt i jego jakość zgodnie z wizją klienta. Co ważne, sam klient powinien wiedzieć, jak działa Agile.

Agile jest odpowiedni dla zespołów wielofunkcyjnych, które łączą specjalistów z różnych dziedzin. W tym przypadku ważny jest profesjonalizm wszystkich uczestników. Waterfall — podejście o jasnej strukturze, które jest odpowiednie zarówno dla doświadczonych specjalistów, jak i dla początkujących. Projekt oparty na metodologii Waterfall może być realizowany przez wewnętrzny zespół programistów i innych specjalistów na zasadzie outsourcingu.

Zalecamy przeczytać:

• Jak sztuczna inteligencja zmieni zarządzanie projektami