Agile bazirani razvoj

Davno je prošlo vrijeme kada bi vas na spomen agilnih metodologija samo blijedo promatrali. Štoviše, agilno je sada u modi, velike svjetske kompanije počinju u sve većoj mjeri koristiti agilne metodologije. No, kakvo je zapravo stanje u agilnom svijetu, koje se metodologije najviše koriste, što vrijedi, što se pokazalo uspješnim, jesu li neke ideje odbačene…? Na ta i slična pitanja pokušat ćemo odgovoriti u ovom članku.

Kada se govori o agilnim metodologijama, mnogi će se prvo sjetiti poznatog Agilnog manifesta (Manifest za agilni razvoj softvera, Manifesto for Agile Software Development) iz 2001. On je tijekom godina stekao takvu slavu da i mnogi iz IT industrije koji ne poznaju agilne metodologije ipak mogu reći da su čuli za njega. Netko će možda pogrešno reći i da upravo on označava trenutak nastanka agilnih metodologija. No, istina je da je povijest agilnih metodologija puno duža.

Japanski geni

Neka se od osnovnih načela agilnih metodologija, poput iterativnog i inkrementalnog načela te načela prilagodljivosti, u kontekstu razvoja softvera spominju od 50-ih godina prošlog stoljeća. Mnoge metode koje su danas poznate kao agilne nastale su prije Agilnog manifesta. Jedna od prvih objavljena je početkom 1995. i danas slabo zastupljena – metoda DSDM (Dynamic Systems Development Method). Nedugo nakon toga iste je godine svjetlo dana službeno ugledao i Scrum, danas najpopularnija agilna metodologija u razvoju softvera. Scrum kakav danas poznajemo zapravo je kreiran daleko od očiju javnosti još 1993., a njegovi začeci mogu se naći u Japanu sredinom 70-ih godina u japanskoj tvrtki Fuji Xerox. Tamo su prilikom razvoja novog fotokopirnog uređaja klasični, sekvencijalni waterfallski model, u kojem iduća faza razvoja počinje tek završetkom prethodne, modificirali tako da se faze preklapaju. S obzirom na to da su autori Japanci, tako izveden waterfallski model poslije je nazvan sashimi model, prema japanskom jelu sashimi (svježi morski plodovi narezani na tanke listiće).

Lagano ili agilno?

Iz potrebe za agilnošću tijekom godina nastale su brojne nove metodologije kojima je cilj bio da razvoj proizvoda bude što “lakši” (engl. lightweight). Skupina entuzijasta za takve metodologije okupila se u veljači 2001. na jednom neformalnom druženju i sastavila poznati Agilni manifest. Sam je manifest vrlo kratak te naglašava neka iskustvom stečena saznanja:

  • ljudi i interakcija vredniji su od procesa i alata
  • ispravan kod vredniji je od opširne dokumentacije
  • suradnja s korisnikom vrednija je od pregovaranja oko ugovora
  • reagiranje na promjenu vrednije je od držanja plana

Iako je zajednička nit vodilja bila riječ “lagano”, “agilno”je bila ta riječ koja je dana nazivu manifesta i takvu načinu razvoja. Razlog je jednostavan: riječ “lagano” (lightweight) za sobom vuče i negativne konotacije pa se moralo naći nešto drugo što bi poboljšalo “prodaju” ovakvog pristupa razvoju softvera. Od tada nadalje, Agile postaje buzzword, što zasigurno ubrzava i olakšava uvođenje takvih metodologija u razvojne procese čak i najvećih (tradicionalno konzervativnih) kompanija na svijetu. Naravno, da same metodologije ne donose dodanu vrijednost, hype bi vjerojatno bio kratkog daha.

Scrum

U Scrumu projekt napreduje iterativno kroz sprintove. Svaki bi sprint trebao trajati dva do četiri tjedna (ali to trajanje mora biti fiksno i unaprijed definirano, timeboxing je jedna od ključnih značajki Scruma) tijekom kojih se kreira verzija produkta spremna za isporuku. Cijelo vrijeme trajanja projekta postoji Product backlog, u kojem su popisane bitne funkcionalnosti nekog proizvoda. Za njih je dovoljno da budu opisane na visokom nivou, bez detalja. Funkcionalnosti koje se implementiraju tijekom jednog sprinta striktno su određene prije pokretanja samog sprinta, u fazi njegova planiranja. Njihov se skup naziva Sprint backlog, a u njemu će se dogovorom između vlasnika projekta i razvojnog tima naći funkcionalnosti iz Product backloga. Zamisao je da se sprint planira tako da ima dovoljno vremena za implementaciju zadataka koji se stave u Sprint backlog te je ovdje jako bitna procjena razvojnog tima. Zadaci koji se nađu u Sprint backlogu trebali bi biti detaljnije razrađeni od onih iz Product backloga, a procijenjena količina posla po zadatku ne bi trebala prelaziti šesnaest sati rada.

Bitno je imati na umu da je Sprint backlog nepromjenjiv. Naime, u njega nije dopušteno dodavati nove aktivnosti iz Product backloga jednom kada je sprint počeo. To je vrlo bitno iz više razloga: timu je povjerena odgovornost za procjenu toga što se može načiniti i u kojem vremenu, a pred sprintom se neće naći neočekivane prepreke. Tako su ljudi motiviraniji za rad, a bitne funkcionalnosti odabrane u fazi planiranja imaju veću vjerojatnost da zbilja budu implementirane na vrijeme.

Product backlog promjenjiv je na više načina. Jedan je od njih uočavanje novih funkcionalnosti koje bi proizvod trebao imati, a koje možda nisu bile očite ili dovoljno jasne u trenutku kada je projekt započeo. Drugi je u slučaju da se neka od funkcionalnosti iz trenutačnog Sprint backloga neće moći implementirati za vrijeme trenutačnog sprinta (npr. ako neki vanjski preduvjeti još nisu zadovoljeni za tu funkcionalnost ili jednostavno nema dovoljno vremena). U takvim se situacijama zadatak mora vratiti u Product backlog. Produžavanje sprinta izvan inicijalno zadanih vremenskih granica nije dopušteno!

Još jedna bitna značajka Scruma jesu dnevni (tzv. standup) sastanci, za koje je bitno:

  • da budu vremenski ograničeni – na 15 minuta
  • da uvijek počinju na vrijeme, bez kašnjenja – u isto vrijeme i na istom mjestu
  • da članovi tima za vrijeme sastanka stoje (odatle i naziv standup) – s obzirom na to da dugo stajanje nije ugodno, time se osigurava da se članovi tima u razgovoru drže bitnih tema
  • da tijekom sastanka svaki član tima odgovori na tri pitanja:
  1. Što je napravio od jučer?
  2. Što planira napraviti danas?
  3. Ima li nekih problema koji ga sprečavaju u izvršavanju zadataka?

Iako je to samo površan pogled na Scrum, već bi otuda trebale biti jasne neke od značajki koje mu donose snagu:

  • jednostavan, lako razumljiv i čvrst razvojni proces
  • usredotočenost na bitne funkcionalnosti koje je razvojni tim sam procijenio da može implementirati
  • svakodnevna komunikacija na standup sastancima, koji se usredotočuju samo na bitno
  • komunikacija između svih članova tima (poslovni analitičari, programeri, testeri…)
  • zadovoljniji članovi tima, što za posljedicu ima kvalitetniji i brži razvoj
  • zadovoljniji naručitelji proizvoda i korisnici

Lean

Ova se metodologija hvali da je proizašla iz Toyota Production System skupa filozofija i praksi koje su bile pokretačka snaga te japanske kompanije. Za razliku od Scruma koji daje jasnu strukturu za vođenje projekta te XP-a koji dodatno naglašava inženjerske prakse prilikom kodiranja aplikacije, Lean daje preporuke koje su primjenjive na nivou kompanije:

  • Eliminirati suvišno – sve što ne donosi korist klijentu predstavlja višak, bilo da se radi o resursima, funkcionalnostima ili birokraciji
  • Još više učiti – u prvom redu o proizvodu koji se razvija i o procesu razvoja
  • Odlučivati što je kasnije moguće – ukoliko neki zahtjevi nisu potpuno poznati, proizvod treba razvijati tako da ga se može lako prilagoditi činjenicama koje se naknadno saznaju. Nikako se ne bi smjelo povoditi za pretpostavkama ili nagađanjima.
  • Isporučivati što je prije moguće – naravno, to ne znači da treba isporučiti neispravan proizvod. Bitno je isporučiti ispravan proizvod bez svih funkcionalnosti kako bi se što prije dobio povratni odgovor od klijenata te se ta saznanja mogla uključiti u iduću iteraciju u razvoju.
  • Dati timu moć – voditelji projekata trebaju pustiti članove tima da rade svoj posao kako znaju. Pritom im treba dati moć da donose određene bitne odluke.
  • Proizvod mora biti cjelovit – postoje dvije dimenzije cjelovitosti: doživljena, koja se odnosi na to koliko kvalitetnim korisnik doživljava proizvod, te konceptualna, koja govori o tome koliko dobro sustav ispod površine (daleko od korisnikova pogleda) funkcionira u pružanju usluge.
  • Promatrati proizvod kao cjelinu – bilo koji proizvod nije samo suma svojih dijelova, bitni su i odnosi između tih dijelova te kako sve zajedno funkcionira. Npr., proizvod se u cjelini može neoptimalno ponašati iako se puno pažnje poklonilo optimizaciji svake komponente zasebno.

CROZ stručnjaci mogu vam pomoći da iskoristite najbolje iz svijeta agilnih metodologija i pomognu odabrati najbolji put za vas.