UNICORN COLLEGE Katedra ekonomiky a managementu BAKALÁŘSKÁ PRÁCE Proces vývoje software z přístupu rigorózních a agilních metodik

UNICORN COLLEGE Katedra ekonomiky a managementu BAKALÁŘSKÁ PRÁCE Proces vývoje software z přístupu rigorózních a agilních metodik Autor BP: Jan Tomšů Vedoucí BP: Ing. Michal Kökörčený Ph.D. 2017 Praha

Čestné prohlášení Prohlašuji, že jsem svou bakalářskou práci na téma Proces vývoje software z přístupu rigorózních a agilních metodik vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím výhradně odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou také uvedeny v seznamu literatury a použitých zdrojů. Jako autor této bakalářské práce dále prohlašuji, že v souvislosti s jejím vytvořením jsem neporušil autorská práva třetích osob a jsem si plně vědom následků porušení ustanovení 11 a následujících autorského zákona č. 121/2000 Sb. V Praze dne (Jan Tomšů)

Poděkování Děkuji vedoucímu bakalářské práce Ing. Michalovi Kökörčenému, Ph.D. za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce.

Proces vývoje software z přístupu rigorózních a agilních metodik Software development process under rigorous and agile methodology 6

Abstrakt V této práci se hodlám zabývat procesem vývoje software z pohledu metodiky vývoje. Metodika vývoje softwaru se zaměřuje na procesní postupy, které se využívají v rámci vývoje softwarových produktů. Účelem této práce je představit rigorózní a agilní postupy, konkrétně metodiky Rational Unified Process a Scrum. Tyto metodiky představují odlišný úhel pohledu na proces vývoje softwaru. V rámci první části této práce hodlám popsat příslušné dvě metodiky. Druhou částí práce je představení reálné implementace na dvou projektech, ve kterých je použita právě jednou každá z popsaných metodik. V rámci tohoto popisu hodlám provést analýzu vývojového cyklu, tzv. iterace, od procesu plánování až po proces nasazení. V poslední části této práce hodlám popsat problémy, ke kterým v rámci jednotlivých přístupů dochází, a navrhnout řešení. Pro návrh řešení hodlám využít svých dosavadních zkušeností ze softwarových projektů v tuzemsku i v zahraničí. Klíčová slova: metodika, proces, vývoj software, rational unified process, scrum Abstract In this Thesis, I intend to examine the software development process from the perspective of methodology. Software development methodology focuses on procedures used in the development of software products. The purpose of this Thesis is to present both rigorous and agile procedures, specifically the Rational Unified Process and Scrum. These methodologies represent different approaches to the software development process. The first part of this Thesis will offer a description of the methodologies. The second part will delve into the respective implementation of these methodologies in two real projects. Here, I will also analyze the development cycle, which is called iteration, from the initial planning phase to deployment. In the third and final part of this Thesis, I will raise the potential problems that can occur throughout the use of these methodologies, and propose steps to tackle them. These solutions will be based on my experience with software projects both domestic and international. 7

Keywords: methodology, process, software development, rational unified process, scrum 8

Obsah Obsah... 9 Úvod... 12 1. Teoretická část... 13 1.1 Rigorózní vývojové metodiky... 14 1.2 Rational Unified Process... 15 1.2.1 Vznik Rational Unified Process... 15 1.2.2 Charakteristika metodiky... 15 1.2.3 Nejlepší praktiky softwarového vývoje... 16 1.2.4 Proces vývoje software v RUP... 22 1.2.5 Struktura projektu... 24 1.3 Agilní vývojové metodiky... 26 1.3.1 Manifest agilního vývoje... 26 1.4 Metodika SCRUM... 28 1.4.1 Role... 29 1.5 Sprint... 31 1.5.1 Backlog... 32 1.5.2 Ukazatele efektivnosti týmu... 35 1.5.3 Meetingy... 36 2. Praktická část... 39 2.1 Přímé srovnání metodik... 40 2.1.1 Přístup... 41 2.1.2 Cyklus... 42 2.1.3 Plánování... 42 2.1.4 Rozsah... 43 2.1.5 Organizační struktura... 43 2.1.6 Management kvality... 43 2.1.7 Dokumentace a artefakty... 44 9

2.1.8 Typ projektu... 45 2.1.9 Závěrem k přímému srovnání... 45 2.2 Popis projektu řízeného metodikou Rational Unified Process... 46 2.2.1 Průběh vývojového cyklu... 47 2.2.2 Konfigurační management... 50 2.2.3 Řízení požadavků a změn... 51 2.2.4 Koordinace týmů projektové meetingy... 51 2.2.5 Shrnutí... 52 2.3 Popis projektu řízeného metodikou SCRUM... 52 2.3.1 Průběh iterace... 53 2.3.2 Zahájení sprintu... 54 2.3.3 Průběh sprintu... 54 2.3.4 Procesy v rámci iterace... 56 2.3.5 Koordinace týmů projektové meetingy... 58 2.3.6 Řízení změn a správa požadavků... 58 2.3.7 Konfigurační management... 59 2.3.8 Shrnutí... 59 2.4 Vyhodnocení... 59 2.4.1 Projekt Alpha... 59 2.4.2 Závěrem k projektu řízením v RUP... 62 2.4.3 Projekt Beta... 63 2.4.4 Role... 63 2.4.5 Průběh sprintů... 66 2.4.6 Meetingy... 67 2.4.7 Definice kritérií... 69 2.4.8 Reakce na změnu... 70 2.4.9 Schopnost agilně myslet... 70 2.4.10 Závěrem k projektu řízeném metodikou SCRUM... 71 2.5 Metodiky z pohledu autora práce... 71 Závěr... 76 Conclusion... 76 Seznam použitých zdrojů... 81 Seznam obrázků... 83 10

Seznam tabulek... 84 11

Úvod Informační technologie jsou v dnešní době již nedílnou součástí našeho každodenního života a s tímto faktem úzce souvisí i vývoj software. K tomuto procesu se dá přistupovat mnoha způsoby a jedním z faktorů, co tento proces ovlivňují, je metodika vývoje. Vzhledem k tomu, že software jako takový existuje již mnoho desítek let, je zřejmé, že metodiky jeho vývoje již nějakou evoluci také zaznamenaly. Metodik je mnoho druhů a představují určitý metodický postup vývoje softwaru jak z hlediska projektového, tak z hlediska vývoje samotného. V této práci se hodlám zabývat popisem dvou metodik, z nichž každá představuje jiný pohled na proces vývoje softwaru. Jedná se o přístup rigorózní, jenž je v tomto případě zastoupen metodikou Rational Unified Process, a přístup agilní, který je zastoupen metodikou Scrum. Popis metodik samotných je pouze jednou částí této práce, druhou částí je popis reálné implementace na konkrétních projektech a následná analýza fungovaní vybrané metodiky v rámci společnosti. Toto téma jsem si vybral z důvodu, že se v dané oblasti vývoje softwaru, konkrétně informačních systémů, pohybuji aktivně již více než dvanáct let, přičemž pět let jsem strávil na projektech řízených metodikou Rational Unified Process a posledních šest let se pohybuji na agilně řízených projektech, hlavně metodikou Scrum, jejíž implementaci jsem měl možnost zažít a řešit na několika zahraničních projektech, např. v Lotyšsku, Bulharsku a v současné době v Číně. Jako přínos této práce vidím především své poznatky z praxe, neboť se domnívám, že většina studijních materiálů a příruček k daným metodikám se zabývá pouze hlavním rámcem toho, jak by měla být metodika implementována. Tyto materiály se již dále nezaměřují na situace, které v reálném prostředí opravdu nastávají, a jelikož je to prostředí velmi různorodé, jsou různorodé i tyto situace. Za účelem této práce jsem názvům projektů, které hodlám popisovat, přiřadil fiktivní jména, jelikož od společností nemám oficiální povolení k distribuci informací o jejich projektech. Prohlašuji tímto, že informace, které v rámci popisu uvedu, jsou pravdivé. 12

1 Teoretická část Metodika vývoje je v dnešní době již nedílnou součástí většiny softwarových projektů. Vzhledem k tomu, že každý projekt je ve své podstatě jedinečný, vyžaduje taktéž individuální přístup. Neznamená to, že by každý projekt vyžadoval svou zvláštní metodiku, ale vývojových metodik je poměrně mnoho a žádná z nich není univerzální. Co vlastně pojem metodika znamená? Metodika představuje v obecném smyslu souhrn metod a postupů pro realizaci určitého úkolu. Metodika budování IS/ICT představuje metody a postupy pro vývoj i provoz IS/ICT s tím, že akcentuje skutečnost, že nemusí jít jen o vývoj nového softwaru na zelené louce, ale také o implementaci již hotových řešení, integraci různých komponent a služeb. 1 Pro účely této práce můžeme definovat pojem metodika následovně: Metodika budování IS/ICT definuje principy, procesy, praktiky, role, techniky, nástroje a produkty používané při vývoji, údržbě a provozu informačního systému, a to jak z hlediska softwarově inženýrského, tak z hlediska řízení. 2 Velmi zjednodušeně by se dalo konstatovat, že vývojová metodika je vlastně návod k tomu, jak správně vést softwarový projekt, jakým chybám se vyvarovat a naopak jaké postupy dodržovat k tomu, aby projekt byl úspěšný a nedocházelo k nežádoucím událostem, nebo dokonce k neúspěšnosti celého projektu jako takového. Vývojové metodiky mají svou historii a také samozřejmě svůj vývoj. Nemůžeme ovšem konstatovat, že postupy, které se využívaly v průběhu 90. let jsou již dnes považovány za zastaralé. V mnoha případech jsou právě tyto postupy ze staré školy optimálnější než postupy moderní. Záleží ovšem na typu a povaze projektu, protože jak již bylo řečeno, každý projekt je ve svém smyslu unikátem. 1 BUCHALCEVOVÁ, A.: Metodiky budování informačních systémů. Praha: Oeconomica, 2009, s. 17. 2 BUCHALCEVOVÁ, A.: Návrh metodického rámce IS/ICT [online]. Praha: 2004 [cit. 2017-06-21]. Doktorská dizertační práce (PhD). Vysoká škola ekonomická v Praze. Dostupné z URL: <http://nb.vse.cz/~buchalc/clanky/disertacniprace.pdf>, s. 15. 13

Postupů k vývoji softwaru je mnoho, pojďme si proto představit dva kandidáty ze dvou hlavních vývojových směrů. 1.1 Rigorózní vývojové metodiky Rigorózní vývojové metodiky bývají často nazývány také jako tzv. těžké metodiky. Důvodem, proč jsou tak nazývány, je stanovení pojmu váha metodiky, který vychází z prací A. Cockburna. Ten zavedl charakteristiky metodiky, kterou označuje zkratkou PARTS prescision (podrobnost), accuracy (přesnost), relevance (relevance), tolerance (tolerance), scale (měřítko). Charakteristika Význam Tabulka 1: Popis charakteristik metodiky Podrobnost Přesnost Relevance Tolerance Měřítko Vyjadřuje, jak podrobně se metodika tématem zabývá Vyjadřuje, jak přesně je dané téma zpracováno Určuje, zda se metodika zabývá určitým tématem Určuje, jaké množství odchylek je povoleno Definuje míru zaostření Zdroj: A. Buchalcevová: Metodiky budování informačních systémů 3 Od těchto charakteristik jsou potom odvozeny pojmy velikost, hustota a váha metodiky. Velikost metodiky (methodology size) vyjadřuje počet kontrolních prvků obsažených v metodice. Hustota metodiky (methodology specific density) vyjadřuje míru podrobnosti a těsnost metodiky, požadovanou podrobnost a konzistenci prvků. 3 BUCHALCEVOVÁ, A.: Metodiky budování informačních systémů. Praha: Oeconomica, 2009, s. 62. 14

Váha metodiky (methodology weight) je potom součin velikosti metodiky a hustoty metodiky. 4 Období 80. až 90. let minulého století vedlo k rozvoji metodik, které se vyznačovaly vysokou mírou propracovanosti, přesnosti definovaných procesů, činností a artefaktů. Tyto metodiky označujeme proto jako rigorózní neboli těžké. 1.2 Rational Unified Process První metodikou, kterou se v této práci hodlám zabývat, je Rational Unified Process (dále jen RUP ). Je považována za jednoho z klasických představitelů rigorózních metodik známého v celosvětovém měřítku a je využíván mnoha velkými společnostmi působících v mnoha oborech. Mezi uživatele této metodiky se řadí např. společnosti Visa (finance), Volvo, Intel (výroba), Oracle (systémová integrace), či dokonce Lockheed-Martin (obranné systémy). 1.2.1 Vznik Rational Unified Process Za formální termín vzniku je považován rok 1995, kdy došlo ke sloučení Rational Software Corporation a Objectory AB. O rok později se datuje vznik Rational Objectory Process (verze 4.0) jako následník Objectory Process (verze 3.8) a Rational Approach. Ze strany Objectory byl poděděn procesní model a centrální koncept případu užití, ze strany Rational zase iterativní vývoj a architektura (pojmy případ užití a iterativní vývoj budou popsány v dalších kapitolách). Rational Objectory Process (v.4) rovněž obsahuje detailní testovací proces od společnosti SQA Inc. a model správy požadavků od Requisite Inc., které rovněž patřily pod Rational Software. Tato verze procesu byla také první, která využívala nově vytvořeného modelovacího jazyka Unified Modeling Language (v.0.8). Postupnou evolucí se dospělo k první verzi Rational Unfied Process (v.5.0) roku 1998. V roce 1999 4 COCKBURN, A.: The Methodology Space, Humans and Technology [online]. 1998. [cit. 2007-07-07]. Dostupný z URL: <http://alistair.cockburn.us/methodology+space>. 15

následovala verze 5.5 a v roce 2000 přišla verze Rational Unified Process 2000. Ve své plné a nejtěžší verzi je zatím známa jako Rational Unfied Process verze 2003.06.15. 1.2.2 Charakteristika metodiky Rational Unified Process může být definován několika způsoby, pojďme si je představit. Metodika Rational Unified Process je softwarový inženýrský proces, který představuje disciplinovaný přístup přiřazující úkoly a odpovědnosti v organizaci zabývající se vývojem softwaru. Jejím cílem je zajistit produkci vysoce kvalitního softwaru, který naplní potřeby koncových uživatelů a plánovaného rozpočtu. Rational Unified Process je procesní produkt. Je vyvinut a udržován společností Rational Software a integrován vlastními vývojovými nástroji. Je dostupný od IBM na CD-ROM nebo prostřednictvím internetu. Rational Unified Process je procesní framework, který může být adaptován a rozšířen na soubor potřeb adaptujících se organizaci. 5 Metodiku RUP svým zacílením na proces řadíme také do kategorie metodik procesních. 1.2.3 Nejlepší praktiky softwarového vývoje Metodika RUP je založena na nejlepších praktikách softwarového vývoje. Mezi tyto praktiky patří: iterativní vývoj, řízení požadavků, použití komponentové architektury, vizuální modelování, kontrola kvality softwaru a řízení změn. 5 KRUCHTEN, P.: The Rational Unified Process: An Introduction (3rd Edition). Addison-Wesley Professional, 2003, s. 17. 16

Iterativní vývoj Jedná se o první z kategorie nejlepších vývojových praktik. Je dosti úzce navázána na model vývoje softwaru konkrétního projektu. Dosti často se můžeme setkat s tvrzením, že RUP je tzv. vodopádovou metodikou. Dovolím si tvrdit, že tomu tak není. Pojďme si proto trochu blíže představit vodopádový model vývoje. Obrázek 1: Vodopádový model životního cyklu Zdroj: ROYCE, W.: Managing the Development of Large Software Systems 6 Celý proces začíná fází specifikace požadavků, poté následují fáze analýzy, návrhu, implementace, testování. Poslední fází je provoz, který v sobě zahrnuje fázi nasazení a následné údržby systému v reálném prostředí. Jméno vodopádový dostal model proto, že jednotlivé fáze jdou po sobě a připomínají tím vodopád. Vodopádový model představoval v době svého vzniku významný pokrok, protože rozdělil celý proces vývoje do samostatných fází a umožnil systematický a opakovaný postup vývoje. 7 6 ROYCE, W.: Managing the Development of Large Software Systems [online]. Proceedings of IEEE WESCON, 1970. [cit. 2017-04-22]. Dostupné z URL: <http://www.cs.umd.edu/class/spring2003/cmsc838p/process/waterfall.pdf>. 17

Nevýhodou vodopádového modelu jsou rizika s ním spojená, jedním z nich je reakce na změnu během vývoje, dalšími jsou například nízká participace zákazníka, která je vyžadována pouze ve fázi na začátku a konci procesu. Další negativa jsou například ta, že model předpokládá, že všechny požadavky jsou definovány na začátku projektu, což ve skutečnosti není moc dobře možné, a v případě změny je možný návrat pouze do předchozí fáze vývoje. To zapříčiňuje odsun řešení problémů do pozdějších fází. Asi největším problémem vodopádového modelu je skutečnost, která nastane až po ukončení programování. Právě tehdy jsou zjištěny problémy, které dosti často vedou k přeprogramování a zpoždění projektu. Pokud nebudete aktivně útočit na rizika Vašeho projektu, rizika zaútočí na Vás. 8 Pojďme se vrátit k pojmu iterativní vývoj, který spočívá v rozdělení vývojového cyklu do několika menších fází, tzv. iterací, kdy každá iterace zapříčiní vznik nové funkční verze systému. To zahrnuje několik základních aktivit. Mezi tyto aktivity patří sběr požadavků, návrh implementace a vyhodnocení. V rámci každého cyklu také rozlišujeme určité fáze, přičemž mezi ty základní patří analýza, konstrukce a zavedení. V každé z těchto fází je nutné provést sběr požadavků, vytipovat rizika, navrhnout řešení, implementovat a ověřit. Iterativní vývoj pomáhá odhalit rizika projektu v jeho počáteční fázi, usnadňuje implementaci změnových požadavků, zvyšuje znovupoužitelnost a pomáhá členům projektu poučit se z minulých chyb. 9 Alternativním modelem vývoje může být například tzv. spirálový model životního cyklu. 7 BUCHALCEVOVÁ, A.: Metodiky budování informačních systémů. Praha: Oeconomica, 2009, s. 48. 8 GILB, T.: Principles of Software Engineering Management. Harlow, UK: Addison-Wesley Professional, 1988, s. 73. 9 ŠTĚDROŇ, B.: Manažerské řízení a informační technologie. Praha: Grada, 2007, s. 90. 18

Obrázek 2: Spirálový model životního cyklu Zdroj: Testování software 10 Tento model byl v roce 1985 definován Barrym Boehmem a jeho výhodou je, že zavedl iterace a analýzu rizik. V každé iteraci se opakují fáze definice cílů, analýza rizik, návrh řešení, ověření, vývoj, testování a plánování. Předmětem první iterace je identifikace globálních rizik projektu a stanovení základních východisek pro řešení. Druhá iterace je zaměřena na specifikaci požadavků. V průběhu třetí iterace se 10 Testování software, [online], [cit. 2017-07-15]. Dostupný z URL: <http://testovanisoftwaru.cz/manualni-testovani/modely-zivotniho-cyklu-softwaru/spiralovymodel/>. 19

vytváří detailní návrh řešení. Čtvrtá iterace slouží k implementaci navrženého řešení a jeho testování. 11 Řízení požadavků Tato praktika má za úkol aktivně spravovat požadavky. Problém požadavků, které se v rámci vývoje objevují, je, že jsou dynamické. Je tedy nutné předpokládat, že se mohou v průběhu životního cyklu měnit, jelikož sběr požadavků probíhá hlavně v začátcích vývoje. Požadavek je definován jako schopnost, kterou musí systém splňovat. 12 Aktivní správa požadavků zahrnuje tři aktivity: získávání, organizování a dokumentaci požadovaných funkcionalit; hodnocení změn daných požadavků a posuzování jejich dopadu; sledování a dokumentace rozhodnutí. 13 Výsledkem správy požadavků je kvalitní dokumentace projektu, jejíž konkrétní požadavky mohou být sledovány a prioritizovány. Komunikace je vázána na konkrétní problémy, nekonzistence se odhalí snadněji. Správa požadavků zahrnuje požadavky jak technického charakteru, kterým může být například architektura systému, či nastavení prostředí, ale hlavně také požadavky uživatelů. Tyto požadavky zpravidla definují nové vlastnosti systému, tzv. features, které jsou obvykle souborem pozorovatelných změn. Tyto soubory se nadále větví na jednotlivé případy užití, tzv. Use-case. Use-case specifikuje množinu akcí, které jsou provedeny systémem za účelem dodání výsledku, který má typicky hodnotu pro jednoho nebo více aktérů nebo zainteresovaných osob. 14 11 BUCHALCEVOVÁ, A.: Metodiky budování informačních systémů. Praha: Oeconomica, 2009, s. 50. 12 ŠTĚDROŇ, B.: Manažerské řízení a informační technologie. Praha: Grada, 2007, s. 90. 13 KRUCHTEN, P.: The Rational Unifiedprocess: An Introduction (3rd Edition). Addison-Wesley Professional, 2003, s. 9. 14 KLIMEŠ, J.: Přednáška REQ, Požadavky v systémové analýze, k předmětu Správa požadavků, [online], publikováno 29. 4. 2010, [cit. 2017-07-22]. Dostupné z URL: <https://www.unicorncollege.cz/>, s. 1. 20

Struktura Use-case zpravidla obsahuje stručný popis předmětu Use-case, popis podmínek nutných pro spuštění, popis hlavních a vedlejších toků, Business pravidla, popř. další doplňující informace. Součástí Use-case může taktéž návrh grafického rozhraní systému. Použití komponentové architektury Komponentová architektura spočívá v rozdělení systému do menších modulů, které jsou na sobě nezávislé a umožňují tak snadnější přístup k úpravám celého systému. Komponenta systému může být chápána jako základní jednotka použitelnosti. Spolu s iterativním vývojem softwaru přispívá komponentová architektura k postupné tvorbě systémové architektury. Takový přístup usnadňuje identifikaci rizik a jejich odstranění již v samotném procesu vývoje. 15 Vizuální modelování Slouží k zachycení reality ve zjednodušeném modelu a popisuje systém z různých úhlů pohledu. Modelování je důležité pro celý vývojový tým, jelikož usnadňuje celkovou vizualizaci a dokumentaci celého systému. Častokrát se využívá více modelů na popis jednoho systému, či dokonce jedné funkcionality. V rámci vizuálního modelování je v metodice RUP využíván Unified Modeling Language (UML). Jazyk UML (Unified Modeling Language, unifikovaný modelovací jazyk) je univerzální modelovací jazyk pro vizuální modelování systémů. Byl navržen proto, aby spojil nejlepší existující postupy modelovacích technik a softwarového inženýrství. Jako takový je explicitně navržen takovým způsobem, aby jej mohly implementovat všechny nástroje CASE (computer-aided software engineering). 16 15 ŠTĚDROŇ, B.: Manažerské řízení a informační technologie. Praha: Grada, 2007, s. 91. 16 ARLOW, J., NEUSTADT, I.: UML 2 a unifikovaný proces vývoje aplikací: objektově orientovaná analýza a návrh prakticky. 2. vydání. Brno: Computer Press, 2011, s. 28. 21

Kontrola kvality Kontrola kvality je nedílnou součástí celého procesu vývoje softwaru. Vzhledem k tomu, že oprava chyb po nasazení systému do produkčního (reálného) prostředí je mnohonásobně dražší, je důležité kontrolu kvality nepodceňovat. Testování softwaru probíhá v rámci celého procesu zajištění kvality (Quality Assurance). Pokud je systém vyvíjen iterativně, je možné v rámci každé iterace provést testy nových funkčností a zároveň otestovat, zdali již implementované funkčnosti nebyly nijak narušeny. V rámci testování dochází k tvorbě testovacích případů k jednotlivým případům užití. Tyto testovací případy se nadále mohou používat v rámci testovacích scénářů, kde se testují celé funkčnosti. V rámci QA procesu dochází k mnoha fázím testů, od tzv. smoke testů, přes systémové integrační testy, regresní testy až po UAT (User acceptance testing) testy, v nichž je systém testován samotnými uživateli. Samotnou kapitolou je pak automatizované testování, ve kterém jsou využívány různé automatizační nástroje, které usnadňují práci na rutinních a stále se opakujících testech a nejčastěji jsou využívány pro regresní testování. Řízení změn Vzhledem k tomu, že vývoj software probíhá často na mnoha pracovištích a účastní se ho více týmů pracujících ve více iteracích, je velmi důležité, aby koordinace aktivit a týmů měla svou disciplínu, jinak hrozí, že z celého procesu vývoje se stane nekontrolovaný chaos. V rámci řízení změn je důležité nastavit životní cyklus změnových požadavků, který napomůže lepšímu rozložení zdrojů a eliminaci rizik. Jako další výhodou dobře organizovaného řízení změn je fakt, že napomáhá identifikaci přijatých změn a zabraňuje neřízenému zvětšování rozsahu projektu. 22

1.2.4 Proces vývoje software v RUP Proces vývoje v RUP bývá nejčastěji interpretován grafem o dvou dimenzích, v nichž osa horizontální zobrazuje pohled z hlediska procesu, rozděluje jej do určitých cyklů a fází a tím stanovuje určité milníky. Vertikální osa zase reprezentuje činnosti konkrétních pracovníků a pracovních toků a výši jejich aktivit v rámci konkrétních fází. Obrázek 3: Fáze a disciplíny RUP Zdroj: Cycoda 17 Vývoj software probíhá v iteracích, kdy každá iterace obsahuje novou funkční verzi systému. Tyto jednotlivé iterace se skládají ze čtyř částí, které na sebe navazují: Počáteční fáze (Inception), Elaborační fáze (Elaboration), Konstrukční fáze (Construction), 17 Cycoda[online]. [cit. 2017-07-10]. Dostupné z URL: <http://cycoda.com/html/prog-rup.html>. 23

Fáze Nasazení (Transition). Počáteční fáze V rámci této fáze dochází k nastavení cílů dané iterace, odhadům a definici rizik projektu. Zároveň se vytváří jednoduchý prototyp, který slouží k ověření, zda je možné realizovat vývoj s použitím vybraných technologií a postupů. Za konec této fáze považujeme rozhodnutí o možnosti provedení. Elaborační fáze Tato je fází architektonického testování, kdy se na prototypovém modelu stanovuje budoucí architektura systému. Probíhá analýza a v rámci implementace se upřesňují komponenty, které budou předmětem vývoje. Konstrukční fáze Jedná se o fázi samotného vývoje, v kterém probíhá jak naprogramování jednotlivých komponent, tak zároveň proces testování. Cílem této fáze je hotový produkt připravený k nasazení. Fáze Nasazení Jedná se o konečnou fázi, kdy se systém nasazuje na produkční prostředí, tzn. předává se uživatelům společně s dokumentací, popř. se zajišťuje uživatelská podpora atd. Jednotlivé fáze jsou oddělovány milníky, v rámci kterých se posuzuje, jak byly splněny cíle fáze, a rozhoduje se o dalších krocích. 1.2.5 Struktura projektu Každý projekt řízený metodikou RUP má svůj určitý model, který je reprezentován pěti základními elementy: Role Aktivity Artefakty Životní cykly 24

Role Disciplíny Role definují chování a odpovědnosti jednotlivců nebo skupiny jednotlivců pracujících dohromady jako tým. Chování je vyjádřeno podmínkami aktivit, které role vykonávají a každá role je asociována souborem soudržných aktivit. Soudržný v tomto smyslu znamená aktivity, které jsou nejlépe prováděny jednou osobou. Odpovědnosti každé role jsou obvykle vyjádřeny vztahem k určitému artefaktu, který tato role vytváří, upravuje či kontroluje. 18 Role nejsou individuální a jedna osoba může zastávat rolí více. Každá role je zastoupena souborem dovedností, které umožňují vykonávat určité aktivity. V rámci RUP metodiky je definována celá řada rolí, mezi hlavní patří role analytické, vývojářské, manažerské, testerské a role produkční podpory. Role odpovídají na otázku kdo. Aktivity Každá role má svou aktivitu, která definuje práci, která má být vykonána. Aktivita je jednotka práce, která má být vykonána a má smysluplný význam v rámci projektu. 19 Aktivita může mít různou granularitu, která může být časově náročná v rámci několika hodin až několika dní, může být taktéž opakována, např. v rámci jedné iterace. Opakované aktivity jsou prováděny stejnými rolemi, nikoliv jednotlivci. Zjednodušeně řečeno: aktivity odpovídají na otázku jak. Artefakty V tomto případě odpovídáme na otázku co. Artefakty jsou hmatatelnými částmi projektu, věcmi, které projekt produkuje v rámci posunu kupředu za splnění cíle, 18 KRUCHTEN, P.: The Rational Unified Process: An Introduction (3rd Edition). Addison-Wesley Professional, 2003, s. 36. 19 KRUCHTEN, P.: The Rational Unified Process: An Introduction (3rd Edition). Addison-Wesley Professional, 2003, s. 38. 25

kterým je finální produkt. Artefakt je vstup pro roli a je vykonán aktivitou. Artefakt má mnoho podob a forem, může jím být například design model, dokument, či třeba zdrojový kód. Životní cykly Životní cyklus v tomto případě chápeme jako sekvenci aktivit, které produkují pozorovatelnou hodnotu a zobrazuje interakce mezi rolemi. Jazyk UML popisuje životní cyklus jako diagram, ať již sekvenční, či diagram aktivit. Životní cyklus je odpovědí na otázku kdy. Disciplíny Jedná se o sdružování aktivit do jednotných celků dle specializace. RUP rozlišuje devět disciplín: Business modelování, požadavky, analýza a design, implementace, testování, nasazování, projektový management, konfigurace a management změny, správa prostředí. 1.3 Agilní vývojové metodiky Tento typ vývojových metodik je druhou částí mé práce, představují jiný pohled na vývoj software a celého fungování v rámci projektu. Agilní vývojové metodiky jsou založeny na jiných principech než metodiky rigorózní. Podstata agilních metodik je zakotvena v Manifestu pro agilní vývoj softwaru. 1.3.1 Manifest agilního vývoje V únoru 2001 došlo k setkání představitelů nových přístupů k vývoji softwaru a byla založena Aliance pro agilní vývoj softwaru a podepsán Manifest agilního vývoje softwaru. V rámci tohoto manifestu jsou zakotveny čtyři hodnoty. Odhalili jsme lepší způsob vývoje software, sami jej používáme a chceme pomoci i ostatním, aby jej používali. Z toho pohledu dáváme přednost: jednotlivci a interakce před procesy a nástroji, fungujícímu software před podrobnou dokumentací, spolupráci se zákazníkem před sjednáváním kontraktu, 26

reakci na změnu před plněním plánu. 20 Hodnoty na levé straně mají větší váhu než hodnoty na straně pravé. Jednotlivci a interakce před procesy a nástroji Tato fráze klade důraz na lidskou spolupráci, snaží se říci, že dobře fungující tým, kde lidé spolupracují a komunikují spolu, je podstatně lepší varianta nežli tým jedinců s dobrými nástroji. Neznamená to, že by nástroje nebyly v tomto případě důležité, ale snaží se naznačit, že dobře fungující tým by si měl vybrat nástroje své, se kterými hodlá nadále pracovat. Fungující software před vyčerpávající dokumentací V tomto bodě se Manifest snaží naznačit, že projektová dokumentace bývá často velmi obsáhlá, aniž by přinášela potřebné výsledky. Dosti často se stává, že zákazník je zahrnut velkým množstvím dokumentace, která pro něj nemá natolik velkou hodnotu jako samotný produkt, neboť často bývá využívána až v krajních případech. Dokumentace je důležitá, ale neměla by převážit nad vlastním produktem, měla by primárně sloužit jako reference pro oblasti, které nejsou intuitivní a snadno pochopitelné. A takových oblastí by mělo být minimum. 21 Vzhledem k tomu že dokumentace může nabývat mnoha podob, je zapotřebí rozlišit tu správnou míru úrovně dokumentace. V případě interní dokumentace, jež se tvoří pro budoucí týmy, jako např. popis architektury, je určitě dobrou myšlenkou tyto materiály zaznamenat, ovšem stojí za zvážení, zdali není dostačují okomentovat ji pouze v kódu. Dokumentaci funkcionalit je možné nahradit kvalitní komunikací mezi členy týmu, kteří by sami mělo rozhodnout o tom, co zdokumentovat pro budoucí spolupracovníky. 20 Manifesto for Agile Software Development [online], cit. [2017-07-22]. Dostupné z URL: <http://agilemanifesto.org>. 21 ŠOCHOVÁ, Z., KUNCE, E.: Agilní metody řízení projektů. Brno: Computer Press, 2014, s. 15. 27

Spolupráce se zákazníkem před vyjednáváním o kontraktu Tímto pojmem je myšleno, že kvalitní komunikace se zákazníkem velmi napomůže specifikaci požadavků, které zákazník od systému očekává, vzhledem k tomu, že většina projektů se ve svém průběhu mění. Pokud je dodavatel schopen s klientem tyto změny, popř. nová zadání, kvalitně komunikovat, je to pro projekt přínosnější než podepsaná smlouva. Smlouvy jsou důležité, ale neměly by být prostředkem nahrazujícím spolupráci a komunikaci. Je důležité se už při jejím podpisu zamyslet nad tím, co se při spolupráci může vlastně stát. Je třeba si uvědomit, že zákazník možná ne vždy ví přesně, co přesně chce, a že se stejně bude měnit rozsah a smlouvu se pokusí přiblížit realitě. 22 Reakce na změnu, před plněním plánu Mnoho projektů se ve svém průběhu mění. Fakt, že zákazník přijde i v pozdních fázích projektu s požadavkem na změnu, není ničím neobvyklým. Samozřejmě je pochopitelné, že projekt má svůj plán a takový požadavek může být velkým zásahem. V tomto ohledu je nutné počítat s tím, že zákazník si některé požadavky uvědomí až později a zjistí, že jsou pro něj klíčové. Z toho důvodu je preferováno, když se dodavatel snaží zákazníkovi vyhovět i na úkor projektového plánu. V rámci Agile manifestu bylo sepsáno ještě dalších deset principů, kterými se v této práci již podrobněji zabývat nehodlám, neboť jsou určitou podmnožinou výše zmíněných hodnot. 1.4 Metodika SCRUM Jedná se o jednu z nejužívanějších agilních metodik. Metodika je zaměřena hlavně na řízení projektu. Jak již bylo patrné z definice agilních metodik, zaujímá k řízení odlišný postoj než metodiky rigorózní, tzn. nepohlíží na vývoj jako na předem 22 ŠOCHOVÁ, Z., KUNCE, E.: Agilní metody řízení projektů. Brno: Computer Press, 2014, s.16. 28

definovaný proces, nýbrž jako na proces dynamický. Název Scrum je převzatý z rugby, znamená skrumáž (mlýn). Stejně jako rugby i tato metodika nahlíží na proces jako na adaptivní a rychle se měnící. Podstatou jsou samoorganizující se týmy. 1.4.1 Role V této kapitole se hodlám zabývat rolemi, které se na projektu řízeném metodikou Scrum nejčastěji vyskytují. Oproti RUP je hierarchie rolí podstatně jednodušší. Metodika v tomto ohledu pracuje se třemi základními elementy, jimiž jsou Scrum Master, Product Owner a Scrum team. Scrum Master Tato role je asi na celém procesu nejvýraznější. Definic toho, co je a není v kompetenci Scrum mastera, je nesčetné množství. Role Scrum mastera je nová a často špatně pochopená. 23 Dle mého názoru by měl Scrum Master fungovat jako týmový coach, jenž se stará o to, aby tým jako takový fungoval co nejefektivněji a zároveň dodržoval proces. Scrum master by neměl být direktivní, nejedná se v tomto případě o manažerskou pozici. Měl by členům týmu pomáhat v řešení jejich problémů a zároveň je chránit od nepříznivých okolních vlivů. Scrum master by měl z týmu vychovat samoorganizující se jednotku, která se naučí, jak si své problémy řešit sama. Za znak toho, že Scrum Master odvedl dobrou práci, se dá považovat fakt, že průběhem času nebude již jeho coachingu zapotřebí, neboť tým se dokáže postarat sám o sebe. Scrum master může v týmu zastávat i jiné role, je ovšem důležité zvážit jaké, aby tyto role neovlivňovaly Scrum Mastera v jeho primární roli. Product Owner Role Product Ownera je další z nových rolí, které Scrum zavádí. Jedná se o roli vlastníka produktu, jehož úkolem je udržovat kontakt se zákazníkem, porozumět jeho potřebám a ty nadále interpretovat směrem k týmu. Product Owner rozhoduje, která 23 LARMAN, C., VODDE, B.: Large-Scale Scrum: More with LeSS. Addison-Wesley Professional, 2016, s. 135. 29

práce se má udělat. On či ona je vlastníkem backlogu a rozhoduje o prioritě a pořadí. 24 Product Owner není úplným členem vývojového týmu, neřídí ho, neměl by udělovat členům týmu povely. Jeho primární úlohou je, starat se o to, co má být uděláno dříve a co později. Zároveň by měl mít velmi dobrou znalost produktu a potřeb zákazníka. Product Owner tvoří pomyslný spojovací most mezi zákazníkem a vývojovým týmem. Vývojový tým Scrum tým Jak již název napovídá, jedná se o samotné jádro celého vývoje, tudíž analytiky, vývojáře, testery, databázové specialisty apod., zkrátka o všechny členy, kteří se fyzicky podílejí na tvorbě produktu. Právě těmto lidem by měl být Scrum Master k službám a napomáhat jim v jejich každodenní rutině. Velikost týmu není nijak definována, ovšem Scrum týmy jsou obecně menší než týmy, které pracují na projektech řízených těžkými metodikami. Velikost týmu by měla být sedm, plus nebo mínus dva. Týmy tak malé jako například tři lidé, mohou mít úspěch, ale malá velikost týmu limituje množství interakcí, které mohou nastat a tím redukuje produktivitu týmu. Týmy větší než osm, nepracují dobře. Týmová produktivita se snižuje, Scrumové kontrolní mechanizmy se stávají těžkopádnými. 25 Složení týmu není nijak definováno, je individuální a závislé na projektu. Důraz je kladen na flexibilitu jednotlivých rolí, spolupráci a komunikaci mezi členy týmu, z tohoto důvodu je silně doporučeno, aby celý tým seděl pohromadě, pokud možno v jedné místnosti. 24 SUTHERLAND, J.,SUTHERLAND, JJ.: Scrum: The Art of Doing Twicet the Work in Half the Time. Crown Business, 2014, s. 176. 25 SCHWABER, K., BEDDLE, M.: Agile Software Development with Scrum. Pearson Education: 2008, s. 36. 30

Manažerské role Z předešlých definic se zdá, že role manažerů nejsou na projektech řízených metodikou Scrum zapotřebí. Není tomu tak. Zodpovědnost manažera v agilním světě je primárně vytvoření prostředí, ve kterém agilní týmy můžou fungovat, a podpora jednotlivých rolí. V menších firmách se často z manažera stává kouč Scrum Masterů, případně někdo, kdo je zodpovědný za celkovou strategii produktů, a je tedy koučem Product Ownerů. 26 Projektový manažer zastává v agilně řízených projektech funkci zajištění projektu, monitoruje důležité milníky v rámci společnosti a na tyto milníky upozorňuje jednotlivé týmy. Mezi další úkoly patří např. reporting, vyplňování rozpočtových tabulek apod. Projektový manažer ovšem nijak nezasahuje do práce jednotlivých týmů a ani je žádným způsobem neřídí. 1.5 Sprint Podobně jako RUP, tak i SCRUM metodika se snaží zaujmout k vývoji iterativní přístup, tzn. vyvíjí v určitých iteracích cyklech. Tyto iterace jsou rozděleny do časových úseků, které jsou nazývány jako tzv. Sprinty. Scrum tým dodává v rámci sprintu novou funkcionalitu, nebo alespoň určitou část nové funkcionality. Týmová práce za pevný časový úsek se nazývá Sprint. 27 Sprint může nabývat různých dob trvání, jeho délka nikde není předepsána a v průběhu vývoje projektu se může dle potřeb měnit. Doporučená doba sprintu je ne kratší než jeden týden a ne delší než čtyři týdny. Důvod je jednoduchý: za dobu kratší jednoho týdne je množství odevzdané práce příliš malé a za dobu delší čtyř týdnů se tým připravuje o možnost kvalitní zpětné vazby jak externího, tak interního charakteru. Zpravidla bývá nastavena jako referenční doba sprintu dva týdny. 26 ŠOCHOVÁ, Z., KUNCE, E.: Agilní metody řízení projektů. Brno: Computer Press, 2014, s. 40. 27 SCHWABER, K., BEDDLE, M.: Agile Software Development with Scrum. Pearson Education: 2008, s. 50. 31

Tým zpravidla na konci sprintu prezentuje výsledky své práce na zákaznickém demu, jež se označuje jako tzv. Sprint review. Jedná se o meeting, kde vývojový tým předvádí funkcionality, které v rámci sprintu dodal. 1.5.1 Backlog Pod pojmem Backlog je možné si zjednodušeně představit zásobník úkolů, které se plánují k řešení. Jak již bylo zmíněno v definici rolí, hlavním správcem backlogu je Product Owner. Není ovšem jediný. Do backlogu má zpravidla přístup celý tým, ale pouze Product Owner rozhoduje, které úkoly jsou prioritní a které naopak mohou počkat. Backlog může být produktový či sprintový a rozdíl mezi nimi je poměrně jednoduchý. Product Backlog zaznamenává úkoly na úrovni celého produktu, Sprint Backlog drží pouze úkoly zařazené do sprintu. Jednotlivé úkoly/funkcionality v rámci Backlogu jsou rozděleny na malé funkční celky. Pravděpodobně nejoblíbenější formou jsou tzv. User Stories, které se svou povahou dají přirovnat k artefaktům, které již byly popsány v kapitole metodiky RUP. V rámci prioritizace projdou User Stories analýzou a jsou připraveny v rámci Product Backlogu na posun do Sprint Backlogu, kde jsou již zpracovány samotnými vývojáři, testery apod. Ideálním stavem je, když takto detailně zpracovaných User Stories je přibližně na tři sprinty dopředu, kdy v případě nepřítomnosti Product Owner, např. z důvodu nemoci, je pro tým připraven dostatek práce, a nedojde tím pádem k výpadku. V rámci přípravy je taktéž doporučeno, aby za frontou takto připravených User Stories bylo připraveno na cca. 5 10 sprintů dalších User Stories, které nebudou v natolik detailní fázi analýzy. Zbytek Backlogu může být ponechán pouze v hrubém stadiu analýzy, neboť je možné, že dojde k nějakému změnovému požadavku a takto detailní analýza by byla zbytečná. 32

User story Jedná se o často používaný výraz v agilních týmech, má předepsaný formát, který definuje popis funkčnosti z pohledu uživatele, jako např.: Jako uživatel si přeji Funkcionalitu, abych dostal Businnes Value. 28 User story popisuje, co se má naimplementovat. Součástí User Story by měl být detailní popis, priorita, akceptační kritéria, odhady, komentáře k review, popř. další přílohy upřesňující popis funkcionality. V dnešní době poměrně vyspělých trackovacích nástrojů, jako např. Jira, je tento formát poměrně lehce dosažitelný. User story by měla být dostatečně malá, aby byla implementovatelná v rámci jednoho sprintu. Epic Epic je další z entit, které se mohou vyskytovat v Product Backlogu. Jedná se o určitý blok funkcionalit, který je příliš komplexní a složitý na to, aby mohl být implementovatelný v rámci jednoho sprintu. Takový Epic bývá zpravidla rozdělen na více User Stories, které se implementují postupně. Akceptační kritéria Jedná se o podmínky, které musí být splněny, aby User Story mohla být akceptována jako splněná, popř. dokončená. Sepisování akceptačních kritérií závisí na projektu, tzn. že akceptační kritéria nejsou povinná. V tomto ohledu spíše napomáhají transparentnosti popisu funkcionalit, kdy v případě možných problémů při odevzdávání hotového produktu jsou možným ukazatelem, zda by úkol splněn správně či nikoliv. Za akceptační kritéria je odpovědný Product Owner. Done kritéria Jedná se o další typ kritérií, která mohou být uvedena v rámci User Story. Tato kritéria určují, co musí být splněno, aby byla User story hotova. V praxi se může 28 ŠOCHOVÁ, Z., KUNCE, E.: Agilní metody řízení projektů. Brno: Computer Press, 2014, s. 48. 33

jednat např. o to, zda byly splněny všechny testy, dokumentace byla napsána, nebo zda byl produkt nasazen na příslušné prostředí. Done kritéria, stejně tako jako akceptační kritéria, vznikají dohodou mezi týmem a Product Ownerem a v ideálním případě by takto hotové funkcionality měly být ihned nasaditelné zákazníkovi. 29 Hodnocení User Stories Hodnocení User Stories je důležitou součástí plánování agilně řízených týmů, neboť každá User Story je jinak náročná a vyžaduje různou alokaci zdrojů. Na hodnocení se podílí celý tým společně s Product Ownerem, dochází zde ke k diskuzi o náročnosti a komplexitě funkcionalit, které na kterých bude tým pracovat. Výsledkem hodnocení je odhad. V rámci agilních metodik se pracuje s odhady relativními, neboť odhady časové jsou považovány za nespolehlivé. Jedním z oblíbených nástrojů je tzv. Planning poker. Jedná se v podstatě o hru, kdy každý z členů týmu má karty, kterými hodnotí náročnost konkrétní User Story. Product Owner představí funkcionality a zahájí se debata k dané funkcionalitě. Když je debata u konce, Scrum Master, který je moderátorem meetingu, vyzve všechny členy k hlasování a ti ve stejný okamžik zvednou kartu s číslem které vyjadřuje jejich představu o náročnosti. Následně Scrum Master vyzve členy týmu, kteří ohodnotili User Story jako nejjednodušší/nejsložitější, aby podali své vysvětlení, proč si myslí, že je funkcionalita tak jednoduchá/složitá. Výsledkem je tak další debata o náročnosti, která vede k upřesnění dalších otázek a odhad se tím stává přesnější. Pro Planning Poker lze využít jak papírové karty, tak např. mobilní aplikaci. Karty nabírají hodnot 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, nekonečno, otazník a symbol s kávou. 29 ŠOCHOVÁ, Z., KUNCE, E.: Agilní metody řízení projektů. Brno: Computer Press, 2014, s. 53. 34

Obrázek 4: Ukázka mobilní aplikace Scrum poker Zdroj: Vlastní zpracování 1.5.2 Ukazatele efektivnosti týmu V této kapitole bych se krátce pozastavil nad ukazateli, které napomáhají měřit efektivnost týmu. Rychlost Tento ukazatel, často nazývaný též Velocita, reprezentuje, kolik je toho tým schopen v rámci jednoho sprintu vytvořit na základě odhadů. Výpočet je poměrně prostý. Jedná se o součet hodnot odhadů jednotlivých User Stories, které byly dokončeny za jeden sprint. Výsledná hodnota ukazuje reálný výkon týmu. Tento údaj je nutné měřit dlouhodobě, až po několika sprintech je možné z údaje o rychlosti vypozorovat, jak tým funguje. Ideální stavem je, aby tento údaj byl konstantní, bez větších výchylek. Burndown graf Tento graf slouží k predikci výkonnosti týmu, má sestupnou tendenci a společně s velocitou se jedná o poměrně užitečný nástroj pro Product Ownera, který tímto může odhadovat, kolik User Stories z backlogu se ještě stihne zpracovat. Burndown graf může být buďto produktový, nebo sprintový, v závislosti na tom, jaký údaj má interpretovat. 35

Obrázek 5: Sprint burndown Zdroj: Scrum institute 30 1.5.3 Meetingy Jak již bylo mnohokrát řečeno, agilní metodiky kladou velký důraz na komunikaci v týmu i mimo tým. K tomu napomáhají meetingy, které tým realizuje. Meetingů je několik a probíhají v rámci sprintu. Standup Často nazývaný také jako Scrum meeting nebo denní Standup. Jedná se o meeting, který se realizuje na denní frekvenci a jak název napovídá, realizuje se ve stoje. Vývojový tým využívá Standup k ověření posunu kupředu v rámci cíle Sprintu a k ověření toho, jak se posun vyvíjí. 31 V rámci tohoto meetingu členové týmu odpovídají na otázky: co jsem dokončil včera 30 SCRUM INSTITUTE [online] [cit. 2017-07-20]. Dostupné z [online] Dostupný z URL: <http://www.scrum-institute.org/sprint_burndown_reports.php>. 31 SCHWABER, K., SUTHERLAND,J.: The Scrum Guide, [online], [cit.2017-04-22], dostupný z URL: <http://www.scrumguides.org/scrum-guide.html#events-daily>. 36

co dokončím dnes jaké mám problémy Časový fond tohoto meetingu je maximálně 15 minut a v jeho rámci by se nemělo zacházet do přílišných detailů. Je úlohou Scrum Mastera, aby tento meeting moderoval postaral se o jeho správný průběh. Standup meeting je primárně pro členy týmu. Účastnit se ho může i kdokoliv jiný, ale pouze v roli přihlížejícího. Plánování Jedná se o meeting, kde tým diskutuje nad prioritizovaným Product Backlogem a hodnotí User Stories, které následně přesouvá do Sprint Backlogu. Průběh meetingu je následovný: Product Owner představuje funkcionality, které mají být implementovány, členové týmu o nich diskutují a User Stories ohodnocují. Celý meeting je opět moderován Scrum Masterem, který průběžně monitoruje, kolik User Stories je naplánováno a kolik se jich ještě může naplánovat (usuzuje tak na základě parametru rychlosti týmu). Dalším úkolem Scrum Mastera je pomoci s ujasněním akceptačních kritérií a kontrolou, zda je popis jednotlivých User Stories dostatečný, aby mohly být implementovány. Názory na časový fond se velmi liší. Někteří jsou toho názoru, že plánování by nemělo trvat déle než jednu hodinu, jiné názory tvrdí, že plánování by mělo být důkladné, a tudíž by mělo trvat alespoň čtyři hodiny. V tomto ohledu je dle mého názoru rozhodující velikost týmu a poměry na projektu, popř. vztah týmu a Product Ownera. Backlog Grooming Jedná se o další společný meeting Product Ownera a vývojového týmu. V rámci tohoto setkání, ke kterému dochází přibližně v polovině sprintu, tým diskutuje společně nad Product Backlogem. Účelem tohoto meeting je porozumění Backlogu a upřesnění si otázek k User Stories. Tento meeting napomáhá plánování, kdy Product Owner získá zpětnou vazbu a v rámci této vazby doplní popisy konkrétní User Story. Tímto 37

se eliminují problémy, které by mohly vzniknout při plánování. V rámci Groomingu může také docházet k ohodnocování jednotlivých US. Priority a Pre-planning Na této schůzce participuje Product Owner s analytikem, softwarovým architektem, popř. UX designerem. Jedná se o pomocný prioritizační meeting, který pomáhá Product Owner při stanovování priorit v Backlogu. Sprint review Tento meeting je vlastně takovým demo meetingem pro zákazníka, popř. pro koncové uživatele. Prezentují se zde User Stories, které byly v rámci sprintu dokončeny. Logicky lze odvodit, že se tato schůzka odehrává na konci sprintu, v některých případech na začátku dalšího. Prezentuje zde celý tým. Sprint review pomáhá týmu získávat zpětnou vazbu od zákazníka. Retrospektiva Tak jako Sprint Review pomáhá získat zpětnou vazbu od zákazníka, tak Retrospektiva pomáhá týmu získat zpětnou vazbu od sám sebe. Jedná se o meeting, kde se schází celý tým a diskutuje nad dosavadním průběhem svých aktivit. V rámci retrospektivy dochází ke sběru dat, diskuze nad nimi a mělo by zde dojít k hlubšímu porozumění informacím a následně k brainstormingu a hledání řešení. Způsobů, jak dělat retrospektivu, je velmi mnoho, od systému lepících štítků, přes časovou osu, metodu plachetnice, až po šest barevných klobouků. Jedním z nejoblíbenějších je systém lepících štítků. Jednotliví členové lepí štítky s tématy na tabuli, která je rozdělena na pět částí: začít (start), dělat více (more), pokračovat (keep), dělat méně (less) a přestat (stop). 38

2 Praktická část V předchozí části práce byly představeny dva druhy vývojových metodik. Každá z nich představuje jiný pohled na proces vývoje softwaru. Rational Unified Process jako zástupce rigorózních vývojových metodik pohlíží na vývoj jako na předem definovaný proces, kde každá akce a každý postup jsou předem naplánovány. Hlavním bodem v rámci této metodiky je proces, metodika je zaměřena na velmi detailní dokumentaci včetně detailního modelování. Iterace jsou spíše delšího charakteru, komunikace je převážně písemná a uplatňuje se zde spíše direktivní styl řízení. Taktéž organizační struktura je složitější, neboť v rámci RUP bývá užito více rolí. Jako zástupce agilních metodik byl vybrán SCRUM. Jedná se v tomto případě o mladší vývojovou metodiku s odlišným pohledem na proces vývoje. Metodika Scrum nenahlíží na vývoj jako na předem definovaný proces, nýbrž jako na činnost dynamickou, která se neustále mění, a v tomto ohledu je zaměřena spíše na adaptaci aktuálním okolnostem. Scrum nepreferuje podrobnou dokumentaci, ba naopak tvrdí, že s mírou dokumentace se musí zacházet velmi střídmě. Pracuje s podstatně kratšími iteracemi, snaží se dodávat menší části funkcionalit ve vyšší frekvenci. Klade vysoký důraz na komunikaci jak uvnitř týmu, tak navenek. Struktura projektových rolí je podstatně chudší a z hlediska hierarchie přistupuje k týmu s myšlenkou, že všichni jsou si rovni. V následující části se hodlám zabývat užitím těchto metodik v praxi. Vzhledem k tomu, že jsem za svou dosavadní kariéru strávil přibližně pět let na projektu řízeném v metodice RUP a v současné době se již sedmým rokem pohybuji na agilně řízených projektech, převážně v metodice Scrum, zažil jsem již mnoho situací, které se v rámci metodických postupů řešily, jak v roli člena týmu, tak v roli metodika. Představeny budou dva projekty řízené ve výše zmíněných metodikách, v rámci čehož budou popsány průběhy jednotlivých iterací, organizační struktury projektů, postupy na projektech užívané a dodržování metodických postupů, popř. monitoring jejich odchylek, neboť metodiky většinou nebývají striktně dodržovány. 39