Masarykova univerzita

Transkript

1 Masarykova univerzita Fakulta informatiky Systém pro řízení agilních projektů Diplomová práce Petr Tvarůžek Brno, 2013

2 Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval(a) samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal(a) nebo z nich čerpal(a), v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.... Vedoucí práce: Ing. Leonard Walletzký, Ph.D. 2

3 Poděkování Chtěl bych poděkovat Ing. Leonardu Walletzkému, Ph.D. za odborné vedení mé diplomové práce a za cenné připomínky. Dále bych chtěl poděkovat RNDr. Zdenko Staníčkovi, Ph.D. za konzultace a připomínky o agilních metodikách. 3

4 Shrnutí Práce ve své teoretické části zkoumá současné trendy v agilním vývoji software, seznamuje se základními pojmy a metodikami. Dále se zabývá pojmem startup, jeho definicí a charakteristickými rysy. V prostředí startupů zkoumá používaný podnikový software a na základě zjištěných informací v praktické části navrhuje a implementuje systém pro podporu agilního vývoje vhodný právě pro tyto firmy. Abstract In the theoretical part of this thesis we investigate contemporary trends in agile software development, introduce basic terms and methodologies. We further deal with the term startup, it's definition and characteristics. Among startups we investigate the commonly used business software and based on the research we propose and implement a system in the practical part, which supports agile development in these small companies. Klíčová slova Agilní metodiky, startup, malé a střední podnikání, SCRUM, Extrémní programování, Kanban Keywords Agile methodology, startup, small and medium enterprise, SCRUM, Extreme programming, Kanban 4

5 Obsah 1. Úvod a motivace Definice startupu Definice na základě kritérií Evropské komise Definice na základě charakteristických znaků Agilní metodiky Manifest agilního vývoje Extrémní programování Scrum Development Process Kanban Rizika zavádění agilních metodik Existující řešení na trhu Systémy pro řízení projektů JIRA TRAC Redmine Ekonomické systémy Altus Vario Průzkum používaného softwaru Návrh a implementace Závěr Literatura

6 1. Úvod a motivace Počátkem devadesátých let dvacátého století se na poli vývoje softwaru začaly rodit metodiky, které později v roce 2001 [1] získávají označení "Agilní", podle tzv. Agilního manifestu [2]. Agilní metodiky, jak už z názvu vyplývá, mají přispívat k větší flexibilitě při vývoji. Využívají iterativní vývoj, podporují informační toky mezi vývojovým týmem a zákazníkem a tím se snaží omezit nedorozumění a být lépe připravené na změny priorit při vývoji. I po deseti letech existence jejich význam stále roste. Postupem času si agilní metodiky našly své místo i v korporátní sféře a čím dál tím víc podniků je využívá, nebo o jejich využití uvažuje. V této práci se zaměřuji zejména na menší, nebo teprve vznikající podniky, které se rozhodly agilní metodiky používat. Jejich postavení je v řadě případů specifické. Jedná se o velice důležitou skupinu podniků, která má velký vliv na ekonomiku. Ze statistik [3] Unie malých a středních podniků ČR vyplývá, že 99,8% podniků v České republice spadá do kategorie malých a středních podniků (MSP), z toho 95% jsou "mikropodniky", tedy firmy s 0-9 zaměstnanci. Podílejí se na 62 procentech celkové zaměstnanosti, 55 procentech vyprodukované přidané hodnoty a zhruba na 50 procentech vývozu naší ekonomiky. Přibližně stejné podíly platí průměrně v celé Evropské unii. [4]. Jsou to však zároveň podniky, které vykazují nejvyšší fluktuaci - bouřlivě vznikají, ale také velká část z nich zanikne během svých prvních let existence. Podle slov analytika útvaru makroanalýz ČSÚ Ing. Václava Kupky: Existují zřejmě překážky ideálnímu životnímu cyklu MSP, totiž přechodu do fáze expanze po počáteční fázi startu, čili přechodu z kategorie drobných podniků mezi malé, zatímco malé podniky obtížně odolávají konkurenci středních. [5] Na tyto překážky rozvoje, nebo problémy při vzniku, se v této práci budu dále soustředit a navrhnu pro potřeby takových firem informační systém, který jednak pomůže tyto překážky překonat a zároveň poskytne nástroje pro podporu agilních metodik. Agilní metodiky a malé firmy se zdají být na dynamickém trhu IT jako vhodná kombinace. Jednak proto, že agilní metodiky jsou relativně novým fenoménem a malé firmy zpravidla rychleji a ochotněji takové nové trendy sledují a implementují. Druhým důvodem je to, že prostředí, ve kterém se tyto firmy vyskytují, je samo o sobě velice proměnlivé a firmě tedy nezbývá nic jiného, než umět se rychle přizpůsobovat. 2

7 V následujících kapitolách této práce se budu věnovat průzkumu existujících řešení na českém trhu a budu zkoumat jejich vliv na efektivitu malých firem, a také jejich úroveň podpory agilních metodik. Najdeme sice mnoho firemních informačních a ekonomických systémů, nebo nástrojů na podporu agilního vývoje, ale jsou buď nedostupné pro malé a vznikající firmy, anebo nepokrývají obě potřebné stránky - ekonomickou a metodickou. Podnikatelé pak často musí kombinovat více nástrojů zároveň, data mezi nimi ručně přenášet z jednoho systému do druhého a tvořit si tabulky v Excelu, což je v dnešní době zbytečně zdlouhavé a neefektivní. Nebudu se zaměřovat na jednu konkrétní metodiku, protože v praxi se agilní metodiky při nasazování často ohýbají pro potřeby dané firmy, nebo se různě kombinují a implementují pouze částečně 1. Cílem je spíše vytvořit prostředí, které by firmě poskytlo nástroje pro firemní administrativu, strategické rozhodování a finanční přehled a zároveň usnadnilo zavedení některé agilní metodiky. Sledování finančního vývoje a efektivity lze provádět za pomocí vhodně zvolených výkonnostních indikátorů. 1 Třeba metodika Crystal k takovému postupu přímo vybízí [6] 3

8 2. Definice startupu Nejdříve je potřeba se zaměřit na vymezení podniků, které lze označit jako startupy. V současné době neexistuje všeobecně uznávaná definice pojmu "startup", proto se jej v této kapitole pokusím definovat alespoň pro účely této práce. Slovo "startup" (psáno také "start-up") pochází z angličtiny a znamená nastartování, spuštění, uvedení do provozu. Dnes je hlavně používáno pro označení téměř jakýchkoliv vznikajících firem, nebo projektů, často teprve ve fázi přípravy podnikatelského záměru. Jedná se zpravidla o projekty s inovativním a originálním nápadem. 2.1 Definice na základě kritérií Evropské komise Při hledání definice startupu lze vycházet z kategorizace podniků podle Evropské komise [7]. Ta využívá několik kritérií: počet zaměstnanců roční obrat nebo bilanční suma nezávislost Podrobně je kategorizace popsána v následující tabulce. Kategorie Počet Roční obrat podniku zaměstnanců Roční bilanční suma Střední < mil. 43 mil. Malý < mil. 10 mil. Mikro < 10 2 mil. 2 mil. Kritérium nezávislosti je splněno pokud minimálně 75 % základního kapitálu a hlasovacích práv je ve vlastnictví podniku, který splňuje kritéria MSP. Tato definice MSP je značně široká a v praxi dochází v ČR často k odlišnému intuitivnímu pojetí velikosti podniku. Veřejnost a podnikatelé většinou označují jako "velký" již střední podnik.[8] To nic nemění na tom, že se jedná o velice specifickou a důležitou skupinu podniků, která má velký vliv na ekonomiku. Startupy v pojetí této práce budou určitě spadat do kategorie mikropodniků, jelikož mají nízké obraty a zároveň vzhledem k jejich krátké existenci mívají méně než 10 4

9 zaměstnanců. Vznik podniku například formou dceřinné společnosti, kdy je možné, že už při vzniku bude mít podnik více než 10 zaměstnanců, nepovažujeme za startup. 2.2 Definice na základě charakteristických znaků Dalším způsobem, jak vymezit pojem startup, je zaměřit se na společné znaky takových podniků. Podle definice českého Angel investora Ondřeje Bartoše je startup charakterizován takto: [9] "Vzhledem k tomu, že se tento výraz začal používat v souvislosti s boomem technologického a internetového podnikání, zpravidla se start-upem rozumí začínající firma vyvíjející či využívající nové technologie nebo Internet. Další charakteristikou start-upu je pak zájem o růst, neboli záměr zakladatelů a managementu dosahovat v budoucnu výraznější pozice na trhu, případně expanze na další trhy, nejčastěji s použitím vnějšího financování. Proto se dále rozlišují startupy zafinancované a nezafinancované podle přítomnosti či nepřítomnosti vnějšího financování od investorů." Z této i dalších dostupných definic lze vysledovat určité opakující se charakteristiky, které jsem shrnul do několika bodů: Jedná se o nově založené firmy - za startup můžeme většinou považovat společnost mladší než 3 roky. Většinou vykazují záporný hospodářský výsledek - v počátku se startupy soustředí na vybudování vlastního podniku a to vyžaduje investice, kvůli nímž nevykazují zisk. Také než se startup prosadí mezi konkurencí, má relativně málo zákazníků, takže negeneruje dostatečný obrat. Soustředí se nejprve na tvorbu nehmotného majetku. Často mají nebo shání investory, kteří budou zároveň mentory - pro investory se jedná o vysoce rizikové investice a těmto specifickým typům se věnují zejména tzv. Angel investoři, nebo Venture Capital investoři. Nejčastější forma společnosti je společnost s ručením omezeným. Na akciovou společnost zpravidla nemají dostatečný kapitál a forma s.r.o. dovoluje narozdíl od OSVČ lepší ochranu v případě krachu. Inovativní přístup + mnoho nejistoty 2 2 "My definition of a startup: a human institution designed to create new products and services under conditions of extreme uncertainity" [10] 5

10 Mladý a malý tým (mikropodniky - malé podniky) Žádné nebo malé předchozí zkušenosti Výhodou oproti větším podnikům je zejména pružnost a rychlost odezvy na změnu trhu, což je dáno jednodušší strukturou a tím rychlejším přijímáním rozhodnutí. Nevýhodou je zejména větší závislost na dodavatelích i zákaznících a menší schopnost eliminovat důsledky výkyvů vnějších vlivů [5][11] V souvislosti s cílem této práce je zajímavý také faktor absence podrobného marketingového plánování. Startupy většinou nevyhledávají žádný plánovací ekonomický software, protože mají pocit, že jej nepotřebují [12]. Do jisté míry je to pravda, protože dokud je tým malý a zákazníci přicházejí převážně na základě doporučení, pak je možné udržovat alespoň rámcový přehled pouhým sledováním bankovního konta. V kapitole 5. Průzkum používaného softwaru jsou uvedeny výsledky dotazování na používaný software, které tuto tezi potvrzují. Většina startupů používá pouze nejnutnější nástroje, které potřebuje ke splnění zákonné daňové evidence, a pokud provádí finanční přehledy, pak většinou pouze intuitivně na základě jednoduchých reportů z účetnictví nebo z bankovního konta. Jakmile ale podnikatel začne najímat více zaměstnanců, musí přecházet na sofistikovanější řešení, což je mnohem náročnější na lidské i finanční zdroje (rozsáhlejší účetní systémy, účinné a konkurenceschopné metody řízení atd.) [3] 6

11 3. Agilní metodiky Mezi charakteristikou startupů a agilních metodik existuje několik společných bodů. Agilní metodiky jsou vhodné pro malé týmy - uvádí se do 10 členů, ideálně okolo 5. Zvyšují flexibilitu a rychlost reakce na změnu, což je pro prostředí startupů důležité. Mladé týmy ochotněji přijímají nové metodiky a preferují nízkou úroveň administrativy, proto jim nevyhovují rigorózní metodiky s velkou režií. Agilní metodiky jsou tedy z tohoto pohledu vhodným řešením. V této kapitole stručně zmiňuji okolnosti vzniku agilních metodik a popíšu tři vybrané metodiky - Scrum, extrémní programování a Kanban. Agilní metodiky byly v posledních několika letech v centru zájmu mnoha odborníků i uživatelů a vzniklo o nich mnoho literatury. Proto popisu obecných principů a výhod bude věnován menší prostor. Pro podrobnější seznámění může sloužit například zdroj [6]. 3.1 Manifest agilního vývoje Jak již bylo zmíněno v úvodu, zrod agilních metodik bývá dáván do souvislosti s tzv. Agilním manifestem. Obsah manifestu je velice krátký, nepopisuje konkrétní metodiku. Jeho jádrem jsou pouze 4 obecné body: Jednotlivci a interakce před procesy a nástroji Fungující software před vyčerpávající dokumentací Spolupráce se zákazníkem před vyjednáváním o smlouvě Reagování na změny před dodržováním plánu S dovětkem: "Jakkoliv jsou body napravo hodnotné, bodů nalevo si ceníme více." Tyto body udávají směr a shrnují hlavní principy, které jsou charakteristické pro všechny metodiky z agilní rodiny. Vychází ze dvou základních myšlenek: "Přijmout a umožnit změnu je mnohem efektivnější, než pokoušet se jí zabránit", a "Je třeba být připraven reagovat na nepředvídatelné události, neboť ty bezpochyby nastanou (jedinou jistotou je změna)".[6] Tyto myšlenky jsou v ostrém rozporu s principy, o které se opírají starší rigorózní metodiky softwarového vývoje, jako například vodopádový životní cyklus, nebo prototypování. Tradiční metodiky vycházely z předpokladu, že množina požadavků je neměnná, stanovená na začátku vývoje, často zakomponovaná do smluv. Mnoho času bylo věnováno formální analýze, specifikaci a dokumentaci, protože se počítalo s tím, že projekt bude existovat ještě dlouhá léta. V letech , kdy na akciových trzích praskla tzv. internetová bublina a situace kolem IT firem se náhle začala bouřlivě měnit, se stal tento předpoklad fatální. Zákazníci potřebovali 7

12 přehodnocovat své priority i v průběhu vývoje softwarového produktu, jinak hrozilo, že získají sice předem specifikovaný a dokonale zdokumentovaný software, ale ten bude v době vydání už naprosto nepoužitelný. V reakci na softwarovou krizi se několik odborníků začalo věnovat zkoumání příčin selhání projektů. Mnozí z nich pracovali na návrhu nových metodik, které by na softwarové inženýrství pohlížely z opačné strany. Místo aby se pokoušely dokonale specifikovat a zakonzervovat podmínky, ve kterých projekt vzniká, přijímají změny jako součást životního cyklu a pružně na ně reagují. Tito lidé se pak v únoru 2001 sešli v americkém Utahu a vzájemně porovnali své závěry. Z nich pak vytvořili právě Manifest agilního vývoje. Mezi nejznámější účastníky patří Martin Fower, Alistair Cockburn, Kent Beck, Ward Cunningham, Jeff Sutherland. Jména všech účastníků jsou uvedena na stránkách spolu s výše zmíněnými 4 body manifestu a rozšířeným popisem 12 hlavních principů. 3.2 Extrémní programování Extrémní programování (XP), je považováno za ikonu a základní ztělesnění agilních programovacích technik [6]. Autorem je Kent Beck, jeden ze signatářů agilního manifestu a expert na vývoj softwaru. Vznik XP se datuje do roku Od ostatních agilních metodik se odlišuje zejména tím, že základní myšlenky agilního vývoje dotahuje opravdu do extrémů. Zdrojový kód je považován za jediný exaktní, jednoznačný, změřitelný, ověřitelný a nezpochybnitelný zdroj informací. V zájmu zachování jednoduchosti doporučuje vždy hledat tu nejjednodušší podobu systému, která vyhovuje požadavkům. Dále zavádí pojem "párové programování", tedy dva programátoři, sedící u jednoho počítače, s jednou klávesnicí, řešící jeden problém. Tím je zajištěno, že každý kód projde ihned revizí. Agilní metodiky obecně doporučují automatizované testování. Extrémní programování, stejně jako například metodika Test Driven Development, předepisuje psát testy dříve než samotný kód. Testy slouží jako specifikace požadovaného výsledku. V XP je navíc testování opět dovedeno do extrému - mělo by pokrývat 100% kódu a akceptační testy dokonce má psát sám klient. Extrémní programování zavádí pojem "Continuous Integration", tedy průběžná integrace [13]. Dle této metody by měl každý vývojář pravidelně (nejlépe denně) svou část práce sestavovat a testovat se zbytkem systému (integrovat). Cílem je odhalit případné chyby co nejdříve. K systémové integraci lze využít speciální nástroje - integrační servery - které všechny úkony integrace provedou automatizovaně, například v předem stanovených časových intervalech, nebo v návaznosti na nějaký úkon programátora (typicky tím úkonem bývá odeslání nové úpravy do centrálního úložiště zdrojových kódů). 8

13 Zajímavé také je, že XP zahrnuje týmové oslavy přímo do vývojového procesu. Jsou přímo součástí metodiky, například po prvním zprovoznění u zákazníka, po dokončení každého cyklu údržby a nakonec i rozlučková oslava po "smrti" projektu. [14] Extrémní programování je mezi odbornou veřejností často přijímáno s obavami a pochybnostmi. [cit. Václav Kadlec] V zemi svého původu (USA), je přijímána výrazně vřeleji, protože více zapadá do tamní mentality. Rozhodně platí, že ne každý člověk je vhodný do XP týmu. Lidskému faktoru, motivaci a rolím v týmu je také v XP oproti jiným metodikám věnována mnohem obsáhlejší část. Dle mého názoru není XP pro české prostředí nejvhodnější metodikou. Párové programování přináší značné zvýšení nákladů, ale k tomu, aby přineslo i stejné zvýšení efektivity, je zapořebí, aby všichni členové týmu táhli za jeden provaz a maximálně se koncentrovali na řešení zákazníkova problému. Drobné neshody mezi členy týmu jsou tomu velkou překážkou. Přesto lze využít výhod párového programování, a to tím, že jej omezíme pouze na řešení specifických náročných problémů. V případech, kdy je nutno zasáhnout například do velmi starých kódů, nebo provést nějakou větší změnu v části systému, na které je mnoho dalších komponent závislých, se vyplatí programovat ve dvojicích. Jeden programátor píše kód, zatímco druhý jej kontroluje a hlídá, aby nebyly porušeny externí závislosti. Průběžně se domlouvají na nejlepším postupu při návrhu algoritmu a po nějakém čase se mohou vystřídat. Pro rutinní programování jednoduchých tříd není potřeba programovat ve dvojicích, protože přidaný efekt nebude tak výrazný. 3.3 Scrum Development Process Název "Scrum" je odvozen od pojmu z ragby. V češtině znamená "skrumáž", "mlýn", "tahanice" a je tím označována situace, kdy se týmy při rozehrávce shromáždí nad míčem v těsné formaci a snaží se míč dotlačit blíže k cíli. Převedeno do softwarového vývoje se jedná zejména o společné úsilí týmu a o postupování ve vzájemné shodě. Za jednu z nejdůležitějších součástí agilních metodik je považována efektivní komunikace. Typickou součástí Scrumu jsou krátké každodenní porady týmu, kde každý člen referuje o tom, co za uplynulý den dělal, co hodlá dělat nyní a případně jestli narazil na nějaký nový problém. Schůzek se můžou účastnit i nečlenové týmu, ti ale mohou pouze přihlížet a ne do nich zasahovat. Přínosem je dřívější odhalení problémů v týmu i v projektu a tedy lepší možnost na ně včas reagovat. Kromě každodenních porad metodika zavádí roli "scrum mastera", což je samostatná role člena týmu, jehož úlohou je hlídat dodržování metodiky, moderovat týmové diskuze a odpovídat na otázky ohledně procesů. Role v týmu jsou definovány podrobněji, než u ostatních agilních metodik. 9

14 Při vývoji pomocí Scrumu je projekt rozdělen do iterací, tzv. "sprintů". Sprinty jsou relativně krátké, doporučuje se délka od 2 týdnů, do 2 měsíců. Pro malé týmy je možno zavést i krátké iterace v délce jednoho týdne. Do sprintu se zařazují úkoly z projektového zásobníku úkolů, tzv. "backlogu". V každém sprintu se prochází celý životní cyklus - od analýzy až po závěrečné otestování. Na začátku při zařazování úkolů z backlogu do sprintu vytváří vývojový tým odhady náročnosti, k čemuž se využívá technika zvaná "plánovací poker" nebo také "Scrum poker". Členové týmu v něm pomocí kartiček s čísly určují náročnost jednotlivých úkolů. Čísla na kartičkách ale neodpovídají přímo hodinové zátěži, vyjadřují pouze relativní složitost, a jejich konkrétní význam si většinou každý tým upraví podle sebe. Scrum je v současnosti jednou z nejrozšířenějších a nejpopulárnějších agilních metodik. V roce 2006 byl proveden průzkum pod názvem Agile Adoption Survey, kterého se zůčastnilo 4235 respondentů. Dle něj mezi nejvíce používané metodiky patří XP (954), Feature Driven Development (502), Scrum (460) a Agile Unified Process (216)[15] [16]. O dva roky později ukázal další průzkum[17], provedený společností Vision One, že Scrum využívá 49% dotázaných, dalších 22% kombinuje Scrum s Extrémním programováním a 8% používá klasické Extrémní programování. V průběhu posledních let se ukázalo, že metodiku Scrum lze použít pro některé problémy i mimo oblast vývoje softwaru [18]. Například práce konstruktérů ve strojírenství je v několika ohledech s prací programátora podobná. Obojí jsou úzce specializované disciplíny, vyžadující kreativní a inteligentní lidi. Manažeři takových týmů často sami nemají dostatečné znalosti, aby mohli člena týmu v případě potřeby plnohodnotně zastoupit. U takových týmů by pravděpodobně bylo možné s úspěchem využít denní porady a iterativní vývoj. Bylo by jistě zajímavé tuto tezi ověřit v samostatné studii, nejedná se však o účel této práce. 3.4 Kanban Pojem Kanban pochází z japonštiny a znamená "cedule", "kartička", nebo obecně "vizuální signál". Autor Taiiči Óno vytvořil tento systém pro Japonskou automobilku Toyota v roce 1953 [19], kde sloužil k řízení výroby součástek. Lze ji zařadit do výrobního procesu typu "Just-in-time", tedy takového, který je řízen aktuální potřebou. Původní Kanban je zaměřený na výrobu součástek a nemá nic společného s vývojem softwaru. Pokud mluvíme o Kanbanu jako agilní metodice, pak se jedná spiše o použití principů Just-in-time a řízení poptávkou v softwarovém procesu. Základní filozofií Kanbanu je klást důraz na následující body: Neodesílat defektní výrobek k dalšímu zpracování (důraz na 100% kvalitu) Následný proces si vyžádá jen nutné množství polotovaru 10

15 Vyrábět jen přesně tolik, kolik vyžaduje následný proces zpracování Přesné nastavení úrovně výroby (Production leveling) Kanban je prostředkem k jemnému doladění výrobního procesu Stabilizace a racionalizace procesu V oblasti vývoje softwaru se z Kanbanu používá zejména Kanban board, tedy tabule, kde jsou zobrazeny jednotlivé stanoviště a kde dochází k ladění procesu. Za stanoviště můžeme považovat stavy, ve kterých se úkol nachází (nový, rozpracovaný, k otestování,...), nebo také role členů týmu, které se na úkolu podílí (analytik, manažer, developer, grafik, tester,...). Kanban board pak může vypadat například následovně: V levém sloupci jsou úkoly, které je potřeba vyřešit. Postupně jak se na úkolu pracuje, tak se posouvá stále více doprava, až do posledního sloupce s hotovými úkoly. Z obrázku je patrné, kterými kroky musí každý úkol projít. Každý sloupec má navíc přiřazený určitý limit - kapacitu. Jakmile je u některého sloupce kapacita dosažena, nebo překročena, signalizuje to slabé místo procesu a je na manažerech aby jej vhodným způsobem optimalizovali. Například z výše uvedeného obrázku lze identifikovat úzké místo v kroku Develop, protože jeho kapacita je téměř dosažena a následující krok Test naopak není téměř vytížen. Dvě prázdné pole ve sloupci Test reprezentují poptávku, kterou je potřeba ze sloupce Develop vyplnit tím, že se dokončí dva úkoly. Pokud by k takové situaci docházelo opakovaně, je na místě navýšit kapacity pro krok Develop, snížit kapacity pro krok Test (zde se nabízí možnost některé testery přesunout do role programátorů), anebo jinak vhodně posílit plynulost průchodu celým procesem. Účelem Kanbanu je zajistit konstantní rychlost dodávky hotových produktů. Je možná i kombinace Kanbanu se Scumem, kde Kanban je využívaný na řízení vývoje uvnitř jednoho Scrum sprintu. Takové kombinaci se pak přezdívá Scum-ban [20]. 11

16 3.5 Rizika zavádění agilních metodik Při zavádění agilních metodik do procesů firmy hrozí určitá rizika. Vzhledem k tomu, že některé z metodik existují již přes 10 let, objevují se reálné závěry z použití v praxi. Uvádím je zde hlavně proto, aby bylo možno se vyhnout častým chybám při zavádění metodiky do nového prostředí. Každá změna přináší rizika, důležité je o nich vědět a umět se s nimi vyrovnat. Několik zdokumentovaných případů [21] [22] zavádění agilních metodik do existujících podniků uvádí výčet problémů, se kterými se účastníci potýkali. Lze je v zásadě shrnout do dvou základních skupin: 1. neochota zúčastněných osob změnit své zaběhnuté procesy a to jak na straně zákazníků, tak uvnitř firmy; nedůvěra v nové postupy. 2. nedokonalé pochopení agilních principů. Neochota přijmout změnu se projevuje například v nechuti k pravidelným denním schůzkám, neochotě plnit testovací scénáře a nechuť týmu komunikovat se zákazníkem [22]. Zákazníci jsou zvyklí na vodopádový životní cyklus vývoje, který považují za prověřený. V agilních týmech je nezbytné aby všichni účastníci včetně zákazníka věděli, jaké výhody jim agilní přistup přinese. Ve startupech je toto riziko nižší, protože jak bylo specifikováno v kapitole Definice startupu, jsou typicky tvořeny malými a mladými týmy a jejich motivace je vysoká. Proto u nich můžeme předpokládat vyšší ochotu své postupy měnit, a tím pádem nižší riziko při osvojování agilních metodik. Naopak vyšší bude toto riziko u větších a déle fungujících týmů, nebo jsou-li tvořeny členy s dlouhou pracovní historií. Problém odmítnutí ze strany zákazníka žádná z agilních metodik explicitně neřeší a proto se firmy snaží metodiky v této oblasti nějakým způsobem přizpůsobit. Je například možno realizovat agilní vývoj uvnitř standardního rámce řízení projektů. Ve vztahu k zákazníkovi a dalším zainteresovaným je projekt řízen tradičně jsou sebrány požadavky a je dohodnut kontrakt. Uvnitř tohoto rámce je pak ale projekt vyvíjen agilně v iteracích. [16]. Druhému základnímu problému - chybám v pochopení agilních principů - se věnuje například český programátor a školitel Jiří Knesl v přednášce s názvem Cargo Scrum [23]. Označení Cargo Scrum, nebo také Cargo cult Scrum vychází z Cargo kultů, náboženských hnutí v Melanésie, které se domnívaly, že opakováním rituálů bílých návštěvníků získají sami darem od bohů hodnotné zboží cargo. Použitím agilních nástrojů a technik, jako jsou například každodenní schůzky, párové programování, nebo backlogy, ale zároveň bez hlubšího pochopení zeštíhlovacích agilních principů, nelze úspěchu dosáhnout. Chybnou interpretací zásad agilních přístupů dochází k různým hybridním pojetím konkrétních metodik, jejichž výsledky nepřináší kýžené 12

17 zlepšení. Mezi nejčastější chyby při zavádění Scrumu do podniků v ČR řadí Jiří Knesl následující: komunikační bariéry mezi vývojovým týmem a zákazníkem implementace pouze některých nástrojů, ale přitom zachování původních neagilních procesů omezování autonomie vývojářů managementem (šéf má poslední slovo) tlak na růst produktivity, ale ne na růst kvality úplné odmítnutí zavedení opakovatelných procesů nebo plánování přidávání nových úkolů do aktuálně probíhajícího sprintu Tento problém lze úspěšně vyřešit nebo minimalizovat například tím, že roli Scrum mastera bude zastávat externí najatý konzultant, který má zkušenosti s implementací Scrumu v jiných firmách. 13

18 4. Existující řešení na trhu 4.1 Systémy pro řízení projektů JIRA JIRA je jedním z produktů společnosti Atlassian. Tento systém je určen k řízení projektů a požadavků. Jedná se o webový systém napsaný v programovacím jazyku Java. Disponuje repozitářem doplňků (pluginů), jejichž instalací lze obohatit systém o další funkce. Jedním z významných dopňků je Greenhopper, který poskytuje nástroje určené pro řízení projektů agilními metodikami. Konkrétně poskytuje dělení projektu do iterací - Scrum sprintů - a podporuje určování náročnosti úkolů v bezrozměrných jednotkách tzv. "story pointech". Dále umožňuje zobrazit průběh práce v tabulce podobné Kanban boardu. Za zmínku dále stojí integrace s dalšími produkty společnosti Atlassian, jako je Confluence - publikační systém ve stylu wiki, ve kterém lze psát dokumentaci k projektům, nebo Bamboo - systém pro Continuous Integration (viz Extrémní programování). JIRA je využívána i mezi korporátními zákazníky, protože jim nabízí kompletní podporu včetně veškeré konfigurace systému vlastními odborníky. Nevýhodou tohoto produktu pro malé firmy je cena za pořízení. Cenová politika je v současnosti postavená na počtu uživatelů, kteří budou mít do systému přístup. Pokud by podnik chtěl vyvíjet agilně a do procesu zapojit i zákazníka, je velmi pravděpodobné, že bude potřebovat více než 10 uživatelských účtů. Cena za licenci společně s doplňkem Greenhopper pro tento počet účtů je ale $1800 v případě provozování na vlastním serveru, nebo $75 měsíčně v případě pronájmu na serverech společnosti Atlassian [24]. Druhou nevýhodou je chybějící finanční statistika. Samostatný systém toto neumožňuje. V nabídce doplňků jsou sice doplňky umožňující napojení na jiné systémy pro podporu rozhodování (Business Intelligence) nebo výkazy odpracovaného času, ale žádný neumožňuje sledovat vývoj firemních financí, ani rozpočty projektů TRAC Projekt TRAC je dostupný pod otevřenou Modified BSD licencí, která dovoluje používání i modifikaci zdrojových kódů programu zdarma. Je vyvíjen v jazyce Python a na vývoji se podílí komunita autorů s podporou společnosti Edgewall Software. V základní instalaci obsahuje nástroje pro řízení projektů a požadavků, 14

19 publikování wiki stránek, integraci se systémem správy zdrojových kódů (původně pouze Subversion, od verze 1.0 také Git) a také existuje rozsáhlá sada doplňkových modulů. Základní filozofií je minimalistický přístup. Software TRAC je využíván více než 400 projektovými týmy a je velice oblíbený u open-source komunity. Významným nedostatkem však je, že TRAC je určen výhradně pro řízení jednoho projektu. V případě správy více projektů je potřeba nainstalovat více instancí softwaru TRAC a ty mezi sebou následně nemají možnost přenosu informací. Při správě více projektů najednou tedy nelze jednoduše získat přehled o stavu všech projektů zároveň. TRAC nepokrývá finanční řízení, ani žádný z dostupných doplňkových modulů tuto funkcionalitu neposkytuje Redmine Redmine je open-source projekt pod licencí GPLv2 napsaný v jazyce Ruby. Narozdíl od TRACu již v základní instalaci podporuje správu několika projektů zároveň a také umožňuje napojení na 6 různých systémů správy zdrojového kódu. Nechybí wiki a možnost instalace doplňkových modulů. Svým výčtem funkcí se jedná o jeden z nejkompletnějších zdarma dostupných softwarů na řízení projektů. Při správném nastavení lze přijímat nové požadavky přímo z u, takže jej lze využít jako centrum zákaznické podpory. Ani Redmine neobsahuje nástroje pro rozpočty projektů a finanční řízení. Mezi dostupnými doplňkovými moduly lze nalézt fakturační modul, který ale poskytuje pouze základní možnosti vystavování faktury. 4.2 Ekonomické systémy Altus Vario Produkt Vario od české společnosti Altus je nabízen jako komerční program určený pro instalaci na zákazníkově počítači. Varianta Vario Free Office je poskytována zdarma pro malé a začínající firmy do 1 zaměstnance (pracovního poměru) a 100 dokladů, ostatní varianty jsou placené. Je primárně navržen pro firmy střední velikosti. Ostatní běžně používané ekonomické systémy na českém trhu jsou Stormware Pohoda, Money S3 a dále různé webové projekty zaměřené zejména na jednoduché fakturace, například Qfaktury.cz, flexibee.eu, fakturoid.cz, fakturman.cz, idoklad.cz a dalsi. 15

20 5. Průzkum používaného softwaru Při pokusu o zjištění statistik používaného podnikového softwaru v malých firmách jsem narazil na problém, protože dostupné statistiky se většinou takto malými podniky vůbec nezabývají. Sestavil jsem proto vlastní dotazník, ve kterém zjišťuji, jaký software startupy používají pro svou interní agendu a komunikaci. Dotazník se zaměřoval na tři podstatné části: jakým způsobem podnik spravuje své účetnictví, jak řídí své projekty a jak komunikuje se svými zaměstnanci nebo zákazníky. Plné znění otázek dotazníku je přiloženo jako Příloha 1 k této práci. Dotazník zodpovědělo celkem 51 zástupců startupů, což není dostatečný počet pro spolehlivé usuzování, ale jsou to jediná data která jsou mi v současnosti dostupná, proto je použiji alespoň jako orientační přehled situace. Délka existence zůčastněných startupů se pohybovala od 3 měsíců, do 3 let, s průměrem 10,71 měsíce. Počet spolupracovníků (všetně externích) se pohyboval od 1 do 14. Průměrnou hodnotou je 5,58. Důležitou otázkou bylo zjišťování použitého softwaru na správu úkolů. 67% dotázaných (34) používá k tomuto účelu specializovaný software. Mezi nimi se nejčastěji objevoval Redmine (9), Mantis (6) a LeanKit Kanban (5). Někteří respondenti uvedli i více projektových softwarů zároveň. Odpovědi na otázku používaného softwaru pro firemní účetnicví jsou vidět v následujícím obrázku. Největší zastoupení má využití externí účetní firmy, jejíž použitý software většinou není znám. 16

21 6. Návrh a implementace V praktické části práce se zaměřuji na návrh a implementaci informačního systému, který poskytuje nástroje pro agilní vývoj a je vhodný pro nasazení v malé začínající firmě. Z teoretické části vyplynulo, že na trhu již existuje několik vhodných řešení jak pro projektovou, tak pro ekonomickou část. Chybí ale propojení mezi těmito dvěma částmi. Větší firmy již používají komplexní integrovaná řešení, ale pro startup jsou zatím nedosažitelná. Místo nich používají víceméně roztroušené nástroje pro každou oblast zvlášť, což potvrzuje provedený dotazníkový průzkum. Nabízí se tedy možnost poskytnout způsob, jak data z těchto roztroušených systémů propojit a vytvářet finanční přehledy automatizovaně, což přinese úsporu času a vytvoří podklady pro efektivní rozhodování. Zaměřil jsem se na tři klíčové oblasti: agilní řízení projektů finanční přehled komunikace Oblast řízení projektů jsme schopni pokrýt některým existujícím softwarem. Podpora agilních metodik spočívá v zařazování úkolů do iterací. Klient by měl mít svůj vlastní uživatelský účet do tohoto systému, aby mohl přímo sledovat projektový vývoj. Všechny systémy projektového řízení zkoumané v teoretické části nabízí nějakou možnost napojení na externí systém pomocí aplikačního rozhraní (API). Můžeme z nich tedy čerpat data potřebná pro plánování a rozhodování. Žádný ze systémů ale neposkytuje nástroj pro odhadování náročnosti úkolů technikou plánovacího pokeru. Tento nástroj bude tedy nutno vyvinout. Jako testovací projektový systém jsem zvolil Redmine. Informace o finančním vývoji budou ve většině případů uložena v účetním systému, který již firma využívá. Ze zkoumaných účetních systémů většina umožňuje exporty dokladů do formátu ISDOC. Tento formát vznikl jako standard pro elektronické faktury na území České republiky. Byl vytvořen Pracovní skupinou pro Elektronické standardy výměny dat v rámci české ICT Unie [25] a v současnosti se jej zavázalo podporovat 46 českých výrobců ekonomických softwarů. Je to tedy vhodný formát pro přenos dat z účetního softwaru. Při dodržení tohoto standardu nezáleží jaký konkrétní účetní software bude použitý. 17

22 Žádný ze zkoumaných softwarů neposkytoval nástroje pro komunikaci mezi členy týmu, kromě komentářů přímo u úkolů v projektovém systému. Z průzkumu přitom vyplynulo, že komunikace je důležitým prvkem každého startupu. Pro zjednodušení komunikace jsem navrhl do systému začlenit správu účtů protokolu XMPP (Jabber), čímž bude zajištěno, že každý zaměstnanec firmy má automaticky zařízen komunikační účet. Zároveň systém obsahuje nástroj webchat, pomocí kterého můžou zaměstnanci komunikovat protokolem XMPP přímo z webového prostředí systému. Systém je postaven na frameworku Symfony ve verzi 1.4. Tento framework implementuje architekturu MVC (Model-View-Controller), která od sebe odděluje prezentační, logickou a datovou vrstvu aplikace. Framework Symfony poskytuje vysokou úroveň abstrakce nad řešeným problémem. Jsme schopni se zabývat návrhem databázové struktury bez toho, abychom se museli potýkat s nízkoúrovňovými problémy konkrétního databázového stroje. Symfony dále poskytuje nástroje pro automatické generování kódu. Toho se zejména využívá k tvorbě tříd modelu na základě jednotné konfigurace. Konfiguraci stačí vytvořit jednou a na jejím základě se vygenerují třídy modelu, formulářů a nakonec i struktura tabulek přímo v databázi. Existuje sice novější verze frameworku Symfony 2.0, ale v této verzi chybí nástroj Admin Generator, který využíváme pro generování rozhraní pro základní operace s objekty v databázi (tzv. CRUD operace create, read, update, delete) Výsledný systém je dostupný na adrese pro vstup do administrace slouží přihlašovací jméno: admin, a heslo: admin. 18

23 7. Závěr V diplomové práci jsem zkoumal specifické postavení mikropodniků, tzv. startupů, které se vyznačují určitými charakteristickými znaky. Pro potřeby těchto podniků jsem navrhoval informační systém, který podporuje komunikaci, orientaci ve firemních financích a agilní vývoj. 19

24 8. Literatura [1] Wikipedia, Metodologie vývoje softwaru [online] 2012, [cit ]. Dostupné z < [2] Manifesto for Agile Software Development, [online], [cit ]. Dostupné z < [3] Unie malých a středních podniků ČR, Statistické údaje MSP, [online], [cit ]. Dostupné z < %C3%A9-%C3%BAdaje-MSP-ke-sta%C5%BEen%C3%AD-za-textem.pdf> [4] BusinessInfo.cz, Co si myslí podnikatelé o postavení malých a středních podniků v ČR a EU? [online], [cit ]. Dostupné z < [5] ČSÚ, Oddělení informačních služeb, Krátká tematická analýza. Malé a střední podniky (jejich místo a role v české ekonomice). [online], [cit ]. Dostupné z < [6] Václav Kadlec, Agilní programování, Computer press, 2004, Brno [7] COMMISSION RECOMMENDATION, of 6 May 2003, concerning the definition of micro, small and medium-sized enterprises, [online], [cit ]. Dostupné z < uri=oj:l:2003:124:0036:0041:en:pdf> [8] Unie malých a středních podniků ČR, Kdo je SME/MSP, [online], [cit ]. Dostupné z < [9] Ondřej Bartoš, Start-upy v České republice, [online], , [cit ]. < 20

25 [10] Eric Ries, The Lean Startup, Crown Business, New York, 2011 [11] APOSTOLIDU, Petra. Možnosti finanční podpory pro začínající podnikatele, str. 11, [online] [cit ]. Diplomová práce. Masarykova univerzita, Ekonomicko-správní fakulta. Vedoucí práce František Kalouda. Dostupné z: < [12] BLAŽKOVÁ, Martina. Marketingové řízení a plánování pro malé a střední firmy, Grada, 2007, str. 16 [13] Wikipedia, Průběžná integrace, [online], [cit ]. Dostupné z < [14] BECK, Kent. Extrémní programování, Grada, Praha, 2002 [15] AMBLER, Scott. Survey Says: Agile Works in Practice, [online], , [cit ]. Dostupné z < [16] BUCHALCEVOVÁ, Alena. Agilní metody, jak dál?, Ostrava, 2008 [17] Version One, 3rd Annual Survey: 2008 The State of Agile Development". [online], , [cit ]. Dostupné z < [18] VYMĚTAL, Dominik. Informační systémy v podnicích, teorie a praxe projektování, Grada, Praha, 2009 [19] OHNO, Taiichi. Toyota Production System - beyond large-scale production, Productivity Press, červen 1988 [20] LADAS, Corey, THOMPSON, Bernie. Scrum-ban, [online], [cit ]. Dostupné z < [21] BUCHALCEVOVÁ, Alena, LEITL, M. Průzkum používání agilních metodik v ČR Praha : PEF ČZU, 2006, s

26 [22] KOTT, Petr. Nasazení agilní metodiky [online] [cit ]. Diplomová práce. Masarykova univerzita, Fakulta informatiky. Vedoucí práce Jaroslav Ráček. Dostupné z: < [23] KNESL, Jiří. přednáška Cargo Scrum, Brno, [online], , [cit ]. Dostupné z < id=13> [24] Atlassian, Pricing Atlassian JIRA, [online], [cit ], Dostupné z < [25] ICT UNIE o.s. (Sdružení pro informační technologie a telekomunikace), ISDOC: Profil, [online], [cit ]. Dostupné z < 22

27 Příloha 1. Dotazník pro majitele / spolumajitele startupů 23