Potrošiti što manje vremena, a zadržati kvalitetu i uspješnost imperativ je svakog projektnog menadžera. Kako optimizirati provođenje vašeg idućeg projekta implementacije nekog IT rješenja te isporučiti najbolje? Odgovor se možda skriva iza naziva Scrum – u zadnjih nekoliko godina izrazito popularne metodologije.

Kao i sve druge agilne metodologije, Scrum je inkrementalni i iterativni pristup razvoju softvera. Inkrementalni razvoj predstavlja razvoj softvera korak po korak, dok iterativni način predstavlja strategiju vremenskog planiranja u kojem se softver kroz svaki definirani period vremena dodatno usavršava.

Osnovna vremenska cjelina Scruma jest sprint.

Na kraju svakog sprinta, razvojni tim isporučuje zaokruženi dio proizvoda, odnosno potencijalno isporučiv inkrement proizvoda.

Razbijanjem razvojnog procesa na sprintove, Scrum smanjuje rizik od isporuke lošeg softvera, softvera koji neće zadovoljiti vaše potrebe, a ujedno se time i lakše prilagođava novim i promijenjenim zahtjevima korisnika koji su neizbježni.

Svaki pojedini sprint dodatno se razbija na još manje dijelove koji traju točno 24 sata, a počinju i završavaju dnevnim scrumom.

Dnevni scrum jedna je od obaveza cijelog razvojnog tima, a nužan je da bi se postigla unutarnja transparentnost u timu. To je stand-up sastanak na kojem svi članovi razvojnog tima u neformalnom okupljanju od 15-ak minuta odgovaraju na točno 3 pitanja:

1. Što je urađeno jučer?
2. Što će se raditi danas?
3. Kakve nam prepreke stoje na putu?

Sprint započinje sastankom planiranja (Sprint planning meeting). Tijekom sastanka definira se sprint backlog – popis svojstava koje treba ugraditi u nadolazeći sprint.

Sprint backlog nastaje na osnovi product backloga – popisa svih svojstava koje treba ugraditi u proizvod sortiran prema prioritetu kako ih vidi sam korisnik. Na vrhu product backloga nalaze se najvažnija svojstva, a na dnu ona s najmanjim prioritetom.

Tijekom sastanka, tim procjenjuje koliko svojstava iz product backloga može staviti u sprint backlog. Na osnovi sprint backloga sastavljaju se ciljevi sprinta, a sastanak završava pristankom cijelog tima da preuzme odgovornost i obveže se ispuniti te ciljeve u idućih 10 kalendarskih dana.

Tijekom trajanja sprinta izbjegava se svaka mogućnost vanjskog utjecaja na ciljeve sprinta, a svi eventualni zahtjevi za promjenama dodaju se u product backlog i predmet su rasprave za sljedeći sprint.

Tijekom sprinta članovi razvojnog tima imaju samo dvije obveze, ispuniti ciljeve sprinta i redovito dolaziti na dnevne scrum sastanke.

Na kraju uspješno završenog sprinta pakira se isporučeno, odnosno inkrement sprinta te se prezentira vlasniku proizvoda (product owner), korisnicima i drugim zainteresiranim stranama. Nakon što se napravi retrospektiva sprinta i unesu podaci u product backlog, sprint je službeno završio, a time i sljedeći počeo.

Razvojni tim treba biti dovoljno malen kako bi bio brz, ali i dovoljno velik kako bi mogao napraviti značajnu količinu posla u okviru svakog sprinta.

Manje od 3 člana umanjuje interakciju, ali i dobit zbog smanjene produktivnosti. Također, raspolažu ograničenim skupom vještina što povećava vjerojatnost da potencijalno isporučiv inkrement proizvoda ne bude gotov na vrijeme.

S druge strane, veliki razvojni timovi su previše kompleksni da bi iskustvena kontrola procesa bila korisna.

Uloge vlasnika proizvoda i Scrum mastera nisu uključene u ovaj broj, osim ako i sami ne sudjeluju u obavljanju posla s Popisa stavki za Sprint.

Kako bismo sumirali odgovor na to pitanje, vratimo se definiciji – Scrum je okvir za razvoj, isporuku i održavanje složenih proizvoda. U praksi se najčešće primjenjuje u područjima kao što su:

• istraživanje i prepoznavanje potencijalnih tržišta, tehnologija i mogućnosti proizvoda;
• razvoj i poboljšavanje proizvoda;
• održavanje i osvježavanje proizvoda.

Transparentnost, provjera i prilagodba stupovi su realizacije Scruma, a njihovom primjenom se:

Postoji mnogo kontroverzi oko definicije onoga što čini uspješan projekt. Za neke je uspješan onaj proizvod koji se isporuči na vrijeme i zadovoljava budžetna ograničenja, a za druge je važnije koju vrijednost donosi i koliko brzo nudi povrat ulaganja. Iako u različitim postotcima, istraživanja pokazuju prednost agilnog rada u odnosu na waterfall metodu. Dokument koji je izradilo 17 razvojnih stručnjaka poznat kao Manifesto for Agile Software Development između ostalog donosi da se agilnim pristupom naučilo više cijeniti:

Drugim riječima, iako se cijene vrijednosti na desnoj strani, veće je povjerenje u one na lijevoj.

U konačnici koju god metodu odabrali bitno je da ona odgovara i primjenjiva je na proizvod i organizaciju rada naručitelja, a najbitniji su ljudi koji sudjeluju u definiranju i realizaciji proizvoda.