Přehled a porovnání nástrojů na podporu agilního vývoje softwaru

Bankovní institut vysoká škola Praha Katedra informatiky a kvantitativních metod Přehled a porovnání nástrojů na podporu agilního vývoje softwaru Bakalářská práce Autor: Lukáš Vojtek, DiS. Informační technologie, SIS Vedoucí práce: doc. Ing. Alena Buchalcevová, Ph.D. Praha Duben 2015

Prohlášení: Prohlašuji, ţe jsem bakalářskou práci zpracoval samostatně a v seznamu uvedl veškerou pouţitou literaturu. Svým podpisem stvrzuji, ţe odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, ţe se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací. V Písku, dne 22. 4. 2015 Lukáš Vojtek, DiS.

Poděkování Děkuji paní doc. Ing. Alena Buchalcevová, Ph.D., vedoucí mé práce, za její cenné rady, vstřícnost a obrovskou trpělivost, kterou se mnou měla při psaní mé bakalářské práce. Také bych chtěl poděkovat své rodině za podporu.

Anotace Tato bakalářská práce se zaměřuje na seznámení s metodikami a nástroji na podporu agilního vývoje softwaru, vysvětlení základních pojmů, jejich výhod, nevýhod a historie vývoje. Cílem je charakterizovat aktuálně dostupné softwarové nástroje pro podporu agilního vývoje softwaru dle zvolených metodik, definovat kritéria pro jejich porovnání a porovnat je. Klíčová slova: Agilní vývoj, Software, Metodiky, Scrum, Kanban, Urban Turtle, TeamPulse, Agilo for Trac Annotation This bachelor thesis focuses on introducing with the methodologies and tools to support agile software development, explanations of basic concepts, their advantages, disadvantages and history of development. The aim is to characterize the currently available software tools to support Agile software development according to the specific methodologies, define the criteria for comparison and compare them. Key words: Agile development, Software, Methodologies, Scrum, Kanban, Urban Turtle, TeamPulse, Agilo for Trac

Obsah Úvod...53 1. Strategie vývoje software... 8 2. Tradiční vývoje software...10 2.1 Historie...10 2.2 Modely ţivotního cyklu...11 2.2.1 Model programuj a opravuj...11 2.2.2 Vodopádový model...12 2.2.3 Spirálový model...13 2.3 Strukturovaný přístup...14 2.3.1 Yourdonova moserní strukturovaná analýza (YMSA)...14 2.3.2 Structured systems analysis and design metod (SSADM)...15 2.4 Objektový přístup...15 2.4.1 Rational Unified Process...15 3. Agilní metodiky...18 3.1 Popis agilních metodik...18 3.2 Rozdíl mezi agilní metodikou a technikou...21 3.3 Manifest agilního vývoje softwaru...22 3.4 Příklady agilních metodik...25 3.4.1 Extrémní programování (Extréme Programming, XP)...25 3.4.2 Crystal Metodiky...27 3.4.3 Dynamic Systems Develpment Method...29 3.4.4 Vývoj řízení vlastnostmi softwaru (FDD, Feature-Driven Development)...29 3.4.5 Adaptivní vývoj softwaru (ASD, Adaptive Software Development)...30 3.4.6 Lean Development...30 3.4.7 Agilní modelování...30 3.4.8 Test Driven Development (TDD)...31 3.4.9 The Agile Unified Process (AUP)...31

3.4.10 Open Unified Process (OpenUP)...31 3.4.11 Microsoft Solutions Framework (MSF)...32 3.4.12 SCRUM Development Process...32 3.4.13 Kanban...34 4. Porovnání agilních a rigorózních metodik...36 5. Nástroje na podporu agilního vývoje softwaru...39 5.1 Urban Turtle 4...40 5.1.1 Popis společnosti...41 5.2 TeamPulse...43 5.2.1 Popis společnosti...43 5.2.2 Popis nástroje...44 5.2 Agilo for Trac...46 5.3.1 Popis společnosti...46 5.3.2 Popis nástroje...47 6. Definice kritérií a porovnání nástrojů...53 6.1 Maximální moţný počet uţivatelů...49 6.2 Distribuce softwaru...50 6.3 Cena...50 Závěr...53 Seznam pouţité literatury:...55 Seznam obrázků...57

Úvod Potřeba vývoje software je stejně stará, jako první počítače. Tato disciplína se musela vypořádat za svou existenci s celou řadou problémů a prodělala i mnoho změn. Od, ve své době, revolučního vývoje pomocí vodopádového modelu se přes spirálový model dostala aţ k současným sofistikovaným přístupům k vývoji software. Tato bakalářská práce se zabývá v dnešním světě stále více diskutovanými agilními metodami vývoje softwaru, které slibují rychlejší a levnější dodávky software. Popisuje strategii vývoje software, zobrazuje vývoj metodik od tvrdých, někdy také zvaných rigorózních aţ po agilní (pruţné) metodiky. Jsou zde popsány principy agilních metodik vycházející z manifestu o agilním programování. Nechybí ani porovnání rigorózních a agilních metodik. Součástí práce je i přestavení tří mnou vybraných nástrojů, které podporují agilní programování a kombinují v sobě metodiky Scrum a Kanban. Definice kritérií pro jejich porovnání a jejich vzájemné porovnání na základě těchto kritérií. V závěru nechybí shrnutí poznatků a doporučení nástrojů pro různě veliké týmy..

1. Strategie vývoje software Obecně můţe říct, ţe strategií vývoje softwaru můţe být pouze volba metodiky představující soubor metod a postupů, které jsou pouţívané k plánování a kontrole vývoje projektu. Existuje široké spektrum takových metodik, které vznikly během uplynulých let, kaţdá se svými klady a zápory. Za některé z příčin vzniku rozsáhlého mnoţství metodik můţe stát rozličnost firemní kultury v dané organizaci nebo technologie vyţadující různé metody a techniky. Jedna zvolená metodika tedy není vţdy vhodná k vývoji všech typů softwaru a nasazení do všech typů podnikových organizací. Pro podnikové organizace potom velké moţností metodik mohou představovat značné potíţe při jejím výběru. Tato obtíţná situace je zapříčiněna především tím, ţe metodiky nejsou jednotným způsobem popsány a rovněţ nejsou dobře kategorizovány. Kritéria, která by mohla vést k usnadnění výběru určité metodiky, jsou podle [1] následující: Kritérium Zaměření metodiky: - Globální metodiky zaměřené na vývoj, provoz i řízení IS v rámci celého podniku - Projektové metodiky pro vývoj IS v určité oblasti Kritérium Rozsah metodiky: - Metodiky pokrývající celý ţivotní cyklus vývoje - Dílčí metodiky zabývající se jen částí ţivotního cyklu vývoje (např.: pouze návrh spolu s implementací) Kritérium Váha metodiky: - Těţké metodiky mají přesně definované procesy, činnosti a artefakty - Lehké metodiky místo podrobných procesů definují spíše principy a praktiky Kritérium Typ řešení: - Vývoj nového řešení - Rozšíření stávajícího řešení - Integrování řešení - Implementování typového řešení 8

Kritérium Domény, představuje určitou oblast, pro kterou je software vyvíjen, oblastí může být např.: - Řízení vstahů se zákazníkem Customer Relationship Management - Elektronické vzdělávání e-learning - Obecný software Kritérium Přístup k řešení, se doporučuje aplikovat pouze u projektových metodik, kde se jedná o nový vývoj. Hodnoty kritéria jsou: - Strukturovaný vývoj - Objektově orientovaný vývoj - Komponentový vývoj Zejména na základě kritéria Váha metodiky lze metodiky rozdělit do dvou hlavních proudů. Na proudy rigorózní někdy taky označované jako těţké metodiky a agilní, téţ označované jako lehké metodiky. Rigorózní metodiky kladou svůj důraz především na plánování, řízení a měření definovaných procesů při vývoji softwaru. Naproti tomu agilní metodiky kladou důraz na projekty, kde je zapotřebí řešení vyvinout velmi rychle a méně se jiţ zabývají samotným postupem jak k tomuto cíli dospět. Hlavní idea je tedy v tom, co nejrychleji začít s vývojem a následně upravovat změny na základě zpětné reakce uţivatele. Pro tyto dvě skupiny metodik je dále charakteristický i její rozličný pohled na zdroje, jak je názorně vidět na obr. 1. Obr. 1 Tradiční a Agilní vývoj softwaru [2] 9

Rigorózní metodiky vnímají poţadavky na systém, které byly stanoveny jiţ na počátku samotného vývoje za fixní, a tedy její naplnění povaţují za hlavní cíl. Na základě těchto neměnných poţadavků se stanovují proměnné zdroje a čas. Naopak při agilním vývoji se funkcionalita daného systému můţe měnit v závislosti na zdrojích a času, které jsou omezené. 2. Tradiční vývoje software Za účelem porozumění důvodů, které stály za vznikem agilních metodik a také proto, aby bylo s čím porovnávat agilní metody, budou v této kapitole představeny někteří zástupci klasického přístupu vývoje a zejména popsán historický proces vývoje. 2.1 Historie Šedesátá léta 19. století představovala pro softwarové inţenýrství značnou krizi. Pokračování vývoje za pouţití tehdejších metodik a nástrojů bylo prakticky nemoţné. Procedurální programovací jazyky a model zaloţený na programuj a opravuj (code-fix) jiţ přestávaly stačit. Další kroky vývoje se jevily jako nemoţné nebo příliš nákladné. Značnými investory v té době byly převáţně státní instituce a armády jednotlivých států, které určovaly, jakým směrem se má uchylovat vývoj efektivnějších metod. Proto se na konferenci NATO v roce 1969 začal definovat nový koncept softwarového inţenýrství, který by měl odráţet nedostatky tehdejších přístupů řízení vývoje softwaru. Novum v začátcích 70. let představoval pak pro softwarové inţenýrství vznik nových technik jako je např. specifikace, návrh, testování, modely ţivotního cyklu (např. vodopádový model). Zpočátku nevyhnutelný a urychlený vývoj, koncem 80. let se potýká s dalšími revolučními poţadavky spjatými s novými výzvami a moţnostmi, které přináší hardware budoucí generace. Model ţivotního cyklu známý jako vodopád stále více ztrácí svůj krok s těmito poţadavky a tím dosahuje ke svým mezním hodnotám. Objektově orientovaný přístup k programování, grafické prostředí a nová generace zkušenějších vývojářů dávají novou naději a adekvátní reakci na stále nové poţadavky ze strany samotných uţivatelů. Na obzoru jsou tak 10

nové nástroje a koncepty, které byly převáţně inspirovány programovacím jazykem Small Talk [3]. Zastaralý přístup vývoje softwaru se tak stává nepouţitelným a je zapotřebí ho nahradit efektivnějším. Nutno také poznamenat, ţe státní instituce jiţ nepředstavují hlavního uţivatele a tím se otevírají nové moţnosti k experimentování s novými přístupy. Proto se v 90. letech začínají prosazovat metodiky zaloţené na objektově orientovaném paradigmatu. Posledními změnami na tomto poli zaznamenáváme vznik nových iterativních resp. agilních metodik a také prolínání tradičních a agilních přístupů. Pro další pozorování pak bude zajímavé sledovat vývoj tímto směrem, zdali přinese vznik nové revoluční metodiky nebo zdali se dočkáme potvrzení, ţe současně pouţívané agilní metodiky jsou dostatečně správnou náhradou za tradiční přístupy vývoje. 2.2 Modely životního cyklu Model ţivotního cyklu softwaru představuje rámec realizace procesů ţivotního cyklu v časové posloupnosti [1]. Tedy pomocí modelu je definována následnost jednotlivých etap vývoje bez stanovení metody, pomocí které se boudou etapy realizovat. V této kapitole budou charakterizovány nejznámější modely ţivotního cyklu. 2.2.1 Model programuj a opravuj V historických dobách byla většina softwarových projektů vyvíjena stylem programuj a opravuj. Pro projekty takto vyvíjené nejsou sestavovány ţádné plány. Návrh systému je zaloţen na základě krátkodobého rozhodnutí. Tento způsob vývoje je v podstatě vhodný v případě, ţe se jedná o software malého rozsahu. V případě robustnějšího softwaru se nelze spolehnout na tento způsob vývoje, jelikoţ postupnou implementací stále nových funkcionalit se přímo úměrně zvyšuje i počet chyb (bug), které jsou pak těţko odstranitelné. Typickou indikací takového softwaru je dlouhá testovací fáze, která pro daný projekt můţe představovat překročení stanoveného termínu dodání. Model programuj a opravuj je tedy jednoduchý způsob vývoje, jeţ je zaloţen na opakujících se činnostech programování, testování a opravě chyb. V první etapě jsou specifikovány 11

poţadavky, následně se přistupuje k opakujícímu se cyklu kódování a opravování. Zde zkušenější vývojáři mají větší šanci na úspěch, jelikoţ produkují méně chyb. Čas od času vývojář demonstruje daný software klientovi, a tím dostává zpětnou reakci. Daný cyklus končí, pokud je počet nalezených chyb na přijatelné úrovni, anebo je dosaţen termín ukončení. Poslední etapou je uvedení softwarové aplikace do provozu[1]. 2.2.2 Vodopádový model Vodopádový model představuje velmi vysokou úroveň abstrakce vývojového procesu,kde jsou jednoznačně definovány posloupnosti vývojových fázi. Jednotlivé po sobě jdoucí fáze připomínají vodopád. Odtud tedy jméno vodopádový model. Ačkoli tento model má mnoho nedostatků, slouţil jako hlavní podklad pro vznik efektivnějších modelů ţivotního cyklu. Ve vodopádovém modelu projekt prochází uspořádanými vývojovými fázemi začínající fází specifikace poţadavků a končící fází zavedení a údrţba. V rámci kaţdé fáze jsou definovány kriteriální body a meziprodukt, který musí být dosaţen při ukončení kaţdé fáze. Vodopádový model je totiţ zaloţen na dokumentech (document driven), coţ znamená, ţe dokumenty tvoří hlavní produkty, které se přenáší mezi jednotlivými fázemi. Následující fáze pak můţe začít aţ po splnění všech stanovených kriterií, v případě nedostatků se lze vrátit jen do předchozí fáze. Obr. 2 Vodopádový model [4] 12

Vodopádový model dosahuje dobrých výsledků v případě, ţe jsou dopředu pevně stanoveny všechny poţadavky na softwarový produkt a tím jsou případné chyby detekovány v raném stadiu projektu. Na druhou stranu, pro tento model nastávají problémy v případě, kdy je nutné během vývoje provádět změny. Výstupy jednotlivých fází totiţ pro klienta nejsou hmatatelné ve formě softwaru aţ do chvíle předposlední fáze ţivotního cyklu. Případné změny mohou být tedy vzneseny ze strany klienta aţ ke konci cyklu. 2.2.3 Spirálový model Spirálový model byl definován Barry Bohem (v článku A Spiral Model of Software Development) v roce 1985. Tento model ţivotního cyklu klade především velký důraz na analýzu rizik. Model rozděluje projekt do jednotlivých kroků (zavedení iterativního vývoje). V kaţdé iteraci se provádějí následující fáze: stanovení cílů, analýza patřičných rizik, návrh řešení, vývoj, testování a plánování. Zde na rozdíl od vodopádového modelu jsou výstupy po dokončení kaţdé iterace předávány ve formě prototypu, kterým si zákazník můţe snáze ověřit, ţe se vývoj ubírá správným směrem. Další výhodou modelu je sníţení nákladů na vývoj softwaru tím, ţe jsou v čas odhalovány chyby. Jelikoţ náklad na odstranění patřičných chyb jsou přímo úměrné době vývoje softwaru. Obr. 3 Spirálový model [5] 13

Podle spirálového modelu se proces vývoje softwaru odehrává ve čtyřech iteracích, jak je vidět na obr. 3, kde předmětem jednotlivých iterací jsou [1]: 1. iterace: identifikace globálních rizik spojených s daným projektem a definovaní návrhu řešení pro eliminaci těchto rizik 2. iterace: předmětem této iterace je specifikace poţadavků 3. iterace: v této iteraci se provádí detailní návrh řešení 4. iterace: poslední iterace se pak zabývá implementaci a testováním 2.3 Strukturovaný přístup Hlavním cílem těchto metodik je zvýšit kvalitu softwaru. Za tímto účelem rozdělují projekt na menší, dobře definované aktivity a rovněţ určují posloupnost a vztahy mezi nimi. Takové rozdělní pak umoţňuje lepší odhad času a kontrolu samotného výsledku. Strukturované metodiky přitom podporují pouze dílčí část ţivotního cyklu a to zejména analýzu a návrh. Významní zástupci těchto metodik budou níţe uvedeny pro lepší přiblíţení. 2.3.1 Yourdonova moserní strukturovaná analýza (YMSA) Metodika YMSA je jedna z nejpouţívanějších strukturovaných metodik, kterou uvedl Edward Yourdon v roce 1989. Tato metodika se soustředí na nalezení esenciálního modelu systému, který vyjadřuje podstatu systému, nezávisí na technických a implementačních omezeních a je dlouhodobě stabilní. Esenciální model se skládá z modelu okolí a modelu chování systému. Základním pouţívaným modelovacím nástrojem pro popis obou částí je diagram datových toků (DFD data flow diagram). Postup při analýze systému touto metodou se skládá z následujících kroků:[6] 1. Vytvoření modelu okolí systému; 2. Vytvoření prvotního modelu chování systému; 3. Dokončení esenciálního modelu; 4. Vytvoření implementačního modelu. 14

2.3.2 Structured systems analysis and design metod (SSADM) Jedná se o striktnější metodiku oproti YMSA, které byla v roce 1981 zpočátku vybrána jako standardní metodika pro vládní projekty, posléze pak i pro další oblasti. Důraz metodiky je kladen převáţně na detailní a strukturovaný přístup v kaţdé etapě. K tomu metodika poskytuje propracované postupy, které pouţívají řadu nástrojů a pohledů. Základní pouţívané modely jsou logické datové struktury, diagramy datových toků a ţivotní cykly entit. Celkově je tato metodika rozdělena do šesti etap, z nichţ první tři spadají do analýzy a zbylé tři do návrhu systému.[6] 1. Analýza stávajícího systému; 2. Specifikace poţadavků; 3. Výběr technických moţností; 4. Návrh logických dat; 5. Návrh logických procesů; 6. Fyzický návrh. 2.4 Objektový přístup Metodiky zaloţené na objektovém přístupu na rozdíl od strukturovaných metodik, nahlíţejí na data a funkce jako na neoddělitelnou součást objektu. A tím se snaţí prostřednictvím předepsaných modelů důvěryhodněji zachytit modelovanou realitu. Mezi základní modely objektových metodik zejména patří: statické modely (např. model tříd) a dynamické modely (např. diagram aktivit). Níţe si uvedeme jednoho z předních zástupců objektově orientovaných metodik. 2.4.1 Rational Unified Process Rational Unified Process (RUP) představuje proces, který zajišťuje disciplinovaný přístup k vývoji softwaru za pomocí řad standardizovaných nástrojů, šablon, artefaktů a včasných dodávek prototypů. Od ostatních výše zmíněných přístupů se převáţně liší tím, ţe se jedná o rozsáhlou a detailněji propracovanou metodiku resp. procesní rámec (process framework). 15

Metodika RUP je vhodná primárně na velké projekty, nicméně je moţné jí upravovat i pro jednodušší projekty. Moţnost upravovat a přizpůsobovat metodiku zapříčinilo vznik metodiky Agile Unified Process (AUP), která v sobě obnáší agilnější praktiky. Metodika RUP popisuje proces vývoje softwaru ve dvou úrovních, jak je vidět na obr. 4. Časová úroveň znázorňuje cykly, fáze, iterace a milníky vývojového procesu. Druhá úroveň pak popisuje jaké činnosti (disciplíny) a v jaké míře, jsou vykonávány v průběhu vývoje. Obr. 4 RUP: Dvě dimenze vývoje softwaru [2] Vývoj podle RUP probíhá v iterativních cyklech, kde kaţdá iterace má podobu menšího vodopádu tj. obsahuje všechny fáze tohoto modelu (analýza - testování). Na počátku projektu je nejvíce času věnováno specifikaci poţadavků a modelování obchodních procesů. Pozdější iterace vývoje se zaměřují na implementaci a testování. Výsledkem kaţdého cyklu je nová verze produktu. Kaţdý takový cyklus je sloţen ze čtyř fází: - Zahájení (Inception) definice poţadavků a cíle projektu - Rozpracování (Elaboration) definice systémové architektury - Konstrukce (Construction) návrh a realizování systému - Předání (Transition) nasazení systému do provozu 16

Metodika pro snadnější porozumění vyvíjeného softwaru pouţívá vizuální model, který je zaloţen na modelovací syntaxi Unified Modeling Language (UML). Mezi výhody této metodiky můţeme zařadit, kromě jiţ zmíněného iterativního přístupu, také moţnost přizpůsobení metodiky na projekty různého rozsahu. Představitel metodiky aktivně pracuje na jejím zlepšení, tím se dostává nejnovějších softwarově inţenýrských postupů a podpory standardů (např. podpora nejnovější specifikace UML). Slabou stránkou metodiky je její komerčnost v případě, ţe se nespokojíme se zobecněnou verzí Unified Process (UP). Obsáhlost metodiky můţe být další nevýhodou zejména u velikostně menších projektů. Menší vývojové týmy mohou totiţ na osvojení metodiky strávit příliš dlouhou dobu [7]. 17

3. Agilní Metodiky V této kapitole se dostáváme k širšímu záběru na agilní metodiky, zejména zde bude vysvětleno, co vlastně agilní vývoj představuje a hlavní zásady a principy, které byly definovány v rámci Manifestu agilního vývoje. Dále se zmíním o dalších rozdílech mezi rigorózními a agilními metodikami a nakonec uvedu stručný přehled některých agilních metodik. 3.1 Popis agilních metodik Anglicky se agilní metodiky označují jako agile methodologies". Toto spojení lze přeloţit jako čilé", hbité" nebo ţivé" metodiky. Dříve se uţíval pojem lightweight methodologies", který měl zdůraznit lehkost" metodik (z pohledu produkované dokumentace), tento pojem má však více různých významů, a tak se od jeho pouţívání postupně upustilo. Samotné překlady uvedené v předchozím odstavci výstiţně popisují cíle agilních metodik, vývoj software má být hbitý" (software je dodán v co nejkratším čase), lehký" (vývoj se omezuje jen na potřebné činnosti a tvorbu nutných dokumentů) a ţivý" (software musí být úspěšně dodán, tedy celý projekt má přeţít). Softwarové projekty vyvíjené tradičním způsobem častěji selhávají neţ projekty vyvíjené agilním vývojem. Jednou z příčin můţe být, ţe většina tradičních metodik se spoléhá na schopnost klienta definovat své poţadavky uceleně a přesně jiţ při první schůzce, a dále pak víra v to, ţe si klient v průběhu realizace vše nerozmyslí. Vývojové týmy se pak setkávají s potíţemi např. při vodopádovém ţivotním cyklu a to ve fázi předvedení, kde povaţují daný projekt za hotový. Jenţe bývají často nemile překvapováni, kdyţ po předvedení daného výsledku projektu uslyší ze strany objednavatele větu takto jsem si to rozhodně nepředstavoval a tím se rázem v podstatě celý projekt vrací na začátek. Jenţe s jednou významnou změnou - tým jiţ vyčerpal určitou finanční částku z rozpočtu. Dále si jistě vedení takového projektu bude pokládat otázky typu bude nás klient i nadále vnímat za profesionály? nebo nezruší klient s námi smluvní vztah a neodejde jinam?. Principy, které se osvědčily v raném vývoji softwarového inţenýrství, jiţ tedy bezpochyby nemůţeme 18

pokládat zcela za správné. Hlavně se jiţ nemůţeme spoléhat na předpoklad přesného definování poţadavků na software ze strany klienta v iniciální fází daného projektu resp. pří analýze systému. Tento předpoklad jistě mohl být povaţován za správný v dobách, kdy byl software vyvíjen pro konkrétního uţivatele a platformu. V současné dynamické ekonomice, která si stále ţádá novější technologie vyvolané poţadavkem trhu, se i poţadavky na vyvíjený software stále mění. A tedy ke splnění těchto poţadavků je nutné přizpůsobit i způsob vedení softwarových projektů. Zejména v době Internetu, kde se stále rozšiřují webové aplikace vyuţívané čím dál tím větším počtem uţivatelů, je rychlost vývoje tím nejdůleţitějším kritériem. V takovém případě jistě nemůţeme vyvíjet webovou aplikaci přehnaně dlouhou dobu za účelem splnění všech předpisů, které si ţádá daná rigorózní metodika [7]. Důvodem je existence hrozby spočívající v konkurenci, která mezitím uvede několik stejných sluţeb a pak budeme čelit značenému problému jak získat klienty jiţ vyuţívající těchto sluţeb na svou stranu. Agilní metodiky jsou proto jistě tou správnou volbou, kde je zapotřebí nejen webové aplikace, nýbrţ i širší spektrum softwaru zrealizovat velmi rychle a přitom se flexibilněji přizpůsobovat měnícím se poţadavkům ze strany klienta v průběhu realizace. Na druhou stranu pak u projektů s jasnou architekturou a plánem nebo s nevhodným týmem, by moţná nebylo zcela nutné a v některých případech i nevhodné pouţít ucelenou agilní metodiku, ale v rámci dané rigorózní metodiky začlenit spíše některou agilní techniku. Přínosem agilních metodik dále spatřujeme i efektivnější způsob motivace týmu. Pomocí iterativního vývoje, kde se dostává častějších viditelných výsledků, jsou členové týmu pozitivněji naladěni tzv. ţijí pro danou věc. Mezi zásadní principy agilních metodiky, které směřuji ke zplnění výše uvedených kritérií, resp. k onomu přizpůsobení způsobu vývoje softwaru, zejména podle [7] patří: - Interaktivní a inkrementální vývoj s krátkými iteracemi: Daný projekt je rozdělen do několika inkrementů (částí), které jsou nezávisle na sobě vyvíjeny. Vývoj v rámci kaţdé části probíhá iterativně (provádějí se jednotlivé fáze vývoje opakovaně), kde plán je sestaven tak, aby se nové funkce dodávaly častěji. Tím je klient průběţně seznamován s aktuálním stavem realizovaného projektu, a je tedy téměř vyloučeno, ţe by na konci realizace dostal něco zcela jiného, neţ očekával. 19

- Komunikace mezi zákazníkem a vývojovým týmem: Integrace nepřetrţité komunikace (např. časté schůzky) jako nedílná součást procesu vývoje, kde členem vývojového týmu je i samotný zákazník, který definuje poţadavky, dále se spolupodílí na návrhu a spolurozhoduje o testech. - Průběžné automatizované testování: Vzhledem k častějším změnám v rámci realizace aplikace a zachování její kvality, je nutné průběţně ověřovat správnost této aplikace. Takovéto ověřování by mělo spočívat v automatizovaných testech, které jsou napsané jiţ před implementací testované část. Výhody agilních metodik: - Iterativní a inkrementální vývoj. - Ranné dodání první funkční verze. - Zdůraznění významu komunikace. - Regresní testování. - Flexibilní reakce na změny. - Optimalizace metodik. Nevýhody agilních metodik: - Nezaručené rozsahy verzí. - Smlouvy nelze formalizovat. - Omezují dokumentace. - Testování provádí přímo autor. - Vyţadují nadprůměrné schopnosti. - Nelze vyuţít na částečný úvazek. 20

3.2 Rozdíl mezi agilní metodikou a technikou V této kapitole budou uvedeny zásadní rozdíly mezi stále se zaměňujícími termíny a to agilní metodikou a agilní technikou. V prvním případě jde o způsob rozvrţení práce za účelem efektivnější organizace, jak bylo výše uvedeno. Naproti tomu agilní technika je od agilní metodiky oddělitelná, spočívá v konkrétním postupu, jak dospět k poţadovanému výsledku např. stanovuje způsob pouţití nástrojů [8]. Software lze vyvíjet celou řadou způsobů. Ať uţ se jedná o vodopádový model (klasický přístup, od analýzy přes návrh a betaverze k finálnímu produktu) nebo o agilní metodiku, je nutné, aby manaţer, tým analytiků, vývojářů a testerů koordinoval, bral v potaz zájem klienta a zároveň kladl důraz na kvalitu a produktivitu samotných pracovníků. Protoţe jsou světy agilních a neagilních týmů poměrně oddělené a zároveň velmi komplexní, zaměříme se na jednu z oblastí. Tedy na agilní metodiky, jejich vliv na produktivitu a také na to, jak agilní metodiky v týmu podporovat.přestoţe se termíny agilní metodika a agilní technika často zaměňují, nebo dokonce povaţují za totéţ, ve skutečnosti se jedná o rozdílné (jakkoliv propojené) oblasti s naprosto rozdílnými významy. Agilní metodika je způsob rozvrţení a ověřování práce. Cílem Agilní metodiky bývá lepší organizace práce. Odlišné Agilní metodiky vedou k odlišným produktům, protoţe povaţují jiné aspekty produktu za klíčové. Liší se i přístup ke změně zadání. Moţnost změny zadání je ale určující podmínkou. Agilní metodika umoţňuje jak vytváření, tak reagování na změny v projektu a tím přinášet uţitek v neustále se měnícím obchodním prostředí. Agilní technika je naproti tomu konkrétní postup, který se většinou týká samotných vývojářů. Cílem těchto technik bývá zvýšení produktivity práce, odstranění chyb, kvalitnější software nebo přesnější dodrţení specifikace. Agilní techniky jsou od metodik oddělitelné. Cílem Agilní techniky bývá kvalitnější produkt. Rozdíly mezi agilní metodikou a technikou: - Agilní metodika se zaměřuje na organizaci práce bez ohledu na to, zda se ve firmě vyvíjí software, nebo se jedná o jinou oblast, kde lze agilní řízení uplatnit. 21

- V agilní metodice je kladen důraz na moţnost změny, agilní technika nic takového nevyţaduje. - Agilní me metodika se netýká pouze vývojářů, ale i managementu. - Agilní technika je konkrétní činnost (především vývojáře, můţe se týkat ale i klienta). Agilní metodiky i agilní techniky historicky vycházejí z Agile Manifesto. Tento manifest vznikl na bázi dlouholetých zkušeností špičkových vývojářů, analytiků zdola nahoru. Tedy managementu navzdory. Přesto se postupy z něj vycházející osvědčily, protoţe řeší následující problémy: - Ubude práce manaţera a tým přitom zlepší svou výkonnost. Jeden manaţer je schopen řídit více zaměstnanců, větší projekt nebo se více zaměřit na kvalitu. Ať uţ je to povahou sebe řízení, tím, ţe se nepíší zbytečné dokumenty nebo tím, ţe manaţer má stejně v průběhu iterace omezené pravomoci. - Je předem známo kolik práce je tým schopen udělat (v časovém rozsahu jedné iterace). To proto, ţe z minulosti je známo, jaká je rychlost v jednotlivých iteracích. Protoţe se zároveň dělají časové odhady na co nejkratší úkoly, je moţné řídit rychlost týmu. - Změny zadání za běhu (coţ je např. pro klasický vodopádový model naprosto neřešitelný problém) - Zrychlení doručování produktu od vývojáře k zákazníkovi (protoţe klientovi produkt doručujete po kaţdém běhu, zákazník se navíc často účastní běhu firmy) - Garance kvality (pomocí automatizovaných testů) - Odstranění bariér mezi produktem a vývojáři - Omezení rigidních procesů ve prospěch komunikace (Agilní metodiky proti dobře nastaveným procesům nejdou, pouze omezují ty procesy, které brání efektivitě, komunikaci a agilnímu přístupu k práci)[22] 3.3 Manifest agilního vývoje softwaru Uplynulo jiţ 14 let od únoru roku 2001, kdy byl sepsán Manifest agilního vývoje softwaru, kde skupinka sedmnácti významných odborníků, představitelů tehdejších light-weight metodik, z oblastí softwarového inţenýrství na popud neodpovídajících, pomalých a 22

byrokratických tradičních metodik společně definuje na základě svých dlouholetých zkušeností dvanáct základních hodnot agilního vývoje softwaru. A tím přináší do světa softwarového inţenýrství jednotný přístup, jak zefektivnit vývoj softwaru. Současně byla zaloţena Aliance pro agilní vývoj, jejíţ prvotní členové byli aktéři manifestu. Mezi nejznámější aktéry manifestu patří Mike Beedle, Alistair Cockburn, Kent Beck, Ward Cunningham, Ken Schwaber, Martin Fower a Jeff Sutherlan. Mezi hlavními pilíři, na kterých je Manifest postaven patří: - Přijmout a umoţnit změnu je mnohem efektivnější, neţ se pokoušet jí zabráni. - Je třeba být adekvátně připraven reagovat na nepředvídatelné události, protoţe ty jsou bezpochyby spjaty téměř s kaţdým projektem. Aktéři na základě výše uvedených pilířích dávají zejména přednost: - Individualitám a interakci před procesy a nástroji. - Fungujícímu software před obsáhlou dokumentací. - Spolupráci se zákazníkem před sjednáváním smluv. - Reakci na změnu před plněním plánu. Níţe bude stručně uvedeno dvanáct principů agilního vývoje, tak jak byly v rámci manifestu sepsány podle [7]. 1. Nejvyšší prioritou je uspokojovat zákazníky včasnou a kontinuální dodávkou softwaru, který jim přináší hodnotu. Zákazník bude mít největší uţitnou hodnotu ze softwaru, nikoliv z UML diagramů nebo ER-modelů. 2. Změny poţadavků dokonce i v pozdních fázích projektu jsou vítané, neboť změna můţe být pro zákazníka konkurenční výhodou. Agilní metodiky očekávají příchod změn a nedělají nic, co není momentálně potřebné, protoţe je pravděpodobné, ţe se to v budoucnu změní. 23

3. Časté dodávky softwaru (od dvou týdnů do dvou měsíců). Iterativní vývoj je podporován i většinou tradičních přístupů, agilní metodiky však zdůrazňují velmi krátké iterace a zkrácení cyklu dodávky. 4. Zákazníci a vývojáři spolupracují denně na projektu. Agilní přístupy vycházejí z toho, ţe nelze na začátku projektu podepsat specifikaci poţadavků a nadále ji v celém průběhu vývoje povaţovat za neměnnou. Místo toho se zpočátku definují pouze hrubé poţadavky umoţňující základní návrh architektury, nicméně se očekává, ţe i ty se mohou v čase měnit. Aby na základě vágně definovaných poţadavků bylo moţné provést návrh a implementaci, je nutný bezprostřední kontakt se zákazníkem. 5. Motivovaní jedinci, kteří mají dobré podmínky a podporu vedení, jsou klíčovým faktorem úspěchu projektu. O úspěchu projektu vţdy rozhodnou lidé, pro něţ je často nejcennější důvěra v jejich schopnosti. Také rozhodování musí provádět kompetentní a pozitivně motivovaní jedinci. 6. Vzájemná konverzace je nejvýkonnější a nejefektivnější metodou přenosu informací v rámci vývojového týmu. Agilní přístupy tvrdí, ţe smyslem dokumentace (v obecném významu) je porozumění problému; tohoto porozumění se však nejefektivněji dosáhne pouţíváním přímé komunikace, nikoliv psaním a čtením rozsáhlých zpráv. 7. Fungující software je primární mírou pokroku a úspěchu. Naplnění specifikace neznamená ještě úspěch projektu; můţe nastat např. neočekávaný problém při integraci. 8. Agilní metodiky předpokládají udrţitelný vývoj. Přesčasy, práce v noci, přetěţování pracovníků můţe krátkodobě vyřešit zpoţdění projektu, ale dlouhodobě je zdrojem nízké produktivity práce. Kent Beck, autor Extrémního programování, uvádí, ţe nutnost práce přesčasové je téměř vţdy signálem závaţných problémů v projektu. 9. Stálá pozornost perfektnímu návrhu a technickému řešení. Agilní přístupy zdůrazňují kvalitu návrhu, přičemţ ale změnu v návrhu neinterpretují jako důkaz jeho nízké kvality. Vzhledem k tomu, ţe základním jevem agilního programování jsou změny přicházející i v době, kdy kód je jiţ napsán, je nutnost měnit návrh a jeho změny následně promítat i do zdrojového kódu zcela přirozená. Návrh není samostatnou etapou dokončenou před 24

zahájením implementace; je to souvislá, kaţdodenní činnost zasahující do všech fází projektu. Základním omylem je však představa, ţe návrh je vynechán nebo zanedbán. Není tomu tak: o důleţitosti návrhu nikdo nepochybuje, návrh je naopak zařazen do kaţdodenní náplně práce programátorů. 10. Zásadní je jednoduchost neboli umění minimalizovat mnoţství neudělané práce. V agilních procesech je kladen důraz na jednoduché postupy, protoţe se snáze mění. Je snazší přidat něco k jednoduchému procesu, neţ něco komplikovaného z procesu odebrat. Do řešení by se mělo zahrnout jen to, co prokazatelně potřebuje kaţdý, nikoliv to, co moţná bude někdo potřebovat. Extrémní programování si například klade otázku Jaká je minimální konfigurace, která ještě můţe fungovat? 11. Důvěra a komunikace vedou ke kreativitě. Kreativita lidí přináší skvělé návrhy, musíme ji však podpořit důvěrou, častou komunikací a rozumnou zátěţí. 12. Jak pracovat efektivněji? Tým se musí v pravidelných intervalech zabývat touto otázkou. Agilní metodiky nejsou předem dané, ale vyvíjejí se, přizpůsobují a reflektují sebe sama. 3.4 Příklady agilních metodik Na základě Manifestu agilního programování resp. jeho základních principů vzniklo nemalé mnoţství metodik a stále se zvyšuje počet těchto metodik. Pro lepší přehlednost existujících agilních metodik v této kapitole, uvedu zejména podle [7] seznam těch nejvýznamnějších. Protoţe mi rozsah diplomové práce nedovoluje se značně rozepisovat o těchto metodikách, bude tedy u kaţdé popisující metodiky uveden i odkaz na zdroje poskytující hlubší informace. 3.4.1 Extrémní programování (Extréme Programming, XP) 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 25

podrobněji popisuje tuto metodiku na základě informací získaných z knihy Extrémní programování [9], jejímţ autorem je Kent Beck. 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 postavené na známých a běţných postupech, ale dotahuje tyto postupy do extrémů. Kdyţ se vyplá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í. Prostřednictvím zdrojového kódu komunikují členové týmu. Výsledky spouštěných testů vypoví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í implementaci. 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]. 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 vynucovalo vzájemnou komunikaci jak mezi jednotlivými programátory, tak mezi programátory a zákazníkem. Poslední podstatnou činností pro XP je navrhování. Navrhování provádějí všichni programátoři kaţdý den. XP klade důraz na zdrojový kód, a tak programátory nenutí ke kreslení 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. Při své práci se snaţí programátoři navrhnout a 26

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, kvalita a šíře zadání. Zákazníci nebo manaţeři zadávají hodnoty tří libovolně zvolených proměnných, vývojový tým pak určí odpovídající hodnotu zbývající proměnné. Tento přístup vychází z jednoduchých úvah. Například kdyţ má málo lidí v krátkém čase udělat moc práce, jsou ve stresu a výsledky jejich snaţení nedosahují odpovídající kvality. Ve většině případů stres a nereálné poţadavky způsobí zpoţdění projektu a s tím i zvýšené náklady. Právě z těchto důvodů XP říká, ţe týmu nelze nadiktovat hodnoty všech řídících proměnných, ale musí mu být dáno právo určit odpovídající hodnotu zbývající proměnné. Pokud nejsou manaţeři s odpovědí spokojeni, mohou si vybrat jiné tři proměnné, ale nikdy nesmí určovat hodnoty všech čtyř proměnných. Za nejvhodnější volnou proměnou pak XP povaţuje právě šíři zadání. 3.4.2 Crystal Metodiky Crystal není jméno jedné metodiky, ale slouţí k označení celé rodiny" metodik, které vymyslel Alistair Cockburn. Jednotlivé metodiky jsou pojmenované podle barev a navzájem se odlišují svou vhodností pro různě velké týmy a různě sloţité projekty. Čím tmavší barva je, tím je metodika robustnější a vhodnější pro rozsáhlejší, případně kritičtější projekty. Jednotlivé barvy jsou čirá, ţlutá, oranţová, červená, hnědá, modrá a fialová. Tyto metodiky nejsou přesné kuchařky", ale obsahují řadu rad, jak je přizpůsobit vlastním potřebám. Vhodná metodika pro projekt se volí na základě hodnot z tří následujících vlastností projektu. První vlastností je velikost vývojového týmu, tedy kolik lidí se účastní vývoje. Druhou vlastností je kritičnost projektu, která ohodnocuje dopad selhání systému a můţe nabývat čtyř hodnot: - 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. 27

- Velká peněz (E) je podobný dopad, jako předchozí, tentokrát ovšem firma ztrácí nezanedbatelnou část svých financí. - Ztráta lidských ţivotů (L) je nejhorším moţným dopadem. Poslední vlastností, podle které se řídí výběr správné metodiky, je priorita projektu. Tato vlastnost vyzdvihuje tu stránku projektu, která má pro nás největší význam. Můţeme se rozhodnout, zda budeme průběh projektu optimalizovat pro maximální produktivitu vývoje nebo dáme přednost například důkladnému měření postupujícího projektu. Volbu vhodné metodiky ilustruje obrázek 5 převzatý z práce Agile software development methods [11]. Čtverečkované jsou na obrázku označeny oblasti, které jsou nedosaţitelné nebo pro které neexistuje příslušná Crystal metodika. Obr. 5 Volba odpovídající Crystal metodiky [11] Robustnější metodiky jsou postupně navrhovány a ověřovány v praxi. Tato práce se zaměřuje na základní metodiku s čirou barvou (Crystal Clear), která spadá do kategorie D6, tedy je určená pro tým čítající od dvou do osmi lidí, kdy při selhání firma ztrácí malou část financí. Má volba byla ovlivněna ostatními metodikami, neboť jsem chtěl srovnávat metodiky určené pro přibliţně stejně velké týmy. 28

3.4.3 Dynamic Systems Develpment 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 faktem, ţ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 dokumentů. Od prvního uvolnění konsorcium usilovně metodiku rozšiřuje a vylepšuje.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. 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. U Dynamic Systems Development Metod se v závislosti na velikosti projektu úč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. 3.4.4 Vývoj řízení vlastnostmi softwaru (FDD, Feature-Driven Development) FDD je formálnější metodika, zaloţená na iterativním vývoji, který je řízen vlastnostmi daného projektu. Vlastnostmi softwaru jsou elementární funkcionality přinášející přidanou hodnotu uţivateli. Dále metodika zavádí do oblasti agilního vývoje objektové modelování, kde se popisují objekty a vztahy mezi nimi pomocí UML diagramů. Vývoj je rozdělen do 5 fází, kde první tři (vytvoření celkového modelu, vytvoření seznamu vlastností a plánování podle vlastnosti) jsou sekvenční, poslední dvě (návrh podle vlastností a implementace podle vlastností) pak iterativní. Iniciální fází je tedy vytvoření globálního modelu, který se následně 29

převede do seznamu vlastností, ty se pak postupně implementují. Na základě krátkých iterací, obvykle 2 týdny, kde jsou klientovi průběţně prezentovány mezivýsledky, lze detailně plánovat a kontrolovat vývojový proces a tím se ujistit, ţe vše se ubírá správným směrem. [12] 3.4.5 Adaptivní vývoj softwaru (ASD, Adaptive Software Development) Tato metodika se od ostatních liší ve filozofickém přístupu, který je zaloţen na teorii, podle které při vývoji nesmíme mít odpor vůči změnám nýbrţ se na takovéto změny patřičným způsobem adaptovat. Charakteristické pro ASD jsou iterativní fáze spekulace, spolupráce a učení. Metodika nepředepisuje konkrétní postupy, ale nechává na vývojovém týmu, jak bude postupovat v dané situaci na základě předešlých zkušeností.[13] 3.4.6 Lean Development Autoři této metodiky byli značně inspirováni osvědčenými praktikami tzv. Lean Manufacturing, který vznikl při rozmachu japonského automobilového průmyslu. Autoři pak definují vlastní pravidla určená pro efektivnější vývoj softwaru, kde hlavním cílem je vývoj za třetinu obvyklého času, vystačit si s třetinou obvyklého rozpočtu a četnost chyb sníţit na třetinu obvyklého mnoţství. Mezi tato pravidla patří: odstranění všeho zbytečného, minimalizace zásob, maximalizování toku informací, vývoj taţený poptávkou, rozhodovací pravomoc přenést na pracovníky, poţadavky zákazníků uspokojovat jak nyní tak i do budoucna, zavedení zpětné vazby, odstranění lokální optimalizace, partnerství s dodavateli a vybudování kultury pro neustále zlepšování.[14] 3.4.7 Agilní modelování Jedná se spíš o přístup k vývoji, neţli o metodiku jako takovou. Základní myšlenkou agilního modelování je zachytit pomocí modelů pouze nezbytně nutné poţadavky na systém a nezatěţovat se zbytečnostmi. Důleţitým faktorem je také to, ţe se modelování systému 30

účastní přímo uţivatel, tím se vývojovému týmu dostává zpětné rekce rychleji. Principy této metodiky převáţně vycházejí z metodiky Extrémního programování. Značnou nevýhodou tohoto přístup můţe být nemoţnost pouţití jejích praktik ve větších týmech.[15] 3.4.8 Test Driven Development (TDD) V tomto případě se také nejedná zcela o metodiku. Základní myšlenkou tohoto přístupu je věnovat velké úsilí testovacímu procesu. Jde o to, nadefinovat co nejkvalitnější testy, které by měli odhalovat nedostatky vyvíjené aplikace. Zákazník tedy dostává kvalitní produkt, který není třeba dále testovat. Pravdou je, ţe i jiné metodiky se věnují testování, v tomto případě jde o přístup k vývoji, který testování nepovaţuje pouze za součást svého procesního vývoje, nýbrţ za hlavní proces. Tato myšlenka se pak odráţí i na samotné programování, kde je prvně zapotřebí vytvořit testovací jednotku pro danou funkcionalitu a teprve potom se přechází na implementaci.[16] 3.4.9 The Agile Unified Process (AUP) Hlavní odlišnosti metodiky AUP od formálnějšího RUP spočívá zejména v tom, ţe správa poţadavků, analýza a návrh systému jsou sloučeny do jedné etapy tvorba modelu. Tady činnost zabývající se vytvářením modelů zcela nevymizela, pouze se zachycují nezbytně nutné prvky. Pro tuto metodiku jsou dále charakteristické její agilní techniky, zaloţené na TDD, agilním modelování, řízení agilních změn a databázovém refaktoringu. AUP představuje jakýsi kompromis mezi jinými agilními metodikami a metodikou RUP. Například agilní metodika XP nám přesně nestanovuje, jak vytvářet artefakty, které jsou důleţité pro managament našeho projektu. Z druhé strany pak RUP nabízí velké mnoţství artefaktů, které mohou být pro vývojáře zbytečné [17]. 3.4.10 Open Unified Process (OpenUP) Mezi nově vzniklé metodiky řadíme OpenUP, která je zaloţena na iterativním a inkrementálním přístupu, který je aplikován uvnitř strukturovaného ţivotního cyklu [17]. Zásadním principem této metodiky, je definování následujících vrstev: Project Lifecycle (ţivotní cyklus projektu), kde je primárním úkolem vytvoření projektového plánu. V této 31

vrstvě je kladen důraz na komunikaci především se zákazníkem, obvyklá délka trvání jednoho cyklu je několik měsíců; Iteration Lifecycle (ţivotní cyklus jedné iterace), cílem kaţdé iterace je dostavení funkční demo verze, která je pro klienta uţitnou hodnotou. Na rozdíl od předchozí vrstvy, zde je kladen důraz na komunikaci v rámci vývojového týmu, trvání jedné iterace je několik týdnu; Micro-Increment (mikroinkrement) je poslední vrstvou představující nejmenší jednotku práce (pouze několik hodin), kde členové týmu plní své přiřazené úkoly. 3.4.11 Microsoft Solutions Framework (MSF) Jedná se o framework pro vývoj softwaru, kde od verze MSF 4.0 jsou k dispozici dvě metodiky MSF for CMMI Process Improvement a MSF for Agile Software Development [1]. U OpenUP metodiky, jak i samotný název napovídá, jsou obsaţeny praktiky agilního přístupu (iterativní a adaptační procesy). MSF je zaloţen na dvou modelech: - Týmový model: Určuje jakým způsobem organizovat vývojový tým a jejich činnost tak, abychom úspěšně realizovali projekt. Především se klade důraz na to, aby v rámci týmu jedna osoba nezastávala více rolí. - Procesní model: V tomto modelu se opakují krátké vývojové cykly, kde výsledkem jednoho cyklu je vţdy vytvoření nové verze aplikace. Tento procesní model je rozdělen do 5 fází a to Envisionig (vytvoření vize), Planning (plánování), Developing (vývoj), Stabilizing (stabilizace) a Deploying (nasazení). 3.4.12 SCRUM Development Process Autory metodiky Scrum jsou Ken Schwaber, Jeff Sutherland a Mike Beedle. Přístup Scrum je zaloţen na přesvědčení, ţe vývoj software není definovaný proces, jak rigorózní metodiky předpokládají, ale empirický proces, a proto vyţaduje úplně odlišný styl řízení. Název Scrum byl vybrán podle skrumáţe (mlýna) v rugby proto, aby zdůraznil, ţe metodika Scrum je podobně jako hra rugby adaptivní, rychlá a samoorganizující. Metodika Scrum je zaměřena především na řízení projektu. Vývoj software probíhá v rámci 30 denních iterací nazývaných Sprint, na jejichţ konci je dodána vybraná mnoţina uţitných vlastností. Klíčovou praktikou metodiky Scrum je ouţívání kaţdodenních 15 minutových porad (Scrum Meetings), které slouţí pro koordinaci integraci prací. Scrum definuje 4 fáze ţivotního cyklu: 32

- Iterativní vývoj: Vývoj metodikou Scrum probíhá v krátkých iteracích, které nazýváme sprinty. Kaţdý sprint trvá cca 14 dnů, na jeho začátku je stanovení cílů, na konci pak vývojový tým předvede klientovi funkční aplikaci. Následuje vyhodnocení úspěšnosti a stanovení cílů pro další sprint. Výhodou je, ţe po kaţdém sprintu lze změnit plány nebo přizpůsobit cíle tak, aby lépe odpovídaly aktuální realitě. Výsledkem sprintu je funkční aplikace, takţe po kaţdém sprintu lze vývoj ukončit. - Kontakt s vývojem: Zákazník má ve Scrumu těsný kontakt s vývojovým týmem. Na konci kaţdého sprintu mu vývojový tým prezentuje aktuální stav aplikace, zejména nově vytvořené funkce. V tomto okamţiku má moţnost do vývoje jakkoli zasáhnout. Tento přístup je mnohem pruţnější neţ tradiční vodopádový model, kde po úvodní analýze běţel vývoj často i několik let, aniţ by do něj zákazník mohl nějak podstatně zasahovat. - Krátkodobé plány: Ţádný plán nepřeţije první kontakt s realitou, ale samotný proces plánování je ezbytný. Scrum počítá se změnou. Vývojový tým i zákazník se během vývoje učí stále nové věci, jejich pohled na problematiku se neustále mění a vyvíjí. Proto ve Scrumu dáváme přednost krátkodobému plánování, ktré nám umoţňuje zůstat v kontaktu s realitou. - Zpětná vazba: Během vývoje ve Scrumu neustále testujeme. Vytváříme automatizované testy, provádíme testy pouţitelnosti, provádíme testovací scénáře. Zákazník navíc často vidí aplikaci a můţe zasahovat do jejího vývoje. To nám umoţňuje dodávat kvalitní řešení problémů, které jsou jen nejasně specifikované, nepřesně ohraničené a celkově velmi sloţité. První a poslední fáze obsahuje definované procesy, u kterých jsou určeny vstupy, výstupy a procesy transformace vstupů na výstupy. Tyto procesy vyjadřují explicitní znalost a jejich provádění je lineární. Fáze vývoje (Sprint) je naproti tomu empirický proces, jehoţ činnosti nelze zpravidla identifikovat a řídit. Tato fáze vystupuje jako černá skříňka, která vyţaduje vnější řízení. Pravidla pro 30 denní Sprint jsou jednoduchá. Kaţdý člen týmu má přidělen úkol, pracuje na splnění cíle Sprintu a účastní se denních porad (Scrum meetings). Tyto porady mají informační charakter a jsou velmi efektivně řízeny. Umoţňují monitorovat stav projektu, zaměřit se na to, co je třeba udělat pro úspěch projektu a jak řešit problémy. Denní porady se konají ve stejný čas na stejném místě a trvají maximálně 30 minut (optimálně 15 minut). Porady řídí Scrum Master, účastní se jich všichni členové týmu a navštěvují je také 33

manaţeři. Denní porady umoţňují týmu sdílet znalosti. Na poradách musí kaţdý účastník zodpovědět tři otázky: - Jaké poloţky se zvládly dokončit od minulé porady? - Jaké nové úkoly se mají řešit? - Jaké jsou omezení a překáţky pro řešení úkolů? Metodika Scrum se řadí do projektových metodik a zaměřená je především na řízení projektu. Chápe procesy při vývoji software jako empirické procesy, které není moţné předvídat, ale je nutné je monitorovat. K tomu poskytuje praktiky jako denní porady, monitorování Sprintu (30 denní iterace) pomocí Backlog graph a další. Metodika Scrum explicitně sniţuje chaos při vývoji tím, ţe stabilizuje úkoly pro 30 denní Sprint. Metodika Scrum je popsána jako jazyk vzorů (Pattern Language).[1] 3.4.13 Kanban Kanban znamená v japonštině karta, štítek nebo lístek. Základní myšlenka systému Kanban je zaloţena na aplikaci zásad organizace činností amerických supermarketů ve výrobě, kde si zákazník vezme z regálu poţadované zboţí, u pokladny jsou ze zboţí sejmuty dopravní karty a poloţeny do skříňky (pošta kanban). Dopravní karty jsou poslány do skladu, poté co je ze skladu odebrané zboţí potřebné na naplnění regálů jsou dopravní karty vyměněny za karty výrobní, které se nacházely na zboţí. Výrobní karty jsou shromaţďovány ve schránce (jiná pošta kanban), zboţí je nyní dovezeno do supermarketu a s dopravními kartami postaveno do regálů. Výrobní karty jsou dodány zpět do továrny, kde se nyní vyrobí přesné mnoţství stanovené pomocí výrobních karet. Po ukončení výroby jsou na nově vyrobeném zboţí umístěny výrobní karty. Zboţí je dáno do skaldu a cyklus se uzavře. Snahou tohoto systému řízení je co nejdokonalejší přizpůsobení se (harmonizace) průběhu výroby materiálovým tokem. Hlavním cílem systému Kanban je na kaţdém stupni výroby podporovat výrobu na objednávku, která umoţňuje bez větších investic redukovat zásoby a zlepšuje přesnost plnění termínů. Aby to bylo moţné dosáhnout, musí se uţ při návrhu výrobní dispozice vyváţit výrobní kapacity (tvorba rodin příbuzných výrobků, zajištění pravidelného odběru a tím i výroby, pouţití principů skupinové technologie apod.) S vyvaţováním výroby se musí začínat ve finální montáţi. 34

Kanban znamená také vrácení funkce řízení zpět do dílny, kde lze přímo na místě přizpůsobit přísun materiálů a zpracování výrobních úkolů okamţitým poţadavkům. Obejde se tak bez těţkopádného centrálního plánování a řízení, vyrábí a dopravuje se jen to, co je poţadováno. Zákazníkem je kaţdý následující proces (NOAC - Next Operation As Customer). V systému Kanban je celé řízení výroby podřízené finální montáţi, která přímo reaguje na poţadavky zákazníků. Systém Kanban je nejvhodnější implementovat pro opakovanou výrobu stejných součástek s velkou mírou v odbytu. Pokud není splněn tento předpoklad, je třeba systém Kanban vybavit speciálním plánovacím systémem (určení kapacity regulačních okruhů a jejich toleranční rozsahy apod.). Předpoklady zavedení metodiky Kanban: - Vyškolený a motivovaný personál. - Vysoký stupeň opakování výroby, bez velkých výkyvů v poptávce. - Vzájemně harmonizované kapacity. - Rychlé postupy přetypování zařízení. - Připravenost personálu v případě zvýšené poptávky dělat přesčasy. - Rychlé odstranění poruch by měli zvládnout dobře vyškolení operátoři zařízení. - Výkonná kontrola kvality přímo na pracovišti. - Připravenost managementu na všech úrovních delegovat pravomoci. - Správně navrţený layout dílny s tendencí k linkovému uspořádání (plynulé toky). Základní pravidla pro fungování Kanban metodiky: 1. Personál následujícího procesu je povinen odebrat dílce z předcházejícího procesu, tak jak to předepisuje příslušná Kanban karta (mnoţství, typ...). 2. Výrobní personál můţe vyrábět jen to, co mu povoluje výrobní Kanban karta. 3. Pokud na pracovišti nejsou k dispozici ţádné Kanban karty, nesmí být realizována ţádná činnost (doprava, výroba). 4. Kanban karty jsou vţdy přepravovány společné s paletami a dílci (kromě jejich návratu). 5. Výrobní personál odpovídá za to, ţe jen výrobky se stoprocentní kvalitou budou vloţeny do palet pro následující proces. Pokud se vyskytne chyba, následuje stop celého procesu a odstranění chyby tak, aby se nemohla opakovat. 35

6. Inicializační počet Kanban karet musí být postupně redukován, provázanost procesů se musí zvyšovat, sníţení zásob odkrývá problémy a umoţňuje tak jejich eliminaci. Tento princip umoţňuje s pomocí počtu přítomných karet Kanban v systému kontrolovat a řídit rozpracovanost výroby a tedy i výšku zásob v rozpracování výrobě a velikost průběţné doby. V systému Kanban je po odebrání kompletní výrobní dávky odeslána z odběrového místa dodavateli (předřazené pracoviště) karta Kanban, která má funkci objednávky na dodávku nové výrobní dávky nebo materiálu či polotovarů. Kanban karty slouţí zároveň pro signalizaci stavu zásob a rozpracovanosti výroby. Nejdůležitější prvky této metodiky jsou: - Vytvoření svázaných samo-řídících regulačních okruhů mezi výrobními a spotřebními oblastmi. - Implementace tahového principu pro následující spotřební stupeň. - Pruţné nasazování personálu a provozních prostředků. - Přenos krátkodobého řízení na výrobní pracovníky pomocí speciálního nosiče informací karty Kanban. 4. Porovnání agilních a rigorózních metodik V současné době představují agilní a rigorózní metodiky dva hlavní směry v oblasti softwarového inţenýrství. Tyto dva směry vycházejí z odlišného pohledu na samotný vývoj softwaru a tím je kaţdý z nich vhodný pouze pro určitý typ projektů. Hlavní rozdíly mezi těmito přístupy vývoje byly uvedeny v předchozích kapitolách, zde si dále uvedeme další srovnání podle vybraných hledisek pomocí tabulky (Tab. 1). 36

Tab. 1 Porovnání rigorózních a agilních metodik [18] 37

Z výše uvedených informací o agilních metodikách lze usoudit, ţe pro pouţití některého ze zástupců těchto metodik je zapotřebí, aby naše prostředí, do kterého chceme danou metodiku zavést, splňovalo určité předpoklady. Zejména se jedná, jak jiţ bylo i v předešlých kapitolách zmíněno, o začlenění koncového uţivatele dané aplikace do řešitelského týmu, čímţ je tedy kladen důraz na vzájemnou komunikaci ne jenom v rámci týmu ale i se samotným zákazníkem. Pro vyuţití výhod osobní komunikace je pak i samotná velikost řešitelského týmu pokládána za velmi důleţitý faktor, kde se doporučuje nejvýše deset vývojářů. Z doporučení na velikost týmu nám pak vyplívá, ţe je nevhodné pouţívat agilní metodiky pro rozsáhlejší projekty, které si ţádají objemné vývojové týmy. Jiným významným poţadavkem je i odborná kvalifikovanost vývojářů, kde kromě jejich odborných znalostí je kladen důraz především na jejich zkušenosti z praxe (tactic knowledge)[1]. Mezi další předpoklady výčtově uveďme [19], [1]: - dokumentace a softwarové modely při vývoji nehrají hlavní roli; - poţadavky na software a prostředí, ve kterém je vyvíjen se v průběhu mění; - přizpůsobení se dynamickému vývojovému procesu vede k vysoce kvalitnímu produktu; - viditelnost do projektu nastává především při ukončení daného přírůstku; - náklady na změnu se dramaticky nezvyšuji v závislosti na překročení termínu. Pokud by námi vyvíjený projekt nesplňoval výše uvedené předpoklady, jsme pak nuceni pouţít těţší metodiku, tedy některou z rigorózních metodik nebo jinou alternativu spočívající v kombinaci těchto rozličných přístupů vývoje. Tedy pokud chceme pouţít agilní metodiku i pro tyto projekty je moţné ji obohatit o některé praktiky ze zástupců rigorózních metodik. Na druhou stranu, pokud jsou předpoklady pro nasazení agilní metodiky splněny, je moţné pouţít i některou odlehčenou verzi rigorózní metodiky, příkladem můţe být metodika AUP [18]. 38

5. Nástroje na podporu agilního vývoje softwaru Jiţ ze samotného manifestu o agilním vývoji vyplývá, ţe bychom se měli soustředit na samotný vývoj a komunikaci a nezdrţovat se definováním procesů a pouţíváním bytelných nástrojů. To by moţná fungovalo u týmu 4 lidí při Extrémním programování. Pokud ale je v týmu více lidí a jsem například manaţer, který řídí více týmů, mohu se začít ztrácet v Excelovských souborech a ocenil bych integrované prostředí přístupné odkudkoliv. Analytická společnost Forrester v roce 2004 ohlásila, ţe proces agilního vývoje přímo nezdůrazňuje potřebu nástrojů, ale přesto jsou nástroje rozhodující pro úspěch agilních projektů. Mezi nejdůleţitější nástroje staví ty pro řízení projektu, jednotkové testování, nástroje pro release a build management.[20] Zřejmě nejpouţívanější metodikou mezi agilními týmy je SCRUM. Tato metodika rozděluje vývoj do jednotlivých sprintů. V rámci kaţdého sprintu jsou nadefinované určité cíle a úkoly. Ke kaţdému úkolu je přiřazen řešitel a odhaduje se potřebná délka na splnění úkolu. Celý průběh metodiky umoţňují později představené nástroje řídit. Na pravidelných Scrum meetings není problém pruţně měnit zdroje přiřazené na projektu nebo přidávat jiné úkoly. Tyto činnosti by se bez potřebných nástrojů museli sloţitě vypisovat například do Excelu a pak data sdílet. Dnešní nástroje samozřejmě podporují nejrůznější agilní metodiky vývoje, Scrum jsem uvedl jen pro představu, jaká funkcionalita je třeba. Argumentem na tomto místě můţe být, ţe takové nástroje zde jiţ přeci dávno jsou a to například MS Project. Rozdíl je ale v tom, ţe takovýto druh softwaru je určen jen pro projektové manaţery, k plánování a odhadování času. Není ale dostatečně flexibilní a nepodporuje specifické potřeby agilních metodik. Silnou stránkou nástrojů pro podporu agilních metodik je komplexnost a integrace veškerého potřebného softwaru pro vývoj do jednoho prostředí. Jako manaţer mohu z druhého konce světa vyuţívat SaaS produktu a mít přesnou představu, co se na projektu děje. Nejlepší nástroje obsahují programové řízení, projektové řízení, řízení zdrojů, poţadavků, testů a defektů. Velice rozsáhlé bývají moţnosti integrace se softwary třetích stran. Buď pro případ, ţe nástroj vyuţívá například freeware pro řízení testů, nebo pro sdílení dat s komerčními nástroji, často vyuţívanými ve firmách. 39

Pro označení verzí produktů je vyuţito pojmů enterprise a community (komunitní). Enterprise znamená plnou verzi vyvíjeného software, to nejlepší, co můţete od firmy získat. Community verze, někdy označována jako Team, značí většinou produkt stejného typu, ale s určitými omezeními. Tato omezení se vztahují nejčastěji na počet uţivatelů, projektových týmů a mívají menší funkcionalitu. Omezení vyplývají z toho, ţe community verze bývají pouze omezenou verzí enterprise produktů a jsou distribuovány zdarma. Pozor na srovnávání community verze s trial verzí, která znamená plnou verzi produktu, ale časově omezenou. V následujících podkapitolách budou popsané jednotlivé nástroje podporující metodiku SCRUM i Kanban. 5.1 Urban Turtle 4 Obr. 6 Ukázka prostředí Urban Turtle [23] 40