Kada počnete pripremati ozbiljan projekt, jedna od prvih ključnih odluka je odabir metodologije upravljanja koju ćete slijediti. To nije mali detalj: planiranje, način rada s klijentom, dokumentacija, rokovi, pa čak i vrste pogrešaka na koje ćete naići putem, sve ovisi o tom izboru.
Unutar ovog raspona, Waterfall metodologija ostaje jedna od najpoznatijih. Iako se o Agileu, Scrumu i Kanbanu široko raspravlja, Waterfall je i dalje vrlo živ u sektorima gdje su stabilnost, predvidljivost i sveobuhvatna dokumentacija važniji od apsolutne fleksibilnosti. U ovom sveobuhvatnom vodiču korak po korak objašnjavam što je Waterfall, odakle dolazi, kako je strukturiran, kada ga ima smisla koristiti, kako se razlikuje od Agilea i kako se uklapa u moderno upravljanje projektima.
Što je metodologija vodopada?
Metodologija vodopada je linearni i sekvencijalni model razvoja u kojem projekt napreduje fazu po fazu, bez sustavnih zastoja. Naziv "vodopad" dolazi upravo od ove slike: svaka faza prelijeva svoje rezultate u sljedeću, poput vode koja pada s jedne stepenice na drugu, i nakon što se spustite za jednu stepenicu, vrlo je teško vratiti se gore.
U praksi to znači da se životni ciklus projekta završava samo jednom, od početka do kraja : prvo se prikupljaju svi zahtjevi; zatim se rješenje dizajnira; potom se ono implementira, provjerava i konačno pušta u rad i održava. Svaka faza mora biti u potpunosti dovršena i odobrena prije početka sljedeće, s formalnim rezultatima i dobro definiranim kriterijima za izlaz.
Ovaj pristup temelji se na vrlo jasnoj pretpostavci: projektni zahtjevi mogu se unaprijed znati i dokumentirati s dovoljnom preciznošću da se uspostavi relativno nepromjenjiva osnova. Ova osnova vodi sav dizajn, razvoj i provjeru, a sve naknadne izmjene tretiraju se kao iznimne, skupe promjene podložne formalnoj kontroli.
Podrijetlo i evolucija modela vodopada
Ideja organiziranja rada u sekvencijalne faze nije nastala u softveru. Dolazi iz tradicionalnih inženjerskih sektora poput građevinarstva, niskogradnje i teške industrije, gdje iteriranje na gotovom proizvodu može biti nepraktično ili izuzetno opasno. Ako gradite most ili branu, morate biti apsolutno jasni oko toga što ćete učiniti prije polaganja prve cigle.
U području razvoja softvera, jedan od ranih primjera datira iz lipnja 1956., kada je Herbert D. Benington predstavio fazni model za velike sustave. Međutim, opis modela vodopada koji se smatra klasičnim pripisuje se Winstonu W. Royceu u članku iz 1970. o upravljanju velikim projektima razvoja softvera. Godinama kasnije, 1976., Bell i Thayer popularizirali su pojam "vodopad" i naveli Roycea kao referencu.
Zanimljivo je da je sam Royce upozoravao da je strogo sekvencijalni model, bez ikakve povratne informacije, rizičan. Predložio je uključivanje iteracija između susjednih faza i prototipova kako bi se smanjio taj rizik. S vremenom se u industriji ukorijenila pojednostavljena, gotovo kruta verzija, gdje je svaka faza bila u potpunosti dovršena prije prelaska na sljedeću, te se tako učvrstio stereotip koji svi danas povezujemo s modelom vodopada.
Zahvaljujući jasnoj logici i jednostavnosti planiranja , Waterfall je brzo prihvaćen ne samo u softveru, već i u sektorima poput građevinarstva, inženjerstva ili bilo kojeg reguliranog okruženja gdje je opseg dobro definiran i postoji mala tolerancija za improvizaciju.
Kako funkcionira metodologija vodopada
U projektu kojim se upravlja korištenjem vodopadnog pristupa, faze slijede jedna drugu vrlo strogo linearnim redoslijedom. Faza ne počinje dok se prethodna ne završi i teoretski nema povratka osim ako se ne pojavi vrlo ozbiljan problem ili ne dođe do promjene ugovora.
U svojoj najklasičnijoj verziji, životni ciklus Waterfalla sastoji se od pet, šest ili čak sedam faza. Razlika obično leži u tome jesu li implementacija i održavanje odvojeni ili grupirani zajedno, ali temeljna logika je ista: napredovati bez preklapajućih faza i s formalnim rezultatima u svakom koraku.
Faze metodologije vodopada
Kako bismo u potpunosti razumjeli Waterfall, vrijedi pažljivo pregledati svaku od njegovih faza. One nisu izolirani odjeljci, već djeluju kao karike u lancu gdje izlaz jedne faze utječe na ulaz sljedeće.
1. Zahtjevi
Faza zahtjeva je srž svakog projekta vodopada. Ovdje je cilj obuhvatiti sve potrebe i ograničenja klijenta i poslovanja, i funkcionalna (što sustav mora raditi) i nefunkcionalna (performanse, sigurnost, propisi itd.).
Ova faza uključuje intervjue, radionice i analize s korisnicima i stručnjacima iz domene kako bi se osiguralo da se ništa ne previdi. Rezultat je vrlo detaljan dokument sa specifikacijom zahtjeva koji pregledavaju i potpisuju sve strane . Ovaj dokument postaje ugovorna i tehnička osnova koja će upravljati ostatkom projekta.
U klasičnom pristupu Waterfall, klijent je prvenstveno uključen u ovu početnu fazu . Nakon toga, njihova uključenost se dramatično smanjuje sve do faze validacije ili prihvaćanja. Zato je toliko važno da prikupljanje zahtjeva bude što temeljitije i jasnije: svi propusti ili nejasnoće bit će pojačani u sljedećim fazama i bit će vrlo skupo ispraviti ih.
2. analiza
Nakon što su utvrđeni zahtjevi, tim ulazi u fazu analize u kojoj se proučava tehnička i funkcionalna izvedivost svega što se traži. Izrađuje se konceptualni model sustava, identificiraju se ovisnosti, razjašnjavaju se složena poslovna pravila i postavljaju se temelji za naknadni dizajn.
Ova faza omogućuje prevođenje poslovnog jezika u tehničkiji jezik, bez dosezanja razine arhitektonskih detalja. U mnogim projektima, analiza i zahtjevi se vremenski preklapaju, ali u modelima vodopada obično su predstavljeni kao zasebna faza s vlastitim rezultatima.
3. Dizajn ili koncepcija
Faza dizajna transformira "što" u "kako". Polazeći od utvrđenih zahtjeva, tim za arhitekturu i dizajn definira cjelovitu strukturu rješenja . U softveru se to često dijeli na dizajn visoke razine (arhitektura, moduli, sučelja, tehnologije) i detaljni dizajn (algoritmi, baze podataka, sheme sučelja itd.).
U drugim sektorima, ova faza je ekvivalentna građevinskim planovima, strukturnim izračunima, električnim shemama ili popisima materijala. Cilj je da naknadna implementacija bude, u biti, vjeran prijevod dizajna , bez potrebe za ponovnim tumačenjem zahtjeva.
U složenim projektima, plan projekta i ovisnosti odražavaju se u alatima poput Ganttovog dijagrama i drugih alata za upravljanje vremenom , koji se vrlo dobro uklapaju u sekvencijalni način razmišljanja vodopada: ulančani zadaci, vrlo jasne prekretnice i dobro definiran raspored isporuke.
4. Implementacija ili razvoj
Nakon što je dizajn završen, počinje faza implementacije. Ovdje se razvojni, konstrukcijski ili integracijski tim usredotočuje na izgradnju proizvoda točno onako kako je dizajniran . U softveru, na primjer, ovo je vrijeme za pisanje koda, konfiguriranje sustava, postavljanje infrastrukture i tako dalje.
Paradoksalno, u mnogim vodopadnim projektima ova je faza kraća od faze zahtjeva i dizajna jer je velik dio truda već uložen u planiranje i dokumentaciju . Ideja je smanjiti improvizaciju: ključne odluke su već donesene, a sada je vrijeme za izvršenje.
Iako mogu postojati interni pregledi i jedinična testiranja, tradicionalna metodologija Waterfall zadržava formalnu verifikaciju za sljedeću fazu, nakon što je cijeli sustav integriran.
5. Verifikacija, testiranje i validacija
Nakon što je sustav izgrađen, vrijeme je za provjeru radi li on zapravo ono što bi trebao. Ovdje je važno razlikovati verifikaciju i validaciju , dva koncepta koja se prilično rigorozno tretiraju u kaskadi.
Verifikacija uključuje osiguravanje da je proizvod ispravno izgrađen: sustav se uspoređuje sa specifikacijama dizajna, a provode se jedinični, integracijski i sistemski testovi kako bi se pronašle tehničke pogreške. Kada su uključeni API-ji, koriste se alati poput Postmanovog vodiča za testiranje API-ja . Odgovor je: "Jesmo li izgradili sustav prema dizajnu?"
Validacija se, s druge strane, usredotočuje na provjeru ispravnosti proizvoda : zadovoljava li korisnikove zahtjeve i potrebe kako je prvobitno definirano. Odgovara na pitanje: "Rješava li ovaj sustav zaista poslovni problem?"
U ovoj fazi provodi se testiranje prihvatljivosti s klijentom. Ako se otkriju pogreške, one se ispravljaju; ako se pojave odstupanja od očekivanja klijenta, dio posla možda će trebati ponoviti. Budući da se ovi problemi otkrivaju kasno, trošak ispravljanja obično je visok i u vremenu i u novcu , što je jedan od glavnih nedostataka modela vodopada u promjenjivim okruženjima.
6. Implementacija ili pokretanje
Nakon što su završeni formalni testovi i prihvaćanje od strane kupca, proizvod prelazi na implementaciju ili produkciju . U softveru to može uključivati instaliranje sustava u konačna okruženja, migraciju podataka, obuku korisnika i integraciju novog sustava s postojećima, za što je korisno poznavanje upravljanja API-jima.
U drugim sektorima, označava trenutak kada se objekt svečano otvara, industrijski pogon predaje ili infrastruktura pušta u rad. Na kaskadni način, ova prekretnica označava kraj razvojnog projekta i početak faze održavanja.
7. Održavanje
Nakon pokretanja započinje faza održavanja, koja je u mnogim slučajevima najduža u životnom ciklusu . Ova faza uključuje ispravljanje pogrešaka koje su se uvukle, prilagođavanje sustava specifičnim promjenama u okruženju (propisi, vanjski sustavi, hardver) i manja poboljšanja.
U čistoj filozofiji vodopada, velike promjene koje značajno utječu na arhitekturu ili zahtjeve obično se pristupaju kao novi vodopadni projekti, s vlastitim ciklusom zahtjeva, dizajna, implementacije i validacije. Dokumentacija generirana u prethodnim fazama postaje spas za tim za podršku, koji možda nije isti tim koji je dizajnirao izvorni sustav.
Središnja uloga dokumentacije u Waterfallu
Ako postoji jedna stvar koja definira metodologiju vodopada, osim slijeda faza, to je važnost dokumentacije kao okosnice projekta. Svaka faza generira formalne rezultate koji podliježu pregledu i odobrenju: specifikacije zahtjeva, nacrti, planovi testiranja, izvješća o provjeri, operativni priručnici itd.
Ova dokumentacija nije birokratski hir; u mnogim sektorima to je regulatorni ili ugovorni zahtjev . Omogućuje vam da pokažete što je dogovoreno, kako je dizajnirano, kako je implementirano i kako je sve provjereno. Nadalje, olakšava potpunu sljedivost od zahtjeva do koda koji ga implementira i testa koji ga validira.
Plan projekta i osnovni podaci
Plan projekta u Waterfall okruženju je pravi plan . Definira opseg, detaljan raspored, resurse, prekretnice, rizike i kriterije prihvaćanja za svaku fazu. Obično je predstavljen vrlo detaljnim Ganttovim dijagramima i rasporedom formalnih pregleda na kraju svake faze.
Nakon odobrenja, plan se zamrzava kao osnova. Sva značajna odstupanja (u opsegu, troškovima ili rasporedu) upravljaju se putem zahtjeva za promjenama i kontrolnih procesa , koje obično pregledava projektni odbor. Ova rigidnost pruža visok stupanj predvidljivosti, što se visoko cijeni kod ugovora s fiksnom cijenom ili programa s kaznama za kašnjenja.
Specifikacija zahtjeva kao ključni dokument
Među svom dokumentacijom, specifikacija zahtjeva obično je dokument s najvećom ugovornom težinom . Ona opisuje što sustav mora raditi, pod kojim ograničenjima, na kojoj razini kvalitete i kako mora komunicirati s drugim elementima.
U kaskadnom pristupu, ova faza obično troši između 20% i 30% ukupnog napora projekta. To se može činiti puno, ali kada je cijena pogreške visoka, jeftinije je uložiti vrijeme u razjašnjavanje željenog ishoda nego na kraju ponovno izgraditi pola sustava.
Sljedivost i zapisi ispitivanja
Još jedna tipična značajka Waterfalla je korištenje matrica sljedivosti, koje povezuju svaki zahtjev s elementima dizajna koji ga implementiraju i testnim slučajevima koji ga provjeravaju . Održavanje ovih matrica zahtijeva disciplinu, ali su neprocjenjive u revizijama i certifikacijama.
Planovi testiranja, skripte, rezultati i izvješća o pregledu čine skup dokaza koji pokazuju da je sustav sustavno testiran . U sektorima kao što su farmaceutska industrija, zrakoplovstvo i željeznica, ovi su zapisi obvezni i moraju se čuvati godinama.
Dokumentacija da, birokracija ne
Uobičajena kritika modela vodopada je da generira hrpu papirologije koju nitko ne čita. I ponekad je to istina, nemojmo se zavaravati. Zato je važno razlikovati dokumentaciju koja dodaje vrijednost (onu koja pomaže u razumijevanju odluka, dokazivanju usklađenosti ili održavanju sustava) i birokraciju koja služi samo za ispunjavanje obrazaca.
Voditelj projekta vodopada mora imati razboritost kako bi eliminirao nepotrebne informacije i usredotočio se na dokumente koji odgovaraju na ključna pitanja: tko je što tražio , zašto je tako dizajnirano i kako je provjerena njegova funkcionalnost. Ako dokument ne pomaže u odgovoru na bilo koje od ovih pitanja ili nije potreban za prolazak revizije, vjerojatno je suvišan.
Prednosti metodologije vodopada
Vodopad nije lijek za sve, ali u pravim kontekstima ima niz prednosti koje je teško usporediti. Ovo su najznačajnije.
Prvo, nudi jasnu, logičnu i visoko organiziranu strukturu . Projekt se dovršava sekvencijalno, s fazama koje se ne preklapaju i dobro definiranim ključnim događajima. To uvelike olakšava raspodjelu resursa i praćenje napretka, jer je uvijek jasno u kojoj se fazi nalazite.
Drugo, omogućuje vrlo precizno planiranje i procjenu kada su zahtjevi stabilni. Budući da je sve definirano prije početka, lakše je izračunati troškove, vremenske rokove i potrebe za osobljem. To je idealno za ugovore s fiksnom cijenom, javne natječaje i projekte gdje klijent od početka mora znati koliko će platiti i kada će dobiti rezultat.
Treće, model vodopada generira sveobuhvatnu dokumentaciju i potpunu sljedivost . Svaka faza ostavlja trag pregledanih i odobrenih rezultata, što je vrlo cijenjeno u reguliranim i kritičnim okruženjima gdje nedostatak dokumentacije može predstavljati pravne ili sigurnosne rizike.
Nadalje, s tako jasno definiranim fazama, lakše je mjeriti napredak projekta i izvještavati o njemu upravi. Tehnike poput zarađene vrijednosti mogu se koristiti i prilično objektivno uspoređivati s početnom linijom.
Konačno, nekim klijentima je praktično što nakon početne faze zahtjeva ne moraju biti kontinuirano uključeni . U Waterfallu, njihovo sudjelovanje je obično koncentrirano na početku (kako bi se definiralo što žele) i na kraju (kako bi se potvrdilo što je isporučeno). Za organizacije s ograničenim vremenom ili bez kulture kontinuirane suradnje, ovo može biti prednost.
Ograničenja i rizici pristupa vodopada
Nedostatak svega navedenog je što model vodopada uvelike pati kada kontekst zahtijeva fleksibilnost i prilagodbu promjenama . Njegovi glavni nedostaci su dobro poznati.
Najočitiji nedostatak je nedostatak fleksibilnosti . Zamrzavanje zahtjeva na početku i kretanje naprijed bez osvrtanja unatrag vrlo otežava uvođenje razumnih promjena usred projekta. Svaka značajna prilagodba može dovesti do modifikacija dizajna, ponovne implementacije i ponovljenog testiranja, što rezultira utjecajem na vrijeme i proračun.
Drugi problem je odgođena isporuka vrijednosti . U modelu vodopada, kupac ne vidi funkcionalan proizvod do završnih faza. Ako, kada dođu do te točke, otkriju da ono što je isporučeno ne odgovara njihovim stvarnim potrebama (jer se kontekst promijenio, pojavili su se novi konkurenti ili su se pojavile bolje ideje), malo se može učiniti bez značajnog vraćanja unatrag.
Također postoji jaka ovisnost o kvaliteti početnih zahtjeva . Ako klijent nije jasan što želi ili ako tim ne uspije to učinkovito uhvatiti, model vodopada postaje skupa zamka: puno se ulaže u planiranje nečega što se zatim mora poništiti.
To je pogoršano nedostatkom kontinuirane povratne informacije . Budući da je uključenost klijenta ograničena tijekom razvoja, gube se mogućnosti prilagodbe rješenja u hodu i ranog otkrivanja problema s upotrebljivošću ili poslovnom usklađenošću.
Konačno, kada se koristi izvan konteksta, model vodopada može stvoriti lažni osjećaj kontrole . Prekrasan Ganttov dijagram i hrpe odobrenih dokumenata ne jamče da će se sustav dobro integrirati ili raditi kako se očekuje. Mnogi problemi pojavljuju se tek na kraju, kada je njihovo rješavanje skuplje.
Vodopad u razvoju softvera
U svijetu softvera, Waterfall je godinama bio dominantan model , posebno u velikim sustavima za vladu, obranu, bankarstvo i telekomunikacije. Slijed "zahtjevi-dizajn-kod-testiranje-održavanje" odgovarao je inženjerskom načinu razmišljanja tog vremena.
S vremenom je postalo jasno da se zahtjevi za većinu digitalnih proizvoda stalno mijenjaju . Tržište se brzo kreće, tehnologija se neprestano razvija, a korisnici otkrivaju što zaista žele tek kada počnu koristiti nešto određeno. U takvom okruženju, otkrivanje konceptualne pogreške u završnoj fazi testiranja znači bacanje puno posla.
Zato je većina softverskih timova orijentiranih na proizvode usvojila agilne i iterativne pristupe (Scrum, Kanban, Lean itd.), koji omogućuju česta povećanja, validaciju poslovnih hipoteza i brzo prilagođavanje kursa.
Unatoč tome, model vodopada i dalje ima svoje mjesto u softveru kada je opseg vrlo ograničen, a stabilnost prioritet: sustavi kritični za misiju (medicinski, vojni, zrakoplovni), integracije sa zatvorenim ugovorima, razvoj za visoko regulirana okruženja ili migracije vrlo starih sustava gdje su poslovna pravila savršeno dokumentirana.
Kada ima smisla koristiti metodologiju vodopada?
Izbor između Waterfalla i Agilea nije stvar trendova, već konteksta. Postoje situacije u kojima je Waterfall vrlo razuman izbor i druge u kojima je to čisto metodološko samoubojstvo.
Projekti sa stabilnim i dobro poznatim zahtjevima
Idealni scenarij za Waterfall je onaj u kojem su zahtjevi jasni, potpuni i malo je vjerojatno da će se promijeniti . Na primjer, migracija naslijeđenog sustava na novu platformu uz zadržavanje iste funkcionalnosti, repliciranje provjerenog industrijskog postrojenja na drugoj lokaciji ili implementacija ERP-a s opsegom definiranim ugovorom.
U tim slučajevima, organizacija obično ima vrlo dobro razumijevanje domene i rizika. Model vodopada im omogućuje da iskoriste to iskustvo, detaljno planiraju i optimiziraju korištenje resursa uz vrlo malo iznenađenja.
Regulirana i vrlo kritična okruženja
Zrakoplovstvo, željeznica, nuklearna energija, medicinski uređaji… To su sektori u kojima su apsolutna sljedivost i sveobuhvatna dokumentacija obvezni. Regulatorne agencije zahtijevaju pristup sekvencijalnim planovima, pregledima dizajna, zapisima o ispitivanju i potpunom opravdanju za svaku tehničku odluku.
U tim domenama, lagana dokumentacija i stalno eksperimentiranje s nekim agilnim pristupima nisu u skladu sa zahtjevima za certifikaciju. Metodologija vodopada pruža potreban dokumentacijski okvir za prolazak formalnih revizija i regulatornih validacijskih koraka.
Ugovori s fiksnom cijenom i outsourcing
Kada dobavljač potpiše ugovor s fiksnom cijenom, mora smanjiti neizvjesnosti. Model vodopada dobro se uklapa u to jer se opseg pregovara, dokumentira i zamrzava prije nego što se preuzme bilo kakva obveza. Sve naknadne promjene imaju svoj formalni postupak i obično su povezane s ponovnim pregovaranjem o troškovima i rokovima.
U outsourcing projektima gdje su timovi raspršeni, a neformalna komunikacija ograničena, model vodopada smanjuje dvosmislenost zamjenjujući stalne razgovore detaljnim specifikacijama.
Organizacijska kultura s malom tolerancijom na neizvjesnost
Postoje visoko hijerarhijske organizacije s fiksnim godišnjim proračunima i opsesijom predvidljivošću. U tim okruženjima, pokušaj implementacije Agile-a po pravilima često rezultira "čudnim hibridom" gdje nijedan model ne koristi njegove prednosti.
Model vodopada najbolje odgovara strukturama gdje se od samog početka cijeni čvrst plan, s linearnim izvješćima o napretku i formalnim pregledima. Ovdje voditelj projekta djeluje kao čuvar osnovne linije , a ne kao posrednik u iteracijama.
Integracija više dobavljača i velikih programa
U velikim projektima s više izvođača (npr. automobilska industrija, brodogradnja ili velika infrastruktura), model vodopada služi kao zajednički jezik za koordinaciju sučelja . Svaki dobavljač razvija svoj podsustav prema fiksnim specifikacijama sučelja, a testiranje integracije planira se znatno unaprijed.
Kad bi svaki tim radio s promjenjivim prioritetima i neovisnim sprintovima bez sveobuhvatnog okvira, integracija bi bila kaotična. Sekvencijalni pristup olakšava definiranje jasnih točaka integracije i bolju kontrolu lanca opskrbe.
Kada nije dobra ideja primijeniti Waterfall?
Jednako važno kao i znati gdje vodopad sija, važno je prepoznati situacije u kojima ga je najbolje bez oklijevanja odbaciti . Neki tipični scenariji:
Kada klijent ne zna točno što mu treba i očekuje se da uči metodom pokušaja i pogrešaka, forsiranje sekvencijalnog modela dovest će samo do frustracije i prekoračenja troškova. Mnogo vremena će se potrošiti na dokumentiranje nečega što će se uskoro promijeniti.
Ako se tržište mijenja tjednima ili mjesecima (startupovi, inovativni digitalni proizvodi, projekti korisničkog iskustva), čekanje do kraja validacije rješenja je nepromišljeno. U tim slučajevima, prikladniji su iterativni i inkrementalni pristupi koji omogućuju pilotiranje, mjerenje i prilagodbu.
Nadalje, ako su rokovi toliko agresivni da ne dopuštaju rigoroznu fazu zahtjeva, pokušaj praćenja modela vodopada neizbježno vodi do verzije modela vodopada bez stvarnih kontrola , gdje se dokumentacija žurno obrađuje samo da bi se "označilo polje". To je najgore od oba svijeta.
Agilni vs. vodopadni pristup: Ključne razlike
Usporedba između Waterfalla i Agilea pojavljuje se u gotovo svakoj raspravi o upravljanju projektima. Oni nisu sami po sebi dobri ili loši; oni jednostavno odražavaju različite filozofije.
Waterfall predlaže linearni i sekvencijalni pristup: prvo se sve definira, zatim dizajnira, implementira, testira i isporučuje. Agile, s druge strane, dijeli rad na kratke, iterativne cikluse (sprintove) gdje se u svakoj iteraciji planira, dizajnira, razvija i testira mali skup funkcionalnosti.
U vodopadnom pristupu, opseg je fiksan na početku, a promjene su skupe iznimke. U agilnom pristupu, promjena se pretpostavlja kao norma, a proizvod se razvija sprint po sprint , prilagođavajući zaostatak na temelju povratnih informacija korisnika i poslovanja.
Što se tiče uključenosti kupaca, Waterfall usmjerava svoje sudjelovanje na početak i kraj projekta. Agile ga distribuira kroz cijeli životni ciklus, s čestim pregledima i potencijalno isporučivim proizvodom na kraju svakog sprinta.
Što se tiče vremena potrebnog za izlazak na tržište, projekti vodopada obično donose vrijednost na kraju procesa. Agile omogućuje izdavanje ranih verzija (MVP-ova) koje se s vremenom usavršavaju.
U praksi se mnoge organizacije odlučuju za hibridne pristupe , kao što je dobro poznati "Water-Scrum-Fall": planiranje i opći dizajn u vodopadnom načinu rada, dnevni razvoj sa Scrumom i implementacija/isporuka ponovno pod prediktivnijim kišobranom.
Uloga voditelja projekta u Waterfallu
Voditelj projekta u vodopadnom okruženju ima drugačiju ulogu od Scrum Mastera ili Agile Coacha. Ovdje se od njega očekuje da bude pedantan planer i kontrolor napretka , a ne voditelj samoorganizirajućih timova.
Ključne odgovornosti uključuju održavanje osnovne linije projekta, koordinaciju faznih pregleda, upravljanje rizicima, kontrolu promjena, osiguravanje poštivanja rokova i proračuna te komuniciranje statusa projekta upravi putem formalnih izvješća. Na velikim projektima ova uloga obično uključuje blisku suradnju s tehničkim voditeljem kako bi se jamčila kvaliteta dizajnerskih i arhitektonskih odluka.
Za one koji se žele specijalizirati za ovu vrstu upravljanja, certifikati poput PMP-a od PMI-ja ili specifični standardi reguliranih sektora (na primjer, DO-178C u zrakoplovstvu) jačaju upravo te vještine usmjerene na prediktivne i snažno dokumentirane životne cikluse.
Hibridne metodologije i koegzistencija s agilnim pristupima
Stvarnost je takva da danas gotovo nijedan ozbiljan projekt nije 100% vodopadni ili 100% agilan. Uobičajeno je pronaći kombinacije gdje vodopad djeluje kao ugovorni kišobran , dok se iterativni ciklusi primjenjuju interno kako bi se smanjio rizik u određenim područjima.
Na primjer, cjelokupna arhitektura i sučelja mogu se definirati korištenjem metodologije vodopada, ali određeni podsustavi mogu se razviti kratkim iteracijama i izradom prototipa . Sve dok se poštuju sučelja i prekretnice integracije, ova kombinacija može funkcionirati vrlo dobro.
Nešto slično se događa u procesima digitalne transformacije: organizacija može migrirati svoju transakcijsku jezgru (stabilnu i reguliranu) koristeći Waterfall, dok istovremeno razvija front-end aplikacije za krajnjeg korisnika s agilnim timovima. Daleko od toga da je kontradiktorno, to je pametan način dodjeljivanja pravog alata svakom problemu.
Također postoje prijelazi s Waterfall na Agile gdje upravljanje timskim resursima i vještinama zahtijeva značajnu kulturnu promjenu . Početak s agilnim pristupima na malim projektima omogućuje timovima da se naviknu na dinamično planiranje i kontinuirane povratne informacije bez ugrožavanja kritičnih programa.
Ukratko, metodologija Waterfall ostaje vrlo relevantan alat u upravljanju projektima, pod uvjetom da se njezine snage - predvidljivost, struktura i sljedivost - u potpunosti razumiju . Kada se primjenjuje na domene sa stabilnim zahtjevima, strogim propisima ili ugovorima s fiksnom cijenom, može biti najsigurnija i najučinkovitija opcija, posebno u kombinaciji s razumnim razinama iteracije i zdravim razumom.
