Zavedení agilních metod vývoje (Scrum) a tvorba nástrojů pro efektivní řízení

Transkript

1 Masarykova univerzita Fakulta informatiky Zavedení agilních metod vývoje (Scrum) a tvorba nástrojů pro efektivní řízení Diplomová práce Vedoucí diplomové práce: RNDr. Jaroslav Škrabálek, MBA Autor: Ondřej Kuchta Brno,

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

3 Anotace Předmětem diplomové práce Zavedení agilních metod vývoje (SCRUM) a tvorba nástrojů pro efektivní řízení je navrhnout a realizovat proces transformace vývoje z vodopádového modelu na agilní metody v antivirové společnosti. Proces transformace je popsán velice obecně a je tak aplikovatelný i v jiných společnostech vyvíjejících software. První část je krátký úvod do vodopádového plánování a výchozího stavu vývoje. Po úvodu do agilních metod je přechod na agilní metody rozdělen do dvou hlavních fází. Výsledkem diplomové práce je ucelený návod pro transformaci již existujícího vývoje na agilní metody. Na konci práce je umístěna kapitola o výběru nového Project management systému a celkové zhodnocení přechodu na agilní metody. Annotation The goal of the thesis: Implementation of Agile methods (Scrum) and tools for effective management is to design and implement the transformation process from the waterfall development model to the agile model in the anti-virus company. The process is described in very general way and therefore applicable also in other software companies. First part is short introduction in to the waterfall model and initial state of the development. The transformation process is divided in two main phases. The last part is about comparing and selecting the right tools for managing agile development. The result of this thesis is fully described process for transformation of the existing development to the agile methods. Klíčová slova Agilní metody, Scrum, Project Management, JIRA, Vodopádový model, vývoj software Keywords Agile methods, Scrum, Project Management, JIRA, Waterfall model, software development 3

4 Poděkování Na tomto místě bych rád poděkoval RNDr. Jaroslavu Škrabálkovi za bezproblémové vedení diplomové práce a za poskytnutí volnosti ve výběru tématu a následného uznání tohoto tématu. Dále pak svému nadřízenému Ing. Tomáši Krejzlíkovi za předané vědomosti o Project managementu z praxe, bez kterých by tato práce nikdy nemohla vzniknout. V neposlední řadě bych rád poděkoval celému vývojovému oddělení za možnost být jeho součástí a podílet se na jeho transformaci. Poděkování pak dále patří všem zaměstnancům společnosti, kteří se na přechodu jakkoliv podíleli. 4

5 OBSAH Anotace... 3 Annotation Úvod Motivace a cíl práce Společnost Vodopádový model Modifikace vodopádového modelu Model mikrotýmů Vývoj ve vodopádovém modelu Komponentní rozložení týmů Zastupitelnost v komponentních týmech Způsob plánování práce komponentních týmů Projekty a plánování nových verzí software Nástroje používané k plánování a realizaci projektů Testování produktu Shrnutí problémů vývoje ve vodopádovém modelu Agilní metody a jejich modely Hlavní priority agilního přístupu Agilní manifest Nejpoužívanější agilní metodiky Lean development Extrémní programování (XP) Scrum Crystal metodiky FDD Feature Driven Development TDD Test Driven Development Základní výhody a nevýhody agilních metod Výhody agilních metod Nevýhody agilních metod Výběr agilní metodiky vhodné pro vývoj Hlavní pojmy metodologie Scrum Scrum tým Sprint Produkt backlog Sprint backlog

6 Scrum master Scrum schůzky Daily Scrum meeting Sprint planning meeting Sprint review meeting Sprint retrospective meeting Scrum of Scrum meeting Burndown graf Zavádění agilních metod Stav vývoje před první fází přechodu - vodopádový model Přechod vývoje na agilní metody agilním způsobem Fáze 1 Agilní komponentní týmy Sprint Iterace v první fázi Plánování v komponentních týmech Plánování iterace Plánování sprintů Eliminace specialistů ve Scrum týmu Definice hotového požadavku Analýza nového požadavku Definice hotového požadavku Testování jako součást vývoje Rozdělení testování na interní a externí Souhrn kroků provedených při první fázi přechodu: Výsledek a hodnocení první fáze přechodu Fáze 2 přechod na agilní vývoj a funkční týmy Funkční týmy Role Organizace řízení projektů Project Steering Group Scrum tým Product owner Scrum master Programový manažer Projektový manažer Produktový manažer

7 6.11. Týmový vedoucí (Team leader) Architekt Agilní plánování iterací Agilní plánování sprintů Theme, epic, story a task Theme Story Task Backlog grooming Technická analýza před Groomingem Estimace ve Story pointech Nevýhody estimací ve Story pointech Postup plánování nových požadavků Rozpady požadavků na implementační tasky Rozpad epicu na story Rozpad epicu na více story Rozpad epicu na více story s externí závislostí Rozpad theme na epicy Postup implementace Schvalovací proces epicu Řízení a monitoring sprintů Scrum of Scrum meeting Elektronický Scrum board Odchylky od Scrum metodologie Specialisté Pevné datum vydání nových verzí software Pevně stanovený rozsah projektu Zhodnocení přechodu na agilní metody ve fázi Vývojář a tester Project a Product management Způsob plánování projektů v agilním prostředí Planning horizon Externí závislosti a planning horizon Spojení Is coordinated with Spojení Is blocked by Spojení depends on

8 8. Zhodnocení přechodu na agilní metody Neexistující důvody proč nepoužívat agilní přístup Udržitelnost architektury Zaměření developera a specialisté V Agilním vývoji neexistuje přesný plán do budoucna Datum dodání finálního produktu Scrum přináší více meetingů Výběr Project Management systému Obecné požadavky na nový systém Požadavky Project managementu Srovnání Project management systémů DevSuite Microsoft Team Foundation Server Hewlett Packard ALM JIRA Výsledná tabulka srovnání Project management systémů Nasazení JIRA Agilní modul do JIRA Zhodnocení nasazení a používání JIRA Závěr Seznam zdrojů Knižní zdroje Internetové zdroje Seznam obrázků Přílohy Příklad nefungujícího agilního plánování s týmem specialistů Příklady Burndown grafů

9 1. Úvod Práce by měla čtenáři sloužit především jako rámcový a praktický návod pro zavedení agilních metod a jasně definuje největší problémy, se kterými se každý bude potýkat v praxi při transformaci existujícího vývoje na agilní metody. Každý větší projekt potřebuje efektivně řídit. Softwarové projekty mají spoustu způsobů a metod řízení. Dříve byl nejčastěji nasazovaným vodopádový model. Ve společnosti, ve které pracuji, se tento model donedávna používal bezmála deset let. Praxe ovšem prokázala, že tento model vývoje je velice nevhodný nejen pro naši společnost, ale pro naprostou většinu vývojových firem. Proto vznikla iniciativa zavést velice dynamické agilní metody místo statického vodopádového modelu. Ovšem transformace vývoje softwarové firmy na agilní metody je komplikovaný proces, který vyžaduje spoustu příprav a nespočet úprav během samotné transformace. V případě paralyzovaného vývoje během transformace nejsou v ohrožení pouze nemalé zisky firmy, ale rovněž potencionálně až 160 miliónů klientů, kteří software využívají. Z těchto důvodů je třeba přechod na agilní metody dobře naplánovat a využít agilní přístup plánování už při samotném zavádění agilních metod, tak aby nebyl vývoj ohrožen. Proces transformace je popsán velice obecně a je tak aplikovatelný i v jiných společnostech vyvíjejících software. Součástí transformace se týká i změna používaných plánovacích nástrojů, kterou se tato práce zabývá v posledních kapitolách Motivace a cíl práce Hlavní motivací je provést čtenáře celým transformačním procesem softwarového vývoje na agilní metody. V současnosti existuje celá řada publikací a článků o agilních metodách, ovšem jen málokterý vůbec zmiňuje, jak převést již existující vývoj, který nepracuje agilně, na agilní metody. Práce je z mého praktického poznání transformace společnosti, ve které jsem se transformace jako projektový manažer účastnil. Veškeré zásadní poznatky jsou psány obecně, aby byli aplikovatelné i v jiné společnosti Společnost Společnost vyvíjí a vydává bezplatný a komerční bezpečnostní software pro koncové uživatele i firmy. V jednotlivých pobočkách po celém světě, v USA, Velké Británii, Nizozemí, České republice a Německu má okolo 900 zaměstnanců. Hlavní vývoj produktů probíhá v Brně, kde firma původně vznikla. Vybudovala také globální síť odborníků, kteří zkoumají hrozby. Produkt aktuálně využívá 150 miliónů uživatelů. 9

10 2. Vodopádový model Ze začátku 80. let, kdy se začínal rozvíjet vývoj software na světovém měřítku, vznikl problém s řízením větších softwarových projektů, zejména proto, že softwarové projekty mají jiný průběh a ukončení. Obecné metody pro vedení projektů selhávaly. Začaly vznikat metody, které se daly použít pro vývoj software. Asi nejznámější vývojový model, používaný většinou firem, je vodopádový model vývoje a životního cyklu software. Postupný vývoj software v jednotlivých fázích řazených za sebou vznikal ve většině firem nejspíš intuitivně. První, kdo se formálně zmínil o vodopádovém modelu, byl Winston W. Royce ve článku publikovaném v roce Ve skutečnosti Winston W. Royce nazval tento model jako nefunkční a nepoužitelný pro vývoj software. I přes tuto kritiku se vodopádový model ujal a byl pro vývoj software neustále používán. Některé vývojové firmy tento model stále používají. Vodopádový model sestává z několika fází, které se následují, a přitom žádná fáze nesmí předběhnout fázi předchozí, nýbrž musí počkat na její úspěšné dokončení. Obrázek 1: Jednotlivé fáze projektu ve vodopádovém modelu 10 Zdroj: Vlastní I přes kritiku vodopádového modelu přímo samotným autorem, který jej jako první definoval, existuje několik pádných argumentů, proč vodopádový model používat. Tyto argumenty vedly k nasazení tohoto modelu v praxi. Prvním takovým je, že vodopádový model kladl důraz na předimplementační fázi návrhu software. Práce strávená na začátku projektu se velice vyplatila při jeho pozdější implementaci. Čím víc chyb bylo nalezeno při inicializaci projektu, především chyby v návrhu nebo ve specifikaci požadavků, tím byla větší pravděpodobnost úspěšného ukončení implementace

11 projektu. Vodopádový model si tímto vynucuje, aby každá fáze byla ukončena na sto procent a s úplnou správností. Zároveň požadavky na výsledný software musí být stanoveny napevno ještě před samotným vývojem a musí být správně pochopeny požadavky zákazníka na výsledný software. Pokud by některý z těchto požadavků nebyl splněn, tak projekt nemůže přejít do fáze vývoje. Další zdánlivou výhodou tohoto modelu je, že klade stejný důraz na dokumentaci jako na samotný implementační kód. Především dokumentace požadavků a dokumentace návrhu. Pokud by některý člen týmu od projektu odešel před jeho dokončením, bylo by bez dobré dokumentace velký problém projekt dokončit. Což je obrovské riziko z pohledu managementu projektu, a proto se investice do řádné dokumentace vyplatí. Pokud existuje dobrá dokumentace, je možné, aby se k projektu přidal další člen, popřípadě aby byl realizován zcela jiným týmem. Další výhodou vodopádového modelu je jeho snadné vysvětlení a jednoduché objasnění týmu a přehledné vysvětlení, jaké jsou další fáze projektu. Podle modelu vývoje software vznikly i týmy, které projekt realizují v jednotlivých fázích. Prvně je potřeba konzultant nebo produktový manažer, který jasně specifikuje, co se od projektu očekává. Další fází je samotný návrh designu, který často zastřešují architekti, pak přichází na řadu samotná implementace developery a následně vydání nebo prodej software zákazníkovy, který obstarají obchodníci. Konečnou fází života software je jeho monitoring. Podle modelu také často dochází k formování týmů. U vodopádového modelu jsem byl svědkem formování týmů sériově, podle míry abstrakce software. Vznikají takzvané komponentní týmy, které si obvykle předávají práci sériově. Vodopádový model má dost negativních vlastností, na které upozorňoval sám autor definice vodopádového modelu Winston W. Royce. Nedoporučoval nasazení modelu v praxi, prohlašoval o vodopádovém modelu, že je nefunkční pro vývoj software. Já sám jsem jich v praxi několik vypozoroval během tří let, kdy jsem jako developer pracoval na vývoji antiviru právě v jednom z komponentních týmů. První z problémů byla chybějící zpětná vazba od produktových manažerů, kteří hodnotili výsledek až po dokončené implementaci. Existovala velká pravděpodobnost, že se bude muset produkt znovu předělávat, protože výsledek nebyl takový, jaký byl původně plánován, nebo se rozhodlo o jeho předělání. V každém případě byl potřeba další vývoj, který stál více peněz a času. Další velký problém je domluva a rozdělení práce na požadavku ve více komponentních týmech. Velká většina požadavků byla právě tohoto typu. Vznikal problém plánování zdrojů, které bylo potřeba plánovat na jednotlivce a dlouho dopředu. Zastupitelnost v týmech byla takřka nulová, protože každý vývojář byl specialista na svou část komponenty a nikdo jej nemohl jednoduše zastoupit. Dost často tak docházelo k situacím, kdy byl jeden jediný člověk úzkým hrdlem celého projektu, což přinášelo obrovský risk. Nevýhodou vodopádového modelu byla rovněž neinformovanost vývojářů o průběhu vývoje produktu jako celku. Každý znal je svou část, na které pracoval, ale přicházel o další návaznosti. Zároveň komunikace o aktuálním stavu projektu mezi vývojáři prakticky neexistovala. Nejdůležitějším problémem, který vedl ke změně modelu z vodopádového na agilní přístup, byl, že nikdo dopředu neznal veškeré technologické limity a požadavky na výsledný software. Dokud se nezačalo s implementací, nebyly známy technologické 11

12 limity ani konečný seznam požadavků. V případě, že se narazilo na problém, na změnu architektury už bylo pozdě a projekt se musel vrátit na počáteční fázi Modifikace vodopádového modelu Už před zavedením agilních metod začali vznikat náznaky agilního přístupu k vývoji. Tím nejmarkantnějším byli takzvané mikro tým. Každý nový požadavek zahrnoval práci několika týmů, nebo dokonce oddělení. Klasický požadavek obsahoval práci pro grafického designéra, programátora grafického rozhraní, programátora jádra aplikace, testera produktu a produktového manažera. Myšlenkou bylo tyto lidi na skrz oddělení spojit pro každý požadavek a ustanovit dočasné tým po dobu jeho realizace. Zodpovědnost za tým a za požadavek jako takový, dostal jeden z členů týmu, a ten fungoval částečně jako projektový manažer. Musel synchronizovat práci všech členů týmu a řešit nastávající komplikace. Největší komplikací těchto malých týmů byl nedostatek zdrojů. Často nešlo takový tým sestavit, protože člověk dedikovaný do týmu musel zároveň pracovat na jiných požadavcích a patřil například do několika malých týmů zároveň. Dalším problémem byli kompetence a schopnosti vedoucího týmu, který musel fungovat jako projektový manažer, ovšem jeho kompetence byli omezené, co se týkalo plánování práce jiných, protože na tuto operaci neměl skrz ostatní oddělení kompetence. Neschopnost vést tým byl sice okrajový případ, ovšem rozhodně stojí za zmínku, protože měl často fatální následky pro celý tým a na požadavek jako takový, který nebyl nakonec dokončen v termínu. I přes všechny tyto nedostatky se mikro týmy osvědčili jako první agilnější přístup k vývoji software a vyplatilo se takto některé požadavky řešit. Bohužel takových požadavků, kde byl jeden malý tým schopen celý požadavek vyřešit sám, aniž by potřeboval externí pomoc, moc nebylo a většina vývoje pracovala stále ve standardním vodopádovém modelu Model mikrotýmů Model mikrotýmů vznikl převážně proto, aby se lidé z různých oddělení spojili v rámci jednoho projektu dohromady a pracovali společně. Model měl za úkol zrychlit především komunikaci mezi lidmi, kteří společně na požadavku pracovali, zjednodušit plánování, řízení a minimalizovat byrokracii. Základními myšlenkami pro vytvoření mikrotýmů: Vytvořit dočasné týmy Zajistit jim autonomii a odpovědnost Odměnit za odvedenou práci celý tým (ne individuálně) Zcela základní myšlenkou je vytvořit pouze dočasné týmy. Podmínkou při tvoření týmů také je, aby se složení týmů často neopakovalo a neskládalo ze stejných lidí. Každý tým 12

13 musí být zcela autonomní a odpovědný za svou práci jako celek ať v případě úspěchu nebo neúspěchu. Hlavními problémy při zavádění mikrotýmů: Moc radikální myšlenka implementovaná bez předchozích zkušeností Velká změna může být velice nebezpečná a představuje riziko Lidé si musí zvykat postupně Myšlenka je poměrně radikální, protože mění způsob, jak lidé komunikují a pracují. Nikdo není schopen dopřed odhadnout, jaký následek zavedení mikro týmů na vývoj má. Lepší cestou je zavádět mikro týmy postupně. Jak začít s mikrotýmy? Postupovat s co nejmenšími změnami Primárně se soustředit na dobrovolníky Motivovat lidi aby se do týmů sami přidali Při vytváření mikrotýmů je nejlepší variantou se soustředit na dobrovolníky, kteří by rádi mikrotým zkusili z vlastní iniciativy. Tým má pak mnohem větší šanci na úspěch. Motivovat lidi, aby si práci v mikro týmu zkusili, je rozhodně dobrý způsob, jak s mikrotýmy začít. Ze všech požadavků vybrat ty, které se dají realizovat pomocí mikrotýmů. Požadavek musí být realizován kompletně celý jen v rámci daného mikrotýmu a nesmí mít externí návaznosti mimo tým. Požadavky, které tyto podmínky nesplňují, musí být řešeny standardní cestou. Sestavit tým podle druhu požadavku. Ideální velikost týmu je 4-6 členů. Obvykle by měl mikrotým obsahovat dva až čtyři vývojáře, jednoho testovacího analytika a testovacího specialistu. Tým si musí sám zvolit svého mluvčího, jehož role je řídit tým po celou dobu jeho existence. Mluvčí je rovněž zodpovědný za reportování stavu projektu a organizaci v rámci týmu. Požadavky na tým se přidělují ve dvoutýdenních cyklech. Výsledkem každého cyklu musí být kompletní specifikace, implementace a hotové testování odvedené implementace. 13

14 Po dokončení každé iterace musí být výsledek práce týmu evaluován. Základní otázky, na které je třeba klást důraz, jsou tyto: Dodání požadavku ve stanovený čas Samostatnost týmu Kvalita dodaného výstupu Motivace a názor všech členů týmu. Hlavní přínosy mikrotýmů je především první krok k agilnosti vývoje a s tím přicházející výhody, jako jsou například rychlejší reakce na změny požadavků bez dopadu na kvalitu výsledku. Rychlejší dodání požadavku než standardní cestou vodopádového modelu a menší procento zavedených chyb ve výsledku díky přítomnosti testerů přímo v týmu. Další nespornou výhodou je, že se lidem práce v mikrotýmech většinou zamlouvá. Metodologie mikrotýmů je zaměřena více na lidi, kteří jsou tak více odpovědni za svou práci a mají možnost ji více ovlivnit, práce v týmu také přináší méně manažerských procesů a mnohem méně byrokratické práce, protože veškerá komunikace jde napřímo, a ne přes manažery jednotlivých oddělení. Ačkoliv jsou mikrotýmy prvním malým krokem k agilnosti od vodopádu, mají své nevýhody, které více méně souvisí právě s problémem, že zbytek vývoje pracuje nadále ve vodopádovém modelu a tím pádem sebemenší externí vstup, který tým může potřebovat, může zcela rozhodit plán mikrotýmu. Bohužel v praxi se téměř nestává, že by existoval požadavek, který by mohla implementovat jen malá skupina lidí bez externí spolupráce se zbytkem vývoje. Během implementace se přichází na externí závislosti, které můžou zpomalit práci týmu nebo ji rovnou zcela zastavit. Další velkou nevýhodou je právě kolektivní zodpovědnost týmu za dodání požadavku. Jedinec v týmu nemůže být zodpovědný za celý tým, protože je tým často složený z lidí, kteří nepatří ani do stejných oddělení a nemůže za jejich výkon nést zodpovědnost, protože není jejich nadřízený. Proto musí nést zodpovědnost za realizaci celý tým. Kolektivní zodpovědnost je ovšem často nefunkční model zodpovědnosti a záleží na každém jedinci v týmu. Vytvořit mikrotým, který bude složený ze správných lidí, kteří jsou schopni úkol samostatně vyřešit, se dá jen u velmi malého počtu požadavků. Podle statistiky je úspěšnost využití mikrotýmů přibližně, z mého sledování, u dvaceti procent požadavků. I přes své nedostatky, se dají mikrotýmy využít pro řešení externích úkolů a návazností, kdy jedna strana používá agilní metody a pracuje agilně a druhá strana pracuje vodopádem. 14

15 2.3. Vývoj ve vodopádovém modelu I přes všechna negativa tohoto modelu zmíněných výše, model ve velké spoustě společností dlouhá léta fungoval a vývoj dodával produkt v takové kvalitě, jakou byznys požadoval. Problém vodopádového modelu a neagilního přístupu byla především pracnost jej udržet ve funkčním stavu a dost často i plýtvání zdroji, pokud se zpozdila dodávka požadavků s dalšími závislostmi. Hodně složité plánování konkrétních lidských zdrojů na velký časový úsek do budoucna, byla jedna z dalších nevýhod tohoto modelu v praxi. Plánování ve velkém procentu případů nevycházelo podle původního záměru. Plán například ani nepočítal s požadavky s vysokou prioritou, které přicházejí těsně před vydáním finálního produktu, k čemuž docházelo velmi často a to především z toho důvodu, že produktový manažer viděl výsledek právě až těsně před samotným vydáním. Paradoxně výhodou vodopádového modelu bylo, že projektový manažer měl absolutní přehled nad každým vývojářem v týmech a přesně věděl, na čem a kdo pracuje. Navíc sám stanovoval časovou mapu vydání produktu a měl plán na půl roku dopředu, podle kterého se snažil řídit zdroje a řešit vzniklé potíže. V agilním přístupu projektový manažer nikdy přesně nezná plán do vzdálenější budoucnosti Komponentní rozložení týmů Rozložení a názvy týmů téměř přesně kopírovaly vyvíjený software. Vývoj byl rozdělen na dva velké funkční celky. Bezpečnostní a aplikační část produktu. Do bezpečnostní části patřily týmy jako jádro antiviru nebo například komponenty kontroly identity nebo firewall. Naopak do aplikační části patřili týmy, které implementovaly aplikační jádro, instalace nebo grafické rozhraní produktu. Rozložení týmů je horizontální, protože přesně kopíruje produkt a každý tým je specializovaný právě na jednu vrstvu produktu v horizontálním směru. Největším problémem komponentních týmů je, že nikdy nejsou autonomní. Existuje jen málo požadavků, které tým dokáže vyřešit samostatně, bez interakce s jiným komponentním týmem. Při implementaci požadavku byla většinou potřeba dvou až tři týmů. Jejich práce byla synchronizována projektovým manažerem. Týmy řešili dodávky potřebných kódů pomocí vodopádového modelu. Implementace požadavku se řadila za sebe od nejnižší vrstvy produktu po nejvyšší, kterou je uživatelské rozhraní. Problémem byli právě návaznosti mezi týmy. Každý z týmů implementoval jinou funkcionalitu, která samostatně fungovala, ale po spojení částí se často stávalo, že požadavek jako celek nefungoval nebo fungoval s chybami. Plánování návaznosti zdrojů skrz několik týmů byla další z řady nevýhod tohoto rozložení vývoje. 15

16 Obrázek 2: Implementace jednoho požadavku přes několik týmů v komponentním rozložení vývoje bez agilních metod Zastupitelnost v komponentních týmech Zdroj: Vlastní Dalším velkým problémem komponentních týmů je prakticky nulová zastupitelnost, a to nejen na úrovni týmů, ale i v rámci jednoho komponentního týmu. Komponentní rozložení a vodopádový model má tendenci vytvářet specialisty na určité oblasti produktu. V konečném důsledku neexistuje zastupitelnost vývojáře z vyšší vrstvy produktu s developerem nižší vrstvy produktu. Výsledkem je několik týmů vývojářů, kteří vzájemně do své práce nevidí a nerozumí ji i přes to, že pracují často na stejném požadavku. Bohužel zastupitelnost není problémem jen vrstev, tedy mezi týmy, ale i v týmu samotném. Práce komponentních týmů je v rámci jedné vrstvy často rozdělena na určité úseky pro jednotlivé developery. Díky přesnému plánování práce na jednotlivého developera se stává, že určitý typ požadavků na určitou část vrstvy chodí vždy na stejného developera, který je schopný práci odvést co nejrychleji, protože danou část kódu perfektně zná. Tím pádem nikdy nepronikne do znalosti kódu v rámci celé vrstvy a stane se z něj specialista na jednu implementační část. Největším problémem specialistů je jejich složité plánování. Často se ze specialistů stává úzké hrdlo plánování, což může způsobit problém s pozdním dodáním požadované funkcionality a může brzdit ve vývoji celé týmy, popřípadě ohrozit vydání produktu. Specialisté mají svou nepopíratelnou výhodu v rychlosti dokončení implementace. Bohužel je tato výhoda značně krátkozraká a z dlouhodobého hlediska se vyplatí specialisty nemít. Ztráta specialisty znamená vždy obrovské riziko, kterému je lepší se v praxi vyhnout. Agilní metody bohužel samy o sobě tento problém neřeší, jak se na první pohled může zdát. Řešením je časté sdílení práce mezi vývojáři a sdílení znalostí. Také dobrá dokumentace může přispět k eliminaci specialistů. Další možností jsou časté prezentace vývojářů o nových úpravách ve své komponentě. Nejlepším způsobem je ovšem skutečná práce na části neznámého kódu. Příkladem může být oprava chyb vývojářem v kódu svého kolegy. 16

17 2.6. Způsob plánování práce komponentních týmů Klasickým nástrojem pro plánování byl software Microsoft Project od společnosti Microsoft, jehož výstupem byl Ganttův diagram s naplánovanými zdroji pro všechny požadavky. Graf se obnovoval každý den v závislosti na dostupnosti zdrojů, oddělané práce nebo kvůli přidání nových požadavků do projektu. Výhodou Ganttového diagramu bylo, že se dalo poměrně jednoduše zjistit, zda se projekt stihne dodělat v čas se všemi požadavky, které obsahoval, ovšem základním předpokladem takového plánování je, že je dopředu přesně daný a neměnný seznam požadavků s jasně stanovenou prioritou Projekty a plánování nových verzí software Standardním velkým projektem je například další verze produktu, která vychází pravidelně každý půlrok. Základní verze jsou dvě. Vedle těchto hlavních verzí produktů ještě existují pravidelné aktualizace aplikace. Pravidelné malé aktualizace se Small Update, za kterým následuje pořadové číslo verze. Tento typ aktualizací se vydává na téměř pravidelné bázi co dva měsíce. Velice malé aktualizace, které pouze opravují a kritické chyby se nazývají Hot Fix neboli rychlá oprava. Tento typ aktualizací se vydává pouze v případě, že je v produktu kritická chyba, která může ohrozit řádově milióny zákazníků. Na všech těchto projektech se pracuje paralelně a vzájemně se ovlivňují. Každý z projektů má svou unikátní prioritu v rámci celého vývoje. Hlavní verze - přibližně co šest měsíců SU (Small Update) - přibližně každé dva měsíce HF (Hot Fix) - pouze v případě kritické chyby Největší prioritu mají samozřejmě rychlé aktualizace, které řeší kritické chyby produktu nebo mají vliv na monetizaci produktu a tím pádem na zisk firmy. Na základě priorit se stanovují data vydání jednotlivých aktualizací nebo verzí produktu. 17

18 Obrázek 3: Příklad časové osy vydávání majoritních a minoritních verzí software Zdroj: Vlastní 2.8. Nástroje používané k plánování a realizaci projektů Hlavním nástrojem pro sběr požadavků, které se mají implementovat, byl systém Accompa. Uživatelem je produktový manažér, který je zodpovědný za sběr a analýzu požadavků na nové verze produktu. Primárním nástrojem na plánování byl Microsoft Sharepoint od společnosti Microsoft, ve kterém byli všechny projekty vedeny. Hlavním nástrojem na tvorbu Ganttových diagramů, byl Microsoft Project, který pomocí skriptů importoval dostupnost zdrojů a přepočítával kritickou cestu všech projektů dvakrát za den. Výsledkem používání těchto dvou nástrojů byl přehledný seznam běžících projektů, jejich aktuálního stavu a časového odhadu do dokončení. Požadavky vytvořené v Accompa systému se automaticky importovaly do Microsoft Sharepoint. Nejdůležitějším nástrojem pro samotný vývoj byl software Bugzilla. Bugzilla je webová aplikace, která pomáhá spravovat vývoj software. Uživatelé a vývojáři do ní zadávají chyby a požadavky na nové vlastnosti, které později projektový manažér nebo vedoucí týmu rozdělí mezi své vývojáře. Existuje tedy přehled, kdo co udělal a co je potřeba udělat. Z Bugzilly se dá zjistit i stav produktu jako takového, podle počtu defektů a samozřejmě podle jejich závažnosti. Defekt je chyba v produktu nalezená testováním, (anglický název pro defekt je bug). V Bugzille se hlídal celý vývoj požadavků a probíhala veškerá technická komunikace napříč týmy. Další systémy používané v rámci vývoje a testování, které nejsou přímo spojeny s plánováním, ale mají vliv na samotný průběh vývoje a jsou integrovány do plánovacích nástrojů Bugzilla a Sharepoint. 18

19 Build systém - vlastní řešení sestavování software balíčků Build server server na kterém se provádí spuštění skriptů, které sestaví kompletní softwarový balíček Crash Analysis Portal reportování chyb a kontola kvality vydaného produktu Knowledge management - WikiMedia a Dita Systémy na testování jako DevTest nebo AppDev Verzovací systém systém pro správu verzí kódu. Mezi nejznámější patří SVN a Git. Všechny tyto systémy jsou částečně integrovány. Nový systém by měl nahradit minimálně systémy Accompa, SharePoint a Bugzilla. Ostatní systémy by měli jít s novým systémem propojit, což je jedno z kritérií výběru nového Project management systému o kterém je poslední kapitola. Úkolem je najít takový systém, který by nahradil všechny aktuálně používané systémy, splnil očekávání všech uživatelů a podporoval agilní metody Testování produktu Další obrovskou nevýhodou tohoto modelu byla absence testerů přímo v týmu. Testování požadavků a celého produktu odděleně od vývoje způsobovalo obrovské zpoždění a pozdní zpětnou vazbu o stavu požadavku a chybách. Rovněž komunikace byla velice neefektivní, probíhala pouze přes Bugzillu a y. 19

20 2.10. Shrnutí problémů vývoje ve vodopádovém modelu Závislosti mezi týmy Absence testerů přímo v týmu Developeři nemají dostatečný přehled o další práci Požadavky jsou udělány tak, aby se nedaly implementovat v rámci jednoho týmu Plánování do budoucnosti vzdálenější než měsíc postrádalo smysl Komponentní týmy Skupinová odpovědnost u mikro týmů Špatná reakce na nové požadavky během vývoje Nulová zpětná vazba od Product managera během vývoje Problém plánování zdrojů na paralelních projektech Neexistující zastupitelnost v komponentních týmech 20

21 3. Agilní metody a jejich modely Až do nástupu odlehčených metodik se používaly těžké, rigorózní metodiky. Ty jsou někdy kritizovány pro svůj vodopádový model vývoje a proto, že vedoucí projektu svým blízkým dohledem omezuje vývojáře v práci. Kromě toho obtížně reagují na změny. V polovině devadesátých let se proto začaly objevovat odlehčené metodiky. Ty se podle jejich tvůrců navrací k vývojovým praktikám ze samotných počátků softwarového vývoje. Mezi tyto odlehčené metodiky patříl Scrum, Crystal Clear, Extrémní programování či FDD (Feature Driven Development). Od publikování Manifestu agilního programování se tyto metodiky nazývají agilními. Agilní projektové řízení je poměrně novým typem projektového managementu. Agilní metody jsou nejčastěji používané pro vývoj software, ačkoliv se dají obecně použít pro jakékoliv odvětví. Agilní projektové řízení staví na jednoduché myšlence inkrementálního neboli iteračního řízení projektu. Vše se dělá postupně po dílčích funkčních celcích, což umožňuje včas odhalit případné problémy, reagovat na ně a případně také včas zastavit či redefinovat projekt jako takový. To je ostatně také důvod, proč se tento způsob řízení projektů velice dobře prosadil v oblasti softwarového vývoje, kdy software už z principu svého fungování staví na dílčích funkčních celcích. Ve světě software se synonymem pro agilní projektové řízení stala metoda řízení projektů Scrum. Její historie sahá až do roku 1986 do Japonska, kdy Hirotaka Takeuchi a Ikujiro Nonaka publikovali svůj článek New Product Development Game v publikaci Harvard Business Review, kdy na příkladech z automobilového průmyslu a z ICT ukazovali nové možnosti řízení projektových týmů. Přičemž odsud pochází i samotný pojem Scrum, který je zkráceninou z ragbyového pojmu skrumáž, a který je zde zmiňován při analogii s ragbyovým utkáním. Pojem Scrum přitom v ragby označuje proces znovu zahájení hry po jejím přerušení z důvodu nechtěného přerušení nebo autu, kdy se hráči obou týmů postaví čelem k sobě a vrhnou se po míči. Za duchovního otce metody agilního vývoje software Scrum je nicméně považován Ken Schwaber, který poprvé použil myšlenky Takeuchiho a Nonaky při vývoji software ve své společnosti, a v roce 1995 spolu s Jeffem Sutherlandem prezentoval získané zkušenosti na programátorské konferenci OOPSLA 95 v americkém Austinu Hlavní priority agilního přístupu Fungující software má přednost před velkou a obsáhlou dokumentací. Lidé a jejich spolupráce má přednost před procesy a nástroji, komunikace napřímo. Spolupráce se zákazníkem před sjednáváním smluv. Reakce na změnu má přednost před přesným dodržováním plánu. 21

22 3.2. Agilní manifest V manifestu je také definováno 12 principů agilního programování. 1. Nejvyšší prioritou je uspokojit zákazníka skrz rychlé a průběžné dodávání kvalitního software. 2. Změnové požadavky jsou vítány, dokonce i v průběhu vývoje. Agilní procesy je zpracují tak, aby zákazníkovi přinášely konkurenční výhody. 3. Dodávejte fungující software často, v intervalech týdnů až měsíců. Upřednostňujte kratší intervaly dodání. 4. Lidé z businessu a vývojáři musí spolupracovat každý den během celého projektu. 5. Pro práci na projektu vybírejte motivované jedince. Dejte jim prostředí a podporu, kterou potřebují, a důvěřujte jim, že práci dokončí. 6. Nejúčinnější metoda sdílení informací vývojářskému týmu (i uvnitř tohoto týmu) je osobní setkání. 7. Fungující software je hlavním měřítkem postupu vývoje. 8. Agilní procesy podporují udržitelný vývoj. Sponzoři, vývojáři i uživatelé by měli být schopní dodržovat stálý výkon, dokud je třeba. 9. Průběžná pozornost věnovaná technické dokonalosti a dobrému návrhu posiluje agilní přístup. 10. Základem je jednoduchost umění co nejvíce práce vůbec nedělat. 11. Nejlepší architektury, požadavky a návrhy vznikají v týmech, které se samy organizují. 12. Tým v pravidelných intervalech vyhodnocuje svou práci a upravuje své postupy tak, aby byl co nejefektivnější Nejpoužívanější agilní metodiky 3.4. Lean development Lean development je spíš než metodikou souhrnem pravidel, jejichž používání by mělo zefektivnit a zrychlit vývojový proces. Tato pravidla zní: eliminovat zbytečné (to, co nepřináší zákazníkovi žádnou hodnotu), zdůraznit proces učení, rozhodovat se tak rychle a pozdě, jak je možné, posílit odpovědnost týmu, zabudovat integritu a vidět systém jako celek. Součástí metodiky jsou také principy a nástroje, které tyto pravidla umožní realizovat. 22

23 3.5. Extrémní programování (XP) XP je pravděpodobně nejznámější agilní metodikou. Propaguje časté dodávky software v krátkých vývojových cyklech. Kromě toho navrhuje párové programování, jednotkové testování celého kódu (nejdříve se vytvoří test, až pak samotný kód), programovat jen to, co je v danou chvíli nezbytné, jednoduchý a jasný kód. Mezi další praktiky patří společné vlastnictví kódu a neustálý proces zefektivnění kódu (code refactoring). Vývojáři by měli počítat se změnami požadavků v průběhu času. Důležitá je častá komunikace se zákazníkem i mezi programátory. Extrémní programování využívá například společnost Facebook nebo Google na některých svých projektech. Je používáno zejména při takzvaných Hackathonech, kdy tým pracuje určitý počet dní prakticky v kuse za účelem navrhnout a implementovat danou aplikaci v co nejkratším možném čase Scrum Klíčovou částí metodiky jsou každodenní setkání týmu. Každý člen zde referuje o své činnosti z minulého dne, o tom, co bude dělat dnes, a na jaké problémy narazil. Metodika prosazuje iterativní vývoj, období iterace se nazývá Sprint a trvá 2-4 týdny. Výsledkem Sprintu je demo vzniklých úprav, které je předvedeno zákazníkovi. Ten poskytne zpětnou vazbu, což umožňuje rychle reagovat na změny v požadavcích. Jsou zde rozeznávány tři role Product owner má za úkol komunikovat se zákazníkem. Správné fungování vývojového týmu zajišťuje Scrum master. Člen vývojového týmu se nazývá Scrum team member Crystal metodiky Nejde jen o jednu metodiku. Hlavní myšlenkou je to, že je lepší metodiku přizpůsobit danému projektu, žádná metodika nebude vyhovovat každému projektu. Vytvoření metodiky je první fází vývoje. Pro vytvořenou metodiku je rozhodující například velikost projektu a vývojového týmu FDD Feature Driven Development FDD začíná vytvořením doménového modelu popisujícího celý systém. Ten se převede do seznamu vlastností (elementární funkcionality, které přináší hodnotu uživateli). Vývoj má celkem pět fází (první tři sekvenční, další dvě iterativní). Iterace trvá většinou dva týdny. Během každé iterace se implementují konkrétní užitné vlastnosti systému. Zákazník průběžně dostává mezivýsledky a nové verze produktu. Na rozdíl od XP nebo SCRUM je jednotlivým programátorům práce přidělena a nevybírají si ji sami TDD Test Driven Development TDD navrhuje psaní testů před samotným kódem a následně naprogramovat samotný kód. Implementuje se přesně takové množství kódu, jaké dokáže projít testem. 23

24 3.10. Základní výhody a nevýhody agilních metod Výhody agilních metod Agilní metody ve mnoha případech pomáhají šetřit peníze a čas. Agilní metody se dají využít zejména u projektů, jejichž obsah se stále mění a není ze začátku zcela jasný. Díky časté informovanosti o průběhu práce je to velice dobře kontrolovatelný proces. Je zde velice jasná viditelnost projektu. Je to iterativní proces a vyžaduje neustálou zpětnou vazbu od uživatele. Díky krátkým iteracím je snadné se přizpůsobit změnám ve kterékoliv fázi projektu. Je jednodušší dodat kvalitní produkt na čas Nevýhody agilních metod Agilní metody a především iterativní vývoj bez pevného data lehce vedou management k domněnce, že můžou obsah projektu neustále zvětšovat a stále požadovat větší funkcionalitu. Pokud není požadavek dostatečně dobře analyzován a vytvořen, nebudou estimace (tzn. odhad časové náročnosti úkolu) správné a požadavek se může táhnout přes několik sprintů. Je výhodnější pro malé projekty, které se rychle vyvíjí kupředu než pro velké projekty. Agilní metodologie potřebují v týmech lidi, kteří je důvěrně znají a umí aplikovat, jinak tým nefunguje. Management kvality produktu se těžce implementuje do agilního procesu, pokud není možné udělat kompletní testy software po konci každého sprintu. Tato nevýhoda se týká zejména komplexních projektů, které není díky jejich velikosti snadné otestovat v krátkém čase. 24

25 3.13. Výběr agilní metodiky vhodné pro vývoj Jako metodiku jsme vybrali Scrum, protože přesně adresoval a řešil některé specifické problémy, se kterými byl na vývoji dlouhodobý problém. Několik hlavních důvodů, proč jsme vybrali Scrum a které problémy Scrum řeší: Spousta změn ve specifikaci požadavků během vývoje je velice frustrující jak pro samotné vývojáře, tak pro plánování projektů. Velikost implementovaných projektů přesahuje měsíce, v některých případech i roky, což často vede k nedorozumění mezi zadavateli a vývojem, protože zadavatelé projektu často nevidí výsledek dřív než těsně před koncem. Vývojáři vnímali dost negativně přesuny mezi různými projekty, nebo paralelní práci na více projektech. Projektový manažer musel mít technickou znalost požadavků a strávil spoustu času na analýze požadavků, aby byl schopen jej estimovat a naplánovat. Scrum umožňuje rozložit zátěž projektu konstantně, aby nedocházelo k velkému pracovnímu vytížení těsně před vydáním produktu. Jasně stanovené role a odpovědnosti v týmech, které byli často nejasné. Jasně stanovené pravidla Scrum schůzek a především jejich obsahu. Inspirace v jiných firmách o stejné velikosti, které vyvíjí software podobného rozsahu. Částečně bylo potřeba Scrum přizpůsobit tak, aby odpovídal typům projektů, a způsobu jakým spolupracujeme s externími týmy po celém světě. 25

26 3.14. Hlavní pojmy metodologie Scrum Scrum tým Nejdůležitějším prvkem Scrumu je tým. Tým se skládá ze 7 až 9 lidí. Je to pouze doporučená velikost, ovšem není dobré ji překračovat z důvodu složitého plánování a dlouho trvajících schůzek při více členech Sprint Hlavní časovou jednotkou ve Scrumu je takzvaný sprint. Scrum je iterační a právě jedna iterace se nazývá sprint. Obvykle jeden sprint trvá od jednoho týdne až po jeden měsíc. Sprint je ohraničený časový úsek, na který tým plánuje a ve kterém pracuje na požadavcích. Po konci sprintu musí tým předvést funkční produkt a mít všechny požadavky, které byly na daný sprint naplánované zcela hotové. Na konci každého sprintu probíhá plánování na další sprint a retrospektiva a zhodnocení předchozího sprintu Produkt backlog Hlavním prvkem Scrumu je Product backlog (seznam požadavků na produkt), který obsahuje všechny požadavky na implementaci od produktového manažera. Každý záznam v Product backlogu má svou vlastní unikátní prioritu. Každý požadavek musí být řádně časově odhadnutý a musí mít sepsanou specifikaci, kterou připraví například architekti. V případě, že je požadavek moc velký a nelze jej umístit do jednoho sprintu, dochází k jeho rozpadu na funkční celky. Správcem Product backlogu je výhradně produktový manažer, který je jeho majitelem a odpovídá za jeho obsah. Úlohou projektového manažera je vycházet z Product backlogu a správně naplánovat všechny položky tak, aby je bylo možné implementovat. Všechny požadavky, které se mají plánovat v rámci sprint plánování, musí být kompletní a s časovou estimací. Pokud je požadavek na více než jeden tým, což u komponentního rozdělení téměř vždy, je třeba estimovat jeho jednotlivé části za každý tým. Pokud se některá část požadavku nevleze do okna sprintu, je třeba požadavek rozdělit na dva funkční celky, které se dají udělat zvlášť a zároveň jsou oba testovatelné a plně funkční. Mnohem jednodušší je pro požadavky funkční rozdělení týmů, kdy se celý požadavek implementuje pouze v rámci jednoho týdne a není ho potřeba rozdělovat na několik týmů Sprint backlog Sprint backlog se liší od Product backlogu tím, že obsahuje pouze požadavky, které bude tým implementovat v daný sprint. Je podmnožinou Product backlogu. Požadavky ve Sprint backlogu se mohou rozpadnout na menší, aby je bylo možné implementovat právě v rámci jednoho sprintu. Výsledkem jednoho sprintu ovšem musí být funkční a testovatelný požadavek, nebo jeho část. 26

27 Scrum master Úkolem Scrum Mastera je vést všechni Scrum schůzky a starat se o Sprint backlog. Scrum master je součástí týmu. Většinou je to vývojář nebo tester, který je z padesáti procent alokovaný na práci Scrum mastera a má za sebou školení úspěšně zakončené certifikátem Scrum schůzky Scrum schůzky se organizují v každém sprintu. Jejich hlavními úkoly jsou včas rozpoznat začínající problémy, ověřit si pochopení přidělených úkolů u jednotlivých členů týmu a v neposlední řadě také zlepšit osobní nasazení jednotlivých členů týmu v jim přidělených úkolech Daily Scrum meeting Nejčastější z nich je Daily Scrum meeting, denní schůzka, která trvá maximálně patnáct minut a každý z členů týmů řekne ostatním ve zkratce, na čem pracoval předchozí den, na čem bude pracovat aktuální den a zda se nevyskytly nějaké problémy, které by mohly ohrozit splnění jemu přiděleného úkolu. Forma: schůzka vestoje Účastníci: Scrum tým, Product owner Trvání: maximálně 15 minut Obsah: každý člen řekne: Co dělal včera. Co bude dělat dnes. Jestli něco blokuje jeho práci. Jaké detaily zmínit: Požadavky: velmi krátké shrnutí ("jedna věta") o čem požadavek je (nebo jeho jméno), na jakém úkolu člen týmu pracuje (specifikace, implementace, dokumentace, testování) Defekt: velmi krátký popis v jakých situacích problém nastává, aktuální stav defektu (analýza, defekt opraven, testování) Pokud je další diskuze zapotřebí, Scrum master naplánuje další diskuzi až po skončení Daily Scrum meetingu a pozve pouze zainteresované členy týmu. Pokud došlo na blokování práce, je třeba probrat, čím je práce blokována a kdo si vezme tento problém na starost. Co si připravit: členové týmu: odpověď na tři otázky zmíněné výše 27

28 Sprint planning meeting Sprint planning meeting, je schůzka, kde dochází k již zmíněnému rozpadu Product backlogu na jednotlivé úkoly pro daný Sprint. Rozdělování úkolů mezi členy týmu přitom může probíhat jak direktivně, tak demokraticky. Během této první schůzky, která by měla trvat maximálně osm hodin, se také (po rozdělení úkolů) dospěje k celkové časové náročnosti daného Sprintu. Účastníci: Scrum tým, Product owner Obsah: na základě priorit naplánovat Sprint backlog z požadavků v Product backlogu Vstup: Product backlog Prioritizované úkoly s estimacemi Prioritizované defekty s estimacemi Plánovací proces Plánovací proces spočívá v průchodu Product backlogem ( story, defekty, tasky), které byli analyzovány a estimovány na Backlog grooming meetingu Po této kontrole budou požadavky bez závislostí naplánovány do sprintu Sprint review meeting Po skončení Sprintu pak následuje Sprint review Meeting, kdy se shrne vše, co v daném Sprintu bylo a nebylo dokončeno a proběhne prezentace hotového funkčního celku zákazníkovi/zadavateli. Tento meeting by měl trvat maximálně 4 hodiny. Účastníci: Scrum tým, Product owner Obsah: prezentace požadavků implementovaných během sprintu Požadavky: živá ukázka nebo video ukazující novou funkčnost. Co si připravit: členové týmu: informace k hotovým úkolům 28

29 Sprint retrospective meeting Posledním meetingem v řadě je pak Sprint retrospective, kterého se zúčastní všichni členové týmu včetně projektového manažera. Toto setkání by přitom mělo přinést odpovědi na otázky, jak probíhal právě dokončený Sprint, kdo při něm pracoval dobře a co by šlo v příštím Sprintu zlepšit. Délka této schůzky by neměla přesáhnout tři hodiny. Účastníci: Scrum tým, Product owner Dobra trvání: 1 hodina Obsah: Co bylo dobré na předchozím sprintu a mělo by tak zůstat nadále Co nebylo dobré a je potřeba to změnit Identifikujte nejzávažnější problémy a navrhněte řešení Každý člen týmu řekne své poznatky a moderátor je zapíše Společně tým projde 2-3 nejzávažnější problémy a pokusí se najít společné řešení Co si připravit: člen týmu a Product owner: nejzávažnější problémy, které během sprintu nastaly Konec a plánování sprintu se nejvíce osvědčilo mít ve středu nebo čtvrtek, protože po plánování má tým ještě jeden až dva dny nového sprintu ve stejném dni, což vývojářům nejvíce vyhovovalo. Navíc je plánování časově náročně a může se protáhnout, proto není pátek ideálním dnem pro plánování sprintu a pondělí jako začátek. Daily status meeting probíhá každý den dopoledne. Celý meeting trvá nejdéle patnáct minut. V první fázi každý čtvrtek probíhá zhodnocení sprintu na Sprint review meetingu. Po Sprint review přichází na řadu Sprint planning meeting. 29

30 Scrum of Scrum meeting Jelikož vznikají závislosti mezi týmy a je potřeba často řešit předávání práce mezi týmy, byl zaveden Scrum of Scrum meeting, jehož účelem je řešit všechny externí problémy týmu, popřípadě i interní, pokud ta možnost je. Na tuto schůzku chodí pouze Scrum master z každého týmu a projektový manažer každého projektu. Řeší se především závislosti a hlavně problémy, které navazují na jiné týmy. Účastníci: Scrum master každého involvovaného týmu, projektový manažer Obsah: prezentace požadavků implementovaných během sprintu, externích závislostí mezi týmy a externích dodávek Požadavky: Seznam požadavků implementovaných ve sprintu, seznam externích závislostí a problému, které blokují tým v realizaci požadavků. Co si připravit: Scrum master: informace k probíhajícím úkolům v týmu Burndown graf V klasickém plánování máme k dispozici Ganttův diagram, který nám ukazuje kritickou cestu projektu. Ve Scrumu ovšem Ganttův diagram k dispozici není, ale máme takzvaný Burndown graf, který dokáže zcela jinak zobrazit časovou náročnost daného sprintu. Na ose x zobrazuje celkový počet dní zbývajících do konce Sprintu a na ose y ukazuje celkový počet hodin na každého vývojáře, zbývajících do splnění všech úkolů v daném Sprintu. Obrázek 4: Ukázka Burndown grafu 30 Zdroj: Vlastní, obrazovka ze systému JIRA

31 Úsečka spojující body se souřadnicemi [Celkem zbývajících hodin, 0 dnů] a [0 zbývajících hodin, celkový počet dnů] se nazývá Ideal Burndown a ukazuje hypotetický ideální průběh prací pro splnění příslušného termínu. Kromě ní je na grafu zobrazena také křivka skutečného počtu zbývajících hodin, která se odvozuje od celkového součtu zbývajících hodin pro splnění jednotlivých úkolů v daný den. Tento počet se přitom může i zvyšovat, a to tehdy, kdy došlo ke špatnému odhadu pracnosti některého z úkolů anebo v okamžiku, kdy byla při rozpadu funkce z Product backlogu na úkoly udělána chyba. Pokud se tato křivka nachází pod křivkou Ideal Burndown, je projekt v předstihu, pokud nad ní, má projekt zpoždění. Výhodou tohoto grafického znázornění je přitom fakt, že každý den lze křivku skutečného počtu zbývajících hodin proložit regresní křivkou, která nám ukáže, jak si na tom aktuálně stojíme v porovnání s vytyčeným datem dokončení. V případě, kdy tak Burndown graf indikuje několik dní po sobě zpoždění, má projektový manažer možnost analyzovat nejkritičtější (tj. nejdéle trvající) úkoly a přidělit k nim další členy týmu, aby se zpoždění začalo včas dohánět. Tyto základní pojmy je třeba znát a především dodržovat pro správný chod Scrum metodologie v týmech. Scrum nabízí pouze obecný pohled na způsob jak pracovat agilně. Dále je možné si Scrum upravit tak, aby vyhovoval danému prostředí. Ovšem výše jmenované pojmy by měli zůstat zachovány. Obrázek 5 : Postup práce ve Scrumu Zdroj: Vlastní 31

32 4. Zavádění agilních metod O agilních metodách a Scrumu existuje nespočet knížek a volně dostupných článků, které vysvětlují agilní metody poměrně dopodrobna. Co mi ovšem chybělo, byl nějaký praktický pohled, jak zavést Scrum na vývoji, který pracuje ve vodopádovém modelu, aniž bych paralyzoval celý vývoj na týdny až měsíce a poškodil tak celou firmu. Zavést agilní metody je mnohem jednodušší, pokud s nimi vývoj začíná zcela od svého začátku, což není případ vývoje ve firmě z mé zkušenosti, která používala vodopádový model předchozích deset let. Problémy aktuálního vývoje byly již všechny objasněny v předchozích kapitolách i s lehkým úvodem do agilních metod a metodologie Scrum. Vše to jsou nutné a základní znalosti, které je třeba vědět, než se zaváděním agilních metod vůbec začne. Existuje také spousta problémů a nejasností, na které se přijde až během zavádění. Teorie je v knihách velmi obecná a často vynechává některé praktické problémy, které řešit obecně neumí. Například problém s externími týmy, které budou nadále pracovat ve vodopádovém modelu. Rozhodl jsem se proto napsat ukázku toho, jak taková transformace probíhá v praxi. Podle výsledků také zhodnotit pozitiva, které přechod přinesl a problémy, které bylo třeba operativně řešit během přechodu Stav vývoje před první fází přechodu - vodopádový model Obecným problémům vývoje ve vodopádovém modelu se věnuje několik předchozích kapitol. Problém není pouze samotné plánování, ale také výsledný software, který týmy tvoří je dostatečně ovlivněn modelem, podle kterého se vyvíjí. U vodopádového modelu a komponentního rozložení týmů dochází ke zvyšování kvality vrstev software na úkor kvality požadavků. Každý tým spravuje svou vrstvu produktu a část nového požadavku určenou pro jejich vrstvu správně implementuje. Problém ovšem často nastává na rozhraní vrstev, kde vzniká většina chyb. Příkladem může být zobrazení výsledků kontroly počítače, kde je kontrola implementovaná správně, zobrazení ve vrstvě grafického rozhraní také, ale chyba může nastat v integraci, tedy někde přesně mezi těmito vrstvami. Komponentní týmy se více soustředí na architekturu svých vrstev než na integraci vrstev. Hlavní problémy Externí závislosti Testeři nejsou součástí týmů na vývoji Specialisté nejen na určitou komponentu, ale dost často i pouze na část komponenty. Velký vodopád, závislosti mezi více než dvěma týmy Chybějící dokumentace Celý tým je zodpovědný za architekturu a konzistenci vrstvy. Je potřeba architekt. 32

33 Cílem je postupně přenést vývoj směrem k agilnímu způsobu plánování. Hlavními pravidlem, kterým je třeba se řídit je Evoluce, ne revoluce. Zavádění agilních metod je iteračním procesem sám o sobě a v každé iteraci se řeší problémy a stabilizuje se stav. Dokud není první fáze zvládnutá na sto procent, není možné pokračovat fází druhou Přechod vývoje na agilní metody agilním způsobem Pro zavedení agilních metod jsme se rozhodli použít agilní přístup. Na základě toho, kam se chceme nakonec dostat, vznikl set požadavků kroků, které musí vývoj splňovat, aby se dal považovat za zcela agilní. Tento set jsme rozdělili do dvou fází, nejen podle priorit, ale taky podle toho, jestli je možné požadavky splnit jako celky v rámci jedné fáze. Pravidelné schůzky a neustálá evaluace změn probíhala aktivně prakticky každý den. Proces zavádění agilních metod je iterativním procesem, kdy se v každé iteraci objeví nové problémy, které je potřeba řešit aby byl vývoj efektivnější a agilnější. Fáze 1 je především o seznámení se Scrumem a naučení se ho používat v praxi. V této fázi se týmy ve starém komponentním rozložení naučili základy Scrumu, dodržování sprintů a agilní plánování v rámci svého týmu. Vývoj jako takový se sice skládal z několika agilních týmů, ale pořád jako celek fungoval ve vodopádovém plánování, protože bylo stále potřeba synchronizovat týmy a řešit závislosti v komponentách. Výsledkem bylo naučení se Scrum metodologie, objevení nedostatků ve Scrumu, které vývoji nevyhovují a seznam nedostatků v agilním plánování, které je potřeba vyřešit. Fáze 2 je o navržení funkčních týmů, zavedení Scrumu skrz všechny vývojové týmy a sestavení nových týmů, zavedení skutečného agilního plánování a začít používat agilní plánovací nástroje. Výsledkem by měl být plně funkční agilní vývoj software. 33

34 5. Fáze 1 Agilní komponentní týmy Zavádění agilních metod a kompletní změna postupu práce celého vývoje je velice riskantní a mělo by se postupovat velice opatrně. Proto jsme se rozhodli rozdělit zavádění agilních metod do dvou fází. V první části zůstali týmy ve stejném složení a navenek pořád pracovali ve vodopádovém modelu. Velká změna ovšem nastala uvnitř týmu, kde jsme postupně zavedli Scrum. Podstatou první fáze bylo, naučit se přemýšlet agilně, zavést a ustálit všechny agilní schůzky, naučit se používat agilní nástroje a především se naučit agilně plánovat. Výsledkem první fáze tedy bylo si prvně Scrum a agilní přístup pouze nanečisto vyzkoušet. Vývoj nadále fungoval vodopádovým modelem. Týmy stále zůstávají v komponentním rozložení. Jedinou personální změnou je, že z jednoho člena týmu je Scrum master na poloviční úvazek. Nástroje zůstávají pořád stejné, nadále se používá Bugzilla a Sharepoint jako dva hlavní plánovací nástroje. Hlavní změnou tedy je nasazení Scrumu ve všech týmech, které mají zájem Scrum zkusit. Důležitým aspektem nasazení je týmy ke změně na Scrum nenutit, aby se nevybudoval přirozený odpor členů týmů, proto bylo nasazení Scrumu ze začátku dobrovolné. Dalším prioritním úkolem v první fázi je postupné přecházení od specialistů v týmu k agilním týmům. Agilní plánování v týmu specialistů je problém jak v případě komponentních, tak funkčních týmů a je třeba se tomuto postupně vyvarovat ještě před přechodem na funkční týmy a plné agilní plánování. Obrázek 6: Implementace jednoho požadavku v komponentním rozložení vývoje v týmech fungujících ve Scrumu. Zdroj: Vlastní 34

35 Tato fáze přechodu by měla trvat tři až čtyři měsíce, aby se lidé v týmech naučili základy Scrumu a práci v iteracích a sprintech. Definoval jsem 14 hlavních aspektů, ve kterých se musí komponentní týmy zlepšit, aby dosáhly lepších výsledků a mohli pracovat agilněji a přiblížili se tak konečnému výsledku pro další fázi transformace. 1. Lidé z různých týmů a oddělení musí komunikovat napřímo, nechodit přes své nadřízené nebo management. 2. Musí být definovány pravidla pro integraci komponent a jasné pokyny pro integraci komponenty mezi dvěma komponentními týmy. 3. Vytvořit jednotnou definici hotového požadavku. 4. Plánování pro další iteraci, takzvaný Iteration planning meeting. Všechny týmy musí společně projít požadavky v Product backlogu a připravit se na další iteraci rozdělením požadavků mezi týmy a sjednotit data dodání jednotlivých částí. Tento přístup způsobuje malé vodopády v plánování, ovšem je to nejlepší co je možné s komponentními týmy dosáhnout. V případě, že jde o závislost pouze mezi dvěma týmy, jedná se o malý vodopád, který se dá jednoduše plánovat a není velkým riskem. 5. Je třeba společně rozdělit velké požadavky, které se nevejdou do časového okna jednoho sprintu a rozdělit je tak, aby vznikaly co nejmenší závislosti mezi týmy. 6. Scrum of Scrum je použito především pro synchronizaci práce mezi týmy. 7. Mezi týmové retrospektivy pořádané jednou za iteraci, kterých by se měli účastni zástupci všech týmů všech oddělení. 8. Vybudovat tým architektů zodpovědných za architekturu komponent a všech vrstev software. Zároveň je úkolem architektů kontrolovat dokumentaci a stanovit pravidla konvencí kódu. 9. Snažit se eliminovat specialisty v týmech. Existující dokumentace je skvělý způsob jak začít. 10. Co největší podíl automatických testů oproti manuálním. 11. Testování kódu přímo v týmu testerem. Tímto bodem se zruší poměrně velká část původního vodopádu. Testování v rámci týmu eliminuje čekání na otestování kódu a snižuje čas reakce opravy chyby na minimum a to zlepšuje i kvalitu produktu. 12. Existující Sprint backlog 13. Existující Produkt backlog, ve kterém jsou požadavky řazeny podle unikátních priorit 14. Dokumentace, automatické testy a vysoké pokrytí kódu unit testem. 35

36 5.1. Sprint Sprint by měl mít prvních pár týdnů po zavedení délku ideálně jeden týden. Je to hned z několika důvodů. Prvním z nich je, aby si vývojáři zvykli na Scrum schůzky a prošli ze začátku co nejvíce sprinty. Dalším je, aby si team leader a Scrum master zvykli na svou roli v týmu a způsob plánování. A v neposlední řadě je ze začátku dobrá zpětná vazba od vývojářů a zjišťovat tak chyby na týdenní bázi. Problém je, že se požadavky obvykle do jednoho týdne časově nevlezou. Dalším problémem je mrhání zdrojů, protože režie na zastavení, zhodnocení ukončeného sprintu a režie na naplánování nového je poměrně velká, protože stojí celý jeden den celého týmu (viz. Scrum schůzky). Jako ideální v další fázi je použít dvoutýdenní sprinty, které se zavedly po deseti jednotýdenních sprintech Iterace v první fázi Protože plánování celé společnosti stále probíhalo na úrovni dlouhodobého plánování na několik měsíců dopředu, bylo potřeba zavést synchronizační prvek, který by dokázal agilně plánovat v rámci agilních týmů, ale zároveň dodával plán pro zbytek neagilní společnosti. Vznikly iterační meetingy, na kterých se definoval obsah práce na následující 4 týdny. Výstupem iteračního meetingu je Iteration backlog obsahující požadavky, které se budou během iterace implementovat a pro které je potřeba dodat veškeré externí vstupy. Iteračního plánování se účastní všichni zástupci za jednotlivá oddělení od vývoje až po oddělení péče o zákazníky Plánování v komponentních týmech Vývoj není jediným oddělením firmy a musí spolupracovat s externími odděleními jak v Praze, tak Izraeli nebo například v USA a Amsterodamu. Problémem ovšem je, že pouze naše oddělení bude fungovat agilně, zatímco ostatní oddělení dále vodopádem. Je potřeba využít znalostí z plánování ve vodopádu a oddělení s rozdílným přístupem plánování sjednotit. Jsou dvě možnosti spolupráce. První je, začít externí tým vnímat jako externí zdroj, který nám dodává výsledek k určitému datu, které patří někam do našeho sprintu. Nebo druhý agilnější přístup je využít mikro týmů pokud to externí oddělení povolí a potřebné zdroje si půjčit po dobu jednoho sprintu přímo do týmu. V každém případě je důležité všechny oddělení držet synchronizované určitým plánem. Tímto plánem, který funguje mezi agilními a neagilními týmy je iterační plán vytvořený na iteračním meetingu. Jedna iterace by měla trvat dva sprinty. V našem případě je to přesně měsíc dlouhá iterace. 36

37 5.4. Plánování iterace Plánování iterace probíhá jednou měsíčně a slouží především k synchronizaci všech oddělení, které spolu pracují na jednom požadavku. Iterací se nazývá plánovací období na jeden měsíc, většinou tedy dva sprinty. Tohoto plánování se účastní zástupci za všechny oddělení nebo týmy, které jsou potřeba u kteréhokoliv požadavku. Vstupem do iteračního plánování je podle priorit seřazený Product backlog s požadavky a výstupem naplánovaná iterace. Výstupem je Iteration backlog a počátečníma estimacema času a pořadím v jakém se budou jednotlivé požadavky řešit. Z tohoto backlogu se pak tvoří Sprint backlog v každém týmu. Na konci každé iterace by měl být produkt, který je testovatelný a vydatelný, ovšem tato podmínka bude splněna až ve druhé fázi přechodu. Obrázek 7 : Iterace sestávající ze dvou sprintů Zdroj: vlastní 5.5. Plánování sprintů Po naplánování iterace je jasný Product backlog, ze kterého je nyní potřeba naplánovat sprint. Sprint se plánuje na konci posledního dne starého sprintu. Pokud sprint trvá dva týdny, tak se plánuje přesně co druhý týden. Sprint se plánuje podle kapacity týmu. Pravidlem, které jsme stanovili, bylo, že se kapacita týmu musí rozdělit mezi nové požadavky, opravu existujících chyb, dokumentaci a rezervu na dovolené. Poměr 37

38 je dynamický a dá se podle potřeb měnit v každém sprintu. Výsledkem tohoto plánování je takzvaný Scrum board, což je tabule s požadavky, které jsou naplánované v daném sprintu a jsou již přidělené vývojářům. Každý vývojář poté posunuje lístečky s požadavky nebo chybami podle toho, v jakém jsou aktuálně stavu, až lísteček dostanou do stavu, který bude splňovat definici hotového požadavku, tak lísteček zahodí a berou si další požadavek z tabule. Příklad časového rozdělení sprintu: 20% času na nové požadavky 45% času na opravu chyb 25% času na dokumentaci a technický dluh 10% času jako rezerva na dovolené Obrázek 8: Scrum board ve vývojovém týmu obsahující naplánovaný sprint Zdroj: Vlastní, fotografie z kanceláře vývojového týmu 38

39 5.6. Eliminace specialistů ve Scrum týmu Většina softwarových produktů má své specialisty, kteří jsou dobří v určité oblasti produktu a jsou ve své podstatě nenahraditelní. Tato nezastupitelnost není jen velkým riskem pro projekt obecně, ale rovněž je obrovskou nevýhodou pro agilní plánování týmů. Většinou argument, že tento přístup je, proti agilním metodám k přesvědčení specialistů nestačí, protože to během plánování jednotlivých sprintů může vypadat, že žádný problém neexistuje a že jsou specialisté pro tým výhodní, protože umí problém řešit mnohem rychleji. Po podrobném prozkoumání několika předešlých sprintů je ovšem jasné, že jsou úzkým hrdlem celého vývoje a nejen svého týmu. Přesně takováto situace je v prezentované firmě, kdy se produkt již dlouhou dobu vyvíjí a vznikla tak spousta specialistů na určité části produktu. Nejlepším způsobem, jak dokázat, že plánování se specialisty nefunguje, je přesná ukázka na reálném příkladu. Na reálnou ukázku stačí 5 sprintů plánování, estimace časového výkonu jednoho specialisty na sprint a Sprint backlog s požadavky. Použitý a demonstrativní příklad je uveden v přílohách práce. Další problémy, ke kterým vede tým specialistů: Tým pracuje více jako skupina individualistů Tým nemá náhradu za specialistu, který odjede na dovolenou nebo odejde z firmy. Samostatná organizace týmu prakticky neexistuje, tým se není schopen účinně rozhodovat jak jednotlivé požadavky implementovat. Z krátkodobého pohledu je tým specialistů ideální, protože řeší problémy produktu rychleji, ovšem z dlouhodobého hlediska může vést k velice vážným problémům v plánování zdrojů a jejich nahraditelnosti. U komplexních produktů se nedá specialistům zcela vyhnout. Z mého zjištění je jediným použitelným řešením postupné šíření znalosti alespoň na některé členy týmů Definice hotového požadavku Velice brzo se narazilo na problém společného chápání hotového požadavku. Každý tým si vytvořil jinou množinu úkonů, které definovaly požadavek jako hotový. Bylo potřeba sjednotit pojmy a stavy života požadavku. Požadavek je ve stavu implementovaný až v momentě, kdy na jsou hotové i jeho Unit testy a kód je pokryt alespoň ze 70% a integrační testy pokrývají alespoň pozitivní cestu. Je provedena kontrola kódu jiným členem týmu. Požadavek je zdokumentovaný. 39

40 5.8. Analýza nového požadavku 1) Analýza sepsána jako textový dokument, který obsahuje datum a jméno autora 2) Obsahuje následující sekce: a) Aktuální stav b) Cíle a úkoly c) Navrhované řešení d) Časovou estimaci e) Risk 3) Dokument byl zkontrolován jiným členem týmu 4) Dokument byl nahrán na Sharepoint Analýza existujícího požadavku 1) Analýza je sepsána jako textový dokument, který obsahuje datum a jméno autora 2) Obsahuje následující: i) Obrázek grafického rozhraní ii) Informace o konfiguraci (1) Obsah (2) Lokace registračních klíčů 3) Závislosti a) Soubory i) Jména ii) Lokace b) Funkcionalitu i) Třídy ii) Funkce 4) Dokument byl zkontrolován jiným členem týmu 5) Dokument byl nahrán na Sharepoint 40

41 5.9. Definice hotového požadavku Pouze požadavek splňující tuto definici může být umístěn do hlavní větve verzovacího systému, odkud se vytváří celý produkt. 1) Kód byl zrevidován členem týmu. 2) Dokumentace byla vytvořena. 3) Unit testy kódu prošly bez problémů. 4) Změny v kódu jsou umístěny ve správné větvi verzovacího systému. 5) Stav požadavku byl nastaven ve všech management systémech. 6) Build server nehlásí žádnou chybu při sestavení kódu. 7) Požadavek byl otestován z funkčního hlediska uživatele 8) Opravy chyb byly otestovány 9) Chyby byly ověřeny na produkční verzi produktu 10) Sanity testy prošly bez zásadních chyb 11) Testování regrese bylo definováno a schváleno QA Supervisorem 12) Interní regresní testy byly úspěšně provedeny Testování jako součást vývoje Jeden z nejdůležitějších kroků bylo zavést testování jako součást vývoje. Původní stav byl takový, že na testování existovalo pouze externí oddělení a naprosto vše od drobných defektů až po testování produktu jako celku se dělo na oddělení testování. Největším problémem byla pomalá zpětná vazba. Nejčastěji se to projevovalo u defektů, které byly opraveny, ale otestovány a verifikovány až o mnoho týdnů později. V případě, že byla oprava provedená špatně, tak byl defekt znovu otevřen například po dvou měsících, kdy vývojář, který defekt opravoval, už ztratil povědomí o kódu a oprava trvala i čtyřikrát déle, než kdyby byl defekt verifikován druhý den od opravy. Navíc takto docházelo k nahromadění defektů k opravě před samotným vydáním nové verze antiviru a tím pádem docházelo k velkému risku. Přidělení testera přímo do vývojového týmu přináší mnoho výhod: rychlá odezva na chyby v kódu odpadá neefektivní komunikace přes Bugzillu menší režie na plánování testování čas strávený na testování se zahrnuje do času vývoje lepší komunikace mezi testerem a developerem 41

42 5.11. Rozdělení testování na interní a externí Po přiřazení testerů do každého Scrum týmu, klasicky dva testeři na jeden tým, bylo nutné jasně definovat jejich povinnosti a rozdělit testování, které se bude provádět v rámci týmu a v rámci externího oddělení. Vzniklo tak rozdělení na interní a externí QA (Quality Assurance tým testování kvality produktu). Interní QA (testeři ve vývojových týmech): Testování všech oprav defektů opravy chyb nalezených v produktu opravy chyb nalezených během testování nových požadavků Testování všech nových požadavků testování všech částí vytvořených v rámci týmu finální testování požadavku jako celku Externí QA (quality assurance oddělení) tým má na starosti především tyto hlavní úkoly: Verifikace buildu Finální ověření před samotným vydáním regresní testování Verifikace defektů Ověření defektů v týmech, kde není tester Výpomoc na verifikaci defektů týmům, které nestíhají testovat Výpomoc s akceptačním testováním požadavků 42

43 5.12. Souhrn kroků provedených při první fázi přechodu: komponentní rozložení týmů bylo zachováno. Nebyly provedeny žádné personální změny v týmech. Smyslem je přesvědčit stávající týmy o výhodách agilního přístupu a naučit se základy Scrumu bez většího risku. začít pro plánování používat Scrum board zavést Scrum daily status meeting, Scrum retrospective meeting, Scrum planing meeting, Scrum of Scrum meeting. zavést pozici Scrum master Zavést alespoň externě prvního testera, který bude členem vývojového týmu a bude spolupracovat na denní bázi a účastnit se Daily Scrum meetingu zavést iterační plánování na 1 měsíc dopředu kvůli synchronizaci mezi odděleními Výsledek a hodnocení první fáze přechodu Výsledek přechodu, jak jej vnímají sami vývojáři, jsem sesbíral na retrospektivních schůzkách, kde se několik prvních sprintů řešil především přechod na Scrum. V první fázi šlo spíše o seznámení se Scrumem a lehké zabruslení do agilních metod, které přineslo jasný obraz o tom, co je potřeba vylepšit než se na Scrum opravdu přejde. První fáze trvala pět měsíců a měla celkem 14 sprintů. První dva měsíce trval jeden sprint pouze týden, aby došlo k rychlému seznámení se Scrumem a plánováním. Iterací bylo celkem pět, každá trvala měsíc. Některé poznatky o výhodách a nevýhodách Scrumu a agilního přístupu v první fázi: lepší měřitelnost oddělané práce přechod obecně vnímán pozitivně vývojáři se rádi účastní plánování estimace na jednotlivé úkoly jsou stanoveny vývojáři a jsou přesnější tým ví náplň své páce na další dva týdny dopředu obrovskou výhodou je testování přímo v týmu tým má víc času na technický dluh je více času na psaní dokumentace, což vede ke snížení specialistů v týmu rozdělení práce na jednotlivé požadavky, které se dají stihnout do jednoho sprintu tým dočasně funguje i bez vedoucího týmu, protože každý ví, co má přesně dělat 43

44 Samozřejmě sebou první fáze přinesla i několik nových poznatků o nevýhodách. Některé jsou pouze dočasné a způsobené tím, že vývoj nepracuje ve funkčních týmech, jiné jsou dány už z definice samotného Scrumu. mnohem větší administrace týmy jsou stále pouze komponentní celý jeden den na konci sprintu je pouze o plánování spousta schůzek týmy zatím nefungují moc agilně, stále vznikají závislosti díky komponentnímu rozložení nedaří se eliminovat specialisty, každý specialista si bere pouze takové úkoly z backlogu kterým rozumí a neučí se jiné části produktu stále se používá Bugzilla a Sharepoint nejasné role, které se často překrývají zatím neexistoval tým architektů, kteří by spravovali architekturu produktu na závěr iterace stále není hotový a vydatelný produkt Konečným zhodnocením první fáze je, že se většina vývoje seznámila se Scrumem a agilním způsobem vývoje. Dobrovolně se přidala většina týmů a několik lidí podstoupilo školení na Scrum mastera. Důležitým krokem, který dopadl dobře, bylo zavedení iteračního plánování, ve kterém se bude pokračovat i ve druhé fázi přechodu. 44

45 6. Fáze 2 přechod na agilní vývoj a funkční týmy Druhá fáze vývoje navazuje na předchozí fázi, která byla spíše naučná. V druhé fázi došlo k radikálnějším změnám, které bylo potřeba udělat, aby mohl vývoj fungovat skutečně agilně. Největší změnou v této fázi bylo přestavění týmů z komponentních na funkční týmy a vytvoření týmu architektů. Přechod na Funkční týmy znamenal kompletní předělání všech týmů a přesun vývojářů. Dalším velkým krokem bylo přijetí testerů přímo do vývojových týmů, aby mohla probíhat úzká spolupráce vývoje a testování. Obrovskou změnu doznal i celkový proces (tzn. pracovní postup), podle kterého se bude dále pracovat a samozřejmě management nástroje, které se budou používat nadále místo Bugzilly, Shrepointu a Accompy. Splnění nejdůležitějších kroků druhé fáze přechodu od vymyšlení vhodného procesu až po reorganizaci týmů na funkční týmy trvalo dva měsíce a stále iterativně pokračuje pro menší změny. Souhrn kroků pro druhou fázi Vytvoření funkčních týmů, testeři součástí týmů Vytvoření týmu architektů Re-organizace struktury projektového managementu Změna procesů vývoje Změna plánování na agilní ( Iterace, Sprint, Grooming meeting) Výběr nového Projekt Management systému Nasazení Project Management systému s podporou pro agilní metody Monitoring týmu a vytvoření KPI (tzv. Key Performance Indicator) 6.1. Funkční týmy Všechny vývojové týmy byly rozděleny do stejného počtu funkčních týmů. Každý funkční tým obsahoval 1-2 členy z každého komponentního týmu, což dalo ve výsledku 6-7 vývojářů a 2 testery, celkově tedy 8-9 členů týmu. Funkční týmy mají obrovskou výhodu, protože tím, že mají specialisty z každé komponenty produktu, získaly vědomost na vytvoření kompletního požadavku od grafického rozhraní až po instalaci. Tím pádem se netvoří závislosti tak jako mezi komponentními týmy. Funkční tým je již skutečně agilním týmem, protože je schopen realizovat celý požadavek od analýzy až po otestování implementace, protože se skládají z vývojářů a testerů. Samozřejmě jsou požadavky, které potřebují externí vstupy, například podklady UI designéra a musí tím pádem čekat na dodání, než se začne s implementací. K řešení právě těchto závislostí slouží plánování iterace, kdy se externí závislosti řeší o sprint dříve než implementace ve funkčním týmu. 45

46 Obrázek 9: Implementace požadavku ve funkčních týmech Zdroj: Vlastní 6.2. Role Se změnou týmů přišla i změna definice řídících rolí v rámci projektů. Vznikla takzvaná Project Steering Group, která je odpovědná za vedení celého projektu. Tato skupina má za úkol dodávat vstupy a požadavky pro týmy, řešit analýzu požadavků, monitorovat průběh vývoje v týmech a kontrolovat kvalitu výstupu týmů. Vedle této skupiny stojí programový manažer, který získává aktuální status projektu právě od Project steering skupiny. Obrázek 10: Rozdělení rolí ve společnosti v rámci vývoje 46 Zdroj: Vlastní

47 6.3. Organizace řízení projektů Celková organizace řízení projektů se vždy skládá z vývojových týmů pro každý projekt, které spolupracují se Project Steering Group (PSG) skupinou dedikovanou pro tento projekt a samozřejmě s daným programovým manažerem. Do vývoje zasahují dále také externí týmy, které doručují materiály potřebné k implementaci projektů Project Steering Group Skupina rolí zodpovědných za celý projekt a produkt od sběru požadavků, implementaci až po otestování. Členy této skupiny jsou Produktový manažer (Product Manager), který ve skupině plní roli sběru požadavků na výsledný produkt. Projektový manažer (Project manager), který je zodpovědný za monitorování průběhu realizace projektu a podávání reportů. Architekt, který je zodpovědný za technický návrh řešení a hlídání implementace produktu. Kontrolor kvality je zodpovědný za kvalitu produktu jako celku včetně externích částí produktu, které vyvíjí externí týmy. Projektový a prduktový manažer z této skupiny komunikuje s programovým manažerem, který je na daný projekt přiřazen. Nejdůležitější součástí jsou samozřejmě vývojové týmy, které realizují implementaci produktu. Hlavní rolí v takovém týmu je vedoucí týmu (Team leader), další rolí je Scrum master a vývojáři samotní. Role a jejich důležitost bude popsána podrobněji na další straně Scrum tým Je tým, ve kterém je Product owner (Produktový manažer), Scrum master a vývojový tým. Funkční tým vývojářů a testerů zodpovědných za implementaci požadavků v každém sprintu. Na konci každého sprintu by měl být tým schopen doručit plně otestovaný a rozšířený produkt, který se dá vydat Product owner Je role zodpovědná za Produkt Backlog, která reprezentuje zájmy vlastníků a zajišťuje požadavky pro vývojové týmy daného projektu. Často je tato role zastoupena Produktovým manažerem Scrum master Je člověk uvnitř vývojového týmu, který má na starost veškeré Scrum procesy a schůzky, kontroluje dodržování Scrumu v týmu aby přinášel co nejlepší výsledky a benefity. Reálně jde o vývojáře, který 50% svého času věnuje roli Scrum mastera. 47

48 6.8. Programový manažer Tato role nepatří do Scrumu, ovšem často patří do korporátních společností, které mají více než jeden projekt. Programový manažer je zodpovědný za reportování stavu projektu k majitelům. Většinou má na starost monitorovat více projektů najednou a sbírat reporty o projektech od projektových manažerů daných projektů. Projektový manažer nespadá pod programového manažera, jen mu reportuje aktuální stav projektu Projektový manažer Tato role rovněž nepatří do metodologie Scrumu. Jeho základní zodpovědností je naplánování projektu jako celku a hlídání, zda se vývojové týmy trefují svým plánováním do finálního bodu vydání produktu. Vytváří reporty o aktuálním stavu projektu, řeší rovněž společně s produktovým manažerem obsah produktového backlogu a upravuje ho podle toho, jak týmy stíhají vyvíjet. Projektový manažer na sebe bere zodpovědnost za stihnutí celého projektu včas. Tato role není uvedena ve Scrumu, ovšem podle mého zjištění je rozhodně potřebná. Projektový manažer by se dal přejmenovat na Scrum master of Scrum masters. Je tedy vrstvou nad jednotlivými vývojovými týmy a je potřeba tam, kde jeden produkt vyvíjí více než jeden tým. Projektový manažer řeší závislosti mezi týmy a hlídá, zda si týmy dodávají vzájemně prostředky, které potřebují. Řeší plánování mezi těmito týmy na další sprinty. Hlavní schůzka, kterou projektový manažer vede je Pre-planning meeting (předplánovací schůzka), na které společně se Scrum mastery a produktovým manažerem jednotlivých týmů plánují externí dodávky do dalších sprintů. Další schůzkou, kterou projektový manažer vede je Scrum of Scrum, která je detailně popsána v kapitole o Scrum schůzkách. Ve zkratce je to schůzka, která se koná několikrát za sprint se všemi Scrum mastery, kteří společně pracují na jednom produktu. Hlavním bodem je získání aktuálního stavu implementace požadavků a zjištění risků a problému během sprintu. Projektový manažer má na starosti tvorbu sprint plánů interně nazvaných Horizon planning, které obsahují všechny požadavky na produkt až do jeho finálního vydání. Udržuje přehled o stavu celého projektu, ne jen o daném sprintu jako Scrum master. Kromě závislostmi mezi týmy řeší i data vydání produktu do beta testování a na trh mezi zákazníky. Díky kompletnímu plánu je schopný přibližné data doručení funkcionality v produktu Produktový manažer Jeho role je ve scrumu označována jako Product owner, tedy majitel produktu a jeho backlogu. Produktový manažer je osoba zodpovědná za obsah backlogu. Sbírá požadavky na produkt a tvoří z nich ucelené vývojové požadavky, které ukládá do systému, například JIRA. Je zodpovědný za obsah požadavků, za kontrolu požadavku během implementace, jestli opravdu odpovídá tomu, co bylo požadováno a nakonec implementovaný požadavek akceptuje. 48

49 6.11. Týmový vedoucí (Team leader) Tato role, podobně jako dvě předchozí, také nepatří do Scrumu. Týmový vedoucí často dělá práci Scrum mastera a Product ownera. Chodí na synchronizační meetingy s projektovým manažerem a zároveň tlumočí týmu požadavky na produkt, pokud není zrovna produktový manažer dostupný. Zároveň se stará o naplnění sprint backlogu pro další sprint. Role týmového vedoucího je hluboko zakořeněná ve struktuře vývojových týmů. Správně by měla být tato role vyměněna za roli Scrum mastera a neměla by existovat v agilním týmu. Ovšem z aktuálního pohledu ji shledávám za důležitou roli, která by se měla zachovat a v budoucnu akorát sloučit s rolí Scrum mastera. Problém této role je především ten, že Team leader je uznáván jako vedoucí týmu, který má v korporátních firmách vyšší status, který vede tým lidí. Týmový vedoucí by změnu názvu své role na Scrum mastera pravděpodobně z pochopitelných důvodů nepřijal pozitivně, ani kdyby si nepohoršil z finančního pohledu. Hlavní důvod je ten, že je role Scrum master chápána jako nižší než týmový vedoucí a tím pádem by si změnou role pohoršil i z pohledu konkurenceschopnosti na pracovním trhu v případě změny zaměstnavatele. Tato pozice z těchto důvodu zůstala zachována Architekt Tým architektů vznikl z důvodu přechodu na funkční týmy. Komponentní týmy si striktně hlídaly architekturu jednotlivých vrstev, ovšem funkční týmy fungují na skrz všech vrstvách a je důležité zachovávat a obnovovat také architekturu produktu. Tým architektů má také na starost analýzu požadavků a tvorbu jejich specifikace Agilní plánování iterací Plánování iterací rovněž probíhá stejně, jak se zavedlo v první fázi přechodu. Velkou změnou ovšem je výstup iterace. Koncem každé iterace by měl být hotový produkt obohacený o požadavky implementované a otestované během iterace. Rovněž kompletní produkt musí projít celkovým regresním testováním. Výsledkem tedy je vydatelný produkt. 49

50 Obrázek 11: Plánování a monitorování iterací Zdroj: Vlastní Agilní plánování sprintů Plánování sprintů v rámci týmů zůstává již stejné tak, jako se nastavilo v první fázi přechodu. Některé týmy se rozhodli zkusit estimaci požadavků ve Story Pointech, což použití nového project management software umožnilo. Scrum board byl také přenesen do elektronické verze, tímto došlo trochu ve změně průběhu Daily Scrum meetingu, který již neprobíhal u Scrum boardu, ale u počítačů. Z pohledu plánování se na úrovni týmu nic zásadního již neměnilo, přibyl ovšem Grooming meeting, jehož podstatou je objasnit a estimovat jednotlivé požadavky z Product backlogu ještě před samotným plánováním. Obvykle Grooming meeting probíhá den před plánovacím meetingem. 50

51 6.15. Theme, epic, story a task Až doposud se pracovalo s požadavky, agilní metodologie ovšem nabízejí detailnější rozdělení požadavků na různé typy podle úrovně abstrakce pohledu a podle určení Theme Je definovaný cíl, který definuje, jak mají produkty vypadat a co mají obsahovat. Téma může být rozbito do sub-témat, které již bývají specifické pro daný produkt. Témata jsou používány jak pro programový, tak projektový pohled a jasně komunikují a definují produkty z nejvyššího pohledu Story Požadavek, který je umístěn do Sprint backlogu se nazývá story. Obecně je story definován ve tvaru: "Jsem <typ uživatele> a chci <udělat akci> tak, aby <požadovaný výsledek >" Z tohoto zadání je jasná práce pro vývojový tým a je jasně definován požadovaný výsledek. Z praktického pohledu je pro vývojové týmy Story vlastně požadavek, nebo set požadavků při více Story, které musí implementovat, aby splnili epic. Více story dohromady tedy většinou definují a implementují epic Task Množina úkolů, je množinou, která definuje jedno story. story je tedy rozbito na více úkolů tak, aby každý úkol nezabíral více než 12 hodin práce, nebo by byl uskutečnitelný za jeden pracovní den. Úkolem je nazván anglicky task Backlog grooming Backlog grooming, jak jej definoval jeden z autorů Scrumu, Ken Schwaber, není formální součástí Scrum procesu, ovšem každý Scrum tým by si měl dedikovat alespoň 5 procent ze svého sprintu právě pro tuto aktivitu. Groomingu by se měl zúčastnit celý tým, Product owner a Scrum master. Hlavním úkolem Groomingu je estimace jednotlivých story, případné rozbití story na tasky a vše připravit na sprint plánování. Grooming není technická analýza úkolů pro další sprint, proto by měli být všichni účastníci již před Groomingem seznámeni s úkoly pro další sprint, aby je mohli na efektivně estimovat. Technická analýza pro jednotlivé story musí probíhat kontinuálně během celého předchozího sprintu a na Groomingu již probírat navrhované řešení a jeho estimaci. Tento meeting je zejména důležitý pro celý tým a hlavně pro plánování dalšího sprintu. Grooming zaručí, že se sprint planning bude skutečně zaobírat jen plánováním již 51

52 estimovaných úkolů do dalšího sprintu. Osobně považuji Grooming jako jeden z nejdůležitějších meetingů pro přípravu sprintu i přes to, že není formální součástí Scrumu. V první fázi byl Grooming zcela vypuštěn, což vedlo k tendenci teprve začít probírat technické řešení jednotlivých úkolů, které musí být již před plánováním specifikované a estimované. Účastníci: scrum tým, product owner Trvání: 2 hodiny každý týden Obsah: diskuze, analýza a estimace požadavků z product backlogu Technická analýza před Groomingem Aby se dal Grooming uskutečnit, je potřeba, aby byl každý úkol pro budoucí sprint technicky připravený. Jednou z možností je každému členovi týmu mimo story a tasků do sprintu přidat i úkol na technickou analýzu jednoho tasku. Každý člen, který analýzu některého z tasků dělal, odprezentuje své řešení na Groomingu před estimací, aby měl každý vývojář jasno, jak se bude úkol technicky řešit a mohl tak odhadnout jak dlouho mu takový úkol bude trvat Estimace ve Story pointech Velký rozdíl v plánování ve vodopádovém modelu a Scrumu je také ten, že se již neplánuje na jednotlivce jak je tomu u vodopádu zvykem, ale na celý tým. Implementace úkolů je ve Scrumu záležitostí celého týmu a proto je kladen důraz na kolektivní úsilí a výkon. Metodologie Scrum nedoporučuje používat na estimaci úkolů klasickou jednotku času, protože takové estimace mohou narušit samo organizaci týmu, což je jeden z nejdůležitějších prvků Scrumu. Navíc práci již neestimuje manažér, ale přímo tým a jeho členové, kteří si svojí práci estimují sami na základě svých zkušeností. Problém ovšem je, že programování není lineární úlohou. Většinou probíhá hodně logaritmicky, kdy vývojář za první hodinu napíše většinu kódu, ovšem zbytek píše spoustu hodin a ještě déle pak trvá oprava chyb a lazení, případné úpravy. Ideálním způsobem, jak takové úkoly estimovat, je nějaká abstraktní jednotka. Scrum jako takový neříká, jakým způsobem úkoly estimovat, ovšem nejpoužívanější jsou například jednotky velikosti oblečení, takzvaný T-shirt sizing, který vypadá takto (XS, S, M, L, XL, XXL, XXXL), nebo například psí plemena, kde nejmenší úkolem je Čivava. Dalším velice rozšířeným jsou takzvané Story points. Story points je naprosto abstraktní jednotka, kde jeden Story point představuje jeden malý úkol. Na prvním malém referenčním úkolu se musí tým dohodnout a vybrat některý z již implementovaných úkolů takový, který prohlásí za referenční a bude tak představovat právě jeden Story point. Všechny následující odhady se budou poté zakládat na odhadu úkolu referenčního. Estimace ve Story pointech probíhá na Groomingu například pomocí karet, kde každý člen má jeden 52

53 balíček u sebe a ukazuje hodnotu, kterou pro daný úkol zvolil. Hodnoty na kartách jsou ve Fibonacciho sekvenci (1, 2, 3, 5, 8, 13, 21, 34, atd.) Nevýhody estimací ve Story pointech Tím největším problémem je nepochopení ze strany managementu. Špatně se vysvětluje, že určitý požadavek bude hotový za několik Story pointů. Navíc se velice špatně kontroluje průběh implementace úkolů, které jsou odhadnuty ve Story Pointech, jelikož projektový manažer nikdy neví, jak daleko vývojář s úkolem je. Dalším problémem je časté nepochopení členy týmů a následně hodně špatné estimace, které trvají podstatně méně, než bylo estimováno. Vývojáři často zapomínají, že je estimace ve Story pointech, které neodpovídají skutečným hodnotám času. V neposlední řadě existuje problém s Burndown grafem v průběhu sprintu, který je velice kostrbatý a dost často neukazuje vůbec relevantní informaci o průběhu sprintu, protože neprobíhá odepisování odpracovaných hodin u jednotlivých úkolů tak jako v případě používání klasických hodin. Obrázek 12: Burndown graf vytvořený ze Story points Zdroj: Vlastní V konečném důsledku tým, který jako první se Story pointy začal, tento pokus ukončil. Především chyběla dostatečně silná podpora v plánovacím systému. A bylo se potřeba vrátit k estimaci v hodinách. Jako jeden z hlavních důvodů byl právě nefunkční Burndown graf a také spočítání celkové výkonnosti týmu a sledování průběhu implementace. 53

54 Obrázek 13: Burndown graf vytvořený ze Story pointů. Nejhorší varianta rostoucího grafu. Zdroj: Vlastní, snímek ze systému JIRA Postup plánování nových požadavků Obrázek 14: Cesta nového požadavku a jeho stavy. Zdroj: Vlastní 54

55 6.24. Rozpady požadavků na implementační tasky Rozpad požadavků je velice důležitou součástí celého fungování vývoje, protože je to proces, během kterého se neurčité nebo komplexní požadavky mění na konkrétní úkoly k implementaci. Bez rozpadu požadavků není možné v agilním vývoji plánovat, protože naplánovat do sprintu lze pouze takové úkoly, které se dají celé stihnout v rámci jednoho sprintu včetně testování, takže musí tvořit samostatné nezávislé celky. Čím jsou požadavky komplexnější, tím složitější je jejich rozpad. U některých je rozpad tak komplexní, že ho musí celý rozpadnout tým architektů Rozpad epicu na story Klasický rozpad jednoho epicu na jednu story. Rozpad probíhá během klarifikačního a estimačního meetingu, kde se ujasní o čem epic je a co je potřeba pro jeho splnění implementovat. Story se rozpadne na příslušné implementační tasky během Grooming meetingu a zaplánují se do následujícího sprintu na Sprint planning meetingu. Tento případ je v praxi okrajový a připadá v úvahu pouze u jednoduchých požadavků, které neobsahují komplexní funkcionalitu. Obrázek 15: Rozpad epic na story Zdroj: Vlastní 55

56 6.26. Rozpad epicu na více story Častějším případem rozpadu epicu je rozpad na více než jednu story po klarifikačním meetingu. Základem je zde rozpadat epic na funkční samostatné celky, tedy Story, které lze samostatně implementovat a netvoří závislosti. Každá Story se pak může rozpadnout dále na Grooming metingu na jednotlivé tasky, které jsou dost malé k implementaci během jednoho až dvou dnů během sprintu. Obrázek 16: Rozpad epicu na více story Zdroj: Vlastní 56

57 6.27. Rozpad epicu na více story s externí závislostí Epic může obsahovat externí závislosti a Story tak mohou být rozděleny mimo jiné týmy. Důležité je, že vzniknou opět závislosti mezi týmy, kterým se nedá jednoduše předejít. Pro externí závislosti může vzniknout externí task, nebo rovnou celá story v případě komplikovanější dodávky. Externí závislost musí být známa již při klarifikaci, proto je důležité u těchto Tasků mít hotovou alespoň zcela základní technickou analýzu požadavku. Pokud se externí závislost objeví až po naplánování Epicu do sprintu, musí později dojít k přeplánování celého sprintu a čekání na externí dodávku. Obrázek 17: Rozpad epicu na více Story s externí závislostí Zdroj: Vlastní 57

58 6.28. Rozpad theme na epicy U větších a komplexních zadání, většinou napříč několika produkty, vznikne theme. Theme je komplexní množina epicu pro jednotlivé části theme. V praxi se nejčastěji theme používá, pokud jde o stejnou změnu v rámci všech software produktů a pro úpravu v každém produktu tak vznikne samostatný epic, nebo v případě, že je požadavek velice komplexní a má pouze hodně abstraktní zadání, které naznačuje pouze směr, kterým se má daný produkt vydat, nebo pouze abstraktně naznačuje požadovanou funkcionalitu Postup implementace Proběhla velká změna v chápání požadavku a bylo potřeba ustanovit nové procesní postupy, jak požadavky na týmy plánovat. Především je potřeba rozbít epic na detailnější popis a vytvořit tak několik Story, které Epic popisují. Zároveň je potřeba každý epic klarifikovat a estimovat. Po klarifikaci a estimaci je potřeba Epic naplánovat do určité iterace, ve které jednotlivé Story spadnou do příslušných sprintů k implementaci a testování. Na konci Sprintu musí být Review meeting, kde zadavatel epicu zkontroluje výsledek a v případě, že je vše v pořádku, tak je epic brán jako uzavřený Schvalovací proces epicu Product owner musí schválit epic, který mu tým předvede na epic demo prezentaci. Obvykle demo předvádí člen týmu, který epic implementoval, není to ovšem podmínkou. Na tomto demu se Produktový manažer rozhodne, zda daná funkcionalita splňuje požadavek tak, jak byl zadán, a na konci změní stav epicu na zavřený nebo ho znovu otevře pro úpravu implementace. 58

59 Obrázek 18: Cesta nového požadavku od zaplánování až po schválení jeho implementace Zdroj: Vlastní Řízení a monitoring sprintů Během sprintu je potřeba sledovat výkon týmu, který může být ze začátku velice proměnlivý, obzvláště pokud se tým teprve učí správně estimovat svoje úkoly. Odhady dost často ze začátku neodpovídají estmacím a tým potřebuje zpětnou vazbu o špatně estimovaných úkolech aby se mohl do dalších sprintů zlepšovat a zpřesňovat své odhady. Dalším faktorem, který je třeba během sprintu sledovat je aktuální stav všech úkolů. Ideální pro kontrolu stavu je Burndown graf, který celkem přesně ukazuje odchylku od ideálního průběhu sprintu. V neposlední řadě je potřeba sledovat závislosti mezi týmy a jejich správné časové navázání aby sprint v jednom týmu nestál kvůli špatnému plánování v týmu jiném Scrum of Scrum meeting Jednou z možností jak sledovat aktuální stav vývoje ve všech týmech je meeting nazvaný Scrum of Scrum. Je to v podstate daily meeting, kterého se účastní pouze Scrum master každého týmu a Project manager, který schůzku vede. 59

60 6.33. Elektronický Scrum board V první fázi přechodu se využíval pouze klasický Scrum board připevněný na stěně v kanceláři týmu. V druhé fázi po nasazení Projekt management systému, který podporuje agilní metodologie, se začal využívat Scrum board v digitální podobě, který je možné kontrolovat odkudkoliv i když není Project manager přímo v kontaktu s týmem. Ideálním způsobem sledování sprintu je využít Scrum of Scrum na pravidelné bázi, sledovat Burndown chart a také sledovat Scrum board Odchylky od Scrum metodologie Specialisté Největší odchylkou od klasického Scrumu je plánování a příprava sprintu. Problém je, že v týmech stále zůstávají specialisté a tím pádem není možné plánovat podle metodologie Scrumu. Plánuje se již dopředu na konkrétní skupinku lidí, kteří jsou schopni task splnit v daném sprintu. Samotná estivace tasku je čistě v režii toho, kdo bude v konečném důsledku task implementovat Pevné datum vydání nových verzí software Další velkou odchylkou od agilního vývoje je pevně stanovené datum vydání nové verze software, který je znám několik měsíců dopředu. A pevný seznam hlavních požadavků, které produkt musí obsahovat, což je přístup vývoje ve vodopádovém modelu. Pevný datum vydání a pevně definovaný Product backlog, který se musí dodržet, znemožňují agilní plánování a je třeba plánování těmto faktům neustále přizpůsobovat. Návaznosti na externí týmy, které nefungují agilně, je rovněž problém, protože takové požadavky blokují sprint. V případě, kdy nejsou požadavky dodány v čas, může se stát, že požadavek, pro který jsou určené, bude vyřazen ze sprintu a dojde ke stejnému zpoždění jako ve vodopádovém modelu Pevně stanovený rozsah projektu U některých nových projektů se stává, že je dopředu dán set požadavků, které systém musí splňovat, a všechny požadavky mají stejnou prioritu. Tím pádem nelze vytvořit prioritizovaný backlog, ze kterého by se podle priorit plánoval sprint. V kombinaci s pevně stanoveným datem vydání se dostáváme zpět k vodopádovému modelu. 60

61 6.2. Zhodnocení přechodu na agilní metody ve fázi 2 Zhodnocení provedených změn a především zpětná vazba, by měli být hlavní součástí přechodu na agilní metody. Jasně stanovené KPI (tzv. Key Performance Indicator ukazatele výkonnosti), které je potřeba hlídat, nám dají jasný obraz o tom, jak agilní metody vývoji pomohly. Stanovil jsem základní KPI, pro které je potřeba získat hodnoty a monitorovat jejich stav několik měsíců po zavedení agilních metod. Hlavní KPI: Kvalita produktu počet defektů nalezených zákazníky Rychlost reakce na změnu požadavků porovnání s předchozími projekty Rychlost reakce na defekt - porovnání s předchozími projekty Počet dodržených dat projektů a počet nespěšných projektů Počet defektů nalezených při externím testování Kvalita dokumentace Spokojenost vývojářů s novými procesy Příkladem může být dashboard (základní obrazovka s přehledem) vytvořený v JIRA, který jasně ukazuje čas potřebný k opravě nově nalezeného defektu. Tento čas by se měl díky zavedení testování přímo v týmech značně zkrátit. 61

62 Obrázek 19: Graf zobrazující rychlost opravy nových defektů Zdroj: Vlastní Obrázek 20: Graf zobrazující reálný výkon týmu a původní estimace Zdroj: Vlastní 62

63 Pro tuto diplomovou práci nejsou bohužel dostupné zdroje dat, které by se daly použít pro zhodnocení přechodu. Agilní týmy, v době psaní práce, pracují na teprve třetím sprintu a jakékoliv závěry o kvalitě produktu nebo o lepším čase implementace by byli zcela nepřesné. První velké zpětné zhodnocení agilních metod bude možné až po třech iteracích, které budou ukončeny na konci srpna Spokojenost jednotlivců se hodnotit dá, protože základní proces Scrumu již běžel od začátku v první fázi přechodu. Lidé tak již mají šest iterací v agilních týmech za sebou Vývojář a tester Oslovil jsem náhodně vybrané jedince na vývojovém oddělení a požádal je o názor na přechod na agilní metody. Navíc jsem součástí většiny Scrum retrospective schůzek na kterých vyplynula většina pozitiv a problémů se Scrumem. Vývojář Petr B. Jsem rád, že si úkoly eximujeme přímo v týmu. Estimace jsou mnohem přesnější než dříve. Vývojář Martin S. Na Scrumu a práci ve sprintech je dobré, že vím, co přesně budu další dva týdny dělat. Vývojář Tomáš S. Nemění se tak často úlohy, na kterých musíme pracovat. To znamená, že nemám paralelně rozpracovaných několik úkolů. Může se stát, že během sprintu přijde něco důležitějšího a budu muset pracovat na něčem jiném, ale už se to nestává tak často jako dříve. Vývojář Pavel T. Rozpad nějakého požadavku na konkrétní implementační tasky si děláme v rámci týmu, což mnohem přesněji odpovídá tomu, co ve skutečnosti budeme implementovat. Vývojář Pavel T. Testování hotových požadavků přímo v týmu je pro mne rozhodně největším přínosem Scrumu. Nemusím čekat například dva týdny, než někdo defekt ověří, zda je spravený a v případě, že je něco špatně, můžu se k opravě vrátit hned další den s čerstvou znalostí kódu, ušetří to spoustu hodin analýzy. Tester Pavol S. Je pro mne lepší být součástí přímo vývojového týmu. Být tam, kde se kód, který testuji, i píše. Mohu mít dotazy přímo na vývojáře a ústní komunikace je mnohem rychlejší než přes nebo Bugzillu. Tester Monika V. Díky tomu, že jsem přímo v týmu, znám jejich aktuální problémy a můžu přizpůsobit testování požadavku, popřípadě testovat největší problémy prioritně. Team leader Jan S. Máme více času na technický dluh jako je dokumentace, se kterou se již v plánu počítá a je nutností pro uzavření tasku. Rovněž na psaní testů máme mnohem více času. Vývojář Lubomír L. Tým dočasně funguje i samostatně pokud Team leader není přítomen. Bez problému si tým se Scrum masterem naplánuje práci a splní sprint. 63

64 Project a Product management Přechod na agilní metody nejvíce ovlivnil celkovou náplň práce Projektového manažera. Projekt manažer - Milan R. Týmy jsou více autonomní než předtím a není tak potřeba plánovat týmu práci na jednotlivce. Projekt manažer -Tomáš J. Funkční tým je konečně tým, který zvládne implementovat a otestovat kompletní požadavek. Není tak potřeba plánovat práci na jednom požadavku skrz několik týmu a týmy synchronizovat. Samozřejmě i ve funkčních týmech se občas stane, že existuje externí závislost, nestává se to ovšem již tak často. Pavel B. Velkou výhodou je rozdělení požadavku na tak malé implementační části, že se požadavek týmu jednak lépe odhaduje, ale také se lépe plánuje a hlavně implementuje. Implementační task přidaný do sprintu bude během sprintu hotový a na jeho konci i otestován, což minimalizuje riziko. Dřív byl požadavek ponechán ve svém původním stavu, nerozbitý na malé implementační tasky a například implementován dva měsíce s nejasným výsledkem. Jiří F. Estimace na jednotlivé tasky, které od týmu dostaneme, jsou mnohem přesnější, než dříve a dá se tak lépe předpokládat konec jejich implementace. Produktový manažer - Jan R. Tým architektů určitě přispěl i nám a nejen vývojovým týmům. Architekt je schopen udělat estmaci na větší požadavek a případně požadavek rozdělit na implementační tasky nebo týmu s rozdělením výrazně pomoct. Produktový manažer - Tomáš H. Mít na konci každé iterace produkt, který je připraven na to být vydán, je perfektní. Minimalizuje to riziko nefunkčního produktu před opravdovým vydáním. Produktový manažer Lukáš Š. Díky tomu, že máme na konci každé iterace hotový produkt, jsme schopní tento produkt každý měsíc prezentovat vlastníkům a získat tak každý měsíc validní zpětnou vazbu zda je produkt takový, jak byl vlastníky požadován. Scrum a agilní metody samozřejmě nejsou univerzálním řešením na veškeré problémy vývoje, ale určitě vnáší větší pořádek do organizace a plánování práce. Mají samozřejmě i spoustu nevýhod a ne každý člen týmu si na práci ve Scrumu zvykne. Pro spoustu vývojářů to ze začátku znamenalo větší administraci a každodenní schůzky bez viditelného přínosu v prvních sprintech. Tendence přestat s agilním přístupem v prvních pár sprintech jsou opravdu viditelné. Spousta společností právě se Scrumem skončí v těchto prvních fázích, kdy je těžké čelit počátečnímu odporu vývojářů ke Scrumu. Tuto prvotní fázi odporu ještě posiluje fakt, že sprint má pouze jeden týden a každý týden tak probíhá nové plánování. Vývojáři si ovšem velice brzo zvyknou a později objeví přínosy Scrumu. Často se z odpůrců stanou Scrum masteři. Po první vlně odporu přijde vlna druhá a to před změnou komponentních týmů na funkční týmy. Dochází totiž k velkým organizačním změnám v rozdělení týmů a každý vývojář si musí vybrat nový tým a odchází do jiné kanceláře. Právě tato změna kolektivu byla nejkontroverznějším tématem probíraným během druhé fáze. 64

65 7. Způsob plánování projektů v agilním prostředí To, že vývoj běží agilně, neznamená, že se velké projekty neplánují vůbec. Opak je pravdou. Agilní plánování není o plánu samotném, ale o umění plánovat a plány efektivně měnit podle aktuální situace. Přechodem na agilní metody vzniká potřeba změnit plánování velkých projektů. Již nelze plánovat projekty způsobem jako ve vodopádovém modelu, protože se k jejich realizaci přistupuje agilním způsobem. Potřeba dlouhodobých plánů je naprosto stejná. Agilní vývoj rovněž neznamená, že by neexistovalo pevné datum dodávek hotových produktů, jak se většina lidí domnívá při přechodu na Scrum. Zákazník stále bude chtít pevné datum dodávek, které je potřeba respektovat Planning horizon Jedním z možných způsobů plánování je srovnání zprioritizovaného a estimovaného backlogu požadavků a kapacit týmů, kteří na požadavcích pracují. Pracovně takový systém plánování nazýváme planning horizon. Principem tohoto plánování je sestavení kompletního seznamu všech požadavků v projektu a požadavky prioritizovat a estimovat. Poté přesně zjistit výkon týmů, tedy kolik hodin za sprint věnují novým požadavkům a tyto dvě informace porovnat v delším časovém horizontu. Plánování do budoucna je velká neznámá a proto je potřeba dělat korekci výkonu týmu. V praxi to vypadá tak, že se první následující sprint v plánu počítá se 100 procenty kapacity a každý následující má kapacitu o 10 procent nižší. Snižování se zastaví na limitu 50 procent kapacity týmu, tedy každý další sprint od pátého sprintu už bude plánován pouze na 50 procent kapacity týmu. Plánování kapacity na 50 procent nám dává určitou míru jistoty, že se projekt stihne. Zbylých 50 procent kapacity je většinou využito na změny požadavků během implementace a případné řešení problémů, které se vyskytnou. Z praxe mohu potvrdit, že zmíněných 50 procent je na většinu projektů ideální hodnota, která sice nezaručí dodání projektu v čas, ovšem dává prostor pro případné problémy. Výsledkem planning horizonu je přehled požadavků a počet sprintů potřebných k jejich realizaci. V planning horizonu je možné sledovat aktuální průběh celého projektu a zejména vyčíst možné datum dodávek i částečné implementace produktu. Čím detailnější je rozpad požadavků, ze kterého planning horizon tvoříme, tím je více plán odpovídá realitě. Na začátku projektu se horizon planning tvoří pouze na základě epiců a jeich nepřesných estimací od týmu architektů. Postupem času se všechny epicy rozbíjí na story, jejichž estimace je značně přesnější a více odpovídá realitě. Prvnostní plány je tedy potřeba brát opravdu s velkou rezervou a nestanovovat podle jejich výsledků finální datum dodávek. Sprinty se podle horizon planningu neplánují. Horizon planning slouží pro vytvoření plánů celkových, ne však pro plánování sprintů. Sprint je potřeba plánovat vždy na 100 procent dostupných kapacit a musí pojmout všechny požadavky, které se do kapacity týmu vlezou. Pomocí horizon planningu se dá pouze sledovat, zda sprinty alespoň částečně sledují plán projektu. 65

66 7.2. Externí závislosti a planning horizon Externím závislostem se vyhnout pomocí agilních metod nedá. Dá se je lépe plánovat a předvídat. Plánování celého projektu se od plánování práce týmu značně liší především tím, že je potřeba brát v úvahu všechny externí závislosti, na kterých projekt stojí. To, že je celý vývoj agilní ještě neznamená, že závislosti mezi týmy neexistují. Závislosti mezi týmy u velkých projektů, které nezvládne sám jeden tým, budou existovat vždy i když se podaří v týmech eliminovat specialisty a vytvořit tým schopný implementovat jakoukoliv funkcionalitu. U větších projektů je potřeba práci rozdělit mezi vývojové týmy a výsledný kód co nejčastěji skládat dohromady aby byla zajištěna integrita a funkčnost. Na zjištění zavilostí je Grooming meeting zmíněný víše v kapitolách o Scrumu. Při zjišťování jak by se měl daný požadavek implementovat, se objeví všechny návaznosti a je tedy možné odvodit nutné pre-rekvizity pro úspěšnou implementaci požadavku. Vznikají tak vazby mezi story, které byly odvozené z epicu. V praxi používáme především tyto tři vazby pro znázornění závislosti: Story1 Is coordinated with Story2 Story1 is blocked by Story2 Story1 depends on Story Spojení Is coordinated with Používá se u story, které musí být implementovány zaráz ve stejném sprintu. Pokud jsou story každá v jiném týmu, musí se týmy domluvit a naplánovat si každý tu svou do stejného sprintu jako druhý tým. Tento druh vazby znázorňuje, že není možné story implementovat každou v jiném sprintu. Nejčastěji se tento druh vazby používá při implementaci integrace produktů nebo při testování integrace mezi produkty Spojení Is blocked by Toto spojení se používá v případě, že jedna story blokuje druhou. To znamená, že jedna story musí být co nejdříve naimplementována, aby se dala zaplánovat do sprintu tato Spojení depends on Toto spojení vyjadřuje sériovou závislost implementace mezi story. Pokud je každá story v jiném týmu, je potřeba domluvit naplánování do sprintu sériově. Tento druh spojení naznačuje, že tyto dvě story by se nikdy neměly naplánovat do stejného sprintu. Story2 by se měla plánovat, až když je první story kompletně implementována a otestována. 66

67 8. Zhodnocení přechodu na agilní metody Zavést agilní metody není jednoduchý úkol. Ze začátku vývoji vůbec nepomůže, objeví se problémy, o kterých jste nikdy ani neuvažovali a ze začátku bude agilní přístup většina odmítat. I přes všechny tyto překážky stojí přechod na agilní metody zato. Agilní metody vedou ke zlepšení komunikace mezi lidmi na vývoji, což beru jako největší plus. Rovněž zvyšují povědomí o práci druhých. O velké většině problémů byste se měli dozvědět z této diplomové práce, ovšem každý vývoj je trochu specifický a určitě narazíte i na problémy, které jsem v publikaci nezmínil. Nezbývá vám, než se s nimi agilně vypořádat Neexistující důvody proč nepoužívat agilní přístup Souhrn základních důvodu, proč si většina myslí, že změna z vodopádového modelu není možná. Těchto názorů se nevyvaruje asi žádný přechod z vodopádového modelu na agilní způsob vývoje Udržitelnost architektury Během rušení komponentních týmů, které se staraly o architekturu produktu, často uslyšíte, že tím přestane existovat možnost jak architekturu udržovat. Každý developer přejde do jiného produktového týmu a tím, že nebudou spolu, nebude mít kdo udržovat architekturu produktu jako celku. Tím pádem se bude architektura zhoršovat, což povede k velice špatné kvalitě produktu. Tento argument se po čase ukázal jako zcela neplatný. Naopak se do návrhu a vývoje architektury zapojují všichni členové agilního týmu a přemýšlí nad architekturou tedy větší počet developerů než dříve, což vede často k lepšímu návrhu. Navíc existuje tým architektů, kteří mají za úkol architekturu neustále analyzovat a vylepšovat Zaměření developera a specialisté Agilní týmy by neměli mít specialisty a všichni by měli umět vše, což není u našeho vývoje možné. Tento názor je částečně správný, jde totiž o nedorozumění. V týmu samozřejmě vždy budou specialisté. Ne každý developer je schopen dělat grafické rozhraní a ne každý developer má rád abstraktní programování. Každý tíhne k trochu jiné oblasti a je v ní lepší než zbytek týmu. Zastupitelnost znamená, že developer, který pracuje převážně na grafickém rozhraní, bude schopen alespoň zastoupit developera pracující na jiné oblasti produktu za co nejkratší dobu. Neznamená to, že se každý developer musí učit zcela něco jiného a musí umět v produktu udělat vše. Naopak každý developer musí mít alespoň povědomí o práci každého v týmu a v případě jeho výpadku ho zastoupit. 67

68 V Agilním vývoji neexistuje přesný plán do budoucna Přesný plán skutečně neexistuje. Tento problém efektivně řeší předchozí kapitola o plánování projektů v agilním prostředí Datum dodání finálního produktu Další obavou, často přicházející od zákazníků a majitelů produktu je, že neví, kdy vlastně dostanou hotový produkt. Částečně tento problém řeší minulá kapitola o plánování velkých projektů. Zákazník dostává produkt s přidanou funkcionalitou ideálně na konci každého sprintu a sám si rozhodne, kdy mu výsledek vyhovuje a další vývoj ukončí. Rámcově, kdy bude minimální požadovaná funkcionalita hotová, se dá zjistit pomocí horizon planningu Scrum přináší více meetingů Scrum vývojáře od meetingů neochrání, naopak jim spoustu meetingů přidá. Odhadem přibude dvojnásobek meetingů, na které vývojář musí chodit. Někdo by tuto vlastnost mohl hodnotit jako negativní. Pravda je taková, že více meetingů přispělo ke zlepšení komunikace mezi vývojáři a rozvíjí tuto dovednost i v jedincích, kteří nejsou tolik zvyklí komunikovat. Komunikace je základem spolupráce. Získávání zpětné vazby téměř za pochodu projektu je velice užitečné. Zlepšuje spolupráci a především Scrum samotný. Je možné už během projektu řešit problémy, které by se jinak řešili až po skončení projektu. V horším případě až po neúspěšném ukončení projektu. 68

69 9. Výběr Project Management systému Proces výběru nového systému pro správu kompletního vývoje zasahuje do všech oddělení skrz firmu. Je třeba si uvědomit, kdo všechno se systémem bude pracovat a především jak. Prvním krokem k výběru nového systému je sesbírání všech požadavků pro všechny druhy uživatelů, kteří budou systém používat Obecné požadavky na nový systém Základní požadavky, které jsou stejné napříč všemi odděleními a jsou požadovány celou společností. Přizpůsobitelný proces (nastavitelný) Nastavitelné UI objekty Hromadná modifikace záznamů Filtrování Full-text vyhledávání Možnost připojit soubor v každém modulu LDAP synchronizace Nastavitelné role and uživatelský přístup Musí podporovat systém Git a Review Code nástroje. Integrace CI (build systém) Integrace testovacího systému Různé druhy položek ( defekt, theme, epic, story, task ) Musí mít dobře zdokumentované API Musí umět zachovat vazbu mezi požadavky při jejich rozbití ( Epic na několik Story ) Reportování Nastavitelné reportování Grafy Integrace s externími nástroji pro reportoání Veřejné reporty Nastavitelné varování a odesílání varovných zpráv 69

70 Podpora pro Agile/Scrum software development metodologii: Prioritizovaný backlog Sprint planning Burndown graf Backlog Sprint scope definice Průběh na každém úkolu Scrum board Možnost přiřadit epicy, story a tasky k projektům a přehazovat je Nastavit závislosti mezi požadavky Hromadná aktualizace položek, změna více položek najednou Vytvořit individuální pohledy, možnost sdílet pohledy Nastavitelná políčka: o podpora RT editoru o Políčka vytvořitelná uživatelem Verzování Oznamování změn Rozšířené filtrování na bázi autora / role Notifikace by měla posílat poze popis změněných políček a né všechny změny Měl by mít konektor k IDE: Visual studio. 70

71 9.2. Požadavky Project managementu Možnost vidět aktuální stav projektů Suma: odpracovaných hodin, zbývajících hodin, původně estimovaného času. Požadavky, které jsou ve zpoždění Možnost vidět stav celé iterace. Požadavky ve stavech done/progress/not started v iteraci. Nastavitelné notifikace Spuštěné na základě volitelných akcí. Procesy, které musí systém být schopný modelovat Estimace projektu a celého plánu. Plánování zdrojů (pro neagilní týmy). Přípravu testů. Spuštění testů (verifikace defektů, testování požadavků, testovací případy, automatizace). Monitorování průběhu sprintu. Předání otestovaného produktu k vydání takzvaný release management. Na workshopech tak vznikl seznam celkem 280 požadavků rozepsaných velice podrobně ze všech oddělení. K obecným požadavkům, na kterých se shodli všichni uživatelé, ještě přibily požadavky specifické pro každé oddělení. Produkt management, Project management, vývoj a QA. V některých specifických požadavcích se dokonce jednotlivé požadavky vzájemně vylučují. Bylo potřeba jednotlivé požadavky několikrát validovat a naplánovat spoustu workshopů, na kterých se jednotlivé neshody probíraly už s ukázkou na vybraném management systému. 71

72 9.3. Srovnání Project management systémů Pro porovnání různých systému jsem použil set základních požadavků, kde jsem každý ohodnotil vůči danému Project management systému známkou od 1 do 5, kde 5 je nejlepší známka a 1 nejhorší DevSuite DevSuite je ALM (Application Lifecycle Management, dále jen ALM) systém od společnosti TechExcel, který v sobě integruje hned několik systému. Plně podporuje agilní metody. DevSpec - systém určený na správu požadavků. DevTrack systém na monitorování implementace a nalezených defektů v produktu DevTest systém na správu testovacích procesů Microsoft Team Foundation Server Dalším testovaným systémem byl Microsoft Team Foundation Server od společnosti Microsoft. V tabulce označen jako MS TFS, je kolaboračním ALM systémem pro vývoj software Hewlett Packard ALM Je ALM systém vyvinutý a používaný společností Hewlett Packard jako součást jejich IT portfolia v roce V tabulce označen jako HP ALM. 72

73 9.7. JIRA JIRA je softwarový nástroj vyvíjený společností Atlassian. JIRA podporuje a usnadňuje proces řízení projektů a požadavků, nabízí flexibilní a uživatelské nástroje pro řízení a sledování pracovníků při výkonu plnění úkolů. JIRA je orientován na podporu dosažení očekávaného výkonu na projektu. V tabulce je označen jako JIRA. Podpora projektového řízení (interní a externí řízení požadavků a úkolů) Management procesů Neustále dostupné informace pro tým přes webové rozhraní Sledování a vyhodnocování kapacit Průkazná historie projektové komunikace Podpora pro klientský servis a helpdesk Sdílení komunikace, informací a dokumentů v týmu Reporty, statistiky, historie evidence Sledování stavu projektu a řešení požadavků zákazníkem Úkoly podle priorit, termínů dokončení Fulltextové vyhledávání, silné filtrovací nástroje Projektové statistiky 73

74 9.8. Výsledná tabulka srovnání Project management systémů Tabulka1: Porovnání Project Management systémů Požadavky Devsuit e Jira MS TFS HP ALM Intuitivní grafické rozhraní Musí podporovat nastavitelné procesy Musí podporovat hromadné úpravy, rozšířené filtrování a full-text vyhledávání Musí mít LDAP/AP podporu Musí mít správu účtů Musí mít zdokumentované API Podporovat nebo mít integrovaný GIT, popřípadě některý verzovací systém N/A 2 2 Podporuje nebo integruje CI (cystom build) 1 4 Podporuje nebo integruje testování systémové integrace Podporuje nebo integruje zadávání z lokálních nebo externích zdrojů Musí podporovat reporting Musí podporovat zasílání ů a notifikací N/A 4 4 Musí podporovat Agilní a Scrum metodologie Musí podporovat agilní vyvíjení software Ukládá asociace mezi epic, story a task, které jsou přidružené Musí podporovat individuální dotazy do databáze, dotazy mít možnost uložit a sdílet s ostatními Musí podporovat nastavitelné políčka pro tyto typy: o Textové pole s editorem textu o Uživatelské políčka 3 5 Musí podporovat verzování 4 Musí podporovat webové prohlížení N/A

75 Musí podporovat vlastní notifikace nastavitelné skriptem N/A Musí mít persistentní linky na všechny položky v systému Vedení projektů je jednodušší než v stávajících systémech (Bugzilla, Accompa, Sharepoint) N/A 1 1 Průměrná známka Zdroj: Vlastní 75

76 10. Nasazení JIRA Podle srovnání všech systémů dosáhla největšího bodového hodnocení JIRA od společnosti Atlasian, která bude s drobnou úpravou velice dobrou náhradou za doposud používané nástroje ( Bugzilla, Sharepoint, Accompa) Agilní modul do JIRA Protože JIRA sama o sobě nemá agilní podporu pro plánování a monitoring metodologií jako Scrum nebo Kanban, bylo potřeba dokoupit další modul jménem GreenHopper, který agilní podporu do JIRA přidá. GreenHopper přidá do JIRA podporu několika základních věcí pro použití JIRA ve Scrumu. První z nich je Scrum board, bez kterého se žádný tým ve Scrumu neobejde. Každý člen týmu má možnost vidět jak svoje naplánované tasky, tak tasky na celý jeho tým. Může tasky vizuálně kontrolovat a táhnutím myši měnit jejich stav přesunutím do další části Scrum boardu. Obrázek 21: Scrum board v systému JIRA Zdroj: Vlastní, obrazovka ze systému JIRA Další zásadní funkcionalitou, kterou GreenHopper poskytuje, je Sprint report, jehož součástí je Burndown graf. 76

77 Obrázek 22: Ukázka Burndown grafu v systému JIRA Zdroj: Vlastní, obrazovka ze systému JIRA Další součástí Sprint reportu je také Velocity graf, který poskytuje přesné informace o výkonnosti týmů. Z grafu je dobře patrný průběh nasazování agilních metod v novém týmu. Ze začátku byla výkonnost velice nízká, poloviční oproti výkonnosti o dva sprinty později. Pozdější pokles výkonu od čtvrtého sprintu je dán zaváděním Story points, na které je v JIRA velice špatná podpora, protože JIRA nesčítala veškerou odpracovanou práci a tím pádem fiktivně klesal výkon týmu. Obrázek 23: Ukázka výkonostního grafu týmu v systému JIRA 77 Zdroj: Vlastní, obrazovka ze systému JIRA