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

Transkript

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

2 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 Lukáš Vojtek, DiS.

3 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 ing. Steinerové, své rodině, přátelům a kolegům za podporu a pochopení.

4 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

5 Obsah Úvod Způsob vývoje software Agilní vývoj softwaru Historie Vodopádový model Agilní metodiky Rozdíly mezi agilní technikou a metodikou Manifest agilního vývoje softwaru Příklady agilních metodik Extrémní programování (Extreme programming, XP) Crystal metodiky Metodika Agile Unified Process (AUP) Metodika Open Unified Process (OpenUp) Agilní modelování Metodika Scrum Metodika Kanban Porovnání agilních a rigorózních metodik Nástroje na podporu agilního vývoj softwaru Výběr nástrojů Urban Turtle Popis společnosti Popis nástroje TeamPulse Popis společnosti Popis nástroje Agilo for Trac Popis společnosti...37

6 4.4.2 Popis nástroje Popis kritérií pro porovnání nástrojů Podpora většího počtu týmů Podpora metodik Dostupnost nástroje Pořizovací náklady Prvky zajišťující konkurenční výhodu Vzhled a úpravy nástroje Hodnocení nástrojů dle kritérií Podpora většího počtu týmů Podpora metodik Dostupnost nástroje Pořizovací náklady Prvky zajišťující konkurenční výhodu Vzhled a úpravy nástroje...50 Závěr...57 Seznam použité literatury:...59 Seznam obrázků...61 Seznam tabulek...61 Seznam zkratek...61

7 Úvod Vývoj softwaru historicky sahá až k prvním počítačům. Tento obor prošel za dobu své existence celou řadou problémů a prodělal i celou řadu změn. Od revolučního vodopádového modelu, přes spirálový model a objektově orientované přístupy jsme dorazili až k dnešním sofistikovaným metodikám vývoje softwaru. V dnešní době se stále více do popředí dostávají tzv. agilní metodiky, kterých již vznikla celá řada. Spolu s metodikami vznikla i spousta nástrojů, které poskytují podporu pro vývoj softwaru a zároveň i zpřehledňují celý průběh projektu. Tato bakalářská práce se zabývá agilními metodikami, které napomáhají rychlejšímu, levnějšímu a optimálnějšímu vývoj softwaru a nástroji na podporu agilního vývoj softwaru, kterých každým rokem přibývá a je tak čím dál víc obtížné vybrat správný nástroj. Je zde stručně popsaná historie, která předcházela vzniku agilních metodik, pro zvýraznění výhod agilního programování jsou popsané i rigorózní metodiky, včetně vzájemného porovnání rigorózních a agilních metod. Zahrnutý je i popis vybraných agilních metodik a manifestu o agilním programování, ze kterého tyto metodiky vycházejí. Součástí práce je i přestavení tří mnou vybraných nástrojů podporující agilní vývoj softwaru, včetně způsobu, podle kterého byly nástroje vybrány. Hlavní podmínkou pro výběr nástrojů bylo to, že musí podporovat jak vývoj pomocí metodiky Scrum, tak i metodiky Kanban. Dále je v práci zahrnut i popis kritérií, podle kterých jsou potom nástroje porovnány a ohodnoceny.

8 1. Způsob vývoje softwaru V této kapitole je uvedený stručný popis způsobů, podle kterých je možné vyvíjet software. Dále jsou zde uvedena kritéria, pomocí kterých můžeme rozdělit jednotlivé způsoby vývoje softwaru, spolu se základními rozdíly vývojových metodik. Obecně je pojem způsob vývoje softwaru vnímán pouze jako volba metodiky, která představuje veškerý soubor postupů a metod používajících se k plánování a kontrole vyvíjeného projektu. Takových metodik vzniklo během uplynulých několika let celá řada a každá z nich se vyznačuje určitými klady a na druhou stranu samozřejmě i zápory. Možnými důvody, které stály za vznikem velkého množství metodik může být například různá zaměření společností nebo technologické prostředky, které vyžadují různé techniky a metody. V případě, že se vývojáři softwaru rozhodnou pro určitou metodiku a ta se při vývoji daného typu softwaru osvědčí, měli by mít stále na paměti, že daná metodika nemusí být vhodná pro vývoj všech typů softwaru a nasazení do všech možných typů podniků. Na jedné straně je jistě výhodou mít k dispozici velký výběr metodik s různými vlastnostmi, na straně druhé však velký výběr metodik může organizacím způsobit nemalé potíže při jejich výběru pro daný vývoj. Tento problém je zapříčiněn zejména tím, že chybí jednotný popis a kategorizace metodik. Kritéria, která by mohla vést ke kategorizaci metodik a tak k usnadnění při jejich výběru jsou podle (Buchalcevová, 2009) následující: - Zaměření metodiky: Podle tohoto kritéria bychom mohli metodiky rozdělit dle oblastí, ve kterých budou metodiky používané, na metodiky globální, které se zaměřují na vývoj, provoz, ale i řízení informačního systému v rámci celého podniku. Nebo na metodiky projektové zaměřující se na vývoj informačního systému v určité oblasti. - Rozsah metodiky: Toto kritérium rozděluje metodiky podle toho, jak moc pokrývají životní cyklus vývoje. Rozděluje metodiky na metodiky pokrývající celý životní cyklus vývoje a metodiky, které se zabývají pouze určitou částí životního cyklu vývoje (např.: návrh a implementace). 8

9 - Váha metodiky: Kritérium váha rozděluje metodiky na tzv. těžké metodiky, tedy metodiky, které mají přesně definované procesy, činnosti i artefakty a na lehké metodiky, které se místo podrobného popisu procesů zaměřují spíše na definování principů a praktik. - Typ řešení: Toto kritérium zohledňuje zejména to, jestli se metodika zaměřuje na vývoj nového řešení, rozšiřuje stávající, již užívané řešení, zabývá se integrací řešení nebo implementováním typového řešení. - Doména: Doménou se u tohoto kritéria rozumí oblast, pro kterou je software vyvíjen. Software může být vyvíjen například pro oblast řízení vztahů se zákazníkem neboli Customer Relationship Management, oblasti elektronického vzdělávání (e-learning) nebo pro vývoj tzv. obecného softwaru. - Přístup k řešení: Doporučuje se toto kritérium aplikovat pouze u projektově orientovaných metodik, které se zabývají novým vývojem. Metodiky se poté dělí na metodiky se strukturovaným vývojem, metodiky s objektově orientovaným vývojem a metodiky, u kterých probíhá vývoj pomocí komponent. Za pomoci kritéria Váha metodiky můžeme obecně metodiky rozdělit do dvou hlavních odvětví. Na odvětví těžkých, někdy také označovaných jako rigorózních metodik a na odvětví lehkých, častěji označovaných jako agilních metodik. U rigorózních metodik je důraz kladen hlavně na plánování, řízení a měření předem definovaných procesů, které se plní při vývoji softwaru. Agilní metodiky oproti tomu kladou důraz především na projekty, u nichž je důležité řešení vyvinout velmi rychle i za cenu toho, že samotnému postupu, který vede k cíli věnují menší pozornost. Hlavní myšlenka agilních metodik spočívá v tom, že se co nejrychleji rozjede vývoj softwaru, který se potom na základě zpětných vazeb od uživatele doladí do takové podoby, která nejvíce odpovídá vizi uživatele. Velmi charakteristický je pro tyto dvě odvětví metodik také jejich rozličný přístup ke zdrojům. Názorně je tento přístup možné vidět na obr. 1. 9

10 Obr. 1 Tradiční a agilní vývoj softwaru (zdroj: autor) U rigorózních metodik jsou požadavky na systém vnímány jako fixní, tyto požadavky se definují vždy již na začátku samotného vývoje a jejich splnění se u tvrdých metodik považuje za hlavní cíl. Na základě těchto předem definovaných a později nemněných (nebo jen velmi obtížně měnitelných) požadavků se poté stanovují proměnné zdroje a čas. Oproti tomu u agilního vývoje jsou zdroje a čas omezené, avšak funkcionalita daného systému se může měnit na základě požadavků zákazníka. Více toto téma popisuje (Buchalcevová, 2009). 10

11 2. Agilní vývoj softwaru V této kapitole je stručně popsaná historie, kterou se ubíral vývoj softwaru, až po vznik agilních metodik. Pro snadnější porozumění důvodů, které se staly podkladem pro vznik agilních metodik je v této kapitole uvedený i jeden z předních zástupců rigorózních metodik. Dále je zde uvedený popis metodik, rozdíl mezi agilní technikou a metodikou a manifest agilního vývoje. 2.1 Historie V šedesátých letech 20. století vznikla v oboru softwarového inženýrství velká krize. Pokračovat ve vývoji používáním tehdy dostupných metodik a nástrojů již bylo prakticky nemožné a navíc procedurální programovací jazyky a model programuj a opravuj se v té době stávali již také nedostačujícími. Největším problémem bylo to, že jakékoliv další možné kroky vývoje se zdály být nemožné nebo byly velice nákladné. Mezi největší investory do vývoje v této době patřili hlavně státní instituce a armádní útvary jednotlivých států světa. Zejména oni určovali, jakým směrem by se měl vývoj efektivnějších metod ubírat. Z tohoto důvodu se v roce 1969 začal definovat nový koncept softwarového inženýrství právě na konferenci NATO. Nový koncept měl zejména odstranit nedostatky současně používaných přístupů k řízení vývoje softwaru. Na počátku 70. let potom vzniklo několik novinek, které představovali významný pokrok pro softwarové inženýrství. Mezi tyto novinky patří např. specifikace, návrh, testování nebo modely životního cyklu. Vnikem nových technik se značně urychlil vývoj softwaru a koncem 80. let 20. století začali vznikat na softwarové vývojáře také nové revoluční požadavky, spojené s novými možnostmi, ale i novými výzvami, které s sebou přinášel hardware budoucí generace. Vodopádový model životního cyklu (viz. podkapitola 2.2) stále více sahá na dno svých sil a proto již nedokáže udržet krok s novými požadavky, které se po vývojářích vyžadovali. Záblesk naděje a adekvátnější reakce na neustále nově vznikající požadavky ze strany uživatelů potom přináší objektově orientovaný přístup k programování, nové generace zkušenějších vývojářů nebo například grafické prostředí. Tyto nové prvky ve vývoji softwaru umožňují vznik dalších a 11

12 přijatelnějších nástrojů a konceptů, které se v té době inspirovali zejména programovacím jazykem Small Talk. Dosavadní přístup vývoje softwaru se tak stal zastaralým a nepoužitelným a bylo nutné jej nahradit více efektivním přístupem. V této době však už nejsou hlavními uživateli státní instituce nebo armádní útvary a proto se odkrývají nové možnosti pro experimentování s přístupy pro vývoj softwaru. Hlavně z těchto důvodů se v 90. letech minulého století začali upřednostňovat metodiky, které byly založené na objektově orientovaném přístupu. Mezi poslední změny na poli vývoje softwaru patří vznik iterativních neboli agilních metodik a jejich vzájemné prolínání s rigorózními přístupy. Zdali tento nový trend ve vývoji povede ke vzniku nějaké nové revoluční metodiky nebo se prokáže, že současně užívané agilní metodiky jsou dostačující náhradou za rigorózní přístupy k vývoji ukáže až čas. Podrobnější popis historie vývoje softwaru uvádí (Wikipedia, 2016). 2.2 Vodopádový model Jméno vodopádový model dostal tento model, protože posloupnost jeho jednotlivých fází připomíná vodopád. V tomto modelu je pořadí všech vývojových fází jednoznačně definováno. I přesto, že má tento model celou řadů nedostatků stal se hlavní předlohou pro vznik mnohem efektivnějších modelů životních cyklů. Každý projekt, který se řídí vodopádovým modelem prochází postupně uspořádanými vývojovými fázemi. V úvodní fázi se specifikují všechny požadavky, tak přesně, jak je to jen možné a každý projekt je ukončen fází zavedení a údržba. Všechny fáze vodopádového modelu mají předem určená kritéria jenž musí být v dané fázi splněna a také meziprodukt, kterého by se mělo dosáhnout na konci každé z těchto fází. Tento model je založen na vývoji, který se anglicky nazývá document driven, z čehož vyplývá, že hlavními produkty tohoto modelu jsou dokumenty, které jsou přenášeny mezi jednotlivými fázemi. Každá z fází může začít pouze tehdy, když jsou splněny všechny stanovené kritéria fáze předchozí a v případě, že se vyskytnou nějaké nedostatky je možné se vrátit pouze do předchozí fáze. Návrat např. o dvě fáze zpět v tomto modelu není možné. 12

13 Obr. 2 Vodopádový model (zdroj: autor) S vodopádovým modelem je možné dosáhnout velmi dobrých výsledků, ale to jen v případě, že zákazník dopředu přesně a pevně stanoví úplně všechny požadavky na výsledný softwarový produkt. Potom je pro vývojáře možné detekovat případné chyby již v raném stádiu projektu. Velkou nevýhodou tohoto modelu je to, že zákazník v průběhu vývoje nemůže provádět změny, nebo pokud je to vůbec možné, je realizace změn velice náročná. Tato nevýhoda je způsobená tím, že zákazník nevidí výsledky jednotlivých fází v podobě softwaru a to až do předposlední fáze životního cyklu, tedy fáze testování. Případné připomínky nebo požadavky na změny může zákazník předložit až ke konci životního cyklu vývoje. Přesnější popis vodopádového modelu je možné nalézt na (Maxwideman, 2012) 2.3 Agilní metodiky V anglickém jazyce se agilní metodiky nazývají agile methodologies. Toto slovní spojení bychom mohli přeložit do českého jazyka jako živé nebo pružné metodiky. Před tímto slovním spojením se využíval pojem light-weight neboli lehké metodiky. Tento pojem měl zdůraznit jednoduchost metodik a to hlavně z pohledu produktových dokumentací, avšak dal 13

14 se vyložit vícero významy a proto se od jeho užívání nakonec upustilo. Český překlad živé nebo pružné metodiky výstižně vystihují hlavní cíle agilních metodik. Vývoj softwaru by měl být rychlý tak, aby byl výsledný produkt dodán zákazníkovi v co nejkratším možném čase, zároveň by měl být i lehký, omezit se pouze na nejdůležitější činnosti a vytvářet pouze nejnutnější dokumentaci. Zároveň by měl být vývoj softwaru pružný tak, aby mohl reagovat na požadavky ze strany zákazníka a živý, tím se rozumí, že výsledný software by měl být úspěšně předán a tím zajistit přežití celého projektu. Za dobu užívání agilních metodik se ukázalo, že softwarové projekty, které jsou vyvíjeny tradičními přístupy selhávají mnohem častěji než ty, které byly vyvíjené přístupem agilním. Hlavní příčinou těchto selhání je fakt, že většina rigorózních metodik je závislá na přesném, detailním a uceleném popisu všech požadavků ze strany zákazníka a to již na úvodní schůzce před zahájením vývoje. Další příčinou selhání těchto metodik je, že zákazník nemůže dělat jakékoliv změny nebo úpravy svých požadavků v průběhu vývoje. Vývojový tým, který pro vývoj softwaru využil například vodopádového modelu životního cyklu, nemusí mít žádné potíže v průběhu vývoje, ale může narazit na problém až ve fázi představení. Během prezentace hotového softwaru zjistí, že výsledky jejich práce se vůbec neshodují s představami zákazníka a ten nyní nechce výsledný software odebrat. V tu chvíli se musí celý projekt vrátit opět na začátek. Jenomže vývojový tým už vyčerpal značnou část ze svého finančního rozpočtu a mohou i nastat obavy, že je zákazník nebude dále považovat za profesionály nebo hůř, že zákazník ztratí důvěru v jejich schopnosti, zruší s vývojovým týmem smluvní vztah a přejde ke konkurenci. Osvědčené zásady a principy, které se využívaly v raných dobách softwarového inženýrství postupem času ztrácely svou efektivitu a v dnešní době se na ně již nedá tolik spolehnout. Zejména se již nedá spolehnout na předpoklad, že je zákazník schopen přesně definovat všechny požadavky na software hned v úvodní fázi projektu, tedy při analyzování systému. Samozřejmě šlo z těchto předpokladů vycházet v době, kdy se software vyvíjel pouze pro konkrétního uživatele nebo pro určitou platformu. Ale v dnešní dynamicky se vyvíjecí ekonomice, která neustále vyžaduje použití novějších technologií vyvolaných poptávkou trhu se zákonitě musí měnit i požadavky, které jsou kladeny na vyvíjený software. A aby bylo možné plnit tyto požadavky je nutné změnit i samotný způsob jakým jsou vedeny softwarové projekty. Obzvlášť v dnešní době, kdy internet využívá už téměř každý a webové aplikace se musí neustále rozšiřovat a vylepšovat, je rychlost, kterou je schopen vývojový tým pracovat 14

15 tou nejdůležitější vlastností. V těchto případech už není možné prodlužovat dobu vymezenou na vývoj softwaru plněním všech možných předpisů, které jsou vyžadovány rigorózními metodikami. Hlavním důvodem zkracování doby vymezené na vývoj softwaru je konkurenční boj mezi jednotlivými vývojáři, kteří se předhánějí ve vývoji nových služeb, proto aby získali nové zákazníky nebo aby od konkurence přetáhli zákazníky k sobě. V případě, že vznikne potřeba vyvinout např. novou webovou aplikaci nebo softwarový projekt většího rozsahu v co nejkratším možném čase a přitom hledět i na přání a připomínky ze strany zákazníka, jsou pro vývojové týmy agilní metodiky tím správným směrem. Ovšem na druhou stranu u projektů, které mají jasný plán i architekturu nebo nevhodně složený tým není výhradně nutné nebo kolikrát i vhodné využít ucelené agilní metodiky. Ale je spíše lepší do metodiky s tradičním přístupem začlenit některou z agilních technik. Velkou výhodou agilních metodik je, že pomohli zefektivnit způsob jakým jsou vývojové týmy motivovány. Díky tomu, že je vývoj rozdělen do více přírůstků mohou vývojáři častěji vidět plody své práce a vidět tak, že se postupně blíží k cíly. Tím se ve vývojovém týmu zvýší morálka a vývojáři se spíše nadchnou pro daný projekt. Blíže metodiky popisuje (Kadlec, 2004). Základními principy agilních metodik, které napomáhají zlepšení kritérií uvedených výše, respektive k lepšímu přizpůsobení způsobu jakým je software vyvíjen, jsou podle (Kadlec, 2004) tyto: - Vývoj po částech s krátkými iteracemi: Každý projekt se dělí do několika částí (inkrementů), tyto části jsou na sobě navzájem nezávislé a jsou tak i vyvíjeny. V rámci každého inkrementu probíhá vývoj iterativně, což znamená, že všechny fáze vývoje jsou prováděny opakovaně a plán se sestavuje pro častější dodávky nových funkcí. Takto může zákazník průběžně sledovat postup jakým se ubírá vývoj jeho projektu a minimalizuje se tak možnost, že na konci bude zákazníkovi předvedeno něco úplně jiného než chtěl. - Vzájemná komunikace vývojového týmu se zákazníkem: Je velmi důležité do vývojového procesu začlenit pravidelné schůzky se zákazníkem. Ten se tak stává součástí vývojového týmu a může tak pravidelně definovat a upravovat své požadavky, podílí se na vytváření návrhu a může i spolurozhodovat o testování. 15

16 - Průběžné ověřování správnosti aplikace: Z důvodu častých změn v průběhu celého projektu je nutné k zachování kvality, průběžného ověřování správnosti aplikace. Toto ověření se provádí za pomoci automatizovaných testů, které jsou definované ještě před implementací dané části. Z výše uvedeného textu je možné sestavit základní seznam výhod a nevýhod agilních metodik. Výhodami jsou inkrementální a iterativní vývoj softwaru, poměrně rané dodání prvního funkčního prototypu, vyzdvihnutí významu vzájemné komunikace mezi zákazníkem a vývojovým týmem, dále průběžné testování softwaru, adekvátní reakce na změny ze strany zákazníka, optimalizace metodik. Mezi nevýhody agilních metodik patří to, že omezují dokumentace, nemohou zaručit výsledný rozsah verze, nelze u nich formalizovat smlouvy, testování je prováděno přímo autorem softwaru, tyto metodiky nelze využít pouze na částečný úvazek a vyžadují, aby byl vývojový tým složen z velmi schopných lidí. 2.4 Rozdíly mezi agilní technikou a metodikou Tato podkapitola má za úkol čtenáři ukázat hlavní rozdíly mezi agilní technikou a agilní metodikou neboť se tyto dva pojmy neustále zaměňují. Agilní metodika popisuje způsob rozvržení práce nebo úkolu tak, aby se dosáhlo cíle co nejefektivnějším způsobem. Agilní technika oproti tomu popisuje konkrétní postup, kterým by se mělo dosáhnout požadovaného výsledku. Agilní technika může například stanovit způsob jakým budou využívané nástroje. Dalším rozdílem je to, že agilní technika je oddělitelná od agilní metodiky. Jak již bylo řečeno je možné software vyvíjet nejrůznějšími způsoby. Od tradičního přístupu, kdy se například u vodopádového modelu řídí vývoj od analýzy k návrhu, k beta verzím až po finální produkt. Až po agilní metodiky kde je nutné, aby manažer vzájemně koordinoval tým analytiků, vývojářů a testerů a zároveň bral i v potaz požadavky zákazníka, přitom všem kontrolovat a zvyšovat produktivitu svých pracovníků a dbát na to, aby se nesnižovala kvalita. Následující část se zaměří na agilní metodiky a na jejich vliv na produktivitu týmu a zároveň bude blíže popsán rozdíl mezi agilní technikou a metodikou. 16

17 Pod pojmem agilní technika rozumíme definování konkrétního postupu, kterého se potom vývojáři při vývoji softwaru drží. Tento postup se definuje hlavně z důvodu zlepšení produktivity vývojového týmu, zvýšení kvality dodávaného softwaru, opravě chyb vzniklých při návrhu nebo aby vývojáři dokázali přesněji plnit specifikace zákazníka. Jak již bylo řečeno agilní techniky je možné od metodik oddělit a použít je pro zvýšení kvality dodávaného zakázkového produktu. Oproti tomu agilní metodikou rozumíme způsob jakým je rozvržena práce vývojového týmu a také způsob jakým se ověřují výsledky jeho práce. Zavedením agilní metodiky se tedy snažíme docílit co nejlepšího řízení práce. Každou agilní metodikou se dosáhne jiného produktu a to z toho důvodu, že každá považuje za klíčový jiný aspekt produktu. Odlišný je u metodik i způsob jakým přistupují ke změnám v zadání. Umožnit změnu v zadání je ovšem zásadní podmínkou. Agilní metodiky podporují vývoj softwaru spolu s adekvátními reakcemi na změny v zadání projektů a tak přinášejí užitek a konkurenceschopnost ve stále se měnící ekonomice. Dalším rozdílem mezi agilní technikou a metodikou je ten, že se metodika specializuje na organizaci práce a nezáleží na tom čím se firma zabývá, nemusí tedy jít pouze o vývoj softwaru, ale může se využít i pro jiné oblasti. Podstatou agilní metodiky je umožnění změn v návrhu avšak agilní technika žádnou takovou podmínku nemá. Agilní metodika se nezaměřuje pouze na vývojáře, ale zahrnuje i management. Tyto techniky popisují konkrétní činností, které se zaměřují především na vývojáře, ale mohou zahrnovat i zákazníka. Podkladem pro vznik agilních metodik i technik se stal manifest o agilním programování neboli The Agile Manifesto. Manifest o agilním programování sestavila skupina velice zkušených vývojářů, kteří do té doby vyvíjeli software za pomoci tradičních přístupů. Díky svým poznatkům z praxe si začali uvědomovat jaké má tradiční přístup k vývoji nedostatky a každý si začal individuálně sestavovat podněty pro novou metodiku. Postupy uvedené v tomto manifestu se snaží zredukovat problémy, které vznikají v průběhu vývoje. Vývojový tým, který se rozhodne řídit těmito postupy by měl zaznamenat, že se sníží objem práce pro managera a současně se i zvýší výkon týmu. Pro jednoho manažera je nyní snazší koordinovat práci ve větších vývojových týmech, řešit projekty většího rozsahu nebo se lépe zaměřit na otázky zvýšení kvality produktu. To je dáno povahou sebeřízení manažera, 17

18 omezením jeho pravomocí a snížením počtu dokumentací, které se musí vypracovat. Díky časovým odhadům nejkratších úkolů lze řídit rychlost týmů, ty zároveň z předchozích zakázek vědí, jaká je jejich rychlost v rámci jedné iterace a mohou tak dopředu určit kolik budou schopni v rámci jedné iterace vykonat práce. Samozřejmostí je podpora změn v zadání v celém průběh vývoje a i přesto se urychlí doručení výsledného produktu zákazníkovi. Vývojáři mohou zákazníkovi také garantovat kvalitu výsledného produktu, kterou neustále ověřují za pomoci automatizovaných testů. Zároveň agilní metodiky omezují nepružné procesy, ne že by je úplně vyloučily z vývoje, ale pouze omezí ty, které by jinak bránily efektivnímu vývoji, lepší komunikaci, nebo bránily agilnímu přístupu. Blíže rozdíly mezi metodikami popisuje (Řepa, 1999). 2.5 Manifest agilního vývoje softwaru Od doby, kdy vznikl Manifest agilního vývoje softwaru uplynulo už 15 let. Tento manifest v únoru roku 2001 sepsala skupina sedmnácti velmi zkušených odborníků z oblasti softwarového inženýrství, kteří v té době vyvíjeli i za pomoci light-weight metodik. Mezi nejznámější vývojáře z této skupiny patří Alistair Cockburn, Mike Beedle, Ken Schwaber, Kent Beck, Heft Sutherlan, Ward Cuningham nebo Martin Fower. Důvodem k sepsání manifestu byly stále více se projevující nedostatky tradičních přístupů k vývoji. Tato skupinka vývojářů na základě svých zkušeností z praxe sestavila základní principy, podle kterých by se měl agilní vývoj softwaru řídit a tak dala naději všem softwarovým inženýrům na efektivnější vývoj. Zároveň spolu s těmito principy i založili Alianci pro agilní vývoj (Agilemanifesto, 2007). Celý manifest je vybudovaný na dvou základních pilířích, těmi jsou: - Je víc efektivní zákazníkovi umožnit změnu v zadání, než vynakládat úsilí na zabránění této změny. - Je velmi důležité adekvátně přistupovat k řešení nepředvídatelných událostí, neboť ty se při vývoji projektu objeví skoro vždy. 18

19 Na základě těchto dvou pilířů se u agilního vývoje dává předost zejména: - Osobitosti v řešení a interakci se zákazníkem před samotnými procesy a nástroji. - Předání funkčního softwaru před tvorbou rozsáhlých dokumentací. - Prohloubení spolupráce se zákazníkem před sáhodlouhým vyjednáváním smluv. - Adekvátní reakci na vzniklou změnu před správným plnění domluveného plánu. V další části bude stručně popsáno dvanáct základních principů, kterých by se měl držet agilní vývoj, tak jak je definuje (Agilemanifesto, 2007). 1. Nejvyšší prioritu by mělo mít uspokojování zákazníka z hlediska včasných dodávek softwaru, neboť právě to oproti ER-modelům a UML diagramům přináší zákazníkovi největší hodnotu. 2. Je důležité umožnit zákazníkům provádět změny ve svých požadavcích i v posledních fázích vývoje projektu, protože právě tyto změny mohou zákazníkům přinést největší výhodu proti konkurenci. Z tohoto důvodu se u agilních metodik nedělá nic, co není bezprostředně nutné, neboť je velmi pravděpodobné, že nastanou změny, které mohou vše změnit. 3. Důležité je i často zákazníkovi dodávat software, v intervalech, které mohou být dlouhé dva týdny až dva měsíce. Přesto, že je iterativní vývoj podporovaný i celou řadou tradičních přístupů k vývoji je u agilních metodik více zdůrazněn význam krátkých iterací a zkrácení dodávek. 4. Vývojáři se společně se zákazníky denně podílí na řešení projektu. Na rozdíl od tradičních přístupů vycházejí ty agilní z toho, že není možné v úvodní fázi projektu definovat úplně všechny požadavky a ty potom v průběhu celého vývoje ani jednou nezměnit. Raději tedy v úvodní fázi definují jen základní požadavky, díky kterým je možné navrhnout architekturu, ale přitom berou na zřetel, že i tyto požadavky se mohou v průběhu vývoje změnit. Aby však bylo možné na základě těchto základních požadavků vytvořit návrh je bezprostředně nutná spolupráce se zákazníkem. 19

20 5. Zásadním faktorem pro úspěch projektu je dobře motivovaný tým, podporovaný svým vedením, kterému se musí vytvořit i dobré pracovní podmínky. O tom zdali je projekt úspěšný rozhodují vždy lidé, kteří považují za nedůležitější důvěru ve vlastní schopnosti. Zároveň i rozhodování musí být prováděno pozitivně motivovanými a kompetentními osobami. 6. Nejefektivnějším a nejvýkonnějším způsobem jak předávat informace uvnitř vývojového týmu je vzájemná komunikace mezi vývojáři a zákazníkem. Podle agilních přístupů jsou obecně dokumentace nástrojem na porozumění konkrétního problému, avšak je mnohem snazší problému porozumět, když se o něm bude hovořit, než když se bude obšírně popisovat a číst z obsáhlých zpráv. 7. Funkční software je základní jednotkou úspěchu, ale i postupu při vývoji. Splnění specifikace nemusí zákonitě znamenat i úspěch projektu, stále totiž mohou nastat problémy například při integraci softwaru. 8. Přílišné přetěžování vývojového týmu přesčasy nebo prací po nocích není z dlouhodobého hlediska výhodné. I přesto, že lze touto cestou krátkodobě snížit zpoždění v odevzdání softwaru, vede toto řešení převážně ke snížení produktivity týmu. 9. Neustále se musí věnovat pozornost dokonalému návrhu a technickým řešením. U agilních přístupů je zdůrazněna důležitost kvalitního návrhu, změna v návrhu však není vnímána tak, že by byl stávající návrh málo kvalitní. Základní charakteristikou agilního vývoje je to, že změny přicházejí i tehdy, když už je napsaný zdrojový kód. Z toho vyplývá, že je nutné na základě těchto změn upravit i návrh a tyto úpravy potom zanést i do zdrojového kódu. Návrh netvoří samostatnou fázi, která by byla dokončena před spuštěním implementace, ale jedná se o souvislou denně opakující se činnost, která zasahuje do všech etap projektu. Zákazníci si často myslí, že se návrh zanedbává nebo se dokonce vůbec neřeší, opak je však pravdou a programátoři se návrhem zabývají v denních intervalech. 10. Velice důležitá je jednoduchost, v tomto případě tím rozumíme schopnost minimalizovat objem neodvedené práce. Agilní procesy upřednostňují jednoduchý postup před komplexním neboť ten lze změnit mnohem snáze. Vždy je lehčí jednoduchý 20

21 proces něčím rozšířit, než o něco zredukovat proces komplikovaný. Jednotlivá řešení by se měla zabývat jen tím, co bude pro každého prokazatelným přínosem a nerozvádět věci, které by se mohli v budoucnu někomu hodit. 11. Výstupem kreativních týmů jsou dobré návrhy, abychom však dosáhly dobrých návrhů je nutné tuto kreativitu podpořit vzájemnou důvěrou, opakovanou komunikací a přitom i příliš nezatěžovat vývojový tým. 12. Aby bylo možné pracovat s větší efektivitou, je nutné, aby se vývojový tým otázkou efektivity zabýval v pravidelných intervalech. Je to z toho důvodu, že agilní metodiky nelze předem definovat, neboť se neustále přizpůsobují, vyvíjí a odráží samy sebe. 21

22 3. Příklady agilních metodik Na základních principech Manifestu agilního programování byla vytvořena již celá řada metodik a jejich počet se dál rozrůstá. Pro větší přehled již existujících metodik budou v této kapitole popsány nejvýznamnější zástupci, se kterými je možné přijít do styku. 3.1 Extrémní programování (Extreme programming, XP) Extreme programming do českého jazyka překládáme jako extrémní programování a jedná se o jednu z nejznámějších metodik vůbec. Podrobné informace o této metodice lze nalézt například v knize Extrémní programování (Beck, 2002). Autory extrémního programování jsou Kent Beck a Ward Cunningham, kteří ho vyvíjeli v průběhu devadesátých let 20. století na základě svých zkušeností převzatých z praxe. Je založené na dobře známých a běžně se vyskytujících postupech, ale rozvádí je až do extrémů. V případě, kdy se vyplatí využít revizi, se stále do kolečka reviduje a vznikne-li potřeba testovat, probíhá testování i několikrát za den. Na základě postupů a principů extrémního programování se do extrému přivedou všechny fáze vývoje: - Přezkoušení zdrojového kódu - Otestování aplikací - Navrhnutí architektury - Integrování systému - Vývoj pomocí iterací Zároveň se však XP snaží co nejvíce snižovat rizika jsou zpoždění se v plánovaném rozvrhu, možného vzniku krachujícího systému, zvýšeného výskytu poruch, nepochopeného zadání ze strany vývojářů, průběžných změn v zadání, nadměrné množství funkcí nebo kolísání výkonu vývojového týmu. Celý vývoj softwaru je u extrémního programování založen na napsání kódu a jeho následném otestování. Skrze zdrojový kód spolu navzájem komunikují jednotlivý členové vývojového týmu a z výsledků testů je možné zjistit aktuální stav projektu. Tato metodika je založená na příkladu vývoje, na který by byl dostatek času. U takového vývoje by 22

23 vývojáři měli dostatek času na zpracování dobře strukturovaného kódu a zároveň by zbýval čas i na pořádné otestování. U metodiky XP se tyto dva kroky navzájem prolínají. V průběhu dne programátoři nejdříve otestují určitou funkci softwaru a potom zároveň ověří možnost její implementace. V případě, že testy vyjdou s pozitivním výsledkem, přechází vývojáři na další funkci. Vývoj softwaru pomocí řízených testů se nazývá Test Driven Development a jedná se o metodiku, která je zcela nezávislá na metodice XP, blíže tuto metodiku ve své knize Programování řízené testy popisuje (Beck, 2004). Extrémní programování definuje činnost naslouchání. Tato činnost je velice důležitou a pan Beck je toho názoru, že nejlepší způsob jak sdílet informace je právě skrze rozhovor. Z tohoto důvodu je XP vyvinuto tak, aby komunikace mezi vývojovým týmem a zákazníkem nebo mezi vývojáři navzájem byla co nejvíce podporována a dokonce i vynucována. Tvorba návrhu je poslední důležitou činností XP. Vytváření návrhu je každodenní činností a zabývají se jí každý programátor ve vývojovém týmu. Jak již bylo zmíněno je u této metodiky kladen důraz hlavně na zdrojový kód a proto programátoři, pokud to neuznají za vhodné, nemusí kreslit diagramy. Při navrhovaní systému se nejprve sepíšou testy, v této fázi je důležité dobře promyslet aplikační rozhraní, protože právě to se bude testovat. Dále se potom programátoři zabývají navrhováním ve fázi tzv. refaktorizace, což znamená, že mění zdrojový kód, ale přitom se snaží, aby byla stále zachována jeho funkčnost. Při vývoji usilují programátoři o navrhnutí co nejjednoduššího, funkčního systému, který je schopný zákazníkovy přinést vytoužený užitek. K řízení vývoje využívá extrémní programování čtveřici proměnných, kterými jsou výše nákladů, úroveň kvality, rozsah zadání a čas na vypracování. Vedoucí vývojového týmu nebo sami zákazníci určí hodnoty u tří jimi vybraných proměnných a vývojový tým potom stanoví jaká hodnota odpovídá zbylé proměnné. Vše je založené na jednoduché úvaze. Když je například vývojový tým složený z malého počtu lidí a má navíc vykonat spoustu práce v krátkém časovém intervalu, je na tento tým vyvíjený velký nátlak a s největší pravděpodobností nepřinese výsledky potřebné kvality. Stres způsobený tímto nátlakem v kombinaci s nereálnými požadavky ze strany vedoucích nebo zákazníků často vede ke zpoždění projektu a tím i ke zvýšení nákladů na vývoj. Z tohoto důvodu není možné vývojovému týmu prostě předepsat všechny čtyři řídící proměnné, ale je důležité dát mu právo stanovit hodnotu zbylé proměnné. V případě, že se vedoucím nelíbí hodnota zbylé 23

24 proměnné, kterou jim přednesl vývojový tým, mohou stanovit hodnoty jiných tří proměnných, nemohou však nikdy stanovit hodnoty pro všechny čtyři proměnné. Podle XP je nejlepší zvolit jako volnou proměnou rozsah zadání. 3.2 Crystal metodiky Za zrodem Crystal metodik stál Alistair Cockburn a nejedná se pouze o jednu metodiku, nýbrž o celou řadu metodik. Každá metodika je pojmenována podle barvy a každá z těchto metodik je vhodná pro odlišně velké vývojové týmy a pro projekty různých rozsahů. Barvami se označuje robustnost metodiky a tedy její použitelnost na větší nebo kritičtější projekty. Obecně můžeme říct, že čím tmavší odstín barvy metodika má, tím je robustnější. Nejméně robustní je čirá metodika a nejvíce robustní metodika je fialová. Crystal metodiky neposkytují přesné návody, ale spíše rady, pomocí nichž je možné si metodiky upravit pro vlastní potřeby. Výběr vhodné metodiky se provádí za pomoci tří základních projektových vlastností. První z nich je velikost týmu a definuje kolik lidí se bude podílet na vývoji softwaru. Druhá vlastnost se zabývá vymezením kritičnosti projektu a odhaduje jaký by byl dopad v případě, že systém selže. Tato vlastnost může nabýt celkem čtyř hodnot označených písmeny C, D, E a L. Písmenem C je označován nejmenší dopad, v tomto případě mohou uživatelé za zvýšeného úsilí nadále využívat systém. Písmeno D potom označuje větší dopad, kdy už firmě kvůli selhání vznikne malá finanční ztráta. Podobně je definované i písmeno E, ale zde už firmě vzniká velká finanční ztráta. Nejhorší možný dopad označuje písmeno L a zde se už jedná o ztrátu na lidských životech. Třetí a tedy poslední vlastnost, která napomáhá výběru metodiky se nazývá priorita projektu. Touto vlastností se zohledňuje jaký aspekt projektu je ten nejdůležitější. Na základě toho lze potom učinit rozhodnutí zdali bude projekt optimalizován na co největší produktivitu nebo se například upřednostní měření postupu projektu. Jak vypadá volba vhodné Crystal metodiky je možné vidět na následujícím obrázku. Pro oblasti označené čtverečky není zatím vytvořená žádná Crystal metodika nebo jich nelze dosáhnout. 24

25 Obr. 3 Volba odpovídající Crystal metodiky (ABRAHAMSSON, 2002), vlastní úprava Na obrázku je možné vidět jednotlivé barevné označení metodik, které jsou navíc podle velikosti týmu a kritičnosti rozdělené do jednotlivých oblastí. Například oblast D6 označuje metodiku, která má čirou barvu a je určená pro vývojový tým, který je složený ze dvou až osmi lidí a při selhání vznikne firmě pouze malá finanční ztráta. Více informací o těchto metodikách je možné nalézt v (ABRAHAMSSON, 2002). 3.3 Metodika Agile Unified Process (AUP) Největší rozdíl u AUP metodiky oproti její formálnější sestře RUP metodice je ve fázi správy požadavků, kde došlo ke sloučení fází analýzy a návrhu systému do jedné fáze, která je zde nazývána jako tvorba modelu. Činnost, která se zabývala vytvářením modelů nebyla z metodiky odstraněna, ale pouze zredukována tak, aby zachycovala pouze ty nejnutnější prvky. Tato metodika využívá řadu agilních technik založených na agilním modelování, databázové refaktorizaci nebo TDD. AUP tvoří kompromis mezi metodikou RUP a ostatními agilními metodikami, například metodika RUP nabízí celou řadu artefaktů, které se vývojářům nemusí vůbec hodit a na druhé straně metodika XP ani přesně neuvádí jak artefakty vytvořit. Více informací poskytuje (Ambysoft, 2014) 25

26 3.4 Metodika Open Unified Process (OpenUP) Metodika OpenUp se řadí mezi ty novější a je také postavena na inkrementálním a iterativním přístupu k vývoji. Základem této metodiky je definování tří základních vrstev, kterými jsou Project Lifecycle, Iteration Lifecycle a Micro-Increment. Project Lifecycle popisuje životní cyklus celého projektu, zde je nejdůležitějším úkolem vytvořit projektový plán. U této vrstvy se důraz klade zejména na komunikaci s klientem a obvykle tento cyklus trvá několik měsíců. Druhá vrstva se nazývá Iteration Lifecycle a popisuje jak vypadá životní cyklus pouze jedné iterace. Tato iterace má za úkol dodat zákazníkovi funkční prototyp softwaru, který pro něj představuje užitnou hodnotu. Oproti vrstvě životního cyklu projektu je největší důraz kladen na komunikaci uvnitř vývojového týmu a délka jedné iterace je omezena na několik týdnů. V poslední vrstvě nazývané jako Micro-Increment se vývojáři zabývají jednotlivými úkoly, které jim byli přiřazeny a doba, za kterou tyto úkoly musí splnit je omezena pouze na pár hodin. Bližší popis metodiky lze nalézt na (Bawiki, 2014) 3.5 Agilní modelování Agilní modelování není metodikou v klasickém smyslu slova, ale je to spíš způsob jakým přistupovat k vývoji. Hlavním úkolem toho modelování je za pomoci různých modelů je vytvořit seznam těch nejdůležitějších požadavků na systém a přitom vývojáře nezatěžovat zbytečnostmi. Důležitou podmínkou agilního modelování je to, že do modelace systému je zapojený i uživatel, který je tak schopen poskytnout rychlejší zpětnou vazbu. Většina principů této metodiky byla převzata z metodiky Extrémního programování. Největší nevýhodou agilního modelování je fakt, že nelze využít jeho praktiky pro práci ve velkých týmech. Více informací týkajících se agilního modelování lze nalézt na (Agilemodeling, ). 26

27 3.6 Metodika Scrum Za zrodem Scrum metodiky stály vývojáři Mike Beedle, Ken Schwaber a Heft Sutherland. Na rozdíl od rigorózních metodik, které předpokládají, že je vývoj softwaru přesně definovaným procesem se tento přístup k vývoji zakládá na myšlence, že se jedná o proces empirický a z toho vyplývá, že je nutné použít úplně jiný styl řízení vývoje. Při výběru názvu se autoři nechali inspirovat skrumáží v rugby, chtěli tak zdůraznit podobnost metodiky s touto hrou, neboť v obou případech se jedná o rychlou, adaptivní a samoorganuzjící se záležitost. Tato metodika se zaměřuje zejména na správné řízení projektu. Vývoj softwaru je rozdělený do iterací, které se nazývají Sprinty a trvají maximálně třicet dní. Na konci každého sprintu je zákazníkovi dodán meziprodukt s vybranou užitnou hodnotou. Klíčovým prvkem této metodiky je využívání patnácti minutových porad, tzv. Scrum meetingů, které se provádí každý den a slouží zejména pro co nejlepší sladění prací. Scrum rozděluje životní cyklus vývoje do 4 fází, těmi jsou: - Vývoj pomocí iterací: Metodika Scrum rozděluje vývoj do krátkých iterací nazývaných sprinty. Na začátku každého sprintu se stanovují cíle, na splnění těchto cílů má potom vývojový tým přibližně 14 dní, maximálně však 30. Výsledkem každého sprintu je funkční aplikace, která je předvedena zákazníkovi. Po ukončení sprintu se vyhodnocuje jak byl úspěšný a stanovují se cíle pro sprint další. Silnou stránkou této metodiky je možnost měnit plány, popřípadě upravit cíle, tak aby lépe vyhovovali současnému postupu na konci každého sprintu. Jak již bylo zmíněno, na konci každého sprintu je možné zákazníkovi předat pracující aplikaci a tak je v podstatě možné po každém sprintu ukončit vývoj. - Zapojení zákazníka do vývoje: V metodice Scrum je zákazník v podstatě součástí vývojového týmu. Po ukončení jednotlivých sprintů vývojáři zákazníkovi vždy předvádějí současný stav vyvíjeného softwaru a zaměřují se hlavně na nové prvky. V tento moment se může zákazník, pokud má k něčemu výhrady nebo by chtěl něco upravit, vložit do vývoje. Tímto způsobem získává vývojový tým potřebnou zpětnou vazbu a může tak adekvátně přizpůsobit vývoj potřebám zákazníka. 27

28 - Plánování na krátkou vzdálenost: Plánování je velice důležitým procesem i přes fakt, že drtivá většina plánů na počátku správně neodráží realitu. Scrum bere v potaz to, že v průběhu vývoje se zákazník i vývojový tým naučí novým věcem a jejich vnímání dané problematiky se může také vyvíjet a měnit. Z tohoto důvodu se upřednostňuje krátkodobé plánování, které umožní častější úpravy plánu a tím se více přibližovat realitě. - Zpětnovazební vyhodnocování: U metodiky Scrum se při vývoji provádí velká spousta testů. Vypracovávají se scénáře pro testování, testuje se použitelnost a testy se automatizují. Navíc je do vývoje zapojený i zákazník, který tak má bližší kontakt s vyvíjenou aplikací a může tak častěji regulovat průběh vývoje. Takto se dosáhne lepší reakce na problémy, které nejsou úplně vymezené nebo specifikované a mohly by tak být těžko odstranitelné. Pro úvodní a závěrečnou fází jsou přesně formulované procesy s danými vstupy a výstupy, včetně způsobu jak přetransformovat vstup na výstup. Tyto procesy se provádějí lineárně. Oproti tomu sprint, zastupující fázi vývoje je vnímán jako proces empirický a z toho důvodu jej nemůžeme jednoznačně určit nebo řídit. Sprint představuje v podstatě černou skříňku, kterou je nutné řídit z vnějšku a zároveň se i řídí prostými pravidly. Jedním z pravidel je, že jsou všem členům vývojového týmu přiděleny určité úkoly a ty se potom vývojáři snaží intenzivně splnit v intervalu dlouhém maximálně 30 dní. Dalším pravidlem je, že v průběhu vývoje se každý den musí vývojáři účastnit informačních porad, kde se probírají možnosti řešení problémů a díky kterým je možné sledovat aktuální průběh projektu a lze se tak lépe zaměřit na nedostatky, které ohrožují zdárné dokončení projektu. Ideálně by tyto porady měly probíhat na jednom místě, vždy ve stejnou dobu a měly by být dlouhé přibližně 15 minut, lze je samozřejmě podle potřeby i prodloužit, ale z důvodu zachování efektivity by neměli přesáhnout dobu třiceti minut. Porady jsou řízeny tak zvaným Scrum masterem a účastnit by se jich měli úplně všichni vývojáři v týmu, včetně manažerů. Hlavním důvodem těchto porad je výměna informací a poznatků získaných při vývoji a v průběhu porady jsou jednotlivým účastníkům kladeny 3 otázky: - Co se dokončilo od poslední schůzky? - Co se má nyní splnit? - Co může představovat problém v plnění nových zadání? 28

29 Scrum je projektová metodika a zaměřuje se zejména na způsob jakým je možné projekt řídit. Jak již bylo řečeno je proces vývoje softwaru chápán v této metodice jako empirický a z tohoto důvodu neexistuje možnost jak předpovědět jeho průběh. I přes skutečnost, že průběh vývoje není možné předpovědět, je velice důležité tento průběh alespoň monitorovat. Za tímto účelem je v metodice obsaženo několik praktik jako je monitorování iterací pomocí tzv. backlogů, sdílení informací v průběhu denních porad atd. Blíže tuto metodiku popisuje (Knesl, 2009). 3.7 Metodika Kanban Slovo kanban pochází z japonského jazyka a do češtiny bychom toto slovo mohli přeložit jako štítek nebo karta. Hlavní idea celého systému je postavena na využití zásad pro organizování procesů v amerických supermarketech a převedení těchto zásad do výroby. Celý cyklus začne v momentě, kdy si zákazník z police v obchodě vybere nějaké zboží, po výběru zboží potom přechází k pokladě, kde je z něho odejmuta dopravní karta. Tato karta se potom uloží do skříňky, které se někdy říká také kanban pošta. Všechny dopravní karty uložené v této schránce se potom odešlou do skladu, kde se podle nich vyskladní zboží potřebné k opětovnému doplnění regálů. Po ukončení vyskladnění se dopravní karty vymění za výrobní, ty byly předtím umístěné na naskladněném zboží. Výrobní karty se také ukládají, ale zase do jiné schránky. V tomto momentu se zboží s dopravními kartami převáží do supermarketu, kde je ukládáno na patřičné pozice v regálech. Výrobní karty putují zpátky do výroby, kde se na jejich základě určí potřebné množství výrobků, které je nutné znovu vyrobit. Jakmile se toto množství vyrobí, umístí se na nové výrobky výrobní karty a převezou se na sklad supermarketu. Tím je celý cyklus uzavřen. Tento systém řízení se snaží co nejvíce přizpůsobit celý průběh výroby pomocí materiálového toku. Základním principem Kanban systému je podpora výroby na zakázku a to na všech stupních výroby. Výrobou na zakázku by se mělo docílit snížení objemu potřebných zásob, které by se jinak museli držet ve skladu, tím i snížení nákladů spojených se zásobením. Zároveň však zakázková výroba napomáhá i k přesnějšímu plnění stanovených termínů. Ovšem aby byly tyto cíle splněny, je nutné již při návrhu výrobních předpokladů správné 29

30 vyvážení výrobních kapacit (např. zajistit pravidelné odběry a tak i pravidelnou výrobu). Vyvážení výroby by se mělo provést v průběhu závěrečné montáže. Metodikou kanban se docílí opětovné navrácení řízení zpět do míst, kde probíhá výroba. Je tak možné efektivně řídit výdej materiálu a plnění úkolů spojených s výrobou na základě aktuálních požadavků zákazníka. Odpadá tak nutnost centrálního řízení a plánování, neboť se vyrábí a dodávají pouze vyžádané výrobky. Za zákazníka jsou považovány všechny následné procesy. V tomto systému je proces řízení výroby podružný závěrečné montáži, která je odpovědná za přímé reakce na požadavky ze strany zákazníků. Nejlepší je využít Kanban pro výrobu, kde je jisté, že si zákazník postupně odebere velké množství výrobků stejného provedení. Pokud však tuto jistotu nemáme je nutné tento systém doplnit o plánovací systém, který např. určí kapacitu regulačního okruhu. Pro zavedení a správnou funkci metodiky Kanban je nutné splnit několik předpokladů. Je např. důležité, aby s metodikou pracoval personál, který byl předtím proškolený, je dobře motivovaný a v případě, že dojde ke zvýšení poptávky je i připravený pracovat přesčas. V případě, že dojde k poruše na některém z výrobních strojů, musí být operátoři těchto strojů schopni závadu rychle odstranit. Manažeři musí umět převádět pravomoci. Pracoviště by ideálně mělo být navržené tak, aby podporovalo linkovou výrobu a mělo by zde být umístěno i stanoviště pro kontrolu kvality. Kanban se hodí zejména pro opakované výroby, kde nedochází k velkým rozdílům v poptávce a jednotlivé kapacity jsou navzájem vyvážené. Kromě výše zmíněných předpokladů je pro zajištění správné funkce metodiky Kanban nutné dodržovat i šest základních pravidel, kterými jsou: - Zaměstnanci následujících procesů musí vždy odebrat příslušné množství a typy výrobků z předcházejících procesů, podle toho jak to definuje daná Kanban karta. - Zaměstnanci pověření výrobou mohou vyrábět pouze ty výrobky, které předepisuje výrobní Kanban karta. - V případě, že se na pracovišti nenachází žádné Kanban karty, nesmí zaměstnanci provádět žádnou činnost ať už se jedná o výrobu nebo jen přepravu hotových výrobků. - Zaměstnanci pověření výrobou zodpovídají za to, že do následujících procesů budou pokračovat pouze ty výrobky, které jsou stoprocentně v pořádku. V případě, že tomu 30

31 tak není se musí celý proces ukončit a vzniklá chyba se musí odstranit takovým způsobem, který zajistí, že se už nebude opakovat. - Úvodní počet karet se musí postupně snižovat, vzájemné propojení procesů se musí prohlubovat a pokles zásob indikuje problémy a je tak možné je odstranit. - Karty Kanban se předávají vždy společně s výrobky, s výjimkou jejich navrácení. Díky tomuto principu je možné mít podle celkového počtu Kanban karet v oběhu přehled o rozpracovanosti výroby, lépe tak výrobu organizovat nebo regulovat objem zásob v rozpracovaných výrobách. Tento systém využívá Kanban karty zejména ke sledování aktuálních zásob a neukončených výrob. V případě dokončení celé výrobní zakázky jsou výrobky předány do následujícího procesu a Kanban karta se odešle do přeřazeného pracoviště, kde slouží jako objednávka na další zakázku, materiál nebo polotovar. Mezi největší přínosy metodiky Kanban patří vytvoření propojených samořídících usměrňovacích okruhů mezi spotřební a výrobní oblastí, umožňuje přizpůsobit nasazení zaměstnanců a prostředků pro provoz a zároveň přenáší řízení na zaměstnance pověřené výrobou skrze Kanban karty. Více informací o této metodice je možné nalézt na (Leankit, 2015). 3.8 Porovnání agilních a rigorózních metodik V současnosti jsou v softwarovém inženýrství považovány za dvě hlavní vývojové cesty rigorózní a agilní metodiky. Každá z těchto cest vychází z jiného pohledu na vývoj a proto se hodí vždy jen na určitý druh projektu. Řada rozdílů mezi těmito metodikami byla již zmíněna, v této kapitole bude uvedeno ještě několik dalších zásadních rozdílů. Tradiční a agilní přístup k vývoji se např. rozchází v názoru jak popsat metodiku. U rigorózních metodik se důraz klade hlavně na pečlivě a podrobně popsané funkce a jednotlivé postupy, naproti tomu u agilních metodik se metodika definuje pouze v nejmenší možné formě a zaměřuje se na postupy přinášející přidanou hodnotu pro zákazníka, zároveň se snaží potlačit postupy, které zákazníkovi nepřinesou hodnotu žádnou. 31

32 Rigorózní metodiky předpokládají, že kvalitně provedenými procesy se musí dosáhnout i kvalitního výsledku a z tohoto důvodu se zaměřují zejména na řízení kvality jednotlivých procesů. Agilní metodiky kladou důraz na dodání produktu s co největší kvalitou a hlavním cílem je co nejvyšší přidaná hodnota pro klienta. Pohled na změny v průběhu vývoje je u těchto dvou cest také velice odlišný. U agilních metodik je změna vítaná a to z toho důvodu, že zákazníkovi se v průběhu vývoje mění pohled na celou situaci, rozvíjí se jeho znalosti i zkušenosti a v případě, že chce provést nějakou změnu, je to z důvodu lepší konkurenceschopnosti vyvíjeného softwaru. Tím, že vývojáři umožní zákazníkovi provádět změny ve vývoji, dosáhnou produktu, který bude zákazníkovi ušit přesně na míru, prokážou své vývojářské schopnosti, zabrání negativnímu výsledku a docílí maximální spokojenosti zákazníka. Rigorózní metodiky se snaží změnám předcházet a pokud je to možné tak je i úplně odstranit. Vycházejí z původních představ zákazníka, které se v co nejméně změněné podobě snaží dotáhnout do cíle. Případné změny musí projít procesem řízení změn a u většiny rigorózních metodik je provádění změn velice náročné. Dalším velmi důležitým rozdílem je způsob jakým je zákazník zapojen do průběhu projektu. Při vývoji tradičním způsobem se zákazník účastní pouze úvodních a finálních etap vývoje. Jakmile podepíše dokument, ve kterém jsou definované všechny jeho požadavky na software, chopí se řízení projektu tým vývojářů a on už do vývoje nemůže zasahovat a může jen trpělivě čekat na výsledek. U vývoje podporovaného agilními metodikami má naopak zákazník řídící funkci v celém průběhu projektu a v průběhu iterací může měnit jednotlivé priority. U agilních a rigorózních metodik se liší i samotný přístup k vývoji. Agilní metodiky sází zejména na inkrementální způsob vývoje s co nejkratšími iteracemi. Oproti tomu rigorózní metodiky se řídí převážně vodopádovým modelem životního cyklu, nebo někdy i iterativním, ale iterace jsou zde dlouhé. Přehlednější popis spolu s celou řadou dalších rozdílů popisuje (Buchalcevová, 2005). Z údajů o agilních metodikách uvedených v této práci je možné dojít k závěru, že pro správnou funkci některé z těchto metodik v určitém vývojovém prostředí je nutné, aby daná metodika splňovala řadu předpokladů. Závěr je to správný a hlavním předpokladem agilního vývoje, který je nutný splnit, je aby tým zabývající se vývojem zapojil do projektu i svého klienta. Tím je podtrhnut význam komunikace nejen mezi samotnými členy vývojového 32

33 týmu, ale i s klientem. Pro zajištění co nejvyšší efektivity vývojového týmu je doporučeno, aby se tým skládal maximálně z deseti vývojářů. Z toho vyplývá, že jsou agilní metodiky vhodné zejména na projekty menších rozsahů. Dalším důležitým předpokladem pro úspěšný agilní vývoj je tým vývojářů složený z kvalifikovaných odborníků, kteří kromě rozsáhlých znalostí v oblasti vývoje mají i spoustu praktických zkušeností. Je důležité, aby si všichni účastníci vývoje uvědomovali, že průvodní dokumentace nejsou zas tak zásadní a že zákaznické požadavky i samotné prostředí, ve kterém probíhá vývoj se mohou v průběhu měnit. Přehled o průběhu projektu získávají všichni účastníci vývojového týmu (včetně zákazníka) na konci každé iterace a jsou tak lépe schopni přizpůsobit další kroky vývoje. V případě, kdy projekt nesplňuje zmiňované podmínky pro agilní vývoj, je lepší použít rigorózní metodiku, eventuálně je možné zkombinovat určité praktiky z obou metodik (Buchalcevová, 2005). 33

34 4. Nástroje na podporu agilního vývoje softwaru V této kapitole je popsán význam a obecné vlastnosti nástrojů na podporu vývoje softwaru. V následujících podkapitolách je uvedený popis výběru nástrojů a dále tři mnou vybrané nástroje. Manifest agilního vývoje nabádá vývojářské týmy k tomu, aby se zaměřily hlavně na vývoj a komunikace uvnitř i vně týmu a neztráceli zbytečně čas sáhodlouhými definicemi procesů a využíváním složitých nástrojů. Tím se jistě mohou řídit menší týmy např. do pěti lidí, kteří pro vývoj využívají metodiku XP. Ale v případě, kdy jeden manager musí koordinovat práci několika robustních vývojových týmů je velice náročné evidovat a sledovat průběh projektu jen za pomoci tabulek vytvořených např. v Excelu. V tu chvíli je jistě výhodnější a z pohledu vedení týmů i bezpečnější využít ucelený nástroj, který je dostupný ze všech koutů světa. Společnost Forrester, která patří mezi uznávané společnosti v oblasti výzkumu a analýz, už před 12 lety prohlásila, že pro agilní vývoj softwaru není používání nástrojů nezbytně nutné, ale nástroje značnou mírou napomáhají úspěšnému dokončení projektu (Forrester, 2004). Vývojové týmy využívající pro svou práci agilních metodik, se nejčastěji řídí metodikou Scrum. Ta, jak již bylo zmíněno v kapitole 3.6 rozčlení celý průběh vývoje do jednotlivých částí tzv. sprintů. Všechny sprinty mají jasně určený cíl, kterého se musí dosáhnout, ale i jednotlivé úkoly podporující splnění cíle. Členům vývojového týmu jsou přiděleny jednotlivé úkoly a potom se stanovuje doba potřebná na dokončení úkolů. Nástroje popsané v této kapitole byly vybrány, protože podporují řízení celého průběhu metodiky Scrum, ale zároveň poskytují možnost řízení pomocí metodiky Kanban. V případě Scrumu je za pomoci nástrojů možné v průběhu jednotlivých schůzek jakkoliv upravovat zdroje přidělené k projektu nebo vývojářům zadat nový, popřípadě upravit jejich stávající úkol. Evidence úkolů nebo úprav zdrojů je velice důležitá činnost napomáhající lepší správě projektu a bez např. mnou vybraných nástrojů se většinou eviduje do excelovských tabulek, které se potom sdílejí mezi jednotlivými členy týmu. Dnes je již na trhu celá řada nástrojů, které podporují nejrůznější metodiky, ať již rigorózní, agilní nebo kombinace dvou a více metodik. Nástroje na podporu vývoje softwaru nejsou novinkou posledních let, ale existují již dlouhou dobu, příkladem může být Microsoft Project. Tento nástroj se ovšem specializuje na podporu projektových manažerů a integruje v sobě nástroje pro lepší plánování úkolů nebo stanovení času 34

35 potřebného na jejich splnění. Jeho nevýhodou však je, že není schopen dostatečně podporovat požadavky kladené agilními metodikami. Velkou výhodou nástrojů podporující agilní metodiky je jejich provedení, které do jediného prostředí sjednocuje všechen software nutný k vývoji. Další výhodou, kterou ocení hlavně manažeři, je možnost používání nástroje jako služby poskytované přes internet. Díky tomu mohou např. na služební cestě sledovat průběh aktuálně vyvíjeného projektu a zůstat tak stále v obraze. Dnes je již konkurence mezi nástroji opravdu silná a proto se snaží společnosti, které vytváří tyto nástroje do svých produktů integrovat co nejvíce prvků. Kvalitní nástroje by v dnešní době měli obsahovat prvky na podporu programového a projektového řízení, správu zdrojů, evidenci zákaznických požadavků nebo prvky zabývající se testováním. Zároveň by měli umožnit integraci např. s firemními nástroji nebo freewary řešící testování. Nástroje na podporu agilního vývoje softwaru se většinou rozdělují na dvě verze, které jsou označovány jako podniková a veřejná. Podniková verze, anglicky nazývaná enterprise představuje plnou verzi vývojového nástroje a poskytuje všechny funkce, které je daná společnost schopna nabídnout. Veřejná verze (anglicky community) většinou označuje stejný produkt, ale nějakým způsobem omezený. Nejčastěji se tato omezení týkají portfolia nabízených funkcí, celkového počtu možných uživatelů nástroje nebo maximálního počtu projektových týmů. Důvodem proč společnosti poskytující nástroje omezují funkce, uživatele a týmy u veřejných verzí je to, že jsou tyto verze poskytovány většinou bez poplatku. Veřejná verze není to samé jako zkušební verze (trial). Trial verze označuje produkt, který není nijak omezený po stránce funkcí a podpory, ani se za něj nemusí platit, ale je možné ho používat pouze po omezenou dobu, kterou si stanovují sami poskytovatelé. 4.1 Výběr nástrojů Při výběru nástrojů jsem se snažil vybrat ty, které obsahují prvky pro řízení projektu, sledování chyb a řízení spolupráce se zákazníkem. Zároveň bylo podmínkou, aby nástroje podporovali jak metodiku Scrum, tak i metodiku Kanban. Nástroje popsané v následujících podkapitolách jsem našel na webové stránce která se zabývá novinkami z oblasti agilního vývoje softwaru. Na této stránce byl uveden článek TOP 20 Scrum Tools, kde bylo vypsaných 20 nástrojů podporující metodiku Scrum.[x] Nástroje byly 35

36 hodnocené podle kritérií (např. spokojenost zákazníků, technická podpora, možnost pořízení, apod.), jejich seznam spolu s odkazem na zdroj je možné vidět v tabulce 1. Tento článek porovnával nástroje pouze z pohledu metodiky Scrum, proto jsem procházel jednotlivé zdroje nástrojů a hledal jsem, jestli mezi nimi nejsou nástroje, které podporují i metodiku Kanban. Nakonec jsem našel 3 nástroje splňující zvolené, výše zmíněné, podmínky, jsou jimi TeamPulse, Urban Turtle 4 a Agilo for Trac. Pořadí Nástroj Zdroj 1 Scrumwise 2 Targetprocess 3 Acunote 4 Agile Agenda 5 TeamPulse 6 Agile Bench 7 Serena 8 Agilefant 9 Urban Turtle Fulcrum 11 Kunagi 12 Scrum Factory 13 Quick Scrum 14 Agilo for Trac 15 Scrinch 16 ReQuest 17 Intervals 18 Scrumy 19 AgileWrap 20 Retrospectiva Tab. 1 Tabulka agilních nástrojů (zdroj: autor) V následujících podkapitolách jsou uvedené popisy nástrojů. Všechny nástroje jsou popsané ve stejné struktuře, kdy je nejprve na obrázku předvedena ukázka prostředí nástroje, potom je 36

37 uvedený popis společnosti, která nástroj poskytuje a na závěr jsou popsané funkce, které nástroj poskytuje. 4.2 Urban Turtle 4 Obr. 6 Ukázka prostředí Urban Turtle (zdroj: Na obrázku 6 můžeme vidět ukázku prostředí nástroje Urban Turtle 4. V horní části je možné sledovat a koordinovat postup větších funkcí nebo řídit činnosti napříč vícero týmy. Uprostřed se nachází seznam úkolů, které je nutné vykonat v rámci daného sprintu, včetně doby vymezené na tyto úkoly. V dolní časti jsou potom popsané jednotlivé funkce spolu s procentuálním značením jejich naplnění a bodovým hodnocením Popis společnosti Softwarový průmysl byl v počátcích nového milénia velmi nesrozumitelný. Softwary byly vyvíjeny lidmi, kterým moc nezáleželo na potřebách koncových uživatelů. A z tohoto důvodu 37