Standardno ili Agilno vođenje projekata?

Perpetuum Mobile Baza znanja, Tips'N'Tricks

Ako želite da projekt ima imalo šansi za uspjeh potrebno je imati dobro razrađenu metodologiju. Metodologije se ugrubo mogu podijeliti na dvije skupine: standardne i agilne. Standardne metodologije se još nazivaju i waterfall (slap), jer se odvijaju po fazama, gdje jedna slijedi drugu i nema iteracija.

Mnogi kritičari smatraju da je ova metodologija, naročito  kada se radi o projektima razvoja softvera, vrlo loša, a poneki su skloni reći i nemoguća. Objašnjenje nalaze u tome da se u toj metodologiji mora precizno isplanirati i najmanji detalj i funkcionalnost prije nego što se krene u razvoj te da su kasnije promjene nemoguće ili ako se rade, vrlo skupe, a timovi koji rade na takvim projektima demotivirani. Agilne metodologije (kao što je to npr. Scrum ili Kanban) s druge strane govore o tome da su promjene tijekom razvoja poželjne i konstantne.

Scrum agilno vođenje projekata

Prvo ću objasniti agilno vođenje projekata na primjeru Scruma. Uloge koje postoje su: Product Owner, Scrum Master i Development Team. Product Owner zastupa kupca i zna što kupac želi i to je uvijek samo jedna osoba. Scrum Master je osoba koja se često miješa s voditeljem projekta. Scrum Master nije voditelj projekta već osoba koja služi da timu pomaže kod primjene Scruma te da miče sve prepreke koje netko može postaviti pred tim. On zapravo vodi tim služeći mu, a ne „šefujujući“ mu. Development Team je skupina pojedinaca (5 do 9) koji rade na projektu tako da planiraju aktivnosti koje treba obaviti da bi napravili određene funkcionalnosti, procjenjuju ih, organiziraju ih u tzv. sprinteve i izvršavaju zadatke. Događaji (Eventi) koji se odvijaju u Scrumu su: Sprint PlanningSprintDaily Sprint MeetingSprint Review i Sprint Retrospective Meeting. Sprint Planning je sastanak (koji traje maksimalno jedan dan, a vrlo često i kraće) na kojem se uzimaju zadaci iz tzv.

Product Backloga (mjesto na kojem su po prioritetima od najvećeg do najmanjeg poredane funkcionalnosti, a koji definira Product Owner) i procjenjuje što se treba napraviti za te zadatke i koliko njih može biti napravljeno u samom Sprintu. Sprint je vremenski ograničen period (od 2 do 4 tjedna) u kojem se ti preuzeti zadaci iz Sprint Backloga rade, hajmo reći – kodiraju, testiraju, integriraju i dokumentiraju. Ti zadaci se nalaze u Sprin Backlogu. Važno je napomenuti da se Sprint ne produljuje ni pod kojim uvjetima. Ako nije sve planirano napravljeno, a primjerice nedostaje još samo pola dana da bi se sve završilo, sprint se, bez obzira na to, završava.

Cilj agilne metodologije je da na kraju svakog sprinta imamo potencijalno razvijene funkcionalnosti koje mogu ići u produkciju (ne nužno uvijek). Daily Sprint Meeting je dnevni sastanak, koji se održava svaki radni dan u isto vrijeme, a koji traje maksimalno 15 minuta i u kojem članovi tima i samo oni daju odgovore na tri pitanja: „Što smo radili jučer?“„Što ćemo raditi danas?“ i „Imamo li kakvih problema?“. Ako je potrebno nešto dodatno razjasniti, to se ne radi na tom sastanku nego na nekom posebnom, najbolje odmah poslije Daily Sprint Meetinga. Kada je Sprint završen radi se sastanak koji se zove Sprint Review,  u kojem se Product Owneru i svim zainteresiranim prezentira što je napravljeno u Sprintu. Sprint Retrospecitve je sastanak na kojem tim i Scrum Master odgovaraju na pitanja: „Što je bilo dobro u zadnjem Sprintu“, „Što nije bilo dobro u zadnjem sprintu?“ i „Što učiniti da bi radili bolje?“. Nakon toga ciklus započinje ponovo novim  Sprint Planningom.

Kada govorimo o standardnom vođenju projekata prvo voditelj projekta, ako je imalo pametan i profesionalan – zajedno s timom, prikuplja i analizira zahtjeve koje treba izvršiti. Nakon toga se ti zahtjevi dokumentiraju u tzv. Specifikaciju funkcionalnosti i, nakon ovjere naručitelja, kreće se s radom. Ovdje neću opisivati sve procese, procedure i područja znanja (kao što je to npr. Scope Management ili Risk Management) koji su prisutni kod ove metodologije.

Ne mogu se svi projekti voditi agilno

Gdje su problemi? Ja sam apsolutno za to da se svi softverski projekti vode agilno! Ali, postoje i neke prepreke. Prva i osnovna prepreka je da se svi projekti jednostavno ne mogu tako voditi. Evo primjera. Državna institucija ABC propiše tender u kojem jasno opiše što želi i do kada to želi. Naravno uz fiksnu cijenu. Ovdje je agilnu metodologiju nemoguće promijeniti jer uz ta ograničenja promjene jednostavno nisu moguće. Građevinski projekti su isto takav primjer. Zamislite da imate nacrt kuće od 5 katova, napravite prva 3 i onda Product Owner kaže: „Ajmo momci sad mi treba dva kata za garažu ispod zemlje!“. Jednostavno – nemoguća misija. Idući problem je svijest. Naime, da bi se radilo po agilnim metodologijama, kupac (naručitelj) mora poznavati jednu od tih metodologija, aktivno sudjelovati u projektu i biti voljan istu i primijeniti. Kako sam opisao u agilnim metodologijama ne postoji voditelj projekta.

Timovi su samoorganizirani i samoodgovorni. Drugim riječima sva odgovornost je na timu, a ne na jednom pojedincu. To bi bilo predivno kada ne bi znali iz prakse da svi ljudi nisu samoodgovorni, a da takve jednostavno ne možete zamijeniti drugim, odgovornim, jer ih jednostavno – nemate. Kada je projekt po agilnim principima vođenja završen?  Onda, kada kupac kaže: „U redu, sve iz Product Backloga je napravljeno i radi.“ ili „Ovo što je do sada napravljeno u potpunosti zadovoljava moje potrebe pa mi ostalo ne treba.“. Hmmmm, da. No najčešće će vam kupac reći: „Meni treba ovo.“ i pitati Vas: „Do kada to možete napraviti i po kojoj cijeni?“. Istina je što pobornici agilnih metodologija (a ja sam jedan od njih) tvrde da je kupac svjestan svojih potreba tek kada se sa projektom započne i kada vidi što će dobiti, odnosno već nakon prvog Sprinta.

Tada će on zapravo imati prilike prvi puta vidjeti kako će proizvod (okvirno) izgledati i isti modificirati, na način da promijeni prioritete već postojećih funkcionalnosti u backlogu ili da neke iz njega izbaci, a doda nove. No takav kupac mora znati da ne može dobiti točan datum kraja projekta. A cijena? Pa cijena je po principu – što ti odradim, to ćeš i platiti, dakle i konačan budžet se ne može precizno odrediti. Vjerovali ili ne, to je ispravan način rada i sve više tvrtki naručitelja su to prepoznale!

Metodologija ovisi o projektu i naručitelju, ali kada možete birajte – agilno!

Tradicionalni („waterfall“) način je loš smo ako kupcu (naručitelju) date da vidi svoj proizvod – na kraju projekta. Ako mu dajete da vidi što je napravljeno tijekom projekta (princip, malo po malo), tada i u tom slučaju kupac može pravovremeno reagirati. Nije istina što neki tvrde, da su promjene bolne i skupe. Jesu ako isporučite sve odjednom na kraju. Nisu, ako kupcu redovno isporučujete tijekom projekta.

Kako kupac može zatražiti promjenu? Jednostavno – pa postoji procedura upravljanja promjenom i dokument – zahtjev za promjenom, u kojem kupac napiše što želi promijeniti ili dodati. Prema tom dokumentu se radi procjena vremena i novaca i nakon dobivene suglasnosti na promjeni se i radi. Ništa novo! Mogu li se standardna i agilna metodologija kombinirati? Naravno da mogu. Primjerice, s kupcem se potpiše jasan specifikacija, a tim radi agilno! To je uobičajena svjetska praksa.

Kao zaključak, kada me ljudi pitaju koja je metodologija bolja, moj odgovor je: „Ovisi za što i s kim radiš.“. Generalno, ako postoji i najmanja mogućnost za agilno – radite agilno bez razmišljanja!