Extrémní programování pod drobnohledem

V minulém článku na téma XP jsme uvedli čtyři základní hodnoty, které tvoří ideologický základ extrémního programování. Připomeňme, že se jedná o komunikaci, jednoduchost, zpětnou vazbu a odvahu. Zapomenout nelze ani na pátou, hlubší hodnotu – respekt.

Uvedené hodnoty tvoří základní metodologický rámec XP, nicméně ve své obecnosti nemohou stačit k vytvoření použitelné metodologie. Je tedy definováno 12 konkrétních postupů vedoucích k vytvoření kvalitního produktu pomocí XP:

• Plánovací hra: podrobný popis bude uveden později
• Malé verze: nové verze se uvolňují často a v co nejmenší konfiguraci; představují však kompletní, funkční mezikrok (jako celek dávají smysl). Četnost jejich uvolňování je závislá na velikosti výsledné aplikace: u většího systému budou samozřejmě postupné verze dodávány pomaleji než u malé aplikace.
• Metafora: veškerý vývoj je obecně veden pod taktovkou jakéhosi sdíleného příběhu. Tento příběh „vypráví“ o tom, jak má celý systém nakonec fungovat. Metafora ovšem neilustruje jen cíle, funkce a požadavky, postupně se konkretizuje a začíná nahrazovat to, co bývá nazýváno „architektura“.
• Jednoduchý návrh: systém je navrhován (a implementován) tak „štíhlý“ a jednoduchý, jak je to zrovna možné. Tážeme se vždy „co je nejmenší konfigurace, která ještě může fungovat?“ Případná komplikovanost je průběžně odstraňována zároveň s tím, jak se objevuje. Nové prvky se do návrhu vkládají až v okamžiku, kdy je to potřeba.
• Testování: testování je jedním ze základních pilířů XP. Neustále jsou psány testy jednotek, test modulu musí existovat dříve, než modul samotný. Vývoj nepokračuje, dokud test neproběhne bez chyby. Zákazníci naopak dodávají jakési testy funkcionality – tedy testy, které ověřují dokončení funkcí (nebo přesněji funkčnosti). Žádná funkce bez zautomatizovaného testu prakticky neexistuje.
• Refaktorizace: refaktorizace je přepis (změna) zdrojového kódu bez změny funkčnosti aplikace. Provádí se tak často, jak je potřeba: pro odstranění duplicit, pro zdokonalení komunikace, pro zjednodušení systému a architektury, pro zvýšení efektivity... Důležité je, že změnou struktury systému nesmí dojít ke změně chování aplikace. Pokud aplikace nefunguje, změny zdrojového kódu nelze nazvat refaktorizací: v takovém případě jsou to prostě opravy.
• Párové programování: všechen zdrojový kód píší vždy dvojice programátorů; každá dvojice sdílí jeden monitor, klávesnici a počítač. Každý pár má jakousi vnitřní strukturu: programátor, který v daném okamžiku pracuje s klávesnicí, implementuje metodu X a přemýšlí jen o nejlepším způsobu implementace právě metody X (v daném kontextu zdrojového kódu). Jeho kolega pak uvažuje více s ohledem na celkovou a globální strategii: bude celá tato architektura fungovat? Nebude zbytečně složitá, nebude neefektivní? Máme automatizovanými testy podchyceny všechny myslitelné situace? Podrobněji se nad párovým programováním zamyslíme níže.
• Společné vlastnictví: všichni mohou měnit jakékoliv místo ve zdrojovém kódu, a to kdykoliv. Tento bod znamená zvýšení potřebného koeficientu, tzv. truck faktoru, jehož hodnota 1 znamená, že každé části zdrojového textu rozumí právě jeden expert. V XP všichni přijímají odpovědnost za celý systém. Realizace tohoto bodu ovšem znamená, že tým musí mít propracované techniky konfiguračního řízení, především pak sdílení kódu a verzování, aby nedocházelo k nekonzistenci změn.
• Nepřetržitá integrace: systém je integrován (a sestavován) několikrát (nejméně však jednou) denně, když je dokončen nějaký nový úkol. XP doporučuje mít k dispozici jeden počítač vyhrazený pouze pro integraci.
• Čtyřicetihodinový pracovní týden: dlouhodobé přesčasy vedou k přetěžování lidských zdrojů a ústí v neefektivitu. Je zcela nepřípustné pracovat přesčas dva týdny za sebou. Tento bod je – zdá se – zbožným přáním snad všech vývojářů, kteří si stěžují na přetížení, stres a nedostatek času.
• Zákazník na pracovišti: součástí týmu se po dobu vývoje stává i skutečný, živý uživatel (nikoliv jeho adresa elektronické pošty), který je ideálně k dispozici na plný úvazek, aby odpovídal na otázky, spolupracoval na testech, řešil spory a určoval priority. Tento bod je opět často zmiňován odpůrci XP: zákazníci nejsou zvyklí na to, že musí vývojový tým „vodit za ruku“. V důsledku by se zákazníkovi rozhodně vyplatilo uvolnit jednoho člověka pro průběžné konzultování s vývojovým týmem, neboť by se mu dostalo produktu přesně podle jeho představ (přesněji řečeno podle představ příslušného pracovníka :)) Nemohlo by se ani stát, že po dokončení vývoje zákazník prohlásí „ale tohle jsem já přece nechtěl!“ Nicméně asi nelze skutečně očekávat, že zákazník jednoho „full-time“ pracovníka opravdu uvolní. V každém případě je však nutné snažit se o průběžné konzultování stavu vývoje se stranou zadavatele.
• Standardy pro psaní zdrojového textu: připomeňme, že zdrojový kód je hlavním nosičem „dokumentace“ ve stylu XP. Z toho plyne, že musí být psán v souladu s pevně stanovenými pravidly, které umožní komunikaci prostřednictvím zdrojového textu. Zdrojový text psaný bez pravidel (bez jakési „štábní kultury“) nemůže sloužit jako centrum dokumentace celého projektu.

Párové programování je dalším pilířem, na který často poukazují lidé, kteří XP nevěří. „Naše firma si přece nemůže dovolit platit dvojnásobek lidí,“ argumentují. To je rozhodně pravda, na druhou stranu je nutné vidět, že investice do „zdvojení“ pracovníků se do budoucna může vyplatit (navíc nelze hovořit o přesně dvojnásobném zvýšení, ve skutečnosti bude podstatně nižší). Nejedná se jen o to, že zdrojový kód bude jednodušší, efektivnější, přímočařejší (programátor má obvykle radost, když najde chybu ve zdrojovém kódu svého kolegy, lze proto právem očekávat, že programátoři budou „soupeřit“ v tom, aby všechny chyby byly odhaleny). Nesmírnou devizou je především skutečnost, že ztrátou jednoho člověka nevznikne žádná krize – příslušný úsek zdrojového kódu zná řada dalších lidí.

Nejcennější by však mohlo být rychlé tempo učení. Pokud pracují dva programátoři společně, mohou se od sebe navzájem učit. Podmínkou je samozřejmě citlivé poskládání dvojic: budou-li spolu dva lidé stejných znalostí a schopností, nenaučí se od sebe nic, na druhou stranu přílišný rozdíl v úrovni také nemůže dlouhodobě fungovat. V tomto bodě (více než kde jinde) záleží na volbě osobnostních typů: mnozí programátoři mohou být frustrováni z toho, že musí předávat své těžce nabyté vědomosti někomu druhému (když mě pak může připravit o místo, že?!).

Praktické činnosti v XP

Tolik k jednotlivým pilířům XP. Nyní se pojďme stručně podívat na čtyři zásadní činnosti, které XP tým provádí nejčastěji (prakticky nepřetržitě):

• Testování: probíhá průběžně, nelze integrovat žádný modul bez toho, aby uspěl v automatizovaném testu. Test modulu se programuje ještě před vlastním modulem; po následné implementaci modulu dojde k nasazení testu. Test je pak spouštěn opakovaně v rámci integrace i při případných změnách modulu. Testy jsou izolované (neovlivňují jiné testy) a automatické (poskytují nezávislý, neovlivněný výsledek).
• Psaní zdrojového kódu: zdrojový text je cílem, ale i metodou XP. Psaní zdrojového kódu začne bezprostředně po napsání příslušných testů.
• Poslouchání: vývojáři musí naslouchat zákazníkům i svým kolegům, aby věděli, co vůbec mají implementovat. Nestačí spolehnout se na spontánní fungování: poslouchání i komunikace musí být strukturované, v některých případech dokonce jemně řízené.
• Navrhování: návrh představuje i v XP jediný způsob, jak se vyhnout cestě do slepé uličky, z níž již v určitém okamžiku není efektivní cesta zpět. Návrh je vytvářením struktury, která organizuje logiku v systému. Dobrý návrh uspořádá logiku tak, že změna v jedné části systému nevyžaduje pokaždé změny v ostatních částech. Návrh je, stejně jako programování, testování a poslouchání, každodenní (povinnou) náplní práce všech programátorů XP. Navrhování není možností, ale nutností.

Posloupnost kroků a fází

V rámci XP není exaktně definována posloupnost fází, kterou musí projít každý projekt. XP tvrdí: vývoj softwaru je vždy rozvíjející se dialog mezi možným a žádoucím. Přirozenou vlastností dialogu je, že mění to, co je viděno jako možné, i to, co je viděno jako žádoucí.

Jako důsledek tohoto přesvědčení definuje XP zvláštní postup určený k plánování projektu, k rozhodování o náplni iterací a vývojových fází: tzv. plánovací hru. XP uvádí, že plánovací hry se musí účastnit jak obchodníci, kteří rozhodují o šíři zadání, prioritách, skládání verzí a datech jejich uvolnění, tak i technici, kteří se na rozhodování podílejí v oblasti odhadů, důsledků (např. technické důsledky volby konkrétní databáze), procesu (tým se částečně samoorganizuje) a podrobného harmonogramu.

XP doporučuje, aby se v samém úvodu projektu vytvořil velmi stručný, hrubý a jednoduchý plán, podle něhož by vývoj probíhal a který by se průběžně aktualizoval. Existuje-li tento hrubý plán (jehož tvorba by neměla obecně trvat déle než několik málo hodin), je možné přistoupit k podrobnějšímu průzkumu situace, k analýze zákazníka a jeho potřeb a k přesnějšímu vyjádření prvotních představ. Tyto představy a požadavky se následně promítnou do plánu verze. Tento plán zahrnuje šíři zadání pro aktuální verzi (dodávku), umožňuje sestavit tým, odhadnout náklady a harmonogram a dát všem zúčastněným jistotu, že verze bude dokončena. Plány verzí vznikají procesem, který Kent Beck nazývá plánovací hra (The Planning Game). Této „hry“ se účastní vedení týmu i vývojáři, přičemž do skupiny vedení jsou zahrnuti i zákazníci. Plánovací hra spočívá v tvorbě tzv. karet zadání, které se stávají základními nosiči informace o požadovaných funkcionalitách. Plánovací hra se skládá ze tří fází:

• průzkum: zjištění, jaké nové věci by mohl systém dělat. Vedení napíše zadání ve formě tzv. uživatelských příběhů (User Stories), vývoj odhadne náročnost a dobu implementace.
• závazek: rozhodnutí, jaká podmnožina všech požadavků se bude dále sledovat. Vedení zvolí šíři zadání a datum uvolnění verze, vývoj se zaváže k jejímu vyvinutí. V této fázi probíhá klasifikace zadání podle důležitosti, rizika a hodnoty; fáze je završena vytvořením a vyčleněním karet zadání, které se budou realizovat.
• řízení: vedení vývoje podle toho, jak skutečnost formuje existující plán. Fáze sestává z plánování iterací (viz dále) a z případných úprav plánu podle průběhu vývoje.

V XP existuje ještě jeden, nejpodrobnější druh plánování: iterační plánovací hra. V jejím rámci se aplikují téměř tatáž pravidla, jako ve výše uvedené plánovací hře. Rozdíl spočívá v záběru obou her: zatímco plánovací hra plánuje náplň tvorby nové verze (typicky tři týdny až dva měsíce), iterační plánovací hra specifikuje náplň jedné iterace (typicky jeden až tři týdny). Na rozdíl od karet zadání, které jsou tvořeny při plánovací hře, je produktem iterační plánovací hry množina tzv. úkolových karet. Úkolové karty jsou konkrétnější než karty zadání; úkolová karta může mít souvislost s jednou nebo více kartami zadání (ale nemusí, např. migrace na novou verzi vývojového prostředí). Hry se aktivně účastní všichni členové týmu. Kent Beck dodává, že ve velmi malých týmech (např. dva programátoři) lze iterační plánování vypustit; při týmech čítajících deset členů je však nutné.

Formální náležitosti a dokumenty

XP má velmi neortodoxní vztah k formalitám a k dokumentům. V průběhu celého životního cyklu nedefinuje XP žádné dokumenty, žádné mezníky, žádné kontrolní body. XP je postaveno na přímé komunikaci, která probíhá nad zdrojovým textem. V průběhu vývoje se nutně objevují pouze následující nosiče psaného textu:

• uživatelské příběhy a z nich vzniklé karty zadání – nosiče zadání; nahrazují specifikaci požadavků,
• úkolové karty – konkrétní popis úkolů pro zprovoznění jednotlivých funkcí,
• nástěnka visící na pracovišti, na níž mohou být nakresleny nejdůležitější body architektury, zapsány poznámky a vzkazy,
• smlouvy se zákazníky podle používaného obchodního modelu.

Volitelně je samozřejmě možné vypracovat více dokumentů (písemné plány, schémata architektury a modely apod.). XP nechává týmu volnost v určení toho, které písemnosti považuje za důležité.

Na závěr

Tolik pro dnešek k XP. Zbývá ještě několik témat, která shrneme v posledním pokračování této „XP ságy“. Kromě jiného si konečně ukážeme, jak například může vypadat konkrétní vývojový cyklus probíhající podle zásad XP.