Ten sam analityk, ten sam zestaw kompetencji, dwa projekty obok siebie. W jednym spędził dwa miesiące na pisaniu 200-stronicowej specyfikacji, zanim ktokolwiek napisał linię kodu. W drugim w poniedziałek opisał trzy user stories, we wtorek programiści zaczęli je budować, a w czwartek pacjent testował działającą funkcję. To nie był inny analityk. To była inna metodyka - i to ona, bardziej niż cokolwiek innego, decyduje o tym, jak wygląda dzień pracy BA.
Agile i Waterfall to dwa fundamentalnie różne podejścia do prowadzenia projektów, a wybór między nimi przebudowuje rolę analityka od podstaw: co dokumentuje, jak komunikuje, kiedy analizuje i jak reaguje na zmianę. Pracowałem w obu i w tym artykule pokażę Ci konkretnie, czym różni się praca analityka w każdym z nich, kiedy które podejście ma sens, jakie błędy popełniają analitycy przy przejściu z jednego do drugiego i jak to wygląda na realnym przykładzie wdrożenia rejestracji online.
Agile vs Waterfall - istota różnicy
Zanim zejdziemy do roli analityka, ustalmy fundament. Różnica nie polega na „dokumentacja vs brak dokumentacji" - to mit. Polega na momencie podejmowania decyzji o szczegółach.
W Waterfall (podejściu kaskadowym) definiujesz wszystkie wymagania na początku, w całości, zanim ruszy budowa. To jak budowa domu według kompletnego projektu architektonicznego: każdy etap musi się zakończyć, zanim zaczniesz następny. Analiza → projekt → implementacja → testy → wdrożenie, jeden raz, w tej kolejności.
W Agile definiujesz szczegóły „just in time" - tuż przed tym, jak będą potrzebne. Pracujesz w krótkich cyklach (sprintach), dostarczasz działające oprogramowanie kawałek po kawałku i na bieżąco reagujesz na informację zwrotną. Analiza nie jest etapem - jest ciągłą czynnością, która towarzyszy projektowi od początku do końca.
Stąd bierze się wszystko inne. Skoro w Waterfall decydujesz o wszystkim na starcie, dokumentacja musi być pełna i precyzyjna, a zmiana - kosztowna. Skoro w Agile decydujesz stopniowo, dokumentacja jest lżejsza, komunikacja bezpośrednia, a zmiana - wbudowana w proces.
Rola analityka w Waterfall: precyzja i dokumentacja
W podejściu kaskadowym rola analityka jest strategiczna i skoncentrowana na froncie projektu. Zanim cokolwiek powstanie, musisz dogłębnie zrozumieć potrzeby biznesowe i przełożyć je na kompletną dokumentację. Proces wygląda zazwyczaj tak:
- Zbieranie wymagań - seria wywiadów, warsztatów i analiza istniejącej dokumentacji. Pamiętam projekt systemu kredytów hipotecznych w banku: tygodnie rozmów z działami od sprzedaży po analizę ryzyka, żeby zrozumieć każdy niuans procesu kredytowego. W Waterfall nie ma drugiej szansy na „dopytamy później".
- Dokumentowanie - tworzysz szczegółową specyfikację wymagań (SRS): wszystkie funkcje, interfejsy, dane i ograniczenia. W dużych projektach to setki stron, które muszą być zrozumiałe i dla dewelopera, i dla klienta.
- Modelowanie - diagramy UML (przypadków użycia, klas, sekwencji) wizualizują architekturę i relacje w systemie.
- Walidacja - upewniasz się, że wymagania są kompletne, spójne i wykonalne, prezentujesz dokumentację klientowi i prosisz o formalne zatwierdzenie. To krytyczny moment: późniejsze zmiany są drogie. Jeśli projekt idzie V-Modelem, sekwencyjnym modelem, w którym testy projektuje się razem ze specyfikacją, do każdego wymagania od razu powstaje też scenariusz testu akceptacyjnego, więc wymaganie, którego nie da się sprawdzić, wychodzi już na tym etapie.
Wyzwania dla analityka w Waterfall: sztywność (zmiany trudne i kosztowne, więc musisz być bardzo dokładny na starcie), długi czas realizacji (od wymagań do wdrożenia mijają miesiące - musisz utrzymać zaangażowanie interesariuszy), oraz ryzyko, że klient nie do końca zrozumie obszerną dokumentację, co odbije się czkawką na końcu.
Rola analityka w Agile: elastyczność i współpraca
W Agile sytuacja jest odwrotna. Zamiast obszernej dokumentacji na froncie, skupiasz się na dostarczaniu wartości w każdej iteracji. Analityk pełni rolę przewodnika, który pomaga zespołowi rozumieć potrzeby biznesowe na bieżąco. Typowy rytm pracy:
- Wizja produktu - zaczynasz od ogólnego kierunku i celów biznesowych, bez zagłębiania się w szczegóły. Chodzi o zrozumienie, dokąd zmierzamy.
- Praca nad backlogiem - tworzysz i utrzymujesz backlog produktu, a podczas refinementu doprecyzowujesz poszczególne elementy i pomagasz szacować nakład. Backlog ewoluuje przez cały projekt.
- Planowanie sprintu - wybieracie z backlogu, co zbudujecie w najbliższym cyklu. Pomagasz zespołowi zrozumieć wymagania i ustalić priorytety.
- Codzienna współpraca - jesteś dostępny dla zespołu przez cały sprint, odpowiadasz na pytania, wyjaśniasz wątpliwości. Szybka komunikacja jest tu walutą.
- Demo i informacja zwrotna - na końcu sprintu prezentujecie działające oprogramowanie i zbieracie feedback, który zasila planowanie kolejnego cyklu.
Głównym narzędziem są user stories z kryteriami akceptacji, backlog uporządkowany według priorytetu, tablica Kanban i wykres burndown. Wyzwania: zmienność wymagań (musisz reagować szybko), brak obszernej dokumentacji (polegasz na komunikacji i bliskości zespołu) oraz wysokie tempo (sprinty trwają 2-4 tygodnie i w każdym musisz dostarczyć wartość).
Porównanie kompetencji analityka: Waterfall vs Agile
Wybór metodyki przesuwa to, które kompetencje są najważniejsze. W Waterfall liczy się precyzja i dokumentacja; w Agile - komunikacja i elastyczność.
| Kompetencja | Waterfall | Agile |
|---|---|---|
| Dokumentacja | Szczegółowa, obszerna, z góry | Lekka, skoncentrowana na user stories |
| Komunikacja | Formalna, pisemna | Nieformalna, bezpośrednia, ciągła |
| Elastyczność | Niska - zmiana jest kosztowna | Wysoka - zmiana jest wbudowana |
| Praca zespołowa | Mniej intensywna, etapowa | Najważniejsza - BA jest częścią zespołu |
| Analiza | Dogłębna, na froncie projektu | Ciągła, rozłożona w czasie |
| Reakcja na feedback | Trudna po zatwierdzeniu zakresu | Naturalna, co sprint |
Zwróć uwagę na słowo „mniej" przy pracy zespołowej w Waterfall - nie „nieważna". W obu podejściach umiejętność rozmowy z ludźmi jest fundamentem. Różni się intensywność i forma kontaktu, nie jego znaczenie.
Kiedy które podejście ma sens
To nie jest konkurs, w którym jedna metodyka „wygrywa". Każda pasuje do innego kontekstu.
Waterfall sprawdza się, gdy:
- Wymagania są stabilne i dobrze zrozumiane od początku (np. system rozliczeniowy zgodny ze sztywnymi przepisami).
- Projekt jest silnie regulowany i wymaga pełnej dokumentacji do audytu (bankowość, sektor publiczny, medycyna).
- Koszt zmiany jest obiektywnie wysoki - bo zaangażowani są dostawcy zewnętrzni, sprzęt albo długie umowy.
Agile sprawdza się, gdy:
- Wymagania są niepewne lub będą się zmieniać w trakcie (nowy produkt, którego rynek dopiero testuje).
- Liczy się szybkie dostarczenie wartości i uczenie się na bieżąco.
- Klient może i chce być zaangażowany regularnie, a nie tylko na starcie i końcu.
W praktyce wiele organizacji działa hybrydowo - np. analiza strategiczna i ramy zgodności robione „kaskadowo" na froncie, a sama budowa funkcji prowadzona zwinnie w sprintach. Dobry analityk nie jest fanatykiem jednej metodyki; dopasowuje warsztat do projektu.
Artefakty analityka - co produkujesz w każdej metodyce
Najkonkretniejsza różnica między metodykami to to, co fizycznie ląduje na Twoim dysku jako efekt pracy. Zestawmy artefakty obok siebie:
| Artefakt | Waterfall | Agile |
|---|---|---|
| Główny dokument wymagań | SRS (pełna specyfikacja, z góry) | Backlog z user stories (rośnie w czasie) |
| Opis pojedynczego wymagania | Wymaganie funkcjonalne z ID, sformalizowane | User story + kryteria akceptacji |
| Modele | Komplet diagramów UML na starcie | Lekkie diagramy „tyle, ile trzeba", just in time |
| Śledzenie | Pełna macierz śledzenia wymagań | Powiązania story-test w narzędziu (np. Jira) |
| Akceptacja zakresu | Formalny podpis pod specyfikacją | Demo na koniec sprintu + „Definition of Done" |
| Reakcja na zmianę | Sformalizowany change request | Nowy element backlogu, repriorytetyzacja |
Zwróć uwagę na ostatni wiersz - to esencja całej różnicy. W Waterfall zmiana to wyjątek wymagający procedury (change request, ocena wpływu, akceptacja). W Agile zmiana to norma: po prostu wkładasz nowy element do backlogu i ustawiasz priorytety. Sposób, w jaki obsługujesz zmianę wymagań, jest tym, co najbardziej różnicuje dzień pracy analityka w obu światach.
Jak płyną wymagania - dwa różne rytmy
Żeby zobaczyć różnicę namacalnie, prześledźmy losy jednego wymagania: „pacjent dostaje przypomnienie o wizycie".
W Waterfall to wymaganie pojawia się raz, na etapie analizy, w SRS jako REQ-027. Zostaje opisane kompletnie (kiedy, jakim kanałem, co przy braku numeru telefonu), zatwierdzone, zaprojektowane, zbudowane i przetestowane - w tej kolejności, miesiące od siebie. Jeśli w trakcie budowy klient stwierdzi, że chce też przypomnienie e-mailem, to change request: ocena wpływu, koszt, akceptacja, dopiero potem realizacja.
W Agile to wymaganie żyje jako user story w backlogu: „jako pacjent chcę dostać przypomnienie o wizycie, żeby o niej nie zapomnieć". Wisi tam, dopóki nie trafi do sprintu. Tuż przed budową doprecyzowujecie szczegóły na refinemencie, zespół buduje przypomnienie SMS-em w jednym sprincie, pokazuje na demo, a klient mówi „świetnie, dorzućmy e-mail" - i to po prostu kolejna story w backlogu, bez ceremonii. Wymaganie dojrzewa stopniowo, razem z produktem.
Ani jeden, ani drugi rytm nie jest z natury lepszy. Pierwszy daje przewidywalność i ślad audytowy. Drugi daje szybkość uczenia się. Twoja rola jako analityka to dostroić się do rytmu, w którym pracuje projekt - i nie próbować narzucać rytmu z poprzedniej pracy.
Hybryda w praktyce - najczęstszy realny scenariusz
W teorii istnieją „czysty Agile" i „czysty Waterfall". W praktyce większość projektów, które prowadziłem, była gdzieś pomiędzy - i to nie z lenistwa, tylko z rozsądku. Typowy układ hybrydowy:
- Front kaskadowy. Analiza strategiczna, ramy zgodności (np. RODO, wymogi regulacyjne) i architektura wysokiego poziomu robione są „z góry", bo zmiana fundamentów w trakcie jest droga niezależnie od metodyki.
- Budowa zwinna. Sama implementacja funkcji prowadzona jest w sprintach, z user stories i regularnym feedbackiem, bo to tu niepewność jest największa i chcesz się uczyć szybko.
Analityk w takim modelu nosi dwa kapelusze: na starcie pisze solidny dokument ram (zgodność, integracje, wymagania niefunkcjonalne), a potem przez resztę projektu pracuje zwinnie z backlogiem. To wymaga elastyczności i świadomości, kiedy który tryb włączyć. Najlepsi analitycy, jakich znam, nie pytają „Agile czy Waterfall?", tylko „która część tego projektu wymaga przewidywalności, a która szybkości uczenia się?".
Częste błędy przy przechodzeniu między metodykami
Najwięcej problemów widziałem nie u analityków pracujących w jednej metodyce, ale u tych, którzy przenoszą nawyki z jednej do drugiej, nie zmieniając podejścia.
- „Waterfall w przebraniu Agile". Analityk pisze 40-stronicowe user stories albo dostarcza zespołowi pełną specyfikację na cały kwartał z góry. Forma jest zwinna, myślenie kaskadowe. Efekt: traci się główną zaletę Agile - możliwość uczenia się i zmiany.
- Brak dokumentacji „bo to Agile". Druga skrajność. Agile nie znaczy „zero dokumentacji" - znaczy „tyle dokumentacji, ile potrzeba, i wtedy, gdy potrzeba". Decyzje architektoniczne, reguły biznesowe i kontrakty API warto utrwalić niezależnie od metodyki.
- Zamrożenie wymagań w Agile. Analityk traktuje user story jak podpisaną umowę i broni jej przed zmianą. To zaprzeczenie idei zwinności.
- Improwizacja w Waterfall. Odwrotnie - analityk liczy, że „doprecyzujemy później", podczas gdy w kaskadzie tego „później" praktycznie nie ma. Niedokończona analiza na froncie mści się na etapie wdrożenia.
- Ignorowanie kryteriów akceptacji. W obu podejściach to one definiują, kiedy wymaganie jest „zrobione". W Agile bywają lekceważone, bo „przecież pogadamy". Pogadać trzeba, ale spisane kryteria akceptacji ratują przed sporami przy odbiorze.
Mini-case: rejestracja online w MediFlow - dwa scenariusze
MediFlow, sieć 12 przychodni, chce wdrożyć rejestrację wizyt online. Pokażę, jak ten sam projekt wyglądałby w obu metodykach z perspektywy analityka.
Scenariusz Waterfall. Zarząd chce pełnej przewidywalności kosztu i terminu, bo część finansowania pochodzi z dofinansowania z twardym rozliczeniem. Analityk spędza sześć tygodni na zbieraniu wymagań od rejestratorek, pacjentów i kierowników, mapuje proces as-is i to-be, pisze SRS obejmujący integrację ze starym systemem, wymogi RODO dla danych medycznych i scenariusze brzegowe. Klient zatwierdza specyfikację. Zespół buduje przez cztery miesiące, potem testy akceptacyjne i wdrożenie we wszystkich przychodniach naraz. Zaleta: pełna kontrola zakresu i zgodności. Ryzyko: jeśli na etapie wdrożenia okaże się, że rejestratorki potrzebują czegoś innego, zmiana jest droga.
Scenariusz Agile. Zarząd akceptuje, że nie wie jeszcze dokładnie, czego pacjenci użyją. Analityk pisze pierwsze user stories dla najprostszej ścieżki: „jako pacjent chcę zobaczyć wolne terminy u mojego lekarza i zarezerwować jeden, żeby nie dzwonić rano na zajętą infolinię". Zespół buduje MVP w trzech sprintach i uruchamia go pilotażowo w jednej przychodni. Feedback: pacjenci masowo rezerwują, ale rejestratorki nie ufają systemowi i dublują wpisy ręcznie. To odkrycie - niewidoczne na żadnym slajdzie - staje się priorytetem kolejnego sprintu: powiadomienia i widok wspólnego kalendarza dla rejestracji. Po czterech miesiącach system jest w czterech przychodniach, dopracowany na podstawie realnego użycia.
Który scenariusz jest lepszy? Zależy od kontekstu. Przy twardym rozliczeniu dotacji i potrzebie pełnej dokumentacji RODO - Waterfall daje przewidywalność. Przy niepewności co do zachowań pacjentów - Agile pozwala uczyć się tanio i szybko. Najgorszy wybór to udawać jedno, robiąc drugie.
FAQ - Agile vs Waterfall z perspektywy analityka
Czy analityk biznesowy jest w ogóle potrzebny w Agile?
Tak. Agile nie eliminuje analizy - zmienia jej rytm. Analityk w zespole zwinnym dba o backlog, doprecyzowuje user stories, łączy zespół z biznesem i pilnuje, by budować właściwe rzeczy. Organizacje, które usunęły analityka „bo Agile", zwykle szybko tonęły w niejasnych wymaganiach i przeróbkach.
Czy w Agile pisze się dokumentację?
Tak, ale tyle, ile naprawdę potrzeba i wtedy, gdy potrzeba. User stories, kryteria akceptacji, decyzje architektoniczne, reguły biznesowe i kontrakty API warto utrwalić. Agile odrzuca dokumentację, która nie wnosi wartości - nie dokumentację jako taką.
Która metodyka jest popularniejsza na polskim rynku pracy?
Zdecydowana większość ofert dla analityków wymaga dziś doświadczenia w Agile (najczęściej Scrum). Waterfall i podejścia hybrydowe wciąż dominują w sektorze publicznym, bankowości i dużych projektach regulowanych. W praktyce warto znać oba.
Czy mogę być dobrym analitykiem, znając tylko jedną metodykę?
Na start - tak. Ale sufit szybko się obniża. Najlepsi analitycy potrafią dopasować podejście do projektu, a nie odwrotnie. Znajomość obu metodyk to przewaga, bo realne projekty rzadko są czysto kaskadowe albo czysto zwinne.
Czym różni się rola analityka od Product Ownera w Agile?
To pokrewne, czasem nakładające się role. Product Owner odpowiada za priorytety i wartość produktu, analityk za zrozumienie i opisanie wymagań. W mniejszych zespołach jedna osoba pełni obie funkcje. Różnice rozkładam w artykule o analityku vs Product Ownerze.
Podsumowanie
Agile i Waterfall to nie wybór między „lepszym" a „gorszym", tylko między dwoma sposobami radzenia sobie z niepewnością. Waterfall mówi: zrozummy wszystko z góry i trzymajmy się planu. Agile mówi: zacznijmy mały, uczmy się i dostosowujmy. Rola analityka zmienia się wraz z metodyką - w jednej jesteś autorem precyzyjnej specyfikacji, w drugiej stałym przewodnikiem zespołu - ale rdzeń pozostaje ten sam: zrozumieć potrzebę biznesową i pomóc dostarczyć rozwiązanie, które ma sens.
Niezależnie od metodyki, na końcu zawsze są ludzie: ich zaangażowanie, wiedza i umiejętność współpracy. Technika to tylko rama. Jeśli chcesz przećwiczyć pracę analityka w obu podejściach na realnych projektach, znajdziesz to w szkoleniach Analify - a swój warsztat sprawdzisz w testach z metodyk i analizy biznesowej.