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 nepotrebne

dokumentacije, smanjenja nesporazuma i povećanja uspješnosti projekata razvoja informacijskih sustava. U ovom radu

opisani su ključni koncepti agilnih metoda razvoja softvera sa naglaskom 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 od

sedamnaest stručnjaka iz područja softverskog inženjerstva

zagovornika agilnih metoda razvoja, sastala se 2001. godine

u maloj kolibici u skijaškom odmaralištu negdje u planinama

Utah-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 ukratko

saž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. Lean

menadžment se pojavio u Japanu 80-ih godina prošlog

stoljeć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 ranoj

fazi 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 projektnog tima moraju imati

viziju kako će zajedno odraditi posao.

Špekuliranje - Iako riječ špekulacija ima odreĎeno

negativno 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 izrada

softvera slijedi se unaprijed definirani plan, dok se u aginom

pristupu u fazi špekulacije okvirno procjenjuju zahtjevi i

funkcionalnosti budućeg softvera, procjenjuje se količina

posla za odreĎene zahtjeve, okvirni plan isporuke, rizici i

strategije ublažavanja rizika te troškovi projekta.

Istraživanje - Faza istraživanja (kako se naziva ponegdje

u literaturi) u principu predstavlja sami razvoj proizvoda.

Istraživanje je riječ koja opisuje samu suštinu ideje agilnog

razvoja. Naime, cilj je kreirati proizvod, ne prema nekom

čvrsto definiranom planu, već uz suradnju krajnjeg korisnika

kroz 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 kada

kažemo da je to prednost, gašenje projekta u ranoj fazi može

uš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 i

izbjegla važno je pravovremeno uočavanje pogrešaka i

zastranjivanja u projektu. Agilne metode razvoja sa svojim

konceptima retrospektiva i redovitih revizija što je učinjeno

uz praćenje sukladnosti obavljenog posla sa potrebama

klijenta 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 i

vlastitih potreba od strane klijenta.

Zatvaranje - Zatvaranje projekta je važan element

dobrog projektnog menadžmenta bez obzira je li riječ on

tradicionalnom ili agilnom pristupu upravljanju projektom.

Agilne metode u fazi zatvaranja projekta naglasak stavljaju

na dovršavanje svih otvorenih zadataka, finalizaciju nužne

dokumentacije i najvažnije, na komunikaciju i odnose unutar

tima.

3. Korisničke priče i prioriteti

Korisničke priče (engl. User Stories) predstavljaju

osnovnu jedinicu u planiranju, izradi i evaluaciji novog

programskog proizvoda. Korisnička priča je pandan

funkcionalnostima 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 puke

funkcionalnosti koja kaže da se odreĎena radnja treba

dogoditi 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 na

umu, sama akvizicija zahtjeva (po tradicionalnom pristupu) je

ponešto drugačiji proces. Praktičar agilne metode koji

komunicirajući s klijentom od njega saznaje njegove potrebe

i opisuje korisničke priče više ulazi u samu problematiku od

tradicionalnog projektanta informacijskog sustava koji

„jednostavno“ popisuje željene funkcionalnosti. Elementi

korisničke priče su: korisnička uloga koja će koristiti

funkcionalnost, cilj koji se postiže korištenjem

funkcionalnosti te razlog zbog kojeg se ta funkcionalnost

koristi. 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žna

komunikacija 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 mu

zapravo treba. Ukoliko 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. U

najboljem 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čin

omogućava se svojevrsno rangiranje funkcionalnosti po

važnosti tj. 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 razvojnu

fazu. Lista prioriteta često je i prilog ugovoru koji se sklapa

izmeĎu naručitelja i isporučitelja. U skladu sa filozofijom

agilnih 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 funkcionalnosti sustava. Prilikom

definiranja prioriteta, razvojni tim i klijent moraju razmišljati

o tome što donosi najveću vrijednost za klijenta i u skladu s

tim 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 o

vremenski kritičnim aplikacijama. Naime, praksa je pokazala

da klijenti često žele isporučene funkcionalnosti što ranije te

se u ranim fazama projekta definiraju dijelovi sustava koji

podržavaju proces, a kontrola i praćenje se zanemaruju i

uključuju u naknadne iteracije. Ukoliko se rezultat ranije

iteracije pusti u rad, a kontrola i praćenje se prepuste

sljedećoj iteraciji, postoji opasnost da se druga faza zbog

mogućih promjena i dodatnih zahtjeva oduži i da se zbog

toga ne uspije realizirati na vrijeme. Zbog toga menadžment

mož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žnija

karakteristika tima je upravo sposobnost i volja za

komuniciranje s klijentom. TakoĎer, tim mora imati

razumijevanja 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 treba

obaviti 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či

naravno i linearno povećanje brzine obavljanja nekog posla, a

sa sobom nosi veću potrebu za koordinacijom.

Obzirom da su najčešći praktikanti agilnih metoda danas

u 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 se

razvio programski proizvod nisu se značajno promijenile u

odnosi na tradicionalne modele razvoja pa tako još uvijek

postoje poslovi koje obavljaju uloge kao što su: projekt

menadžer, program menadžer, projektant, razvojni inženjer,

tester, dizajner itd. Obzirom na ograničenost ljudskih resursa

u 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 postoje

smjernice koje uloge je poželjno, a koje nije poželjno

kombinirati 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 da

klijent nažalost nije dovoljno uključen. Kod dogovaranja

novog 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 karakteristike

klijenta 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 ne

mora nužno biti i budući korisnik toga rješenja. tako se

primjerice može dogoditi da se razvojni tim povodi za

naputcima naručitelja (sponzora) projekta, koji je često u

menadžerskoj ili vlasničkoj poziciji, zanemarujući zahtjeve

krajnjih 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čekivanja

klijenta/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…”, “Ali

rekli 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še

vremena provode na definiranje i kreiranje arhitekture

sustava tj. korisniku nevidljivih dijelova sustava. Kasnije se

više vremena provodi izraĎujući funkcionalnosti za krajnje

korisnike. U skladu s tim i korisnikova percepcija procesa

razvoja je drugačija. Možemo u grubo konstatirati kako su

korisnici u inicijalnim fazama projekta nestrpljivi jer im se

čini da se puno vremena gubi, a ne vide rezultate, dok su u

kasnijim fazama pohlepni obzirom da stječu dojam kako za

kreiranje 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 radi

nerealne procjene, a zaboravlja pritom vrijeme utrošeno na

izgradnju 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čkih

funkcionalnosti kroz vrijeme [4]

6. Procjenjivanje

Procjena opsega i vremenskog roka potrebnog za

obavljanje posla zamišljenog projektom je veoma važna

aktivnost u cijelom procesu agilnog razvoja. Početna

procjena temelj je za planiranje resursa, očekivanja klijenta i

razvojnog tima te pretpostavljenu cijenu samog projekta.

Osim početne procjene, u toku rada na projektu, razvojni tim

trebao bi periodički procjenjivati ostatak posla obzirom na

identificirane promjene i nova saznanja.

Općenito, možemo konstatirati da danas u praksi postoje

dva temeljna načina procjenjivanja. Prvi način je vremenski i

obič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 potrebno

implementirati 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 za

obavljanje 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), onda

vidimo da je neprecizni procjenitelj bio zapravo puno bliže

realnosti tj. njegova procjena je bila točnija. Iz primjera

mož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že

identificirati 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ćeg

razvojnog tima daju svoje mišljenje tj. svoju vlastitu

procjenu. Kod takvog načina procjenjivanja, voditelj projekta

mora 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 ovo

može uključiti u konačnu procjenu i o tome će biti riječi u

nastavku.

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čava

optimističnu procjenu potrebnog vremena, N je

najvjerojatnije, a P je pesimistično vrijeme potrebno za

procjenu. Praksa je pokazala da, kada se od članova tima koji

trebaju procijeniti odreĎeni posao zatraži tri vremena

(optimistično, najvjerojatnije, pesimistično), procjenitelji daju

točnije procjene. Objašnjenje toga je poticanje takvog načina

procjenjivanja na dublje promišljanje o problematici o kojoj

se radi. Ukoliko procjenitelj mora dati optimističnu procjenu,

sam će sebi postavljati pitanja koji su to faktori koji bi mogli

utjecati da se posao obavi u optimističnom roku. Ukoliko se

radi o programerima, vjerojatno će procjenitelju kroz glavu

proći pomisao o ponovnoj iskoristivosti nekog ranije

napisanog koda ili nešto slično. Ako se pak od procjenitelja

traži pesimistična varijanta, veća je vjerojatnost da će osoba

promisliti o mogućim problemima i možda se prisjetiti više

mogućih poteškoća negoli da se radi o procjeni koja za

rezultat ima samo jednu vrijednost, a ne tri kako je to slučaj

kod PERT-a.

Kako se zapravo radi o vaganoj aritmetičkoj sredini triju

vrijednosti procjena, ta formula se može i korigirati ovisno o

individualnim karakteristikama procjenitelja. Tako se ovisno

o tome je li procjenitelj pesimist ili optimist, težište u formuli

može staviti na optimistično tj. pesimistično vrijeme,

množeći to vrijeme sa faktorom različitim od 1 i sukladno

tome 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 razvojnog

tima koje kao izlaz imaju programski kod tj. aplikaciju ili

sustav spreman za uporabu od strane klijenta. Aktivnosti

članova tima često se u agilnim metodama predstavljaju

zadaćama (engl. Task). Nekoliko zadaća čini posao koji treba

odraditi kako bi se realizirala korisnička priča (engl. User

Story). Nekoliko korisničkih priča može sačinjavati

funkcionalnost (engl. Feature). Dok skup funkcionalnosti

može predstavljati opseg posla koji se mora odraditi u jednoj

iteraciji. Nakon jedne ili više iteracija razvoja, može uslijediti

isporuka (engl. Delivery). Isporuka predstavlja preuzimanje

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

agilne metode gdje ove granice nisu strogo definirane pa se

tako i po završetku rada na nekoj korisničkoj priči i po

testiranju iste od strane razvojnog tima može odmah prijeći

na isporuku realiziranog dijela sustava te korisnik može

odmah 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šnjih

agilnih metoda za upravljanje projektima izrade softvera.

Restrospektive se izvode nakon svake iteracije (sprinta) i

predstavljaju diskusiju u kojoj sudjeluju članovi razvojnog

tima. 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 kako

dokumentaciju 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 i

osiguranje neke vrste repozitorija svih artefakata projekta u

digitalnom obliku. Razlozi za to su naravno

dokumentarističke prirode. Osim samog bilježenja svih

aktivnosti, poželjno je i povećanje efikasnosti i osiguranje

konzistentnosti korištenjem nekog softverskog alata. Vrlo

praktičan primjer u kojem bi korištenje softvera umjesto

klasične ploče, samoljepljivih papirića i tabličnog kalkulatora

bilo poželjno je slučajno otpadanje papirića s ploče zbog loše

kvalitete ljepila, čime se stvara nekonzistentnost u

„project/sprint backlog-u“.

Svakako, pri odabiru softverskog alata za podršku

agilnom 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 od

drugih. 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 u

zahtjevima. [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 koji

timovi u tom sportu dogovaraju prije akcije i kako malo po

malo kroz sprintove osvajaju teritorij. Razvojni ciklus u

Scrumu se naziva Sprint. Sprint je zapravo jedna iteracija u

razvoju i obično traje od dva tjedna do pet tjedana. Scrum

poput većine ostalih agilnih metoda podrazumijeva korištenje

korisničkih priča za planiranje i izvoĎenje projekta. Sve

korisničke priče koje opisuju rad planiran za projekt čine tzv.

„Project Backlog“, dok skup korisničkih priča koje će se

realizirati 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 znanstvenoj

literaturi mogu se pronaći i brojne druge metode za agilno

upravljanje projektima i to ne samo za industriju proizvodnje

softvera. Od agilnih metoda za proizvodnju softvera možemo

spomenuti 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 projekata

obzirom 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 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 pozitivnih strana, 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 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 probijanje

vremenskog okvira projekta. Postavlja se dakle pitanje – što

sa rokovima i što sa cijenom izrade softvera? Slobodno

možemo reći sljedeće – ako se radi o agilnom projektu i

agilnom timu, nužno je da i klijent bude agilan. Kako u

smislu suradnje, tako i u smislu plaćanja vaše agilnosti.

12. Zaključak

Agilne metode razvoja softvera naglasak stavljaju na veću

komunikaciju i kreiranje korisnog programskog proizvoda, a

u drugi plan su stavljeni strogi okviri unaprijed definiranih

projektnih faza i opširna dokumentacija. U praksi se pokazalo

kako prakticiranje agilnih metoda uvelike može povećati

postotak uspješnosti IT projekata obzirom 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 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 pozitivnih

strana, 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 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 probijanje

vremenskog okvira projekta. Svi ovi, ali i neki drugi problemi

prakticiranja agilnih metoda mogu biti predmet budućih

istraž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 te

implementacija 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 with

Outsourced Development. Agile 2006, international

Conference. Mineapolis.