Kao menadžer projekata u Sagi, često se zapitam kako se različite metodologije izvođenja projekta odražavaju na kvalitet finalnog rezultata. U jednom trenutku, najčešće u procesu ugovaranja projekta, demonstracije rešenja ili prilikom sastanaka sa potencijalnim klijentom, postavlja se pitanje – kojom metodologijom da izvedemo projekat? Nekad u vidu zahteva klijenta, a nekad kao predlog sa naše strane, agilnost se nekako prirodno nameće kao odgovor kada se pokrene pitanje metodologije izvođenja projekta. Zašto baš agilnost i kuda nas vodi ova metodologija?

Ono što je odlično je to što se priča i razmišlja o načinu isporuke rešenja i što su korisnici sve više upoznati sa pojmom agilnog pristupa. Način isporuke je značajan element projekta, jer se direktno odražava na finalni rezultat projekta i na odnose koje će Saga uspostaviti sa klijentom. Najviše zbog toga što dobra metodologija isporuke omogućava adekvatnu i pravovremenu komunikaciju, koja je ključni faktor uspeha projekta.

Međutim, postoje slučajevi u kojima se konverzacija o načinu isporuke vrlo brzo završava time što mi istaknemo da radimo agilno, klijent bude zadovoljan, jer prepoznaje agilnu metodologiju, kao danas najbolju i pređe se na sledeću temu. Ono što je u ovom „default agilnom pristupu“ pogrešno, a što je dobrim delom i tema ovog teksta, je to što se, bez konkretne analize „ispaljuje“ termin agilno, a zajedno sa njim i termini scrum, kanban, lean i scrumban, kao glavni sinonimi i primeri agilne metodologije. Ovu grešku pravi klijent, a često i mi sami!

U poslednjih 20 godina došlo je do ekspanzije u oblasti upravljanja projektima i metodologiji razvoja softvera. U poređenju sa drugim popularnim trendovima u periodu od 2004. godine do danas, Google Trends pokazuje kako se kotiraju dva najpoznatija agilna termina.

Sve zemlje u regionu, uključujući i Srbiju, imaju svoju godišnju konferenciju koja pokriva ovu temu, dok broj organizacija koje teže da sertifikuju učesnike sa nekim „agilnim“ sertifikatom raste. Koliko je „agilna filozofija“ zapravo postala industrija za uzimanje para, najbolje govori jedan od kreatora agilnog manifesta, Dave Thomas – link. Sertifikacija je tema za sebe, ali činjenica da je kod većine oglasa za rukovodioca projekta neophodno da neko ima sertifikat Scrum master-a ili neki drugi „agilni“ sertifikat, ukazuje da je sve otišlo dalje nego što bi trebalo. Iz moje perspektive, najbitnije vrednosti koje dobijamo sticanjem sertifikata jesu IDEJE koje se rađaju kroz čitanje literature i spremanje ispita. Ideje koje će se primeniti i dalje razvijati kroz rad na projektima i testirati u praksi.

Pre svega treba razumeti da ne postoji jedna jedinstvena agilna metodologija sa definisanim principima i pravilima. Agilnost treba posmatrati kao nivo fleksibilnosti nekog pristupa – neka metodologija je „agilna“ u meri u kojoj omogućava:

• brzo reagovanje na: novonastale probleme, proširenja u zahtevima korisnika i potrebne dorade, a sve to u vidu: definisanja replana sa konkretnim akcijama, komuniciranja promene prethodnog stanja na svim nivoima i započinjanja novih aktivnosti;
• jednostavan i brz protok informacija između različitih nivoa organizacione strukture;
• skraćenje vremena između dogovora da se nešto uradi i dobijanja povratne informacije u vidu: potvrde da se može ili ne može uraditi, dokumenta ili e-mail-a sa opisom predloga rešenja, urađenom celinom spremnom za testiranje ili izveštajem sa rezultatima testiranja.

Nebi trebalo daidemo dalje od definicije atributa agilnost, da bi se razumelo šta leži u osnovi ove „filozofije“. Različite metodologije i procesni okviri, poput Scrum-a, DSDM-a, Prince 2, PMI-a, Lean-a, na sebi svojstvene načine definišu procese, principe i pravila koji su u manjoj ili većoj meri agilni. Ono što je zanimljivo jeste da se za većinu metodologija može reći da su agilne. Takođe, interesantna je i pojava da autori većine poznatih pristupa, poput PMI-a i Scrum-a, izbegavaju da okarakterišu njihove pristupe kao metodologije, već ih definišu kao procesne okvire – framework. Možda razlog leži u tome što termin procesni okvir zvuči fleksibilnije od metodologije.

Ako su sve metodologije agilne, u čemu je onda problem? Problem je u tumačenju agilne metodologije kao efikasnije, brže ili bilo koji drugi termin koji se koristi za promovisanje agilne konferencije, sertifikata ili metodologije u odnosu na neku drugu. Najčešće se ove prethodne metodologije i načini isporuke karakterišu terminima „tradicionalni“ ili waterfall”, a neretko i PMI. Evo šta jednostavna pretraga na ovu temu sa Google-a daje kao rezultat.

Kada se uđe malo dublje u tematiku, u velikom broju upotreba termini traditional i waterfall se stavljaju u kontekst poređenja sa agilnim metodologijama, odnosno naglašavanja prednosti agilnih u odnosu na njih. Preporučujem sledeći članak koji detaljnije objašnjava ovu pojavu.

Međutim, kao neko ko je istraživao ovu oblast i dalje nisam naišao na metodologiju, metod ili okvir koji sebe opisuje kao tradicionalan ili čak waterfall. Sam termin waterfall  izvučen je iz konteksta iz rada Winston-a Royce-a iz 1970. godine. U radu je navedeno koje su to faze kroz koje treba da prođe razvoj softvera i dat je njihov redosled – slika ispod predstavlja waterfall pristup. U svom radu, autor štaviše sugeriše korišćenje principa iterativnog razvoja i razvijanja prototipa – nešto što agilne metodologije vrlo agresivno zastupaju danas.

Vratimo se na problem sa početka ovog teksta – nepromišljeno i brzopleto korišćenje termina agilno, Scrum, lean, itd. Isto kao što je neoprezno i nedovoljno profesionalno od tehničkog rukovodioca da kaže kako je svejedno da li će se za razvoj aplikacije koristi MSSQL ili Oracle za Database server, od mrežnog inženjera da je svejedno da li će se za Core mreže koristiti „stack“ ili „VSS“, od HR-a da će ­­­­­­­­proveriti u kojoj meri je kandidat timski igrač tako što će mu dati NEO PI-R test ličnosti ili tako što će ga staviti u prostoriju sa još pet kandidata i pratiti ponašanje, tako je neoprezno i nedovoljno profesionalno reći sledeće: “Da, možemo da radimo Scrum, Lean, Kanban, Scrumban“ ili „Da, radimo agilno. To vam je najbolje“. Tehnički rukovodilac, mrežni inženjer i HR, svi će prvo proučiti situaciju i analizirati sve relevantne faktore, nakon čega će zaključiti kako je najbolje nastaviti i imaće jasne argumente u korist odabranog načina. Isti proces razmišljanja važi i prilikom kreiranja projektne metodologije. Najjednostavnije rečeno, potrebno je prvo analizirati:

• okruženje u okviru kojeg će se raditi projekat – Sagin tim, korisnički tim, interne i eksterne procedure, itd;
• karakteristike projekta – obim projekta, rok za isporuku, priroda posla, itd. i
• naučene lekcije, dobre prakse i probleme iz prethodnih projekata slične prirode.

Uzevši u obzir ove faktore, velika je verovatnoća da će predložena metodologija biti efikasnija za primenu od neke generičke (Scrum, Prince 2, itd.). Pri tome, radeći stvari na ovaj način, pokazujemo korisniku da smo uložili trud analizirajući konkretan projekat koji radimo za njega i ponudili metodologiju koja najbolje odgovara specifičnostima njegovog projekta. Naravno, velike su šanse da će predložena metodologija biti u značajnoj meri agilna, nismo hejteri!

Dakle Scrum, iako najpopularnija metoda za organizaciju rada prilikom razvoja softvera danas:

možda nije najbolja za konkretnu implementaciju o kojoj se pregovara. U konkretnom slučaju primene Scrum-a, odmah treba postaviti pitanje: „Da li smo izvodili po Scrum-u ranije projekte?“ Takođe, „Da li je korisnik radio po Scrum-u?“ Ukoliko su odgovori negativni, zašto bi se insistiralo na ovom načinu rada? Zato što je najpopularniji, zato što se koristi i u drugim industrijama, zato što ima dosta slučajeva na internetu gde se govori o njegovoj uspešnosti? Svakako ne. Prihvatanje da se radi po nekom načinu isporuke, bez prethodne analize, je podjednako opasno kao prihvatanje nekog posla bez razumevanja podele odgovornosti i obaveza koje sa njim dolaze. Rezultat će biti nerazumevanje, loša komunikacija i trošenje energije na sekundarne aspekte projekta. Da se razumemo, može jedan softverski tim u dobro organizovanoj kompaniji vrlo lako da radi po Scrum-u, ali je onda potrebno prvo obučiti taj tim i proći kroz realizaciju makar jednog manjeg projekta na ovaj način. Sa druge strane, potrebno je imati korisnika koji je upoznat sa ovim načinom isporuke i ugovor koji omogućava ovakav način isporuke. Svakako nije preporuka primeniti ga prvi put na većim i složenijim projektima.

Na kraju, odgovor na pitanje: „Da li možemo na agilan način da radimo ovaj projekat?“ ne treba da bude brzopleto i isključivo da! Odgovor treba da glasi „Možemo da radimo agilno, ali hajde da uradimo adekvatnu analizu i izaberemo metodologiju koja je najbolja za ovaj projekat!“ Hajde da znamo zašto baš ta metodologija, a ne, na primer Scrum, Kanban ili čak interno definisana metodologija klijenta, koju koristi za sve projekte. Na kraju, metodologija je po prirodi fleksibilna, ukoliko nije adekvatna ili ima prostora za poboljšanje u određenim segmentima, treba je prilagoditi potrebama konkretnog projekta. Ovo vodi ka zadovoljstvu klijenta i uspešnosti našeg tima, što jeste krajnja svrha.

Da sumiram čitav tekst u jednoj rečenici:

Metodologija ne sme da bude sama sebi cilj, već cilj metodologije mora da bude kvalitet finalnog proizvoda!