Sveučilište u Zagrebu

Fakultet organizacije i informatike

Varaždin

Razvoj projekta XP metodikom

Ivan Rubil
38866/09-R

U Varaždinu, 21.01.2010.
SADRŽAJ

Uvod ........................................................................................................................................... 3
Agilne metode ............................................................................................................................ 4
Ekstremno programiranje – XP.................................................................................................. 5
Osnovne aktivnosti ................................................................................................................. 5
Praktične tehnike .................................................................................................................... 7
Cijeli tim............................................................................................................................. 7
Igra planiranja .................................................................................................................... 8
Korisnički testovi ............................................................................................................... 9
Mala izdanja ....................................................................................................................... 9
Jednostavan dizajn............................................................................................................ 10
Programiranje u paru ........................................................................................................ 10
Testiranje .......................................................................................................................... 11
Unaprjeđenje dizajna........................................................................................................ 11
Kontinuirana integracija ................................................................................................... 11
Zajedničko vlasništvo....................................................................................................... 12
Standardi pisanja koda ..................................................................................................... 12
Održivi tempo................................................................................................................... 12
Metafora ........................................................................................................................... 13
Faze projekta i životni ciklus ............................................................................................... 13
Primjer.................................................................................................................................. 16
Kritike................................................................................................................................... 19
Zaključak .................................................................................................................................. 21
Literatura .................................................................................................................................. 22

2
Uvod

Danas živimo u vrlo dinamičnom svijetu što se tiče programskog inženjerstva i razvoja
aplikacija. Očekuju se da se naprave sve kompliciranije aplikacije u što manje vremena i s što
manje potrošenog novca. Ovo je djelomično opravdano razvojem tehnologija, kako
hardverska (računala su svakim danom sve brža) tako i softverska (programski jezici i alati su
sve brojniji i moćniji). Unatoč tome pojavili su se problemi zbog korištenja zastarjelih metoda
razvoja aplikacija koje su prvobitno osmišljene za razne industrijske procese.

Danas kada su okruženje i zahtjevi sve dinamičniji potrebne su nove metode koje će moći ići
u korak s vremenom. Prijašnje metode su prije funkcionirale dosta dobro ali osamdesetih je
došlo do velikih promjena i svijet se počeo ubrzavati i globalizirati, a razvoj softvera skupa s
njim.

Godine 2001. donesen je manifest agilne metode razvoja i njenih principa koji je objedinjavao
mnogo drugih modernih metoda (Ekstremno programiranje, Scrum, DSDM, Pragmatično
programiranje itd.).

U ovom radu biti će riječ o Ekstremnom programiranju, metodi čiji je cilj popraviti kvalitetu
softvera i povećati sposobnost prilagodbe na česte promjene u zahtjevima aplikacije. Metodu
je razvio trojac: Kent Beck, Ward Cunningham, i Ron Jeffries Ova metoda zagovara razvoj u
mnogo malih koraka ili „izdanja“ u kratkim vremenskim razmacima. Ekstremno
programiranje je jedna od najviše korištenih agilnih metoda razvoja softvera.

3
Agilne metode

Prije nego krenem s ekstremnim programiranjem želio bih prvo dati kratki osvrt na osnove
svih agilnih metoda, koji im je temelj, principi i na što se fokusiraju. Sve metode koje spadaju
pod naziv agilne metode se fokusiraju na iste probleme priliko razvoja samo što ih rješavaju
na malo drugačiji način, ali sve imaju iste osnovne principe.

U već spomenutom manifestu1 agilnih metoda govori se da je njihov cilj otkrivati bolje načine
razvoja softvera razvijajući i pomažući drugima u razvijanju softvera. Kroz taj rad počeli su
cijeniti:
• Osobe i interakcije umjesto procesa i alata
• Softver koji radi umjesto opširne dokumentacije
• Zajednički rad s kupcem umjesto pregovaranja preko ugovora
• Reagiranje na promjene umjesto striktnog pridržavanja plana

Vrijednosti s desne strane se također cijene i ne treba ih nikako zapostaviti, ali agilne metode
cijene više one s lijeve i na njih se fokusiraju. Glavni principi2 su im:
• da zadovolje klijente s ranim i kontinuiranim isporučivanjem korisnog i primjenjivog
softvera,
• da se bude spreman na promjene čak i kasnijim fazama, čime se dobije na
konkurentnosti,
• često isporučivanje softvera koji je primjenjiv i radi, svakih par tjedana ili mjeseci,
• bliski rad naručitelja i programera softvera
• projekte treba graditi oko motiviranih ljudi kojima se mora osigurati pozitivna okolina
• najučinkovitiji način komunikacije u timu je licem u lice
• softver koji radi je osnovno mjerilo napretka
• promovira se održivi tempo razvoja cijelo vrijeme
• stalna pažnja usmjerena na tehničku izvrsnost i dobar dizajn povećavaju agilnost
• jednostavnost – “umjetnost” povećanja posla koji ne treba napraviti je ključno
• najbolje arhitekture, zahtjevi i dizajn pojave se iz samoorganizirajućih timova

1
http://agilemanifesto.org/
2
http://www.agilealliance.org

4
 • tim periodički ispituje dobre i loše postupke te ih prokušava popraviti u sljedećem
periodu

Ekstremno programiranje – XP

U klasičnim metodama razvoja zahtjevi su obično postavljeni jasno na početku i uglavnom

ostaju fiksni. To znači da će cijena mijenjanja zahtjeva, što je čest slučaj kod razvoja softvera,
biti velika. Kao i druge agilne metode ekstremno programiranje (XP nadalje) pokušava
smanjiti tu cijenu uvodeći u razvoj mnogo malih ciklusa radije nego jedan veliki. U takvom
okruženju promijene su prirodne, neizbježne i dobrodošle u razvoju softvera te treba računati
na njih umjesto da se pokušavaju stvoriti fiksni i stabilni zahtjevi.

Ekstremno programiranje je idealno za manje timove (manje od 15 članova) koji rade na

projektima gdje su ciljevi nejasno definirani i podložni čestim promjenama. Vrlo je veliki
naglasak na timski rad i na međusobnu te komunikaciju s klijentima. Uobičajena je praksa
kodiranja u paru te je napisani kod otvoren svima, time se postiže da netko drugi svojim
idejama može pridonijeti kodu.

Primjenom ove metode gdje se rade česta manja izdanja softvera omogućava klijentu da ih
odmah testira i da svoje mišljenje. Problem je u tome što klijenti obično nisu stručni dovoljno
da bi jasno mogli definirati što bi krajnji proizvod trebao raditi ili na koji način bi trebao
raditi. Ako se cijeli projekt podjeli u puno malih dijelova koji su funkcionalni te ih klijent
može odmah isprobati, tada se mogu dati primjedbe i savjete jer je klijentu puno jasnije s
vremenom što mu odgovara, a što ne.

Osnovne aktivnosti

Programiranje – zagovornici XP-a kažu da su jedini istinski važni produkti razvojnog

procesa linije koda koje računalo može izvršavati. Bez koda nema krajnjeg rezultata, gotovog
produkta. U slučaju nedoumice u vezi koda se predlaže kodiranje svake varijante te testiranje i
odabir najbolje. Kodiranje se koristi za komunikaciju u slučaju da jedan programer želi
objasniti nešto drugome pošto je kod uvijek nedvosmislen i jasan.

5
Testiranje - ne možete biti sigurni da funkcija radi ukoliko je niste testirali. Programske i
dizajnerske greške su velik problem prilikom i poslije razvoja. Pretpostavka je da ako malo
testiranja rješava neke probleme, puno testiranja će riješiti većinu problema. Provode se
testovi na svim pojedinačnim blokovima koda gdje je težnja da se naprave automatizirani
testovi koji će rigorozno testirati kod. Moraju se testirati sve funkcionalnosti (eng. feature)
prije nego se krene na slijedeću. Također se vrši testiranje u kojem se provjerava da li
napravljeni posao odražava zahtjeve klijenta.

Slušanje – programeri moraju slušati što klijenti zahtijevaju da sustav treba raditi odnosno
koja poslovna logika je potrebna. Moraju to dobro razumjeti da bi klijentu mogli objasniti
kako se to tehnički može odnosno ne može izvesti. Ova komunikacije ne traje samo u početku
već se potiče stalna komunikacija sa klijentom. Pošto se XP vrti oko malih izdanja programeri
mogu prije i nakon izdanja dobiti vrlo potrebne povratne informacije.

Dizajn – iz perspektive jednostavnosti (koja je naglašena u XP-u) moglo bi se zaključiti da

razvoj sustava ne treba više od kodiranja, testiranja i slušanja. Pretpostavka je da ako se ove
faze provode učinkovito da će krajnji proizvod biti kvalitetan. Ovo obično nije istina, osim
možda kod vrlo malih projekata. Problem nastaje kod kompliciranijih i većih projekata kada
ova aktivnost postaje ključna. Kod većih projekata međuovisnosti komponenti često postaju
nejasne. Ovo se može izbjeći tako da se dizajnira struktura koja organizira logiku u sustavu.
Dobar dizajn će izbjeći mnogo ovisnosti unutar sustava zbog čega će biti lakše raditi kasnije
izmjene. Promjenom odgovarajućih arhitektura u dizajniranju (slojevita struktura) krajnja
aplikacija će biti vrlo fleksibilna, lako će se moći izmijeniti ili nadograditi.

6
Praktične tehnike

XP je vrlo prilagodljiva metoda razvoja, iako timovi moraju usvojiti vrijednosti i principe
svakodnevnica i detalji projekta variraju od tima do tima. XP pruža nekoliko svakodnevnih
praksi koje, kada se zajedno koriste, pokazuju jako dobre rezultate u stvaranju kvalitetnog
softvera. Te tehnike3 su:
• Cijeli tim
• Igra planiranja
• Korisnički testovi
• Jednostavan dizajn
• Testiranje (test first development ili test driven development)
• Refaktoriranje
• Programiranje u paru
• Zajedničko vlasništvo nad kodom
• Stalna integracija
• 40 satni radni tjedan
• Naručitelj u timu
• Standardi pisanja koda

Cijeli tim

Mnoge metodologije se oslanjaju na strategiju podijeli-pa-vladaj. Proces razvoja se podijeli na

specifične korake te se koriste različiti ljudi s različitim vještinama u svakom koraku, rezultati
se komuniciraju od jednog koraka kroz drugi preko dokumentacije. U XP timu svi su stalno
uključeni i komunicira se kroz razgovor.

Ova strategija je jako učinkovita, ali zahtjeva da svi fizički budu blizu jedni drugima. Stavlja
se veliki naglasak na sudjelovanje klijenata i drugih stručnjaka u takvim timovima recimo ako
se izrađuje financijska aplikacija jako je poželjno da u timu bude prisutan računovođa ili
financijski administrator.

3
Intro into agile methods, Steve Hayes i Martina Andrews, stranice 15-16

7
Osim stručnjaka koji su vezani za domenu problema poželjno je imati u timu, po potrebi, i
menadžera (u neku vrstu trenera) koji će se pobrinuti da tim ima sve što mu je potrebno i da
ukloni moguće prepreke učinkovitom radu. Svatko je potpuno informiran u timu i svi rade
zajedno. Vrijeme između pitanja i odgovarajućeg odgovora bi trebalo biti nula.

Igra planiranja

U klasičnim metodama naglasak je na jedno ključno pitanje4, a to je da li ćemo biti gotovi do

toga datuma? U agilnim metodama to pitanje se dijeli na dva, koliko će biti gotovo do tog
datuma i što trebamo slijedeće raditi. Većina metoda je pokušava predvidjeti tijek razvoja,
devijacije od tog plana se nazivaju greškama. XP je prilagodljiv i on također pokušava
predvidjeti razvoj ali je spreman na promjenu, ali se predviđanja prilagođavaju stvarnim
razvojem projekta. U slučaju promjene, devijacije, predviđanja su ta koja se smatraju
pogrešnim, a ne stvarni razvoj situacije.

Glavni proces planiranja u XP-u se zove igra planiranja. Igra su sastanci koji se održavaju
jednom po iteraciji ili jednom tjedno. Proces planiranja5 se dijeli na dva dijela:

• Planiranje izdanja – fokusira se na zahtjeve koji su uključeni u određenom

kratkoročnom izdanju i na to kada se treba izdati. Klijenti i programeri su oboje
sastavni dio ove faze. Planiranje izdanja se može podijeliti na tri faze:
o Faza istraživanja – u ovoj fazi će klijent odrediti kratku listu važnih zahtjeva i
kada se oni moraju isporučiti. Oni postaju korisničke priče.
o Faza angažiranja – programeri surađuju sa poslodavcima u radu na
funkcionalnosti koja će biti uključena u slijedeće izdanje.
o Upravljačka faza – u ovoj fazi plan se može prilagoditi, mogu se dodati novi
zahtjevi ili postojeći maknuti odnosno promijeniti.

• Iterativno planiranje – planiraju se aktivnosti i zadaci programera. Klijenti nisu

uključeni u ovaj proces. Iterativno planiranje se također može podijeliti u tri faze:

4
Intro into agile methods, Steve Hayes i Martina Andrews, stranica 16
5
http://en.wikipedia.org/wiki/Extreme_Programming_Practices

8
 o Faza istraživanja – unutar ove faze zahtjevi će se transformirati u različite
zadatke.
o Faza angažiranja – zadaci se dodjeljuju programerima i procjenjuje se potrebno
vrijeme.
o Upravljačka faza – zadaci se izvršavaju nakon čega se rezultati uspoređuju s
originalnim korisničkim pričama.

Cilj igre planiranja je da se razvoj uspješno privede kraju. Umjesto da se pokuša predvidjeti
točne datume kada će programi biti potrebni i završeni, što je vrlo teško, pokušava se projekt
voditi do isporuke koristeći neposredan pristup.

Korisnički testovi

Korisnički testovi oslovljavaju dva uobičajena problema6 u razvoju softvera, kako programeri
znaju kada su gotovi i kako tim može znati da ono što je radilo u zadnjoj iteraciji još uvijek
funkcionira? Za svaku se funkcionalnost (eng. feature) dizajniraju automatizirani testovi koji
će pokazati da sve još uvijek funkcionira, pokretanjem svih testova može se potvrditi da sve
dosad napravljeno još uvijek funkcionira. Time se osigurava da razvoj nikada iz nepažnje ide
unazad. U ovim testovi klijent je taj koji odlučuje da li je funkcionalnost zadovoljavajuća.

Mala izdanja

Isporuka softvera se izvodi kroz česta funkcionalan izdanja koja predstavljaju konkretne
rezultate. Ona daju klijentu povjerenje u razvojni proces i napredak projekta. Ovo omogućuje
održavanje koncepta cijelog tima jer klijent može predložiti svoje ideje i preporuke temeljene
na stvarnom iskustvu dobivenog radom sa softverom. Ovo je najbolji način da se dobije
povratna informacija. Korisnik može prekinuti softver ukoliko je zadovoljan sa
funkcionalnošću koja mu je dana ili ukoliko nije zadovoljan.

6
Intro into agile methods, Steve Hayes i Martina Andrews, stranica 16

9
Vrijednost softvera se daje korisniku što je prije moguće, dio po dio umjesto jedne završne
verzije nakon dugog vremena razvijanja. Sustav se postupno unaprjeđuje, dodaju se nove
funkcionalnosti ili unaprjeđuju stare svaki dan.

Jednostavan dizajn

Programeri trebaju raditi prema pristupu da naprave najjednostavniju stvar koja će raditi
(DTSTTCPW – “do the simplest thing that could possibly work”) te da se ne radi ono što nije
zadatak (YAGNI – You aren’t gonna need it).

Kada se god napiše kod programer se treba zapitati da li postoji jednostavniji način da se to
napravi. Ovo često zna biti problem te se najjednostavnija rješenja mogu lako postati
komplicirana. XP timovi vide dizajn kao nešto što se kontinuirano radi a ne samo na početku
razvoja. Treba ipak paziti i na moguće kasnije nadogradnje. Razni alati i UML se koriste
samo kada pomažu da se nešto napravi ne treba trošiti vrijeme na uređivanje dijagrama.

Programiranje u paru

Sav posao u XP timu se radi u paru gdje sva programera sjede jedan pored drugoga i rade na
istom računalu. Ovo se na prvi pogled može činiti neproduktivnim, ali programiranje je puno
više od samog tipkanja koda. Kod programiranja puno se više vremena provodi razmišljajući i
dizajnirajući male komade koda u kojem slučaju drugačija perspektiva na problem dobro
dođe. Da je ovo dobra praksa potvrđuju istraživanja7 i iskustvo stotinu parova koji kažu da je
programiranje u paru produktivnije. Dok je jedan programer za računalom i piše kod drugi
razmišlja o kodu i daje ideje. Drugi je programer više usredotočen na „veliku sliku“ i stalno
provjerava kod koji prvi programer piše. Ove uloge se stalno izmjenjuju. Preporuča se da
parovi ne budu fiksni kako bi svi znali što koji tim radi i da bi bili upoznati sa cijelim
sustavom (ova praksa ide ruku pod ruku s konceptom zajedničkog vlasništva nad kodom).

7
http://www.pairprogramming.net

10
Testiranje

Važno je izvršavati već pripremljene automatizirane testove svaki puta kada programer doda
novu funkcionalnost. Testovi se moraju napraviti prije nego se implementira neka
funkcionalnost. Ovakav pristup fokusira programera na to što program treba raditi a ne kako.
„Pisanje testova mora postati navika. Na ovaj način programeri su uvijek sigurni da su testovi
spremni te ako izmijene nešto to odmah mogu i testirati. U ovakvom pristupu promjene ne
koštaju puno, čak se i potiču. Ove testove dizajniraju, implementiraju i posjeduju programeri
te se razlikuju od već spomenutih korisničkih testova“8.

Unaprjeđenje dizajna

Kako XP tim isporučuje nove funkcionalnosti tako se sve više upoznaju sa sustavom. Tijekom
razvoja pronalaze zajedničke točke i različitosti u sustavu. Kako uče tako postepeno trebaju
evoluirati dizajn pomoću postupka zvanog refaktoriranje. Refaktoriranje je tehnika
poboljšanja koda bez promijene funkcionalnosti. Izvodi se prije implementacije neke funkcije
tako da se kod učini jednostavnijim ili nakon implementacije. Teško je raditi refaktoriranje
ako nema već pripremljenih testova. Jednostavni dizajn, pisanje testova i programiranje u
paru su prakse koje ovaj proces čine puno „jeftinijim“ i bržim.

Kontinuirana integracija

„XP projekti su timske aktivnosti, važno je da svačiji kod radi zajedno s ostalim. Umjesto da
se dugo vremena paralelno razvija sustav forsira se što češća integracija koda u jednu cjelinu.
Nije neobično da parovi programera integriraju svoj kod svakih par sati ili čak i češće“9. Ne
smije se integrirati dok svi programski testovi ne prođu. Integrirani kod se može staviti na
poslužitelj koji služi kontroli verzija (CVS, SourceControl, ClearCase, Subversion).
Promjenom ove prakse XP timovi ne prolaze kroz česte problema drugih metoda kada se
cijeli proces razvoja zaustavi jer se nakon dugo vremena odlučilo integrirati kod koji
prilikom integracije stvara puno problema.

8
Intro into agile methods, Steve Hayes i Martina Andrews, stranica 18
9
Intro into agile methods, Steve Hayes i Martina Andrews, stranica 18

11
Zajedničko vlasništvo

Pošto su XP projekti timske aktivnosti normalno je da bilo tko može izmijeniti kod nekog
drugog tima. Ovo sprječava česte zastoje kada se čeka da netko napravi neku izmjenu te u isto
vrijeme popravlja kvalitetu koda pošto ga gleda puno ljudi. Ovo je moguće u XP projektu jer
se radi u parovima koji se stalno izmjenjuju pa su svi upoznati sa cijelim kodom te su testovi
uvijek spremni da bi se izmjena testirala10.

Standardi pisanja koda

Sav kod koji XP tim napiše bi trebao izgledati kao da ga je napisala ista (vrlo sposobna)
osoba. Ovo je vrlo važno jer kao što je dosad pokazano u XP timovima stalno netko proučava
kod, a ako ga se ne razumije troši se vrijeme. Ipak standard ne smije oduzimati previše
vremena pa se koriste razni alati. Čest je slučaj da programeri imaju različite navike i stilove
kod pisanja koda tako da standard mora biti prihvaćen od svih. Ovime se podupire učinkovito
sparivanje programera i koncept zajedničkog vlasništva.

Održivi tempo

Većina projekata počinje brzo raditi ali se taj tempo tijekom dana često uspori. To je zato što
njihove prakse stvaraju prepreke učinkovitom radu koje se tijekom dana brzo nakupe. To
uključuje stvari kao što je pisanje duplog koda, dugačke metode, klase koje rade puno stvari,
loše nazvane klase i metode i mnogo drugih problema. XP timovi žele ići najbržim tempom
koji je održiv do kraja. Svaki dan provode malo vremena na prakse koje im sutra ubrzaju
rad11. Tu je važan i menadžment koji mora osigurati odgovarajuću okolinu tako da ne zamara
tim sa administracijom te da osigura rad bez stresa, pritiska ili stalnog umora. Preporuča se
fiksan broj radnih sati tjedno, recimo 40 satni radni tjedan, tako da se nakon osam sati rada
članove tima pošalje kući i da se ne dozvoljava prečest prekovremeni rad.

10
Intro into agile methods, Steve Hayes i Martina Andrews, stranica 18
11
Intro into agile methods, Steve Hayes i Martina Andrews, stranica 19

12
Metafora

Za učinkovitu komunikaciju svatko u timu mora moći razgovarati o sustavu koristeći isti
rječnik i jezik. Učestala je komunikacija kroz metaforu pomoću koje se opisuje sustav
koristeći reference na sustave s kojima su članovi tima upoznati. Ideja je da programeri preko
metafore dobiju sliku gdje se njihov rad uklapa u sustav. Zato je potrebno definirati zajednički
jezik odnosno termine koji su svima jasni. Ovakav način komunikacije omogućava da se na
jednostavan i brz način kaže puno toga. Metafora je u biti figurativan opis arhitekture (podaci
moraju biti podijeljeni i sortirani kao u knjižnici).

Faze projekta i životni ciklus

Na slijedećoj slici prikazane su faze XP-a koju je predložio Scott Ambler. Prvo dolazi faza
istraživanja u kojoj se stvaraju ideje te se postavljaju pitanja što, zašto i kako napraviti nešto.
Ove ideje se temelje na korisničkim pričama koje su temelj svih ideja. Stvara se stup, osnova,
arhitekture sustava. U fazi planiranja se razmišlja o izdanjima verzija tj. kako što bi trebala
raditi i koje zahtjeve mora ispuniti. Nakon toga se ide na ide na dodjeljivanje zadataka,
njihovu procjenu trajanja, sortiranje po važnosti, planiranje iteracije i samo pisanje koda.
Nakon što izdanje zadovolji sve testove i zahtjeve mjere se performanse i ukoliko je sve u
redu izdaje se. Cijelo vrijeme se već postojeći kod održava i unaprjeđuje te ispravljaju greške.
Nakon toga dolazi kraj. Ova i slijedeće slike preuzete su sa stranice o ekstremnom
programiranju (http://www.extremeprogramming.org) autora Don Wells.

13
 Prikaz faza XP-a

Na slijedećoj slici može se vidjeti životni ciklus jedne iteracije XP tima. Iz slike je jasno vide
već od prije opisane prakse i principi.

Životni ciklus XP iteracije

14
 Životni ciklus razvoja u jednom danu

Na slijedećoj slici je prikazan jedan dan programera. Postupak je otprilike ovakav:

1. Dizajniranje rješenja
• u paru se raspravlja o mogućim rješenjima
• moguće pisanje dijagrama (UML)
2. Pisanje programerskog testa
• prvo se napišu tipični testovi koji provjeravaju funkciju koda
• zatim se pišu testovi za provjeru netipičnih slučajeva (rubni uvjeti, greške, ...)
3. Pisanje koda
• kod je gotov kada svi testovi za taj kod prođu
4. Integracija
• integracija s ostatkom koda (čitav softver)
• gotovo je onda kada svi testovi prođu

Jedan dan programera

15
Primjer
Ovaj primjer je preuzet iz knjige „Intro to agile methods“ autora Steve Hayesa i Martina
Andrewsa.

Koraci Primjer i komentari

Iteracija 0
Izrada odgovarajuće okoline
Odabir i instalacija razvojnih alata
Klijenti naprave listu priča koje očekuju
da budu implementirane u aplikaciji.
Programeri procjenjuju svaku priču
Kada je priča prevelika ili nejasna
klijent je dijeli na manje priče
Nove priče se ponovno procjenjuju Imamo 250 točaka
Tim odlučuje o dužini iteracije 1 tjedan
Određuje se početna brzina 10 točki po iteraciji
Tim određuje broj iteracija po izdanju 4 iteracije po izdanju
Klijenti grupiraju priče u izdanja. Svako Izdanje 1 je za sponzore i pokazuje
izdanje treba imati svrhu i treba proizvesti navigaciju kroz forme
kod koji nešto radi. Po potrebi se podjele Izdanje 2 doda unos podatak
na više izdanja Izdanje 3 dodaje izvještavanje
Izdanje 4 automatizirano obavještavanje o
raznim stanjima
Tim raspravlja i dogovara metafore i Ovo se može napraviti bilo gdje, ali prije prve
arhitekturu iteracije. Metafore su još nedovoljno
definirane i trebat će ih doraditi
Izdanje 1
Iteracija 1
Igra planiranja
Programeri koriste procjenu brzine 10 točki po iteraciji
iz iteracije 0
Klijenti biraju priče koje će biti
uključene u iteraciju

16
 Neke priče treba podijeliti
Nove priče se procjenjuju
Programeri pretvaraju priče u Zadaci uključuju:
praktične zadatke Raspored elemenata na zaslonu
Povezane zaslone
Testne podatke
Programeri odabiru zadatke Eksperti za sučelje (GUI) preuzimaju
odgovornost za većinu zadataka dok su ostali
spremni za rad u paru. Jedna osoba napravi
testne podatke
Razvoj
Dogovaraju se parovi i započinje s Zasada parovi uglavnom ostaju fiksni dok se
kodiranjem istražuje tehnologija i metafore
Parovi inkrementalno rade na
dizajnu, pišu testove te refaktoriraju
kod da bi promjene bile lakše, rade
promjene
Automatizirana, kontinuirana
integracija stalno se odvija
Dnevni neformalni sastanci
Izvještava se o napretku, U izvješću je rečeno da se dvije priče od po
planovima za danas i dvije točke neće stići napraviti do kraja
problemima iteracije
Tim dodjeljuje resurse da se U posebnom sastanku klijent je podijelio
ukloni prepreke i probleme svaku priču u dvije priče od jedne točke od
kojih se jedna može napraviti dok će se druga
ignorirati
Još kodiranja
Iteracija 2
Retrospektiva Klijent demonstrira završenu priču i prve
iteracije. Ovo osigurava da su svi u timu
upoznati s njenom funkcionalnošću
Svi u timu, uključujući klijenta, Klijent ističe da su neki programeri prijavili

17
 komentiraju što je dobo a što se da je priča gotova bez da su provjerili
može popraviti funkcionalnost s klijentom ili pitali korisnički
test
Tim se slaže oko stvari koje treba Tim se slaže da će se fokusirati na interakciju
popraviti u slijedećoj iteraciji s klijentom te da će o tom razmisliti u
uključujući i sam proces slijedećoj retrospektivi
Igra planiranja
Programeri koriste broj napravljenih 8 točki
točki iz prve iteracije kao brzinu
rada za drugu iteraciju
Klijent bira priče koje će se Klijent odlučuje da neće implementirati dvije
implementirati u iteraciji nedovršene točke iz prve iteracije jer nisu
toliko važne. Izabire 6 točaka i želi da se
implementira još jedna priča od 3 točke
Neke se priče moraju podijeliti te Odlučuje se da nema mjesta za cijelu priču od
ponovo procijeniti 3 točke pa se u iteraciju uključuju samo 2
Priče se pretvaraju u zadatke
Programeri odabiru zadatke Oni koji su najviše radili u prošloj, spuštaju
tempo u ovoj iteraciji
Razvoj
Dogovaraju se parovi i započinje s Parovi se često izmjenjuju svaki dan pošto su
kodiranjem naučili podijeliti rad na manje cjeline i bolje
su upoznati s metaforom
Parovi inkrementalno rade na
dizajnu, pišu testove te refaktoriraju
kod da bi promjene bile lakše, rade
promjene
Automatizirana, kontinuirana
integracija stalno se odvija
Dnevni neformalni sastanci
Izvještava se o napretku, Na sastanku tim primjećuje da treba sve više
planovima za danas i vremena za kompajliranje i jedan član se
problemima javlja da to prouči, netko se javio da to s njim

18
 odradi u paru

Na drugom sastanku jedan programer ističe

kako će završiti s obvezama prije vremena.
Ostatak tima napreduje po rasporedu
Tim dodjeljuje resurse da se Klijent odabire malu priču koja se dodaje
ukloni prepreke i probleme iteraciji
Još kodiranja
Iteracija 3 ...
Iteracija 4 Klijent uzima rezultat ove iteracije i
demonstrira je puno većoj grupi ulagača
uključujući sponzore. Daju vrlo važne
povratne informacije.

Kritike

XP je metoda u razvoju te dolazi i sa nizom ograničenja i opasnosti koje korištenje ove

metode može donijeti. Važno je za početak imati prave ljude za posao isto kao i klijenta koji
spreman na komunikaciju. Kritičari12 XP-a obično imaju ove primjedbe:
• metodologija je jedino dobra koliko i ljudi koji su uključeni. XP to ne rješava
• često se koristi da bi se izvukao novac od klijenata zbog nejasnih definicija krajnjeg
produkta
• nedostatak strukture i dokumentacije
• zahtjeva česte sastanke koje puno košta klijente
• zahtjeva puno prilagodbe od programera
• može biti neučinkovito, ako se dio koda izmjeni kroz iteracije bit će napisan više puta
ponovo
• nemoguće postaviti realne procjene potrebnog truda i vremena jer na početku nitko ne
zna cijeli opseg sustava i sve zahtjeve
• povećava rizik nekontroliranog mijenjanja opsega sustava zbog nedostatka detaljne
dokumentacije zahtjeva
12
Kritike preuzete iz: http://en.wikipedia.org/wiki/Extreme_Programming,
The dangers of extreme programing, Patrick Emery

19
 • agilne metode su orijentirane na funkcionalnosti (eng. fratures) te zanemaruju druge
kvalitete

Općenito XP ne treba primjenjivati kada postoji velik otpor toj metodologiji ili kada je
okolina nefleksibilna. Nije prikladna kada je potrebna opsežna i detaljna dokumentacija. XP
zahtjeva ritam koji je održiv i ne odgovara kada je prekovremeni rad uobičajen. Stalno se
ističe komunikacija i ne može biti primijenjeno kada ljudi ne žele ili ne mogu komunicirati
(kada su previše umišljeni ili povučeni, fizički udaljeni). XP je učinkovit u malim timovima.
Teško ga je povoditi kada se dugo čeka na povratne informacije.

20
Zaključak

Mislim da je XP vrlo dobra metoda koja je jako učinkovita u malim timovima koji su spremni
blisko surađivati i komunicirati. XP sam koristio u dva projekta i mogu reći da programiranje
u paru zna biti jako produktivno, ideje lakše dolaze, manje je opterećenje na pojedinačnu
osobu i na kraju je kod kvalitetniji.

XP treba shvatiti ozbiljno te ga treba provoditi do kraja ili nikako, nema između. Ova pravila,
vrijednosti i prakse su rezultat iskustava velikog broja programera tijekom dugog niza godina
razvoja softvera te se trebaju prikladno primijeniti. Iako je atmosfera u XP timu neformalnija
nego inače, obveze i zadatke se mora ozbiljno shvatiti.

Postoje mnoge kritike i mnogi misle da je XP daleko od idealne metode razvoja softvera, a
lista kritika nije mala. Nekako imam osjećaj da te kritike proizlaze iz neshvaćanja XP procesa
razvoja te da je većina njih rezultat neprikladnog praćenja koraka ili jednostavne primjene
XP-a na projekte za koje nije ni dizajniran. Neke kritike ipak stoje, ali mislim da će se tijekom
vremena riješiti.

Općenito je moj dojam da je ovo odlična metoda za manje projekte na kojima sam do sada
radio te da ću je u budućnosti još puno puta koristiti.

21
Literatura

Knjige i prezentacije:
• Naziv: Intro to agile methods, Autori: Steve Hayes i Martina Andrews, Izdavač:
Cretive Commons licenca (Attribution-Noncommercial), Opis: Pregled agilnih metoda
razvoja softvera s fokusom na ekstremno programiranje
• Naziv: Agilne metode razvoja programa, Autor: Mario Kušek
• Naziv: Agilne metode razvoja softvera, Autori: Ivan Padavić i Marko Velić, Izdavač:
Initium Futuri Ltd.

Internet:
• Naziv: Extreme Programming
Izvor: http://en.wikipedia.org/wiki/Extreme_Programming
• Naziv: The dangers of extreme programming
Izvor: http://members.cox.net/cobbler/XPDangers.htm#_Toc530042781
• Naziv: Agile software development
Izvor: http://en.wikipedia.org/wiki/Agile_software_development
• Naziv: Agile manifest
Izvor: http://agilemanifesto.org/
Autori: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward,
Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron
Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff
Sutherland, Dave Thomas
Izdavač: može se slobodno umnožavati, izdana 2001. godine
Opis: Ovaj manifest je temelj svih agilnih metoda u kojemu su prikazane osnovne
vrijednosti i principi agilnih metoda.
• Naziv: Agile Alliance
Izvor: http://www.agilealliance.org
Opis: Predstavlja udruženje pojedinaca i kompanija koji primjenjuju agilne metode u
svojem radu. Sadrži veliki broj članaka i informacija o svim aspektima agilnih metoda.

22