eXtreme Programming - Agile hópurinn

Á þessari síðu er farið yfir helstu þætti eXtreme Programming (XP) aðferðafræðinnar og við hvaða aðstæður hún getur helst nýst í hugbúnaðarþróun.

-Hlöðver Tómasson, 2005

Hvað er XP?

XP aðferðafræðin var útbúin til að mæta þeirri þörf í hugbúnaðarþróun að kröfur geta breyst títt. Oftar en ekki hefur sá sem er að biðja um hugbúnaðinn ekki alveg nógu nákvæma mynd af því sem kerfið á að gera en með tilkomu eXtreme Programming er nú hægt að útbúa hugbúnað þar sem hreinlega er búist við því að virknin eigi eftir að breytast reglulega. Þannig eru síbreytilegar kröfur loks orðnar viðurkenndar sem hluti af þróunarferli hugbúnaðar og eitt af markmiðum XP er þá að undirbúa forritara fyrir breytilegar aðstæður, jafnvel seint í þróunarferlinu.

Tilgangur XP er einnig að taka fast á áhættuþáttum sem fylgja verkefnum. Ef viðskiptavinur þarfnast t.d. kerfis innan ákveðinnar dagsetningar þá er áhættumat verkefnisins mjög hátt og ef kerfið er að mestu leyti nýtt fyrir teymið þá er áhættan enn meiri. XP er uppbyggt til að draga úr áhættu með ákveðnum aðferðum og reglum til að auka líkur á árangri. Eitt af aðalmarkmiðum XP er að afhenda nákvæmlega þann hugbúnað sem viðskiptavinurinn þarfnast, þegar hann þarfnast hans.

Extreme Programming er vel skilgreind og öguð aðferðafræði við að þróa hugbúnað, þvert á það sem efasemdarmenn halda. Hún kemur úr Smalltalk heiminum, nánar tiltekið smiðju Kent Beck, Ward Cunningham og Ron Jeffries. Á tímabilinu sem aðferðafræðin var í mótun unnu höfundarnir saman að fjölda verkefna og söfnuðu hugmyndum um hvernig hentugast væri að þróa hugbúnað í umhverfi þar sem kröfur eru síbreytilegar. Árið 1999 skrifaði aðalsprauta tríósins, Kent Beck, fyrstu bókina um efnið sem kallast Extreme Programming Explained: Embrace Change (önnur útgáfa kom út 2004 og er hún talsvert endurbætt).

Aðferðin er ein af "léttvægu/kviku" aðferðunum sem rutt hafa sér til rúms í hugbúnaðarþróun síðastliðin ár. Aðferðin er ekki sammála fyrirrennurum sínum að það borgi sig að hanna og brjóta hugbúnað upp í smáar einingar í upphafi ferlisins. Líkt og aðrar Agile aðferðir leggur XP mikið upp úr þátttöku viðskiptavina og nánu samstarfi allra aðila innan þróunarteymisins. Verkefnastjórar, forritarar og viðskiptavinir eru allir hluti af skilgreindu teymi sem hefur það eina markmið að útbúa hágæðahugbúnað. Aðferðafræðin hefur komið vel út því vegna þess hve mikið hún leggur áherslu á ánægju viðskiptavinarins.

Grunnhugmyndin er að byrja einfalt og smíða eitthvað sem virkar, en með takmörkunum þó. Notkunarsögur sem viðskiptavinurinn hefur útbúið eru hannaðar og smíðaðar ein af öðrum og sífellt er endurþáttað (e. Refactoring) til að betrumbæta hönnunina, frekar heldur en að eyða of miklum tíma við hönnun í upphafi. Í stað þess að útbúa ítarlegar hönnunarútlistanir, þá skrifa forritarar próf, kóða, greina og hanna eftir því sem þurfa þykir. Sífellt er verið að samþætta kóða eftir því sem verkefnið líður áfram.

Það má einnig nefna að XP er samfélag fólks sem lætur sér hugbúnaðargerð varða. Fjölmargar bækur og greinar hafa verið skrifaðar um efnið og auðvelt að nálgast aðstoð hjá hinum ýmsu umræðugrúppum, þar sem frammámenn innan greinarinnar eru duglegir að senda inn vangaveltur og svör (t.d. http://groups.yahoo.com/group/extremeprogramming/). Eins eru ráðstefnur haldnar reglulega þar sem menn hittast og ræða saman um þróunina í XP og hugbúnaðargerð (t.d. http://www.xp2006.org/)

XP aðferðafræðin beinist að því að taka, á einfaldan og skilgreindan máta, á þeim skorðum og hömlum sem upp geta komið við þróun hugbúnaðar, þ.e. tæknilegum og mannlegum hlutum en tekur ekki á fjárhagslegum eða markaðslegum atriðum er varða verkefni. Aðferðafræðin tekur þó eitthvað á slíkum atriðum þegar það á við, en beinir annars almennt ekki athygli sinni náið að þeim. Aðferðafræði er ,,samansafn reglna sem ber að fylgja til að tryggja árangur" og þær virka ekki eins og forrit því fólk starfar ekki eins og tölvur. Hvert einasta teymi stundar XP á mismunandi máta og með mismunandi árangri.
Flest hver hugbúnaðarhús á Íslandi hafa á að skipa smáum teymum þar sem forritarar vinna náið saman með viðskiptavinum. Mörg af þeim hafa verið að nota Agile aðferðir í gegnum tíðina, löngu áður en Agile hugtakið varð áberandi í hugbúnaðarumfjölluninni. Íslendingar hafa þróað nothæfan hugbúnað í gegnum tíðina án ítarlegra og niðurnjörvaða ferla og án vandkvæða. Margar af þeim góðu venjum sem Agile hugbúnaðarþróun og XP hafa sett í öndvegi eru almennt ekki notaðar hér á Íslandi. Má þar nefna hluti eins og sjálfvirkar einingaprófanir og stöðuga þróun. Ef það er eitthvað sem við mælum með að teymi taki upp þá eru það einmitt þessi tvö atriði. Stuttar ítranir er líka eitthvað sem hefur gefið gríðarlega góða raun í samskiptum forritara og kúnna og vert fyrir teymi að prófa. Code-and-Fix þróun er allt of ríkjandi í íslenskum hugbúnaðarhúsum og rúm til bætingar víða og óhætt að mæla með að slík hús kynni sér skilgreint Agile ferli eins og Extreme Programming. Frést hefur af teymum á Íslandi hafa verið að prófa sig áfram með Agile aðferðir og með góðum árangri. Þau hjá AppliCon, nota t.d. Scrum og XP saman þar sem Scrum fókusar á verkefnisstýringu en XP á forritunina.

Uppbyggingin

Eins og aðrar Agile aðferðir þá leggur XP megináherslu á lokaniðurstöðu þróunarinnar og hvernig það kerfi nýtist sem best tilætluðu viðskiptaumhverfi. Til þess er notast við stuttar ítranir þar sem stöðugt er verið að prófa, þróa og endurmeta kerfið.

Aðferðin leggur megináherslu á hugtökin einfaldleiki, samskipti, svörun, hugrekki og virðing, sem nefnd eru XP-gildin. Það er metnaður hvers XP forritara að hafa alla hönnun og útfærslu einfalda og tæra. Þeir leggja mikið upp úr reglulegum samskiptum bæði sín á milli og við kúnnann. Þeir fá góða svörun með því að byrja að prófa hugbúnaðinn strax. Þeir afhenda virk kerfi eða kerfisbúta til viðskiptavinarins eins snemma og mögulegt er og útfæra svo þær breytingar sem kúnninn fer fram á. Með XP aðferðafræðinni öðlast forritarar hugrekki til að bregðast við breytingum sem geta orðið á kröfum og tækni, jafnvel seint í þróunarferlinu. Til að komast frá þessum heimspekilegu gildum yfir í praktík er XP gildunum skipt upp í einfaldar meginreglur og nánar í verklagsreglur. Þessar reglur lýsa á einfaldan hátt öllu sem tengist XP. Atriðunum er skipt niður í einfalda flokka; Áætlanagerð, prófanir, hönnun og kóðun. Margar verklagsreglurnar eru gamlar og góðar aðferðir sem ekki eru alltaf nefndar sérstaklega eða gert hátt undir höfði í öðrum ferlum. Meginreglurnar mynda nokkurskonar brú á milli gildanna og verklagsreglnanna og saman myndar þetta allt eina heild til að uppfylla markmið gildanna. Grundvallarreglur Agile forritunarþróunar eru hafðar að leiðarljósi við uppbyggingu XP. Eins og t.d. að hafa einfaldleikann í fyrirrúmi sem er sú list að ,,hámarka það vinnuframlag sem ekki er unnið".

Helstu þættir/hugtök XP eru eftirfarandi:

Áætlanagerð - Áætlanagerð er mikilvægur þáttur í XP. Með því að samþykkja það að kröfur geti breyst títt, þá þarf stöðugt að endurmeta áætlunina og upplýsa aðila um stöðuna.
Notkunarsögur - Kúnninn sem er sérfræðingur í viðskiptavandamálinu útbýr notkunarsögur fyrir vandamálin sem hann vill láta leysa. Hugbúnaðarsérfræðingur getur aðstoðað við sögugerðina. Hver notkunarsaga á aðeins að taka fáeina daga fyrir forritara að útfæra.
Ítrun - Ítrun stendur yfir í fáeinar vikur. Kúnninn forgangsraðar notkunarsögum og velur hverjar þeirra hann vill láta útfæra í hverri ítrun.
Útgáfustjórnun - Kúnninn ákveður minnstu mögulegar útgáfur sem hafa eitthvert viðskiptalegt gildi og hægt er að setja í notkun sem fyrst.
Einingaprófanir - Forritarar skrifa einingaprófanir fyrir allan kóða hvort heldur sem það er fyrir viðskipta-, gagna- eða viðmótslagið.
Virkniprófanir - Fyrir hverja sögu eru skrifuð (sjálfvirk) virknipróf sem sýna kúnnanum fram á að kóðinn sem útfærir söguna virki. (FitNesse tólið hefur reynst vinsælt í utanumhaldi virkniprófa)
Stöðug þróun* (e. Continuous Integration) - Eftir hverja ítrun er til kerfi þar sem þau atriði sem voru þróuð innan ítrunarinnar eru tilbúin til keyrslu. Öll einingapróf og þau virknipróf sem hægt er að keyra stöðugt eru keyrð oft á dag. Öll próf verða að keyra, alltaf. (CruiseControl hefur reynst vinsælt í utanumhaldi fyrir stöðuga þróun)
Endurþáttun (e. Refactoring) - Stöðugt er verið að endurmeta og endurþátta kerfið til að bæta hönnun þess. Það sem er flókið er reynt að einfalda og kerfinu haldið í sveigjanlegu ástandi þar sem þess er þörf til að auðvelda viðhald og viðbætur á kerfinu í framtíðinni.

Það sem er sérstaklega áhugavert við XP er hin ríka áhersla á prófanir. Prófin eru gerð að grunnþætti þróunarvinnunnar þar sem forritarar skrifa prófin á undan sjálfum kóðanum. TDD (Test Driven Development) aðferðin er orðin vinsæl í hönnun og þróun hugbúnaðar hjá forriturum og öflugt samfélag í þeim fræðum má finna hér. Prófin eru hluti af ,,stöðugri þróun" sem leiðir til öflugs grunns fyrir viðhald og frekari þróun kerfisins. Oft getur verið erfitt að prófa ákveðna hluti en þá þarf frekar að beita hugvitssemi á slík sértilfelli heldur en að sleppa því að útbúa sjálfvirkt próf. Í einhverjum tilfellum þarf að breyta hönnun hugbúnaðar til að auðvelda prófun. Allt er hægt ef viljinn er bara fyrir hendi. Margar reglur úr Testing og Coding reglum XP eru góðar venjur þótt XP sé ekki ferlið sem er fylgt. Þá er átt við að allur kóði skuli vera einingaprófaður og öll próf verði að keyra áður en hugbúnaðurinn er gefinn út.

XP teymi inniheldur ekki aðeins forritarana, heldur líka verkefnastjóra og viðskiptavini, sem allir vinna nálægt hver öðrum, spyrjandi spurninga, ákvarða umfang og tímaáætlanir. Að útbúa virknipróf krefst meira en þess að forritarinn sé bara viðriðinn þróunina.

Í XP er réttur viðskiptavinarins sá að hann geti tekið þær viðskiptalegur ákvarðanir er varða hugbúnaðargerðina. Hann getur breytt umfangi verkefnins og haft þannig áhrif á dagsetningar. Hann getur hætt frekari þróun á hverjum tíma og er á þeirri stundu með keyrandi kerfi sem endurspeglar fjárfestingu hans hingað til.

Er XP fyrir alla?

XP hentar alls ekki öllum verkefnum, hvað þá öllum teymum. Í hefðbundnum hugbúnaðarhúsum hér á Íslandi hentar XP líklega vel því meðlimir teyma eru oftast tiltölulega fáir og staðsettir nálægt hver öðrum. Algengasta aðferðin í gegnum tíðina hefur verið ,,Code-and-Fix" með misjöfnum árangri. Slík teymi hagnast strax á innleiðingu agaðra vinnuferla. Teymum hefur þótt þægilegra að innleiða léttvæg Agile aðferðir heldur en þyngri og viðameiri ferla. Það eru meiri líkur á því að fólk taki upp og tileinki sér einfalda ferla fljótt og örugglega þegar það er ekki vant því að vinna samkvæmt ferlum. Ef menn hafa sannfærst um að góð leið til að þróa hugbúnað sé með Agile aðferðum þá er alls ekki galið að kynna sér hvað XP hefur upp á að bjóða.
Þegar XP lýst í upphafi var því ætlað fyrir smá teymi, í kringum 10 manns, en sú tala hækkaði fljótlega eftir að menn sem höfðu náð góðum árangri í smáu teymunum fóru að beita henni á enn stærri verkefni. Martin Fowler segir t.d. á heimasíðu sinni að þeir hjá ThoughtWorks, sem hafa verið leiðandi fyrirtæki í þróun hugbúnaðar með Agile aðferðum, hafi beitt XP í verkefnum með allt að 100 manns á mismundandi stöðum í heiminum.

Það er að fjölmörgu að huga áður en menn ákveða að gerast Agile og taka upp nýja aðferðafræði. Það er ennfremur langt frá því að vera sársaukalaust að taka upp nýtt hugbúnaðarferli og alls engin silfurkúla. Menn verða að vera algjörlega sammála um hvert þeir vilji stefna með upptöku nýs ferlis og ekki stökkva bara til og senda út tölvupóst til starfsfélaga sinna og segja að hér eftir skuli notast við Extreme Programming.

XP er fyrir þá sem er ekki ánægðir með eldra ferli. Það er engin ástæða til að breyta góðu ferli sem virkar. XP og Agile aðferðafræðir almennt eru hins vegar uppfullar af góðum venjum sem hægt er að innleiða í eldra ferli til að betrumbæta það án þess þó að taka upp XP. Það er þó mælt með því að ganga alla leið ef menn eru komnir með um helming af XP aðferðafræðinni í gagnið.

Það veltur í raun og veru langmest á fólkinu sjálfu sem myndar teymið hvort XP henti því. Það á alls ekki að reyna að troða Agile aðferðafræði upp á fólk sem ekki er opið fyrir því. Ef viðskiptavinur er ekki tilbúinn að beita aðferðafræðinni þá verður að finna aðrar leiðir.

Hvar er best að byrja?

Líkt og gildir um alla tækni þá er alltaf besta leiðin að prófa sig sjálfur áfram. Langbesta leiðin til að læra um XP aðferðafræðina og meta hvort hún henti tilteknu teymi er að beita henni á ,,næsta" verkefni sem til þess hentar. Aðferðin byggir á samvinnu fólks og því verða allir sem koma að verkefninu að vera samþykkir hinu nýja ferli og upplýstir um hlutverk sitt. Þátttaka viðskiptavinanna er afar mikilvæg og verður að kynna vel fyrir þeim hlutverk þeirra og ávinning þess í Agile hugbúnaðarþróun.

Bókin hans Kent Beck er líklega besti staðurinn til að viða að sér fróðleik um aðferðafræðina. Fáeinar ágætis síður sem vert er að skoða eru eftirfarandi:

http://www.extremeprogramming.org/ (Aðalsíðan sem útlistar markmið og uppbyggingu XP. Leiðarvísirinn er sérstaklega gagnlegur.)
http://www.xprogramming.com/ (Síða Ron Jeffries sem er einn af höfundum XP)
http://www.xp123.com/ (Síða William C. Wake, sem hefur ritað mikið efni um hugbúnaðargerð og XP)
http://www.xpdeveloper.net/xpdwiki/Wiki.jsp?page=FrontPage (Bresk XP wiki síða)
http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap (wiki leiðarvísir)
Svo má benda XP póstlistann sem er öflugur umræðuhópur fyrir XP. Það er líka alltaf gott að ræða við einhvern sem þekkir til efnisins og þú veist að er að beita XP eða öðrum Agile aðferðum. Þegar menn eru að feta sín fyrstu skref þá er alltaf hætta á því að gera einhver mistök. Það er því alltaf gott að ræða við einhvern sem hefur farið í gegnum ferlið og getur forðað þér frá því að gera sömu mistök og hann gerði og þannig flýtt fyrir árangri innleiðingar þinnar.

Engin tvö teymi er með nákvæmlega eins hugbúnaðarferli, þrátt fyrir að styðjast jafnvel við sömu aðferðafræði. Það sem mestu máli skiptir er að endurmeta ferlið reglulega og spyrja sig hvað sé það sem virki vel og hvað ekki. Ef einhverjir þættir aðferðafræðinnar er ekki að virka eins og skyldi þá er málið að breyta til. Á síðunni ,,Fairly Good Practices" eru týnd til ýmis atriði sem hafa virkað vel í XP og hvernig hægt er að leysa ýmis vandamál sem geta komið upp í ferlinu.

Frábært efni um notandasögur og áætlanagerð eru bækurnar User Stories Applied og Agile Estimating and Planning eftir Mike Cohn. Bækurnar eru góð blanda af fræðum og praktík.

Ekki gefast upp! Að breyta og bæta hugbúnaðarferli fyrirtækis er ekki einfalt. Hvað þá að innleiða nýtt. Mjög mikilvægt er að menn gefist ekki upp ef þeir sjá ekki umsvifalaust haginn í nýju aðferðunum. Nokkurra mánaða prófunartími er síst of mikið til að vega og meta kostina. Ef fyrirtæki eða teymið er ekki vant ferlum og hefur að mestu leyti verið að stunda Code-and-Fix, þá er líklega best að innleiða góðar Agile eða XP venjur smátt og smátt í stað þess að ætla að gera sér of mikið. Best er að taka fyrst upp þau atriði sem auðvelt er að innleiða og mönnum þykir nær nær öruggt að gefi góða raun strax. Þegar menn eru komnir á góðan stað með ferlið þá skal ekki hætta heldur fara alla leið og nota alla þætti Extreme Programming.

Ert þú í Agile hópnum?

Við í Agile hópnum viljum gjarnan fræðast um hvort þú eða þitt fyrirtæki er að beita Extreme Programming eða einhverjum hlutum aðferðafræðinnar. Sendu okkur endilega línu á agile@agile.is ef þitt teymi er að nota XP eða einhverja þætti þess, eða bara hvað sem þér liggur á hjarta varðandi Agile hugbúnaðarþróun. Margir í Agile hópnum eru ekki einungis áhugamenn um Agile aðferðafræðir heldur eru að nota þær í sinni vinnu eða rannsóknum. Agile hópurinn hittist reglulega til að ræða um Agile málefni sem okkur eru hugleikin. Þú getur sent okkur póst á áðurnefnt netfang eða skoðað fréttagrúppuna okkar á http://groups.yahoo.com/group/agileis fyrir frekari upplýsingar.