INFOTEH-JAHORINA Vol. 11, March 2012.
Agilni pristup upravljanju softverskim projektima
Milica Nekovi, Mladen Rakovi
Katedra za raunarstvo
Elektronski fakultet
Ni, Srbija
milica.m.neskovic@gmail.com, mladen.rakovic@hotmail.com
SadrajSavremena dostignua u domenu Informacionih
tehnologija rezultuju porastom broja projekata u oblasti
softverskog inenjerstva. Obzirom na osobenosti ovakvih
projekata u odnosu na ostale inenjerske discipline, intenzivno se
istrauju metodologije za njihovim efikasnim upravljanjem.
Kroz ovaj rad predlaemo agilni pristup upravljanju projektima
uz Scrum metodologiju kao najoptimalniji nain za ostvarivanje
primarnih ciljeva projekta: izradu softvera, koji u potpunosti
zadovoljava korisnike zahteve, i njegovu dostavu na vreme, a u
okruenju koje ini agilan razvojni tim motivisan za nove
izazove. (Abstract)
Kljune rei-agilna metodologija; Scrum; sprint; (key words)
I. UVOD
Softversko inenjerstvo se u velikoj meri razlikuje od
ostalih inenjerskih disciplina. Razmotrimo osnovne razlike
[1]:
Proizvod je nedodirljiv:
Tokom izrade opipljivih proizvoda, menader u svakom
momentu moe pratiti razvoj kroz sagledavanje samog
proizvoda. Meutim, u procesu razvoja softvera, esto je
nemogue sagledati napredak dok se ne doe do zavrne faze.
Samim tim, tee je uoiti eventualne zastoje u izradi proizvoda
i preduprediti nepotovanje postavljenih rokova.
Ne postoji standardni nain za razvoj softvera:
Softver se u mnogo emu razlikuje od organizacije do
organizacije, naroito ako je softver deo velikih inenjerskih
projekata.
Veliki softverski projekti se uglavnom znatno razlikuju
od prethodnih projekata:
Zbog toga ak i menaderi sa iskustvom ne mogu uvek da
predvide probleme u realizaciji projekta. Takoe, stalni razvoj
Informacionih tehnologija esto ponitava prethodno iskustvo i
zahteva prilagoavanje novim tehnologijama, koje sa sobom
nose nove eventualne potekoe u izradi softvera.
Prethodno navedene injenice znatno oteavaju postupak
upravljanja projektom u oblasti softverskog inenjerstva.
U ovom radu analiziramo najee korienje metodologije
za upravljanje softverskim projektima i izdvajamo agilni
pristup kroz njegovu integraciju u sve faze upravljanja
projektom i isticanje uloge u efikasnom ostvarivanju
postavljenih ciljeva projekta.
II. UPRAVLJANJE PROJEKTOM POJAM I FAZE
Upravljanje projektom podrazumeva definisanje ciljeva
projekta, planiranje projekta, procenu njegovog trajanja i
kontrolisanje aktivnosti u procesu realizacije projekta kako bi
se blagovremeno ostvarili ciljevi projekta [2]. Ove zadatke
sprovodi menader projekta.
A. Definisanje ciljeva projekta
Definisanje ciljeva projekta se oslanja na prikupljanje
zahteva od krajnjih korisnika softvera. Zahtevi se mogu
dokumentovati u funkcionalnim specifikacijama ili kreiranjem
korisnikih pria (User Stories), zavisno od toga koja metoda
e biti koriena u procesu planiranja projekta. Vano je
prikupiti to vie zahteva i stei to kompletniju sliku o
funkcionalnosti i izgledu projekta pre nego to e se krenuti sa
njegovom realizacijom. Zavisno od korienog metoda za
upravljanje projektom, korisniki zahtevi se mogu redovno
revidirati i planirati dalji koraci u razvoju aplikacije.
B. Planiranje i realizacija projekta
Inicijalni korak u planiranju projekta je priprema resursa
kroz planiranje ljudskih, materijalnih i trokovnih resursa.
Raspoloivost resursa direktno utie na obim projekta, kao i na
planirani period realizacije.
Nakon toga vri se izbor metodologije za upravljanje
projektom.
Pod metodologijom se podrazumeva skup smernica ili
principa, koje mogu biti oblikovane i primenjene u odreenoj
situaciji [3]. Upravo od mogunosti primene i ciljeva projekta
zavisi koja e metodologija biti koriena za njegovo planiranje
i realizaciju.
Postoje brojne metodologije za planiranje i upravljanje
realizacijom projekta [3]: tradicionalna (waterfall), agilna,
reverzno inenjerstvo, Open Source metodologija, rad sa
prototipovima i mnoge druge. U ovom radu emo se bazirati na
osobine tradicionalnog i agilnog pristupa kao najee
korienih.
Tradicionalni pristup podrazumeva realizaciju projekta
korak po korak kroz 5 faza:
1. Analiza zahteva i izrada specifikacija;
2. Arhitekturalni dizajn;
3. Implementacija i integracija;
4. Verifikacija, testiranje;
- 814 -
5. Dostavljanje i odravanje softvera.
Posmatrani pristup se esto koristio zbog mogunosti ranog
otkrivanja greaka u funkcionisanju softvera bug-ova. Tokom
prikupljanja korisnikih zahteva i planiranja kroz specifikaciju
se mnoge greke mogu preduprediti. Ovakav pristup je znatno
isplativiji od postupka pronalaenja neispravnosti u fazi
testiranja. Pored toga, iscrpna dokumentacija u ovakvom
pristupu znatno olakava integraciju novih lanova u razvojni
tim.
Tradicionalni pristup se i dalje moe primenjivati u
sistemima gde ne dolazi do este izmene korisnikih zahteva.
Meutim, softverski sistemi jednostavno nisu takvi. Najei je
sluaj da korisnici nakon prvog uvida u aplikaciju trae
ogromne izmene tvrdei da proizvod ne ispunjava njihova
oekivanja. Ovo iziskuje ogromne trokove za razvojni tim i
produava period realizacije projekta.
Razmotrimo prethodni pristup na primeru kreiranja 4 nove
karakteristike (features) softvera. Krajnji korisnici mogu videti
rezultate rada tek kada se okonane sve aktivnosti na projektu,
odnosno kada su sve 4 karakteristike implementirane. Tokom
pregleda i dopune ovakvih planova, menader projekta je
uglavnom koncentrisan na pronalaenje nedostajuih aktivnosti
umesto na nedostajue karakteristike. Pored toga, prilikom
realizacije ovakvih planova esto dolazi do nepotovanja
rokova zbog meuzavisnosti aktivnosti, pa se samim tim
kanjenje u jednoj aktivnosti odraava na trajanje samog
projekta. Menader moe pokuati da to prevazie tako to e
smanjiti vreme utroeno na kontrolu kvaliteta proizvoda,
odnosno testiranje, ime se poveava mogunost isporuke
nestabilnog softvera, koji moe izazvati nezadovoljstvo
korisnika i ak eventualni prekid dalje saradnje.
Zbog pomenutih problema, uveden je agilni pristup
upravljanju projektima. Osnovni postulat agilnog pristupa tvrdi
da je softver koji radi glavno merilo napretka projekta [4].
Umesto faza u realizaciji projekta, neophodno je vriti
kontinuirane izrade prototipova softvera, koji e se periodino
dostavljati korisnicima. Ovo je iterativni pristup razvoju
softvera.
Nakon prikupljanja korisnikih povratnih informacija
pristupa se izmenama softvera u tenji da se proizvede softver
koji u potpunosti zadovoljava njihove zahteve.
Razmotrimo Scrum [4] kao reprezentativnu agilnu
metodologiju.
Scrum zagovara iterativni pristup planiranju i realizaciji
projekta kroz modelovanje uloga lanova tima. Obuhvata
sledee faze:
1. Izabrati lana tima koji ima ulogu vlasnika proizvoda
(Product Owner):
Njegov zadatak je da odredi cilj projekta na osnovu
interakcije sa korisnicima i da definie prioritete u njegovom
razvoju. Preporuka je izabrati osobu, koja ve dobro poznaje
poslovanje klijenta ili se moe brzo integrisati i samim tim
obuhvatiti i usmeriti njihove zahteve.
2. Izabrati lana tima koji ima ulogu Scrum Master-a:
Scrum Master organizuje tim u procesu izrade plana,
obuava ga u pravcu sprovoenja metodologije i uklanja
prepreke u sprovoenju metodologije i realizaciji projekta.
Obe pomenute uloge esto obavlja ista osoba najee
menader projekta.
3. Organizovati sastanak tima sa sledeim zadacima:
Definisati Product Backlog:
Product Backlog obuhvata sve funkcionalne i
nefunkcionalne karakteristike softvera iskazane korisnikim
priama (User Stories).
Prioritizovati Product Backlog:
To je zadatak Product Owner-a. Podrazumeva postavljanje
prioriteta meu zadacima na osnovu logikog sleda i hitnosti
dobijanja odreene funkcionalnosti bilo da je ona iskazana od
strane korisnika ili definisana od strane razvojnog tima.
Product Backlog se iskazuje korisnikim priama, koje zapravo
predstavljaju poslovnu terminologije koja je od znaaja za
korisnika.
Definisati trajanje korisnikih pria:
Veliina korisnikih pria iskazuje se u poenima (Story
Points). Svaka pria dobija odreenu vrednost na osnovu
procenjene teine na nivou tima. U procenama se preporuuje
upotreba Fibonaijevih brojeva. Procene se daju kroz tzv.
planski poker (Planning Poker) tako to svaki lan tima daje
svoju procenu, a dalje se dogovorno vri usaglaavanje. Poker
se ponavlja sve dok svi lanovi tima ne daju isti broj poena
korisnikoj prii. Ovim se inicijalni sastanak sa timom
zavrava. Ukoliko je obim neke od korisnikih pria isuvie
veliki (21 poen ili vie), poeljno je takve korisnike prie
rastaviti na 2 manje, a zatim definisati njihove veliine.
Granulacijom zadatka se dodatno smanjuje verovatnoa za
pogrenim procenama usled okvirnih procena prevelikog
zadatka.
4. Analizirati prioritete:
Analiza prioriteta podrazumeva preispitivanje prioriteta
korisnikih pria nakon to je definisana njihova veliina.
Nekada se prioriteti menjaju tako to se korisnike prie koje
krae traju pomeraju na poetak ciklusa, dok se obimnije
korisnike prie odlau za kasnije, mada se uvek mora voditi
rauna o logikom sledu korisnikih pria, kao i prioritetu
realizacije na osnovu informacija od korisnika.
5. Organizovati sastanak tima sa sledeim zadacima:
Definisati duinu iteracije:
U Scrum metodologiji iteracija se naziva sprintom. Sprint
treba da traje izmeu jedne i etiri nedelje.
Definisati pojedinane zadatke u okviru svake
korisnike prie:
Zadaci ne moraju biti korisniki orijentisani i mogu
obuhvatati faze u razvoju softvera: dizajn, razvoj, unit
testiranje, UAT (User Acceptance Testing).
Procene trajanja zadataka u satima:
- 815 -
 Za svaki zadatak se relevantni zaposleni za njegovu
realizaciju dogovaraju u vezi duine trajanja i donose procenu.
Na odluku mogu uticati i ostali lanovi tima kroz precizno
razjanjavanje zaduenja. Vano je naglasiti da se ne definie
koji resurs e obavljati odreeni zadatak. Tim mora da
funkcionie kao celina i da se organizuje u pravcu realizacije
zadatka bez isticanja pojedinaca.
Izbor korisnikih pria, koje e ui u sprint:
Na osnovu trajanja zadataka, pa samim tim i trajanja
implementacije svake zaokruene celine, odabrati korisnike
prie, koji e ui u sprint. Preporuljivo je pripremiti i dodatne
prie, koji bi se potencijalno mogle odraditi ukoliko bi sprint
bio okonan pre roka, ali se ne obavezivati na njihovu
realizaciju Product Owner-u. Ovim se sastanak sa timom
zavrava.
6. Odabrati softver za sprovoenje agilne metodologije:
Mogu se koristiti razliiti alati, kao to su ScrumWorks,
iceScrum, JIRA uz korienje dodatka GreenHopper. Vri se
kreiranje sprinta i korisnikih pria u njemu. Svaka korisnika
pria sadri zadatke, koji se mogu rasporeivati resursima.
Zadaci su grupisani u kategorije Uraditi, U toku, Zavreno.
Zavisno od upotrebljenog softvera, mogu se dodati i nove
kategorije kao to su Product Backlog, koji sadri korisnike
prie za implementaciju, ili Zastoji, koji obuhvata zadatke koji
kasne sa realizacijom. Svi lanovi tima se u razliitim
svojstvima mogu prijavljivati u aplikaciju i prikazivati
realizaciju svojih zadataka kroz njihovo prevlaenje iz jedne
kategorije u drugu. Na ovaj nain sprint zapoinje.
7. Pratiti realizaciju projekta:
Sa poetkom sprinta zapoinje se realizacija projekta.
Zadatak Scrum Master-a je da prati realizaciju projekta kroz
dnevne i nedeljne sastanke sa timom, uoava zastoje u
realizaciji i radi na njihovom prevazilaenju.
8. Zakljuiti sprint uenje zasnovano na prethodnom
iskustvu:
Na kraju iteracije sabiraju se poeni dodeljeni svakoj
korisnikoj prii i na taj nain se utvruje obim sprinta izraen
u poenima. Pored toga, zadatak Scrum Master-a je da sa timom
utvrdi ta je oteavalo sprint, ta se moe uiniti da se sledei
sprint popravi i odluiti ta e tim uraditi drugaije u narednom
sprintu.
III. PRIMER AGILNOG PRISTUPA UPRAVLJANJU PROJEKTOM
Razmotrimo pomenuti pristup na primeru projekta izrade
Web aplikacije za evidenciju zaposlenih u jednoj kompaniji -
eZaposleni.
Najpre se definiu lanovi tima, koji e se ponaati kao
Product Owner i Scrum Master. Pomenute osobe moraju dobro
poznavati razvojni tim (naroito se odnosi na Scrum Master-a)
i potrebe aplikacije koja se izrauje (naroito se odnosi na
Product Owner-a). Obzirom na to da ovaj posao esto obavlja
ista osoba, vano je ouvati ideju o razvoju softvera koji
isporuuje traene karakteristike softvera korisniku i ne bazirati
se na pojedinane aktivnosti razvojnog tima, tj. ne prevariti se i
ne skliznuti u tradicionalni menadment projektom gubei iz
vida potrebe korisnika.
Nakon definisanja krucijalnih uloga lanova tima, pristupa
se definisanju prioriteta u Product Backlog-u.
Poetna funkcionalnost, koju bi aplikacija trebalo da ponudi
korisnicima je mogunost kreiranja novog zaposlenog, pregled
njegovih podataka, izmena podataka i brisanje zaposlenog.
Pomenute karakteristike aplikacije se mogu objediniti u
poetnom sprintu, gde e svaka pomenuta karakteristika
aplikacije predstavljati posebnu opciju (feature).
Pomenute karakteristike se mogu modelovati preko
sledeih korisnikih pria:
Kao administrator, elim da dodam novog zaposlenog
aplikaciji.
Kao administrator, elim da vidim podatke o
kreiranom zaposlenom u aplikaciji.
Kao administrator, elim da menjam podatke o
zaposlenom.
Kao administrator, elim mogunost da uklonim
zaposlenog iz aplikacije.
Pored navedenih korisnikih pria, poeljno je definisati i
dodatne, koje e biti smetene u Product Backlog. One se
mogu planirati za naredne iteracije i koristiti za planiranje
release-a aplikacije. Takoe mogu posluiti kao rezerva
ukoliko se sprint eventualno zavri ranije.
Za svaku korisniku priu se definie obim u poenima.
Prilikom definisanja veliine zadataka, kao najbolji pristup
pokazuje se izdvajanje najmanje korisnike prie kojoj e se
dodeliti 1 poen. Razvojnom timu e dalje biti lake da definie
poene za ostale korisnike prie, jer e imati inicijalnu priu sa
kojom e moi da porede svaku narednu. Za navedenu
aplikaciju, utvreni poeni prvog sprinta su sledei: 5, 1, 3, 3.
Nije vrena dodatna revizija prioriteta, jer su dobijeni poeni bili
oekivani od strane menadera projekta.
Dobijene korisnike prie se dalje segmentiu na
pojedinane zadatke i unosi se vreme predvieno za realizaciju
svakog zadatka.
Deljenje korisnikih pria na zadatke moe se vriti
razdvajanjem na aktivnosti u razvojnom procesu. Na primer, za
poetnu korisniku priu se mogu definisati sledei zadaci:
Novi zaposleni serverska strana
Novi zaposleni korisniki interfejs
Testirati dodavanje novog zaposlenog
Za definisane zadatke se definie i vreme trajanja u
idealnim satima, odnosno efektivnom broju sati koje bi lan
tima potroio na njegovo odraivanje. Za navedene zadatke,
utvrena vremena trajanja su po 10 asova za svaki zadatak.
Potrebno je voditi rauna o meuzavisnosti zadataka tokom
definisanja trajanja korisnike prie. Serverska strana i
korisniki interfejs se obino mogu razvijati paralelno s tim to
se izvesno vreme potroi na njihovu integraciju. Testiranje
- 816 -
implementirane funkcionalnosti obino u potpunosti zavisi od
prethodnih zadataka. Samim tim, trajanja svih zadataka se ne
mogu jednostavno sabrati, jer bi to impliciralo meusobnu
uslovljenost svih zadataka, koja ne mora nuno da postoji.
Prilikom definisanja trajanja korisnike prie preporuujemo
da se za zadatke, koji se izvravaju paralelno, kao njihovo
vreme trajanja usvoji vreme potrebno za realizaciju dueg
zadatka i da mu se doda vreme potrebno za testiranje. U naem
primeru, obzirom da i razvoj na serverskoj strani i korisnikom
interfejsu traju paralelno po 10 asova, usvojiemo 10 asova
kao trajanje ovih zadataka. Ovom vremenu emo dodati vreme
potrebno za testiranje funkcionalnsoti. Dolazi se do zakljuka
da posmatrana korisnika pria ima predvieno trajanje od 20
asova.
Obzirom da je agilni pristup test-driven [4], potrebno je da
procene obuhvate i vreme potrebno za unit testiranje, kao i za
acceptance testiranje.
Slian postupak se sprovodi i za ostale korisnike prie.
Nakon to se definie vreme trajanja sprinta (1 4 nedelje),
potrebno je ukljuiti odreeni broj korisnikih pria u sprint na
osnovu njihovog predvienog trajanja. Preostale korisnike
prie ostaju u Product Backlog-u.
Prilikom definisanja korisnikih pria, koje e ui u sprint,
definisano je i trajanje samog sprinta u Story Point-ima i
idealnim satima. Na osnovu ovih podataka se mogu grubo
planirati naredni sprintovi i konani release aplikacije. Nakon
svakog sprinta, ovakve okvirne planove je potrebno revidirati i
dopuniti. Samim tim e i release plan biti sve konkretniji sa
svakim realizovanim sprintom.
Za automatizaciju agilnog upravljanja projektom korien
je ScrumWorks softver.
Instaliran je ScrumWorks Pro Server 5.1.0, koji integrie
desktop aplikaciju ScrumWorks Pro Desktop Client i
jednostavniji ScrumWorks Pro Web Client [5] (Sl. 1).
Podacima smetenim na serveru se moe pristupati kroz obe
aplikacije.
Slika 1. Primer praenja sprinta u ScrumWorks aplikaciji
Desktop aplikacija se koristi za konfiguraciju projekta kroz
kreiranje projekta, release-ova, sprintova, timova, korisnika i
modelovanje njihovih uloga. Pored toga, moe se koristiti i za
kreiranje korisnikih pria i zadataka unutar njih. Web
- 817 -
aplikacija je znatno jednostavnija i omoguava samo
manipulaciju korisnikim priama i zadacima, pa e zato biti
koriena u svakodnevnom radu lanova tima.
Sve korisnike prie su smetene u sekciji Backlog Items.
Njihov prioritet se moe menjati jednostavnim prevlaenjem
iznad ili ispod prethodnika, odnosno sledbenika.
Zadaci koji pripadaju priama se nalaze u Not Started
sekciji. Svaki zaposleni moe poeti rad na zadatku tako to e
ga jednostavno prevui (drag-and-drop) u sekciju In Progress
ili manuelno promeniti njegov status. Kada se zadatak okona,
moe se premestiti u sekciju Done.
Pored toga, postoji i sekcija Impeded za zadatke sa
tekoama u realizaciji. Jedan od zadataka Scrum Master-a je
da uoi potekoe na vreme i da pokua da ih otkloni.
Kroz ovaj softver, Scrum Master ima centralizovan pristup
informacijama vezanim za sprint koji se sprovodi, moe pratiti
njihov progres, na vreme lokalizovati potekoe, planirati
trajanje release-a i blagovremeno aurirati podatke.
Nakon zavretka sprinta, proizvod se moe dostaviti
krajnjem korisniku u vidu Preview Build-a. Dobijene povratne
informacije se mogu koristiti za izmenu ili dopunu ve
postojeih zahteva po pitanju novih karakteristika aplikacije,
pri emu e se znaajno poveati ansa da korisnik dobije
proizvod koji u potpunosti zadovoljava njegove zahteve.
Zadovoljstvo korisnika otvara mogunost za nove projekte sa
njim ili njegovim partnerima, kojima bi mogao preneti
pozitivna iskustva iz saradnje sa razvojnim timom.
ZAKLJUAK
U ovom radu analizirali smo osnovne faze u upravljanju
projektima, definisali potencijalne potekoe u realizaciji
projekta i preporuili agilnu metodologiju kao pristup koji ima
najbolji efekat na blagovremenu realizaciju ciljeva projekta.
Pored toga, pozitivno utie na razvojni tim na sledeim
poljima:
podstie timski duh,
smanjuje pritisak na pojedinca,
motivie tim za naredne sprintove.
Osim povoljnog uticaja na razvojni tim, potvrdili smo da se
na ovaj nain doprinosi razvoju softvera, koji integrie
korisnike povratne informacije i samim tim u velikoj meri
zadovoljava korisnike zahteve, a to je svakako jedan od
ciljeva projekta, jer zadovoljan korisnik je esto garancija za
buduu saradnju.
LITERATURA
[1] I. Sommerville, Software Engineering, Addison Wesley, 2006.
[2] J. P. Leviw, Fundamentals of Project Management, Amacom Books,
1995
[3] J. Charvat, Project Management Methodologies: Selecting,
Implementing, and Supporting Methodologies and Processes for
Projects, John Wiley & Sons, 2003
[4] K. Schwaber, Agile Project Management with Scrum, Microsoft Press,
2004
[5] http://danube.com/docs/scrumworks/pro/latest/userguide.html, management with Scrum methodology as the most
Copyright 2011 CollabNet, Inc. All rights reserved. optimal way of achieving the primary objectives of project.
Primary objectives of project are making the software, which
ABSTRACT fully meets the user requirements, ensures delivery on time and
Recent achievements in the field of in an environment that makes agile development
information technology cause increase of the number of team motivated for new challenges.
projects in the field of software engineering. Having in mind
the characteristics of such projects, in relation to AGILE APPROACH TO SOFTWARE PROJECT
other engineering disciplines, there is a necessity for MANAGEMENT
customized software project management methodology. Milica Neskovic, Mladen Rakovic
Through this paper we propose an agile approach to project

- 818 -