Fakulta elektrotechnická

České vysoké učení technické vpraze Fakulta elektrotechnická BAKALÁŘSKÁ PRÁCE Agilní metodiky programování DAQařídicích aplikací Praha, 2011 Autor: Adam Hamr

Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně aže jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o dodržování etických principů při přípravě vysokoškolských závěrečných prací. V Praze dne podpis i

Poděkování Na tomto místě bychrád poděkoval především panu Doc. Ing. Jaroslavu Roztočilovi, CSc., vedoucímu bakalářské práce, za jeho vstřícnost během vedení práce. Také děkuji panu Ing. Milanu Kaši za odbornou pomoc a ochotu spolupracovat í dalším, kdo podpořili mou práci dobrou radou. ii

Abstrakt V poslední době se rozmach agilních metodik vývoje softwaru ustaluje a ty získaly svou konkrétní podobu. Mnozí softwaroví specialistéjižvědí, co se dáodnichočekávat. Jejich správné užití vedekrychlému dosažení kvalitních výsledků. Vývojovému týmu přitom do jisté míry zůstává možnost postupovat podle svých zaběhnutých zvyklostí. Práce poskytuje náhled na techniky agilního vývoje a porovnává je.také shrnuje zkušenosti odborníků. iii

Abstract In the last years the expansion of agile software development methodics stabilizes. Therefore methodics obtain a clear schemes. Many software experts are aware of what we can expect from them. The right use of them leads to a fast achievement of quality results. In addition to this the developing team could continue to a certain extent with his custom practice. This essay has to provide a view on agile techniques of software development and compares them. It summarises experience of experts as well. iv

vi

Obsah Seznam obrázků xi 1 Úvod 1 1.1 Struktura písemné práce................................ 1 1.2 Základní pojmy..................................... 2 1.2.1 Metodika.................................... 2 1.2.2 Iterativní vývoj................................. 2 1.2.3 Inkrementální postup............................. 2 2 Historický kontext vzniku agilních metodik 3 2.1 Vodopádový modelživotního cyklu.......................... 4 2.1.1 Výhody..................................... 4 2.1.2 Nevýhody.................................... 5 2.2 Spirálový modelživotního cyklu............................ 5 2.2.1 Průběh vývoje................................. 5 2.2.2 Výhody..................................... 6 2.2.3 Nevýhody.................................... 6 2.3 Rational unified process (RUP)............................ 7 2.3.1 Klíčové pojmy................................. 7 2.3.2 Výhody..................................... 7 2.3.3 Nevýhody.................................... 8 2.4 Unified software development process (UP)..................... 8 3 Agilní metodiky 9 3.1 Základní charakteristika agilních metodik...................... 9 3.1.1 Manifest agilního vývoje softwaru...................... 9 3.1.2 Principy umožňující progresivní vývoj.................... 10 3.1.3 Omezující požadavky............................. 10 3.1.4 Odlišnosti od tradičních metodik....................... 11 vii

3.1.5 Nevýhody agilních metodik.......................... 12 3.2 Přehled nejběžnějších agilních metodik........................ 13 3.3 Extrémní programování................................ 14 3.3.1 Charakteristika................................. 14 3.3.2 Základní principy................................ 15 3.3.2.1 Příklady známých myšlenek a postupů.............. 15 3.3.2.2 Čtyři proměnné charakterizující vývoj............... 16 3.3.2.3 Čtyři hodnoty............................ 16 3.3.3 Základní metody XP.............................. 17 3.3.4 Základní činnosti................................ 18 3.3.5 Průběh vývoje jedné verze........................... 19 3.3.6 Vývoj první verze............................... 20 3.3.7 Týmové role.................................. 21 3.3.8 Závěr...................................... 21 3.4 Lean software development.............................. 22 3.4.1 Základní charakteristika............................ 22 3.4.2 Klíčové pojmy................................. 22 3.4.2.1 Plýtvání............................... 22 3.4.2.2 Hodnota............................... 23 3.4.3 Klíčová pravidla................................ 24 3.4.4 Základní principy................................ 27 3.4.5 Závěr...................................... 28 3.5 Scrum development................................... 29 3.5.1 Základní charakteristika............................ 29 3.5.2 Klíčové pojmy................................. 29 3.5.2.1 Flexibilita a spolupráce....................... 29 3.5.2.2 Backlog................................ 30 3.5.2.3 Graf zbývající práce......................... 30 3.5.2.4 Riziko................................. 31 3.5.2.5 Sprint................................. 31 3.5.2.6 Pigs a chickens............................ 31 3.5.2.7 Denní schůzka............................ 31 3.5.3 Průběh vývoje................................. 32 3.5.3.1 Průběh jednoho sprintu....................... 32 3.5.3.2 Předčasné ukončení sprintu..................... 33 3.5.4 Týmové role.................................. 33 3.5.5 Spolupráce více týmů............................. 34 viii

3.5.6 Závěr...................................... 35 3.6 Feature driven development.............................. 35 3.6.1 Základní charakteristika............................ 35 3.6.2 Klíčové pojmy................................. 35 3.6.2.1 Vlastnost............................... 35 3.6.2.2 Přístup řízený modelem....................... 36 3.6.3 Průběh vývoje................................. 36 3.6.4 Základní principy................................ 38 3.6.4.1 Objektové modelování domén................... 38 3.6.4.2 Vývoj podle vlastností....................... 39 3.6.4.3 Vlastnictví tříd............................ 39 3.6.4.4 Týmy sestavované podle vlastností................. 39 3.6.4.5 Inspekce............................... 40 3.6.5 Závěr...................................... 40 3.7 Test driven development................................ 40 3.7.1 Charakteristika................................. 40 3.7.2 Základní principy................................ 41 3.7.3 Průběh vývoje................................. 41 3.7.3.1 Průběh jednoho cyklu........................ 42 3.7.4 Závěr...................................... 42 3.8 Porovnání agilních metodik.............................. 43 3.8.1 Velikost týmů aprojektů........................... 43 3.8.2 Náročnost na zavedení a provoz........................ 43 3.8.3 Míra omezení pravidly............................. 44 3.8.4 Rozšířenost................................... 44 3.8.5 Přijatelnost pro zákazníka........................... 44 3.8.6 Zajištění kvality (quality assurance)..................... 44 3.8.7 Kombinace metodik.............................. 46 3.8.8 Truck factor................................... 46 3.8.9 Psaní nadbytečného kódu........................... 46 3.8.10 Dokumentace.................................. 47 3.8.11 Společné vlastnosti............................... 47 3.9 Řízení projektů v praxi................................ 47 3.9.1 Agilní metodiky................................ 48 3.9.1.1 Výhody, kterých si firmy nejvíc cení................ 48 3.9.1.2 Nevýhody, které firmám nejvíc vadí................ 48 3.9.2 Ostatní způsoby řízení projektů........................ 49 ix

4 Závěr 51 A Název přílohy B Obsah přiloženého CD I III x

Seznam obrázků 2.1 Schéma vodopádového modelu životního cyklu................... 4 2.2 Schéma spirálového modelu životního cyklu; zdroj - http://3.bp.blogspot. com/_el72o8-wx9g/tndqfsrlfbi/aaaaaaaaacu/2dxxgjj99cy/s1600/spiral_model. gif............................................ 6 3.1 Cena změny požadavků; zdroj - developerfusion.com................ 12 3.2 Možnápodobakartyzadání používané v XP. Její obsah stanovuje zákazník.; překresleno podle 9.................................. 17 3.3 Vzájemný vztah činností vxp;překresleno podle 9................ 19 3.4 Postup při vývoji podle tradičních metodik; překresleno podle 9......... 25 3.5 Graf zbývajícípráce; zdroj - http://www.businessvize.cz/rizeni-a-optimalizace/agilniprojektove-rizeni.................................... 30 3.6 Schéma vývoje softwaru podle FDD; překresleno podle 9............. 36 3.7 Postup při vývoji softwaru podle TDD; překresleno podle 9............ 42 xi

xii

Kapitola 1 Úvod Stále více softwarových společností se v dnešní době zabývá efektivitou vývoje a pokoušíseoco nejlepší využití svých sil a zdrojů. Každá která mezi ně patří, zcela jistě použije zásady, které již zavedlyněkteré z agilních metodik. Aplikuje tyto principy, at se na agilní techniky přímo orientuje nebo ne. Také jestále více firem, které sezabývají otázkou, jestli by tyto techniky nebyly přínosné právě proně. To svědčíotom,že agilní programování užnení nic mimořádného nebo nadstandardního. Pravděpodobně přichází jako nová etapa softwarového inženýrství 1 av budoucnu se bez zavedení podobných postupů neobejde žádný projektovýmanažer. Účelem této práce je přiblížit a zhodnotit jednotlivé způsoby organizace vývoje. Dále také porovnat výhody a nevýhody jednotlivých agilních metodik a naznačit možnosti jejich začlenění. Také jsem se zaměřil na eventuality jejich kombinací. Práce tedy může pomoci jako vodítko při hledání vhodného způsobu řízení projektůprokonkrétní vývojový tým. 1.1 Struktura písemné práce Práce má čtyři kapitoly. V první kapitole je rozebráno zadání, popsána struktura dokumentu auvedenyněkteré důležité pojmy. Druhá kapitola slouží jako ilustrace historických souvislostí a prezentuje tradiční postupy. Třetí kapitola nejprve charakterizuje a dál porovnává různé agilní metodiky. Také jezařazena podkapitola se souhrnem praktických zkušeností vřízení softwarových projektů. Zhodnocení přínosu jednotlivých druhů řízení projektůsenachází v kapitole čtvrté. V příloze je popsána funkcionalita modulu do řídicího systému DisCo. 1 Softwarové inženýrství je zavedení apoužívání řádných inženýrských principů tak, abychom dosáhli ekonomické tvorby softwaru, který je spolehlivý a pracuje účinně na dostupných výpočetních prostředcích. (Václav Kadlec, 2004, strana 22) 1

2 KAPITOLA 1. ÚVOD 1.2 Základní pojmy V oblasti řízení softwarových projektů jsouklíčové následující pojmy,které budu používat. 1.2.1 Metodika Voblastivývoje softwaru jde o komplexní postup, návod pro vývoj aplikace. Zabývá se pohledem zvýšky na projekt jako celek. Radí, proč akdysemácodělat, co se má vytvořit a kdo má na starosti jaký úkol. Neodpovídá napodrobnéotázky, jak přesně semáněco provádět - na ty odpovídají dílčí metody. Avšak metodika vypovídá víc než modelživotního cyklu, který pouze říká, kterými fázemi softwarový produkt prochází. Je důležité, aby každý člen týmu metodiku znal a řídil se jí. 1.2.2 Iterativní vývoj Vývojový proces se rozdělí doněkolika iterací. V každé znichsekompletně zpracuje některý fragment systému. Po jeho dokončení se otestuje integrace této části do celého systému a je možné ji odevzdat zákazníkovi. Následuje dalšíiterace. 1.2.3 Inkrementální postup Spočívá vtom,že už odprvní iterace existuje funkční apoužitelný systém. S každou dalšíiterací se rozšiřuje o nové funkcionality. Tím se umožňuje otestování vpraxiuž od raných fází vývoje. Zároveň zákazník vidí, jak postupuje práce a může se k ní vyjadřovat.

Kapitola 2 Historický kontext vzniku agilních metodik Do konce šedesátých let 20. století sedajípokusyovývoj softwarových aplikací označit jako průkopnické. Koncem šedesátých let došlo k softwarové krizi způsobené špatným vedením projektů atakézvyšováním nároků naně. Jejím hlavním důsledkem byl neúspěch, přesněji nedodání, většiny projektů [ 9 kap. 2.2]. V sedmdesátých letech vzniká obor softwarové inženýrství [ 9 kap. 2 ]. Ten souvisí především s rozšířením aplikací interagujících s uživatelem a dále se zvýšením dostupnosti hardwaru. V roce 1967 vznikl Ericssonův model, který začal modelovat složité systémy jako množinu propojených bloků [ 9 kap. 8.1]. Vtéto době sevývojáři začali zamýšlet nad tím, jak zvýšit efektivitu práce, a vývoj se formoval do konkrétních podob. Efektivita spočívala především v uspořádání vývoje softwarového projektu do posloupnosti fází. Mezi ně byla nově zařazena zejména analýza a specifikace požadavků. Tím vznikl vodopádový modelživotního cyklu. V osmdesátých letech se softwarové inženýrství dále rozvíjelo. Vypukl převratný objektově orientovaný přístup a s ním nové postupy. Efektivita vývoje spočívala v jeho řízení určitou metodikou. Roku 1985 Barry Boehm představil spirálový modelživotního cyklu, který přinesl iterativnípřístup. Tím se začala ošetřovat rizika, která mohou při vývoji vzniknout. 1987 vyvinul Ivar Jacobson ve spolupráci s telekomunikační firmou metodiku Objectory process a tím byly položeny základy pro metodiky RUP a UP - viz dále. Objectory process poprvé pracuje s pojmem případ užití. Devadesátá léta přinesla dalšídvadůležité koncepty. Roku 1995 šlo o metodiku Rational unified process a roku 1999 o Unified software development process. Začátkem 21. století se efektivity vývoje dosahuje pomocí nové skupiny metodik vývoje - agilních. Roku 2001 byl pro ně položen základ Manifestem agilního vývoje softwaru. Nyní sepodívejme, o co jde v tradičních metodikách. 3

4 KAPITOLA 2. HISTORICKÝ KONTEXT VZNIKU AGILNÍCH METODIK Obrázek 2.1: Schéma vodopádového modelu životního cyklu 2.1 Vodopádový modelživotního cyklu Jde o první apravděpodobně nejznámějšímodelživotního cyklu. Zároveň prvnípředpis postupu při vývoji softwaru. Ten začal být poprvé členěn na jednotlivé aktivity. Postupuje se sekvenčně podle logické posloupnosti fází bezjakýchkoli iterací. Při každém přechodu mezi dvěma fázemi dochází ke schvalovacímu procesu. Během vývoje lze přecházet mezi fázemi vždy o jednu dopředu nebo zpět. Během údržby je možné sevrátit ke kterékoliv fázi a pokračovat následujícími. Tento model lze považovat za nejobecnějšípřípad metodiky, protože každá určitým způsobem zahrnuje fáze vývoje vodopádového modelu: 1. Definice problému, poznání zákazníka, proniknutí docílové oblasti 2. Analýza a specifikace požadavků 3. Návrh systému 4. Implementace systému 5. Integrace a testování systému 6. Provoz a údržba Model má spoustyrůzných podob a tato vychází ze[2]. 2.1.1 Výhody Každá fáze vychází pouzezvýstupního dokumentu té předchozí. K hlavním pozitivům modelu patří, že je jednoduchý apřístupný. Řízení procesu je tedy snadné avelicepřehledné. Velmi se

2.2. SPIRÁLOVÝ MODELŽIVOTNÍHO CYKLU 5 hodí pro jednoduché systémy. Výsledný projekt pak má disponovatúplnou dokumentací. 2.1.2 Nevýhody Tento postup se však svou jednoduchostí nehodíproprojektyrozsáhlejší. Striktně daná posloupnost fází způsobuje, že je vývoj nepružný, když nenímožné sevracetkfázím procesu starším nežjepředchozí. Potíže vznikají takétím, že není možnédodržet původníplán, pokud se zpozdí i jediná fáze. Po zahájení procesu zákazník nekomunikuje s dodavatelem a do poslední chvíle před dodáním mu není známé, jaký bude výsledek. Důsledkem toho je nejistota, zda je návrh správný. Jeho kompletní tvorba je v praxi nesplnitelná anavíc zabírá příliš mnoho času. Zásadní problém vodopádového modelu tedy spočívá ve specifikaci požadavků, kterou není možné provést najednou a později neměnit. Kvůli tomu je vývoj velmi neefektivní. 2.2 Spirálový modelživotního cyklu Nejdůležitějším přínosem tohoto modelu pro softwarové inženýrství jsoudvanovépostupy.jeto analýza rizik 1 a iterativnípřístup. S ním je spojena výhoda modularity aplikace 2.Vkaždéiteraci se opakují fáze, které popisuje vodopádový model.přitom se zpřesňují požadavky, odhalují se nová rizika a plánuje se následující cyklus. Během analýzy rizik se zjišt uje, co může ohrozit hladký průběh projektu, a připravují se reakce na tyto události. Rozlišují se tyto druhy rizik: Projektová rizika - příkladem je odchod lidí ztýmu Technická rizika - mezi ně patříproblémy s vývojovými nástroji Obchodní rizika - např. uvedení konkurenční aplikace Další z nejpoužívanějších metod k odstranění rizik a chyb je vytváření prototypů. 2.2.1 Průběh vývoje Podívejme se podrobněji na posloupnost kroků při vývoji podle spirálového modelu. Postupuje se podle obrázku obr. 2.2 po spirále od středu na kraj. Nejprve popišme čtyři kvadranty, kterými spirála prochází. Kdykoliv se projekt dostane do levého horního kvadrantu, stanovují secíle, 1 Riziko je jakákoliv událost, při které může být projekt ohrožen. 2 Aplikace je složena z modulů, z nichž každý zahrnujeurčitou elementární funkcionalitu. Jednotlivé moduly jsou použitelné nezávisle na ostatních a můžou být použity i v aplikacích zcela jiných, než pro které byly poprvé vyrobeny.

6 KAPITOLA 2. HISTORICKÝ KONTEXT VZNIKU AGILNÍCH METODIK Obrázek 2.2: Schéma spirálového modelu životního cyklu; zdroj - http://3.bp.blogspot.com/_el72o8-wx9g/tndqfsrlfbi/ AAAAAAAAACU/2DXXgJJ99CY/s1600/spiral_model.gif alternativy a omezení pro aktuální iteraci.pravýhorní kvadrant je vyhrazen analýze rizik. V pravém spodním kvadrantu probíhá realizace, což jehlavněspecifikacepožadavků, podrobnější návrh, implementace a testování. Posledníkvadrantjeurčen k plánování další iterace. 2.2.2 Výhody Je kladen velký důraz na analýzu rizik a úspěšně setedypředchází většině problémů, ke kterým může při vývoji dojít. To včas vyloučí nevhodná řešení. Další výhody spirálového modelu spočívají v jeho komplexnosti, takže je vhodný prosložité projekty.takévtom,že je pro každou aktivitu a zdroj definována míra dostatku. Riziky řízený přístup například umožňuje stanovit, kolik času je potřeba vyhradit jednotlivým krokům. 2.2.3 Nevýhody Komplikovaný spirálový modelpřinášínásledující nevýhody: Je zatížen množstvím byrokratických povinností, což snižuje efektivitu a rychlost vývoje. Členové týmu musí být schopni spolehlivě analyzovat zdroje rizik, jinak projekt může ztroskotat. Během práce nelze provádět změny kdykoliv, jen po dokončení cyklu. Tím vznikají zbytečné časové prodlevy.před konečnou fází nenídodán žádný software a do té doby není zákazníkovi známá jeho podoba. Spirálový model není skutečnou metodikou a nepopisuje tedy ani zhruba všechny důležité činnosti.

2.3. RATIONAL UNIFIED PROCESS (RUP) 7 2.3 Rational unified process (RUP) V tomto odstavci se zaměříme na velmi obecnou, širokou a mohutnou metodologii 3 vhodnou pro mnoho druhů projektů. Jejím tvůrcem je Ivar Jacobson s firmou Rational. Ta v současnosti spadá podibm[?? ]. Vývoj probíhá v iteracích, což mápodobnýpřínos jako u spirálového modelu. Předchází se rizikům, snáz se spravují změnyamodulytvořící aplikaci jsou použitelné opakovaně. Také sedařípřiblížit se lépe k zákazníkovi. Fáze každé iterace jsou zahájení (Inception), projektování (Elaboration), realizace (Construction) a předání (Transition) [ 1 ]. Přístup RUP nenípřímo řízený riziky jako Spirálovýmodel,nýbržpřípady užití. Metodologie je objektově orientovaná - definuje všechny důležité elementy pro modelování aproplánování vývojového procesu. Každý element má podrobný popis, jak ho realizovat. Jsou čtyři [ 1 ]: Role a pracovníci - Radí jak obsadit role. Odpovídá naotázku kdo? Činnosti - Každáznichmá konkrétnívýsledek (meziprodukt). Popisuje, jak ho dosáhnout. Odpovídá naotázku jak? Meziprodukty - Části informace použité v procesu. Odpovídá naotázku co? Pracovní procesy - Posloupnost činností a interakce mezi pracovníky. Odpovídá naotázku kdy? 2.3.1 Klíčové pojmy Co je pro RUP specifické, je například prácesezákazníkovými požadavky. Řízení asprávu zákazníkových nároků ani jeden ze dřívějších modelů nezahrnují. Dále je definována úspora zdrojů. K tomu je zřízena podpora komponentové architektury. Komunikace mezi vývojáři je zjednodušena díky vizuálnímu modelování softwaru - využívá se notace UML. Metodologie je sní dokonale provázaná apoužití UMLpakpři vývoji je výhodné. Kvalita je kontrolována a zajišt ována průběžně, a tak se každá chyba odhalí krátce po tom, co nastane. Její opravajeo to levnější. Dalším ulehčením korekcí chyb, ale i jiných úprav je doporučení, aby změny byly řízené. 2.3.2 Výhody Tato metodologie umožňuje upravit a přizpůsobit návod pro každý projekt. Ten pak obsahuje podrobně propracované a zdokumentované krokyvývoje od začátku až do konce. Výrobce RUP údajně průběžně pracuje na vývoji metodologie, takže podporuje i nové technologie. Je známá a rozšířená a existuje k ní množství doplňujících informací anávodů. 3 Metodologie je obecnějšípojemnežmetodika.jevědní disciplínou, která sezabývá metodikami.

8 KAPITOLA 2. HISTORICKÝ KONTEXT VZNIKU AGILNÍCH METODIK 2.3.3 Nevýhody Existuje však množství důvodů, proč seruppoužívat nehodí. Především pro malé projekty je postup neefektivní. Metodologie požaduje hluboké studium a tým vždy stráví mnohočasu zkoumáním návodu a vytvářením meziproduktů. Dalším argumentem je, že projektoví inženýři amanažeři musí být trénováni v práci s RUP, jinak projekt nemusí skončit úspěšně. RUP se prodává jako komerční softwarový produkt. 2.4 Unified software development process (UP) Tuto metodiku vydal Ivar Jacobson jako knihu čtyři roky po vzniku RUP. UP je určitým zjednodušením RUP. Rovněž jde o inkrementální vývoj v iteracích. Každá z nich se skládá zfází plánování, analýzaanávrh, implementace, testování a integrace, dodání. Vývoj je řízen případy použití a riziky. UP požaduje dávat důraz na architekturu. Na rozdíl od RUP nerozebírá do hloubky všechny postupy. Je bezplatná, avšak neposkytuje žádné doplňky a bonusy. Také podpora různých vývojových nástrojůproupnení taková, jako pro RUP.

Kapitola 3 Agilní metodiky Agilní metodiky byly zavedeny z potřeby učinit vývoj efektivnější, kvalitnějšíarychlejší. Proto se silně zaměřujínavýsledek. Takévýznam slova agilní značí, že jde o vývoj velmi aktivní, svižný, bez zdržování ačasových prostojů ujednotlivých fází. 3.1 Základní charakteristika agilních metodik Tyto techniky zabezpečí softwarovým firmám flexibilitu, přizpůsobivost a pružnost. Dále metodiky omezují zmatek, nejistotu a nervozitu v týmu a maximalizují produktivitu. Jedním slovem lze agilní vývoj charakterizovat jako - progresivní. Charakteristika je dána manifestem agilního vývoje softwaru (viz [ 3 ]a dále). Během práce je dobře vidět postup k cíli. Programátor průběžně odevzdává jednotlivé části projektu. Těm již nemusí věnovat přílišnou pozornost a může se plně zaměřit na aktuální problém. Pokud vznikají nějaké potíže, pracovník se o nich včas dozví. Například nespokojenost s ovládacími prvky uživatelského rozhraní může zákazník sdělit během raných iterací, protože vývoj často začíná formováním interface. Agilní metodiky jsou vhodné promaléa středně velké projekty. Nevedou k efektivnímu řešení velmi složitých a komplexních problémů. Takové je nutno dekomponovat na jednodušší. Většina autorů těchto metodik má zkušenosti s velkým neúspěchem nějakého projektu. Každý z nich si dobře uvědomil všechny výhody i nedostatky vývojových procesů. To je vedlo k vyvinutí flexibilních metodik, které vylepší produktivitu a efektivitu vývojového procesu. 3.1.1 Manifest agilního vývoje softwaru V roce 2001 se setkali nejvýznamnějšípředstavitelénových přístupů ketvorbě softwaru a formulovali principy pro agilní vývoj. Mezi nejznámější autory Manifestu agilního vývoje patříkent 9

10 KAPITOLA 3. AGILNÍ METODIKY Beck, Mike Beedle, Alistair Cockburn, Ward Cunningham, Martin Fowler, Jim Highsmith, Ken Schwaber, Jeff Sutherland. Než se tito lidé sešli, pracovali prakticky nezávisle na sobě anavývoj softwaru si vytvářeli vlastní názory, často radikální. Konsensus takto reformních osobností na konečné formulaci manifestu znamená, že se shodli na něčem podstatném. Základní teze, ze kterých manifest vychází: Přijmout a umožnit změnu je mnohem efektivnější, než se pokoušet jí zabránit. Je třeba být připraven reagovat na nepředvídatelné události, nebot ty bezpochyby nastanou. Jediná jistota je změna. Na základě těchto tezíautoři manifestu dávají přednost (překlad z [ 3 ]): individualitám a komunikaci před procesy a nástroji provozuschopnému softwaru před obsáhlými, objemnými dokumentacemi spolupráci se zákazníkem před uzavíráním mnoha smluv reakci na změnu před striktním plněním plánu Vážísivíce položek na levé straně,ikdyž hodnoty napravo také uznávají. 3.1.2 Principy umožňující progresivní vývoj Existuje vícero principů, které vedou k progresivitě. Mezi hlavní z nich patří jednoduchost a rychlost. Lidé nedělají nicnež to, co vede k cíli - funkční software. Neztrácí čas nadbytečnou analýzou, tvorbou málo významné dokumentace nebo kódu, jehož důležitost je pouze teoretická, ne skutečná. Zásadní jeumění najít co největšímnožství činností, které není nutno dělat. Další zásadou je navrhovat jen to, co je nezbytné pro aktuální implementaci. Nic se nenavrhuje s větším předstihem, protože je pravděpodobné, že se to v budoucnu změní. Jedině návrh pro okamžitou potřebu je zaručeně správný. Jinou důležitou věcí jedůraz na komunikaci uvnitř týmu. Metodiky zdůrazňují, že osobní komunikace je nejrychlejší a nejspolehlivější. Popisují konkrétnízpůsoby komunikace a předměty jednání. Vedoucí projektumásprávně motivovat pracovníky a také důvěřovat v jejich schopnost azodpovědnost. Kvalitu projektu podstatně ovlivňuje, jak je úzká spolupráce se zákazníky a obchodníky. Ti podle agilních metodik často mají být součástí vývojového týmu. 3.1.3 Omezující požadavky Agilní metodiky také požadují jistou disciplínu, aby bylo možné dosáhnout progresivity. Jedno z omezení spočívá vtom,že programátor nemá rozšiřovat zadání svými představami. Kvalita aplikace nenípřímo úměrnájejí robustnosti nebo obsáhlosti. Například neníúčelnépředpokládat,

3.1. ZÁKLADNÍ CHARAKTERISTIKA AGILNÍCH METODIK 11 že vytvářený databázový systém má umět naráz obsloužit stovky klientů, pokud je zákazník přesvědčen o tom, že uživateli budou pouze zaměstnanci jeho malé firmy. Za nejvýznamnější známku kvality se tedy má považovat výhradně daná funkčnost. Tou není nic z toho, co jen programátor vidí jako potřebné. Disciplinovaný pracovník pravidelně ověřuje funkčnost uzákazníka. Ten průběžně sleduje stav aplikace díky pravidelně vydávaným mezivýsledkům. Určuje správnost všech částí systému a jejich odezev. Důkladná komunikace se zadavatelem vede k tomu, že se vždy implementuje právě takové chování systému, jaké jesprávné. Dále je důležité, aby se nové verze dodávaly často a v malých dávkách. Tím se zajistí okamžitá a přesná zpětná vazba. Navíc časté odevzdávání subsystémů pomáhá vývojářům odhalovat chyby a urychluje získávání zkušeností. Dalším předpokladem je, že programátoři jsou otevření novým potřebám zadavatele. Na požadované změny musí reagovat prakticky ve kterékoliv fázi vývoje. To je umožněno hlavně iterativním postupováním. Manažer projektu musí být schopný sám plánovat podrobné krokyvdané situaci. Agilní metodiky nedefinují detailnímetody,jakprovádět jednotlivéčinnosti. Málokdy poradí konkrétní postup, což může na jednu stranu vypadat jako nevýhoda. Avšaknadruhoustranusezáměrně způsob řízení projektu nechává přizpůsobit okolnostem. Autoři Feature driven development tvrdí, že metodiky definované do detailů fungují jen v případech, kdy vývojový proces je předvídatelný a probíhá podlepřesně stanoveného plánu. To se všakvpraxiděje ojediněle, proto je cennější volnost v rozhodování nežslepédodržování předepsaných kroků. Manažer tedy musí zvážit, jestli mu stačí, že metodika jen ukáže směr, jakým se ubírat. Jinak si musí zajistit návod na veškeré postupy. 3.1.4 Odlišnosti od tradičních metodik Podmínky každého vývojového procesu se dá charakterizovat třemi základními proměnnými. Jsou to: čas vyhrazený provývoj, zdroje a funkcionalita produktu. Cílem při vývoji tradičním způsobem je splnit co nejpřesněji konkrétnípředpoklady dané dokumentem specifikace požadavků. Při vývoji podle agilní metodiky je cíl jiný - vytvořit projekt v definovaném čase a za určité náklady. Většinou je pro zadavatele přijatelnějšízměna specifikace požadavků nežzdražení nebo posunutí termínu dodání oprotipředpokladu. Požadavky se stejně mění vždycky, at chceme nebo nechceme. Rozdíl mezi oběma způsoby tedy spočívá vtom,že podle tradičních zvyklostí je hlavní neporušit podmínky vymezené proměnnou funkcionalita produktu aostatnídodržet jen v rámci možností vývojového týmu. A při agilním programování se naopak má zachovatčas vyhrazený provývoj a použít jen stanovené zdroje. Podle tradičních metodik se má předpokládat, že vývoj softwaru je definovaný proces. Podle nich úkoly mohou být detailně definovány, složitost implementace algoritmů jemožno popsat. Výsledky práce jsou přesně měřitelné aměřitelnost je vodítko při opakování procesů tak dlouho,

12 KAPITOLA 3. AGILNÍ METODIKY Obrázek 3.1: Cena změny požadavků; zdroj - developerfusion.com dokud tolerance nejsou zanedbatelné. Je tedy možné předem určit, jak bude probíhat vývojový proces. Tradiční metodiky jsou řízeny plánem. Agilní metodikyplánu nepodléhají, vycházejí zproměnlivých podmínek a vlastně jsouřízeny momentálními požadavky zákazníka. Čím více jsou nestálé, a zároveň čím vícejetechnologieneznámá, tím vyššíšanci na úspěch mají agilní přístupy oproti tradičním. Tolik je nejdůležitějších odlišnostíohledně obecného přístupu. Následujírozdíly v konkrétních postupech. Analýza požadavků a celého problému vůbec je při agilním programování podstatně zrychlená. Vždy se analyzuje pouze to, co je momentálně důležité. O to důslednějšímusíbýt testování. Barry Boehm říká: Nalezení aodstranění chyby je stokrát dražší po dokončení produktu než zezačátku vývoje. Což také výstižně dokumentuje obrázek obr. 3.1. Hojně se využívají automatizované testy. Obvykle se mají psát dříve než zdrojovýkód programu. Neztrácí sečas vytvářením dokumentů, bez kterých se programátoři obejdou. Důležitější než dokumentace je orientace ve zdrojovém kódu. Ten tvoříčasto spolu s testovacím kódem hlavní část dokumentace. Lidé oceňují ifakt,že vývoj podle agilních metodik je zábavnějšínež podle tradičních. 3.1.5 Nevýhody agilních metodik Byla popsána všemožná pozitiva agilních metodik. Nyní jsounařadě jejich nevýhody a potíže, týkající sepředevším manažera projektu. Protože jsou tyto metodiky novějšínežtradiční techniky, jeví seméně přirozené ahůř sezavádí. Některé metodiky jsou velmi přísné avyžadují velkou disciplínu (například XP). Obecně kladou velké nároky na kvalitu pracovníků. Dále je potíž přesvědčit zákazníkaotom,že se mu vyplatí investovat vlastní čas do spolupráce na vývoji.

3.2. PŘEHLED NEJBĚŽNĚJŠÍCH AGILNÍCH METODIK 13 Na začátku se dá jenobtížně určit, jaký bude výsledek. Nelze tedy přesně říct, jak dlouho potrvá vývoj systému a jestli se do stanoveného termínu stihnou vytvořit všechny požadované součásti. Podobně předem nejde určit, zda bude k dokončení projektustačit stanovená konečná cena. Ta se odvíjí bud od doby strávené na projektu, nebo se určí cena za jednotku práce a doplácí sezanovépožadavky. V praxi dochází krozšiřování zadání atím k posouvání termínu dodání. Na konci projektu jde pak těžko rozlišit, co zákazník definoval na začátku a co dodefinoval v průběhu. Jestliže má vývoj probíhat agilně, není možné dokumentovatkaždou změnu. Je tedy nutné provést jakýsi kompromis a vydat několik dokumentů navíc. Zákazník typicky nechce přistoupit na nejisté podmínky. Také nechcezaplatitzapráci na přáních, která nebyla prokazatelně vyslovena až vprůběhu vývoje. Většinou se agilní metodiky nehodípropřílišvelké projekty. Rozsáhlétýmy potřebují striktní pravidla a ta jsou v rozporu s agilním vývojem. Jak je však uvedeno dále,podleněkterých agilních metodik jdou řídit i rozsáhlé projekty. 3.2 Přehled nejběžnějších agilních metodik 1. Extrémní programování (Extreme Programming, dále jen XP) Autor - Kent Beck XP je zřejmě nejpropracovanější metodika. Vychází zpřirozeného lidského přístupu. Na jeho základě jsou postavena pravidla, která jsouextrémním zesílením myšlenek tohoto přístupu. Například jde snadno každá jednoduchá práce, proto vytvářejme co nejjednodušší produkt, který aleještě bude fungovat. Metodika se velmi dobře hodí při tvorbě menších produktů, které majínejasnénebočasto se měnící zadání. 2. Lean Software Development (dále jen Lean development) Autoři - Tom a Mary Poppendieck Lean development nevzniklo jako formalizace vývoje softwaru. Bylo vytvořeno podle výrobního procesu Lean manufactoring, jehož pravidla byla upravena pro potřeby agilního programování. Není pravoumetodikou,kterábypřesně popisovala, jakým způsobem postupovat. Ale jde o souhrn myšlenek vedoucích k rychlejšímu vývoji s menším množstvím chyb a ekonomičtějším výsledkem. 3. SCRUM Development (dále jen Scrum) Autoři - Ken Schwaber a Mike Beedle Metodiku nejlépe charakterizuje vysoká flexibilita týmu a snaha o dokonalou spolupráci. Zásadní prvek Scrum jsou denní schůzky týmu, které umožňují nejen dobře projednat vše

14 KAPITOLA 3. AGILNÍ METODIKY důležitéohledně projektu, ale také pomáhají celkovému zkvalitňovánítýmu. Usnadňují například šíření vědomostí a budování sociálních vztahů mezi členy. 4. Feature Driven Development (dále jen FDD) Autory metodiky jsou projektový manažer Jeff De Luca a známý odborník na vývoj softwaru Peter Coad. Ten se zaměřil především na objektově orientované koncepce. Podle FDD je vývoj softwaru řízen požadovanými vlastnostmi výsledného produktu, které slouží jako základní stavební složky. Těmi se rozumí všechny konkrétní funkcionality, důležité části nebo charakteristiky systému. Vlastnosti jako by odkrokovaly celou činnost. 5. Test Driven Ddevelopment (dále jen TDD) TDD je technika, jejíž vedlejší efekt je dokonalé prověření zdrojového kódu jednotkovými testy. Vychází z jednoduchého faktu, že čím dřív se začne s testováním, tím dříve se odhalí chybyatím levnější jsou jejich opravy [ 20 ]. Proto TDD požaduje formulovat jednotkové testy v nejranějšífázi vývoje - před zhotovením funkcí. Ze stejného důvodu se mají formulovat i akceptační, vyšetřovací testy (acceptance tests, investigative tests) a testy uživatelského rozhraní conejdříve, ne až po dokončení projektu. 3.3 Extrémní programování Metodika XP je jedním z nejdůležitějších zástupců agilního vývoje, jehož přednosti splňuje všechny. Je vhodná promaléprojektyamalétýmy o dvou až deseti lidech. Největšídůraz dává na účinnost procesu, jež sesnaží dosáhnout velmi racionální postupy. U každé činnosti musí být na první pohled zřejmá jejídůležitost. Produktivitu také viditelně zvyšuje předepsaná snaha vytvořit takové prostředí, aby práce byla zábavná. Autor se inspiroval neúspěšným projektem Chrysler Comprehensive Compensation (C3) [ 6 ]. To byla pro něj výzva vybudovat metodiku, která by byla flexibilnějšíaumožňovala lépe reagovat na průběžné změny. 3.3.1 Charakteristika Metodika převzala některé myšlenky z výroby ve firmě Toyota[5].Tyhovoříotom,že každý pracovník je odpovědný za celou výrobní linku, vylepšování vychází zesnižování plýtvání a největším plýtváním je nadprodukce. Té jevývoj softwaru plný ataké proto XP požaduje jednoduchost a upřednostňuje ji před nevyužitelnou robustností produktu. Návrh a implementace jsou sepjaté a nikdy se nenavrhuje nic, co není momentálně potřeba.nikdysenemátvořit více verzí kóduanivpřípadě, že neníjisté, která verze by byla správná. V takové situaci se má

3.3. EXTRÉMNÍ PROGRAMOVÁNÍ 15 nejdříve vyřešit nejzákladnějšíproblém a implementovat funkcionalitu správným způsobem. I zde každý pracovník odpovídá za celý vývoj, tým má být ucelený a jednolitý. XP dává přednost přímé komunikaci o zdrojovém textu před písemnou komunikací, formalitami a dokumenty. Ty mají jen nezbytně malou důležitost. 3.3.2 Základní principy XP vycházízeznámých zkušenostístím, co pomáhápři obecné lidskéčinnosti. Použitímyšlenek těchto zkušeností dotahuje do extrémů. 3.3.2.1 Příklady známých myšlenek a postupů Jednoduchost projektu pomáhá snadné orientaci v kódu a udržení vývoje v rychlém tempu. Proto se podle metodiky má vytvořit tak jednoduchý produkt, který ještě funguje asplňuje aktuální požadavky na systém. Je nevýhodné budovat složité aplikace s cílem usnadnit hypotetická budoucí rozšíření. XP přesvědčuje o tom, že stojí nejméně práce udržovat systém v minimální konfiguraci a přebudovat ho až vpřípadě, kdy je potřebná úprava, třebaže v danou chvíli již značně rozsáhlá. Návrh a architektura systému mají zásadní vliv na průběh vývoje. Využívá se toho, že se aplikace implementuje tím lépe, čím lépejenavržena. Návrh se tedy vylepšuje denně refaktorizací, avšak v souladu s charakterem agilních metodik. Testování funkcionality odhalí nejvíce chyb, proto budou průběžně a neustále testovat všichni včetně zákazníků. Revize a kontroly odstraní největšímnožství chyb v projektu. Z toho důvoduxpradí nepřetržitě kontrolovat a procházet zdrojový textapředkládá metodu tzv. párového programování. Nepřetržitá integrace a testování máprobíhat několikrát denně. Iterace mají být tak krátké, jak to odpovídá nejmenším možným a použitelným částem systému. Další poznatky, které XP využívá, jsou následující: Je výhodnější využít problémy jako příležitost něco dokázat, než sesnažit je obcházet. Typické je také lidské jednání mezičleny týmu a vyvažování jejich potřeb. Také se lidé rádi učíarozvíjejí. Jako příklad XP uvádí, že během fáze průzkum programátoři získávají praxi s technologiemi a zákazník s psaním zadání. Vzájemný prospěch obecně je jeden z nejdůležitějších principů XP[5].Zároveň jezřejmě nejnáročnější k dodržování. Jde jak o vzájemné podporování uvnitř týmu, vedoucí k úspěchu, tak o to

16 KAPITOLA 3. AGILNÍ METODIKY dát si záležet na spokojenosti zákazníka. Ta by však neměla být na úkor prospěchu vyvíjející společnosti. Efektivitu práce pozitivně ovlivňuje radost z kvalitních výsledků, viditelného postupu a vylepšování. S kvalitními výsledky souvisí nutnost připustit i možnost neúspěchu a uměníkněmu přistupovat. Jak autoři XP říkají: Kdo dopustí úspěch jeho problému, selhává. Neselhat je podle mého názoru silná motivace k řešení potíží. Metodika dále upozorňuje na význam různorodosti konání, nebo vědomí odpovědnosti za něco důležitého. Lépe pracuje člověk, který provádí lákavějšíčinnost, než stání uběžícího pásu. Nebo také ten,kdomáodpovědnost a vyšší sebevědomí. 3.3.2.2 Čtyři proměnné charakterizující vývoj Obecně agilní metodiky sice zavádítři proměnné, avšak XP používá dalšíčtvrtou a takézměněné názvy pro původní tři.jsoutokvalita(cožodpovídá funkcionalitě projektu), čas vyhrazený pro vývoj, náklady (obecně zdroje)ašíře zadání. Poslední z nich je množina funkcí produktu, strukturovaná podle jejich důležitosti, a autor ji považuje za nejdůležitější parametr. Ke změně šíře zadání může dojít při rozhodnutí implementovat více nebo méně funkčností produktu. Zákazník může volit tři parametry a podle nich vývojový tým určíčtvrtý. Snaha zákazníka volit všechny čtyři parametry vede ke snížení kvality práce a k nedodržení termínu dodání. 3.3.2.3 Čtyři hodnoty Patřímezizákladní pojmy metodiky. Ta je na nich postavena, řídí se jimi a vylepšuje jimi vývojový proces [ 4 ]. Mezi čtyři nejvíce uznávané hodnoty XP patří komunikace, jednoduchost, zpětná vazba, odvaha a sebevědomí. Je definována ještě pátá podprahová hodnota - respekt. Dobrá komunikace umožňuje odstraňovat chyby a překážky s nejmenším možným zpožděním. Největší objem dorozumívání byměl být ústní osobní. Proto by celý tým měl pracovat v jedné místnosti. Je vyloučené jakékoliv zatajování nedostatků neboproblémů. Jednoduchost je ekonomičtějšínežvývoj nevyužitelně robustních aplikací, které jdou snadno rozšířit. Vždy se má začít co nejjednodušším systémem, který sezdokonalí, až kdyžpřijde čas. Tím se předejde vytváření něčeho, co nebude nakonec potřeba. Zpětná vazba je ukazatel a prostředek hodnotící,vjakém je systém stavu a jestli produkt odpovídá klientovým potřebám. Provádí se zejména testováním, které sepodlexpmá maximalizovat. Testováním prochází jakmalé moduly, tak většíčásti - subsystémyapod. ajedoněj zapojen i zákazník. Odvaha a sebevědomí jsou obzvlášt důležité v XP. Tým se nesmí bát okamžitě odstraňovat chyby a provádět nutné změny,atozakaždou cenu. XP upozorňuje, že cenou může být i nepoužitelnost dvou třetin všeho hotového kódu. Pátá podprahová hodnota - respektování osob okolo sebe. Členovétýmu musí spolupracovat,

3.3. EXTRÉMNÍ PROGRAMOVÁNÍ 17 Obrázek 3.2: Možnápodobakartyzadání používané v XP. Její obsah stanovuje zákazník.; překresleno podle 9 zajímat se jeden o druhého, a ne věnovat se výhradně svépráci, aby metodika byla funkční. 3.3.3 Základní metodyxp Jde o postupy, které jenutnédovývoje zařadit všechny. Je vidět, že přijmout všech dvanáct pravidel jde jen v extrémním případě, kdy je tým skutečně schopnýaukázněný. Nedodržení některé z praktik je v rozporu s XP. Business praktiky 1. Plánovací hra-celýtým vytváří tzv. karty zadání, které nesou základní informace o požadovaných funkcionalitách obr. 3.2. 2. Vydávání malých verzí -Verzesemají vydávat v konfiguracích co nejmenších, které jako celek ale ještě mají viditelný význam pro zákazníka. Čím častější je vydávání, tím lepšíje zpětná vazba. Také nazákazníka dobře působí zřetelnější produktivita týmu. 3. Metafora - Obrazný název pro architekturu pomáhá účastníkům sjednotit pohledy na systém, tak aby mu rozuměli všichni. Příklad metafory je tabulka, která může být ve skutečnosti realizována jako tabulka, nebo zcela jinak. 4. Zákazník na pracovišti - Zákazník je součástí týmu na plný úvazek a je osobně přítomen. Musí vědět, že aplikace díky němu funguje o to dříve a lépe. Pokud klient odmítá vstoupit do procesu na plný úvazek, protože je pro něj cennějšíjehopráce a čas než užitek ze systému, je lepšísedovývoje nepouštět.

18 KAPITOLA 3. AGILNÍ METODIKY Programovací praktiky 5. Jednoduchý návrh - Veškeré inovace se provádí, až když jsou potřeba. Co je příliš složité, ihned se odstraní. 6. Testování - XP definuje fázi plánování, alenenávrh. To znamená, že návrh probíhá, ale ne ve zvláštní fázi. Vychází čistě zepsanízdrojového kódu. Testování jetedytím důležitější. 7. Refaktorizace kódu - Přestrukturování kódu beze změn jeho chování jedůležité pro jednoduchost a přehlednost kódu. Je nutné rozlišovat dobu refaktorizace a implementace. Refaktorizace se nejčastěji týká zvyšování soudržnosti kódu odstraňováním duplicit. Jejich odstranění jezřetelný znak jednoduchosti. 8. Neustálá integrace - Projekt se integruje několikrát denně pokaždém splnění určitého úkolu. Hlavně v rozsáhlých projektech se vyplatí testovat integraci několikrát denně. Týmové praktiky 9. Párové programování -Ujednohopočítače vždy pracují dva programátoři. Jeden z nich se snaží o co nejlepší implementaci na aktuálním místě. Druhý přemýšlí otom,jakdaný kus kódu zapadá do celkové koncepce systému a jestli zůstane zachovaná jeho integrita. Takéhledázpůsoby, jak produkt zjednodušit. Prácevedvouvedekezkvalitnění kódu a k menšíchybovosti.může trvat několik týdnů, než semetodaukáže jako výhodná. 10. Kolektivní vlastnictví kódu - XP zavádí tzv. truck faktor a radí maximalizovat ho. Tento ukazatel značí, kolik programátorů rozumíjednéčásti zdrojového textu. Největšího možného faktoru se má dosáhnout tím, že všechen kód vlastnívšichni a kdokoliv ho může upravovat. 11. Udržitelné tempo - Pracovníci mají být rychlí a nabití energií, a proto nesmějí být přetěžováni. Pracovní týden nemá víc než čtyřicet hodin a nadměrná práce přes čas vede ke zvýšené chybovosti pracovníků. 12. Standardy kódu - Mají existovat v každém týmu, nebot zdrojový textjezákladní a jediná forma uchování informace. Proto musí být přehledný a srozumitelný všem. 3.3.4 Základní činnosti Činnosti, které probíhají během vývoje podle XP, jsou na obrázku obr. 3.3. 1. Testování -Každá funkce a funkcionalita má jednotkový test[6].tenmusíproběhnout bez chyb před pokračováním v dalším vývoji. Testy jsou izolované, tedy nemají vliv na jiné testy. Jsou automatizované, a tak je výsledek vždy nezávislý naokolních datech. Test modulu se napíše dřív, než modul začne vznikat.

3.3. EXTRÉMNÍ PROGRAMOVÁNÍ 19 Obrázek 3.3: Vzájemný vztah činností v XP; překresleno podle 9 2. Psaní zdrojového kódu - Jde o cíl a zároveň metoduxp.vdoběvývoje neexistují jiné dokumenty, ze kterých by člověk něco vyčetl o systému. 3. Poslouchání -Vývojáři musí mít zájem o své spolupracovníky a aktivně jim naslouchat. Komunikace má mít určitou strukturu. 4. Navrhování, design - Návrh je jediný nástroj, kterým jde zabránit neřešitelným situacím (efektivním způsobem). Změna v jedné části by neměla způsobit pokaždé nutnost změn ostatních částí. 3.3.5 Průběh vývoje jedné verze XP nedefinuje posloupnost přesných fází popisujících konkrétní úkony. Vývoj podle agilních metodik neprobíhá podlepřesných postupů, ale jde o dialog mezi jeho možným a žádoucím přizpůsobením určitému vodítku. Jsou definovány tyto fáze: 1. Průzkum Programátoři zkouší sestavit systém třemi až čtyřmi různými způsoby, než naleznou nejvhodnější architekturu. Dále shání conejvětšímnožství materiálu pro vytvoření karet zadání. 2. Plánování Vrámci tzv. plánovací hry vznikne plán jedné verze. Před zahájením vývoje se v rámci průzkumu z minulého bodu vytvoříhrubý a jednoduchý plán. V této chvíli je plán pouze přibližný aočekávají sezměny odhadů ipriorit.nazákladě podrobnějšího průzkumu situace se určínáplň tvorby verze. Ta trvá typicky jeden až dvadny.jdeo tvorbu množiny karet zadání jako základního materiálu popisující požadované funkcionality. Průběh plánovací hry (a) Průzkum - Najde se nová funkcionalita. Vedení jipopíše běžnou řečí, čímž vznikne tzv. user story a jedna karta zadání. Vývoj odhadne náročnost a dobu implementace.

20 KAPITOLA 3. AGILNÍ METODIKY (b) Závazek - Vývoj se zaváže k vytvoření nové verze za daných finančních podmínek. Karty zadání seseřadí podledůležitosti. Vedení zvolíšíři zadání adatumuvolnění verze. (c) Řízení -Plánování iteracíaúpravy plánu podle průběhu vývoje. Plánovací hryseúčastní celý tým. Obchodníci rozhodují ošíři zadání, technici rozhodují o odhadech, o důsledcích volby daných prvků apodrobném harmonogramu. 3. Testování Testování sestavínadvouzákladních principech. Za prvé probíhá dvojí kontrola - automatické testy a procházení kódu. Druhý principříká, že oprava chyby je tím levnější, čím dřív se chyba odhalí. 4. Konstrukce, design Inkrementálně poiteracích se navrhuje a konstruuje systém. Postup musí být vhodný provývojový tým. Začne se iterační plánovací hrou,cožjeúkon podobný plánovací hře pro celou verzi aplikace. Zákazník vybere karty zadání, které mají určit činnost pro jednu iteraci. Jejich počet záležínatempuvývoje a určísejakopočet splněných karet v předchozí iteraci.vytváříseúkolové karty,kteréjsoupodrobnějšínež karty zadání. Nikdy se neplánuje déle dopředu než na dobu bezprostřední implementace. Osobní komunikace je nezbytná. Konstrukce a design nejsou jednorázovou záležitostí, je nutné považovat vývoj za neustálý proces. Při něm je udržována integrita systému a její nezachování zvyšuje chybovost při programování. Tým musí být na udržování celistvosti zvyklý. Jinak se prodlužují intervaly odevzdávání nových funkcionalit. 5. Dekompozice Podle velikosti týmu se problém rozdělí namenší a aplikují se jednoduchá řešení. Pokud zůstane složitý nerozložitelný problém, aplikuje se komplexní řešení. 3.3.6 Vývoj první verze 1. Plánování 2. Zprovozňování Každá iterace trvá jeden až čtyři týdny, dokud není vytvořena základní architektura systému neboli jeho kostra. Poté se interval mezi jednotlivýmiiteracemizkrátí zhruba na třetinu. Tím se docílí získání lepšízpětné vazbyareakcenazměny požadavků. Ukaždé změny je nutné zvážit, jestli je aktuální, či jestli ji stačí zapracovat až vdalší verzi. Zde je také prostor na vylad ování a optimalizaci projektu. 3. Údržba spočívá vzavádění nových funkcí azačleňování nových osob do projektu. Také musí být nabízena technická podporavšem uživatelům.

3.3. EXTRÉMNÍ PROGRAMOVÁNÍ 21 4. Smrt nastává v situaci, kdy zákazníka nenapadají nová zadání, která bychtěl nechat vydat. Případně systém ztratí možnostexistovatzarozumných finančních podmínek. Fáze smrt je první chvíle za celou dobu, kdy má smysl napsat pěti až desetistránkový dokument s popisem systému. Ten se v té době užnemění a dokumentace se může sepsat bez obav ojejí použitelnost v budoucnosti. 3.3.7 Týmové role XP je agilní metodika nejvíce zaměřená napráci s lidmi a na jakýkoliv lidský faktor. Motivace lidí jepodpořena také týmovýmioslavamivprůběhu vývoje - například po každé iteracinebo po ukončení práce na projektu. Cílem těchto oslav je kladné vzájemné hodnocení členů týmu a zábavnějšíauvolněnějšívývojový proces. Programátor - má ústřední roli. Vytvářízdrojový text, design, refaktoruje a testuje jednotky. Musí dobře komunikovat s ostatními členy a přijmout párové programování. Zákazník - je ten, kdo ví, co se má programovat, i když neví jak. Má naplno využít možnost ovlivňovat projekt. Musí přijmout pravidla XP a spoluodpovědnost za projekt. Jeho povinností jepsát zadání a testy funkcionality. Tester - pomáhá zákazníkovi se psaním testů funkcionality. Stopař -má nadhled nad systémem. Odhaduje termíny, zpracovává informace ze zpětné vazby a analyzuje zpoždění projektů. Kouč -odpovídá za proces jako celek. Stará se o otevřenost komunikace a hlídá správnost postupů. Konzultant - je expert v konkrétní oblasti,kterátýmu není známá. Velkýšéf - vede organizaci. Musímít odvahu, trpělivost, rozvahu a tím i schopnost přijmout principy XP, včetně zdánlivě nesmyslných kroků. Těmi můžou být například párové programování, refaktorizace, zahození nepoužitelného kódu. 3.3.8 Závěr XP je flexibilní metodika, která si klade za cíle harmonii a vyvážení. Boří konzervativnípředstavy odůležitosti dokumentace a podrobného plánování. Vychází ztoho,cojepřirozené a co lidé mají rádi, což jenapříklad výhra, týmová spolupráce, důvěra, blízký viditelný cíl, fungující software. Pro metodiku existuje řada zdrojů informací anástrojů vevývojových prostředích. Říkáseoní například v [ 4 ], že je jednou z nejrozšířenějších a nejznámějších. Jsem přesvědčen o

22 KAPITOLA 3. AGILNÍ METODIKY tom, že toto platí vamerice,avšak ověřil jsem si, že na území České republiky jsou častějšíjiné agilní metodiky. Evropané nemívají narozdíl od Američanů takvýhodné povahové vlastnosti (například velkou odvahu), které jsouužitečné pro XP. Také jsou lidé zvyklí pracovatspíše samostatně, ale v XP musí spolupracovat. 3.4 Lean software development Přínos Lean development nespočívá v popisu průběhu vývoje software, ale radí, jakým způsobem zefektivnit práci. Jako cíle si klade na první pohled náročné požadavky. Ty jsou produkovat software za třetinu obvyklého času, vystačit se třetinou obvyklého rozpočtu a snížit četnost chyb na třetinu obvyklého množství [ 9 str. 159 ]. Cíle nejsou absurdní. Jak se můžeme dočíst dále, základní principy Lean development naopak vysvětlují, že časté doručování prototypů, vysoká kvalita a nízká cena jsou plně v souladu. Nejsou stanoveny žádné kroky, jejichž pomocí secílů jistě dosáhne. Lean development pouze vymezuje pravidla, která umožní proces zefektivnit. 3.4.1 Základní charakteristika Lean development navazuje na Lean manufactoring. To vychází ze snahy zabránit problémům, na které narazili japonští výrobci automobilů při řízení produkce. Avšak tyto komplikace byly stejného charakteru, jako potíže při vývoji softwaru - měnících se požadavků, efektivity a pružnosti výroby. Hlavní automobilový producent, který rozvíjel Lean Manufacturing, je Toyota. Jeho významně ovlivnil Dr. W. Edwards Deming učením s názvem Absolutně kvalitní management a čtrnácti body týkajícími se managementu. Lean Manufactoring dobře definuje pojmy klíčové pro efektivní činnost. Ta spočívá v dovedném zacházení s pojmem hodnota a v zamezení plýtvání. Kromě toho, že metodiku formovali, také ji prosadili v Agilní aliancitoma Mary Poppendieck. 3.4.2 Klíčové pojmy 3.4.2.1 Plýtvání Jedno z nejdůležitějších pravidel je odstranění plýtvání. Autorka FDD ho definuje v [ 8 str. 3] sedm druhů. Přitom vychází ze sedmi základních způsobů plýtvání vprůmyslové výrobě. Při produkci softwaru se objevují tato: Nadvýroba je zhotovování vlastností, které zákazník nepožadoval. Nepřidají žádnou hodnotu produktu, protože ten může stejně fungovat i bez nich. Nadvýroba je každá