Metodika SCRUM. pro malé IT projekty

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Metodika SCRUM pro malé IT projekty DIPLOMOVÁ PRÁCE Bc. Arina Starastsina Brno, 2016

2 Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracovala samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používala nebo z nich čerpala, 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.

3 Poděkování Chtěla bych poděkovat RNDr. Jaroslavu Ráčkovi, Ph.D. za vedení této práce, cenné rady a připomínky při jejím psaní. Také děkuji Ing. Radku Jaitnerovi za pomoc s korekturou a podporu během psaní dané práce.

4 Shrnutí Diplomová práce se zabývá adaptací metodiky Scrum pro malé IT projekty. V práci jsou popsány agilní metodiky vývoje, je uveden podrobný rozbor metodiky Scrum. Dále je daná metodika upravena pro malé IT projekty. Na závěr je navržen SW nástroj pro podporu metodiky SCRUM pro tento typ projektů.

5 Klíčová slova Scrum, malé IT projekty, agilní vývoj, řízení vývoje, SW nástroj

6 Obsah 1. Úvod Softwarové inženýrství Rigorózní vývoj software Spirálový model Metodika RUP Agilní vývoj software Základní principy agilního vývoje Projekty v IT Specifika malých IT projektů Komerční vs. veřejné zakázky Interní vs. externí projekty Rigorózní vs. agilní přístupy Fix Price vs Time&Materials Projekty vhodné pro agilní metodiky Metodiky agilního vývoje Extrémní programování (XP) Lean Development Feature Driven Development Test Driven Development Scrum Porovnání agilních metodik Scrum Slovník Role Artefakty Ovládání Scrumu Výhody a nedostatky metodiky Scrum Výhody Scrumu Nedostatky Scrumu Scrum pro malé IT projekty Změny ve Scrumu pro malé IT projekty:... 45

7 7.2. Adaptace metodiky Scrum pro malé IT projekty Plánování projektu Vedení projektu Scrum nástroje Bez nástrojů Softwarové nástroje Závěr o využívání nástrojů Návrh Scrum Nástroje Nástroj pro malé IT projekty Požadavky na nástroj: Use Case diagram Závěr Literatura Seznam příloh... 73

8 1. Úvod Nabídka různých metodik vývoje je velice široká, avšak skoro všechny jsou obecné a ne vždy je jasné, jak konkrétní metodiku aplikovat na určitý druh projektu. Proto se v mé diplomové práci zabývám adaptací jedné z nejčastěji používaných agilních metodik vývoje Scrum. Práce popisuje nasazení Scrumu pro malé IT projekty. Malé projekty jsou častou záležitostí v různých firmách a agilní metodiky vývoje jsou pro ně nejvíce vyhovující díky možnosti rychlého vývoje a flexibilitě. Avšak stanovené principy agilních metodik nejsou určené přesně pro malé nebo velké projekty. Proto v případě nasazení Scrumu pro malé IT projekty je potřeba upravit některá doporučení a promyslet co nejefektivnější postup tak, aby se neporušoval koncept Scrumu, ale zároveň by byl přístup adaptovaný pro malé projekty. V první části diplomové práce jsou popsány rigorózní a agilní metodiky vývoje, jejich základ a principy. Dále následuje kapitola, která se věnuje specifikům malých IT projektů a různým druhům projektů v IT. Porovnávají se komerční a veřejné zakázky, interní a externí projekty, různé typy smluv. Na závěr je vyhodnoceno, jaké typy projektů jsou vhodné pro agilní metodiky vývoje. Poté jsou uvedeni různí zástupci agilních metodik, detailně popsána metodika Scrum, jsou vyhodnoceny její výhody a nedostatky. Druhá část práce se věnuje přímo adaptaci metodiky Scrum pro malé IT projekty. Jsou navrženy potřebné změny v řízení projektů pomocí dané metodiky. Následně jsou tyto změny a zkušenosti z praxe začleněny do plánování a vedení projektu. Dále jsou popsány a vyhodnoceny existující nástroje na ovládání metodiky Scrum, posouzeny jejich výhody a nedostatky, které následně slouží jako inspirace pro navržení vlastního softwarového nástroje. Návrh SW nástroje na ovládání metodiky Scrum pro malé IT projekty je představen požadavky na takový nástroj, Use Case diagramem a detailním popisem každého případu užití, včetně modelování jemu příslušných procesů, příklady uživatelského rozhraní a datového modelu. Cílem práce je poskytnout návrh změn v metodice Scrum a jejich následné nasazení pro efektivní řízení malých IT projektů, navrhnout SW nástroj na ovládání daného typu projektů. 1

9 2. Softwarové inženýrství Softwarové inženýrství je zavedení a používání řádných inženýrských principů tak, abychom dosáhli ekonomické tvorby software, který je spolehlivý a pracuje účinně na dostupných výpočetních prostředcích. [1] Takovou definici softwarového inženýrství přednesl Fritz Bauer v roce Je dostatečně krátká a vystihuje přesně to, čím se softwarové inženýrství zabývá. Softwarové inženýrství popisuje řadu důležitých aspektů potřebných pro vývoj kvalitního softwaru, který odpovídá požadavkům zákazníka, je těžko zranitelný a efektivně využívá dostupné zdroje (hardwarové, softwarové, personální). [1] Důvodem vzniku softwarového inženýrství jako oboru pravděpodobně byla takzvaná softwarová krize. Na konci 60. let minulého století vznikala spousta problémů souvisejících s vývojem softwaru: projekty se moc prodlužovaly, ceny rostly, kvalita výchozího produktu byla nízká, nemožnost údržby a aktualizace, špatná produktivita programátorů, celková neefektivita vývoje. Příčin bylo hodně, často se dokonce vzájemně kombinovaly. Například špatná komunikace v týmu a mezi týmem a zákazníkem; nesprávný přístup - za akceptaci splnění požadavků odpovídal vývojář, jako jediný, kdo tomu rozumí; špatné plánování a odhady trvání vývoje, nákladů, rozsahu; nízká produktivita, podcenění hrozeb a rizik. Tím pádem se postupně začaly formovat propracovanější inženýrské postupy, které by měly zabránit vzniku charakteristických chyb. Dané postupy, které časem vznikají pro všechny fáze vývoje a tvoří disciplínu softwarového inženýrství. [2] 2.1. Rigorózní vývoj software Rigorózní nebo tradiční metodika spočívá v podrobném popisu procesů vývoje softwaru, definici posloupnosti činnosti, vedení obsáhlých dokumentací a sériovém vývoji. Pro tradiční vývoj je vždy konstantní zadání projektu, jeho funkcionalita, kterou chce zákazník. Je považován za náročný, protože je velmi podrobný, obsahuje hodně formalit a je specifický svým direktivním řízením. Daný přístup umožňuje dobré řízení projektu, role a fáze jsou předem určené, ale je těžko kompatibilní s průběžnými změnami. Dále je uveden nejznámější model a metodika tradičního vývoje. [3] 2

10 Spirálový model Spirálový model životního cyklu se pokouší o eliminaci některých problémů modelu vodopádového, pro něž je charakteristické provedení všech fázi ve stanoveném pořadí. Zavádí nové pojmy do procesu vývoje: iterativní postup a analýza rizik. Patří do skupiny přístupů řízených riziky - postup do další fáze není možný před důslednou analýzou všech možných problémů a rizik spojených s tím. Na základě výsledků analýzy rizik se rozhoduje o následujícím směru vývoje. Rizika se v rámci modelu dají chápat co nejobecněji, totiž všechno, co ohrožuje dosažení cílů projektu. Obrázek 1. Spirálový model životního cyklu [4] 3

11 Model je založen na iterativním přístupu a opakované analýze rizik. Průběh se skládá z opakování jednotlivých kroků, dokud produkt není hotový. Lépe se vypořádává s pozdějšími změnami požadavků. To znamená, že daný model je vhodný i pro větší projekty. Na začátku se produkt vyvíjí na základě hrubé specifikace požadavků, dále během vývoje se provádí upřesňování požadavků zákazníka. Podle obrázku č. 1 lze vidět, že model má čtyři hlavní fáze: Určení cílů, alternativ, omezení, Vyhodnocení alternativ, identifikace a řešení rizik, Vývoj a verifikace další úrovně produktu, Plánování následujících fází. Po každé fázi probíhá testování, hodnocení a předání dílčích výsledků. Díky pravidelnému testování se všechny chyby dají odhalit a vyřešit včas. Analýza rizik pomáhá předem zjistit možná ohrožení průběhu projektu a také připravit reakce na různé typy rizik (projektová, technická, obchodní). [5] Jednotlivé cykly také mají svůj význam: První cyklus má za úkol najít globální rizika, která by mohla ohrozit celý vývoj. Vytváří se základní koncept vývoje; Druhý cyklus ověřuje specifikaci požadavků na systém; Třetí je zaměřený na vytvoření detailního designu; Čtvrtý je o implementaci, testování a integraci. Výhody daného modelu spočívají v tom, že se vytváří prostředí pro vývoj znovupoužitelných komponent, model je vhodný pro složité projekty, provádí se včasné vyloučení nevhodných řešení. Na druhou stranu má i svoje nevýhody: chybějící propracování všech činností během vývoje, změny požadavků se dají provést pouze po ukončení cyklu, víra v dokonalost lidských zdrojů. V současné době se spirála nepoužívá moc často. Na základě spirálového modelu vzniklo hodně konkrétních propracovaných metodik, které ho často zastupují. Samotný model ale už není dostatečně vyhovující a pružný pro nové druhy aplikací. [1] 4

12 Metodika RUP Rational Unified Process (RUP) je rigorózní technika odvozená z klasického spirálového modelu životního cyklu. Je to rozsáhlá a propracovaná metodika vývoje softwaru. Je to komerční produkt vytvořený firmou Rational Software Corporation (která byla odkoupena IBM) s poměrně vysokou pořizovací cenou. Avšak RUP podrobně odpovídá na všechny otázky, které souvisí s procesem vývoje softwaru. Technika vychází z takových praktik a postupů jako iterativní vývoj, řízení změn, ověřování kvality software, aktivní správa požadavků, komponentová architektura a vizuální modelování. RUP je objektově orientovaná metodika, která patří do přístupů řízených případy užití. Hlavní element je případ užití definovaný jako sekvence akcí systému, která poskytuje konkrétní hodnotu uživateli. [1] Obrázek 2. RUP [6] Na obrázku č. 2 je představen první (úvodní vývojový) cyklus vývoje. Po jeho ukončení zpravidla vývoj ještě pokračuje. Produkt se může vyvíjet dál. Následující cykly jsou rozvíjející. Každý cyklus má čtyři základní fáze: 1. Zahájení. Definování účelu a rozsahu projektu, obchodní kontext. Většinou se skládá z jedné iterace. 5

13 2. Příprava. Analýza potřeb projektu a zákazníka, definice základní architektury. Zpravidla obsahuje dvě iterace, v případě více rizik (noví pracovníci, úplně nový produkt) mohou být i tři či čtyři iterace. 3. Konstrukce. Vývoj designu, tvorba zdrojového kódu. Obvykle se plánují minimálně dvě iterace, v případě složitějších projektů tři až čtyři. 4. Předávání. Předání produktu buď zákazníkovi, nebo do dalšího vývojového cyklu. Stejně jako předchozí mívá minimálně dvě iterace. [7] Výhodami RUPu jsou jeho obecnost a možnost přizpůsobit různým projektům, iterativní přístup, detailní propracovanost, znovupoužitelnost, dostupnost šablon, jednotná notace UML, včasné odhalení rizik a jednodušší správa změn. Ale například rozsáhlost a obecnost techniky může být nevýhodou pro menší týmy z důvodu potřeby dlouhého a hlubokého studia. Značnou nevýhodou je také to, že produkt je komerční a poměrně drahý. Metodika RUP je nejvhodnější pro rozsáhlé organizace, které pracují na velkých a složitých projektech. Nehodí se pro malé firmy a týmy, které vznikají z důvodu vypracování jednoho či pár projektů. [1] 2.2. Agilní vývoj software Dynamičnost okolního světa a každodenní změny rozhodně mají vliv i na vývoj softwaru. Změny nastávají ve výpočetní technice, vývojových nástrojích a prostředích, objevují se nové představy, požadavky na software, rychlost jeho dodání a kvalitu. Všechny tyto důvody vedou k tomu, že je potřeba přizpůsobit i styl vývoje a způsob vedení takových projektů. Jako reakce na potřebu změny postupně vznikly agilní metodiky vývoje softwaru. Jsou to metodiky, které umožňují rychlý vývoj, umí reagovat na měnící se požadavky a zvládají průběžnou údržbu. Byl vytvořen Manifest agilního vývoje softwaru (Manifesto for Agile Software Development, The Agile Manifesto), spolu s ním byla založena Aliance pro agilní vývoj softwaru (The Agile Alliance). Pojem agilní metodologie označuje skupinu metodik, které vycházejí z poznání, že jedinou cestou, jak prověřit správnost navrženého systému, je co nejrychleji jej vyvinout, předložit zákazníkovi a na základě zpětné vazby upravovat. [8] Text Manifestu je následující: Objevujeme lepší způsoby vývoje software tím, že jej tvoříme a pomáháme při jeho tvorbě ostatním. Při této práci jsme dospěli k těmto hodnotám: 6

14 Jednotlivci a interakce před procesy a nástroji Fungující software před vyčerpávající dokumentací Spolupráce se zákazníkem před vyjednáváním o smlouvě Reagování na změny před dodržováním plánu Jakkoliv jsou body napravo hodnotné, bodů nalevo si ceníme více [9] Základní principy agilního vývoje Podrobněji rozebereme body z Manifestu agilního vývoje softwaru. Iterativní a inkrementální vývoj s krátkými iteracemi Plán projektu se vytváří takovým způsobem, že se nové funkce dodávají souběžně s vývojem. Zákazník je často seznamován s novými konfiguracemi, proto má nejen pocit, že je začleněný přímo do vývoje a vidí pokrok, ale také má možnost kontrolovat vývoj a funkcionalitu. Osobní komunikace v rámci týmu jako forma vývoje Je známá věc, že za hodně problémů odpovídá špatná komunikace v rámci týmu. Agilní přístup prohlašuje komunikaci za jednu z forem vývoje a integruje ji přímo do procesu, což značně zlepšuje chápání problémů a snižuje riziko vznikajících chyb. To znamená, že komunikací dosáhneme fungujícího softwaru. Komunikace se zákazníkem Tím, že se zákazník stává součástí vývojového týmu, výrazně se zlepšuje zpětná vazba ze strany uživatele. Zákazník se má zúčastňovat setkání, návrhů, hodnocení testů. Všechno to pomáhá přesněji vyhovět požadavkům klienta a rychle se přizpůsobit případným změnám. Reakce na změny, opakované testování Vzhledem ke stálé spolupráci se zákazníkem je očekávané, že bude potřeba provádět některé změny během projektu. Je důležité umět rychle zareagovat na nové požadavky podle potřeb klienta. Proto je také nutné průběžně testovat správnost vyvinutých funkcionalit systému. Testy by měly být automatizované a napsané ještě před implementací testované části. [8] 7

15 Také v Manifestu jsou uvedeny určité principy, na kterých je založen agilní vývoj: 1. Naší nejvyšší prioritou je vyhovět zákazníkovi časným a průběžným dodáváním hodnotného softwaru. 2. Vítáme změny v požadavcích, a to i v pozdějších fázích vývoje. Agilní procesy podporují změny vedoucí ke zvýšení konkurenceschopnosti zákazníka. 3. Dodáváme fungující software v intervalech týdnů až měsíců, s preferencí kratší periody. 4. Lidé z byznysu a vývoje musí spolupracovat denně po celou dobu projektu. 5. Budujeme projekty kolem motivovaných jednotlivců. Vytváříme jim prostředí, podporujeme jejich potřeby a důvěřujeme, že odvedou dobrou práci. 6. Nejúčinnějším a nejefektnějším způsobem sdělování informací vývojovému týmu z vnějšku i uvnitř něj je osobní konverzace. 7. Hlavním měřítkem pokroku je fungující software. 8. Agilní procesy podporují udržitelný rozvoj. Sponzoři, vývojáři i uživatelé by měli být schopni udržet stálé tempo trvale. 9. Agilitu zvyšuje neustálá pozornost věnovaná technické výjimečnosti a dobrému designu. 10. Jednoduchost - umění maximalizovat množství nevykonané práce - je klíčová. 11. Nejlepší architektury, požadavky a návrhy vzejdou ze samo-organizujících se týmů. 12. Tým se pravidelně zamýšlí nad tím, jak se stát efektivnějším, a následně koriguje a přizpůsobuje své chování a zvyklosti. [9] 8

16 3. Projekty v IT Moje diplomová práce se zabývá nasazením metodiky Scrum pro malé IT projekty, proto tato kapitola bude zaměřena na specifika takových projektu. Také se uvedou rozdíly mezi komerčními a veřejnými zakázkami, interními a externími projekty. Porovnáním projektů z různých hledisek se zjistí, které projekty se dají vyvíjet pomocí metodiky Scrum Specifika malých IT projektů Malé IT projekty jsou poměrně rozšířenou praxí jak ve velkých tak i v malých firmách. Avšak většina standardních rigorózních vývojových metodik je zaměřena na větší projekty a předpokládá, že během vývoje budou dostupné všechny potřebné zdroje. Nasazení daných metodik pro menší projekty bývá těžké a neefektivní. Občas se muže stát i to, že systematický vývoj bude úplně zanedbán z důvodů toho, že projekt je malý a nepotřebuje speciální plán realizace. Všechno to vede k neuspokojivým výsledkům, chybám a odkládání termínu odevzdání. Je důležité chápat, že každý, ať velký nebo malý projekt, potřebuje nějaký určitý přístup, který pomůže efektivně splnit požadavky zákazníka a včas dodat očekávaný produkt. K hlavním vlastnostem malých IT projektů patří: Jednodušší obsah. Nejde o velké složité systémy nebo aplikace, menší IT projekty přepokládají nižší náročnost požadavků, rychlý vývoj, nižší rozpočet. Menší délka trvání. Pro menší projekty je charakteristický i menší čas určený pro splnění všech požadavků. Menší množství a náročnost požadavků, menší rozpočet projektu a z toho plyne i očekávání, že projekt bude dokončen poměrně rychle. Menší tým, širší zaměření. Tým, který pracuje na menším projektu, obsahuje i méně členů, také z důvodu nižšího rozpočtu. Vzhledem k tomu, že členů týmu je méně, měl by každý z nich mít širší přehled a možnost zastoupit jiného člena týmu v případě potřeby. Pro větší projekty je obvykle potřeba mít úzce zaměřené specialisty, kteří se dobře vyznají ve svém oboru, u menších projektů se hodí, aby každý člen týmu měl širokou specializaci, nevadí, pokud není specialista v každém z oborů, protože požadavky menších projektů nejsou obvykle vysoké náročnosti. 9

17 Nižší náročnost funkcionality. Nižší rozpočet a délka trvání vedou k tomu, že náročnost projektu a funkcionalit v něm také nebude vysoká. Často se dají použít hotová řešení a řešení s otevřeným zdrojovým kódem. Dynamický životní cyklus projektu. Vzhledem k tomu, že projekt je menší a neobsahuje složité funkcionality, očekává se, že během vývoje bude možné změnit některé požadavky, což zákazníci často využívají. Předpokládá se dynamičtější styl řízení, vysoká efektivita a schopnost reagovat na průběžnou změnu požadavků Komerční vs. veřejné zakázky Komerční zakázky jsou to, co si člověk běžně představí pod pojmem zakázky. Proběhne domluva se zákazníkem, upřesní se požadavky, sepíše se smlouva a v průběhu projektu budou moct proběhnout potřebné změny. Co se týče veřejných zakázek, je to mnohem složitější. Veřejné zakázky začínají tím, že instituce vypíše zakázku s požadavky na funkcionalitu výchozího produktu a čeká, až se přihlásí firmy pro následující soutěž. Vzhledem k tomu, že veřejné zakázky jsou financované státem, nejdůležitější kritérium je cena. Dodavatel se vybírá na základě ekonomický nejvýhodnější nabídky. Pokud zadavatel chce rozšířit stávající software o další licenci, může to vyvolat spoustu problémů spojených s tím, že ne vždy se dá obrátit na předchozího dodavatele, z důvodů možnosti poskytování dalších služeb jenom v rámci zadávacích podmínek původní zakázky. Často je potřeba vypisovat novou veřejnou zakázku, což může nakonec znamenat nejenom změnu, ale i celkovou náhradu produktu. Je to velice ekonomicky neefektivní a konfrontuje s hlavním principem veřejných zakázek, který vždy trvá na nejmenším rozpočtu. [10] Častým problémem u státních zakázek je řízení změn. Podle zákonů o veřejných zakázkách 82 odst. 7: (7) Zadavatel nesmí umožnit podstatnou změnu práv a povinností vyplývajících ze smlouvy, kterou uzavřel s vybraným uchazečem. Za podstatnou se považuje taková změna, která by a) rozšířila předmět veřejné zakázky; tím není dotčeno ustanovení 23 odst. 5 písm. b) a 23 odst. 7, b) za použití v původním zadávacím řízení umožnila účast jiných dodavatelů, 10

18 c) za použití v původním zadávacím řízení mohla ovlivnit výběr nejvhodnější nabídky, nebo d) měnila ekonomickou rovnováhu smlouvy ve prospěch vybraného uchazeče. [11] Tím pádem provedení výraznějších změn v rámci projektu je zcela nemožné. Zákon v podstatě stanovuje, že se zakázka má vyvíjet klasickým rigorózním stylem, protože každý agilní přístup klade důraz na komunikaci se zákazníkem a řešení aktuálních požadavků a problémů, místo dlouhého sjednávání smluv, přesného určení všech požadavků do hloubky a důkladného vedení dokumentace. Dalšími specifickými problémy veřejných zakázek v IT může být požadavek zadavatele na výhradní licenci a požadavek na neomezenou odpovědnost za škodu. Požadavek na výhradní licenci předpokládá, že ani daný hotový produkt ani jeho část nebudou v budoucnu nikde jinde využity. Pro firmy, které se nespecializují na vývoj jedinečných řešení pro každého zákazníka, je to velké omezení a potřeba změn v licenčních podmínkách, což často vede k jejich nezájmu ohledně poskytování služeb jediné státní instituci. Požadavek na neomezenou odpovědnost za škodu je také složité téma, protože firmy většinou mají určité limity pro náhradu škody. V případě, že se uskuteční škoda a bude sjednáno, že výrobce má neomezenou odpovědnost, bude to složitý proces dokazování, zda za tu škodu může dodavatel, může to trvat několik let a nakonec nedojít k žádnému uspokojujícímu řešení. [10] 3.3. Interní vs. externí projekty Externí projekty slouží k dosažení ekonomické hodnoty, interní mají poskytovat podpůrnou funkci, která přímo ovlivňuje i kvalitnější realizaci projektů externích. Hlavním rozdílem mezi externími a interními projekty je různý charakter cíle: U externích projektů je cílem dosáhnout co nejvyšší hrubé marže, tyto projekty jsou zdrojem zisku, prostředků pro další rozvoj podniku a také referencí pro zákazníky. Cílem interních projektů je dosažení konkurenční výhody, zefektivnění činnosti podniku. Měřítkem úspěšnosti projektu je dosažení návratnosti vložených prostředků. [12] Externí projekt vychází z uzavřené smlouvy mezi zákazníkem a firmou dodavatele. Interní projekt může vzniknout na základě potřeb firmy nebo jako investice do rozvoje, v prvním případě se konkrétněji stanovují požadavky na očekávaný výsledek, v druhém může být jenom určen abstraktní cíl. U externích projektů je důležité před sjednáním smlouvy zjistit všechna očekávání zákazníka a pečlivě se 11

19 domluvit na všech smluvních závazcích, u interních projektů je to mnohem volnější a často se požadavky doplňují časem. Důležitou vlastností externích projektů je plnění smluvních závazků. Pokud se nedodržují stanovené termíny, parametry výchozího produktu a další sjednané podmínky vývoje, firma musí vyplácet náhrady škod a pokuty. Pro interní projekty spíš platí, že se podmínky, požadavky a termíny mohou měnit, žádné pokuty za to nehrozí, proto se často ve firmách dává přednost externím projektům a interní se mohou odkládat, případně i pozastavit. Také je důležité uvést, že na podporu externích projektu se klade mnohem větší důraz, protože podpora produktů je sjednána ve smlouvě, má určitý postup a musí se plnit. Pro případné problémy v interních projektech se řešení zakládá na dohodě, postup není fixní a často se řeší, pokud je na to čas. [13] Externí a interní projekty ve firmě jsou vždy logicky propojené. Externí projekty využívají výhody interních projektů. Například, pokud firma interně vypracuje svoji technologii a bude ji uplatňovat pro externí projekty. Pro lepší znázornění na obrázku č. 3 je vidět vztah mezi různými typy projektů a jejich spojení s externími subjekty. Obrázek 3. Vztah mezi různými typy projektů a jejich spojení s externími subjekty [12] 3.4. Rigorózní vs. agilní přístupy Jestli porovnáváme rigorózní a agilní metodiky vývoje, dá se zjistit, že mají docela odlišné zaměření v rámci vývoje softwaru. 12

20 Obrázek 4. Rigorózní vs. agilní přístupy Obrázek č. 4 znázorňuje rozdíl dvou přístupů. Pro klasický je fixní funkcionalita a čas, zdroje se mohou během vývoje měnit. Agilní naopak považuje čas a zdroje za fixní, přičemž funkcionalita se může během vývoje změnit. Například, pokud zákazník zjistí, že potřebuje něco navíc. Rigorózní Agilní Definování požadavků předem Definování požadavků na začátku jenom obecně Změny by se měly minimalizovat. Řízení změn je náročný proces. Změny jsou povolené. Vývojový proces se může přizpůsobit změně požadavků. Zaměření na konečný kvalitativní výsledek. Zaměření na hodnotu, která bude zákazníkovi hned dodána. Procesy a činnosti jsou přesně definované. Souhrn obecných pravidel a přístupů. 13

21 Minimalizace komunikace se zákazníkem. Zákazník nepatří do vývojového procesu. Stálá komunikace se zákazníkem během celého projektu. Zákazník je součástí vývoje. Velké projekty, standardní projekty Menší týmy, výzkumné projekty Lidský faktor není primární. Lidé, jejich spolupráce, znalosti a zodpovědnost jsou důležité pro efektivní vývoj. Tabulka 1. Rigorózní vs. Agilní vývoj Porovnání přístupů ukazuje, že rigorózní metodiky jsou vyhovující spíš pro velké týmy a projekty, kde je potřeba mít stanoven postup a přehled všeho, co se děje během vývoje. Agilní metodiky jsou vyhovující pro menší týmy, kde vývojáři mají možnost komunikovat a řešit aktuální požadavky a problémy. Rigorózní metodiky se hodí pro velké projekty, v nichž se dá ztratit a zamotat bez konkrétně předepsaných postupů a procesů. Agilní metodiky jsou spíše pro malé a střední projekty, v nichž se dá měnit a přidávat funkcionality bez výrazné změny celého projektu Fix Price vs Time&Materials Fix Price. Předpokládá stanovený rozpočet, časový rámec a projektový rozsah. Většinou se používá pro menší projekty s jasnými požadavky. Požadavky jsou konkrétně sepsané a zpravidla se nemění během vývoje. Takový druh smluv je dobrý pro zákazníka tím, že přesně ví, kolik peněz zaplatí na konci. Nevýhodou je to, že se nepočítá se žádnými změnami během projektu. Time&Materials. Přibližný odhad časového rámce, možnost změn během vývoje, cena záleží na čase stráveném na projektu. Práce je v případě dané smlouvy mnohem flexibilnější, protože málokdy zákazník na začátku přesně ví, co potřebuje a to způsobuje změny v projektu. Daný typ smluv zaručí kvalitnější a dobře otestovaný výsledek. Dodavatel se nemusí bát, že dostane na konci méně, než věnoval celému projektu, protože se platí za reálný čas práce. Nevýhodou pro dodavatele může být to, že konečná cena bude nižší než průměr na trhu; pro zákazníka to, že se projekt může dlouze roztáhnout řešením neexistujících problémů. 14

22 Ve světě agilních metodik je model Time&Materials bližší realitě, protože způsobuje častou komunikaci dodavatele a zákazníka, počítá se změnami během projektu. Daný model nebrání plánování časového odhadu a počítání přibližného rozpočtu projektu. [14] 3.6. Projekty vhodné pro agilní metodiky Posuzování projektů z různých hledisek dává možnost zjistit, které projekty se hodí pro nasazení agilních metodik. Státní zakázky se nehodí pro agilní vývoj, protože vyžadují stanovení všech požadavků ještě před začátkem vývoje, nepovolují výrazné změny během vývojového procesu, potřebují pečlivě sepsanou smlouvu a důslednou dokumentaci. Agilní metodiky nepředpokládají hned od začátku stanovení všech potřebných požadavků. Zpravidla se domluví základní funkcionalita a pak se postupně přidávají a mění prvky projektů. To znamená, že agilní metodiky jsou vyhovující jenom pro komerční zakázky. Pro agilní vývoj není velký rozdíl, zda je projekt interní nebo externí. Avšak jestli jsou pro interní projekty agilní metodiky skoro přirozené a intuitivní, pro externí projekty může jejich nasazení zabrat více času, protože u externích projektů je potřeba pečlivě dodržovat smluvní podmínky včetně termínu. Podstatná je i správná volba smluvního modelu při agilním řízení projektu. Smlouva musí počítat se specifikami agilních metodik. Projekty vyhovující pro agilní metodiky vývoje: komerční zakázky, interní a externí projekty, time&materials. Ve své diplomové práci se zaměřím na nasazení agilní metodiky Scrum pro menší IT projekty. To znamená, že projekty by měly být nejenom komerční interní nebo komerční externí, ale i odpovídat specifikaci malých IT projektů, které předpokládají jednodušší obsah, kratší čas, menší rozpočet a nižší náročnost funkcionalit. 15

23 4. Metodiky agilního vývoje V následující části práce jsou popsány konkrétní metodiky vycházející z agilního manifestu. Agilní metodiky jsou v současnosti různorodé a stále se objevují nové. Následující přehled se týká nejznámějších zástupců, které mají širší využití v praxi. V agilním vývoji také existuje tendence aktivního upravování metodik podle vlastních potřeb firem, projektů, týmů Extrémní programování (XP) Extrémní programování je metodika, která je vhodná pro střední a malé týmy (cca 2-10 programátorů). Základním filozofickým východiskem extrémního programování je přesvědčení, že jediným exaktním, jednoznačným, změřitelným, ověřitelným a nezpochybnitelným zdrojem informací je zdrojový kód. [1] XP metodika je založena na využití známých postupů a myšlenek, avšak občas dosahuje extrémního použití. Pokud se osvědčila revize kódu, pak v XP se zdrojový text reviduje neustále. Využívá se tzv. párového programování, kdy společně u jednoho počítače pracují dva programátoři. Zabraňuje se tam mimo jiné tzv. profesionální slepotě. Pokud se osvědčilo testování kódu, pak v XP se testuje vše a neustále. Testují jak programátoři pomocí jednotkových testů tak i zákazníci pomocí akceptačních testů (testů funkcionality). Testovací kód mnohdy svým rozsahem převyšuje vlastní výkonný kód. Testování pak probíhá prakticky neustále, před změnou kódu, po změně kódu a kontroluje zda se v průběhu vývoje funkcionalita nepoškodila. Pokud se osvědčilo navrhování kódu, pak v XP bude navrhovat úplně každý a neustále. Pomocí refaktorizace může každý kontrolovat návrh kódu a vhodně ho upravovat. Pokud se osvědčila jednoduchost, pak v XP udržujeme program na co nejmenší úrovni složitosti. Vždy programujeme jen to, co je v danou chvíli nezbytné. Nejjednodušší program, který bude fungovat. Pokud je důležitá architektura, pak v XP se bude každý neustále podílet na definování a úpravě architektury. Využívá se k tomu metafory. 16

24 Pokud je důležité testování integrace, pak se v XP testuje integrace jednotlivých komponent i několikrát denně, aby bylo zajištěno že všechny části spolupracují tak jak mají. Toto pravidlo se nazývá neustálou integrací. Pokud se osvědčily krátké iterace, pak v XP zkrátíme iterační periodu na extrémně krátkou minuty, hodiny či dny místo týdnů, měsíců či roků. Jakmile je nová funkce připravena a otestována, integrujeme ji do produkční verze programu. K určení optimální iterační periody využíváme plánovací hru. [15] Proměnné Extrémní programování lehce modifikuje tři základní proměnné z obrázku č. 4 a přidává k nim jednu navíc, která se považuje za nejdůležitější. Jsou potom čtyři proměnné: kvalita, čas, náklady, šíře zadání. Poslední nová proměna označuje všechnu funkcionalitu, kterou chce zákazník. Šíře zadání také ukazuje, které funkce jsou klíčové a které nejsou až tak podstatné. Důležitý axiom XP zní: vnější síly (zákazníci, manažeři) mají možnost vybrat hodnoty libovolných tří proměnných; vývojový tým pak vybere výslednou hodnotu čtvrté proměnné. [16] Pokud někdo pro tým stanoví všechny čtyři proměně, tým bude pracovat pod tlakem a zhorší se kvalita výsledků. [1] Hodnoty Pro extrémní programování jsou charakteristické čtyři základní hodnoty a jedna nejhlubší a nevýznamnější. Jsou to komunikace, jednoduchost, zpětná vazba, odvaha a respekt. XP metodika se hodně zaměřuje na správné fungování komunikačních kanálů. Jsou celé řady postupů pro spolupráci, které buď podporují komunikaci anebo se bez ní ani nemohou provést. 17

25 XP se zaměřuje na jednoduchost a přemýšlení o současnosti - nejsnadnější fungující varianta toho co je potřeba udělat teď, je správným řešením. Extrémní programování říká, že čím více je testů, tím lepší a kvalitnější bude výsledek. Zpětná vazba přichází jak od interního průběžného testování hotových součástí projektu, tak i od zákazníků, kteří kontrolují potřebnou funkcionalitu. Odvaha je v podstatě součástí XP. Vzhledem k tomu, že se během vývoje může objevit jakákoliv zásadní chyba, je potřeba mít dostatek odvahy na to, aby tým zahodil celou nesprávnou část řešení a začal znova. Anebo se nebát hledat správná řešení a zkoušet různé postupy, dokud se neobjeví správný. A poslední pátá skrytá hodnota, respekt, znamená to, že členové týmu pracující na projektu by se měli starat o společný cíl, rozumět si, zajímat se, podporovat. [17] [1] Postupy Hodnoty a proměnné popsané výše vytváří určitý rámec pro extrémní programování, avšak nepředvádí XP jako použitelnou metodiku pro vývoj software. Proto existuje dvanáct postupů, jejichž využití pomáhá efektivnímu vytváření kvalitních produktů. Plánovací hra. Celý tým pracuje na vytváření karet zadání. Po plánovací hře vzniká plán verze. Metafora. Metaforický příběh o fungování systému. Pomáhá udržovat v hlavě, co se od produktu očekává. Testování. Průběžné testování vznikajících části systému. Zákazníci také testují funkcionality. Párové programování. Zdrojový kód se píše párem vývojářů. Maji pro oba jeden počítač. Jeden, který zrovna programuje, přemýšlí nad implementací v daný okamžik. Druhý přemýšlí nad celkovým postupem a strategií v rámci systému a průběžně kontroluje kód. Pak se vymění. Nepřetržitá integrace. Po dokončení úkolů je systém integrován a testován (minimálně jednou denně). Zákazník na pracovišti. Pro lepší zpětnou vazbu nabízí XP, aby zákazník či skutečný uživatel byl stále součástí týmu a byl kdykoliv přístupný (přímo na pracovišti). Malé verze. Předvádí se kompletní a funkční součásti produktů, které realizují drobnou či větší funkcionalitu. 18

26 Jednoduchý návrh. Hlavní cíl je, aby byl systém co nejjednodušší, ale stále splňoval požadavky. Refaktorizace. Zlepšení, zjednodušení, zpřehlednění kódu. Provádí se před nebo po změně programu. Společné vlastnictví. V extrémním programování nesou všichni členové týmu zodpovědnost za celý systém. Kdokoliv může měnit zdrojový text v systému. Čtyřicetihodinový pracovní týden. Přesčasy vedou ke snížení efektivity. Je důležité mít spokojené zaměstnance. Standardy pro psaní zdrojového kódu. Zdrojový kód je základním nositelem informací. Proto je potřeba, aby všechen kód byl přehledný, čitelný a srozumitelný pro každého člena týmu. Všech dvanáct principů by se mělo dodržovat zároveň, protože se vzájemně podporují a vyžadují. [1] Činnosti Základní činnosti při vývoji pomocí XP: 1. Testování. Průběžné. Žádná integrace bez úspěšných testů. Testy se píšou před samotnou částí systému. 2. Psaní kódu. Zdrojový kód je cíl a metodou extrémního programování. Kód se píše po napsání testů. 3. Poslouchání. Je důležité chápat, co chtějí zákazníci, co říkají kolegové. Komunikace je součástí procesu vývoje. 4. Design. Dobrý návrh pomůže eliminovat chyby a uspořádá logiku tak, aby změny jedné části systému nevyvolaly potřebu změn ostatních. Proto návrh a jeho vylepšení je každodenní nutnou prací všech vývojářů. Všechny základní činnosti extrémního programování jsou obousměrně závislé na sobě. [1] Shrnutí K výhodám extrémního programování patří vyrovnanost s lidskými zvyky a chováním. Všechny postupy jsou založené na tom, co lidé rádi dělají. Například komunikují, mají vyvážený vztah v týmu, vzájemný respekt. Další výhodou je 19

27 postupné řešení projektu, který vychází z iterativního a inkrementálního vývoje. Výhodou je také i to, že daná metoda je dost populární a dá se o ní najít dostatečné množství informací. Jednou, ale podstatnou, nevýhodou XP je obtížná realizace. Postup a hodnoty metody jsou jasné, ale naučit se dělat věci tak, jak říká daná metodika, není jednoduché. Všichni v týmu, zákazníci a nadřízení si musí zvyknout na nový přístup a naučit se spolupracovat. Jenom v takovém případě bude extrémní programování úspěšné a efektivní. XP se nehodí pro velké týmy, je určeno pro menší (2-10 lidí), pracující na měnících se podmínkách s nekonkrétním zadáním. Hodí se pro lidi ochotné komunikovat a schopné se naučit hlavním principům metody a správně je aplikovat. V takovém případě využití extrémního programování bude příjemné pro programátory a účinné pro celkový proces vývoje. [17] 4.2. Lean Development Lean development je štíhlý přístup k vývoji software. Zakládá se na tom, aby se věci dělaly jen v případě potřeby. Lean přístup je strategičtější než jiné agilní metodiky. Má pro sebe stanovené cíle: vyvíjet za třetinu standardního času, využít třetinu standardního rozpočtu a snížit množství výskytu chyb také o třetinu. Lean Development nepopisuje jakým způsobem vyvíjet a jak řídit tým, ale nabízí pravidla a principy pro efektivnější vývoj a snížení nákladů. [18] [1] Pravidla 1. Odstranit vše, co je zbytečné. 2. Minimalizovat zásoby (minimalizovat meziprodukty). 3. Maximalizovat tok (zkrátit čas potřebný pro vývoj). 4. Vývoj je tažen poptávkou (většina rozhodnutí se dělá tak pozdě, jak je to jen možné). 5. Pracovníci mají pravomoci rozhodovat (rozhodování probíhá i na nejnižších úrovních). 6. Hlavním cílem je uspokojovat požadavky zákazníků (a to nejen teď, ale i v budoucnu). 7. Zavést zpětnou vazbu (nebát se změn v učiněných rozhodnutích). 20

28 8. Odstranit lokální optimalizaci (neustálá optimalizace stávajícího řešení postrádá smysl). 9. Vybudovat partnerství s dodavateli (využívat subdodávek a předpřipravených komponent). 10. Vybudovat kulturu pro možnost neustálého zlepšování. [1] Principy Lean Software Development je založen na daných principech: Odstranit vše, co nepřináší hodnotu. Zbavit se všech nepotřebných věcí. Pracovat a udržovat něco, co na konci ani nebude potřeba je plýtvání časem a penězi. Zlepšovat se a učit v průběhu práce. Pravidelná zpětná vazba připomíná, co je opravdu důležité a poukazuje na chyby, kterým by se příště dalo vyhnout. Rozhodovat se co nejpozději. Pokud rozhodnutí probíhá později, k dispozici je více informací, na základě kterých se dá vybrat lepší řešení. Vede to ke snížení shromáždění nepotřebných věcí, co se vyvíjely pro jistotu. Dodávat práci, jak nejrychleji to jde. Po dokončení se dá otestovat a zhodnotit výsledek, což dává zpětnou vazbu, kterou se dá použít v příští iteraci vývoje. Dát týmu důvěru a zodpovědnost. Důvěra a zodpovědnost motivuje tým a vede k lepším výsledkům. Zaměřit se na celkový výsledek. Chyby musí poučit pro příště. Je potřeba začít u malých věcí, zhodnotit je a poučit se. Přemýšlet nejen o výsledné funkcionalitě, ale i dojmu, který produkt vyvolává. Dbát o kvalitu a udržitelnost celkového systému. [18] Klíčové pojmy Klíčovými pojmy v Lean Development jsou hodnota a plýtvání. Jedno z hlavních pravidel dané metodiky říká: ignorovat všechny zbytečnosti a provádět jenom to, co poskytuje hodnotu výslednému produktu. Hodnoty pro Lean jsou například: nástroje, které používá tým během výroby, dovednosti získané týmem, výsledný produkt. Zbytečnost či plýtvání mohou být následující: nadvýroba, čas ztracený čekáním, hledáním, stahováním, zbytečně kroky v procesu vývoje, neefektivní práce, defekty. [1] 21

29 Shrnutí Lean Development není rozsáhlá a propracovaná metoda, která obsahuje konkrétní postupy pro efektivní vývoj software. Jsou to jenom pravidla a principy, které naznačují, jak má probíhat vývoj, kam směřovat a čemu se vyhnout. Tato metodika rozhodně nebude vyhovovat firmám a týmům, které potřebují konkrétní, propracovaný postup se svými metodami a návody k jejich použití. Avšak využití pravidel a principu Lean Development by rozhodně zlepšilo efektivitu vývoje týmům, které by byly ochotné vyzkoušet metodiku v praxi. Na principech Lean Development je také založena známá metodika Kanban Feature Driven Development Feature Driven Development je metodika agilního vývoje, ve které hlavní roli hrají vlastnosti konečného produktu. FDD je iterativní proces, který má krátké iterace a je založen na modelování. Proces vývoje začíná návrhem celkového, globálního modelu, jehož cílem je ukázat, z jakých části se bude systém skládat a jak bude probíhat komunikace s okolím. Pak následují iterace (doporučená délka je dva týdny), ve kterých se provádí realizace jednotlivých užitných vlastností. Po skončení každé iterace se zpravidla dodává zákazníkovi ukázka funkční verze aplikace. Tím pádem má zákazník možnost se zúčastnit vývoje dáváním zpětné vazby a mít přehled o práci na zakázce. [19] Klíčové pojmy Vlastnost. Z pohledu FDD je vlastnost malý výsledek či malá část funkčnosti, která je užitečná pro klienta. Vlastnost je měřitelná, srozumitelná a realizovatelná. Musíme být schopni porovnat vlastnost aplikace, jestli odpovídá vlastnosti požadované zákazníkem, být schopni popsat vlastnost, vědět čeho se týká daná vlastnost a co je jejím výsledkem. Máme mít jistotu, že vlastnost se dá realizovat a že to nezabere více, než je standardní doba realizace vlastnosti. Vlastnost se zapisuje ve formátu: <akce> <předmět> <podrobnosti>, - kde akce je činnost, která se má provést v rámci dané vlastnosti, předmět je artefakt, na němž akce probíhá, podrobnosti se využívají pro upřesnění vlastnosti. Příklad: <vypsání> <jednotlivých prodejů> <na obrazovku>. Vlastnost je malá funkce, která by se mohla 22

30 dokončit do dvou týdnů, ideálně i dřív. Na druhou stranu nemá být vlastnost jenom přístupovou metodou. Přístup řízený modelem. Pro FDD je modelování důležitou součástí vývojového procesu. Vývoj každého systému začíná návrhem modelu celého systému, v každé iteraci se vytváří svůj konkrétní model. Feature Driven Development říká, že dobrý model urychlí proces vývoje tím, že pomůže hlubšímu porozumění problematiky daného produktu. [1] Procesy Obrázek 5. FDD [20] Dále jsou popsány jednotlivé procesy (obrázek č. 5). V závorkách je uvedeno procento času v úvodním průchodu/procento času v opakovaných průchodech. Pokud je čas stejný i v úvodním i v opakovaném průchodu, je uvedeno jenom jedno číslo. Poslední fáze, návrh a implementace mají stejnou délku, protože se počítají dohromady. 1. Vytvoření globálního modelu (10 %/4 %). Uvádí se představa o systému, požadavky a kontext. Cílem je, aby členové vývojového týmu získali představu o tom, co je očekává. Dále se pracuje na úvodním modelu (například diagram tříd) a probíhá podrobnější vysvětlování vlastností, které se očekávají od systému. Součástí obecného modelu může být i prvotní seznam požadovaných vlastností systému. 2. Vypracování seznamu užitných vlastností (4 %/1 %). Po první fázi je možné vytvořit podrobný seznam základních užitných vlastností. Výsledkem je seznam vlastností, který je kontextově rozdělen do logicky souvisejících skupin. 23

31 3. Plánování užitné vlastnosti (2 %). Vytváří se další plány. Důležité je datum ukončení celého vývoje. Pak se vytváří plán pro každou skupinu vlastností, přiřazuje se ji vlastník (programátor zodpovědný za úspěšné ukončení) a stanoví se datum ukončení. Také se vytváří předběžné pořadí pro implementaci vlastností. 4. Návrh užitné vlastnosti (77 %). Poslední dvě fáze jsou iterativně opakované. Hlavní programátor vybírá vlastnost. Pak se spouští proces DBF (Design by Feature, návrh podle vlastnosti). To znamená, že se určí třídy, které vybranou vlastnost pokrývají a následně se kontaktují vlastníci daných tříd. Vlastníci tříd vytvoří dočasný tým, který vypracuje návrh pro implementaci vlastnosti. 5. Implementace užitné vlastnosti (77 %). Zahajuje se činnost BBF (Build by Feature, realizace podle vlastnosti). Vlastník třídy odpovídá za její návrh a implementaci. Vlastník realizuje metody, vytváří a provádí testy pro svoji třídu. Po dokončení testu se třída vkládá do sdíleného systému pro správu tříd. Když hlavní programátor bude spokojen s konečným výsledkem, vlastnost může být integrovaná do aplikace. [19] [1] Aspekty Pro metodiku FDD jsou charakteristické některé úplně nové a v ostatních metodikách nepoužívané principy. Jsou dostatečně nestandardní a mohly by být využité i v jiných vývojových procesech. Objektové modelování domén. Vytváří se diagram tříd pro znázornění významných objektů a jejich vztahů. Také se doporučuje vytvořit diagramy posloupnosti pro lepší ukázku způsobu komunikace objektů. FDD říká, že se má vytvořit jeden globální model, během jehož vytváření se vyjasní všechny nejednoznačné momenty. Vytváření objektového modelu pomáhá rozdělit projekt na menší části - objekty, což pomáhá efektivnějšímu návrhu a implementaci, jelikož zabývat se menší části je snadnější, než celým projektem najednou. Vývoj podle vlastnosti. Místo klasického vývoje podle modulu či funkce, FDD využívá vývoj podle vlastnosti. Pomáhá to kontrolovat plnění požadavků zákazníka. Při vývoji modulu se může stát, že se vývoj odchýlí od základní myšlenky, při vývoji podle vlastnosti se to stát nemá, protože FDD nabízí omezit funkční požadavky jenom na ty, které přináší hodnotu klientovi, ty se i stávají vlastnostmi. Když je definována množina potřebných vlastností, pak je jednoduché ověřit, zda systém splňuje všechny uživatelské požadavky. 24

32 Vlastnictví tříd. Každá třída má svého vlastníka, který by měl zaručit úspěšnou realizaci třídy. Určení vlastníka třídy pomáhá zachovat konceptuální integritu příslušného zdrojového kódu, vyznačit člena týmu, který bude o svojí třídě vědět všechno: jak funguje, jak v ní nejefektivněji něco aktualizovat, jak vypadá její zdrojový kód. Týmy sestavené podle vlastností. V metodice FDD existuje specifické sestavování dočasných týmů, které vznikají a zanikají dynamicky podle potřeb vývojového procesu. Každá třída má svého vlastníka, každá vlastnost má také svého vlastníka. Vzhledem k tomu, že implementace jedné vlastnosti zasahuje do více tříd, vlastník vlastnosti by měl řídit práci dalších vlastníků. Z důvodu těžkého vytváření takových jednotlivých statických týmů jsou v FDD týmy dynamické a jejich členové se mění podle aktuální potřeby. Další aspekty. Mezi ostatní aspekty FDD patří inspekce, což je využití různých technik pro detekci chyb; pravidelné vytváření rozvrhu pro lepší časový řád a plánování jednotlivých akcí; řízení konfigurací, mít přehled o celkové IT infrastruktuře pro včasné reagování na nefunkčnost některé že služeb. [1] Shrnutí Metodika Feature Driven Development je rozhodně zajímavým zástupcem agilních způsobů vývoje software. Daná metodika se snaží přistupovat trochu jinak k procesu vývoje. FDD nerozebírá konkrétní metody práce, volba metod je pouze na hlavním vývojáři. Rychlé iterace, dodávání fungujících částí a komunikace se zákazníkem pomáhá splnit všechny požadavky a dodat fungující software včas. Vývoj se může přizpůsobit měnícím se požadavkům klienta. [1] [19] 4.4. Test Driven Development Test Driven Development (TDD) se povazuje za metodiku, která klade velký důraz na testování a dělá ho nejdůležitějším krokem při vývoji. Ovšem není to úplně metodika, ale spíše jeden ze způsobů vývoje, který je často začleněn do jiných metodik. TDD spočívá v tom, že se pro všechny součásti systému píšou automatické testy tříd, funkcí, metod ještě před samotným vývojem, které se potom mohou spouštět dokola a testovat tu stejnou část systému. Vývoj probíhá tak, že se na začátku napíšou testy pro konkrétní funkcionalitu, dále se naimplementuje takové množství kódu, kolik 25

33 zvládne projít testem, pak následuje refaktorizace, což znamená, že se kód zefektivňuje bez změn funkčnosti. [21] Fáze vývoje 1. Napsání testu. První krok je vytvořit test, který selže, to znamená, že v tento moment test nebude moct proběhnout úspěšně. V podstatě takový test definuje požadavky na funkcionalitu. 2. Spuštění testu. Dále se spouští všechny testy a ujišťuje se, že nový test neprošel a selhal, protože žádný kód, který by mohl zajistit úspěch testu, ještě neexistuje. Tento krok je kontrola správného napsání testu, protože v případě, že testy projdou bez toho, že funkcionalita je implementována, bude to znamenat, že se někde stala chyba. 3. Psaní kódu. Přichází čas na psaní zdrojového kódu, implementace funkcionality. Pak se kontroluje, zda kód projde testem, který byl vytvořen před implementací. V daném kroku nejde o nejefektivnější kód, ale jenom o úspěšný průchod testem. 4. Testování. Následující krok je spouštění všech testů systému. Pokud testování selhalo, musíme upravit kód, pokud prošlo úspěšně, můžeme se přesunout do další fáze. 5. Refaktorizace. Je to poslední fáze, v které se upravuje zdrojový kód systému a testů. Odstraňují se duplicity a kód se upravuje do přehlednější podoby. Testy se přesunou do testovací knihovny a ověří se, že nebyla porušena integrita testu. Daných pět kroků se stále opakuje během celého vývoje softwaru. Cykly jsou krátké, typicky se počítají v minutách. Pokud se test či kód nedá napsat za stanovené minuty, doporučuje se zahodit takový test i kód a napsat jednodušší nový test i kód. Během vývoje je důležité kontrolovat konzistenci a logickou provázanost testů, protože každé přidání řádku kódu může ovlivnit nejenom aktuální test, ale i řadu dalších. [1] Testování Testování v TDD probíhá podle následujících principů (obrázek č. 6): 26

34 Obrázek 6. Testování v TDD 1. Na začátku je vstup do zeleného stavu, který znamená, že software je funkční a všechny testy prošly. 2. Pokud je systém hotový, následuje postup do další vývojové fáze, což je kompletní testování. V opačném případě se provede refaktorizace kódu či implementace nové funkcionality. Dále se zase provedou testy. Pokud testy prošly, je systém v zeleném stavu a může se vyvíjet další funkcionalita, to znamená, že se píše nový test. Pokud nastal červený stav, musí se opravit chyba ve zdrojovém kódu. 3. Po opravě kódu se zase spustí testy. 4. Pokud není potřeba vyvíjet další funkcionality a nenapadají nás žádné další testy, můžeme dokončit vývoj. [21] Shrnutí TDD dává možnost vyvíjet rychle a opravovat chyby hned, jak se objeví. Tím, že se testy píšou ještě před implementací, dá se vyhnout dlouhé a nepříjemné fázi hledání chyb. V TDD jsou chyby odchycené hned při průchodu testy. Test Driven Development se moc nezabývá tvorbou specifikací, dokumentací a dalších formálních záležitostí. Dané doplňky si může vývojový tým vybrat sám podle svých představ a potřeb projektu. Pomocí předem psaných testů se dobře regulují i změny požadavků během vývoje, stačí upravit či přepsat testy a kód. Systém se skládá z menších částí, proto se snadněji upravuje. Na druhou stranu je potřeba na daný přístup zvyknout a musí být kvalitní vedení projektu, protože pro programátory je neobvyklé zabývat se na začátku testy a pak samotným kódem systému. Také psaní testů pro všechny 27

35 součásti systému znamená to, že se zvyšuje objem kódu, v testech se také mohou objevovat chyby, výsledkem toho často bývá snížení produktivity na začátku vývoje. Avšak TDD slibuje, že při dodržování jeho principů se dá vyvíjet kvalitní software bez následného neočekávaného chování. Většinou se daný přístup používá ve spojení s jinými metodikami vývoje. [1] [21] 4.5. Scrum Poslední příklad agilní metodiky, která je uvedena v mojí diplomové práci je metodika Scrum. Vzhledem k tomu, že celá práce se zabývá adaptací Scrumu pro menší IT projekty, daná metodika bude podrobněji popsána v následující kapitole č Porovnání agilních metodik XP Lean FDD TDD Scrum Iterativní Standard kódování Velikost projektů S,M S,M,L S,M,L S,M,L S,M,L Konkrétní postup Testování Prototypování Základ kód štíhlost vlastnost testy daily scrum Tabulka 2. Agilní metodiky 28

36 5. Scrum V dané kapitole bude více do hloubky uvedena metodika agilního vývoje Scrum - vysvětlené pojmy spojené s ní, hlavní role, artefakty a podrobně popsáno, co je potřeba zavést ve firmě pro ovládání této konkrétní metodiky. Scrum, jako většina agilních metodik, využívá spojení inkrementálního a iterativního vývoje. Je odvozena od klasického spirálového modelu životního cyklu, představuje ale nový a odlišný přístup, který se snaží o lepší produktivitu a jednodušší přizpůsobení změnám v požadavcích. Metodika je založena na vývoji v přesně určených časových úsecích, jejichž délka je v rámci měsíců, a pravidelných setkáních týmu, která podporují komunikaci a umožňují zpětnou vazbu. [1] 5.1. Slovník Pro správné chápání metodiky Scrum je potřeba pochopit význam všech pojmů, které se používají při využití dané metodiky. Existují i české překlady, některé z nich jsou podle mě nedostatečně přesné a podle mých zkušeností z praxe se častěji používají anglické pojmy, proto ve svojí diplomové práci budu používat originální názvy, které jsou vysvětleny v následující tabulce: Acceptance criteria Kritéria, která definují, zda je User Story hotová. Backlog Grooming Pravidelné setkání, kde tým s Product Ownerem řeší priority a chápání User Story z Backlogu. Burndown chart Graf, který zobrazuje rychlost práce týmu v rámci jednoho Sprintu - úsilí ku času (Story Points ku dnům). Done criteria Obecná pravidla pro předání, která definují hotový prvek. Epic Větší funkční celek. Skládá se z více User Story. 29

37 Planning meeting Plánování následujícího Sprintu. Planning Poker Metoda pro odhadování náročnosti či velikosti User Story. Pre-planning Příprava na plánování, kde Product Owner určuje priority funkcionalit, z nichž se pak některé vybírají pro plánování dalšího sprintu. Product Backlog Seznam funkcionalit (User Story) seřazený podle priority Product Owner Vlastník vize produktu. Product Proxy Owner Pomocník Product Ownera, když není dostupný. Retrospective meeting Setkání, na němž se řeší, jak proběhl poslední Sprint, efektivita, případně změny. Review meeting Setkání na konci Sprintu, kde se prezentují výsledky. Scrum Master Moderátor týmu, stará se o spojení týmu a vnějšího světa. Udržuje průběh Sprintu. Scrum Table Zobrazuje stav aktuálního Sprintu. Sprint Fixně dlouhá iterace. Obvykle se doporučuje 14 dní. Sprint Backlog Vybraná funkcionalita (User Story) z Backlogu pro konkrétní Sprint. Standup Meeting/ Každodenní setkání týmu pro krátkou prezentaci aktuálního stavu. Daily (Meeting) Scrum 30

38 Story point Jednotka velikosti User Story. User Story Funkcionalita popsaná v určité formě. Jako <uživatel>, chci <funkcionalitu>, abych <dostal hodnotu >. Velocity Měří se pro konkrétní tým pro lepší příští odhad úsilí. Tabulka 3. Scrum slovník 5.2. Role Scrum Master Role Scrum Mastera není úplně standardní. Není to manažer ani klasický teamleader, není nadřízený, je to člen týmu, stejně jako ostatní. Scrum Master pracuje jako spojení mezi týmem a jakýmkoliv rušivým elementem zvenku. Totiž role Scrum mastera je chránit tým a vytvářet prostředí, kde by členy týmu nikdo neměl rušit, podporovat tým, odstraňovat problémy a pomáhat jeho efektivnější práci. Mezi povinnosti také patří dodržování Scrumu, jeho efektivita a fungování, podporování týmu a řešení konfliktu. Povinnosti Scrum Mastera by se neměly kombinovat s povinnostmi jiných rolí. Například vývojář či tester by neměl být Scrum Master z toho důvodu, že zaprvé by upřednostňovali svoji práci, zadruhé by byl konflikt v tom, že takový člen týmu by nemohl být zároveň i chráněn před vnějším vlivem i chránit sebe a ostatní před ním. Scrum Master by neměl být zároveň ani projektový manažer, ačkoliv ty role někomu přijdou podobné. Manažer má zpravidla direktivnější přístup a rozhoduje za tým, řídí ho. Takové míchání rolí by potlačilo význam přítomnosti Scrum Mastera. [18] Scrum Master má být vnímavý a komunikativní člověk, který bude schopen směřovat tým k úspěšnější a efektivnější práci, měl by být schopen i dopředu ošetřit některá nadcházející rizika. Povinnosti Scrum Mastera se mění v závislosti na zkušenostech a schopnostech týmu, jednotlivých členů a jejich způsobu práce a komunikace. [22][23] Product Owner Další specifická role pro Scrum je Product Owner. Je to vlastník produktu. Product Owner má určovat priority, rozhoduje o tom, na čem se bude dál pracovat, má na starosti vizi projektu. Také odpovídá za Backlog a pracuje na něm s Product 31

39 Teamem, do něhož mohou patřit například zástupce zákazníka a uživatelů či softwarový architekt. Product Owner by měl být týmu pravidelně k dispozici, ale na rozdíl od Scrum Mastera se nemusí starat o potřeby týmu a neustále s ním komunikovat. Mezi povinnosti dané role patří i trávení více času se zákazníky pro lepší porozumění jejich potřebám, protože primárním cílem Product Ownera je chápat produkt, vědět, jak má fungovat. Product Owner neřídí tým a nerozkazuje, jenom definuje priority. [22] V tom případě, že Product Owner nemůže být stále k dispozici, zavádí se role Product Owner Proxy. Je to člověk, který by měl zastoupit Product Ownera, moct odpovědět na všechny otázky vznikající u týmu, rozhodovat a nést zodpovědnost za svoje rozhodnutí. Jestli povinnosti Product Owner Proxy jsou na plný úvazek nebo ne, záleží jenom na určitém případě - projektu, firmě, časovém vytížení vlastníka produktů. Není to nutná role pro Scrum, ale hodí se v případě časté nepřítomnosti Product Ownera. [18][23] Scrum tým Důležitá vlastnost právě Scrum týmu je to, že má být sebedisciplinovaný. Týmová spolupráce je velice důležitá pro agilní vývoj. Vzhledem k odlišnosti produktů vědí členové týmu často lépe, jak organizovat vývojový proces. Proto ve Scrumu může tým ovlivňovat to, jak pracují, podílet se na tvorbě a úpravách Backlogu. Ve Scrumu se tým bere jako nedělitelný celek, proto nezáleží na selhání jednoho člena, vždy za to odpovídají všichni. Proto je důležité, aby si všichni v týmu uvědomovali, že mají společný cíl a musí si navzájem pomáhat. Ve Scrum týmu nejde jenom o disciplínu, ale i o multifunkčnost. Členové týmu by měli umět pomoct kolegovi, nebo jej ideálně v případě potřeby i nahradit. Správný Scrum tým pracuje na User Story spolu od začátku. Například analytik se zabývá tím, jak se funkcionalita bude chovat a pomáhá vývojáři s její implementací, mezi tím tester může identifikovat chybové scénáře. Výhodou je to, že při takové organizaci práce se nestává, že by někdo z členů týmu neměl práci a vzniká méně problémů v oblasti komunikace a chápání cizích myšlenek. [18] Scrum tým by měl sedět v jedné místnosti pro lepší komunikaci, sdílení zkušeností a případnou pomoc. Tým musí zahrnovat Scrum Mastera, který pomůže vývojovému procesu a komunikaci týmu s vnějším světem a Product Ownera, který ví vše o produktu a určuje směr a priority ve vývoji, ale nemusí sedět ve stejné místnosti se zbývajícím týmem.[23] 32

40 Zákazník Stálá komunikace se zákazníkem je základ většiny agilních metodik. Scrum není výjimkou. Pokud chceme, aby byl zákazník spokojený s konečným produktem, musíme mu dávat možnost se vyjádřit už v průběhu vývoje. Je dobré ukázat klientovi Backlog, User Story, vysvětlit, co je Burndown Chart. Scrum se obvykle řídí pomocí nějakého softwaru, takže pokud zákazník bude mít přístup k němu, vždy se bude moct podívat, jaký je posun ve vývoji. Také je pozitivní to, že vývoj probíhá v iteracích a zákazník může být seznámen s výsledkem každé iterace na Review Meetingu. [18] Pomáhá i to, když je zákazník seznámen s týmem, který se stará o jeho zakázku. Pokud se lidé znají naživo, pak si lépe rozumí a více se tolerují požadavky a chyby. Pro vývojáře je důležité dostávat zpětnou vazbu od zákazníka a pomocí ní se mu snažit dodat přesně to, co potřebuje. Manažer Ve Scrumu nepotřebuje tým člověka, co každý den určuje, co a jak se bude dělat a následně kontroluje odvedenou práci. Pro řešení každodenních problémů má tým Scrum Mastera. Avšak role manažera také není zbytečná. Role manažera ve Scrumu se posouvá spíše ke strategickým rozhodnutím. Manažer se může starat o právní záležitosti, hlídat důležité termíny, odpovídat za rozpočet. Ve Scrumu by neměl manažer výrazně zasahovat do organizace každodenních činností a spíše pozorovat a popřípadě upozorňovat tým na důležité termíny či aspekty. [18] 5.3. Artefakty Sprint Agilní metodiky se zakládají na iterativním vývoji. Scrum má svojí pojmenovanou iteraci Sprint. Je to fixní časový úsek, k jehož konci tým dodává hotovou funkcionalitu, která se prezentuje zákazníkovi. Délka Sprintu záleží na projektu. Má být dostatečně velká na to, aby se dala naimplementovat nová funkcionalita, ale i dostatečně krátká na to, aby se pravidelně dodávala zpětná vazba. Obvykle je to 1-4 týdny, 14 dní je průměr. Pokud se nedaří během Sprintu dodělat všechna User Story, neznamená to, že by se Sprint měl prodloužit. Je lepší při plánování příštího Sprintu snížit množství User Story, nebo 33

41 jejich složitost, nebo zapracovat na spolupráci v týmu. Délka Sprintu má být konstantní. Obsah Sprintu by se neměl měnit v jeho průběhu. Pokud nastane situace, v níž bude potřeba změnit obsah Sprintu, musí se Sprint zrušit a následně se vytvořit nový a znovu se naplánovat. V případě, že se objeví nějaká funkcionalita, která bude poměrně důležitá v okamžitý moment, dá se domluvit s Product Ownerem, případně i se zákazníkem o tom, že bude implementována v dalším sprintu. Proto se doporučuje zodpovědně a přesně plánovat každý Sprint, následující problémy se změnami by nebylo jednoduché vyřešit. [23] Product Backlog Pro každý projekt je důležité určit požadavky a mít je někde uspořádané a zapsané. Pro Scrum je to Product Backlog. Do Product Backlogu se přidávají všechny funkcionality, které je potřeba mít u produktu. Každá položka Backlogu odpovídá jedné funkcionalitě. Produktový backlog je seznam všech vlastností, funkcí, požadavků, rozšíření a oprav chyb, které představují všechny změny, které budou provedeny v produktu v příštích vydáních. Položky produktového backlogu mají popis, prioritu a odhad. [23] Na začátku projektu má Product Backlog jenom to nejdůležitější, funkcionality, které jsou jasně požadované pro konkrétní produkt. Během vývoje se Product Backlog rozrůstá, začíná být konkrétnější a podrobnější. Product Backlog znázorňuje průběh celého projektu, ukazuje, co už je hotové, na čem se bude příště pracovat, co je přidáno nedávno. Vzhledem k seřazení User Story podle priority musí být funkcionality, které mají nejvyšší prioritu, detailně propracované, ty, co mají nízkou, mohou obsahovat jenom to nejdůležitější pro jejich pochopení. Také je v dobrém Backlogu u všech User Story přiřazena jejich složitost, kterou určuje Product Owner spolu s týmem. Pro bezproblémové zvládání Scrumu by mělo být v Product Backlogu kvalitně popsáno a vypracováno User Story na 2-3 Sprinty dopředu a celkově dostatečně rozepsáno ještě na dalších 5-10 Sprintů. O Product Backlog se stará Product Owner, avšak vývojový tým se mu snaží pomáhat. Péče o Backlog je dynamický proces, během kterého se stále zpřesňují jednotlivé User Story, provádí se odhady nových funkcionalit, vytváří se detailní popis, přezkoumávají se a revidují se už existující funkcionality. Product Backlog existuje a vyvíjí se, dokud se pracuje na produktu. Jeho pravidelná údržba zjednodušuje plánování a pomáhá dobře chápat, v jakém stadiu se nachází projekt a kam směřuje jeho vývoj. [18] [23] 34

42 Sprint Backlog Sprint Backlog je podmnožinou aktuálních User Story vybraných z Product Backlogu. Sprint Backlog ukazuje, na čem se bude pracovat v daném Sprintu, co bude hotovo k jeho konci, jaká funkcionalita bude dodána zákazníkovi. Sprint Backlog se vybírá na základě priorit na začátku Sprintu. O Sprint Backlog se stará jenom vývojový tým. Může do něho přidat konkrétní úkoly pro každé User Story, znázorňovat na čem se aktuálně pracuje a zaznamenává, kolik času bylo stráveno na každém úkolu. Sprint Backlog jasně znázorňuje aktuální práci a stav Sprintu. [18] User Story Po konzultaci se zákazníkem či Product Ownerem dělí tým práci na jednotlivé funkcionality, které se ve Scrumu nazývají User Story. Takové User Story popisují funkcionalitu, kterou chceme přidat či aktualizovat. User Story je vždy ohodnoceno podle své náročnosti určitými Story Points a má následující tvar: Jako <uživatel>, chci <funkcionalitu>, abych <dostal hodnotu >. Příklad: Jako návštěvník knihovny, chci půjčit knihu, abych si ji mohl přečíst doma. Daný popis je vždy pochopitelný pro tým a zákazníka. User Story je zaměřeno na obchodní hodnotu, popisuje to, co od něho očekáváme, ne seznam technických požadavků. User Story má také splňovat kritéria INVEST: Independent (Nezávislé). Jedno User Story musí být nezávislé na ostatních. Pokud jsou User Story závislé na sobě, vznikají potíže s plánováním, určováním priorit a celkovým odhadem. Základem je rozdělit celý projekt na jednotlivé funkcionality, které jsou na sobě nezávislé. Na začátku se může zdát, že to není možné, ale chce to praxi pro lepší ovládání takové metodiky práce. Negotiable (Vysvětlitelné). Product Owner by měl rychle a jednoduše popsat přínos a funkčnost User Story, aby vývojový tým mohl ohodnotit její složitost. Nemusí se sepisovat celé dokumenty požadavků, vysvětlení musí být výstižné a jasné, aby tým mohl zcela chápat požadavky zákazníka a dodávat kvalitní řešení. Valuable (Mít hodnotu). Každé User Story musí mít hodnotu pro zákazníka. Pokud není hodnota, není to User Story. Pro vývojáře je důležité chápat, proč danou hodnotu implementuje, pro zákazníka vidět, že po každé iteraci je systém kompletnější. 35

43 Estimable (Ohodnotitelné). Vývojový tým by měl být schopen ohodnotit každé User Story pro správnou prioritizaci a plánování. Pro dobré ohodnocení musí tým rozumět každé funkcionalitě a umět odhadnout, kolik práce bude vyžadovat. Small (Malé). User Story by měla být malá. Taková aby se dala dokončit do poloviny Sprintu. Jinak ji je potřeba rozdělit na více funkcionalit. Testable (Otestovatelné). User Story musí být otestovatelná. Jinak se nedá pochopit, zda je hotová. [24] Všechna kritéria jsou úzce spojena. Dobře napsané User Story musí být nezávislé na ostatních funkcionalitách, být pochopitelné, přinášet hodnotu pro klienta, být srozumitelné pro tým a ohodnocené, dostatečně malé, aby se dalo realizovat během Sprintu a otestovatelné. Na začátku může být těžké odpovídat všem požadavkům, ale časem se to nacvičí a vytváření a popisování User Story začne být intuitivní. Dále se v popisu User Story uvádí Acceptance Criteria. Je to seznam podmínek, které musí být splněné pro to, aby User Story bylo dokončeno. Acceptance criteria řeší tým a Product Owner nejpozději během plánování Sprintu. Jsou důležitá pro přesné pochopení, co všechno musí být realizováno, aby se User Story mohlo považovat za dokončené. Doporučuje se psát Acceptance Criteria formou otázek a stručně. Pokud je kritérií příliš hodně, User Story by se měla rozdělit na menší funkcionality. Existují také Done Criteria, která popisují dokončení User Story z globálního hlediska. Zpravidla jsou určena pro celý projekt, pro všechna User Story. Například to může být: pro každou funkcionalitu musí být napsané testy a uživatelská dokumentace, testy úspěšně prošly, produkt běží na testovacím prostředí. [25] Epic Když zákazník zadává projekt a začínají se definovat požadavky, často je potřeba začít z rozdělení projektu na větší oblasti. Takové části projektu se nazývají Epic. Ony drží pohromadě jednotlivá User Story provázané globálním kontextem. Epic se nedá naplánovat do Sprintu, ani ohodnotit, ale pomáhají udržovat obecnou představu a lépe se orientovat v celém projektu. [18] Planning Poker Ve Scrumu je důležitou součástí vytváření User Story odhadování jeho náročnosti. Pro jednodušší rozhodování se často používá technika Planning Poker, která spočívá v tom, že tým má kartičky s bodovým ohodnocením a vybírá ty, které se mu zdají 36

44 správné. Nejčastěji se používá Fibonacciho posloupnost 0,1,3,5,8,13... Členové týmu vybírají kartičky odpovídající jejich představám složitosti a pak je zároveň ukazují. Lidé, kteří mají nejvyšší a nejnižší ohodnocení musí obhájit své rozhodnutí. Pak se hlasuje zas. Nejde o kompromis, ale o domluvu mezi ostatními členy týmu. Pomocí komunikace a sdílení názorů je potřeba dosáhnout shody na určitém množství bodů. Jako i s dalšími technikami Scrumu to na začátku může být velice těžké a zabírat spoustu času, avšak časem si všichni zvyknou a naučí se to dělat produktivně. [18] Velocity Na konci každého Sprintu se sečtou body hotových User Story. Tento součet je rychlost. U dobře fungujících týmu je rychlost více méně konstantní a předvídatelná, což dělá plánování dalších Sprintů poměrně jednoduché. Pokud se rychlost u Sprintu stále mění, doporučuje se pro příští sprint spočítat průměrnou rychlost několika posledních Sprintů. Na začátku může být problematické správně odhadnout, kolik Story Points zvládne tým dostat za jeden Sprint, proto se doporučuje u prvních sprintů dávat trochu menší množství bodů, než je očekávané. Zaprvé je větší pravděpodobnost, že všechno bude ke konci Sprintu splněno, zadruhé to bude více motivovat tým, než zbylé nedokončené User Story při pozitivnějším odhadu Ovládání Scrumu Znalost všech pojmů Scrumu nezaručuje jeho správné využití. Také je potřeba vědět, jak probíhá celý proces vývoje pomocí dané metodiky. Jak už bylo uvedeno výše, Scrum je iterativní vývoj a skládá se z jednotlivých Sprintů. Po každém Sprintu musí být zákazníkovi prezentován nový inkrement, zahrnující hotové funkcionality přinášející určitou hodnotu. Na začátku celého projektu by měl Product Owner se zákazníkem a vývojovým týmem vypracovat Product Backlog. Nemusí v něm být vše, co se bude vyvíjet během celého projektu, ale měly by být sepsané User Story pro nejbližší plánované Sprinty a být seřazené podle priority. Potom se všechny User Story přidělí k určitým Epicům. Dále se může začít pracovat na první iteraci. Sprint má následující plán (obrázek č. 7): Pre-planning Planning meeting 37

45 Daily Scrum Backlog Grooming Review meeting Retrospective meeting Obrázek 7. Scrum. [26] Pre-planning Cílem Pre-planningu je vybrat z Product Backlogu User Story na základě priorit, aby následně vývojový tým mohl vybrat, která User Story se budou vyvíjet v následujícím Sprintu. Pre-planning se provádí obvykle pár dní před samotným plánováním následujícího Sprintu. Tím pádem má tým možnost popřemýšlet nad tím, co chce vyvíjet v dalším cyklu. Pre-planning je záležitost Product Ownera. Může vybírat User Story na základě toho, že Backlog je stále seřazen podle priorit nebo zavolat lidi, kteří mají zájem o následující iteraci, například zákazníka či analytika. Dále se rozhoduje, na čem by se mohlo 38

46 pracovat příští Sprint a pak se daná nabídka User Story předává vývojovému týmu pro detailnější zamyšlení. [18] Planning Plánování by mělo začít představením vybraných User Story na Pre-planningu. Jak už bylo uvedeno, je vhodné dodat vybraná User Story vývojovému týmu pár dní před samotným plánováním. Pokud tým dostává možnost vybírat, co chce dělat, cítí za to větší zodpovědnost a prokazuje lepší výsledky, ale není potřeba mu dávat úplnou svobodu, protože může dojít k zanedbání priorit projektu. Během plánování by měl Scrum Master pomáhat vývojářům s plánováním a chápáním User Story. Je důležité upozorňovat tým na to, jestli zvládnou dokončit všechno, co vybírají a jestli všemu rozumí. Tým by měl vybírat User Story do Sprint Backlogu postupně, jedno po druhém. Po dokončení naplňování Sprint Backlogu by měl tým prodiskutovat aktuální stav a ujistit se v tom, že všechno naplánované zvládne splnit během Sprintu. V případě nejistoty by se mělo plánování přehodnotit. Následně se každé User Story rozdělí na menší úkoly. [23] Pro dvoutýdenní Sprint je průměrná délka Planningu 30 minut až 1 hodina. Pokud se během Planningu řeší nová funkcionalita, tak spíš plánování zabere několik hodin. V prvních Sprintech se může stát, že plánování nebude úplně odpovídat výsledkům, avšak je to dobré poučení pro příště. Daily Scrum Daily Scrum, Scrum Meeting či Standup Meeting, to je všechno název pro známou praktiku ve Scrumu, která spočívá v tom, že se tým setká každý den pro rychlou prezentaci své práce. Většinou se Daily Scrum uspořádává ráno, před tím, než každý začne pracovat na svých úkolech, pro lepší motivaci a dobrý přehled. Standup Meeting se to nazývá proto, že se doporučuje toto setkání provádět ve stoje u tabule, kde každý člen týmu odpoví na otázky: co jsem stihl udělat za včera, co se chystám udělat dnes, jestli nejsou žádné problémy (jestli se všechno stíhá)? 39

47 Takové každodenní setkání je moderováno Scrum Masterem. Product Owner, manažer či další zájemci se mohou také zúčastnit Scrum Meetingu, ale jenom v roli pozorovatele, protože nemohou zasahovat do tohoto procesu. Normální délka Daily Scrumu je minut. Nemělo by se všechno probírat moc dopodrobna nebo technicky do hloubky. Stačí udělat přehled o tom, jak jde Sprint. Taková každodenní setkání mají dobrý motivační vliv na celý tým, protože když člen týmu ráno řekne, že dnes dodělá nějaký úkol, cítí zodpovědnost a snaží se dodržet svůj slib. Daily Scrum posiluje týmové vztahy a zlepšuje komunikaci. Například po vyskytnutí problému u jednoho člena týmu mu může nabídnout pomoc druhý, kterému se v daném Sprintu daří zvládat úkoly rychleji. [18] [23] Backlog Grooming Pro tým bývá náročné stále udržovat dobrou představu o stavu Product Backlogu ve složitých projektech. Proto existuje ještě jeden typ setkání, který se nazývá Backlog Grooming. Obvykle se plánuje v první polovině Sprintu, nebo i párkrát během Sprintu. Před začátkem musí být prioritizovaný Product Backlog. Během Backlog Groomingu Product Owner spolu s týmem postupně prochází Backlog po jednotlivých User Story a probírá, co znamená každá funkcionalita, vzpomíná na staré User Story, seznamuje se a ohodnocuje nové User Story. [18] Review Meeting Před začátkem Sprintu se konzultuje se zákazníkem, co on chce, aby bylo uděláno v následujícím Sprintu. Po dokončení Sprintu se musí ukázat zákazníkovi, jaké výsledky byly dosaženy. Zákazníkem může být kdokoliv, kdo má zájem o daný projekt. Čím víc lidí ohodnotí odvedenou práci, tím lepší bude zpětná vazba, která pomůže zdokonalit systém. Na začátku Review Meetingu může Product Owner uvést obecný popis Sprintu. Dále by měl prezentovat jednotlivá User Story vývojový tým. Když má tým možnost prezentovat takovým způsobem výsledky své práce, zvětšuje to v něm motivaci a zodpovědnost za svoje úkoly. Zákazníkovi se ukazují jenom hotové User Story, u kterých jsou splněna Accaptance Criteria, jsou otestované a zdokumentované. 40

48 Na konci setkání by se měly zrekapitulovat výsledky Sprintu - kolik bylo naplánováno User Story, kolik z nich bylo dokončeno, kolik se stihlo navíc, kolik nestihlo. Dále by bylo vhodné uvést představu o tom, co se bude dít v následujícím Sprintu. [18] [23] Retrospective Meeting Retrospektiva se provádí pro zlepšení pracovních procesů, spolupráce a porozumění v týmu, zavádění nových věcí. Obvykle se Retrospective meeting provádí po Sprint Review, pokud ještě všichni pamatují, jak probíhala práce v posledním Sprintu. Restrospective Meeting se skládá z několika částí: 1. Sběr informací. Každý člen týmu se může vyjádřit ohledně toho, co se mu líbí/nelíbí, co by zavedl nového. 2. Porozumění informacím a návrh řešení. Pokud existuje problém, musí se pochopit a upřesnit a najít důvod, proč vznikl. Pokud se neřeší takové problémy, časem se sníží motivace pracovníků a klesne i efektivita. Podílet se na hledání řešení by mohl každý člen týmu. Následně by se to mohlo prodiskutovat. 3. Závěr. Shrnutí informací, které se probíraly během setkání. Potvrzení konkrétních činností, které budou aplikované na pracovní proces a pomohou vyřešit stávající problémy a konflikty. Je důležité dodržovat v budoucnu odsouhlasená řešení, protože jinak se smysl Retrospective Meetingu ztrácí. Často se retrospektiva zanedbává během práce. Vznikají problémy a konflikty, tým je neřeší a všechno to vede k horším výsledkům. Na začátku práce na projektu bývá hodně nejasných, nepropracovaných záležitostí, avšak právě Retrospective Meeting dává možnost zlepšit všechny aspekty. Časem, když se tým domluví na většině věcí, práce bude příjemnější a zpětná vazba výrazně méně obsáhlá než na začátku. [18] 41

49 6. Výhody a nedostatky metodiky Scrum Kapitola č. 6 se bude věnovat posuzování metodiky Scrum z různých hledisek, popíše její výhody a nedostatky. Pokud je jasné, v čem spočívají slabé a silné stránky dané agilní metodiky, pomůže to co nejvýhodněji nasadit a upravit Scrum vyhovující malým IT projektům Výhody Scrumu První a nejvýznamnější výhodou metodiky Scrum je schopnost rychle reagovat na změny v průběhu projektu. Scrum se může přizpůsobit změně požadavků zákazníka, přidat nový prvek či funkcionalitu, rozhodnout se pro jiné řešení, nebo se vypořádat s novým rizikem. Průběh projektu je velice pružný. Na začátku se většinou vývojový tým a zákazníci domluví jenom na obecných rysech výchozího produktu a jeho hlavní funkcionalitě, dále s postupným vývojem přichází nové požadavky a nápady, které se navazují na už existující strukturu. Takový inkrementální způsob vývoje dává projektu možnost rychle reagovat na změny, případně nové požadavky či nápady na zvýšení efektivity vývoje. [1] Vzhledem k uspořádání rolí ve Scrumu a průběhu Sprintu dostávají vývojáři určitou svobodu. Projektový manažer se může s týmem domluvit na aktuálních potřebách projektu a nasměrovat je určitým způsobem, ale v rámci Sprintu jenom tým rozhoduje, jak bude přistupovat k práci. Všechno to dává možnost vývojářům realizovat svoje nápady, změnit přístup, zvýšit efektivitu. Každý člen týmu cítí zodpovědnost a to, že on je ten, kdo se rozhoduje, čímž se zpevňuje jeho vztah vůči projektu a motivace nejenom k úspěšnému, ale i ke kvalitativně nadstandardnímu dokončení. Menší množství členů týmu (charakteristické pro Scrum 7+/-2, včetně Scrum Mastera a Product Ownera) zlepšuje komunikaci, podporuje vzájemnou pomoc a pomáhá sdílet znalosti jednotlivých členů s celým týmem. [1] Další výhodou Scrumu je přesně daný postup ve vedení projektu. Projekt je rozdělen na časově omezené úseky, během nichž musí tým dodat domluvenou funkcionalitu. Každý Sprint má stejný plán: plánování, vývoj, každodenní schůzky, závěr, retrospektiva. Myslím, že takový postup pomáhá udržovat volnější přístup k vývoji v určitých hranicích a efektivně je spojovat dohromady. Zavedení retrospektivy má pozitivní vliv na porozumění v týmu, zlepšení pracovního prostředí, zvýšení efektivity vývoje a to všechno vede k vyšší produktivitě. Všichni říkají, že zpětná vazba je velice důležitá, ale ne každá metodika ji zařazuje do procesu. 42

50 Scrum to povinně dělá a nutí na tom lidi pracovat, což následně dává jenom lepší výsledky Nedostatky Scrumu Scrum je spíše metodika vedení projektů, než posloupnost kroků vedoucích k vývoji kvalitního softwaru. Není určena žádná technická specifikace kroků a proto nasazení Scrumu v nové firmě, která ještě nemá svůj přístup k vývoji, může být náročné. Na druhou stranu, pokud je takový přístup vypracovaný, nasadit Scrum a využít jeho výhod může být pro firmu jenom prospěšnější. [1] Druhý problém spočívá v tom, že Scrum předpokládá, že každý člověk v týmu je zodpovědný, aktivní, komunikativní, spolehlivý. Avšak může být problém najít takové lidí do týmu a zajistit, že budou stejní v praxi i v budoucnu. Je důležité, aby si každý člen týmu uvědomoval svoji roli a respektoval role ostatních. Když vývojáři dostávají určitou svobodu rozhodování, může se to proměnit ve znevažování role projektového manažera a Scrum Mastera, protože si budou myslet, že je nepotřebují a vědí sami, jak všechno udělat nejlíp. Je potřeba, aby se lidé přizpůsobili Scrum metodice, chápali ji a akceptovali jako účinnou. Ve Scrumu se skoro nedají vyřešit změny, které mohou nastat během Sprintu. Je jasné, že to bylo vymyšleno pro zlepšení efektivity a lepší plánování, avšak na složitých projektech, kde se často komunikuje s externími dodavateli, to může být problém. Například dodavatel slíbí, že zajistí dodání služby na začátku příštího Sprintu, ale nevyjde to a pak má tým na práci jenom pár drobností a nemůže dokončit potřebnou funkcionalitu. Dá se říct, že v takový moment se má Sprint zrušit a přeplánovat, ale co když dodavatel neřekne, kdy přesně dodá službu. Vždy během projektu může nastat neurčitý moment, když něco půjde udělat, až se stane něco jiného, ale žádné konkrétní termíny u toho nebudou. A v případě využití externích služeb to může nastávat stále. Některé firmy zavádí svůj určitý způsob, jak se s tím vypořádat a definují možné změny v rámci Sprintu i když je to proti pravidlům. Nejdůležitější je stále dokončit projekt a nepokazit efektivitu. Výhoda toho, že se Scrum jednoduše přizpůsobuje změnám, může být i zápornou stránkou. Projekt roste, zvětšuje se, vznikají nové požadavky, zákazník chce více. Časem mohou vzniknout problémy s tím, že rozpočet už se zvýšil víc, než horní povolená hranice a čas spolu s ním. Scrum navrhuje každý Sprint dodávat určitou funkcionalitu zákazníkovi. Avšak nepočítá s laděním, neříká, že pro hledání chyb a jejich opravu je také potřeba rezervovat čas. Je to ještě složitější. Stěží se dá říct, kolik času takové ladění zabere. 43

51 Může to být hotové hned, může zabrat den. Z mých zkušeností, jednou před vydáním, probíhalo ladění chyb dva Sprinty po sobě. Každý nový tým a firma určitě najde v metodice Scrum svoje nedostatky a problémy. Ale myslím si, že teorie Scrumu nemusí být jako určitý konkrétní nástroj, který zabrání všem životním potížím vznikajícím během řízení projektu a vývoji softwaru. Ideální Scrum se dá použít jenom na stabilních malých projektech. Pro každý jiný je potřeba nechat základ a principy Scrumu a adaptovat ho přesně podle potřeb týmu, firmy či projektu. Jak to udělat lépe, může vědět jenom člověk, který s tím bezprostředně pracuje. 44

52 7. Scrum pro malé IT projekty. Praktickou částí mé diplomové práce je přizpůsobit Scrum malým IT projektům a navrhnout nástroj na jeho ovládání. Firma, v níž jsem měla stáž během Interim Project, se zabývala malými a středními IT projekty a používala výhradně metodiku Scrum. Během praxe jsem pozorovala, jak funguje Scrum a jaké problémy vznikají, pokud nebyla provedena vhodná adaptace. Na základě toho jsem se snažila navrhnout možná řešení problémů pro lepší fungování Scrumu ve firmě. Na základě znalostí pravidel metodiky, znalostí z praxe, přehledu specifik malých IT projektů, posouzených výhod a nedostatků Scrumu se dá vytvořit seznam změn v dané metodice vyhovujících právě malým IT projektům, popsat adaptaci Scrumu pro takové projekty a navrhnout nástroj, který bude postačující a zároveň jednoduchý na ovládání Scrumu Změny ve Scrumu pro malé IT projekty: Délka Sprintů u malých IT projektů nemusí být moc velká. Stačí jeden až dva týdny, tolik za kolik vývojáři zvládnou dodat funkcionalitu a zároveň bude vyhovovat týmu, vedení a zákazníkům. Meetingy by měly zabírat méně času, protože tým je menší, domluva je rychlejší, tím pádem má tým více času na práci a z toho plyne i kratší délka Sprintů. Daily Scrum se nemusí provádět každý den, ale třeba jednou za dva dny nebo rovnoměrně párkrát za týden (například pondělí středa pátek). V menším týmu je lepší přehled o tom, co se aktuálně děje a stejný úkol může trvat několik dní, takže není potřeba tak často kontrolovat práci týmu. Na ovládání řízení metodikou Scrum stačí fyzická tabule a záznam důležitých informací o projektu nebo jednoduchý, ale postačující nástroj umožňující plné ovládání. Není potřeba platit více za funkcionalitu, která nakonec stejně nebude použita. Scrum Master nemusí být samostatná role. Může ji částečně plnit analytik, může to být Scrum Master, který je součástí více týmů. V případě úplně malého týmu může být Scrum Master jeden z vývojářů, což není úplně žádoucí, ale občas není na výběr. Role Scrum Mastera a Product Ownera či projektového manažera by se neměly míchat. 45

53 Množství členů týmu není velké, ale všichni by se měli vzájemně nahrazovat a vědět o práci ostatních členů týmu dostatečně, aby zvládali i jejich práci v případě potřeby. Na menších projektech není potřeba, aby každý člen týmu byl jenom odborníkem ve své úzké oblasti, spíš se hodí lidé, kteří se vyznají dostatečně ve všem. Funkcionalita malých projektů není tak náročná, jak u velkých, což znamená, že vzájemná zastupitelnost členů týmu je důležitější, než dokonalé znalosti jedince v jedné oblasti. Popis User Story u malých projektů nemusí být tak podrobný jak u velkých a náročných, protože si tým většinou pamatuje funkcionality a dostatečně dobře se vyzná v Backlogu. V tomto případě to bude také šetřit čas, protože nebude potřeba se věnovat důkladnému popisování User Story. Je třeba počítat s testováním a laděním. Scrum se docela problematicky vyrovnává s danými aktivitami, avšak mohou se zadávat jako User Story do Backlogu s přibližným očekávaným časem. Na malých projektech se ladění zanedbává ještě častěji než na větších, protože funkcionalita připadá jednodušší a proto mají vývojáři větší jistotu v tom, že všechno udělali správně a bez chyb. Pro malé projekty by se dalo využít možnosti toho, že požadovaný systém byl během analýzy navržený v UML jako Use case diagram a místo složitého rozdělení projektu na User Story označit jednoduše každý Use Case jako User Story, popřípadě u složitějších projektů jako Epics a rozdělit na další jednodušší případy užití, které by mohly odpovídat velikosti User Story. Díky tomu, že projekt je malý a zabírá méně času a úsilí, dalo by se nechat veškerou dokumentaci týkající se projektu až na konec Adaptace metodiky Scrum pro malé IT projekty Následující podkapitola se bude věnovat adaptaci Scrumu pro malé IT projekty s výše uvedenými změnami. Bude popsáno, jak zařadit dané změny do standardního Scrum procesu a tím zvýšit efektivitu vývoje a snížit náklady na malé projekty Plánování projektu Charakteristickou věcí pro malé IT projekty je jejich nižší náročnost, menší čas a rozpočet. Proto je důležité umět se tomu přizpůsobit. Když firma dostává zakázku, musí upřesnit hlavní požadavky, pochopit, co přesně chce zákazník a domluvit se 46

54 na stylu spolupráce. Před začátkem projektu se musí projektový manažer rozhodnout, jak bude celý projekt probíhat, jak se upraví metodika pro konkrétní projekt, sestaví se tým, seznámí se se zakázkou a domluví se na postupu vývoje, který vyhovuje všem. Scrum tým Scrum tým se skládá z Product Ownera, Scrum Mastera a ostatních vývojářů. Product Owner je samostatná role, kterou nemůže plnit žádný jiný člen týmu, avšak nejčastěji je to projektový manažer, proto hraje ve firmě více rolí a odpovídá i za více projektů. Častý problém je role Scrum Mastera. Dokonce se stává, že v některých firmách, které praktikují Scrum, se úplně zanedbává. Ke všem změnám, které se dají doporučit ve Scrumu pro malé IT projekty rozhodně nepatří odstranění role Scrum Mastera. Vede to ke ztrátě izolace týmu. Tím pádem musí tým stále komunikovat s projektovým manažerem a celá myšlenka Scrumu o zodpovědnosti a samostatnosti vývojářů mizí. Ale je jasné, proč se na malých IT projektech zanedbává role Scrum Mastera. Pokud je projekt malý, role Scrum Mastera není na plný úvazek. Tento problém má několik řešení. V případě, že je firma větší, mohou mít různé týmy jednoho Scrum Mastera. Největší problém ale je, pokud je firma také malá. Četla jsem doporučení, že by malá firma mohla vzít Scrum Mastera na částečný úvazek, ale myslím si, že to není dobré řešení. Často se stává, že Scrum Master musí být přístupný týmu stále, protože nikdy není jisté, kdy vzniknou problémy. Pokud má ale Scrum Master částečný úvazek a není v práci v ten moment, když nastává problém, nutí to tým komunikovat například s Product Ownerem pro vyřešení situace, což porušuje principy Scrumu a časem jde tým místo komunikace se Scrum Masterem rovnou za Product Ownerem, protože je to jednodušší a ten je stále k dispozici. Proto bych doporučila v málem týmu vybrat na roli Scrum Mastera vývojáře, který pracuje na plný úvazek. V ideálním případě by to byl například softwarový analytik, ale může to být i programátor, který bude vykonávat dvě role zároveň. Je to složité, ale každopádně lepší, než nemít Scrum Mastera vůbec. Scrum tým má 7 +/- 2 lidí. To znamená, že pokud odečteme Product Ownera a Scrum Mastera zůstává nám 5+/-2 vývojářů. Na málem projektu se toto množství bude blížit k dolní hranici. Není to hodně, proto je v takové situaci vzájemná zastupitelnost členů týmu požadovaná ještě více, než na jiných projektech. Protože jestli jsou v týmu 3 vývojáři a jeden, který umí potřebnou technologií, onemocní, zastaví se celá práce, což nepovede k dobrým výsledkům. Pro dobré fungování Scrumu je velice důležité, aby tým chápal princip fungování metodiky. Každý člen týmu musí rozumět svojí roli a respektovat role ostatních členů, musí znát hranice své zodpovědnosti a svých možností. Lidé, kteří dřív nepracovali ve Scrumu, zapomínají na jeho hlavní principy. Vývojáři se snaží vyhýbat rutině jako 47

55 je popisování User Story, povídání o tom, jakou práci odvedli a retrospektivním schůzkám. Myslím si, že by se hodilo pro tým, který se poprvé setkal se Scrumem, udělat nejenom schůzku, na které bude řečeno, jak všechno funguje, ale i vysvětleno, proč jsou ty principy zavedené a co přináší týmu. Product Backlog Základním prvkem Scrumu je Product Backlog. Product Owner musí po setkání se zákazníkem a zjištění požadavků na zakázku začít pracovat na Product Backlogu. Nemusí se hned sepsat celý seznam úloh na projekt, ale poznamenat důležité body a jejich význam. Ještě před začátkem projektu není tak podstatný tvar, v němž jsou zapsané User Story, hlavně aby Product Owner mohl představit týmu projekt a promluvit o hlavní funkcionalitě požadované zákazníkem. Dále si celý tým může podrobněji popovídat o jednotlivých bodech a vytvořit z toho kostru projektu a rozepsat první úkoly. První schůzka Na začátku každého projektu by měla proběhnout schůzka, na níž by byl představen projekt, a týmu by byly sděleny všechny podstatné informace. Takové schůzky by se mohl zúčastnit i zákazník pro seznámení s týmem a lepší vysvětlení vize projektu. Na začátku bych doporučila provést krátké či podrobné, v závislosti na týmu, školení ohledně Scrumu. Pro tým, co se s tím setkal poprvé, by bylo dobré vysvětlit více o tom, co je Scrum, jak funguje, na čem jsou založeny jeho principy a čím prospěje vývoji. Pro týmy, které se se Scrumem setkali v minulosti, může být školení kratší, spíš pro upřesnění představ a očekávání jednotlivých členů. Dále by mohlo následovat představení projektu. Buď Product Owner sám vysvětlí informace, které dostal od zákazníka, nebo to představí spolu se zákazníkem, který se schůzky zúčastní, podstatné je to, aby tým pochopil, co se očekává po dokončení projektu, jaká funkcionalita je pro zákazníka důležitá a jaké má celkové požadavky na vývoj. Samotné seznámení tymu se zákazníkem může prospívat větší toleranci a navázání důvěryhodného vztahu. Po seznámení s projektem by měl Product Owner probrat s týmem požadavky a vytvořit z toho Product Backlog, který bude rozdělen na jednotlivé User Story. Product Backlog se může rozdělit na Epics. Není to nutnost, obzvlášť u malých projektů, ale pokud má projekt viditelně odlišné části, pomůže to vyhledávání v Backlogu a lepší orientaci, jak v projektu tak i v tom, co je už dokončené. Epics se mohou vytvořit hned na začátku anebo po diskuzi o potřebných User Story, které se 48

56 do určitých Epics následně přiřadí. Tým by se měl domluvit na hlavních bodech projektu a mít je poznamenané a vytvořit určité User Story pro několik budoucích Sprintů, detailněji propracovat ty User Story, z nichž by vývoj mohl začít. Organizační informace by se neměly zanedbávat a po dokončení diskuze o Backlogu by se tým měl chvíli věnovat tomu, jak dlouhé budou Sprinty, jaká bude rychlost týmu, kde a jak často budou probíhat schůzky, kdy začne první Sprint. Délka Sprintu pro malé IT projekty by neměla být moc velká. Je potřeba čas, za který tým dokáže dodat funkcionalitu. Zároveň je třeba počítat, že pokud na každém Review Meetingu má být zákazník, nemusí pro něj být pohodlné každý týden jezdit pro výsledky za dodavatelem. Rychlost týmu se dá odhadnout buď podle předchozích zkušeností daného týmu, nebo se domluvit na přibližné hodnotě, která se v následujících několika Sprintech může změnit v závislosti na výkonu. Dobré je hned na začátku stanovit, kde a kdy budou probíhat Planning, Review a Retrospective meetingy, aby byl tým vždy připraven a věděl, kdy má práci dokončit. Zároveň je potřeba zjistit, jak často, kde a v kolik hodin budou Daily Scrum Meetingy. Doporučuje se provádět Daily Scrum ráno, aby mohl tým zbytek dne pracovat na úkolech. Proto je potřeba vědět v kolik hodin musí být všichni v práci, aby se mohli zúčastnit Daily Scrumu. Není potřeba na plánování probírat všechno moc do hloubky buď z technického hlediska anebo se snažit rozdělit celý projekt na malé úkoly od začátku do konce, protože to zbytečně zabere čas a nakonec se možná ani nevyužije, protože se všechno několikrát změní. Musí být stanovené přibližné časově rozmezí, jak dlouho takové plánování projektu může trvat. Plánovací schůzka celého projektu nemusí být samotnou schůzkou a může být součástí Planning meetingu prvního Sprintu Vedení projektu Po plánovací schůzce projektu začíná první Sprint. Po prvním Sprintu následuje další a tak do konce projektu. Z hlediska řízení jsou všechny iterace stejné. Každá obsahuje Planning, Review a Retrospective meeting a Daily Scrum Meeting. Dále jsou dané schůzky popsány více dopodrobna se zaměřením na specifika malých IT projektů. Planning meeting Nový Sprint začíná Planning Meetingem, na němž se domlouvá, jaké User Story budou dokončené v následující iteraci a jakou funkcionalitu dostane na konci zákazník. Obsah Sprint Backlogu řeší celý tým na základě priorit Product Backlogu, 49

57 osobních požadavcích zákazníka, které prezentuje Product Owner, a rozhodnutí vývojářů. Čas trvání takových schůzek pro malé IT projekty má být výrazně menší, než pro větší. Menší tým předpokládá menší množství úkolů a to znamená, že je potřeba méně času na diskuse ohledně User Story. Je potřeba se rozhodnout, které User Story budou v následujícím Sprintu, ohodnotit jejich náročnost, rozdělit na jednotlivé úkoly a odhadnout časovou náročnost úkolů, zjistit pořadí User Story ve Sprintu. V menších týmech je jednodušší domluva, proto by vybírání User Story a odhad jejich náročnosti nemělo trvat dlouho. Ve firmě, kde jsem pracovala, jsme se domlouvali jenom na User Story, které budou patřit do dalšího Sprintu. Týmu bylo řečeno, kolik hodin má přibližně každý během Sprintu. Členové týmu se sami zabývali vytvářením úkolů ve svých User Story a odhadováním jejich časové náročnosti. Potom to bylo kontrolováno a konzultováno se Scrum Masterem a Product Ownerem, popřípadě se řešily problémy, které mohly během té aktivity vzniknout. Efektivita byla mnohem vyšší, než když celý tým spolu rozhodoval o všech úkolech, protože se každý staral o své User Story, a když měl všechno hotovo a nebyl žádný problém, mohl začít pracovat na svých úkolech. Během plánování Sprintu a rozdělování User Story na úkoly je potřeba nezapomínat na testování a ladění. V malých projektech se na to často zapomíná vzhledem k tomu, že Scrum to nijak nepřipomíná, proto je nutné přidat, kam je potřeba, i úkoly, které se týkají ladění. Po dokončení plánování se může doplnit popis User Story, avšak na menších projektech často není potřeba dopodrobna rozepisovat každou jednotlivou funkcionalitu. Zaprvé to zbytečně bere čas, zadruhé je obvykle funkcionalit méně, jejich náročnost není tak vysoká a tým může pochopit i ze stručného popisu, o co se jedná. Na konci schůzky může proběhnout diskuse o realizaci jednotlivých User Story, lepších technikách, doporučeních, vzájemné pomoci členů týmu. Není to plýtvání časem, protože pokud se tým před chvíli bavil o aktuálních úkolech, je mnohem jednodušší promluvit i o jejich realizaci. Později nebudou vývojáři tak ochotně diskutovat o řešení úkolů a nebudou na to chtít utrácet čas. Tím pádem diskuse v rámci Planning Meetingu podporuje snahu najít lepší řešení, sdílet informace a doporučení a tím pádem zlepšit produktivitu celého týmu. Daily Scrum Každodenní setkání se provádí z důvodu zjištění stavu Sprintu. Na něm se řeší otázky jako: 50

58 co bylo uděláno včera? co bude uděláno dnes? jestli se nevyskytly problémy? Pro malé IT projekty není potřeba provádět Daily Scrum každý den. User Story je méně, proto se může stát, že během několika dní se nic nezmění. Schůzky mohou probíhat jednou za dva dny nebo několikrát za týden. Avšak je důležité se dohodnout, že v případě vzniku problémů se tým hned sám obrátí na Scrum Mastera a nebude čekat na následující Daily Scrum. První dvě otázky Daily Scrumu jsou spíš určené oznámení stavu Sprintu. Nejdůležitější je třetí otázka a mohla by být rozšířena i o zjištění informací, zda každý člen týmu myslí, že všechno stihne včas. Ne každý si může uvědomit, že zpoždění také může ovlivnit výsledek a poprosit o pomoc. Review Meeting a Retrospective Meeting Review a Retrospective meeting pro malé IT projekty se ničím neliší od ostatních projektů, kromě toho, že jsou méně časově náročné. Přítomnost zákazníka na Review Meetingu je velice doporučená. Pokud zákazník může hned poskytnout zpětnou vazbu, velice to prospěje úspěchu budoucího vývoje. Retrospektiva je stejně důležitá jak pro malé projekty a týmy, tak i pro velké. To je ještě jedna věc, která se často zanedbává ve Scrumu na malých IT projektech. Je důležité pamatovat, že každá zpětná vazba prospívá efektivní synergii týmu. Není potřeba tomu věnovat hodiny času, pokud není závažný problém, ale vždy se hodí zhodnotit práci a spolupráci v týmu a udělat závěry o tom, co by se dalo v budoucnu zlepšit Scrum nástroje Předchozí kapitola popisovala celou metodiku Scrum - na čem je založena, jak funguje, co využívá. Nyní je potřeba se podívat na praktické využití Scrumu. Co může pomoct k ovládání vývojového procesu, jaké nástroje existují, jestli jsou potřeba v každé firmě. 51

59 Bez nástrojů Metodika Scrum v praxi nevyžaduje využití konkrétních softwarových nástrojů. Stačí mít propracovaný Product Backlog, který je dobré mít v elektronické podobě k lepšímu ovládání, přehlednosti a stálé přítomnosti. Backlog může vypadat jako na obrázku č. 8. Obrázek 8. Product Backlog Avšak pro sledování stavu sprintu stačí mít obyčejnou tabuli, na kterou se budou lepit lístečky, znázorňující jednotlivé úkoly (obrázek č. 9): Obrázek 9. Sprint Backlog 52

60 Lísteček se přesouvá do Progresu a do dokončených úkolů během sprintu, až všechny lístečky jednoho User Story jsou označené jako dokončené, může se přesunout i lísteček User Story do sekce Done. Jednodušší sledování produktivity umožňuje zavedení Burndown Chartu, který znázorňuje poměr získaných Story Points za každé dokončené User Story ku času (obrázek č. 10): Obrázek 10. Burndown Chart [27] Modrá čára ukazuje ideální průběh Sprintu, červená čára reálný. Takový graf umožňuje vývojovému týmu sledovat svoji efektivitu a motivuje k dosažení lepších výsledků. Lidé, kteří se zabývají teorií a aplikací Scrumu doporučují využívat právě takový styl řízení, kde se nebude využívat pomocný softwarový nástroj a vývojový tým bude využívat fyzickou tabuli. Tím pádem bude podporována komunikace v rámci týmu, výsledky budou viditelnější a bude to ještě lépe motivovat tým. V případě využití softwarového nástroje se zanedbává komunikace, členové týmu se méně dívají na aktuální stav Sprintu, snižuje se jejich motivace a zhoršuje se přehled Softwarové nástroje Existují ale situace, kdy je tým nucen k využití softwarových nástrojů. Příkladem je distribuovaný tým, kde není možná přítomnost všech členů týmu na jednom místě 53

61 a je potřeba mít stálý přehled o průběhu a změnách v rámci vývoje. Dalším příkladem mohou být velké a složité projekty, které mají hodně funkcionalit, poměrně rozsáhlý tým nebo více týmů. Potřebují mít úložiště, kde bude všechno poznamenáno, každé User Story, každá změna v projektu. Občas ale takové nástroje nabízí příliš moc možností a jsou poměrně složité, což může začít rušit proces vývoje náročností vyplňování všech záležitosti v rámci nástroje. Proto v případě, že tým nutně potřebuje využívat softwarový nástroj pro Scrum, je potřeba detailně prostudovat trh a vybrat to nejlepší. Dále je uvedeno pár příkladů softwarových nástrojů, které pomáhají ovládat Scrum. Yodiz Yodiz je placený online nástroj, který umožňuje řízení projektů ve Scrumu nebo Kanbanu. Má verzi Starters, která umožňuje až 3 uživatele a je zdarma. Pro Scrum nabízí ovládání všech Sprintů, Product Backlogu, Sprint Backlogu a průběhu Sprintu, Epics, Plánování a další nástroje. Scrum tabule vypadá následujícím způsobem (obrázek č. 11), je poměrně pohodlná a jednoduchá. Člen týmu může přidat úkoly ke každému User Story, ukázat a doplnit popis, nastavit časový odhad a přetahovat úkol mezi sloupci New, In Progres a Done. Pokud jsou všechny úkoly hotové, User Story automaticky změní svoji barvu a status. Na konci Sprintu se dá označit jednotlivou User Story jako hotovou, zamítnutou či zaseknutou. Obrázek 11. Yodiz. Sprint Backlog. [28] 54

62 Backlog vypadá jako standardní tabulka, do které se dají přidávat nové funkcionality a měnit jejich priority. Epics je také intuitivní a má vzhled seznamu Epiců, které po rozkliknutí zobrazí svůj obsah, to znamená User Story, co jim náleží. Plánování v daném programu není úplně jednoduché a intuitivní. Na plánovací stránce se dá vybrat ze všech nástrojů jako Epics, Sprint, Backlog několik a z nich přetahovat úkoly do plánovaného Sprintu (obrázek č. 12). Není to pohodlné, protože okna jsou malá, a nastavování priorit ve Sprint Backlogu stejným způsobem je matoucí. Teoreticky se dá nastavit priority ve Sprint Backlogu změnou čísel priorit přímo v aktuálním Sprintu, ale tato funkcionalita často selhávala a dávala neočekávané výsledky. Obrázek 12. Yodiz. Plánování [28] Každý Sprint má k dispozici přehled různých metrik, jako například Burndown Chart, rychlost, celkový čas. Jsou velice pohodlné pro lepší přehled stavu Sprintů, vypisují všechny potřebné informace a znázorňují je graficky. Celkem se dá nástroj posoudit jako užitečný a pomocný při ovládání Scrumu, ale má svoje určité nepohodlné prvky. Podle teorie Scrumu stačí polovina funkcionalit, co nabízí daná aplikace. Myslím si, že pro ovládání programu nestačí vědět, jak funguje Scrum, ale je potřeba provést krátké školení. Sprint Backlog Product Backlog 55

63 Epics Statistiky a metriky Plánování Nastavení priorit ve Sprintu Hodně nadbytečných prvků Vivify Scrum Vivify Scrum, jako hodně online aplikací, nabízí zdarma demo verzi a profesionální placené. Daná aplikace se liší od většiny podobných a předchozích jiným uspořádáním a propojením prvků. Má menší rozsah funkcionalit, ale je poměrně intuitivní. Na začátku uživatel vytvoří Tabuli. Může to být Scrum nebo Kanban. Po otevření tabule vidí uživatel Product Backlog a jednotlivé Sprinty se Sprint Backlogy (obrázek č. 13) Obrázek 13. Vivify Scrum. Product Backlog [29] Nastavování priorit v Product a Sprint Backlogu je vyřešeno manuálním přetahováním User Story. Podle mého názoru je nepohodlné, pokud je User Story více, než je možné vidět zároveň na obrazovce. Sprint Backlog ukazuje aktuální Sprint a skládá se z Items, které jsou i User Story i úkoly zároveň. Existuje možnost přidat 56

64 i další sloupce podle potřeby, například sloupec, kde úkoly čekají na otestování. Obrázek č. 14. Obrázek 14. Vivify Scrum. Sprint Backlog [29] Dále je k dispozici Burndown Chart, konfigurace týmu, přidávání souboru, popis úkolů. Celé ovládání je poměrně jednoduché a intuitivní. Jediné co chybí podle teorie Scrumu jsou Epics a dělení User Story na úkoly, ale myslím si, že některým menším projektům i daná funkcionalita bohatě stačí. Je možné, že chybějící prvky se objeví v placené verzi Vivify Scrum. Plánování probíhá jednoduchým přetahováním úkolů ze sloupce Product Backlog do sloupců Sprint. U jednotlivých Item se dají nastavit Parent Item a Sub Item, je možné, že vývojáři aplikace tím chtěli nahradit potřebu Epics a Tasks, ovšem to je úplně nenahrazuje. Program působí jednoduše a je vidět, že není potřeba hodně času na pochopení ovládání, avšak má určité pro Scrum nestandardní prvky a těžko říct, jestli to v praxi nebude dělat problémy. Jednoduché intuitivní ovládání Product Backlog 57

65 Statistiky a metriky Minimum nadbytečných prvků Epics Tasks Prioritizace User Story ScrumTool.me Nástroj ScrumTool je dostupný online a zdarma. Práce s nástrojem začíná vytvářením projektu, kde si uživatel může vybrat způsob, jak se budou přiřazovat priority a odhadovat složitost User Story. Nástroj umožňuje ovládání Product Backlogu a Sprintů. Product Backlog má klasický vzhled (obrázek č. 15), ale omezenou kapacitu User Story na 20. Pokud se User Story přiřazuje k určitému Sprintu, v Product Backlogu se už nezobrazuje a uvolňuje místo. Ke každému User Story se dají vytvořit úkoly. Není tady ale žádný odhad časového úsilí. Aplikace také neumožňuje vytváření Epics. Obrázek 15. ScrumTool.me. Product Backlog Ovládání Sprintu je také klasické (obrázek č. 16). Při zadávání nového Sprintu se dá vybrat množství sloupců a jejich účel. Když se zadávají nové úkoly do User Story, aplikace nabízí vybrat barvu lístečků. Může to být pohodlné pro zadávání úkolů různým uživatelům, když každý má úkoly své barvy. 58

66 Obrázek 16. ScrumTool.me. Sprint Backlog Nastavování priorit v Product Backlogu a Sprint Backlogu je jako i v ostatních aplikacích vyřešeno manuálním přetahováním. Vzhledem k tomu, že množství User Story v Product Backlogu je omezeno na 20, nemusí být problém se změnou priorit takovým způsobem. Celkové ovládání aplikace je jednoduché a jasné, avšak není úplně pohodlné. Pochopit jak funguje aplikace, nedělá problém, ale intuitivně člověk očekává jinou reakci při využití některých prvků. Jestli vezmeme v úvahu to, že je nástroj zdarma, svůj účel splňuje a může být vyhovujícím pro úplně malé IT projekty anebo začátečníky. Sprinty a Sprint Backlog Změna barvy úkolů Jednoduchost Omezená kapacita Product Backlogu Epics Časový odhad Intuitivnost ovládání Metriky a statistiky 59

67 Scrumblr Daný nástroj je online tabule. Není placený a má minimum funkcionality. Princip je úplně jednoduchý. Jsou čtyři sloupce: Product Backlog, Sprint Backlog, Work in progress, Done. Vytváří se úkoly a přiřazují se do určitého sloupce. Lístečky se mohou volně přetahovat mezi sloupce a mohou se označit barevnou tečkou nebo celkově zabarvit (obrázek č. 17): Obrázek 17. Scrumblr. Sprint Backlog [31] Není tu časový odhad, složitost úkolů, Tasks, Epics, metriky, dlouhodobý Backlog, který by uchovával historii User Story. Je to jenom tabule, na níž se dá podívat nejenom v kanceláři, ale i vzdáleně. Ovládání je jednoduché a intuitivní. V případě, že firma nechce utrácet peníze a má vymyšleno, jak uchovávat Product Backlog, může to stačit pro malý projekt. Jednoduchost Intuitivnost Barevné označení Minimum funkcionality 60