}w!"#$%&'()+,-./012345<ya

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY }w!"#$%&'()+,-./012345<ya Použití SCRUM pro menší a střední webové projekty DIPLOMOVÁ PRÁCE Roman Fianta Brno, 2011

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

3 Poděkování Děkuji doktoru Ráčkovi za trpělivé a inspirativní vedení této práce, cenné připomínky a rady, ochotu a nasměrování na správnou cestu; děkuji i za důvěru a podporu, díky které jsem dokázal zmíněnou cestu vydláždit. Dále děkuji svým blízkým, že se ke mně neotočili zády, když jsem je soustavně odbýval z důvodu nedostatku času. iii

4 Shrnutí Práce popisuje principy agilního vývoje softwaru a uvádí jejich výhody oproti rigoróznímu přístupu. Zaměřuje se zejména na jednotlivé současné varianty metodiky SCRUM, tyto popisuje z pohledu odlišnosti procesu, struktury týmu a používaných artefaktů. Na základě zvolených kritérií je vybrána vhodná variantu SCRUMu pro vývoj malých nebo středně velkých webových aplikací. V praktické části je připraven projekt vývoje malé nebo středně velké webové aplikace dle postupu SCRUM. Je vytvořen základní projektový plán, odhadnuty náklady, identifikována rizika. Navržený postup je následně zrealizován v praxi nad daným projektem a celkový postup je zhodnocen z pohledu času, nákladů a kvality vzniklého systému. iv

5 Klíčová slova scrum, agilní, projektové řízení, web, e-shop v

6 Obsah 1 Softwarové inženýrství Proč potřebujeme softwarové inženýrství? Modely životních cyklů Vodopád Spirála Rigorózní přístupy RUP Vhodnost metodiky RUP Agilní metodiky Agilní vs. Rigorózní Metodiky XP Scrum Lean development Crystal Další metodiky Scrum Empirické řízení procesů Jak funguje Scrum Srdce Scrumu Role Průběh Artefakty Product backlog Release backlog Sprint backlog Burndown chart Varianty Scrumu Typy A, B, C Scrum pro distribuované týmy Scrum společně s CMMI Kombinace s XP

7 3.3.5 Kombinace s metodikou Kanban Projekt webové aplikace s použitím Scrumu Start projektu Vize Funkční požadavky Plán projektu Rámcový časový plán Počet členů týmu Náklady Rizika Tým Scrum Master Tým Vlastník produktu Přizpůsobení metodiky Délka Sprintu Denní srazy Vývojářské techniky Kdy je úkol dokončen? Ganttův diagram Výběr nástroje Tabulkový procesor Požadavky PangoScrum Scrum d Agilo for Scrum ScrumDo Rally Dev Community ScrumDesk MiniScrum Další nástroje Nástroje pro Scrum Nástroje pro měření času Realizace Přípravy Sprint 1 - Položení základů Cíl Sprintu Product backlog Poker Sprint backlog

8 6.2.5 Postup prací Zhodnocení prvního Sprintu Sprint Zhodnocení Sprintu Sprint Skladový systém Graf průběhu Sprintu Zhodnocení Sprintu Sprint Sprint Sprint Sprint Přehled Zhodnocení Objem Sprintů Závěrečná analýza Řádky zdrojového kódu Odhad práce Porovnání s plánem v Ganttově diagramu Čas Náklady Rizika Kvalita Defekty Kvalita kódu ScrumDesk A Obrázky z vývoje aplikace B Ukázky zdrojového kódu aplikace B.1 Kategorie B.2 Animace C Odkazy na nástroje D Obsah přiloženého CD

9 Úvod Moderní doba je všechno, jen ne pomalá a ležérní. Je rychlá. Hoří termíny, výsledky práce jsou poptávány as soon as possible, bez mobilu a počítače je moderní člověk mnohdy ztracen. Celosvětová sít Internet umožňuje hromadné šíření informací v řádu desítek milisekund. Výsledky jsou požadovány okamžitě a v co nejvyšší kvalitě. Jakékoli zdržení postrkuje zákazníka do rukou konkurence. Je složitá. Nikdy v historii neměl člověk tolik informací a tolik možností volby, kolik má dnes. Jediný dotaz ve vyhledávači najde tisíce či miliony informací různé relevance. V obchodě jsme zavaleni tolika výrobky, že si již neumíme vybrat. Manažeři několikrát denně vydávají důležitá rozhodnutí na základě obrovského množství dat. Je nestálá. Pokud bylo dříve složité předpovědět, jaký bude svět za pět let, díky překotnosti vývoje je dnes ohromně těžké odhadnout, jak bude vypadat svět příští rok. Co fungovalo dnes, může být příští měsíc zastaralé. Jaká je doba, takový je i software. Jeho vývoj je rychlý, výsledný produkt je složitý a okolní podmínky jsou nestálé. Pokud dříve stačilo vyděrovat algoritmus výpočtu na děrný štítek, ten vsunout do sálového počítače a počkat několik minut na výsledek, dnes se setkáváme s aplikacemi, které s námi dokáží interagovat, které dynamicky reagují na naše chování, které s námi vedou dialog a v pozadí přitom dokáží zpracovávat množství dat, které by ještě nedávno bylo nemyslitelné. Vývoj softwaru dříve trval dlouho a stál hodně peněz. Jelikož všudypřítomnost konkurence nebyla taková, jaká je dnes, zákazník byl ochoten na výsledek čekat, třebaže dodaný produkt nakonec nesplňoval přesně jeho představy. Nynější doba požaduje, aby byl výsledný produkt vyvinut rychleji, stál méně peněz a jeho kvalita byla vyšší. Tradiční inženýrské techniky, které dříve pomohly překonat krizi vývoje softwaru, mnohdy nestačí držet pomyslný prst na tepu doby. Potřebnost nového přístupu byla ještě posílena příchodem Webu, kterému se daří postupně bořit zažitá paradigmata. Z těchto důvodů se na přelomu tisíciletí o své slovo přihlásily agilní metodiky. Cílem této práce je na konkrétním příkladě ukázat moderní způsob ří- 4

10 zení vývoje softwaru, konkrétně malé až střední webové aplikace, ve velmi malém týmu. V první kapitole této práce se zabývám příčinami softwarové krize a postupy, které ji nakonec pomohly zažehnat. Zmiňuji vodopádový a spirálový model životního cyklu, což jsou důležité pojmy umožňující pochopit současný směr vývoje. V následující kapitole srovnávám agilní a rigorózní přístupy k vývoji softwaru, stručně popisuji známé agilní metodiky a vybírám vhodného kandidáta pro vývoj ukázkové aplikace. Kapitola číslo 3 je věnována popisu frameworku Scrum, jež byl zvolen jako vhodný kandidát pro praktickou část práce. Jsou rozebrána specifika procesu, artefakty a struktura týmu. Podstatná část kapitoly je věnována i rozličným modifikacím Scrumu. Následuje praktická část práce, začínající kapitolou číslo 4. V ní jsou parametry Scrumu upraveny tak, aby odpovídaly požadavkům kladeným na projekt. Pro porovnání s tradiční metodou vývoje softwaru je uveden i plán pomocí Ganttova diagramu. Kapitola 5 je věnována výběru vhodného nástroje pro vývoj pomocí frameworku Scrum. Následující kapitola 6 popisuje vývoj ukázkového projektu zejména z pohledu řízení, je však doplněna i o některé implementační detaily. Součástí kapitoly jsou také grafické výstupy nástroje zvoleného pro podporu vývojového procesu dle Scrumu. Předposlední kapitola hodnotí dosažené výsledky a srovnává je s teoretickými předpověd mi vypočítanými na základě Ganttova diagramu. Zabývá se kvalitou vzniklé aplikace a na základě získaných dat se snaží předpovědět budoucí podobu vývojového procesu. Na tuto kapitolu navazuje závěr, který shrnuje dosažené výsledky a hodnotí přínos práce. 5

11 Kapitola 1 Softwarové inženýrství 1.1 Proč potřebujeme softwarové inženýrství? Software byl v dobách, kdy počítače ještě zabíraly celé sály, dílem hrstky technicky velmi zdatných lidí, a těmto lidem také sloužil. Počítač přijímal příkazy z děrných štítků a na výsledek se čekalo dlouho. Jak ale běžel čas, spolu s rostoucím výkonem hardwaru rostly i požadavky na software. Výstupní a vstupní zařízení se stávala sofistikovanějšími a programy nabývaly na komplexnosti. Software tak brzy narazil na limity týkající se vývoje, když ke konci 60. let naplno udeřila softwarová krize. [11] Produkty se tehdy vyvíjely převážně podle modelu napiš a oprav (codeand-fix) [3] a software se potýkal s častými prodleními v době dodání, překračováním rozpočtu a obecně nízkou kvalitou. Pro ilustraci uved me statistiku [21], která uvádí úspěšnost softwarových produktů pro vládu USA v době softwarové krize: téměř polovina produktů byla dodána, ale nikdy nebyla nasazena, přes 28 % produktů bylo zaplaceno, ale nedodáno, téměř 20 % produktů bylo po rozsáhlých změnách nakonec zahozeno, zhruba 3 % produktů byla po úpravách použita a necelá 2 % produktů byla použita beze změny. Důvod této hrozivé statistiky byl nedostatek povědomí o zákonitostech při výrobě softwaru a absence softwarového inženýrství. Tento pojem se poprvé oficiálně objevil na konferenci NATO v roce 1969 [2], kde se mimo jiné probírala nutnost řešit softwarovou krizi, způsobenou zejména nedostatkem systematického přístupu k vývoji. Postupně se ustálilo množství technik, které se sice nestaly pověstnou stříbrnou kulkou vývoje softwaru [4], ale pomohly zažehnat krizi a nastolit pravidla, jejichž dodržová- 6

12 1. SOFTWAROVÉ INŽENÝRSTVÍ ním vývojový tým podstatně zvyšuje svou šanci na úspěch. Zmiňme například modularitu, strukturované programování, znalost životního cyklu softwaru, modelovací nástroje a později například objektový přístup. 1.2 Modely životních cyklů Životní cyklus softwaru popisuje fáze, kterými software při vývoji prochází. [11] Modelů životních cyklů je mnoho, mezi nejrozšířenější patří takzvaný vodopád a iterativní/inkrementální životní cyklus. Zatímco při vodopádu software postupně prochází fázemi od návrhu až po nasazení, při iterativním/inkrementálním vývoji se můžou některé fáze vícekrát opakovat. [11] U iterativního přístupu celý produkt postupně roste a zpřesňuje svou podobu. Pokud je cílem iterace dodat inkrement neboli přírůstek, mluvíme o inkrementálním vývoji; výsledný systém je pak tvořen nezávislými přírůstky integrovanými do jednoho celku. [17] Vodopád Vodopád, představený v roce 1970 Dr. Winstonem Roycem, je stále jedním z nejpopulárnějších modelů životního cyklu. Vývoj podle vodopádu se dělí na několik fází obvykle se uvádí analýza, návrh, implementace, testování a provoz. Každá fáze vyjma té první staví na výstupech fází předcházejících. Royce ve vodopádu přehledně načrtl fakt, že software je potřeba nejdříve pečlivě naplánovat (jako architekt nejdříve projektuje budovu) a až poté se pustit do implementace. Kladl také velký důraz na dokumentaci. [20] Vodopád je oblíbený zejména mezi manažery, protože je velmi jednoduchý na uchopení a poskytuje snadnou měřitelnost postupu. Model však v sobě skrývá několik zádrhelů. [11] Na počátku není rozumně možné zjistit, co přesně zákazník požaduje. Chyby zanesené na začátku projektu, které se projeví v pozdějších fázích, jsou velmi drahé, model není flexibilní. Dlouho trvá, než se začne vytvářet reálný produkt, zákazník může získat pocit, že projekt se nevyvíjí, výsledek pak dostane formou velkého třesku. 7

13 1. SOFTWAROVÉ INŽENÝRSTVÍ Obrázek 1.1: Vodopádový model Tyto nedostatky daly následně vzniknout modifikacím vodopádu, obohacujícím jej například o prototypování. Vodopád se tak i dnes hodí na projekty, kdy vývojový tým přesně ví, co a jak má dělat, tedy obrazně řečeno pro vývoj produktů jako na běžícím páse ; tento předpoklad však platí dosti zřídka. Vodopádový model je tedy dnes odborníky často považován za překonaný Spirála Spirálový model, představený Barry Boehmem v práci A Spiral Model of Software Development and Enhancement [3], vštěpil do povědomí softwarových inženýrů dva velmi důležité pojmy - iterativní vývoj a analýzu rizik. Iterativní vývoj bere v potaz fakt, že zejména u nových projektů na počátku je těžké (a zhusta nemožné) přesně specifikovat, jak má výsledný produkt vypadat. Vývoj je proto lepší provádět v několika cyklech iteracích. Na počátku je tak možné specifikovat například jen rámcovou specifikaci, vytvořit první hrubou verzi produktu a na základě konzultace se zákazníkem zpřesnit požadavky do další iterace. Druhá převratná myšlenka Boehmova modelu je důsledná a opakovaná analýza rizik. Ta redukuje ceny softwaru tím, že snižuje cenu jeho přepracování, obvykle o %. [21] Rizika jsou totiž při vývoji (zejména komplexního) softwaru všudypřítomná a jediný způsob boje proti nim je tudíž 8

14 1. SOFTWAROVÉ INŽENÝRSTVÍ Obrázek 1.2: Spirálový model odhalit je předem a eliminovat či alespoň snížit jejich dopad. Rizika jsou také podstatnou součástí metodiky Scrum, kterou se zabývá tato práce. Ze spirálového modelu vychází množství metodik, např. MBASE, Win- Win či RUP, která bude stručně představena i v této práci. 1.3 Rigorózní přístupy Z modelů uvedených v předchozí sekci vychází většina tzv. rigorózních přístupů. Ty se obecně vyznačují velmi podrobně popsaným procesem vývoje s velkým množstvím dokumentů, vysokou mírou formalizace a důrazem na specifikace a analýzu. Rigorózní přístupy mohou být vhodné pro komplexní projekty a systémy s kritickou mírou spolehlivosti (např. letecké systémy či systémy pro zdravotnictví). 9

15 1. SOFTWAROVÉ INŽENÝRSTVÍ RUP Typickým představitelem rigorózní metodiky je Rational Unified Process (RUP). Jedná se o iterativní, objektově orientovanou metodiku řízenou případy použití (use-case-driven approach). Vývoj pomocí metodiky RUP sestává ze čtyř fází [11]: zahájení definice cílů projektu a životního cyklu; projektování analýza potřeb projektu a zákazníka, analýza rizik, plánování; realizace kompletace analýzy a designu, tvorba zdrojových kódů, testování; předání předání produktu uživatelům, školení, podpora, údržba. Obrázek 1.3: Rational Unified Process - fáze vývoje Každá z těchto fází probíhá v několika iteracích. Modelování probíhá pomocí jazyka UML, jenž je dobře vybaven pro objektový návrh. Metodika RUP vyžaduje splnění mnoha formálních náležitostí a pro každý meziprodukt (Artifact) definuje mnoho fragmentů, namátkou obecný popis, určení 10

16 1. SOFTWAROVÉ INŽENÝRSTVÍ rolí, účel meziproduktu, časovou náročnost, určení šablony, UML reprezentaci a další. [11] Pokrok projektu se hodnotí po dosažení mezníku (Milestone), tedy formálního ukončení některé z fází Vhodnost metodiky RUP Výhodou metodiky RUP je jednoznačně její obecnost, šíře a mohutnost, iterativní přístup a z něj plynoucí snažší správa změn, znovupoužitelnost a včasné odhalení rizik. [11] Nesporným plusem je také velmi široké povědomí o metodice a množství nástrojů umožňující práci s ní. Pro malé a flexibilní týmy se však snadno některé výhody (obecnost, formalizace) mohou proměnit v nevýhody zejména u rozsáhlejších projektů může tým ztratit příliš mnoho času kvůli práci s metodikou a vývoj tak může začít postrádat efektivitu. Podobně se nevyplatí zavádět RUP pro jednoúčelové týmy. [11] 11

17 Kapitola 2 Agilní metodiky Rigorózní postupy se léty osvědčily u velkých, organizovaných a stabilních týmů. Software však již dnes mnohdy bývá dílem malých a flexibilních skupin vývojářů (kupříkladu 37signals), pro které se vysoká míra formalismu a byrokratických zdržení může snadno stát přítěží. Kvůli obrovské konkurenci není zákazník ochoten čekat na kvalitu dlouho, jako tomu bylo dříve. Jeho požadavky se navíc často mění, na což tradiční přístupy neumí reagovat; jak uvádí Ken Schwaber v [23], postrádají flexibilitu. I proto se s nástupem nového tisíciletí rozšířily takzvané agilní metodiky. V roce 2001 se v Utahu sešlo několik zkušených odborníků, kteří cítili potřebu změnit způsob vývoje softwaru. Obvykle sami již zažili krach několika projektů a neměli z náplně své práce příliš dobrý pocit. Překvapivě snadno se během debaty shodli na principech, které se jim samotným osvědčily při práci na svých projektech. Tyto principy jsou obsaženy v hodnotách Manifestu agilního vývoje softwaru [1]. Autoři v něm tvrdí, že ačkoli si uvědomují důležitost hodnot uvedených vpravo, upřednostňují: jednotlivce a komunikaci před procesy a nástroji, fungující software před vyčerpávající dokumentací, spolupráci se zákazníkem před vyjednáváním o smlouvě, schopnost reagovat na změny před dodržováním plánu. Jednou z hlavních tezí agilního vývoje je tedy přijetí změny jako všudypřítomného činitele při vývoji softwaru (ne nadarmo se původní domovská stránka agilní metodiky Scrum nazývá controlchaos.com). Oproti složitým specifikačním dokumentům spoléhají agilní metodiky na přímou komunikaci se zákazníkem a časté dodávky (částí) softwaru, na které může zákazník reagovat a které mu přinášejí hodnotu tedy pravý opak již zmíněného velkého třesku. 12

18 2. AGILNÍ METODIKY 2.1 Agilní vs. Rigorózní Nejčastěji se rozdíl mezi agilními a rigorózními metodikami popisuje na trojúhelníku znázorňujícím funkcionalitu, časový plán a zdroje. Zatímco rigorózní metodiky se snaží dosáhnout smluvené funkcionality i za cenu zvýšení nákladů a zpoždění projektu, metodiky agilní přizpůsobují funkcionalitu pevně dané horní hranici na náklady a čas vývoje. [11] Obrázek 2.1: Železný trojúhelník a jeho modifikace Společným jmenovatelem agilních metodik jsou oproti rigorózním přístupům velmi krátké iterace, jejichž výstupem je použitelný přírůstek (inkrement) softwaru. Nové funkce se mohou dodávat i denně a přináší okamžitou zpětnou vazbu od zákazníka. [32] Ten je při vývoji přítomen v mnohem větší míře než u rigorózních metodik, dá se říci, že je součástí vývojového týmu a neustále koriguje své požadavky. Množství exaktních dokumentů známé z tradičních přístupů pak nahrazují agilní metodiky důrazem na přímou, osobní komunikaci v týmu. Podle průzkumu provedeného Scottem W. Amblerem z IBM v roce 2010 vykazují agilní metodiky vyšší míru úspěšnosti než metodiky tradiční (viz obrázek 2.2). Bez povšimnutí by neměl zůstat fakt, že agilní metodiky se vyplácí i u velkých týmů. Z průzkumu [15], který mezi softwarovými firmami provedla v roce 2010 společnost VersionOne, pak vyplývá, že: 90 % dotázaných pracuje ve společnosti, která nějakým způsobem používá agilní metodiky (v roce 2009 [16] to bylo 84 %), 83 % (oproti 80 % v roce 2009) respondentů potvrdilo rychlejší či alespoň stejně rychlý vývoj pomocí agilních metodik oproti metodikám rigorózním 13

19 2. AGILNÍ METODIKY Obrázek 2.2: Průzkum Scotta W. Amblera z IBM z roku 2010 mezi šest hlavních přínosů zavedení agilních metodik patří zvýšená schopnost řídit měnící se priority, viditelnost pokroku projektu, vyvažování mezi technologickými a obchodními cíli, zvýšená morálka týmu, rychlejší dodání na trh a zvýšená produktivita. Lze tedy nahlédnout, že agilní metodiky se staly za poslední roky velmi populární. Navíc již dávno nejsou jen záležitostí malých týmů, existují případy, kdy byl Scrum použit pro týmy čítající přes 800 lidí [24]. 2.2 Metodiky Agilních metodik existuje v současnosti hned několik. Cílem této podkapitoly je uvést jejich stručný přehled a zvolit vhodného zástupce, pomocí nějž bude vyvíjen elektronický obchod v praktické části práce XP Extrémní programování (XP) patří mezi zdaleka nejpopulárnější a nejznámější agilní metodiky. Základní tezí XP je přesvědčení, že jediným exakt- 14

20 2. AGILNÍ METODIKY ním, jednoznačným, změřitelným, ověřitelným a nezpochybnitelným zdrojem informací je zdrojový kód. [11] Této tezi je přizpůsobena celá metodika, která zavádí různé novátorské postupy, kupříkladu párové programování, kdy programátoři pracují ve dvojicích a vzájemně tak kontrolují svou práci. S tím souvisí jedna z elementárních vlastností XP, kterou je kolektivní vlastnictví kódu. [32] Extrémní programování slibuje dodat výsledek v nejkratším možném čase a za minimální náklady. Extrémní programování doporučuje vždy zvolit nejjednodušší řešení a případné změny či komplexnější kód (pokud bude nezbytný) implementovat později. [32] Aby při takovémto přístupu byl schopen vývojový tým dostát požadavkům na kvalitu, je třeba najímat talentované, kvalitní pracovníky. Těm metodika XP na oplátku slibuje, že je práce bude bavit, jelikož většina programátorů upřednostňuje psaní zdrojového kódu před zkoumáním návrhu a psaním dokumentace. Požadavky zákazníka jsou v XP zaznamenávány pomocí uživatelských příběhů (user stories), které v jedné až zhruba třech větách stručně zachycují nějakou vlastnost systému. Od tradiční specifikace požadavků se uživatelské příběhy odlišují mnohem menší mírou detailu a zaměřením na potřeby uživatele Scrum Scrum je v současné době zdaleka nejpopulárnější agilní metodikou, jak ukazují již zmíněné průzkumy společnosti VersionOne. V roce % agilních vývojových týmů využívalo Scrum [16], v současné době je to již 58 % [15]. Dalších 17 % týmů kombinuje Scrum s metodikou Extrémního programování. Mezi důležité vlastnosti Scrumu patří jeho flexibilita Scrum je totiž hlavně nástroj na řízení procesů, konkrétní vývojářské techniky si tak tým může volit sám podle potřeby. Kvůli všeobecné uznávanosti, rozšířenosti, množství literatury a jednoduchým principům jsem Scrum zvolil jako metodiku pro vývoj elektronického obchodu v praktické části práce. Proto bude této metodice věnována mnohem hlubší pozornost v samostatné kapitole Lean development Pro tuto metodiku se ještě v českých kruzích neustálil název, budeme si tak muset vystačit s anglickým přepisem. Metodika Lean development pochází z jiných než softwarových inženýrským disciplín konkrétně z odvětví výroby automobilů ve firmě Toyota. Pravidla této metodiky doporu- 15

21 2. AGILNÍ METODIKY Obrázek 2.3: Výzkum agilních metodik z roku 2010 společnosti VersionOne čují absolutní odstranění všeho zbytečného, co v průběhu vývoje vzniká a co může snížit efektivitu a zvýšit náklady [11]. Tato pravidla, přizpůsobená vývoji softwaru, tvoří metodiku Lean development. Obecně hovoříme o sedmi základních principech. Eliminace plýtvání. Cílem je naučit se rozpoznávat neefektivní procesy a vidět zdroje plýtvání s ohledem na zachování kvality softwaru. Rozvoj učení. Vývoj pomocí krátkých iterací a důraz na zpětnou vazbu a synchronizace jednotlivých složek vývoje umožní poučit se z minulých chyb a zefektivnit další práci na projektu. Rozhodovaní co nejpozději. Tento princip umožní pružně reagovat na změnu. Rychlé a časté dodávky. Změny se snáze zapracovávají do malých částí systému než do kompletního projektu. Pravomocní pracovníci. V tradičních přístupech často řadoví zaměstnanci netuší, kam společnost směřuje a jaké jsou její priority. Přidělení pravomocí i níže postaveným zaměstnancům zvýší jejich motivaci a přispěje k lepšímu chápání souvislostí. Integrita. Zde se myslí jak integrita softwaru (důraz na testování a refaktorizace), tak integrita vývojového procesu, kdy bychom měli 16

22 2. AGILNÍ METODIKY umět najít a odstranit anomálie narušující přirozený průběh vývojového procesu. Vidět celek. Tento princip se týká zejména optimalizace: má smysl měřit spíše celkový výkon systému a hledat slabé články řetězce než optimalizovat každou komponentu zvlášt Crystal Crystal je spíše než jediná metodika celá rodina metodik, soubor pravidel, podle kterých si můžeme vytvořit vlastní metodiku na míru. Zakladatel Alistair Cockburn vyzdvihuje tři základní vlastnosti metodik z rodiny Crystal - zaměření na lidi, ultra-lehkost a přizpůsobivost. [5] V závislosti na počtu lidí zapojených do projektu, závažnosti projektu a priorit projektu určuje Crystal pomocí matice způsob vývoje projektu, množství dokumentace, formu setkání a podobně. Ačkoliv pravidla určená metodikou Crystal jsou závazná, lze je nahradit obdobnými prvky z jiných agilních metodik, což přináší značnou adaptabilitu. Přes tyto výhody se však metodika Crystal nestala tak populární, jako je v současné době kupříkladu Scrum Další metodiky Existují i další metodiky, jako TDD (Test-driven development), FDD (Featuredriven Development vývoj řízený vlastnostmi), ASD (Adaptive Software Development) a další. TDD přikazuje, aby testy byly napsány dříve než kód, což je obecně doporučovaný a často používaný způsob vývoje. Vývoj řízený vlastnostmi klade (na agilní metodiku nezvykle silný) důraz na vytvoření celkového modelu, z nějž se následně odvozuje podrobný seznam vlastností, které jsou pak centrální součástí celého vývoje. ASD nahrazuje klasické fáze vývoje (plánování, návrh a realizaci) fázemi spekulace, učení a spolupráce. [11] Přehled metodik v této kapitole nebyl vyčerpávající, což však ani nebylo jejím cílem. Tím byl všeobecný přehled současného stavu na poli agilních přístupů a výběr vhodné metodiky pro projekt elektronického obchodu. Jak již bylo zmíněno, byl zvolen Scrum, jelikož se jedná v současnosti o nejrozšířenější metodiku, která je výborně popsaná v literatuře a zároveň poskytuje hodně volnosti. 17

23 Kapitola 3 Scrum Scrum má své kořeny již poměrně hluboko v minulosti, oficiálního představení se ale dočkal v roce Samotný název Scrum není zkratkou, jak by mohlo vyplývat z jejího častého uvádění velkými písmeny, ale pochází z anglického výrazu pro mlýn používaný v rugby do češtiny by se dal také přeložit jako skrumáž. [11] Podobně jako se v rugby při mlýnu na malém prostoru přetlačují všichni hráči, je důležitou součástí metodiky Scrum každodenní shromáždění ve stoje, kde se stručně řeší otázky týkající se postupu na projektu. Scrum ve své podstatě není metodika, ale pouze rámec (framework) [22], na jehož základě může vývojový tým použít techniky a procesy, které se mu osvědčily. 1 Ač se tedy může zdát, že existuje nespočetně variant Scrumu, jedná se většinou o stále stejný Scrum framework, pouze s použitím jiných vnitřních procesů a technik. Jelikož pro Scrum jsem nenašel v českých publikacích adekvátní názvosloví (Václav Kadlec v [11] například ctí v pojmenování anglický originál), pokusil jsem se pro omezení bastardizace jazyka některé výrazy přeložit. Snažil jsem se převést výrazy do češtiny a zároveň zachovat jejich původní vzhled pro snadnou korelaci s původními pojmy Sprint review tak není Zhodnocení, ale Recenze (Revize mi přišla vzdálená původnímu významu a příliš formální). U pojmu Product Owner jsem váhal zřejmě nejvíce v české literatuře jsem se setkal s překladem Vlastník produktu, subjektivně mi ale připadalo, že Majitel by se vyslovoval snáze. Nakonec jsem se rozhodl nečeřit vody a zůstat u již zažitého Vlastníka produktu. Je úsměvnou historkou z natáčení, že tým, na který jsem dohlížel jako Scrum Master v praktické části této diplomové práce, poměrně záhy Vlastníka produktu překřtil na Vlastíka. Výraz se vžil a i Vlastník produktu jej přijal za svůj. Stejně tak se nakonec vžilo označení Retro pro Retrospektivu Sprintu. 1. Přesto se lze s termínem metodika setkat i v oficiální literatuře, v této práci se tedy toto označení bude vyskytovat také. 18

24 3. SCRUM Na druhou stranu, některé pojmy jsem pro jejich všeobecnou známost raději ponechal v původní podobě - Scrum tak není skrumáž či mlýn, ale Scrum, podobně u Scrum Mastera jsem se rozhodl opustit variantu Mistra Scrumu a ponechat původní výraz. Z pojmu Daily Scrum se ale nakonec stal Denní sraz, jelikož Denní Scrum nezní v češtině příliš věrohodně a Denní setkání mi opět přišlo dlouhé a příliš formální. Kvůli pronikání manažerského newspeaku do češtiny jsem se rozhodl ponechat výraz stakeholder v původní podobě rozumný český ekvivalent totiž pravděpodobně neexistuje. Výsledek překladu není nejlepší, mnohdy poněkud skřípe a ne vždy řeší problém skloňování cizích výrazů, přesto si myslím, že vynaložená snaha nebyla zbytečná a je lepší mluvit například o Recenzi Sprintu než o Sprint Review Meetingu. Na druhou stranu musím konstatovat, že ne všechny překlady se v našem týmu v praxi uchytily: uživatelským příběhům jsme nakonec říkali Historky a příběhovým bodům jednoduše Story pointy. Je záležitostí každého týmu najít, co mu vyhovuje. Anglicky Scrum Sprint (Scrum) Team Scrum Master Product Owner stakeholders Daily Scrum Release Sprint planning meeting Sprint retrospective Sprint review pigs chickens user stories epic story points impediment backlog Planning Poker Česky Scrum Sprint Tým (Scrumu) Scrum Master Vlastník produktu stakeholdeři Denní sraz Release či Vydání Plánování Sprintu Retrospektiva Sprintu Revize Sprintu prasata kuřata uživatelské příběhy Epos příběhové body překážka backlog Plánovací poker 19

25 3. SCRUM 3.1 Empirické řízení procesů Ken Schwaber ve své knize Agile Project Management with Scrum [24] identifikuje dva typy řízení procesů - definovaný a empirický. Definované řízení procesů umožňuje opakovaně zajistit dohodnutou míru kvality. Může se však stát, že procesní aktivity jsou natolik složité což u softwaru obvykle jsou že musíme řízení procesů průběžně upravovat podle aktuálních potřeb; pak mluvíme o empirickém řízení procesů. Rozdíl mezi definovaným a empirickým řízením uvádí ve své knize Process Dynamics, Modeling and Control i autoři B. A. Ogunnaike a W. H. Ray: It is typical to adopt the defined (theoretical) modeling approach when the underlying mechanisms by which a process operates are reasonably well understood. When the process is too complicated for the defined approach, the empirical approach is the appropriate choice. Kdykoli je to možné, používáme definované řízení, jelikož je ze své podstaty levnější a umožňuje určit cenu produktu jako u běžného zboží. Díky komplexitě aktivit spojených s procesy je však možné, že produkt bude neúspěšný a bude nutné jej přepracovat v takovém případě je levnější vyvinout produkt správně napoprvé dražší empirickou metodou řízení procesů než riskovat neúspěch a kompletní přepracování (zde lze vidět paralelu s vodopádovým modelem, u něhož k předání produktu a jeho zhodnocení dochází až na konci celého vývojového procesu). Příkladem empirického řízení procesu je například revize zdrojového kódu zkušenými vývojáři v případě dokončení funkcionality a následná oprava chyb, přizpůsobení kódu dohodnutým standardům a poučení do budoucna. [24] Scrum jako agilní metodika schopná reagovat na změny staví na empirickém řízení procesů. Základní pilíře umožňující takové řízení jsou obecně viditelnost, inspekce a adaptace. [24] Konkrétní podoba řízení projektu pomocí Scrumu bude popsána v následujících částech. Viditelnost. Aspekty procesu, které ovlivňují jeho výstup, musí být pravdivé a viditelné osobám řídícím proces. Pod pojmem pravdivé si představme zejména shodu na definicích a vyhýbání se vágním pojmům jak například definovat, že je vlastnost hotova? Znamená to, že byla nakódována, otestována a integrována, nebo že pouze bylo možné ji zkompilovat? Inspekce. Rozličné aspekty procesu musí být kontrolovány dostatečně často na to, aby byly zachyceny nepřípustné odchylky. 20

26 3. SCRUM Adaptace. Pokud kontrolor z výsledku inspekce vyvodí, že jeden či více aspektů procesu se ocitl mimo přípustné limity a výsledný produkt tak bude neakceptovatelný, musí proces upravit co nejrychleji, aby se předešlo dalšímu odchylování. 3.2 Jak funguje Scrum Srdce Scrumu Scrum, jako všechny agilní metodiky, staví na iterativním přístupu, jak je zřejmé z obrázku 3.1. Výstupem jednotlivých iterací (spodní kruh) je použitelný přírůstek (inkrement) produktu. Před začátkem iterace tým vybere ze seznamu funkcí ty, které mají nejvyšší prioritu a které je možno stihnout v rámci jedné iterace. Týmu je ponechána volnost, jak výsledku dosáhne tým řídí sám sebe. Horní kruh pak představuje denní inspekci, při které se členové týmu setkají, aby zjistili aktivity druhých a shodli se na případných vhodných změnách. Obrázek 3.1: Srdce Scrumu Role Scrum definuje pouze tři role - Scrum Master, Product Owner (Vlastník produktu) a Team (Tým). Lidé, kteří se na projektu přímo nepodílí, ale nějakým způsobem jsou v něm zainteresovaní, se nazývají stakeholdeři. 21

27 3. SCRUM Vlastník produktu. Vlastník produktu představuje zájmy stakeholderů, tedy lidí, kteří bud financují projekt, nebo hodlají používat funkcionalitu jím poskytovanou či budou nějakým jiným způsobem projektem ovlivněni. Vlastník produktu je zodpovědný za tvorbu požadavků, návratnost investic (ROI) a plán vydání (release plan). Požadavky jsou zachyceny v artefaktu nazývaném Product backlog. Je taktéž prací Vlastníka produktu určovat prioritu jednotlivých položek v Product backlogu. Je obvyklé, že Vlastník produktu přichází ze strany zákazníka, není to však pravidlem; může být i členem vývojového týmu. [24] Tým. Tým je zodpovědný za vyvíjení funkcionality, tedy z hlediska softwaru za tvorbu kódu. Jak bylo zmíněno, tým řídí a organizuje sám sebe a sám určuje, jakým způsobem přetvoří vybranou funkcionalitu z Product backlogu do použitelného, funkčního inkrementu. Mnoha tradičním týmům proto chvíli trvá, než se dokáží adaptovat na Scrum a přijmout fakt, že jim nikdo nezadává práci a příkazy. Zodpovědnost za úspěch každé iterace leží na celém kolektivu týmu. Výše zmíněnými principy Scrum dosahuje stavu, že tým se cítí zavázán splnit cíl Sprintu. [24] Ideální počet členů týmu je obvykle uváděn jako 5 9 osob, spoluzakladatel Scrumu Jeff Sutherland však doporučuje tým maximálně o sedmi lidech pro zachování co nejvyšší efektivity. 2 Mike Cohn v [9] uvádí velmi stručnou poučku pro velikost týmu: pokud nasytíte tým dvěma pizzami, máte správnou velikost. V téže knize autor rovněž uvádí statistiku vytvořenou Dougem Putnamem z QSM; týmy ze 491 sledovaných projektů byly rovnoměrně rozřazeny do skupin dle počtu členů: 1,5 3, 3 5, 5 7, 9 11, Z výsledků vyplývá, že týmy o 1,5 3 lidech jsou nejproduktivnější a vynaloží na stejný projekt nejméně celkového úsilí. Co se však týče doby práce, za nejkratší čas zvládnou projekt dokončit týmy s 5 7 členy. Rozdíly mezi týmy do sedmi členů nejsou tak markantní jako u týmů nad 9 lidí, u kterých se pozoruje citelný nárůst doby řešení, vyšší náklady, nižší produktivita a větší množství zanesených chyb. Scrum Master. Scrum Master má na starosti samotný proces Scrumu školí principy Scrumu lidem zainteresovaným na projektu, implementuje vhodně Scrum do kultury firmy a kontroluje dodržování pravidel a praktik Scrumu. Je to právě Scrum Master, který na každodenním setkání klade otázky a zajišt uje moderaci diskuse. Scrum Master může i nemusí být čle

28 3. SCRUM nem vývojového týmu. Náplní jeho práce je odstraňovat překážky (v angličtině impediments), které brání týmu v dosažení maximální efektivity. [26] Některé publikace tak kvůli jeho ochranitelským vlastnostem pasují Scrum Mastera do role jakéhosi pastýře týmu. Dle [9] je dobrý Scrum Master: zodpovědný za co nejvyšší efektivitu týmu, skromný stavící zájmy týmu nad své vlastní, schopný spolupráce vytvářející prostředí, kde se členové týmu nebojí klást otázky a kolektivně řešit problémy, zavázaný k úspěšnému dokončení Sprintu jako všichni ostatní členové týmu, schopný ovlivnit ostatní, jelikož z hlediska Scrumu není nadřízeným týmu a může tak spoléhat pouze na přirozenou autoritu a schopnost moderovat tok diskuse, erudovaný, jelikož vedoucí osobnost orientující se v problematice projektu zvyšuje šanci týmu na úspěch. Rozdělení rolí. Scrum rozděluje role lidí zapojených do projektu na prasata (pigs) a kuřata (chickens). Toto rozdělení vychází z vtipu, uvedeném na obrázku 3.2. Mezi prasata patří lidé zastávající jednu z výše zmíněných třech rolí. Ostatní kuřata do projektu nemohou zbytečně zasahovat a například jim nepřísluší mluvit na Denních srazech. Toto rozdělení je důležité pro vlastnost viditelnosti vyjasňuje se, kdo na projektu pracuje a kdo jen kibicuje Průběh Na počátku projektu stojí vize, která může být formulovaná i vcelku vágně, s upřesněním se totiž počítá později. Vlastník produktu je zodpovědný za přetavení vize ve funkcionalitu, která maximalizuje návratnost investic. Činí tak přes správu Product backlogu a prioritizaci jeho položek. Předměty z backlogu, které slibují přidat nejvíce hodnoty k výslednému produktu, mají vždy nejvyšší prioritu. Jednotlivým iteracím se ve Scrumu říká Sprinty. Ačkoli doporučovanou délkou pro jeden Sprint je zhruba 30 kalendářních dní, Scrum je flexibilní natolik, že se běžně setkáváme i se Sprinty, které trvají méně než týden; 23

29 3. SCRUM Obrázek 3.2: Role prasat a kuřat v projektu řízeném pomocí Scrumu vždy záleží na povaze projektu. Veškerá práce na projektu se odehrává ve Sprintech. Na začátku každého Sprintu probíhá Plánování Sprintu (Sprint planning meeting). Toto setkání nesmí trvat déle než osm hodin (pro kratší než 30denní Sprinty je pak tato hodnota adekvátně nižší). V první polovině přiděleného času Vlastník produktu pomocí prioritizace prvků z Product backlogu sdělí týmu, co je požadováno. Tým pak po úvaze sdělí Vlastníkovi produktu, kolik z požadovaných prvků stihne vypracovat v nadcházejícím Sprintu. V druhé polovině setkání Tým plánuje průběh Sprintu. Tímto plánováním začíná běžet čas Sprintu. [24] Častým způsobem, jak ohodnotit položky backlogu, je Plánovací Poker, známý z Extrémního programování. [8] Každý člen týmu dostane karty s číselnými hodnotami, které lze přiřadit položkám backlogu. Tým prochází jednotlivé položky, k nimž vždy proběhne stručné vysvětlení od Vlastníka produktu následované diskusí týmu o způsobu, jak lze položku implementovat. Následně každý člen zvolí kartu s bodovou hodnotou, která podle něj nejvíce odpovídá náročnosti položky. Tuto kartu položí rubem nahoru. Jakmile jsou s tímto krokem všichni hotovi, karty se naráz otočí. Pokud se zahrané karty bodovými hodnotami shodují, položka je odhadnuta. Pokud ne, hráči, jejichž karty se svými hodnotami nejvíce liší, podají krátké odůvodnění a začne další kolo, dokud tým nedosáhne konsenzu. Je důležité připomenout, že položky se odhadují týmově, nezávisle na tom, který člen je bude implementovat [7] přiřazení práce probíhá až na příslušných Denních srazech. Denní srazy jsou jedním z nejdůležitějších a nejinovativnějších prvků Scrumu. Toto setkání trvá pouze 15 minut a probíhá výhradně ve stoje, aby byla u účastníků podpořena tendence ke stručnosti vyjadřování. Denní sraz 24

30 3. SCRUM umožňuje včas korigovat směřování projektu a synchronizovat vývojáře, kteří na něm pracují. Každý člen týmu při srazu odpovídá na následující tři otázky: Co jsem na projektu udělal od posledního Denního srazu? Co plánuji udělat na projektu do příštího Denního sraz? Jaké překážky stojí v cestě splnění závazků na tomto Sprintu a projektu? Sprint je ukončen dvěma setkáními. Na Recenzi Sprintu (Sprint review meeting) prezentuje tým Vlastníkovi produktu a případným dalším stakeholderům odvedenou práci. Cílem tohoto neformálního setkání je povzbudit přítomné k dohodě nad další prací týmu. [24] Vzhledem k faktu, že výstupem Sprintu je funkční přírůstek, může dojít k dohodě tento přírůstek skutečně vydat. Druhé setkání, Retrospektiva Sprintu (Sprint Retrospective meeting), se zabývá vnitřními procesy týmu a Scrum Master na něm dodává Týmu motivaci a podněty ke zlepšení efektivity a zábavnosti práce v rámci frameworku Scrum. Projekt dle Scrumu prochází třemi fázemi: Předehra (Pregame) se skládá z plánování a příprav na projekt, ve Hře (Game) probíhá samotný vývoj a Dohra (Postame) obsahuje přípravy na vydání, finalizaci, finální otestování a spuštění. [29] Artefakty Nejdůležitějšími artefakty Scrumu jsou backlog a Burndown chart. Zatímco backlog obsahuje funkcionalitu produktu, Burndown chart transparentně zobrazuje aktuální pokrok projektu. Product backlog Product backlog v sobě soustředí veškeré požadavky na funkcionalitu produktu. Zodpovědnost za Product backlog nese bez výjimky Vlastník produktu. [24] Product backlog se stále mění podle aktuálních potřeb a nikdy není úplný. [19] Vlastník produktu pomocí určení priority má přímý vliv na položky budoucího Sprintu, jelikož Tým vždy řeší položky nejvyšší priority. Přesnou podobu backlogu Scrum nedefinuje, často se jedná o obyčejný dokument v Excelu či lepící kartičky na tabuli. Položky Product backlogu jsou zpočátku definovány jen v hrubých obrysech, detaily jsou upřesněny, až když je na ně zaměřena pozornost jako na položky s vysokou prioritou. Pro položky backlogu, nejčastěji uživatelské příběhy, existuje několik způsobů ohodnocení náročnosti příběhové body, velikosti triček či přirovnání ke zvířatům. 25

31 3. SCRUM Obrázek 3.3: Příklad Product backlogu Populární posloupnost příběhových bodů pro ohodnocení položek backlogu je modifikovaná Fibonacciho řada (1, 2, 3, 5, 8, 13, 20, 40). [6] Příběh ohodnocený 2 body trvá dvojnásobně déle než příběh ohodnocený 1 bodem, 3bodový příběh trvá podobně dlouho jako spojení jednoho 1bodového a jednoho 2bodového příběhu atp. Při Plánování Sprintu pak lze díky hlubšímu porozumění a rozpracování učinit odhad v hodinách. Product backlog by měl dle [9] dodržovat zásady DEEP. Detailed appropriately. Spolu s rostoucí prioritou položek, a tedy i zvyšující se pravděpodobností jejich brzkého zařazení do Sprintu, roste i míra detailu, do které jsou rozpracovány (viz obrázek 3.4); zpočátku se jedná o rozsáhlé uživatelské příběhy (eposy), ty se s rostoucí prioritou zpřesňují, rozpadají na několik dílčích uživatelských příběhů. Estimated. Položkám jsou přiřazeny odhady, nejedná se jen o seznam pracovních činností. Emergent. Product backlog se neustále mění. Prioritized. Položky, které slibují přinést produktu nejvyšší hodnotu, mají nejvyšší prioritu. 26

32 3. SCRUM Obrázek 3.4: Míra detailu u položek backlogu Release backlog Release backlog sdružuje požadavky z Product backlogu potřebné pro určité vydání (release). Pro případ, že produkt není rozdělen do více vydání, ztrácí Release Backlog smysl a je možné jej vynechat. Sprint backlog Položky z Product backlogu (resp. Release backlogu), na kterých Tým pracuje v rámci Sprintu, jsou přeneseny do artefaktu Sprint backlog. Každá položka je v tomto stadiu detailněji rozpracována a je jí přiřazen časový odhad (nejčastěji v jednotkách hodin). Čas přiřazený úkolům se různí, nejčastěji se však jedná o 4 16 hodin; položky delší než 16 hodin by měly být rozloženy na více úkolů. Díky Sprint backlogu Tým snadno vidí, kolik práce je třeba udělat, aby na konci Sprintu mohl doručit funkční přírůstek produktu. Aby se zamezilo nedorozuměním, je třeba předem dohodnout, co znamená, že je položka backlogu hotová. Mělo by se jednat o důkladně otestovaný, strukturovaný, odladěný, dokumentovaný a spustitelný kód, připravený na nasazení, definice se však mohou napříč týmy lišit. Pro případ, že příprava na implementaci není součástí definice hotovo, je možné udržovat transparentnost procesu přidáním nedokončené práce do backlogu. [25] 27

33 3. SCRUM Burndown chart Burndown chart je možná největším lákadlem pro použití Scrumu, protože velmi přehledně ukazuje množství zbývající práce. Každá položka v backlogu je ohodnocena časovým odhadem. Pokud je na položce pracováno, časový odhad se denně aktualizuje. Výsledná data pak lze jednoduše použít v grafu Burndown chart, který je tak skvělou vizualizační pomůckou pro přehled pokroku projektu a z něj vycházející časové odhady. Obrázek 3.5: Burndown chart Burndown chart existuje ve třech podobách - pro celý produkt, Vydání (Release) nebo Sprint. Princip jejího fungování je pro všechny případy totožný, třebaže nejpřesnější údaje podává Burndown chart v případě Sprintů, kde jsou položky backlogu rozpracovány nejvíce do detailů. Alternativou k Burndown chart je Burnup chart. Místo klesající křivky tento graf zobrazuje dokončenou práci jako křivku, která roste nahoru směrem k druhé křivce představující objem práce na probíhajícím Sprintu. Tento objem se může v průběhu iterace dynamicky měnit, Burnup chart tak poskytuje transparentnější údaje o zbývající práci a dosaženém pokroku na Sprintu. [28] I Burndown chart je však možné upravit, aby měnící se množství práce reflektoval při změně objemu práce na Sprintu se posune dno grafu. [29] 28

34 3. SCRUM 3.3 Varianty Scrumu Jelikož je Scrum framework, a ne metodika, variantami Scrumu myslíme zpravidla implementaci rozličných vývojářských technik; časté je například spojení Scrumu s extrémním programováním. Jakoukoli modifikaci, která mění základní principy a artefakty Scrumu, už totiž podle zakladatele Kena Schwabera nemůžeme považovat za opravdový Scrum. [22] V komunitě softwarových vývojářů se přesto mluví o jistých variantách Scrumu, které si ted rozebereme Typy A, B, C Ze Scrumu se stala široce používaná metodika a po celém světě existují stovky tisíc projektů, které jsou jím řízeny. Díky mohutné uživatelské základně se tudíž evolučně vyvinuly varianty Scrumu, které slibují ještě vyšší produktivitu a škálovatelnost. Rychlost vývoje totiž od počátku tisíciletí ještě pokročila a původní Scrum, ve kterém se počítá s vydáním aplikace zhruba jednou za půl roku, už mnohdy nemusí stačit. Proto v současné době rozlišujeme tři typy Scrumu - A, B a C. Jak je vidět na obrázku 3.6, pokročilé varianty Scrumu spočívají v překrývání (typ B) či přímo sloučení (typ C) Sprintů. Obrázek 3.6: Typy Scrumu Typ A je Scrum ve své původní podobě, tak, jak byl představen Kenem Schwaberem. Jedná se o nejčastější implementaci a vyžaduje oproti dalším 29

35 3. SCRUM dvěma variantám nejméně zkušeností a úsilí. Jeff Sutherland jej v [29] označil názvem Team Scrum (Týmový Scrum). Jednotlivé iterace Sprinty jsou v tomto případě oddělené jedna od druhé. Jelikož při Týmovém Scrumu veškerý vývoj probíhá v časově ohraničeném rámci Sprintu, mezi jednotlivými iteracemi nutně nastává zdržení v podobě reorganizace na nový Sprint tým tak místo ideálních 12 Sprintů ročně stihne jen zhruba 9. V počátečních fázích Sprintu navíc jistou dobu trvá, než vývojáři dostatečně proniknou do uživatelských požadavků a začnou programovat. 3 Typ B tato prodlení eliminuje pomocí včlenění přípravných prací na následující iteraci do právě probíhajícího Sprintu. Jednotlivé Sprinty tak na sebe navazují kontinuálně a Product backlog je stále zaplněn, tým je tedy celkově produktivnější. Proto se tato varianta nazývá Continuous Flow. Jeff Sutherland však doporučuje nasazení typu B až poté, co byl dokonale zvládnut typ A. Nasazení typu B také vyžaduje pochopení principů Lean development. Pokud tým beze zbytku ovládá Scrum typu B, existuje ještě jedna cesta, jak zvýšit produktivitu a zkrátit čas mezi jednotlivými vydáními Scrum typu C (All-At-Once). Jak samotný název napovídá, při této variantě probíhá několik Sprintů současně. Při použití tohoto typu bylo třeba zavést nové artefakty - Scrum of Scrums (setkání vedoucích jednotlivých týmů na denní bázi), nově pak MetaScrum (setkání všech stakeholderů jednou týdně, jehož účelem je dohlížet na všechny Sprinty a upravovat jejich směřování). Typ C také předpokládá velmi pokročilou automatizaci řídících procesů. Výsledkem jsou minimální režijní náklady Jeff Sutherland dosáhl méně než 60 sekund denně pro vývojáře a méně než 10 minut denně pro Scrum Mastera. Typ C umožňuje konverzi celé firmy na vývoj podle Scrumu, vyžaduje však pokročilé zkušenosti Scrum pro distribuované týmy Scrum lze implementovat nikoli jen na malé týmy, ale dá se škálovat na celé organizace. Pokud však v nadnárodní firmě existují týmy, které operují v několika časových pásmech, je nutné Scrum modifikovat, aby umožňoval spolupráci i v takto ztížených podmínkách. [35] Pokud se pracovní hodiny jednotlivých členů distribuovaného týmu překrývají, je řešení poměrně přímočaré - Denní srazy se naplánují v překrývajícím se čase. Tým se však musí vypořádat s mnohými překážkami konference na dálku, jako je absence vnímání řeči těla a pomalejší domluva. 3. MacCormack [14] při analýze dat z 29 softwarových projektů firmy Hewlett-Packard nalezl silnou korelaci mezi adekvátní specifikací produktu a produktivitou. 30

36 3. SCRUM Jelikož se více než polovina mezilidské komunikace odehrává nonverbálně [33], může dojít k různým nedorozuměním. Pro nepřekrývající se pracovní hodiny uvádí autoři v knize [35] čtyři způsoby Denního srazu. První a nejméně efektivní zavádí předávání znalostí mezi členy týmu pomocí psané dokumentace (např. wiki, ). Druhou možností je řešení přes prostředníka, kdy prostředník (obyčejně Scrum Master) předává informace týmům z jiného časového pásma. Informace se ale mohou ztrácet a zkreslovat, podobně jako při dětské hře tichá pošta. Třetím způsobem je střídání času meetingů tak, aby se každý tým mohl účastnit setkání alespoň obden; i zde existuje riziko ztráty informace od vývojářů, kteří se zrovna neúčastní. Čtvrtou a poslední variantou je technika, kdy se tým flexibilně domlouvá na časech společných srazů, které se mohou konat i mimo pracovní dobu, což může znamenat pro některé jedince problémy. Žádný z přístupů tedy není nejlepším řešením. Distribuované týmy vždy vyžadují kompromisy, a to nejen co se týče Denních srazů, ale i komunikace mezi jednotlivými členy na rozdílných lokacích. Komunikace na dálku je mnohem méně efektivní než přímá spolupráce na jednom pracovišti. Dalším problémem mohou být i kulturní a jazykové bariéry Scrum společně s CMMI Agilní techniky byly zpočátku považovány za novum, které nejde sloučit s rigorózními procesy zavedených společností. Vyspělost organizace, měřená pomocí modelu CMM (Capability Maturity Model), případně novějšího CMMI (Capability Maturity Model Integration), značí, do jaké míry společnost kontroluje své procesy a jak dokáže zaručit úspěch projektu. Rozlišujeme stupně 1 až 5, kde 1 je výchozí stupeň a 5 je maximální hodnota, kdy má společnost procesy velmi silně pod kontrolou a jsou maximálně optimalizované. [21] Kritické vládní projekty kupříkladu většinou vyžadují velmi vyspělé společnosti, které integrovaly CMMI na stupni 4 nebo 5. Mohlo by se zdát, že agilní přístupy do konceptu přesně definovaných procesních struktur příliš nezapadají, pomalu se však objevují výjimky. Paulk ve své knize [18] tvrdí, že racionálně implementované agilní metodiky nasazené ve vhodném příhodném prostředí korespondují s mnoha praktikami CMM stupně 2 a 3. Agilní metodiky, konkrétně Scrum, však lze použít i u pokročilejších společností implementující CMMI stupně 5. Jak je uvedeno v [29], Systematic, firma, která pomocí implementace CMMI 5 snížila úsilí nutné k dokončení projektu na 69 % oproti CMMI 1, po zavedení 31

37 3. SCRUM principů Scrum snížila úsilí až na 35 %. Společnost Systematic integrovala Scrum jako metodu pro dokončení krátkých iterací (Sprintů) na zvolené podmnožině úkolů s nejvyšší prioritou. Při zavádění do společností dodržující vysoký stupeň CMM(I) je však agilní techniky třeba řádně institucionalizovat a zavést jejich disciplinované dodržování, aby nebyly narušeny požadavky CMM. [29] Kombinace s XP Extrémní programování je metodika, se kterou bývá Scrum spojován nejčastěji. Symbióza těchto dvou metodik funguje tak, že Scrum poskytuje rámec pro řízení projektu, zatímco extrémní programování zajišt uje konkrétní vývojářské techniky. [12] V anketách [16] a [15] z let 2009 a 2010 získala kombinace těchto dvou technik největší zastoupení rozšířenější je už jen samotný Scrum. Mezi nejoblíbenější techniky zavedené extrémním programováním patří párové programování, kdy vývojáři tvoří a revidují kód ve dvojicích. Dále můžeme zmínit důraz na testy, kolektivní vlastnictví kódu a nepřetěžování pracovníků přesčasy. Pokud si pročteme doporučení nejnovější literatury zabývající se Scrumem ([9], [19]), zjistíme, že techniky Extrémního programování začínají pomalu se Scrumem splývat. Jakoby už položky backlogu byly automaticky uživatelské příběhy ohodnocené uživatelskými body, plánovací poker byl standardem pro plánování, kolektivní vlastnictví kódu bylo samozřejmým předpokladem, důraz na testy a kvalitní kód neoddiskutovatelným doporučením a párové programování častou a ověřenou technikou Kombinace s metodikou Kanban Kanban má podobně jako Lean development kořeny v Japonsku. Jedná se o skutečně velmi dietní metodiku, která předepisuje naprosté minimum technik a týmu nechává maximální volnost. Oproti Scrumu ruší pevné časové ohraničení Sprintů a nenutí rozdělení úkolů na podúkoly tak, aby se vešly do jednotlivých iterací. Kanban stojí na třech základních principech: vizualizace pracovního toku (workflow) rozdělení práce na úkoly, jejich vepsání na karty a přilepení na zed či nástěnku, zároveň použití pojmenovaných sloupců pro zařazení úkolů do jednotlivých fází pracovního toku; 32

38 3. SCRUM přiřazení limitů pro jednotlivé fáze pracovního toku; měření hodnoty Lead time, tedy průměrného času k dokončení jedné položky. Kanban vztahuje omezení na množství práce k dané fázi pracovního toku, zatímco Scrum jej vztahuje k dané iteraci. Rozdíl těchto přístupů je dobře vidět na obrázku 3.7, kde Kanban definuje maximum dvou položek, které se mohou nacházet ve fázi Ongoing. Mezi další rozdíly patří zejména absence (či ještě lépe nepovinnost) mnohých prvků Scrumu v metodice Kanban jedná se kupříkladu o časové odhady, definice rolí (Kanban nedefinuje žádné) či volitelnou prioritizaci. Obrázek 3.7: Kanban tabule Kanban je obecně záhodno použít na projekty s velmi rychle se měnícími požadavky; úkoly, na kterých tým pracuje, totiž u Scrumu nejdou změnit v průběhu Sprintu, ale až po něm. Scrum tak zajišt uje nerušenost a soustředěnost týmu. Obyčejně je tato vlastnost ceněná, v některých projektech však může být na škodu. Vývojové týmy proto mohou zkusit spojit Scrum a Kanban dohromady - vzdát se časového rámce Sprintů a umožnit měnit požadavky kdykoli. Je však nutné podotknout, že přestože tým může dodržovat denní setkání a jiné postupy Scrumu, technicky vzato se už nejedná o Scrum. Mluvíme tak spíše o Kanbanu s použitím technik Scrumu. Jedna technika Kanbanu je však ve Scrumu velmi populární lepení karet s úkoly na tabuli (resp. zed či nástěnku) rozdělenou na sloupce, kupříkladu na To-Do, Probíhající a Hotové. Tato technika signifikantně zvyšuje přehlednost backlogu. 33

39 Kapitola 4 Projekt webové aplikace s použitím Scrumu V předchozí kapitole byly popsány současné varianty Scrumu, rozdíly mezi nimi a vhodnost použití. V této kapitole bude věnována pozornost nasazení vhodné varianty Scrumu na webový projekt elektronického obchodu. Nejedná se o uměle vytvořený příklad, ale reálný projekt s praktickým využitím. Jelikož projekt je rozsahem spíše menší a i některé další jeho vlastnosti jsou, jak zmíním dále, poměrně specifické, rozhodl jsem se Scrum přizpůsobit tak, aby přinášel co nejvíce užitku jak týmu, který se vyznačuje velmi nízkým počtem členů, tak zákazníkovi. Vycházel jsem z doporučení uvedených v literatuře, zkušeností ostatních týmů, diskuse s vlastním týmem a v neposlední věci i pocitu, pro který má angličtina pojmenování gut feel. Do češtiny bych tento pojem přeložil nejspíše jako intuice či selský rozum. Ne vždy totiž byl možné najít jednoznačně správnou odpověd, což jsou přesně chvíle kdy gut feel může pomoci učinit rozhodnutí. [24] 4.1 Start projektu E-komerce je v současnosti velmi rozšířená činnost a elektronických obchodů je na internetu spousta, at už těch čistě elektronických, nebo jako alternativní prodejní kanál obchodů kamenných. Jelikož na webu je konkurence vzdálená mnohdy pouze jedno kliknutí, je třeba zákazníka zaujmout na první pohled vizuální atraktivitou a dobrou použitelností Vize Cílem praktické části je vytvořit elektronický obchod (e-shop) specializovaný na prodej oblečení. Součástí výsledné aplikace bude jak back-end (administrace), tak front-end (prezentační část); obě části budou postavené na webové platformě. Elektronických obchodů je na internetu k dispozici spousta, a to jak placených verzí, tak open-source variant. Zdálo by se, že vytvořit další e-shop 34

40 4. PROJEKT WEBOVÉ APLIKACE S POUŽITÍM SCRUMU je zbytečné, nicméně jako ukázkovou aplikaci jsem jej zvolil z následujících důvodů. Specializace. Cílem bylo vytvořit specializovaný, na míru upravený obchod optimalizovaný na prodej oblečení. Nejedná se tak o další všeobecný obchod obsahující přebytečné funkce, ale produkt cílený na prodej oblečení, bot a doplňků. Názornost. E-shop je velmi typická aplikace, kterou si každý dokáže snadno představit, a při jejímž vývoji půjde dobře ukázat principy Scrumu. Praktické využití. Předpokládá se nasazení do produkčního prostředí. Vhodná velikost. E-shop je nikterak velká aplikace, kterou není těžké rychle vyvinout ve velmi malém týmu, což personální situace vyžadovala. Alan Cooper ve své knize About Face [10] doporučuje, aby si tým určil jasné a výstižné heslo, kterého se bude po celou dobu vývoje držet. Heslo by mělo nejlépe v několika úderných slovech vystihovat hlavní motto projektu. Cíl projektu popisovaného v této práci bylo vytvořit E-shop, který je v prodávání oblečení a bot pevný v kramflecích Funkční požadavky Výše zmíněná vize staví na reálných podnětech pocházejících od majitele obchodu s oblečením, který projevil zájem rozšířit svou živnost i do elektronické podoby. Aby bylo možno určit velikost týmu pro vývoj aplikace, byl ve spolupráci s majitelem sestaven seznam základních funkčních požadavků na e-shop. E-shop měl rozlišovat alespoň dvě základní uživatelské role uživatel (zákazník) a administrátor (majitel obchodu). Bylo dohodnuto, že administrátor budoucího elektronického obchodu bude moci spravovat následující položky: produkty, značky, kategorie, sezóny (obvykle jaro/léto a podzim/zima s příslušným rokem), 35

41 4. PROJEKT WEBOVÉ APLIKACE S POUŽITÍM SCRUMU objednávky, množství produktů příslušných velikostí na skladě. Hlavní devízou nového e-shopu měla být především nativní podpora prodeje oblečení. Bylo dohodnuto, že kromě administrační části bude vytvořena i část prezentační, a to včetně grafického návrhu. Po shrnutí základních funkčních požadavků a získání hrubé představy budoucího produktu tak k určení velikosti týmu zbývalo zjistit časové rozpětí dokončení projektu. 4.2 Plán projektu Tři hlavní atributy každého projektu - čas, funkcionalita a rozpočet, nemohou být nikdy všechny pevně dané, nejméně jeden z nich musí být proměnný. [19] Volba, které atributy zafixovat, záleží na prioritách projektu jedná se o aplikaci s omezeným rozpočtem? Záleží úspěch aplikace na co nejbližším datu vydání? Oproti počátkům softwarového inženýrství není díky komplexnosti moderního softwaru zvykem zafixovat funkcionalitu požadavky na ni se totiž v průběhu projektu neustále mění. Roman Pichler ve své knize [19] doporučuje určit jako fixní proměnnou čas a přizpůsobit funkcionalitu. Zafixování data a ustanovení pevné délky iterací umožňuje pravidelně dodávat hodnotné přírůstky. Při pevně stanoveném datu a stabilním týmu je navíc jednoduché vypočítat náklady (za předpokladu, že práce je hlavní položka výsledné ceny). Místo pevného data vydání však Pichler navrhuje sestrojit časové okno, do kterého se má vydání produktu vejít, aby byl produkt pro zákazníka hodnotný. Skutečné datum vydání se od toho přesně naplánovaného totiž může při odhadu vycházejícím z požadavků lišit až o 60 %. 1 Plán vydání ve Scrumu tedy není pevně určen předem v dokumentaci projektu, ale je postupně vytvářen a měněn za spolupráce vývojářského týmu a zadavatele. Ačkoli pro větší projekty je třeba důkladnější plánování s předstihem až několik Sprintů dopředu, u menších projektů, ke kterým se řadí i probíraný e-shop, obvykle stačí seskupovat položky z Product backlogu do podskupin značících jednotlivá vydání - takovéto podskupině se říká Release backlog. [19] Pro porovnání agilního a tradičního vývoje byl vytvořen i plán pomocí Ganttova diagramu, který bude probrán na konci této kapitoly. 1. Tyto hodnoty vycházejí z tzv. kuželu nejistoty, představeného Barry Boehmem. 36

42 4.2.1 Rámcový časový plán 4. PROJEKT WEBOVÉ APLIKACE S POUŽITÍM SCRUMU Majitel obchodu Jiří Lejska původně požadoval mít e-shop naprogramovaný nejpozději do dvou měsíců, a to jak část administrační, tak prezentační. Jiřího jsem následně seznámil s komplexností vývoje softwaru a jeho nejistou dobou vydání. Byl ujištěn, že výsledkem každého Sprintu bude inkrement přinášející hodnotu a výslednou podobu bude moci přímo ovlivňovat na základě dosažených výsledků. Spolupráce mohla být také prodloužena v případě Jiřího spokojenosti. Blížil se konec ledna, časové okno vydání projektu bylo tedy stanoveno na konec března s tolerancí dva týdny. Do té doby měla být vyvinuta verze e-shopu s dostatečnou funkcionalitou pro prodávání zboží. Případné pokročilé funkce, které by se do data vydání nestihly implementovat, by byly dodány později. Počet členů týmu Na základě předchozích zkušeností jsem se nakonec rozhodl pro tříčlenný vývojářský tým. Tento počet považuji za dostatečný na předvedení principů Scrumu a zároveň velikostně přiměřený množství práce, která se měla do konce termínu stihnout. Složení týmu se věnuji podrobněji v samostatné podkapitole Náklady Aby bylo možné realisticky odhadovat časovou náročnost a proveditelnost jednotlivých úkolů, bylo nutné se shodnout, jaké technologie a postupy bude tým dodržovat. Důraz byl kladen na open-source technologie a minimalizaci nákladů týmu. Výhodou Scrumu je nesporně fakt, že k řízení je potřeba naprosté minimum nástrojů. Na uživatelské příběhy stačí tužka a papír, popřípadě libovolný tabulkový procesor. Kvůli zefektivnění procesu jsem však hledal nástroje, které by umožnily strojové zpracování dat, spolupráci a v neposlední řadě i export a import dat. Konkrétní požadavky a výběr nástroje jsou zpracovány v samostatné kapitole. Přímé finanční náklady z pohledu týmu byly pouze: kancelářské potřeby papíry, fixy, lepící štítky; magnetická tabule její použití umožňuje rapidní spolupráci, prototypování a je skvělým pomocníkem pro brainstorming ohledně nových nápadů; 37

43 4. PROJEKT WEBOVÉ APLIKACE S POUŽITÍM SCRUMU Lze tedy vidět, že náklady na zavedení Scrumu jsou spíše mentální než finanční. Jako technologii pro vývoj aplikace bylo zvoleno PHP spolu s MySQL. Přestože PHP není nejlepší volbou na poli jazyků pro webovou platformu, jeho negativa byla vyvážena předchozí zkušeností všech tří členů týmu s tímto jazykem, velmi širokou dostupností hostingů s podporou PHP a v neposlední řadě nedostatkem času nutného pro proniknutí do nového jazyka kvůli okamžitému startu projektu. Jelikož je cílem této práce především ukázat fungování Scrumu pro malé až střední projekty, volba technologie není ve výsledku tak podstatná. Kromě výše zmíněných iniciálních investic byla jediným nákladem práce vývojářů, která se dala snadno a transparentně vypočítat díky pevnému časovému rámci pravidelně probíhajících Sprintů. Jak zmíním dále, problémem byl proměnlivý počet odpracovaných hodin jednotlivých členů, průměrně se však dala časová kapacita jednoho člena odhadnout zhruba na 6 hodin týdně. Výpočet nákladů tedy probíhal podle vzorce náklady = počet sprintů 5 dní počet členů týmu 6 hodin sazba za hodinu Rizika Řízení rizik se nachází v povědomí softwarových inženýrů již od zveřejnění spirálového modelu. Proto byla i u tohoto projektu možná rizika předem zvážena a vyhodnocena. Pravděpodobnost nastání rizika byla odhadnuta kombinací intuice a zkušeností z předchozích projektů. V následující tabulce vidíme rizika, pravděpodobnost jejich nastání, způsobenou ztrátu a expozici rizika. Expozice rizika je součin pravděpodobnosti a ztráty. Tento způsob výpočtu rizik je běžnou praktikou při řízení projektů, je zmiňovaný například v [21]. Vysvětlení údajů v tabulce následuje. Riziko Pravděpodobnost Ztráta Expozice Odchýlení od požadavků 0, Pozdní dodání 0, Pomalá odezva systému 0, Odchod člena týmu 0, Výsledný produkt nebude odpovídat představám zadavatele. Jak uvádí Roman Pichler v [19], každé rozhodnutí týkající se projektu v sobě nese určité riziko. Vývoj softwaru se tudíž neobejde bez rizik. Navíc, čím vyšší je neurčitost výsledného produktu, tím vyšší je i riziko. Neurčitost je spojena 38

44 4. PROJEKT WEBOVÉ APLIKACE S POUŽITÍM SCRUMU s nedostatečnou znalostí, proto by neurčité a rizikové položky měly mít při vývoji softwaru vysokou prioritu. Přesně to předepisuje Scrum, použitý pro vývoj vzorového projektu. Díky této technice a díky iterativnímu vývoji, zainteresovanosti zákazníka a častým dodávkám funkčního softwaru tedy Scrum efektivně snižuje výše zmíněné riziko, proto byla pravděpodobnost nastavena na pouhých 5 %. Cena je odhad za přepracování některé podstatné části projektu. Expozice rizika je tak v poměru k projektu v řádu pouhých desítek tisíc velmi nízká, lze tedy dobře vidět, že díky volbě agilního vývoje se tímto rizikem téměř nemá cenu zabývat. Výsledný produkt nebude dodán včas. Toto riziko by měla metodika Scrum také účinně potlačovat. Jednoduché a názorné artefakty jako Release backlog pomáhají včas odhalit, když se projekt odchyluje od dohodnutých termínů. Dalším nástrojem Scrumu pro kontrolu rychlosti vývoje jsou každodenní setkání týmu a hodnotící setkání po každém Sprintu. Jelikož se Vlastník produktu aktivně podílí na směřování projektu, může kdykoli naplánovat implementační Sprint, ve kterém bude dokončená funkcionalita implementována do produkční verze. I kdyby byl projekt zpožděný, je tak možno zprovoznit alespoň jeho část a snížit tak celkovou ztrátu. Pokuta byla stanovena za zpoždění projektu větší než měsíc. Za dodání části projektu by byla tato pokuta poměrově snížena. Výsledná expozice rizika tedy značí poměrně malé nebezpečí. Systém bude pomalý. Pravděpodobnost pomalosti systému byla odhadnuta na 0,2. Tým se držel zlatého pravidla optimalizace, totiž neoptimalizovat, dokud to není nezbytně nutné. [34] Odhad ztráty byl však poměrně komplikovaný jak odhadnout, kolik procent zákazníků odejde při pomalé odezvě systému? Nejnovější výzkum společnosti Akamai, provedený roku 2009, ukázal, že uživatelé očekávají načtení stránky do dvou sekund 2 a 40 % lidí po třech vteřinách marného čekání na vykreslení stránky odchází. Pokud předpokládáme, že náš e-shop by měl vykazovat měsíční zisk Kč, tedy Kč ročně, a stránky by se nedokázaly vykreslit do tří vteřin, mohli bychom díky odchodu 40 % uživatelů vypočítat ztrátu, která by činila Kč. Expozice rizika je pak Kč, což je nejvíce ze zmíněných rizik. Přestože časté dodání přírůstků, které je součástí Scrumu, umožní dříve odhalit problémy s rychlostí aplikace, riziku jsme se rozhodli předejít. 2. Což je o dvě sekundy méně, než v roce

45 4. PROJEKT WEBOVÉ APLIKACE S POUŽITÍM SCRUMU Pro případ, že by vyhrazený výkon nepostačoval, zakoupili jsme virtuální server umožňující dostatečnou rezervu pro zvýšení výkonu. Rezerva může být využita i pro případné zrychlení administrace, jelikož při pomalé odezvě by mohlo dojít k nespokojenosti zákazníka, na kterého spoléháme v předání dobrých referencí dalším potenciálním klientům. Ztráta by v případě nespokojenosti zákazníka tudíž mohla být ještě větší. Rychlost odezvy aplikace je totiž klíčovým faktorem pro způsob, jakým ji uživatel vnímá a pro přirozené, nepřerušované myšlení. Studie na téma interakce člověka s počítačem byly prováděné již v šedesátých letech 3. Výstižné shrnutí uvádí ve své knize guru interakčního designu Alan Cooper [10]. Do 0,1 sekundy vnímají uživatelé odezvu systému jako okamžitou. V tomto případě mají pocit, že přímo manipulují s uživatelským rozhraním a daty. Do zhruba 1 sekundy mají uživatelé pocit, že systém reaguje. Pravděpodobně si všimnou prodlení, to je ale dostatečně malé, aby myšlenkový proces uživatelů zůstal nepřerušený. Do zhruba 10 sekund uživatelé jasně vnímají, že systém je pomalý, a jejich myšlenky se pravděpodobně začnou rozbíhat; stále jsou však schopni věnovat aplikaci jistou dávku pozornosti. Kriticky důležité je v tomto případě použití ukazatele pokroku (progress bar). Po deseti sekundách přestává uživatel věnovat aplikaci pozornost. Naším cílem bylo tedy udržet čas odezvy kolem jedné sekundy. Případné zpomalení odezvy by bylo řešeno přesunem obchodu na virtuální server s vyšším výkonem a optimalizací kódu. Odchod člena týmu. Odchod nějakého člena z týmu je vzhledem ke složení týmu věc poměrně pravděpodobná. Záleží samozřejmě, v jaké fázi projektu by člen týmu odešel. Jelikož Brooksův zákon říká, že přijmutí nových sil na zpožděný projekt způsobí jeho ještě větší zpoždění 4, došel jsem k závěru, že pokud by člen týmu odešel v pokročilejší fázi projektu, nemělo by, zejména vzhledem k velikosti projektu, valný smysl najímat nového člena. Hlavními dopady naplnění tohoto rizika jsou tedy zpoždění 3. Lze nalézt na s_law 40

46 4. PROJEKT WEBOVÉ APLIKACE S POUŽITÍM SCRUMU projektu (odtud ztráty) a ztráta znalosti v důsledku odchodu člena. Opatření byla navrhnuta následující: dostatečná rezerva termínu dokončení, párové programování na složitějších úkolech a dokumentace kódu, a to přinejmenším vnořenými komentáři. 4.3 Tým Scrum Master Role Scrum Mastera jsem se ujal já, mým úkolem tak bylo předat nabyté znalosti ostatním členům týmu a dohlížet na dodržování pravidel a principů Scrumu. Role to pro mě byla zcela nová, zpočátku jsem tak těžil hlavně z příkladů v literatuře. Zároveň jsem se nevzdal role vývojáře, kromě dohlížení nad Scrumem jsem tedy psal i kód Tým Druhým vývojářem byl Pavel Chmelař, jenž měl kromě programování na starosti i grafický návrh. Díky svým kontaktům to byl on, kdo sehnal klienta. Třetí člen vývojového týmu byl do projektu zahrnut až po vytvoření vize a základních funkčních požadavků; nechtěl být jmenován, pro větší přehlednost mu přiřad me jméno Milan Šebera. Jeho úkolem bylo programování. Po sestavení se tým sešel a Scrum Master zhruba ve čtyřech hodinách představil podrobněji principy, pravidla a role Scrumu. Vývojáři v týmu měli o agilním vývoji jen obecné povědomí, do té doby pracovali na projektech samostatně Vlastník produktu Vlastníkem produktu se stal z pochopitelných důvodů majitel obchodu Jiří Lejska. Jiřímu jsem vysvětlil principy a pravidla Scrumu, stejně jako výhody, které mu tento typ vývoje přinese. Pro majitele, jako člověka nepříliš se orientujícího v problematice vývoje softwaru, byla lákavá zejména vize jeho úzké spolupráce na projektu a časté dodávky fungujících inkrementů. 41

47 4.4 Přizpůsobení metodiky 4. PROJEKT WEBOVÉ APLIKACE S POUŽITÍM SCRUMU Ukázkový projekt byl specifický v několika ohledech. Především, vývojový tým byl složen ze studentů, kteří neměli vlastní kancelář a práci neprováděli na plný úvazek; pracovali ve volných chvílích ze svých domovů. Štěstím v tomto případě bylo, že bydleli velmi blízko sebe a mohli se scházet na denní srazy. Velikost týmu a velikost projektu navíc byla poměrně malá, klientovy požadavky byly často měněny. Také stakeholderů zainteresovaných na projektu, ale nepůsobících v týmu (v názvosloví Scrumu kuřat), bylo minimum - jednalo se pouze o prodavače v obchodě s oblečením. Díky těmto omezením jsem proces Scrumu po dohodě s týmem poupravil následovně Délka Sprintu Webové aplikace jsou známé svým velmi rychlým vývojem. Doba je překotná, trh se mění rychle a doba reakce je pro úspěšný vývoj klíčová. Scrum je přece jen z dnešního hlediska starý již více než 15 let, pokud bereme v potaz jen jeho oficiální představení. Není proto velkým překvapením, že původní Sprint o délce 30 kalendářních dní v některých případech začal být příliš dlouhý pro adekvátní reakci na měnící se podmínky, mnohé týmy tak původní čtyřtýdenní Sprinty zkracují, kupříkladu na dva týdny [9]. Objevují se i 3denní Sprinty 5. Pokud týmu jakýkoliv Sprint není dost krátký, může být řešením metodika Kanban, která se nejvíce hodí právě pro ad-hoc vývoj. V našem případě jsem se dobu trvání Sprintu rozhodl zkrátit na jeden kalendářní týden, tedy 5 pracovních dní. Cílem tohoto zkrácení bylo umožnit pružnější reagování na rychle se měnící klientské požadavky. 30denní Sprint by totiž při malém rozsahu projektu znamenal téměř dokončený produkt; u kratšího Sprintu jsem měl naopak obavy, že by mohl negativně ohrozit soustředění týmu v průběhu Sprintu a způsobit chaotický vývoj řízený momentální náladou zadavatele. Práce na projektu probíhala během pracovního týdne. Netradičně v neděli se sešli všichni členové týmu včetně Vlastníka produktu a společně provedli revizi předchozího Sprintu, načež naplánovali Sprint další. Časy byly proporcionálně zmenšeny oproti doporučeným dobám trvání. Původní čas Sprintu doporučený Kenem Schwaberem v [26] je čtyři týdny, naše Sprinty byly naplánovány jako jednotýdenní, proto byly doby trvání zmenšeny na jednu čtvrtinu s tím, že pokud by čas nestačil, upravily by se příslušné doby trvání v následujících Sprintech. Čas nebyl zkrácen akorát u Denního srazu,

48 4. PROJEKT WEBOVÉ APLIKACE S POUŽITÍM SCRUMU jelikož se jedná o tak rychlé setkání, že jej nemělo příliš smysl zkracovat, a to zejména pro tým, který se Scrumem teprve začíná. Původní Scrum Modifikace Doba trvání Sprintu 30 dní 7 dní Počet členů týmu Plánování Sprintu - co 4 hodiny 1 hodina Plánování Sprintu - jak 4 hodiny 1 hodina Recenze Sprintu 4 hodiny 1 hodina Retrospektiva 3 hodiny 1 hodina Denní sraz 15 minut 15 minut Specifikem ukázkového projektu bylo, že tým tvořili studenti. Nejen že tak kvůli jiné časové vytíženosti zřídka trval pracovní den osm hodin (obyčejně zhruba 6), navíc se také časové možnosti jednotlivých členů týmu ve Sprintech občas lišily. Ne vždy také všichni členové týmu dokázali sesynchronizovat pracovní dobu, Denní sraz však probíhal pravidelně pro někoho na začátku pracovní doby, pro jiného na konci, podobně jako při distribuovaném Scrumu [35]. Tento fakt trochu ztěžoval plánování, jelikož nebylo možné přesně vycházet z údajů nasbíraných při předchozích Sprintech, technika včerejšího počasí známá z Extrémního programování [31], tudíž nefungovala stoprocentně. Díky malé velikosti týmu však nakonec vysoký rozptyl pracovních hodin nebyl výrazný problém, a to hlavně díky délce Sprintů, jelikož časovou vytíženost byli členové týmu schopni na pět dní dopředu odhadnout velmi přesně Denní srazy Pro Vlastníka produktu byla doba cesty na Denní sraz několikanásobně vyšší než doba samotného setkání, proto s ním po vzoru Scrumu pro distribuované týmy byly zavedeny videokonference přes program Skype. Tým tak byl pohromadě a těžil z komunikace tváří v tvář, zatímco Vlastník se setkání účastnil přes internet. Pro nahrazení chybějící přímé komunikace byl v každém Sprintu vyhrazen alespoň jeden den, kdy se Vlastník produktu na Denní sraz dostavil. Tento den byl dohodnut ad-hoc Vývojářské techniky Díky již zmiňované provázanosti Scrumu a Extrémního programování se tým shodl na následujících technikách. 43

49 4. PROJEKT WEBOVÉ APLIKACE S POUŽITÍM SCRUMU Požadavky budou psány ve formě Uživatelských příběhů. Ohodnocení příběhů se inspiruje Fibonacciho posloupností: 0, 1, 2, 3, 5, 8, 13, 20. Plánování bude prováděno pomocí tzv. Plánovacího Pokeru. Při práci na složitých částech systému budou vývojáři pracovat ve dvojicích. Jelikož je vývojářů lichý počet, bude utvořena jedna dvojice, zatímco třetí vývojář bude pracovat samostatně Kdy je úkol dokončen? Důležitým faktorem při vývoji pomocí metodiky Scrum je přesná definice dokončeného úkolu. Ken Schwaber v [24] popisuje případy, kdy se tým nechal unést častými dodávkami funkčního softwaru a spokojeností zákazníka, kterému na revizích Sprintu dokázal představovat spoustu nových funkcí. Při bližším přezkoumání byla však úspěšně prezentovaná funkcionalita pod povrchem nedokončená, neotestovaná a obsahovala mnoho chyb. Pokud by se zákazník rozhodl zmíněné funkce implementovat, což Scrum umožňuje, tým by měl najednou plné ruce práce. Řešením bylo naplánovat kratší Sprint určený k odstranění chyb a ladění kódu. Abychom předešli takovýmto nečekaným obtížím a zároveň nezaváděli rigorózní inspekce a nadbytečnou dokumentaci, každý dokončený úkol musel být okomentován a po základním odladění nasazen do vývojové větve aplikace, kde byl následně přezkoumán a otestován jiným vývojářem je totiž známým faktem, že člověk má sklony se k vlastnímu kódu chovat spíše defenzivně. Výjimkou byl kód programovaný ve dvojici, jelikož párové programování by mělo zajistit menší množství chyb; takový kód byl tedy, až na výjimky, testován přímo autory. Po otestování autor kódu opravil případné chyby a teprve poté byl úkol označen jako hotový. Žádosti o otestování probíhaly běžné komunikační prostředky (instant messaging, telefon) nebo byly vznášeny na Denním srazu při shrnutí předchozí práce. Díky malému týmu nebylo potřeba vést seznam defektů, jelikož autor kódu si jeho odladění hlídal sám a řešil jej souběžně s psaním kódu. Opravy rozsáhlejších defektů, které z nějakého důvodu nemohly být provedeny okamžitě, byly zařazeny do Sprint backlogu. Důsledkem uvedených opatření byl tým schopen každý Sprint přinášet hotovou funkcionalitu, která mohla být v případě žádosti zákazníka implementována bez nadbytečného úsilí. Dalším benefitem byla transparentnost 44

50 4. PROJEKT WEBOVÉ APLIKACE S POUŽITÍM SCRUMU postupu na projektu, což je pro empirický řídící proces, kterým Scrum je, zcela nezbytné. 4.5 Ganttův diagram Pro porovnání s agilním vývojem jsem na základě doposud zjištěných dat v programu MS Project vytvořil Ganttův diagram s plánem projektu. Plán pro tři pracovníky začíná 1. února a končí 12. března. Projekt začíná specifikací požadavků a ve svém průběhu prochází čtyřmi iteracemi. Iterativní přístup je zde nezbytný, jelikož jsou očekávány změny v požadavcích zákazníka a tým e-shop, natož e-shop specializovaný na oblečení, doposud nikdy nevyvíjel. I proto nejsou zřejmě odhady příliš přesné, jako vodítko však posloužit mohou. Pomocí Ganttova diagramu byla kromě doby trvání odhadnuta i pracnost (604,5 hodiny) a náklady, které při sazbě 150 Kč/hod činí Kč. Obrázek 4.1: Ganttův diagram 45

51 Kapitola 5 Výběr nástroje Scrum je velmi lehká metodika, která nevyžaduje žádné speciální nástroje; v nejjednodušším případě stačí tužka a papír. Jak totiž stojí v agilním manifestu, lidé a komunikace jsou cennější než procesy a nástroje. Tužka a papír ale postrádá jednu důležitou schopnost - snadnou přístupnost, pokud členové týmu nepracují na stejném pracovišti. V takovém případě přestává být nasazení pokročilejších nástrojů pouhým vylepšením a stává se prakticky nutností. Tato kapitola přináší přehled nástrojů podporujících Scrum. Uvedený přehled není v žádném případě vyčerpávající, jelikož počet nástrojů je dosti vysoký a nové často přibývají. Pro co největší aktuálnost práce zde zmíním i nástroje, které jsem nalezl až po proběhnutí ukázkového projektu. Programy popisuji v jejich nejnovějších verzích. 5.1 Tabulkový procesor Příkladem tabulkového procesoru je Microsoft Excel nebo LibreOffice Calc. Pomocí něj je možné tvořit grafy, zaznamenávat položky v backlogu, počítat užitečné statistiky a tisknout karty s uživatelskými příběhy. Tabulkový procesor je aplikace, kterou umí na dostatečné úrovni používat naprostá většina technicky zdatnějších uživatelů. Problémem by mohla být jistá bezradnost v začátcích u nových týmů, které Scrum teprve zavádí, což je případ praktického projektu této práce. Jak nastavit buňky tak, aby byl Product backlog přehledný? Jakým způsobem dokument sdílet? Jak vyřešit současnou práci více uživatelů na dokumentu? Jak projektovou dokumentaci přizpůsobit různým rolím (Scrum Master, Vlastník produktu a další)? Scrum je naštěstí tak rozšířená metodika, že existují volně dostupné šablony, které mohou pomoci tyto začátky překonat 1. Randaar Puust, softwarový architekt z Toronta, na zmíněné stránce rovněž zvažuje plusy a mínusy 1. např. 46

52 5. VÝBĚR NÁSTROJE řešení pomocí tabulkového procesoru. Mezi klady patří snadná přizpůsobitelnost (mazání sloupců či řádků je triviální), umístění v jednom dokumentu, což je vhodné pro jednoduché odeslání přes , a možnost se snadno vracet k dřívějším verzím v případě, že se zachovává historie souborů. Řešení přes tabulkový procesor však přináší i nevýhody, zejména se jedná o již probíranou nižší intuitivnost (zde můžou pomoci právě šablony), nemožnost současné práce na dokumentu a nakonec i komplexnost, jelikož provázání jednotlivých artefaktů v tabulkovém procesoru není triviální. Z výše zmíněných důvodů jsem se nakonec rozhodl opustit variantu tabulkového procesoru a nalézt vhodný softwarový nástroj, který může počáteční kroky ve Scrumu učinit podstatně snažší, jelikož dokáže účinně vést uživatele k zadání správných dat a pomoci tak pracovat s artefakty Scrumu správně. 5.2 Požadavky Pro vybrání vhodného nástroje bylo nejdříve potřeba si určit požadavky na jeho vlastnosti. Po shrnutí požadavků budou představeny nástroje, na které jsem narazil. Jejich výběr není vyčerpávající a při jejich volbě jsem se řídil spíše citem, snažil jsem se však vyzkoušet široké množství nástrojů, abych mohl porovnat rozdíly mezi nimi. Webová platforma. Pro co nejsnazší spolupráci a dostupnost jsem se rozhodl hledat aplikaci běžící bud kompletně na webové platformě nebo alespoň pracující se vzdálenou centrální databází. V úvahu přicházely i opensource aplikace s možností instalace na vlastním serveru, podmínkou však byla jednoduchost instalace a správy. Členové týmu a Vlastník produktu pracovali převážně na strojích s operačním systémem Windows. Export a import. Jelikož například pro Plánovací Poker může tým upřednostnit vytištění karet s uživatelskými příběhy před jejich ručním přepisováním, aplikace by měla podporovat možnost exportovat a případně i importovat data. Výstupní formát by měl být snadno editovatelný, ideálně by se tedy mělo jednat o dokument tabulkového procesoru. Export dat je také možno využít pro prezentaci lidem nepodílejících se přímo na projektu. Dostatečná granularita. Aplikace by měla podporovat dekompozici uživatelských příběhů na úkoly a ideálně i další atributy jednotlivých položek 47

53 5. VÝBĚR NÁSTROJE backlogu (výzkum, defekt a jiné). Toto se dá obejít různými formami tagování, preferovaná je však nativní podpora v aplikaci. Strmá křivka učení. Program by měl být uživatelsky přívětivý a jednoduchý na pochopení. Celý tým pracuje se Scrumem poprvé a Vlastník produktu je zvyklý pracovat pouze s běžnými počítačovými aplikacemi. Aplikace by měla být intuitivní a měla by pro tým znamenat minimální režijní náklady. Počet funkcí. Tento požadavek souvisí s požadavkem předchozím. Jelikož počet členů týmu je nevelký a projekt e-shopu je poměrně malá aplikace, komplexnost řídícího procesu není tak velká, aby byly vyžadovány velmi pokročilé funkce. Případné pokročilé funkce by tak měly být v systému bud nepřítomný nebo být pouze volitelné, aby byl tým schopen flexibilně využívat jen takové množství nástrojů, které je nezbytně nutné. 5.3 PangoScrum PangoScrum je webová aplikace, která je v současnosti ve fázi beta a je zdarma. V budoucnu je pravděpodobné zavedení poplatků. Program je postaven na webové platformě, na první pohled vypadá jednoduše a přívětivě, ovládání a navigace je však místy překvapivě málo intuitivní. Poněkud netradiční je zadávání doby trvání Sprintu, kdy uživatel nejprve určí datum Plánování Sprintu, následně datum Retrospektivy Sprintu a program za něj doplní do dnů mezi těmito dvěma setkáními Denní srazy. Při přeplánování Sprintu však už aplikace Denní srazy nepřepočítá. Otázka potřeby mít Denní srazy zaznamenány explicitně v kalendáři je také sporná, ačkoli jinak přítomnost kalendáře hodnotím jednoznačně kladně. Největším nedostatkem aplikace je chybějící dekompozice položek backlogu na úkoly. Položky ohodnocené příběhovými body, které jsou mimochodem ne příliš intuitivně znázorněny ikonou tužkové baterie, tak lze jedině posunout nebo ukončit. Členové týmu nemohou zadávat počet odpracovaných hodin, což dosti snižuje transparentnost vývojového procesu, která je počítána mezi nejsilnější stránky Scrumu. Členové týmu tím pádem navíc nejsou konfrontování se svými odhady a nemohou (tedy alespoň ne skrze tuto aplikaci) se učit odhadovat přesněji. Pokud bych měl tento nástroj shrnout několika slovy, řekl bych, že je jednoduchý až příliš. 48

54 5. VÝBĚR NÁSTROJE 5.4 Scrum d Scrum d zaujme příznivou cenovou politikou (přes omezení na jediný projekt nabízí neomezeně uživatelů a 1GB prostor na přílohy zdarma) a přívětivým uživatelským prostředím. Narozdíl od PangoScrum, kde se záhlaví mění v závislosti na umístění uživatele v aplikaci, zde jsou záložky neměnné, což umožňuje se neztrácet v kontextu aplikace a mít stále důležité funkce po ruce. Scrum d umožňuje dělit příběhy na úkoly a přidělovat časový odhad v hodinách. Aplikace bohužel obsahuje několik chyb. Za menší nedostatek by se dalo považovat zmizení úkolu po změně jeho stavu a následná nutnost obnovení stránky, větší nepříjemností už je nemožnost vrácení položky ze Sprint backlogu do Product backlogu v případě překliknutí. Absence podpory českých znaků při exportování dat pak byla dostatečným důvodem, proč Scrum d nezvolit. 5.5 Agilo for Scrum Produkt společnosti Agile42 je velmi vyspělou aplikací s mnoha funkcemi. Ačkoli není vyloženě uživatelsky nepřívětivý, je zpočátku poněkud obtížné se v něm vyznat, strmá křivka učení se tedy předpokládat nedá. Agilo vyžaduje ke svému běhu lokální server, který je součástí instalace pro Windows, případně je možno nainstalovat aplikaci na vlastní sdílený server a umožnit tak vzdálenou spolupráci; tato varianta vyžaduje ke svému běhu Python. Kvůli náročnějším začátkům a absenci hostované verze jsem se rozhodl Agilo nevyužít, pokročilejším týmům by však mohla tato aplikace vyhovovat. 5.6 ScrumDo ScrumDo je poměrně nová webová aplikace, která razí podobnou cestu jako PangoScrum, akorát to dělá mnohem lépe. Jedná se o open-source aplikaci opět na bázi Pythonu, s instalací v prostředí Windows jsou bohužel podle diskusních fór potíže. Autoři však zdarma nabízejí možnost hostovaného přístupu, nutnost instalace pak odpadá. Odezva aplikace je velmi svižná, hostovaný přístup si však vybírá svou daň v podobě frekvence vykreslování grafů; ty se aktualizují pomocí skriptu přes cron pouze jednou denně. Tým tudíž musí čekat na odezvu dlouho. Zajímavostí je použití grafu Burnup místo Burndown, ačkoli podle diskuse 49

55 5. VÝBĚR NÁSTROJE na fóru, kam autoři svědomitě přispívají, by mohl být do budoucna přidán i graf Burndown. ScrumDo má velmi dobrou podporu importování a exportování, dá se navíc provázat s oblíbenou aplikaci Basecamp. Příběhy je možné pomocí Drag&Drop posouvat na tabuli připomínající Kanban. ScrumDo dále podporuje dělení příběhů na úkoly, k těm však neumí přiřadit časový odhad v hodinách. Tento nedostatek a málo častá aktualizace grafů jsou jsou důvodem, proč bych zatím s volbou ScrumDo váhal, do budoucna mu však předpovídám světlou budoucnost, zejména díky jeho rychlé odezvě, otevřenému zdrojovému kódu, vyváženým funkcím a velmi intuitivnímu uživatelskému prostředí. 5.7 Rally Dev Community Rally Community Edition je omezená na deset uživatelů a jeden projekt, nabízí však opravdu bohatou funkcionalitu. Uživatelské prostředí je účelné, strohé a technicistní, mohlo by být uživatelsky přívětivější. Možnosti importu a exportu dat jsou dobré. Pro větší týmy s pokročilým vývojovým procesem by mohla být aplikace Rally jedním z favoritů při výběru nástroje pro Scrum. Začátečníky ale může množství funkcí a nabídek zpočátku mást. Z tohoto důvodu nakonec na Rally volba nepadla, přestože tuto aplikaci jinak řadím mezi nejpovedenější. 5.8 ScrumDesk ScrumDesk je dílem slovenského vývojáře a současně se nachází v páté verzi. Jedná se o desktopovou aplikaci vyžadující.net verze alespoň 3.5. Úschovu dat je možno řešit lokálně (k instalaci je potřeba SQL Server 2008) či vzdáleně, kdy je databáze hostována na serverech aplikace ScrumDesk - její vytvoření chvíli trvá, obecně je ale do jednoho dne připravená. Program je zdarma pro pět uživatelů, další licence je již nutné dokoupit. Program je přehledný a ač to na první pohled nevypadá, množstvím funkcí velmi bohatý. Výhodou je, že tyto pokročilé funkce se uživateli nevnucují a pokud členům týmu stačí jen základní nástroje, nebudou se v programu ScrumDesk cítit ztraceně, jako tomu hrozí u některých nástrojů uvedených výše. ScrumDesk umožňuje exportovat uživatelské příběhy do podoby kartiček, které se následně dají použít při plánování. I další možnosti exportu jsou poměrně bohaté, nevýhodou je absence exportu Product backlogu v jed- 50

56 5. VÝBĚR NÁSTROJE nodušší podobě; kartičky nemusí být vždy vhodné. Ovládání je intuitivní, mnoho úkolů jde udělat více způsoby, je podporován Drag&Drop a podobně jako ScrumDo umožňuje aplikace přesouvat položky po tabuli připomínající Kanban, což zvyšuje přehlednost. ScrumDesk podporuje spolupráci na dálku pomocí virtuálního Plánovacího pokeru, ohlašování překážek či hlasování o nápadech na Retrospektivách Sprintu. Umožňuje také připojovat komentáře a přílohy. Jelikož náš tým se dokázal setkávat osobně, nebyly tyto funkce potřebné, distribuovaným týmům by se ale hodit mohly. Oproti aplikaci Rally chybí programu ScrumDesk možnost vytvářet hierarchickou strukturu uživatelských příběhů, což poněkud zhoršuje dekompozici uživatelských příběhů. Pro někoho může být nevýhodou nutnost instalovat.net. Po zvážení všech pro a proti jsem tuto aplikace nakonec zvolil pro práci na ukázkovém projektu. Vedly mne k tomu následující důvody: poměrně bohaté možnosti exportu, dobře navržené GUI, jednoduchá instalace, oproti Rally nebo Agilo strmá křivka učení, bohatá funkcionalita, která neruší a umožňuje růst, jak se člověk s programem sžívá a vývojový proces se stává vyspělejším. 5.9 MiniScrum Tato webová aplikace zcela dostává svému názvu, jelikož nabízí skutečné minimum funkcí. Toto minimum je však pečlivě zvoleno, a tak aplikace umožňuje zadávat časové odhady, exportovat data, dělit vývoj na releasy a přiřazovat položkám příběhové body. Aplikace nevyžaduje po uživateli žádný úkol navíc poskytuje například možnost přihlášení přes Google účet, datum doplňuje sama a uživatelské prostředí nevyžaduje žádné kognitivní úsilí, nebot je zcela intuitivní a prosté. Aplikace je navíc nabízena zcela zdarma. Pro menší týmy vyvíjející nepříliš rozsáhlé aplikace může být MiniScrum skvělou volbou; objevit ji dříve než během rešerše nástrojů při psaní této práce, byla by horkým kandidátem na použití pro vývoj. 51

57 5. VÝBĚR NÁSTROJE 5.10 Další nástroje Nástroje pro Scrum Zabýval jsem se i několika dalšími nástroji, většině z nich jsem však již nevěnoval hlubší pozornost, obecně z důvodu nesplnění některé (či některých) z podmínek vytyčených na začátku; at už se jednalo o nevyhovující cenovou politiku, nesnadnou instalací či nevyhovění požadavkům na funkcionalitu. Jistě jsem také některé nástroje přehlédl. Pro případné další rozpracování však alespoň uvádím stručný přehled některých aplikací, na které jsem při hledání vhodného nástroje narazil: Banana Scrum (absence verze zdarma), Scrum-It, Daily Scrum, FireScrum (složitější instalace), ScrumWorks, Scrumy (tak jednoduché, že se dle mého názoru jedná spíše o pomůcku pro Kanban než pro Scrum) Nástroje pro měření času Pro dosažení zpětné vazby ohledně svých odhadů bylo třeba měřit čas strávený prací co nejpřesněji. Užitečným pomocníkem se ukázala být aplikace Toggl. Jeden z členů týmu, Pavel Chmelař, dokonce lokalizoval aplikaci do češtiny. 52

58 Kapitola 6 Realizace Mike Cohn v [9] při zavádění Scrumu do firmy doporučuje podstoupit pilotní projekt, během nějž pracovníci zjistí, jak se Scrumem nakládat a které praktiky jim nejvíce vyhovují. Cohn také uvádí, že je dokázáno, že Scrum funguje, přesto jeho nasazení nelze provést univerzálně a je záležitostí týmu si proces přizpůsobit svým potřebám. Náš pilotní projekt byl tedy e-shop s oblečením. V této kapitole se zaměřím na popis jednotlivých iterací projektu elektronického obchodu, tvorbu artefaktů, problémy, na které jsme při implementaci Scrumu narazili a specifika této metodiky. Cílem není podrobně popsat výsledný produkt, ale jeho zajímavé části a způsob jeho výroby řízený metodikou Scrum. Výsledek by mohl posloužit i jako inspirace týmům, které se Scrumem začínají. 6.1 Přípravy Výsledky příprav jako modifikace metodiky či velikost týmu byly popsány v samostatné kapitole, tato podkapitola tedy slouží spíše jako shrnutí, jak se podařilo nastartovat projekt, co bylo potřeba provést a v jakém pořadí. Na počátku projektu byl spolu se zákazníkem po zhruba půlhodinovém rozhovoru sepsán rámcový seznam funkčních požadavků budoucího e-shopu. Nejednalo se o smlouvu či rigorózní dokument specifikace požadavků, ale stručný seznam několika bodů. Na základě rozhovoru byl utvořen tým, odhadnuty náklady a rizika, vybrán vhodný nástroj, dohodnut předběžný termín vydání a upravena metodika Scrum tak, aby více odpovídala povaze projektu. Před započetím prací byl zakoupen potřebný materiál a autorem této práce zaškolen tým i zákazník. Součástí školení nebylo jen představení principů fungování Scrumu, ale i práce se zvoleným nástrojem v tomto případě ScrumDesk. Tyto přípravy zabraly pouhý jeden den; na tomto příkladě je tedy dobře vidět, že za předpokladu, že alespoň jeden člen vývojo- 53

59 6. REALIZACE vého týmu zná Scrum, je možné nasadit tento populární framework velmi rychle a bez nadbytečných formálních náležitostí. Přesto, nebo spíše právě proto, bylo třeba Scrum důkladně prostudovat framework je tak jednoduchý, až může svádět k pouhému používání jeho užitečných artefaktů bez hlubší znalosti důležitých principů. Tento problém se týká zejména jedinců, kteří jsou již zvyklí na tradiční způsob vývoje softwaru. Jak ukazuje Ken Schwaber v [24], důsledkem může být i situace, kdy se projekt navenek tváří jako agilně vyvíjený, ale ve skutečnosti se jedná o rigorózní proces, který je pouze obohacený o Product backlog a kde denní setkání jsou spíše formalitou než užitečným střetnutím týmu. Po školení byl zákazník požádán o sestavení iniciálního Product backlogu, jenž bude základem na první Plánování Sprintu. Položky iniciálního backlogu měly být oproštěné od detailů (spíše než o uživatelské příběhy mělo jít o eposy) a seřazené podle priority. Pak už zbývalo jen dohodnout čas a místo prvního Plánování Sprintu. 6.2 Sprint 1 - Položení základů První Plánování Sprintu probíhalo v místnosti s magnetickou tabulí, kartičkami z Product backlogu, počítačem a tiskárnou (pro případný dotisk karet backlogu). Ačkoli podle plánu měly být na setkání vyhrazeny dvě hodiny, čas jsme po dohodě prodloužili, jelikož se jednalo o náš první Plánování Sprintu a bylo třeba jednak najít styl, kterým budeme k setkáním přistupovat, a jednak se jednalo o nový projekt, se kterým jsme se museli teprve důkladněji seznámit. Z původně plánovaných dvou hodin se setkání prodloužilo téměř na hodin pět tři na hledání odpovědi na otázku co, dvě na jak Cíl Sprintu Prvním úkolem bylo určit Cíl Sprintu (Sprint Goal). Cíl Sprintu slouží ke shrnutí požadovaných výstupů Sprintu. Pomáhá všem prasatům (Scrum Masterovi, Vlastníkovi produktu a Týmu) sjednotit představy o výsledku Sprintu, umožňuje snadnou komunikaci se stakeholdery a vymezuje okruh funkcionality, na které se v rámci dané iterace bude pracovat. [19] Prioritou byla v počátcích vývoje administrační část. Cílem našeho prvního Sprintu bylo Položit základy analyzovat a vytvořit jádro aplikace. Očekávaným výstupem byla zejména volba technologického řešení, návrh databáze a nastavení vývojového prostředí. 54

60 6. REALIZACE Product backlog Iniciální backlog, přinesený zákazníkem Jiřím na setkání, byl nejprve ve stručnosti představen bod po bodu. Následně do něj byly doplněny položky nezbytné pro funkčnost aplikace jedná se zejména o technologické a návrhové úkoly jako vytvoření návrhu informační architektury a ER diagramu, který bude sloužit jako reference pro psaní databázových dotazů. Těmto položkám byla přiřazena nejvyšší priorita, jelikož byly základním stavebním kamenem aplikace. Ačkoli bývá určování priority výsadou Vlastníka produktu, byla tedy v tomto případě učiněna výjimka Poker Další fází setkání byl Plánovací poker. Product backlog byl pro přehlednost vytištěn. Jelikož mi přišlo zbytečné tisknout či shánět speciální balíček karet, navrhl jsem týmu použití klasické karetní sady, kde čísla vyšší než deset nahradíme obrázkovými kartami (spodek, svršek, král, eso). Jelikož se jednalo o první Plánovací poker, začali jsme nejmenší položkou backlogu, z jejíhož odhadu jsme následně mohli vycházet u dalších položek; jedná se o jeden z doporučovaných postupů, kterých existuje samozřejmě více. [19] Po ohodnocení první položky šlo již odhadování poměrně snadno. Kartičky s uživatelskými příběhy jsme přidávali na tabuli do sloupců pro lepší srovnání náročnosti jednotlivých položek. Odhady byly následně přeneseny do aplikace ScrumDesk. Jelikož bylo na tabuli málo místa, příští iterace jsme místo sloupců použili řádky, jak doporučuje Mike Cohn v [6]. Po pomalém začátku, kdy tým váhal a seznamoval se se svou rolí, nabralo odhadování Product backlogu spád, jelikož tým mohl porovnávat s předchozími položkami a zvykl si na hodnocení pomocí příběhových bodů. Položek v backlogu nebylo velké množství, tým tudíž odhadl všechny, aby vedle již hotové prioritizace dostál také požadavku Estimated z principu DEEP Sprint backlog Po dokončení iniciálního Product backlogu tým po diskusi se zákazníkem odsouhlasil, které položky implementuje v prvním Sprintu. Vyřešena tak byla otázka, co bude tým implementovat, jinými slovy byl naplněn Sprint backlog. Kvůli časové tísni musel být následně tým rozpuštěn, odpověd na otázku jak tedy byla posunuta na další den, kdy měl Sprint začít. V dohodnutý čas se tým sešel, dekomponoval uživatelské příběhy na úkoly a přiřadil jim časový odhad. 55

61 6. REALIZACE Postup prací Na základě doposud zjištěných požadavků na administraci i e-shop jsem zpracoval databázový návrh a převedl jej z papírové formy do nástroje MySQL Workbench, který umožnil návrh vytisknout pro snadnou orientaci členů týmu v databázi projektu. Již v návrhu jsem myslel na případné budoucí použití více jazyků; přestože z důvodu rychlosti jsem zvažoval lokalizaci implementovat pomocí více řádků v tabulce (kupříkladu místo řádku description by tabulka produktu obsahovala řádky cs_description a en_description), z důvodu budoucí rozšiřitelnosti a minimalizace plýtvání místem jsem zvolil z hlediska návrhu čistější variantu pomocí vazebních entit. Obrázek je díky svým rozměrům uveden v přílohách. Grafické vzezření administrace je minimalistické, nerušivé, přitom však vizuálně poměrně atraktivní. Přihlašování do systému probíhá způsobem výzva odpověd (challenge response). Obrázek 6.1: Odhlášení z administrace Zhodnocení prvního Sprintu Odhadování se v prvním Sprintu potýkalo s problémy. Zřejmě z respektu k faktu, že většina týmů si toho první Sprint na bedra naloží příliš [9], došlo k dokončení veškeré práce, když ještě v zbývaly volné hodiny. Díky probíhajícím Denním srazům se dalo odhadnout dopředu, že práce bude dokončena dříve, proto byl čas přijít s řešením nastalé situace. Navrhl jsem problém vyřešit tak, že se dekomponovala položka z backlogu s vysokou 56

62 6. REALIZACE prioritou (Grafický návrh) a její část se přiřadila do probíhajícího Sprintu. Zamezilo se tak plýtvání časem a navíc byla důsledkem větší spokojenost zákazníka, kterému byl výsledek prezentován na Revizi Sprintu. Nejen že tým neodhadl správně počet příběhových bodů na Sprint, což mělo za následek předčasné dokončení prací, ale ani samotné ohodnocení příběhovými body nebylo dvakrát přesné čtyřhodinové zjištění představy o prezentační části e-shopu bylo ohodnoceno třemi body, zatímco sedmihodinová příprava vývojového prostředí byla v backlogu oceněna dvěma body. Kvůli seznamování s prostředím programu ScrumDesk byl Sprint omylem odstartován dříve, než byly položky zaneseny do Sprint backlogu a časově odhadnuty, proto je počet hodin ve Sprint Burndown diagramu ze začátku na nule. Zpětná vazba poskytnutá diagramem je ale i tak cenná. Ukazuje strmější začátek, kdy bylo odpracováno nejvíce hodin, a pozvolnější konec, jelikož práce byla hotová dříve, než se očekávalo, a ke konci i přes doplnění nové položky do backlogu tým přece jen pracoval ve volnějším režimu. Obrázek 6.2: Sprint 1 - Burndown Při jednom z Denních setkání bylo zjištěno, že v reportech Sprintu se místy nesprávně objevily nulové časové hodnoty pro původní odhad úkolů. Jelikož program ale jinak prozatím přes občasné padání fungoval dobře, rozhodli jsme nezavádět jiný nástroj, obzvláště když ScrumDesk byl nejblíže požadavkům týmu, a zmíněnou chybu jsme zaevidovali, ale rozhodli se s ní smířit. Všechny zmíněné nedostatky, v řeči Scrumu překážky, byly probrány s týmem na Retrospektivě Sprintu. Důležité nakonec ale bylo, že se Sprint dokončil včas. Ačkoli se jednalo o víceméně technologicky zaměřenou iteraci, přihlášení do administrace poskytlo možnost k demonstraci hotové funkcionality. Sprint tak splnil jak vytyčený cíl, tak požadavek, aby každý 57

63 6. REALIZACE Sprint poskytl funkční přírůstek a posunul produkt o krok blíže směrem k vydání. 6.3 Sprint 2 Při první fázi plánování druhého Sprintu jsme se nevešli do přiděleného času, proto jsme do budoucna raději prodloužili čas na obě fáze plánování Sprintu na dvě a půl hodiny, tedy hodinu a čtvrt pro každou fázi. Délku Retrospektivy Sprintu a Recenze Sprintu jsme ponechali na původních hodnotách, jelikož u nich se časový interval po ukončení minulého Sprintu osvědčil. Cíl druhého Sprintu je poměrně samovysvětlující - Přidávat produkty a kategorie, což by mělo být nosným prvkem budoucího e-shopu. Na grafu 6.3 je dobře vidět, jak přibývala a ubývala práce v průběhu iterace tým totiž může objevit související činnost, kterou je třeba zařadit mezi práci na Sprintu, aby tým mohl dostát cíli, který si určil. Obrázek 6.3: Sprint 2 - Burndown Jednou z překážek týmu byla pomalá práce s databází, proto byla přidána databázová nadstavba umožňující snazší pokládání dotazů. Také byl kromě beta verze administrace přidán release beta verze e-shopu. Pro oba releasy byla pevně stanovena data vydání, nicméně bylo zatím příliš brzy, aby šlo z grafu Release burndown vyčíst informace o stíhání časového termínu, jelikož trend pokroku na projektu se ustaluje obvykle až po 2 3 Sprintech, jak uvádí [25] Zhodnocení Sprintu Vzhledem k několika podceněným odhadům tým potkal pravý opak situace z předchozího Sprintu práce bylo příliš a nakonec bylo jasné, že se 58

64 6. REALIZACE všechny úkoly Sprintu nestihnou. Atmosféra týmu, nadšeného z dobře proběhlého prvního Sprintu, byla chmurná a padly návrhy, zda neprodloužit Sprint alespoň o den a dokončit zbývající práci. Jako Scrum Master jsem týmu doporučil, abychom k takovému kroku nepřistupovali. Jak upozorňuje Mike Cohn v [9], smyslem pevného časového rámce Sprintu je jednak podpořit dojem, že se projekt neustále posouvá dopředu, a jednak pomoci členům týmu dodržovat disciplínu v dodržování termínů. Zcela výjimečně jsme nakonec položku přesunuli do následujícího Sprintu. Dohodli jsme se, že příští plánování každý člen týmu přidá ke svému odhadu zhruba čtvrtinu času navíc, aby příště nezhatil jeden problém výsledek celé iterace. 6.4 Sprint 3 Ve třetí iteraci Plánování Sprintu probíhalo standardně, tým už se v odhadech více ustálil. Na základě předchozích zkušeností byl zvolen objem o něco menší než předchozí 42bodový Sprint, tedy nakonec 36. V průběhu Sprintu byly zjištěny některé chyby, které nemohly být opraveny hned, byly proto zaneseny do Sprint backlogu a řešeny později v průběhu iterace. Jak cíl Sprintu Co máme na skladě? napovídá, hlavní náplní třetí iterace byl návrh a implementace skladového systému. Do databáze byly zaneseny běžné velikosti seskupené podle typu výrobku (XXS XXL pro trička, čísla pro boty a podobně) Skladový systém Pro zlepšení uživatelského zážitku bylo načítání velikostních tabulek prováděno přes AJAX. Každý produkt může mít přidělenou jednu sadu velikostí a více barevných variant. Každé velikosti v dané barvě může být přiřazena cena ve slevě, na což obvykle narážíme u výprodeje. Pole na vyplnění ceny se objevuje dynamicky jen u produktů, které mají zaškrtnut checkbox Akce, což napomáhá snížit vizuální šum a zvýšit přehlednost. Přidávání produktu je možné si vyzkoušet v demoverzi e-shopu určeného pro tuto diplomovou práci na adrese (přihlašovací jméno admin, heslo admin). Použití AJAXu je v tomto případě nejen téměř nezbytné, jelikož není předem známo, kolik variant administrátor přidá, ale zároveň dodržuje princip Setrvání na stránce uvedený v [27]. Setrvání na stránce pomáhá udržet flow, tedy stav, kdy je člověk tak soustředěný na svou práci, že ztrácí ponětí o okolí a ubíhajícím čase. 59

65 6. REALIZACE Vytrhnout uživatele z tohoto stavu je však poměrně snadné; jedním z prvků, které to dokážou, může být i obnovení stránky. Jedná se o fenomén Change blindness, kdy člověk díky způsobu fungování lidského mozku nedokáže za určitých podmínek rozpoznat i velké změny. 1 I čtvrtsekundové obnovení stránky totiž dokáže znemožnit vnímání změny. [27] Setrvání na stránce tedy nepřeruší koncentraci uživatele a umožní mu lépe vnímat chování systému a chápat kontext prováděné akce. Přidávání produktu bylo rozděleno na 3 kroky: vyplnění základních údajů, přidání skladových položek a přidání fotografií; přepínání mezi nimi probíhá pomocí záložek umístěných nahoře. Toto řešení zvyšuje přehlednost a umožňuje uživateli pohybovat se vpřed a zpět jednotlivými kroky bez vynakládání nadbytečného kognitivního úsilí. Záložky k navigaci doporučuje například Steve Krug v [13] či Pawan Vora v [30]. Obrázek 6.4: Použití záložek při přidávání produktu Programování skladového systému probíhalo zčásti ve dvojici, jelikož se jednalo o kritickou část aplikace a při odchodu autora hrozilo prodlení z důvodu ztráty znalosti Graf průběhu Sprintu Na burndown grafu ukazujícím zbývající hodiny práce lze vidět posunutí počátku pod ideální linii ubývání práce. Toto posunutí se na grafu objevilo kvůli hotové práci z předchozího Sprintu, která byla přesunuta do Sprintu 3. Pro lepší transparentnost procesu by bylo lepší přesunout do Sprintu příště pouze nedokončenou část práce. Nástroj ScrumDesk umožňuje i zobrazení grafu, který místo úbytku času zobrazuje úbytek příběhových bodů. Pokud opomeneme zřejmou chybu programu, který na začátku Sprintu místo počtu příběhových bodů ukazuje počet zbývajících hodin, objevíme zajímavý ukazatel, který může být cenný pro vyhodnocení Sprintu posunuté dno. Posunuté dno je zmíněno například v [29] a díky němu dokáže graf lépe zachytit měnící se množství 1. Příklady lze najít například na 60

66 6. REALIZACE Obrázek 6.5: Burndown chart zbývající hodiny práce na Sprintu. Další metodou, jak měnící se objem Sprintu zachytit, je pak použití již v kapitole 3 zmíněného burnup grafu, který také přikládám. Rovná linie mezi 16. a 17. únorem neznamená, že by tým nepracoval, pouze nedokončil žádnou položku ze Sprint backlogu. Obrázek 6.6: Burndown chart zbývající úsilí (příběhové body) Zhodnocení Sprintu Sprint 3 byl zřejmě nejklidnější z dosavadních iterací. Odpadla nervozita i přehnané nadšení z prvního Sprintu a vytratil se splín a stres ze Sprintu druhého. Přírůstek prezentovaný na Recenzi Sprintu sklidil úspěch a projekt se začal usazovat; Scrum se stal pro účastníky na projektu přirozeností. Zvolený objem Sprintu se osvědčil, všechny položky byly dokončeny včas. 61

67 6. REALIZACE Obrázek 6.7: Burnup chart 6.5 Sprint 4 Čtvrtý Sprint byl poznamenán nečekanou událostí Michal Šebera musel náhle z projektu odstoupit. Situaci jsme probrali na Plánování Sprintu a jelikož už byl projekt v pokročilé fázi, rozhodli jsme se tým nerozšiřovat. Podle položek v backlogu se dalo odhadnout, že projekt půjde dokončit včas, v případě množství nových požadavků bylo možné odložit na později nekriticky důležitou správu stránek e-shopu z administrace. Pro zbývající členy týmu tento objem znamenal sice větší, ale stále ještě zvladatelný zápřah. Jelikož objem minulého Sprintu byl 36 bodů, zmenšili jsme kapacitu čtvrtého Sprintu na 25 bodů. Při plánování se po rozpadu uživatelských příběhů na menší položky objem nakonec vyšplhal na 28. Vzhledem odchodu člena jsme se rozhodli Sprint o vyšším objemu risknout a pracovat větší množství času. Součástí čtvrtého Sprintu, který se kromě grafického návrhu e-shopu zaměřoval především na dokončení administrační části, bylo i několik vylepšení, kupříkladu možnost zvolit u produktu (ne)viditelnost. Novou funkcionalitu zákazník přidal do Product backlogu po odzkoušení nejnovější verze aplikace na předcházející Recenzi Sprintu. Nebýt Recenze, zákazník by s podobnými požadavky mohl přijít mnohem později; pak by hrozilo riziko složitější implementace. Takto byla díky vysoké prioritě položky úprava provedena ihned a u zákazníka byl posílen pocit, že může výslednou podobu produktu přímo ovlivňovat. Podobných případů se při vývoji vyskytlo hned několik a vždy na ně bylo možné rychle (nejčastěji hned v příštím Sprintu) zareagovat. Při Denním srazu v polovině Sprintu jsme zjistili, že díky skluzu nabranému nečekaně dlouhou optimalizací pro Internet Explorer 6 je ohroženo 62

68 6. REALIZACE včasné dokončení Sprintu. Kontaktoval jsem Milana Šeberu, který se naštěstí projevil jako týmový hráč a i přes své nesnáze odpracoval několik hodin na zprovoznění u a pomohl tak Sprint dokončit včas. Další obtíže nenastaly. Tým byl v méně lidech pochopitelně méně produktivní, efektivita však zůstala subjektivně stejná množství času vynaloženého na synchronizaci dvou- a tříčlenného týmu se téměř nelišilo. 6.6 Sprint 5 Pátý Sprint byl zaměřený zejména na to, co dělá obchod obchodem: nakupování. Cílem bylo umožnit procházení produktů a jejich přidávání do nákupního košíku. Dokončení tohoto kroku bylo potřebné pro správu objednávek, jež byla posledním velkým uživatelským příběhem z administrační části aplikace, který bylo třeba dokončit do beta verze administrace. Jinak tento Sprint probíhal zcela standardně, díky vyšší časové kapacitě jsme si navíc mohli dovolit zvýšit objem Sprintu. Graf Sprint burndown chart vykázal podivnou anomálii v podobě opožděného klesání křivky ideálního úbytku času. Pokoušel jsem se situaci nasimulovat a vyčíst z backlogů, co bylo příčinou, nicméně nic neobvyklého jsem nenašel. Správný průběh křivky jsem vyznačil světle žlutou přerušovanou čarou na obrázku 6.8. Další záběry z průběhu Sprintu, kde lze vidět plánování, prioritizovaný a odstupňovaný Product backlog či poměr rozdělení práce mezi členy týmu, jsou kvůli svému většímu objemu k nalezení v přílohách práce. Obrázek 6.8: Sprint 5 Burndown chart s opravou ideální křivky Jelikož jak z hlediska Scrumu, tak z hlediska implementačního již neproběhlo v této iteraci nic, co by vybočovalo z normy nastolené výše zmíněnými Sprinty, přejdu rovnou ke Sprintu dalšímu. 63

69 6. REALIZACE 6.7 Sprint 6 Cílem šestého Sprintu byl pohodlný nákup. Přestože předcházející dva Sprinty svou kapacitou nepřekračovaly 30 bodů, díky blížícímu se termínu dokončení a časovým možnostem zaplnily nakonec položky Sprint backlogu 33 bodů. V tomto Sprintu bylo dokončeno objednávání zboží a na něj navázaná správa objednávek. Přítomnost zákazníka při vývoji se ukázala jako velmi cenná, když upravil naše představy, že zboží ze stornované objednávky by se automaticky připsalo zpět na sklad. Díky zkušenostem, že někdy se z objednávky o více kusech stornuje jen část, by automatické přidávání produktů zpět na sklad mohlo způsobit nesrovnalosti. Specifikem ukázkového obchodu s oblečením je zobrazení dostupných barevných variant hned při procházení výrobků, nikoli až v detailu produktu. Při jeho implementaci jsem využil knihovnu jquery, která podstatně usnadňuje práci s JavaScriptem. Pro nerušený vizuální dojem se barevné varianty objevují až po najetí kurzoru nad objekt; přáním klienta bylo takto zobrazovat i cenu. Výsledkem poměrně svižné animace je tak rychlý přehled o barevných variantách bez nutnosti dalšího klikání. Podobný prvek jsem na běžných e-shopech s oblečením nenašel; přesto si nedovoluji tvrdit, že se jedná o unikát. Obrázek 6.9: Sprint 6 Zobrazení barevných variant 64

70 6. REALIZACE Část funkcionality byla dokončována v neděli, ScrumDesk ji však rozpoznal jako ukončenou až v pondělí, jelikož neděle byla nastavena jako den volna. Na Recenzi Sprintu byla zákazníkovi předána beta verze administrace i e-shopu k posouzení, zda v příští iteraci proběhne nasazení na produkční server nebo se bude tým nadále věnovat novým funkcím. 6.8 Sprint 7 Zákazník se rozhodl pro nasazení do produkčního prostředí za podmínky, že ještě bude dokončeno několik marginálních příběhů z administrace a pokročilé filtrování produktů. Tým tyto položky následně zařadil do Sprint backlogu, přidal opravu stránkování, položky důležité pro tým (vypnutí systému) a oproti předchozím iteracím poněkud odlehčenější Sprint začal. Při vývoji pokročilých filtrů se ukázalo, že prostor jimi zabíraný je poměrně veliký a začínající uživatele by mohl odradit svou přílišnou složitostí. Rozhodl jsem se proto pokročilé filtry rozbalovat pomocí Javascriptu, aby nerušily při volném procházení produktů. Tato technika odhalení ovládacích prvků po kliknutí (Toggle-Reveal Tools) je uvedena mezi vzory užívané při návrhu webových rozhraní. [27] Obrázek 6.10: Sprint 7 Pokročilé filtrování Vzhledem k budoucím úpravám obchodu, se kterými se počítalo, jsem navrhl a implementoval vypínání jak back-endu, tak front-endu. Úpravy, přestože by probíhaly v nočních hodinách, by totiž mohly (v případě frontendu) bud odradit zákazníky, nebo (v případě back-endu) způsobit ztrátu či zanesení nesprávných dat. Ovládání stavu systému je přítomno přímo v administraci, avšak je dostupné pouze uživatelům s oprávněním root, tedy vývojářům. 65

71 6. REALIZACE Po vypnutí se vývojářům kvůli odlad ování standardně zobrazí obsah stránek, ostatní vidí symbol údržby s vysvětlením důvodu odstávky, které zadal vývojář při vypnutí systému. Při testování se ukázalo, že lze snadno zapomenout systém znovu zapnout, proto jsem přidal do levého horního rohu upozornění na vypnutý systém (viz obr. 6.11). Obrázek 6.11: Sprint 7 Upozornění na vypnutý systém Nasazení na produkční server nevyžadovalo díky průběžnému dodávání systému výraznější úsilí. Byla otestována funkčnost nově přidaných prvků, možnost objednat zboží a naposledy změřena odezva systému, přestože testy na rychlost probíhaly po každém Sprintu. U zákazníka v obchodě proběhlo školení prodavače, týkající se zejména popisování produktů s ohledem na optimalizaci pro vyhledávače, jelikož prodavač si práci se systémem již předtím sám vyzkoušel a byl například původcem připomínky o chybném řazení produktů. Na Recenzi Sprintu byla zákazníkovi pro kontrolu demonstrována funkčnost jednotlivých uživatelských příběhů z backlogu, načež byl obchod spuštěn. 6.9 Přehled Program ScrumDesk produkuje spoustu užitečných výstupů. Z obrázku 6.12 vidíme, jak probíhala práce na vydání betaverze administrace: zpočátku probíhal vývoj rychle, postupně se zpomaloval, jelikož se pracovní úsilí jednak přesunulo na prezentační část aplikace, jednak už se spíše jednalo o dokončování menších funkcí a ladění detailů. Administrace zabrala větší část aplikace, jak lze vidět na obrázku Graf také ukazuje, že po dokončení obou betaverzí už vydání první verze aplikace nebylo příliš pracné. Zajímavé je také srovnání objemu Sprintů s užitečnými statistikami, například vypočítanými průměry. Graf Product burndown je v programu ScrumDesk zobrazen jako koláčový graf. Část grafu označená jako To be done jsou položky plánované do budoucích verzí systému. Relevantní obrázek A.3 je umístěn v přílohách. 66

72 6. REALIZACE Obrázek 6.12: Release burndowns Obrázek 6.13: Objemy vydání Obrázek 6.14: Přehled Objemy Sprintů 67

73 Kapitola 7 Zhodnocení Po sedmi Sprintech byl vytvořen plně funkční e-shop, jak můžeme vidět v tabulce 7.1. Po jeho nasazení neproběhl ihned další Sprint, ale obchod se ponechal chvíli beze změny, aby bylo možné za reálného provozu lépe systém poznat, vyhodnotit jeho slabiny a možnosti vylepšení a přiřadit prioritu položkám, které postupně v Product backlogu začaly přibývat. Termín byl splněn s týdenním předstihem, tým navíc dodal více funkcionality, než bylo původně předpokládáno oproti 165 příběhovým bodům na počátku projektu jich tým dokončil 213. Produkt velmi přesně odpovídal představám zákazníka. Postupem času do obchodu byly přidány další funkce - správa bannerů, správa stránek obchodu či WYSIWYG editor. Obchod je v současnosti v provozu u třech zákazníků http: // Do budoucna je v plánu mimo jiné zpříjemnění objednávkového systému a rozšíření skladového modulu na víceskladový systém, k němuž je již připraven databázový návrh. Současná verze e-shopu je k vyzkoušení na romanfianta.cz. Sedm Sprintů však mělo kromě dodání produktu zákazníkovi další, pro vývojový tým možná ještě podstatnější význam. Tým si osvojil pravidla Tabulka 7.1: Release plán Sprint Objem Pracovníků Hlavní náplň Release Položit základy Produkty, kategorie Skladový systém Zprovoznění front-endu Procházení produktů Nakupování a objednávky Beta Pokročilé filtry, nasazení V

74 7. ZHODNOCENÍ Tabulka 7.2: Multiplikátory v závislosti na počtu dokončených Sprintů Dokončených Sprintů Spodní hranice Horní hranice 1 0,6 1,6 2 0,8 1,25 3 0,85 1,15 4 a více 0,9 1,10 Scrumu a naučil se je využívat ve svůj prospěch. 7.1 Objem Sprintů Týdenní Sprint se svou dobou trvání osvědčil a tým si na něj zvykl, nebyl tedy důvod jej měnit. Důležitým prvkem při plánování příštích Sprintů je ale i určení objemu, který bude tým schopen zvládnout. Je zřejmé, že čím více Sprintů podstoupí, tím lépe může plánovat. Jedním ze způsobů, jak odhadovat objem příštích iterací, je použití multiplikátorů [8]. Na základě průměrného objemu dosavadních Sprintů a jejich množství můžeme vypočítat objem budoucích Sprintů pomocí hodnot uvedených v tabulce. Pomocí tabulky jsem vypočítal pravděpodobný objem budoucích Sprintů ukázkového projektu. Jelikož se počet lidí pracujících na projektu měnil, jsou uvažovány pouze Sprinty vyvíjené ve dvou, jelikož pro budoucí vývoj se po ukončení první verze projektu nepředpokládal nábor nových sil. Z hodnot v tabulce 7.1 vypočítáme průměr posledních čtyř Sprintů, který následně vynásobíme multiplikátory z tabulky 7.2. Jelikož 28,5 0,9 = 25,65 a 28,5 1,1 = 31,35, můžeme pro příští Sprinty po zaokrouhlení počítat s objemem mezi 26 a 31 body. Druhou možností předpovědi objemu budoucích Sprintů je použít interval spolehlivosti, jak doporučuje opět Mike Cohn, tentokrát v [9]. Prvním krokem je vyřazení Sprintů, které nereprezentují očekávaný budoucí vývoj, v našem případě se tedy jedná o vyřazení Sprintů, na kterých pracovali tři lidé. Dále je třeba seřadit Sprinty dle velikosti, v našem případě dostaneme posloupnost 23, 28, 30, 33. Pro sestrojení 90% intervalu spolehlivosti je třeba nejméně 5 Sprintů, náš odhad tudíž nebude příliš přesný; vzhledem k volnějšímu tempu v posledním Sprintu se však dá předpokládat, že pod hodnotu 23 by objem neklesl. Pomocí tabulky 7.3 zjistíme, které objemy budou hranicemi pro náš interval spolehlivosti. Jelikož číslo 4 je nejblíže číslu 5, hranice našeho intervalu 69

75 7. ZHODNOCENÍ Tabulka 7.3: Výpočet intervalu spolehlivosti Počet pozorování n-té pozorování budou čísla, která jsou první od začátku a od konce posloupnosti. Z 90 % si tedy můžeme být jistí, že objem příštího Sprintu se bude pohybovat mezi hodnotami 23 a 33. Vidíme, že jde o dosti hrubý odhad, který by zpřesnilo použití většího množství dat, tedy více podstoupených Sprintů. Odhad objemu nadcházejících Sprintů není možné považovat za definitivní, jelikož mnohdy je potřeba přizpůsobit se vnějším podmínkám, jako jsou dovolené, Vánoce či změny množství pracovníků. Přesto poskytuje důležité vodítko, ze kterého tým může vycházet. 7.2 Závěrečná analýza Po skončení má smysl projekt zhodnotit a výsledky uchovat, jelikož z nich lze poznat schopnosti procesu, na jejichž základě je možné budovat příští projekty [21]. Výsledky lze popsat slovně, některé se ale hodí i pro kvantitativní rozbor, který může být velmi cenný při porovnávání s příštími projekty. Dokument o závěrečné analýze může obsahovat obecné informace, rizikové řízení, velikost projektu, údaje o práci a defektech. Vhodnou, třebaže nikoli dokonalou metrikou je počet řádků zdrojového kódu Řádky zdrojového kódu Pro určení velikosti programu jsem použil program phploc, který počítá řádky zdrojového kódu (Lines of Code, zkráceně LOC), a další statistiky. Z nich jsem vybral kromě počtu řádků kódu i cyklomatickou složitost a počet řádků komentářů. Jelikož program phploc se zabývá jen PHP kódem, pro větší výpovědní hodnotu jsem následně použil program cloc, jehož výstupem jsou i počty řádků kódu v dalších jazycích. Výsledek jsem umístil 70

76 7. ZHODNOCENÍ Tabulka 7.4: Řádky zdrojového kódu PHP Řádky zdrojového kódu Cyklomatická složitost / LOC 0.17 Počet řádků komentářů LOC bez komentářů Převzatý kód Celkem LOC JavaScript LOC CSS Celkem řádků Tabulka 7.5: Příběhové body SP Hodin >20 do tabulky Odhad práce Po sečtení všech odhadů práce jsem obdržel výsledek o hodnotě 435 hodin, reálný odpracovaný počet hodin byl přitom 475. Rozdíl mezi odhadem a realitou lze odůvodnit příliš optimistickými odhady programátorů, zejména co se týče předvídání nečekaných problémů; pokud problémy nenastaly, odchylka většinou nebyla vysoká. I přesto je rozdíl mezi odhadem a realitou méně než 10 %, což je poměrně slušný výsledek. Odhadů se týká i hodnocení pomocí příběhových bodů (SP), kde tým zpočátku poněkud tápal. Postupem času se však hodnoty ustálily, přibližné hodnoty uvádím v tabulce. 71

77 7. ZHODNOCENÍ Porovnání s plánem v Ganttově diagramu Čas Pomocí Ganttova diagramu byl konec projektu odhadován na Projekt vyvíjený pomocí Scrumu skončil Ačkoli se může zdát, že tento údaj hovoří proti použití Scrumu, není tomu tak z několika důvodů. Počet pracovníků. Počet pracovníků byl u Scrumu nižší, jelikož v průběhu projektu odešel jeden člen týmu. Po zprůměrování (tři Sprinty ve třech lidech, čtyři Sprinty ve dvou) dostaneme hodnotu 2,42 člověka na projekt vyvíjený Scrumem, zatímco Ganttův diagram počítal po celou dobu projektu s nasazením 3 lidí. Funkcionalita. Funkcionalita dodaná pomocí Scrumu byla mnohem bohatší a užitečnější 1, jelikož zákazník v roli Vlastníka produktu určoval dynamicky směr vývoje každý týden. Mezi funkce, které se v projektu objevily navíc, patří například pokročilé filtrování či zdokonalený výpis produktů. Fiktivní projekt. Jelikož podle plánu zachyceného v Ganttově diagramu neproběhl reálný projekt, není jasné, zda by termín ukončení byl dodržen. Náklady Pomocí Ganttova diagramu byly náklady na projekt (při hodinové taxe 150 Kč/programátora) odhadnuty na Kč. Reálné náklady při použití Scrumu byly díky 475 odpracovaným hodinám nižší při stejné hodinové sazbě Kč. Tato nižší částka je pochopitelně způsobena i nižším počtem pracovníků na projektu. Rozdíly mezi reálným projektem vyvíjeným pomocíí Scrumu a plánem projektu v Ganttově diagramu jsem vizualizoval pomocí grafů. Pokud připočteme k přidané hodnotě v podobě nižších nákladů podstatně vyšší množství implementované funkcionality, vychází ze srovnání vývoj dle Scrumu efektivněji a levněji. 1. I Mike Cohn v [9] upozorňuje na fakt, že mnoho týmů zavedením Scrumu nezvýší sice svou produktivitu, ale zvýší užitečnost své práce díky zaměření na nejbližší iterace, nikoli na projekt v celé jeho komplexnosti. 72

78 7. ZHODNOCENÍ Obrázek 7.1: Srovnání Scrumu s tradičním plánováním Rizika Z rizik uvedených v kapitole 4 se naplnilo jedno riziko odchod člena týmu. Díky úzké spolupráci týmu na projektu, možnosti přizpůsobit funkcionalitu dostupným časovým zdrojům a dostatečnému termínu neznamenalo toto riziko vážnější problém Kvalita Defekty Jedním z měřítek chybovosti softwaru je poměr počtu chyb na funkční body (FP), které se dají odhadnout z počtu řádků zdrojového kódu (LOC). Jelikož jsem v převodní tabulce 2 nenašel jazyk PHP, rozhodl jsem se jej přirovnat k C++, jehož průměrný konverzní poměr je 59 LOC/FP. Pokud budeme mezi řádky zdrojového kódu počítat i JavaScript, hodnota 59 se po zprůměrování díky zaokrouhlení nezmění. Sečtením řádků zdrojového kódu PHP a JavaScriptu a následným vydělením číslem 59 dostaneme po zaokrouhlení počet funkčních bodů 231. Jelikož byla v projektu oprava chyb přítomna v definici ukončené položky a před uzavřením položky ji nejdříve otestoval jiný člen týmu, byla většina chyb zachycena již v zárodku. U některých chyb se to přesto nepodařilo, patří mezi ně: 1 kritická chyba (nemožnost odeslat objednávku),

79 7. ZHODNOCENÍ 3 velké chyby (stránkování, nefunkční filtry a chybné řazení), 8 malých či kosmetických chyb. Celkový poměr defektů k počtu funkčních bodů je tedy 0,05. Většina chyb uvedených v seznamu byla opravena ihned po objevení, kromě výjimek, kdy se řešení kvůli časové vytíženosti muselo odložit či kdy byla chyba objevena mimo průběh Sprintu pak se stala součástí plánu příští iterace. Kvalita kódu Kvůli vysoké rychlosti vývoje není kód příliš kvalitní. Za největší slabinu považuji absenci implementace architektury MVC, kvůli níž je výsledný produkt mnohem hůře přenositelný. Dalším nedostatkem je velmi slabá opora v objektovém návrhu, nebot projekt obsahuje velmi malý počet tříd. I přes používání funkcí je tak kód místy hodně špagetový. Na následujícím fragmentu zdrojového kódu z funkce tisknoucí seznam produktů vidíme absenci architektury MVC a použití příkazu echo přímo ve funkci. Výsledný kód je nepřehledný a těžko udržovatelný. echo <div class="box"> ; Další fragment kódu ukazuje nevhodné vytvoření instance databázové třídy a její předávání parametrem. Vhodnější by bylo použití vzoru Singleton, popřípadě Dependency Injection. // create the $db object $db = new Database(DB_SERVER, DB_USER, DB_PASS, DB_DATABASE,DB_CHARSET,DB_NAMESET); // connect to the server $db->connect(); require_once dirname( FILE ). "/includes/login.php"; /** * SYSTEM SHUTDOWN * use carefully :-) */ 74

80 7. ZHODNOCENÍ if (systemisoff($db, "frontend")) {... Taktéž dokumentace kódu existuje jen v podobě vnořených komentářů, které navíc v některých případech chybí nebo sdělují málo informací. Při případném odchodu kmenových pracovníků se tak v budoucnu dají předpokládat problémy s údržbou. Jak je vidět na fragmentu z funkce přidávající typ platby, kód byl například zčásti zkopírován i s původním komentářem. // adding season if($paymenttypeformaction == "add"){ $sql = "SELECT (IFNULL(MAX(order_number), 0) + 1) AS max_order FROM ". PAYMENT_TYPES; $result = $db->query_first($sql); $data[ order_number ] = $result[ max_order ]; $id = $db->query_insert(payment_types, $data); Zmíněnou kvalitu kódu považuji za své opomenutí a odchýlení se od jedné ze základních hodnot Scrumu, do budoucna tak hodlám své úsilí směřovat zejména k dosažení vyšší kvality, jelikož ostatní elementy Scrumu se s přibývajícími Sprinty poměrně ustálily a fungují spolehlivě. Do budoucna je, co se týče projektu, v plánu nezbytné přepracování prezentační, poté i administrační části do spravovatelnější a méně chaotické podoby, například pomocí českého PHP frameworku Nette, který podporuje architekturu MVC a usnadňuje podstatně vývoj ScrumDesk Program ScrumDesk se osvědčil jako cenný pomocník a do budoucna umožňuje vývojový proces ještě vylepšit, jelikož podporuje zaznamenávání překážek, rizik, prioritizaci pomocí MoSCow a další pokročilé funkce. Aplikace ale trpí jistými chybami. Zřejmě největším nedostatkem je absence hierarchické struktury uživatelských příběhů. Občas se objevily nepřesnosti v grafech či vygenerovaných dokumentech. Odezva by mohla být lepší, aplikace navíc čas od času padala. Celkově hodlám nasazení programu ScrumDesk v příštích projektech ještě zvážit. Pro menší projekty je zde silná konkurence v podobě aplikace MiniScrum, slibný vývoj lze pozorovat i u ScrumDo. Pro větší projekty by 75

81 7. ZHODNOCENÍ mohlo být dobrou volbou překonat těžší začátky a proniknout do aplikace Rally. 76

82 Závěr Cílem této práce bylo ukázat na praktickém příkladě, jak dokáží agilní metodiky pomoci malému týmu při vývoji malé až středně velké aplikace. Bylo třeba nastudovat dostatečné množství literatury, jelikož pravidla Scrumu jsou velmi jednoduchá, snad ale právě proto je snadné je implementovat polovičatě a bez jasných přínosů. Studijních materiálů o Scrumu bylo vzhledem k jeho popularitě přímo nadbytek. Narozdíl od některých agilních metodik, které poslední dobou spíše ustupují do pozadí a příliš se o nich nemluví, je totiž kolem Scrumu neuvěřitelně živá komunita a framework neusíná na vavřínech. V práci jsem poskytl podrobný popis principů Scrumu, metodiku upravil dle potřeb a ukázal její nasazení do týmu, který se v praxi s metodikou do té doby nesetkal. Výsledný text tak může posloužit jako inspirace začínajícím týmům, jelikož obsahuje popis kroků nutných pro zahájení projektu, rady ohledně výběru nástroje a zmiňuje problémy, které mohou při vývoji nastat. Mohu potvrdit zvěsti, že Scrum je návykový, jelikož nezatěžoval vývojový tým nadbytečnými režijními náklady a umožňoval jeho členům se svou prací bavit. Důraz na mezilidskou komunikaci pomohl vytvořit uvnitř týmu pocit sounáležitosti. Díky oboustrannému respektování pravidel Scrumu mohl tým po celý týden pracovat na přidělené práci bez přerušování a změn. Produkt ukázkového projektu e-shop je stále v provozu a do budoucna existuje prostor i chut jej dále rozšiřovat. Vadou na kráse je nízká kvalita kódu, v brzké době tak bude nutná refaktorizace a přepsání některých částí aplikace. Jelikož české literatury o metodice Scrum je stále pomálu, rád bych věřil, že se mi podařilo shrnout nejnovější poznatky a doporučení týkající se tohoto frameworku a ukázat, že Scrum má cenu vyzkoušet, at už je velikost týmu či projektu jakákoli. 77

83 Literatura [1] Manifesto for Agile Software Development. [cit ]. Available from: [2] The NATO Software Engineering Conferences. [cit ]. Available from: randell/nato/. [3] Barry W. Boehm. A Spiral Model of Software Development and Enhancement [4] Frederick P. Brooks Jr. No Silver Bullet: Essence and Accidents of Software Engineering [5] Alistair Cockburn. Crystal methodologies. [cit ]. Available from: methodologies. [6] Mike Cohn. Agile estimating and planning. [cit ]. Available from: presentation/file/85/cohn_estimatingandplanning. pdf. [7] Mike Cohn. User Stories Applied: For Agile Software Development. Addison Wesley Longman Publishing Co., Inc., Redwood City, CA, USA, [8] Mike Cohn. Agile Estimating and Planning. Prentice Hall PTR, Upper Saddle River, NJ, USA, [9] Mike Cohn. Succeeding with Agile: Software Development Using Scrum. Addison-Wesley Professional, 1st edition, [10] Alan, Reimann, Robert, Cronin, Dave Cooper. About Face 3: The Essentials of Interaction Design. Wiley Publishing, Inc., 3. edition, [11] Václav Kadlec. Agilní programování. Computer Press,

84 7. ZHODNOCENÍ [12] Henrik Kniberg. Scrum and XP from the Trenches: Enterprise Software Development. Lulu.com, [13] Steve Krug. Don t Make Me Think!: A Common Sense Approach to Web Usability. Que Corp., Indianapolis, IN, USA, 1st edition, [14] A. aj. MacCormack. Exploring Tradeoffs Between Productivity and Quality in the Selection of Software Development Practices. IEEE Software, [15] Version One. State of agile development survey results. [cit ]. Available from: state_of_agile_development_survey/10/page3.asp. [16] Version One. State of agile survey [cit ]. Available from: Agile_Development_Survey_Results.pdf. [17] R. Ošlejšek. Slidy k předmětu pa103, masarykova univerzita. [cit ]. [18] M. C. Paulk. Agile Methodologies and Process Discipline. CrossTalk, [19] Roman Pichler. Agile Product Management with Scrum: Creating Products that Customers Love. Addison-Wesley Professional, 1st edition, [20] Winston W. Royce. Managing the development of large software systems. [cit ]. Available from: class/spring2003/cmsc838p/process/waterfall.pdf. [21] Jiří Ráček, Jaroslav, Sochor. Slidy k předmětu pa104, masarykova univerzita. [cit ]. [22] Ken Schwaber. Scrum as a framework. [cit ]. Available from: scrum-as-a-framework/. [23] Ken Schwaber. Scrum development process. [cit ]. Available from: download/attachments/ /scrum+development+ Process.pdf. 79

85 7. ZHODNOCENÍ [24] Ken Schwaber. Agile Project Management With Scrum. Microsoft Press, Redmond, WA, USA, [25] Ken, Sutherland, Jeff Schwaber. Scrum guide Available from: 20Guide.pdf. [26] Mike Schwaber, Ken, Beedle. Agile Software Development with Scrum. Prentice Hall PTR, Upper Saddle River, NJ, USA, 1st edition, [27] Bill, Neil, Theresa Scott. Designing Web Interfaces: Principles and Patterns for Rich Interactions. O Reilly Media, Inc., 1st edition, [28] Nik Silver. Burn-up and burn-down charts. [cit ]. Available from: burn-up-and-burn-down-charts/. [29] Jeff Sutherland. The scrum papers: Nut, bolts, and origins of an agile framework. Available from: oopsla/schwapub.pdf. [30] Pawan Vora. Web Application Design Patterns. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, [31] Doug aj. Wallace. Extreme Programming for Web Projects. Addison Wesley, [32] Don Wells. Extreme Programming: A gentle introduction. [cit ]. Available from: org/index.html. [33] Wikipedia. Nonverbal communication. [cit ]. Available from: communication. [34] Wikipedia. Program optimization. [cit ]. Available from: optimization#cite_note-autogenerated [35] Elizabeth, Surdek, Steffan, Ganis, Matthew Woodward. A Practical Guide to Distributed Scrum. IBM Press, 1. edition,

86 Příloha A Obrázky z vývoje aplikace Jelikož některé obrázky byly větších rozměrů nebo nebylo nezbytné je vmísit přímo do textu práce, umístil jsem je do této přílohy. Obrázek A.1: Průběh plánování prvního Sprintu Obrázek A.2: Treemap přehledné rozdělení Sprint backlogu dle vlastníka 81

87 A. OBRÁZKY Z VÝVOJE APLIKACE Obrázek A.3: Product burndown (koláčový graf) Obrázek A.4: Rychlost načtení stránky se vejde do 3 sekund 82

88 A. O BRÁZKY Z VÝVOJE APLIKACE Obrázek A.5: Plánování prvního Sprintu 83

89 A. OBRÁZKY Z VÝVOJE APLIKACE Obrázek A.6: ER diagram zachycující databází v nejnovější podobě pomocí reverse engineeringu 84