Agilní metodiky vývoje software

MASARYKOVA UNIVERZITA V BRNĚ FAKULTA INFORMATIKY

^ T I S mp

Agilní metodiky vývoje software DIPLOMOVÁ PRÁCE

Bc. Tomáš Kotrla

Brno, P o d z i m 2005

Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypra­ coval 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 soft­ warové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 Develo­ pment 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 Struktura práce 2 Agilní metodiky 2.1 Charakteristika agilních metodik 2.2 Srovnaní s klasickým přístupem 2.3 Manifest agilního vývoje software 2.4 Hodnocení agilních metodik 3 Vybrané agilní metodiky 3.1 Extrémní programování 3.1.1 Principy 3.1.2 Role 3.1.3 Postupy 3.1.4 Životní cyklus 3.1.5 Hodnocení 3.2 Crystal metodiky 3.2.1 Principy 3.2.2 Role 3.2.3 Postupy 3.2.4 Životní cyklus 3.2.5 Hodnocení 3.3 Dynamic Systems Development Method 3.3.1 Principy 3.3.2 Role 3.3.3 Postupy 3.3.4 Životní cyklus 3.3.5 Hodnocení 3.4 Srovnání vybraných metodik 3.4.1 Principy 3.4.2 Role 3.4.3 Postupy 4 Případová studie 4.1 Výchozí podmínky 4.2 Extrémní programování 4.3 Crystal Clear 4.4 Dynamic Systems Development Method 4.5 Srovnání životních cyklů 5 Závěr Literatura

1 1 2 2 3 5 7 10 11 12 14 15 17 19 20 22 23 24 27 29 29 30 31 33 34 35 37 37 39 41 44 44 45 49 51 52 54 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 28 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 [8], 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, srov­ ná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 srov­ ná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 vybra­ ný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 methodolo­ gies", 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 meto­ dik, 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 ICT1 získává ekonomická stránka vývoje software na významu. Pokud chce firma v konkurenci obstát, musí být schopná dodat soft­ ware 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 ak­ ceptaci 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 hlav­ ní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 pro­ vozu, 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í me­ todiky 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ůraz­ ně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 [4] Aleny Buchalcevové.

Funkcionalita

Zdroje fi cíti

>- i

promáimé Zdroje

Tradiční přístupy

Funkcionalita

A gilní

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 pode­ psanou specifikaci na začátku projektu, která se dále v průběhu projektu nemění. Implemen­ tace 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, ji­ ný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í [3], agilní metodiky produ­ kují mnohem méně formální dokumentace, vycházejí totiž z přesvědčení, že základním, jed­ noznač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ě ob­ jemný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 eli­ minuje 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í meto­ diky 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 komu­ nikace 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í specifi­ kace, v průběhu během občasných doplňujících schůzek, případně při předvádění proto­ typů a nakonec během akceptace dodaného software. Lze tedy říci, že komunikace je cel­ kově 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é testo­ vá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žado­ vá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 spo­ leč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 [1], zastřešující jejich společnou činnost a byl sepsán Manifest agilního vývoje software [2], 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ác­ lava 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 iden­ tifikované 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 re­ alizace 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řes­ ně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 zdro­ jový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ý soft­ ware 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 hle­ dají 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 schop­ nosti 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ěpo­ dobností 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 uni­ verzá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 meto­ diku 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 do­ dá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ákaz­ ní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 jednot­ livé 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 tes­ tuje 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 Testing3 (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. r i s k b a s e d t e s t i n g . 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ý úva­ zek, protože nejsou k dispozici po celou dobu a přicházejí tak o část komunikace. Její zpro­ stř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 pro­ jektu 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 meto­ diky a Dynamic System Development Method, tato a následující kapitola 4 Případová stu­ die se jim postupně věnují. Informace o ostatních metodikách je možné nalézt v přednášce Aleny Buchalcevové Agilní metodiky [4], v knize Václava Kadlece Agilní programování [3], v diplomové práci Tomáše Hajdina Agilní metodiky vývoje software [6] 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 eti­ cí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é hod­ nocení metodiky. Některé detaily metodik jsou prezentovány až v následující kapitole 4 Případová stu­ die, spolu s náčrtem řešení studie vybranou metodikou. Poslední podkapitola obsahuje pře­ hledné 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 [10]. Informace lze také nalézt v knize Václava Kadlece Agilní programování [3] 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 refaktorizace, 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 Refaktoring [9], 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ěn­ ný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žadova­ nou 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 po­ stupně. 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ři­ jmutí 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ý sys­ tém je nejjednodušší možný, který pokrývá všechny klíčové požadavky. Přidanou hodno­ tou 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 sku­ teč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 de­ bata 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. Po­ kud je dlouhá doba odezvy, nebo někdo něco podstatného nesdělí ostatním, protože zapo­ mně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é pro­ gramá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 ma­ naž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. Komuni­ kuje 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. Ne­ mě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 infor­ mací lze najít v knize Extrémní programování [12]. 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 souvi15

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 pro­ vozu. 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 vy­ tvář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 archi­ tektury. 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ů funkci­ onality 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 dupli­ city, 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 do­ plň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 in­ tegraci 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 dispo­ zici 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í ži­ votní 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 vybe­ rou 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í vhod­ ných prototypů. Ve stejné době se zákazník učí psát své požadavky v podobě karet zadání, aby byly sro­ zumitelné 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, tech­ nologiemi 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í ite­ raci 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é funkciona­ lity. 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é sys­ té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 od­ váž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 sys­ té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řípa­ dech 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

PLANOVÁNi

ITERACE PRED UVOLNENÍM

I

NEPRETRŽITÁ

. REVIZE . PRAVIDELNĚ

DOPLŇOVÁNO/

KARTY ZADÁNI * Í PŔÍSTÍ ITERACE

Ji^_

NÁVRH

KARTY ZADÁNI

O

>

VL

O

0Ĺ

PÁROVĚ PROGRAMOVÁN'

{

_ . ' Pracnosl ZPĚT N A VAZBA Priorita

/

I

a_ N

r..--. -J ".-v - •. i TESTll

TESTOVÁWi

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 robust­ ně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é vy­ myslel 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. Jednot­ livé 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í pro­ jektu. První vlastností je velikost vývojového týmu, tedy kolik lidí se účastní vývoje. Dru­ hou vlastností je kritičnost projektu, která ohodnocuje dopad selhání systému a může na­ bý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 roz­ hodnout, 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 [11]. 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

D4Q

D30

•:e

C20

C4a

CSO

Čirá

Žlutá

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 meto­ diky 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 fun­ gování metodiky a další čtyři jen zvyšují pravděpodobnost úspěšnosti celého projektu, po­ souvají 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 čas­ tou 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 za­ daní 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

3.2. CRYSTAL METODIKY Pozornost (Focus) V tomto principu se skrývají dvě velké myšlenky. Vývojář musí mít na paměti, které dva úkoly z probíhající iterace má na starost. Práce na těchto úkolech má pro něj pak nej­ větší prioritu. Aby se této práci mohl plně věnovat zajišťuje druhá myšlenka. Vývojář dělá minimálně dva pracovní dny práci pro jeden projekt, pak může další dva dny dělat pro jiný projekt. Nemusí tedy často přeskakovat mezi úkoly pro různé projekty. Každý den má zaručené dvě hodiny, kdy nebude od své práce vyrušován.

Dostupnost uživatelů Programátoři během vývoje si často potřebují ujasnit zadání, proto je potřeba aby kom­ petentní (expertní) uživatel byl dostupný v dostatečně krátkém čase. Je potřeba rozlišit kon­ zultace s uživateli od konzultací s doménovým expertem (Bussiness expert), který je větši­ nou přímo součástí týmu. Realizováno to je například tak, že uživatel je pravidelně jednou týdně osobně k dis­ pozici na společné schůzce se všemi programátory a zbytek týdne konzultuje s vývojáři případné problémy telefonicky.

Technické vybavení Rychlý a kvalitní vývoj systémů je potřeba podpořit patřičným technickým vybavením a osvědčenými postupy. Použití konfiguračního managementu a spouštění automatizova­ ných testů musí být pro tým samozřejmostí. Významnou roli také hrají krátké iterace a pře­ devším častá integrace nových částí s existujícím systémem.

Uvedené principy jsou společné pro všechny metodiky rodiny Crystal, s výjimkou prin­ cipu Podprahová komunikace. Tento princip je v ostatních metodikách rodiny hůře realizo­ vatelný, protože vývojový tým je už moc velký, případně rozmístěn do více kanceláří. 3.2.2 Role Crystal clear se od ostatních barev liší především tím, že se projektu účastní pouze jeden tým, který sdílí společnou kancelář. Tento tým obsahuje maximálně osm lidí, proto jeden člověk většinou zastává několik z uvedených rolí. Práci rolí tester nebo písař, naopak větši­ nou dělá kdokoliv v týmu, kdo má zrovna čas.

Sponzor (Executive Sponsor) Stejně jako metodiky DSDM má tato role na starost financování projektu, na který se dívá z dlouhodobého pohledu. V krátkodobém poměru balancuje priority jednotlivých po­ žadavků, rozsah a cenu plánovaných verzí. 23

3.2. CRYSTAL METODIKY Uživatel (Expert user) Jedná se o zástupce uživatelů, kteří budou používat nebo již používají vyvíjený systém. Týmu je užitečný svými konzultacemi a testováním jak funkčních vlastností, tak použitel­ nosti systému. Zná četnosti jednotlivých obchodních procesů a souvisejících operací. Radí při návrhu systémových rozhraní. Hlavní vývojář (Lead designer) Člověk v této roli dělá stejnou práci jako ostatní obsazení v roli vývojář, rozdíl je však v tom, že znalosti hlavního vývojáře v oblasti návrhu architektury, programování systému a projektových procesů jsou na mnohem vyšší úrovni. Důležité nebo složité úkoly proto obstarává tato role. V malém týmu, který má Crystal Clear, se málokdy najde víc než jeden člověk schopný zastávat tuto roli. Vzhledem k důležitosti role bývá tento jediný člověk často přetěžován. Je tedy potřeba, aby maximum svých jednodušších úkolů delegoval na ostatní. Vývojář (Designer-programmer) Navrhování bez programování může produkovat těžce realizovatelné návrhy, protože osobě chybí právě zpětná vazba z programování. Proto každý člověk v roli vývojáře systém navrhuje i programuje. Doménový expert (Business expert) Na rozdíl od uživatele musí mít tato role všeobecný přehled o podnikání zákazníka. Ví jak jednotlivé procesy podnikání probíhají, jakými se řídí pravidly, jak často se mění apod. Koordinátor (Coordinator) Koordinuje práci ostatních, zaznamenává a zpřehledňuje průběh projektu pro sponzora. Musí mít dobré společenské cítění, schopnosti podporovat diskusi a urovnávat spory. Tester (Tester) Testuje vyvíjený systém a objevené chyby zaznamenává do seznamu chyb (Bug report). Písař (Writer) Má na starost tvorbu uživatelské dokumentace (User Help Text). 3.2.3 Postupy V metodice Crystal Clear se místo o praktikách mluví o strategiích a technikách. Metodika ovšem nediktuje použití žádné strategie ani techniky, v této oblasti dává týmu úplnou svo­ bodu. Tým tedy může zůstat u svých naučených postupů, případně může použít postupy z jiné metodiky než z rodiny Crystal. 24

3.2. CRYSTAL METODIKY Pro usnadnění přijmutí Crystal Clear jako nové metodiky Alistair Cockburn ve své knize [5] dává zájemcům do začátku alespoň výběr doporučených postupů. Jedná se o následují­ cích pět strategií a sedm technik. Strategie jsou: Průzkum (Explory 360) Nejdříve se zkoumá, zda má celý projekt vůbec smysl. Jestli je realizovatelný za rozum­ ných ekonomických podmínek. Jestli má tým dostatek zkušeností s potřebnými technolo­ giemi. Celý průzkum trvá od několika dnů po jeden až dva týdny, jeho výsledkem je buď spuštění projektu nebo jeho zamítnutí. Při rozhodování se zjišťuje přidaná hodnota plánovaného systému pro zákazníka. Iden­ tifikují se hlavní případy užití, budoucí uživatelé systému, požadavky na systém. Vytváří se doménový model, zkouší se technologie, odhaduje se hrubý plán vývoje. Na závěr se všechny získané poznatky prodiskutují na společném workshopu. Motivující úspěch (Early victory) Dosažený úspěch lidi dobře motivuje v jejich další práci. Toho se dá využít tak, že pro­ jekt začneme realizací nejsnazších požadavků. S velkou pravděpodobností budeme úspěšní, motivuje tým do další iterace, uživatelé brzo uvidí první náčrt systému, zákazník bude spo­ kojený, že vývojový proces funguje. Tahle strategie je pravým opakem doporučení udělat nejkomplikovanější věci jako první, abychom co nejdříve snížili riziko neúspěchu. Cockburn doporučuje nechat nejtěžší věci až jako druhý úkol. Následně dodává, že z ekonomického hlediska je nejvýhodnější nejdříve realizovat požadavky s nejvyšším přínosem pro obchod. Běžící kostra (Walking skeleton) Cílem úvodní fáze projektu je co nejdříve vytvořit fungující kostru budoucího systému. Tato kostra postrádá ze začátku téměř veškerou požadovanou funkcionalitu. Jejím úkolem je však propojit jednotlivé části systému jako například rozhraní a databázi, čímž se zvýší možnost paralelního vývoje v následujícím období. Je nutné si uvědomit, že tato kostra neslouží k ověření technologií, ale je už skutečným základem vyvíjeného systému, řádně prověřeným pomocí testů. Během následujícího ob­ dobí bude nejspíše zdrojový kód kostry měněn a zdokonalován, pro vývoj je však důležité mít nějakou funkční podobu co nejdříve. Inkrementální architektura (Incremental Rearchitecture) Běžící kostru je nutné zdokonalit. To lze nejlépe realizovat pomocí inkrementálních změn architektury navrhovaného systému. Zároveň s prováděnými změnami architektury jsou inkrementálně měněny funkcionalita a rozhraní systému. Rozsáhlou architekturu nelze navrhovat jinak než inkrementálně, mozek žádného návr­ háře nedokáže rozumně uchopit tak rozsáhlou abstrakci, i o části architektury lze efektivně 25

3.2. CRYSTAL METODIKY přemýšlet po dobu maximálně dvou týdnu. Informační tabule (Information Radiators) Smyslem informačních tabulí je prezentovat informace o průběhu projektu na snadno dostupných místech. Jde o informace, jejichž opakované sdělování vedení by tým zbytečně zdržovalo. Také jsou takto prezentovány informace užitečné pro samotný tým. Doporučené techniky jsou: Nastavení metodiky (Methodology shaping) Na začátku projektu se nejprve nastaví prvotní parametry metodiky. Děje se tak na spo­ lečném workshopu, kde členové týmu diskutují o svých přednostech a slabinách. Hledají se postupy, které přednosti vyzvednou a maximálně eliminují rizika plynoucí ze slabin. Zdokonalující workshop (Reflection workshop) Jednou za čas, většinou po uvolnění nové verze, se tým sejde a probere své pocity z pro­ bíhajícího procesu vývoje. Tato schůzka slouží k průběžnému upravení parametrů metodiky nastavených předešlou technikou. Tým určuje postupy, které chce i nadále zachovat. Opět se identifikují problémy s vý­ vojem a hledá se způsob jejich odstranění. Navrhují se nové postupy, které mají vyzkoušet během následující iterace. Bleskové plánování (Blitz planning) Toto plánování se používá pro horizont příštích tří měsíců. Při plánování se sejdou spon­ zor, zástupci budoucích uživatelů a celý vývojový tým. Jako alternativu lze použít i pláno­ vací hru metodiky XP. Na kartičky se sepíší všechny identifikované úkoly. Tyto úkoly vývojový tým doplní o své odhady pracnosti. Pokud je k realizaci potřeba konkrétní člověk, je jeho jméno dopl­ něno na kartičku. Plánování je realizováno přesouváním kartiček na stole podle priorit pro zákazníka, návazností jednotlivých úkolů a s přihlédnutím na zatížení případných lidí, kteří jsou na kartičce uvedení jako nutní k realizování úkolu. Věštění doby trvání (Delphi estimation) Na začátku je těžké přesně určit dobu trvání jednotlivých úkolů. Nemáme jinou mož­ nost než použít expertní odhady. Odhadují se počet tříd, jejich náročnost, potřebné znalosti vývojářů. Konkrétní příklad uvádí Cockburn ve své knize. Denní schůzky (Daily stand-ups) Tato technika pochází z metodiky SCRUM. Každé ráno se celý tým sejde na pár minut a probere, co kdo udělal, co bude dělat a jaké má problémy. Tyto problémy jsou během schůzky pouze identifikovány, nikoliv řešeny, proto celá schůzka netrvá déle než čtvrt ho­ diny. Problémy se případně řeší až po schůzce v kruhu zainteresovaných lidí. 26

3.2. CRYSTAL METODIKY Optimalizace rozhraní (Essential interaction design) Tuto techniku Cockburn přejímá od Jeffa Pattona a ve své knize [5] ji detailně popisuje. Já na tomto místě práce jen krátce naznačím její význam a cíle. Různé skupiny budoucích uživatelů budou pracovat se systémem různým způsobem, proto mají na systém různé požadavky a různé očekávání. Asi se nám nepodaří vyhovět všem skupinám, musíme tedy identifikovat jednu nebo dvě nejdůležitější a pro uživatele těchto skupin optimalizovat rozhraní vyvíjeného systému. Miniprojekt (Process miniature) Pro člověka seznamujícího se s novou metodikou je ze začátku těžké chápat závislosti mezi jednotlivými procesy. Cockburn doporučuje uspořádat pro nováčky malý projekt trva­ jící maximálně den, při kterém si vše vyzkouší a uvidí závislosti mezi jednotlivými procesy. Blízké programování (Side-by-side programming) Jde o lehčí verzi párového programování, které definuje metodika XP Cockburn pova­ žuje za vhodnější, pokud programátoři pracují každý na svém úkolu na vlastním počítači. Sedí však dostatečně blízko sebe, takže vidí na monitor druhého a jsou mu k dispozici ke konzultaci. Přírůstkové grafy (Burn charts) Technika určená k jednoduché, rychlé a přehledné prezentaci pokroku při vývoji. Na viditelné místě je umístěn a pravidelně aktualizován graf, na jehož horizontální ose je čas a na vertikální měřitelná jednotka pokroku. Vhodnou jednotkou na ose pokroku je taková, která je během celého procesu vývoje známá. Nebude jí tedy počet řádků zdrojového kódu (celkový počet je znám až na konci poslední iterace), lepší je použití například počet případů užití. Při úvodním plánování se do grafu nanese k jednotlivým milníkům předpokládané pro­ cento implementovaných případů užití ze všech požadovaných a těmito body je proložena křivka. Opakovaně (například na konci každé iterace) je do grafu zaneseno skutečné pro­ cento navržených, naprogramovaných a otestovaných případů užití. 3.2.4 Životní cyklus Projekt řešený metodikou Crystal Clear je tvořen skupinou do sebe vnořených cyklů růz­ ných délek. Těmito cykly jsou vývoj, iterace, dodávka a celý projekt. Jejich vzájemné uspo­ řádání ukazuje obrázek 3.3. Ve zbytku podkapitoly jsou postupně popsány jednotlivé etapy, k čemuž jsou hojně používány pojmy vysvětlené v předchozích částech práce 3.2.3 Postupy a 3.2.2 Role. Projekt začíná etapou nazvanou mapování. Během ní je nejdříve sestaven tým, důraz je kladen na vhodné obsazení rolí sponzor, hlavní vývojář a uživatel. Tým je podle potřeby doplněn o asi dva až pět vývojářů. Dále je realizována strategie průzkum nebo některá její 27

3.2. CRYSTAL METODIKY

Projekt

Projekt mapování

Dodávka

předání

Dodávka

Dodávka Iterace

|

Iterace

|

nasazení

|

workshop iterace

plánování

Den

Den

Den

ukončeni a oslava Den

denní schůzka

Integrace

Integrace

Integrace Integrace

Vývoj

Vývoj

Vývoj

sestavení a test

Obrázek 3.3: Cykly projektu řízeného metodikou Crystal Clear

alternativa převzatá například z metodiky RUP. Následuje technika nastavení metodiky. Na závěr se vytvoří prvotní plán projektu. K jeho tvorbě může být použita již zmiňovaná technika bleskové plánování, nebo některá její alternativa používaná metodikou DSDM, SCRUM, nebo XP. Po etapě mapování následují časově dlouhé cykly pojmenované dodávka, skládající se z jedné nebo několika iterací, popsaných dále. Minimálně na konci etapy je nový inkrement dodán alespoň některým uživatelům, kteří otestují novou funkcionalitu a především infor­ mují tým o použitelnosti nových obrazovek. Během dodávky je alespoň jednou uskutečněn zdokonalující workshop, kdy je přezkoumán a vylepšen proces vývoje. Délka jedné iterace se může pohybovat mezi jedním týdnem a dvěma měsíci. Obě uve­ dené hodnoty jsou extrémní a vyžadují velkou opatrnost. Při dlouhé iteraci nesmí tým zapo­ menou na průběžné ukázky systému uživatelům kvůli včasné zpětné vazbě. Krátká iterace zase vyžaduje rozdělení požadavků na velmi malé úkoly realizovatelné v tak krátké době. Iterace v sobě obsahuje plánování, jednotlivé pracovní dny, integrační cykly, ukončení a oslavu. Délka integračního cyklu je závislá na schopnostech týmu. Četnost integrace může být různá, 3.3 naznačuje provádění integrace několikrát za den, stejně tak existují projekty, kde se integrace provádí jednou za den, tři dny, týden i více. Čím delší je interval mezi jed­ notlivými integracemi, tím větší je riziko problémů. Snadnost etapy integrace významně ovlivňuje technické vybavení, jak je již zmíněno v části 3.2.1 Principy. Mezi uvažované cykly patří i týden a den, které mají v každém týmu specifický průběh. Pondělní přivítání po víkendu, krátké konstatování stavu a podobně. Na začátku každého dne je vhodné uspořádat krátkou denní schůzku, jak ji zavádí metodika SCRUM.

28

3.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD Posledním zde popsaným cyklem je vývoj, který je součástí integračního nebo denního cyklu (podle častosti integrace). V tomto cyklu se ve skutečnosti skrývá návrh, programo­ vání, testování a hledání chyb.

3.2.5 Hodnocení Celou rodinu metodik Crystal shledávám velmi zajímavou pro jejich obrovskou flexibilitu. Žádná metodika nemůže být univerzální pro každý projekt. Metodiky Crystal z tohoto kon­ statování přímo vycházejí, projekt začíná volbou a konfigurací vhodné metodiky z rodiny podle daných doporučení. Samotná vybraná metodika je pak spíše sadou doporučení, kterými se tým může řídit. Dokonce i u povinných úkolů má tým možnost vybrat si způsob jejich realizace, například použít alternativní postup jiné metodiky. Zmíněná flexibilita může být bohužel pro některé týmy i překážkou. Začínající vývojáři většinou uvítají „berličku" v podobě striktně definovaných postupů „zaručeně" vedoucích k úspěšnému řešení projektu. Metodiky rodiny crystal jsou orientovány více na lidi než implementaci. Dostupné jsou zatím jen metodiky pro malé a středně velké týmy a pro lehké a středně obtížné projekty.

3.3

Dynamic Systems Development Method

Dynamic Systems Development Method (DSDM) je vytvářena konsorciem DSDM od roku 1984, první verze metodiky byla uvolněna až v roce 1995. Dlouho dobu lze vysvětlit fak­ tem, že konsorcium si dalo za cíl vytvořit podpůrné prostředí pro rychlý vývoj software. Vedle doporučených postupů tak metodika obsahuje rovněž framework, nad kterým jsou aplikace vyvíjeny. Dále metodiku doplňují vývojové nástroje a šablony vytvářených doku­ mentů. Od prvního uvolnění konsorcium usilovně metodiku rozšiřuje a vylepšuje, v době psaní této práce je k dispozici Framework for Business Centred Development verze 4.2. Metodika DSDM je nejvíce rozšířená ve Velké Británii, je však používána i v jiných státech Evropy a Severní Ameriky. Přístup k metodice a frameworku je bohužel limitován, k jeho použití je potřeba licence. Z tohoto důvodu jsem při popisu metodiky DSDM čerpal z neauthentizované části portálu Konsorcia DSDM [7], knihy Agilní programování [3] od Václava Kadlece a dále z práce Agile software development methods [11]. DSDM vychází z myšlenky, která je společná většině agilních metodik, pevně definovat potřebný čas a náklady na vývoj software, přičemž rozsah vyvinutého systému je pak zá­ vislou proměnnou. Zdárné dokončení projektu zajišťuje použití dvou praktik časový blok a MoSCoW, které jsou detailně popsány v části 3.3.3 Postupy. 29

3.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD 3.3.1 Principy Metodika DSDM je založena na devíti principech, z nichž většina vychází z manifestu agil­ ního vývoje [2]. Aktivní účast zákazníka Kvalifikovaní zástupci budoucích uživatelů musí být k dispozici po celou dobu vývoje systému, aby týmu zajišťovali častou a přesnou zpětnou vazbu. Tým má pravomoc k rozhodování Cekání na potvrzení dalšího postupu od vedení neúměrně prodlužuje vývoj systému. DSDM tým má na základě komunikace s kvalifikovanými zástupci zákazníka pravomoc rozhodnout o dalším směru vývoje. Důraz na časté dodávky Nové verze systému jsou uvolňovány co nejdříve je to možné. Zrychluje se tak zpětná vazba od uživatelů systému, dříve se objeví změnové požadavky a zjistí nepochopené za­ dání. Vhodnost systému pro podnikání Zákazník očekává systém, který mu přinese svým používáním očekávaný užitek. Spl­ nění tohoto očekávání je pro něj důležitější než vědomí, že systém využívá nejnovější tech­ nologie a prošel důkladným regresním testováním. Iterační vývoj a inkrementální dodávky Systém je vhodnější dodávat postupně pomocí inkrementů než celý najednou na konci vývoje. Chyby v systému jsou tak objeveny a odstraněny dříve. Iterace jsou nejvhodnější postup vývoje software. Vratné změny Během vývoje je snadné vydat se špatnou cestou, je však důležité mít možnost se z této cesty rychle dostat zpět. Veškeré prováděné změny proto musí jít lehce vrátit do původního stavu. Požadavky na vysoké úrovni Vysoká abstrakce při práci s požadavky umožňuje opožděné rozhodování, požadavky jsou postupně upřesněny až v době, kdy je jejich detailní podoba jistá nebo kdy je detailní popis nutný pro další vývoj. 30

3.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD Průběžné testování Testování se provádí v průběhu celého vývoje, aby se eliminovalo riziko, že ke konci už na testování nebude čas, tudíž se neprovede, nebo provede nedostatečně. Vzhledem k inkre­ mentálnímu vývoji se provádí regresní testování, tedy opakovaně se přetestuje celý zatím vyvinutý systém, což zvyšuje pravděpodobnost odhalení zavlečených chyb. Spolupráce Dokonalá spolupráce a dostatečná komunikace je základem úspěšného vývoje systému. Důležitá je jak mezi členy týmu při společném řešení požadavků, tak mezi týmem a uživateli při rozhodování o přidaných funkcionalitách v nové verzi systému. 3.3.2 Role DSDM uvažuje dohromady patnáct různých rolí. Přehled a stručný popis nejvýznamnějších rolí následuje. Vývojář (Developer) Tato role spolu s následující jsou jediné, které mají v týmu na starost samotný vývoj systému. Jde o obecné označení pro zaměstnance, kteří mají na starost analýzu, návrh, pro­ gramování nebo testování vyvíjeného systému. Senior vývojář (Senior developer) Do této role je povýšen některý ze zaměstnanců v roli vývojáře, pokud má větší zkuše­ nosti nebo znalosti než jeho kolegové. Tento člověk jim pak dělá vedoucího. Technický koordinátor (Technical coordinator) Navrhuje architekturu vyvíjeného systému a je zodpovědný za její technickou kvalitu. Zároveň hlídá projekt po technické stránce, má na starost konfigurační management. Zástupce uživatelů (Ambassador user) V této roli je obsazen jeden z budoucích uživatelů systému. Jeho úkolem je zajišťovat komunikaci mezi vývojovým týmem a budoucími uživateli. Týmu musí poskytnout znalosti uživatelů a tlumočit jejich požadavky. Uživatele pak musí naopak informovat o průběhu projektu a výsledcích vývoje. Rádce (Adviser user) Zastupuje předchozí roli v případech, kdy se jedná o specifické požadavky. Může se jednat například o zaměstnance zákazníka z ICT nebo finančního oddělení. 31

3.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD Vizionář (Vissionary) Je člověk, který přišel s myšlenkou nového systému. Jeho úkolem je zajistit, aby se všechny základní požadavky na systém identifikovaly v rané části celého projektu. V následném čase pak hlídá, že projekt směřuje správným směrem a realizuje identifikované požadavky. Výkonný ředitel (Executive sponsor) Je člověk na straně zákazníka, který má na starost financování celého projektu. Z toho vyplývá, že při rozhodování má poslední slovo. Projektový manažer (Project manager) Tradiční role, která má na starosti hladký průběh projektu. Netradiční u metodiky DSDM je, že tuto roli může zastávat i někdo ze strany zákazníka. Týmový předák (Team leader) Má na starost celý tým, kontroluje a napomáhá jejich práci a odbourává případné komu­ nikační bariéry. Tester (Tester) Má na starost ty testy, které nemůže realizovat zákazník sám. Písař (Scribe) Účastní se všech workshopů, porad a schůzek a zodpovídá za jejich dokumentaci. Mimo jiné zapisuje i všechny nalezené požadavky. Moderátor (Facilitator) Nepovinná role, která se stará o hladký průběh workshopů, porad a schůzek. Specialisté (Specialist) V roli specialistů jsou odborníci na různé oblasti vývoje software. Může se jednat napří­ klad o doménové experty, správce kvality, test architekty nebo systémové integrátory.

V závislosti na velikosti projektu se účastní vývoje jeden nebo více týmů. Mezi velkým a malým projektem se z pohledu řízení téměř nerozlišuje, protože se vychází z předpokladu, že velký projekt lze rozdělit na menší nesouvisející části, které mohou řešit jednotlivé týmy nezávisle na sobě. Tým je složen ze dvou až šesti lidí. Minimum je dáno požadavkem, že v každém týmu musí být alespoň uživatel a vývojář. Maximum šesti lidí je výsledkem dlouhodobých zku­ šeností z používání metodiky DSDM. 32

3.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD 3.3.3 Postupy Vzhledem k nutné licenci pro použití DSDM se mi podařilo získat informace bohužel jen o dvojici nepodstatnějších postupů, v terminologii DSDM nazvaných technikami. Časový blok (Timebox) Celý projekt i jednotlivé iterace mají pevně stanovené datum ukončení, které nelze za žádných okolností odložit. Délka iteračních bloků se typicky pohybuje v rozmezí dvou až šesti týdnů, podle náročnosti plánované iterace. Během bloku se postupně realizují poža­ davky, které jsou seřazeny podle priorit. Žádná iterace díky tomu nepřekročí plánované datum ukončení, může se však stát, že některé z méně důležitých požadavků se nestihnou realizovat. Každý blok obvykle projde postupně třemi fázemi: zkoumáním, zdokonalením a konso­ lidací. První ověřuje, zda projekt zdárně pokračuje ke svému cíly. Druhá zajišťuje zlepšo­ vání procesů na základě poznatků získaných během předešlého vývoje. Poslední pak slouží k dokončení všech nepřesných a nedokončených aspektů. MoSCoW Slovo MoSCoW vzniklo jako složenina čtyř písmen označující jednotlivé úrovně priorit. Jedná se postup, kterým DSDM přiřazuje jednotlivým požadavkům různé priority, podle kterých je během vývoje s požadavky nakládáno. DSDM uvažuje následující úrovně priorit. •

Nezbytné (Must) jsou požadavky, které musejí být nezbytně realizovány, jinak je ohro­ žen průběh celého projektu.

•

Doporučené (Should) jsou požadavky, které by měli být realizovány, neohrožují však životaschopnost projektu.

•

Možné (Could) jsou požadavky, jejichž nesplnění nezpůsobuje projektu žádné vážně problémy.

•

Odložitelné (Won't) jsou požadavky, které lze realizovat kdykoliv později.

DSDM dále uvádí další techniky, které souvisí s vývojem software. Jedná se o známé po­ jmy softwarového inženýrství, proto zde techniky pouze vyjmenuji bez jejich detailnějšího popisu. Uváděnými technikami jsou modelování, tvorba prototypů, testování a konfígurační management. Všechny tyto techniky nejsou obecně vhodné pro každý projekt, jejich použití záleží na konkrétním případě. 33

3.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD 3.3.4 Životní cyklus Během vývoje podle metodiky DSDM projde projekt sedmi etapami uvedenými dále. První tři jsou sekvenční, další čtyři pak inkrementální a iterativní. Jednotlivé iterace mají pevnou, předem danou délku, to vyplývá z použití časových bloků, zmíněných již dříve v části 3.3.3 Po­ stupy. Úvod projektu (Pre-project) Jedná se o krátkou etapu předcházející samotnému vývoji sloužící k ujištění, že je projekt dobře nakonfigurován a všechny související procesy správně nastartovány. Studie proveditelnosti (Feasibility study) V této etapě se rozhoduje, jestli je systém realizovatelný pomocí DSDM. Rozhodnutí je závislé na technických možnostech a hrozících rizicích. Během této etapy vznikají dva dokumenty, jsou to Zpráva o proveditelnosti (Feasibility report) a Rámcový plán vývoje (Outline plan for development). Pokud projekt vyžaduje týmu málo známou technologii, vytváří se během této etapy prototyp, který ověří proveditelnost. Délka této první etapy smí být maximálně několik týdnů. Obchodní studie (Business study) V této etapě se zkoumají základní charakteristiky fungování firmy zákazníka a požado­ vaných technologií. DSDM doporučuje během této etapy uspořádat workshop, na kterém se s experty zákazníka projdou aspekty vyvíjeného systému a určí priority jednotlivých úkolů. Při této etapě se vytváří dokument Definice prostředí firmy (Business Area Definitions), ve kterém jsou identifikovány prováděné procesy a zainteresovaní lidé ve zkoumané firmě. Dalšími produkovanými dokumenty jsou Definice architektury (System Architecture Definition) a Rámcový plán pro prototyp (Outline Prototyping Plan). První uvedený do­ kument v sobě obsahuje prvotní návrh architektury vyvíjeného systému, tento návrh se bě­ hem dalších etap může měnit. Druhý dokument navrhuje strategie pro vývoj prototypu a obsahuje informace důležité především pro konfigurační manažery. Stanovení modelu funkcí (Functional model iteration) Tato etapa je první inkrementální a iterační. Během jednotlivých iterací probíhá jak ana­ lýza tak kódování. Jedním z výstupů této etapy je Funkční model (Functional Model), tedy kód prototypu. Dále tato etapa produkuje dokumenty Priority funkcionalit (Prioritized functi­ ons), Revize funkčního modelu (Functional prototyping review documents), Nefunkční po­ žadavky (Non-function requirements) a Analýza rizik dalšího vývoje (Risk analysis of futher development). Během etapy se průběžně testuje. Návrh a implementace (Design and build iteration) 34

3.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD Při této etapě se navrhuje a vytváří vyvíjený systém. Během iterací se zároveň upra­ vuje vzhled a celý systém se sestavuje dohromady. Jako zpětná vazba slouží připomínky uživatelů, kteří během této etapy systém zkouší. Hlavním produktem etapy je otestovaný systém, který splňuje přinejmenším předem domluvenou minimální množinu kladených požadavků. Nasazení (Implementation) Během této poslední etapy se vyvinutý systém nasadí do ostrého provozu u zákazníka. Zároveň probíhá školení uživatelů nového systému. V případech, kdy je tato etapa časově náročnější, může probíhat v podobě několika iterací. Součástí etapy je dodání dvou doku­ mentů, Uživatelský manuál (User manual) a Zhodnocení projektu (Project Review Report). Závěr projektu (Post-project) Tato etapa následuje po nasazení systému u zákazníka. Před koncem celého projektu se ověřuje, zda systém běží efektivně a zda nasazení systému přineslo očekávaný užitek.

Po skončení předposlední etapy nasazení mohou nastat čtyři možnosti, jak bude celý projekt pokračovat, všechny uvádí následující přehled: •

všechny požadavky na systém byly splněny a vývoj končí

•

větší množství požadavků bylo odloženo, nebo byly některé požadavky objeveny v poz­ dější části vývoje, pak se celý životní cyklus opakuje od první etapy

•

méně kritické funkčnosti byly vynechány, cyklus se opakuje od třetí etapy

•

nebyl čas na některé technické požadavky, pak se cyklus opakuje od čtvrté etapy

Celý životní cyklus vývoje software podle metodiky DSDM ještě shrnuje obrázek 3.4 pře­ vzatý z webových stránek Konsorcia DSDM [7]. Na obrázku je zároveň vidět, že zpětný přechod na předchozí etapu je možný i dříve než po dokončení nasazení. 3.3.5 Hodnocení Metodika DSDM mi připadá důsledně propracovaná a velmi dobře dokumentovaná. Je po­ znat, že se usilovně zdokonaluje už deset let. Licencovaný přístup k této metodice, dle mého názoru, významně omezuje její výrazné rozšíření mezi vývojářskou společnost. Méně re­ striktivní přístup by mohl zdokonalování metodiky urychlit, protože by se do tohoto pro­ cesu zapojilo mnohem více lidí. Za zajímavou považuji myšlenku časových bloků a navržené úrovně priorit jednotlivých požadavků. Kombinace těchto dvou postupů s velkou pravděpodobností zaručí, že verze 35

3.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD

Obrázek 3.4: Životní cyklus podle DSDM

vyvíjeného systému budou dodány včas. Celkový čas trvání projektu se samozřejmě může i přesto protáhnout. Zajímavou zkušeností by byl vývoj nad frameworkem DSDM a jeho srovnání s jinými. Bohužel to kvůli licencím není možné. V opačném případě by šla posoudit jeho úroveň a odhadnout jakým způsobem urychlí a pomůže při vývoji software. Výhodné může být použití metodiky DSDM spolu s metodikou RUP, XP nebo Prince2. Této problematice se věnuje řada článků odkazovaných z portálu Aliance agilního vývoje software [1]. Zájemci o detailnější poznání této metodiky články doporučuji k přečtení. Zá­ věrem ještě uvedu, že podle práce Agile software development methods [11] je tato meto­ dika vhodnější pro projekty z obchodní sféry než pro inženýrské nebo vědecké projekty. 36

3.4. SROVNÁNÍ VYBRANÝCH METODIK 3.4

Srovnání vybraných metodik

Obsahem této kapitoly je srovnání vybraných metodik. V úvodu je každá metodika před­ stavena pomocí jediného odstavce, ve zbývajících sekcích jsou postupně srovnány principy, role a postupy. Extrémní programování je metodika určená pro jeden tým (do deseti programátorů). Zaměřuje se především na psaní kódu a ostatní disciplíny vývoje ponechává stranou. Je to nejznámější a asi nejrozšířenější agilní metodika, která se pomalu usídluje i u nás. Lze se inspirovat z dobrých programátorských návyků (testovaní a refaktoring), které metodika prezentuje. Bez doplnění dalšími přístupy (třeba metodikou RUP) je samostatně ve větších firmách nepoužitelná. Částečné osvojení může však softwarové firmě přinést užitek. Crystal metodiky jsou skupinou metodik, které si dávají za cíl pokrýt všechny možné projekty, vybráním správné metodiky ze skupiny a nastavením odpovídajících parametrů. Zatím jsou však k dispozici jen metodiky pro malé a středně velké týmy a pro lehké a středně složité projekty. Celkově jsou metodiky spíš zaměřeny na lidský faktor a poradenství, de­ tailní popis postupů ve většině případů neposkytují. Metodiky jsou velmi flexibilní, postupy a činnosti týmu pouze doporučují, případně dávají na výběr z několika alternativních mož­ ností, kde některé jsou převzaté i s ostatních agilních metodik (XP, SCRUM, DSDM). Metodika Dynamic Systems Development Method je postavená na vlastním frameworku, který umožňuje rychlý vývoj aplikací. Kromě frameworku mají vývojáři podporu i ve vý­ vojových nástrojích a v šablonách dokumentů. Postupy jsou z části povinné, z části dopo­ ručené. Metodika nepokrývá celou oblast vývoje, je proto vhodná kombinace s jinou meto­ dikou, která jí doplní. Příkladem takové metodiky může být RUP. Použití metodiky a fra­ meworku je omezeno licencí. To bohužel zabraňuje masivnějšímu rozšíření. 3.4.1 Principy Nemá smysl znovu podrobně rozebírat principy jednotlivých metodik, pro připomenutí však alespoň uvedu jejich seznam. Extrémní programování •

Rychlá zpětná vazba

•

Předpoklad jednoduchosti

•

Přírůstková změna

•

Využití změny

•

Kvalitní práce

•

Výuka poznatků

•

Malá počáteční investice 37

3.4. SROVNÁNÍ VYBRANÝCH METODIK •

Hraní na výhru

•

Konkrétní experimenty

•

Otevřená a upřímná komunikace

•

Práce v souladu s lidskými instinkty

•

Přijetí odpovědnosti

•

Místní přizpůsobení

•

Cestování nalehko

•

Poctivé měření

Crystal metodiky •

Pravidelné dodávky

•

Zdokonalování procesů

•

Podprahová komunikace

•

Přátelské prostředí

•

Pozornost

•

Dostupnost uživatelů

•

Technické vybavení

Dynamic Systems Development Method •

Aktivní účast zákazníka

•

Tým má pravomoc k rozhodování

•

Důraz na časté dodávky

•

Vhodnost systému pro podnikání

•

Iterační vývoj a inkrementální dodávky

•

Vratné změny

•

Požadavky na vysoké úrovni

•

Průběžné testování

•

Spolupráce

38

3.4. SROVNÁNÍ VYBRANÝCH METODIK Srovnání Všechny tři porovnávané metodiky vycházejí z manifestu agilního vývoje software [2], a tak se jejich principy téměř neliší. Principům, které lze najít ve všech třech metodikám, se zde nebudu věnovat, uvedu jen zbývající. Jen XP má přijetí odpovědnosti, jako jediná tak uvažuje psychologický efekt vybrání si úkolu místo jeho přidělení. Crystal metodiky zase jako jediné zajišťují nerušený čas (pozornost), což je rozdílné od XP, kde se předpokládá, že jeden programátor druhému kdykoliv pomůže. 3.4.2 Role Stejně jako při srovnání principů nejdříve připomenu role jednotlivých metodik. Extrémní programování (XP) Kouč Stopař Programátor Zákazník Tester Konzultant Velký šéf

Crystal Clear (CC) Sponzor Uživatel Hlavní vývojář Vývojář Doménový expert Koordinátor Tester Písař

39

3.4. SROVNÁNÍ VYBRANÝCH METODIK Dynamic Systems Development Method (DSDM) •

Vývojář

•

Senior vývojář

•

Technický koordinátor

•

Zástupce uživatelů

•

Rádce

•

Vizionář

•

Výkonný ředitel

•

Projektový manažer

•

Týmový předák

•

Tester

•

Písař

•

Moderátor

•

Specialisté

Srovnání U všech metodik lze identifikovat tři skupiny rolí: programátorské, uživatelské a řídící. U první skupiny metodiky shodně rozlišují programátory podle zkušeností. U XP kouč své zkušenosti a znalosti pomocí párového programování rychle předává mezi ostatní, zvyšuje tak svou technickou zastupitelnost. Hlavní vývojář u CC takto jednoduše své povědomí o architektuře nepředává, v případě problémů proto bývá přetížen, protože je nezastupi­ telný. Je důležité, aby si v týmu „vychoval" alespoň jednoho „náhradníka". Uživatelských rolí je nejvíce u DSDM, lze z toho tedy usuzovat, že se metodika detailně zaměřuje na různé vazby mezi týmem a zákazníkem. Otázkou je, zda to má smysl. Možným důvodem by mohla být skutečnost, že DSDM je i pro velké projekty, kdy se vývoje účastní více týmů. Za takových okolností by adresování komunikace na různé role na straně zákaz­ níka v závislosti na řešeném problému dávalo smysl. Ve všech metodikách je role tester chápána jako specialista na proces testování, který je v této oblasti oporou ostatním členům týmu, případně zákazníkovi. Je to dáno faktem, že jedna ze společných vlastností všech agilních metodik je regresní automatizované testování, v týmech tedy nejsou lidé, kteří by na základě testovacích scénářů ručně testovali vyvíjený software. 40

3.4. SROVNÁNÍ VYBRANÝCH METODIK Metodiky také společně uvádějí role specializovaných odborníků, kteří vývojářům po­ skytují podporu v neznámých oblastech. Kromě role moderátoru DSDM neexistuje jiná role specifická pro některou metodiku. Celkově lze říci, že vybrané metodiky se z pohledu rolí liší jen v jemnosti dělení, napří­ klad role obsazené lidmi od zákazníka, konkrétně zákazník, případně velký šéf v XP oproti zástupce uživatelů, rádce, vizionář, výkonný ředitel, případně projektový manažer a speci­ alisté v DSDM. 3.4.3 Postupy Opět nejdříve uvedu seznam principů pro připomenutí. Extrémní programování (XP) •

Plánovací hra

•

Malé verze

•

Metafora

•

Jednoduchý návrh

•

Testování

•

Refaktorizace

•

Párové programování

•

Společné vlastnictví

•

Nepřetržitá integrace

•

40hodinový týden

•

Zákazník na pracovišti

•

Standardy pro psaní zdrojového kódu

Crystal Clear (CC) •

Průzkum

•

Motivující úspěch

•

Běžící kostra

•

Inkrementální architektura 41

3.4. SROVNÁNÍ VYBRANÝCH METODIK •

Informační tabule

•

Nastavení metodiky

•

Zdokonalující workshop

•

Bleskové plánování

•

Věštění doby trvání

•

Denní schůzky

•

Optimalizace rozhraní

•

Miniprojekt

•

Blízké programování

•

Přírůstkové grafy

Dynamic Systems Development Method (DSDM) •

Časový blok.

•

MoSCoW

Srovnání Postupy DSDM časový blok a MoSCoW jsou alternativní k plánovací hře v XP a blesko­ vému plánování v CC. Všechny slouží k plánování rozsahu verze na základě odhadovaného času a přidělené priority, každá však jiným způsobem. Nejsnáze lze pochopit a použít plá­ novací hru, bleskové plánování je však přehlednější. Další postupy metodiky DSDM jsem bohužel nezjistil, takže dále srovnám jen metodiky XP a CC, přičemž se zaměřím jen na rozdíly, tedy postupy které v druhé metodice nemají alternativní postup nebo postupy. Pokud není některý postup dále uveden, znamená to tedy, že k němu lze najít alternativu. U metodiky XP jsou ojedinělými postupy metafora a společné vlastnictví. Příběh k snad­ nějším úvahám o software se u CC nevyskytuje, ani nic podobného. Postup, kdy je zdro­ jový kód všech a může ho tak kdokoliv měnit není také zrovna typickým. Proti metafoře nic nenamítám, ale myslím si, že za kód by měl být někdo zodpovědný. Zároveň i chápu, že pokud chce být XP rychlé, nemůže čekat až chybu opraví někdo jiný. Optimum vidím v kompromisu, kdy kód může měnit kdokoliv, ale pověřená osoba musí změnu přijmout. U metodiky Crystal Clear lze najít také dva jedinečné postupy, jsou to optimalizace roz­ hraní a miniprojekt. Metodika XP se zaměřuje na kód, pro tvorbu uživatelských rozhraní žádný podpůrný postup nemá. Miniprojekt je zajímavý, protože radí jak nováčkům v týmu 42

3.4. SROVNÁNÍ VYBRANÝCH METODIK rychle ukázat nejdůležitější body metodiky. Částečně to lze přirovnat k párovému progra­ mování se zkušeným partnerem nebo postupnému přijímání u metodiky XP. Velká podob­ nost je mezi párovým programováním a blízkým programováním.

43

Kapitola 4

Případová studie Tato kapitola obsahuje srovnání vybraných metodik pomocí řešení případové studie. Stručné zadaní a okolnosti myšleného projektu jsou obsahem části 4.1 Výchozí podmínky. Následují ukázky řešení pomocí vybraných metodik. V poslední části 4.5 Srovnání životních cyklů je shrnutí rozdílů mezi vybranými metodikami. Kapitola se zaměřuje především na rozdíly při hledání požadavků, plánování projektu a na odlišnosti v integraci. Závěrem ještě musím zdůraznit, že jsem se nepokoušel projekt skutečně řešit, odhady pracnosti jednotlivých požadavků jsou pouze tipovány bez důkladnějšího rozboru. Je proto pravděpodobné, že jsem někde „prestrelil". Tato kapitola má jen ilustrovat řešení projektu vybranými metodikami, korektní časové odhady proto zde nejsou důležité. Při reálném ře­ šení by byly co možná nejpřesnější odhady klíčové a pověřené role by je museli expertně odhadnout.

4.1

Výchozí podmínky

Jednotlivé metodiky mají za úkol vyvinout software pro podporu správy squashových kurtů. Soukromý podnikatel (dále zákazník) zakoupil existující squashové centrum, které právě opravuje. Centrum chce znovu otevřít během jednoho měsíce (22 pracovních dnů), poža­ duje tedy software v co nejkratším možném termínu. Od dodaného software zákazník očekává skladovou evidenci prodávaného doplňko­ vého zboží (rakety, obuv, míčky,...), správu časové rezervace jednotlivých herních kurtů a evidenci pravidelných návštěvníků kategorizovaných do různých skupin (profesionálové, studenti, běžní hráči,...). Software musí poskytovat potřebné podklady pro vedení účetnic­ tví. Produkované statistiky vytíženosti kurtů v závislosti na čase a různých skupinách hráčů pomohou zákazníkovi při volbě otevíracích hodin a cenové politiky. Svým průzkumem zákazník zjistil, že hráči mají zájem o možnost rezervace kurtů po­ mocí webového rozhraní. Takovou službu žádné konkurenční centrum zatím neposkytuje, proto by ji zákazník chtěl uvést na místní trh jako první hned při znovuotevření centra. Software bude realizovat šestičlenný tým zkušených vývojářů. Ve studii se předpokládá, že složení týmu je pevně dáno, protože je uvažována malá softwarová firma s jedním vý­ vojovým týmem, a tým má s použitou metodikou již zkušenosti, což je předpoklad pro efektivní použití metodik. Ve studii se tedy neuvádí procesy budování týmu a obsazování členů do rolí. 44

4.2. EXTRÉMNÍ PROGRAMOVÁNÍ Podmínky zde schválně nejsou uvedeny podrobněji, neboť je tak lépe patrné, kdy, jak a jestli vůbec metodiky podrobnosti objeví. 4.2

Extrémní programování

Studie ukazuje průběh projektu podle ideálního životního cyklu popsaného v 3.1.4 Životní cyklus, začíná tedy fází Průzkum, kdy jsou od zákazníka zjištěny požadavky a je složen vývojový tým. Průzkum Požadavky jsou od zákazníka získány pomocí uživatelských příběhů (User stories), které píše zákazník a lze je chápat jako případy užití. Příklad 4.2.1 uvádí, jak by vypadal jeden takový uživatelský příběh v případě uvažovaného squashové centra. Obsluha vybere z nabídky požadované datum, ze zobrazeného harmonogramu dne zjistí, zda je v požadovaný čas volný některý z hracích kurtů. Pokud ano, rezervuje hráči kurt na danou dobu a informuje hráče o jeho rezervaci. V opačném případě zkouší hráči navrhnout rezervaci ve volném čase, který je k požadovanému nejblíže. V případě zájmu, rezervuje kurt na novou dobu, jinak není provedena žádná rezervace. Když je rezervace prováděna pro nového hráče, je tento hráč zároveň vložen do evidence. Příklad 4.2.1: Ukázka uživatelského příběhu (rezervace kurtu) Konzultací mezi zákazníkem a celým týmem jsou uživatelské příběhy doplněny a vzni­ kají karty zadání, jednu ukazuje obrázek 4.1. Zákazník určuje prioritu. Typ činnosti může nabývat tří hodnot: nová, opravná nebo zlepšovací. Ostatní položky jsou vyplněny až v ná­ sledných etapách. Datum: Cíälc zadání: Předchozí odkaz Zadání úkolu:

Poznámky: Sledování úkolu: Datum

12.12.20 05 Typ činnosti: 1122 Priorita (uživ}: Riziko:

nová vysoká

Priorita (tech.}: Tech. Odhad:

est ijnkce: |

NO VÁ REZE RVAJCE KU RTU: po výběru dne je potřeba zjistit obsazenost kurtů a zobrazit ji. Recepční zadá rezervaci na dobu, kdyje kurt winý. Zadaní je kontrolováno, zda nekoliduje

Zadání kurtu a času bude pro snadnou obsluhu realizován výběrem odpovídajících políček výpisu. Status

Udělat

Poznámky

Obrázek 4.1: Ukázka karty zadání 45

4.2. EXTRÉMNÍ PROGRAMOVÁNÍ Za normálních okolností by tato etapa trvala několik týdnů, v případě že by tým ne­ měl zkušenosti s požadovanou technologií i několik měsíců. Dále se však předpokládá, že software lze úspěšně realizovat pomocí technologie J2EE1, kterou tým už důkladně zná a může tak začít hned pracovat. Zákazníkovi přitom bylo vysvětleno, že je nereálné dodat vše do plánovaného otevření centra. Zákazník tedy v této fázi specifikuje pouze klíčovou funkcionalitu, kterou potřebuje nejdříve a ostatní uživatelské příběhy budou sepsány a re­ alizovány až v dalším průběhu projektu. Celá fáze tak byla zkrácena na jeden a půl dne a zákazník zvolil jako klíčovou část software, která má na starost rezervaci hracích kurtů a správu hráčů. Projekt pokračuje fází plánování, kdy jsou vybrány karty zadaní do první iterace Plánování Plánování normálně zabere jeden až dva dny, v této studii je zkráceno na půl dne, z před­ chozí etapou tedy projekt zabral zatím dva dny. Na etapu zprovoňování se vedení rozhodlo vyčlenit týden před otevřením squashového centra. Na následující etapu iterací do uvolnění první verze zbývají tedy tři týdny. Plánování je realizováno pomocí plánovací hry a iterační plánovací hry, které jsou vy­ světleny v knížce Extrémní programování [12] na straně 76 až 83. Vývoj (celý tým) odhadne pracnost jednotlivých karet zadání. Vedení (zde kouč a zákazník) setřídí karty podle přidané hodnoty pro zákazníka. Vývoj setřídí karty podle rizika nepřesnosti odhadu. Vedení zvolí šíři zadání verze, tedy sadu karet zadání které budou implementovány. Podrobnější popis průběhu plánovací hry by byl nad rámec této studie, ta je omezená na konstatování, že kouč rozhodl před nasazením uskutečnit dvě iterace o délce dva a jeden týden, do kterých vybral karty zadání, které jdou napříč celým prvotním software, jehož jádro má být dodáno před otevřením centra. Do verze byly zahrnuty například karty zadání uvedené v tabulce 4.1. Karta Rezervace kurtů Evidence hráčů Vytvoření prvotního modelu 2 Simulace nehotového modelu

Stručný popis přidání, rušení a přehled rezervací kurtů přidání, rušení a přehled hráčů databáze a persistence dat potřebná k testům ostatních částí

Odhad (dny) 4 2 5 2

Tabulka 4.1: Část karet zadání vybraných do první iterace

Iterace do uvolnění první verze 1. Java 2 Platform, Enterprise Edition < h t t p : / / j ava . sun . com>

46

4.2. EXTRÉMNÍ PROGRAMOVÁNÍ Iterace předcházející uvolnění první verze trvají jeden až čtyři týdny. Tým ve této studii kvůli podmínkám (brzké otevření centra) provede jen dvě iterace. Během první je vytvořena kostra systému, trvá dva týdny. Druhá slouží k doplnění systému o karty zadání s nejvyšším přínosem pro zákazníka, které lze v daném čase zvládnout. Na začátku každé iterace probíhá iterační plánovací hra sloužící k převedení vybraných karet zadání pro danou iteraci na úkolové karty pro programátora. Příklad úkolové karty je na obrázku 4.2. Každý programátor vezme část z karet zadání a rozebere tyto zadání na jednotlivé úkoly, které jsou napsány do úkolových karet. Pracnost jedné úkolové karty má být v řádu několika málo dnů (počet odhaduje tým z předchozích zkušeností), pokud tedy nějaký úkol zabere delší čas, musí být dále rozdělen na menší úkoly. Naopak nenáročné úkoly jsou sloučeny do jedné úkolové karty. Datum Pcf l i úkolu

1212 ÄCbfliüüpcp 5J 11ÍÍ programátor pdhad útalu | .Ť f::reba r ; i ; ; : : j ' - : -1s-f = ;io radar-, der láli ' .i ivaic: -.= 11 r^rer. aci kunj

programátora Sltdtrvíňi' úkolu nátura

Salus

[MU

Pů známky

Obrázek 4.2: Ukázka úkolové karty Časovým odhadem příslušné úkolové karty přebírá programátor odpovědnost za její implementaci. Při plánování iterace sečte každý programátor odhady na svých úkolových kartách a výsledný počet násobí zátěžovým faktorem (viz další odstavec). Když je některý programátor přetížen, předá část svých karet méně zatíženým kolegům (již během pláno­ vání). Pokud jsou Přetíženi všichni, je nutné se vrátit do plánovací hry a přehodnotit rozsah celé iterace. Veškeré odhady během plánovací hry i iterační plánovací hry předpokládají, že progra­ mátor bude mít jen jeden odhadovaný úkol a při jeho implementaci nebude rušen, vznikají tak odhady v tzv. ideálním čase. Zátěžový faktor je určen k přepočítání ideálního času na kalendářní, tedy skutečnou délku. I pro zkušené programátory má tento faktor minimální hodnotu dva, tedy ve skutečnosti jim úkol zabere alespoň dvakrát tolik času, než je odha­ dováno, protože se během vývoje musí věnovat i ostatní činnosti. Ve studii má tým zkušené programátory, takže hodnota jejich faktoru je dva, na první iteraci tedy mají pět ideálních dnů. Programátor zastávající roli kouče je většinou i stopa­ řem, ostatní činnost ho bude více zaměstnávat, proto na první iteraci bude mít dva ideální dny. Stejně tak programátor v roli testera, který bude zákazníkovi pomáhat s psaním testů funkcionality. V týmu je šest programátorů, dva ideální dny mají dva členové, od ostatních se čeká pět ideálních dnů. V součtu tedy během první iterace (deset kalendářních dnů) plánuje šesti­ členný tým implementovat úkoly v rozsahu dvaceti čtyř dnů. Během každého dne je implementace řízena testy, příklady lze najít v knize Programo47

4.2. EXTRÉMNÍ PROGRAMOVÁNÍ vání řízené testy a v knize Agilní programování. Řešení případové studie pomocí TDD uvádí ve své diplomové práci Tomáš Hajdin, v této studii je tedy konkrétní příklad vy­ nechán. K oblasti testování v této studii jen uvedu, že testují jen provozní metody. Například by se otestovalo, zda nelze jeden kurt v daný okamžik rezervovat více lidem. Naopak se ne­ testují jednoduché funkce, ve kterých je malá pravděpodobnost chyby. Takovými funkcemi jsou většinou set a get metody, které nastavují a čtou atributy oběktů.

Zprovozňování Při zprovozňování je první verze software nasazena k zákazníkovi a jsou prováděny optimalizace a testování. Vzhledem k tomu, že v naší studii tým tři týdny vyvíjel ve zcela identickém prostředí k dodanému zákazníkovi (projekt byl domluven včetně dodávky a konfigurace hardware), neexistuje předchozí software k paralelnímu testování a akceptační testování probíhalo již během předchozích iterací, proběhla tato etapa bez problémů. Do­ konce skončila o den dříve. Tento den využil tým k oslavě nasazení a k regeneraci před dalším programováním.

Údržba Během údržby je prováděn servis nasazeného software, jsou implementovány nové a dříve odložené karty zadání. Ve studii bude probíhat vývoj stejným způsobem jako v před­ chozích iteracích, před nasazením. Délka iterace bude dva týdny. Prováděný servis však sníží programátorům počet ideálních dnů na čtyři. Tento počet je týmem předpokládán a sledováním ověřen. Aby tým zvýšil svou efektivitu, rozhodl se kouč rozšířit tým o další dva programátory. Takto se rozhodl již během etapy plánování, před nasazením uspořádal výběrové řízení a dva nováčky pomocí párového programování tým rychle zaškolil během etapy údržby. Rozšíření týmu na maximální počet deseti lidí by v tomto případě zvýšilo neudržitelně zátěž týmu, který by zaškoloval čtyři nové lidi.

Smrt Smrt nastává v okamžiku, kdy už zákazník nemá další požadavky. V této studii tento okamžik nikdy nenastane. Tým sice postupně implementuje všechny požadované karty za­ dání, takže by se zdálo, že tím projekt končí. Dodavatel však nadále poskytuje servis soft­ ware. Díky párovému programování ví o dodaném software všechno každý programátor, opravu tedy může realizovat kterýkoliv volný a ostatní mouhou mezitím pracovat na jiných projektech. Protože práce na software téměř ustala, je napsán krátký popis software, který poslouží jako podklady v době, kdy tým k projektu vrátí, například k dopracování nových poža­ davků. 48

4.3. CRYSTAL CLEAR 4.3

Crystal Clear

V této části je ukázán vývoj podle části 3.2.4 Životní cyklus, během něhož jsou použity po­ stupy z části 3.2.3 Postupy. Mapování Projekt začíná etapou mapování, kdy je sestaven tým (studie předpokládá, že zůstane složení týmu z předchozích projektů a této problematice se dále nevěnuje), následuje prů­ zkum, nastavení metodiky a bleskové plánování. Průzkum slouží k ověření, zda má projekt smysl, tedy jestli je tým připraven k realizaci požadavků a jestli software zvýší zákazníkův užitek. Jsou identifikováni budoucí uživatelé software (zákazník, recepční, trenéři a hráči), hlavní případy užití (rezervace kurtu, proná­ jem kurtu, prodej sportovního vybavení, ...) a požadavky na systém (webová rezervace, evidence hráčů,...). Nastaví se prvotní parametry metodiky, které budou korigovány během zdokonalujících workshopů. Jde o společnou domluvu týmu o rozsahu iterací a konvencí, které bude při projektu dodržovat. Během bleskového plánování je normálně vytvořen plán na další tři měsíce. Tým se roz­ hodne pro plánování jednoho měsíce, na konci kterého je otevřeno squashové centrum. Zá­ kladem jsou identifikované požadavky sepsané na bleskových plánovacích kartách. Několik ukazuje obrázek 4.3. Je na něm uvedeno, že za úkol „Design webu" je zodpovědný Honza, protože je to člen týmu s nejlepším estetickým cítěním, návrh obrazovek proto pravidelně dělá on. Přitom využívá postup optimalizace rozhraní, popsaný v knize Crystal Clear [5].

Evidence hráčů 1 týden

Honza Design webu 1 týden

Testy evidence 1 týden

Obrázek 4.3: Ukázka bleskové plánovací karty Bleskové plánování je detailně popsáno v knize Crystal Clear [5] na straně 68 až 75, zde uvádím jen bodově, jak vzniká plán. 1. účastní se všichni, společná zodpovědnost 2. 15minutový brainstorming, vzniknou bleskové plánovací

karty 49

4.3. CRYSTAL CLEAR 3. rozmístění karet, podle priority a vzájemných závislostí 4. revize karet, doplnění chybějících 5. přidání odhadů a vývojářů (pokud jsou nutní k danému úkolu) 6. seřazení karet, přezkoumání závislostí 7. výběr běžící kostry, první verze 8. identifikace dalších verzí 9. optimalizace podle projektových priorit 10. poznamenání, výsledný plán Vše je na závěr prodiskutováno na workshopu. Délka celého mapování jsou 2 dny. Dodávka a iterace Software je vyvíjen a dodáván zákazníkovi. Jedna etapa dodávky v sobě může obsahovat jednu nebo víc iterací. Ve studii tým zvolil délku dodávky 1 měsíc a stejnou délku iterace, na konci první iterace tak zákazníkovi k otevření centra dodal běžící kostru. Při realizaci běžící kostry se často stává, že je hlavní vývojář přetížen mnoha úkoly, neboť je jediný v týmu, který má potřebné znalosti. Tým ve studii tento problém nemá, protože se skládá ze zkušených vývojářů, zátěž je tedy rovnoměrně rozložena. V dalším průběhu projektu při zdokonalovacím workshopu se tým shodl, že bude lepší provádět dvě iterace v každé dodávce, zkusili přitom zkrátit délku iterace na 3 týdny. Na začátku každé iterace je věnováno půl dne k jejímu naplánování. Každý vývojář má přiděleny dva úkoly, které má během iterace realizovat. Pracovní den Pracovní den začíná denní schůzkou (převzaté z metodiky SCRUM) na které se každý člen vyjádří ke své práci: •

co udělal předchozí den,

•

co plánuje dělat dnes,

•

jaké má překážky.

Celý tým má tak přehled, na čem ostatní právě dělají a můžou je v průběhu dne požádat o radu, když dělají na souvisejícím problému. Případně můžou sami poradit, pokud znají postup k odstranění překážek. Vše se ale řeší až po schůzce mezi zainteresovanými členy, schůzka tak nepřesáhne čtvrt hodiny. Během dne pak vývojáři opakovaně navrhují, implementují a testují své úkoly. Úspěšně otestované úkoly integrují do dodávaného software. Integrace tedy probíhá několikrát za den. 50

4.4. DYNAMIC SYSTEMS DEVELOPMENT METHOD Předání Jde o poslední etapu, kdy je celý software už hotový a nasazený u zákazníka. Je předána požadovaná dokumentace. 4.4

Dynamic Systems Development Method

Podle portálu konsorcia DSDM [7] říká metodika co se má kdy dělat, ale neříká už jak. V řešení studie můžu tedy také uvést pouze, co se v jednotlivých etapách vývojového cyklu děje. Bohužel už nemůžu demonstrovat jak. Když k tomu přidám, že jsem kvůli omezení licencí nezjistil moc detailní informace, nezbývá mi než konstatovat, že řešení studie touto metodikou je stručněji prezentováno než předešlé. Úvod projektu a studie proveditelnosti Tyto dvě sekvenční etapy ověří, zda je projekt dobře nakonfigurován a zda lze použít metodiku DSDM. Nemůžu tvrdit, že je metodika pro studii vhodná a že požadovaný soft­ ware lze nad frameworkem metodiky realizovat. Budu ale dále předpokládat, že metodika vhodná je a framework použít lze. Vznikají dokumenty Zpráva o proveditelnosti a Rámcový plán, ve kterém se stanoví milníky projektu. Obě etapy dohromady zaberou 3 dny, neboť studie je pro DSDM malý projekt. Obchodní studie V této etapě je naplánován workshop se zákazníkem a jeho zaměstnanci, kde tým iden­ tifikuje a zkoumá obchodní procesy ve firmě zákazníka. V této etapě se získávají požadavky a navrhuje prvotní architektura. Jsou vytvářeny následující dokumenty: •

Definice prostředí firmy, kde je uvedeno, že firma se skládá z majitele, trenérů a re­ cepčních. V dokumentu jsou mimo jiné tyto obchodní procesy: trénování hráčů, pro­ nájem kurtů (firmám i hráčům na jednotku času), prodej a půjčování sportovních po­ třeb.

•

Definice architektury je prvotním návrhem aplikačního software.

•

Rámcový plán pro prototyp určuje strategii použitou k vývoji prototypu.

Etapa ve studii trvá 3 dny. Stanovení modelu funkcí Tato etapa je již iterační a slouží k převedení požadavků do podoby modulů a funkcí. Opakovaně se: •

identifikuje funkční prototyp, 51

4.5. SROVNÁNÍ ŽIVOTNÍCH CYKLŮ •

stanovuje a potvrzuje harmonogram prací,

•

vytváří funkční prototyp

•

provádí revize prototypu.

Ve studii tak vzniknou například modul k u r t y nebo modul h r á č i s funkcemi p ř i d e j h r á č e , smaž h r á č e a e d i t u j h r á č e . Etapa trvá týden. Návrh a implementace Tato etapa se podobá předchozí, opakují se kroky: •

identifikace návrhového prototypu,

•

stanovení a potvrzení harmonogramu,

•

vytvoření návrhového prototypu,

•

revize prototypu.

Zde se vytváří požadovaný software, je opakovaně navrhován, sestavován a testován. Sou­ běžně jsou s uživateli konzultovány a upravovány obrazovky. Etapa trvá týden. Nasazení Během této etapy je nasazen software u zákazníka. V případě složitějšího systému může být rozdělena do více iterací, ve studii bud však stačit jedna, trvající týden, během kterého jsou zaškoleni uživatelé. Za normálních okolností se k software přidává uživatelský manuál a zhodnocení projektu. Protože však za měsíc bylo uděláno relativně málo z celé aplikace a uživatelé jsou zaučení, domluvilo se tentokrát vynechání dokumentů. Práce na projektu dále pokračuje, tým se vrací k stanovení modelu funkcia vytváří další inkrementy Z počátku se nechají délky etap na 1 týdnu (každé 3 týdny zákazník získá novou verzi), později se protáhnou na dvojnásobek a inkrementy budou rozsáhlejší. Závěr projektu Projekt končí dodáním všech požadavků a ověřením, že aplikace funguje efektivně a spl­ nila zákazníkovo očekávání. 4.5

Srovnání životních cyklů

Považoval jsem za vhodné před srovnáním životních cyklů metodik alespoň částečně tento cyklus ilustrovat. Z tohoto důvodu je srovnání cyklů až v této kapitole 4 Případová studie a ne v předchozí 3.4 Srovnání vybraných metodik. Všechny metodiky používají iterační a inkrementální vývoj s volitelnou délkou iterace. Liší se však obdobím, kdy provádějí integraci. XP několikrát za den vždy po dokončení 52

4.5. SROVNÁNÍ ŽIVOTNÍCH CYKLŮ úkolu. Crystal Clear (CC) volí b u ď stejný styl integrací jak XP, nebo je provádí po několika málo dnech. DSDM provádí integraci také v krátkých cyklech, ale až v etapě návrh a imple­ mentace. XP a CC tedy provádí integraci v průběhu celého projektu, DSDM jen v jedné fázi. Projektům, kde častá integrace není možná (například pro časovou náročnost), se dokáže nejlépe přizpůsobit CC. Naopak XP jen z velkými problémy, pravděpodobně by neuspělo. Pro získávání požadavků a plánování verzí používají všechny metodiky workshopy, kde se komunikací snaží ze zákazníka vytáhnout potřebné informace, následně podle zákazní­ kem určených priorit poskládat plán. XP používá plánovací hru, kde zákazník píše karty zadání. DSDM k tomuto slouží časové bloky a MoSCoW. CC používá bleskové plánování nebo jako alternativu zvolí způsob metodiky XP, DSDM nebo SCRUM. Jako nejsnazší k po­ chopení a přijetí považuji plánovací hru, bleskové plánování je hůře realizovatelné, ale více přehledné. Metodiky DSDM a CC ve svých cyklech plánují optimalizaci rozhraní vyvíjeného soft­ ware, podloženou definovanými postupy práce. Je tedy patrný důraz na vzhled a použi­ telnost. Oproti tomu XP klade důraz především na fungující kód. Jistě se snaží, aby byl zákazník s rozhraním spokojen, žádné konkrétní postupy však nedefinuje. Srovnat lze metodiky i na základě velikosti týmu, kde je XP nejflexibilnější, většinou začíná s malým týmem (2 programátoři) a podle potřeby se rozšiřuje na tým až o 10 členech. U metodiky CC a DSDM má tým maximální velikost 6 členů. Z pohledu rozsahu projektu je na tom pak nejhůře CC, protože má nejmenší tým. Nejlépe je na tom DSDM, která má sice malý tým, ale jako jediná ze srovnávaných dokáže řídit i více týmů. DSDM mi připadá jako metodika s nejlépe propracovanou analýzou, téměř jako u tradič­ ních přístupů. Nelze se divit, protože je určená pro velké softwarové firmy. Jen ty si můžou dovolit platit licence a můžou akceptovat období, kdy se vývojář učí a zvyká si používat framework, nepřináší tedy firmě dočasně užitek.

53

Kapitola 5

Závěr Hlavním cílem práce bylo získání přehledu o agilních metodikách, což se mi povedlo, své postřehy uvádím v kapitole 2. Agilní metodiky. K dalšímu zkoumání jsem si vybral meto­ diky Extrémní programování, Crystal metodiky a Dynamic Systems Development Method a snažil jsem se o jejich srovnání, což se mi přes určité obtíže uváděné dále podařilo v kapi­ tole 3. Vybrané agilní metodiky, kde jsou metodiky nejdříve popsány a následně srovnány Poslední úkol, demonstrace vybraných metodik na případové studii, je řešený v kapitole 4. Případová studie. Oblast agilních metodik není u nás zatím moc rozšířená, proto jsem musel ve velké míře čerpat z elektronických zdrojů, odkazovaných ze stránek Aliance agilního vývoje software [1]. Další komplikací byl fakt, že metodika DSDM je omezena licencí, čímž je omezena do­ stupnost detailních informací o této metodice. Poslední komplikací bylo zjištění, že meto­ diky rodiny Crystal nejsou zatím kompletní. V práci jsem se tedy zaměřil hlavně na nejpro­ pracovanější metodiku z rodiny, na Crystal Clear. Po vypracování této práce předvídám agilním metodikám slibnou budoucnost. Jsou po­ stavené na rozumných principech. Jejich největší předností je flexibilita, z jakou se dokáží přizpůsobit měnícím se podmínkám a požadavkům na projekt, a rychlost, z jakou dokáží dodat první omezené funkční verze. Se zájmem budu i nadále sledovat dění v této oblasti vývoje software. Agilní metodiky lze dále zkoumat v mnoha směrech. Jedním je jejich postupné zdoko­ nalování a vylepšování, aby pokrývaly širší spektrum projektů. Dále lze zkoumat možnosti spolupráce mezi agilními metodikami nebo mezi agilním a tradičním přístupem. Jako po­ slední směr bych uvedl zkoumání podpůrných nástrojů agilních metodik, jakým je napří­ klad framework DSDM. Zjišťování technický limitů by jistě přineslo zajímavé výsledky.

54

Literatura [1] Beck, K. a Beedle, M. a Bennekum, A. a Cockburn, A. a Cunningham, W. a Fowler, M. a Grenning, J. a Highsmith, J. a Hunt, A. a Jeffries, R. a Kern, J. a Mariek, B. a Martin, R. a Mellor, S. a Schwaber, K. a Sutherland, J. a Thomas, D.: Aliance agilního vývoje

software
org>.

[2] Beck, K. a Beedle, M. a Bennekum, A. a Cockburn, A. a Cunningham, W. a Fowler, M. a Grenning, J. a Highsmith, J. a Hunt, A. a Jeffries, R. a Kern, J. a Mariek, B. a Martin, R. a Mellor, S. a Schwaber, K. a Sutherland, J. a Thomas, D.: Manifest agilního vývoje

software
org/>.

Computer Press, 2004, 80-251-0342-0.

[4] Buchalcevová, A.: Agilní metodiky In sborník konference Objekty, Česká zemědělská univerzita v Praze, 2002, 53-62. [5] Cockburn, A.: Crystal Clear: A Human-Powered Addison-Wesley, 2005,0-201-69947-8.

Methodology

for Small

Teams,

[6] Hajdin, T: Agilní metodiky vývoje software [Diplomová práce], Fakulta informatiky Masarykovy univerzity v Brně, 2005. [7] Portál konsorcia DSDM
org>.

//www. rational.

com>.

[9] Fowler, M.: Refaktoring - Zlepšení existujícího kódu, Grada, 2003,80-247-0299-1. [10] Beck, K.: Programování řízené testy, Grada, 2004,80-247-0901-5. [11] Abrahamsson, P a Salo, O. a Ronkainen, J. a Warsta, J.: Agile software development methods: Review and analysis, VTT Technical Research Centre of Finland, 2002, 95138-6010-8. [12] Beck, K.: Extrémní programování,

Grada, 2002,80-247-0300-9.

55