Upload
kemal80
View
15
Download
0
Embed Size (px)
DESCRIPTION
agilni-razvoj
Citation preview
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.