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

Bankovní institut vysoká škola Praha Katedra informatiky a kvantitativních metod

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

Bakalářská práce

Autor:

Lukáš Vojtek, DiS. Informační technologie, SIS

Vedoucí práce:

Praha

doc. Ing. Alena Buchalcevová, Ph.D.

Duben 2016

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 20.4.2016

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

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 .......................................................................................................................................................57 1. Způsob vývoje software ...................................................................................................................... 8 2. Agilní vývoj softwaru ........................................................................................................................11 2.1 Historie..........................................................................................................................................11 2.2 Vodopádový model .......................................................................................................................12 2.3 Agilní metodiky ............................................................................................................................14 2.4 Rozdíly mezi agilní technikou a metodikou .................................................................................17 2.5 Manifest agilního vývoje softwaru ...............................................................................................19 3. Příklady agilních metodik ..................................................................................................................22 3.1 Extrémní programování (Extreme programming, XP) .................................................................22 3.2 Crystal metodiky ...........................................................................................................................24 3.3 Metodika Agile Unified Process (AUP) .......................................................................................25 3.4 Metodika Open Unified Process (OpenUp) ..................................................................................26 3.5 Agilní modelování ........................................................................................................................26 3.6 Metodika Scrum ............................................................................................................................27 3.7 Metodika Kanban ..........................................................................................................................29 3.8 Porovnání agilních a rigorózních metodik ....................................................................................31 4. Nástroje na podporu agilního vývoj softwaru ....................................................................................34 4.1 Výběr nástrojů ..............................................................................................................................35 4.2 Urban Turtle 4 ..............................................................................................................................37 4.2.1 Popis společnosti ...................................................................................................................37 4.2.2 Popis nástroje ........................................................................................................................38 4.3 TeamPulse ....................................................................................................................................40 4.3.1 Popis společnosti ...................................................................................................................37 4.3.2 Popis nástroje ........................................................................................................................37 4.4 Agilo for Trac ...............................................................................................................................43 4.4.1 Popis společnosti ...................................................................................................................37

4.4.2 Popis nástroje ........................................................................................................................37 5. Popis kritérií pro porovnání nástrojů ..................................................................................................47 5.1 Podpora většího počtu týmů .........................................................................................................37 5.2 Podpora metodik ..........................................................................................................................37 5.3 Dostupnost nástroje ......................................................................................................................37 5.4 Pořizovací náklady .......................................................................................................................37 5.5 Prvky zajišťující konkurenční výhodu .........................................................................................51 5.6 Vzhled a úpravy nástroje ..............................................................................................................51 6. Hodnocení nástrojů dle kritérií ...........................................................................................................57 6.1 Podpora většího počtu týmů .........................................................................................................53 6.2 Podpora metodik ..........................................................................................................................54 6.3 Dostupnost nástroje ......................................................................................................................50 6.4 Pořizovací náklady .......................................................................................................................50 6.5 Prvky zajišťující konkurenční výhodu .........................................................................................50 6.6 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

Ú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.

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

-

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

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

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

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

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

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

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

-

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

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

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

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

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

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

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

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

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

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

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, ©2001-2014).

26

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

-

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

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

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

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

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

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

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

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 http://www.agilescout.com, 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

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

http://www.scrumwise.com/

2

Targetprocess

http://scrum-project-management-tool.targetprocess.com/

3

Acunote

http://www.acunote.com/

4

Agile Agenda

http://www.agileagenda.com/

5

TeamPulse

http://www.telerik.com/teampulse

6

Agile Bench

http://agilebench.com/

7

Serena

http://www.serena.com/index.php/en/

8

Agilefant

http://www.agilefant.com/

9

Urban Turtle 4

http://urbanturtle.com/en/

10

Fulcrum

http://wholemeal.co.nz/projects/fulcrum.html

11

Kunagi

http://kunagi.org/

12

Scrum Factory

http://www.scrum-factory.com/

13

Quick Scrum

https://www.quickscrum.com/

14

Agilo for Trac

http://www.agilofortrac.com/

15

Scrinch

https://sourceforge.net/projects/scrinch/

16

ReQuest

http://reqtest.com/features/agile-board/

17

Intervals

https://www.myintervals.com/

18

Scrumy

http://scrumy.com/

19

AgileWrap

https://product.agilewrap.com/

20

Retrospectiva

https://github.com/dim/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

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: http://urbanturtle.com/en)

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.

4.2.1 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

v té době vznikali převážně nástroje, které byli zbytečně nepřehledné, co se vzhledu týče často odbyté a postrádali jakoukoliv vizi do budoucna. Strůjci nástroje Urban Turtle, tři mladí vývojáři z Kanady, toho už měli dost a proto si v roce 2001 položili otázku: „Co děláme při vývoji softwaru špatně?“ a na základě této otázky potom začali dávat dohromady jednotlivé prvky jejich vlastního nástroje na podporu vývoje softwaru. Jejich hlavním cílem bylo vyvíjet lépe než doposud a vytvářet software, který nepostrádá smysl a vizi. Aby toho docílili, museli se oprostit od všech svých zvyklostí a při hledání nového směru pro svou práci, brzy narazili na agilní techniky. Odhalení nového směru, kterým se bude ubírat jejich práce nakonec vedlo k založení společnosti Pyxis, která poté vzala pod svá křídla i společnost Urban Turtle. Pouť těchto tří odvážlivců za lepším vývojem softwaru se však neobešla bez chyb. Chyb se dopouštěli často, ale nedali se jimi odradit a naštěstí se z nich dokázali i poučit. Za pomoci svých zkušeností, rozumu, věrných zaměstnanců a partnerů, kteří jim byli oporou v nejtěžších chvílích, tak dokázali dosáhnout úspěchu. Pyxis v dnešní době patří mezi přední společnosti zabývající se agilními praktikami v zemích jako jsou Kanada, Francie nebo Švýcarsko. Světově první Scrum trenér, který uměl mluvit francouzsky byl vyškolen právě touto společností a od svého zaškolení potom pomáhal evropským Scrum Masterům i vývojářům s aplikováním agilních metodik do praxe.

4.2.2 Popis nástroje Urban Turtle přináší celou řadu agilních prvků pro lepší řízení projektu, které napomáhají jeho úspěšnému završení. Aby bylo možné mít neustále pod kontrolou celý průběh vývoje, včetně dodávek jednotlivých funkcionalit softwaru obsahuje nástroj Urban Turtle tzv. product management. Ten napomáhá s co nejlepším sladěním robustních úkolů, jejichž splnění vyžaduje účast většího počtu týmů. Průběh vývoje je potom možné sledovat skrze rozpracované a splněné úkoly. Tím je odstraněna bariéra mezi uživatelskými požadavky a jejich potřebami. Výstupem produktového řízení je plán projektu, ve kterém je popsán harmonogram odevzdávek jednotlivých funkcionalit. Vývojové týmy pak mohou plán ukázat svým zákazníkům a řešit individuální náležitosti všech dodávek. Produktové řízení se nedoporučuje používat u projektů dlouhodobých nebo pevně stanovených.

38

Během projektu je nutné učinit spousty rozhodnutí a aby tato rozhodnutí byla správná je také nutné prohlédnout si i metriky. K tomu je možné využít Agile dashboard neboli agilní přístrojovou desku, která manažerům přehledně ukáže metriky ze všech probíhajících projektů. Všechny metriky rozděluje do dvou skupin, na manažerské metriky a týmové metriky. Seznam metrik lze prohlížet i skrze Team Foundation Server. Součástí této desky je tzv. Sunset Graph, pomocí kterého je možné předpovědět průběh aktuálního projektu a dále obsahuje i řadu ovládacích prvků, přes které je možné sledovat údaje z nesplněných úkolů a to dokonce v reálném čase. Takto je možné sledovat průběh všech sprintů a předem stanovených milníků, včetně doby potřebné na jejich slnění, dále hospodaření s rozpočtem a kritické faktory, které mohou ovlivnit průběh vývoje. Pro větší přehlednost je možné projekt rozdělit i přes nástěnku. Manažer určí jaké milníky nebo iterace budou na nástěnce ukázány a jednotlivým týmům potom přidělí určitý proces ke splnění. Skrze prosté a velmi přehledné rozhraní tak může jednoduše vytvořit nebo upravit všechny štítky na nástěnce nebo pracovat s vícero nástěnkami najednou. Podporovány jsou všechny procesy ať už malé nebo rozsáhlé a metodiky SCRUM a Kanban. Pro podporu lepšího plánování průběhu práce a stanovení jejích priorit je pro manažery poskytován nástroj zvaný product backlog. Ten umožňuje skrze různobarevné karty stanovit prioritu všem nesplněným úkolům a týmy se tak mohou zaměřit na úkoly, které jak se říká nejvíce hoří. Zároveň je možné za chodu vytvářet pracovní položky, čímž se urychlí plánování samotných sprintů. Všechny založené nebo nezařazené položky lze najít také v tomto seznamu. Pomocí toho všeho je nakonec možné potvrdit správnost předpovědi vývojového týmu a zároveň mít i neustálý přehled o jeho postupu. Všichni členové vývojového týmu mají možnost monitorovat svou vlastní pracovní vytíženost během sprintů a to pomocí nástroje sprint backlog. Díky němu je možné z jednoho místa shlédnout všechny dokončené procesy, ty které momentálně probíhají nebo ty, na kterých se ještě nezačalo pracovat. U procesů je ukázaný zbývající čas na jejich dokončení, ten se neustále aktualizuje i když backlog neukončíme. Za pomoci tohoto nástroje není nutné upravovat procesy, bohatě postačí, když přednastavíme backlog. Součástí nástroje Urban Turtle je i nástěnka pro stanovení odhadů, díky které je možné zvýšit součinnost jednotlivých týmů a lépe rozvrhnout neprovedenou práci pro její rychlejší 39

zpracování. Do Team Foundation Serveru se potom ukládají všechny týmem zpracované odhady. Více informací o tomto nástroji je možné nalézt na webových stránkách společnosti (UrbanTurtle, ©2015).

4.3 TeamPulse

Obr. 5 Ukázka prostředí TeamPulse (zdroj: http://www.telerik.com/teampulse)

Na obrázku 7 je zobrazená ukázka z prostředí nástroje TeamPulse. Na pravé straně se nachází navigační panel pro jednotlivé funkce. Uprostřed jsou potom ukázané momentálně řešené iterace, dokončené, právě probíhající a ty, které se zatím nezačali zpracovávat. Na pravé straně je potom ukázaný souhrn všech položek a úkolů, lze také vybrat pouze některé.

4.3.1 Popis společnosti Bulharská společnost Telerik se již řadu let zabývá poskytováním softwarových nástrojů na podporu vývoje web, mobile i desktop aplikací, ale i nástrojů a různých služeb specializovaných na jejich rozvoj. Vznikla v roce 2002 a v té době se specializovala na nástroje podporované platformou .NET. Dnes už však neposkytuje platformy pouze pro

40

webový vývoj, ale například i pro nativní nebo hybridní. V roce 2014 se společnost Telerik spojila se společností Progress Software. Společnost založili čtyři absolventi ze dvou bulharských univerzit (Technické a Americké). Nejprve se zabývali outsourcovaným vývojem aplikací pro domácí společnosti, brzy však jejich služeb mohli využívat i zahraniční společnosti. Postupem času se tato společnost začala zajímat o nástroje, které podporují vývoj softwaru a nedlouho na to přinesla na trh svůj vlastní výrobek. Jejich první počin v tomto odvětví se nazýval Rapid Application Development editor a jednalo se nástroj určený pro editaci webových stránek. Tento editor podporoval technologii ASP.NET, což byla v té době novinka. Dále potom rozšiřovali svou nabídku např. o uživatelská rozhraní nebo ovládací prvky navigace, což dalo základy pro vznik řídícího systému Telerik Sitefinity. Díky podnětům od vývojářů byl Telerik schopný vytvořit další nástroje podporující technologii .NET, mezi ty známější patří např. AJAX, MVC nebo Silverlight. Začátkem roku 2011 představila tato společnost uživatelské rozhraní Kendo, které podporuje JavaScript a HTML5.

4.3.2 Popis nástroje Nástroj TeamPulse poskytuje vývojovým týmům podporu pro lepší naplánování průběhu projektu. Za tímto účelem obsahuje prvek zvaný TeamPulse Backlog, který sjednocuje veškerá hlášení týkající se projektu (např. chybová hlášení, různé problémy při vývoji, možná rizika) do jednoho místa. V backlogu je možné si jednotlivá hlášení prohlídnout, upravit je nebo jim přiřadit prioritu. Lze tak lépe stanovit harmonogram odevzdávání jednotlivých funkcí aplikace i iterací, díky lepšímu přehledu a správě funkcí určených k dodání zákazníkovi. Zároveň je možné rozčlenit všechny funkce do samostatných příběhů a ty potom připojit k iteracím. Aby si tým nebo manažer mohl udržet přehled o průběhu projektu, jsou zde k dispozici dva druhy nástěnek (příběhová a úkolová). Ty umožňují vytvářet a upravovat pracovní položky, přerozdělovat členy týmu, filtrovat iterace nebo oblasti. Za pomoci kanban nástěnky obohacené o WIP limity je tak možné vyvíjet software i bez iterací. Manažer musí pouze stanovit horní a dolní hranice pro každý proces a nástroj potom sám ohlídá případy, kdy došlo k překročení těchto hranic. Výhodou tohoto prvku je, že nástroj pouze neupozorní na

41

nedodržení limit, ale zároveň i napomáhá odstraňovat bariéry bránící zdárnému dokončení projektu. Díky lepšímu přehledu o průběhu práce je pro manažery snadnější stanovit zdali se zvládne odevzdat daná funkce softwaru v plánovaném termínu nebo předpovědět možnost vzniku rizika na základě seznamu chyb, které již při vývoji nastaly. Součástí nástroje jsou i prvky, které poskytují manažerům podporu pro správu většího počtu projektů, které jsou realizované souběžně. Je tak možné efektivně řídit pracovní položky, které zasahují do více projektů nebo např. určit priority skrz naskrz projekty. Pro projekty je možné vytvořit i jednotný backlog, díky kterému manažeři získají větší nadhled a mohou tak snáze přiřadit vyšší prioritu pracím, které jsou pozadu. Takto se zajistí, že všichni členové týmu mají přehled o jednotlivých úkonech a vědí o slabých částech, na které je nutné zaměřit pozornost. Pro ještě přesnější přehled o průběhu vývoje se evidují veškeré úkony vykonané všemi členy vývojových týmů u všech projektů a to i s dobou, kterou strávili na zpracování daného úkonu. Tyto záznamy je potom možné třídit pomocí parametrů: čas, projekt nebo člen týmu. Na základě těchto informací je potom snadné zjistit, jak dlouho trvaly jednotlivé procesy a manažerům se tak usnadní proces kalkulace celkové ceny za práci. Ke každému časovému údaji je možné přiložit komentář popisující okolnosti a důvody, kvůli kterým daný proces zabral uvedenou dobu. Všechny tyto informace je navíc možné převést do excelovské tabulky. Dalším velmi zajímavým prvkem tohoto nástroje portál zajišťující přímou komunikaci mezi vývojáři a jejich zákazníky. Zde je zákazníkům umožněno zasílat své požadavky na úpravu aplikace, upozornit vývojáře na chyby, na které narazili nebo jim poskytnout své poznatky a zpětnou vazbu pro zlepšení vyvíjené aplikace. Portál je nastavený tak, aby zákazníky informoval o tom v jaké fázi zpracování se nachází jejich požadavek a zároveň jim umožnil i připsat komentář. Na tento portál mají zákazníci přístup i přes mobilní telefony. Součástí nástroje je tabulka, která má za úkol zpřehlednit veškeré bariéry bránící klidnému dokončení projektu. Jsou zde evidované chyby, které nastaly v průběhu vývoje, problémy s odevzdáváním nebo vzniklá rizika. Na základě historie chyb je možné předcházet rizikům nebo určit procesy, u kterých hrozí zpoždění a více se na ně zaměřit.

42

Velkou výhodou tohoto nástroje je prvek Best Praktice Analzyer, který pomáhá vývojovým týmům lépe vstřebávat agilní metodiky tím, že převádí agilní teorii v praxi. Analyzátor porovnává a označuje ty části projektu, které se neshodují s osvědčenými postupy a na základě zpráv, které poskytuje je možné zaměřit se na specifické operace a rychleji tak odstranit vzniklé problémy. Podrobnější popis tohoto analyzátoru i ostatních výše zmíněných funkcí je možné nalézt na webové prezentaci nástroje (TeamPulse, ©2002-2016).

4.4 Agilo for Trac

Obr. 6 Ukázka prostředí Agilo for Trac (zdroj: http://www.agilofortrac.com)

Na obrázku 8 je na dvou obrazovkách ukázané prostředí nástroje. Na levé obrazovce je ukázaný burndown chart a další statistiky. Pravá obrazovka slouží k navigaci v procesu vývoje.

43

4.4.1 Popis společnosti Nástroj Agilo for Trac byl vyvinut softwarovým inženýrem jménem Andrea Tomasini. Ten s vývojem začal začátkem roku 2007 a pouhý rok na to v lednu 2008 byla k dispozici první verze pro veřejnost. Zpočátku se tým stojící za tímto nástrojem zabýval pouze distribucí, dnes už poskytují i konzultace přímo u zákazníků. Tento nástroj je postaven na systému Trac, což je velmi rozšířený systém pro správu a řízení procesů. Jako programovací jazyk použil Tomasini Python a je dnes poskytován pod licencí Apache Software jako open source webový nástroj. Od roku 2011 se nástroj oficiálně jmenuje jako Agilo For Trac pro zdůraznění vazby na systém Trac. Agilo podporuje metodiky Scrum i Kanban a je vhodné ho použít na podporu agilních projektů napříč všemi ekonomickými sektory. Dnes je aplikace poskytována formou služby, ale je možné si jí stáhnout i přes Windows instalátor nebo VMware apod. Jak již bylo zmíněno je aplikace postavená na systému Trac a všechny nové verze využívají systém verze 0,12.

4.4.2 Popis nástroje Nástroj poskytuje prvky pro podporu hladkého průběhu projektu nejen manažerům, ale i vývojovým týmům a zákazníkům s ohledem na různý přístup k projektu všech členů. Jednotlivé funkce nástroje vycházejí z dlouhodobé praxe vývojářů založené na podpoře již realizovaných projektů. Pro lepší zohlednění průběhu vývoje obsahuje tzv. hierarchické štítky, pomocí kterých poskládá všechny úkoly do jednoho příběhu. Do tohoto příběhu je samozřejmě možné začlenit i požadavky ze strany zákazníků. Díky tomu je možné mít neustálý přehled nad požadavky klienta, příběhem včetně jednotlivých úkolů, ze kterých se skládá až po dodávky jednotlivých funkcí na konci každé iterace a to vše z jednoho místa. Nástroj do sebe integruje různé rozšiřující verze, včetně úkolů, závad apod. Usnadňuje práci vývojářům díky lepší správě zdrojového kódu zobrazující odkazy ke změnám a zároveň podporou velké škály systémů pro kontrolu např. Git, Perforace nebo Bazar. Všechny data je možné převést do CSV formátu.

44

Důležitým prvkem nástroje je Backlog pomocí, kterého má tým lepší přehled o průběhu všech sprintů. Je skrze něj možné odhalit procesy, které se nestíhají splnit v daném termínu a přiřadit jim větší prioritu, pro přitáhnutí pozornosti vývojářů. Agilo for Trac obsahuje více než jeden backlog. K dispozici je backlog pro záznam chyb vzniklých při vývoji, sledování rozpracovaných procesů nebo vyhodnocování rizik. Pomocí těchto backlogů je pro manažery snadnější uřídit práci více souběžně probíhajících projektů najednou nebo efektivněji koordinovat práci členů týmu. Nástroj poskytuje podporu pro řízení distribuovaných týmů, neboli týmů pracujících na dálku. Při tom bere ohled i na různá časová pásma, ve kterých se vývojáři nacházejí. Zároveň podporuje i týmy specializující se na předcházení rizikům, zpracovávající zákaznické požadavky nebo týmy, které pracují na odstranění chyb. Koordinaci těchto týmu usnadňuje funkce označovaná jako graf vytíženosti, který manažerům ukazuje jak jsou jednotlivý členové týmů v průběhu plnění jednotlivých procesů vytížení. Za pomoci přehledného rozhraní je možné spojit všechny právě probíhající vývoje (příběhy) do jednoho celku. Je tak možné získat ucelený pohled na všechna přání ze strany zákazníků, efektivněji přizpůsobovat vlastnosti průběhů nebo spravovat úkoly skrze backlog zobrazující seznam rozpracovaných procesů. Zároveň však zpřehlední i nesplněné úkoly, které přímo nesouvisejí s hlavním příběhem. Sjednocuje také službu wiki spolu s řízením týmů a umožňuje tak manažerům snadnější kontrolu týmů. Manažerům stačí pomocí této funkce do aplikace pouze vyplnit jak jsou jednotlivé vývojové týmy momentálně dostupné a ona potom sama vykoná všechny potřebné propočty. Tento prvek je možné rozšířit o celou škálu modulů, které jsou společností poskytovány zcela bez poplatků. Agilo for Trac poskytuje svým zákazníkům spousty možností jak si nástroj upravit pro co nejpohodlnější užívání. Mimo velkého počtu možností jak upravit vzhled aplikace je klientům umožněno např. i definování nových typů nebo postupů. Nástroj obsahuje i kanban tabulku, kterou může zákazník upravit nejrůznějšími způsoby. Podporován je i vývoj pomocí metodiky Kanban přes nastavitelné sloupce. Výše zmíněné funkce jsou podporovány nástrojem Agilo free, který je poskytován zdarma. Existuje i verze Pro, která už je placená, ale oproti verzi zdarma poskytuje celou řadu prvků pro podporu vývojářů. Výčtem zmiňme např. funkci SLA neboli dohodu o kvalitě 45

dodávaného softwaru nebo přidání nástěnky, kde si mohou vývojáři zapisovat poznatky získané v průběhu vývoje. Agilo Pro dále umožňuje členům vývojového týmu vytvářet nové karty, upravovat vlastnosti průběhů nebo všech úkolů a to přímo z rozhraní pro správu rozpracovaných procesů, bez nutnosti toto rozhraní neustále zapínat a vypínat. Bližší informace ke všem funkcím nástroje je možné získat na webové prezentaci nástroje (Agilo for Trac, ©2014).

46

5. Popis kritérií pro porovnání nástrojů V této kapitole jsou popsané kritéria, pomocí kterých se následně porovnávají nástroje vybrané v kapitole 4. Je zde uvedené vysvětlení, jak jsem zvolil kritéria. V jednotlivých podkapitolách je potom uvedený popis jednotlivých kritérií. Všechny informace o nástrojích jsem získal z webových stránek společností, které je distribuují. Tím vzniká problém s objektivitou informací, protože všechny společnosti uvádějí samozřejmě pouze klady svých aplikací. Je to z důvodu lepší reklamy, aby se podpořil prodej nástrojů. Zároveň společnosti nechtějí své potencionální zákazníky zahltit kvantem technických údajů. Další problém je spojený s funkcemi programu, kde je často shodná funkce označována pod jinými názvy, jen aby neměla shodný název jako konkurenční společnosti. Pro stanovení kritérií jsem si sám sebe představil v roli manažera začínající vývojové společnosti, který má na starosti osmičlenný tým vývojářů. Kritéria jsou vybrána s ohledem na to, co by podle mého názoru pro takového manažera bylo nejdůležitější. Dále jsem se pro stanovení kritérií nechal inspirovat seminární prací (Hanzalová a Justová, 2013). Všechna kritéria jsou bodově ohodnoceny, nula označuje nejnižší hodnotu a číslo tři nejvyšší. Pro porovnání nástrojů jsem vybral následující kritéria, která jsou v dalších podkapitolách popsána: -

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 práce s nástrojem

47

5.1 Podpora většího počtu týmů Ve velkých vývojových společnostech však může jeden manažer koordinovat práci více týmů, kteří pracují na různých projektech najednou. Jako začínajícího manažera mě bude hlavně zajímat jestli nástroj poskytne dostatečnou podporu pro mne a můj tým. Postupem času však mohu začít přemýšlet o rozšíření společnosti o další vývojový tým např. z důvodu většího počtu zakázek nebo aby moje společnost byla schopna zpracovávat i větší projekty. Z těchto důvodů je dobré vědět, jestli nástroj, který jsem pro svou společnost vybral bude vhodný i do budoucna, v případě růstu společnosti. Vývojový tým se totiž zatím naučí pracovat se současným nástrojem a v případě, že nebude umožňovat podporu dalších členů, musel by se nástroj vyměnit a vývojáři by si museli zvykat zas na nové prostředí. Pro hodnocení kritéria se bere v úvahu maximální počet uživatelů, pro který je nástroj schopný zajistit podporu, ale přihlíží se i na funkce zajišťující tuto podporu. Kritérium je hodnoceno následovně: 0: Podpora pouze jednoho vývojového týmu 1: Podpora dvou vývojových týmů 2: Podpora tří vývojových týmů 3: Podpora více vývojových týmů najednou

5.2 Podpora metodik Jak již bylo zmíněno, ne každá metodika se hodí na vývoj úplně všech aplikací. Z tohoto důvodu je dobré, když nástroj podporuje více metodik. Tím totiž umožní vyvíjet různé aplikace pomoci různého způsobu řízení, bez nutnosti vynakládaní dodatečných výdajů na pořízení nového nástroje. Velkou výhodou kombinování více metodik do jednoho nástroje je pokrytí větší oblasti trhu s nástroji a také to, že si uživatelé nemusí zvykat na nové prostředí. Kritérium je hodnocené podle počtu metodik, které nástroj podporuje, zároveň se ale přihlíží i na to zda jde o metodiky rigorózní nebo agilní. V tomto případě byly porovnávané nástroje na podporu agilního vývoj softwaru, pro úplnost jsem ale do škály hodnocení uvedl i možnost pro nástroje podporující i rigorózní metodiky. Hodnocení je následovné: 48

0: Podpora pouze jedné rigorózní metodiky 1: Podpora pouze jedné agilní metodiky 2: Podpora hybridních metodik 3: Podpora dvou a více metodik (agilních či rigorózních)

5.3 Dostupnost nástroje Toto kritérium se zabývá, jakými způsoby lze software pořídit. Pro manažera je totiž důležité zhodnotit i okolnosti vyplývající z užívání nástroje různými způsoby. Například jestli bude nutné pořídit server k užívání nástroje atd. Většina dnešních nástrojů je poskytována buďto formou instalačního balíčků, který je možný nainstalovat na firemní server nebo jsou nástroje poskytovány jako služba. Obzvlášť druhá možnost bývá mezi zákazníky velmi oblíbená a to hlavně kvůli výhodám, které poskytuje. Značnou výhodou je, že společnosti nemusí pořizovat výkonný hardware pro běh aplikace nebo najímat zaměstnance, kteří by měli na starosti bezproblémový provoz. Dalším plusem služby je možnost jejího využívání odkudkoliv na světě, podmínkou je samozřejmě, že počítač, na kterém nástroj používáme, musí být připojený k internetu. Tím pádem není tým omezený pouze na určité prostory, ale vývojáři mohou pracovat např. i z domova. Zřejmě největší výhodou však je to, že za hladký chod aplikace ručí společnost, která jí dodává. Zákazníci si na základě smlouvy určí podmínky, za kterých bude nástroj dodáván a zároveň stanoví i postihy, které budou hrozit poskytovateli v případě, že nástroj nebude možné používat. Zároveň pokud je aplikace dodávaná jako služba, tak je zákazníkům dodána se všemi vylepšeními a každé nové vylepšení je automaticky instalované. Tím zákazníkům odpadá povinnost cokoliv instalovat nebo vynakládat další finanční prostředky za tyto vylepšení. Využívání softwarových nástrojů formou služby však sebou přináší i možné ohrožení firmy. Existuje šance, že dojde k odcizení informací, které jsou archivované u dodavatele nástroje. Proto je důležité nezanedbat výběr poskytovatele a hlavně se bránit co nejlépe sepsanou smlouvou. Dále je velice důležité, aby společnost, která využívá službu měla dobré připojení k internetu, protože tak předejde problémům s přístupem k nástroji ze své strany.

49

Kritérium se hodnotí podle toho kolika různými způsoby lze nástroj pořídit a přihlíží se i na různé možnosti instalací, jako např. přes Windows instalátor nebo VMware, instalace na operační systém Linux atd. Hodnocení jsem stanovil takto: 0: Nástroj je poskytován pouze jako instalační balíček 1: Nástroj je poskytován pouze formou služby 2: Nástroj je distribuován formou služby i jako instalační balíček 3: Nástroj je distribuován oběma formami a poskytuje i další možnosti instalací nástroje

5.4 Pořizovací náklady Pro každého manažera, obzvláště pro ty co právě začínají, budou nejdůležitějším kritériem pro porovnání nástrojů zejména pořizovací náklady. Všechny tři nástroje, které jsem vybral pro porovnání jsou poskytované ve dvou verzích. Jedná se podnikovou (enterprise) a zkušební (trial) verzi a náklady se vždy odvíjí od celkového počtu uživatelů a doby, po kterou je nástroj využíván. Nástroj TeamPulse jako jediný z mnou vybraných nástrojů poskytuje i veřejnou (community) verzi, která je co se týče funkcí omezená oproti podnikové verzi, ale je možné ji pořídit bez poplatku. V mém případě jde o osmičlenný tým složený z manažera a sedmi vývojářů a nástroj bude používaný jeden rok. Pro tento případ jsem zvolil nástroj poskytovaný formou služby, protože se jedná o začínající firmu a odpadnou tak starosti na pořízení hardwaru apod. Jelikož se jedná o nástroje, které poskytují zahraniční společnostmi, jsou náklady uváděné v amerických dolarech nebo eurech. Pro větší přehlednost jsem je dne 20.2.2016 převedl na koruny podle kurzu ČNB. Kritérium je hodnocené pro podnikovou i zkušební verzi zvlášť. Obvykle bývají zkušební verze společnostmi poskytované bez poplatku, jeden z mnou vybraných nástrojů však zpoplatňuje i tuto verzi. Proto hodnocení zkušebních verzí nabývá pouze dvou hodnot, hodnotu 1, kdy je nástroj bez poplatku nebo 0, pro případ kdy se za zkušební verzi musí platit. Z pohledu veřejných verzí jsem nástroje neporovnával, protože tuto možnost poskytuje pouze nástroj TeamPulse. Pro podnikové verze je hodnocení následující: 0: Pořizovací náklady od 30000 Kč výše 1: Pořizovací náklady od 25000 Kč do 30000 Kč

50

2: Pořizovací náklady od 20000 Kč do 25000 Kč 3: Pořizovací náklady do 20000 Kč

5.5 Prvky zajišťující konkurenční výhodu Toto kritérium hodnotí nástroj z pohledu doplňkových funkcí. Doplňkovou funkcí se v tomto případě rozumí prvek, který nemusí přímo souviset s vývojem, ale umožní uživateli nástroje se nějakým způsobem odlišit od konkurence. V dnešní době už téměř všechny nástroje poskytují funkce pro kontrolu průběhu projektu, řízení sprintů, záznam chyb, sledování rozpracovanosti jednotlivých procesů, koordinaci více týmů nebo projektů najednou a mnoho dalších. Například lze na zákazníka zapůsobit tím, že během jednání s ním proberu aktuální průběh vývoje, který bude přehledně zobrazený na tabletu, nebo ho budu moc ujistit, že se jeho projekt zpracovává s vypětím všech sil týmu pomocí grafů vytíženosti apod. Tím se v očích zákazníka odliším od ostatních vývojových společností a otevře se tak příležitost k prohloubení vztahu s ním. Hodnocení kritéria je založeno na prvcích nástroje, které nejsou bezpodmínečně důležité pro vývoj softwaru, ale pozitivně zapůsobí na zákazníka uživatele nástroje. Bodové hodnocení je následující: 0: Nástroj neobsahuje žádné doplňkové funkce 1: Podpora práce na mobilních zařízeních nebo tabletech 2: Nástroj obsahuje portál pro zpracovávání zákaznických požadavků v reálném čase 3: Nástroj poskytuje dvě a více doplňkových funkcí

5.6 Vzhled a úpravy nástroje V průběhu let vzniklo obrovské množství nástrojů, ale bohužel spousta z nich má uživatelské rozhraní velmi nepřehledné nebo ho není možné jakkoliv přizpůsobit. Pro vývojáře bude jistě lepší, když budou mít k dispozici nástroj, ve kterém jim nebude dělat problém se orientovat nebo, ve kterém si mohou uspořádat všechny potřebné funkce podle sebe. V případě, že si vše uspořádají podle svých představ a nebudou se muset neustále „proklikávat“ jednotlivými

51

funkcemi, ušetří si čas i nervy. Zejména ušetření času mne jako manažera zajímá, protože jak se říká: „čas jsou peníze“ a efektivní využívání nástroje zajistí i efektivnější vývoj a tím více peněz. Uživatelské prostředí nástrojů může na každého jedince působit jinak, ale možnost ho přizpůsobit potřebám každého člena týmu by mělo být umožněno vždy. Hodnocení tohoto kritéria je založené hlavně na možnostech přizpůsobení nástroje a přehlednosti jeho uživatelského rozhraní: 0: Nástroj je nepřehledný a neumožňuje ani žádné úpravy 1: Nástroj je nepřehledný, ale lze ho alespoň přizpůsobit 2: Nástroj je přehledný, ale neumožňuje žádné úpravy pro specifické role týmu 3: Nástroj je přehledný a umožňuje navíc úpravy pro specifické role týmu

52

6. Hodnocení nástrojů dle kritérií V této kapitole bude provedeno porovnání nástrojů popsaných v kapitole 5 pomocí stanovených kritérií. Jednotlivé bodové hodnocení kritérií je možné vidět v tabulce 1 a zdůvodnění hodnocení je popsané pod tabulkou. Porovnání je provedeno zprůměrňováním jednotlivých kritérií. Nástroj s nejvyšším průměrným hodnocením je nejvíce vhodný pro můj případ užití. TeamPulse

Urban Turtle

Agilo for Trac

Podpora většího počtu týmů

3

2

3

Podpora metodik

3

3

3

Dostupnost nástroje

3

2

2

Pořizovací náklady enterprise verze

0

2

1

Pořizovací náklady trial verze

1

1

0

Prvky zajišťující konkurenční výhodu

3

1

0

Vzhled a práce s nástrojem

3

3

3

Suma

16

14

12

Průměrné hodnocení

2,3

2

1,7

Tab. 2 Tabulka hodnocení nástrojů (zdroj: autor)

V tabulce 2 můžeme vidět hodnocení jednotlivých kritérií u příslušných nástrojů. Průměrným hodnocení vychází u všech tří nástrojů přibližně stejný výsledek, který se blíži k dvěma bodům, nástroje se od sebe liší pouze třemi desetinami bodů. TeamPulse má ve výsledku hodnocení o tři desetiny lepší než jeho konkurenti. Z toho vyplývá, že pro mnou zvolený případ jen nejlepší volbou nástroj TeamPulse.

6.1 Podpora většího počtu týmů Toto kritérium jsem u nástroje TeamPulse ohodnotil třemi body, protože maximální možný počet uživatelů u tohoto nástroje není nijak omezený. Úvodní balíček může používat sice jen pět uživatelů, je však možné ho rozšířit o libovolný počet uživatelů. Navíc je nástroj velmi

53

robustní a dobře zpracovaný, takže by práce s ním neměla představovat žádný problém i při koordinaci více týmů najednou. Nástroj Urban Turtle byl ohodnocený dvěma body, přestože u něj také není nijak omezený maximálním počtem uživatelů. Stanovený je pouze minimální počet uživatelů, který je pět. Na rozdíl od TeamPulse ovšem není tak komplexní a propracovaný a je proto otázkou jestli by při koordinaci většího počtu týmů, nástroj stále poskytoval efektivní podporu. Agilo for Trac jako jediný z vybraných nástrojů nestanovuje minimální počet uživatelů a proto ho může používat jen jeden uživatel. Na rozdíl od zbylých dvou nástrojů ovšem omezuje maximum uživatelů na 100. Pro jeho přehledné provedení a funkce podporující práci více týmů najednou a organizaci práce skrze týmy byl nástroj ohodnocen třemi body.

6.2 Podpora metodik Všechny tři mnou vybrané nástroje na podporu agilního vývoje softwaru byly z pohledu podpory metodik ohodnocené třemi body. Nejvyšší možné hodnocení u tohoto kritéria získali díky tomu, že v sobě kombinují nejen metodiky Scrum a Kanban, ale také například Lean metodiku.

6.3 Dostupnost nástroje Přestože všechny tři společnosti poskytují své nástroje jak formou služby tak i jako instalační balíček, nezískali stejné bodové ohodnocení. Nástroj TeamPulse oproti svým dvou konkurentům totiž poskytuje ještě řadu instalačních možností. Lze jej používat např. jako zdrojový tarball (pro instalaci na systém Linux), stáhnout v podobě python-egg, VMware apod. Tyto možnosti už u nástrojů Urban Turtle a Agilo for Trac uvedené nejsou a proto jsou ohodnocené dvěma body a TeamPulse získal body tři.

54

6.4 Pořizovací náklady Jak již bylo zmíněno je toto kritérium rozdělené do dvou částí, na pořizovací náklady za trial verzi a za enterprise verzi. Trial verze je u nástrojů TeamPulse a Urban Turtle zcela bez poplatku a lze jí používat třicet dní. Z tohoto důvodu oba tyto nástroje získali jeden bod. Agilo for Trac bylo ohodnocené nulou z důvodu zpoplatnění trial verze. Aby bylo možné používat Agilo trial po dobu třiceti dnů je nutné jednorázově zaplatit částku 784 Kč. U tohoto kritéria, jako jediného, byl nástroj TeamPulse ohodnocen nulou, protože pořizovací náklady za enterprise verzi přesahují částku 30000 Kč. Celkové náklady, na užívání nástroje devíti osobami po dobu dvanácti měsíců, činní 61125,50 Kč, což je téměř třikrát více než konkurenční nabídky. Aplikace je nabízená formou úvodního balíčku, který může používat celkem pět uživatelů za cenu 36725,50 Kč. Tento balíček je možný rozšířit o libovolný počet uživatelů a za každého dalšího uživatele se musí zaplatit 6100,50 Kč. Na webových stránkách nástroje Urban Turtle je k dispozici kalkulátor pro výpočet pořizovacích nákladů. Zde stačí zadat dobu, po kterou bude nástroj používán a počet uživatelů, pro který chceme nástroj pořídit. Po zadání obou parametrů byly pořizovací náklady zkalkulovány na částku 23814 Kč. Jelikož se jedná o částku do 25000 Kč, byl nástroj ohodnocen dvěma body. U aplikace Agilo for Trac jako jediné nebylo možné nastavit přesný počet uživatelů. Pořizovací náklady jsou proto rozpočítány na tým o deseti členech. Celkové pořizovací náklady potom činní 28554 Kč a z toho důvodu získala aplikace jeden bod. Veřejné (community) verze jsem u nástrojů nehodnotil, protože možnost pořízení nástroje touto cestou poskytuje pouze TeamPulse.

6.5 Prvky zajišťující konkurenční výhodu Z pohledu tohoto kritéria jasně vede nástroj TeamPulse a proto byl ohodnocen třemi body. Obsahuje rozhraní pro online zpracování zákaznických požadavků, kam mohou zákazníci nejen přidávat své požadavky, ale zároveň i sledovat v jaké fázi zpracování se nachází. Dále 55

nabízí např. funkci, která kontroluje jednotlivé procesy a zjišťuje u nich zdali byly provedeny v souladu s tzv. best practice. Tím pomáhá vývojovým týmům s osvojením si agilního přístupu k vývoji a zároveň poskytne zákazníkovi jistotu, že se na jeho zakázce pracuje pomocí nejlepších možných postupů. Urban Turtle byl u tohoto kritéria ohodnocen jedním bodem, poskytuje sice podporu práce na mobilních zařízeních, ale jinak poskytuje pouze standardní funkce na podporu vývoje, které je možné nalézt i u konkurenčních výrobků. Agilo for Trac u toho kritéria získalo nula bodů, protože oproti svým konkurentům neposkytuje uživatelům nástroje žádné prvky, díky kterými by se mohl uživatel tzv. „vytáhnout“ nad konkurenci před zákazníkem. I přestože obsahuje funkci Team Management, která je schopna sama vypočítat možnosti vývojového týmu a řadu dalších funkcí podporující vývoj je hodnocení z tohoto pohledu nula.

6.6 Vzhled a práce s nástrojem Všechny tři mnou vybrané nástroje mají velmi pěkně a přehledně zpracované uživatelské rozhraní, které umožňuje jednoduchou navigaci jednotlivými funkcemi. Zároveň všechny poskytují různé možnosti jak si toto rozhraní co nejvíce přizpůsobit vlastním potřebám. Z tohoto důvodu jsem všechny tři nástroje ohodnotil třemi body. Je důležité zmínit, že toto kritérium může každý jedinec hodnotit jinak, protože na každého mohou uživatelská rozhraní jednotlivých nástrojů zanechat jiný dojem. Hlavní však bylo, zdali jsou nástroje přehledné a je možné je upravit a tuto podmínku splňují všechny.

56

Závěr Agilní metodiky vycházejí z nedostatků a chyb předchozích způsobů vývoje softwaru. Z toho vyplývá, že jsou schopné se lépe přizpůsobit současným požadavkům na vývoj. Díky větší flexibilitě se tyto metodiky snáze přizpůsobí měnícím se požadavkům ze strany zákazníka, vývoj je příjemnější, přehlednější a zároveň i levnější. Díky umožnění změn v projektu je mnohem větší pravděpodobnost, že bude projekt dokončen s pozitivním výsledkem a celkově vývoj zabere kratší dobu. Zároveň agilní metodiky odstraňují bariéry mezi zákazníkem a vývojáři a díky pravidelným dodávkám funkčních verzí se docílí i větší spokojenosti zákazníků. Vývoj nástrojů na podporu agilního vývoje softwaru nemá dlouhou historii, přesto už vznikla celá řada nástrojů, které se zaměřují na různé metodiky vývoje nebo na různé funkce (jako řízení projektu, řízení požadavku, atd.). Většinou se jedná o nástroje, které jsou stále ve fázi vývoje nebo nástroje, které podporují pouze jednu metodiku nebo funkci. V současné době se ovšem nástroje snaží stále více začlenit větší počet funkci nebo metodik do jednoho uceleného prostředí. Dle mého názoru jde o správný směr a kombinováním různých metodik a začleněním více funkcí do jednoho nástroje se dosáhne přesnějších a výkonnějších nástrojů. Řízení projektů pomocí agilních metodik zatím není v České republice rozšířené, tak jako v zahraničních zemích. Kvůli tomu jsem se při psaní práce opíral o informace z elektronických zdrojů, jako například webové stránky poskytovatelů nástrojů. Tyto zdroje nejsou příliš objektivní, protože každý z poskytovatelů nástrojů popíše z důvodu velké konkurence pouze klady svého nástroje a nalézt zápory konkrétního nástroje je potom velice obtížné. Na základě porovnání kritérií stanovených v kapitole 5, vyšla jako nejlepší volba nástroj TeamPulse, ten získal nejvíce bodů (celkem 2,3) ze všech vybraných nástrojů. Tento nástroj je velmi rozsáhlý a poskytuje celou řadu funkci pro lepší přehled a řízení projektů. Oproti své konkurenci, která je popsána v kapitole 4 obsahuje mnohem více prvků na podporu práce většího počtu týmů i řízení práce skrze týmy. Velkou výhodou tohoto nástroje je online portál sloužící k vyřizování zákaznických požadavků integrovaný přímo do uživatelského prostředí nástroje. Veškerý postup v projektu, včetně vytíženosti jednotlivých vývojářů, je možné

57

zákazníkům předvést přímo na mobilních zařízeních. Největší předností tohoto nástroje však je prvek Best Praktice Analyzer, který vývojářům usnadňuje přijetí agilních metodik tak, že kontroluje provedené úkoly a ověřuje zda-li byly splněny pomocí ověřených agilních postupů. Nástroj TeamPulse získal nula bodů pouze u jednoho kritéria. Tímto kritériem jsou pořizovací náklady, které jsou zde vůči konkurentům nejvyšší. Nejhoršího výsledku dosáhl nástroj Agilo for Trac, který po zhodnocení všech kritérií získal pouze 1,7 bodů. Nástroj Urban Turtle 4 získal dva body a umístil se tak na druhé místo za TeamPulse.

58

Seznam použité literatury: BUCHALCEVOVÁ, Alena. Metodiky budování informačních systémů. Vysoká škola ekonomická v Praze. Praha: Oeconomica, 2009. ISBN 978-80-245-1540-3 Software engineering – Wikipedia, the free encyclopedia. ©2016 [online]. [cit. 2015-11-12] Dostupné z: http://en.wikipedia.org/wiki/Software_engineering Expert Project Management-The Role of the Project Life Cycle (Life Span) in Project Management. [online]. [cit. 2015-10-11] Dostupné z: http://www.maxwideman.com/papers/plc-models/1990s.htm KADLEC, Václav. Agilní programování – Metodiky efektivního vývoje softwaru. Brno: Computer Press, 2004. ISBN 80-251-0342-0

Principles behind the Agile Manifesto. ©2007 [online]. [cit. 2015-12-11] Dostupné z: http://www.agilemanifesto.org/principles.html

The Agile Unified Process (AUP). ©2014 [online]. [cit. 2015-10-10] Dostupné z: http://www.ambysoft.com/unifiedprocess/agileUP.html Unified Process. ©2014 [online]. [cit. 2015-12-10] Dostupné z: http://www.bawiki.com/wiki/concepts/sdlc-process-models/unified-process/ ŘEPA, Václav. Analýza a návrh informačních systémů. Praha: Ekopress, 1999. ISBN 80-86119-13-0 BECK, Kent: Extrémní programování, Praha: Grada Publishing, 2002. ISBN 80-247-0300-9 BECK, Kent: Programování řízené testy, Praha: Grada Publishing, 2004. ISBN 80-247-0901-5

59

ABRAHAMSSON, Pekka a Outi SALO a Musei RONKAINEN a Johani WARSTA: Agile software development methods: Review and analysis, VTT Technical Research Centre of Finland, 2002. ISBN 951-38-6010-8 Principles Agile Modeling. ©2001-2014 [online]. [cit. 2016-01-02] Dostupné z: http://www.agilemodeling.com/ KNESL, Jiří, 2009. Agilní vývoj: Scrum. [online]. [cit. 2016-04-02] Dostupné z: https://www.zdrojak.cz/clanky/agilni-vyvoj-scrum/ A (Very) Short History of Kanban. ©2015 [online]. [cit. 2016-08-02] Dostupné z: http://leankit.com/learn/kanban/what-is-kanban/ Tools And Technology. ©2004 [online]. [cit. 2016-10-03] Dostupné z: https://www.forrester.com/search?N=10001&range=504005&sort BUCHALCEVOVÁ, Alena. Metodiky vývoje a údržby informačních systémů. 1. vydání. Praha: Grada, 2005. ISBN 80-247-1075-7 A collection of Agile add-ons to manager your project from A to Z. ©2015 [online]. [cit. 2016-05-03] Dostupné z: http://www. urbanturtle.com/en/features/ Agilo for trac – Feature list. ©2014 [online]. [cit. 2016-07-03] Dostupné z: http://www.agilofortrac.com/features/ Scrum, Kanban or Any Process You Need.. ©2002-2016 [online]. [cit. 2016-10-03] Dostupné z: http://www.telerik.com/teampulse/features/scrum-kanban HANZALOVÁ, Marie a Markéta JUSTOVÁ. 2013. Přehled a kategorizace nástrojů pro agilní vývoj SW. Semestrální práce. Praha: VŠE. Vedoucí práce Alena Buchalcevová

60

Seznam obrázků Obrázek 1: Tradiční a agilní vývoj softwaru ........................................................................... 10 Obrázek 2: Vodopádový model ............................................................................................. 13 Obrázek 3: Volba odpovídající Crystal metodiky ................................................................... 25 Obrázek 4: Ukázka prostředí Urban Turtle ............................................................................ 37 Obrázek 5: Ukázka prostředí TeamPulse ............................................................................... 40 Obrázek 6: Ukázka prostředí Agilo for Trac ........................................................................... 43

Seznam tabulek Tabulka 1: Tabulka agilních nástrojů .................................................................................... 36 Tabulka 2: Tabulka hodnocení nástrojů ................................................................................ 53

Seznam zkratek Atd.

–

A tak dále

Tzv.

–

Takzvaný

Obr.

–

Obrázek

Např.

–

Například

Apod. –

A podobně

61