Subotica, 2014.

godina

UNIVERZITET U NOVOM SADU

EKONOMSKI FAKULET
SUBOTICA

SCRUM U AGILNOM RAZVOJU SOFTVERA

Mentor:
prof. dr Pere Tumbas

Student-autor:
Vladimir Vasovi

Subotica, 2014. godina

Sadraj
1. Uopte o softverskom inenjeringu i razliitim metodologijama razvoja softvera ..... 1
1.1. Pojam i istorijat softverskog inenjerstva ............................................................. 1
1.2. ivotni ciklus razvoja softvera .............................................................................. 2
1.3. CASE alati ............................................................................................................. 2
1.4. Kratak predled najznaajnijih metodologija razvoja softvera ............................... 3
1.4.1. Model vodopada (Waterfall) .......................................................................... 5
1.4.2. Model prototipskog razvoja ............................................................................ 5
1.4.3. Spiralni model ................................................................................................ 6
2. Uopte o agilnim metodologijama razvoja softvera .................................................... 6
2.1. Agilni Manifest ..................................................................................................... 7
2.1.1. etiri vrednosti Agilnog Manifesta ................................................................ 7
2.1.2. Dvanaest principa Agilnog Manifesta ............................................................ 8
2.2. Specifinosti pojedinih agilnih metodologija ........................................................ 9
2.4. Iskustva primene agilnih metodologija ................................................................. 9
3. Uopte o Scrumu ........................................................................................................ 10
3.1. Pojam i istorijat Scrum-a ..................................................................................... 10
3.2. Uloge ................................................................................................................... 12
3.2.1. Vlasnik proizvoda (Product Owner) ............................................................. 13
3.2.2. Scrum Master ............................................................................................... 13
3.2.3. Razvojni tim (Development Team) .............................................................. 13
3.3. Dogaaji .............................................................................................................. 14
3.3.1. Sprint ............................................................................................................ 14
3.3.2. Sastanak planiranja Sprinta (Sprinta Sprint Planning) ................................. 15
3.3.3. Dnevni Scrum sastanak (Daily Scrum) ........................................................ 16
3.3.4. Sastanak pregleda Sprinta (Sprint Review) .................................................. 16
3.3.5. Sastanak ostvrta na Sprint (Sprint Retrospective) ........................................ 16
3.4. Artefakti .............................................................................................................. 17
3.4.1. Lista zahteva proizvoda (Product Backlog) ................................................. 17
3.4.2. Lista zahteva Sprinta (Sprint Backlog) ........................................................ 18
3.4.3. Inkrement proizvoda (Product Increment) ................................................... 18
3.4.4. Grafikon sagorevanja (Burndown Chart) ..................................................... 19
3.5. Terminologija ...................................................................................................... 19

SCRUM U AGILNOM RAZVOJU SOFTVERA

1. Uopte o softverskom inenjeringu i razliitim metodologijama
razvoja softvera
1.1. Pojam i istorijat softverskog inenjeringa
Postoji vie definicija softverskog inenjeringa. Jedna od najboljih i najpreciznijih je
ona koju daje IEEE (Institute for Electrical and Electronics Engineers): softverski
inenjering predstavlja primenu sistematinog, disciplinovanog i merljivog pristupa
razvoju, uvoenju i odravanju softvera, tj. primenu inenjeringa na softver.[11] Kod
razjanjenja pojma softverskog inenjerstva bitno je razumeti nekoliko kljunih stvari:
prva, da je programiranje samo jedna u nizu aktivnosti u razvoju softvera i na nju otpada
svega 20% ukupnih aktivnosti razvoja softvera, tj. ivotnog ciklusa razvoja softvera[11];
druga, da se softversko inenjerstvo bavi ne samo tehnikim aspektima izgradnje
softvera, ve i menaderskim problemima poput organizacije programerskih timova,
vremenskim i finansijskim aspektima projekata razvoja softvera i sl; i trea, da
softversko inenjerstvo nema za cilj samo izradu softverskog proizvoda, nego i razvoj
na trokovno delotvoran nain, to podrazumeva da se sa ogranienim resursima i u
ogranienom vremenskom periodu kreira softverski proizvod visokog kvaliteta[11].
Pojam softverski inenjering je prvi put upotrebljen 1968. godine kao naziv za naunu
konferenciju organizovanu od strane naunog komiteta NATO-a odranu u Zapadnoj
Nemakoj - NATO Software Engineering Conference. Na toj konferenciji su
prisustvovali meunarodni softverski strunjaci koji su eleli da definiu provereno
najbolje prakse za razvoj softvera kakve su ve postojale u ostalim inenjerskim
disciplinama. Glavni rezultat te konferencije je bio izvetaj kojim se definie kako treba
razvijati softver.[21] Predloena reenja su se oslanjala na primenu principa i metoda iz
domena graevinskog i mainskog inenjerstva, naravno, u onoj meri u kojoj je njihova
primena bila mogua u razvoju softvera.
Disciplina softverskog inenjerstva je nastala u cilju pokuaja reavanja problema
niskog kvaliteta softvera, redovnog probijanja vremenskih rokova i budeta predvienih
za razvoj softvera. Ti problemi su nastajali usled rapidnog rasta mogunosti ondanjeg
raunarskog hardvera (npr. usled pojave mainframe raunara IBM S/360[11]) zbog ega
su porasle mogunosti reavanja razliitih naunih, vojnih i poslovnih problema uz
pomo raunara, ali to je iziskivalo i rast
Slika 1: mainframe raunar IBM S/3602[25]
sloenosti softvera (to najbolje ilustruje
projekat razvoja operativnog sistema
OS/360 za raunar IBM S/360). To je
nazvano
"softverska
kriza"
i
predstavljala je situaciju u kojoj uopte ne
postoje definisane smernice i preporuke za
razvoj softvera i za upravljanje projektima
razvoja
softvera.[3] Programeri
su
jednostavno
postavljali
korisnicima
1

pitanja u vezi sa onim to bi softver trebalo da radi i to bi predstavljalo osnovu za

poetak rada na programiranju.[3] Ponekad je takav pristup davao solidne rezultate, ali se
mnogo ee zavravao neuspehom.[3] Zato je bilo neophodno uvesti vie reda i
sistematinosti u razvoj softvera. Dakle, softverski inenjering je nastalo kao
odgovor na softversku krizu.
U narednim decenijama dolo je do pojave brojnih novih pristupa koji su nastojali da
okonaju softversku krizu. Tokom 1970-ih veliku popularnost dobija strukturni
pristup razvoju softvera (najpre strukturno programiranje, a zatim i strukturni dizajn i
analiza), tokom 1980-ih i 1990-ih objektno orijentisani pristup (takoe najpre
objektno orijentisano programiranje, a zatim i objektno orijentisani dizajn i analiza), a
tokom 2000-ih agilni pristup, emu e biti posveen najvei deo ovog rada.

1.2. ivotni ciklus razvoja softvera

ivotni ciklus razvoja softvera (SLDC - Software Development Life Cycle) je termin
koji se koristi u softverskom inenjeringu i koji opisuje proces planiranja, kreiranja,
testiranja i odravanja softvera. Sastoji se iz posebnih, jasno definisanih faza ili
aktivnosti kroz koje prolaze strunjaci razliitih profila (sistem analitiari, projektanti,
programeri...) i zajedno sa korisnicima kreiraju softverski proizvod. Dakle, svaki
projekat razvoja softvera, bez obzira da li je mali ili veliki, prolazi kroz odreene faze
kao to su npr. planiranje, analiza, dizajn, implementacija, testiranje i odravanje.
Slika 2: ivotni ciklus razvoja softvera (SDLC)
Analiza
analiza informacionih potreba kranjih korisnika
i specifikacija njihovih zahteva

Odravanje
modifikacija softverskog reenja nakon
isporuke, korekcija greaka i poboljanje
karakteristika - nove verzije i rilizi (releases)

Testiranje
sistemsko testiranje (system testing) i
korisniko testiranje (user acceptance testing)

Dizajn
prevoenje korisnikih specifikacija u tehnike
specifikacije - arhitektonski dizajn visokog
nivoa i detaljan dizajn niskog nivoa - programa,
baze podata i korisnikog interfejsa

Implementacija
transformacija dizajna u programski kod
(coding), testiranje jedinica koda (unit testing) i
integraciono testiranje (integration testing)

1.3. CASE alati

CASE (Computer Aided Software Engineering) alati su softverski proizvodi koje
koriste softverski inenjeri za razvoj drugih softverskih proizvoda.[13] Namenjeni su
automatizaciji pojedinih ili svih aktivnosti ivotnog ciklusa razvoja softvera. Tako
postoje alati za modelovanje poslovnih procesa, alati za planiranje razvoja softvera, alati
za analizu korisnikih zahteva, za dizajn, za automatsko generisanje dokumentacije, za
izradu prototipova, za dizajn korisnikog interfejsa, za upravljanje projektima, za
2

automatsko generisanje programskog koda, za testiranje i upravljanje kvalitetom

softvera, za podrku odravanja... itd.
CASE alati ne predstavljaju zamenu za pojedine metode razvoja softvera, ve njihovu
dopunu.[13] Cilj njihove primene je poveanje produktivnosti rada softverskih inenjera,
poveanje kvaliteta softvera, skraenje vremena i smanjenje trokova razvoja softvera,
naroito kod velikih i sloenih projekata. Zato je njihovo korienje interatktivno,
prilagoeno korisniku uz naglasak na upotrebu grafike.[13]
Glavna komponenta strukture CASE alata je njegova centralna baza podataka (tj.
skladite ili ekciklopedija) u koju se smetaju svi potrebni podaci i informacije o
softverskom proizvodu koji se razvija i o samom projektu. Ona omoguava da se
pojedine faze razvoja softvera automatski meusobno nadovezuju, tj. da se rezultati iz
odreene faze stavljaju na raspolaganje alatima u narednim fazama procesa razvoja.[13]
CASE alati se mogu klasifikovati prema razliitim kiruterijumima. Ukoliko se posmatra
namena alata u smislu broja zadataka i aktivnosti ivotnog ciklusa razvoja softvera iju
automatizaciju CASE alat podrava, dele se na:[13]
Lower CASE alate - namenjeni su automatizaciji faze planiranja i upravljanja
projektom razvoja softvera
Middle CASE alate - namenjeni su automatizaciji faza analize i dizajna softvera
Upper CASE alate - namenjeni su automatizaciji faza programiranja, testiranja i
odravanja softvera.
Ukoliko se posmatra stepen integrisanosti, CASE alati se dele na:[13]
CASE tools - automatizuju pojedine aktivnosti u fazama razvoja softvera
CASE workbench - automatizuju sve aktivnosti u fazama razvoja softvera
CASE environments (I-CASE) - automatizuju itav ili vei deo procesa razvoja
softvera.
Za uspenu primenu CASE alata je veoma vano da osobe koje rade sa njima budu
adekvatno obuene za njihovo korienje.[13] Uspenost primene CASE alata zavisi ne
samo od kvaliteta samih alata, ve i od sposobnosti i znanja osoba koje ih koriste.[13]
Takoe je vano da svi alati budu integrisani, da bi podaci kojima isti upravljaju bili
integrisani. Integrisani alati imaju zajedniki korisniki interfejs i skladite podataka,
tako da se podaci mogu lako deliti izmeu pojedinih alata i aktivnosti ivotnog ciklusa
razvoja softvera bez potrebe za njihovom konverzijom iz jednog formata u drugi.[13]
Bitno je istai i da CASE alati uspeno automatizuju veinu rutinskih aktivnosti razvoja
softvera, dok je njihova primena u kreativnijim aktivnostima jo uvek uglavnom
neuspena.[13]

1.4. Kratak pregled najznaajnijih metodologija razvoja softvera

Brojne su metodologije (ili metodi, modeli, procesi, pristupi) koje se danas koriste u
razvoju softvera. Mogue ih je podeliti u dve velike grupe: tradicionalne i agilne. U
tradicionalne metodologije spadaju strukturalne i objektne metodlogije. Strukturalne

su veliku popularnost stekle tokom 1970-ih i 1980-ih godina, objekte tokom 1990-ih, a
agilne tokom 2000-ih.
Takoe je mogua podela na kaskadni pristup i iterativni pristup razvoju softvera.[4]
Osnova razlika izmeu ova dva pristupa je nain podele projekta na manje delove. [4]
U kaskadnom pristupu (waterfall) projekat delimo po osnovu pojedinih aktivnosti
ivotnog ciklusa razvoja softvera.[4] Na primer, jednogodinji projekat moe imati
dvomesenu fazu analize, etvoromesenu fazu dizajna, tromesenu fazu programiranja
i na kraju tromeseno testiranje. [4]
U iterativnom pristupu projekat delimo na podskupove koje sadre odreene
funkcionalnosti softvera.[4] Na primer, godina moe da se podeli na tromesene
iteracije.[4] U prvoj iteraciji uzima se etvrtina zahteva i izvravaju se sve aktivnosti
ivotnog ciklusa proizvoda za to tromeseje: analiza, dizajn, programiranje i testiranje.[4]
Na kraju prve iteracije imamo softverski proizvod - inkrement - sa etvrtinom
potrebnih funkcionalnosti.[4] Zatim prelazimo na drugu iteraciju, i posle est meseci od
poetka rada na projektu imamo jo jedan inkrement i proizvod sa polovinom potrebnih
funkcionalnosti.[4] Nakon tree imamo tri etvrtine potrebnih funkcionalnosti, a nakon
etvrte sve potrebne funckionalnosti, nakon ega se realizacija projekta okonava.
Dakle, svakim inkrementom se dodaju nove funcionalnosti proizvodu, dok se postojee
zadravaju.
Kaskadni pristup se odnosi na model vodopada (waterfall model), dok se iterativni
pristup odnosi na ostale modele kao to su: modifikovani watefall modeli, model
prototipskog razvoja, spiralni model, RUP (Rational Unified Process), RAD (Rapid
Application Development) i sve agilne metodologije, ukljuujui i Scrum.
Generalno posmatrano, iterativni pristup se danas smatra "modernim" pristupom i
mnogo ee se primenjuje, dok se kaskadni pristup smatra "zastarelim" i uglavnom se
mnogo manje primenjuje nego nekad.[4] Osnovni razlog za naputanje kaskadnog
pristupa je tekoa utvrivanja da li se projekat u toku realizacije nalazi na pravom
putu.[4] Obino je to mogue utvrditi tek na kraju projekta kada su trokovi bilo kakvih
izmena veoma visoki.[4] Naime, u mnogim projektima dolazi do velike izmene zahteva u
kasnijim fazama realizacije projekta.[4] Kaskadni pristup podrazumeva zamrzavanje
zahteva u ranim fazama i ne dozvoljava promene, ali to nosi sa sobom rizik
isporuivanja proizvoda koji uopte ne odgovara potrebama korisnika. Pristalice
iterativnog pristupa smatraju da su izmene zahteva od strane korisnika neizbene, a
poto taj pristup dozvolja promene, verovatnije je da emo tako kreirati softverski
proizvod koji odgovara potrebama korisnika. Takoe, proizvod je upotrebljiv i pre
zavretka realizacije itavog projekta poto svaki inkrement zadovoljava odreeni
podskup korisnikih zahteva. Dakle, kod iterativnog pristupa postoji povratna sprega i
mogunost ugranje korisnikog iskustva u redefinisani proizvod na jeftiniji nain nego
kod kaskadnog pristupa.

1.4.1. Model vodopada (Waterfall)

Model je dobio naziv po toku aktivnosti i nainu prenoenja rezultata iz jedne u drugu
fazu ivotnog ciklusa razvoja softvera, koji podsea na vodopad.[13] Prvi ga je opisao
Winston W. Royce u svom radu "Upravljanje razvojem velikih softverskih sistema"[6] iz
1970. godine, mada on
Slika 3: Model vodopada
nije upotrebio termin
"vodopad",
niti
je
preporuivao primenu
tog modela.
Strogo je sekvencijalan
to znai da se u
narednu fazu razvoja
prelazi
tek
nakon
zavretka
prethodne
faze. Izlaz iz prethodne
faze je ulaz u narednu
fazu.
To je najstariji model, ali je i najkritikovaniji zbog brojnih slabosti. Ukoliko se prilikom
testiranja otkrije greka iz neke od ranih faza razvoja, trokovi otklanjanja te greke su
priblino jednaki trokovima itavog projekta. Interakcija sa korisnikom je slaba odvija se samo na poetku (prilikom prikupljanja zahteva) i na kraju projekta (prilikom
isporuke proizvoda).[10] Takoe, korisnik moe da pone da upotrebljava softverski
proizvod tek kada je projekat okonan. Pogodan je samo za projekte kod kojih su
korisniki zahtevi nepromenljivi, tj. kod kojih korisnik unapred tano zna ta eli od
softverskog proizvoda.
Kao odgovor na kritike modela vodopada nastale su brojne modifikacije tog modela.
One se razlikuju od "istog" modela vodopada po tome to uvode povratnu spregu
izmeu pojedinih faza razvoja, to smanjuje rizik prenoenja greaka kroz sve faze
razvoja do kraja projekta.

1.4.1. Model prototipskog razvoja

Slika 4: model prototipskog razvoja [13]

Model prototipskog razvoja je iterativni

model, u kojem se za korisnika razvija
prototip budueg proizvoda (najee je to
samo korisniki interfejs), koji simulira
njegove funkcije, sa ciljem da korisnik da
svoje miljenje i odlui koji i kakvi su njegovi
zahtevi.[13] Tako korisnik ve u najranijem
periodu moe videti na koji e se nain
zadovoljiti njegovi zahtevi.[13] Prototip se po
potrebi dorauje, dok se ne dobije konano
prihvatljiva verzija kao osnova za razvoj
5

finalnog proizvoda.[13]
Model prototipskog razvoja zapoinje prikupljanjem zahteva korisnika; zatim sledi brzi
dizajn; nakon toga, razvija se prototip koji slui za preiavanje zahteva; to
preiavanje je iterativno i ponavlja se dok prototip u potpunosti ne zadovolji zahteve
korisnika. [13] Tek kada prototip proe korisniku evaluaciju, tek tada se prelazi u
razvojnu fazu proizvoda.[13]

1.4.2. Spiralni model

Slika 5: spiralni model [13]

Spiralni model objedinjuje

dobre
osobine
modela
vodopada
i
modela
prototipskog razvoja, uz
istovremeno
ukljuivanje
aktivnosti analize rizika.[13]
Razvio ga je Barry Boehm
1988. godine i namenjen je
razvoju velikih, skupih i
sloenih
softverskih
[13]
projekata.

Vizuelno se predstavlja
spiralom
u
kojoj
su
definisane
etiri
faze
razvoja: planiranje, razvoj
alternativa i rizika, inenjering i procene korisnika.[13] Svakom iteracijom se
progresivno razvijaju kompletnije i sloenije verzije proizvoda.[13]
U prvoj iteraciji prikupljaju se zahtevi i planira projekat razvoja, vri se analiza rizika.[13]
Ukoliko postoje neizvesnosti u zahtevima, razvija se prototip zarad bolje spoznaje
zahteva.[13] Nakon to se donese odluka o daljem razvoju, obavlja se inenjering u
svakoj iteraciji i to odabranim modelom (model vodopada ili prototipski model)[13]. Po
zavretku inenjeringa, korisnik ocenjuje proizvod i daje sugestije za njegovu
modifikaciju.[13] Zatim zapoinje naredna iteracija. Svaka iteracija zahteva analizu
rizika i donoenje odluke "nastaviti" ili "ne nastaviti" dalji razvoj.[13] Ukoliko je rizik
isuvie visok, projekat se okonava i zadrava se u upotrebi proizvod nastao u
prethodnim iteracijama.[13]

2. Uopte o agilnim metodologijama razvoja softvera

Agilni pristup razvoju softvera se ne odnosi na jednu metodologiju razvoja softvera, ve
je to krovni termin za vie razliitih metodologija. To je filozofija, stil razvoja softvera,
pre nego metodologija. Osnovna zajednika paradigma svih agilnih metodologija je
iterativno-inkrementalni razvoj (IID - Iterative and Incremental Development) to
znai da se razvoj odvija u kratkim iteracijama koje su vremenski ograniene
(timeboxed) i traju 1 do 4 nedelje, a nakon svake iteracije se isporuuje funkcionalan
softver (inkrement). To omoguuje brz odziv na promene.[2] Klijent u svakom trenutku
6

diktira razvoj.[2] Takoe, agilne metodologije su orijentisane vie ka ljudima nego ka

procesima kao i komunikaciji i interakciji izmeu njih. Agilni timovi su
samoorganizovani i viefunkcionalni.
Najpoznatije agilne metodologije su:

Ekstremno programiranje (XP - Extreme Programming)

Scrum
Razvoj na bazi karakteristika (FDD - Feature Driven Development)
Kanban
Lean
Metodologija dinamikog razvoja sistema (DSDM - Dynamic Systems Development
Method)
Familija kristalnih metodologija (Chrystal Methodologies)
Adaptivni razvoj softvera (ASD - Adaptive Software Development)
Agilno modelovanje (Agile Modeling)
Agilni unificirani proces (AUP - Agile Unified Process), itd.

Agilne metodologije su nastale jo sredinom 1990-ih, ali tada nisu nazivane "agilne",
ve "lagane" (lightweight) metodologije.[2] Pojavile su se kao kritika reakcija na
"robusne" (heavyweight) metodologije, koje su teko savladive i u kojima je proces
razvoja propisan do svakog, i najmanjeg detalja (to su pre svega metodologije bazirane
na waterfall modelu razvoja).[2] Naime, pobornici agilnog pristupa razvoja su smatrali
da su "robusne" metodologije isuvie birokratske i spore.[2] Zato su oni pokuali da nau
kompromis izmeu dve suprotne krajnosti - biti u potpunosti bez postupka i imati
previe postupaka.[2]

2.1. Agilni Manifest

U februaru 2001. godine sedamnaest istaknutih softverskih inenjera se okupilo u mestu
Snowbird, u dravi Utah (Juta), gde su diskutovali o "laganim" (lightweight)
metodologijama razvoja softvera i tada su usvojili naziv "agilne metodologije" i objavili
Agilni Manifest.[14] Neki od njih su oformirili neprofitnu organizaciju "Agilna
Alijansa" (The Agile Alliance) iji je cilj promovisanje razvoja softvera u skladu sa
vrednostima i principima Agilnog Manifesta.

2.1.1. etiri vrednosti Agilnog Manifesta

Manifest Agilnog Razvoja Softvera u originalu glasi:[14]
Otkrivamo bolje naine razvoja softvera razvijajui softver sami i pomaui drugima pri
njegovom razvijanju. Kroz taj rad nauili smo da vie vrednujemo:
Pojedince i interakcije od procesa i alata
Primenljiv softver od detaljne dokumentacije
Saradnju sa klijentima od ugovornih aranmana
Reakciju na promenu od pridravanja plana

Drugim reima, iako cenimo znaaj inilaca predstavljenih na desnoj strani, stavke
prikazane na levoj strani vrednujemo vie.[14]
Znaenje stavki na levoj strani:
Pojedinci i interakcije - procesi treba da budu prilagoeni ljudima, a ne obruto.
Veoma su vani komunikacija i interakcija u timu. Preporuuje se korienje
besplatnih alata, a samo po potrebi kupovina licenci za skupe CASE alate.[13]
Primenljiv softver - primenljiv softver je korisniji za prezentovanje klijentima nego
obimna i detaljna dokumentacija.
Saradnja sa klijentima - zahtevi ne mogu odmah na poetku razvojna biti u
potpunosti definisani, zato je veoma vano stalno uee klijenata u svim
aktivnostima razvoja. Ugovor ne sme biti zamena za saradnju.
Reakcija na promene - poto su promene u toku projekta neminovnost, agilni razvoj
je fokusiran na brz odziv na promene. Predvianje daleko u budunost nije mogue,
zato planovi moraju biti fleksibilni i prilagodljivi promenama.[13]
Dakle, zakljuak je da tradicionalne metodologije vrednuju vie stavke na desnoj strani,
dok agilne vrednuju vie stavke na levoj strani.

2.1.2. Dvanaest principa Agilnog Manifesta

Principi na kojima se zasniva Agilni Manifest su: [19]
1. Najvii prioritet u razvoju ima zadovoljenje korisnika kroz ranu i stalnu isporuku
upotrebljivog softvera.
2. Spremno prihvatamo promene zahteva, ak i kada pristiu u kasnijim fazama razvoja.
Agilni procesi omoguavaju uspeno prilagoavanje izmenjenim zahtevima to za
rezultat ima prednost klijenata u odnosu na konkurenciju.
3. Uestalo isporuivati za korisnika upotrebljiv softver, u periodu od nekoliko nedelja
do nekoliko meseci, sa preferiranjem to kraih vremenskih intervala.
4. Klijenti i developeri svakodnevno sarauju u toku celokupnog trajanja projekta.
5. Na projektu moraju raditi motivisani pojedinci. Potrebno im je obezbediti ambijenti i
podrku koja im je potrebna i njima se preputa posao sa poverenjem.
6. Najproduktivniji i najefikasniji metod prenosa informacije do i unutar razvojnog tima
je kontakt licem u lice.
7. Primenljiv softver je osnovno merilo napretka.
8. Agilni procesi promoviu odrivi razvoj. Pokrovitelji, developeri i korisnici moraju
biti u stanju da kontinuirano rade usklaenim tempom, nezavisno od perioda trajanja
projekta.
9. Stalna posveenost vrhunskom tehnikom kvalitetu i dobar dizajn pospeuju agilnost.
10. Jednostavnost - vetina dovoenja do najvieg stepena koliine rada koji nije
potrebno uraditi - je od sutinske vanosti.
11. Najbolje arhitekture, zahtevi i dizajn, rezultat su rada samo-organizovanih timova.
12. Timovi u redovnim intervalima razmatraju naine kako da postanu efikasniji, zatim
se usklauju i na osnovu tih zakljuaka prilagoavaju dalje postupke.

2.2. Specifinosti pojedinih agilnih metodologija

Agilne metodologije se meusobno razlikuju po tome koje faze ivotnog ciklusa razvoja
softvera podravaju, kao i po tome da li podravaju aktivnosti upravljanja projektom i
da li sugeriu korienje odreenih procesa i tehnikih praksi u pojedinim fazama
ivotnog ciklusa razvoja softera. Neke agilne metodlogije su fokusirane na tehnike
prakse (XP - ekstremno programiranje), dok su neke druge fokusirane na upravljanje
projektom (Scrum).[1] Takoe, postoje metodologije koje potpuno pokrivaju ivotni
ciklus razvoja softvera (DSDM, RUP).[1] Postoje i metodologije koje pokrivaju ceo ili
vei deo ivotnog ciklusa razvoja softvera - kako sve ili veinu faza, tako i upravljanje
projektom, procese i tehnike prakse (RUP, FDD).[1]
Slika 6: specifinosti pojedinih agilnih metodologija[1]

Ukoliko se razmatra veliina tima, XP, Scrum i Agilno modelovanje su fokusirani na

male timove sa manje od 10 lanova.[1] Familija kristalnih metodologija, FDD, RUP,
ASD i DSDM podravaju projekte sa timovima sa do 100 lanova.[1] Ipak, predlagai
agilnog pristupa smatraju da ako veliina tima poraste, obim dokumentacije e se
uveati i projekat tada postaje "manje agilan".[1]

2.4. Iskustva primene agilnih metolologija

Anketa pod nazivom "The State of Agile"[23] prati trendove vezane za primenu agilnih
metodologija u razvoju softvera. Sprovodi je firma VesionOne jednom godinje jo od
2006. godine. Rezultati poslednje ankete, sprovedene na uzorku od 3501 ispitanika u
periodu od 04. avgusta do 16. oktobra 2013. godine, pokazuju da 73% ispitanika kae
da im agilni pristup pomae da zavre projekte bre; 92% kae da im agilni pristup
9

poboljava sposobnost odziva na promene; i 87% kae da aglini pristup poveava

produktivnost njihovih razvojnih timova.
Anketa pod nazivom "CHAOS Manifesto"[17] koju sprovodi konsultantska firma
Standish Group International svake godine od 1994, kae da je procenat uspenih IT
projekata u 2010. narastao na 37% (isporuka proizvoda je bila na vreme, u okviru
budeta i sa svim neophodnim svojstvima i karakteristikama), 42% projekata su bili
problematini (vremenski rok, budet je bio probijen i/ili su nedostajala neka od
neophodnih svojstava i karakteristika proizvoda) i 21% projekata su bili neuspeni
(otkazani su pre zavretka ili su isporueni, ali nisu korieni). Odmah na poeku
izvetaja je konstatovano da su kljuni razlozi za rast stope uspenosti projekata razvoja
softvera ea primena agilnog pristupa i rea primena waterfall pristupa. Dalje se
konstatuje da je u periodu izmeu 2002. i 2010. godine stopa uspenosti agilnih
projekata bila tri puta vea od tradicionalnih waterfall projekata.
Slika 7: stopa uspenosti waterfall i agilnih metodologija[15]

Sline rezultate koji ukazuju na veu stopu uspenosti agilnih projekata u odnosu na
tradicionalne projekte pokazuju mnoge ankete sprovedene od strane konsultantske firme
"Scott Ambler & Associates".[16]
Agilni pristup nije prikladan za sve situacije.[12] Nametanje agilnog pristupa procesno
orijentisanim, nekooperativnim organizacijama, mirnim i staloenim timovima vodi u
neuspeh projekta i raspad tima.[12] Takoe, taj pristup nije za velike timove najuspenije se izvodi u timovima do deset lanova, na ta i ukazuje anketa "State of
Agile".[23]
Agilni razvoj se pokazao kao uspean u ekstremnim, kompleksnim, visokopromenljivim
projektima.[12] Okruenje u kojem taj pristup daje najbolje rezultate je organizaciona
kultura usmerena na ljude i saradnju.[12] Koliko je vana organizaciona kultura za
uspenu primenu agilnog pristupa ukazuju rezultati ankete "State of Agile" prema
kojima je nesposobnost promene organizacione kulture glavna barijera za dalje usvjanje
tog pristupa.[23]

3. Uopte o Scrum-u
3.1. Pojam i istorijat Scrum-a
Scrum je iterativno-inkrementalni agilni radni okvir (framework) za upravljanje
projektima razvoja sloenih softverskih proizvoda. On omoguuje isporuku poslovnih
10

vrednosti u najkraem roku. Projekti ostvaruju napredak kroz niz iteracija (Sprint-eva)
koji traju od 1 do 4 nedelje i u kojima se kreira inkrementalni softverski proizvod
(potencijalno isporuiv inkrement). Scrum se oslanja na samoorganizujue,
viefunkcionalne timove. Osim u razvoju softvera, nalazi primenu i u proizvodnji,
marketingu, logistici, obrazovanju i sl.[18] Razvili su ga Ken Schwaber i Jeff Sutherland
ranih 1990-ih godina.[9] Obojca su, inae, potpisnici Agilnog Manifesta iz 2001.
godine.[14] Scrum je prvi put javno prezentovan 1995. godine na konferenciji OOPSLA
(Object-Oriented Programming, Systems, Languages & Applications) u Ostinu, Teksas,
SAD.[9] [7]
Scrum je pojam preuzet iz ragbija i oznaava momenat kada se protivniki timovi
sakupljaju na gomilu i bore za posed lopte.[2] To predstavlja suprotnost tafetnim trkama
u kojima svaki takmiar deluje kao pojedinac, a ne kao deo tima. Iako nije akronim,
esto se pogreno pie velikim slovima - SCRUM.
Od svog prvog objavljivanja 1995. do danas, Scrum je prihvaen od strane velikog broja
softverskih kompanija irom sveta. Vie od hiljadu knjiga je objavljeno na temu Scruma[9], izmeu ostalih i "Agilni razvoj softvera sa Scrum-om" (Ken Schwaber i Mike
Beedle, 2002.) i "Agilno upravljanje projektima sa Scrum-om" (Ken Schwaber, 2004.).
Schwaber i Sutherland su autori i Scrum Vodia objavljenog 2010. godine i prevedenog
na 30 jezika, izmeu ostalog i na srpski.[9]
Schwaber je 2002. godine osnovao Scrum Alijansu ("Scrum Alliance") i kreirao
program "Cerfified Scrum Master" kurseva.[9] Napustio je Scrum Alijansu 2009. godine
da bi osnovao Scrum.org u cilju daljeg poboljanja kvaliteta i efikasnosti Scrum-a, pre
svega kroz program "Professional Scrum" kurseva.[9]
Scrum je danas najpopularniji agilni metod razvoja softvera, to potvruju izvetaji
"State of Scrum"[22] (objavljuje ga Scrum Alijansa) i "State of Agile"[23] (objavljuje ga
firma VersionOne) - prema prvom, zastupljenost Scrum-a je 40%, a prema drugom
55%.
Slika 8: zastupljenost Scrum-a(State of Agile)[23]

11

Slika 9: zastupljenost Scrum-a (State of Scrum)[22]

Scrum radni okvrir ine odgovarajue uloge, sastanci i artefakti kao i pravila koja ih
povezuju.[8]
Slika 10: Scrum radni okvir (framework)

3.2. Uloge
U Scrum-u postoje tri uloge: vlasnik proizvoda (Product Owner), Scrum Master i
razvojni tim (Development Team). Oni zajedno predstavljaju Scrum tim (Scrum
Team).[8]
Scrum timovi su samoorganizovani i viefunckionalni.[8] Samoorganizovanim timom ne
upravlja niko izvan tima, nego sam tim odluuje kako najbolje obaviti posao.[8]
Viefunkcionalan tim poseduje sve kompetencije za obavljanje posla bez zavisnosti od
12

drugih (izvan tima).[8] Ovaj model Scrum tima ima za svrhu veu flesibilnost,
kreativnost i efikasnost.[8]
Scrum timovi isporuuju proizvod iterativno i inkrementalno, maksimizirajui tako
mogunost dobijanja povratnih informacija (feedback).[8]

3.2.1. Vlasnik proizvoda (Product Owner)

Product Owner je lan Scrum tima koji reprezentuje interese stakeholdera (korisnika,
klijenata i ostalih zainteresovanih strana) i usko sarauje sa njima.[18] Odgovoran je za
maksimizaciju poslovne vrednosti koju tim isporuuje klijentima.[20] On olakava
komunikaciju izmeu tima i stakeholdera i vodi brigu o tome da tim kreira pravi
proizvod. Opisuje ta i zato treba razvijati, ali ne i kako.
Zaduen je za upravljanje Product Backlog-om (listom zahteva proizvoda) - pie
korisnie zahteve (najee u formi korisnikih pria - user stories), rangira ih i
prioritizuje u skladu sa njihovom vanou tj. poslovnom vrednou.
Product Owner moe biti samo jedna osoba. Ovu ulogu nikako ne treba kombinovati sa
ulogom Scrum Master-a.
Uloga Product Owner-a u Scrum-u je donekle slina ulozi poslovnog analitiara u
tradicionalnom pristupu razvoja softvera.

3.2.2. Scrum Master

Odgovornost Scrum Master-a je da uini da Scrum bude razumljiv i usvojen od strane
Scrum tima.[8] Dakle, on je taj koji osigurava da se projekat odvija u skladu sa teorijom,
praksom i pravilima Scrum-a da bi tim bio maksimalno produktivan.[8] Zato Scrum
Master mora vrlo dobro da poznaje i razume Scrum i da ima sposobnost da to svoje
znanje prenese na druge. On predsedava svim sastancima tima.
Takoe, on je taj koji uklanja sve smetnje i prepreke koje ometaju napredak Razvojnog
tima.[8] Dakle, Scrum Master je sluga-lider (servant-leader) Scrum tima.[8]
On pomae i svima izvan tima da razumeju Scrum i da shvate koje interakcije su
korisne za tim, a koje ne.[8]
Uloga Scrum Master-a je donekle slina ulozi menadera projekta u tradicionalnom
pristupu razvoja softvera. Kljuna razlika je u tome to Scrum Master nema upravljaki
autoritet nad lanovima Scrum tima, ve samo nad Scrum procesom.[5] Uloga Scrum
Master-a se moe posmatrati i kao uloga "vlasnika procesa", nasuprot ulozi vlasnika
proizvoda (Product Owner-a).[7]

3.2.3. Razvojni tim (Development Team)

Razvojni tim ine eksperti koji rade na stvaranju potencijalno isporuivih inkremenata
(PSI - Potentially Shippable Increments) na kraju svakog Sprint-a, u skladu sa
definicijom obavljenog (DoD - Definition of Done).[8]

13

Razvojni tim je viefunkcionalan, to znai da lanovi tima poseduju sve kompetencije

neophodne za razvoj inkrementa proizvoda. Oni su ti koji obavljaju poslove analize,
dizajna, kodiranja, testiranja, dokumentovanja softverskog proizvoda i sl.
Razvojni tim je samoorganizovan, to znai da im niko (ak ni Scrum Master) ne moe
odreivati kako da zahteve iz Product Backlog-a pretvore u potencijalno isporuiv
inkrement, ve oni sami odluuju kako e to uraditi, dogovarajui se izmeu sebe ko e
ta raditi. [8]
Dakle, Product Owner pravi listu zahteva ta treba da se razvija. lanovi razvojnog
tima onda predviaju koliko e moi da razviju u jednom Sprint-u i samoorganizuju se,
tj. samostalno odluuju kako e razviti inkrementalni proizvod.
Razvojni tim bi trebao da ima od 5 do 9 lanova (7 plus-minus 2 lana). Manji razvojni
timovi imaju potekoe u smislu potrebnih kompetencija tokom Sprint-a, to uzrokuje
nemogunost tima da razvija potrencijalno isporuiv inkrement.[8] Vei razvojni timovi
zahtevaju mnogo vie koordinacije i poveavaju sloenost upravljanja procesom.[8]

3.3. Dogaaji
Dogaaji u Scrum-u su Sprint-evi (iteracije) i Scrum sastanci. Trebali bi da se odravaju
redovno u cilju umanjenja potreba za dodatnim sastancima koji nisu deo Scrum-a.[8]
Vremenski su ogranieni (time-boxed), tako da svaki ima definisanu maksimalnu
duinu trajanja.[8]
Svaki dogaaj je ansa za nadgledanje i prilagoavanje neega (inspect and adapt).[8]
Dogaaji su osmiljeni s ciljem da omogue potrebnu transparentnost i nadgledanje.[8]
Izostanak bilo kojeg od Scrum dogaaja ima za rezultat smanjenu transparentnost i
proputenu priliku za nadgledanje i prilagoavanje.[8]
Slika 11: Scrum proces[22]

3.3.1. Sprint
Sprint (iteracija) je osnovna jedinica razvojnog vremena u Scrum-u.[15] To je srce
Scrum-a.[8] Vremenski je ogranien (time-boxed) i uobiajeno traje izmeu jedne i etiri
14

nedelje. U toku Sprint-a razvojni tim kreira upotrebljiv, potencijalno isporuiv

inkrement proizvoda koji ima poslovnu vrednost za klijenta ili korisnika.
Sastoji se iz sledeih sastanaka i aktivnosti:
sastanak planiranja Sprint-a (Sprint Planning),
dnevni Scrum sastanak (Daily Scrum),
razvoja proizvoda,
sastanak pregleda Sprint-a (Sprint Review),
sastanak osvrta na Sprint (Sprint Retrospective).
Dakle, svaki Sprint se zapoinje sastankom planiranja Sprint-a (Sprint Planning
Meeting), a okonava se sastancima pregleda Sprint-a (Sprint Review Meeting) i osvrta
na Sprint (Sprint Retrospective Meeting). Novi Sprint zapoinje odmah po okonanju
prethodnog.[5] U toku Sprint-a svakodnevno se odrava dnevni Scrum sastanak (Daily
Scrum Meeting).
Sprint ne bi trebao da traje due od mesec dana.[8] Ukoliko bi Sprint trajao predugo,
plan onoga to treba da se kreira moe da se promeni, kompleksnost moe da poraste i
rizik moe da se povea. Ideja je da se omogui predvidivost na nain da se nadgledanje
i prilagoavanje deava najmanje jednom meseno.[8]

Sastanci
3.3.2. Sastanak planiranja Sprint-a (Sprint Planning)
Sprint se zapoinje Sprint Planning sastankom. Posao koji treba da se obavi tokom
Sprint-a planira se na ovom sastanku.[8] Ovaj plan se stvara saradnjom itavog Scrum
tima - Product Owner-a, Scrum Master-a i razvojnog tima.[8] Vremenski je ogranien na
najvie osam sati za jednomeseni Sprint.[8] Ako je Sprint krai, onda e i ovaj sastanak
trajati krae.[8]
Za realizaciju svih zahteva iz Product Backloga potrebno je mnogo vie vremena nego
to je duina trajanja jednog Sprint-a. Zato je potrebno selektovati najprioritetnije
zahteve za koje razvojni tim proceni da je realistino da ih moe realizovati u toku
jednog Sprint-a. Dakle, razvojni tim je taj koji odabira zahteve koje e realizovati u
tekuem Sprint-u.
Nakon to razvojni tim odredi zahteve koji mogu biti isporueni kao rezultat tekueg
Sprint-a, Scrum tim odreuje Cilj Sprint-a (Sprint Goal).[8] To je cilj koji e biti
ispunjen u okviru Sprint-a realizacijom zahteva iz Product Backlog-a i on daje smernice
razvojnom timu zato se kreira inkrement.[8]
Nakon to su odreeni Cilj Sprint-a i najprioritetniji zahtevi iz Product Backlog-a, koji
e biti realizovani u tekuem Sprint-u, razvojni tim odluuje o tome kako stvoriti
inkrement proizvoda tokom Sprint-a. Zahtevi, najee u formi korisnikih pria (user
stories), se analiziraju i ralanjuju na zadatke (tasks). Za svaki zadatak razvojni tim
procenjuje vreme potrebno za njegov zavretak, najee u asovima. U tu svhu se
15

koriste razliite tehnike, a najpoznatija je planiranje pokera (Planning Poker). Kreira se

Sprint Backlog (lista zahteva Sprint-a) koji sadri te zadake.
Dakle, u toku ovog sastanka definiu se dva artefakta: Cilj Sprint-a (Sprint Goal) i lista
zahteva Sprint-a (Sprint Backlog).[20]

3.3. 3. Dnevni Scrum sastanak (Daily Scrum)

Svakog dana u toku Sprint-a odrava se dnevni Scrum sastanak (Daily Scrum) da bi
pratili napredak ka cilju Sprint-a.[18] Naziva se jo i dnevni stojei sastanak (Daily
Stand-Up), zbog uobiajene prakse da se stoji tokom sastanka.[5]
Vremenski je ogranien na petnaest minuta. Odrava se uvek u isto vreme i na istom
mestu.[20]
Ovaj sastanak vodi Scrum Master i svim lanovima razvojnog tima postavlja sledea tri
pitanja:[5]
ta si radio jue?
ta e raditi danas?
Da li postoji neka prepreka koja ometa tvoj napredak?
Dnevni Scrum sastanak je kljuan za nadgledanje i prilagoavanje.[8] Njegova svrha nije
reavanje problema.[5] Problemi se reavaju tek nakon okonanja ovog sastanka. [5]
Iako ostale zainteresovane strane mogu da prisustvuju dnevnom Scrum sastanku, samo
je lanovima Scrum tima dozvoljeno da govore.[5]
Na kraju svakog Sprint-a, odravaju se dva sastanka: sastanak pregleda Spint-a (Sprint
Review) i sastanak osvrta na Sprint (Sprint Retrospecive).

3.3.4. Sastanak pregleda Sprinta (Sprint Review)

Kada je Sprint zavren, odrava se sastanak pregleda Sprint-a (Sprint Review). Cilj
ovog sastanka je nadgledanje i prilagoavanje (insect and adapt) inkrementa
proizvoda.[5]
Vremenski je ogranien na etiri sata za sluaj jednomesenog Sprint-a.[8] Ako je Sprint
krai, ovaj sastanak e trajati krae.[8] Na primer, ukoliko je Sprint trajao dve nedelje,
sastanak e trajati dva sata, a ukoliko je Sprint trajao nedelju dana, sastanak e trajati
jedan sat.[18]
Glavna tema diskusije na ovom sastanku je inkrement proizvoda koji je razvijen u toku
Sprinta.[18] Dakle, tokom ovog sastanka, Scrum tim i stejkholderi diskutuju o tome ta je
uraeno tokom Sprint-a.[20] Inkrement proizvoda se demonstrira stejkholderima u cilju
prikupljanja povratnih informacija. Ukoliko postoji potreba, Product Backlog se
koriguje, ime se redefinie ulaz za naredni Sprint.

3.3.5. Sastanak ostvrta na Sprint (Sprint Retrospective)

Poslednji sastanak koji se odrava na kraju svakog Sprint-a je sastanak osvrta na Sprint
(Sprint Retrospective). Odrava se nakon sastanka pregleda Sprint-a (Sprint Review), a
16

pre sastanka planiranja Sprint-a (Sprint Planning).[5] Cilj ovog sastanka je nadgledanje i
prilagoavanje (inspect and adapt) procesa.[5]
Vremenski je ogranien na tri sata kod jednomesenog Sprint-a.[8] Za sluaj da je Sprint
krai, sastanak e biti krai.[8]
Tokom ovog sastanka, Scrum Master, Product Owner i razvojni tim diskutuju o tome
kako je tekao proces, ta je dobro raeno, a ta nije i identifikuju potencijalna
poboljanja.[5] Oni onda dalje planiraju kako e realizovati ta poboljanja u toku
narednog Sprinta.[5]
Jedan od najjednostavnijih, ali i najefektivnijih nain odravanja ovog sastanka je da
svaki lan Scrum tima odgovori na pitanje ta bi oni trebali da:[20]
ponu da rade
prestanu da rade
nastave da rade
Dakle, moe se sumirati da se sastanak pregleda Sprint-a (Sprint Review) fokusira na
proizvod, dok se sastanak osvrta na Sprint (Sprint Retrospective) fokusira na proces
kojim tim gradi taj proizvod.

3.4. Artefakti
Scrum radni okvir definie etiri artefakta:

Product Backlog (lista zahteva proizvoda)

Sprint Backlog (lista zahteva Spritn-a)
Inkrement proizvoda (Product Increment)
Dijagram sagorevanja (Burndown Chart)

3.4.1. Lista zahteva proizvoda (Product Backlog)

Product Backlog je lista zahteva za proizvod poreanih po prioritetu.[20] Sadri sve
funkcionalnosti, poboljanje i popravke koje je potrebno implementirati u proizvod.[8]
Razvojni tim kreira proizvod samo na osnovu zahteva iz Product Backlog-a i to je jedini
izvor zahteva za njih.
Product Owner je odgovoran za Product Backlog. On sarauje sa stejkholderima da bi
prikupio i definisao stavke.[5]
Stavke u Product Backlog-u su najee u formi korisnikih pria (user stories). To su
kratki, jednostavni opisi eljenih funcionalnosti iz perspektive korisnika.
Product Backlog moe biti dugaak ili kratak spisak.[18] Moe biti nejasno ili jasno
definisan.[18] Obino je u poetku kratak i nejasno definisan, ali vremenom postaje dui i
jasnije je definisan.[18] Zahtevi se stalno menjaju, tako da je to dinamian artefakt.[8]
Prerada Product Backlog-a (Product Backlog Refinement) podrazumeva dodavanje
detalja, procenu i prioritizaciju Product Backlog stavki.[8] Dodavalje detalja
podrazumeva analizu i ralanivanje veih, uopteno definisanih stavki na manje,
konrektnije definisane stavke. Stavke sa vie detalja e se nalaziti na vrhu liste, dok e
17

se stavke sa manje detalja nalaziti na dnu liste.[8] Procenu razvojnog napora za svaku
stavku vri razvojni tim, dok procenu poslovne vrednosti vri Product Owner.
Prioritizacija podrazumeva da e se stavke koje imaju najviu poslovnu vrednost
nalaziti na vrhu liste, dok se e one koje imaju najmanju poslovnu vrednost nalaziti na
dnu liste.
Tokom sastanka planiranja Sprint-a Product Owner prezentuje Product Backlog stavke
razvojnom timu. Razvojni tim procenjuje koliko stavki sa vrha liste moe da realizuje u
predstojeem Sprintu. Te odabrane stavke se onda prenose u Sprint Backlog.

3.4.2. Lista zahteva Sprinta (Sprint Backlog)

Sprint Backlog je skup Product Backlog stavki koje su odabrane od strane razvojnog
tima za tekui Sprint.[18] Ovaj artefakt odraava predvianje razvojnog tima o tome
koliko posla moe biti okonano u jednom Sprintu.[18]
Tokom sastanka planiranja Sprinta, razvojni tim selektuje odreen broj Product Backlog
stavki, koje su najee u formi korisnikih pria (user stories), i identifikuje zadatke
neophodne za realizaciju svake korisnike prie.[20] Veina timova takoe procenjuje
koliko sati je potrebno za realizaciju
Slika 12: tipina Scrum tabla zadataka[26]
svakog zadatka.[20]
Nakon to je Sprint Backlog kreiran,
razvojni tim poinje sa radom na
inkrementu proizvoda.[18] Dakle, zadaci
koji se nalaze u Sprint Backlog-u
predstavljaju ulaz za tekui Sprint.
Scrum tabla zadataka (Scrum task
board) pokazuje evoluciju stanja Sprint
Backlog-a tokom vremena.[5] Podeljena
je na etiri kolone: "korisnike prie",
"uraditi", "u toku" i "gotovo". Svi zadaci
se inicijalno nalaze u koloni "uraditi" (To
Do).[5] Kada razvojni tim proceni da
treba zapoeti rad na nekim zadacima, ti
zadaci se premetaju u kolonu "u toku"
(In Progress).[5] Kada je zadatak zavren,
premeta se u kolonu "gotovo" (Done).[5]

3.4.3. Inkrement proizvoda (Product Increment)

Izlazni rezultat svakog Sprint-a je inkrement proizvoda ili potencijalno isporuiv
inkrement (PSI - Potentially Shippable Increment), najvaniji Scrum artefakt.[18] To je
skup svih Product Backlog stavki koje su zavrene tokom Sprinta. Na kraju Sprint-a,
novi inkrement mora biti u upotrebljivom stanju i mora da ispunjava definiciju
zavrenog (DoD - Definition of Done).[8] Product Onwer donosi odluku da li e ga
pustiti u upotrebu ili ne.[8]
18

Definicija zavrenog (DoD - Definition of Done) - kada je inkrement proizvoda

isporuen, mora biti "zavren" u skladu sa zajednikim razumevanjem ta "zavren"
znai.[18] Iako definicija zavrenog moe da varira meu razliitim Scrum timovima,
lanovi jednog Scrum tima moraju da imaju usklaeno razumevanje definicije
zavrenog.[8]

3.4.4. Grafikon sagorevanja (Burndown Chart)

Burndown Chart prikazuje ukupnu koliinu nedovrenog posla u Sprint Backlogu. Na
vrlo jednostavan nain vizualizuje ostvaren progres u Sprint-u.
Na horizontalnoj osi se prikazuje preostalo vreme do kraja Sprint-a, a na vretikalnoj osi
preostali posao koji se moe meriti u danima, satima, poenima dodeljenim korisnikim
priama (story points)... itd.[20]
Slika 13: grafikon sagorevanja[24]

3.5. Terminologija
Scrum tim (Scrum Team) - ine ga: Scrum Master, vlasnik proizvoda (Product
Owner) i razvojni tim (Development Team).
Razvojni tim (Development Team) - uloga odgovorna za razvoj inkrementa proizvoda
u svakom Sprint-u.
Vlasnik proizvoda (Product Owner) - uloga koja reprezentuje interese klijenata.
Odgovorna za maksimizaciju isporuene poslovne vrednosti. Odrava listu zahteva
proizvoda (Product Backlog).
Scrum Master - uloga odgovorna za usvajanje i razumljivost Scrum procesa od strane
svih lanova Scrum tima.
Sprint - iteracija koja je vremenski ograniena na najvie 30 dana i nakon koje se
isporuuje inkrement proizvoda. Sastoji se iz sledeih sastanaka i aktivnosti:
19

 sastanak planiranja Sprint-a (Sprint Planning),

dnevni Scrum sastanak (Daily Scrum),
razvoja proizvoda,
sastanak pregleda Sprint-a (Sprint Review),
sastanak osvrta na Sprint (Sprint Retrospective).
Kada se zavri tekui Sprint, odmah se prelazi na naredni Sprint.
Definicija zavrenog (DoD - Definition of Done) - zajedniko razumevanje ta
"zavren" (Done) inkrement proizvoda znai za razvojni tim.
Cilj Sprinta - kratak iskaz koji oznaava cilj koji treba da bude ispunjen na kraju
Sprinta.
Sastanak planiranja Sprinta (Sprint Planning) - odrava se na poetku svakog
Sprint-a. Na ovom sastanku se planiraju sve aktivnosti koje e se izvriti tokom Sprinta. Vremenski je ogranien na jedan dan za tridesetodnevni Sprint.
Dnevni Scrum sastanak (Daily Scrum) - petnaestominutni sastanak koji se odrava
svakog dana kada svaki lan razvojnog tima odgovara na tri pitanja:
ta si radio jue?
ta e raditi danas?
da li postoji neto to ometa tvoj napredak?
Sastanak pregleda Sprinta (Sprint Review) - odrava se na kraju svakog Sprint-a.
Cilj odravanja je nadgledanje i prilagoavanje (inspect and adapt) inkrementa
proizvoda.
Sastanak ostvrta na Sprint (Sprint Retrospective) - takoe se odrava na kraju
svakog Sprint-a. Cilj odravanja je je nadgledanje i prilagoavanje procesa kojim se
kreira inkrement proizvoda.
Lista zahteva proizvoda (PBL - Product Backlog) - prioritizovana lista zahteva za
proizvod. Stavke u Product Backlog-u su najee u formi korisnikih pria (User
Stories). Odrava ga Product Owner.
Lista zahteva Sprint-a (SBL - Sprint Backlog) - deo Product Backlog stavki sa
najveim prioritetom koje su odabrane za tekui Sprint. Selekcija stavki se vri tokom
sastanka planiranja Sprint-a (Sprint Planning Meeting). Te stavke su najee
dekomponovane na vei broj zadataka.
Stavka liste zahteva proizvoda (PBI - Product Backlog Item) - jedinica posla
dovoljno mala da se zavri u jednom Sprint-u. Stavke se dekomponuju na jedan ili vie
zadataka i tako se prenose u Sprint Backlog.
Grafikon sagorevanja (Burndown Chart) - prikazuje preostali deo posla. Na X osi se
nalazi preostali obim posla, a na Y osi preostalo vreme.

20

Stejkholder (Stakeholder) - osoba izvan Scrum tima koja je zainteresovana za

proizvod. Reprezentuje je Product Owner. Aktivno uestvuje tokom sastanka pregleda
Sprinta (Sprint Review).

21

Literatura
[1] Abrahamsson Pekka, Salo Outi, Ronkainen Jussi & Warsta Juhani, Agile softvare
development methods, review and analysis, 2002.
[2] Borjan Milo, Agilne i tradicionalne metodologije u razvoju informacionih sistema,
magistarski rad, 2010.
[3] urkovi Jovica, Zoran iri, Vuk Vukovi, Struktura analiza i dizajn, 2011.
[4] Fowler Martin, UML ukratko, kratak vodi korz standardni jezik za modelovanje, 2003.
[5] Keneth S. Rubin, Essential Scrum A Practical Guide to the Most Popular Agile Process,
2012.
[6] Royce W. Winston, Managing the Development of Large Software Systems, 1970,
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
[7] Schwaber Ken, SCRUM Development Process, 1995,
http://agilix.nl/resources/scrum_OOPSLA_95.pdf
[8] Schwaber Ken, Sutherland Jeff, Scrum Guide, 2013,
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-US.pdf#zoom=100
[9] Schwaber Ken, Sutherland Jeff, Scrum Guides, 2013,
http://www.scrumguides.org/history.html
[10] Tomaevi Violeta, Razvoj aplikativnog softvera, 2012.
[11] Tumbas Pere, Objektni softverski inenjering, Materijal za ispit, 2008,
http://www.ef.uns.ac.rs/Download/objektni_si/28-01-08 materijal za ispit.pdf
[12] Tumbas Pere, Razvoj informacionih sistema, Literatura za usmeni ispit, 2012,
http://www.ef.uns.ac.rs/Download/ris/2012-06-05-literatura-usmeni.pdf
[13] Tumbas Pere, Razvoj informacionih sistema, Literatura za drugi teorijski test, 2012,
http://www.ef.uns.ac.rs/Download/ris/2012-05-15-literatura-2-teorijski-test.pdf

[14] Agile Manifesto, 2001, http://agilemanifesto.org/

[15] Agile Scrum, Neon Rain, http://www.neonrain.com/agile-scrum-web-development
[16] Agile Surveys, Scott Ambler & Associates, http://www.ambysoft.com/surveys/
[17] CHAOS Manifesto, Standish Group, 2013,
http://www.versionone.com/assets/img/files/ChaosManifest_2011.pdf
[18] Core Scrum Values, Scrum Alliance, https://www.scrumalliance.org/why-scrum/corescrum-values-roles
[19] Principles behind Agile Manifesto, 2001, http://agilemanifesto.org/principles.html
[20] Scrum Overview for Agile Software Development,
http://www.mountaingoatsoftware.com/agile/scrum/overview
[21] Software Engineering, Report on a conference sponsored by the NATO Science Committee,
1968, http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF

22

[22] The State of Scrum report, Scrum Alliance, 2013,

https://www.scrumalliance.org/scrum/media/ScrumAllianceMedia/Files%20and%20PDFs/State
%20of%20Scrum/2013-State-of-Scrum-Report_062713_final.pdf
[23] The State of Agile, VersionOne, 2013, http://www.versionone.com/pdf/2013-state-of-agilesurvey.pdf

[24] Burndown Chart: http://joel.inpointform.net/wpcontent/uploads/2010/11/burndown132.png

[25] IBM S/360: http://www03.ibm.com/ibm/history/ibm100/images/icp/C713286B04220T42/us__en_us__ibm100__syste
m_360__woman_at_360__800x593.jpg
[26] Scrum task board: http://www.flickr.com/photos/plutor/5260265039/

23