piše: Zoran Šljivić, lead software developer, Serengeti
Najveća je razlika između, uvjetno rečeno, dobrog i lošeg tima iskustvo razvoja projekata, a ono se stječe na pogreškama, odnosno njihovim prepoznavanjem i akcijama koje će se provesti da se spriječi njihovo ponavljanje. Važno je da se već na početku otklone sve nejasnoće i da se ne počinje samo da se što prije završi. Tada se, naime, pogreške slažu jedna na drugu
Postoje IT tvrtke i postoje uspješne IT tvrtke. U potonjima razvojni timovi jednostavno znaju što rade, a postoje i razlozi zbog kojih je tome tako. Znamo da svaki uspješan projekt mora imati jasno definirane rokove i proračun, da dogovorene funkcionalnosti moraju biti isporučene, a istodobno standardi struke zadovoljeni. O svemu tome vode računa razvojni timovi, koji moraju imati jasno definiran projektni zadatak i projektnog menadžera s jasnom ulogom, a to je da na vrijeme dozna što više detalja od naručitelja projekta kako bi se u startu izbjegle pogreške.
Neke od pogrešaka su nerealna očekivanja, preoptimističan raspored projektnih zadataka, pretpostavke o razvojnom putu proizvoda ili usluge, izjednačavanje procjene zadatka i stvarnog cilja, previše multitaskinga, mijenjanje strategije unutar razvojnog ciklusa te postavljanje svih zadataka u top-prioritet.
Deset puta uspješniji
Glavna karakteristika uspješnih razvojnih timova, koji mogu biti čak i deset puta uspješniji od drugih, ispravno je biranje strategije razvoja projekta, koja se određuje prema parametrima roka isporuke, proračuna, veličine tima, detaljnog opisa zadatka i ciljeva. Rok isporuke određuje se nakon što razvojni tim obavi procjenu zadataka koje mora obaviti, tj. koliko će vremena biti potrebno da se nešto razvije. Proračun se mjeri u vremenu i novcu kojim se raspolaže za određeni projekt, a određuje ga klijent, dok veličina tima ovisi o kompleksnosti projekta.
Kvalitetni timovi imaju veliku prednost – oni znaju detaljno opisati zadatke na temelju ciljeva koje pred njih postavlja klijent kako bi se spriječilo krivo tumačenje naizgled jednostavnog zadatka. Također, znaju da primarno moraju raditi na samo jednom projektu u zadanom vremenu.
Otklanjanje nepoznanica
Timovi s dobrom praksom prvo će identificirati sve nepoznanice u zahtjevu koji im je klijent isporučio, a tim s nedovoljno iskustva uglavnom će odmah krenuti u razvoj i jednostavno sam pretpostavljati što je naručitelj projekta mislio ili htio s određenim zadacima. Tim s više prakse i iskustva zna da će daleko više vremena potrošiti ispravljajući pogreške nastale iz krivih pretpostavki i upravo će zato prvo identificirati sve nepoznanice i utrošiti vrijeme da ih otkloni i razjasni.
To podrazumijeva nove sastanke s naručiteljem projekta i tek nakon što su sve nedoumice otklonjene, kreće se s planiranjem zadataka i procjenom njihova trajanja. Ako je riječ o razvoju projekta duljeg trajanja, od šest i više mjeseci, potrebno je planirati zadatke onoliko daleko koliko je realno moguće kako bi se izbjeglo puko ispunjavanje planiranih zadataka bez naknadnih evaluacija trenutačnog stanja projekta.
Odabir strategije
Odabrana metoda razvoja također je bitna, bila ona agilna, waterfall bila neka druga, a još je važnije da se redovno radi osvrt na trenutačno stanje projekta kako bi se uklonili mogući rizici i kako bi projekt mogao biti uspješno i na vrijeme isporučen. Dakle, inicijalan plan procjene na tjednoj ili mjesečnoj bazi mora biti nadopunjavan.
Dobar razvojni tim odabrat će strategiju koja je najbolja za projekt i neće se držati samo waterfall ili samo agilne strategije razvoja zbog toga što su trenutačno popularne, već će paziti da najefikasnije odradi posao. To znači da će birati dobro provjerenu tehnologiju s kojom ima iskustva u radu i neće eksperimentirati s nekom novom tehnologijom, osim ako to nije predviđeno projektom, jer bi ona pred tim mogla donijeti brojne nepoznanice i izazove na koje će trebati potrošiti dodatno vrijeme. U razvoju je bitno koristiti se alatima koji će poboljšati proces umjesto da proces prilagođavamo alatima koje smo odabrali.
Neizostavni bazeni znanja
Neke od pogrešaka koje rade manje iskusni razvojni timovi su i izbjegavanje dokumentiranja tijeka projekta, izmišljanje već postojećih procedura i nedovoljno dobra komunikacija među članovima tima. Kombinacija tih triju pogrešaka dovodi do znatnoga gubitka vremena u razvoju proizvoda ili usluge pa je najvažnije da tim vodi dokumentaciju razvoja projekta, bilježi sve probleme i njihova rješenja te ih sprema u tzv. bazen znanja, odnosno mjesto na sharepointu ili nekakvom repozitoriju kojem svi članovima imaju pristup da se ubuduće ne bi gubilo vrijeme na iste stvari. Uigrani tim će se isto tako svaki dan u isto vrijeme koristiti i mogućnosti daily stand up-a, sastanka na kojem će se govoriti što se radilo jučer, što će se raditi danas i postoji li problem o kojem treba razgovarati.
Iznimno važna u dobrim timovima je i revizija koda, koja osigurava kvalitetu koda u razvoju i kojom se smanjuje mogućnost ponavljanja pogrešaka. Često će tim koji nema dovoljno iskustva u razvoju reći da nema vremena za reviziju koda jer mora završiti razvoj. No, praksa je pokazala da takav pristup često dovodi do povećanog broja defekata prilikom korisničkog testa i da njihovo rješavanje oduzima više vremena od same revizije koda kojom bi se potencijalni problem ranije uočio i otklonio, što bi u konačnici uštedjelo i novac.
Defekti u razvoju
Cijena defekata koji se ne otkriju prilikom revizije koda može biti vrlo skupa. Zašto je to tako? Svaki defekt koji otkriju korisnici prilikom korisničkog testa mora se evidentirati, vratiti na razvojni tim, koji onda mora potvrditi je li to stvarno defekt ili dorada koje su se korisnici sjetili naknadno te utrošiti vrijeme na njegov ispravak, a kako bi ponovno završio na testiranju kod korisnika. Dobar razvojni tim imat će minimalan broj defekata na korisničkom testiranju, jer ih je velik dio spriječio u početku, kod definiranja zadataka i rješavanja nepoznanica u početku definicije projekta.
Prema Garyju E. Mogyorodiju, oko 83 posto svih defekata postoji prije negoli je ijedna linija koda napisana. Prema njegovom iskustvu, 56 posto svih defekata u razvoju proizvoda nastane zbog nedovoljno dobro definiranih zahtjeva. Ističe da su zahtjevi koji nisu dovoljno jasni najčešći uzrok neuspjelih projekata. Isto tako, navodi da je u fazi definiranja zahtjeva najmanja cijena izmjene zahtjeva. Ostatak defekata, što se tiče dizajna i samoga koda, povezuje uglavnom s tim što je zahtjev loše definiran i nije dovoljno ispitan pa će, naravno, nastati pogreške u dizajnu jer se zahtjev pogrešno protumačio. Nastavno na pogreške u dizajnu dolaze i pogreške u pisanju koda, što je najmanji postotak defekata u projektu.
Vrijeme za izradu
Nešto u čemu će neiskusan tim također češće pogriješiti jest procjena, odnosno postupak predviđanja najrealnije količine napora, izraženog u ljudskim satima ili novcu, potrebnog za razvoj ili održavanje softvera na temelju nepotpunog, neizvjesnog i bučnog unosa.
Praksa lošijih timova je da često precijene svoje mogućnosti, bilo da žele impresionirati korisnike potrebnim vremenom za izradu projekta bilo da padnu pod pritiskom roka i pristanu na nešto što unaprijed znaju da neće uspjeti ispuniti. Dobar razvojni tim neće brkati pojmove procjene i cilja jer je cilj datum koji je korisnik dao kao krajnji rok isporuke proizvoda ili usluge, a procjena zadataka unutar nekog projekta nešto je za što je potpuno odgovoran razvojni tim.
Uči se na pogreškama
Svi znamo da se radom na različitim projektima susrećemo i s različitim izazovima te da su najvažnije lekcije one koje ćemo naučiti u odnosu s klijentima koji naručuju projekte i zajedničkim uklanjanjem nedoumica vezanih uz projektne zadatke.
Najveća je razlika između, uvjetno rečeno, dobrog i lošeg tima, iskustvo razvoja projekata, a ono se stječe na pogreškama, reflektiranjem na njih i akcijama kojima ćemo spriječiti njihovo ponavljanje. Nemoguće je dovoljno naglasiti koliko je važno da se u početku otklone sve nejasnoće i da se ne srlja u razvoj projekta kako bi se on što prije završio jer ćemo najviše napraviti ako dobro definiramo sve zahtjeve u početku i ako svi imamo jednaku sliku cilja koji se želi postići.