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:
Praha
doc. Ing. Alena Buchalcevová, Ph.D.
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
5.1.1 Popis společnosti Za vytvářením nástroje Urban Turtle stála otázka: „Proč jsme špatní ve vytváření softwaru?“ Za touto otázkou se skrývalo zklamání a selhání. Průmysl v ranném roce 2000 nedával smysl. Software byl postaven lidmi, kteří se příliš nestarali o koncové uţivatele. Takţe tehdejší nástroje byli ošklivé a nepouţitelné. Prostě nástroje bez vize. Na konci léta roku 2001 se tři kluci rozhodli, ţe uţ toho mají dost. Chtěli dělat věci lépe a vytvářet software, který má smysl. To vedlo, ţe se od všeho odprostili. Při jejich hledání nového významu jejich práce, přišli brzy na potenciál agilních technik. A tak se zrodila společnost Pyxis, která je mateřskou firmou společnosti Urban Turtle. Jejich příběh však není bez chybičky. Tito tři odváţlivci chybovali a chybovali často. Naštěstí se však ze svých chyb vţdy poučili. Kdyţ tedy zkombinujeme to co se naučili společně s jejich výkonnými mozky, oddanými zaměstnanci a partnery, kteří je podpořili, není divu, ţe úspěch na sebe nenechal dlouho čekat. Společnost Pyxis se stala vůdcem agilních praktik v Kanadě, Francii, Belgii a ve Švýcarsku. Pyxis měl prvního francouzsky mluvící Scrum trenéra na světě, a od té doby trénoval tisíce vývojářů a Scrum Masterů na uplatňování agilních principů.
5.1.2 Popis nástroje Nástroj Urban Turtle 4 poskytuje agilní řešení pro správu projektů pomáhajících k dokončení softwarového projektu. V této podkapitole budou stručně popsány. Produkt management pomáhá k vytvoření plánu agilního projektu, který usnadní sledovat celý proces a dodávky sluţeb. Produkt management pomáhá s koordinací větších úkolů, které jsou rozloţené do více týmů. Sledování postupu projektu, které je moţné díky sledování plnění jednotlivých úkolů. Překlenuje propast mezi potřebami uţivatelů a specifickými poţadavky. Plán agilního projektu je prohlášení o záměru, který popisuje, jak jsou plánované dodávky funkcí v průběhu času. Urban Turtle umoţňuje probrat budoucí cíle mezi týmy a zúčastněnými stranami. Zobrazit plán dodávek jednotlivých funkcí. Avšak neměl by být pouţíván k vytváření fixních nebo dlouhotrvajících projektů.
41
Agilní přístrojová deska (Agile Dashboard) umoţňuje zobrazit všechny metriky, které jsou potřebné k učinění správného rozhodnutí v průběhu agilního projektu. Toto je moţné provést přímo přes Team Foundation Server. Dashboard umoţňuje zobrazit všechny agilní metriky ze všech projektů. Zahrnuje tak zvaný Sunset Graph, který poskytuje skutečnou předpověď ohledně probíhajícího agilního projektu. Součástí dashboardu jsou i widgety, které zobrazují v reálném čase informace z nevyřízených případů. Zobrazuje postup jednotlivých sprintů s jednotlivými milníky a strávenou dobou, umoţňuje sledování rozpočtu, kritických faktorů a rozdělení přístrojové desky na metriky týmu a metriky samotného managera. Vlastní úprava nástěnky (Custom Boards) umoţňuje snadno vytvářet, zobrazovat a spravovat více nástěnek. Kaţdý tým můţe mít svůj vlastní proces (jinou nástěnku pro kaţdou iteraci). Podporují Kanban i Scrum nebo jakéhokoliv procesy, jednoduché či komplexní. Manager rozhoduje co, která z nástěnek zobrazuje (milníky, WIP limity, iterace, atd.). Vytvoření nové desky a její úprava je velice snadné pomocí jednoduchého a přehledného rozhraním. Produkt Backlog je chytrý nástroj pro majitele výrobku a Scrum Mastery k naplánování a určení priorit práce. Zvyšuje schopnosti plánování. Zpřehledňuje a určuje priority jednotlivých nevyřízených úkolů pomocí barevných kartiček. Zrychlí plánování sprintů tím, ţe umoţní vytváření pracovních poloţek a úkolů za pochodu. Nově vytvořené nebo nezařazené pracovní poloţky je moţné nalézt ve stejném seznamu. Umoţňuje potvrzení týmových předpovědí a jednoduché sledování týmového postupu. Sprint Backlog je nástroj, který umoţní kaţdému členovi týmu sledovat své pracovní vytíţení v průběhu sprintu. Zobrazuje dokončené, probíhající nebo zbývající práce vše přehledně na jednom místě. Rychle aktualizuje zbývající čas bez nutnosti opustit sprint backlog. Díky této funkci není potřeba měnit proces, stačí překonfigurovat backlog. Estimation Board (Nástěnka Odhadu) tato funkce umoţňuje zlepšní odhadu. Zvyšuje spolupráci a zlepší rozvrţení neudělané práce rychleji. Odhady jsou automaticky ukládány do Team Foundation Serveru. Tuto funkci lze spustit i na tabletech.[23]
42
5.2 TeamPulse
Obr. 7 Ukázka prostředí TeamPulse[24]
5.2.1 Popis společnosti Nástroj TeamPulse vytvořila společnost Telerik coţ je bulharská společnost nabízející softwarové nástroje pro vývoj webových, mobilních, desktopových aplikací, nástroje a předplatné sluţby pro rozvoj aplikací. Společnost byla zaloţena v roce 2002 jako společnost zaměřená na vývojové nástroje .NET, Telerik nyní také prodává platformy pro webové, hybridní a nativní vývoje aplikací. Dne 22. října 2014 Progress Software oznámila akvizici společnosti Telerik. Akvizice byla dokončena 1. prosince 2014. Telerik byla zaloţena v roce 2002 čtyřmi absolventy Americké univerzity v Bulharsku a Technické univerzity v Sofii. Zpočátku se zaměřili na poskytování outsourcingového vývoj softwaru pro zahraniční a bulharské společnosti, poté firma přesunula své zaměření k vytvoření nástroje pro vývoj aplikací. Jejich prvním výrobkem, RAD editor (Rapid Application Development), byl editor webových stránek navrţen tak, aby podporoval nedávno vydanou technologií společnosti Microsoft, ASP.NET. Firma pak rozšířila své nabídky, aby zahrnovali uţivatelské rozhraní (UI) ovládacích prvků navigace a Telerik 43
Sitefinity, systém pro správu o několik let později. Na základě interakcí vývojářů, Telerik vyvinula nástroje zaměřené na podporu dalších .NET technologií, jako jsou ASP NET AJAX, ASP.NET MVC, WPF, Silverlight a Windows / Windows Phone. Telerik představil podporu pro HTML5 a JavaScript v roce 2011 se svým produktem Kendo UI, který se shoduje s očekávaným růstem v mobilním průmyslu.
5.2.2 Popis nástroje TeamPulse Backlog je navrţen tak, aby všechna projektová hlášení bylo moţné nalézt na jednom místě (jako uţivatelské příběhy, chyby, problémy a rizika, kde je lze prohlíţet, editovat a stanovit jejich prioritu. Nástroj TeamPulse pomáhá naplánovat dodávky a iterace díky intuitivnímu uţivatelskému rozhraní, které umoţňuje rychle přiřadit funkce k dodání, rozdělit funkce do příběhů a přiřadit příběhy k iteracím. Pro vizualizaci pokroku jsou k dispozici dva typy virtuálních nástěnek: nástěnka s úkoly a nástěnka příběhová. Na těchto nástěnkách lze provádět téměř cokoliv od vytváření a editace pracovních poloţek, přes filtrování lidí iterací nebo olastí. Díky kanbanovské nástěnce s WIP limity lze pracovat bez iterací a pouze nastavit minimální a maximální počet objektů, který můţe jeden proces mít. Nástroj poté upozorní pokud nejsou limity dodrţeny a napomůţe odstranit překáţky, které brání pokračování v práci. Díky sledování a zaznamenávání průběhu projektu je snadné určit zda se stihne naplánovaný termín dodávek, nebo určit rizika pomocí historie vzniklých chyb. Nástroj TeamPulse pomáhá efektivnímu řízení více souběţných projektů najednou. Lze s ním spravovat pracovní poloţky související s různými projekty, vše na jedné obrazovce. Umoţňuje tak stanovit priority napříč různými projekty. V případě, ţe se spustí více projektů s omezenými zdroji, je moţné vytvořit souhrnný backlog a na jeho základě stanovit větší priority pracím, které nejvíce zaostávají. Tímto způsobem bude mít tým vţdy jasnou představu na jaké poloţky se musí zaměřit. Pro lepší sledování průběhu vývoje jsou k dispozici všechny časové záznamy provedené členy týmů napříč všemi projekty. Lze tak filtrovat pomocí času, člena týmu, projektu nebo typu pracovní poloţky. Nástroj umoţňuje zobrazit celkový čas strávený jednotlivými kroky, coţ se
44
dá vyuţít k výpočtu ceny za práci pro zákazníka. K jednotlivým časovým údajům lze přikládat i poznámky s odůvodněními proč daná práce trvala danou dobu, atd. Všechny časové údaje lze také exportovat do formátu CSV. Zlepšuje propojení týmu spolu s účastněnými stranami prostřednictvím portálu pro zpětnou vazbu. Na tomto portálu mohou zákaznici poţadovat úpravy, hlásit chyby, nebo přispět svými nápady na zlepšení. Nástroj má zabudovaný oznamovací systém, který zákazníky upozorňuje na průběh zpracování jejich poţadavku a umoţňuje jim hlasovat nebo přikládat komentáře. Všechny informace jsou dostupné i z mobilních zařízení. Pomáhá s odstraněním překáţek a udrţet tak projekt ve správných kolejích. Díky tabulce zobrazující jednotlivé překáţky (chyby, rizika, bloky v iritacích nebo problémy s vydáním) je moţné předpovídat rizika, sledovat historii chyb, vytipovat, které procesy se zpozdí a tak učinit dopředu případná opatření. TeamPulse pomáhá týmům adaptovat se na agilní metodiky. Best Practice Analyzer pomáhá s uvedením agilní teorie do praxe. Nástroj analyzuje a vykazuje prvky v projektu, které nejsou v souladu s nejlepšími praktikami. Zprávy z Best Practise Analyzeru umoţní vzít konkrétní akce a rychle opravit případné problémy.[24]
45
5.3 Agilo for Trac
Obr. 8 Ukázka prostředí Agilo for Trac [25]
5.3.1 Popis společnosti Agilo for Trac (formálně známý jako Agilo for Scrum) je open source, webový Scrum nástroj, který podporuje agilní procesy vývoje software. Agilo je zaloţen na systému Trac, široce pouţívaném systému sledování záleţitostí. Je naprogramován v jazyce Python a je distribuován pod Apache Software License 2.0. Vývoj tohoto nástroje byl zahájen v lednu 2007 panem Andrea Tomasinim a první veřejná verze byla vydána v lednu roku 2008. Od srpna 2011 byl pojmenován jako Agilo For, aby se zdůraznila jeho vazba s Trac. Agilo je pouţíván pro projekty agilního vývoje softwaru, ve všech hospodářských odvětvích, které vyuţívají rámce Scrum. Aplikace python lze stáhnout a pouţít jako zdrojový tarball, python-egg, SaaS a VMware Virtual Appliance nebo Windows Installer. Agilo verze 0.8 je
46
zaloţena na systému Trac 0.11, novější verze jsou zaloţené na systému Trac 0.12. Agilo podporuje scrum týmy, Scrum Mastery a majitelé produktu v průběhu projektu a pomáhá koordinovat projekty agilního vývoje softwaru.
5.3.2 Popis nástroje Nástroj Scrum Agilo for Trac je navrţen a vyvinut pro týmy, Scrum Mastery a vlastníky produktu, jakoţ i zúčastněných stran zapojených do projektu. Nástroj nabízí mnoho uţitečných funkcí zaloţených na tisíci hodinách zkušeností z podpory reálných projektů svých zákazníků, ať uţ tými pracovali na dálku či lokálně. Nástroj Agilo for Trac umoţňuje plnou podporu pro všechny tři Scrum role (vývojáře, scrum mastery i majitele výrobku) s různými funkcemi podporující jejich práci. Obsahuje hierarchické vstupenky, které propojují jednotlivé úkoly do příběhu (a poţadavků v případě potřeby), tím zajišťuje kompletní přehled od poţadavků, příběhu a úkolů aţ po dodávky funkcí. Agilo for Trac zajišťuje integraci jednotlivých „podverzí“ (subversions), jejich úkolů, chyb atd. Poskytuje těsnou integraci se zdrojovým kódem a to jak browse kódů, tak i odkazů ke změně sad s různými verzemi kontrolních systémů (Subversion, Mercurial, Git, Bazaar a Perforce). Soubory je moţné exportovat do Excelu ve formátu CSV spolu s importem úpravy objemu nebo jeho mazání. Součástí nástroje je samozřejmě i Backlog, který umoţňuje určení priorit a podporu pro mapování příběhu a jednotlivých sprintů. Backlogů lze nalézt hned několik např: backlog chyb, rozpracovanosti, překáţek. Ty napomáhájí k podpoře více projektů a více členných týmů. Burdown chart (graf vytíţenosti) podporuje distribuované týmy v různých časových pásmech (podpora časových pásem). Podporuje také týmy pro omezení nepředvídatelných úkolů jako je podpora poţadavků nebo opravy chyb. Poskytuje široké moţnosti úpravy vzhledů jako přidání vlastních typů, polí pro jiţ existující
47
typy, definici vlastních postupů pro karty, sledování restů, které nejsou přímo spojeny s uţivatelským příběhem, atd. Agilo for Trac umoţňuje propojení jednotlivých příběhů a tak znásobit poţadavky, pro větší přehlednost, úpravu atributů příběhu nebo úkolů přímo v přehledu rozpracovanosti (Backlog view). Integruje wiki a týmový management, kde stačí zadat pouze dostupnost týmu a nástroj uţ
sám
provede
výpočty,
je
rozšiřitelný
o
moduly,
které
jsou
zdarma,
Všechny výše uvedené vlastnosti jsou společné pro Agilo free (verze zdarma) i pro Agilo Pro (profesionální, placenou verzi). Agilo Pro nabízí oproti free verzi ještě několik dalších moţností pro vývojáře. Jako profesionální podporu zahrnující SLA, integrování tabule pro zápisky, export tabule a moţnost jí vytisknout, vytvoření nové karty přímo z pohledu rozpracovanosti, úpravu všech atributů příběhů a úkolů přímo z karty rozpracovanosti bez nutnosti vypínání a opětovného zapnutí. Moţnosti pohledů jsou uloţeny pro všechny uţivatele. Podporuje také Kanban skrze nekonfigurovatelných sloupečků a zajišťuje hostované sluţby.[25]
48
6. Definice kritérií a porovnání nástrojů Informace týkající se jednotlivých nástrojů jsem čerpal z webových prezentací firem, které je vyvíjeli. Z tohoto důvodu nebylo snadné získat všechny potřebné informace pro řádné porovnání produktů jelikoţ do svých prezentací neuvedly mnoho technických specifikací. Navíc se často jako marketingový tah, stejná funkcionalita pojmenovává různými způsoby pro odlišení se od konkurence. Kritéria pro porovnání nástrojů jsem stanovil na základě informací získaných z webových prezentací, jsou to tyto: -
Maximální moţný počet uţivatelů
-
Distribuce softwaru
-
Cena
-
Funkcionalita
-
Design a ovládání
6.1 Maximální možný počet uživatelů Agilní týmy většinou nemívají tisícovky uţivatelů. Toto kritérium jsem však zvolil, protoţe pro zákazníky je dobré vědět, jestli daný program bude podporovat všechny členy zákazníkova týmu. Popřípadě rozhodne-li se zákazník tým rozšířit, jestli je moţné rozšířit i program. Společnost Telerik nabízí nástroj TeamPulse v podobě StarterPack (balíček pro začátek), který můţe vyuţívat pouze pět uţivatelů, avšak toto není konečný počet uţivatelů. V případě, ţe si zákazník přeje přidat více uţivatelů, bude muset za kaţdého nového uţivatele připlatit 249 dolarů. Celkový počet uţivatelů není omezený. Společnost Urban Turtle má na svých stránkách kalkulátor, který umoţní okamţité zobrazení ceny pro daný počet uţivatelů. Minimální počet uţivatelů je 5 a maximální mnoţství je omezené na 999 uţivatelů.
49
Společnost Agilo for Trac jako jediná nabízí moţnost vyuţívání svého softwaru pro jediného uţivatele. Ovšem oproti předchozím dvou m nástrojům je maximální počet uţivatelů omezený pouze na 100 uţivatelů.
6.2 Distribuce softwaru Distribucí softwaru se mám na mysli způsob zavedení softwaru. Zda-li dodáván jako instalační balík na vlastní aplikační server, nebo co je častější a v současnosti i více ţádané, a to jako sluţba. Druhý případ formou SaaS má obrovské výhody. Mezi ty zásadní patří v podstatě nulové nároky na nový hardware a zaměstnance, kteří by tento hardware a instalaci museli udrţovat. Dále je sluţba přístupná z jakéhokoliv počítače připojeného k internetu, a tím pádem umoţňuje práci odkudkoliv je třeba. Značnou výhodou je, ţe za běh sluţby zodpovídá dodavatel a ručí za podmínky uvedené ve smlouvě. Formou SaaS jsou také zaručeny veškeré upgrady a opravy chyb, aniţ by zákazníci museli sami něco přeinstalovat a hlavně za to platit. Další výhodnou dodávky softwaru jako sluţby jsou výborná škálovatelnost a moţnost platby jen za to, co opravdu v danou chvíli zákazník dostane. Bohuţel poskytování softwaru jako sluţby není bez rizika. Je zde moţnost zneuţití interních dat, která jsou uloţena u poskytovatele sluţby. Avšak zvolením ověřené a stabilní firmy spolu s kvalitní smlouvou se jakémukoliv zneuţití dá předejít. Mezi důleţité aspekty také patří to, v jaké lokalitě se firma nachází z důvodu dostatečné internetové konektivity. Firma můţe mít sebelepší smlouvu s poskytovatelem softwaru, ale můţe doplatit na špatné připojení.[21] Všechny tři mnou porovnávané nástroje poskytují software formou SaaS a je moţné je instalovat i na aplikační server. Hostované verze vyjdou zákazníka vţdy dráţ neţ verze určené k instalaci na platformu.
6.3 Cena V dnešní době je asi jedeno z nejdůleţitějších kritérií hlavně cena. V tomto kritériu jsem porovnával jak Enterprise (podnikové) verze, tak i Trial (pokusné) verze. Pokusné verze firmy zprostředkovávají formou hostingu. Abych mohl porovnat ceny jednotlivých nástrojů musel
50
jsem určit, ţe maximální počet uţivatelů je pět a nástroj bude poskytnut na dobu jednoho roku. Ceny na svých stránkách společnosti Urban Turtle a Telerik uvádějí v dolarech, pouze společnost Agilo for Trac uvádí cenu v eurech, proto pro lepší srovnání převádím tuto cenu na americké dolary podle kurzu České Národní Banky ze dne 24.5.2015. Společnosti Urban Turtle a Telerik nabízejí své nástroje v rámci trial verzí zdarma na dobu třiceti dnů. Společnost Agilo for Trac nabízí svůj nástroj také na dobu třiceti dnů, ovšem za jeho poskytnutí si účtují jednorázový poplatek 29 euro (32,85 USD). Pro enterprise verzi nástroje TeamPulse společnost Telerik nabízí začínající balíček (StarterPack), který můţe vyuţívat pět uţivatelů po dobu jednoho roku za 1499 USD. V případě, ţe si zákazník bude přát uţivatelů více bude muset za kaţdého dalšího uţivatele připlatit 249 USD. Společnost Urban Turtle nabízí svůj software pro neomezené mnoţství uţivatelů. Cena se samozřejmě odvíjí od počtu uţivatelů. Roční uţívání enterprise verze nástroje Urban Turtle pro pět uţivatelů vyjde zákazníka na 540 USD. Uţivatele lze samozřejmě i přidat, přidávat lze vţdy minimálně po pěti uţivatelích a cena za přidání nové pětice uţivatelů je vţdy 540 USD. Společnost Agilo for Trac vychází z těchto tří nástrojů ekonomicky nejvýhodněji. Za vyuţívání nástroje po dobu jednoho roku pro pět uţivatelů zákazník zaplatí 427 euro, tedy 483,62 USD a v případě, ţe zákazník bude chtít navýšit maximální počet uţivatelů, uplatňuje se zde mnoţstevní sleva.
6.4 Funkcionalita Všechny tři nástroje umoţňují přehledné řízení agilních projektů se sledování průběhu jednotlivých sprintů, průběhu celého projektu, vytváření a analýzy backlogů, sledování vytíţenosti jednotlivých týmů, chyb a překáţek v plnění dílčích úkolů, převádění výstupních dat do formátu CSV, vlastní úpravu vzhledu jednotlivých funkcí, atd. Proto jsem se v tomto kritériu zaměřil na funkce, které jeden nástroj nabízí a druhý postrádá. V této oblasti oproti svým konkurentům vyniká hlavně nástroj TeamPulse. Jako jediný má
51
přímo v sobě zabudovaný portál pro podporu zákazníkům, kteří zde mohou psát své poţadavky na funkce, hlásit chyby, poţadovat úpravy jiţ zavedených funkcí, atd. a zároveň i sledovat jak probíhá vyřízení jejich poţadavku. Ostatní společnosti mají zákaznické podpory samozřejmě také, ale nemají je přímo integrované do svých nástrojů. Velkou výhodu oproti svým konkurentům má nástroj TeamPulse také v tom, ţe pomáhá vývojářským týmům s adaptací na agilní řízení projektu. Obsahuje funkci Best Practice Analyzer, který analyzuje a vykazuje prvky v projektu, které nejsou v souladu s nejlepšími praktikami. Coţ velmi pomáhá uţivatelům převést teoretické znalosti agilního programování v praxi. Nástroje TeamPulse a Urban Turtle oproti Agilo for Trac umoţňují podporu tabletů. Tedy vyuţívání svých nástrojů na těchto mobilních zařízeních. Nástroj Agilo for Trac má navíc oproti svým konkurentům integrovaný team management, coţ je funkce, která pomáhá s řízením týmů, tak ţe stačí zadat dostupnost týmů a program uţ sám provede matematické výpočty.
6.3 Design a ovládání Toto kritérium je velice subjektivní a kaţdý můţe design a ovládání jednotlivých programů vnímat jinak. Všechny tři nástroje obsahují širokou škálu sad pro úpravu funkcí, tak aby si zákazník mohl uţivatelské prostředí nastavit tak, jak mu nejvíce vyhovuje. Na mne působil uţivatelsky nejpřátelštějším dojmem nástroj Urban Turtle. Uţivatelské prostředí je přehledné, jednoduché a snadno se v něm uţivatel zorientuje. Nejnáročnější na zorientování pro mne byl nástroj TeamPulse. Avšak tento výsledek byl očekávatelný, neboť vývojový tým nástroje Urban Turtle se hlavně zaměřuje na to aby jejich program byl co nejjednodušší a uţivatelsky co nejpřátelštější, tak aby vývojáře práce s ním bavila.
52
Závěr Agilní metodiky jsou postavené na rozumných principech, jejich největší předností je flexibilita, díky které se dokáţí přizpůsobit měnícím se podmínkám a poţadavkům na projekt a také rychlost, se kterou dokáţí dodat první omezené funkční verze. Přestoţe vývoj agilních nástrojů nemá dlouhou historii je jiţ moţné v dnešní době nalézt celou řadu nástrojů. Z velké části jde o nástroje ve fázích vývoje nebo nástroje, které se zaměřují na podporu pouze jedné metodiky. Avšak trend ve vývoji nových nástrojů nasvědčuje tomu, ţe budoucí nástroje budou v sobě kombinovat metodiky dvě nebo i více. Dle mého názoru je tento směr správný, kaţdá z metodik (ať uţ agilní či rigorózní) má co nabídnou a vyjmutím toho nejlepšího z kaţdé z nich a jejich kombinacemi můţeme pouze získat lepší, přesnější a přehlednější nástroje, které budou vývojářským týmům ku pomoci v čím dál větším rozsahu. Řízení projektů pomocí agilních metodik není u nás zatím moc rozšířené, z tohoto důvodu jsem se při psaní této práce spoléhat na informace z elektronických zdrojů, jako byli například stránky dodavatelů nástrojů. Tím mohl vzniknout problém neobjektivnosti, protoţe kaţdý z výrobců vychvaluje svůj software z důvodu konkurenceschopnosti. Tím pádem je velmi obtíţné nalézt informace o nedostatcích jejich softwaru. Po prozkoumání funkcionalit a porovnání mnou vybraných nástrojů jsem došel k závěru, ţe kaţdá z firem, kterou jsem v této práci popsal se zaměřuje na jinak veliké týmy. Společnost Urban Turtle se zaměřuje hlavně na to aby vývojové týmy jejich práce bavila a proto vytváří prostředí jednoduché, přehledné a lehko upravitelné. Přestoţe na svých stránkách mají kalkulátor, který ukazuje, ţe maximální počet uţivatelů aţ 999, jejich podpora řízení více týmů a více projektů není tak dobře zpracovaná jako u softwarů Agilo for Trac nebo TeamPulse. Z tohoto důvodu soudím, ţe nástroj Urban Turtle slouţí spíše pro podporu menších týmů, a ţe tým Urban Turtle chtěl na své zákazníky udělat dojem téměř neomezeným počtem uţivatelů a v případě, ţe by nastala situace, kdy si někdo objedná jejich software pro opravdu velký počet uţivatelů, budou problémy řešit za pochodu.
53
Nástroj Agilo for Trac má dobře zpracované vedení více týmů a více projektů avšak celkový počet uţivatelů je omezený na 100. Agilní vývojové týmy nemívají moc velké počty uţivatelů, ovšem v případě, ţe zákazníkovo tým má právě 100 a více uţivatelů je pro něj tento nástroj, nepouţitelný. Z tohoto důvodu usuzuji, ţe se společnost Agilo for Trac zaměřuje na týmy střední a větší velikosti. Z mnou tří vybraných nástrojů se pro pouţití ve velkých firmách, dle mého názoru, nejvíce hodí nástroj TeamPulse od společnosti Telerik. Tento nástroj je velmi robustní a nejvíce naditý funkcemi. Oproti svým konkurentům, popisovaných v této práci nabízí mnohem více funkcí pro správu, sledování a vyhodnocování času stráveného na projektech. Obsahuje velké mnoţství funkcí pro zpřehlednění, správu a řízení většího počtu týmů, větších týmů a více projektů. Navíc obsahuje portál pro podporu, která umoţňuje vývojovým týmům bliţší spolupráci se svými zákazníky a zákazníkům umoţňuje snazší úpravu pro ně vyvíjeného softwaru. Velmi příjemně mne překvapilo, ţe se nástroj TeamPulse snaţí vést své uţivatele ke správnému agilnímu řízení a pomáhá jim převést jejich teoretické znalosti agilních principů do praxe. Shrnu-li své závěry, tak pro začínající vývojové týmy bych doporučil nástroj Agilo for Trac z důvodu pestré škály funkcí a hlavně v porovnání s konkurencí nejniţšími ekonomickými náklady. Právě ekonomické náklady budou dle mého názoru pro začínající týmy velmi důleţité. Přestoţe Urban Turtle je velmi uţivatelsky přátelským nástrojem, čímţ je vhodnou volbou pro začínající týmy, nemá tolik funkcí jako Agilo for Trac a navíc je i ekonomicky více náročný. Pro zkušené nebo velké vývojové týmy bych poté jednoznačně doporučil nástroj TeamPulse, který hlavně vedoucím týmů velice významně usnadní řízení týmů a projektů.
54
Seznam použité literatury: [1]
BUCHALCEVOVÁ, Alena. Metodiky budování informačních systémů. Vysoká
škola
ekonomická
v Praze.
Praha:
Oeconomica,
2009.
ISBN 978-80-245-1540-3 [2]
OŠLEJŠEK, Radek. Objektové metody návrhu informačních systémů – Strategie vývoje softwaru [dokument ve formátu pdf]. Fakulta informatiky MU. Dostupné
z:
_Strategie_vyvoje-sw.pdf?fakulta=1433;obdobi=4724;kod=PA103 > [3]
Software engineering – Wikipedia, the free encyclopedia. [online]. Dostupné z: < http://en.wikipedia.org/wiki/Software_engineering>
[4]
Expert Project Management- The Role of the Project Life Cycle (Life
Span)
in
Project
Management
[online].
Dostupné z:
[5]
RÁČEK, Jaroslav. Analýza a návrh systémů – Úvod [dokument ve formátu pdf]. Faktura informatiky MU, 2007
[6]
RÁČEK, Jaroslav. Strukturovaná analýza systémů. Masarykova univerzita, Brno, 2006. ISBN 80-210-4190-0
[7]
KADLEC, Václav. Agilní programování – Metodiky efektivního vývoje softwaru. Brno: Computer Press, 2004. ISBN 80-251-0342-0
[8]
ŘEPA, Václav. Analýza a návrh informačních systémů. Ekopress, 1999. ISBN 80-86119-13-0
[9]
BECK, Kent: Extrémní programování, Grada, 2002. ISBN 80-247-0300-9.
[10] BECK, Kent: Programování řízené testy, Grada, 2004. ISBN 80-247-0901-5. [11] ABRAHAMSSON,
Pekka
WARSTA, Juhani: Agile
a SALO, Outi a RONKAINEN, software
Jussi a
development methods: Review and
analysis, VTT Technical Research Centre of Finland, 2002. ISBN 951-386010-8. [12] PALMER; STEHEN; FELSING; JOHN. A Practical Guide to Feature-Driven Development, Prentice Hall, 2002. [13] HIGHSMITH, Jim. Agile Software Development Ecosystems [online] Dostupné z:
55
[14] Lean Agile Executives Management Transition. [online] Dostupné
z:
management-transition/>. [15] Principles Agile Modeling. [online] Dostupné z: [16] ASTELS, David. Test Driven Development: A Practical Guide. Prentice Hall. 2003. [17] Introduction to OpenUp. [online] Dostupné z: [18] BUCHALCEVOVÁ, Alena. Metodiky vývoje a údržby informačních systémů. 1. vydání. Praha: Grada, 2005. 163 s. Management v informační společnosti. ISBN 80-247-1075-7 [19] TURK, Dan; FRANCE, Robert; RUMPE, Bernard. Limitations of Agile Software Processes. [online]. Dostupné z: . [20] BECK, Kent; BEEDLE, Mike; BENNEKUM, Arie; COCKBURN, Alistair; CUNNINGHAM,
Ward;
FOWLER,
Martin;
GRENNING,
James;
HIGHSMITH, Jim; HUNT, Andrew; JEFFRIES, Ron; KERN, Jon; MARICK, Brian;
MARTIN,
Robert;
MELLOR,
Steve;
SCHWABER,
Ken;
SUTHERLAND, Jeff; THOMAS, Dave. Aliance agilního vývoje software. Dostupné z: . [21] VOŘÍŠEK, Jiří. Principy a modely řízení podnikové informatiky. 1. vyd. Praha: Oeconomica, 2008. ISBN 976-80-245-1440-6. [22] VÍTEK, Václav. Tahový systém řízení výroby. [online] Dostupné z: [23] Urban Turtle features. [online] Dostupné z: [24] TeamPulse Benefits. [online] Dostupné z: [25]
Agilo for Trac Features. [online] Dostupné z:
56
Seznam obrázků Obrázek 1: Tradiční a Agilní vývoj softwaru ............................................................................ 9 Obrázek 2: Vodopádový model ............................................................................................. 12 Obrázek 3: Spirálový model ................................................................................................... 13 Obrázek 4: RUP: Dvě dimenze vývoje softwaru .................................................................... 16 Obrázek 5: Volba odpovídající Crystal metodiky ................................................................... 28 Obrázek 6: Ukázka prostředí Urban Turtle ............................................................................ 40 Obrázek 7: Ukázka prostředí TeamPulse ............................................................................... 43 Obrázek 8: Ukázka prostředí Agilo for Trac ........................................................................... 46
57
