Water-Agile-Fall, nova metodologija ili stara stvar

Kao profesionalnog voditelja projekta, uvijek me ljutila – zadrtost. Ljudi se u projektima uhvate jedne stvari, fraze, postupka i onda ju okolo zagovaraju kao da je sveta, nedodirljiva stvar. I o njoj nema rasprave.

E pa ima! Zašto je zadrtost u primjeni bilo čega na projektima jednostavno – KRIVA! Pa definicija projekta je: „Projekt je privremen pothvat poduzet radi kreiranja jedinstvenog proizvoda, rezultata ili usluge“. Ako je projekt jedinstven (a je), onda je logično da se pristup svakom projektu može i mora modificirati.

Vrlo pametni ljudi su opisivali vođenje projekata tzv. Waterfall metodologijom kao nešto što je loše i nadmašeno. Kako bi onda rekli da je „ono pravo“ jedno i jedino – agilno. Bez diskusije. Čak se ide tako daleko da se za propast svakog projekta u IT industriji smatra neprimjenjivanje agilnih pristupa, a ako se i primjenjivao agilni pristup, onda se nije primjenjivao kako treba. Hahahaha. To je jedini komentar. Od kad je primjena metodologije jamac uspjeha? Kad bi to bilo tako, tko bi bio toliko lud ugroziti projekt primjenom krive metodologije?

Waterfall metodologija je opisana u mnogim knjigama kao loša zbog toga jer se slijede faze: iniciranje, planiranje, izvršenje (razvoj), testiranje i produkcija. Dakle tek kad je gotov kompletan plan (a, pazi sad, plan radi isključivo voditelj projekta i on vrši procjene koliko vremena treba za koju aktivnost, bez konzultacije s onim tko će tu aktivnost izvršiti??), predaje se developerima u izvedbu, kodiranje ili što već treba napraviti. Tek kad je sve gotovo (????) ide se u testiranje i onda u produkciju. Naručitelj dobiva ono što je zapisano u planu projekta tek na kraju projekta i svaka izmjena praktički znači, sve iz početka. Čitajući nekoliko knjiga s takvim opisom, nisam mogao vjerovati.

Ja sam vodio vrlo mnogo projekata waterfall metodologijom i nikad, ali nikad nisam tako radio. Uvijek je cijelo vrijeme bio naručitelj bio uključen u projekt i sve se odmah testiralo i naručitelj je odmah mogao davati svoje sugestije i komentare. Pokušao sam naći poveznicu u tim knjigama. I našao sam! Zove se Sjedinjene Američke Države. Sve su knjige pisali autori iz SAD! Ako se pod waterfall metodologijom smatra takav opis (iz knjiga), onda je sve bolje nego to! Ali baš sve. I kad se krene s tom permisom, normalno da je agilno rješenje, ono pravo.

Agilni pristup znači kratkoročno planiranje (dakle cijeli opseg nije odmah definiran), a naručitelj je uključen u razvoj cijelo vrijeme i može mijenjati mišljenje bilo kada. To je super! Genijalno! Sjećate se popularnog Malog mista? I uzrečice: ‘Judi ‘ko more ovo platit??’ Što kad imate fiksan budžet i fiksan rok, kakvi su mnogi projekti, ne samo kod nas nego i u svijetu. Što kad dobijete zahtjev za nekim novim, na primjer, softverom, u kojem morate jasno reći što ćete isporučiti i u kojem vremenu i za koliko novaca? E tada slijedi kombiniranje. Dakle, tada slijedi nova metodologija, o kojoj bruji Internet zadnjih mjeseci, a koja je zapravo – stara stvar. Zove se water-agile-fall. Što je to?

wsf

To je metodologija u kojoj su funkcionalnosti jasno definirane i njihova cijena i rok. Svaka promjena se provodi kroz unaprijed zadanu proceduru, poznatu kao i „upravljanje promjenama“, gdje se za svaku novu funkcionalnost automatski procjenjuje vrijeme i novac, pa i krajnji rok projekta. OK! To je naslijeđe waterfalla. Gdje je tu agilno? Pa agilno je u tome da se raspored aktivnosti (funkcionalnosti) radi u malim intervalima i naručitelju se isporučuje softver dio po dio. Naručitelj može mijenjati svoje mišljenje, dapače, ovisno o tome što želi tijekom projekta, ali ako ta promjena zahtjeva još vremena i novaca (a traži, budimo iskreni), naručitelj to plaća. Dakle, kombinacija najbolje od obje metodologije. E sad. U agilnim metodologijama nema, ono što u water-agile-fall ima, a to je voditelj projekta.

Kad se posao ugovara naručitelj želi znati tko je odgovorna osoba. Imenom i prezimenom, da budemo precizni. Odgovor tipa: „Cijeli tim je odgovoran!“, kao osnovni postulat agilnih metodologija, jednostavno – ne prolazi, ili u najmanju ruku, vrlo rijetko prolazi. Voditelj projekta se ne miješa (i ne smije se miješati, bez obzira na metodologiju) u posao izvoditelja (developera). On ne zna razviti softver i to nije njegov posao. Ali voditelj projekta je nadležan da se poštuju rokovi, da se isporučuju dogovorene funkcionalnosti i slijedu kako su dogovorene i za ostalu projektnu komunikaciju s naručiteljem. Što je tu tako loše?

Kao zaključak moram citirati staru i istinitu izjavu: „Projekt nije tu da bi zadovoljio metodologiju već je metodologija tu da se prilagodi projektu, kako bi isti bio uspješan!“. Izaberite pristup, koji odgovara najviše Vama, vašem naručitelju i projektu u cijelosti!

by Nenad Trajkovski

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s