INFOTEH-JAHORINA Vol. 10, Ref. E-I-16, p. 466-470, March 2011.

AGILNI RAZVOJ PROGRAMSKIH PROIZVODA

AGILE SOFTWARE DEVELOPMENT
Ivan Padavi, Initium Futuri ltd., Zagreb
Marko Veli, Initium Futuri ltd., Zagreb
Dejan Ljubobratovi, Faculty of Teacher Education - University of Rijeka
Sadraj - U poslednje vreme u domeni softverskog inenjerstva veoma su popularne tzv. agilne metode izrade softvera. Agilne
metode svoje korene vuku iz lean menadmenta koji se pojavio u Japanu 80-ih godina prolog veka. Ove metode postavljaju
principe akvizicije korisnikih zahtjeva, projektiranja i razvoja aplikacija i informacionih sistema na nain koji ukljuuje
krajnjeg korisnika u puno veoj mjeri nego je to kod tradicionalnih metoda. Osim toga, agilne metode predlau novi,
fleksibilniji nain razmiljanja tj. oputeniji odnos prema cjelokupnom projektu, a sve u svrhu eliminacije nepotrebne
dokumentacije, smanjenja nesporazuma i poveanja uspenosti projekata razvoja informacionih sustava. U ovom radu opisani
su kljuni koncepti agilnih metoda razvoja softvera sa naglaskom na SCRUM metodiku. Agilne metode nisu panacea za
uspean razvoj softvera posebice u sferi finansiranja agilnih projekata pa je u radu opisan i taj praktini problem.
Abstract Recently in Software engineering, agile software development methods are becoming more and more popular. Agile
methods are coming from Japanese industrial lean management practices. These methods involve end user in the entire
software development process much more than in traditional waterfall approach. Besides that, agile methods introduce new
flexible project management concepts and eliminate unnecessary documentation. This paper presents key agile development
practices with emphasis on SCRUM. Agile methods are not panacea for successful project and practical issues are described.
ostali dionici. I tree, lanovi projektnog tima mora da imaju
viziju kako e zajedno da odrade posao.

1. Nastanak agilnih metoda

Potaknuta nezadovoljstvom uzrokovanim velikim
procentom neuspenih IT projekata, skupina sastavljena od
sedamnaest strunjaka iz podruja softverskog inenjerstva
zagovornika agilnih metoda razvoja, sastala se 2001. godine
u maloj kolibici u skijakom odmaralitu negdje u planinama
Jute kako bi pokuali nai rjeenje za gorue probleme
postojeih metodologija programskog inenjerstva. Rezultat
njihovog druenja je uveni manifest - Agile Manifesto. [1]
Agilni manifest je dokument koji opisuje temeljne
postavke buduih agilnih metoda. Manifest moemo ukratko
saeti na etiri temeljne poruke:
1. Individualci i interakcija ispred procesa i alata
2. Softver koji radi ispred iscrpne dokumentacije
3. Saradnja s klijentom ispred pregovora o ugovoru
4. Reagiranje na promenu ispred praenja plana
Ove poruke zapravo su prilagodba temeljnih koncepata
lean menadmenta softverskom inenjerstvu. Lean
menadment se pojavio u Japanu 80-ih godina prolog veka i
njegov je cilj eliminacija nepotrebnih aktivnosti i vea
ukljuenost samih radnika u unaprjeenje procesa
proizvodnje.
2. Principi agilnih metoda
Vizija - Jedan od temeljnih koncepata agilnog upravljanja
projektima koji se susree u literaturi koja ga opisuje je
vizija. Vizija je prema [2] kritini faktor uspenosti u ranoj
fazi projekta. Prije svega moramo imati viziju ta radimo.
Zatim, moramo imati viziju tko e biti ukljuen u projekt
klijenti, proizvodni menaderi, lanovi projektnog tima i

pekuliranje - Iako rije pekulacija ima odreeno

negativno znaenje u smislu nepromiljenog riskiranja ili
manipulacija,
izvorno
znaenje
rijei
je
Nasluivati/pretpostavljati neto na temelju nepotpunih
injenica ili informacija. U tradicionalnim metodama izrada
softvera sledi se unaprijed definirani plan, dok se u aginom
pristupu u fazi pekulacije okvirno procenjuju zahtjevi i
funkcionalnosti budueg softvera, procenjuje se koliina
posla za odreene zahtjeve, okvirni plan isporuke, rizici i
strategije ublaavanja rizika te trokovi projekta.
Istraivanje - Faza istraivanja (kako se naziva ponegdje
u literaturi) u principu predstavlja sami razvoj proizvoda.
Istraivanje je rije koja opisuje samu sutinu ideje agilnog
razvoja. Naime, cilj je kreirati proizvod, ne prema nekom
vrsto definiranom planu, ve uz saradnju krajnjeg korisnika
kroz proces razvoja istraivati i otkrivati to je to to korisnik
zapravo treba.
Adaptacija - Agilni razvoj kao svoju prednost ima i
mogunost ranog gaenja projekta. Iako zvui suludo kada
kaemo da je to prednost, gaenje projekta u ranoj fazi moe
utedjeti mnogo uzaludnog rada, novca i nezadovoljstva.
Naravno uvjet uza to je realnost u suoavanju s napretkom
projekta od strane klijenta i razvojnog tima. Kako bi se takva
situacija uope prepoznala, a to je jo vanije naravno i
izbjegla vano je pravovremeno uoavanje pogreaka i
zastranjivanja u projektu. Agilne metode razvoja sa svojim
konceptima retrospektiva i redovitih revizija to je uinjeno
uz praenje sukladnosti obavljenog posla sa potrebama
klijenta omoguavaju upravo to. Adaptaciju na promjene,
bilo da se radi o promjenama u okolini sustava za koji radimo

466

proizvod ili o promjenama u shvaanju konanog projekta i

vlastitih potreba od strane klijenta.
Zatvaranje - Zatvaranje projekta je vaan element
dobrog projektnog menadmenta bez obzira je li rije on
tradicionalnom ili agilnom pristupu upravljanju projektom.
Agilne metode u fazi zatvaranja projekta naglasak stavljaju
na dovravanje svih otvorenih zadataka, finalizaciju nune
dokumentacije i najvanije, na komunikaciju i odnose unutar
tima.
3. Korisnike prie i prioriteti
Korisnike prie (engl. User Stories) predstavljaju
osnovnu jedinicu u planiranju, izradi i evaluaciji novog
programskog proizvoda. Korisnika pria je pandan
funkcionalnostima u tradicionalnom pristupu razvoja. Naziv
funkcionalnost zadrao se i kod praktiara agilnih metoda.
Iako je sami naziv manje bitan, vano je percipirati kako taj
novi naziv korisnika pria u sebi sadrava sutinu
filozofije agilnog razvoja. Naime, za razliku od puke
funkcionalnosti koja kae da se odreena radnja treba
dogoditi u odreenom trenutku, korisnika pria je opis tko,
ta i zbog ega eli neto uiniti. Iako se razlika na prvi
pogled ini minorna, ona je itekako velika. Imajui ovo na
umu, sama akvizicija zahtjeva (po tradicionalnom pristupu) je
poneto drugaiji proces. Praktiar agilne metode koji
komunicirajui s klijentom od njega saznaje njegove potrebe
i opisuje korisnike prie vie ulazi u samu problematiku od
tradicionalnog projektanta informacionog sistema koji
jednostavno popisuje eljene funkcionalnosti. Elementi
korisnike prie su: korisnika uloga koja e koristiti
funkcionalnost, cilj koji se postie koritenjem
funkcionalnosti te razlog zbog kojeg se ta funkcionalnost
koristi. Primjer korisnike prie je: Voditelj prodaje ima
uvid u broj prodanih proizvoda u odabranom razdoblju po
mjesecima kako bi mogao pratiti trendove.
Kod definicije korisnikih pria izuzetno je vana
komunikacija sa krajnjim korisnikom tj. razumijevanje
njegovih potreba. esto se dogaa da krajnji korisnik ne
posjeduje informatika znanja i da ne zna objasniti to mu
zapravo treba. Ukoliko se ne pridravamo ovih naela vrlo
esto emo dobiti odgovor klijenta koji e glasiti poput:
Napravili ste to sam traio, ali to nije ono to mi treba.
Ako programer koji radi na funkcionalnosti samo proita
korisniku priu i krene raditi bez komunikacije s klijentom,
vrlo je vjerojatno da korisnik nee dobiti ta eli. U najboljem
sluaju, dobit e ta je napisano.
Definisanje prioriteta u izradi informacionog sistema
veoma je vano, posebice kod veih projekata. Na taj nain
omoguava se svojevrsno rangiranje funkcionalnosti po
vanosti tj. vrednosti za krajnjeg korisnika ime je pak
omoguena isporuka programskog proizvoda u iteracijama.
Upravo isporuke u iteracijama, gdje se nakon svake iteracije
razvoja korisniku isporuuje softver koji radi, temelj je svih
agilnih metoda. Prilikom definisanja prioriteta razvojni tim i
korisnik se moraju usuglasiti oko toga koliko e razina
prioriteta imati i koje e funkcionalnosti ui u koju razvojnu
fazu. Lista prioriteta esto je i prilog ugovoru koji se sklapa
izmeu naruitelja i isporuitelja. U skladu sa filozofijom
agilnih metoda i lista prioriteta je promenjiva. To zapravo

znai da korisnik u saradnji s razvojnim timom moe, ukoliko

primeti potrebu za tim, podignuti ili smanjiti prioritet
odreene funkcionalnosti sistema. Prilikom definisanja
prioriteta, razvojni tim i klijent moraju razmiljati o tome ta
donosi najveu vrednost za klijenta i u skladu s tim definisati
koje e funkcionalnosti (opisane korisnikim priama) ui u
koju fazu. Prilikom definisanja prioriteta treba paziti na
zamku koja se moe dogoditi ukoliko se radi o vremenski
kritinim aplikacijama. Naime, praksa je pokazala da klijenti
esto ele isporuene funkcionalnosti ta ranije te se u ranim
fazama projekta definisaju dijelovi sistema koji podravaju
proces, a kontrola i praenje se zanemaruju i ukljuuju u
naknadne iteracije. Ukoliko se rezultat ranije iteracije pusti u
rad, a kontrola i praenje se prepuste sljedeoj iteraciji,
postoji opasnost da se druga faza zbog moguih promena i
dodatnih zahteva odui i da se zbog toga ne uspe realizovati
na vreme. Zbog toga menadment moe da ostane bez
primerice mesenog izvjetaja koji moe da bude kljuan za
donoenje odluke, a njegova realizacija kasni.
4. Karakteristike tima
Kako je jedna od temeljnih pretpostavki agilnog razvoja i
agilnog upravljanja projektom komunikacija, najvanija
karakteristika tima je upravo sposobnost i volja za
komuniciranje s klijentom. Takoer, tim mora da ima
razumevanja za ve pomenute probleme vezane uz shvaanje
ICT-a i budueg softvera od strane samog klijenta.
ta se tie veliine timova, to naravno ovisi o samom
projektu te tehnikoj zahtjevnosti i opsegu posla koji treba da
se obavi u zadatom vremenu. Agilna metoda XP je pogodna
za manje timove, dok je Scrum, primerice, najpogodniji za
timove od pet do deset lanova. Razmatrajui veliinu tima,
na umu valja imati i prednosti i mane malih odnosno velikih
timova. Mali timovi su fleksibilniji, no problem nastaje kada
neki lan tima iznenada napusti tim. Kako u agilnim
metodama ne postoji opsena projektna dokumentacija,
gubitak lana tima koji poseduje mnoga znanja o projektu,
predstavlja velik rizik. Isto tako, poveanje tima ne znai
naravno i linearno poveanje brzine obavljanja nekog posla, a
sa sobom nosi veu potrebu za koordinacijom.
Obzirom da su najei praktikanti agilnih metoda danas
u industriji proizvodnje softvera male tvrtke tj. mali projektni
timovi, postavlja se pitanje to sa razliitim ulogama unutar
samog razvojnog tima. Same aktivnosti potrebne da bi se
razvio programski proizvod nisu se znaajno promenile u
odnosi na tradicionalne modele razvoja pa tako jo uvijek
postoje poslovi koje obavljaju uloge kao to su: projekt
menader, program menader, projektant, razvojni inenjer,
tester, dizajner itd. Obzirom na ogranienost ljudskih resursa
u malim timovima, jasno je da e se ove uloge esto morati
pojavljivati unutar jedne osobe. Zbog mogueg svojevrsnog
sukoba interesa meu ulogama unutar pojedinca postoje
smernice koje uloge je poeljno, a koje nije poeljno
kombinirati u istoj osobi. Primjer jedne takve preporuke dat
je na slici 1.

467

malo vremena. U ovom potonjem se krije i opasnost od

nerazumevanja korisnika koje se esto manifestira i gubitkom
povjerenja jer mu se ini kako razvojni tim radi nerealne
procjene, a zaboravlja pritom vrijeme utroeno na izgradnju
arhitektonske osnovice sustava. Ilustracija odnosa aktivnosti
izrade arhitekture i korisnikih funkcionalnosti prikazana je
na slici 2.

Slika 1. MSF Timski model [3]

5. Karakteristike klijenta
Sve agilne metode razvoja podrazumevaju veliku
ukljuenost klijenta u sami proces razvoja. Neke agilne
metode to preporuaju veoj, a neke u manjoj mjeri, no bez
obzira koju metodu koristili u praksi, najee se pokazuje da
klijent naalost nije dovoljno ukljuen. Kod dogovaranja
novog projekta, veoma je vano klijentu objasniti prednosti
agilnog razvoja te ga pripremiti na sve to ga oekuje. U
provoenju agilnog projekta nune su neke karakteristike
klijenta poput sledeih: strpljenje, spremnost na sudjelovanje
u razvoju, strpljivost, spremnost na plaanje agilnosti
projektnog tima.
Takoer vano je imati na umu da naruitelj reenja ne
mora nuno da bude i budui korisnik toga reenja. Tako
primerice moe da se desi da se razvojni tim povodi za
naputcima naruitelja (sponzora) projekta, koji je esto u
menaderskoj ili vlasnikoj poziciji, zanemarujui zahteve
krajnjih korisnika (radnika), a da kasnije taj isti naruitelj
plaanje projekta uvjetuje prihvaanjem od strane radnika
buduih korisnika sistema/aplikacije.
U praksi treba biti oprezan u pogledu oekivanja
klijenta/naruitelja te u pregovorima i pojanjavanju
problematike klijentu treba biti i realan jer u suprotnom, u
kasnijim fazama projekta, moemo oekivati pitanja poput:
Ali vi ste to trebali uoiti, Ali to je bio va posao,
Ali nama je to jako skupo, Ali nama je on jako
vaan, Ali rekli ste da e vam trebati toliko, Ali
rekli ste da e to kotati toliko.
Jo jedna vana aktivnost u agilnom upravljanju
projektom je i upravljanje korisnikim oekivanjima. Naime,
isporuka pojedinih dijelova programskog proizvoda se u
razliitim fazama izrade odvija razliitom dinamikom. U
poetnim fazama (iteracijama) razvojni inenjeri vie
vremena provode na definiranje i kreiranje arhitekture
sistema tj. korisniku nevidljivih delova sistema. Kasnije se
vie vremena provodi izraujui funkcionalnosti za krajnje
korisnike. U skladu s tim i korisnikova percepcija procesa
razvoja je drugaija. Moemo u grubo konstatirati kako su
korisnici u inicijalnim fazama projekta nestrpljivi jer im se
ini da se puno vremena gubi, a ne vide rezultate, dok su u
kasnijim fazama pohlepni obzirom da stjeu dojam kako za
kreiranje funkcionalnosti za krajnjeg korisnika treba izrazito

Slika 2. Odnos aktivnosti izrade arhitekture i korisnikih

funkcionalnosti kroz vreme [4]
6. Procenjivanje
Procjena opsega i vremenskog roka potrebnog za
obavljanje posla zamiljenog projektom je veoma vana
aktivnost u celom procesu agilnog razvoja. Poetna procena
temelj je za planiranje resursa, oekivanja klijenta i razvojnog
tima te pretpostavljenu cenu samog projekta. Osim poetne
procene, u toku rada na projektu, razvojni tim trebao bi
periodiki da procenjuje ostatak posla obzirom na
identificirane promene i nova saznanja.
Openito, moemo da kaemo da danas u praksi postoje
dva temeljna naina procenjivanja. Prvi nain je vremenski i
obino se izraava u jedinicama ovek/dan ili ovek/as.
Drugi nain je bodovni i pretpostavlja identificiranje koliko
je bodova teka odreena funkcionalnost koju je potrebno
implementirati u projektu. Kada govorimo o problemu
procenjivanja potrebno je razumeti razliku izmeu tonost i
preciznosti. Naime, ako programer kae da mu je za
obavljanje odreenog posla potrebno 25,6 asova, to je vrlo
precizna informacija. Ako je drugi programer rekao da e za
isti posao biti potrebno 2 dana, onda je to informacija sa
znatno manjom preciznou. Uzmimo za primer da je realno
za taj posao bilo potrebno 16 radnih asova (znai 2 dana),
onda vidimo da je neprecizni procjenitelj bio zapravo puno
blie realnosti tj. njegova procjena je bila tonija. Iz primjera
moemo da zakljuimo kako bi nam tonost trebala biti
vanija od preciznosti same procene.
Pridjeljivanje tehnike kompleksnosti takoer moe da
pridonese realnijoj proceni lanova razvojnog tima.
Razmiljajui o tehnikoj kompleksnosti, procenitelj moe
identificirati potencijalne probleme koji bi mogli da se pojave
bilo da je re o implementaciji ili novim znanjima koja je
potrebno usvojiti kako bi se realizovala potrebna aktivnost
Kod procenjivanja, preporuka je da svi lanovi budueg
razvojnog tima daju svoje miljenje tj. svoju vlastitu procenu.

468

Kod takvog naina procenjivanja, voditelj projekta mora da

ima na umu i individualne karakteristike procenitelja. Neki
lanovi tima po svojoj prirodi mogu da budu pesimisti, a neki
optimisti. Postoje i matematike tehnike kako ovo moe da se
ukljui u konanu procenu i o tome e biti rei u nastavku.
Jedan od matematikih metoda za procenjivanje je i
uveni PERT (engl. Project Evaluation and Review
Technique). PERT dolazi iz podruja mrenog planiranja i
jedan od njegovih elemenata je i matematika tehnika
procenjivanja dana sledeom formulom:

KPp predstavlja procenjenu koliinu posla, O oznaava

optimistinu procenu potrebnog vremena, N je
najverovatnije, a P je pesimistino vreme potrebno za
procenu. Praksa je pokazala da, kada se od lanova tima koji
trebaju da procene odreeni posao zatrai tri vremena
(optimistino, najverovatnije, pesimistino), procenitelji daju
tonije procene. Objanjenje toga je poticanje takvog naina
procenjivanja na dublje promiljanje o problematici o kojoj
se radi. Ukoliko procenitelj mora dati optimistinu procenu,
sam e sebi postavljati pitanja koji su to faktori koji bi mogli
utjecati da se posao obavi u optimistinom roku. Ukoliko se
radi o programerima, verovatno e procenitelju kroz glavu
proi pomisao o ponovnoj iskoristivosti nekog ranije
napisanog koda ili neto slino. Ako se pak od procenitelja
trai pesimistina varijanta, vea je verovatnost da e osoba
promisliti o moguim problemima i moda se prisetiti vie
moguih potekoa negoli da se radi o proceni koja za
rezultat ima samo jednu vrednost, a ne tri kako je to sluaj
kod PERT-a.
Kako se zapravo radi o vaganoj aritmetikoj sredini triju
vrednosti procena, ta formula se moe i korigirati ovisno o
individualnim karakteristikama procjenitelja. Tako se ovisno
o tome je li procenitelj pesimist ili optimist, teite u formuli
moe staviti na optimistino tj. pesimistino vreme, mnoei
to vreme sa faktorom razliitim od 1 i sukladno tome smanjiti
faktor kojim se mnoi najverovatnije procenjeno vreme.
7. Razvojni ciklusi
Razvojni ciklusi su u agilnim metodama organizovani u
cikluse koje se popularno nazivaju i iteracije (engl. Iteration).
Iteracije obuhvaaju aktivnosti razvojnog tima koje kao izlaz
imaju programski kod tj. aplikaciju ili sistem spreman za
uporabu od strane klijenta. Aktivnosti lanova tima esto se u
agilnim metodama predstavljaju zadaama (engl. Task).
Nekoliko zadaa ini posao koji treba odraditi kako bi se
realizovala korisnika pria (engl. User Story). Nekoliko
korisnikih pria moe sainjavati funkcionalnost (engl.
Feature). Dok skup funkcionalnosti moe predstavljati opseg
posla koji mora da se odradi u jednoj iteraciji. Nakon jedne ili
vie iteracija razvoja, moe uslediti isporuka (engl. Delivery).
Isporuka predstavlja preuzimanje funkcionalnosti od strane
naruitelja. Takoer, postoje i agilne metode gde ove granice
nisu strogo definisane pa se tako i po zavretku rada na nekoj
korisnikoj prii i po testiranju iste od strane razvojnog tima
moe odmah prei na isporuku realiziranog dela sistema te
korisnik moe odmah da pone s koritenjem.

Primer hijerarhije ciklusa i aktivnosti u nekom projektu:

Isporuka 1.
Iteracija 1.1.
Funkcionalnost 1.1.1.
Korisnika pria 1.1.1.1.
Task 1.1.1.1.1.
Task 1.1.1.1.2.
Korisnika pria 1.1.1.2.
8. Retrospektive
Restrospektive su sastavni koncept veine dananjih
agilnih metoda za upravljanje projektima izrade softvera.
Restrospektive se izvode nakon svake iteracije (sprinta) i
predstavljaju diskusiju u kojoj sudeluju lanovi razvojnog
tima. Za vreme osvrta na proteklu iteraciju lanovi tima
pokuavaju odgovoriti na sledea pitanja: to nije bilo u
redu?, Gdje smo pogreili?, Kako moemo da izbegnemo
iste probleme u budunosti?.
9. Softver
Iako agilne metode u svojoj sutini minimiziraju kako
dokumentaciju tako i alate (ukljuujui i softverske) ve
fokus stavljaju na ljude i procese, praksa je pokazala kako je
ipak dobro imati nain praenja provoenja agilnih metoda i
osiguranje neke vrste repozitorija svih artefakata projekta u
digitalnom obliku. Razlozi za to su naravno
dokumentaristike prirode. Osim samog bileenja svih
aktivnosti, poeljno je i poveanje efikasnosti i osiguranje
konzistentnosti koritenjem nekog softverskog alata. Vrlo
praktian primer u kojem bi koritenje softvera umjesto
klasine ploe, samoljepljivih papiria i tablinog kalkulatora
bilo poeljno je sluajno otpadanje papiria s ploe zbog loe
kvalitete ljepila, ime se stvara nekonzistentnost u
project/sprint backlog-u.
Svakako, pri odabiru softverskog alata za podrku
agilnom razvoju ne smemo smetnuti s uma samu bit agilnih
metoda i dozvoliti da primena softvera odvede u nepotrebnu
birokratizaciju i otuenje samih lanova tima jednih od
drugih. Upravo stoga, zahtjevi koji se postavljaju pred takav
softver su brzina i jednostavnost koritenja te fleksibilnost u
smislu prilagodbe individualnoj organizaciji/projektu tj.
modifikaciji agilne metode koja se koristi.
10. Popularne agilne metode razvoja softvera
XP - Ekstremno programiranje predstavlja model razvoja
softvera posebno dizajniran za malene i srednje velike
razvojne timove, koji se susreu za ubrzanim promjenama u
zahtjevima. [5] Ekstremno programiranje uvodi niz obrazaca
kojima se pospjeuje razvoj softvera u uvjetima stalnih
promjena zahtjeva. Neki do tih obrazaca su programiranje u
paru, unit testiranje, refaktoriranje, konstantno menjanje i
prilagoavanje arhitekture i kratke iteracije. [6]
Scrum - Agilno upravljanje projektima primjenom Scrum
metodike izvorite ima u radu japanaca Takeuchi-a i Nonakae i njihovih analiza najboljih praksi u kompanijama poput
Fuji-Xerox, Honda, Canon i Toyota. [7] Scrum je metodika
razvoja softvera koja sledi sve paradigme agilnog razvoja i
donosi obrasce za upravljanje timom i razvojnim ciklusom

469

programskog proizvoda. Samo ime metodike dolazi iz

amerikog nogometa i inspirirano je nainom na se koji
timovi u tom sportu dogovaraju prije akcije i kako malo po
malo kroz sprintove osvajaju teritoriju. Razvojni ciklus u
Scrumu se naziva Sprint. Sprint je zapravo jedna iteracija u
razvoju i obino traje od dva tjedna do pet tjedana. Scrum
poput veine ostalih agilnih metoda podrazumijeva koritenje
korisnikih pria za planiranje i izvoenje projekta. Sve
korisnike prie koje opisuju rad planiran za projekt ine tzv.
Project Backlog, dok skup korisnikih pria koje e se
realizirati za vreme jednog Sprinta ine Sprint Backlog, a
primjer je dan na slici 3.

Slika 3. Sprint backlog [6]

Ostale metode - Osim XP-a i Scrum-a koji su danas
najrasprostranjenije agilne metode, u strunoj i znanstvenoj
literaturi mogu se pronai i brojne druge metode za agilno
upravljanje projektima i to ne samo za industriju proizvodnje
softvera. Od agilnih metoda za proizvodnju softvera moemo
pomenuti FDD (engl. Feature Driven Development), TDD
(Test Driven Development), Kanban itd. no njihovo
opisivanje nadilazi okvire ovog rada. Osim navedenih i neki
stariji ustaljeni okviri upravljanja projektima razvoja softvera
u novije vreme dobivaju inaice za agilni razvoj. Tako
primerice i popularni Microsoftov MSF (engl. Microsoft
Solution Framework) ima inaicu za agilni razvoj.
11. Zato agilne metode nisu panacea za projektni
menadment (pogotovo kod nas)
U praksi se pokazalo kako prakticiranje agilnih metoda
uvelike moe da povea procenat uspenosti IT projekata
obzirom da razvojni tim kroz intenzivnu komunikaciju s
klijentom i odgovaranje na promene u zahtevima koje nastaju
u tijeku provoenja projekta stjee bolji uvid u stvarne
korisnikove potrebe i na taj nain kreira softver koji je
usklaeniji sa korisnikim oekivanjima. Iako agilne metode
imaju mnogo pozitivnih strana, postoje i problemi s kojima se
suoavaju praktiari. Ti problemi tiu se znanja steenih u
radu, obzirom da ne postoji opirna dokumentacija, velikih
napora koje klijent mora uloiti, obzirom da se od njega
oekuje ukljuenost u razvoj, nedoreenosti u smislu pravne
popraenosti projekta, obzirom da ne postoje smjernice za
stvaranje agilnog ugovora te problem finansiranja i
osiguravanja projektnog budeta, obzirom da se od agilnog
tima oekuje prilagoavanje promenama u zahtevima to
neminovno znai i probijanje vremenskog okvira projekta.

Postavlja se dakle pitanje to sa rokovima i to sa cenom

izrade softvera? Slobodno moemo da kaemo sledee ako
se radi o agilnom projektu i agilnom timu, nuno je da i
klijent bude agilan. Kako u smislu saradnje, tako i u smislu
plaanja vae agilnosti.
12. Zakljuak
Agilne metode razvoja softvera naglasak stavljaju na veu
komunikaciju i kreiranje korisnog programskog proizvoda, a
u drugi plan su stavljeni strogi okviri unaprijed definisanih
projektnih faza i opirna dokumentacija. U praksi se pokazalo
kako prakticiranje agilnih metoda uvelike moe da povea
procenat uspenosti IT projekata obzirom da razvojni tim
kroz intenzivnu komunikaciju s klijentom i odgovaranje na
promene u zahtevima koje nastaju u tijeku provoenja
projekta stjee bolji uvid u stvarne korisnikove potrebe i na
taj nain kreira softver koji je usklaeniji sa korisnikim
oekivanjima. Iako agilne metode imaju mnogo pozitivnih
strana, postoje i problemi s kojima se suoavaju praktiari. Ti
problemi tiu se znanja steenih u radu, obzirom da ne postoji
opirna dokumentacija, velikih napora koje klijent mora
uloiti, obzirom da se od njega oekuje ukljuenost u razvoj,
nedoreenosti u smislu pravne popraenosti projekta,
obzirom da ne postoje smernice za stvaranje agilnog ugovora
te problem finansiranja i osiguravanja projektnog budeta, jer
se od agilnog tima oekuje prilagoavanje promenama u
zahtevima to neminovno znai i probijanje vremenskog
okvira projekta. Svi ovi, ali i neki drugi problemi
prakticiranja agilnih metoda mogu biti predmet buduih
istraivanja iz ove domene.
LITERATURA
[1]

Agile Manifesto, http://agilemanifesto.org/

[2]
Jim Highsmith. (2004). Agile Project Management:
Creating Innovative Products. Addison Wesley.
[3]
MSF for Agile Software Development Process
Guidance:
http://www.microsoft.com/downloads/details.aspx?FamilyId
=9F3EA426-C2B2-4264-BA0F35A021D85234&displaylang=en
[4]
Mountain Goat Software
http://www.mountaingoatsofware.com
[5]
Beck, K. (1999). Extreme Programming Explained:
Embrace Change. Addison-Wesley Professional.
[6]
Padavi, I. (2009). Postupak evaluacije te
implementacija agilnog modela razvoja softvera, diplomski
rad. Varadin: Fakultet organizacije i informatike.
[7]
Sutherland, J., Viktorov, A., & Blount, J. (2006).
Distributed Scrum: Agile Project Management with
Outsourced Development. Agile 2006, international
Conference. Mineapolis.

470