UNIVERZITET ZA POSLOVNE STUDIJEBANJA LUKA

Agilni model razvoja software-a, SCRUMPredmet: Sotversko inenjerstvoSEMINARSKI RAD

Mentor:student:doc. dr Mihajlo TravarDanilo Milidrag(V223/12)

Banja Luka,Januar 2015Sadraj

1.Uvod31.1.Istraivanje31.2.Svrha i ciljevi istraivanja42.Razvoj metodologija53.Agilne metode razvoja softvera63.1.Primjeri agilnih metoda razvoja softvera:93.1.1.Ekstremno programiranje93.1.2.Kristalna porodica metodologija104.Scrum metodfologija114.1.Karakteristike124.1.1.Scrum tim124.1.2.Dogaaji u Scrumu134.1.3.Sprint134.1.4.Artefakti (lista zahtjeva i dokumenti) u Scrumu134.1.5.Kontrola i prilagoavanje154.2.Faze metodologije164.3.Uloge i odgovornosti164.4.Praksa i koritenje184.5.Prednosti i nedostaci204.5.1.Prednosti Scrum metodologije:204.5.2.Nedostaci Scrum metodologije:205.Zakljuak21Literatura22

1. Uvodmid (2011) istie da je Scrum kakav danas poznajemo zapravo kreiran daleko od oiju javnosti jo 1993. godine, a Baeli (2013) nadodaje da je kreiran od strane Kena Schwabera i Jeffa Sutherlanda i njegovi zaeci mogu se nai u Japanu sredinom 70-ih godina u japanskoj kompaniji Fuji Xerox. Tamo su prilikom razvoja novog fotokopirnog ureaja klasini, sekvencijalni vodopadni (eng. waterfall) model, u kojem idua faza razvoja zapoinje tek zavrekom prethodne, modificirali tako da se faze preklapaju. S obzirom na to da su autori Japanci, tako izveden vodopadni model poslije je nazvan sashimi model, prema japanskom jelu sashimi (svjei morski plodovi narezani na tanke listie). Preklapanje faza dovelo je do potrebe za poveanom komunikacijom i interakcijom izmeu uesnika projekta, a projektne su timove inili ljudi iz razliitih struka (istraivaki inenjeri, prodaja, razvojni inenjeri, testeri...), to je jedna od osobina koja odlikuje timove na projektima voenim agilnim metodologijama. Korist je bila viestruka: od kraeg trajanja projekta, vee fleksibilnosti prema promjenama, promovisanja odgovornosti i saradnje, bolje razmjene kljunih informacija meu lanovima tima koji imaju razliite zadae do, u konanici, kvalitetnijeg proizvoda. Topi (2012) objanjava da termin Scrum potie iz ragbija (eng. rugby), a oznaava vraanje u igru lopte (uz pomo timskog rada osam igraa poredanih u tri reda) koja je iz iste izala.1.1. IstraivanjeU dananjem svijetu razvoja informatike, softver je jedno od najvanijih dostignua stvaralatva. Razvoj softvera je proces koji traje od formiranja ideje do realizacije te ideje i izrade konanog softvera. Ideja ima mnogo, od onih koje mogu pomoi u rjeavanju raznih problema s kojima se ljudi susreu, pa do raunarskih igara namijenjenih istoj zabavi.Softver je svakim danom sve sloeniji zbog neprestanog razvoja sistema koji ga koriste. Kao posljedica te sloenosti raste i broj razvojnih timova koji unutar softverskih kua rade na razvoju softvera. Najvee problematike dananjice javljaju se zbog sve veih zahtjeva trita, potreba korisnika te isporuke softvera na vrijeme. Cilj razvoja softvera je proizvodnja kvalitetnog softvera, u zadanom vremenu, unutar predvienog budeta i uz zadovoljavanje potreba naruitelja.Pojam procesa esto se odnosi na standarniziranu i dokumentiranu metodologiju koja je ve prije koritena na slinim projektima razvoja softvera ili se ve koristi unutar neke organizacije. Iako postoji mnogo definicija metodologija, na kraju se one svode na isto.Metodologija razvoja softvera je postupak, odnosno kodifikovan skup preporuenih praksi koje pokazuju kako organizacija odabire sistem ljudi i potrebnih resursa kako bi kreirala i odravala softverski proizvod.Metodologija premouje mnoge discipline, ukljuujui upravljanje projektom, analizu, specifikaciju, dizajn, kodiranje, testiranje te osiguravanje kvalitete.Tokom godina napredovanja tehnologije i samog razvoja softvera, mnoge su se metodologije koristile, zastarijevale i javljale se nove. U najveem broju opstale su samo one koje su se pokazale dovoljno kvalitetnima i prilagodljivima da odgovore na sve zahtjevnije potrebe trita.Agilne metodologije u razvoju programskog proizvoda javljaju se kao odgovor na opsene (tradicionalne) metodologije. Pobornici agilnih metoda razvoja programskog proizvoda 2001. godine donose Agilni manifest (Agile Software Development Manifesto) pokuavajui naglasiti ulogu koju fleksibilnost moe odigrati u spretnijem i brem razvoju programskog proizvoda.Prema Manifestu je uspostavljen novi sistem vrijednosti: Osobe i interakcije umjesto procesa i alata Programski proizvod koji radi umjesto opirne dokumentacije Zajedniki rad i saradnja s kupcem umjesto pregovaranja preko ugovora Reagovanje na promjene umjesto striktnog pridravanja plana Metodologije razvoja programskog proizvoda temeljenog na agilnim principima koje su originalno ukljuene u Agile Alliance su: eXtreme Programming XP Scrum Feature Driven Development FDD Crystal family of methodologies Dynamic Systems Development Method DSDM Adaptive Software Development ASD 1.2. Svrha i ciljevi istraivanjaSvrha i cilj istraivanja je teorijski i empirijski istraiti, analizirati i uporediti faze provedbe Srum metodologije.Pokazae se kako se formiraju faze svake od metodologija te prednosti i nedostaci izmeu njih.Uvidom u svaku fazu razvoja metodologija doi emo do saznanja zbog ega se u dananje vrijeme sve ee koristi Scrum metodologija, tj. koje su razlike koje su dovele do potrebe za razvojem metodologija i uvoenjem agilnih metodologija.Takoer z na primjeru preduzea pokazati na koji nain se primjenjuje izabrana metodologija, naini kako timovi funkcioniu te poboljanja u poslovanju do koje je dolo uvoenjem agilnih metodologija.Oekivani doprinos ovog rada je iznijeti i interpretirati temeljne dosadanje spoznaje o razvoju metodologija. Takoe u detaljnije obraditi Scrum metodologiju. Prikazau nain na koji timovi rade prilikom upravljanja projekata.2. Razvoj metodologijaMetodologija je, prema PMI definiciji, sistem praksi, tehnika, procedura i pravila koje rabi onaj ko radi na podruju odreene discipline, gdje je procedura niz koraka koji se da bi se neto postignulo, odvijaju po redosljedu. Metodologijom se smatraju uloge, ekipe, vjetine, procesi, tehnike, alati i standardi koje rabi projektni tim. Ukoliko to primjenjuje jedna ili dvije osobe, onda se moe nazvati metodom, a ukoliko to primjenjuje cijela ekipa, moe se nazvati metodologijom. Razliiti pristupi u razvoju softvera doveli su razvoja razliitih metodologija. Metodologije koje su svojim pristupom pokazale dovoljno kvalitetnima i prilagodljivima opstale su i danas.Metodologije koje se koriste mogu se podijeliti unutar tradicionalnih grupa, procesno orijentiranih i metoda pristupa u razvoju softvera te agilnih grupa metoda koje su usredotoene na manje jedinice posla i s naglaskom na vrijednosti i principima umjesto na procesima. Svaku od metodologija nije mogue koristiti na svakom projektu. Unutar projekta ponekad se kombinira i nekoliko metodologija. Cilj razvoja softvera je proizvodnja kvalitetnog softvera, u zadanom vremenu, unutar predvienog budeta i uz zadovoljavanje stvarnih potreba naruitelja. Uspjeh projekta ovisi o dobrom upravljanju zahtjevima.Dvije glavne grupe metodologije razvoja softvera su:1. Teke i opsene metodologije (engl. heavyweight methodologies) razvoja softvera koje sadre mnogo pravila, naina postepena i dokumentacije. Trae vrijeme i disciplinu za ispravno slijeenje 2. Lake i manje opsene metodologije razvoja softvera (engl. lightweight methodologies) sadre tek nekoliko pravila i naina postepena koji su lagani za slijeenje. Metodologija odabire metode, prilagoava ih konanom cilju, propisuje redoslijed upotrebe metoda, propisuje proces modeliranja od poetka do kraja ivotnog ciklusa softvera. Cijeli pristup razvoju softvera podrazumijeva upotrebu metodologije koja u sebi sadri metode primjenjive u pojedinim fazama razvoja softvera, tako da je svaka faza pokrivena s jednom ili vie metoda.Karakteristike dobre metodologije su: Preporuen stepen detalja, koritenje predloaka, standardizovane tehnike planiranja, vremenskoga odreivanja i kontrole trokova, standardizovani oblik izvjetavanja, fleksibilnost za primjenu na svim projektima, fleksibilnost za bri razvoj, razumljivost korisniku, prihvaenost i uporabljivost u organizaciji, koritenje standardizovanih faza ivotnoga ciklusa te temeljenost na smjernicama i na etici dobro obavljenoga posla. 3. Agilne metode razvoja softveraModerna definicija agilnog razvoja softvera potie iz sredine 1990-tih godina kao negativna reakcija na teke metode, prije svega zbog vrsto reguliranih i raspostranjenih vodopadnih modela razvoja. Agilne metodologije u razvoju softvera javljaju se kao odgovor na opsene (tradicionalne) metodologije koje su nastale od 1970-ih do 1990-ih. One su pokuale nametnuti nekakav oblik discipline vezane za nain na koji se softver osmiljava, dokumentira, razvija i testira. Procesi koji su nastali upotrebom zastarjelih metoda smatrani su sporima, zahtjevnima i kontradiktornima onome kako se programiranje zaista odvija u praksi.U samim poecima agilne metode nazvane su laganima. 2001. godine istaknuti svjetski inenjeri sastali su se u mjestu Snowbird u dravi Utah, SAD, gdje su usvojili naziv Agilne metode pokuavajui naglasiti ulogu koju fleksibilnost moe odigrati u spretnijem i brem razvoju softvera. Oni su definirali 12 principa agilnog manifesta na kojem se temelje agilne metode.12 principa Agilnog manifesta su:1. zadovoljstvo klijenta kroz brze isporuke korisnog softvera, 2. prihvatanje promjena u zahtjevima ak i u kasnijim fazama razvoja kako bi se to vie poboljala pozicija klijenta, 3. funkcionalni softver isporuuje se uestalo, svakih nekoliko sedmicaa ili mjeseci (to krae, to bolje), 4. funkcionalni softver osnovna je mjera napretka projekta, 5. odrivi razvoj, koji moe odrati konstantnu brzinu tokom cijelog projekta, 6. bliska saradnja izmeu poslovnih ljudi i programera na dnevnoj razini, 7. direktna komunikacija najbolji je oblik komunikacije, 8. projekti su izgraeni oko motiviranih pojedinaca kojima se treba iskazati povjerenje, 9. konstantan fokus na tehniku izvrsnost i dobar dizajn koji poveavaju agilnost projekta, 10. jednostavnost, 11. samoorganizujui timovi u stanju su isporuiti najbolje arhitekture, zahtjeve i dizajn, 12. periodiko preispitivanje unutar tima te prilagoavanje promjenama u okolini.

Agilni manifest je dokument koji opisuje temeljne postavke buduih agilnih metoda. Manifest moemo ukrako saeti na etiri temeljne poruke:1. Individualci i interakcija ispred procesa i alata 2. Softver koji radi ispred iscrpne dokumentacije3. Saradnja s klijentom ispred pregovora o ugovoru4. Reagovanje na promjenu ispred praenja planaU agilnom manifestu definisano je da je softver razvijen tokom jedne jedinice vremena predstavlja iteraciju koja traje od jednog do etiri sedmice te se na kraju svakog ciklusa vri ocjena projektnih prioriteta. Svaka iteracija je kompletan softverski projekt, ukljuujui zahtjeve, dizajn, kodiranje, testiranje i dokumentaciju. Nakon svake iteracije tim radi re-evaluaciju projekta.U agilnim metodama istie se vrednovanje pojedinaca i interakcija sa procesima i alatima, to podrazumijeva da je projektnom timu potrebno osigurati neophodne resurse i imati povjerenje u to da e oni svoje poslove uraditi kvalitetno. Timovi se samoorganizuju i komuniciraju bez posredstva dokumentacije. Vie vremena se troi za izradu softvera. Ova metoda sadre manje dokumentacije nego druge metode, to je meta kritiara zbog nedostatka discipline. Glavni cilj agilnih metoda je zadovoljavanje korisnika. Uvoenjem fleksibilnosti u proces razvoja agilne metode pruaju mogunost korisnicima da mijenjaju zahtjeve obzirom da je trite jako promjenjivo te da se zahtjevi trita brzo mijenjaju. Obiljeja koja razvojnu metodu ini agilnom su kada je razvoj softvera inkrementalan (malene isporuke sa brzim ciklusima), kooperativan (naruitelj i razvojni tim rade zajedno u bliskoj komunikaciji), izravan (metoda je jednostavna za uenje i modificiranje te dostatno dokumentirana) te prilagodljiv (u mogunosti da se promjene izvre i u posljednjem trenutku).Istorija agilnih metodologija je duga. Neka se od osnovnih naela agilnih metodologija, poput iterativnog i inkrementalnog naela te naela prilagodljivosti, u kontekstu razvoja softvera spominju od 50-ih godina prolog vijeka. Mnoge metode koje su danas poznate kao agilne nastale su prije Agilnog manifesta. Jedna od prvih objavljena je poekom 1995. i danas slabo zastupljena metoda DSDM (Dynamic Systems Development Method). Nedugo nakon toga iste je godine svjetlo dana slubeno ugledao i Scrum, danas najpopularnija agilna metodologija u razvoju softvera. Nastanak ranih agilnih metoda vezan je za period prije 2000. godine jer je sama metoda razvoja softvera Scrum nastala 1986. godine. 1995. godine nastao je adaptivni razvoj softvera, razvoj voen karakteristikama te metode dinaminog razvoja softvera.Crystal clear i ekstremno programiranje nastaju godinu dana kasnije, a 2004. godine uvodi se industrijsko ekstremno programiranje.Softverske kompanije koje koriste agilne metode imaju mogunost poveati inovativnost i brzinu te kreiraju promjene kod konkurenata. Sporije i manje inovativne kompanije doivljavaju kaos koji su drugi pokrenuli. Sposobnosti kompanija da dre korak i kreiraju promjene lei u sposobnosti razvoja softvera. U svijetu neprestanih promjena, tradicionalne rigorozne metode razvoja softvera su nedovoljne za uspjeh.Najpoznatije metode agilnog softverskog razvoja danas su: Ekstremno programiranje (XP) Industrijsko ekstremno programiranje (IXP) Scrum Agilno modeliranje Adaptivni razvoj softvera (ASD) Crystal clear i ostale Crystal metode Metoda dinaminog razvoja sistema (DSDM) Razvoj voen karakteristikama (FDD) Suvi razvoj (Lean development)

Slika 1: Najee koritene agilne metodologijeNa Slici 1. nalazi se prikaz najee koritenih agilnih metodologija, a mi emo u nastavku objasniti nekoliko metoda agilnog softverskog razvoja, dok emo Scrum metodologiju poblie upoznati u nastavku rada.3.1. Primjeri agilnih metoda razvoja softvera:3.1.1. Ekstremno programiranjeEkstremno programiranje je softverska inenjerska metodologija koja je najpoznatija od nekoliko brzih razvojnih softverskih metodologija. Metodologija omoguuje prilagoavanje promjenama zahtjeva u bilo kojem trenutku u procesu razvoja projekta to je ini realistinijom i pristupanijom nego metoda koja definira sve zahtjeve na poetku projekta, ime se smanjuju trokovi realizacije. Propisuje se day-to-day praksa za menadere i razvojne programere te se utjelovljuje i potie softver vie razine koji nastaje u interakciji klijenta i razvojnog tima, to dovodi do bolje kvalitete usluge jer se u potpunosti ostvaruje bolje razumijevanje s klijentom. Prednost ekstremnog programiranja je u kratkim iteracijama, komunikaciji u timovima, davanju odgovornosti i moi lanovima tima.. Najuspjeniji dio XP je onaj koji je usmjeren tehnikom dijelu, a ne upravljanju projektima. etiri osnovne vrijednosti od kojih se kree u XP su : jednostavnost, komunikacija, povratna informacija i hrabrost.Ekstremno programiranje je usmjereno da se ostvari: Pokuaj da uskladi ljudski faktor i produktivnost, mehanizam za socijalne promjene, put prema poboljanju, stil razvoja, softversku razvojnu disciplinu. Dizajn s korisnikim iskustvom je integriran u razvoj softvera i ostale oblike razvoja aplikacija tako da se postigne interakcija s korisnikom, sukladno s korisnikovim ciljevima.Dizajn se odnosi na kreiranje arhitekture i modela interakcije, koji imaju utjecaj na korisniku percepciju ureaja ili sistema. Korisniko iskustvo je izraz koji se koristi za opisivanje svih iskustava i zadovoljstava korisnika kada koriste neki proizvod ili sistem.Glavne dobiti ove metode su: Smanjenje nepotrebnih opcija koje nisu potrebne korisniku, unapreenje ope iskoristivosti sistema realizacija dizajna i razvoj projekta kroz detaljne i pravilno definisane smjernice. Raspoloivost korisnika: lanovima tima treba omoguiti saradnju s korisnicima tokom cijelog projekta Automatski testovi i integracija: definisani su razliiti oblici verifikacije funkcionalnosti projektaU porodicai Crystal metodologija inkrementalni ciklus ne smije biti dui od 4 mjeseca, a radionice se moraju odrati nakon svake isporuke proizvoda tako da metodologija bude samo prilagodljiva te da se nakon pogleda unatrag ui iz vlastitih greaka. U ovoj metodologiji projekt e biti uspjean ukoliko ljudi sjede zajedno te esto komuniciraju, te ako je eliminirana birokracija te smanjena papirologija, a korisnik je direktno ukljuen u projekt te su napisani dobri testovi.3.1.2. Kristalna porodica metodologijaCrystal metodologije naglaavaju vanost ljudi u razvoju programskog proizvoda. Crystal se usredotouje na ljude, interakciju, zajednitvo, vjetine, talent i komunikaciju kao najvaniji utjecaj na performanse. Proces ostaje vaan, ali sekundaran. Pored metodologija, Crystal pristup ukljuuje principe za prilagoavanje da bi se zadovoljile razliite okolnosti u projketima. Svaki lan Crystal porodicai oznaen je bojom koja predstavlja teinu metodologije, npr. tamnija boja znai teu metodologiju. Crystal predlae biranje odgovarajuih boja ovisno o rangu vanosti projekta. Razliitim metodama su dodijeljene boje rasporeene prema opadajuoj prozirnosti te je stoga najagilnija metodologija Kristalno ista (eng. Crystal Clear), zatim Kristalno uta (eng. Crystal Yellow), Kristalno naranasta (eng. Crystal Orange) i Kristalno crvena (eng. Crystal Red). Vei projekti zahtijevaju vie kordinacije i tee metode u odnosu na manje projekte.Definisano je sedam kljunih principa Crystal metodologije: Uestala isporuka: vri se svakih nekoliko mjeseci, a korisnici su upoznati s meuverzijama te daju povratne informacije Kontinuirane povratne informacije projektni ti raspravlja o projektnim aktivnostima i o moguim problemima, a validacija projekta se odvija s korisnicima Stalna komunikacija: mali timovi su smjeteni u jednoj prostoriji dok su vei timovi lokacijski povezani Sigurnost: lanovi tima komuniciraju i rade bez represije jer svi projekti nisu kritino isti Fokus: lanove tima je potrebno upoznati s prioritetnim ciljevima te im dati mogunost da ih ostvare Raspoloivost korisnika: lanovima tima treba omoguiti saradnju s korisnicima tokom cijelog projekta Automatski testovi i integracija: definisani su razliiti oblici verifikacije funkcionalnosti projektaU porodicai Crystal metodologija inkrementalni ciklus ne smije biti dui od 4 mjeseca, a radionice se moraju odrati nakon svake isporuke proizvoda tako da metodologija bude samo prilagodljiva te da se nakon pogleda unatrag ui iz vlastitih greaka. U ovoj metodologiji projekt e biti uspjean ukoliko ljudi sjede zajedno te esto komuniciraju, te ako je eliminirana birokracija te smanjena papirologija, a korisnik je direktno ukljuen u projekt te su napisani dobri testovi.4. Scrum metodfologijaScrum je najpopularnija agilna metodologija u razvoju softvera. Scrum kakav danas poznajemo zapravo je kreiran jo 1993. (Ken Schwaber i Jeff Sutherland), a njegovi zaeci mogu se nai u Japanu sredinom 70-ih godina u japanskoj kompaniji Fuji Xerox. Tamo su prilikom razvoja novog fotokopirnog ureaja klasini, sekvencijalni vodopadni (waterfallski) model, u kojem idua faza razvoja poinje tek zavrekom prethodne, modifikovali tako da se faze preklapaju. Obzirom da su autori Japanci, tako izveden Vodopadni (waterfallski) model poslije je nazvan Sashimi model, prema japanskom jelu sashimi (svjei morski plodovi narezani na tanke listie). Preklapanje faza dovelo je do potrebe za poveanom komunikacijom i interakcijom izmeu uesnika projekta, a projektne su timove inili ljudi iz razliitih struka (istraivaki inenjeri, prodaja, razvojni inenjeri, testeri...), to je jedna od osobina koja odlikuje timove na projektima voenima agilnim metodologijama. Korist je bila viestruka: od kraeg trajanja projekta, vee fleksibilnosti prema promjenama, promovisanja odgovornosti i saradnje, bolje razmjene kljunih informacija meu lanovima tima koji imaju razliite zadae do, u konanici, kvalitetnijeg proizvoda. Do sredine 80-ih Sashimi model postao je dominantan u Fuji Xerox korporaciji, ali i ire u Japanu. Kako je u to vrijeme Japan bio na svom vrhuncu, a inilo se kao da su njihove brojne korporacije nezaustavljive u pokoravanju ostatka svijeta, raene su brojne analize koje su pokuale otkriti odakle dolazi ta snaga. Jedna od najbitnijih uoenih znaajki bio je upravo sashimi pristup. Kao dalja evolucija Sashimi modela kod kojega postoji preklapanje samo izmeu susjednih faza, nastao je i model u kojem se preklapa vie faza istovremeno, a lanovi tima, koji uestvuju na projektu u razliitim fazama, zajednikim snagama dolaze do cilja. Takav je model bio dominantan u drugim japanskim kompanijama, poput Honde i Canona, a nazvan je ragbijskim pristupom. Time podrijetlo naziva Scrum metodologije, a i korijeni njene evolucije postaju oiti svim oboavateljima dotinog sporta (za nas ostale, Scrum je u ragbiju naziv za isprepletenu gomilu igraa kojom se zapoinje akcija, tj. oznaava momenat kada se protivniki timovi skupljaju na gomilu i bore za posjed lopte). Kao zanimljivost, spomenimo da Scrum metodologija ima jo jednu poveznicu sa svojim japanskim korijenima sashimije u Scrumu naziv za izvjetaj kojim se oznaava da je neka aktivnost (npr. dio koda) dovrena.Scrum esto zovemo metodologijom, ali ako elimo biti posve precizni, Scrum to nije. Scrum je okvir (framework) metodologije razvojnog procesa koji se koristi za upravljanje kompleksnim razvojem i za razliku od nekih drugih agilnih metodologija kao to su XP ili Crystal. Scrum ne definira detalje procesa, ve daje okvir unutar kojega tim stvara proces prilagoen sebi, odnosno proces ija je karakteristika konstantno usavravanje i prilagoavanje timu koji ga provodi.Scrum je utemeljen na teoriji empirijske kontrole procesa, odnosno, tvrdnjama da znanje dolazi iz iskustva i odluivanja temeljenih na poznatom. Scrum koristi iterativni i inkrementalni pristup radi optimizacije predvidivosti i kontrole rizika. Inkrementalni razvoj predstavlja razvoj softvera korak po korak, dok iterativni nain predstavlja strategiju vremenskog planiranja u kojem se softver kroz svaki definisani period vremena dodatno usavruje.Empirijska kontrola procesa temeljena je transparentnosti, kontroli i prilagodbi. Transparentnost se temelji na tome da kljuni aspekti moraju biti vidljivi onima koji su odgovorni za krajnji proizvod. Korisnici Scrum metodologije esto moraju kontrolirati artefakte (liste zadataka projekta i liste zadataka perioda implementacije) i napredak prema cilju radi uoavanja neeljenih odstepena, na emu se temelji kontrola, dok se prilagoavanje odnosi korekciju proizvoda ukoliko je to nuno radi minimiziranja odstepena.Scrum je jednostavan, lako razumljiv i vrst razvojni proces te je usredotoen na bitne funkcionalnosti koje je razvojni tim sam procijenio da moe implementirati. Komunikacijom na svakodnevnim stojeim sastancima rjeavaju se tekui problemi i daju obeanja to e se napraviti do idueg sastanka ime se stvara povjerenje izmeu lanova tima (poslovni analitiari, programeri, testeri...).. Rezultat su zadovoljni lanovi tima to za posljedicu ima kvalitetniji i bri razvoj, a samim time su zadovoljni naruitelji i korisnici programskog proizvoda.4.1. KarakteristikeScrum framework se sastoji od Scrum timova, njihovih pridruenih uloga, dogaaja, artefakata i pravila.

Slika 2: Scrum framework4.1.1. Scrum tim Scrum tim sastoji se od vlasnika proizvoda (engl. Product Owner), razvojnog tima (engl.Development team) i Scrum mastera. Scrum isporuuje proizvode iterativno i inkrementalno, maksimirajui mogue povratne informacije.4.1.2. Dogaaji u Scrumu Scrum koristi propisane dogaaje radi uspostave pravilnosti i minimizacije potrebne na sastancima koji nisu definisani Scrumom. Scrum koristi vremenski ograniene dogaaje na nain da svaki vremenski dogaaj ima odreeno maksimalno trajanje. Na taj nain se osigurava da se dovoljno vremena koristi za planiranje bez uzaludnog troenja vremena.4.1.3. Sprint Osnovna vremenska cjelina Scruma jest sprint. Sprint je zaokruena jedinica razvojnog procesa koja najee traje 30 kalendarskih dana tokom kojega se proizvede zavren, upotrebljiv i potencijalno isporuiv inkrement proizvoda. Inkrement je zbroj svih stavaka s liste zadataka projekta (engl. Product backlog) zavrenih tokom perioda implementacije i svih prethodnih perioda implementacije. Za to vrijeme se svakodnevno prati napredak i identificira sporna i rizina mjesta napredovanja. Sprintovi su jednakog trajanja tokom cijelog razvoja proizvoda. Novi Sprint zapoinje neposredno nakon to zavri prethodni.Sprint se sastoji od sastanka za planiranje Sprinta, dnevnog Scruma, posla razvoja, revizije Sprinta i retrospektive Sprinta. Poput projekata Sprint se koristi da se obavi neki posao. SvakiSprint ima definiciju to e se obaviti, na koji nain i koji e odrediti izradu, posao i konani proizvod. Unutar svakog sprinta, Scrum prolazi kroz sve faze razvojnog procesa. Planiranje, programiranje, testiranje i isporuka ponavljaju se kroz svaki sljedei sprint. Na kraju svakog sprinta razvojni tim isporuuje zaokrueni dio proizvoda, odnosno potencijalno isporuiv inkrement proizvoda. Razbijanjem razvojnog procesa na sprintove, Scrum smanjuje rizik od isporuke loeg softvera, softvera koji nee zadovoljiti trite, a ujedno se time i lake prilagouje novim i promijenjenim zahtjevima korisnika koji su neizbjeni. No Scrum se ne zaustavlja na tome, pa svaki pojedini sprint dodatno razbija na jo manje dijelove koji traju tono 24 sata, a poinju i zavravaju dnevnim Scrumom.4.1.4. Artefakti (lista zahtjeva i dokumenti) u Scrumu Product Backlog (zaliha proizvoda)Skup karakteristika koje ulaze u svaki Sprint dolaze iz Product Backlog-a, koji predstavlja skup zahtjeva rangiranih po prioritetu. Product backlog je sortirana lista svega to e moda biti potrebno za proizvod i jedini izvor zahtjeva za bilo kakvim promjenama koje se rade na proizvodu. Za svaki zahtjev u Product backlogu postoji jedinstveni identifikator za zahtjev, kategoriju (svojstvo, poboljanje, greka), status, prioritet, procjena koliko je vremena potrebno za implementaciju. uva se u obliku tablice. Koja backlog stavka e ui u sprint se odreuje tokom sprint sastanka planiranja. Tokom ovog sastanka vlasnik proizvoda informira tim o pojedinostima, ukljuujui njegov sadraj, raspoloivost i sortiranje u Product backlog za koje eli da budu kompletirani. Tim odreuje koliko ovoga se moe uraditi tokom sljedeeg sprinta. Product backlog nikad nije konaan. Do promjene moe doi zbog uoavanja novih funkcionalnosti koje proizvod treba imati ili u sluajevima kada neka od funkcionalnosti iz trenutane liste zahtjeva nee moi implementirati za vrijeme trenutanog sprinta jer nema dovoljno vremena ili neki vanjski preduvjeti nisu zadovoljeni. U poetku sadri samo one zahtjeve koji su inicijalno poznati i razumljiviji. Product backlog evoluira kako evoluira proizvod i okolina na kojoj e se primjenjivati. Product backlog sadri listu svih mogunosti, funkcionalnosti, zahtjeva, unaprjeenja i popravaka koja zajedno ine promjene koje e se primijeniti nad proizvodom u budunosti. Obino je sortiran prema vrijednosti, riziku, prioritetu i nunosti. Stavke na vrhu backloga su dio trenutnih razvojnih aktivnosti.Kada pone sprint niko ne moe da promijeni backlog, tj. zahtjevi su zamrznuti za sprint. Koordinacija se vri na kratkim svakodnevnim sastancima tokom sprinta pod nazivom Scrum. Sprint Backlog (zalihe trenutne iteracije)Sprint backlog je skup stavki s Product Backloga koje su odabrane za Sprint plus plan realizacije inkrementa i realizacije cilja Sprinta. To je ujedino i lista svih poslovnih i tehnologijskih svojstava, poboljanja i nedostataka koji su rasporeeni u trenutnu iteraciju (sprint). Sprint Backlog je procjena razvojnog tima koje funkcionalnosti e biti u sljedeemInkrementu i posao koji je potreban za realizaciju tog Inkrementa.Sprint backlog je plan sa dovoljno detalja da bi se na Dnevnom Scrumu mogle razumjeti aktualne promjene. Razvojni tim mijenja Sprint backlog tokom Sprinta, te se na njega dodaju zadaci tokom Sprinta. Ti zadaci se dogaaju kada Razvojni tim, radei prema planu, naui neto vie o poslu koji je potreban da se zadovolji cilj Sprinta. U svakom od zadataka postoji kratak opis kako je nastao, ko je vlasnik zadatka, status i vrijeme koje je potrebno da se zadatak izvri. Kako se pojavi potreba za novim poslom, Razvojni tim ga dodaje na Sprint backlog. Samo razvojni tim moe mijenjati Sprint backlog tokom Sprinta. Sprint backlog je vidljiva slika posla u realnom vremenu kojeg Razvojni tim namjerava obaviti tokom Sprinta i koji pripada iskljuivo Razvojnom timu. Sprint burndown graph (Dijagram preostalog posla u Sprintu)Dijagram prikazuje koliko je vremena preostalo da se zavre Sprint zadaci te je prikazan Scrum timu. Koriste se za praenje i procjenu napretka te prikazuju procjenu napretka implementacije.

Slika 3: Dijagram preostalog posla u sprintu4.1.5. Kontrola i prilagoavanje Scrum propisuje etiri formalne prilike za kontrolu i prilagodbu: sastanak planiranja perioda implementacije (sprint), dnevni Scrum sastanak, revizija perioda implementacije i retrospektiva Revizija perioda implementacije (Planning meeting) odrava se na kraju samog perioda implementacije radi kontrole inkrementa i prilagoavanja listezadataka projekta, ako je potrebno Retrospektiva perioda implementacije (Sprint Rewiev) je prilika za lanove Scrum tima da kontroliraju sebe i donesu plan za unapreenja koja e se provesti tokom sljedeeg perioda implementacije. Dnevni Scrum je vremenski ogranien dogaaj, koji slui da razvojni tim uskladi aktivnosti i donese plan za sljedea 24 sata. Vri se kontrola rada od prethodnog dnevnog Scrum sastanka i procjenom posla koji bi mogao biti odraen prije slijedeeg sastanka. Dnevni Scrum se odrava uvijek na istom mjestu svaki dan, bez kanjenja, da bi se smanjila kompleksnost, da lanovi tima za vrijeme sastanka stoje (odatle i naziv standup) s obzirom na to da dugo stajanje nije ugodno, time se osigurava da se lanovi tima u razgovoru dre bitnih tema.Scrum sastanak je osnovna komponenta metodologije te se na njemu daju obeanja koja podiu odgovornost i odravaju da projekt ide u pravom smjeru. Meutim, ovi sastanci mogu biti nemogui ukoliko na njima prisustvuje previe ljudi, a preporueno je da svaki tim ima maksimalno sedam ljudi. Kada postoje vei timovi, oni se dijele u manje grupe gdje svaka od njih ima svoj Scrum sastanak, a nakon toga predstavnik svake grupe sudjeluje na Scrumu Scrumova sastanku gdje odgovara na ve navedena pitanja te na ovaj nain se ire informacije meu podtimovima. Scrum master forsira pravilo da samo razvojni tim sudjeluje na dnevnom Scrum sastanku i da sastanak traje 15 minuta. Dnevni Scrum jedna je on malobrojnih obaveza cijelog razvojnog tima, a nuan je da bi se postigla unutarnja transparentnost u timu.To je stand-up sastanak na kojem svi lanovi razvojnog tima u neformalnom okupljanju odgovaraju na tono tri pitanja:1. to je napravio od juer? 2. to planira napraviti danas? 3. Ima li nekih problema koji ga spreavaju u izvravanju zadataka? Ova pitanja se odnose na:1. Kontrolu izvrenog 2. Planiranje budueg dizajna3. Identifikaciju rizika i nalaenje rjeenja

Slika 4: Prikaz ploe sa aktivnostima4.2. Faze metodologijeProces razvoja programskog proizvoda provodi se kroz tri faze:Prije igre (planiranje, dizajn/arhitektura visoka razina apstrakcije)Igra (razvoj, sprintovi iterativni ciklusi, poboljanja, nove verzije)Poslije igre (nema novih zahtjeva, sistem spreman za produkciju).4.3. Uloge i odgovornostiScrum nain razvoja softvera u svojoj je biti samoorganizujui proces te kao takav ne zahtijeva ulogu voditelja, barem ne u smislu kako se tradicionalno takva uloga opisuje. Scrum tim se najee sastoji od sedam lanova, a minimum je pet dok je maksimum devet, od kojih su obavezni jedan vlasnik proizvoda (Product owner) koji je predstavnik klijenta, Scrum master koji je voa tima i ostali lanovi tima koji mogu biti specijalisti za pojedine dijelove razvoja Uobiajeno je Scrum tim smjeten zajedno, meutim, postoje Scrum timovi koji su geografski razmjeteni te gdje lanovi tima uestvuju na dnevnim sastancima preko konferencijske veze. Scrum timovi su samousmjereni i samoorganizirani. Tim se obvezuje da e izvriti zadane ciljeve u jednoj iteraciji te mu je dana autonomija i odgovornost da odlui kako e do toga doi.Glavne uloge u Scrum-u imaju: ScrumMaster - koji vodi procese (slino project manager-u) Product Owner koji predstavlja zainteresirane uesnike (stakeholders) Team - razvojni tim Scrum majstor: (eng. scrum master)Scrum majstor ima za zadatak pojaavati cilj iteracije, odravati dnevne sastanke (Scrum sastanci), demonstrati iteracije (Sprint pregled), pratiti napredak, uklanjati zapreke i osiguravavati resurse. Scrum Master ima ulogu kontrolirati proces, ali ne i ljude u timu.Umjesto da rasporeuje posao i govori svim lanovima tima to da rade, Scrum Master nadzire proces i brine se o tome da se on odradi. On je takoer razvojni programer zaduen za cijeli razvojni proces te sudjeluje u razvoju proizvoda, odnosno nije samo menader. Scrum Master donekle odgovara ulozi voditelja projekta, iako Scrum strogo gledajui ne poznaje ulogu voditelja projekta.On povezuje vlasnika proizvoda i razvojni tim i pomae razvojnom timu da ostanu kreativni i produktivni. Scrum Master savjetuje vlasnika proizvoda o tome kako poveati povrat ulaganja. Vlasnik proizvoda: (eng. product owner)Vlasnik proizvoda je odgovoran za izradu i prioritiziranje zaliha proizvoda, odabire to e biti ukljueno u sljedeu iteraciju (sprint) i pregledava sistem po zavretku sprinta. Vlasnik proizvoda odgovoran je za maksimizaciju vrijednosti proizvoda i rada razvojnog tima, te upravljanje listom zadataka projekta. Lista zadataka projekta je artefakt Scruma koji sadri sve to e moda biti potrebno za proizvod i jedini je izvor zahtjeva za bilo kakvim promjenama koje se rade na proizvodu. Vlasnik proizvoda mora zastupati interese kupaca kroz zahtjeve i odreivanje prioriteta .Cijeli tim mora potovati odluke vlasnika proizvoda.

Razvojni timRazvojni programer je lan Scrum tima koji se zalae za postizanje cilja Sprinta i ima sve ovlasti da uini to god je potrebno da bi to postigao. Tim je odgovoran za dovretak posla . U idealnom sluaju, ekipa se sastoji od sedam lanova, plus ili minus dva pojedinaca . Za softverske projekte, tipini tim ukljuuje profesionalce koje ini mjeavina softverskih inenjera , arhitekata , programera , analitiara , QA strunjaka , testera i UI dizajnera.Na kraju svakog sprinta , interesne grupe i lanovi tima moraju ocijeniti napredak projekta i planirati svoje daljnje korake. To omoguuje da se projekt kree u smjeru koji treba, da se prilagoditi i orijentira na obavljeni posao, a ne nagaanja i predvianja .Upravo taj naglasak na trajnoj procjenu obavljenog posla je u velikoj mjeri odgovoran za njegovu popularnost kod menaderima i programera.

Slika 5: Uesnici skruma

4.4. Praksa i koritenjeBudui da Scrum ne zahtjeva neku odreenu inenjersku praksu, moe je se usvojiti za upravljanje bilo kojom inenjerskom praksom koja trenutno postoji u odreenoj organizaciji. Scrum moe promijeniti opise poslova i obiaje Scrum projektnog tima. Na primjer, upravitelj projektom, tj. Scrum Master, vie ne organizira tim, ve se tim sam organizira i donosi odluke o tome to da radi. To se moe nazvati samoorganizirani tim .29Umjesto da organizira tim, Scrum Master radi na uklanjanju nedostataka u procesu, vodi dnevne Scrum sastanke ije odluke usuglaava sa upravom. Njegova uloga sada postaje vie kao trener nego kao upravitelj projektom. Smatra se da se najbolja prilagoavanje nekih Scrum metoda dogaa na dnevnim Scrum sastancima. Scrum metoda se moe primijeniti za upravljanje bilo kojom inenjerskom praksom, ali najvie se koristi kod razvoja financijskih upravljanja, Internet i medicinskih aplikacija. Metoda se koristi u 50 tak velikih organizacija i na tisuama projekata.Primjer koritenja i najboljih praksi koritenja Scruma: Praenje pomou dijagrama moe se koristiti za praenje sprinta statusa. Grafiki prikazi su bolji od tablinih prikazima u planiranju. Povrat investicija vrijednosti su korisni za odreivanje prioriteta stavke u sprintu. Koritenje plou i jednostavnog planiranja te alata za izvjetavanje (npr. Excel, SPR intometer , project simple ) vani su i dovoljno su procesno kvalitetni. Scrum metodologija ne nudi dokumentira sve, ali to ne znai da "nema dokumentacije". Stvarno potrebna dokumentacija se moe obaviti po potrebi. Dnevni sastanci ne smije biti due od 15 minuta. Scrum je okretna metodologija i niko ne treba sluati druge lanove oko problematinih detalja. Ti se podaci mogu raspravljati nakon svakodnevnog susreta s Scrum majstorom Stand up sastanak stil je bolji na dnevnim sastancima, da bi sastanak krako trajao. Takoer sastanak, mjesto i vrijeme se preporua da se isti za svaki dan. Zaostatak moe sadravati stavke koje nee biti razvijene. Prema ROI vrijednosti, neke stvari se ne mogu razvijati i to je normalno. Zaostatak treba sadravati sve mogue stavke svejedno. Sprint duina (u tjednima) ne preporuuje se da se mijenja. No, prema rezultatima sprintera retrospektivnih sastanka, sprint od sedmica duljine moe se promijeniti, ako su stvarno vani razlozi. 6 sati na dan je realno planiranje ulaz. Ukupni kapacitet sprinta satu moe se izraunati kao: (broj lanova tima) * (broj dana sprint) * 6 sati

4.5. Prednosti i nedostaci4.5.1. Prednosti Scrum metodologije: Pomae kompaniji u utedi vremena i novaca Zbog kratkih i brzih sprintova i stalne povratne informacije, lake se nositi s promjenama. Dnevni sastanci omoguuju mjerenje individualne produktivnosti. To dovodi do poboljanja u produktivnosti kod svakog od lanova tima. Problemi su identificirani i unaprijed odreeni na dnevnim sastancima i stoga moe biti rijeeni vrlo brzo. Lake je dostaviti kvalitetan proizvod u zakazano vrijeme. Dodatan troak u smislu procesa i upravljanja je minimalan to dovodi do breg i jeftinijeg rezultat. Inzistira se na estim auririranjima kako bi se otkrio napredak u radu putem. Stoga postoji jasna vidljivost projekta. To je iterativan proces koji zahtjeva stalnu povratnu informaciju od korisnika. Problemi su identificirani i unaprijed kroz dnevnim sastancima i stoga moe biti rijeen u brzo 4.5.2. Nedostaci Scrum metodologije: Ako zadatak nije dobro definisan, procjena trokova projekta i vremena da se projekt obavi nee biti tona. U takvom sluaju, zadatak se moe protegnuti na nekoliko Sprintova. Ako su lanovi tima nisu usklaeni, projekt nee uspjeti. To je dobro za male projekte, koji se brzo kreu jer se dobro radi samo s malim timom. Ova metodologija treba iskusan tim lanovima. Ako se tim sastoji od ljudi koji nisu obueni, projekt ne moe biti dovren na vrijeme. Scrum majstor mora vjerovati timu jer ako su previe strogi, to moe biti vrlo frustrirajue za njih, to dovodi do demoralizacije i neuspjeha projekta. Ukoliko bilo koji od lanova tima prestao raditi tokom razvoja moe imati ogroman obrnut utjecaj na razvoj projekta.

5. ZakljuakAgilne 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 poveati postotak uspjenosti IT projekata obzirom da razvojni tim kroz intenzivnu komunikaciju s klijentom i odgovaranje na promjene u zahtjevima 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 financiranja i osiguravanja projektnog budeta, obzirom da se od agilnog tima oekuje prilagoavanje promjenama u zahtjevima 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. Baeli, E. (2013). Usporedba vodopadne metodologije i Scrum metodologije prema fazama provedbe, Ekonomski fakultet, Split2. Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley Professional3. Belak, S. (2005). Uvod u znanost, Visoka kola za turistiki menadment, ibenik.4. Chan, K. (2013). Project vs Program Management, Online5. Highsmith J. (2004), Agile Project Management: Creating Innovative Products. Addison Wesley6. Padavi, I. (2009). Postupak evaluacije te implementacija agilnog modela razvoja softvera, diplomski rad, Fakultet organizacije i informatike, Varadin:.7. Sutherland, J., Viktorov, A., & Blount, J. (2006). Distributed Scrum: Agile Project Management with Outsourced Development. Agile 2006, international Conference, Mineapolis2