agilni razvoj

5/17/2018 agilni razvoj - slidepdf.com

http://slidepdf.com/reader/full/agilni-razvoj 1/5

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

Sadržaj - U posljednje vrijeme u domeni softverskog inženjerstva veoma su popularne tzv. agilne metode izrade softvera.

Agilne metode svoje korijene vuku iz lean menadžmenta koji se pojavio u Japanu 80-ih godina prošlog stoljeća. Ove metode

postavljaju principe akvizicije korisničkih zahtjeva, projektiranja i razvoja aplikacija i informacijskih sustava na način koji

uključuje krajnjeg korisnika u puno većoj mjeri nego je to kod tradicionalnih metoda. Osim toga, agilne metode predlažu novi,

fleksibilniji način razmišljanja tj. „opušteniji“ odnos prema cjelokupnom projektu, a sve u svrhu eliminacije nepotrebnedokumentacije, smanjenja nesporazuma i povećanja uspješnosti projekata razvoja informacijskih sustava. U ovom radu

opisani su ključni koncepti agilnih metoda razvoja softvera sa nagla skom na SCRUM metodiku. Agilne metode nisu panacea

za uspješan razvoj softvera posebice u sferi financiranja agilnih projekata pa je u radu opisan i taj praktični 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.

1. Nastanak agilnih metoda

Potaknuta nezadovoljstvom uzrokovanim velikim

postotkom neuspješnih IT projekata, skupina sastavljena odsedamnaest stručnjaka iz područja softverskog inženjerstva

zagovornika agilnih metoda razvoja, sastala se 2001. godineu maloj kolibici u skijaškom odmaralištu negdje u planinamaUtah-a kako bi pokušali naći rješenje za goruće probleme

postojećih metodologija programskog inženjerstva. Rezultat

njihovog druženja je čuveni manifest - Agile Manifesto. [1]

Agilni manifest je dokument koji opisuje temeljne

postavke budućih agilnih metoda. Manifest možemo ukratkosažeti na četiri temeljne poruke:

1. Individualci i interakcija ispred procesa i alata

2. Softver koji radi ispred iscrpne dokumentacije

3. Suradnja s klijentom ispred pregovora o ugovoru

4. Reagiranje na promjenu ispred praćenja plana

Ove poruke zapravo su prilagodba temeljnih koncepata

lean menadžmenta softverskom inženjerstvu. Leanmenadžment se pojavio u Japanu 80-ih godina prošlogstoljeća i njegov je cilj eliminacija nepotrebnih aktivnosti i

veća uključenost samih radnika u unaprjeĎenje procesa proizvodnje.

2. Principi agilnih metoda

Vizija - Jedan od temeljnih koncepata agilnog upravljanja

projektima koji se susreće u literaturi koja ga opisuje je

vizija. Vizija je prema [2] kritični faktor uspješnosti u ranojfazi projekta. Prije svega moramo imati viziju što radimo.Zatim, moramo imati viziju tko će biti uključen u projekt – klijenti, proizvodni menadžeri, članovi projektnog tima i

ostali dionici. I treće, članovi pr ojektnog tima moraju imati

viziju kako će zajedno odraditi posao.

Špekuliranje - Iako riječ špekulacija ima odreĎenonegativno značenje u smislu nepromišljenog riskiranja ili

manipulacija, izvorno značenje riječi je„Naslućivati/pretpostavljati nešto na temelju nepotpunih

činjenica ili informacija“. U tradicionalnim metodama izradasoftvera slijedi se unaprijed definirani plan, dok se u aginom

pristupu u fazi špekulacije okvirno procjenjuju zahtjevi ifunkcionalnosti budućeg softvera, procjenjuje se količina

posla za odreĎene zahtjeve, okvirni plan isporuke, rizici istrategije ublažavanja rizika te troškovi projekta.

Istraživanje - Faza istraživanja (kako se naziva ponegdjeu literaturi) u principu predstavlja sami razvoj proizvoda.

Istraživanje je riječ koja opisuje samu suštinu ideje agilnograzvoja. Naime, cilj je kreirati proizvod, ne prema nekom

čvrsto definiranom planu, već uz suradnju krajnjeg korisnikakroz proces razvoja istraživati i otkrivati što je to što korisnik zapravo treba.

Adaptacija - Agilni razvoj kao svoju prednost ima i

mogućnost ranog gašenja projekta. Iako zvuči suludo kadakažemo da je to prednost, gašenje projekta u ranoj fazi možeuštedjeti mnogo uzaludnog rada, novca i nezadovoljstva.

Naravno uvjet uza to je realnost u suočavanju s napretkom

projekta od strane klijenta i razvojnog tima. Kako bi se takva

situacija uopće prepoznala, a što je još važnije naravno iizbjegla važno je pravovremeno uočavanje pogrešaka izastranjivanja u projektu. Agilne metode razvoja sa svojim

konceptima retrospektiva i redovitih revizija što je učinjenouz praćenje sukladnosti obavljenog posla sa potrebamaklijenta omogućavaju upravo to. Adaptaciju na promjene,

bilo da se radi o promjenama u okolini sustava za koji radimo



proizvod ili o promjenama u shvaćanju konačnog projekta ivlastitih potreba od strane klijenta.

Zatvaranje - Zatvaranje projekta je važan elementdobrog projektnog menadžmenta bez obzira je li riječ ontradicionalnom ili agilnom pristupu upravljanju projektom.

Agilne metode u fazi zatvaranja projekta naglasak stavljaju

na dovršavanje svih otvorenih zadataka, finalizaciju nužnedokumentacije i najvažnije, na komunikaciju i odnose unutar tima.

3. Korisničke priče i prioriteti

Korisničke priče (engl. User Stories) predstavljajuosnovnu jedinicu u planiranju, izradi i evaluaciji novog

programskog proizvoda. Korisnička priča je pandanfunkcionalnostima u tradicionalnom pristupu razvoja. Naziv

„funkcionalnost“ zadržao se i kod praktičara agilnih metoda.Iako je sami naziv manje bitan, važno je percipirati kako taj

novi naziv „korisnička priča“ u sebi sadržava suštinu

filozofije agilnog razvoja. Naime, za razliku od pukefunkcionalnosti koja kaže da se odreĎena radnja trebadogoditi u odreĎenom trenutku, korisnička priča je opis tko,što i zbog čega želi nešto učiniti. Iako se razlika na prvi

pogled čini minorna, ona je itekako velika. Imajući ovo naumu, sama akvizicija zahtjeva (po tradicionalnom pristupu) je

ponešto drugačiji proces. Praktičar agilne metode kojikomunicirajući s klijentom od njega saznaje njegove potrebe

i opisuje korisničke priče više ulazi u samu problematiku odtradicionalnog projektanta informacijskog sustava koji

„jednostavno“ popisuje željene funkcionalnosti. Elementikorisničke priče su: korisnička uloga koja će korist iti

funkcionalnost, cilj koji se postiže korištenjem

funkcionalnosti te razlog zbog kojeg se ta funkcionalnostkoristi. Primjer korisničke priče je: „Voditelj prodaje ima

uvid u broj prodanih proizvoda u odabranom razdoblju po

mjesecima kako bi mogao pratiti trendove.“

Kod definicije korisničkih priča izuzetno je važnakomunikacija sa krajnjim korisnikom tj. razumijevanje

njegovih potreba. Često se dogaĎa da krajnji korisnik ne posjeduje informatička znanja i da ne zna objasniti što muzapravo treba. Ukolik o se ne pridržavamo ovih načela vrločesto ćemo dobiti odgovor klijenta koji će glasiti poput:„Napravili ste što sam tražio, ali to nije ono što mi treba.“

Ako programer koji radi na funkcionalnosti samo pročita

korisničku priču i krene raditi bez komunikacije s klijentom,vrlo je vjerojatno da korisnik neće dobiti što želi. Unajboljem slučaju, dobit će što je napisano.

Definiranje prioriteta u izradi informacijskog sustava

veoma je važno, posebice kod većih projekata. Na taj načinomogućava se svojevrsno rangiranje funkcionalnosti po

važnosti t j. vrijednosti za krajnjeg korisnika čime je pak omogućena isporuka programskog proizvoda u iteracijama.Upravo isporuke u iteracijama, gdje se nakon svake iteracije

razvoja korisniku isporučuje softver koji radi, temelj je svih

agilnih metoda. Prilikom definiranja prioriteta razvojni tim i

korisnik se moraju usuglasiti oko toga koliko će razina

prioriteta imati i koje će funkcionalnosti ući u koju razvojnufazu. Lista prioriteta često je i prilog ugovoru koji se sk lapa

izmeĎu naručitelja i isporučitelja. U skladu sa filozofijomagilnih metoda i lista prioriteta je promjenjiva. To zapravo

znači da korisnik u suradnji s razvojnim timom može,ukoliko primijeti potrebu za tim, podignuti ili smanjiti

prioritet odreĎene f unkcionalnosti sustava. Prilikom

definiranja prioriteta, razvojni tim i klijent moraju razmišljatio tome što donosi najveću vrijednost za klijenta i u skladu stim definirati koje će funkcionalnosti (opisane korisničkim

pričama) ući u koju fazu. Prilikom definiranja prioriteta treba

paziti na zamku koja se može dogoditi ukoliko se radi ovremenski kritičnim aplikacijama. Naime, praksa je pokazalada klijenti često žele isporučene funkcionalnosti što ranije tese u ranim fazama projekta definiraju dijelovi sustava koji

podržavaju proces, a kontrola i praćenje se zanemaruju iuključuju u naknadne iteracije. Ukoliko se rezultat ranijeiteracije pusti u rad, a kontrola i praćenje se prepustesljedećoj iteraciji, postoji opasnost da se druga faza zbogmogućih promjena i dodatnih zahtjeva oduži i da se zbogtoga ne uspije realizirati na vrijeme. Zbog toga menadžmentmože ostati bez primjerice mjesečnog izvještaja koji može

biti ključan za donošenje odluke, a njegova realizacija kasni.

4. Karakteristike tima

Kako je jedna od temeljnih pretpostavki agilnog razvoja i

agilnog upravljanja projektom komunikacija, najvažnijakarakteristika tima je upravo sposobnost i volja za

komuniciranje s klijentom. TakoĎer, tim mora imatirazumijevanja za već spomenute probleme vezane uz

shvaćanje ICT-a i budućeg softvera od strane samog klijenta.

Što se tiče veličine timova, to naravno ovisi o samom projektu te tehničkoj zahtjevnosti i opsegu posla koji se trebaobaviti u zadanom vremenu. Agilna metoda XP je pogodna

za manje timove, dok je Scrum, primjerice, najpogodniji za

timove od pet do deset članova. Razmatrajući veličinu 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 opsežna projektna dokumentacija,gubitak člana tima koji posjeduje mnoga znanja o projektu,

predstavlja velik rizik. Isto tako, povećanje tima ne značinaravno i linearno povećanje brzine obavljanja nekog posla, asa sobom nosi veću potrebu za koordinacijom.

Obzirom da su najčešći praktikanti agilnih metoda danasu industriji proizvodnje softvera male tvrtke tj. mali projektni

timovi, postavlja se pitanje što sa različitim ulogama unutar

samog razvojnog tima. Same aktivnosti potrebne da bi serazvio programski proizvod nisu se značajno promijenile uodnosi na tradicionalne modele razvoja pa tako još uvijek

postoje poslovi koje obavljaju uloge kao što su: projektmenadžer, program menadžer, projektant, razvojni inženjer,

tester, dizajner itd. Obzirom na ograničenost ljudskih resursau malim timovima, jasno je da će se ove uloge često morati

pojavljivati unutar jedne osobe. Zbog mogućeg svojevrsnog„sukoba interesa“ meĎu ulogama unutar pojedinca postojesmjernice koje uloge je poželjno, a koje nije poželjnokombinirati u istoj osobi. Primjer jedne takve preporuke dan

je na slici 1.



Slika 1. MSF Timski model [3]

5. Karakteristike klijenta

Sve agilne metode razvoja podrazumijevaju veliku

uključenost klijenta u sami proces razvoja. Neke agilne

metode to preporučaju većoj, a neke u manjoj mjeri, no bez

obzira koju metodu koristili u praksi, najčešće se pokazuje daklijent nažalost nije dovoljno uključen. Kod dogovaranjanovog projekta, veoma je važno klijentu objasniti prednosti

agilnog razvoja te ga pripremiti na sve što ga očekuje. U provoĎenju agilnog projekta nužne su neke karakteristikeklijenta poput sljedećih: strpljenje, spremnost na sudjelovanje

u razvoju, strpljivost, spremnost na plaćanje agilnosti projektnog tima.

TakoĎer važno je imati na umu da naručitelj rješenja nemora nužno biti i budući korisnik toga rješenja. tako se

primjerice može dogoditi da se razvojni tim povodi zanaputcima naručitelja (sponzora) projekta, koji je često u

menadžerskoj ili vlasničkoj poziciji, zanemarujući zahtjevekrajnjih korisnika (radnika), a da kasnije taj isti naručitelj plaćanje projekta uvjetuje prihvaćanjem od strane radnika – budućih korisnika sustava/aplikacije.

U praksi treba biti oprezan u pogledu očekivanjaklijenta/naručitelja te u pregovorima i pojašnjavanju

problematike klijentu treba biti i realan jer u suprotnom, u

kasnijim fazama projekta, možemo očekivati pitanja poput: “Ali vi ste to trebali uočiti…”, “Ali to je bio vaš posao…”,

“Ali nama je to jako skupo…”, “Ali nama je on jako

važan…”, “Ali rekli ste da će vam trebati toliko…” , “Alirekli ste da će to koštati toliko…”.

Još jedna važna aktivnost u agilnom upravljanju projektom je i upravljanje korisničkim očekivanjima. Naime,

isporuka pojedinih dijelova programskog proizvoda se u

različitim fazama izrade odvija različitom dinamikom. U početnim fazama (iteracijama) razvojni inženjeri viševremena provode na definiranje i kreiranje arhitekture

sustava tj. korisniku nevidljivih dijelova sustava. Kasnije se

više vremena provodi izraĎujući funkcionalnosti za krajnjekorisnike. U skladu s tim i korisnikova percepcija procesa

razvoja je drugačija. Možemo u grubo konstatirati kako sukorisnici 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 stječu dojam kako zakreiranje funkcionalnosti za krajnjeg korisnika treba izrazito

malo vremena. U ovom potonjem se krije i opasnost od

nerazumijevanja korisnika koje se često manifestira i

gubitkom povjerenja jer mu se čini kako razvojni tim radinerealne procjene, a zaboravlja pritom vrijeme utr ošeno naizgradnju arhitektonske osnovice sustava. Ilustracija odnosa

aktivnosti izrade arhitekture i korisničkih funkcionalnosti

prikazana je na slici 2.

Slika 2. Odnos aktivnosti izrade arhitekture i korisničkihfunkcionalnosti kroz vrijeme [4]

6. Procjenjivanje

Procjena opsega i vremenskog roka potrebnog zaobavljanje posla zamišljenog projektom je veoma važnaaktivnost u cijelom procesu agilnog razvoja. Početna

procjena temelj je za planiranje resursa, očekivanja klijenta irazvojnog tima te pretpostavljenu cijenu samog projekta.

Osim početne procjene, u toku rada na projektu, razvojni timtrebao bi periodički procjenjivati ostatak posla obzirom naidentificirane promjene i nova saznanja.

Općenito, možemo konstatirati da danas u praksi postojedva temeljna načina procjenjivanja. Prvi način je vremenski iobično se izražava u jedinicama čovjek/dan ili čovjek/sat.Drugi način je bodovni i pretpostavlja identificiranje koliko

je „bodova teška“ odreĎena funkcionalnost koju je potrebnoimplementirati u projektu. Kada govorimo o problemu

procjenjivanja potrebno je razumjeti razliku izmeĎu točnost i preciznosti. Naime, ako programer kaže da mu je zaobavljanje odreĎenog posla potrebno 25,6 sati, 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 preciznošću. Uzmimo za primjer da je realno

za taj posao bilo potrebno 16 radnih sati (znači 2 dana), ondavidimo da je neprecizni procjenitelj bio zapravo puno bližerealnosti t j. njegova procjena je bila točnija. Iz primjeramožemo zaključiti kako bi nam točnost trebala biti važnija od

preciznosti same procjene.

Pridjeljivanje tehničke kompleksnosti takoĎer može pridonijeti realnijoj procjeni članova razvojnog tima.Razmišljajući o tehničkoj kompleksnosti, procjenitelj možeidentificirati potencijalne probleme koji bi se mogli pojaviti

bilo da je riječ o implementaciji ili novim znanjima koja je potrebno usvojiti kako bi se realizirala potrebna aktivnost

Kod procjenjivanja, preporuka je da svi članovi budućegrazvojnog tima daju svoje mišljenje tj. svoju vlastitu procjenu. Kod takvog načina procjenjivanja, voditelj projektamora na umu imati i individualne karakteristike procjenitelja.



Neki članovi tima po svojoj prirodi mogu biti pesimisti, a

neki optimisti. Postoje i matematičke tehnike kako se ovomože uključiti u konačnu procjenu i o tome će biti riječi unastavku.

Jedan od matematičkih metoda za procjenjivanje je ičuveni PERT (engl. Project Evaluation and Review

Technique). PERT dolazi iz područja mrežnog planiranja i jedan od njegovih elemenata je i matematička tehnika procjenjivanja dana sljedećom formulom:

KPp predstavlja procijenjenu količinu posla, O označavaoptimističnu procjenu potrebnog vremena, N jenajvjerojatnije, a P je pesimistično vrijeme potrebno za

procjenu. Praksa je pokazala da, kada se od članova tima kojitrebaju procijeniti odreĎeni posao zatraži tri vremena(optimistično, najvjerojatnije, pesimistično), procjenitelji dajutočnije procjene. Objašnjenje toga je poticanje takvog načina

procjenjivanja na dublje promišljanje o problematici o kojojse radi. Ukoliko procjenitelj mora dati optimističnu procjenu,sam će sebi postavljati pitanja koji su to faktori koji bi mogliutjecati da se posao obavi u optimističnom roku. Ukoliko seradi o programerima, vjerojatno će procjenitelju kroz glavu

proći pomisao o ponovnoj iskoristivosti nekog ranijenapisanog koda ili nešto slično. Ako se pak od procjeniteljatraži pesimistična varijanta, veća je vjerojatnost da će o soba

promisliti o mogućim problemima i možda se prisjetiti višemogućih poteškoća negoli da se radi o procjeni koja zarezultat ima samo jednu vrijednost, a ne tri kako je to slučajkod PERT-a.

Kako se zapravo radi o vaganoj aritmetičkoj sredini trijuvrijednosti procjena, ta formula se može i korigirati ovisno oindividualnim karakteristikama procjenitelja. Tako se ovisno

o tome je li procjenitelj pesimist ili optimist, težište u formulimože staviti na optimistično tj. pesimistično vrijeme,množeći to vrijeme sa faktorom različitim od 1 i sukladnotome smanjiti faktor kojim se množi najvjerojatnije

procijenjeno vrijeme.

7. Razvojni ciklusi

Razvojni ciklusi su u agilnim metodama

organizirani u cikluse koje se popularno nazivaju i iteracije(engl. Iteration). Iteracije obuhvaćaju aktivnosti razvojnogtima koje kao izlaz imaju programski kod tj. aplikaciju ili

sustav spreman za uporabu od strane klijenta. Aktivnosti

članova tima često se u agilnim metodama predstavljajuzadaćama (engl. Task). Nekoliko zadaća čini posao koji trebaodraditi kako bi se realizirala korisnička priča (engl. User Story). Nekoliko korisničkih priča može sačinjavatifunkcionalnost (engl. Feature). Dok skup funkcionalnosti

može predstavljati opseg posla koji se mora odraditi u jednojiteraciji. Nakon jedne ili više iteracija razvoja, može uslijeditiisporuka (engl. Delivery). Isporuka predstavlja preuzimanje

funkcionalnosti od strane naručitelja. TakoĎer, postoje i

agilne metode gdje ove granice nisu strogo definirane pa setako i po završetku rada na nekoj korisničkoj priči i potestiranju iste od strane razvojnog tima može odmah prijeći

na isporuku realiziranog dijela sustava te korisnik možeodmah početi s korištenjem.

Primjer hijerarhije ciklusa i aktivnosti u nekom projektu:

Isporuka 1.

Iteracija 1.1.

Funkcionalnost 1.1.1.

Korisnička priča 1.1.1.1. Task 1.1.1.1.1.

Task 1.1.1.1.2.

Korisnička priča 1.1.1.2.

8. Retrospektive

Restrospektive su sastavni koncept većine današnjihagilnih metoda za upravljanje projektima izrade softvera.

Restrospektive se izvode nakon svake iteracije (sprinta) i

predstavljaju diskusiju u kojoj sudjeluju članovi razvojnogtima. Za vrijeme osvrta na proteklu iteraciju članovi tima

pokušavaju odgovoriti na sljedeća pitanja: „Što nije bilo u

redu?“, „Gdje smo pogriješili?“, „Kako ćemo izbjeći site probleme u budućnosti?“.

9. Softver

Iako agilne metode u svojoj suštini minimiziraju kakodokumentaciju tako i alate (uključujući i softverske) većfokus stavljaju na ljude i procese, praksa je pokazala kako je

ipak dobro imati način praćenja provoĎenja agilnih metoda iosiguranje neke vrste repozitorija svih artefakata projekta u

digitalnom obliku. Razlozi za to su naravno

dokumentarističke prirode. Osim samog bilježenja svihaktivnosti, poželjno je i povećanje efik asnosti i osiguranje

konzistentnosti korištenjem nekog softverskog alata. Vrlo praktičan primjer u kojem bi korištenje softvera umjestoklasične ploče, samoljepljivih papirića i tabličnog kalkulatora

bilo poželjno je slučajno otpadanje papirića s ploče zbog lošekvalitete ljepila, čime se stvara nekonzistentnost u„project/sprint backlog-u“.

Svakako, pri odabiru softverskog alata za podrškuagilnom razvoju ne smijemo smetnuti s uma samu bit agilnih

metoda i dozvoliti da primjena softvera odvede u nepotrebnu

birokratizaciju i otuĎenje samih članova tima jednih oddrugih. Upravo stoga, zahtjevi koji se postavljaju pred takav

softver su brzina i jednostavnost korištenja 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 susreću za ubrzanim promjenama uzahtjevima. [5] Ekstremno programiranje uvodi niz obrazaca

kojima se pospješuje razvoj softvera u uvjetima stalnih promjena zahtjeva. Neki do tih obrazaca su programiranje u

paru, unit testiranje, refaktoriranje, konstantno mijenjanje i

prilagoĎavanje arhitekture i kratke iteracije. [6]

Scrum - Agilno upravljanje projektima primjenom Scrum

metodike izvorište ima u radu japanaca Takeuchi-a i Nonaka-

e i njihovih analiza najboljih praksi u kompanijama poput



Fuji-Xerox, Honda, Canon i Toyota. [7] Scrum je metodika

razvoja softvera koja slijedi sve paradigme agilnog razvoja i

donosi obrasce za upravljanje timom i razvojnim ciklusom

programskog proizvoda. Samo ime metodike dolazi iz

američkog nogometa i inspirirano je načinom na se kojitimovi u tom sportu dogovaraju prije akcije i kako malo pomalo kroz sprintove osvajaju teritorij. Razvojni ciklus u

Scrumu se naziva Sprint. Sprint je zapravo jedna iteracija urazvoju i obično traje od dva tjedna do pet tjedana. Scrum poput većine ostalih agilnih metoda podrazumijeva korištenjekorisničkih priča za planiranje i izvoĎenje projekta. Svekorisničke priče koje opisuju rad planiran za projekt čine tzv.„Project Backlog“, dok skup korisničkih priča koje će serealizirati tijekom 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 stručnoj i znanstvenojliteraturi mogu se pronaći i brojne druge metode za agilnoupravljanje projektima i to ne samo za industriju proizvodnje

softvera. Od agilnih metoda za proizvodnju softvera možemospomenuti 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 vrijeme dobivaju inačice za agilni razvoj. Tako primjerice i popularni Microsoftov MSF (engl. Microsoft

Solution Framework) ima inačicu za agilni razvoj.

11. Zašto agilne metode nisu panacea za projektni

menadžment (pogotovo kod nas)

U praksi se pokazalo kako prakticiranje agilnih metoda

uvelike može povećati postotak uspješnosti IT projekataobzirom da razvojni tim kroz intenzivnu komunikaciju s

klijentom i odgovaranje na promjene u zahtjevima koje

nastaju u tijeku provoĎenja projekta stječe bolji uvid ustvarne korisnikove potrebe i na taj način kreira softver koji

je usklaĎeniji sa korisničkim očekivanjima. Iako agilnemetode imaju mnogo pozitivnih strana, postoje i problemi s

kojima se suočavaju praktičari. Ti problemi tiču se znanjastečenih u radu, obzirom da ne postoji opširnadokumentacija, velikih napora koje klijent mora uložiti,

obzirom da se od njega očekuje uključenost u razvoj,nedorečenosti u smislu pravne popraćenosti projekta,obzirom da ne postoje smjernice za stvaranje agilnog ugovora

te problem financiranja i osiguravanja projektnog budžeta,

obzirom da se od agilnog tima očekuje prilagoĎavanje promjenama u zahtjevima što neminovno znači i probijanjevremenskog okvira projekta. Postavlja se dakle pitanje – štosa rokovima i što sa cijenom izrade softvera? Slobodnomožemo reći sljedeće – ako se radi o agilnom projektu i

agilnom timu, nužno je da i klijent bude agilan. Kako usmislu suradnje, tako i u smislu plaćanja vaše agilnosti. 12. Zaključak

Agilne metode razvoja softvera naglasak stavljaju na većukomunikaciju i kreiranje korisnog programskog proizvoda, a

u drugi plan su stavljeni strogi okviri unaprijed definiranih

projektnih faza i opširna dokumentacija. U praksi se pokazalok ako prakticiranje agilnih metoda uvelike može povećati

postotak uspješnosti IT projekata obzirom da razvojni timkroz intenzivnu komunikaciju s klijentom i odgovaranje na

promjene u zahtjevima koje nastaju u tijeku provoĎenja projekta stječe bolji uvid u stvarne korisnikove potrebe i na

taj način kreira softver koji je usklaĎeniji sa korisničkim

očekivanjima. Iako agilne metode imaju mnogo pozitivnihstrana, postoje i problemi s kojima se suočavaju praktičari. Ti problemi tiču se znanja stečenih u radu, obzirom da ne postoji

opširna dokumentacija, velikih napora koje klijent morauložiti, obzirom da se od njega očekuje uključenost u razvoj,nedorečenosti u smislu pravne popraćenosti projekta,obzirom da ne postoje smjernice za stvaranje agilnog ugovora

te pr oblem financiranja i osiguravanja projektnog budžeta,obzirom da se od agilnog tima očekuje prilagoĎavanje

promjenama u zahtjevima što neminovno znači i probijanjevremenskog okvira projekta. Svi ovi, ali i neki drugi problemi

prakticiranja agilnih metoda mogu biti predmet budućihistraživanja 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-BA0F-

35A021D85234&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 teimplementacija agilnog modela razvoja softvera, diplomski

rad. Varaždin: Fakultet organizacije i informatike.

[7] Sutherland, J., Viktorov, A., & Blount, J. (2006).

Distributed Scrum: Agile Project Management withOutsourced Development. Agile 2006, international

Conference. Mineapolis.

agilni razvoj

Documents

Transcript of agilni razvoj