Kako procijeniti vrijeme potrebno za implementaciju IT projekta? Ključna razlika između tradicionalnih metoda i pristupa kojeg ću opisati je fleksibilnost.
Zašto kažem fleksibilnost? Tradicionalne metode planiranja projekata uključuju procjenu trajanja projekta koja se donosi na početku, prije nego je napisana i jedna linija koda. U najboljem slučaju procjena potrebnog vremena se donosi nakon što je napravljeno manje istraživanje i možda implementiran prototip sustava. U svojoj praksi ja nisam nikad vidio da se planiranju vremena pristupa nakon što se izradi prototip. Posebno u današnjim kriznim uvjetima, trošiti resurse na prototip projekta (dakle, raditi na projektu a da još niste niti potpisali ugovor) vrlo je rijetka praksa.
S druge strane, agilni pristup planiranju vremena kaže: nerealno je očekivati da na početku projekta možemo kvalitetno procijeniti koliko će trajati implementacija cijelog sustava. Zato nakon planiranja arhitekture sustava treba početi s implementacijom. Prvi pokušaj implementacije nekog od dijelova sustava izgleda slično izradi prototipa. Taj kod na kraju čak i može biti odbačen da bi bio zamijenjen kodom koji će biti korišten u produkciji. Dakle, sve je do sad vrlo slično ideji o ranom planiranju vremena zajedno s izradom prototipa.
Razlike počinju odmah nakon implementacije tog prvog podsustava. Kad je podsustav završen (u agilnom svijetu to znači: potpuno funkcionalan i testiran) mjeri se koliko je vremena bilo potrebno za njegovu implementaciju. Procjenjuje se (ugrubo) relativna složenost tog podsustava u odnosu na ostale dijelove koji još nisu implementirani. To sve fino pomnožimo i pozbrojimo i dobijemo jednu grubu procjenu koliko vremena treba da se implementira cijeli projekt. Ključno je ovdje prihvatiti činjenicu da se radi o gruboj procjeni. Ako klijent pristane da se projekt pod takvim uvjetima izvodi do kraja nastavlja se s implementacijom. Pri tome se za svaki završeni podsustav mjeri koliko je vremena trebalo i na osnovu toga se korigira početna procjena. Ako se ispostavi da je procijenjeno vrijeme bilo preveliko, super, projekt će biti gotov ranije i ima mjesta za implementaciju dodatnih ideja koje će klijent sigurno imati u međuvremenu. Ako se ispostavi da je procijenjeno vrijeme bilo premalo, zajedno s klijentom se radi promjena plana. Ili se produžuje rok za cijeli projekt ili se izbacuju podsustavi dok se po novoj procjeni ne uđe unutar granica početno procijenjenog vremena. Agilna metodologija tu preporučuje ovo drugo rješenje.
Bitno je da klijent cijelo vrijeme bude uključen u razvoj projekta. Svaki put kad je neki podsustav završen, klijent ga mora barem pogledati, a idealno bi bilo da ga i testira koliko može i da razvojnom timu da svoje sugestije i komentare. Svaki put kad se radi nova procjena vremena potrebnog za implementaciju ostatka sustava klijent mora biti prisutan i zajedno s vama odlučivati što će se dodatno implementirati i što će se izbaciti. Na taj način se ne može desiti da na kraju projekta dođete klijentu i kažete mu "Mi smo bili malo sporiji od očekivanog, evo ovo smo do sad stigli napraviti" i isporučite mu polufunkcionalan proizvod koji ima funkcionalnost koja klijentu uopće nije bila visoko na listi prioriteta. Ako već mora biti rezova neka klijent odluči što će se rezati.
Sigurno se neki od vas pitaju: a što ako ne stignemo napraviti niti minimum funkcionalnosti koju sustav mora obavljati da bi uopće imao svrhu postojati? To je moguća situacija i vjerojatnija je kod mlađih i neiskusnih timova i neiskusnih klijenata. Takva bi se situacija u većini slučajeva trebala moći prepoznati na početku a i ako se ne prepozna, uvijek postoji rješenje produljenja rokova. Ako je klijent općenito zadovoljan s vašim radom možda mu neće bilo teško produljiti rokove. Tome posebno pomaže činjenica da ste ga kvalitetno izvještavali kroz cijeli projekt i da zbog kontinuranih re-evaluacija vremena zna koliko je još potrebno da se projekt završi. Opet, u odnosu na tradicionalni pristup, puno je veća šansa da ćete ranije postati svjesni vaših problema i to vam donosi prednost u odnosu na timove koji počinju priznavati da su u problemima tek zadnji tjedan prije krajnjeg roka za isporuku.
Ovakav pristup, naravno, nije obavezan baš za sve projekte. Najprikladniji je za novi razvoj ili za projekte gdje i uz postojeći kod još uvijek treba uložiti značajnu količinu truda da bi proizvod zadovoljio potrebe klijenta. Ako npr. već imate gotov proizvod i novi klijent ima samo zahtjev da se na svim vidljivim mjestima vaš logo zamijeni logom njegove firme, za takav projekt je prilično jednostavno procijeniti potrebno vrijeme. Čak je i kontraproduktivno gnjaviti ga svaki put kad ste dodali novu sličicu u grafičko sučelje.
Tema koja se svo ovo vrijeme proteže kroz moje pisanje o agilnim projektima je klijentovo sudjelovanje u projektu. Mislim da je to najvažniji element u ovoj priči. Jer, kako se ono kaže: ljudi smo, možemo se dogovoriti! :)
| Igor Rumiha nezavisni je konzultant koji se u svojoj IT karijeri od 2000. godine do danas bavio izradom sustava za mrežni nadzor, provisioning sustavima u ISP i mobile telekom okolinama i automatizacije testova na embedded platformama. U pauzama između tih poslova bavio se administracijom Oracle i MSSQL baza, billing sustava pa čak i izradom billing sustava. |
