Extrémní programování v praxi

Dnes bych vás rád seznámil s úžasnou nejmenovanou 3D hrou, v níž hráč ovládá tučňáka, který klouže po břiše závodní drahou a cestou loví sledě. Poslední článek nás totiž definitivně odpoutá od mlhavých ideálů, vznešených hodnot a nekonstruktivních povzdechů z článků předchozích, pustíme se do konkrétních návodů, které nám přináší extrémní programování. Tedy vzhůru na sledě.

V předchozích článcích jsme si shrnuli rizika IT projektů, nadhodili pár myšlenek na téma kterak těmto rizikům předcházet a nakonec se seznámili se základy metodiky zvané extrémní programování. Tato metodika vychází z důrazu na čtyři základní hodnoty: komunikace, jednoduchost, zpětná vazba a odvaha. Mít základní hodnoty je jistě prima, jak ale s nimi naložit v praxi?

V diskusi pod předešlým článkem jsem tak trochu nastínil, o čem dnes bude řeč. Zároveň ale předesílám, že ani dnes se nedozvíte žádnou zázračnou metodu, jde spíše o rozvinutí výše zmíněných základních hodnot do konkrétních postupů, které mohou přinést kýžené výsledky, ale které také – jak už je to se vším – není možné násilně roubovat na všechny situace. Je tedy na laskavém čtenáři, aby tento miniseriál bral spíše jako inspiraci a aby pro extrémní postupy samotné nezapomínal na základy. Pokud vám zpětná vazba říká, že XP pro ten či onen konkrétní projekt není, asi na tom něco bude.

A pro ty ostatní je tady XP v praxi a s tím související možné…

Peripetie

Projekt se rozjel, a s ním vzniká spousta různých činností. Programátoři programují, zákazníci zakazují… Ne, takhle by to nešlo. Co že se to vlastně důležitého děje?

Numerologové a fanoušci Terryho Pratchetta zajásají. Extrémní programování nám po čtyřech hodnotách totiž postuluje další významnou čtveřici, tentokráte základních projektových činností. I tyto činnosti spolu jdou ruku v ruce a nikoho asi nepřekvapí, že se jedná o plánování, psaní zdrojového kódu a návrh. A pozorný čtenář předchozích článků si jistě domyslí, že tou čtvrtou do taroků bude testování. Projděme si nyní toto kvarteto podrobněji.

Programování

Rozhodně vám uvedením psaní zdrojového kódu na prvním místě nechci sugerovat myšlenku, že v XP můžeme bez rizika začít bezhlavým programováním. Ale přeci jen této činnosti musíme přiznat výsostné postavení. Jakkoli bez ostatních činností projekt nejspíš pohoří, bez programování jaksi ani nemá co pohořet. Navíc předpokládám, že článek beztak budou číst převážně lidé, jimž programování zaplňuje nezanedbatelnou část pracovní doby.

Podceňovaný aspekt vlastního programování spočívá v tom, že nám dává možnost komunikovat na velmi exaktní úrovni. Jednoduchý, byť rychle „spíchnutý“ prototyp může dát klientovi více informací než mnohastránková analýza. Kolegovi se sklony k sofistikovaným architektonickým řešením na fragmentu zdrojového kódu názorně ukážete rozdíl mezi složitým a jednoduchým. A kolegovi programátorovi můžete svůj bugreport velmi jasně popsat tím, že mu zašlete test, kterým jeho chybný kód neprojde.

Řekli jsme si, že dbaní na základní hodnoty XP nám přináší mnohé jistoty, o něž se můžeme opřít při překonávání rizik. Tyto hodnoty můžeme ve fázi programování rozvíjet následujícími technikami:

• Cirkulace programátorů – nenecháme si v projektu černé díry, kterým rozumí jeden jediný génius.
• Společné vlastnictví kódu – částečně vyplývá z předchozího bodu. Je nutné, aby idea sdílení znalostí nezůstala jen na papíře. Prostě si řekneme, že každý může bezostyšně sáhnout do cizího kódu.
• Dodržování standardů pro úpravu zdrojového kódu – bez toho programátoři nezvládnou luštit po sobě zdrojáky bez újmy na duševním zdraví.
• Programování ve dvojicích – postup na pohled věru extrémní. Ale podporuje sdílení znalostí a zejména vyrovnává rozdíly ve znalostech jednotlivých programátorů.
• Refaktorizace – zamotáváme-li se při rozšiřování kódu do ošetřování chyb původního návrhu, věnujme namísto toho čas (a odvahu) úpravě kódu stávajícího, která naše rozšíření usnadní. Moderní vývojová prostředí poskytují nástroje, které za nás udělají spoustu otravných činností s tím spojených.
• Častá integrace – nenechme rozdělit vývoj do izolovaných komponent, které „možná jednou nějak“ dáme dohromady. Každý programátor (či dvojice) je zodpovědný za co nejčastější integraci svého aktuálního kousku s ostatním kódem.
• Zákazník na pracovišti – co dodat a neopakovat se?

Plánování

Co obvykle plánujeme? Potřebujeme dát dohromady projektový tým, chceme upřesnit zadání a zejména priority, zajímá nás odhad nákladů a harmonogramu. Základní hodnoty XP nám dále připomenou, že bychom si měli připravit způsob, jak vyhodnocovat zpětnou vazbu. Dobrý plán by nás měl naplnit jistotou, že projekt je nastaven dobře a že jsme na nejlepší cestě jej dovést do zdárného cíle.

Oproti detailní přípravě a zdlouhavým mnohastránkovým analýzám nám XP nabízí následující postup:

1. Vytvoříme hrubý plán, který poskytne oběma stranám představu, co by bylo možné v patřičném časovém horizontu realizovat.
2. Definujeme priority, nejprve řešíme ty nejožehavější problémy.
3. V krátkých vývojových iteracích vydáváme průběžné verze produktu.
4. Spolu se zákazníkem plán průběžně aktualizujeme na základě odhadů dalších iterací, které vzhledem k jejich jednoduchosti poskytují sami programátoři. Zákazník je do vývoje co nejvíce vtažen, takže sám má šanci pozorovat změny a možná zlepšení.

Zní to hezky. Aby nezůstalo jen u toho, extrémní programování navíc navrhuje rámec pro základní i průběžné plánování, a to formou takzvané „Plánovací hry“. Jejími detailními pravidly nebudu zdržovat, můžete si je najít v pramenech na konci tohoto článku. A radši to opravdu udělejte, máte-li dojem, že pojem „hra“ do řízení projektu zavádím jen proto, že mi v úvodu zmíněný TuxRacer leze na mozek. Zjednodušeně řečeno, jde o následující postup:

1. Průzkum
   1. Klient vytvoří zadání v podobě jasných stručně formulovaných dílčích požadavků (tzv. „user stories“)
   2. Programátoři odhadnou náročnost jednotlivých úkolů v ideálních programovacích dnech (tj. bez započtení konzultací s kolegy, „rauchpauz“ a flirtování po ICQ). Tyto odhady zahrnují psaní a vyhodnocování testů.
   3. V případě složitějších požadavků je rozdělíme na podúkoly, případně naopak sloučíme triviality.
2. Závazek
   1. Klient setřídí zadání podle priority.
   2. My pro změnu setřídíme zadání podle rizikovosti (či odhadnutelnosti).
   3. Odhadneme reálnou rychlost – tj. poměr ideálních programátorských dní ke kalendářním jednotkám.
   4. Zákazník určí první úkoly k realizaci, přičemž zadává buď rozsah nebo termín, druhá hodnota se dopočítá z programátorských odhadů.
3. Řízení
   1. Vlastní vývoj probíhá v krátkých iteracích, začínáme od úkolů s nejvyšší prioritou.
      • Iterace plánujeme podobně jako celý projekt.
      • Iterace se skládá s jednotlivých drobných úloh, které by neměly přesáhnout 3 dny čistého programátorského času.
      • Na základě čistého odhadnutého času stanovíme reálný čas. Nepřepínáme. U nových členů týmu to může být třeba pětinásobek, každopádně pokud se dostáváme pod dvounásobek, riskujeme, že na pracovní vypětí doplatí komunikace.
      • Nikdy neztrácíme čas implementací funkcionalit, které nejsou na pořadu dne.
      • Zaznamenáváme pokroky, případně iniciujeme přehodnocení plánů, nastavení rychlosti apod.
      • Hlídáme si zpětnou vazbu pomocí vlastních jednotkových testů, větších s klientem naplánovaných testů funkcionalit a samozřejmě i neformální komunikací se zástupcem klienta.
   2. Na základě dosud proběhlých iteracích vyhodnocujeme správnost provedených odhadů, snažíme se poučit pro další iterace, případně upravujeme plán.
   3. Hlídáme si termíny, pokud došlo ke špatnému odhadu, ihned hlásíme a přehodnocujeme možnosti. Zjistíme-li potřebu doplnění zadání, doplníme zadání.
   4. A iterujeme a iterujeme…

Navrhování

Klíčovým pojmem je jednoduchost. Zopakuji radu z předchozího článku: „Udělejme to nejjednodušší, co ještě funguje.“ Přičemž „funguje“ znamená „projde aktuální sadou testů“. Návaznost této rady na základní hodnoty byla už naznačena v předchozím článku.

Tento přístup samozřejmě naráží na přirozené podezření. Jsme zvyklí tušit v projektu bubáky a předcházet jim. Ale kolikrát toto předcházení bylo opravdu smysluplné a kolikrát jen zbytečnou komplikací? Kolikrát nám pomohlo realizovat pozdější změnu snáze (se započtením preventivní práce) než bez nich? Určitě se to tak leckdy stalo. Ale pokud na základě oprávněné odvahy usoudíme, že později to zvládneme i bez profylaktických komplikací, nezdržujme se s nimi.

Dobrá, máme jednoduchost, jak postupovat dál? Udělejme si hrubou představu. Tam, kde tím neovlivňujeme funkčnost, nastřelme základní osvědčenou rutinní hrubou architekturu. Spokojme se s tím, že náš minisystémek komunikuje jen s tím, co je zapotřebí. Máme-li nejasnost, zkusme si ušetřit zdlouhavé teoretické diskuse naprogramováním jednoduchých příkladů pro různé varianty. Připravme testy – a programujme (disciplinovanému XP programátorovi bychom řekli pouze programujme, on s testy samozřejmě začne). A nepřidávejme žádné funkcionality předčasně.

Matka Kenta Becka, autora níže citované knížky o XP, poučila svého syna o řízení auta následovně: „Řízení není o tom, jak auto dostat do pohybu ve správném směru. Při řízení se musí stále dávat pozor, kdy je třeba upravit směr mírně na jednu stranu a pak zase na druhou.“ A s projektem je to podobné.

Testování

Proč o testování píšu až nakonec? Určitě ne proto, že by bylo natolik bezvýznamné, spíš proto, abyste na ně během tohoto dlouhého článku nestihli zapomenout. Testy jsou tím, co drží náš systém pohromadě. Testy nám dodávají důvěru, že chyby zanášené s novými změnami odhalíme co nejdříve a nebudeme programovat ve strachu, co kde zase rozvrtáme. Akceptační testy dávají exaktní náhled na funkčnost systému zákazníkovi. Trochu podrobněji o tom, co a jak testovat:

• Akceptační testy

  Tyto testy vytváříme v průběhu plánování ze zákazníkových požadavků a za účasti zákazníka. Pracujeme, jako bychom chtěli testovat černou skříňku – máme požadavky, a chceme zjistit, jestli je dotyčná skříňka splňuje. Pokud ano, výborně. Po provedení akceptačních testů můžeme požadavek považovat za vyřešený. Pochopitelně je zde vyžadována aktivní účast zákazníka na tvorbě i vyhodnocování testů, zákazník zde přijímá svůj díl zodpovědnosti. Je to možná nezvyklé, má to ale logiku. Kdo jiný může lépe poznat, jestli systém funguje, jak má, než náš zákazník, náš pán?

• Jednotkové testy

  Veškerý námi vytvořený kód musí projít jednoduchým testem specifickým pro danou úlohu. Dobře, nemusíme například u JavaBeans testovat každou get/set metodu, ale snažme se být důkladní. Testy píšeme jednoduché, abychom se nedostali do přílišného rizika, že během vývoje budeme odhadovat chyby v testech a ne v systému. A konečně se při vytváření testů nenecháme ovlivňovat stávajícím kódem, což je jen další argument pro to, abychom začali s psaním testů dříve, než se pustíme do vlastním implementace.

  Na jednotkové testy se můžeme dívat podobně, jako na testy akceptační. Jsme-li programátor vytvářející dílčí komponentu, je vedoucí týmu náš zákazník, a tudíž mu musíme být schopni prokázat, že náš kód „akceptačním“ testem prošel. S tím rozdílem, že ve své pozici máme dostatek znalostí i zodpovědnosti, abychom si svůj test zvládli napsat sami. Nebo ještě lépe s kolegou. Nezapomínejme na programování v párech.

Teď umíme plánovat, navrhovat, testovat, ba dokonce i programovat. V duchu struktury antického dramatu by po peripetii měla následovat…

Katastrofa

Ale té se přece chceme vyhnout, ne?

Katarze

„Strejda“ Google mi našel, že slovo katarze znamená „očištění od potlačených emocí“. Jak bylo vidět i v diskusi k předchozím dílům, myšlenky extrémního programování ve vás vyvolají spoustu pochybností a otázek. Bude klient ochoten postrádat svého pracovníka k tomu, aby byl našemu týmu neustále a nejlépe osobně k dispozici? Můžeme si dovolit rozptylovat programátory tím, že je necháme prostřídávat se na různých částech projektu? Nevymstí se nám podceňování budoucích nových požadavků? Neztrácíme příliš mnoho času důrazem na testování? Co teprve programování ve dvojicích, není to vyslovené plýtvání lidskými zdroji? A vůbec, co když máme stovky dalších důvodů, proč se nám XP jeví pochybným?

Osobně jsem přesvědčen, že není možné situaci lámat přes koleno a vnucovat nějaké nové postupy všude, kde nás jen napadne. Například pokud nám klient svého zástupce k dispozici nedá, přece se na projekt nevykašleme jen kvůli nějakým abstraktním zásadám. A pracujeme-li na relativně malých projektech, cítíme, že by se to klientovi opravdu vyplatit nemuselo.

V tomto miniseriálu jsem chtěl nastínit zejména některé základní myšlenky, které se vyplatí vzít v potaz. Těžko budeme něco vytýkat vytyčení základních hodnot (komunikace, jednoduchost, zpětná vazba a odvaha), zvlášť když jsme si tak hezky vysvětlili, jak se nám vzájemně doplňují. Dokonce, podíváme-li se na projekt z nového úhlu pohledu, můžeme snadno a rychle pomocí metod XP rozpoznat, kdy se pro náš projekt tato metodika příliš nehodí. Pokud nám ale nevyhovují dílčí postupy, je užitečné zvážit, nakolik se jedná o malichernost specifickou pro konkrétní prostředí, která nám v úspěšné aplikaci ducha XP nezabrání.

Vezměme si příklad napohled zcela odjinud, ze světa vývoje open source software. Mezi jednoznačně nejúspěšnější současné open source projekty patří projekt J2EE aplikačního serveru JBoss. Jeho hlavní vývojáři se k myšlenkám extrémního programování velmi silně hlásí. Co si ale pod tím máme představit? Znamená to snad, že programují ve dvojicích? To by šlo asi těžko, když je velká část vývojářů rozptýlena po celém světě. Zákazník na pracovišti? Ale kdo je zákazník a kde je pracoviště?

Přesto při bližším pohledu zjistíme, že extrémní programování není pouze prázdným sloganem. Testy vidíme na každém kroku. Našli jsme chybu? Vzniká test nový nebo je stávající test podroben revizi. Jako u většiny významných open source projektů, v uživatelské i vývojářské konferenci proudí čilá komunikace (kterou zejména v té vývojářské hlavní osoby projektu tu více tu méně citlivě, ale hlavně účelně usměrňují do co nejkonstruktivnější roviny). Sdílení kódu? Maximální možné, pokud se trochu aktivně a konstruktivně projevujete, pravděpodobně získáte práva pro zápis přímo do CVS repozitáře. Odvaha pánům bezesporu také nechybí. A především to funguje.

Takže nezbývá než popřát, ať to funguje i vám, ať už více či méně extrémně.

Odkazy a zdroje

• Kent Beck: Extrémní programování (Grada 2002) – odsud jsem si dovolil vypůjčit termín „pozorování programátorů v divočině“
• www.extremeprogramming.org

Starší komentáře ke článku

Pokud máte zájem o starší komentáře k tomuto článku, naleznete je zde.