Uvod

Scrum je inkrementalni i iterativni agilni okvir za razvoj softvera za upravljanje razvojem

proizvoda. Prvi put su ga definisali kao „fleksibilna, holistička strategija razvoja proizvoda u kojoj
razvojni tim radi kao jedinica da bi se postigao zajednički cilj“ 1986. godine od strane Hirotaka
Takeučija i Ikudžira Nonake u igrici za razvoj novih proizvoda. Ova strategija dovodi u pitanje
pretpostavke o „tradicionalnom, sekvencijalnom pristupu“ razvoju proizvoda i podstiče timove
da se samoorganizuju podstičući blisku onlajn saradnju svih članova tima, kao i komunikaciju
licem u lice među svim članovima tima i disciplinama u projekat.

Ključni princip scrum-a je „promenljivost zahteva“, odnosno prepoznaje činjenicu da tokom

proizvodnih procesa kupci mogu da promene mišljenje o tome šta žele i šta im je potrebno. Ovi
nepredviđeni izazovi ne mogu se lako rešiti na tradicionalan prediktivni ili planski način i stoga
je to prednost scrum/agilne metodologije. Scrum usvaja empirijski pristup—prihvatajući da se
problem ne može u potpunosti definisati, umesto toga se fokusira na odgovaranje na nove
zahteve i prilagođavanje tehnologijama koje se razvijaju i promenama u tržišnim uslovima.

Scrum koristi procese donošenja odluka u realnom vremenu zasnovane na stvarnim događajima
i informacijama. Za to su potrebni specijalizovani timovi sposobni za samoupravljanje,
komunikaciju i donošenje odluka. Scrum je agilna metodologija koja se može primeniti na skoro
svaki projekat; međutim, najčešće se koristi u razvoju softvera. Scrum proces je pogodan za
projekte sa zahtevima koji se brzo menjaju ili veoma nastali.1

1
Dr. Mark C. Paulk, Noopur Davis, „On Empirical Research Into Scrum“ , Institute for Software Research
Carnegie Mellon University, Pittsburgh (2004), p. 15-25
Šta je tako posebno u scrum-u?

Scrum je alat, okvir koji se može koristiti za izgradnju složenih proizvoda. . To je „fleksibilna
strategija razvoja proizvoda. Ne propisuje ništa od uobičajenog inženjeringa, ljudi, upravljanja
rizikom ili druge prakse.

Pošto Scrum ne opisuje eksplicitno nijednu inženjersku praksu, moguće je, a ponekad i poželjno,
razmotriti ne-Scrum prakse koje mogu biti usko povezane sa uspehom Scrum-a. Na primer,
razvoj vođen testom se pokazao uspešnim za agilne projekte, ali nije eksplicitna Scrum praksa.
Scrum se često primenjuje u kombinaciji sa metodama kao što je ekstremno programiranje koje
utiče na uspeh Scrum-a.

Ono što Scrum pruža su povratne informacije tako da neko ko koristi Scrum može poboljšati
rezultate. Na primer, ako neko želi produktivnost i kvalitet i može da ima zajednički tim, Scrum
će pomoći da se pronađe najbolji mogući način. Ako osoba počne sa disperzovanim timom i
uporedi njegovu produktivnost sa drugim timom koji se nalazi zajedno, može se doći do
zaključaka. Osoba tada može inteligentno da donese odluku na osnovu dobijenih zaključaka i
može da izvrši promene u skladu sa tim. Dakle, specijalnost ološa leži u stalnom unapređenju
procesa.

Ispravno korišćenje Scrum-a znači poštovanje svih njegovih pravila, koja sve (transparentno)
izlažu na uvid i prilagođavanje. Inteligentna osoba bi onda pregledala šta Scrum čini
transparentnim i napravila izmene kako bi optimizovala rezultate. Pretpostavlja se da su
promene troškovno opravdane.

Scrum se može savršeno koristiti i ignorisati ono što je učinjeno transparentnim. Scrum se može
koristiti nesavršeno i uzimajući u obzir neke od stvari koje su učinjene transparentnim. Neko ko
savršeno koristi Scrum i deluje inteligentnije na ono što je postalo transparentno, nadmašiće
bilo koga drugog. 2

Scrum prakse i uloge

Scrum alijansa je objavila ―Scrum vodič‖ koji daje formalnu definiciju metode [SA09].
Sutherland i Vodde su kreirali Testove za procenu statusa timova koji tvrde da koriste Scrum.
Silver, još jedan član Scrum alijanse, takođe je identifikovao ključne karakteristike i prakse za
Scrum. Ovi opisi Scrum-a i njegovih praksi su razrađeni i pojašnjeni u različitim izveštajima i
obukama, kao i povezanim knjigama. Sledeći kratak opis Scrum praksi i uloga naglašava
specifične aspekte Scrum-a koji se mogu istražiti da bi se potvrdilo da je implementacija Scrum-
2
―THE SCRUM ROLES-CEREMONIES-ARTIFACTS , dostupno na http://www.agiletrick.com/about-agile/agile-
frameworks/
a važeća. U mnogim slučajevima Scrum se usvaja kao celina sa malo promena, ali u nekim
slučajevima se usvaja u „prilagođenom“ obliku. Ovo krojenje može, ali i ne mora, predstavljati
razumnu adaptaciju originalne metode. Neprikladne varijacije Scrum-a poznate su kao
„ScrumButs“. Scrum je „skup“ znanja koji se najbolje usvaja u celini; malo je verovatno da će
usvajanje po komadu ili neprikladno prilagođeno usvajanje Scrum praksi postići očekivana
ponašanja i koristi od metode.

Sa scrum-om, proizvod je izgrađen u nizu iteracija fiksne dužine koje se nazivaju sprintovi.
Sprintovi su ciklusi fiksnog trajanja tokom kojih se proizvod gradi i isporučuje radi povratnih
informacija. Sprint je jedna iteracija od mesec dana ili manje koja je dosledne dužine tokom
razvojnog napora. Samo Vlasnik proizvoda ima ovlašćenje da otkaže Sprint. Prekretnice – tj. kraj
sprinta – dolaze često i u redovnim intervalima, donoseći sa sobom osećaj opipljivog napretka
sa svakim ciklusom koji daje energiju svima i kontinuirano inspiriše tim, a takođe pomaže da se
otkriju nedostaci ili pogrešno shvaćeni zahtevi u ranoj fazi . Kratke iteracije takođe jačaju
važnost dobre procene – ponavljajuća borba u projektima vodopada.

Scrum uloge

Za razliku od klasičnih metoda upravljanja projektima, Scrum nema i nije mu potreban

menadžer proizvoda, menadžer zadataka ili vođa tima. Scrum tim ima malo drugačiji sastav od
tradicionalnog projekta vodopada, sa tri specifične uloge:

• Vlasnik proizvoda,
• Scrum Master, i
• Razvojni tim.

Ove tri uloge su jednake i sve imaju određene odgovornosti.

Vlasnik proizvoda je odgovoran za viziju proizvoda, prikupljanje i određivanje prioriteta zahteva,

kontrolu budžeta i ROI. Scrum Master se brine o problemima, preuzima odgovornost da se
pravila Scrum-a na odgovarajući način poštuju i on takođe trenira tim. Tim Scrum-a je
samoorganizovana grupa ljudi, odgovornih za kreiranje i kvalitet proizvoda. A pošto su scrum
timovi međusobno funkcionalni, „tim za razvoj“ pored programera uključuje testere, dizajnere i
operativne inženjere. Pored ove tri uloge postoje još neki Stejkholderi, koji npr. služi kao
posmatrač ili savetnik.
 Slika 1. Scrum uloge i njihov odnos.

Epske priče

Epska priča je skup posla koji se može podeliti na specifične zadatke (koje se nazivaju korisničke
priče) na osnovu potreba/zahteva kupaca ili krajnjih korisnika. Epics je važna praksa za agilne i
DevOps timove.

Kada usvajate agile i DevOps, epska priča služi za upravljanje zadacima. To je definisani obim
posla koji je segmentiran u specifične zadatke (nazvane „priče“ ili „korisničke priče“) na osnovu
potreba/zahteva kupaca ili krajnjih korisnika.3

Epske priče su koristan način da organizujete svoj rad i da kreirate hijerarhiju. Ideja je da se
posao razbije na delove koji se mogu isporučiti tako da veliki projekti zaista mogu da se završe i
da nastavite da redovno isporučujete vrednost svojim klijentima. Epice pomažu timovima da
razbiju svoj posao, dok nastavljaju da rade ka većem cilju.

Održavanje agilnosti prilikom organizovanja velikih zadataka, kao što su epovi, nije mali zadatak
(namera reči). Učenje o tome kako su epovi povezani sa zdravim agilnim i najboljim praksama
DevOps-a je neophodna veština bez obzira na veličinu vaše organizacije.

Šta je agilni ep?

3
Agile epics: definition, examples, and templates, https://www.atlassian.com/agile/project-management/epics
Ep je veliki deo dela koji se može razbiti na nekoliko manjih priča, ili se ponekad nazivati
„Problemi“ u Jira. Epice često obuhvataju više timova, na više projekata, a čak se mogu pratiti
na više ploča.

Epi se skoro uvek isporučuju u nizu sprinteva. Kako tim sazna više o epu kroz razvoj i povratne
informacije kupaca, korisničke priče će se dodavati i uklanjati po potrebi. To je ključ sa agilnim
epovima: Obim je fleksibilan, zasnovan na povratnim informacijama kupaca i timskom tempu.

Stvaranje agilnog epa

Kada kreirate novi ep, uzmite u obzir druge alate za planiranje i organizaciju koje vaš tim možda
već ima. Pravljenje epizoda oko tromesečnih ciljeva tima ili OKR-a je odličan početak. Kada
pravite ep, uzmite u obzir sledeće:4

• Izveštavanje — Kreirajte epove za projekte na koje će menadžeri i rukovodioci želeti da

drže na oku.
• Pripovedanje priča — Koristite epove i priče koje se u njih uvijaju kao mehanizam da
ispričate priču o tome kako ste došli do trenutnog stanja funkcije ili proizvoda.
• Kultura — Neka organizaciona kultura diktira veličinu i granularnost epa.
• Vreme – Većina razvojnih timova se oslanja na okvire za procenu umesto na vreme, ali
vredna je provera da biste bili sigurni da će vašim epizodama biti potrebno nekoliko
nedelja da se završe. Ne predugačko i ne prekratko.

Scrum događaji
Propisani događaji se koriste u Scrum-u da bi se stvorila regularnost i smanjila potreba za
sastancima koji nisu definisani u Scrum-u. Svi događaji su vremenski ograničeni, tako da svaki
događaj ima maksimalno trajanje. Kada Sprint počne, njegovo trajanje je fiksno i ne može se
skratiti ili produžiti. Preostali događaji se mogu završiti kad god se postigne svrha događaja,
osiguravajući da se potroši odgovarajuća količina vremena bez dopuštanja gubitka u procesu.

Osim samog Sprinta, koji je kontejner za sve druge događaje, svaki događaj u Scrum-u je
formalna prilika da se nešto pregleda i prilagodi. Ovi događaji su posebno osmišljeni da
omoguće kritičnu transparentnost i inspekciju. Neuključivanje bilo kojeg od ovih događaja
rezultira smanjenom transparentnošću i izgubljena je prilika za inspekciju i prilagođavanje.

4
Chhavi, A. Agile testing with Scrum-A survey. International Journal of Advanced Research in Computer Science and
Software Engineering. 2013; 3:452-459.
Sprint

Srce Scrum-a je Sprint, vremenski okvir od mesec dana ili manje tokom kojeg se kreira
„Gotovo“, upotrebljivo i potencijalno slobodno povećanje proizvoda. Sprintovi imaju
konzistentno trajanje tokom razvojnog napora. Novi Sprint počinje odmah nakon završetka
prethodnog Sprinta.

Sprintovi sadrže i sastoje se od planiranja sprinta, dnevnog skrama, razvojnog rada, pregleda
sprinta i retrospektive sprinta.5

Tokom sprinta:

• Ne vrše se nikakve izmene koje bi ugrozile cilj Sprinta;

• Ciljevi kvaliteta se ne smanjuju; i,
• Obim se može razjasniti i ponovo pregovarati između vlasnika proizvoda i razvojnog tima
kako se više sazna.

Svaki Sprint se može smatrati projektom sa ne više od jednomesečnog horizonta. Kao i projekti,
sprintovi se koriste za postizanje nečega. Svaki sprint ima cilj šta treba da se izgradi, dizajn i
fleksibilan plan koji će voditi njegovu izgradnju, rad i rezultirajući prirast proizvoda.

Sprintovi su ograničeni na jedan kalendarski mesec. Kada je horizont Sprinta predugačak,

definicija onoga što se gradi može se promeniti, složenost može porasti, a rizik se može
povećati. Sprintovi omogućavaju predvidljivost obezbeđivanjem inspekcije i prilagođavanja
napretka ka cilju sprinta najmanje svakog kalendarskog meseca. Sprintovi takođe ograničavaju
rizik na jedan kalendarski mesec troškova.

Planiranje sprinta

Radovi koji će se izvoditi u Sprintu planirani su na Planiranju Sprinta. Ovaj plan je kreiran
zajedničkim radom celog Scrum tima.

Planiranje sprinta je vremenski ograničeno na maksimalno osam sati za jednomesečni sprint. Za

kraće sprintove, događaj je obično kraći. Scrum Master obezbeđuje da se događaj održi i da
polaznici razumeju njegovu svrhu. Scrum Master uči Scrum tim da ga drži unutar vremenskog
okvira.

Planiranje sprinta odgovara na sledeće:

• Šta se može isporučiti u inkrementu koji je rezultat predstojećeg Sprinta?

5
K. Schwaber & J. Sutherland, „The Definitive Guide to Scrum: The Rules of the Game“, (November 2017), p. 9-13
 • Kako će se postići rad potreban za isporuku Inkrementa?6

PROCENA NAPORA

PROCENA PRIČE

Tačka priče je jedan broj koji predstavlja sav rad koji je potreban celom timu da napravi konačni
proizvod. Kao rezultat toga, da bi se izvršila procena na osnovu tačaka priče, potrebno je
višestruko funkcionalno predstavljanje svih potrebnih veština i znanja u podacima, alatima i
infrastrukturi Platforme poslovne inteligencije tokom sastanka o planiranju sprinta.

Poeni priče se koriste za visoku procenu korisničkih priča. Obično se zasnivaju na isporuci sličnih
korisničkih priča u prethodnim Sprintovima. Ovo pretpostavlja da su projektni tim, podaci i
infrastruktura relativno konstantni između jednog i drugog projekta. Veličina tačke priče za dati
projektni tim će se vremenom normalizovati.

Sve priče treba da budu dodeljene kao procenjeni napor ili trošak za implementaciju. Koristimo
modifikovanu Fibonačijevu seriju, kao što su 1, 2, 3, 5, 8, 13, 20, 40 i 100, da predstavimo napor.
Ovo podstiče da se funkcije podele na najmanji mogući zadatak i pruža realističniji opseg
procene.

PROCENA ZADATAKA

Procena zadatka se vrši na nivou Sprinta. Tokom sesije planiranja sprinta, tim deli korisničke
priče u njihove složene zadatke da bi odredio kako će biti isporučene. Proces dekompozicije
rešenja može otkriti dodatne zadatke ili složenije zadatke koji nisu bili očigledni tokom procene
zasnovane na Tački priče visokog nivoa, a koji utiču na ono što je planirano da se isporuči. Obim
Sprinta može se ponovo pregovarati sa vlasnikom proizvoda ako je to slučaj. Za razliku od Stori
Points, ove procene su indikativna ideja o tome koliko će im vremena trebati u idealnom svetu.

PROCENA VREMENA

Pretvaranje procenjenih troškova u procenjeno vreme je veoma jednostavno. Postoje 2

primarna modifikatora koje koristimo. Režija zaposlenih i tačnost procene (ili rizika).

Ovo je procentualni modifikator raspoloživosti osoblja za rad na specifičnim projektnim

zadacima. Omogućava vam da uzmete u obzir faktore kao što su procenjeni odmor, bolest,
6
Schild, J., Walter, R., and Masuch, M. “ABC-Sprints: adapting Scrum toacademic game development courses”.
2010. Proceedings of the Fifth International Conference on the Foundations of Digital Games (FDG '10) ACM, New
York, NY, USA, pp.187-194.
pauze, scrum sastanci itd. Modifikator industrijskog standarda je 25%-40%, mada biste ovo
trebalo da izmenite po potrebi. Da biste izračunali režijske troškove osoblja, koristite sledeći
proces;7

radno vreme = (sati dnevno * dani po sprintu * osoblje) – planirani odmor

sati projekta = zbir stvarnih (od poslednjeg sprinta)

režijski troškovi osoblja = (radni sati/projektni sati) – 1

SCRUM MEETING

Svrha dnevnog stand-up sastanka je da obezbedi dosledan fokus na inkrementalni napredak i

isporuku prikazanu vlasniku proizvoda. Namera je da bude informativan i interaktivan i da
uskladi razumevanje tima o tome na čemu se radi, ko radi i njegovom trenutnom statusu.

Ovaj sastanak se sastoji od vlasnika proizvoda, Scrum Master-a i projektnog tima i vremenski je
ograničen na 15 minuta.8

Svi učesnici treba da odgovore na sledeća tri pitanja:

1. Šta ste postigli juče?

2. Šta ćete danas postići?

3. Koja prepreka može da vas spreči da danas postignete svoj cilj?

Cilj Scrum Master-a je da ukloni svaku prepreku koju je tim identifikovao.

Slika2. DNEVNI TOK RADA STANDAP-a

7
EVAN LEYBOURN, DIRECTING THE AGILE ORGANISATION (2005), p. 25-27
8
EVAN LEYBOURN, DIRECTING THE AGILE ORGANISATION (2005), p. 25-27
Projekti sa više timova treba da održavaju skup skrum-a, takođe vremenski ograničen na 15
minuta, nakon početnih scrum-ova. Ovaj sastanak bi trebalo da okupi Scrum majstore iz više
timova da odgovore na ista 3 pitanja kao i ranije, ali koja se odnose na njihove timove.

Zaključak

Razvoj softvera korišćenjem agilnih metodologija postaje sve veća realnost u svakodnevnom
životu kompanija za razvoj softvera. Agilnost donosi kvalitet u razvoj softvera i proces
upravljanja. Da bi se dodala vrednost konačnom softveru, mora se imati tim za dobro
strukturisanje koji prati metodologiju i koristi ispravne strategije. Hibridizacija scrum-a sa
drugim metodologijama razvoja softvera je uobičajena jer scrum ne pokriva ceo životni ciklus
razvoja proizvoda; stoga, organizacije nalaze potrebu da dodaju dodatne procese kako bi
stvorile sveobuhvatniju implementaciju. Različiti autori i zajednice ljudi koji koriste scrum
takođe su predložili detaljnije tehnike kako primeniti ili prilagoditi scrum određenim
problemima ili organizacijama. Takođe, projekti u kojima su programeri geografski odvojeni su
manje pogodni za scrum pristup. Pošto su scrum sprintovi kratki, manje vremena je dostupno za
iterativno testiranje, što otežava održavanje kontrole kvaliteta za takve projekte kada se koristi
scrum pristup.
Literatura

1. Dr. Mark C. Paulk, Noopur Davis, „On Empirical Research Into Scrum“ , Institute for
Software Research
2. Carnegie Mellon University, Pittsburgh (2004), p. 15-25
3. Chhavi, A. Agile testing with Scrum-A survey. International Journal of Advanced Research
in Computer Science and Software Engineering. 2013; 3:452-459.
4. Schwaber K. & Sutherland J, „The Definitive Guide to Scrum: The Rules of the Game“,
(November 2017), p. 9-13
5. Schild, J., Walter, R., and Masuch, M. “ABC-Sprints: adapting Scrum toacademic game
development courses”. 2010. Proceedings of the Fifth International Conference on the
Foundations of Digital Games (FDG '10) ACM, New York, NY, USA, pp.187-194.
6. EVAN LEYBOURN, DIRECTING THE AGILE ORGANISATION (2005), p. 25-27

Internet izvori

1. THE SCRUM ROLES-CEREMONIES-ARTIFACTS , dostupno na

http://www.agiletrick.com/about-agile/agile-frameworks/
2. Agile epics: definition, examples, and templates,
https://www.atlassian.com/agile/project-management/epics