Zavedení agilních metod vývoje (Scrum) a tvorba nástrojů pro … · 2014. 1. 8. · 3 Anotace Předmětem diplomové práce „Zavedení agilních metod vývoje (SCRUM) a tvorba

1

Masarykova univerz i ta

Fakulta informatiky

Zavedení agilních metod vývoje (Scrum)

a tvorba nástrojů pro efektivní řízení

Diplomová práce

Vedoucí diplomové práce: Autor:

RNDr. Jaroslav Škrabálek, MBA Ondřej Kuchta

Brno, 2013

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

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

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.

5

OBSAH

Anotace ................................................................................................................................................ 3

Annotation .......................................................................................................................................... 3

1. Úvod...................................................................................................................................... 9

1.1. Motivace a cíl práce ................................................................................................................. 9

1.2. Společnost ................................................................................................................................ 9

2. Vodopádový model ............................................................................................................ 10

2.1. Modifikace vodopádového modelu ........................................................................................ 12

2.2. Model mikrotýmů .................................................................................................................. 12

2.3. Vývoj ve vodopádovém modelu ............................................................................................ 15

2.4. Komponentní rozložení týmů ................................................................................................. 15

2.5. Zastupitelnost v komponentních týmech................................................................................ 16

2.6. Způsob plánování práce komponentních týmů ...................................................................... 17

2.7. Projekty a plánování nových verzí software .......................................................................... 17

2.8. Nástroje používané k plánování a realizaci projektů ............................................................. 18

2.9. Testování produktu................................................................................................................. 19

2.10. Shrnutí problémů vývoje ve vodopádovém modelu........................................................... 20

3. Agilní metody a jejich modely .......................................................................................... 21

3.1. Hlavní priority agilního přístupu ............................................................................................ 21

3.2. Agilní manifest ....................................................................................................................... 22

3.3. Nejpoužívanější agilní metodiky ............................................................................................ 22

3.4. Lean development .................................................................................................................. 22

3.5. Extrémní programování (XP) ................................................................................................. 23

3.6. Scrum ..................................................................................................................................... 23

3.7. Crystal metodiky .................................................................................................................... 23

3.8. FDD –Feature Driven Development ...................................................................................... 23

3.9. TDD – Test Driven Development .......................................................................................... 23

3.10. Základní výhody a nevýhody agilních metod .................................................................... 24

3.11. Výhody agilních metod ...................................................................................................... 24

3.12. Nevýhody agilních metod .................................................................................................. 24

3.13. Výběr agilní metodiky vhodné pro vývoj .......................................................................... 25

3.14. Hlavní pojmy metodologie Scrum ..................................................................................... 26

3.14.1. Scrum tým .......................................................................................................................... 26

3.14.2. Sprint .................................................................................................................................. 26

3.14.3. Produkt backlog ................................................................................................................. 26

3.14.4. Sprint backlog .................................................................................................................... 26

6

3.14.5. Scrum master ...................................................................................................................... 27

3.15. Scrum schůzky ................................................................................................................... 27

3.15.1. Daily Scrum meeting .......................................................................................................... 27

3.15.2. Sprint planning meeting ..................................................................................................... 28

3.15.3. Sprint review meeting ........................................................................................................ 28

3.15.4. Sprint retrospective meeting .............................................................................................. 29

3.15.5. Scrum of Scrum meeting .................................................................................................... 30

3.16. Burndown graf ................................................................................................................... 30

4. Zavádění agilních metod................................................................................................... 32

4.1. Stav vývoje před první fází přechodu - vodopádový model .................................................. 32

4.2. Přechod vývoje na agilní metody agilním způsobem ............................................................. 33

5. Fáze 1 – Agilní komponentní týmy .................................................................................. 34

5.1. Sprint ...................................................................................................................................... 36

5.2. Iterace v první fázi ................................................................................................................. 36

5.3. Plánování v komponentních týmech ...................................................................................... 36

5.4. Plánování iterace .................................................................................................................... 37

5.5. Plánování sprintů .................................................................................................................... 37

5.6. Eliminace specialistů ve Scrum týmu .................................................................................... 39

5.7. Definice hotového požadavku ................................................................................................ 39

5.8. Analýza nového požadavku ................................................................................................... 40

5.9. Definice hotového požadavku ................................................................................................ 41

5.10. Testování jako součást vývoje............................................................................................ 41

5.11. Rozdělení testování na interní a externí ............................................................................. 42

5.12. Souhrn kroků provedených při první fázi přechodu:.......................................................... 43

5.13. Výsledek a hodnocení první fáze přechodu ....................................................................... 43

6. Fáze 2 – přechod na agilní vývoj a funkční týmy ........................................................... 45

6.1. Funkční týmy ......................................................................................................................... 45

6.2. Role ........................................................................................................................................ 46

6.3. Organizace řízení projektů ..................................................................................................... 47

6.4. Project Steering Group ........................................................................................................... 47

6.5. Scrum tým .............................................................................................................................. 47

6.6. Product owner ........................................................................................................................ 47

6.7. Scrum master .......................................................................................................................... 47

6.8. Programový manažer ............................................................................................................. 48

6.9. Projektový manažer ................................................................................................................ 48

6.10. Produktový manažer ........................................................................................................... 48

7

6.11. Týmový vedoucí (Team leader) ......................................................................................... 49

6.12. Architekt ............................................................................................................................. 49

6.13. Agilní plánování iterací ...................................................................................................... 49

6.14. Agilní plánování sprintů ..................................................................................................... 50

6.15. Theme, epic, story a task ................................................................................................... 51

6.16. Theme ................................................................................................................................. 51

6.17. Story ................................................................................................................................... 51

6.18. Task .................................................................................................................................... 51

6.19. Backlog grooming .............................................................................................................. 51

6.20. Technická analýza před Groomingem ................................................................................ 52

6.21. Estimace ve Story pointech ............................................................................................... 52

6.22. Nevýhody estimací ve Story pointech ................................................................................ 53

6.23. Postup plánování nových požadavků ................................................................................. 54

6.24. Rozpady požadavků na implementační tasky .................................................................... 55

6.25. Rozpad epicu na story ........................................................................................................ 55

6.26. Rozpad epicu na více story ................................................................................................ 56

6.27. Rozpad epicu na více story s externí závislostí .................................................................. 57

6.28. Rozpad theme na epicy ...................................................................................................... 58

6.29. Postup implementace ......................................................................................................... 58

6.30. Schvalovací proces epicu ................................................................................................... 58

6.31. Řízení a monitoring sprintů ................................................................................................ 59

6.32. Scrum of Scrum meeting .................................................................................................... 59

6.33. Elektronický Scrum board .................................................................................................. 60

6.1. Odchylky od Scrum metodologie ........................................................................................... 60

6.1.1. Specialisté .......................................................................................................................... 60

6.1.2. Pevné datum vydání nových verzí software ....................................................................... 60

6.1.3. Pevně stanovený rozsah projektu ....................................................................................... 60

6.2. Zhodnocení přechodu na agilní metody ve fázi 2 .................................................................. 61

6.2.1. Vývojář a tester .................................................................................................................. 63

6.2.2. Project a Product management ........................................................................................... 64

7. Způsob plánování projektů v agilním prostředí............................................................. 65

7.1. Planning horizon .................................................................................................................... 65

7.2. Externí závislosti a planning horizon ..................................................................................... 66

7.3. Spojení „Is coordinated with“ ................................................................................................ 66

7.4. Spojení „Is blocked by“ ......................................................................................................... 66

7.5. Spojení „depends on“ ............................................................................................................. 66

8

8. Zhodnocení přechodu na agilní metody .......................................................................... 67

8.1. Neexistující důvody proč nepoužívat agilní přístup ............................................................... 67

8.1.1. Udržitelnost architektury .................................................................................................... 67

8.1.2. Zaměření developera a specialisté...................................................................................... 67

8.1.3. V Agilním vývoji neexistuje přesný plán do budoucna ..................................................... 68

8.1.4. Datum dodání finálního produktu ...................................................................................... 68

8.2. Scrum přináší více meetingů .................................................................................................. 68

9. Výběr Project Management systému............................................................................... 69

9.1. Obecné požadavky na nový systém ....................................................................................... 69

9.2. Požadavky Project managementu .......................................................................................... 71

9.3. Srovnání Project management systémů.................................................................................. 72

9.4. DevSuite ................................................................................................................................. 72

9.5. Microsoft Team Foundation Server ....................................................................................... 72

9.6. Hewlett Packard ALM ........................................................................................................... 72

9.7. JIRA ....................................................................................................................................... 73

9.8. Výsledná tabulka srovnání Project management systémů ..................................................... 74

10. Nasazení JIRA ................................................................................................................... 76

10.1. Agilní modul do JIRA ........................................................................................................ 76

10.2. Zhodnocení nasazení a používání JIRA ............................................................................. 80

11. Závěr .................................................................................................................................. 82

12. Seznam zdrojů ................................................................................................................... 83

12.1. Knižní zdroje ...................................................................................................................... 83

12.2. Internetové zdroje ............................................................................................................... 83

12.3. Seznam obrázků ................................................................................................................. 85

13. Přílohy ................................................................................................................................ 86

13.1. Příklad nefungujícího agilního plánování s týmem specialistů .......................................... 86

13.2. Příklady Burndown grafů ................................................................................................... 95

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.

1.1. 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.

1.2. 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ů.

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 1970. 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

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é

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.

2.1. 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.

2.2. 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

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.

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.

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.

2.4. 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.

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.

Zdroj: Vlastní

2.5. Zastupitelnost v komponentních týmech

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.

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.

2.7. 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.

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.

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.

2.9. 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 emaily.

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

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.

3.1. 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.

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ší.

3.3. 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.

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.

3.6. 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.

3.7. 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.

3.8. 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.

3.9. 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.

24

3.10. Základní výhody a nevýhody agilních metod

3.11. 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.

3.12. 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.

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ě.

26

3.14. Hlavní pojmy metodologie Scrum

3.14.1. 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.

3.14.2. 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.

3.14.3. 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ů.

3.14.4. 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.

27

3.14.5. 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.

3.14.6. 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.

3.14.7. 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

28

3.14.8. 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

3.14.9. 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

29

3.14.10. 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.

30

3.14.11. 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

3.14.12. 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

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í

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.

4.1. 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.

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.

4.2. 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.

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í

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.

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.

5.2. 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.

5.3. 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.

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

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

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ů.

5.7. 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ý.

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

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

5.10. 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

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ů

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

5.13. 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

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.

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.

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

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ů.

6.4. 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ě.

6.5. 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.

6.6. 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.

6.7. 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.

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.

6.9. 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.

6.10. 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.

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.

6.12. 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.

6.13. 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.

50

Obrázek 11: Plánování a monitorování iterací

Zdroj: Vlastní

6.14. 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.

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í.

6.16. 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.

6.17. 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.

6.18. 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.

6.19. 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ž

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

6.20. 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.

6.21. 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

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.).

6.22. 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.

54

Obrázek 13: Burndown graf vytvořený ze Story pointů. Nejhorší varianta rostoucího grafu.

Zdroj: Vlastní, snímek ze systému JIRA

6.23. Postup plánování nových požadavků

Obrázek 14: Cesta nového požadavku a jeho stavy.

Zdroj: Vlastní

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ů.

6.25. 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í

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í

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í

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.

6.29. 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ý.

6.30. 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.

59

Obrázek 18: Cesta nového požadavku od zaplánování až po schválení jeho implementace

Zdroj: Vlastní

6.31. Ří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.

6.32. 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.

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.

6.1. Odchylky od Scrum metodologie

6.1.1. 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.

6.1.2. 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.

6.1.3. 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.

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.

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í

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 2013.

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.

6.2.1. 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 email 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.“

64

6.2.2. 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.

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.

7.1. 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.

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“ Story2

7.3. 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.

7.4. 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.

7.5. 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.

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.

8.1. 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.

8.1.1. 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.

8.1.2. 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.

68

8.1.3. 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í.

8.1.4. 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.

8.2. 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.

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.

9.1. 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 e-mail zpráv

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.

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.

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ší.

9.4. 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ů

http://techexcel.com/products/devsuite/

9.5. 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.

http://msdn.microsoft.com/en-us/vstudio/ff637362.aspx

9.6. Hewlett Packard ALM

Je ALM systém vyvinutý a používaný společností Hewlett Packard jako součást jejich IT portfolia v roce 2010. V tabulce označen jako HP ALM.

http://en.wikipedia.org/wiki/HP_Application_Lifecycle_Management

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

http://www.atlassian.com/software/jira/overview

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í 2 5 3 2

Musí podporovat nastavitelné procesy 4 5 5 3

Musí podporovat hromadné úpravy, rozšířené filtrování a full-text vyhledávání

2 4 4 4

Musí mít LDAP/AP podporu 5 5 5

Musí mít správu účtů 4 5 4

Musí mít zdokumentované API 2 5 3 4

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 5 5 4

Podporuje nebo integruje zadávání z lokálních nebo externích zdrojů

3 5 3

Musí podporovat reporting 3 4 3 4

Musí podporovat zasílání emailů a notifikací N/A 4 4

Musí podporovat Agilní a Scrum metodologie 3 5 3

Musí podporovat agilní vyvíjení software. 4 5 3

Ukládá asociace mezi epic, story a task, které jsou přidružené

3 5 5 3

Musí podporovat individuální dotazy do databáze, dotazy mít možnost uložit a sdílet s ostatními

4 5 5 4

Musí podporovat nastavitelné políčka pro tyto typy:

o Textové pole s editorem textu 5 4 3

o Uživatelské políčka 3 5

Musí podporovat verzování 4

Musí podporovat webové prohlížení N/A 5 1

75

Musí podporovat vlastní notifikace nastavitelné skriptem N/A 4 4 1

Musí mít persistentní linky na všechny položky v systému 2 5 4 1

Vedení projektů je jednodušší než v stávajících systémech (Bugzilla, Accompa, Sharepoint)

N/A 1 1

Průměrná známka 3.28 4.72 3.67 3.00

Zdroj: Vlastní

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).

10.1. 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.

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

Zdroj: Vlastní, obrazovka ze systému JIRA

78

Dalším velice důležitým prvkem pro agilní plánování je Product a Sprint backlog. V Product backlogu jsou umístěny všechny Epicy, na kterých tým bude v budoucnu pracovat, zároveň je to kompletní rozsah produktu. Každý Sprint má svůj vlastní Sprint backlog, na který je navázaný Sprint report popsaný výše. Backlog se dá jednoduše prioritizovat a jednotlivé tasky táhnutím myši přidat z Product backlogu do Sprint backlogu.

Obrázek 24: Ukázka backlogu v systému JIRA

Zdroj: Vlastní, obrazovka ze systému JIRA

JIRA díky rozšíření pak dokáže zobrazovat velice zajímavé informace o vytížení týmu a dokonce i procentuální vyjádření počtu tasku na jednotlivce v týmu.

Z pohledu Project managementu je taky velice zajímavý graf poměru vytvořených nových tasků a počtu uzavřených tasků. Z tohoto grafu se dá zjistit, zda zátěž v podobě nových úkolů na tým je z dlouhodobého hlediska zvládatelná a zda výkonnost týmu stačí na splnění všech úkolů.

79

Obrázek 25: Ukázka statistik týmu ze systému JIRA

Zdroj: Vlastní, obrazovka ze systému JIRA

80

JIRA pak umožňuje ze všech dat udělat dashboard, který obsahuje všechny aktuální informace a dá se tak jednoduše aktuálně sledovat stav projektů. Jednou z nejlepších obrazovek je Activity Stream (na obrázku uprostřed), která informuje o aktuálních změnách a novinkách.

Obrázek 26: Dashboard v systému JIRA pro monitorování stavu projektů

Zdroj: Vlastní, obrazovka ze systému JIRA

10.2. Zhodnocení nasazení a používání JIRA

Nasazení JIRA bylo poměrně komplikované z důvodu neustálých úprav procesů, které bylo potřeba udělat tak, aby vyhovovaly všem uživatelům. Pro použití bylo potřeba udělat nespočet vlastních úprav systému tak, aby vyhovoval. Systém se dá poměrně snadno na základní úrovni upravovat přímo v administrační části. Pokud jsou potřeba větší změny, je potřeba sáhnout po úpravě zdrojového kódu JIRA, který Atlassian dodává společně s JIRA. Kód je otevřen pro úpravy v konkrétní firmě a upravované řešení se nesmí nikde dále distribuovat. Další možností je programování vlastních modulů, které se do JIRA dají přidat a rozšířit tak funkcionalitu. JIRA má rovněž API, které umožňuje přístup k databázi, v případě, že máte zájem dělat statistiky nebo zobrazovat data tak, jak to JIRA neumožňuje.

Ovládání JIRA je velice intuitivní pokud jde o základní každodenní úkoly. Ovšem má taky svá negativa. První omezení, na které jsme narazili, byla špatná podpora Story points. Bez vlastních úprav systému byla JIRA nepoužitelná. Největším problémem byla špatně počítaná výkonnost týmu. Všechny úkoly přidané do sprintu až během sprintu, to znamená po jeho plánování, nebyly připočteny k celkovému výkonu týmu, což zkreslovalo výkonnost o více než 50 procent.

81

Hlavním problémem je zde striktnost řešení, které Atlassian propaguje a snaží se pevně dodržovat pravidlo pro přidávání nových úkolů do sprintu, které tvrdí, že by se tasky přidané až za běhu, neměli počítat do výkonnosti týmu.

Na problémy uživatelé přichází každý den a jsou operativně řešeny administrátory JIRA systému, kteří mají systém na starost.

82

11. Závěr

Transformace softwarové firmy na agilní metody je komplikovaný proces, který vyžaduje spoustu příprav a nespočet úprav během samotné transformace. Z mé zkušenosti jsem se snažil vybrat ty nejpodstatnější problémy, které sebou transformace přináší a ve většině případů i jejich řešení. Každý problém, který v této práci popisuji, je třeba řešit proaktivně a v co nejkratším časovém okně.

Agilní metody v první fázi prokazatelně zlepšili komunikaci a spolupráci v rámci vývoje hned po prvotním nasazení. Zvedla se spokojenost vývojářů s odvedenou prací a získalo se více času na dokumentování a testování kódu a přehled o odváděné práci. Rovněž se zlepšilo obecné povědomí o práci mezi vývojáři.

Drhá fáze zavedení agilních metod je již mnohem složitějším procesem, který ovšem přináší největší výhody agilních metod. Přechod z komponentních týmů na produktové je organizačně náročný proces, který z počátku může zpomalit vývoj. Půl roku zpětně tento krok hodnotím jako vůbec nejlepší a nejužitečnější z celého přechodu na agilní metody. Efektivita vývoje se zvedla téměř na dvojnásobek a v menším počtu lidí, se dá stále produkt velice efektivně udržovat a vyvíjet. Tento krok ovšem hlavně přispěl u týmů, které začaly vyvíjet nový produkt, protože se díky tomuto kroku snížila závislost na jiných týmech na nutné minimum.

V celém procesu je stále spousta chyb a pořád je potřeba proces zlepšovat. Rovněž se dá stále zlepšovat integrace týmů a slučování lidí potřebných k vývoji produktu do jednoho týmu. Mezery zatím vidím i v komunikaci s externími týmy v jiných lokacích, která se začíná teď, po půl roce od zavedení agilních metod, rapidně zlepšovat.

I přes veškeré problémy, přes které si musí vývoj projít, se nasazení agilních metod prokazatelně vyplatí. Nejlepším ukazatelem není jen množství odvedené práce před nasazením agilních metod a po nasazení, ale především spokojenost lidí s prací v takovémto procesu. Dalším velice dobrým ukazatelem je větší pružnost vývoje v reakci na změny zadání, které jsou nedílnou součástí agilního přístupu k vývoji produktu. Velice užitečnou vlastností, která se rovněž osvědčila v praxi, je sdílení výsledku se zadavateli projektu po každém ukončeném sprintu. Minimalizuje počet případů nespokojenosti zadavatele s výsledkem.

Celý přechod na agilní metody hodnotím kladně. Agilní metody ovšem nejsou nic zázračného, co by dokázalo spravit veškeré problémy vývoje. Agilní metody jsou obrazně řečeno „Framework“, který se dá pro vývoj využít. Špatným vývojovým týmům v žádném případě nepomůže a je třeba nejdříve řešit základní problémy. U těch dobrých, vede ke zvýšené efektivitě práce, lepší komunikaci a spokojenosti s odvedenou prací.

83

12. Seznam zdrojů

12.1. Knižní zdroje

[1] LARMAN, Craig a Bas VODDE. Scaling lean: thinking and organizational tools for large-scale Scrum. Upper Saddle River, NJ: Addison-Wesley, c2009, xiv, 348 p. ISBN 03-214-8096-1.

[2] LEFFINGWELL, Dean. Agile software requirements: lean requirements practices for teams, programs, and the enterprise. Upper Saddle River, NJ: Addison-Wesley, c2011, xxxv, 518 p. Agile software development series. ISBN 03-216-3584-1.

[3] LEFFINGWELL, Dean. Scaling software agility: best practices for large enterprises. Upper Saddle River: Addison-Wesley, 2007, xxix, 349 s. The Agile software development series. ISBN 03-214-5819-2.

[4] ROYCE, Winston. Managing the development of large software systems. Proceedings, IEEE WESCON. 1970, č. 1, s. 9. Dostupné z: http://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_royce.pdf

12.2. Internetové zdroje

[5] CHAUDHARY, Mukesh. Working with Component Teams: How to Navigate the

Complexity. In: Scrumalliance.org [online]. 2012 [cit. 2013-05-18]. Dostupné z: http://www.scrumalliance.org/articles/444-working-with-component-teams-how-to-navigate-the-complexity

[6] SHANLEY, Raymond. ScrumBut: Construct the Sprint Backlog According to Individual Specialist Capacity. In:Scrumalliance.org [online]. 2009 [cit. 2013-05-18]. Dostupné z: http://www.scrumalliance.org/articles/142-scrumbut-construct-the-sprint-backlog-according-to-individual-specialist-capacity

[7] DOSHI, Hiren. Scrum team organization: Feature teams or Component teams - Part 1. In: Practiceagile.com [online]. 2009 [cit. 2013-05-18]. Dostupné z: http://www.practiceagile.com/2009/07/scrum-team-organization-feature-teams.html

[8] VODDE, Bas. Specialization and Generalization in Teams. In: Scrumalliance.org [online].

2011. vyd. [cit. 2013-05-18]. Dostupné z: http://www.scrumalliance.org/articles/324-specialization-and-generalization-in-teams

[9] LEFFINGWELL, Dean. Organizing at Scale: Feature Teams vs. Component Teams – Part 3. In:Scalingsoftwareagilityblog.com [online]. 2009 [cit. 2013-05-18]. Dostupné z: http://scalingsoftwareagilityblog.com/organizing-agile-at-scale-feature-teams-versus-component-teams-part-3/

[10] MYLLERUP, Bent. Why Agile Does Matter in an Embedded Development Environment.

In: Scrumalliance.org [online]. [cit. 2013-05-18]. Dostupné z: http://www.scrumalliance.org/articles/341-why-agile-does-matter-in-an-embedded-development-environment

[11] MYLLERUP, Bent. Coaching Scrum Teams. In: Scrumalliance.org [online]. 2008 [cit.

2013-05-18]. Dostupné z: http://scrumalliance.org/articles/98-coaching-scrum-teams

84

[12] SZALVAY, Victor. Technical Debt for PMs. In: Scrumalliance.org [online]. 2012 [cit. 2013-05-18]. Dostupné z: http://www.scrumalliance.org/articles/451-technical-debt-for-pms

85

12.3. Seznam obrázků

OBRÁZEK 1: JEDNOTLIVÉ FÁZE PROJEKTU VE VODOPÁDOVÉM MODELU .................................................................... 10 OBRÁZEK 2: IMPLEMENTACE JEDNOHO POŽADAVKU PŘES NĚKOLIK TÝMŮ V KOMPONENTNÍM ROZLOŽENÍ

VÝVOJE BEZ AGILNÍCH METOD. ................................................................................................................................. 16 OBRÁZEK 3: PŘÍKLAD ČASOVÉ OSY VYDÁVÁNÍ MAJORITNÍCH A MINORITNÍCH VERZÍ SOFTWARE ......................... 18 OBRÁZEK 4: UKÁZKA BURNDOWN GRAFU ...................................................................................................................... 30 OBRÁZEK 5 : POSTUP PRÁCE VE SCRUMU ....................................................................................................................... 31 OBRÁZEK 6: IMPLEMENTACE JEDNOHO POŽADAVKU V KOMPONENTNÍM ROZLOŽENÍ VÝVOJE V TÝMECH

FUNGUJÍCÍCH VE SCRUMU. ........................................................................................................................................ 34 OBRÁZEK 7 : ITERACE SESTÁVAJÍCÍ ZE DVOU SPRINTŮ ................................................................................................. 37 OBRÁZEK 8: SCRUM BOARD VE VÝVOJOVÉM TÝMU OBSAHUJÍCÍ NAPLÁNOVANÝ SPRINT ......................................... 38 OBRÁZEK 9: IMPLEMENTACE POŽADAVKU VE FUNKČNÍCH TÝMECH .......................................................................... 46 OBRÁZEK 10: ROZDĚLENÍ ROLÍ VE SPOLEČNOSTI V RÁMCI VÝVOJE ............................................................................ 46 OBRÁZEK 11: PLÁNOVÁNÍ A MONITOROVÁNÍ ITERACÍ ................................................................................................. 50 OBRÁZEK 12: BURNDOWN GRAF VYTVOŘENÝ ZE STORY POINTS ............................................................................... 53 OBRÁZEK 13: BURNDOWN GRAF VYTVOŘENÝ ZE STORY POINTŮ. NEJHORŠÍ VARIANTA ROSTOUCÍHO GRAFU. .. 54 OBRÁZEK 14: CESTA NOVÉHO POŽADAVKU A JEHO STAVY. ......................................................................................... 54 OBRÁZEK 15: ROZPAD EPIC NA STORY ............................................................................................................................ 55 OBRÁZEK 16: ROZPAD EPICU NA VÍCE STORY ................................................................................................................ 56 OBRÁZEK 17: ROZPAD EPICU NA VÍCE STORY S EXTERNÍ ZÁVISLOSTÍ ....................................................................... 57 OBRÁZEK 18: CESTA NOVÉHO POŽADAVKU OD ZAPLÁNOVÁNÍ AŽ PO SCHVÁLENÍ JEHO IMPLEMENTACE ............ 59 OBRÁZEK 19: GRAF ZOBRAZUJÍCÍ RYCHLOST OPRAVY NOVÝCH DEFEKTŮ ................................................................. 62 OBRÁZEK 20: GRAF ZOBRAZUJÍCÍ REÁLNÝ VÝKON TÝMU A PŮVODNÍ ESTIMACE ...................................................... 62 OBRÁZEK 21: SCRUM BOARD V SYSTÉMU JIRA ............................................................................................................. 76 OBRÁZEK 22: UKÁZKA BURNDOWN GRAFU V SYSTÉMU JIRA ..................................................................................... 77 OBRÁZEK 23: UKÁZKA VÝKONOSTNÍHO GRAFU TÝMU V SYSTÉMU JIRA ................................................................... 77 OBRÁZEK 24: UKÁZKA BACKLOGU V SYSTÉMU JIRA .................................................................................................... 78 OBRÁZEK 25: UKÁZKA STATISTIK TÝMU ZE SYSTÉMU JIRA ........................................................................................ 79 OBRÁZEK 26: DASHBOARD V SYSTÉMU JIRA PRO MONITOROVÁNÍ STAVU PROJEKTŮ ............................................ 80

Použité pojmy

Některé pojmy použité v textu nejsou zcela jasně vysvětleny. Při čtení této práce se počítá, že čtenář pojmy již zná, protože jsou z velké části součástí agilní terminologie.

Pojmy pracovních pozic ve společnosti jsou v textu dále zachovány v anglickém jazyce. Slovo „manager“ má český ekvivalent „manažer“, který je v textu práce použit, pokud je psán samostatně.

Project manager – Projektový manažer

Program manager – Programový manažer

Product manager – Produktový manažer

Team leader – Vedoucí týmu

86

Pojmy agilních metod jsou rovněž uvedeny v anglickém jazyce. Anglický jazyk je použitý úmyslně aby došlo k zachování terminologie a názvů se světovými publikacemi a čtenář se tak mohl snadno zorientovat pomocí pojmů i v jiných zdrojích informací.

13. Přílohy

13.1 – Příklad nefungujícího agilního plánování s týmem specialistů 13.2 - Příklady Burndown grafů

13.1. Příklad nefungujícího agilního plánování s týmem specialistů

Tento příklad jasně demonstruje na jednoduchém příkladu, jak přítomnost specialisty v týmu narušuje plánování a celkovou výkonnost agilního týmu. Pro příklad máme 5 komponent vyvíjených jedním týmem. Každý člen týmu má na starost právě jednu komponentu. Každý ze specialistů je schopen za sprint odpracovat trochu jiné množství práce. Výkon týmu je součtem výkonů jednotlivců v týmu. Tento příklad jsem používal v praxi pro názornou ukázku, jak specialisti snižují výkon týmu.

Obrázek z přílohy 1: Spočtená výkonnost týmu

Zdroj: [5]

Náhodně stanovený počáteční backlog pro sprint. Písmeno odpovídá komponentě, na které bude specialista pracovat a odhad ve Story pointech o náročnosti a trvání práce specialisty.

Obrázek z přílohy 2: Náhodný počáteční backlog

87

Zdroj: [5]

Součet práce na jednotlivých komponentách

Obrázek z přílohy 3: Součet všech estimací podle component

Zdroj: [5]

Sprint 1

Pokud projdeme produkt backlog a naplánujeme první sprint podle toho, kolik je schopen každý specialista odpracovat:

Obrázek z přílohy 4: Naplánovaný backlog pro Sprint 1

Zdroj: [5]

Požadavky, které se vlezly do sprintu jsou 1,2,3,4,5,7 a dohromady dávají odhad na 13 story pointů. Ovšem estimovaný výkon týmu je 17 story pointů. Požadavek 6 se nevešel, protože vývojář C už byl plně alokován.

88

Sprint 2

Soupis nových požadavků v backlogu, které přibyly během druhého Sprint planingu do backlogu.

Obrázek z přílohy 5: Nové požadavky pro Sprint 2

Zdroj: [5]

Nový Product backlog pro druhý sprint, ve kterém přibylo po plánování několik nových požadavků. Požadavky, které se budou implementovat v rámci druhého sprintu, jsou označeny odškrtnutím, ty které ne jsou označeny křížkem.

Obrázek z přílohy 6: Naplánovaný backlog pro Sprint 2

Zdroj: [5]

Požadavek číslo 6 je moc velký na to, aby mohl být udělán developerem C v jednom sprintu.

Tento požadavek by měl být rozdělen na menší části. Rozdělení ovšem neřeší to, že developer C je velice časově vytížen a stává se z něj brzda celého týmu a vývoje.

Všimněte si, že se začíná projevovat paradox, kdy je prioritnější úkol odstrčen zpět a dostávají se před něj méně prioritní úkoly.

89

Požadavky, které se vejdou do sprintu, jsou 9, 10, 11, 12, 13, 15, 16, 17 a 20, což dohromady dává naplánovaných 14 story pointů na sprint 2.

Sprint 3

Nové požadavky, které se dostaly do Product backlogu před plánováním třetího sprintu.

Obrázek z přílohy 7: Nové požadavky pro Sprint 3

Zdroj: [5]

Sestavíme Product backlog s požadavky podle toho, které se do třetího sprintu vešly a které ne.

Obrázek z přílohy 8: Naplánovaný backlog pro Sprint 3

Zdroj: [5]

Požadavky, které se vešly do třetího sprintu jsou 14, 19, 21, 23, 25, 28, 29 a 30, což dává celkovou vytíženost týmu 13 Story pointů. Již v tomto sprintu je jasné, že prioritizace přestává fungovat a téměř každý druhý požadavek je nahrazen méně prioritním požadavkem.

90

Komponenta X se stává úzkým hrdlem celého vývoje a developer C má moc přidělené práce a nestíhá komponentu spravovat. Řešením není ani aktuálně některého developera naučit komponentu X a odlehčit tak developerovi C, protože ten nemá čas někoho komponentu učit.

Navíc monitorování takových to úzkých hrdel, které vznikají, je velice náročné a u klasického agilního týmu tato kontrola funguje automaticky.

Sprint 4

Nové požadavky, které se dostaly do Product backlogu před plánováním čtvrtého sprintu.

Obrázek z přílohy 9: Nové požadavky na Sprint 4

Zdroj: [5]

Stejně jako u předchozích sprintů pohled na backlog a požadavky, které se budou během sprintu implementovat.

91

Obrázek z přílohy 10: Naplánovaný backlog pro Sprint 4

Zdroj: [5]

Požadavky, které se dostaly do tohoto sprintu, jsou 18, 24, 31, 33, 34, 35 a 36, což dává celkový plán na tento sprint v součtu na 12 story pointů.

V tomto sprintu bylo vybráno více méně prioritních požadavků z dolní půlky backlogu než z horní půlky backlogu.

Porovnání se Scrum týmem, kde nejsou specialisté.

Sprint 1

Obrázek z přílohy 11: Sprint 1 v týmu bez specialistů

Zdroj: [5]

92

Kapacita týmu je sice 17 story pointů, ale vezmeme na ukázku jen 14 story pointů. Sedm nejprioritnějších požadavků se dostalo do sprintu.

Sprint 2

Obrázek z přílohy 12: Sprint 2 v týmu bez specialistů

Zdroj: [5]

Opět jsme naplánovali pouze 14 story pointů a přesto se osm nejprioritnějších požadavků dostalo do sprintu.

93

Sprint 3

Obrázek z přílohy 13: Sprint 3 v týmu bez specialistů

Zdroj: [5]

Tentokrát naplánujeme 16 ze 17 story pointů z celkového výkonu týmu. V tomto sprintu se udělalo devět nejprioritnějších požadavků.

Sprint 4

Obrázek z přílohy 14: Sprint 4 v týmu bez specialistů

Zdroj: [5]

94

Na poslední sprint naplánujeme 16 ze 17 story pointů z celkového výkonu týmu. V tomto sprintu se udělalo opět devět nejprioritnějších požadavků.

Srovnání obou přístupů

Nyní můžeme srovnat backlogy hotových požadavků u posledního sprintu u obou přístupů:

Obrázek z přílohy 15: Srovnání obou týmů

Zdroj: [5]

Tento příklad ukázal jak se jeden developer specialista mmůže stát brzdou výkonu celého týmu. Navíc tento přístup naprosto ignoruje prioritu požadavků a méně prioritní požadavky jsou často implementovány dříve.

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.

95

13.2. Příklady Burndown grafů

Ideální tým

Tento graf indikuje tým, který je schopen samoorganizace a velice dobré estivace na základě své kapacity. Pravděpodobně má rovněž dobrého Product ownera, který si uvědomuje důležitost nepřidávat nové požadavky během sprintu a kvalitního Scrum Mastera, který týmu pomáhá.

Obrázek z přílohy 16: Ideální tým

Zdroj: Vlastní

Dobrý tým

Tento graf je velmi častým v případě zkušeného týmu, který je schopen úspěšně splnit sprint. Do tohoto stavu se každý tým snaží dostat.

Obrázek z přílohy 17: Dobrý tým

Zdroj: Vlastní

Schopný tým

Tento graf je příkladem klasického postupu práce v agilních týmech. Tým by měl probrat proč došlo k odchylce v první fázi sprintu a snažit se těmto situacím vyvarovat. Ale je schopný sprint bez problému splnit.

96

Obrázek z přílohy 18: Schopný tým

Zdroj: Vlastní

Nedokončený sprint

Tento graf jasně znázorňuje sprint, ve kterém nebyla splněná práce, která byla na sprint naplánována. Tým byl pozadu během celého sprintu. Tým se nepřizpůsobil svému výkonu a pravděpodobně si do sprintu zařadil víc věcí, než je schopen stihnout. Tým by měl při příštím sprintu více brát v potaz svoje kapacity.

Obrázek z přílohy 19: Nedokončený sprint

Zdroj: Vlastní

97

Předčasně dokončený sprint

Všechna práce byla dokončena mnohem dříve než před koncem sprintu. Pravděpodobně za tento stav může špatná estimace úkolů pro daný sprint, nebo špatně změřená výkonnost týmu, podle které se plánuje množství práce pro daný sprint.

Obrázek z přílohy 20: Předčasně dokončený sprint

Zdroj: Vlastní

Odpočinkový sprint

Graf znázorňuje práci týmu, který si do sprintu nabral nedostatek úkolů, jejichž součet náročnosti je mnohem menší než práce, kterou je schopen skutečně udělat. Tým má většinu práce hotovou už v první fázi sprintu a druhou fázi hodně zpomalí práci, aby ji dokončil až s koncem sprintu. V takovém případě by si měl tým během sprintu přibrat další práci.

Obrázek z přílohy 21: Odpočinkový sprint

Zdroj: Vlastní

98

Nereportovaný stav během sprintu

V případě kdy graf spíše připomíná čtverec než klasický Burndown graf, je jasné, že dochází ke špatnému reportování odpracované práce během sprintu. Veškerá udělaná práce se odepisuje až na úplném konci sprintu. Do tohoto stavu by se rozhodně neměl dostat žádný agilní tým a je třeba tento problém okamžitě řešit.

Obrázek z přílohy 22: Nereportovaný stav během sprintu

Zdroj: Vlastní

Nefunkční tým

Pokud je výsledkem sprintu rovný graf, je jasné, že tým vůbec nefunguje. Není jasná příčina, proč k tomuto došlo. Tým by měl začít od úplného začátku a znovu projít školením o agilních metodách.

Obrázek z přílohy 23: Nefunkční tým

Zdroj: Vlastní

99

Nulová estimace

Tento graf znázorňuje několik situací. První je, že úkoly pro daný sprint nejsou estimované a nebo sprint ještě nezačal.

Obrázek z přílohy 24: Nulová estimace

Zdroj: Vlastní

Rostoucí sprint

První sprinty obvykle vypadají přesně takto. Problémem je přidávání nových úkolů během běžícího sprintu. Tým evidentně nezná svou výkonnost a snaží se do sprintu zařadit vše co příjde. Backlog by měl být okamžitě upraven a Product owner poučen o výkonnosti týmu a o zamčení Sprint backlogu během sprintu.

Obrázek z přílohy 25: Rostoucí sprint

Zdroj: Vlastní

100

Nárazníkový tvar

Sprint nebyl správně spuštěn. Chyběl plánovací meeting a úkoly byli do sprintu zařazeny až po jeho spuštění. Správných východiskem v tomto případě je sprint restartovat a spustit od začátku s předchozím naplánováním.

Obrázek z přílohy 26: Nárazníkový tvar

Zdroj: Vlastní