Umějí Češi programovat extrémně?

Dnešní článek se vrací k Extrémnímu programování. Nejprve dokončíme popis této zajímavé agilní metodologie a ukážeme si formální příklad životního cyklu projektu vyvíjeného pomocí XP. V závěru se pokusíme zodpovědět důležitou otázku: je možné používat Extrémní programování v českých softwarových společnostech? XP má mnohá specifika: jsou na ně Češi připraveni?
V předchozích dvou článcích o Extrémním programování (XP) jsme tuto metodologii zevrubně popsali, seznámili se s jejími základními hodnotami a technikami. Zbývá několik informací, o něž bych nerad zájemce o XP ochudil. Začít nelze jinak než samotným zavedením (nasazením) metodologie.

Kent Beck se ve své knize Extrémní programování (český překlad vyšel v nakladatelství Grada v roce 2002) zamýšlí nad postupem, jak implementovat (zavést) XP v organizaci využívající jinou metodologii. Zdůrazňuje, že nejvhodnějším postupem je zavádět XP postupně, vždy pouze na problém, který je týmem považován za nejpalčivější:

  • Vyberte svůj nejpalčivější problém.
  • Řešte jej stylem XP.
  • Jakmile již daný problém není nejpalčivější, opakujte tento postup.

Výhody a silné stránky

Tolik nejdůležitější pravidlo pro zavádění XP. Pojďme nyní shrnout výhody, které Extrémní programování může nabídnout.

Jednou z hlavních výhod XP je práce v souladu s lidskými instinkty a nikoliv proti nim: lidé rádi vyhrávají, lidé se rádi učí, lidé se rádi stýkají s jinými lidmi, lidé jsou rádi součástí týmu, lidé jsou rádi, když mají kontrolu, lidé jsou rádi, když se jim věří, lidé rádi odvádějí dobrou práci (snad s výjimkou některých českých politiků), lidé jsou rádi, když software funguje, lidé před sebou rádi vidí blízký a konkrétní cíl.

Další výhody plynou z iterativního, inkrementálního způsobu vývoje. Pozitivní je též nelpění na formalitách a přímočarý postup k cíli. V ideálním případě je vývoj efektivní, aplikace je dodána relativně rychle a splňuje požadavky svého zákazníka.

Výhodou je také všeobecný zájem o XP, který je patrný v širokých kruzích vývojářské veřejnosti. Díky tomu lze nalézt o XP řadu zdrojů informací, a to jak na internetu, tak i v knižní podobě.

Nevýhody a potíže

Po výčtu nejdůležitějších výhod zmiňme i možné potíže. Autor XP uvádí (cituji z výše zmíněné knihy): „XP je jednoduché v detailech, ale obtížné při vykonávání.“

Nevýhodou XP jsou obtíže při jeho praktické realizaci, především v době, kdy si vývojový tým na XP teprve zvyká. Obtížné je například dělat věci jednoduše, naučit se vidět svět v nejjednodušších pojmech, připustit „nevím“, jít za zákazníkem a žádat o vysvětlení těch nejzákladnějších konceptů nebo obrátit se na programátorského kolegu a přiznat neznalost programátorských základů. Z těchto všech problémů vyplývá silný důraz, který musíme klást na složení vývojového týmu a na volbu vhodných osobnostních typů.

Na zvláštnosti XP vývoje si musí zvyknout bez výjimky všichni členové týmu, včetně šéfů, manažerů a zákazníků. Všichni se kromě jiného musí naučit spolupracovat, přestože náš vzdělávací systém nás od útlých let směruje k individualismu („spolupráce na projektu“ bývá ve škole nazvána podváděním a potrestána, ve většině společností jsou zaměstnanci individuálně ohodnocováni).

Lidé v XP týmu se musí naučit nestydět se za své emoce a vyjadřovat je. Je-li někdo rozzloben či frustrován a nemluví o tom, po krátké době se sníží výkonnost celého týmu.

Ne každý člověk je vhodný do XP týmu. Mnozí vývojáři odmítají myšlenky párového programování, kolektivního vlastnictví kódu, permanentní komunikace. Autor XP sice uvádí, že většina si nakonec zvykne, nicméně z diskusí, které vede odborná veřejnost, je cítit silná pochybnost o tomto tvrzení.

Formální příklad životního cyklu

V tomto odstavci uvedu příklad životního cyklu projektu vyvíjeného pomocí XP. XP však zdůrazňuje, že žádné dva projekty vyvíjené podle XP nikdy nebudou (a ani nemohou být) přesně stejné.

Na počátku ukázkového životního cyklu probíhá průzkum. XP se snaží uvést software (byť v minimálním rozsahu) do provozu co možná nejdříve. Předtím je však nutné projít průzkumovou fází; ta končí ve chvíli, kdy jsou splněny oba následující požadavky:

  • zákazník si bude jistý, že existuje dostatek materiálu na vytvoření karet zadání pro první verzi,
  • programátoři si budou jisti, že už nemohou lépe odhadovat, aniž by systém skutečně implementovali.

Při průzkumu zkoumají programátoři možnosti architektury tím, že se pokusí třemi až čtyřmi způsoby sestavit systém, který bude podobný tomu požadovanému. Tým získává praxi s technologiemi, zákazník s psaním zadání.

Fáze průzkumu může u zkušeného týmu trvat několik málo týdnů. Tým, pro který představuje daná technologie zcela nový pojem, může naopak potřebovat několik měsíců.

Po dokončení průzkumu následuje fáze plánování. Jejím účelem je, aby zákazníci i programátoři mohli s jistotou souhlasit s datem uvolnění nejmenší sady zadání. Plánovací postup byl popsán v předchozím článku na téma XP. Při dobrém provedení předchozího průzkumu by mělo být úvodní plánování dokončeno za jeden či dva dny.

Je-li hotov hrubý plán, následuje další fáze, která spočívá v provádění iterací až do uvolnění první verze. Iterace trvají jeden až čtyři týdny a výsledkem každé z nich je sada testů funkcionality pro všechna zadání, která jsou do dané iterace zařazena.

Na tomto místě je vhodné zdůraznit, že nikde se nenalézají žádné samostatné fáze analýzy a návrhu: po formulaci zadání se bezprostředně začne implementovat a návrh se provádí jako nedílná součást implementace. Neuvažuje se příliš do budoucna; pokud později nastane potřeba změny architektury, provede se refaktorizace a pokračuje se dál ve stejném duchu.

Vraťme se však zpět k probíhajícímu vývoji. První iterace by měla položit základy architektury. Je tedy důležité vybrat do ní takové karty zadání (vytvořit takové úkolové karty), které vývojáře donutí vytvořit „celý systém“, byť jen v podobě kostry.

Výběr konkrétních zadání do další fáze bude záležet na zákazníkovi. Na konci každé iterace je uspořádána týmová oslava. S oslavami se při XP vývoji mimochodem vůbec nešetří, jak bude patrné z dalšího textu. Na konci poslední iterace je první verze připravena k uvedení do provozu.

V tom okamžiku přechází projekt do další fáze, která je definována jako zprovozňování. Měla by se projevit tím, že se zhruba trojnásobně zvýší frekvence iterací za účelem získání aktuální zpětné vazby, která umožní pružnou reakci na uživatelské požadavky. V této fázi také může být tým nucen zapracovat na vyladění či optimalizaci projektu. Důležité je ohodnotit každou požadovanou změnu a odpovědně rozhodnout, zda je nutné ji implementovat ještě v této verzi, nebo postačí počkat do další dodávky. Když se programové vybavení kompletně zprovozní, uspořádá se týmová oslava.

Další, poměrně náročnou fází (možná přesněji stavem) životního cyklu je údržba. V jejím rámci se produkují nové funkce, udržuje se současný systém v provozu a začleňují se případní noví členové do projektu. Nezanedbatelnou částí údržby je také provoz helpdesku. Protože součástí údržby je i vývoj nové verze, dochází k postupnému návratu opět na začátek – k průzkumu. Tým se může pokusit o velkou refaktorizaci, experimentovat s novými architektonickými myšlenkami, přejít na novou verzi vývojového prostředí apod. Celý cyklus se opakuje i s nezbytnými průběžnými oslavami.

XP definuje ještě jednu fázi životního cyklu – smrt: „Jestliže už zákazník nemůže přijít na žádná nová zadání, je čas pustit systém z hlavy.“ XP upozorňuje, že v tomto okamžiku je (teprve!) čas a příležitost napsat pěti- až desetistránkový dokument s popisem systému, který může být využit, až se tým bude muset k projektu za několik let vrátit.

Druhou situací vedoucí též k přechodu do fáze smrti, je neschopnost systému dále existovat (zákazník potřebuje nové funkce a tým je nemůže přidat při rozumných nákladech, míra poruch neúměrně roste…). Bez ohledu na příčinu smrti se uspořádá rozlučková oslava se systémem.

Přístup k lidskému faktoru

XP klade velmi silný důraz na práci s lidmi. Zaměřuje se na složení vývojového týmu, na lidské role, na motivaci lidí a dokonce i na nejvhodnější uspořádání pracovišť.

XP definuje následující role uvnitř týmu:

  • Programátor – zatímco v jiných metodologiích je programátor považován spíše za mechanického naplňovatele návrhu, v XP je srdcem týmu. Zaměření je jiné: kromě psaní programu a psaní testů je úkolem programátora komunikace s ostatními členy. Programátor musí umět programovat, refaktorizovat a testovat software po jednotkách.
  • Zákazník – druhá klíčová role: programátor umí programovat, zákazník ví, co programovat. Musí se sžít s některými zásadami XP: naučit se psát zadání a testy funkcionality, přijmout možnost ovlivňovat projekt a spoluzodpovídat za něj. Zopakujme, že v XP je zákazník nedílnou součástí týmu; vyskytuje se na pracovišti a průběžně komunikuje s vývojáři i managementem vývojářské firmy.
  • Tester – hodně testovací odpovědnosti leží na bedrech programátorů; tester je především zodpovědný za pomoc zákazníkovi při výběru a psaní testů funkcionality.
  • Stopař – stopař provádí především časové odhady a sbírá informace vzešlé ze zpětné vazby. Analyzuje příčiny zpoždění projektů. Současně má nad systémem nadhled.
  • Kouč – kouč je zodpovědný za proces jako celek. Pokud se lidé odchýlí od týmového procesu, kouč je upozorní. Kouč musí pochopit, jaké alternativní postupy by mohly pomoci aktuálním problémům. Kontroluje, zda lidé otevřeně komunikují. Dobrý kouč musí být schopen detekovat problémy i v mezilidských vztazích a snažit se je eliminovat (nebo alespoň minimalizovat jejich dopad na práci týmu).
  • Konzultant – vzhledem k tomu, že v typickém XP týmu neexistují experti na konkrétní oblasti (všichni se zabývají všemi částmi kódu), tým občas potřebuje odborného technického konzultanta.
  • Velký šéf – osoba vedoucí organizaci. Požadavkem je ochota přijmout skutečnost, že tým využívá XP, což vede někdy k zdánlivě nesmyslným krokům (párové programování). Velký šéf musí mít dostatek rozvahy, trpělivosti a odvahy, protože XP vývoj někdy zdánlivě směřuje zpět (refaktorizace, zahození napsaného kódu).

XP definuje také nejlepší rozvržení prostoru na pracovišti. Tým by měl pracovat v co nejmenším počtu separovaných místností (ideálně v jedné). Uprostřed místnosti by mělo být několik počítačů, dvě židle u každého. Po okrajích místnosti mohou být kóje (nemusí obsahovat počítač, ale měly by být vybaveny telefonem), do nichž se pracovníci uchýlí, potřebují-li soukromí. Přední a zadní zdi by měly být pokryty tabulemi, které znázorňují např. testy funkcionality, aktuální iterační plán, zásadní návrhové struktury apod. Místnost dále obsahuje jeden další stůl, u něhož se tým schází k poradám. Na podlaze není koberec, aby se židle mohly volně pohybovat.

Vhodnost

Přesné hranice XP nejsou jasně stanoveny. Metodologie je obecně určena pro týmy se dvěma až deseti členy, kteří pracují na často se měnících nebo nejasných zadáních. XP se rozhodně nehodí pro velké týmy. Pro stočlenné skupiny je bezesporu nepoužitelné, pro dvacetičlenné pravděpodobně také ne.

Metodologie se nehodí v případech, v nichž manažeři odmítají vyměnit kontrolu (dokument Specifikace požadavků) za dialog, důvěru a možnost změn (plánovací hra). Stejně tak nelze s úspěchem zavést XP, pokud osobnostní typy vývojářů odporují zásadám, jež XP razí. XP nelze použít ani v případech, v nichž z technologických nebo z jiných důvodů trvá získání zpětné vazby příliš dlouho. Pokud např. trvá kompilace systému 24 hodin, nelze realizovat průběžnou integraci ani pravidelné testování.

Pro všechny ostatní případy je zřejmě XP použitelné a po překonání úvodních nevyhnutelných problémů a nedorozumění může být i velmi efektivní. Nejvhodnější se jeví být pro malé projekty (včetně internetových).

XP po česku: utopie nebo realita?

V úvodu článku jsem slíbil pokus o odpověď na otázku, je-li možné použít extrémní programování v našich, českých lokálních podmínkách. Rád bych zdůraznil, že zatímco předchozí kapitoly obsahovaly objektivní informace (získané především z knihy zakladatele XP a z odborných internetových zdrojů), následující odstavce vyjadřují pouze mé osobní přesvědčení a nelze je tedy směšovat s definicí Extrémního programování.

Při popisu Extrémního programování jsme několikrát zopakovali, že jedním ze základních předpokladů úspěšného využívání XP je odvaha, neboť častým průvodním jevem XP je nutnost vyhodit už hotovou práci, vrátit se zpět a začít znovu.

Právě v tomto bodě spatřuji určitou propast mezi praktickou využitelností XP v USA a například v Evropě. XP je postaveno 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ů jsem si jist, že tento přístup může fungovat v USA – v zemi, jejíž sebevědomí je legendární. Američan si z chyb nic nedělá: 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 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-biz12/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ď, zdokonalujme 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.

Zmírnit tuto propast by zřejmě mohlo jen vhodné složení vývojového týmu: tým by musel být sestavován se silným důrazem na volbu dostatečně sebevědomých (zároveň však zodpovědných, kreativních a odborně zdatných) jedinců.

Na závěr

Jaký je váš názor? Jsme schopni (a připraveni) přistoupit na principy XP? Máme na to povahu? Máme dostatek víry v sebe sama – víry, že i když vyhodíme pět hotových modulů, bude nakonec produkt hotov včas a v dobré kvalitě? Nebudeme to považovat za nepřípustnou ztrátu času? Pochopí to vedoucí týmů a manažeři? Porozumí tomu zákazník? Napište do diskuse!

Diskuze (79) Další článek: Servery Blade od Sunu s procesory Athlon budou později

Témata článku: Software, Programování, Předchozí výběr, Osobnostní typ, Pravidelné testování, Úspěšný test, Dobrá využitelnost, Nejvhodnější postup, Extrémní systém, TomTom, Dobrý test, Kent, Dobré provedení, Nedílná součást, Místnost, Vzdělávací systém, Extrém, Beck, Základní hodnota, Fáze, Špatná věc, Celá místnost, Nejdůležitější otázka, Špatná podmínka, Lidská práce


Určitě si přečtěte

Užijte si poslední změny času: Už od března 2019 můžeme mít trvale letní čas

Užijte si poslední změny času: Už od března 2019 můžeme mít trvale letní čas

** Evropská komise přijala legislativní návrh na zrušení střídaní času ** Možná tak v březnu 2019 přesuneme ručičky hodinek naposledy ** Od toho okamžiku bude permanentně platit letní čas

Karel Kilián | 96

Nedávno detekovaná potulná planeta je ohromné magnetické monstrum

Nedávno detekovaná potulná planeta je ohromné magnetické monstrum

** Astronomové nedávno zaznamenali pozoruhodné prvenství ** Poprvé s radioteleskopem detekovali planetární objekt za hranicemi Sluneční soustavy ** Stejně tak poprvé změřili magnetické pole takové planety

Stanislav Mihulka | 6

Modelářský zázrak: Maketa raketoplánu Columbia, která létá jako skutečná raketa

Modelářský zázrak: Maketa raketoplánu Columbia, která létá jako skutečná raketa

** Model raketoplánu Columbia od českého konstruktéra umí i létat ** Obdivuhodný model si vzal 1600 hodin práce ** Podívejte se na fotografie ze stavby a prvního letu

Karel Jeřábek | 20

V doupěti hackerů na brněnské FIT: Ukázali nám útoky na Bluetooth i vlastní chytré krabičky

V doupěti hackerů na brněnské FIT: Ukázali nám útoky na Bluetooth i vlastní chytré krabičky

** Internet je plný malwaru, to už dnes ví každý ** Víte ale, že lze útočit třeba i na Bluetooth? ** Navštívil jsem hackery z brněnského FITu

Jakub Čížek | 1


Aktuální číslo časopisu Computer

Megatest: 13 grafických karet

Srovnání 7 dokovacích stanic s USB-C

Jak na perfektní noční fotografie

Kvalitní zdroje informací pro sebevzdělávání