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.

2

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

3

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.

4

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

5

• 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.

6

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.

7

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

8

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

9

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

10

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

11

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

12

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

13

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.

14

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

15

Ž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

16

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 treba imati svrhu i treba proizvesti

kod koji nešto radi. Po potrebi se podjele

na više izdanja

Izdanje 1 je za sponzore i pokazuje

navigaciju kroz forme

Izdanje 2 doda unos podatak

Izdanje 3 dodaje izvještavanje

Izdanje 4 automatizirano obavještavanje o

raznim stanjima

Tim raspravlja i dogovara metafore i

arhitekturu

Ovo se može napraviti bilo gdje, ali prije prve

iteracije. Metafore su još nedovoljno

definirane i trebat će ih doraditi

Izdanje 1

Iteracija 1

Igra planiranja

Programeri koriste procjenu brzine

iz iteracije 0

10 točki po iteraciji

Klijenti biraju priče koje će biti

uključene u iteraciju

17

Neke priče treba podijeliti

Nove priče se procjenjuju

Programeri pretvaraju priče u

praktične zadatke

Zadaci uključuju:

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

kodiranjem

Zasada parovi uglavnom ostaju fiksni dok se

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,

planovima za danas i

problemima

U izvješću je rečeno da se dvije priče od po

dvije točke neće stići napraviti do kraja

iteracije

Tim dodjeljuje resurse da se

ukloni prepreke i probleme

U posebnom sastanku klijent je podijelio

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

18

komentiraju što je dobo a što se

može popraviti

da je priča gotova bez da su provjerili

funkcionalnost s klijentom ili pitali korisnički

test

Tim se slaže oko stvari koje treba

popraviti u slijedećoj iteraciji

uključujući i sam proces

Tim se slaže da će se fokusirati na interakciju

s klijentom te da će o tom razmisliti u

slijedećoj retrospektivi

Igra planiranja

Programeri koriste broj napravljenih

točki iz prve iteracije kao brzinu

rada za drugu iteraciju

8 točki

Klijent bira priče koje će se

implementirati u iteraciji

Klijent odlučuje da neće implementirati dvije

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

ponovo procijeniti

Odlučuje se da nema mjesta za cijelu priču od

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

kodiranjem

Parovi se često izmjenjuju svaki dan pošto su

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,

planovima za danas i

problemima

Na sastanku tim primjećuje da treba sve više

vremena za kompajliranje i jedan član se

javlja da to prouči, netko se javio da to s njim

19

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

ukloni prepreke i probleme

Klijent odabire malu priču koja se dodaje

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

20

• 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.

21

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.

22

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.