Agilní metodiky vývoje software

MASARYKOVA UNIVERZITA V BRNĚ FAKULTA INFORMATIKY #ris m p Agilní metodiky vývoje software DIPLOMOVÁ PRÁCE Bc. Tomáš Kotrla Brno, Podzim 2005

Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí práce: Mgr. Barbora Zimmerová 11

Poděkování Rád bych poděkoval Ing. Václavu Kadlecovi za představení zajímavého odvětví agilních metodik, Mgr. Barboře Zimmerové za cenné rady a trpělivost projevenou při mém vedení a své matce za podporu a zázemí, které jsem měl během celého studia. m

Shrnutí Agilní metodiky vývoje softwaru jsou v poslední době rychle se rozvíjejícím odvětvím softwarového inženýrství, kterému mnozí odborníci předpovídají slibnou budoucnost. Agilní metodiky jsou vyhledávané zejména pro svoji schopnost rychle poskytnout fungující základ systému a flexibilně reagovat na měnící se požadavky. Práce se věnuje odvětví agilních metodik vývoje software a pro důkladnější zkoumání si vybírá metodiky Extrémní programování, Crystal metodiky a Dynamic Systems Development Method, které popisuje a srovnává. Součástí práce je náčrt řešení případové studie pomocí vybraných metodik. IV

Klíčová slova vývoj software, agilní metodiky, Extrémní programování, XP, Crystal metodiky, Crystal Clear, Dynamic Systems Development Method, DSDM v

Obsah 1 Úvod 1 1.1 Struktura práce 1 2 Agilní metodiky 2 2.1 Charakteristika agilních metodik 2 2.2 Srovnaní s klasickým přístupem 3 2.3 Manifest agilního vývoje software 5 2.4 Hodnocení agilních metodik 3 Vybrané agilní metodiky 10 3.1 Extrémní programování 11 3.1.1 Principy 12 3.1.2 Role 14 3.1.3 Postupy 15 3.1.4 Životní cyklus 17 3.1.5 Hodnocení 19 3.2 Crystal metodiky 20 3.2.1 Principy 22 3.2.2 Role 23 3.2.3 Postupy 24 3.2.4 Životní cyklus 27 3.2.5 Hodnocení 29 3.3 Dynamic Systems Development Method 29 3.3.1 Principy 30 3.3.2 Role 31 3.3.3 Postupy 33 3.3.4 Životní cyklus 34 3.3.5 Hodnocení 35 3.4 Srovnání vybraných metodik 37 3.4.1 Principy 37 3.4.2 Role 39 3.4.3 Postupy 41 4 Případová studie 44 4.1 Výchozí podmínky 44 4.2 Extrémní programování 45 4.3 Crystal Clear 49 4.4 Dynamic Systems Development Method 51 4.5 Srovnání životních cyklů 52 5 Závěr 54 Literatura 55 vi

Seznam obrázků 2 Agilní metodiky 2.1 Srovnání tradičních a agilních přístupů 3 3 Vybrané agilní metodiky 3.1 Životní cyklus podle XP 20 3.2 Volba odpovídající metodiky z rodiny" Crystal 21 3.3 Cykly projektu řízeného metodikou Crystal Clear 3.4 Životní cyklus podle DSDM 36 4 Případová studie 4.1 Ukázka karty zadání 45 4.2 Ukázka úkolové karty 47 4.3 Ukázka bleskové plánovací karty 49 1

Seznam tabulek 2 Agilní metodiky 2.1 Vlastnosti agilních metodik 8 4 Případová studie 4.1 Část karet zadání vybraných do první iterace 46

Kapitola 1 Úvod Potřeba vývoje software je stejně stará, jako první počítače. Tato disciplína se musela vypořádat s řadou problémů a prodělala tak mnoho změn. Od, ve své době, revolučního vývoje podle modelu vodopád se přes spirálový model dostala až k současným sofistikovaným přístupům k vývoji software. Úspěšným zástupce takových přístupů je metodika firmy IBM s názvem Rational Unified Process [ ], zkráceně RUP V poslední době se však objevili nové metodiky, které směle slibují rychlejší a levnější dodávky software. Jsou souhrnně označované jako agilní. Přitahují na sebe čím dal tím větší pozornost a část odborné veřejnosti jim předpovídá slibnou budoucnost. Úkolem a cílem práce je získat přehled o agilních metodikách a následně je zhodnotit. Druhým úkolem je výběr tří metodik a jejich vzájemné srovnání. Posledním úkolem je pak ukázka vývojového cyklu pomocí případové studie. 1.1 Struktura práce Práce je rozdělena na pět kapitol, v první uvádím zadání práce a definuji její cíle. V kapitole 2. Agilní metodiky charakterizuji agilní metodiky, věnuji se důvodům jejich vzniku, srovnávám je s tradičními přístupy a hodnotím jejich vlastnosti. Na začátku kapitoly 3. Vybrané agilní metodiky si vybírám trojici agilních metodik, kterým se v práci více věnuji. Každou stručně představuji, uvádím její principy, definované role v týmech, předepsané postupy, typickou podobu vývojového cyklu a vyjadřuji hodnocení dané metodiky. Na závěr srovnávám principy, role a postupy vybraných metodik, přičemž se zaměřuji většinou jen na rozdíly. V kapitole 4. Případová studie se snažím stručně ukázat průběh projektu ve vybraných metodikách a nakonec metodiky srovnat na základě jejich vývojových cyklů. Poslední kapitola je závěrem práce, kde shrnuji výsledky práce a zabývám se možnostmi dalšího bádání v oblasti agilních metodik. 1

Kapitola 2 Agilní metodiky Tato kapitola se věnuje obecně všem agilním metodikám, popisuje jejich přístup k vývoji software, uvádí jejich společné principy a rozdíly oproti tradičním přístupům. Kapitola je ukončena stručným hodnocením obsahujícím výčet pozitivních a negativních vlastností agilních metodik. 2.1 Charakteristika agilních metodik V angličtině se agilní metodiky označují jako agile methodologies". Toto spojení lze přeložit jako čilé", hbité" nebo živé" metodiky. Dříve se užíval pojem lightweight methodologies", který měl zdůraznit lehkost" metodik (z pohledu produkované dokumentace), tento pojem má však více různých významů, a tak se od jeho používání postupně upustilo. Samotné překlady uvedené v předchozím odstavci výstižně popisují cíle agilních metodik, vývoj software má být hbitý" (software je dodán v co nejkratším čase), lehký" (vývoj se omezuje jen na potřebné činnosti a tvorbu nutných dokumentů) a živý" (software musí být úspěšně dodán, tedy celý projekt má přežít). Vzhledem k rostoucímu počtu firem v oboru ICT 1 získává ekonomická stránka vývoje software na významu. Pokud chce firma v konkurenci obstát, musí být schopná dodat software v co nejkratším čase a udržet přitom minimální náklady. Důvod je zřejmý, zakázku získá konkurenční firma, která je schopná vyvinout software rychleji a levněji. Je nutné si uvědomit, že se při vývoji uvažují dva různé časy. Prvním je celkový čas, který zabere realizace softwarového řešení, tedy od počátečního sepsání smlouvy až po akceptaci konečného řešení. Druhým a významnějším uvažovaným časem je doba potřebná k dodání první fungující části software 2, kterou již může zákazník používat při své práci. Minimalizace právě druhého uvažovaného času je pro vývoj software klíčová z dvou hlavních důvodů. Fungující část software zákazníkovi přináší užitek a tím i určitý příjem, který snižuje náklady na vývoj zbývajících částí software. Čím dříve zákazník uvidí systém v provozu, tím dříve získává vývojový tím zpětnou vazbu. Dalším významným faktorem je psychologie práce ve skupině. Agilní metodiky považují motivované lidi v týmu za klíčový předpoklad pro úspěšný vývoj. Proto se agilní metodiky zaměřují na pracovní prostředí, na zajištění podpory všem členům týmu, aby mohli 1. Informační a komunikační technologie (Information and Communications Technology) 2. Tento čas je často označován zkratkou TTM (Time To Market) 2

2.2. SROVNANÍ S KLASICKÝM PŘÍSTUPEM odvádět svou práci co nejlépe, na vzájemnou komunikaci mezi členy týmu i mezi týmem a zákazníkem. Z pohledu agilních metodik jsou lidé významnější, než dodržované postupy, produkované dokumenty nebo používané nástroje. 2.2 Srovnaní s klasickým přístupem Předchozí část kapitoly byla úvodem do oblasti agilních metodik, v této části jsou zdůrazněny základní principy agilních metodik včetně jejich srovnání s tradičními přístupy. Výstižně tyto různé přístupy srovnává obrázek 2.1 převzatý z přednášky Agilní metodiky [ ] Aleny Buchalcevové. funkcionalita Zdroje ' " L; "* V 7 ťas Zdroje Funkcionalita Tradiční přístupy Agilní přístupy Obrázek 2.1: Srovnání tradičních a agilních přístupů Z obrázku 2.1 je patrné, že tradiční přístupy považují za fixní funkcionalitu, tedy podepsanou specifikaci na začátku projektu, která se dále v průběhu projektu nemění. Implementace takové specifikace následně zabere nějaký čas a spotřebuje určité zdroje (platy vývojářů a kapitál firmy). Hodnoty těchto proměnných jsou při plánování v úvodní fázi odhadnuty, během průběhu projektu se však mohou a často také mění, vývoj pak trvá déle a stojí víc. Agilní metodiky oproti tradičnímu přístupu zaměňují fixní a volné proměnné. Na začátku se odhadnou a pevně naplánují potřebné zdroje a čas, funkcionalita je ponechána jako volná proměnná jejíž hodnota je upravována podle aktuální úspěšnosti projektu, jinými slovy v případě problémů se implementace části funkčnosti odloží v zájmu dodržení termínu. Zdrojový kód jako nositel informace Jak uvádí Václav Kadlec ve své knize Agilní programování [ ], agilní metodiky produkují mnohem méně formální dokumentace, vycházejí totiž z přesvědčení, že základním, jednoznačným, exaktním, nezpochybnitelným a spolehlivým nositelem informace je zdrojový 3

2.2. SROVNANÍ S KLASICKÝM PŘÍSTUPEM kód. Toto přesvědčení nesdílí tradiční přístupy, které vývoj software staví na tvorbě různě objemných dokumentací (formální specifikace, detailní návrh, apod.) před samotným psaním zdrojového kódu. Důraz na dokumentaci je způsoben strachem z neúspěšného projektu, nutností rozumného udržení znalostí a mnohdy přímo vynucen uzavřenou smlouvou. Iterativní a inkrementální vývoj Plán projektu podle agilních metodik sestává z velmi krátkých iterací, během nichž se postupně vyvíjí inkrementy výsledného software. Získává se tak dříve zpětná vazba a eliminuje riziko, kdy vývojový tým na konci dodá něco, co zákazník vůbec nechtěl. Zároveň tým dříve zjistí integrační problémy. Výhody iteračního a inkrementálního vývoje jsou nesporné, našli si proto své místo i mezi tradičními přístupy (spirálový model, iterace a buildy v metodice RUP). Agilní metodiky se tedy liší jen tím, že jejich iterace bývají většinou kratší. Přímá osobní komunikace Mnoho komplikací během vývoje způsobuje špatná komunikace a problémové vztahy mezi členy týmu. Agilní metodiky se tyto komplikace snaží řešit utužováním vzájemných vztahů a zavedením časté osobní komunikace do základních činností vývoje. V každém týmu je osoba zodpovědná za včasné zjištění a vyřešení všech komunikačních problémů. Osobní komunikace je považována za nejlepší způsob předání informace. Tradiční přístupy se většinou zabývají více činnostmi vývoje než vztahy mezi lidmi. Řešení společenských problémů je spíše ponecháno na umu vedoucích pracovníků. Osobní komunikace není tradičními přístupy samozřejmě potlačována, je však vyžadována komunikace podle určených formálních pravidel. Důvodem je snaha o zaznamenání všech důležitých rozhodnutí a o udržení uceleného systému znalostí. Blízká spolupráce s uživatelem Agilní týmy během své práce často komunikují s budoucími uživateli, upřesňují si tak potřebné informace o fungování zákazníkova obchodu nebo o požadavcích na software. Tato komunikace je ve stejné míře během celého projektu, v ideálním případě jsou zástupci budoucích uživatelů přímo členy týmu. Tradiční přístupy oproti tomu s uživateli komunikují na začátku během psaní specifikace, v průběhu během občasných doplňujících schůzek, případně při předvádění prototypů a nakonec během akceptace dodaného software. Lze tedy říci, že komunikace je celkově menší a v průběhu projektu nerovnoměrně rozprostřená. Průběžné testování Vyvíjený software se často během projektu mění, proto je důležité jeho důkladné regresní testování často a pravidelně prováděné v průběhu celého vývoje. Znovu otestování celého software je většinou nelehký úkol, je tedy nutné software navrhovat tak, aby jeho testování 4

2.3. MANIFEST AGILNÍHO VÝVOJE SOFTWARE bylo co nejsnazší a aby ho bylo možné realizovat pomocí nástrojů pro automatizované testování. Metodika Extrémní programování dokonce trvá na vytváření příslušných testů dříve, než programátor přistoupí k implementaci daného požadavku. Při tradičním přístupu etapa testování navazuje na etapu implementace. Detaily provádění samotných testů jsou většinou specifické pro konkrétní projekt. Zpravidla je vyžadováno, aby testování a implementaci prováděly různé osoby a snížila se tak pravděpodobnost opakování chybného porozumění specifikaci. 2.3 Manifest agilního vývoje software Jednotliví autoři se snažili při vytváření metodik reagovat na nové potřeby kladené na úspěšný vývoj software. Dřívější potřebu spolehlivého software v současnosti doplňují nové potřeby jako ekonomická stránka vývoje nebo psychologie skupinové práce, zmiňované již v úvodu této kapitoly. Nejdříve každý autor považoval svou metodiku za ojedinělou, v únoru 2001 ze společného setkání v Utahu vyplynul opak, vznikající metodiky měly řadu společných tezí. Vznikla tak Aliance pro agilní vývoj software [ ], zastřešující jejich společnou činnost a byl sepsán Manifest agilního vývoje software [ ], kde jsou vyjmenovány společné teze, některé překlady jmen tezí uvedených dále jsou převzaty z knížky Agilní programování [3] od Václava Kadlece. Základní myšlenky manifestu jsou: přijmout a umožnit změnu požadavků je efektivnější než jí bránit, požadavek na změnu se určitě objeví. Na základě uvedených myšlenek autoři manifestu dávají přednost: individualitám a komunikaci před procesy a nástroji, provozuschopnému software před obsáhlou dokumentací, spolupráci se zákazníkem před vyjednáváním formálních smluv, reakci na změnu před striktním plněním plánu. Na základě uvedených myšlenek a předností formulovali autoři manifestu následující teze. Užitná hodnota pro zákazníka Zákazník má větší užitek z dodaného fungujícího software než z rozsáhlé dokumentace v podobě UML-diagramů a ERA-modelů. Metodiky proto dávají větší prioritu vyvíjenému software než jeho dokumentaci. 5

2.3. MANIFEST AGILNÍHO VÝVOJE SOFTWARE Vítané změny Prostředí, ve kterém zákazník podniká, se většinou rychle mění, proto požadavky identifikované na začátku projektu (při psaní specifikace) nemusí být na konci projektu žádané, mohou se výrazně změnit nebo dokonce zrušit. Přidaní nového požadavku až v průběhu realizace projektu může znamenat významnou konkurenční výhodu pro zákazníka. Z těchto důvodů metodiky nefixují požadavky v úvodních fázích, ale přizpůsobují vývoj a plánovaní měnícím se požadavkům. Časté dodávky Vývoj software je iterativní a inkrementální. Dodávky nových verzí jsou v co možná nejkratším intervalu. Tím získává tým od zákazníka včasnou zpětnou vazbu a zákazníkovi přináší běžící software očekávaný užitek. Zákazníci spolupracují s týmem Vítané změny znamenají, že vývojový tým nemá detailní specifikaci k dispozici od začátku implementace, proto jsou nutné časté konzultace se zaměstnanci zákazníka k upřesnění specifikace. Klíčová motivace Základem úspěšného vývoje jsou lidé. Ti musí být patřičně motivovaní a musí jim být dána dostatečná důvěra a kompetence k dělání klíčových rozhodnutí. Vzájemná konverzace Přímá konverzace je nejrychlejší a nejefektivnější formou přenosu informace. Pokud ji podmínky umožňují, je snadnější než psaní a čtení dokumentace. Úspěch posuzujeme podle fungování Fungující software je primárním ukazatelem průběhu projektu. Udržitelný vývoj Lidé nevydrží efektivně tvořit, pokud musejí být v práci dlouhodobě přesčas. Udržitelný vývoj znamená, že lidé dlouhodobě nepřekračují standardní pracovní dobu. Perfektní návrh a řešení Vzhledem k častým změnám v požadavcích je nutné mít perfektní návrh a řešení, které umožní rychlé zapracování změn do již vyvinutého systému. Změna návrhu nebo zdrojových kódů je považována za přirozenou věc při agilním vývoji, neznamená tedy selhání některé předchozí činnosti. Návrh a implementace probíhají současně, navzájem se prolínají ve velmi krátkých cyklech. 6

2.4. HODNOCENÍ AGILNÍCH METODIK Jednoduchost Základem úspěchu je udělat minimum práce přinášející maximum užitku. Vyvíjený software je postupně skládán z jednoduchých částí, které lze snadno změnit. Očekávání častých změn způsobuje maximální možné odkládání implementace požadavků. Samoorganizující se tým Nejlepší výsledky mají samoorganizující se týmy obsahující schopné a kreativní členy, kteří spolu často komunikují. Zdokonalování Během vývoje se často hledají slabá místa a způsoby jejich odstranění. Stejně tak se hledají silné stránky a jejich možné vylepšení. Celkově tato snaha vede ke zvýšení efektivity vývojového týmu. 2.4 Hodnocení agilních metodik Osobně si myslím, že žádná metodika (ani tradiční přístup) nemůže zaručit úspěch každého projektu. Za nejvýznamnější faktor ovlivňující úspěch projektu považuji vlastnosti a schopnosti všech zainteresovaných lidí, které mají mnohem větší vliv než používaná metodika nebo nástroje. Vycházím z předpokladu, že tým rozumných, schopných a zkušených lidí si sám najde pro něj vhodné a potřebné postupy, jak kvalitně a v požadovaný čas (pokud je reálný) vyvinout požadovaný software. Pokud v týmu převládají lidé opačných vlastností a pokud ještě zastávají vedoucí pozice, pak rozsáhlejší a složitější projekt s velkou pravděpodobností skončí neúspěchem. Z jednotlivých prací a metodik autorů agilního manifestu je patrné, že jejich názory jsou stejné jako můj (uvedený v předešlém odstavci). Agilní metodiky tak nelze chápat jako univerzální návody jak tvořit software, ale je nutné je brát jako soubor doporučení, rad, návodů a možných přístupů, který nám poskytují na základě svých dlouhodobých zkušeností autoři metodik. Agilní metodiky obsahují řadu postupů, jejichž nevhodné použití týmu přinese další komplikace. V případech kdy tyto postupy použít lze, dokáží naopak urychlit a usnadnit vývoj software. Je tedy na odpovědnosti vedoucích pracovníků rozhodnout, zda lze metodiku nebo její část použít. V tabulce 2.1 uvádím kladné a záporné body použití agilních metodik, jejich poměr je vyrovnaný. Iterativní a inkrementální vývoj je nespornou výhodou, jsou určeny pevné termíny dodání jednotlivých verzí. Ty bohužel mají nezaručený rozsah, protože nelze dopředu určit, jaké komplikace se objeví a jak zredukují rozsah prováděné iterace. Není známý postup, jak rozsah zaručit, pravděpodobně žádný takový postup ani nemůže existovat. Pro zákazníka je lepší vědomí, že v daném termínu dostane verzi s nezaručeným obsahem, než čekání neznámou dobu na verzi v plném rozsahu. 7

2.4. HODNOCENÍ AGILNÍCH METODIK Kladné iterativní a inkrementální vývoj brzy první verze zdůrazňují význam komunikace regresní testování flexibilní reakce na změny optimalizace metodik Záporné nezaručené rozsahy verzí smlouva nelze formalizovat omezují dokumentaci testuje přímo autor nadprůměrné schopnosti nelze na částečný úvazek Tabulka 2.1: Vlastnosti agilních metodik Metodiky přistupují k implementační fázi velmi rychle, během krátké doby tak vyvinou první verzi software s omezenou funkčností. I tak ale většinou lze software již komerčně využít. Na začátku projektu te těžké odhadnout přesně cenu vývoje a podrobně určit jednotlivé milníky. Lze tedy těžce sepsat nějakou formálnější smlouvu. Pro agilní metodiky je vhodnější zákazník, který týmu důvěřuje a je ochoten přistoupit na neformálně sepsanou smlouvu. Pro zákazníka by mohl být vhodný tzv. team outsourcing, tedy pronajmutí a řízení celého týmu. Měl by tak lépe pod kontrolou své výdaje a práci týmu. Komunikace je pro vývoj důležitá. Myslím si, že každý tým na světě si toho je vědom. Považuji za klad agilních metodik, že se snaží o nastavení podmínek k efektivní komunikaci. Nelze však spoléhat pouze na přímou komunikaci. Důležité závěry a poznatky musí být poznamenané na nějaké místo, kde je půjde v případě potřeby snadno dohledat. Pokud by se dokumentace zcela vynechala, tým by se mohl dostat do problémů. Nelze spoléhat na vědomosti a znalosti obsažené jen v hlavě programátorů a zdrojovém kódu, lidé zapomínají a jejich vlastní kód jim časem nebude dávat smysl. Testování je další nesporně výhodná vlastnost. Rizikem však je, pokud programátor testuje vlastní výtvor. Připouštím však, že v agilním pojetí vývoje nelze čekat, až vytvoří test někdo další. Regresní testování poskytuje týmu velkou míru jistoty, protože jeho pomocí lze najít zavlečenou chybu ve všech částech systému. Z rostoucím objemem systému však i roste rozsah potřebných testů a tím rostou i náklady na jejich tvorbu, údržbu a běh. Proto považuji za vhodnější použití metody Risk Based Testing 3 (RBT), kdy se testování zaměřuje jen na nejvýznamnější část systému. Určení takové části je ale nejkomplikovanějším prvkem RBT. Agilní metodiky jsou ceněné pro svou schopnost flexibilní reakce na změnu požadavků. Aby toho byly schopné, potřebují mít v týmu schopné lidi. Tohle je ale slabé místo metodik, protože na trhu práce nemusí být dostatečný počet uchazečů, kteří mají požadované znalosti a zkušenosti. V průběhu projektu pravidelně věnují agilní metodiky určitý čas a úsilí k optimálnějšímu nastavení svých parametrů. Kontrolují správnost odhadů, hledají možná zlepšení. Vývojový proces se tak postupem času stává lépe ovladatelným a efektivnějším. 3. Informace lze nalézt na <www. riskbasedtesting. com/> 8

2.4. HODNOCENÍ AGILNÍCH METODIK Agilní metodiky je těžší realizovat v týmech zaměstnávajících studenty na částečný úvazek, protože nejsou k dispozici po celou dobu a přicházejí tak o část komunikace. Její zprostředkování nepřítomným je možné, ale zatíží a zpomalí to tým prací navíc. Agilní metodiky jsou zajímavým přístupem k tvorbě software, své uplatnění naleznou při projektech, ve kterých nejsou na začátku zcela jasné požadavky nebo se v průběhu projektu značně mění. Slibují časté a pravidelné dodávky software. Vyžadují úzkou spolupráci s uživateli. Agilní metodiky nelze použít při projektech, kde je provádění změn v průběhu projektu nákladné nebo dokonce nemožné. 9

Kapitola 3 Vybrané agilní metodiky Mezi nejznámější agilní metodiky patří Extrémní programování (XP) SCRUM Development Process Crystal metodiky Vlastnostmi řízený vývoj (FDD) Dynamic System Development Method (DSDM) Adaptivní vývoj software (ASD) Lean Development Testy řízený vývoj (TDD) Pro důkladnější zkoumání byly vybrány metodiky Extrémní programování, Crystal metodiky a Dynamic System Development Method, tato a následující kapitola 4 Případová studie se jim postupně věnují. Informace o ostatních metodikách je možné nalézt v přednášce Aleny Buchalcevové Agilní metodiky [ ], v knize Václava Kadlece Agilní programování [ ], v diplomové práci Tomáše Hajdina Agilní metodiky vývoje software [ ] nebo v práci Agile software development methods [11]. Každá podkapitola nejprve metodiky stručně charakterizuje. Následně jmenuje principy, na kterých jsou metodiky postavené. Zabývá se rolemi, které lze identifikovat v týmech eticích danou metodiku. Poté uvádí postupy metodik odvozené z jejich principů. Je popsán životní cyklus vývoje software podle zvolené metodiky. Na závěr je uvedeno stručné hodnocení metodiky. Některé detaily metodik jsou prezentovány až v následující kapitole 4 Případová studie, spolu s náčrtem řešení studie vybranou metodikou. Poslední podkapitola obsahuje přehledné srovnání vybraných metodik. 10

3.1. EXTRÉMNÍ PROGRAMOVÁNÍ 3.1 Extrémní programování Extrémní programování (XP) je jednou z nejznámějších agilních metodik. Pojmy XP a agilní metodiky jsou dokonce někdy nesprávně považovány za ekvivalentní. Tato podkapitola podrobněji popisuje tuto metodiku na základě informací získaných z knihy Extrémní pro gramování [12], jejímž autorem je Kent Beck. Kniha byla přeložena do češtiny před třemi lety, metodika jistě prošla řadou zlepšení, které zde tak nejsou zahrnuty. Extrémní programování vznikalo během devadesátých let minulého století na základě praktických zkušeností jeho autorů, kterými jsou Kent Beck a Ward Cunningham. Je posta vené na známých a běžných postupech, ale dotahuje tyto postupy do extrémů. Když se vy plácí revize, tak se reviduje neustále. Pokud je nutné testovat, tak se testuje několikrát denně. XP pomocí svých principů a postupů dovádí do extrému všechny části vývoje software jako jsou revize kódu, testování aplikace, návrh architektury, integrace systému a iterační vývoj. Stejně tak se XP snaží bojovat proti rizikům jako zpoždění harmonogramu, zrušení celého projektu, krachující systém, zvětšující se míra poruchovosti, nepochopení zadání, průběžné změny zadání, přemíra funkcí a fluktuace pracovníků. Základem celého vývoje software je pro XP psaní zdrojového kódu a testování. Pro střednictvím zdrojového kódu komunikují členové týmu. Výsledky spouštěných testů vy povídají o stavu projektu. XP vychází z představy, jak by vývoj vypadal, kdyby na něj bylo dost času. Vývojáři by psali dobře strukturovaný a řádně otestovaný kód. Psaní zdrojového kódu a testovaní se v metodice XP prolíná. Programátoři během dne střídavě píší jednotlivé testy a implementace, nejdříve test jedné funkčnosti, následně její im plementaci. Když test projde, přechází se na další funkčnost. Tento způsob vývoje řízeného testy je možné použít jako samostatnou metodiku Test Driven Development (TDD), Kent Beck ji popisuje v knize Programování řízené testy [ ]. Informace lze také nalézt v knize Václava Kadlece Agilníprogramování [ ] nebo diplomové práci Tomáše Hajdina Agilní me todiky vývoje software [6]. Další důležitou činností v XP je poslouchání. Kent Beck tvrdí, že nejlepším způsobem komunikace je rozhovor, a proto je XP navrženo tak, aby maximálně podporovalo a vynu covalo vzájemnou komunikaci jak mezi jednotlivými programátory, tak mezi programátory a zákazníkem. Konkrétně to zajišťují postupy s jménem párové programování a zákazník na pracovišti, které jsou spolu s dalšími postupy vysvětleny v kapitole 3.1.3 Postupy. Poslední podstatnou činností pro XP je navrhování. Navrhování provádějí všichni pro gramátoři každý den. XP klade důraz na zdrojový kód, a tak programátory nenutí ke kres lení diagramů, pokud to sami nechtějí. Návrh systému začíná psaním testů, kdy si musí programátoři dobře rozmyslet rozhraní vyvíjené aplikace, neboť právě toto rozhraní testují. Dalším postupem, kdy se programátoři plně věnují navrhování je reíaktorizace, tedy změna zdrojového kódu při zachování funkčnosti. Více je postup refaktorizace popsán v kapitole 3.1.3 Postupy, detaily pak obsahuje kniha Reíaktoring [ ], jejímž autorem je Martin Fowler. Při své práci se snaží programátoři navrhnout a udržet vyvíjený systém v nejjednodušší možné podobě, která může ještě fungovat a přitom přináší zákazníkovi očekávaný užitek. Pro řízení vývojového procesu uvažuje XP čtyři řídící proměnné, jsou to náklady, čas, 11

3.1. EXTRÉMNÍ PROGRAMOVÁNÍ kvalita a šíře zadání. Zákazníci nebo manažeři zadávají hodnoty tří libovolně zvolených proměnných, vývojový tým pak určí odpovídající hodnotu zbývající proměnné. Tento přístup vychází z jednoduchých úvah. Například když má málo lidí v krátkém čase udělat moc práce, jsou ve stresu a výsledky jejich snažení nedosahují odpovídající kvality. Ve většině případů stres a nereálné požadavky způsobí zpoždění projektu a s tím i zvýšené náklady. Právě z těchto důvodů XP říká, že týmu nelze nadiktovat hodnoty všech řídících proměnných, ale musí mu být dáno právo určit odpovídající hodnotu zbývající proměnné. Pokud nejsou manažeři s odpovědí spokojeni, mohou si vybrat jiné tři proměnné, ale nikdy nesmí určovat hodnoty všech čtyř proměnných. Za nejvhodnější volnou proměnou pak XP považuje právě šíři zadání. 3.1.1 Principy Tato část práce prezentuje principy XP tak, jak jsou uvedené v knize Kenta Bečka Extrémní programování [12]. Prvních pět principů je považovaných za hlavní, zbytek pak za doplňkové. Rychlá zpětná vazba Doba reakce je důležitá kvůli učení. Společnost se naučí, jak může systém nejlépe přispívat, a tento poznatek předá zpětnou vazbou během dnů či týdnů, a nikoliv během měsíců nebo let. Programátor se naučí, jak systém nejlépe navrhnout, implementovat a testovat, a tento poznatek předá zpětnou vazbou během vteřin či minut, a nikoliv během dnů, týdnů nebo měsíců. Předpoklad jednoduchosti Dělejme systém co nejjednodušší, složitější věci přidávejme až když jsou opravdu třeba. Vyvíjíme pro dnešek, ne pro zítřek. Věříme ve své schopnosti kdykoliv přidat požadovanou funkčnost, nemusíme s ní tedy počítat předem. Jednoduchý systém se lehce testuje, je přehledný a snadný na údržbu. Přírůstková změna Nelze udělat velkou změnu najednou. Návrh, plán a velikost týmu se musí měnit postupně. Nemůžeme vše navrhnout okamžitě, svůj návrh upřesňujeme za základě znalostí již vyvinutého systému a zjištěných problémů. Stejně tak nevíme, jak přesně bude vývoj probíhat, proto nemůže provést důkladné plánování hned na začátku. Nejprve vytvoříme hrubý odhad, který postupně upřesňujeme pro každou iteraci. Je nesmyslné mít na začátku projektu tým čítající deset programátorů, pokud máme práci sotva pro dva. Dokonce i přijmutí XP je postupné, po malých krocích. Nejdříve se použije XP na část, se kterou má náš vývoj největší problémy. Využití změny 12

3.1. EXTRÉMNÍ PROGRAMOVÁNÍ Nejlepší strategie je ta, která zachovává nejvíce možností a přitom skutečně vyřeší ten nejnaléhavější problém. Tento princip souvisí s předpokladem jednoduchosti. Vyvíjený systém je nejjednodušší možný, který pokrývá všechny klíčové požadavky. Přidanou hodnotou využití změny je pak možnost rychle reagovat na změněný požadavek a uvedení nové funkčnosti do provozu dřív než konkurence. Kvalitní práce Práce bude tým bavit, jen pokud ji bude odvádět kvalitně, tedy kvalita není ve skutečnosti volná proměnná, může nabývat jen dvou hodnot a to vynikající" a neuvěřitelně skvělá". Kvalitní práce je důležitou složkou XP, tuto metodiku není možno provozovat s týmem neobsahujícím velmi zkušené programátory. Tým se nemusí skládat jen z výborných programátorů, musí však obsahovat alespoň nějaké, kteří budou svým vlivem zdokonalovat méně zkušené programátory. Výuka poznatků Metodika XP se zaměřuje na výuku strategií k získávání poznatků o tom, kolik testování, navrhování, refaktorizace a všeho ostatního bychom měli provádět. Těmto strategiím dává přednost před dogmatickými postupy, jak dělat určitou činnost. Malá počáteční investice Nízké rozpočty nutí programátory a zákazníky, aby zredukovali své požadavky a přístupy. Většinou všichni vystačí s nižšími prostředky, než které by chtěli. Prostředky však mohou být také příliš malé. Hraní na výhru Vývoj programového vybavení hraný na výhru dělá všechno, co týmu pomůže vyhrát a nedělá nic, co k výhře nepomůže. Opakem je hraní, aby se neprohrálo, kdy se vše dělá předpisově, aby jsme byli krytí, když se projekt nepovede. Konkrétní experimenty Neotestovaná rozhodnutí představují riziko, že nebudou správná. To znamená, že debata o návrhu nebo o požadavcích by měla vyústit v řadu experimentů, které prověří jejich realizovatelnost. Všechna abstraktní rozhodnutí by měla být takto otestovaná. Otevřená a upřímná komunikace Dobrá komunikace je jeden z nejnutnějších předpokladů úspěšného vývoje software. Pokud je dlouhá doba odezvy, nebo někdo něco podstatného nesdělí ostatním, protože zapomněl nebo se bál, má to negativní vliv na celkový vývoj. Programátoři proto musejí mít absolutní svobodu, aby mohli vyjadřovat své obavy a získávat podporu, aby mohli sdělit nedobrou zprávu zákazníkům a manažerům, aby ji mohli sdělit včas a aby za ní nebyli potrestáni. 13

3.1. EXTRÉMNÍ PROGRAMOVÁNÍ Práce v souladu s lidskými instinkty Lidé rádi vyhrávají. Lidé se rádi učí. Lidé se rádi stýkají s jinými lidmi. Lidé mají rádi, když jsou 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. Lidé jsou rádi, když jejich software funguje. XP se shoduje s pozorováním programátorů v divočině" cituje Kent Beck ve své knize [12]. Přijetí odpovědnosti Odpovědnost musí být přijata, nikoliv předána. Pokud však tým dospěje k rozhodnutí, že je třeba splnit určitý úkol, někdo si ho bude muset vybrat bez ohledu na jeho nepříjemné stránky. Místní přizpůsobení XP nemůže být univerzální kuchařkou. Každý tým, který chce XP přijmout, si ho musí přizpůsobit vlastním podmínkám. XP může jen upozornit na následky při odbočení od některých jeho principů. Cestování nalehko Udržované nástroje by měli splňovat tři vlastnosti, měl by jich být malý počet, měli by být jednoduché a hodnotné. Potřeba jsou jen testy a zdrojový text. Poctivé měření Měření je podstatné při vývoji, protože slouží ke sledování a kontrole jeho průběhu. Důležité je pro měření zvolit odpovídající přesnost, která bude mít dostatečnou vypovídající hodnotu a nebude zatěžovat tým více než je nutné. 3.1.2 Role XP v týmu uvažuje následující role. Některé mohou být obsazené stejným člověkem. Například povinnosti kouče a stopaře většinou plní jeden člověk. Kouč Má na starosti celý tým. Je k dispozici jako vývojový partner, zejména pro nové programátory. Sleduje dlouhodobé cíle refaktorizací. Pomáhá programátorům s jednotlivými technickými dovednostmi jako testování, formátování a refaktorizace. Vysvětluje proces manažerům na vyšších úrovních. Tým by měl řídit spíše jemným nasměrováním než pomocí autoritativních příkazů. Stopař Jeho úkolem je sledovat aktuální metriky a hlídat, zda projekt pokračuje podle plánů a přání. Zároveň zajišťuje, aby tým viděl, jak si na tom právě stojí. Toho dosahuje vyvěšováním různých statistik na tabule v pracovní místnosti. 14

3.1. EXTRÉMNÍ PROGRAMOVÁNÍ Programátor Je základem týmu, odhaduje pracnost zadání a jednotlivých úkolů během plánovací hry. Psaním unit testů analyzuje požadavky a navrhuje rozhraní vyvíjeného systému. Komunikuje se zákazníkem a ostatními programátory při upřesňování požadavků a jejich řešení. Během párového programování dva programátoři píší testy, zdrojové kódy a integrují změny do systému. Zákazník Rozhoduje, co se má dělat. Během plánovací hry píše karty zadání, následně upřesňuje nejasnosti, a tak se učí psát karty přesněji. V případě komplikací při vývoji rozhoduje, která část funkčnosti má menší prioritu a může být přesunuta do následující iterace a dodána až v další verzi. Zákazník s pomocí testera vytváří testy funkcionality, které slouží jako akceptační testy pro dodaný systém. Tester Většinu testování v XP zajišťují programátoři, role testera pomáhá zákazníkovi vybírat a psát testy funkcionality. Zajišťuje správný chod všech testovacích nástrojů. Má na starosti pravidelné spouštění testů funkcionality a seznámení týmu s výsledky těchto testů. Konzultant Pomáhá týmu ve specifických problémech, na které tým občas narazí. Problémy však nikdy neřeší sám někde v ústraní, ale vždy s alespoň jedním programátorem, který se tímto od něj učí. Velký šéf Zodpovídá za vývojový proces jako celek. Zajišťuje nové lidi, když jsou potřeba. Neměl by se týmu plést do cesty, pokud nemá podezření, že se tým ubírá špatným směrem. V takovém případě je na týmu, aby svoje jednání obhájilo. Když to tým nedokáže, směřoval vývoj nejspíše špatným směrem a velký šéf splnil svou povinnost, když nenechal tým dál pokračovat, ale naopak ho přiměl k zastavení a zamyšlení. 3.1.3 Postupy XP je založeno na dvanácti postupech, které jsou stručně popsány v této kapitole, více informací lze najít v knize Extrémní programování [ ]. Tyto postupy použité samostatně mohou způsobit projektu vážné problémy, ale dohromady tvoří silný celek, který urychluje vývoj software. Plánovací hra Plánovací hra slouží v XP k řízení projektu. Zákazník jejím prostřednictvím rozhoduje o šíři celkového zadání, stanovuje priority požadavků, určuje jaké funkčnosti spolu souvi- 15

3.1. EXTRÉMNÍ PROGRAMOVÁNÍ sejí a mají se tak objevit společně v další verzi uvolněného software, podle svých záměrů (například účast na veletrhu) upravuje datum, kdy se mají jednotlivé verze uvést do provozu. Programátoři během plánovací hry odhadují potřebný čas na vývoj jednotlivých požadavků, radí zákazníkovi při technických rozhodnutích (například volba databáze) a vytvářejí podrobný harmonogram právě začínající iterace. Malé verze Pro zákazníka je důležité, aby novou funkčnost mohl začít používat co nejdřív, proto XP dodává malé verze a v krátkých časových intervalech v řádu měsíce nebo dvou, v případě rozsáhlejšího systému maximálně po půl roce. Metafora Metafora zajišťuje komunikaci mezi vývojovým týmem a zákazníkem. Je společným příběhem", kterým popisuje zákazník provádění stávajících procesů ve své společnosti a programátoři mluví o chování vyvíjeného software. V XP metafora zastupuje význam architektury. Jednoduchý návrh Vyvíjený software má neustále nejjednodušší možnou podobu, která pokrývá aktuální požadavky zákazníka. Nic se nevyvíjí dříve, než je to potřeba, protože se může stát, že to nebude potřeba nikdy. Testování Programátoři pomocí testů jednotek ověřují svůj zdrojový kód a udržují si tak víru ve své schopnosti a důvěru k dříve vyvinuté části systému. Zákazník z výsledků testů funkcionality pozná, jaká část systému je již úspěšně vyvinutá a kolik funkčnosti ještě chybí. Refaktorizace Programátoři pomocí refaktorizace udržují zdrojové kódy, tak aby neobsahovaly duplicity, aby šlo lehce přidat novou funkčnost, aby zvýšili čitelnost zdrojového kódu, aby zlepšili návrh aplikace atd. Při této činnosti jim pomáhají hotové testy, které jim dávají jistotu, že se chování systému nezměnilo. Důležité je, aby programátoři rozlišovali, kdy refaktorují a kdy vyvíjí novou funkčnost, a nikdy tyto dvě činnosti neprováděli současně. Párové programování Při XP se zdrojový kód píše v páru, jeden programátor píše nový test, kód nebo refaktoruje, druhý mu přitom radí a hlídá, jestli výsledek činnosti prvního odpovídá celkové strategii. První programátor při své práci uvažuje jen o části systému, kterou mění či doplňuje. Důsledky pro systém jako celek musí mít na mysli druhý, v případě potřeby musí prvního opravit. Páry se mění většinou dvakrát za den. 16

3.1. EXTRÉMNÍ PROGRAMOVÁNÍ Společné vlastnictví Všichni členové týmu mají stejnou odpovědnost za celý vyvíjený systém, proto pokud objeví někde chybu nebo příležitost ke zlepšení, mají pravomoc (dokonce povinnost) chybu opravit nebo zlepšení realizovat sami, namísto aby upozornily odpovědnou osobu a čekali, až tato osoba bude mít čas. Nepřetržitá integrace Procesy testování a integrace se opakují v XP během velmi krátkého času, vždy alespoň jednou za den. Pro integraci je vyhrazen přímo jeden počítač, ke kterému si dvojice sednou, když dokončí implementaci svého úkolu. Na tomto vyhrazeném počítači pak provedou integraci s již vyvinutým systémem, to znamená vyřeší všechny případné kolize, provedou překlad zdrojových kódů a následně spustí testy. Pokud testy neprojdou na sto procent, musí chyby odstranit nebo svůj kód zahodit a začít znovu implementovat. 40hodinový týden Přesčasy jsou známkou problémů při vývoji software. Unavení programátoři nemůžou vyvíjet rychle a kvalitně, proto XP zakazuje přesčasy v dvou následujících týdnech. Pokud je potřeba, aby byl tým v práci dlouhodobě přesčas, je nezbytné rychle identifikovat a odstranit problém, který to způsobil. To může nakonec samozřejmě způsobit i přeplánování zbytku iterace. Zákazník na pracovišti Všechny agilní metodiky mají společný požadavek, aby byl zákazník kdykoliv k dispozici pro upřesnění nejasností v zadání a poskytnutí konzultací z oboru podnikání zákazníka. Nejvhodnější je, pokud je zákazník v jedné místnosti s týmem a je tak možná rychlá a přímá komunikace. Zákazník sice musí být k dispozici kdykoliv, těžko ho však bude tým neustále zahlcovat dotazy, a tak se může zákazník po většinu času věnovat vlastní práci. Standardy pro psaní zdrojového textu Standardy jsou nutné kvůli společnému vlastnictví kódu, všichni programátoři musí znát a dodržovat standardy, které si celý tým vzal za své, aby se snadno a rychle vyznali v kódu, který psal někdo jiný. 3.1.4 Životní cyklus Metodika XP se přizpůsobuje podmínkám projektu a potřebám týmu, životní cyklus se proto bude projekt od projektu lišit. V této části práce je popsáno, jak probíhá ideální životní cyklus. Průzkum (Exploration) 17

3.1. EXTRÉMNÍ PROGRAMOVÁNÍ Každý projekt začíná průzkumem. Během této fáze si programátoři zkouší navrhnout a částečně realizovat různé architektury plánovaného systému. Ze svých pokusů pak vyberou nejvhodnější architekturu. Zároveň se učí odhadovat, kolik času jim zaberou jednotlivé úkoly, porovnáním odhadovaného a skutečně potřebného času. Pokud úspěšné zvládnutí začínajícího projektu vyžaduje po programátorech znalosti nové technologie, seznamují se s touto technologií právě v této fázi. Zároveň tato fáze slouží k ověření výkonnostních limitů požadovaného systému. Ověření je prováděno pomocí vhodných prototypů. Ve stejné době se zákazník učí psát své požadavky v podobě karet zadání, aby byly srozumitelné pro programátory. V této etapě by měl sepsat požadavky na první verzi systému. Délka etapy je závislá na znalostech a zkušenostech programátorů s danými nástroji, technologiemi a oborem podnikání zákazníka, pohybuje s v rozmezí několika týdnů až měsíců, přičemž by neměla přesáhnout půl roku. Plánování Etapa plánování navazuje na etapu průzkumu. Pokud se během průzkumu zákazník i tým dostatečně připraví, pak samotná etapa plánování trvá jeden či dva dny, během nichž se vyberou karty zadání pro první verzi systému a dohodne se termín jejího uvolnění. Tento termín bývá v období následujících dvou až šesti měsíců. Pokud je tým schopen první verzi dodat dřív, je to jen dobře, ale většinou se to nestává. Naopak doba delší než šest měsíců znamená zvýšení rizika. Iterace do uvolnění první verze Iterace, které probíhají do uvolnění první verze, trvají jeden až čtyři týdny. Pro první iteraci se vybírají taková zadání, aby pokryla celý systém, tedy aby výsledkem první iterace byla kostra systému. Která zadání jdou do dalších iterací rozhoduje zákazník na základě svých priorit. Na konci každé iterace by měla být malá oslava dodání plánované funkcionality. Výsledkem poslední iterace je pak první verze software určená k nasazení do ostrého provozu. Zprovozňování Tato etapa slouží k nasazení první verze systému k zákazníkovi. Nejprve je nutné systém důkladně otestovat, případně pomocí paralelního testování nového a starého systému. Zároveň se v této době tým pokouší o vyladění výkonu, protože má už dostatek znalostí o systému a zároveň má k dispozici provozní hardware. Během této etapy většinou dochází ke zkrácení iterace ze tří týdnů na jeden. Zároveň dochází i ke zpomalení vývoje, protože veškeré změny musejí být lépe promyšleny, neboť systém je už nasazen do ostrého provozu. Nové myšlenky tykající se implementace se sepíší a odloží do následujících iterací. Nasazení systému je vhodné uzavřít menší oslavou, jde totiž o významný okamžik celého projektu. 18

3.1. EXTRÉMNÍ PROGRAMOVÁNÍ Údržba Po nasazení systému do ostrého provozu dochází ke zpomalení vývoje. Jedním z důvodů je, že programátoři musejí vedle implementace nových úkolů zároveň zajišťovat servis běžící aplikace. Proto je vhodné v tento okamžik přibrat nové programátory do týmu. Jejich rychlé zaškolení je realizováno pomocí párového programování se zkušenějším kolegou. Vývoj dalších verzí začíná vždy průzkumem, v rámci něhož se můžeme pokusit o odvážnou změnu architektury nebo může zákazník přijít s novým přelomovým zadáním. Tým však musí být více opatrný, protože pracuje s ostrými daty a běžícím systémem. Zároveň se musí snažit o co nejčastější slučování nového zdrojového kódu s provozním, aby se později vyhnul velkým integračním problémům. Tým může předem odhadovat, jak jeho efektivitu sníží souběžný servis běžícího systému. Důležité je tyto odhady během údržby potvrdit nebo vyvrátit pomocí měření. Stejně tak je vhodné programátory poskytující servis postupem času prostřídat. Během servisu se mohou naučit mnoho důležitých věcí, na druhou stranu jim jejich práce nepřijde tak zábavná, jako při implementaci nových úkolů. Smrt Smrt znamená konec vývoje systému. Ten může nastat ze dvou důvodů. Méně častým důvodem je, že zákazník nemá už žádné nové zadání, které by chtěl realizovat a systém je dokonale vyladěný, tudíž vývojový tým nemá, co by víc udělal. Castěji je však ukončení vývoje způsobeno neschopností vývojového týmu přidat efektivně novou funkcionalitu. Během této etapy se sepisuje několikastránkový dokument o vyvinutém systému, který by měl týmu pomoci, kdyby se k systému po čase vrátil. Taktéž je vhodné prozkoumat příčiny, které vedly k ukončení vývoje, a vzít si z nich poučení do dalších projektů. Jednotlivé etapy životního cyklu vývoje software podle metodiky XP shrnuje obrázek 3.1 převzatý z práce Agile software development methods [11]. 3.1.5 Hodnocení Metodika XP se hodí do prostředí, ve kterém se požadavky často mění nebo přicházející až během samotného vývoje, neboť je změně otevřená, požadavky v podobě karet zadání můžou přijít kdykoliv a nejpozději v následující iteraci na ně tým i reaguje. Na druhou stranu XP potřebuje prostředí, ve kterém je cena změny víceméně konstantní, nelze ho tedy použít tam, kde cena změny s postupem času rapidně roste. V těchto případech je nejdříve nutná důkladná analýza a celý vývoj by nešel s XP skloubit. Dále v XP vidím čtyři potencionální rizika. Hrozí, že programátory refaktorizace zaujme tak, že ji budou dělat pořád a nevyvinou žádnou novou funkcionalitu. Vývoj se může dostat do slepé uličky, ze které nebude cesta ven, jen proto, že se celou dobu navrhuje pro dnešek a nemyslí se na zítřek. Dalším nedostatkem je fakt, že během plánování se dostatečně neuvažuje závislosti mezi jednotlivými úkoly. A za poslední nedostatek, částečně řešený pomocí 19

3.2. CRYSTAL METODIKY PRŮZKUM I PLÁNOVÁNÍ PRAVIDELNĚ DOPLŇOVÁNO/ KARTY ZADÁNI *Í PŔÍSTÍ ITERACE ITERACE PRED UVOLNENÍM NEPRETRŽITÁ. REVIZE. _V^ *L p AROVÉ PROGRAMOVÁN' I Z Z N O > O 0Ĺ a_ N I { NAVRH r..--. -J ".-v -. i TĚSTll TESTOVÍWi KARTY ZADANÍ Priorita Pracnost ZPĚT N A VAZBA / NEPRETRŽITÁ INTEGRACE Obrázek 3.1: Životní cyklus podle XP párového programování, považuji skutečnost, že zdrojový kód a jeho test píše stejný člověk, tudíž hrozí, že jeho chyba bude jak v kódu, tak v testu a ve výsledku způsobí funkční test a tedy neodhalení této chyby. Metodiku XP celkově považuji za zajímavou možnost, jak vyvíjet software. Spíše než její samostatné použití bych však doporučil kombinaci s jinou metodikou, která bude robustnější a odstraní nedostatky XP. Články o společném použití XP a metodik jako RUP, SCRUM, Prince a dalších lze najít na serveru Aliance agilního vývoje software [?]. 3.2 Crystal metodiky Crystal není jméno jedné metodiky, ale slouží k označení celé rodiny" metodik, které vymyslel Alistair Cockburn. Jednotlivé metodiky jsou pojmenované podle barev a navzájem se odlišují svou vhodností pro různě velké týmy a různě složité projekty. Čím tmavší barva je, tím je metodika robustnější a vhodnější pro rozsáhlejší, případně kritičtější projekty. Jednotlivé barvy jsou čirá, žlutá, oranžová, červená, hnědá, modrá a fialová. Tyto metodiky nejsou přesné kuchařky", ale obsahují řadu rad, jak je přizpůsobit vlastním potřebám. Vhodná metodika pro projekt se volí na základě hodnot tří následujících vlastností projektu. První vlastností je velikost vývojového týmu, tedy kolik lidí se účastní vývoje. Druhou vlastností je kritičnost projektu, která ohodnocuje dopad selhání systému a může nabývat čtyř hodnot. 20

3.2. CRYSTAL METODIKY Ztráta komfortu (C) je nejmenší dopad, kdy lze systém i nadále používat, ale uživatele to stojí zvýšené úsilí. Malá ztráta peněz (D) má větší dopad, v tomto případě firma kvůli selhání ztratí nějaké finance. Velká ztráta peněz (E) je podobný dopad, jako předchozí, tentokrát ovšem firma ztrácí nezanedbatelnou část svých financí. Ztráta lidských životů (L) je nejhorším možným dopadem. Poslední vlastností, podle které se řídí výběr správné metodiky, je priorita projektu. Tato vlastnost vyzdvihuje tu stránku projektu, která má pro nás největší význam. Můžeme se rozhodnout, zda budeme průběh projektu optimalizovat pro maximální produktivitu vývoje nebo dáme přednost například důkladnému měření postupujícího projektu. Volbu vhodné metodiky ilustruje obrázek 3.2 převzatý z práce Agile software development methods [1 ]. Ctverečkovaně jsou na obrázku označeny oblasti, které jsou nedosažitelné nebo pro které neexistuje příslušná Crystal metodika. Kritičnost D6 D20 C40 D30 :e C20 C4a CSO Čirá Zluta Oranžová Červená Velikost týmu Obrázek 3.2: Volba odpovídající metodiky z rodiny" Crystal Robustnější metodiky jsou postupně navrhovány a ověřovány v praxi. Já se v této práci zaměřil na základní metodiku s čirou barvou (Crystal Clear), která spadá do kategorie D6, 21

3.2. CRYSTAL METODIKY tedy je určená pro tým čítající od dvou do osmi lidí, kdy při selhání firma ztrácí malou část financí. Má volba byla ovlivněna ostatními metodikami, neboť jsem chtěl srovnávat metodiky určené pro přibližně stejně velké týmy. Mou volbu ovlivnil také fakt, že v knihovně je k dispozici poměrně nová kniha Crystal Clear [5], ze které jsem tak mohl čerpat. 3.2.1 Principy Metodika Crystal Clear vychází ze sedmi principů, z nichž první tři jsou nutné pro fungování metodiky a další čtyři jen zvyšují pravděpodobnost úspěšnosti celého projektu, posouvají projekt dál v zóně bezpečnosti" (Safety zone). Alistair Cockburn v druhé kapitole své knihy Crystal Clear [5] uvádí dále jmenované principy jako vlastnosti metodiky Crystal Clear. Pravidelné dodávky (Frequent delivery) Pro vývoj systémů je důležité pravidelné uvolňování nových verzí. Získáváme tak častou a pravidelnou zpětnou vazbu od uživatelů. Stejně tak má vedení lepší přehled o průběhu vývoje. Z pohledu tohoto principu nemá délka jedné iterace takový vliv, jako interval mezi uvolněním jednotlivých verzí systému. Pro programátory může být důležité, aby zadaní nebylo během iterace měněno a oni se tak mohli plně soustředit na řešení jednotlivých úkolů. Zdokonalování procesů (Reflective improvement) Při práci je důležité poučení se z vlastních chyb. Proto se tým jednou za čas sejde, aby prodiskutoval proces vývoje, našel jeho silné i slabé stránky a pokusil se najít způsob, jak proces v dalších iteracích vylepšit. Pravidelnost, stejně jako průběh a druh výstupu těchto zdokonalovacích schůzek, je ponechána na úvaze týmu. Metodika jen trvá na jejich konání a dává nezávazné rady. Podprahová komunikace (Osmotic communication) Jedná se o velmi důležitý princip, objevující se i v jiných metodikách, který lze bohužel snadno realizovat jen v malých týmech s vhodným návrhem pracovního místa. Spočívá ve společné práci všech vývojářů na jednom místě. Každý člen týmu je tak přítomen a podprahově vnímá každou relevantní komunikaci. Pokud má co říct, může rychle a efektivně sdílet své vědomosti. Přátelské prostředí (Personal safety) Cílem je pracovní kolegy vnímat jako přátele. Programátor se nesmí bát oznámit šéfovi problémy s vývojem některé části systému. Musí umět upozornit kolegu na chybu v jeho kódu nebo naopak být schopen požádat o pomoc s vlastním kódem. Nesouhlasné názory na návrh architektury se nesmí projevit ve vzájemných citech. Takové prostředí se kladně projeví i při zdokonalování vývojového procesu. 22