V předchozích článcích na téma softwarového inženýrství jsme se zabývali hnutím agilního vývoje softwaru a představili jsme si myšlenky agilního manifestu, což je základní referenční dokument příznivců nového přístupu k programování.
Principy uvedené v agilním manifestu se hezky čtou, ale neodpovídají na základní otázku – jak provádět agilní vývoj v praxi?
Agilní hnutí je pouze zastřešujícím seskupením, ale samo o sobě žádné nové metodologie nepřináší. Konkrétní metodologie vznikají na popud nejrůznějších lidí, často signatářů manifestu. Jedním z nejznámějších zástupců agilních metodologií je extrémní programování, které vzešlo z hlavy Kenta Becka.
Co je extrémní programování?
Extrémní programování (XP) je metodologie vhodná pro malé až střední týmy (2 až 10 programátorů), které se při vývoji musí vyrovnat s rychle se měnícím nebo nejasným zadáním. Základním filozofickým východiskem extrémního programování je přesvědčení, že jediným exaktním, jednoznačným, změřitelným, ověřitelným a nezpochybnitelným zdrojem informací je zdrojový kód.
Vznik a vývoj metodologie
Vznik XP se datuje do roku 1999, kdy Kent Beck poprvé představil jeho základní myšlenky. O tři roky dříve začal Beck pracovat ve společnosti Chrysler Corp. na projektu souvisejícím se mzdami, nicméně ani po roce nebyl systém úspěšně implementován. Beck poznal, že hlavní příčinou neúspěchu byl nesprávný vývojový proces, který byl příliš zkostnatělý a nedokázal reflektovat řadu průběžných změn. Beck měl již z dřívějška zkušenosti z několika vývojových týmů a poznal více metodologií; začal tedy pracovat na návrhu metodologie, která by měla umožnit flexibilnější a přizpůsobivější vývojový proces. V roce 1999 v rozhovoru pro magazín C++ definoval poprvé základní myšlenky XP.
Obecný popis
XP je označován jako lehký, účinný, nepříliš rizikový, pružný, předvídatelný, vědecký a zábavný způsob, jak vyvíjet software. Autor, Kent Beck, ve své knize Extrémní programování uvádí, že některým lidem se XP po právu jeví jako střízlivé a praktické uvažování. Klade tedy otázku, proč má ve svém názvu slovo „extrémní“? Zároveň přináší odpověď: je tomu tak proto, že XP využívá běžně známé principy a postupy, které dotahuje do extrémů:
- Pokud se osvědčují revize zdrojového textu, budeme jej neustále revidovat (tato myšlenka vede k tezi párového programování).
- Jestliže se osvědčuje testování, budou všichni neustále testovat (testování jednotek) a testovat budou dokonce i zákazníci (testování funkcionality).
- Osvědčuje-li se návrh, zařadíme jej každodenně do činností všech (refaktorizace).
- Pokud se osvědčuje jednoduchost, vždy ponecháme systém s nejjednodušším návrhem vyhovujícím požadovaným funkcím (to nejjednodušší, co ještě může fungovat).
- Jsme-li přesvědčení o důležitosti architektury, budou ji všichni neustále definovat a propracovávat (metafora).
- Jestliže se přesvědčíme o důležitosti testování integrace, budeme integrovat a testovat několikrát denně (nepřetržitá integrace).
- Pokud se osvědčují krátké iterace, uděláme je opravdu krátké: vteřiny, minuty a hodiny namísto týdnů, měsíců a let (plánovací hra).
Při tom všem slibuje XP snížení projektových rizik, zlepšení schopnosti reagovat na změny a vylepšování produktivity během celého životního cyklu systému.
XP mírně modifikuje tři tradiční proměnné, které vystupují ve vývojovém cyklu (viz následující obrázek, který jsme již uváděli v jednom z předchozích článků), a navíc představuje unikátní čtvrtou proměnou, na níž zároveň klade největší důraz. XP tedy pracuje se čtyřmi proměnnými:
- kvalita (odpovídá funkcionalitě v obrázku)
- čas
- náklady (odpovídá zdrojům v obrázku)
- šíře zadání (nová proměnná, kterou XP přidává k tradičním třem).
Důležitý axiom XP zní: vnější síly (zákazníci, manažeři) mají možnost vybrat hodnoty libovolných tří proměnných; vývojový tým pak vybere výslednou hodnotu čtvrté proměnné. XP si je vědomo, že manažeři či zákazníci mají často snahu stanovit hodnoty všech čtyř proměnných; výsledkem tohoto jevu je obvykle drastické snížení kvality. Pokud bude všem zainteresovaným od počátku zřejmé, které čtyři proměnné jsou ve hře, dokáží zvolit a nastavit tři. Nebudou-li pak spokojeni s implikovanou hodnotou čtvrté proměnné, mohou změnit „vstupní hodnoty“, případně nadefinovat hodnoty jiných tří vstupních proměnných.
A jaký je význam šíře zadání? Tím, že se nebudeme snažit dodat příliš mnoho, zachováme schopnost produkovat požadovanou kvalitu při stanovených nákladech včas. Stanoví-li si zákazník přesné časové, kvalitativní a nákladové požadavky, je nutné, aby seřadil požadavky podle priority a byl připraven na to, že v první dodávce nedostane všechny požadované funkce, ale jen ty s vyšší prioritou.
Klíčové pojmy
Mezi nejdůležitější pojmy XP patří čtyři hodnoty, kterými se řídí a na kterých staví:
- Komunikace: příčinu potíží v projektu obvykle odhalíme u někoho, kdo nemluví s druhým o něčem důležitém. Ke špatné komunikaci však obvykle nedochází náhodou (trest jako reakce na špatnou zprávu apod.). XP se zaměřuje na udržení řádných komunikačních toků tím, že využívá mnoho postupů, které nelze bez komunikace provádět (např. testování jednotek, párové programování, odhadování úkolů...). XP dále definuje zvláštního člena projektu, tzv. kouče, který detekuje výpadky komunikace a znovunavazuje vztahy mezi lidmi.
- Jednoduchost. XP se průběžně ptá: „Co je nejjednodušší věc, která by ještě mohla fungovat?“ V tomto ohledu si XP doslova zahrává. Sází na to, že je lepší udělat něco jednoduchého dnes a zítra případně zaplatit víc za případnou změnu, než platit dnes za složitou věc, která se ovšem zítra nemusí využít. Umění nemyslet na předpokládanou budoucnost je přitom velmi obtížné; aby bylo možné realizovat jednoduchost podle definice XP, je nutné nehledět dopředu na záležitosti, které se budou muset implementovat zítra, příští týden a příští měsíc.
- Zpětná vazba. Zpětná vazba o aktuálním stavu systému je velmi důležitá a máloco ji dokáže nahradit. Programátoři totiž někdy trpí přehnaným optimismem. Ten se dobře eliminuje právě zpětnou vazbou, která je obvykle realizována především testováním. Zpětná vazba v XP probíhá ve dvou paralelních časových rovinách. První z nich je v řádu minut a dnů a týká se testů jednotek, které dávají okamžitou informaci o stavu nově napsané jednotky. Další je v řádu týdnů a měsíců a realizuje se testy funkčnosti (jakýmisi zjednodušenými provozními případy).
- Odvaha. Pokud tým zjistí, že dopředu cesta nevede (zásadní problém v architektuře, špatné rozhraní mezi moduly apod.), je nutné chybu opravit i v případě, že by to znamenalo zahození poloviny již napsaného zdrojového textu. Je-li odvaha kombinována s předchozími třemi hodnotami, stává se nesmírně cennou.
Právě v tomto bodě osobně spatřuji nesmírnou propast mezi praktickou využitelností XP v USA a v Evropě. Jak si řekneme v některém z příštích článků o XP, tato metodologie je postavena na myšlence průběžné implementace; v okamžiku, kdy se zjistí, že díky špatnému návrhu nelze pokračovat současným směrem, část kódu se jednoduše vyhodí, návrh se vylepší a implementuje se znovu – jinak. Na základě osobních zkušeností i z mnoha zdrojů si myslím, že tento přístup může fungovat v USA, zemi plné sebevědomých lidí, kteří si z chyb nic nedělají: Američan je schopen vyzkoušet pět špatných postupů, než najde šestý správný – a celý tento proces s úsměvem prohlásí za úspěšný a efektivní. Naproti tomu evropská (a především česká) mentalita je v tomto směru diametrálně odlišná: bojíme se chyb, vyhození hotové části kódu považujeme za selhání a tři špatné postupy následující po sobě nás přimějí k úvahám o ukončení projektu.
Američan Jack Stack, předseda představenstva a CEO Finanční skupiny České spořitelny, v rozhovoru pro časopis e-biz (e-biz 12/02) na otázku „Je v české kultuře něco, s čím jste nepočítal?“ uvádí: „Nejvíc mě překvapuje posedlost dokonalostí, snaha mých českých kolegů vyhnout se chybě. Američané se nebojí zkusit deset věcí, a když sedm z nich vyjde a tři ne, považují to za bezvadný výsledek. Tady je tendence nejít s produktem ven, dokud nebude stoprocentní. To nás hodně zdržuje, a neustále s tím bojuji. ... Proto mám v kanceláři zarámované heslo: Implementujme teď, zkononalujme později.“
Přestože pro Jacka Stacka je možná XP zcela neznámým pojmem, bezděky má v kanceláři heslo jako vystřižené z knihy Kenta Becka. Myslím, že americká mentalita leží principům XP nesrovnatelně blíže než česká. To je možná také důvodem, proč se v odborných diskusích na českých internetových serverech ozývá na adresu XP značná nedůvěra; ze stejné příčiny považuji implementaci XP v lokálních podmínkách za obtížnou.
Pod povrchem výše uvedených čtyř hodnot se pak skrývá pátá, hlubší: respekt. Pokud by se členové týmu nestarali o to, co který z nich dělá, bude XP odsouzeno k záhubě. Kent Beck uvádí, že totéž se týká i jiných přístupů k programování (a pravděpodobně i čehokoliv jiného), ale XP je na respekt velmi citlivé.
Na závěr
Tolik pro dnešek k extrémnímu programování. Jistě jste postřehli, že jsme se ani dnes prozatím nedostali k žádným praktickým postupům a k ničemu, co by (byť jen velmi vzdáleně) připomínalo návrh metodologie pro vývoj softwaru.
Dílem je to způsobeno skutečností, že XP žádné exaktní postupy nedefinuje, ale hlavním důvodem je skutečnost, že bych vám rád vysvětlil principy XP opravdu důkladně – tak, aby si i čtenář, který o XP dosud nic neslyšel, mohl o tomto novém směru učinit svůj vlastní obrázek.
Za týden budeme pokračovat popisem jednotlivých fragmentů XP – vyjmenujeme si 12 konkrétních postupů, které bychom měli při přijetí extrémního programování dodržovat, zdůrazníme 4 klíčové činnosti a konečně se dostaneme také k trochu vágně definované posloupnosti kroků a fází.