INFOTEH-JAHORINA Vol. 10, Ref. E-I-16, p. 466-470, March 2011. 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 poslednje vreme u domeni softverskog inženjerstva veoma su popularne tzv. agilne metode izrade softvera. Agilne metode svoje korene vuku iz lean menadžmenta koji se pojavio u Japanu 80-ih godina prošlog veka. Ove metode postavljaju principe akvizicije korisničkih zahtjeva, projektiranja i razvoja aplikacija i informacionih sistema 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 uspešnosti projekata razvoja informacionih sustava. U ovom radu opisani su ključni koncepti agilnih metoda razvoja softvera sa naglaskom na SCRUM metodiku. Agilne metode nisu panacea za uspešan razvoj softvera posebice u sferi finansiranja 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 procentom neuspeš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 Jute 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. Saradnja s klijentom ispred pregovora o ugovoru 4. Reagiranje na promenu 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 veka 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 uspešnosti u ranoj fazi projekta. Prije svega moramo imati viziju šta 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 mora da imaju viziju kako će zajedno da odrade 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 sledi se unaprijed definirani plan, dok se u aginom pristupu u fazi špekulacije okvirno procenjuju zahtjevi i funkcionalnosti budućeg softvera, procenjuje 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 saradnju 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 466
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, šta 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 informacionog sistema 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 šta želi. U najboljem slučaju, dobit će šta je napisano. Definisanje prioriteta u izradi informacionog sistema veoma je važno, posebice kod većih projekata. Na taj način omogućava se svojevrsno rangiranje funkcionalnosti po važnosti tj. vrednosti 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 definisanja 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 promenjiva. To zapravo znači da korisnik u saradnji s razvojnim timom može, ukoliko primeti potrebu za tim, podignuti ili smanjiti prioritet određene funkcionalnosti sistema. Prilikom definisanja prioriteta, razvojni tim i klijent moraju razmišljati o tome šta donosi najveću vrednost za klijenta i u skladu s tim definisati koje će funkcionalnosti (opisane korisničkim pričama) ući u koju fazu. Prilikom definisanja 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 šta ranije te se u ranim fazama projekta definisaju dijelovi sistema 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 promena i dodatnih zahteva oduži i da se zbog toga ne uspe realizovati na vreme. Zbog toga menadžment može da ostane bez primerice mesečnog izvještaja koji može da bude 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 da ima razumevanja za već pomenute probleme vezane uz shvaćanje ICT-a i budućeg softvera od strane samog klijenta. Šta se tiče veličine timova, to naravno ovisi o samom projektu te tehničkoj zahtjevnosti i opsegu posla koji treba da se obavi u zadatom vremenu. Agilna metoda XP je pogodna za manje timove, dok je Scrum, primerice, 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 poseduje 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 promenile 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 smernice koje uloge je poželjno, a koje nije poželjno kombinirati u istoj osobi. Primjer jedne takve preporuke dat je na slici 1. 467
malo vremena. U ovom potonjem se krije i opasnost od nerazumevanja 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. 5. Karakteristike klijenta Slika 1. MSF Timski model [3] Sve agilne metode razvoja podrazumevaju 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 sledeć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 rešenja ne mora nužno da bude i budući korisnik toga rešenja. Tako primerice može da se desi da se razvojni tim povodi za naputcima naručitelja (sponzora) projekta, koji je često u menadžerskoj ili vlasničkoj poziciji, zanemarujući zahteve krajnjih korisnika (radnika), a da kasnije taj isti naručitelj plaćanje projekta uvjetuje prihvaćanjem od strane radnika budućih korisnika sistema/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 sistema tj. korisniku nevidljivih delova sistema. 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 Slika 2. Odnos aktivnosti izrade arhitekture i korisničkih funkcionalnosti kroz vreme [4] 6. Procenjivanje Procjena opsega i vremenskog roka potrebnog za obavljanje posla zamišljenog projektom je veoma važna aktivnost u celom procesu agilnog razvoja. Početna procena temelj je za planiranje resursa, očekivanja klijenta i razvojnog tima te pretpostavljenu cenu samog projekta. Osim početne procene, u toku rada na projektu, razvojni tim trebao bi periodički da procenjuje ostatak posla obzirom na identificirane promene i nova saznanja. Općenito, možemo da kažemo da danas u praksi postoje dva temeljna načina procenjivanja. Prvi način je vremenski i obično se izražava u jedinicama čovek/dan ili čovek/čas. 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 procenjivanja potrebno je razumeti razliku između točnost i preciznosti. Naime, ako programer kaže da mu je za obavljanje određenog posla potrebno 25,6 časova, 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 primer da je realno za taj posao bilo potrebno 16 radnih časova (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 da zaključimo kako bi nam točnost trebala biti važnija od preciznosti same procene. Pridjeljivanje tehničke kompleksnosti također može da pridonese realnijoj proceni članova razvojnog tima. Razmišljajući o tehničkoj kompleksnosti, procenitelj može identificirati potencijalne probleme koji bi mogli da se pojave bilo da je reč o implementaciji ili novim znanjima koja je potrebno usvojiti kako bi se realizovala potrebna aktivnost Kod procenjivanja, preporuka je da svi članovi budućeg razvojnog tima daju svoje mišljenje tj. svoju vlastitu procenu. 468
Kod takvog načina procenjivanja, voditelj projekta mora da ima na umu i individualne karakteristike procenitelja. Neki članovi tima po svojoj prirodi mogu da budu pesimisti, a neki optimisti. Postoje i matematičke tehnike kako ovo može da se uključi u konačnu procenu i o tome će biti reči u nastavku. Jedan od matematičkih metoda za procenjivanje 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 procenjivanja dana sledećom formulom: KPp predstavlja procenjenu količinu posla, O označava optimističnu procenu potrebnog vremena, N je najverovatnije, a P je pesimistično vreme potrebno za procenu. Praksa je pokazala da, kada se od članova tima koji trebaju da procene određeni posao zatraži tri vremena (optimistično, najverovatnije, pesimistično), procenitelji daju točnije procene. Objašnjenje toga je poticanje takvog načina procenjivanja na dublje promišljanje o problematici o kojoj se radi. Ukoliko procenitelj mora dati optimističnu procenu, 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, verovatno će procenitelju kroz glavu proći pomisao o ponovnoj iskoristivosti nekog ranije napisanog koda ili nešto slično. Ako se pak od procenitelja traži pesimistična varijanta, veća je verovatnost da će osoba promisliti o mogućim problemima i možda se prisetiti više mogućih poteškoća negoli da se radi o proceni koja za rezultat ima samo jednu vrednost, a ne tri kako je to slučaj kod PERT-a. Kako se zapravo radi o vaganoj aritmetičkoj sredini triju vrednosti procena, ta formula se može i korigirati ovisno o individualnim karakteristikama procjenitelja. Tako se ovisno o tome je li procenitelj pesimist ili optimist, težište u formuli može staviti na optimistično tj. pesimistično vreme, množeći to vreme sa faktorom različitim od 1 i sukladno tome smanjiti faktor kojim se množi najverovatnije procenjeno vreme. 7. Razvojni ciklusi Razvojni ciklusi su u agilnim metodama organizovani 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 sistem 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 realizovala 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 mora da se odradi u jednoj iteraciji. Nakon jedne ili više iteracija razvoja, može uslediti isporuka (engl. Delivery). Isporuka predstavlja preuzimanje funkcionalnosti od strane naručitelja. Također, postoje i agilne metode gde ove granice nisu strogo definisane 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 preći na isporuku realiziranog dela sistema te korisnik može odmah da počne s korištenjem. Primer 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 sudeluju članovi razvojnog tima. Za vreme osvrta na proteklu iteraciju članovi tima pokušavaju odgovoriti na sledeća pitanja: Što nije bilo u redu?, Gdje smo pogrešili?, Kako možemo da izbegnemo iste 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 bileženja svih aktivnosti, poželjno je i povećanje efikasnosti i osiguranje konzistentnosti korištenjem nekog softverskog alata. Vrlo praktičan primer 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 smemo smetnuti s uma samu bit agilnih metoda i dozvoliti da primena 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 menjanje i prilagođavanje arhitekture i kratke iteracije. [6] Scrum - Agilno upravljanje projektima primjenom Scrum metodike izvorište ima u radu japanaca Takeuchi-a i Nonakae i njihovih analiza najboljih praksi u kompanijama poput Fuji-Xerox, Honda, Canon i Toyota. [7] Scrum je metodika razvoja softvera koja sledi sve paradigme agilnog razvoja i donosi obrasce za upravljanje timom i razvojnim ciklusom 469
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 teritoriju. 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 za vreme 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 pomenuti 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 vreme dobivaju inačice za agilni razvoj. Tako primerice 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 da poveća procenat uspešnosti IT projekata obzirom da razvojni tim kroz intenzivnu komunikaciju s klijentom i odgovaranje na promene u zahtevima 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 finansiranja i osiguravanja projektnog budžeta, obzirom da se od agilnog tima očekuje prilagođavanje promenama u zahtevima što neminovno znači i probijanje vremenskog okvira projekta. Postavlja se dakle pitanje što sa rokovima i što sa cenom izrade softvera? Slobodno možemo da kažemo sledeće ako se radi o agilnom projektu i agilnom timu, nužno je da i klijent bude agilan. Kako u smislu saradnje, 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 definisanih projektnih faza i opširna dokumentacija. U praksi se pokazalo kako prakticiranje agilnih metoda uvelike može da poveća procenat uspešnosti IT projekata obzirom da razvojni tim kroz intenzivnu komunikaciju s klijentom i odgovaranje na promene u zahtevima 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 smernice za stvaranje agilnog ugovora te problem finansiranja i osiguravanja projektnog budžeta, jer se od agilnog tima očekuje prilagođavanje promenama u zahtevima š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. 470