7/25/2019 RSS-6-5.pdf

1/5

INFOTEH-JAHORINA Vol. 11, March 2012.

- 814 -

Agilni pristup upravljanju softverskim projektima

Milica Nekovi, Mladen Rakovi

Katedra za raunarstvo

Elektronski fakultet

Ni, Srbijamilica.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 ovakvihprojekata u odnosu na ostale inenjerske discipline, intenzivno seistrauju metodologije za njihovim efikasnim upravljanjem.

Kroz ovaj rad predlaemo agilni pristup upravljanju projektimauz Scrum metodologiju kao najoptimalniji nain za ostvarivanje

primarnih ciljeva projekta: izradu softvera, koji u potpunostizadovoljava 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 odostalih inenjerskih disciplina. Razmotrimo osnovne razlike[1]:

Proizvod je nedodirljiv:

Tokom izrade opipljivih proizvoda, menader u svakommomentu moe pratiti razvoj kroz sagledavanje samogproizvoda. 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 proizvodai preduprediti nepotovanje postavljenih rokova.

Ne postoji standardni nain za razvoj softvera:

Softver se u mnogo emu razlikuje od organizacije doorganizacije, naroito ako je softver deo velikih inenjerskihprojekata.

Veliki softverski projekti se uglavnom znatno razlikujuod prethodnih projekata:

Zbog toga ak i menaderi sa iskustvom ne mogu uvek dapredvide probleme u realizaciji projekta. Takoe, stalni razvoj

Informacionih tehnologija esto ponitava prethodno iskustvo izahteva prilagoavanje novim tehnologijama, koje sa sobomnose nove eventualne potekoe u izradi softvera.

Prethodno navedene injenice znatno oteavaju postupakupravljanja projektom u oblasti softverskog inenjerstva.

U ovom radu analiziramo najee korienje metodologijeza upravljanje softverskim projektima i izdvajamo agilnipristup kroz njegovu integraciju u sve faze upravljanjaprojektom i isticanje uloge u efikasnom ostvarivanjupostavljenih ciljeva projekta.

II. UPRAVLJANJE PROJEKTOMPOJAM I FAZE

Upravljanje projektom podrazumeva definisanje ciljevaprojekta, planiranje projekta, procenu njegovog trajanja ikontrolisanje aktivnosti u procesu realizacije projekta kako bise blagovremeno ostvarili ciljevi projekta [2]. Ove zadatkesprovodi menader projekta.

A. Definisanje ciljeva projekta

Definisanje ciljeva projekta se oslanja na prikupljanje

zahteva od krajnjih korisnika softvera. Zahtevi se mogudokumentovati u funkcionalnim specifikacijama ili kreiranjemkorisnikih pria (User Stories), zavisno od toga koja metodae biti koriena u procesu planiranja projekta. Vano jeprikupiti to vie zahteva i stei to kompletniju sliku ofunkcionalnosti i izgledu projekta pre nego to e se krenuti sanjegovom realizacijom. Zavisno od korienog metoda zaupravljanje projektom, korisniki zahtevi se mogu redovnorevidirati i planirati dalji koraci u razvoju aplikacije.

B. Planiranje i realizacija projekta

Inicijalni korak u planiranju projekta je priprema resursakroz planiranje ljudskih, materijalnih i trokovnih resursa.

Raspoloivost resursa direktno utie na obim projekta, kao i naplanirani period realizacije.

Nakon toga vri se izbor metodologije za upravljanjeprojektom.

Pod metodologijom se podrazumeva skup smernica iliprincipa, koje mogu biti oblikovane i primenjene u odreenojsituaciji [3]. Upravo od mogunosti primene i ciljeva projektazavisi koja e metodologija biti koriena za njegovo planiranjei realizaciju.

Postoje brojne metodologije za planiranje i upravljanjerealizacijom projekta [3]: tradicionalna (waterfall), agilna,reverzno inenjerstvo, Open Source metodologija, rad sa

prototipovima i mnoge druge. U ovom radu emo se bazirati naosobine tradicionalnog i agilnog pristupa kao najeekorienih.

Tradicionalni pristup podrazumeva realizaciju projektakorak po korak kroz 5 faza:

1. Analiza zahteva i izrada specifikacija;

2. Arhitekturalni dizajn;

3. Implementacija i integracija;

4. Verifikacija, testiranje;

7/25/2019 RSS-6-5.pdf

2/5

- 815 -

5. Dostavljanje i odravanje softvera.

Posmatrani pristup se esto koristio zbog mogunosti ranogotkrivanja greaka u funkcionisanju softvera bug-ova. Tokomprikupljanja korisnikih zahteva i planiranja kroz specifikacijuse mnoge greke mogu preduprediti. Ovakav pristup je znatnoisplativiji od postupka pronalaenja neispravnosti u fazitestiranja. Pored toga, iscrpna dokumentacija u ovakvompristupu znatno olakava integraciju novih lanova u razvojnitim.

Tradicionalni pristup se i dalje moe primenjivati usistemima gde ne dolazi do este izmene korisnikih zahteva.Meutim, softverski sistemi jednostavno nisu takvi. Najei jesluaj da korisnici nakon prvog uvida u aplikaciju traeogromne izmene tvrdei da proizvod ne ispunjava njihovaoekivanja. Ovo iziskuje ogromne trokove za razvojni tim iproduava period realizacije projekta.

Razmotrimo prethodni pristup na primeru kreiranja 4 novekarakteristike (features) softvera. Krajnji korisnici mogu videtirezultate rada tek kada se okonane sve aktivnosti na projektu,odnosno kada su sve 4 karakteristike implementirane. Tokom

pregleda i dopune ovakvih planova, menader projekta jeuglavnom koncentrisan na pronalaenje nedostajuih aktivnostiumesto na nedostajue karakteristike. Pored toga, prilikomrealizacije ovakvih planova esto dolazi do nepotovanjarokova zbog meuzavisnosti aktivnosti, pa se samim timkanjenje u jednoj aktivnosti odraava na trajanje samogprojekta. Menader moe pokuati da to prevazie tako to esmanjiti vreme utroeno na kontrolu kvaliteta proizvoda,odnosno testiranje, ime se poveava mogunost isporukenestabilnog softvera, koji moe izazvati nezadovoljstvokorisnika i ak eventualni prekid dalje saradnje.

Zbog pomenutih problema, uveden je agilni pristupupravljanju projektima. Osnovni postulat agilnog pristupa tvrdi

da je softver koji radi glavno merilo napretka projekta [4].Umesto faza u realizaciji projekta, neophodno je vritikontinuirane izrade prototipova softvera, koji e se periodinodostavljati korisnicima. Ovo je iterativni pristup razvojusoftvera.

Nakon prikupljanja korisnikih povratnih informacijapristupa se izmenama softvera u tenji da se proizvede softverkoji u potpunosti zadovoljava njihove zahteve.

Razmotrimo Scrum [4] kao reprezentativnu agilnumetodologiju.

Scrum zagovara iterativni pristup planiranju i realizacijiprojekta 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 osnovuinterakcije sa korisnicima i da definie prioritete u njegovomrazvoju. Preporuka je izabrati osobu, koja ve dobro poznajeposlovanje klijenta ili se moe brzo integrisati i samim timobuhvatiti 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 uklanjaprepreke u sprovoenju metodologije i realizaciji projekta.

Obe pomenute uloge esto obavlja ista osoba najeemenader projekta.

3. Organizovati sastanak tima sa sledeim zadacima:

DefinisatiProduct Backlog:Product Backlog obuhvata sve funkcionalne i

nefunkcionalne karakteristike softvera iskazane korisnikimpriama (User Stories).

PrioritizovatiProduct Backlog:

To je zadatakProduct Owner-a. Podrazumeva postavljanjeprioriteta meu zadacima na osnovu logikog sleda i hitnostidobijanja odreene funkcionalnosti bilo da je ona iskazana odstrane korisnika ili definisana od strane razvojnog tima.Product Backlogse iskazuje korisnikim priama, koje zapravopredstavljaju poslovnu terminologije koja je od znaaja zakorisnika.

Definisati trajanje korisnikih pria:

Veliina korisnikih pria iskazuje se u poenima (StoryPoints). Svaka pria dobija odreenu vrednost na osnovuprocenjene teine na nivou tima. U procenama se preporuujeupotreba Fibonaijevih brojeva. Procene se daju kroz tzv.planski poker (PlanningPoker) tako to svaki lan tima dajesvoju procenu, a dalje se dogovorno vri usaglaavanje. Pokerse ponavlja sve dok svi lanovi tima ne daju isti broj poenakorisnikoj prii. Ovim se inicijalni sastanak sa timomzavrava. Ukoliko je obim neke od korisnikih pria isuvieveliki (21 poen ili vie), poeljno je takve korisnike prierastaviti na 2 manje, a zatim definisati njihove veliine.Granulacijom zadatka se dodatno smanjuje verovatnoa za

pogrenim procenama usled okvirnih procena prevelikogzadatka.

4. Analizirati prioritete:

Analiza prioriteta podrazumeva preispitivanje prioritetakorisnikih pria nakon to je definisana njihova veliina.Nekada se prioriteti menjaju tako to se korisnike prie kojekrae traju pomeraju na poetak ciklusa, dok se obimnijekorisnike prie odlau za kasnije, mada se uvek mora voditirauna o logikom sledu korisnikih pria, kao i prioriteturealizacije na osnovu informacija od korisnika.

5. Organizovati sastanak tima sa sledeim zadacima:

Definisati duinu iteracije:

U Scrum metodologiji iteracija se naziva sprintom. Sprinttreba da traje izmeu jedne i etiri nedelje.

Definisati pojedinane zadatke u okviru svakekorisnike prie:

Zadaci ne moraju biti korisniki orijentisani i moguobuhvatati faze u razvoju softvera: dizajn, razvoj, unittestiranje, UAT (User Acceptance Testing).

Procene trajanja zadataka u satima:

7/25/2019 RSS-6-5.pdf

3/5

- 816 -

Za svaki zadatak se relevantni zaposleni za njegovurealizaciju dogovaraju u vezi duine trajanja i donose procenu.Na odluku mogu uticati i ostali lanovi tima kroz preciznorazjanjavanje zaduenja. Vano je naglasiti da se ne definiekoji resurs e obavljati odreeni zadatak. Tim mora dafunkcionie kao celina i da se organizuje u pravcu realizacijezadatka bez isticanja pojedinaca.

Izbor korisnikih pria, koje e ui usprint:

Na osnovu trajanja zadataka, pa samim tim i trajanjaimplementacije svake zaokruene celine, odabrati korisnikeprie, koji e ui usprint. Preporuljivo je pripremiti i dodatneprie, koji bi se potencijalno mogle odraditi ukoliko bi sprintbio okonan pre roka, ali se ne obavezivati na njihovurealizaciju Product Owner-u. Ovim se sastanak sa timomzavrava.

6. Odabrati softver za sprovoenje agilne metodologije:

Mogu se koristiti razliiti alati, kao to su ScrumWorks,iceScrum, JIRA uz korienje dodatka GreenHopper. Vri sekreiranje sprintai korisnikih pria u njemu. Svaka korisnikapria sadri zadatke, koji se mogu rasporeivati resursima.Zadaci su grupisani u kategorije Uraditi, U toku, Zavreno.Zavisno od upotrebljenog softvera, mogu se dodati i novekategorije kao to su Product Backlog, koji sadri korisnikeprie za implementaciju, iliZastoji, koji obuhvata zadatke kojikasne sa realizacijom. Svi lanovi tima se u razliitimsvojstvima mogu prijavljivati u aplikaciju i prikazivatirealizaciju svojih zadataka kroz njihovo prevlaenje iz jednekategorije u drugu. Na ovaj nainsprintzapoinje.

7. Pratiti realizaciju projekta:

Sa poetkom sprinta zapoinje se realizacija projekta.Zadatak Scrum Master-a je da prati realizaciju projekta krozdnevne i nedeljne sastanke sa timom, uoava zastoje u

realizaciji i radi na njihovom prevazilaenju.

8. Zakljuiti sprint uenje zasnovano na prethodnomiskustvu:

Na kraju iteracije sabiraju se poeni dodeljeni svakojkorisnikoj prii i na taj nain se utvruje obimsprintaizraenu poenima. Pored toga, zadatak Scrum Master-aje da sa timomutvrdi ta je oteavalo sprint, ta se moe uiniti da se sledeisprintpopravi i odluiti ta e tim uraditi drugaije u narednomsprintu.

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 kaoProduct Owneri Scrum Master. Pomenute osobe moraju dobropoznavati razvojni tim (naroito se odnosi na Scrum Master-a)i potrebe aplikacije koja se izrauje (naroito se odnosi naProduct Owner-a). Obzirom na to da ovaj posao esto obavljaista osoba, vano je ouvati ideju o razvoju softvera kojiisporuuje traene karakteristike softvera korisniku i ne baziratise na pojedinane aktivnosti razvojnog tima, tj. ne prevariti se i

ne skliznuti u tradicionalni menadment projektom gubei izvida potrebe korisnika.

Nakon definisanja krucijalnih uloga lanova tima, pristupase definisanju prioriteta uProduct Backlog-u.

Poetna funkcionalnost, koju bi aplikacija trebalo da ponudikorisnicima je mogunost kreiranja novog zaposlenog, preglednjegovih podataka, izmena podataka i brisanje zaposlenog.

Pomenute karakteristike aplikacije se mogu objediniti upoetnom sprintu, gde e svaka pomenuta karakteristikaaplikacije predstavljati posebnu opciju (feature).

Pomenute karakteristike se mogu modelovati prekosledeih korisnikih pria:

Kao administrator, elim da dodam novog zaposlenogaplikaciji.

Kao administrator, elim da vidim podatke okreiranom zaposlenom u aplikaciji.

Kao administrator, elim da menjam podatke ozaposlenom.

Kao administrator, elim mogunost da uklonimzaposlenog iz aplikacije.

Pored navedenih korisnikih pria, poeljno je definisati idodatne, koje e biti smetene u Product Backlog. One semogu planirati za naredne iteracije i koristiti za planiranjerelease-a aplikacije. Takoe mogu posluiti kao rezervaukoliko sesprinteventualno zavri ranije.

Za svaku korisniku priu se definie obim u poenima.Prilikom definisanja veliine zadataka, kao najbolji pristuppokazuje se izdvajanje najmanje korisnike prie kojoj e sedodeliti 1 poen. Razvojnom timu e dalje biti lake da definiepoene za ostale korisnike prie, jer e imati inicijalnu priu sa

kojom e moi da porede svaku narednu. Za navedenuaplikaciju, utvreni poeni prvog sprinta su sledei: 5, 1, 3, 3.Nije vrena dodatna revizija prioriteta, jer su dobijeni poeni bilioekivani od strane menadera projekta.

Dobijene korisnike prie se dalje segmentiu napojedinane zadatke i unosi se vreme predvieno za realizacijusvakog zadatka.

Deljenje korisnikih pria na zadatke moe se vritirazdvajanjem na aktivnosti u razvojnom procesu. Na primer, zapoetnu 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 uidealnim satima, odnosno efektivnom broju sati koje bi lantima potroio na njegovo odraivanje. Za navedene zadatke,utvrena vremena trajanja su po 10 asova za svaki zadatak.

Potrebno je voditi rauna o meuzavisnosti zadataka tokomdefinisanja trajanja korisnike prie. Serverska strana ikorisniki interfejs se obino mogu razvijati paralelno s tim tose izvesno vreme potroi na njihovu integraciju. Testiranje

7/25/2019 RSS-6-5.pdf

4/5

- 817 -

implementirane funkcionalnosti obino u potpunosti zavisi odprethodnih zadataka. Samim tim, trajanja svih zadataka se nemogu jednostavno sabrati, jer bi to impliciralo meusobnuuslovljenost svih zadataka, koja ne mora nuno da postoji.Prilikom definisanja trajanja korisnike prie preporuujemoda se za zadatke, koji se izvravaju paralelno, kao njihovovreme trajanja usvoji vreme potrebno za realizaciju duegzadatka i da mu se doda vreme potrebno za testiranje. U naem

primeru, obzirom da i razvoj na serverskoj strani i korisnikominterfejsu traju paralelno po 10 asova, usvojiemo 10 asovakao trajanje ovih zadataka. Ovom vremenu emo dodati vremepotrebno za testiranje funkcionalnsoti. Dolazi se do zakljukada posmatrana korisnika pria ima predvieno trajanje od 20asova.

Obzirom da je agilni pristup test-driven[4], potrebno je daprocene obuhvate i vreme potrebno za unit testiranje, kao i zaacceptancetestiranje.

Slian postupak se sprovodi i za ostale korisnike prie.

Nakon to se definie vreme trajanjasprinta(1 4 nedelje),potrebno je ukljuiti odreeni broj korisnikih pria usprintna

osnovu njihovog predvienog trajanja. Preostale korisnikeprie ostaju uProduct Backlog-u.

Prilikom definisanja korisnikih pria, koje e ui u sprint,definisano je i trajanje samog sprinta u Story Point-ima iidealnim satima. Na osnovu ovih podataka se mogu gruboplanirati narednisprintovii konani release aplikacije. Nakonsvakogsprinta, ovakve okvirne planove je potrebno revidirati idopuniti. Samim tim e i release plan biti sve konkretniji sasvakim realizovanimsprintom.

Za automatizaciju agilnog upravljanja projektom korienje ScrumWorkssoftver.

Instaliran je ScrumWorks Pro Server 5.1.0, koji integrie

desktop aplikaciju ScrumWorks Pro Desktop Client ijednostavniji ScrumWorks Pro Web Client [5] (Sl. 1).Podacima smetenim na serveru se moe pristupati kroz obeaplikacije.

Slika 1. Primer praenja sprinta u ScrumWorks aplikaciji

Desktop aplikacija se koristi za konfiguraciju projekta krozkreiranje projekta, release-ova, sprintova, timova, korisnika imodelovanje njihovih uloga. Pored toga, moe se koristiti i zakreiranje korisnikih pria i zadataka unutar njih. Web

aplikacija je znatno jednostavnija i omoguava samomanipulaciju korisnikim priama i zadacima, pa e zato bitikoriena u svakodnevnom radu lanova tima.

Sve korisnike prie su smetene u sekciji Backlog Items.Njihov prioritet se moe menjati jednostavnim prevlaenjemiznad ili ispod prethodnika, odnosno sledbenika.

Zadaci koji pripadaju priama se nalaze u Not Started

sekciji. Svaki zaposleni moe poeti rad na zadatku tako to ega jednostavno prevui (drag-and-drop) u sekcijuIn Progressili manuelno promeniti njegov status. Kada se zadatak okona,moe se premestiti u sekcijuDone.

Pored toga, postoji i sekcija Impeded za zadatke satekoama u realizaciji. Jedan od zadataka Scrum Master-a jeda uoi potekoe na vreme i da pokua da ih otkloni.

Kroz ovaj softver, Scrum Master ima centralizovan pristupinformacijama vezanim zasprintkoji se sprovodi, moe pratitinjihov progres, na vreme lokalizovati potekoe, planiratitrajanje release-ai blagovremeno aurirati podatke.

Nakon zavretka sprinta, proizvod se moe dostaviti

krajnjem korisniku u viduPreview Build-a. Dobijene povratneinformacije se mogu koristiti za izmenu ili dopunu vepostojeih zahteva po pitanju novih karakteristika aplikacije,pri emu e se znaajno poveati ansa da korisnik dobijeproizvod koji u potpunosti zadovoljava njegove zahteve.Zadovoljstvo korisnika otvara mogunost za nove projekte sanjim ili njegovim partnerima, kojima bi mogao prenetipozitivna iskustva iz saradnje sa razvojnim timom.

ZAKLJUAK

U ovom radu analizirali smo osnovne faze u upravljanjuprojektima, definisali potencijalne potekoe u realizacijiprojekta i preporuili agilnu metodologiju kao pristup koji ima

najbolji efekat na blagovremenu realizaciju ciljeva projekta.Pored toga, pozitivno utie na razvojni tim na sledeimpoljima:

podstie timski duh,

smanjuje pritisak na pojedinca,

motivie tim za narednesprintove.

Osim povoljnog uticaja na razvojni tim, potvrdili smo da sena ovaj nain doprinosi razvoju softvera, koji integriekorisnike povratne informacije i samim tim u velikoj merizadovoljava korisnike zahteve, a to je svakako jedan odciljeva 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 forProjects, John Wiley & Sons, 2003

[4] K. Schwaber, Agile Project Management with Scrum, Microsoft Press,2004

7/25/2019 RSS-6-5.pdf

5/5

- 818 -

[5] http://danube.com/docs/scrumworks/pro/latest/userguide.html,Copyright 2011 CollabNet, Inc. All rights reserved.

ABSTRACT

Recent achievements in the field ofinformation technology cause increase of the number ofprojects in the field of software engineering. Having in mindthe characteristics of such projects, in relation to

other engineering disciplines, there is a necessity forcustomized software project management methodology.Through this paper we propose an agile approach to project

management with Scrum methodology as the mostoptimal way of achieving the primary objectives of project.Primary objectives of project are making the software, whichfully meets the user requirements, ensures delivery on time andin an environment that makes agile developmentteam motivated for new challenges.

AGILE APPROACH TO SOFTWARE PROJECTMANAGEMENT

Milica Neskovic, Mladen Rakovic