Fakulta elektrotechnická

ˇ ´ vysoke ´ uc ˇen´ı technicke ´ v Praze Cesk e ´ Fakulta elektrotechnicka

´ RSK ˇ ´ PRACE ´ BAKALA A Agiln´ı metodiky programov´ an´ı DAQ a ˇ r´ıdic´ıch aplikac´ı

Praha, 2011

Autor: Adam Hamr

Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem pˇredloˇzenou práci vypracoval samostatnˇe a ˇze jsem uvedl veˇskeré pouˇzité informaˇcn´ı zdroje v souladu s Metodick´ ym pokynem o dodrˇzov´ an´ı etick´ ych princip˚ u pˇri pˇr´ıpravˇe vysokoˇskolsk´ ych závˇereˇcn´ ych prac´ı.

V Praze dne podpis

i

Podˇ ekov´ an´ı Na tomto m´ıstˇe bych rád podˇekoval pˇredevˇs´ım panu Doc. Ing. Jaroslavu Roztoˇcilovi, CSc., vedouc´ımu bakal´ aˇrské práce, za jeho vstˇr´ıcnost bˇehem veden´ı pr´ ace. Také dˇekuji panu Ing. Milanu Kaˇsi za odbornou pomoc a ochotu spolupracovat ´ı dalˇs´ım, kdo podpoˇrili mou pr´ aci dobrou radou.

ii

Abstrakt V posledn´ı dobˇe se rozmach agiln´ıch metodik v´ yvoje softwaru ustaluje a ty z´ıskaly svou konkrétn´ı podobu. Mnoz´ı softwarov´ı specialisté jiˇz vˇed´ı, co se d´ a od nich oˇcekávat. Jejich spr´ avné uˇzit´ı vede k rychlému dosaˇzen´ı kvalitn´ıch v´ ysledk˚ u. V´ yvojovému t´ ymu pˇritom do jisté m´ıry z˚ ust´ av´ a moˇznost postupovat podle sv´ ych zabˇehnut´ ych zvyklost´ı. Práce poskytuje náhled na techniky agiln´ıho v´ yvoje a porovnává je. Také shrnuje zkuˇsenosti odborn´ık˚ u.

iii

Abstract In the last years the expansion of agile software development methodics stabilizes. Therefore methodics obtain a clear schemes. Many software experts are aware of what we can expect from them. The right use of them leads to a fast achievement of quality results. In addition to this the developing team could continue to a certain extent with his custom practice. This essay has to provide a view on agile techniques of software development and compares them. It summarises experience of experts as well.

iv

vi

Obsah Seznam obr´ azk˚ u

xi

´ 1 Uvod

1

1.1

Struktura p´ısemné pr´ ace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2

Z´ akladn´ı pojmy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.2.1

Metodika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.2.2

Iterativn´ı v´ yvoj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.2.3

Inkrement´ aln´ı postup . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

2 Historick´ y kontext vzniku agiln´ıch metodik 2.1

2.2

2.3

2.4

Vodop´ adov´ y model ˇzivotn´ıho cyklu . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.1.1

V´ yhody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.1.2

Nev´ yhody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

Spir´ alov´ y model ˇzivotn´ıho cyklu . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.2.1

Pr˚ ubˇeh v´ yvoje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.2.2

V´ yhody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.2.3

Nev´ yhody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

Rational unified process (RUP) . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.3.1

Kl´ıˇcové pojmy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.3.2

V´ yhody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.3.3

Nev´ yhody . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

Unified software development process (UP) . . . . . . . . . . . . . . . . . . . . .

8

3 Agiln´ı metodiky 3.1

3

9

Z´ akladn´ı charakteristika agiln´ıch metodik . . . . . . . . . . . . . . . . . . . . . .

9

3.1.1

Manifest agiln´ıho v´ yvoje softwaru

9

3.1.2

Principy umoˇzn ˇuj´ıc´ı progresivn´ı v´ yvoj . . . . . . . . . . . . . . . . . . . . 10

3.1.3

Omezuj´ıc´ı poˇzadavky

3.1.4

Odliˇsnosti od tradiˇcn´ıch metodik . . . . . . . . . . . . . . . . . . . . . . . 11

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

vii

3.1.5

Nev´ yhody agiln´ıch metodik . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2

Pˇrehled nejbˇeˇznˇejˇs´ıch agiln´ıch metodik . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3

Extrémn´ı programov´ an´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.1

Charakteristika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3.2

Z´ akladn´ı principy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.3.2.1 3.3.2.2 3.3.2.3

3.4

3.5

Pˇr´ıklady zn´ am´ ych myˇslenek a postup˚ u . . . . . . . . . . . . . . 15 ˇ ri promˇenné charakterizuj´ıc´ı v´ Ctyˇ yvoj . . . . . . . . . . . . . . . 16 ˇ ri hodnoty . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Ctyˇ

3.3.3

Z´ akladn´ı metody XP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3.4

Z´ akladn´ı ˇcinnosti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3.5

Pr˚ ubˇeh v´ yvoje jedné verze . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3.6

V´ yvoj prvn´ı verze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.7

T´ ymové role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3.8

Z´ avˇer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Lean software development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.4.1

Z´ akladn´ı charakteristika . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4.2

Kl´ıˇcové pojmy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.4.2.1

Pl´ ytv´ an´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4.2.2

Hodnota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4.3

Kl´ıˇcov´ a pravidla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.4.4

Z´ akladn´ı principy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.4.5

Z´ avˇer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Scrum development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.5.1

Z´ akladn´ı charakteristika . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.5.2

Kl´ıˇcové pojmy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.5.3

3.5.2.1

Flexibilita a spolupráce . . . . . . . . . . . . . . . . . . . . . . . 29

3.5.2.2

Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.5.2.3

Graf zb´ yvaj´ıc´ı práce . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.5.2.4

Riziko . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.5.2.5

Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.5.2.6

Pigs a chickens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.5.2.7

Denn´ı sch˚ uzka . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Pr˚ ubˇeh v´ yvoje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 3.5.3.1

Pr˚ ubˇeh jednoho sprintu . . . . . . . . . . . . . . . . . . . . . . . 32

3.5.3.2

Pˇredˇcasné ukonˇcen´ı sprintu . . . . . . . . . . . . . . . . . . . . . 33

3.5.4

T´ ymové role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.5.5

Spolupráce v´ıce t´ ym˚ u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 viii

3.5.6 3.6

Feature driven development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.6.1

Základn´ı charakteristika . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.6.2

Kl´ıˇcové pojmy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.6.2.1

Vlastnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.6.2.2

Pˇr´ıstup ˇr´ızen´ y modelem . . . . . . . . . . . . . . . . . . . . . . . 36

3.6.3

Pr˚ ubˇeh v´ yvoje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.6.4

Z´ akladn´ı principy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.6.5 3.7

Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.6.4.1

Objektové modelov´ an´ı domén

3.6.4.2

V´ yvoj podle vlastnost´ı . . . . . . . . . . . . . . . . . . . . . . . 39

3.6.4.3

Vlastnictv´ı tˇr´ıd . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.6.4.4

T´ ymy sestavované podle vlastnost´ı . . . . . . . . . . . . . . . . . 39

3.6.4.5

Inspekce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Test driven development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.7.1

Charakteristika . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.7.2

Základn´ı principy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.7.3

Pr˚ ubˇeh v´ yvoje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.7.3.1

3.7.4 3.8

. . . . . . . . . . . . . . . . . . . 38

Pr˚ ubˇeh jednoho cyklu . . . . . . . . . . . . . . . . . . . . . . . . 42

Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Porovn´ an´ı agiln´ıch metodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.8.1

Velikost t´ ym˚ u a projekt˚ u . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.8.2

Nároˇcnost na zaveden´ı a provoz . . . . . . . . . . . . . . . . . . . . . . . . 43

3.8.3

M´ıra omezen´ı pravidly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.8.4

Rozˇs´ıˇrenost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.8.5

Pˇrijatelnost pro zákazn´ıka . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.8.6

Zajiˇstˇen´ı kvality (quality assurance) . . . . . . . . . . . . . . . . . . . . . 44

3.8.7

Kombinace metodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.8.8

Truck factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.8.9

Psan´ı nadbyteˇcného kódu . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.8.10 Dokumentace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.9

3.8.11 Spoleˇcné vlastnosti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 ˇ ızen´ı projekt˚ R´ u v praxi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.9.1

3.9.2

Agiln´ı metodiky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.9.1.1

V´ yhody, kter´ ych si firmy nejv´ıc cen´ı . . . . . . . . . . . . . . . . 48

3.9.1.2

Nev´ yhody, které firm´ am nejv´ıc vad´ı . . . . . . . . . . . . . . . . 48

Ostatn´ı zp˚ usoby ˇr´ızen´ı projekt˚ u . . . . . . . . . . . . . . . . . . . . . . . . 49 ix

4 Z´ avˇ er

51

A N´ azev pˇ r´ılohy

I

B Obsah pˇ riloˇ zen´ eho CD

III

x

Seznam obr´ azk˚ u 2.1

Schéma vodop´ adového modelu ˇzivotn´ıho cyklu . . . . . . . . . . . . . . . . . . .

2.2

Schéma spir´ alového modelu ˇzivotn´ıho cyklu; zdroj - http://3.bp.blogspot.

4

com/_El72O8-WX9g/TNDqfSRLFbI/AAAAAAAAACU/2DXXgJJ99CY/s1600/spiral_model. gif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

3.1

Cena zmˇeny poˇzadavk˚ u; zdroj - developerfusion.com . . . . . . . . . . . . . . . . 12

3.2

Moˇzn´ a podoba karty zadán´ı pouˇz´ıvané v XP. Jej´ı obsah stanovuje zákazn´ık.; pˇrekresleno podle 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3

Vz´ ajemn´ y vztah ˇcinnost´ı v XP; pˇrekresleno podle 9 . . . . . . . . . . . . . . . . 19

3.4

Postup pˇri v´ yvoji podle tradiˇcn´ıch metodik; pˇrekresleno podle 9 . . . . . . . . . 25

3.5

Graf zb´ yvaj´ıc´ı pr´ ace; zdroj - http://www.businessvize.cz/rizeni-a-optimalizace/agilniprojektove-rizeni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.6

Schéma v´ yvoje softwaru podle FDD; pˇrekresleno podle 9 . . . . . . . . . . . . . 36

3.7

Postup pˇri v´ yvoji softwaru podle TDD; pˇrekresleno podle 9 . . . . . . . . . . . . 42

xi

xii

Kapitola 1

´ Uvod St´ ale v´ıce softwarov´ ych spoleˇcnost´ı se v dneˇsn´ı dobˇe zab´ yv´ a efektivitou v´ yvoje a pokouˇs´ı se o co nejlepˇs´ı vyuˇzit´ı sv´ ych sil a zdroj˚ u. Kaˇzdá kter´ a mezi nˇe patˇr´ı, zcela jistˇe pouˇzije zásady, které jiˇz zavedly nˇekteré z agiln´ıch metodik. Aplikuje tyto principy, at’ se na agiln´ı techniky pˇr´ımo orientuje nebo ne. Také je stále v´ıce firem, které se zab´ yvaj´ı otázkou, jestli by tyto techniky nebyly pˇr´ınosné pr´ avˇe pro nˇe. To svˇedˇc´ı o tom, ˇze agiln´ı programov´ an´ı uˇz nen´ı nic mimoˇrádného nebo nadstandardn´ıho. Pravdˇepodobnˇe pˇrich´ az´ı jako nová etapa softwarového inˇzen´ yrstv´ı1 a v budoucnu se bez zaveden´ı podobn´ ych postup˚ u neobejde ˇzádn´ y projektov´ y manaˇzer. ´ celem této pr´ Uˇ ace je pˇribl´ıˇzit a zhodnotit jednotlivé zp˚ usoby organizace v´ yvoje. Dále také porovnat v´ yhody a nev´ yhody jednotliv´ ych agiln´ıch metodik a naznaˇcit moˇznosti jejich zaˇclenˇen´ı. Také jsem se zamˇeˇril na eventuality jejich kombinac´ı. Práce tedy m˚ uˇze pomoci jako vod´ıtko pˇri hled´ an´ı vhodného zp˚ usobu ˇr´ızen´ı projekt˚ u pro konkrétn´ı v´ yvojov´ y t´ ym.

1.1

Struktura p´ısemn´ e pr´ ace

Pr´ ace m´ a ˇctyˇri kapitoly. V prvn´ı kapitole je rozebr´ ano zadán´ı, pops´ ana struktura dokumentu a uvedeny nˇekteré d˚ uleˇzité pojmy. Druh´ a kapitola slouˇz´ı jako ilustrace historick´ ych souvislost´ı a prezentuje tradiˇcn´ı postupy. Tˇret´ı kapitola nejprve charakterizuje a d´ al porovnáv´ a r˚ uzné agiln´ı metodiky. Také je zaˇrazena podkapitola se souhrnem praktick´ ych zkuˇsenost´ı v ˇr´ızen´ı softwarov´ ych projekt˚ u. Zhodnocen´ı pˇr´ınosu jednotliv´ ych druh˚ u ˇr´ızen´ı projekt˚ u se nach´ az´ı v kapitole ˇctvrté. V pˇr´ıloze je popsána funkcionalita modulu do ˇr´ıdic´ıho systému DisCo. 1

Softwarové inˇzen´ yrstv´ı je zaveden´ı a pouˇz´ıv´ an´ı ˇra ´dn´ ych inˇzen´ yrsk´ ych princip˚ u tak, abychom dos´ ahli ekono” ´ clav mické tvorby softwaru, kter´ y je spolehliv´ y a pracuje u ´ˇcinnˇe na dostupn´ ych v´ ypoˇcetn´ıch prostˇredc´ıch.“ (Va Kadlec, 2004, strana 22)

1

´ KAPITOLA 1. UVOD

2

1.2

Z´ akladn´ı pojmy

V oblasti ˇr´ızen´ı softwarov´ ych projekt˚ u jsou kl´ıˇcové následuj´ıc´ı pojmy, které budu pouˇz´ıvat.

1.2.1

Metodika

V oblasti v´ yvoje softwaru jde o komplexn´ı postup, návod pro v´ yvoj aplikace. Zab´ yv´ a se pohledem z v´ yˇsky na projekt jako celek. Rad´ı, proˇc a kdy se m´ a co dˇelat, co se má vytvoˇrit a kdo má na starosti jak´ yu ´kol. Neodpov´ıd´ a na podrobné ot´ azky, jak pˇresnˇe se m´ a nˇeco provádˇet - na ty odpov´ıdaj´ı d´ılˇc´ı metody. Avˇsak metodika vypov´ıdá v´ıc neˇz model ˇzivotn´ıho cyklu, kter´ y pouze ˇr´ıká, kter´ ymi f´ azemi softwarov´ y produkt proch´ az´ı. Je d˚ uleˇzité, aby kaˇzd´ y ˇclen t´ ymu metodiku znal a ˇr´ıdil se j´ı.

1.2.2

Iterativn´ı v´ yvoj

V´ yvojov´ y proces se rozdˇel´ı do nˇekolika iterac´ı. V kaˇzdé z nich se kompletnˇe zpracuje nˇekter´ y fragment systému. Po jeho dokonˇcen´ı se otestuje integrace této ˇcásti do celého systému a je moˇzné ji odevzdat z´ akazn´ıkovi. N´ asleduje dalˇs´ı iterace.

1.2.3

Inkrement´ aln´ı postup

Spoˇc´ıvá v tom, ˇze uˇz od prvn´ı iterace existuje funkˇcn´ı a pouˇziteln´ y systém. S kaˇzdou dalˇs´ı iterac´ı se rozˇsiˇruje o nové funkcionality. T´ım se umoˇzn ˇuje otestov´ an´ı v praxi uˇz od ran´ ych fáz´ı v´ yvoje. Zároveˇ n zákazn´ık vid´ı, jak postupuje pr´ ace a m˚ uˇze se k n´ı vyjadˇrovat.

Kapitola 2

Historick´ y kontext vzniku agiln´ıch metodik Do konce ˇsedes´ at´ ych let 20. stolet´ı se daj´ı pokusy o v´ yvoj softwarov´ ych aplikac´ı oznaˇcit jako pr˚ ukopnické. Koncem ˇsedesát´ ych let doˇslo k softwarové krizi zp˚ usobené ˇspatn´ ym veden´ım projekt˚ u a také zvyˇsov´ an´ım n´ arok˚ u na nˇe. Jej´ım hlavn´ım d˚ usledkem byl ne´ uspˇech, pˇresnˇeji nedodán´ı, vˇetˇsiny projekt˚ u [ 9 kap. 2.2]. V sedmdes´ at´ ych letech vzniká obor softwarové inˇzen´ yrstv´ı [ 9 kap. 2 ]. Ten souvis´ı pˇredevˇs´ım s rozˇs´ıˇren´ım aplikac´ı interaguj´ıc´ıch s uˇzivatelem a dále se zv´ yˇsen´ım dostupnosti hardwaru. V roce 1967 vznikl Ericsson˚ uv model, kter´ y zaˇcal modelovat sloˇzité systémy jako mnoˇzinu propojen´ ych blok˚ u [ 9 kap. 8.1]. V této dobˇe se v´ yvoj´ aˇri zaˇcali zam´ yˇslet nad t´ım, jak zv´ yˇsit efektivitu práce, a v´ yvoj se formoval do konkrétn´ıch podob. Efektivita spoˇc´ıvala pˇredevˇs´ım v uspoˇrádán´ı v´ yvoje softwarového projektu do posloupnosti fáz´ı. Mezi nˇe byla novˇe zaˇrazena zejména anal´ yza a specifikace poˇzadavk˚ u. T´ım vznikl vodopádov´ y model ˇzivotn´ıho cyklu. V osmdesát´ ych letech se softwarové inˇzen´ yrstv´ı dále rozv´ıjelo. Vypukl pˇrevratn´ y objektovˇe orientovan´ y pˇr´ıstup a s n´ım nové postupy. Efektivita v´ yvoje spoˇc´ıvala v jeho ˇr´ızen´ı urˇcitou metodikou. Roku 1985 Barry Boehm pˇredstavil spir´ alov´ y model ˇzivotn´ıho cyklu, kter´ y pˇrinesl iterativn´ı pˇr´ıstup. T´ım se zaˇcala oˇsetˇrovat rizika, která mohou pˇri v´ yvoji vzniknout. 1987 vyvinul Ivar Jacobson ve spolupráci s telekomunikaˇcn´ı firmou metodiku Objectory process a t´ım byly poloˇzeny z´ aklady pro metodiky RUP a UP - viz d´ ale. Objectory process poprvé pracuje s pojmem pˇr´ıpad uˇzit´ı. Devadesát´ a léta pˇrinesla dalˇs´ı dva d˚ uleˇzité koncepty. Roku 1995 ˇslo o metodiku Rational unified process a roku 1999 o Unified software development process. Zaˇcátkem 21. stolet´ı se efektivity v´ yvoje dosahuje pomoc´ı nové skupiny metodik v´ yvoje - agiln´ıch. Roku 2001 byl pro nˇe poloˇzen z´ aklad Manifestem agiln´ıho v´ yvoje softwaru. Nyn´ı se pod´ıvejme, o co jde v tradiˇcn´ıch metodik´ ach. 3

´ KONTEXT VZNIKU AGILNÍCH METODIK KAPITOLA 2. HISTORICKY

4

Obr´ azek 2.1: Schéma vodopádového modelu ˇzivotn´ıho cyklu

2.1

Vodop´ adov´ y model ˇ zivotn´ıho cyklu

Jde o prvn´ı a pravdˇepodobnˇe nejznámˇejˇs´ı model ˇzivotn´ıho cyklu. Zároveˇ n prvn´ı pˇredpis postupu pˇri v´ yvoji softwaru. Ten zaˇcal b´ yt poprvé ˇclenˇen na jednotlivé aktivity. Postupuje se sekvenˇcnˇe podle logické posloupnosti fáz´ı bez jak´ ychkoli iterac´ı. Pˇri kaˇzdém pˇrechodu mezi dvˇema f´ azemi docház´ı ke schvalovac´ımu procesu. Bˇehem v´ yvoje lze pˇrech´ azet mezi f´ azemi vˇzdy o jednu dopˇredu nebo zpˇet. Bˇehem u ´drˇzby je moˇzné se vr´ atit ke kterékoliv fázi a pokraˇcovat následuj´ıc´ımi. Tento model lze povaˇzovat za nejobecnˇejˇs´ı pˇr´ıpad metodiky, protoˇze kaˇzdá urˇcit´ ym zp˚ usobem zahrnuje fáze v´ yvoje vodop´ adového modelu: 1. Definice problému, poznán´ı z´ akazn´ıka, proniknut´ı do c´ılové oblasti 2. Anal´ yza a specifikace poˇzadavk˚ u 3. Návrh systému 4. Implementace systému 5. Integrace a testován´ı systému 6. Provoz a u ´drˇzba Model m´ a spousty r˚ uzn´ ych podob a tato vych´ az´ı ze [ 2 ].

2.1.1

V´ yhody

Kaˇzdá fáze vych´ az´ı pouze z v´ ystupn´ıho dokumentu té pˇredchoz´ı. K hlavn´ım pozitiv˚ um modelu ˇ ızen´ı procesu je tedy snadné a velice pˇrehledné. Velmi se patˇr´ı, ˇze je jednoduch´ y a pˇr´ıstupn´ y. R´

´ ´ MODEL ZIVOTN ˇ ÍHO CYKLU 2.2. SPIRALOV Y

5

hod´ı pro jednoduché systémy. V´ ysledn´ y projekt pak m´ a disponovat u ´plnou dokumentac´ı.

2.1.2

Nev´ yhody

Tento postup se vˇsak svou jednoduchost´ı nehod´ı pro projekty rozsáhlejˇs´ı. Striktnˇe dan´ a posloupnost f´ az´ı zp˚ usobuje, ˇze je v´ yvoj nepruˇzn´ y, kdyˇz nen´ı moˇzné se vracet k f´ az´ım procesu starˇs´ım neˇz je pˇredchoz´ı. Pot´ıˇze vznikaj´ı také t´ım, ˇze nen´ı moˇzné dodrˇzet p˚ uvodn´ı plán, pokud se zpozd´ı i jediná f´ aze. Po zah´ ajen´ı procesu z´ akazn´ık nekomunikuje s dodavatelem a do posledn´ı chv´ıle pˇred dod´ an´ım mu nen´ı známé, jak´ y bude v´ ysledek. D˚ usledkem toho je nejistota, zda je návrh spr´ avn´ y. Jeho kompletn´ı tvorba je v praxi nesplnitelná a nav´ıc zab´ır´ a pˇr´ıliˇs mnoho ˇcasu. Z´ asadn´ı problém vodop´ adového modelu tedy spoˇc´ıv´ a ve specifikaci poˇzadavk˚ u, kterou nen´ı moˇzné provést najednou a pozdˇeji nemˇenit. Kv˚ uli tomu je v´ yvoj velmi neefektivn´ı.

2.2

Spir´ alov´ y model ˇ zivotn´ıho cyklu

Nejd˚ uleˇzitˇejˇs´ım pˇr´ınosem tohoto modelu pro softwarové inˇzen´ yrstv´ı jsou dva nové postupy. Je to anal´ yza rizik1 a iterativn´ı pˇr´ıstup. S n´ım je spojena v´ yhoda modularity aplikace2 . V kaˇzdé iteraci se opakuj´ı f´ aze, které popisuje vodop´ adov´ y model. Pˇritom se zpˇresˇ nuj´ı poˇzadavky, odhaluj´ı se nov´ a rizika a pl´ anuje se následuj´ıc´ı cyklus. Bˇehem anal´ yzy rizik se zjiˇst’uje, co m˚ uˇze ohrozit hladk´ y pr˚ ubˇeh projektu, a pˇripravuj´ı se reakce na tyto události. Rozliˇsuj´ı se tyto druhy rizik: • Projektov´ a rizika - pˇr´ıkladem je odchod lid´ı z t´ ymu • Technick´ a rizika - mezi nˇe patˇr´ı problémy s v´ yvojov´ ymi n´ astroji • Obchodn´ı rizika - napˇr. uveden´ı konkurenˇcn´ı aplikace Dalˇs´ı z nejpouˇz´ıvanˇejˇs´ıch metod k odstranˇen´ı rizik a chyb je vytv´ aˇren´ı prototyp˚ u.

2.2.1

Pr˚ ubˇ eh v´ yvoje

Pod´ıvejme se podrobnˇeji na posloupnost krok˚ u pˇri v´ yvoji podle spir´ alového modelu. Postupuje se podle obrázku obr. 2.2 po spir´ ale od stˇredu na kraj. Nejprve popiˇsme ˇctyˇri kvadranty, kter´ ymi spirála proch´ az´ı. Kdykoliv se projekt dostane do levého horn´ıho kvadrantu, stanovuj´ı se c´ıle, 1 2

Riziko je jak´ akoliv ud´ alost, pˇri které m˚ uˇze b´ yt projekt ohroˇzen. Aplikace je sloˇzena z modul˚ u, z nichˇz kaˇzd´ y zahrnuje urˇcitou element´ arn´ı funkcionalitu. Jednotlivé moduly

jsou pouˇzitelné nez´ avisle na ostatn´ıch a m˚ uˇzou b´ yt pouˇzity i v aplikac´ıch zcela jin´ ych, neˇz pro které byly poprvé vyrobeny.

6


Obr´ azek 2.2: Schéma spir´ alového modelu ˇzivotn´ıho cyklu; zdroj http://3.bp.blogspot.com/_El72O8-WX9g/TNDqfSRLFbI/ AAAAAAAAACU/2DXXgJJ99CY/s1600/spiral_model.gif

alternativy a omezen´ı pro aktu´ aln´ı iteraci. Prav´ y horn´ı kvadrant je vyhrazen anal´ yze rizik. V pravém spodn´ım kvadrantu prob´ıh´ a realizace, coˇz je hlavnˇe specifikace poˇzadavk˚ u, podrobnˇejˇs´ı n´ avrh, implementace a testov´ an´ı. Posledn´ı kvadrant je urˇcen k pl´ anován´ı dalˇs´ı iterace.

2.2.2

V´ yhody

Je kladen velk´ y d˚ uraz na anal´ yzu rizik a u ´spˇeˇsnˇe se tedy pˇredch´ az´ı vˇetˇsinˇe problém˚ u, ke kter´ ym m˚ uˇze pˇri v´ yvoji doj´ıt. To vˇcas vylouˇc´ı nevhodná ˇreˇsen´ı. Dalˇs´ı v´ yhody spirálového modelu spoˇc´ıvaj´ı v jeho komplexnosti, takˇze je vhodn´ y pro sloˇzité projekty. Také v tom, ˇze je pro kaˇzdou aktivitu a zdroj definov´ ana m´ıra dostatku. Riziky ˇr´ızen´ y pˇr´ıstup napˇr´ıklad umoˇzn ˇuje stanovit, kolik ˇcasu je potˇreba vyhradit jednotliv´ ym krok˚ um.

2.2.3

Nev´ yhody

Komplikovan´ y spir´ alov´ y model pˇrin´ aˇs´ı následuj´ıc´ı nev´ yhody: Je zat´ıˇzen mnoˇzstv´ım byrokraˇ tick´ ych povinnost´ı, coˇz sniˇzuje efektivitu a rychlost v´ yvoje. Clenov´ e t´ ymu mus´ı b´ yt schopni spolehlivˇe analyzovat zdroje rizik, jinak projekt m˚ uˇze ztroskotat. Bˇehem práce nelze prov´ adˇet zmˇeny kdykoliv, jen po dokonˇcen´ı cyklu. T´ım vznikaj´ı zbyteˇcné ˇcasové prodlevy. Pˇred koneˇcnou fáz´ı nen´ı dod´ an ˇz´ adn´ y software a do té doby nen´ı z´ akazn´ıkovi znám´ a jeho podoba. Spir´ alov´ y model nen´ı skuteˇcnou metodikou a nepopisuje tedy ani zhruba vˇsechny d˚ uleˇzité ˇcinnosti.

2.3. RATIONAL UNIFIED PROCESS (RUP)

2.3

7

Rational unified process (RUP)

V tomto odstavci se zamˇeˇr´ıme na velmi obecnou, ˇsirokou a mohutnou metodologii3 vhodnou pro mnoho druh˚ u projekt˚ u. Jej´ım tv˚ urcem je Ivar Jacobson s firmou Rational. Ta v souˇcasnosti spad´ a pod IBM [ ?? ]. V´ yvoj prob´ıhá v iterac´ıch, coˇz má podobn´ y pˇr´ınos jako u spirálového modelu. Pˇredch´ az´ı se rizik˚ um, sn´ az se spravuj´ı zmˇeny a moduly tvoˇr´ıc´ı aplikaci jsou pouˇzitelné opakovanˇe. Také se daˇr´ı pˇribl´ıˇzit se lépe k zákazn´ıkovi. Fáze kaˇzdé iterace jsou zahájen´ı (Inception), projektov´ an´ı (Elaboration), realizace (Construction) a pˇred´ an´ı (Transition) [ 1 ]. Pˇr´ıstup RUP nen´ı pˇr´ımo ˇr´ızen´ y riziky jako Spirálov´ y model, n´ ybrˇz pˇr´ıpady uˇzit´ı. Metodologie je objektovˇe orientovan´ a - definuje vˇsechny d˚ uleˇzité elementy pro modelov´ an´ı a pro plánován´ı v´ yvojového procesu. Kaˇzd´ y element má podrobn´ y popis, jak ho realizovat. Jsou ˇctyˇri [ 1 ]: • Role a pracovn´ıci - Rad´ı jak obsadit role. Odpov´ıdá na otázku kdo? ˇ • Cinnosti - Kaˇzd´ a z nich m´ a konkrétn´ı v´ ysledek (meziprodukt). Popisuje, jak ho dosáhnout. Odpov´ıd´ a na ot´ azku jak? ˇ asti informace pouˇzité v procesu. Odpov´ıdá na otázku co? • Meziprodukty - C´ • Pracovn´ı procesy - Posloupnost ˇcinnost´ı a interakce mezi pracovn´ıky. Odpov´ıdá na ot´ azku kdy?

2.3.1

Kl´ıˇ cov´ e pojmy

ˇ ızen´ı a spr´ Co je pro RUP specifické, je napˇr´ıklad práce se z´ akazn´ıkov´ ymi poˇzadavky. R´ avu zákazn´ıkov´ ych n´ arok˚ u ani jeden ze dˇr´ıvˇejˇs´ıch model˚ u nezahrnuj´ı. D´ ale je definov´ ana u ´spora zdroj˚ u. K tomu je zˇr´ızena podpora komponentové architektury. Komunikace mezi v´ yvoj´ aˇri je zjednoduˇsena d´ıky vizu´ aln´ımu modelov´ an´ı softwaru - vyuˇz´ıv´ a se notace UML. Metodologie je s n´ı dokonale provázan´ a a pouˇzit´ı UML pak pˇri v´ yvoji je v´ yhodné. Kvalita je kontrolována a zajiˇst’ována pr˚ ubˇeˇznˇe, a tak se kaˇzdá chyba odhal´ı krátce po tom, co nastane. Jej´ı oprava je o to levnˇejˇs´ı. Dalˇs´ım ulehˇcen´ım korekc´ı chyb, ale i jin´ ych u ´prav je doporuˇcen´ı, aby zmˇeny byly ˇr´ızené.

2.3.2

V´ yhody

Tato metodologie umoˇzn ˇuje upravit a pˇrizp˚ usobit n´ avod pro kaˇzd´ y projekt. Ten pak obsahuje podrobnˇe propracované a zdokumentované kroky v´ yvoje od zaˇcátku aˇz do konce. V´ yrobce RUP u ´dajnˇe pr˚ ubˇeˇznˇe pracuje na v´ yvoji metodologie, takˇze podporuje i nové technologie. Je zn´ am´ a a rozˇs´ıˇren´ a a existuje k n´ı mnoˇzstv´ı doplˇ nuj´ıc´ıch informac´ı a návod˚ u. 3

Metodologie je obecnˇejˇs´ı pojem neˇz metodika. Je vˇedn´ı discipl´ınou, kter´ a se zab´ yv´ a metodikami.

8

2.3.3


Nev´ yhody

Existuje vˇsak mnoˇzstv´ı d˚ uvod˚ u, proˇc se RUP pouˇz´ıvat nehod´ı. Pˇredevˇs´ım pro malé projekty je postup neefektivn´ı. Metodologie poˇzaduje hluboké studium a t´ ym vˇzdy str´ av´ı mnoho ˇcasu zkoumán´ım n´ avodu a vytv´ aˇren´ım meziprodukt˚ u. Dalˇs´ım argumentem je, ˇze projektov´ı inˇzen´ yˇri a manaˇzeˇri mus´ı b´ yt trénováni v pr´ aci s RUP, jinak projekt nemus´ı skonˇcit u ´spˇeˇsnˇe. RUP se prod´ av´ a jako komerˇcn´ı softwarov´ y produkt.

2.4

Unified software development process (UP)

Tuto metodiku vydal Ivar Jacobson jako knihu ˇctyˇri roky po vzniku RUP. UP je urˇcit´ ym zjednoduˇsen´ım RUP. Rovnˇeˇz jde o inkrement´ aln´ı v´ yvoj v iterac´ıch. Kaˇzdá z nich se skládá z fáz´ı pl´ anov´ an´ı, anal´ yza a n´ avrh, implementace, testov´ an´ı a integrace, dod´ an´ı. V´ yvoj je ˇr´ızen pˇr´ıpady pouˇzit´ı a riziky. UP poˇzaduje d´ avat d˚ uraz na architekturu. Na rozd´ıl od RUP nerozeb´ır´ a do hloubky vˇsechny postupy. Je bezplatná, avˇsak neposkytuje ˇzádné doplˇ nky a bonusy. Také podpora r˚ uzn´ ych v´ yvojov´ ych nástroj˚ u pro UP nen´ı taková, jako pro RUP.

Kapitola 3

Agiln´ı metodiky Agiln´ı metodiky byly zavedeny z potˇreby uˇcinit v´ yvoj efektivnˇejˇs´ı, kvalitnˇejˇs´ı a rychlejˇs´ı. Proto se silnˇe zamˇeˇruj´ı na v´ ysledek. Také v´ yznam slova agiln´ı znaˇc´ı, ˇze jde o v´ yvoj velmi aktivn´ı, sviˇzn´ y, bez zdrˇzov´ an´ı a ˇcasov´ ych prostoj˚ u u jednotliv´ ych fáz´ı.

3.1

Z´ akladn´ı charakteristika agiln´ıch metodik

Tyto techniky zabezpeˇc´ı softwarov´ ym firm´ am flexibilitu, pˇrizp˚ usobivost a pruˇznost. D´ ale metodiky omezuj´ı zmatek, nejistotu a nervozitu v t´ ymu a maximalizuj´ı produktivitu. Jedn´ım slovem lze agiln´ı v´ yvoj charakterizovat jako - progresivn´ı. Charakteristika je d´ ana manifestem agiln´ıho v´ yvoje softwaru (viz [ 3 ]a d´ ale). Bˇehem práce je dobˇre vidˇet postup k c´ıli. Program´ ator pr˚ ubˇeˇznˇe odevzd´ avá jednotlivé ˇcásti projektu. Tˇem jiˇz nemus´ı vˇenovat pˇr´ıliˇsnou pozornost a m˚ uˇze se plnˇe zamˇeˇrit na aktuáln´ı problém. Pokud vznikaj´ı nˇejaké pot´ıˇze, pracovn´ık se o nich vˇcas dozv´ı. Napˇr´ıklad nespokojenost s ovládac´ımi prvky uˇzivatelského rozhran´ı m˚ uˇze zákazn´ık sdˇelit bˇehem ran´ ych iterac´ı, protoˇze v´ yvoj ˇcasto zaˇc´ın´ a formován´ım interface. Agiln´ı metodiky jsou vhodné pro malé a stˇrednˇe velké projekty. Nevedou k efektivn´ımu ˇreˇsen´ı velmi sloˇzit´ ych a komplexn´ıch problém˚ u. Takové je nutno dekomponovat na jednoduˇsˇs´ı. Vˇetˇsina autor˚ u tˇechto metodik m´ a zkuˇsenosti s velk´ ym ne´ uspˇechem nˇejakého projektu. Kaˇzd´ y z nich si dobˇre uvˇedomil vˇsechny v´ yhody i nedostatky v´ yvojov´ ych proces˚ u. To je vedlo k vyvinut´ı flexibiln´ıch metodik, které vylepˇs´ı produktivitu a efektivitu v´ yvojového procesu.

3.1.1

Manifest agiln´ıho v´ yvoje softwaru

V roce 2001 se setkali nejv´ yznamnˇejˇs´ı pˇredstavitelé nov´ ych pˇr´ıstup˚ u ke tvorbˇe softwaru a formulovali principy pro agiln´ı v´ yvoj. Mezi nejznámˇejˇs´ı autory Manifestu agiln´ıho v´ yvoje patˇr´ı Kent 9

KAPITOLA 3. AGILNÍ METODIKY

10

Beck, Mike Beedle, Alistair Cockburn, Ward Cunningham, Martin Fowler, Jim Highsmith, Ken Schwaber, Jeff Sutherland. Neˇz se tito lidé seˇsli, pracovali prakticky nez´ avisle na sobˇe a na v´ yvoj softwaru si vytv´ aˇreli vlastn´ı názory, ˇcasto radik´ aln´ı. Konsensus takto reformn´ıch osobnost´ı na koneˇcné formulaci manifestu znamen´ a, ˇze se shodli na nˇeˇcem podstatném. Z´ akladn´ı teze, ze kter´ ych manifest vych´ az´ı: • Pˇrijmout a umoˇznit zmˇenu je mnohem efektivnˇejˇs´ı, neˇz se pokouˇset j´ı zabránit. • Je tˇreba b´ yt pˇripraven reagovat na nepˇredv´ıdatelné události, nebot’ ty bezpochyby nastanou. Jedin´ a jistota je zmˇena. Na základˇe tˇechto tez´ı autoˇri manifestu dávaj´ı pˇrednost (pˇreklad z [ 3 ]): • individualit´ am a komunikaci pˇred procesy a n´ astroji • provozuschopnému softwaru pˇred obs´ ahlými, objemnými dokumentacemi • spolupr´ aci se z´ akazn´ıkem pˇred uzav´ır´ an´ım mnoha smluv • reakci na zmˇenu pˇred striktn´ım plnˇen´ım pl´ anu V´ aˇz´ı si v´ıce poloˇzek na levé stranˇe, i kdyˇz hodnoty napravo také uzn´ avaj´ı.

3.1.2

Principy umoˇ zn ˇ uj´ıc´ı progresivn´ı v´ yvoj

Existuje v´ıcero princip˚ u, které vedou k progresivitˇe. Mezi hlavn´ı z nich patˇr´ı jednoduchost a rychlost. Lidé nedˇelaj´ı nic neˇz to, co vede k c´ıli - funkˇcn´ı software. Neztr´ ac´ı ˇcas nadbyteˇcnou anal´ yzou, tvorbou m´ alo v´ yznamné dokumentace nebo k´ odu, jehoˇz d˚ uleˇzitost je pouze teoretická, ne skuteˇcná. Z´ asadn´ı je umˇen´ı naj´ıt co nejvˇetˇs´ı mnoˇzstv´ı ˇcinnost´ı, které nen´ı nutno dˇelat. Dalˇs´ı z´ asadou je navrhovat jen to, co je nezbytné pro aktuáln´ı implementaci. Nic se nenavrhuje s vˇetˇs´ım pˇredstihem, protoˇze je pravdˇepodobné, ˇze se to v budoucnu zmˇen´ı. Jedinˇe návrh pro okamˇzitou potˇrebu je zaruˇcenˇe správn´ y. Jinou d˚ uleˇzitou vˇec´ı je d˚ uraz na komunikaci uvnitˇr t´ ymu. Metodiky zd˚ urazˇ nuj´ı, ˇze osobn´ı komunikace je nejrychlejˇs´ı a nejspolehlivˇejˇs´ı. Popisuj´ı konkrétn´ı zp˚ usoby komunikace a pˇredmˇety jedn´ an´ı. Vedouc´ı projektu m´ a správnˇe motivovat pracovn´ıky a také d˚ uvˇeˇrovat v jejich schopnost a zodpovˇednost. Kvalitu projektu podstatnˇe ovlivˇ nuje, jak je u ´zká spolupráce se zákazn´ıky a obchodn´ıky. Ti podle agiln´ıch metodik ˇcasto maj´ı b´ yt souˇcást´ı v´ yvojového t´ ymu.

3.1.3

Omezuj´ıc´ı poˇ zadavky

Agiln´ı metodiky také poˇzaduj´ı jistou discipl´ınu, aby bylo moˇzné dosáhnout progresivity. Jedno z omezen´ı spoˇc´ıv´ a v tom, ˇze programátor nemá rozˇsiˇrovat zad´ an´ı sv´ ymi pˇredstavami. Kvalita aplikace nen´ı pˇr´ımo u ´mˇern´ a jej´ı robustnosti nebo obs´ ahlosti. Napˇr´ıklad nen´ı u ´ˇcelné pˇredpokl´ adat,

´ Í CHARAKTERISTIKA AGILNÍCH METODIK 3.1. ZAKLADN

11

ˇze vytváˇren´ y datab´ azov´ y systém m´ a umˇet nar´ az obslouˇzit stovky klient˚ u, pokud je z´ akazn´ık pˇresvˇedˇcen o tom, ˇze uˇzivateli budou pouze zamˇestnanci jeho malé firmy. Za nejv´ yznamnˇejˇs´ı známku kvality se tedy m´ a povaˇzovat v´ yhradnˇe daná funkˇcnost. Tou nen´ı nic z toho, co jen programátor vid´ı jako potˇrebné. Disciplinovan´ y pracovn´ık pravidelnˇe ovˇeˇruje funkˇcnost u zákazn´ıka. Ten pr˚ ubˇeˇznˇe sleduje stav aplikace d´ıky pravidelnˇe vydávan´ ym meziv´ ysledk˚ um. Urˇcuje spr´ avnost vˇsech ˇc´ ast´ı systému a jejich odezev. D˚ ukladn´ a komunikace se zadavatelem vede k tomu, ˇze se vˇzdy implementuje právˇe takové chován´ı systému, jaké je správné. D´ ale je d˚ uleˇzité, aby se nové verze dodávaly ˇcasto a v mal´ ych dávk´ ach. T´ım se zajist´ı okamˇzit´ a a pˇresná zpˇetná vazba. Nav´ıc ˇcasté odevzd´ aván´ı subsystém˚ u pom´ ahá v´ yvojáˇr˚ um odhalovat chyby a urychluje z´ıskáv´ an´ı zkuˇsenost´ı. Dalˇs´ım pˇredpokladem je, ˇze programátoˇri jsou otevˇren´ı nov´ ym potˇreb´ am zadavatele. Na poˇzadované zmˇeny mus´ı reagovat prakticky ve kterékoliv f´ azi v´ yvoje. To je umoˇznˇeno hlavnˇe iterativn´ım postupov´ an´ım. Manaˇzer projektu mus´ı b´ yt schopn´ y sám plánovat podrobné kroky v dané situaci. Agiln´ı metodiky nedefinuj´ı detailn´ı metody, jak provádˇet jednotlivé ˇcinnosti. M´ alokdy porad´ı konkrétn´ı postup, coˇz m˚ uˇze na jednu stranu vypadat jako nev´ yhoda. Avˇsak na druhou stranu se z´ amˇernˇe zp˚ usob ˇr´ızen´ı projektu necháv´ a pˇrizp˚ usobit okolnostem. Autoˇri Feature driven development tvrd´ı, ˇze metodiky definované do detail˚ u funguj´ı jen v pˇr´ıpadech, kdy v´ yvojov´ y proces je pˇredv´ıdateln´ y a prob´ıh´ a podle pˇresnˇe stanoveného pl´ anu. To se vˇsak v praxi dˇeje ojedinˇele, proto je cennˇejˇs´ı volnost v rozhodov´ an´ı neˇz slepé dodrˇzován´ı pˇredepsan´ ych krok˚ u. Manaˇzer tedy mus´ı zv´ aˇzit, jestli mu staˇc´ı, ˇze metodika jen uk´ aˇze smˇer, jak´ ym se ub´ırat. Jinak si mus´ı zajistit návod na veˇskeré postupy.

3.1.4

Odliˇ snosti od tradiˇ cn´ıch metodik

Podm´ınky kaˇzdého v´ yvojového procesu se d´ a charakterizovat tˇremi základn´ımi promˇenn´ ymi. Jsou to: ˇcas vyhrazen´ y pro v´ yvoj, zdroje a funkcionalita produktu. C´ılem pˇri v´ yvoji tradiˇcn´ım zp˚ usobem je splnit co nejpˇresnˇeji konkrétn´ı pˇredpoklady dané dokumentem specifikace poˇzadavk˚ u. Pˇri v´ yvoji podle agiln´ı metodiky je c´ıl jin´ y - vytvoˇrit projekt v definovaném ˇcase a za urˇcité náklady. Vˇetˇsinou je pro zadavatele pˇrijatelnˇejˇs´ı zmˇena specifikace poˇzadavk˚ u neˇz zdraˇzen´ı nebo posunut´ı term´ınu dodán´ı oproti pˇredpokladu. Poˇzadavky se stejnˇe mˇen´ı vˇzdycky, at’ chceme nebo nechceme. Rozd´ıl mezi obˇema zp˚ usoby tedy spoˇc´ıv´ a v tom, ˇze podle tradiˇcn´ıch zvyklost´ı je hlavn´ı neporuˇsit podm´ınky vymezené promˇennou funkcionalita produktu a ostatn´ı dodrˇzet jen v r´ amci moˇznost´ı v´ yvojového t´ ymu. A pˇri agiln´ım programov´ an´ı se naopak m´ a zachovat ˇcas vyhrazen´ y pro v´ yvoj a pouˇz´ıt jen stanovené zdroje. Podle tradiˇcn´ıch metodik se má pˇredpokl´ adat, ˇze v´ yvoj softwaru je definovan´ y proces. Podle nich u ´koly mohou b´ yt detailnˇe definovány, sloˇzitost implementace algoritm˚ u je moˇzno popsat. V´ ysledky pr´ ace jsou pˇresnˇe mˇeˇritelné a mˇeˇritelnost je vod´ıtko pˇri opakován´ı proces˚ u tak dlouho,


12

Obr´ azek 3.1: Cena zmˇeny poˇzadavk˚ u; zdroj - developerfusion.com

dokud tolerance nejsou zanedbatelné. Je tedy moˇzné pˇredem urˇcit, jak bude prob´ıhat v´ yvojov´ y proces. Tradiˇcn´ı metodiky jsou ˇr´ızeny plánem. Agiln´ı metodiky pl´ anu nepodléhaj´ı, vycházej´ı ˇ ım v´ıce z promˇenliv´ ych podm´ınek a vlastnˇe jsou ˇr´ızeny moment´ aln´ımi poˇzadavky z´ akazn´ıka. C´ jsou nestálé, a z´ aroveˇ n ˇc´ım v´ıce je technologie neznám´ a, t´ım vyˇsˇs´ı ˇsanci na u ´spˇech maj´ı agiln´ı pˇr´ıstupy oproti tradiˇcn´ım. Tolik je nejd˚ uleˇzitˇejˇs´ıch odliˇsnost´ı ohlednˇe obecného pˇr´ıstupu. Následuj´ı rozd´ıly v konkrétn´ıch postupech. Anal´ yza poˇzadavk˚ u a celého problému v˚ ubec je pˇri agiln´ım programov´ an´ı podstatnˇe zrychlená. Vˇzdy se analyzuje pouze to, co je momentálnˇe d˚ uleˇzité. O to d˚ uslednˇejˇs´ı mus´ı b´ yt testov´ an´ı. Barry Boehm ˇr´ık´ a: Nalezen´ı a odstranˇen´ı chyby je stokr´ at draˇzˇs´ı po dokonˇcen´ı produktu neˇz ze zaˇc´ atku vývoje. Coˇz také v´ ystiˇznˇe dokumentuje obrázek obr. 3.1. Hojnˇe se vyuˇz´ıvaj´ı automatizované testy. Obvykle se maj´ı psát dˇr´ıve neˇz zdrojov´ y k´ od programu. Neztr´ ac´ı se ˇcas vytváˇren´ım dokument˚ u, bez kter´ ych se program´ atoˇri obejdou. D˚ uleˇzitˇejˇs´ı neˇz dokumentace je orientace ve zdrojovém kódu. Ten tvoˇr´ı ˇcasto spolu s testovac´ım kódem hlavn´ı ˇcást dokumentace. Lidé oceˇ nuj´ı i fakt, ˇze v´ yvoj podle agiln´ıch metodik je zábavnˇejˇs´ı neˇz podle tradiˇcn´ıch.

3.1.5

Nev´ yhody agiln´ıch metodik

Byla pops´ ana vˇsemoˇzn´ a pozitiva agiln´ıch metodik. Nyn´ı jsou na ˇradˇe jejich nev´ yhody a pot´ıˇze, t´ ykaj´ıc´ı se pˇredevˇs´ım manaˇzera projektu. Protoˇze jsou tyto metodiky novˇejˇs´ı neˇz tradiˇcn´ı techniky, jev´ı se ménˇe pˇrirozené a h˚ uˇr se zav´ ad´ı. Nˇekteré metodiky jsou velmi pˇr´ısné a vyˇzaduj´ı velkou discipl´ınu (napˇr´ıklad XP). Obecnˇe kladou velké nároky na kvalitu pracovn´ık˚ u. D´ ale je pot´ıˇz pˇresvˇedˇcit z´ akazn´ıka o tom, ˇze se mu vyplat´ı investovat vlastn´ı ˇcas do spolupráce na v´ yvoji.

ˇ ˇ ZN ˇ EJ ˇ SˇÍCH AGILNÍCH METODIK 3.2. PREHLED NEJBE

13

Na zaˇc´ atku se d´ a jen obt´ıˇznˇe urˇcit, jak´ y bude v´ ysledek. Nelze tedy pˇresnˇe ˇr´ıct, jak dlouho potrvá v´ yvoj systému a jestli se do stanoveného term´ınu stihnou vytvoˇrit vˇsechny poˇzadované souˇcásti. Podobnˇe pˇredem nejde urˇcit, zda bude k dokonˇcen´ı projektu staˇcit stanovená koneˇcn´ a cena. Ta se odv´ıj´ı bud’ od doby strávené na projektu, nebo se urˇc´ı cena za jednotku pr´ ace a doplác´ı se za nové poˇzadavky. V praxi doch´ az´ı k rozˇsiˇrov´ an´ı zad´ an´ı a t´ım k posouv´ an´ı term´ınu dodán´ı. Na konci projektu jde pak tˇeˇzko rozliˇsit, co z´ akazn´ık definoval na zaˇcátku a co dodefinoval v pr˚ ubˇehu. Jestliˇze m´ a v´ yvoj prob´ıhat agilnˇe, nen´ı moˇzné dokumentovat kaˇzdou zmˇenu. Je tedy nutné provést jak´ ysi kompromis a vydat nˇekolik dokument˚ u nav´ıc. Zákazn´ık typicky nechce pˇristoupit na nejisté podm´ınky. Také nechce zaplatit za práci na pˇrán´ıch, která nebyla prokazatelnˇe vyslovena aˇz v pr˚ ubˇehu v´ yvoje. Vˇetˇsinou se agiln´ı metodiky nehod´ı pro pˇr´ıliˇs velké projekty. Rozs´ ahlé t´ ymy potˇrebuj´ı striktn´ı pravidla a ta jsou v rozporu s agiln´ım v´ yvojem. Jak je vˇsak uvedeno d´ ale , podle nˇekter´ ych agiln´ıch metodik jdou ˇr´ıdit i rozs´ ahlé projekty.

3.2

Pˇ rehled nejbˇ eˇ znˇ ejˇ s´ıch agiln´ıch metodik

1. Extr´ emn´ı programov´ an´ı (Extreme Programming, d´ ale jen XP) Autor - Kent Beck XP je zˇrejmˇe nejpropracovanˇejˇs´ı metodika. Vych´ az´ı z pˇrirozeného lidského pˇr´ıstupu. Na jeho základˇe jsou postavena pravidla, kter´ a jsou extrémn´ım zes´ılen´ım myˇslenek tohoto pˇr´ıstupu. Napˇr´ıklad jde snadno kaˇzdá jednoduch´ a práce, proto vytv´ aˇrejme co nejjednoduˇsˇs´ı produkt, kter´ y ale jeˇstˇe bude fungovat. Metodika se velmi dobˇre hod´ı pˇri tvorbˇe menˇs´ıch produkt˚ u, které maj´ı nejasné nebo ˇcasto se mˇen´ıc´ı zad´ an´ı. 2. Lean Software Development (d´ ale jen Lean development) Autoˇri - Tom a Mary Poppendieck Lean development nevzniklo jako formalizace v´ yvoje softwaru. Bylo vytvoˇreno podle v´ yrobn´ıho procesu Lean manufactoring, jehoˇz pravidla byla upravena pro potˇreby agiln´ıho programován´ı. Nen´ı pravou metodikou, která by pˇresnˇe popisovala, jak´ ym zp˚ usobem postupovat. Ale jde o souhrn myˇslenek vedouc´ıch k rychlejˇs´ımu v´ yvoji s menˇs´ım mnoˇzstv´ım chyb a ekonomiˇctˇejˇs´ım v´ ysledkem. 3. SCRUM Development (d´ ale jen Scrum) Autoˇri - Ken Schwaber a Mike Beedle Metodiku nejlépe charakterizuje vysoká flexibilita t´ ymu a snaha o dokonalou spolupráci. Zásadn´ı prvek Scrum jsou denn´ı sch˚ uzky t´ ymu, které umoˇzn ˇuj´ı nejen dobˇre projednat vˇse


14

d˚ uleˇzité ohlednˇe projektu, ale také pom´ ahaj´ı celkovému zkvalitˇ nován´ı t´ ymu. Usnadˇ nuj´ı napˇr´ıklad ˇs´ıˇren´ı vˇedomost´ı a budov´ an´ı sociáln´ıch vztah˚ u mezi ˇcleny. 4. Feature Driven Development (d´ ale jen FDD) Autory metodiky jsou projektov´ y manaˇzer Jeff De Luca a znám´ y odborn´ık na v´ yvoj softwaru Peter Coad. Ten se zamˇeˇril pˇredevˇs´ım na objektovˇe orientované koncepce. Podle FDD je v´ yvoj softwaru ˇr´ızen poˇzadovan´ ymi vlastnostmi v´ ysledného produktu, které slouˇz´ı jako z´ akladn´ı stavebn´ı sloˇzky. Tˇemi se rozum´ı vˇsechny konkrétn´ı funkcionality, d˚ uleˇzité ˇc´ asti nebo charakteristiky systému. Vlastnosti jako by odkrokovaly celou ˇcinnost. 5. Test Driven Ddevelopment (d´ ale jen TDD) TDD je technika, jej´ıˇz vedlejˇs´ı efekt je dokonalé provˇeˇren´ı zdrojového kódu jednotkov´ ymi testy. Vycház´ı z jednoduchého faktu, ˇze ˇc´ım dˇr´ıv se zaˇcne s testován´ım, t´ım dˇr´ıve se odhal´ı chyby a t´ım levnˇejˇs´ı jsou jejich opravy [ 20 ]. Proto TDD poˇzaduje formulovat jednotkové testy v nejranˇejˇs´ı f´ azi v´ yvoje - pˇred zhotoven´ım funkc´ı. Ze stejného d˚ uvodu se maj´ı formulovat i akceptaˇcn´ı, vyˇsetˇrovac´ı testy (acceptance tests, investigative tests) a testy uˇzivatelského rozhran´ı co nejdˇr´ıve, ne aˇz po dokonˇcen´ı projektu.

3.3

Extr´ emn´ı programov´ an´ı

Metodika XP je jedn´ım z nejd˚ uleˇzitˇejˇs´ıch zástupc˚ u agiln´ıho v´ yvoje, jehoˇz pˇrednosti splˇ nuje vˇsechny. Je vhodná pro malé projekty a malé t´ ymy o dvou aˇz deseti lidech. Nejvˇetˇs´ı d˚ uraz dává na u ´ˇcinnost procesu, jeˇz se snaˇz´ı dos´ ahnout velmi racion´ aln´ı postupy. U kaˇzdé ˇcinnosti mus´ı b´ yt na prvn´ı pohled zˇrejm´ a jej´ı d˚ uleˇzitost. Produktivitu také viditelnˇe zvyˇsuje pˇredepsan´ a snaha vytvoˇrit takové prostˇred´ı, aby pr´ ace byla z´ abavn´ a. Autor se inspiroval ne´ uspˇeˇsn´ ym projektem Chrysler Comprehensive Compensation (C3) [ 6 ]. To byla pro nˇej v´ yzva vybudovat metodiku, která by byla flexibilnˇejˇs´ı a umoˇzn ˇovala lépe reagovat na pr˚ ubˇeˇzné zmˇeny.

3.3.1

Charakteristika

Metodika pˇrevzala nˇekteré myˇslenky z v´ yroby ve firmˇe Toyota [ 5 ]. Ty hovoˇr´ı o tom, ˇze kaˇzd´ y pracovn´ık je odpovˇedn´ y za celou v´ yrobn´ı linku, vylepˇsov´ an´ı vycház´ı ze sniˇzován´ı pl´ ytván´ı a nejvˇetˇs´ım pl´ ytván´ım je nadprodukce. Té je v´ yvoj softwaru pln´ y a také proto XP poˇzaduje jednoduchost a upˇrednostˇ nuje ji pˇred nevyuˇzitelnou robustnost´ı produktu. Návrh a implementace jsou sepjaté a nikdy se nenavrhuje nic, co nen´ı momentálnˇe potˇreba. Nikdy se nem´ a tvoˇrit v´ıce verz´ı k´ odu ani v pˇr´ıpadˇe, ˇze nen´ı jisté, která verze by byla správn´ a. V takové situaci se m´ a

´ Í PROGRAMOVAN ´ Í 3.3. EXTREMN

15

nejdˇr´ıve vyˇreˇsit nejz´ akladnˇejˇs´ı problém a implementovat funkcionalitu správn´ ym zp˚ usobem. I zde kaˇzd´ y pracovn´ık odpov´ıd´ a za cel´ y v´ yvoj, t´ ym m´ a b´ yt ucelen´ y a jednolit´ y. XP d´ avá pˇrednost pˇr´ımé komunikaci o zdrojovém textu pˇred p´ısemnou komunikac´ı, formalitami a dokumenty. Ty maj´ı jen nezbytnˇe malou d˚ uleˇzitost.

3.3.2

Z´ akladn´ı principy

XP vycház´ı ze znám´ ych zkuˇsenost´ı s t´ım, co pom´ ah´ a pˇri obecné lidské ˇcinnosti. Pouˇzit´ı myˇslenek tˇechto zkuˇsenost´ı dotahuje do extrém˚ u. 3.3.2.1

Pˇ r´ıklady zn´ am´ ych myˇ slenek a postup˚ u

• Jednoduchost projektu pom´ ahá snadné orientaci v kódu a udrˇzen´ı v´ yvoje v rychlém tempu. Proto se podle metodiky m´ a vytvoˇrit tak jednoduch´ y produkt, kter´ y jeˇstˇe funguje a splˇ nuje aktu´ aln´ı poˇzadavky na systém. Je nev´ yhodné budovat sloˇzité aplikace s c´ılem usnadnit hypotetick´ a budouc´ı rozˇs´ıˇren´ı. XP pˇresvˇedˇcuje o tom, ˇze stoj´ı nejménˇe pr´ ace udrˇzovat systém v minim´ aln´ı konfiguraci a pˇrebudovat ho aˇz v pˇr´ıpadˇe, kdy je potˇrebn´ a u ´prava, tˇrebaˇze v danou chv´ıli jiˇz znaˇcnˇe rozs´ ahl´ a. • N´ avrh a architektura systému maj´ı z´ asadn´ı vliv na pr˚ ubˇeh v´ yvoje. Vyuˇz´ıvá se toho, ˇze se aplikace implementuje t´ım lépe, ˇc´ım lépe je navrˇzena. Návrh se tedy vylepˇsuje dennˇe refaktorizac´ı, avˇsak v souladu s charakterem agiln´ıch metodik. • Testov´ an´ı funkcionality odhal´ı nejv´ıce chyb, proto budou pr˚ ubˇeˇznˇe a neust´ ale testovat vˇsichni vˇcetnˇe z´ akazn´ık˚ u. • Revize a kontroly odstran´ı nejvˇetˇs´ı mnoˇzstv´ı chyb v projektu. Z toho d˚ uvodu XP rad´ı nepˇretrˇzitˇe kontrolovat a procházet zdrojov´ y text a pˇredkl´ adá metodu tzv. párového programov´ an´ı. • Nepˇretrˇzit´ a integrace a testov´ an´ı má prob´ıhat nˇekolikr´ at dennˇe. • Iterace maj´ı b´ yt tak kr´ atké, jak to odpov´ıdá nejmenˇs´ım moˇzn´ ym a pouˇziteln´ ym ˇcástem systému. Dalˇs´ı poznatky, které XP vyuˇz´ıv´ a, jsou následuj´ıc´ı: Je v´ yhodnˇejˇs´ı vyuˇz´ıt problémy jako pˇr´ıleˇzitost nˇeco dok´ azat, neˇz se snaˇzit je obcházet. Typické je také lidské jedn´ an´ı mezi ˇcleny t´ ymu a vyvaˇzov´ an´ı jejich potˇreb. Také se lidé rádi uˇc´ı a rozv´ıjej´ı. Jako pˇr´ıklad XP uv´ ad´ı, ˇze bˇehem f´ aze pr˚ uzkum programátoˇri z´ısk´ avaj´ı praxi s technologiemi a zákazn´ık s psan´ım zad´ an´ı. Vz´ ajemn´ y prospˇech obecnˇe je jeden z nejd˚ uleˇzitˇejˇs´ıch princip˚ u XP [ 5 ]. Z´ aroveˇ n je zˇrejmˇe nejn´ aroˇcnˇejˇs´ı k dodrˇzov´ an´ı. Jde jak o vzájemné podporován´ı uvnitˇr t´ ymu, vedouc´ı k u ´spˇechu, tak o to


16

d´ at si z´ aleˇzet na spokojenosti zákazn´ıka. Ta by vˇsak nemˇela b´ yt na u ´kor prospˇechu vyv´ıjej´ıc´ı spoleˇcnosti. Efektivitu pr´ ace pozitivnˇe ovlivˇ nuje radost z kvalitn´ıch v´ ysledk˚ u, viditelného postupu a vylepˇsov´ an´ı. S kvalitn´ımi v´ ysledky souvis´ı nutnost pˇripustit i moˇznost ne´ uspˇechu a umˇen´ı k nˇemu pˇristupovat. Jak autoˇri XP ˇr´ıkaj´ı: Kdo dopust´ı u ´spˇech jeho problému, selh´ av´ a. Neselhat je podle mého názoru siln´ a motivace k ˇreˇsen´ı pot´ıˇz´ı. Metodika d´ ale upozorˇ nuje na v´ yznam r˚ uznorodosti kon´ an´ı, nebo vˇedom´ı odpovˇednosti za nˇeco d˚ uleˇzitého. Lépe pracuje ˇclovˇek, kter´ y prov´ ad´ı lákavˇejˇs´ı ˇcinnost, neˇz stán´ı u bˇeˇz´ıc´ıho p´ asu. Nebo také ten, kdo m´ a odpovˇednost a vyˇsˇs´ı sebevˇedom´ı. 3.3.2.2

ˇ ri promˇ Ctyˇ enn´ e charakterizuj´ıc´ı v´ yvoj

Obecnˇe agiln´ı metodiky sice zavád´ı tˇri promˇenné, avˇsak XP pouˇz´ıvá dalˇs´ı ˇctvrtou a také zmˇenˇené n´ azvy pro p˚ uvodn´ı tˇri. Jsou to kvalita (coˇz odpov´ıdá funkcionalitˇe projektu), ˇcas vyhrazen´ y pro v´ yvoj, náklady (obecnˇe zdroje) a ˇs´ıˇre zadán´ı. Posledn´ı z nich je mnoˇzina funkc´ı produktu, strukturovaná podle jejich d˚ uleˇzitosti, a autor ji povaˇzuje za nejd˚ uleˇzitˇejˇs´ı parametr. Ke zmˇenˇe ˇs´ıˇre zad´ an´ı m˚ uˇze doj´ıt pˇri rozhodnut´ı implementovat v´ıce nebo ménˇe funkˇcnost´ı produktu. Zákazn´ık m˚ uˇze volit tˇri parametry a podle nich v´ yvojov´ y t´ ym urˇc´ı ˇctvrt´ y. Snaha zákazn´ıka volit vˇsechny ˇctyˇri parametry vede ke sn´ıˇzen´ı kvality pr´ ace a k nedodrˇzen´ı term´ınu dod´ an´ı. 3.3.2.3

ˇ ri hodnoty Ctyˇ

Patˇr´ı mezi základn´ı pojmy metodiky. Ta je na nich postavena, ˇr´ıd´ı se jimi a vylepˇsuje jimi v´ yvojov´ y proces [ 4 ]. Mezi ˇctyˇri nejv´ıce uzn´ avané hodnoty XP patˇr´ı komunikace, jednoduchost, zpˇetná vazba, odvaha a sebevˇedom´ı. Je definována jeˇstˇe pát´ a podprahová hodnota - respekt. Dobr´ a komunikace umoˇzn ˇuje odstraˇ novat chyby a pˇrekáˇzky s nejmenˇs´ım moˇzn´ ym zpoˇzdˇen´ım. Nejvˇetˇs´ı objem dorozum´ıv´ an´ı by mˇel b´ yt u ´stn´ı osobn´ı. Proto by cel´ y t´ ym mˇel pracovat v jedné m´ıstnosti. Je vylouˇcené jakékoliv zatajov´ an´ı nedostatk˚ u nebo problém˚ u. Jednoduchost je ekonomiˇctˇejˇs´ı neˇz v´ yvoj nevyuˇzitelnˇe robustn´ıch aplikac´ı, které jdou snadno rozˇs´ıˇrit. Vˇzdy se m´ a zaˇc´ıt co nejjednoduˇsˇs´ım systémem, kter´ y se zdokonal´ı, aˇz kdyˇz pˇrijde ˇcas. T´ım se pˇredejde vytváˇren´ı nˇeˇceho, co nebude nakonec potˇreba. Zpˇetná vazba je ukazatel a prostˇredek hodnot´ıc´ı, v jakém je systém stavu a jestli produkt odpov´ıd´ a klientov´ ym potˇreb´ am. Prov´ ad´ı se zejména testován´ım, které se podle XP má maximalizovat. Testov´ an´ım proch´ az´ı jak malé moduly, tak vˇetˇs´ı ˇcásti - subsystémy apod. a je do nˇej zapojen i z´ akazn´ık. Odvaha a sebevˇedom´ı jsou obzvl´ aˇst’ d˚ uleˇzité v XP. T´ ym se nesm´ı b´ at okamˇzitˇe odstraˇ novat chyby a provádˇet nutné zmˇeny, a to za kaˇzdou cenu. XP upozorˇ nuje, ˇze cenou m˚ uˇze b´ yt i nepouˇzitelnost dvou tˇretin vˇseho hotového k´ odu. ˇ Pát´ a podprahová hodnota - respektov´ an´ı osob okolo sebe. Clenov´ e t´ ymu mus´ı spolupracovat,


17

Obr´ azek 3.2: Moˇzn´ a podoba karty zad´ an´ı pouˇz´ıvané v XP. Jej´ı obsah stanovuje z´ akazn´ık.; pˇrekresleno podle 9

zaj´ımat se jeden o druhého, a ne vˇenovat se v´ yhradnˇe své práci, aby metodika byla funkˇcn´ı.

3.3.3

Z´ akladn´ı metody XP

Jde o postupy, které je nutné do v´ yvoje zaˇradit vˇsechny. Je vidˇet, ˇze pˇrijmout vˇsech dvan´ act pravidel jde jen v extrémn´ım pˇr´ıpadˇe, kdy je t´ ym skuteˇcnˇe schopn´ y a ukáznˇen´ y. Nedodrˇzen´ı nˇekteré z praktik je v rozporu s XP. Business praktiky 1. Plánovac´ı hra - Cel´ y t´ ym vytváˇr´ı tzv. karty zadán´ı, které nesou z´ akladn´ı informace o poˇzadovan´ ych funkcionalit´ ach obr. 3.2. 2. Vyd´ av´ an´ı mal´ ych verz´ı - Verze se maj´ı vydávat v konfigurac´ıch co nejmenˇs´ıch, které jako ˇ ım ˇcastˇejˇs´ı je vydáván´ı, t´ım lepˇs´ı je celek ale jeˇstˇe maj´ı viditeln´ y v´ yznam pro zákazn´ıka. C´ zpˇetná vazba. Také na z´ akazn´ıka dobˇre p˚ usob´ı zˇretelnˇejˇs´ı produktivita t´ ymu. 3. Metafora - Obrazn´ y n´ azev pro architekturu pom´ ahá u ´ˇcastn´ık˚ um sjednotit pohledy na systém, tak aby mu rozumˇeli vˇsichni. Pˇr´ıklad metafory je tabulka, která m˚ uˇze b´ yt ve skuteˇcnosti realizov´ ana jako tabulka, nebo zcela jinak. 4. Z´ akazn´ık na pracoviˇsti - Zákazn´ık je souˇcást´ı t´ ymu na pln´ yu ´vazek a je osobnˇe pˇr´ıtomen. Mus´ı vˇedˇet, ˇze aplikace d´ıky nˇemu funguje o to dˇr´ıve a lépe. Pokud klient odm´ıt´ a vstoupit do procesu na pln´ y u ´vazek, protoˇze je pro nˇej cennˇejˇs´ı jeho práce a ˇcas neˇz uˇzitek ze systému, je lepˇs´ı se do v´ yvoje nepouˇstˇet.


18 Programovac´ı praktiky

5. Jednoduch´ y n´ avrh - Veˇskeré inovace se provád´ı, aˇz kdyˇz jsou potˇreba. Co je pˇr´ıliˇs sloˇzité, ihned se odstran´ı. 6. Testován´ı - XP definuje f´ azi pl´ anován´ı, ale ne n´ avrh. To znamen´ a, ˇze návrh prob´ıhá, ale ne ve zvl´ aˇstn´ı f´ azi. Vych´ az´ı ˇcistˇe ze psan´ı zdrojového kódu. Testov´ an´ı je tedy t´ım d˚ uleˇzitˇejˇs´ı. 7. Refaktorizace k´ odu - Pˇrestrukturov´ an´ı k´ odu beze zmˇen jeho chován´ı je d˚ uleˇzité pro jednoduchost a pˇrehlednost kódu. Je nutné rozliˇsovat dobu refaktorizace a implementace. Refaktorizace se nejˇcastˇeji t´ yk´ a zvyˇsov´ an´ı soudrˇznosti k´ odu odstraˇ nován´ım duplicit. Jejich odstranˇen´ı je zˇreteln´ y znak jednoduchosti. 8. Neust´ al´ a integrace - Projekt se integruje nˇekolikr´ at dennˇe po kaˇzdém splnˇen´ı urˇcitého u ´kolu. Hlavnˇe v rozs´ ahl´ ych projektech se vyplat´ı testovat integraci nˇekolikr´ at dennˇe. T´ ymové praktiky 9. P´ arové programov´ an´ı - U jednoho poˇc´ıtaˇce vˇzdy pracuj´ı dva programátoˇri. Jeden z nich se snaˇz´ı o co nejlepˇs´ı implementaci na aktu´ aln´ım m´ıstˇe. Druh´ y pˇrem´ yˇsl´ı o tom, jak dan´ y kus k´ odu zapadá do celkové koncepce systému a jestli z˚ ustane zachovan´ a jeho integrita. Také hled´ a zp˚ usoby, jak produkt zjednoduˇsit. Pr´ ace ve dvou vede ke zkvalitnˇen´ı kódu a k menˇs´ı chybovosti. M˚ uˇze trvat nˇekolik t´ ydn˚ u, neˇz se metoda ukáˇze jako v´ yhodná. 10. Kolektivn´ı vlastnictv´ı k´ odu - XP zav´ ad´ı tzv. truck faktor a rad´ı maximalizovat ho. Tento ukazatel znaˇc´ı, kolik program´ ator˚ u rozum´ı jedné ˇcásti zdrojového textu. Nejvˇetˇs´ıho moˇzného faktoru se má dos´ ahnout t´ım, ˇze vˇsechen kód vlastn´ı vˇsichni a kdokoliv ho m˚ uˇze upravovat. 11. Udrˇzitelné tempo - Pracovn´ıci maj´ı b´ yt rychl´ı a nabit´ı energi´ı, a proto nesmˇej´ı b´ yt pˇretˇeˇzováni. Pracovn´ı t´ yden nemá v´ıc neˇz ˇctyˇricet hodin a nadmˇern´ a práce pˇres ˇcas vede ke zv´ yˇsené chybovosti pracovn´ık˚ u. 12. Standardy k´ odu - Maj´ı existovat v kaˇzdém t´ ymu, nebot’ zdrojov´ y text je z´ akladn´ı a jedin´ a forma uchován´ı informace. Proto mus´ı b´ yt pˇrehledn´ y a srozumiteln´ y vˇsem.

3.3.4

Z´ akladn´ı ˇ cinnosti

ˇ Cinnosti, které prob´ıhaj´ı bˇehem v´ yvoje podle XP, jsou na obr´ azku obr. 3.3. 1. Testován´ı - Kaˇzd´ a funkce a funkcionalita m´ a jednotkov´ y test [ 6]. Ten mus´ı probˇehnout bez chyb pˇred pokraˇcov´ an´ım v dalˇs´ım v´ yvoji. Testy jsou izolované, tedy nemaj´ı vliv na jiné testy. Jsou automatizované, a tak je v´ ysledek vˇzdy nezávisl´ y na okoln´ıch datech. Test modulu se nap´ıˇse dˇr´ıv, neˇz modul zaˇcne vznikat.


19

Obr´ azek 3.3: Vzájemn´ y vztah ˇcinnost´ı v XP; pˇrekresleno podle 9

2. Psan´ı zdrojového k´ odu - Jde o c´ıl a zároveˇ n metodu XP. V dobˇe v´ yvoje neexistuj´ı jiné dokumenty, ze kter´ ych by ˇclovˇek nˇeco vyˇcetl o systému. 3. Poslouchán´ı - V´ yvoj´ aˇri mus´ı m´ıt z´ ajem o své spolupracovn´ıky a aktivnˇe jim naslouchat. Komunikace m´ a m´ıt urˇcitou strukturu. 4. Navrhován´ı, design - Návrh je jedin´ y nástroj, kter´ ym jde zabr´ anit neˇreˇsiteln´ ym situac´ım (efektivn´ım zp˚ usobem). Zmˇena v jedné ˇcásti by nemˇela zp˚ usobit pokaˇzdé nutnost zmˇen ostatn´ıch ˇca´st´ı.

3.3.5

Pr˚ ubˇ eh v´ yvoje jedn´ e verze

XP nedefinuje posloupnost pˇresn´ ych f´ az´ı popisuj´ıc´ıch konkrétn´ı u ´kony. V´ yvoj podle agiln´ıch metodik neprob´ıhá podle pˇresn´ ych postup˚ u, ale jde o dialog mezi jeho moˇzn´ ym a ˇzádouc´ım pˇrizp˚ usoben´ım urˇcitému vod´ıtku. Jsou definov´ any tyto fáze: 1. Pr˚ uzkum Programátoˇri zkouˇs´ı sestavit systém tˇremi aˇz ˇctyˇrmi r˚ uzn´ ymi zp˚ usoby, neˇz naleznou nejvhodnˇejˇs´ı architekturu. Dále sh´ an´ı co nejvˇetˇs´ı mnoˇzstv´ı materiálu pro vytvoˇren´ı karet zadán´ı. 2. Pl´ anov´ an´ı V r´ amci tzv. plánovac´ı hry vznikne pl´ an jedné verze. Pˇred zahájen´ım v´ yvoje se v r´ amci pr˚ uzkumu z minulého bodu vytvoˇr´ı hrub´ y a jednoduch´ y plán. V této chv´ıli je pl´ an pouze pˇribliˇzn´ y a oˇcekávaj´ı se zmˇeny odhad˚ u i priorit. Na základˇe podrobnˇejˇs´ıho pr˚ uzkumu situace se urˇc´ı n´ aplˇ n tvorby verze. Ta trvá typicky jeden aˇz dva dny. Jde o tvorbu mnoˇziny karet zad´ an´ı jako základn´ıho materi´ alu popisuj´ıc´ı poˇzadované funkcionality. Pr˚ ubˇeh pl´ anovac´ı hry (a) Pr˚ uzkum - Najde se nov´ a funkcionalita. Veden´ı ji pop´ıˇse bˇeˇznou ˇreˇc´ı, ˇc´ımˇz vznikne tzv. user story a jedna karta zad´ an´ı. V´ yvoj odhadne n´ aroˇcnost a dobu implementace.


20

(b) Z´ avazek - V´ yvoj se zav´ aˇze k vytvoˇren´ı nové verze za dan´ ych finanˇcn´ıch podm´ınek. Karty zad´ an´ı se seˇrad´ı podle d˚ uleˇzitosti. Veden´ı zvol´ı ˇs´ıˇri zad´ an´ı a datum uvolnˇen´ı verze. ˇ ızen´ı - Pl´ (c) R´ anován´ı iterac´ı a u ´pravy pl´ anu podle pr˚ ubˇehu v´ yvoje. Plánovac´ı hry se u ´ˇcastn´ı cel´ y t´ ym. Obchodn´ıci rozhoduj´ı o ˇs´ıˇri zad´ an´ı, technici rozhoduj´ı o odhadech, o d˚ usledc´ıch volby dan´ ych prvk˚ u a podrobném harmonogramu. 3. Testov´ an´ı Testov´ an´ı se stav´ı na dvou z´ akladn´ıch principech. Za prvé prob´ıhá dvoj´ı kontrola - automatické testy a procházen´ı k´ odu. Druh´ y princip ˇr´ıká, ˇze oprava chyby je t´ım levnˇejˇs´ı, ˇc´ım dˇr´ıv se chyba odhal´ı. 4. Konstrukce, design Inkrement´ alnˇe po iterac´ıch se navrhuje a konstruuje systém. Postup mus´ı b´ yt vhodn´ y pro v´ yvojov´ y t´ ym. Zaˇcne se iteraˇcn´ı plánovac´ı hrou, coˇz je u ´kon podobn´ y plánovac´ı hˇre pro celou verzi aplikace. Z´ akazn´ık vybere karty zad´ an´ı, které maj´ı urˇcit ˇcinnost pro jednu iteraci. Jejich poˇcet záleˇz´ı na tempu v´ yvoje a urˇc´ı se jako poˇcet splnˇen´ ych karet v pˇredchoz´ı iteraci. Vytváˇr´ı se u ´kolové karty, které jsou podrobnˇejˇs´ı neˇz karty zad´ an´ı. Nikdy se nepl´ anuje déle dopˇredu neˇz na dobu bezprostˇredn´ı implementace. Osobn´ı komunikace je nezbytná. Konstrukce a design nejsou jednor´ azovou záleˇzitost´ı, je nutné povaˇzovat v´ yvoj za neust´ al´ y proces. Pˇri nˇem je udrˇzov´ ana integrita systému a jej´ı nezachov´ an´ı zvyˇsuje chybovost pˇri programován´ı. T´ ym mus´ı b´ yt na udrˇzov´ an´ı celistvosti zvykl´ y. Jinak se prodluˇzuj´ı intervaly odevzd´ av´ an´ı nov´ ych funkcionalit. 5. Dekompozice Podle velikosti t´ ymu se problém rozdˇel´ı na menˇs´ı a aplikuj´ı se jednoduch´ a ˇreˇsen´ı. Pokud z˚ ustane sloˇzit´ y nerozloˇziteln´ y problém, aplikuje se komplexn´ı ˇreˇsen´ı.

3.3.6

V´ yvoj prvn´ı verze

1. Pl´ anov´ an´ı 2. Zprovozˇ nov´ an´ı Kaˇzd´ a iterace trv´ a jeden aˇz ˇctyˇri t´ ydny, dokud nen´ı vytvoˇrena základn´ı architektura systému neboli jeho kostra. Poté se interval mezi jednotliv´ ymi iteracemi zkr´ at´ı zhruba na tˇretinu. T´ım se doc´ıl´ı z´ısk´ an´ı lepˇs´ı zpˇetné vazby a reakce na zmˇeny poˇzadavk˚ u. U kaˇzdé zmˇeny je nutné zv´ aˇzit, jestli je aktu´ aln´ı, ˇci jestli ji staˇc´ı zapracovat aˇz v dalˇs´ı verzi. Zde je také prostor na vylad’ován´ı a optimalizaci projektu. ´ zba spoˇc´ıv´ 3. Udrˇ a v zav´ adˇen´ı nov´ ych funkc´ı a zaˇcleˇ nován´ı nov´ ych osob do projektu. Také mus´ı b´ yt nab´ızena technick´ a podpora vˇsem uˇzivatel˚ um.


21

4. Smrt nast´ avá v situaci, kdy z´ akazn´ıka nenapadaj´ı nová zad´ an´ı, která by chtˇel nechat vydat. Pˇr´ıpadnˇe systém ztrat´ı moˇznost existovat za rozumn´ ych finanˇcn´ıch podm´ınek. F´ aze smrt je prvn´ı chv´ıle za celou dobu, kdy má smysl napsat pˇeti aˇz desetistr´ ankov´ y dokument s popisem systému. Ten se v té dobˇe uˇz nemˇen´ı a dokumentace se m˚ uˇze sepsat bez obav o jej´ı pouˇzitelnost v budoucnosti.

3.3.7

T´ ymov´ e role

XP je agiln´ı metodika nejv´ıce zamˇeˇren´ a na pr´ aci s lidmi a na jak´ ykoliv lidsk´ y faktor. Motivace lid´ı je podpoˇrena také t´ ymov´ ymi oslavami v pr˚ ubˇehu v´ yvoje - napˇr´ıklad po kaˇzdé iteraci nebo po ukonˇcen´ı pr´ ace na projektu. C´ılem tˇechto oslav je kladné vzájemné hodnocen´ı ˇclen˚ u t´ ymu a z´ abavnˇejˇs´ı a uvolnˇenˇejˇs´ı v´ yvojov´ y proces. • Programátor - má u ´stˇredn´ı roli. Vytv´ aˇr´ı zdrojov´ y text, design, refaktoruje a testuje jednotky. Mus´ı dobˇre komunikovat s ostatn´ımi ˇcleny a pˇrijmout párové programov´ an´ı. • Z´ akazn´ık - je ten, kdo v´ı, co se m´ a programovat, i kdyˇz nev´ı jak. Má naplno vyuˇz´ıt moˇznost ovlivˇ novat projekt. Mus´ı pˇrijmout pravidla XP a spoluodpovˇednost za projekt. Jeho povinnost´ı je ps´ at zad´ an´ı a testy funkcionality. • Tester - pom´ ah´ a z´ akazn´ıkovi se psan´ım test˚ u funkcionality. • Stopaˇr - má nadhled nad systémem. Odhaduje term´ıny, zpracov´ avá informace ze zpˇetné vazby a analyzuje zpoˇzdˇen´ı projekt˚ u. • Kouˇc - odpov´ıd´ a za proces jako celek. Star´ a se o otevˇrenost komunikace a hl´ıdá správnost postup˚ u. • Konzultant - je expert v konkrétn´ı oblasti, která t´ ymu nen´ı znám´ a. • Velk´ y ˇséf - vede organizaci. Mus´ı m´ıt odvahu, trpˇelivost, rozvahu a t´ım i schopnost pˇrijmout principy XP, vˇcetnˇe zd´ anlivˇe nesmysln´ ych krok˚ u. Tˇemi m˚ uˇzou b´ yt napˇr´ıklad p´ arové programov´ an´ı, refaktorizace, zahozen´ı nepouˇzitelného kódu.

3.3.8

Z´ avˇ er

XP je flexibiln´ı metodika, která si klade za c´ıle harmonii a vyv´ aˇzen´ı. Boˇr´ı konzervativn´ı pˇredstavy o d˚ uleˇzitosti dokumentace a podrobného pl´ anován´ı. Vych´ az´ı z toho, co je pˇrirozené a co lidé maj´ı r´ adi, coˇz je napˇr´ıklad v´ yhra, t´ ymov´ a spolupráce, d˚ uvˇera, bl´ızk´ y viditeln´ y c´ıl, funguj´ıc´ı software. Pro metodiku existuje ˇrada zdroj˚ u informac´ı a n´ astroj˚ u ve v´ yvojov´ ych prostˇred´ıch. ˇ ıká se o n´ı napˇr´ıklad v [ 4 ], ˇze je jednou z nejrozˇs´ıˇrenˇejˇs´ıch a nejzn´ R´ amˇejˇs´ıch. Jsem pˇresvˇedˇcen o


22

ˇ e republiky jsou ˇcastˇejˇs´ı jiné tom, ˇze toto plat´ı v Americe, avˇsak ovˇeˇril jsem si, ˇze na u ´zem´ı Cesk´ agiln´ı metodiky. Evropané nem´ıvaj´ı na rozd´ıl od Ameriˇcan˚ u tak v´ yhodné povahové vlastnosti (napˇr´ıklad velkou odvahu), které jsou uˇziteˇcné pro XP. Také jsou lidé zvykl´ı pracovat sp´ıˇse samostatnˇe, ale v XP mus´ı spolupracovat.

3.4

Lean software development

Pˇr´ınos Lean development nespoˇc´ıv´ a v popisu pr˚ ubˇehu v´ yvoje software, ale rad´ı, jak´ ym zp˚ usobem zefektivnit pr´ aci. Jako c´ıle si klade na prvn´ı pohled n´ aroˇcné poˇzadavky. Ty jsou produkovat software za tˇretinu obvyklého ˇcasu, vystaˇcit se tˇretinou obvyklého rozpoˇctu a sn´ıˇzit ˇcetnost chyb na tˇretinu obvyklého mnoˇzstv´ı [ 9 str. 159 ]. C´ıle nejsou absurdn´ı. Jak se m˚ uˇzeme doˇc´ıst dále, z´ akladn´ı principy Lean development naopak vysvˇetluj´ı, ˇze ˇcasté doruˇcov´ an´ı prototyp˚ u, vysok´ a kvalita a n´ızk´ a cena jsou plnˇe v souladu. Nejsou stanoveny ˇzádné kroky, jejichˇz pomoc´ı se c´ıl˚ u jistˇe dosáhne. Lean development pouze vymezuje pravidla, která umoˇzn´ı proces zefektivnit.

3.4.1

Z´ akladn´ı charakteristika

Lean development navazuje na Lean manufactoring. To vycház´ı ze snahy zabr´ anit problém˚ um, na které narazili japonˇst´ı v´ yrobci automobil˚ u pˇri ˇr´ızen´ı produkce. Avˇsak tyto komplikace byly stejného charakteru, jako pot´ıˇze pˇri v´ yvoji softwaru - mˇen´ıc´ıch se poˇzadavk˚ u, efektivity a pruˇznosti v´ yroby. Hlavn´ı automobilov´ y producent, kter´ y rozv´ıjel Lean Manufacturing, je Toyota. Jeho v´ yznamnˇe ovlivnil Dr. W. Edwards Deming uˇcen´ım s názvem Absolutnˇe kvalitn´ı management a ˇctrn´ acti body t´ ykaj´ıc´ımi se managementu. Lean Manufactoring dobˇre definuje pojmy kl´ıˇcové pro efektivn´ı ˇcinnost. Ta spoˇc´ıvá v dovedném zach´ azen´ı s pojmem hodnota a v zamezen´ı pl´ ytván´ı. Kromˇe toho, ˇze metodiku formovali, také ji prosadili v Agiln´ı alianci Tom a Mary Poppendieck.

3.4.2 3.4.2.1

Kl´ıˇ cov´ e pojmy Pl´ ytv´ an´ı

Jedno z nejd˚ uleˇzitˇejˇs´ıch pravidel je odstranˇen´ı pl´ ytván´ı. Autorka FDD ho definuje v [ 8 str. 3] sedm druh˚ u. Pˇritom vycház´ı ze sedmi základn´ıch zp˚ usob˚ u pl´ ytván´ı v pr˚ umyslové v´ yrobˇe. Pˇri produkci softwaru se objevuj´ı tato: • Nadv´ yroba je zhotovov´ an´ı vlastnost´ı, které zákazn´ık nepoˇzadoval. Nepˇridaj´ı ˇzádnou hodnotu produktu, protoˇze ten m˚ uˇze stejnˇe fungovat i bez nich. Nadv´ yroba je kaˇzdá

3.4. LEAN SOFTWARE DEVELOPMENT

23

aktivita, kterou je moˇzno pˇri cestˇe k v´ ysledku pˇreskoˇcit. Kaˇzd´ y kus kódu, kter´ y nakonec nejde pouˇz´ıt. Nadv´ yrobu je moˇzné omezit konkrétn´ım opatˇren´ım, kter´ ym se daj´ı odstranit vˇsechny nadbyteˇcné ˇcinnosti. Takov´ ym opatˇren´ım m˚ uˇze b´ yt napˇr´ıklad revize prov´ adˇená nadˇr´ızen´ ym. • Nevyuˇ zit´ı pˇ r´ıleˇ zitost´ı se uˇ cit Vyplat´ı se pˇri v´ yvoji vˇenovat nezbytn´ y ˇcas zpracov´ an´ı zkuˇsenost´ı, které lze pˇri projektu z´ıskat. • Ztr´ ata ˇ casu ˇ cek´ an´ım na dokonˇcen´ı nˇejaké funkˇcnosti Pracovn´ıci maj´ı b´ yt pˇridˇelov´ ani na jednotlivé u ´koly vhodnˇe, pokud moˇzno dynamicky. Jako pˇr´ıklad uvád´ım testery, kteˇr´ı vˇzdy mus´ı naj´ıt jinou pr´ aci, pokud moment´ alnˇe nemaj´ı pˇr´ıstup k pˇridˇelené funkˇcnosti. • Ztr´ ata ˇ casu pˇ ri transportu je zbyteˇcné ˇcekán´ı pˇri stahov´ an´ı dat, hledán´ı informac´ı. Pr´ ace m´ a b´ yt vhodnˇe rozdˇelena. Pokud je to moˇzné, procesy se maj´ı automatizovat. • Pl´ ytv´ an´ı souvisej´ıc´ı se zpracov´ an´ım jsou vˇsechny nadbyteˇcné aktivity bˇehem v´ yvoje. Veden´ı t´ ymu má m´ıt pˇrehled o ˇcinnosti vˇsech. Je d˚ uleˇzité odhalit chyby pˇred jejich implementac´ı. • Neefektivn´ı pr´ ace m˚ uˇze m´ıt v´ıce pˇr´ıˇcin. Jde o zbyteˇcné ”pˇrep´ınán´ı”mezi u ´koly nebo vracen´ı se k p˚ uvodn´ım návrh˚ um. Dále sem patˇr´ı technické nedostatky a nevyuˇzit´ı automatick´ ych n´ astroj˚ u. To zp˚ usobuje sniˇzován´ı v´ ysledné hodnoty produktu a zvyˇsov´ an´ı spotˇreby zdroj˚ u. Programátoˇri maj´ı ohl´ıdat, aby pouˇzili vˇsechny dostupné nástroje. Veden´ı mus´ı zajistit, aby se program´ atoˇri o nástroj´ıch dozvˇedˇeli. • Pl´ ytv´ an´ı spojen´ e s chybami v programu Je potˇreba vyuˇz´ıt mechanismy pro hled´ an´ı a odstraˇ nov´ an´ı chyb.

3.4.2.2

Hodnota

Zásadn´ı mˇeˇr´ıtko je hodnota v´ ysledného produktu, kter´ y si nˇekdo chce koupit. Proto metodika rad´ı zab´ yvat se v´ yhradnˇe t´ım, co zvyˇsuje jeho hodnotu. Kaˇzd´ y model, návrh, dokument, komponenta nebo jak´ ykoliv jin´ y meziprodukt m´ a hodnotu, pokud umoˇzn´ı zlevnit dokonˇcen´ı v´ ysledného produktu. Hodnota m´ a nˇekolik podob. Jednou z nich jsou zdroje, coˇz je ˇcas pracovn´ık˚ u a také pˇredpˇripravené komponenty. Dále to jsou nástroje pouˇz´ıvané pˇri v´ yrobˇe a dovednosti, které t´ ym z´ısk´ avá bˇehem pr´ ace.


24

3.4.3

Kl´ıˇ cov´ a pravidla

Autoˇri Lean development pˇrevzali od Lean manufacturing pravidla, kter´ a vyloˇzili zp˚ usobem odpov´ıdaj´ıc´ım v´ yvoji softwaru. 1. Odstranit vˇ se, co je zbyteˇ cn´ e Vˇsechny zbyteˇcné produkty a meziprodukty sniˇzuj´ı efektivitu a zvyˇsuj´ı náklady, proto je nutné odstranit vˇsechny zbyteˇcné dokumenty a funkcionality. To se m´ a provádˇet vˇedom´ ym rozhodován´ım o tom, co nepˇrinese nic v´ yslednému produktu ˇci zákazn´ıkovi, a co je naopak nezbytné. Pokud nedokáˇzeme ˇr´ıct, jestli se bez artefaktu obejdeme nebo ne, m˚ uˇzeme ho prohl´ asit za zbyteˇcn´ y. Kl´ıˇcové je zamˇeˇrit se na z´ akazn´ıka. Kaˇzd´ y program´ ator o nˇem mus´ı vˇedˇet, kdo to je a co je pro nˇej skuteˇcnˇe hodnotné [ 7 ]. Pro efektivn´ı hledán´ı zbyteˇcn´ ych ˇcinnost´ı Lean manufacturing pouˇz´ıv´ a princip, kter´ y se dá snadno aplikovat v softwarovém inˇzen´ yrstv´ı. Zkoum´ a se kaˇzdá aktivita a hodnota, kterou aktivita pˇridáv´ a v´ ysledku. Poté se zkouˇs´ı naj´ıt efektivnˇejˇs´ı zp˚ usob, jak této hodnoty dos´ ahnout. V pˇr´ıpadˇe softwarového v´ yvoje jde o omezen´ı dokument˚ u, jejichˇz pouˇz´ıván´ı nen´ı zcela u ´ˇcinné. 2. Minimalizovat z´ asoby a meziprodukty Pl´ ytvat se nesm´ı ani na meziproduktech, u kter´ ych je zˇrejm´ y jejich v´ yznam pro lepˇs´ı dosaˇzen´ı v´ ysledku. Kaˇzd´ y potˇrebuje specifikaci, ze které se dozv´ı, jak m´ a aplikace fungovat. Ovˇsem je nutné zachovat nezbytnou délku dokument˚ u a t´ım pˇredej´ıt pl´ ytván´ı. Neefektivn´ı meziprodukty spotˇrebov´ avaj´ı pˇr´ıliˇs mnoho zdroj˚ u nejen jejich vytváˇren´ım, ale také schvalov´ an´ım, prohl´ıˇzen´ım a aktualizac´ı. Nejlepˇs´ı zp˚ usob jak minimalizovat, zkr´ atit d˚ uleˇzité produkty je zv´ yˇsen´ı jejich m´ıry abstrakce. Nˇekteré dlouhé v´ yˇcty popisuj´ı totéˇz, co se d´ a vyjádˇrit nˇekolika pravidly s dokumentac´ı v´ yjimek nebo jedn´ım schématem. Nejvˇetˇs´ı pl´ ytván´ı zp˚ usobuje dokumentace, kter´ a je chybn´ a nebo nesplˇ nuje zcela poˇzadavky uˇzivatele. 3. Maximalizovat tok Maximalizovat to znamen´ a vylouˇcit ˇcekán´ı pracovn´ık˚ u na dokonˇcen´ı fáz´ı procesu, které pˇredch´ azej´ı jejich ˇcinnostem. T´ım se má zkr´ atit ˇcas pro v´ yvoj oproti postup˚ um podle tradiˇcn´ıch metodik obr. 3.4. Lean development proto doporuˇcuje jako z´ asadn´ı paradigma iterativn´ı v´ yvoj, kter´ y umoˇzn ˇuje práci vhodnˇe rozdˇelovat. V´ yvoj jde zrychlit také bránˇen´ım pˇr´ıliˇsné kumulaci pr´ ace prov´ adˇené v jednom okamˇziku. T´ım se zkr´ at´ı doba iterac´ı. ˇ ıdit se popt´ 4. R´ avkou a prov´ adˇ et kl´ıˇ cov´ a rozhodnut´ı tak pozdˇ e, jak je to jen moˇ zn´ e


25

Obr´ azek 3.4: Postup pˇri v´ yvoji podle tradiˇcn´ıch metodik; pˇrekresleno podle 9

Má se odloˇzit kaˇzd´ y z´ avˇer, na kterém moment´ alnˇe nen´ı z´ avisl´ y dalˇs´ı postup. Zároveˇ n nen´ı moˇzné usn´ aˇset se na nˇeˇcem v dobˇe, kdy uˇz je pozdˇe. Metodika pˇresvˇedˇcuje o tom, ˇze u ´spˇeˇsn´ y nen´ı ten, kdo pˇredpov´ıdá zmˇeny. Vhodnˇejˇs´ı je upravit systém v´ yvoje tak, aby mˇel co nejkratˇs´ı odezvu na nov´ a pˇrán´ı klienta. Manaˇzer stav´ı svá rozhodnut´ı z´ aroveˇ n na sv´ ych zkuˇsenostech a na v´ ypovˇed´ıch zákazn´ıka. Nicménˇe pro zákazn´ıka je obt´ıˇzné urˇcit vyˇcerpávaj´ıc´ım zp˚ usobem i jeho souˇcasné poˇzadavky. Tedy nem´ a v´ yznam zab´ yvat se jeho budouc´ımi potˇrebami ani vyslovovat dalekos´ ahlé závˇery. Toto pravidlo pom´ ahá lépe a pruˇznˇeji reagovat na nové poˇzadavky a provádˇet v´ yhradnˇe ty kroky, které jsou nezbytné. ˇ adn´ Z´ a akce se nem´ a provádˇet dˇr´ıv, neˇz je vyˇzadov´ ano [ 8 str. 7 ]. 5. Rozhodnut´ı delegovat pracovn´ık˚ um na u ´ rovn´ıch co nejniˇ zˇ s´ıch Jsou rozhodnut´ı, která m˚ uˇze vykonat manaˇzer stejnˇe dobˇre jako program´ ator. Toho vˇsak dobˇre motivuje ke kvalitn´ı práci, pokud m´ a nˇejaké pravomoci, pocit urˇcité zodpovˇednosti a nejen povinnost vykonávat pˇr´ıkazy. Proto se hod´ı dát vˇsem pracovn´ık˚ um nˇejakou pravomoc. Kaˇzd´ y ˇclen v´ yvojového t´ ymu mus´ı vˇedˇet, kam spoleˇcnost smˇeˇruje, ˇceho chce dos´ ahnout a jak s´ am pom´ ahá dosaˇzen´ı c´ıle. Pak je snazˇs´ı mu sdˇelit, co je jeho d´ılˇc´ım c´ılem, a nechat ho nalézt ˇreˇsen´ı. Dokumenty se pak stávaj´ı struˇcnˇejˇs´ı, pruˇznˇejˇs´ı a zv´ yˇs´ı se m´ıra jejich abstrakce. Opaˇcn´ y zp˚ usob zadáván´ı práce je detailn´ı popis toho, co maj´ı programátoˇri udˇelat, aby spoleˇcnost dosáhla c´ıle, aniˇz by ho znali. D˚ uleˇzité je motivovat pracovn´ıky také ke snaze o efektivitu a smysluplnost jejich pr´ ace. Za tohoto pˇredpokladu nen´ı nutné se obávat udˇelit nˇekomu podˇr´ızenému nˇejakou pravomoc. Je pak menˇs´ı pravdˇepodobnost, ˇze se uch´ yl´ı k anarchii nebo nerozumn´ ym ˇcinnostem. 6. Jako hlavn´ı c´ıl stanovit uspokojen´ı z´ akazn´ıka To plat´ı nejen pro vyhovˇen´ı moment´ aln´ım pˇrán´ım, ale i budouc´ım. Metodika vyb´ız´ı softwarovou spoleˇcnost, aby uvaˇzovala stylem v´ yhra - v´ yhra. M´ a dát pˇrednost partnerstv´ı se


26

z´ akazn´ıkem pˇred nucen´ım ho definitivnˇe podepsat specifikaci poˇzadavk˚ u pˇred zahájen´ım pr´ ace. S postupn´ ym a mˇen´ıc´ım se z´ıskáván´ım poˇzadavk˚ u t´ ym mus´ı poˇc´ıtat. Systém proto mus´ı umoˇzn ˇovat hladké reakce na zmˇeny bˇehem ˇzivotn´ıho cyklu. Kl´ıˇcov´ y a samozˇrejm´ y je zde iterativn´ı v´ yvoj. 7. Zav´ est zpˇ etnou vazbu Je d˚ uleˇzité napoprvé vytváˇret správn´ y produkt a vyhnout se dalekosáhl´ ym oprav´ am v pozdn´ıch f´ az´ıch ˇzivotn´ıho cyklu. To neznamená zmrznut´ı specifikace poˇzadavk˚ u. Podle ˇctvrtého pravidla nen´ı moˇzné se ubránit zmˇenám v zadán´ı, ale tato z´ asada vyb´ız´ı br´ anit se z´ avaˇznˇejˇs´ım pˇrevrat˚ um. Ty mohou b´ yt zp˚ usobeny jak chybou v architektuˇre systému zp˚ usobenou v´ yvoj´ aˇri, tak odklád´ an´ım vyˇzadovaného pˇrizp˚ usoben´ı klientov´ ym potˇreb´ am. Takov´ ym pot´ıˇz´ım se dá zamezit spr´ avnou spoluprac´ı s klientem, kter´ y upravuje a upˇresˇ nuje zad´ an´ı po ˇcástech. Zároveˇ n se t´ ym nesm´ı bát zmˇen v uˇcinˇen´ ych rozhodnut´ıch, nebot’ iterativn´ı v´ yvoj s sebou nese nutnost pˇrebudovat dokonˇcenou architekturu nebo pˇripravené rozhran´ı. Podstatnou roli zde hraje testov´ an´ı, nebot’ tyto zmˇeny jsou velk´ ym zdrojem chyb. Avˇsak jde o malé modifikace ve srovn´ an´ı s pˇretv´ aˇren´ım celého produktu ke konci implementace po zjiˇstˇen´ı odchylek od zadán´ı. 8. Odstranit lok´ aln´ı optimalizaci Podle Lean Manufacturing zamˇestn´ avá developery snaha o u ´plné vyt´ıˇzen´ı vˇsech stroj˚ u natolik, aˇz vznik´ a takov´ a ˇrada nevyˇr´ızen´ ych u ´kol˚ u, ˇze t´ım opˇet docház´ı ke sn´ıˇzen´ı vyt´ıˇzen´ı. Podobnˇe ztr´ acej´ı smysl neust´ alé lokáln´ı optimalizace st´ avaj´ıc´ıho ˇreˇsen´ı v softwarovém inˇzen´ yrstv´ı. Ty vedou k celkové nevyváˇzenosti produktu. Nejde toitˇz zaruˇcit, aby kaˇzdá jeho souˇcást byla optimalizovan´ a podle zcela stejného kritéria a ve stejné m´ıˇre. Optimalizace se také prov´ ad´ı vzhledem k aktu´ aln´ı ˇs´ıˇri zad´ an´ı, která se vˇetˇsinou mˇen´ı neust´ ale. Je tedy lepˇs´ı dbát na hladk´ y bˇeh celého systému neˇz se zamˇeˇrovat na co nejlepˇs´ı splnˇen´ı d´ılˇc´ıho u ´kolu. Systém je moˇzné optimalizovat jako celek aˇz ke konci v´ yvojového procesu a lokáln´ı optimalizace m´ a své m´ısto pouze v pˇr´ıpadˇe v´ yraznˇe nekvalitn´ıho modulu ve srovn´ an´ı s ostatn´ımi. 9. Db´ at na partnerstv´ı s dodavateli Vyplat´ı se vyuˇz´ıvat subdodávek pˇredpˇripraven´ ych komponent, neprogramovat vˇsechno od zaˇcátku. Pro z´ akazn´ıka je nejd˚ uleˇzitˇejˇs´ı v´ ysledná hodnota a nez´ aleˇz´ı na tom, jak hodnoty dosáhneme. Pˇri pouˇz´ıv´ an´ı ciz´ıch komponent je velmi d˚ uleˇzit´ a osoba partnera. Je nutné ohl´ıdat nˇekolik hledisek - zejména bezpeˇcnost dod´ avky, jistota nov´ ych verz´ı a spolehlivost podpory produktu pˇri pozdˇejˇs´ıch zmˇenách. Nejlepˇs´ıch v´ ysledk˚ u s obchodn´ımi vztahy dos´ ahli v osmdes´ at´ ych letech firmy, které uzavˇreli pˇrátelské partnerstv´ı jen s nˇekolika málo dodavateli. Spoleˇcnosti pak st´ aly o vz´ ajemnou


27

pomoc sp´ıˇs, neˇz uvaˇzovat stylem v´ yhra - prohra. Nav´ıc sloˇzité a zaruˇcenˇe bezpeˇcné smlouvy stoj´ı mnoho ˇcasu pˇri produkci i vyˇrizován´ı a také mnoˇzstv´ı pap´ıru, jehoˇz cena je vˇetˇs´ı, neˇz se d´ a oˇcekávat. Nepˇrinesou takovou v´ yslednou hodnotu za dan´ ych finanˇcn´ıch podm´ınek, jako pozitivn´ı vztahy zaloˇzené na d˚ uvˇeˇre. 10. Vybudovat kulturu pro moˇ znost neust´ al´ eho zlepˇ sov´ an´ı Organizace má m´ıt takov´ y systém fungován´ı, kter´ y nedus´ı jej´ı softwarovou vyspˇelost. Naopak podporuje rozvoj pracovn´ık˚ u i organizace jako celku a umoˇzn ˇuje se pouˇcit z kaˇzdého projektu. Zamˇestnanci mus´ı b´ yt ke spoleˇcnosti loaj´ aln´ı a povaˇzovat ji za svou. K tomu je spoleˇcnost mus´ı motivovat, jinak nejdou oˇcekávat maximáln´ı nasazen´ı pracovn´ık˚ u.

3.4.4


V tomto odstavci rozeberme principy Lean development, které vycház´ı z kl´ıˇcov´ ych pravidel popsan´ ych v pˇredchoz´ım odstavci. 1. Eliminace pl´ ytv´ an´ı Urˇc´ı se hodnoty v´ yznamné pro projekt. Z´ uˇcastnˇené osoby se nemaj´ı zab´ yvat niˇc´ım jin´ ym, neˇz t´ım, co produktu d´ av´ a tyto hodnoty [ 8 str. 3]. Systematicky se hledaj´ı a likviduj´ı zdroje pl´ ytván´ı. 2. Rozvinout uˇ cen´ı Bˇehem v´ yvoje ˇclenové t´ ymu nab´ yvaj´ı nejen technické znalosti, ale i praxi v mezilidské komunikaci a ve vzájemném porozumˇen´ı. Nejlepˇs´ı zp˚ usob, jak zkvalitnit v´ yvoj softwaru, je zintenzivnit z´ıskáv´ an´ı zkuˇsenost´ı. Kromˇe toho je nutné pˇred kaˇzd´ ym nevratn´ ym rozhodnut´ım co nejlépe nastudovat doménu daného problému. 3. Rozhodov´ an´ı co nejpozdˇ eji ˇ ım je systém komplexnˇejˇs´ı, t´ım v´ıce chyb m˚ C´ uˇze vzniknout pˇri n´ avrhu. Odloˇzen´ı ˇcásti rozhodnut´ı umoˇzn´ı oddálit také nˇekteré chyby a t´ım jim pˇredej´ıt. S t´ım je spojeno, ˇze o lecˇcem mus´ı rozhodovat také program´ atoˇri na nejniˇzˇs´ıch pozic´ıch, protoˇze v´ ysledek obvykle ovlivˇ nuje je. Kaˇzd´ y m´ a uvaˇzovat o vˇsech variant´ ach, které pˇrich´ azej´ı v u ´vahu. Proto je potˇreba vhodnˇe pˇridˇelovat zodpovˇednosti a podporovat pˇr´ımou spolupráci. 4. Rychl´ eaˇ cast´ e dod´ avky Tento princip vysvˇetluje souvislost mezi tˇremi c´ıli Lean development, uveden´ ymi na zaˇc´ atku kapitoly. Dod´ av´ an´ı produktu po v´ıce ˇcástech umoˇzn´ı zákazn´ıkovi delˇs´ı dobu specifikovat ˇ ım dˇr´ıve je iterace dokonˇcena, t´ım v´ıce zdroj˚ poˇzadavky a rozhodovat se. C´ u uˇsetˇr´ı na ˇcase,


28

kter´ y zabere. Také m´ a uˇzivatel t´ım delˇs´ı dobu na podáván´ı zpˇetné vazby. Proto se vyplat´ı zrychlovat iterace. Podle metodiky dev´ıti aˇz dvanáctimˇes´ıˇcn´ı projekt generuje asi 25% zmˇen. Jeho rozdˇelen´ı na nˇekolik mˇes´ıˇcn´ıch cykl˚ u se mnoˇzstv´ı odchylek od p˚ uvodn´ıho zadán´ı sn´ıˇz´ı na jedno aˇz dvˇe procenta [ 9 str. 174 ]. 5. Pravomocn´ı pracovn´ıci K lidem nejde pˇristupovat pouze jako ke zdroj˚ um hotové práce, ale lidé potˇrebuj´ı motivaci a vˇedom´ı své osobn´ı uˇziteˇcnosti. Nejd˚ uleˇzitˇejˇs´ı osoby v t´ ymu maj´ı b´ yt právˇe ty, které produkuj´ı hodnoty projektu [ 8 str. 4], ne manaˇzer. Jeho hlavn´ı role nen´ı ˇr´ıdit vˇsechno, ale poskytovat podporu a pomoc v obt´ıˇzn´ ych situac´ıch a nechat t´ ym uvaˇzovat pozitivnˇe. Urˇcit´ a hierarchie pravomoc´ı poˇzaduje vhodnˇe a peˇclivˇe vyb´ırat osobnosti do t´ ymu a zaˇskolovat je. 6. Integrita softwaru i v´ yvojov´ eho procesu Integrita se má udrˇzovat zamˇeˇren´ım se na vˇsechny sloˇzky produktu a bedliv´ ym soustˇredˇen´ım na v´ yvojov´ y proces. K tomu jsou vyuˇzitelné metody jako svˇedomité testov´ an´ı, pokud moˇzno automatické, a refaktorizace. Také je nutné rozumˇet dané doménˇe problému, kter´ y je ˇreˇsen dan´ ym produktem. Avˇsak se j´ı v´ yvoj´ aˇri mus´ı zab´ yvat jako celkem, ne po ˇcástech. 7. Vidˇ et celek Dneˇsn´ı velké systémy nejdou povaˇzovat jako prosté souˇcty jeho ˇcást´ı, ale sp´ıˇse jako produkt ˇ ım vˇetˇs´ı je projekt, t´ım d˚ vztah˚ u mezi jeho subsystémy. C´ uleˇzitˇejˇs´ı je dokonale definovat vztahy mezi jeho u ´seky a mezi d´ılˇc´ımi t´ ymy. Toto plat´ı, obzvl´ aˇstˇe pokud na projektu pracuje v´ıce organizac´ı. Pokud se mˇeˇr´ı neefektivita nebo chybovost, nemaj´ı se hodnotit konkrétn´ı moduly, ale celek.

3.4.5

Z´ avˇ er

Tato metodika zkvalitˇ nuje v´ yvojov´ y proces zaveden´ım deseti pravidel a sedmi princip˚ u. Ty jdou pomˇernˇe snadno zavést, protoˇze nejsou na sobˇe pˇr´ıliˇs silnˇe závislé. Je tedy moˇzn´ y postupné pˇrej´ım´ an´ı a zvyk´ an´ı si na nˇe. Charakteristika Lean development jen volnˇe odpov´ıdá pˇrekladu slova lean - ˇst´ıhl´ y, zeslaben´ y. Ten se t´ yk´ a zmenˇsen´ı n´ aklad˚ u na v´ yvoj odstranˇen´ım vˇsech nadbyteˇcn´ ych krok˚ u.

3.5. SCRUM DEVELOPMENT

3.5

29

Scrum development

Scrum je dalˇs´ı metodika vznikl´ a s c´ılem zv´ yˇsit efektivitu v´ yvoje softwaru. D˚ uraz na iterativn´ı a inkrement´ aln´ı pˇr´ıstup je tedy u n´ı samozˇrejmost´ı. Název Scrum podle chumlu lid´ı v ragby kumulovan´ ych na jednom m´ıstˇe za u ´ˇcelem dotlaˇcen´ı m´ıˇce na poˇzadované m´ısto. Toto metodika bere jako metaforu pro v´ yvojov´ y proces, bˇehem nˇejˇz jsou pracovn´ıci shrom´ aˇzdˇen´ı na jednom m´ıstˇe s posl´ an´ım spoleˇcnˇe dos´ ahnout c´ıle - uspokojit zákazn´ıka. Metodika zaˇcala vznikat v roce 1995 a jej´ı myˇslenky pˇredstavili Ken Schwaber a Mike Beedle.

3.5.1


Scrum vyuˇz´ıv´ a objektovˇe orientovan´ y pˇr´ıstup, kter´ y je dobˇre rozˇs´ıˇren´ y a existuje pro nˇej mnoho informac´ı. Kaˇzd´ y v´ yvoj´ aˇr odpov´ıd´ a za mnoˇzinu objekt˚ u s chov´ an´ım a rozhran´ım jasnˇe definovan´ ym, coˇz usnadˇ nuje rozdˇelen´ı pr´ ace. Nev´ yhoda je, ˇze kaˇzd´ y ˇclen t´ ymu je nezastupiteln´ y. Na druhou stranu se programátor stará o odpov´ıdaj´ıc´ı tˇr´ıdy jako o své vlastn´ı, coˇz motivuje k vˇetˇs´ı snaze o kvalitu. Pr˚ ubˇeh v´ yvoje je ˇclenˇen do nˇekolika urˇcit´ ych ˇcasov´ ych interval˚ u - sprint˚ u (Sprints). Kaˇzd´ y z nich m´ a konkrétn´ı v´ ystup (Demo). Na poˇca´tku projektu nen´ı zn´ amé, co vˇsechno bude nutné provádˇet. Nejde tedy pˇredem urˇcit nejvhodnˇejˇs´ı posloupnost ˇcinnost´ı jako anal´ yza, návrh nebo v´ yvoj. Proto nem´ a smysl plánovat pˇresn´ y pr˚ ubˇeh sprint˚ u. Centráln´ı pl´ anován´ı podrobn´ ych krok˚ u nahrazuj´ı pravidelné kaˇzdodenn´ı sch˚ uzky - Scrum meetings. T´ım je v´ yvoj flexibilnˇejˇs´ı, pruˇznˇejˇs´ı a t´ ym se m˚ uˇze lépe pˇrizp˚ usobovat zmˇenám. Na sch˚ uzk´ ach se podle aktuáln´ı situace urˇc´ı pˇresn´ y postup pro nejbliˇzˇs´ı dobu.

3.5.2 3.5.2.1

Kl´ıˇ cov´ e pojmy Flexibilita a spolupr´ ace

Flexibiln´ı pˇredmˇety dod´ an´ı - V r˚ uzn´ ych pˇr´ıpadech jsou nejvhodnˇejˇs´ı r˚ uzné formy v´ ystup˚ u z jednotliv´ ych ˇcinnost´ı. Forma a obsah dokument˚ u a jin´ ych dod´ avek se urˇcuje v pr˚ ubˇehu projektu. Napˇr´ıklad specifikace poˇzadavk˚ u m˚ uˇze b´ yt v daném pˇr´ıpadˇe nejvhodnˇejˇs´ı, kdyˇz jej´ı forma je dan´ a normou IEEE, jindy je lepˇs´ı prototyp nebo objektov´ y model. Flexibiln´ı harmonogram - term´ıny dod´ an´ı se mohou mˇenit. Je nutné o tom ˇsikovnˇe pˇresvˇedˇcit i zákazn´ıka, aby neurˇcitost term´ın˚ u nepovaˇzoval za projev neprofesionality. Spolupr´ ace - Je d˚ uleˇzité, aby ˇclenové t´ ymu spolupracovali vzájemnˇe i se sv´ ym okol´ım, pˇredevˇs´ım se zákazn´ıky. Malé t´ ymy - T´ ym nem´ıv´ a v´ıc neˇz deset ˇclen˚ u. Na jednom projektu m˚ uˇze pracovat nˇekolik t´ ym˚ u.


30

Obr´ azek 3.5: Graf

zb´ yvaj´ıc´ı

pr´ ace;

zdroj

-

http://www.businessvize.cz/rizeni-a-optimalizace/agilniprojektove-rizeni

ˇ e revize - Bˇehem denn´ıch sch˚ Cast´ uzek se podrobnˇe zkoum´ a systém a dosavadn´ı postup. Jinak zmˇeny a pokrok se zkoum´ a neust´ ale.

3.5.2.2

Backlog

Obsahuje z´ akladn´ı informace o funkc´ıch a vlastnostech, které jeˇstˇe je potˇreba implementovat, a také zmˇeny, které se maj´ı provést. Jeho forma je libovolná, m˚ uˇze j´ıt napˇr´ıklad o uˇzivatelské pˇr´ıbˇehy, tabulku nebo to-do list. Avˇsak nejlépe se osvˇedˇcuj´ı uˇzivatelské pˇr´ıbˇehy [ 10 ]. Backlog m˚ uˇze kdokoliv ˇc´ıst, ale zapisovat do nˇej a upravovat zadán´ı pouze vlastn´ık produktu. Ten ho zároveˇ n udrˇzuje co nejlépe seˇrazen´ y. Pˇriˇrazuje prioritu jednotliv´ ym poloˇzkám. Ty hodnot´ı nejprve z obchodn´ıho hlediska a v pˇr´ıpadˇe shody d˚ uleˇzitost´ı je rozhoduj´ıc´ım faktorem u ´sil´ı, které je nutné vynaloˇzit pro implementaci. Vyˇsˇs´ı prioritu dostane u ´kol jednoduˇsˇs´ı na realizaci. Rozliˇsuje se • Systémov´ y backlog - Ten obsahuje hrub´ y popis u ´kol˚ u t´ ykaj´ıc´ıch se celého projektu. Odhady doby plnˇen´ı u ´kol˚ u se pohybuj´ı ve dnech (1 - 20). Patˇr´ı vlastn´ıkovi produktu. • Sprint backlog - obsahuje podrobnˇejˇs´ı popis u ´kol˚ u urˇcuj´ıc´ıch pr´ aci pro cel´ y sprint. Doby práce na u ´kolech se odhaduj´ı v hodinách (1 - 16). Patˇr´ı t´ ymu. Kaˇzd´ y ˇclen pr˚ ubˇeˇznˇe upravuje poˇcet hodin, které jeˇstˇe potˇrebuje k dokonˇcen´ı jeho u ´kolu. Jednotlivé poloˇzky nab´ yvaj´ı stavy ”V plánu”, ”Zpracov´ av´ a se”nebo ”Dokonˇceno”.

3.5.2.3

Graf zb´ yvaj´ıc´ı pr´ ace

(Burn down chart obr. 3.5) Jde o prostˇredek, kter´ y slouˇz´ı k odhadu ˇcasu potˇrebného k dokonˇcen´ı projektu. Pomoc´ı grafu jde odhadnout poˇcet sprint˚ u, které projekt zabere. Burn down


31

zobrazuje odhad mnoˇzstv´ı zb´ yvaj´ıc´ı práce na zaˇcátku kaˇzdého sprintu. Toto mnoˇzstv´ı se ukazuje v urˇcit´ ych jednotk´ ach (hodiny, body. . . ). Zároveˇ n se zobrazuje, kolik pr´ ace pˇribylo kv˚ uli zmˇenám. Kladné hodnoty grafu zobrazuj´ı poˇcet jednotek práce urˇcené pˇred zahájen´ım projektu. Absolutn´ı hodnoty vyˇc´ıslen´ı, která jsou zobrazena jako z´ aporná, ukazuj´ı, kolik pr´ ace pˇribylo v pr˚ ubˇehu v´ yvoje. Jednou z nˇekolika grafick´ ych metod se urˇc´ı, bˇehem kolika dalˇs´ıch sprint˚ u je t´ ym schopn´ y dokonˇcit projekt. Obr´ azek ukazuje jeden z moˇzn´ ych zp˚ usob˚ u, jak odhadnout zb´ yvaj´ıc´ı potˇrebn´ y ˇcas [ 10 ]. Graf slouˇz´ı jako pom˚ ucka, kter´ a umoˇzn ˇuje sledovat rychlost postupu. Je d˚ uleˇzité vˇedˇet, jestli se napˇr´ıklad sn´ıˇz´ı rychlost v´ yvoje kv˚ uli poklesu produktivity t´ ymu, nebo kv˚ uli mnoˇzstv´ı nov´ ych ´kol˚ u u. 3.5.2.4

Riziko

Scrum d´ av´ a velk´ y d˚ uraz na anal´ yzu rizik. Ta prob´ıhá na konci kaˇzdé iterace a bˇehem denn´ıch sch˚ uzek. 3.5.2.5

Sprint

Jde o základn´ı v´ yvojovou etapu, jej´ıˇz v´ ysledek je nové viditelné rozˇs´ıˇren´ı produktu. Délka této iterace se uv´ ad´ı nejˇcastˇeji jako tˇricet dn´ı, avˇsak ˇcasto se osvˇedˇcuje také poloviˇcn´ı doba [ 10]. Sprint zahrnuje kromˇe pr´ ace pˇr´ımo na produktu také ˇr´ıdic´ı ˇcinnost, kter´ a br´ an´ı zmatk˚ um, ale nepotlaˇcuje pruˇznost v´ yvoje. 3.5.2.6

Pigs a chickens

Jde o rozdˇelen´ı t´ ymov´ ych rol´ı do dvou skupin. V´ yvoj (Development) prov´ ad´ı veˇskerou práci t´ ykaj´ıc´ı se v´ yvojového procesu a ˇr´ıká se jim pigs. Veden´ı (Management) nejsou pˇr´ımo souˇcást´ı v´ yvojového procesu, ale poˇc´ıtaj´ı se do projektu jako zadavatelé práce. Tˇem se pˇrezd´ıvá chickens. Názvy podle tˇechto zv´ıˇrat vych´ azej´ı ze známého amerického ˇzertu, ve kterém m´ a b´ yt kuˇre jen nepˇr´ımo zapleteno a vepˇr pˇr´ımo zapojen, odevzd´ an do urˇcitého projektu [5]. 3.5.2.7

Denn´ı sch˚ uzka

(Scrum meeting) Pravideln´ a kaˇzdodenn´ı sch˚ uzka celého t´ ymu trvaj´ıc´ı patnáct, maxim´ alnˇe tˇricet minut. Jej´ım u ´ˇcelem je podpoˇrit komunikaci v t´ ymu mezi vˇsemi u ´ˇcastn´ıky. Sejdou jak ˇclenové v´ yvoje, tak veden´ı. Nepˇrehlédnuteln´ yu ´ˇcinek setk´ an´ı je také zˇretelné scelován´ı t´ ymu. Hovoˇrit sm´ı jen pigs. Chickens nem˚ uˇzou dˇelat nic jiného neˇz pozorovat a uˇcit se. Chickens, kteˇr´ı jak´ ymkoliv zp˚ usobem d´ avaj´ı najevo své n´ azory, maj´ı sch˚ uzku radˇeji opustit. N´ apln´ı sch˚ uzky je pˇrehled vykonané pr´ ace, plán pˇr´ıˇst´ıho dne, projednán´ı vˇsech aktuáln´ıch, d˚ uleˇzit´ ych rizik, zmˇen a dalˇs´ıch témat. Je vedena t´ ymem. Kaˇzd´ y jeho ˇclen vysvˇetluje [ 13]:


32 • Co udˇelal od posledn´ı sch˚ uzky. • Na ˇcem bude pracovat do pˇr´ıˇst´ı sch˚ uzky. • Jestli nˇeco brán´ı jeho postupu. • Jestli detekoval nˇejak´ a nov´ a rizika.

• Nˇejaké nové moˇznosti ke zlepˇsen´ı nebo zefektivnˇen´ı práce.

3.5.3


Nejde o ˇzádnou posloupnost detailnˇe popsan´ ych postup˚ u. Pr˚ ubˇeh v´ yvoje je nelineárn´ı a empirick´ y. Urˇcuje se a upravuje na t´ ymov´ ych sch˚ uzk´ ach. Skládá se z následuj´ıc´ıch ˇcást´ı. Fáze pˇredehry: 1. Plánov´ an´ı - Mapuj´ı se poloˇzky z backlogu na objekty. Urˇc´ı se rozsah aktu´ aln´ı verze, harmonogram, zdroje. Vol´ı se v´ yvojové nástroje a prob´ıhá anal´ yza rizik. 2. Architektura a design - Vytvoˇr´ı se nebo uprav´ı architektura podle nov´ ych poˇzadavk˚ ua rizik. Fáze hry: 3. V´ yvoj - Cyklus sprint˚ u. Délka cyklu se urˇc´ı podle komplexnosti produktu, velikosti t´ ymu, mnoˇzstv´ı rizik. Fáze dohry 4. 4. Uzavˇren´ı - Doch´ az´ı ke komplexn´ı integraci, testován´ı a tvorbˇe dokumentace. Jakmile na konci posledn´ıho sprintu schv´ al´ı veden´ı nebo zákazn´ık, ˇze aktuáln´ı verze má dostaˇcuj´ıc´ı parametry, n´ asleduje tato f´ aze. 3.5.3.1

Pr˚ ubˇ eh jednoho sprintu

Sprint zaˇc´ıná sch˚ uzkou t´ ymu, vlastn´ıka produktu a dalˇs´ıch, kdo maj´ı b´ yt u plánován´ı sprintu. Nem´ a pˇresáhnout osm hodin a je rozdˇelena do dvou stejnˇe dlouh´ ych ˇcást´ı [ 14 ]. V prvn´ı z nich vˇsichni vyberou skupinu poˇzadavk˚ u ze systémového backlogu, na kterou se chtˇej´ı zamˇeˇrit. Tyto poloˇzky nejsou pˇr´ıliˇs obsáhle pops´ any a doba implementace nen´ı pˇresná. Vlastn´ık produktu smluv´ı s t´ ymem, kolik pr´ ace se dá provést bˇehem nadch´ azej´ıc´ıho sprintu. Stanov´ı a odsouhlas´ı c´ıl sprintu. Ve druhé p˚ uli sch˚ uzky se provede expanze poloˇzek vybran´ ych ze systémového backlogu. Podrobnˇe se zmapuj´ı poˇzadavky a vloˇz´ı se do sprint backlogu. Stanov´ı se postup a pl´ an v´ yvoje.


33

Po této u ´vodn´ı sch˚ uzce následuj´ı fáze v´ yvoj (develop), zabalen´ı (wrap), revize (review) a pˇrizp˚ usoben´ı (adjust). Funkcionality se po implementaci zabal´ı do jednoho celku a provede se jejich revize. To je sch˚ uzka, na které se pˇredvede funkˇcn´ı prototyp celému t´ ymu a vlastn´ıkovi produktu. T´ ym t´ım z´ısk´ a zpˇetnou vazbu na nové funkcionality. Zkoumaj´ı se nedokonˇcené u ´koly. Sch˚ uzka je ˇcasovˇe omezená na ˇctyˇri hodiny. Potom se provedou potˇrebn´ a pˇrizp˚ usoben´ı a pˇred´ an´ım prototypu. Nakonec se uplynul´ y sprint zhodnot´ı na závˇereˇcném zased´ an´ı. Sejde se cel´ y t´ ym vˇcetnˇe veden´ı a vlastn´ıka produktu. Kaˇzd´ y m´ a dostat pˇr´ıleˇzitost sdˇelit, co se zdaˇrilo, a navrhnout moˇznosti, jak pˇr´ıˇst´ı sprint vylepˇsit. Posledn´ım bodem setk´ an´ı je hled´ an´ı nov´ ych poloˇzek backlogu a odhad obsahu n´ asleduj´ıc´ıho sprintu. Vˇse by se mˇelo stihnout do tˇr´ı hodin. 3.5.3.2

Pˇ redˇ casn´ e ukonˇ cen´ı sprintu

Za urˇcit´ ych okolnost´ı se m˚ uˇze stát, ˇze sprint je nutné ukonˇcit pˇredˇcasnˇe. Pˇreruˇsen´ı vyˇzaduj´ı tyto situace: • Je jisté, ˇze nejde dos´ ahnout c´ıle sprintu. • Z´ asadn´ı a naléhavé vnˇejˇs´ı zmˇeny, které zp˚ usob´ı neplatnost c´ıle sprintu nebo v´ yznamné funkcionality. • Selh´ an´ı implementace Scrum kv˚ uli nemoˇznosti pˇresvˇedˇcit vlastn´ıka produktu, aby z´ıskal odpovˇedi na ot´ azky t´ ymu. • Selh´ an´ı implementace Scrum kv˚ uli zásadn´ımu sporu uvnitˇr t´ ymu. Po pˇredˇcasném ukonˇcen´ı sprintu následuje plánován´ı dalˇs´ıho sprintu, pˇri kterém se také projedn´ a d˚ uvod ukonˇcen´ı pˇredeˇslého sprintu.

3.5.4

T´ ymov´ e role

Projekt ˇr´ızen´ y podle Scrum vyˇzaduje obsazen´ı tˇechto rol´ı: • V´ yvoj (pigs) – Manaˇzer t´ ymu (Scrum master) se stará o správn´ y postup vedouc´ı k urˇcenému c´ıli sprintu. Háj´ı zájmy t´ ymu a pom´ ahá mu dosahovat co nejlepˇs´ıch v´ ysledk˚ u. Kontroluje pokroky a odchylky od zad´ an´ı. Jeho zodpovˇednost je mluvit za t´ ym s okol´ım. Jelikoˇz se t´ ym s´ am um´ı podle Scrum nejl´ıp organizovat, nemˇel by toto dˇelat manaˇzer t´ ymu. – T´ ym - Hlavn´ım u ´kolem je vyvinout produkt podle zadán´ı. Skl´ adá se ze tˇr´ı aˇz deseti pracovn´ık˚ u nevyhranˇen´ ych ve schopnostech jen na jednu ˇcinnost. Podle momentáln´ı potˇreby berou na sebe role program´ ator˚ u, tester˚ u, dokument´ ator˚ u a osob


34

zodpovˇedn´ ych za ˇr´ızen´ı kvality. Kaˇzd´ y by mˇel dˇelat cokoliv, co t´ ymu pom˚ uˇze k dosaˇzen´ı c´ıle sprintu. T´ ym um´ı sám rozhodovat, jaké konkrétn´ı kroky m´ a kdo provádˇet pˇri ˇreˇsen´ı problému. – Vlastn´ık produktu (product owner) - Reprezentuje z´ akazn´ıka, jehoˇz neust´ alou pˇr´ıtomnost na pracoviˇsti Scrum nepˇredepisuje. M´ a na starosti backlog. Kontroluje, jestli t´ ym pracuje správnˇe z obchodn´ıho hlediska a podává zpˇetnou vazbu na hotové ˇcásti produktu. M˚ uˇze b´ yt ˇclenem, ale ne manaˇzerem t´ ymu. Nˇekdy se ˇrad´ı mezi veden´ı. • Veden´ı (chickens) – Investoˇri (z´ akazn´ıci, obchodn´ıci) - Spouˇst´ı projekt. Pˇr´ımo jsou do nˇej zapojeni pouze bˇehem revize sprintu. – Manaˇzer projektu (project manager) - Definuje obsah a harmonogram dod´ avek verz´ı. Vytváˇr´ı prostˇred´ı pro organizaci vyv´ıjej´ıc´ı produkt. ˇ Clenov´ e spoleˇcnosti organizované podle Scrum mus´ı b´ yt • Flexibiln´ı - umˇet pruˇznˇe reagovat na zmˇeny pˇri v´ yvoji • Zodpovˇedn´ı - schopn´ı vysvˇetlit pˇr´ıˇciny zmˇen a odpov´ıdat za pˇr´ıpadné problémy • Spolehliv´ı - aby mohli odpov´ıdat za mˇen´ıc´ı se systém

3.5.5

Spolupr´ ace v´ıce t´ ym˚ u

Pokud je t´ ym na rozsah projektu pˇr´ıliˇs mal´ y, nen´ı vhodné ho rozˇsiˇrovat, lepˇs´ı je vytvoˇrit dalˇs´ı. Existuj´ı dvˇe metody, jak vhodnˇe projekt rozdˇelit na v´ıce ˇcást´ı. Jedna z nich je funkcion´ aln´ı dˇelen´ı, kdy se vytvoˇr´ı shluky funkc´ı. Druh´ a moˇznost je systémové dˇelen´ı, coˇz je rozˇclen´ı projektu po vrstvách. Podobnˇe jako t´ ym lid´ı jde koordinovat podle Scrum také klastr t´ ym˚ u. Kaˇzd´ y t´ ym potom deleguje jednoho z´ astupce na denn´ı sch˚ uzky mezit´ ymového Scrum. Denn´ı sch˚ uzky klastr˚ u t´ ym˚ u prob´ıhaj´ı po sch˚ uzk´ ach t´ ym˚ u. Bˇehem nich se jedná hlavnˇe o integraci a pˇresahem zad´ an´ı jednotliv´ ych t´ ym˚ u. Otázky manaˇzera klastru jsou rozˇs´ıˇreny o tyto [ 11 ]: • Co dˇelal tv˚ uj t´ ym od posledn´ıho naˇseho setk´ an´ı? • Na ˇcem bude tv˚ uj t´ ym pracovat do pˇr´ıˇst´ıho setk´ an´ı? • Je zde nˇeco, co zpomaluje tv˚ uj t´ ym? • Chyst´ aˇs se zas´ ahnout do ˇcinnosti jiného t´ ymu? Je také moˇzné vytvoˇrit klastr klastr˚ u rovnˇeˇz ˇr´ızen´ y podle Scrum a t´ımto zp˚ usobem vést projekt, na kterém pracuje aˇz pˇet set lid´ı [ 11 ].

3.6. FEATURE DRIVEN DEVELOPMENT

3.5.6

35

Z´ avˇ er

Mezi hlavn´ı pˇrednosti Scrum patˇr´ı flexibilita t´ ymu jako celku. Ten dokáˇze reagovat na zmˇeny vznikaj´ıc´ı bˇehem práce na projektu. V libovolnou chv´ıli je tedy moˇzné pˇrej´ıt na efektivnˇejˇs´ı cestu k c´ıli. D´ıky denn´ım sch˚ uzk´ am je v´ yvojov´ y t´ ym velmi dobˇre soudrˇzn´ y a reaguje na potˇreby sv´ ych ˇclen˚ u. Je mal´ y a dobˇre se v nˇem komunikuje. Kaˇzd´ y má moˇznost se poradit s ostatn´ımi, pokud má pot´ıˇze. Pr´ ace podle této metodiky je pˇr´ıjemn´ a, protoˇze ˇclenové t´ ymu si sami vol´ı, jakou budou dˇelat pr´ aci a kolik na ni potˇrebuj´ı ˇcasu. Mohou navrhovat optim´ aln´ı ˇreˇsen´ı podle sebe. Zp˚ usob odhadu pracnosti m´ a vysokou u ´roveˇ n. Manaˇzer t´ ymu tedy dobˇre vid´ı, jak t´ ym postupuje k vytyˇcenému c´ıli a je vˇcas informov´ an, pokud se oˇcekávaj´ı nˇejaké obt´ıˇze.

3.6

Feature driven development

Metodika povaˇzuje za z´ akladn´ı pil´ıˇre projektu vlastnosti a lidi. Projekt jde rozdˇelit na jednotlivé vlastnosti a vyv´ıjet zvláˇst’ kaˇzdou z nich. Kvalita aplikace m´ a b´ yt zaruˇcena co nejlepˇs´ı implementac´ı jednotliv´ ych ˇc´ ast´ı. D´ ale povaˇzuje za kl´ıˇcové trávit pracovn´ı dobu co nejpˇr´ıjemnˇeji. Snaha autor˚ u metodiky je podat n´ avod, jak pracovat efektivnˇe, produktivnˇe a bez zbyteˇcn´ ych rozvrat˚ u ˇci jin´ ych pˇrek´ aˇzek u ´ˇcinnému pokroku.

3.6.1


FDD m´ a pˇrehledn´ y ˇzivotn´ı cyklus. Soustˇred’uje se na f´ aze n´ avrh a implementace. V´ yvoj je rozˇclenˇen do krátk´ ych iterac´ı - kaˇzdá trvá jeden aˇz tˇri t´ ydny. V pr˚ ubˇehu jedné z nich je vytvoˇrena urˇcit´ a skupina vlastnost´ı. S dokonˇcen´ım iterace se z´ akazn´ıkovi pˇred´ avá nová betaverze. Vych´ az´ı se z objektov´ ych model˚ u: Glob´ aln´ı model je znaˇcnˇe abstraktn´ı a je obecnˇejˇs´ı strukturou neˇz podrobn´ y popis architektury systému. Dále se pro kaˇzdou iteraci vytv´ aˇr´ı jeden nebo v´ıce objektov´ ych model˚ u, které obsahuj´ı vˇsechny d˚ uleˇzité detaily.

3.6.2 3.6.2.1

Kl´ıˇ cov´ e pojmy Vlastnost

Jak je jiˇz uvedeno v u ´vodu, je vlastnost základn´ım stavebn´ım kamenem. Jde o mal´ y v´ ysledek uˇziteˇcn´ y z pohledu z´ akazn´ıka, o konkrétn´ı funkcionalitu, která má vˇsechny tyto tˇri pˇr´ıznaky: • Mˇeˇritelnost - Mus´ı j´ıt rozhodnout, jestli je implementovan´ a vlastnost shodná s poˇzadovanou. • Srozumitelnost - Je zˇrejmé, ˇceho se vlastnost t´ yk´ a a co bude jej´ım v´ ysledkem.


36

Obr´ azek 3.6: Schéma v´ yvoje softwaru podle FDD; pˇrekresleno podle 9

• Realizovatelnost - Doba implementace nepˇresáhne délku jedné iterace, jinak se vlastnost má rozˇclenit na menˇs´ı. Aby vlastnosti mohly lépe odpov´ıdat charakteristikám, je pro jejich n´ azev pˇredepsán konkrétn´ı formát: akce - pˇredmˇet - podrobnosti. Akce vyjadˇruje ˇcinnost, kterou vlastnost realizuje. Rad´ı, ˇ ık´ jak´ a se m´ a napsat metoda. Pˇredmˇet popisuje artefakt, se kter´ ym se akce prov´ ad´ı. R´ a, jaké tˇr´ıdy se vlastnost t´ yk´ a. Podrobnosti upˇresˇ nuj´ı vlastnost. Na rozd´ıl od pˇr´ıpad˚ u uˇzit´ı jde pˇri ˇclenˇen´ı projektu dos´ ahnout vyrovnan´ ych vlastnost´ı z hlediska n´ aroˇcnosti na implementaci. 3.6.2.2

Pˇ r´ıstup ˇ r´ızen´ y modelem

Metodika proti agiln´ımu manifestu upˇrednostˇ nuje návrh pomoc´ı modelu pˇred funkˇcn´ım kódem. Vlastnost je mnohem menˇs´ı z´ akladn´ı element neˇz iterace v pˇr´ıpadˇe jin´ ych agiln´ıch metodik. Proto se n´ avrh ned´ a obej´ıt, aby mohl vzniknout funkˇcn´ı celek. Cel´ y systém m´ a globáln´ı model a kaˇzdá iterace m´ a podrobnˇejˇs´ı model.

3.6.3


FDD definuje pˇet proces˚ u obr. 3.6 1. Vytvoˇren´ı glob´ aln´ıho modelu 2. Vypracován´ı podrobného seznamu vlastnost´ı 3. Plánov´ an´ı podle vlastnost´ı 4. Návrh podle vlastnost´ı 5. Implementace podle vlastnost´ı


37

Kaˇzd´ y proces prob´ıh´ a podle ˇsablony ETVX (Entry, Task, Verification, eXit) [ 16 ], kterou zaˇradil do metodiky Jeff De Luca. Podle n´ı má m´ıt proces specifikov´ any (kromˇe obecného popisu) n´ asleduj´ıc´ı parametry: • Vstupn´ı kritéria ´ • Ukoly, které se maj´ı splnit (vˇcetnˇe identifikace ˇreˇsitel˚ u a odpovˇedn´ ych manaˇzer˚ u) • N´ astroje a metody verifikace (uk´ aˇzou, jestli uˇz je proces dokonˇcen´ y) • V´ ystupn´ı kritéria procesu (fyzické v´ ystupy, dokumenty a prototypy) Nejprve probˇehnou vˇsechny procesy v uvedeném poˇrad´ı. Poté se stˇr´ıdaj´ı fáze 4 a 5 a t´ım prob´ıhaj´ı jednotlivé iterace. Kdykoliv se zjist´ı, ˇze je nutné pˇrizp˚ usobit a modifikovat objektov´ y model a dalˇs´ı dokumenty, je moˇzné se po skonˇcen´ı iterace vr´ atit k u ´vodn´ım fáz´ım. Ty zab´ıraj´ı v celém procesu asi pˇetinu celkového ˇcasu, ve zb´ yvaj´ıc´ı dobˇe se provád´ı implementace. 1. Vytvoˇ ren´ı glob´ aln´ıho modelu Vstupn´ımi kritérii jsou urˇcen´ı funkc´ı hlavn´ıho program´ atora a hlavn´ıho architekta. Dalˇs´ım vstupn´ım poˇzadavkem je také existence tzv. doménov´ ych expert˚ u. To jsou lidé, kteˇr´ı dobˇre znaj´ı prostˇred´ı, ve kterém m´ a b´ yt systém nasazen. Z´ aroveˇ n d˚ ukladnˇe znaj´ı obor, ˇ kterého se aplikace t´ yk´ a. Casto jde o z´ akazn´ıky. Vˇsechny tyto osoby sestav´ı t´ ym pro vytvoˇren´ı globáln´ıho modelu. Nechaj´ı t´ ym vytvoˇrit model, vylad´ı ho a nap´ıˇsou k nˇemu poznámky. Vznikl´ y model demonstruje z´ akladn´ı u ´ˇcel systému a je smˇerodatn´ y pro vˇsechny z´ uˇcastnˇené. Je tedy abstraktn´ı a je odst´ınˇen od podruˇzn´ ych podrobnost´ı [1]. B´ yv´ a objektov´ y a formovan´ y v jazyce UML. V této f´ azi je tedy d˚ uleˇzité nepˇredb´ıhat do dalˇs´ıch krok˚ u, vyvarovat se u ´vah´ am nad detaily a t´ım se uˇz od zaˇcátku ubránit nekonzistenc´ım. 2. Vypracov´ an´ı podrobn´ eho seznamu vlastnost´ı V dalˇs´ı f´ azi hlavn´ı program´ ator, hlavn´ı architekt a doménov´ı experti sestav´ı t´ ym pro vytvoˇren´ı seznamu vlastnost´ı. V´ ystupn´ımi kritérii jsou hotov´ y seznam hlavn´ıch oblast´ı domény, seznam obchodn´ıch proces˚ u ke kaˇzdé z tˇechto oblast´ı a seznam vlastnost´ı. Kaˇzdému kroku kaˇzdého obchodn´ıho procesu odpov´ıdá jedna vlastnost. Jako pˇr´ıklad obchodn´ıho procesu vezmˇeme pˇrihl´ aˇsen´ı uˇzivatele do systému pomoc´ı uˇzivatelského jména a hesla. Tento proces m´ a vyvolat nˇekolik krok˚ u. Tˇem pak odpov´ıdaj´ı jednotlivé vlastnosti a patˇr´ı mezi nˇe pˇredevˇs´ım kontrola existence uˇzivatelského jména, ovˇeˇren´ı správnosti hesla a pˇridˇelen´ı sady pˇr´ıstupov´ ych pr´ av, urˇcené pro dané uˇzivatelské jméno. Seznam vlastnost´ı mus´ı b´ yt seˇrazen podle priorit a má pokr´ yvat co nejv´ıc poˇzadavk˚ u na systém. V téhle f´ azi vˇsak jeˇstˇe nen´ı definitivn´ı.


38 3. Pl´ anov´ an´ı podle vlastnost´ı

Nejprve se stanov´ı datum ukonˇcen´ı v´ yvoje produktu. To má b´ yt definitivn´ı a jemu se maj´ı pˇrizp˚ usobit vˇsechny ostatn´ı mezn´ıky, aby se nezvyˇsovaly n´ aklady produktu. N´ aslednˇe se pˇridˇel´ı vedouc´ı program´ atoˇri obchodn´ım proces˚ um a vlastn´ıci skupinám vlastnost´ı a tˇr´ıd. Tito lidé odpov´ıdaj´ı za dokonˇcen´ı jejich práce do urˇcitého data. Na základˇe priorit a vzájemn´ ych z´ avislost´ı mezi vlastnostmi se rozhodne o poˇrad´ı, ve kterém se budou implementovat. Nejde vˇsak o striktn´ı a nemˇennou posloupnost. 4. N´ avrh podle vlastnost´ı Hlavn´ı program´ ator vybere pro následuj´ıc´ı iteraci mnoˇzinu vlastnost´ı podle plánu z pˇredchoz´ı fáze a také db´ a na to, aby mnoˇzina co nejlépe sd´ılela stejné tˇr´ıdy. Potom zah´ aj´ı proces zvan´ y ”Design by feature”, kter´ y spoˇc´ıvá zejména v podrobném zkoumán´ı domény a relevantn´ıch dokument˚ u. Poté se vylad´ı objektov´ y model a nap´ıˇsou se hlaviˇcky tˇr´ıd a metod. Podrobnosti jsou v [ 18 str. 7 ]. Je d˚ uleˇzité rozliˇsovat v´ ysledky pr´ ace, které se t´ ykaj´ı návrhu a které implementace [ 17 ]. Spojován´ı tvorby oboj´ıho do jedné ˇcinnosti by sn´ıˇzilo efektivitu napˇr´ıklad proto, ˇze se pˇri n´ avrhu pracuje se znalostmi doménov´ ych expert˚ u, zat´ımco pˇri implementaci se vycház´ı hlavnˇe z n´ avrhu. 5. Implementace podle vlastnost´ı Tento proces m´ a název ”Build by feature”. Vlastnost se implementuje pˇridán´ım kódu do nˇekolika tˇr´ıd. Je jasné, ˇze funkcionality jedné tˇr´ıdy se mohou t´ ykat mnoha vlastnost´ı. Kaˇzdá tˇr´ıda m´ a svého vlastn´ıka; ti vytvoˇr´ı t´ ym pro danou vlastnost. Podle aktuáln´ıho stavu hlavn´ı program´ ator shromaˇzd’uje do r˚ uzn´ ych skupin programátory, kteˇr´ı jsou mu podˇr´ızen´ı. Mus´ı stanovit, kteˇr´ı lidé danou vlastnost vytváˇrej´ı. Typicky se t´ ymy vzájemnˇe prol´ınaj´ı, v pr˚ ubˇehu jedné iterace vznikaj´ı a zanikaj´ı. Proto hlavn´ı program´ ator mus´ı udrˇzet o situaci pˇrehled. Verifikace procesu se provád´ı pr˚ ubˇeˇznou inspekc´ı a jednotkov´ ymi testy. ˇ Cinnost program´ ator˚ u spoˇc´ıv´ a ve psan´ı jednotkov´ ych test˚ u, implementaci a testován´ı tˇr´ıd. Hotové tˇr´ıdy ukl´ adaj´ı do tzv. Class repositury a hlavn´ı program´ ator je schvaluje. Poté je integruje do hlavn´ı aplikace. Pro zajiˇstˇen´ı kvality kódu FDD pˇredepisuje zároveˇ n defenzivn´ı programován´ı a jednotkové testy. Srovnán´ı tˇechto dvou metod je uvedeno v [ 21 ].

3.6.4 3.6.4.1

Z´ akladn´ı principy Objektov´ e modelov´ an´ı dom´ en

Pro kaˇzdou oblast problému - doménu - se vytváˇr´ı model, kter´ y znázorˇ nuje vˇsechny v´ yznamné objekty. Objektov´ y model domény je abstraktn´ı r´ amec, do kterého se pozdˇeji vkl´ adaj´ı jednotlivé


39

funkce. Toto je dokument, kter´ y pom´ ahá orientovat se v projektu a slouˇz´ı k udrˇzen´ı integrity systému. FDD doporuˇcuje realizovat modely pomoc´ı objektov´ ych diagram˚ u tˇr´ıd (class diagrams) a sekvenˇcn´ıch diagram˚ u. V´ yhodou diagram˚ u tˇr´ıd oproti sekvenˇcn´ım je zn´ azornˇen´ı vztah˚ u mezi tˇr´ıdami, mezi nˇeˇz patˇr´ı dˇediˇcnost. Z´ aroveˇ n je na sekvenˇcn´ıch diagramech vidˇet, jak´ ym zp˚ usobem mezi sebou objekty komunikuj´ı. Jde o ER-diagramy (Entity-Relationship diagrams) a ERAdiagramy (Entity-Relationship-Attribute diagrams). Peter Coad navrhnul metodu barevného odliˇsen´ı prvk˚ u v modelu. Na prvn´ı pohled jde rozliˇsit napˇr´ıklad ˇcasov´ yu ´daj ˇci roli od objektu. V´ıce v [ 24 ].

3.6.4.2

V´ yvoj podle vlastnost´ı

Pˇri v´ yvoji podle tradiˇcn´ıch metodik t´ ym ˇcasto povaˇzuje za z´ akladn´ı stavebn´ı sloˇzky projektu velké u ´seky, celé moduly. FDD navrhuje postup po ˇcástech menˇs´ıch, neˇz jsou moduly, a to pˇrin´ aˇs´ı nˇekolik v´ yhod. M´ısto propracov´ aván´ı modul˚ u se v´ yvoj´ aˇri zamˇeˇruj´ı pˇr´ımo na poˇzadované funkcionality a tak se o to v´ıce zab´ yvaj´ı poˇzadavky zákazn´ıka. D´ ale tento princip do znaˇcné m´ıry omezuje nepouˇzité metody a atributy. Nen´ı d˚ uleˇzité to, o ˇcem si v´ yvoj´ aˇr mysl´ı, ˇze se m´ a naprogramovat. Vytv´ aˇr´ı se pr´ avˇe ty metody, které jsou na seznamu funkˇcn´ıch poˇzadavk˚ u a pˇrin´ aˇs´ı hodnotu uˇzivateli.

3.6.4.3

Vlastnictv´ı tˇ r´ıd

S vlastnictv´ım tˇr´ıd souvis´ı následuj´ıc´ı v´ yhody: Vlastn´ık m´ a nad sv´ ymi tˇr´ıdami nadhled a zabr´ an´ı kaˇzdému naruˇsen´ı jejich konceptu´ aln´ı integrity. Rovnˇeˇz dokáˇze tˇr´ıdu upravovat rychleji, neˇz ˇclovˇek, kter´ y k´ od nezná. Vˇetˇsinou vlastn´ıkovi z´ aleˇz´ı na tom, aby ”jeho”tˇr´ıdy byly co nejkvalitnˇejˇs´ı. Ale s vlastnictv´ım tˇr´ıd jsou spojené i nˇekteré nev´ yhody. Projev´ı se hlavnˇe tehdy, kdyˇz nˇekdo opust´ı t´ ym. Vlastn´ık b´ yv´ a pˇresvˇedˇcen o dokonalosti sv´ ych tˇr´ıd a také je nerad nech´ av´ a kvalitnˇe otestovat.

3.6.4.4

T´ ymy sestavovan´ e podle vlastnost´ı

Kaˇzdou vlastnost implementuje t´ ym lid´ı sloˇzen´ y z vlastn´ık˚ u tˇr´ıd, kter´ ych se dan´ a vlastnost t´ yká. Na dobu vyhotoven´ı vlastnosti sestav´ı t´ ym. Jeho jedin´ yu ´kol je realizovat vlastnost. Kaˇzd´ y ˇclen tvoˇr´ı ˇc´ ast vlastnosti, jej´ıˇz k´ od obsahuje jeho tˇr´ıda. Avˇsak je typické, ˇze v jedné tˇr´ıdˇe je implementov´ ano v´ıcero ˇc´ ast´ı vlastnost´ı. Tedy jeden vlastn´ık tˇr´ıdy je ˇclenem nˇekolika t´ ym˚ u. T´ımto pˇr´ıstupem se dosáhne zˇretelného rozdˇelen´ı u ´kol˚ u a je jasné, kdo má co ps´ at. Prol´ın´ an´ı t´ ym˚ u vˇsak klade velké n´ aroky na ˇséfy t´ ym˚ u. Od nich se poˇzaduje velk´ a odpovˇednost, komunikaˇcn´ı dovednosti a jiné schopnosti.


40 3.6.4.5

Inspekce

Bˇehem kaˇzdé z fáz´ı v´ yvoje se prov´ ad´ı inspekce nebo posudkové ˇr´ızen´ı, aby se detekovaly chyby. Mezi hlavn´ı techniky patˇr´ı kontroly designu, k´ odu, testov´ an´ı jednotek, intern´ı a extern´ı posudkov´ a ˇr´ızen´ı. Intern´ı prob´ıhaj´ı uvnitˇr t´ ymu a extern´ı je konzultace se z´ akazn´ıkem. Za nejefektivnˇejˇs´ı techniky FDD povaˇzuje posudkov´ a ˇr´ızen´ı a procházen´ı kódu. Naopak nejménˇe chyb odhal´ı jednotkové testy, coˇz je uvedeno v [ ?? ].

3.6.5

Z´ avˇ er

FDD je velmi praktická metodika, která vycház´ı ze skuteˇcn´ ych zkuˇsenost´ı. Projekty ˇr´ızené podle n´ı b´ yvaj´ı pro zákazn´ıka hodnotné, coˇz dokazuje napˇr´ıklad ˇclánek v [ 23 ]. Metodika definuje, jak má vypadat obecn´ y r´ amec projektu a popisuje pˇet kl´ıˇcov´ ych proces˚ u. Navrhuje dekomponovat v´ yvojov´ y proces na velmi malé ˇca´sti - vlastnosti. Nezavád´ı ˇzádn´ a sloˇzit´ a pravidla pro v´ yvoj a pˇri novém zavádˇen´ı metody nevyˇzaduje pˇr´ıliˇs mnoho zmˇen v postupech pracovn´ık˚ u. Nedefinuje ˇzádné konkrétn´ı metody, jak prov´ adˇet jednotlivé ˇcinnosti. Tvrd´ı, ˇze tyto metody m´ a znát hlavn´ı programátor. V opaˇcném pˇr´ıpadˇe potˇrebuje zkuˇseného poradce, kter´ ym m˚ uˇze b´ yt i extern´ı pracovn´ık [ 15 ].

3.7

Test driven development

Základem celého procesu v´ yvoje podle TDD je testov´ an´ı. Je zam´ıtunuto psan´ı jakéhokoliv k´ odu, dokud pro nˇej neexistuje test. Pokud se vyplat´ı implementovat urˇcitou funkˇcnost, m´ a v´ yznam i tvoˇrit pro ni jednotkov´ y test.

3.7.1

Charakteristika

P5i tomto postupu je skuteˇcnˇe podstatné psát nejprve testovac´ı a pak zdrojov´ y k´ od. Vznik´ a tak zaj´ımav´ y synergick´ y efekt [ 23 ]: • Programátor lépe porozum´ı zad´ an´ı. • Lepˇs´ı zamˇeˇren´ı se na u ´kol je zp˚ usobeno t´ım, ˇze programátor se pokaˇzdé zab´ yv´ a jedn´ım jednoduch´ ym testovac´ım pˇr´ıpadem. Nemus´ı se tedy momentálnˇe soustˇredit na pˇr´ıliˇs sloˇzit´ y problém. • Postup po mal´ ych ˇc´ astech je spojen se snadnou identifikac´ı a opravou chyb v daném u ´seku. Dále poskytuje moˇznost udrˇzovat projekt stále funkˇcn´ı t´ım vyd´ avat ˇcásteˇcné verze pˇred dokonˇcen´ım celého procesu [ 21 ].

3.7. TEST DRIVEN DEVELOPMENT

41

• Jak jsem si mohl ovˇeˇrit malou anketou, ˇcasto je pˇred napsán´ım zdrojového kódu v´ıce ˇcasu ke psan´ı testu. Pokud psan´ı testu nem´ a d˚ uleˇzitost, nemá smysl ani produkce zdrojového kódu [ 25 ]. Je pochopitelné, ˇze mnoˇzstv´ı test˚ u sice zpomaluje v´ yvoj, avˇsak v´ ysledek b´ yvá kvalitnˇejˇs´ı. TDD nedefinuje f´ azi celkového návrhu. Zamˇeˇruje se aˇz na chv´ıli, kdy je potˇreba implementovat konkrétn´ı funkˇcnost. Do té doby nech´ av´ a prostor jin´ ym metodik´ am.

3.7.2


Kent Beck, kter´ y je z´ aroveˇ n autor XP, klade d˚ uraz na efektivn´ı produkci testovac´ıch modul˚ u a architekturu. Jej´ı kvalita záleˇz´ı hlavnˇe na jej´ı konzistenci. Umoˇzn ˇuje jednoduchost testov´ an´ı, u ´prav a u ´drˇzby. Ide´ aln´ı podoba je volné spojen´ı komponent. Beck od testovac´ıch modul˚ u oˇcekáv´ a [1]: • Rychl´ y bˇeh bez zdrˇzov´ an´ı konfigurac´ı a okamˇzité vracen´ı v´ ysledk˚ u. • Testy jsou samostatné a vz´ ajemnˇe nezávislé - bez rozd´ılu, v jakém poˇrad´ı jsou spouˇstˇeny. • Vypisuj´ı relevantn´ı data, ze kter´ ych je snadno pochopiteln´ y v´ ysledek testu. • Pracuj´ı s reáln´ ymi daty. • Z testu m´ a b´ yt jasné, jak´ a nová funkcionalita byla do aplikace pˇridána. TDD vyˇzaduje pouˇzit´ı n´ astroj˚ u, které podporuj´ı testov´ an´ı, jinak by byla aplikace TDD obt´ıˇzn´ a.

3.7.3


Implementace prob´ıh´ a v cyklech dlouh´ ych ˇrádovˇe minuty. Bˇehem kaˇzdého z nich se vytvoˇr´ı jedna funkce, pˇr´ıpadnˇe jeden modul. Pro lepˇs´ı orientaci v postupu jsou definovány dva stavy aplikace - zelen´ y a ˇcerven´ y, kdy nejménˇe jeden test selˇze. Zelen´ y stav znaˇc´ı, ˇze vˇsechny testy probˇehnou u ´spˇeˇsnˇe a ukazuje, ˇze bud’ je vˇsechen kód v poˇra´dku, nebo jsou nˇekteré testy chybné. Cel´ y proces prob´ıh´ a v tˇechto f´ az´ıch: 1. Systém je v zeleném stavu. Nen´ı ˇzádn´ y test, kter´ y by hl´ asil chybu. 2. Pokud produkt nen´ı dokonˇcen, m˚ uˇze se provést refaktorizace hotového kódu nebo implementovat nová funkcionalita. Spust´ı se vˇsechny testy. Pokud vˇsechny projdou, vr´ at´ıme se do f´ aze 1. Jinak pokraˇcujeme f´ az´ı 3. 3. Systém je v ˇcerveném stavu. Uprav´ı se zdrojov´ y k´ od, kter´ y neproˇsel testem, a vrát´ıme se do f´ aze 2.


42

Obr´ azek 3.7: Postup pˇri v´ yvoji softwaru podle TDD; pˇrekresleno podle 9

3.7.3.1

Pr˚ ubˇ eh jednoho cyklu

Bˇehem jedné iterace je nutné dodrˇzet poˇrad´ı ˇcinnost´ı jako je na obrázku obr. 3.7: 1. V´ yvojáˇr co nejrychleji nap´ıˇse testovac´ı kód pro nov´ y zdrojov´ y k´ od. 2. Spust´ı se vˇsechny testy (nebo jejich podmnoˇzina v pˇr´ıpadˇe rozs´ ahl´ ych projekt˚ u) pro kontrolu konzistence testovac´ı sady. Ovˇeˇr´ı se, ˇze selˇze jen nov´ y test kv˚ uli absenci nového k´ odu. 3. M˚ uˇze se psát, upravovat a testovat zdrojov´ y kód - tak dlouho, dokud test nepˇrestane hl´ asit chybu. Pokud nen´ı moˇzné upravit testovan´ y k´ od bˇehem nˇekolika minut tak, aby proˇsel testem, je lepˇs´ı oba k´ ody zahodit a napsat je jednoduˇseji. Pomoc´ı refaktorizace se zdrojov´ y kód zjednoduˇs´ı a zefektivn´ı a totéˇz plat´ı i pro testovac´ı k´ od. Kent Beck upozorˇ nuje, ˇze nové funkce se p´ıˇsou pouze tehdy, kdyˇz pro nˇe selhal automatizovan´ y test. Podle nˇej také maj´ı b´ yt eliminov´ any veˇskeré duplicity. [ 25 ]. 4. Spust´ı se vˇsechny ostatn´ı testy (nebo jejich podmnoˇzina). Pokud neprojdou, je nutné upravit zdrojov´ y k´ od. 5. Provedou se potˇrebné u ´pravy testovac´ıch pˇr´ıpad˚ u i zdrojového k´ odu a odstran´ı se pˇr´ıpadné duplicity. Testovac´ı pˇr´ıpad se pˇresune do knihovny test˚ u spouˇstˇen´ ych automaticky.

3.7.4

Z´ avˇ er

Kód projektu stvoˇren´ y podle TDD m´ a velmi pˇrehlednou a dobrou strukturu d´ıky jeho testovatelnosti a odstranˇen´ı duplicit. Testy se tedy p´ıˇsou lépe, kdyˇz uˇz je zdrojov´ y kód hotov´ y, ˇclovˇek m´ a lepˇs´ı pˇredstavu o tom, co testovat [ 22 ]. Avˇsak je logické, ˇze pˇri opaˇcném postupu se o to lépe p´ıˇse zdrojov´ y kód, coˇz je d˚ uleˇzit´ a v´ yhoda TDD. Metodika je obl´ıben´ a, svˇedˇc´ı o tom

´ Í AGILNÍCH METODIK 3.8. POROVNAN

43

napˇr´ıklad fakt, ˇze lidé chtˇej´ı TDD vyuˇz´ıvat co nejlépe a pˇrizp˚ usobit ji vlastn´ım potˇreb´ am. Je tak dostupná podpora TDD d´ıky ˇsirokému spektru jednotkov´ ych test˚ u (xUnit tests). Vznikaj´ı také r˚ uzné odnoˇze - napˇr´ıklad Storytest driven development (STDD) [ 24 ]. Jde o propojen´ı FDD a TDD, kde se na zaˇc´ atku nep´ıˇsou testy pro jakoukoliv ˇcást kódu, ale definuje se vlastnost. Vytvoˇr´ı se testy pro ni a d´ ale se pokraˇcuje jako u TDD. Testov´ an´ı je jedna z nejznámˇejˇs´ıch a nejviditelnˇejˇs´ıch sloˇzek zabezpeˇcen´ı kvality (QA). Kritici TDD vˇsak tvrd´ı, ˇze v´ıce chyb se d´ a efektivnˇe naj´ıt jin´ ymi sloˇzkami QA jako revize návrh˚ u nebo strukturované proch´ azen´ı. Na jedné studii ukazuj´ı, ˇze kvalita projektu jen pomalu roste s mnoˇzstv´ım napsan´ ych test˚ u nez´ avisle na pouˇzité strategii v´ yvoje [ 23 ]. Nezáleˇz´ı na tom, jestli se testy nap´ıˇsou dˇr´ıve, nebo pozdˇeji neˇz zdrojov´ y kód. Existuje silnˇejˇs´ı korelace mezi mnoˇzstv´ım napsan´ ych test˚ u a produktivitou t´ ymu pˇri testov´ an´ı aˇz po dopsán´ı zdrojového kódu. Metodika nepokr´ yv´ a vˇsechny v´ yvojové f´ aze. Napˇr´ıklad nejde pouˇz´ıt na celkov´ y design velk´ ych projekt˚ u, n´ avrh uˇzivatelského rozhran´ı.

3.8

Porovn´ an´ı agiln´ıch metodik

Na tomto m´ıstˇe rozeberme, v ˇcem se liˇs´ı jednotlivé agiln´ı metodiky a na co se která metodika hod´ı. Kaˇzdému v´ yvojovému t´ ymu vyhovuje jin´ a charakteristika zp˚ usobu pr´ ace. Necht’ je moˇzné podle této kapitoly urˇcit, která metodika je nejvhodnˇejˇs´ı pro dan´ y t´ ym lid´ı. Kritéria jsou seˇrazena podle pˇredpokl´ adané d˚ uleˇzitosti.

3.8.1

Velikost t´ ym˚ u a projekt˚ u

Nejvˇetˇs´ı t´ ymy jdou ˇr´ıdit jen podle Scrum, avˇsak metodika je vhodn´ a i pro malé. Nejvˇetˇs´ı t´ ym, se kter´ ym jsem se setkal bˇehem pr˚ uzkumu, je sloˇzen ze dvou set v´ yvoj´ aˇr˚ u ˇr´ızen´ ych podle Scrum. Nˇekteré informaˇcn´ı zdroje [ 11 ] uvád´ı, ˇze t´ ymy sloˇzené z klastr˚ u klastr˚ u Scrum t´ ym˚ u m´ıvaj´ı aˇz pˇet set ˇclen˚ u. Také TDD se hod´ı i pro velké projekty. XP je vhodné pro malé t´ ymy do deseti ˇclen˚ u.

3.8.2

N´ aroˇ cnost na zaveden´ı a provoz

Agiln´ı metodiky jsou obecnˇe n´ aroˇcné na kvalitu ˇclen˚ u t´ ymu. Zjistil jsem, ˇze nejnároˇcnˇejˇs´ı je XP. Setkal jsem se s jedin´ ym v´ yjimeˇcn´ ym pˇr´ıkladem jeho zaveden´ı. Práci upravuje mnoˇzstv´ım pravidel. Ta sice vych´ azej´ı z pˇrirozen´ ych princip˚ u, ale pˇresto se na nˇekter´ a tˇeˇzko zvyk´ a, pˇrestoˇze Nároˇcnost se t´ yk´ a jak program´ ator˚ u, tak manaˇzer˚ u. U Scrum je na prvn´ı pohled zˇrejmé, ˇze se zavád´ı snadno. Je pomˇernˇe rozˇs´ıˇren´ y a také


44

d´ av´ a prostor t´ ymu pro vlastn´ı zp˚ usob práce. Konkrétn´ı poˇzadavky se net´ ykaj´ı ˇclen˚ u t´ ymu, jen manaˇzer˚ u. T´ ym se má organizovat s´ am. V tomto ohledu je Scrum protikladem TDD, které ned´ av´ a ˇzádné u ´koly manaˇzer˚ um. Ovˇsem je tˇeˇzké naj´ıt do t´ ymu Scrum vhodné lidi, kteˇr´ı um´ı metodiku efektivnˇe vyuˇz´ıt. Co zav´ ad´ı Lean development nav´ıc oproti tradiˇcn´ım pˇr´ıstup˚ um je pˇrirozená efektivita v´ yvoje, které softwarové spoleˇcnosti ˇcasto dosahuj´ı i bez zaveden´ı této metodiky. Vzhledem k pˇrirozenosti pravidel je nenároˇcn´ a. Avˇsak pokud uˇz nˇekdo chce programovat agilnˇe, vˇetˇsinou uplatn´ı jinou metodiku. Snadno se zav´ ad´ı, nebot’ nepˇrikazuje postupovat nijak nepˇrijateln´ ym zp˚ usobem. Doporuˇcuje jen ˇradu pravidel, jinak ponech´ avá v´ yvoj´ aˇr˚ um volnost v ˇcinnosti. Lean nen´ı ne´ uspˇeˇsná metodika, neˇz si na ni t´ ym zvykne. Napˇr´ıklad ˇr´ızen´ı projektu jen ˇcásteˇcnˇe pomoc´ı XP vede k v´ ysledk˚ um velmi ˇspatn´ ym. FDD je nen´ aroˇcná metodika, snadno se na ni zvyká, v´ yvojov´ y proces se j´ı d´ a dobˇre pˇrizp˚ usobit. Spoˇc´ıv´ a pouze v pˇeti z´ akladn´ıch procesech (vytvoˇren´ı glob´ aln´ıho modelu, vypracov´ an´ı podrobného seznamu vlastnost´ı, pl´ anován´ı podle vlastnost´ı, návrh podle vlastnost´ı, implementace podle vlastnost´ı).

3.8.3

M´ıra omezen´ı pravidly

Nejstriktnˇejˇs´ı pravidla poˇzaduje XP. Je jich dvan´ act, coˇz je mnoho. Nejménˇe základn´ıch pouˇcek zavád´ı FDD. Je jich jen pˇet - objektové modelov´ an´ı, v´ yvoj podle vlastnost´ı, t´ ymy sestavované podle vlastnost´ı, vlastnictv´ı tˇr´ıd a pr˚ ubˇeˇzné inspekce.

3.8.4

Rozˇ s´ıˇ renost

XP je rozˇs´ıˇrené hlavnˇe v Americe. V naˇsich oblastech jsem si vˇsimnul sp´ıˇse s odm´ıtavého pˇr´ıstupu. Nejˇcastˇeji jsem se setkal se Scrum, pˇr´ıpadnˇe se Scrum kombinovan´ ym s FDD.

3.8.5

Pˇ rijatelnost pro z´ akazn´ıka

XP je velmi nároˇcné nejen pro softwarovou spoleˇcnost, ale i pro z´ akazn´ıka. Pˇrikazuje mu, aby byla pˇr´ımo jeho osoba, nˇekdy dvˇe v prostˇred´ı softwarové spoleˇcnosti po celou dobu v´ yvoje. FDD vyˇzaduje z´ akazn´ıkovu aktivn´ı u ´ˇcast jen bˇehem u ´vodn´ı fáze. Podle Scrum se m´ a klient dostavit po kaˇzdém sprintu. Jinak metodiky samozˇrejmˇe nut´ı klienty pr˚ ubˇeˇznˇe kontrolovat ˇcinnost, ale kromˇe XP je moˇzn´ a komunikace na dálku.

3.8.6

Zajiˇ stˇ en´ı kvality (quality assurance)

Rozd´ıly dané t´ımto kritériem snad nejv´ıce ovlivˇ nuj´ı v´ ysledek a n´ aroˇcnost dosaˇzen´ı jeho kvality. Názory na pˇredch´ azen´ı chyb´ am v pr˚ ubˇehu implementace se r˚ uzn´ı. Mezi hlavn´ı metody patˇr´ı jed-

´ Í AGILNÍCH METODIK 3.8. POROVNAN

45

notkové testy a defenzivn´ı programov´ an´ı, pˇri kterém se napˇr´ıklad kontroluj´ı vstupn´ı parametry metody, jejichˇz nespr´ avnost vyvol´ a v´ yjimku. Vloˇzen´ı defenzivn´ıho kódu do metody je jednoduˇsˇs´ı, neˇz pokr´ yt vˇsechny pˇr´ıpady jednotkov´ ym testem. Ten jen prok´ aˇze, ˇze v kódu je chyba, ale jej´ı absenci nezaruˇc´ı t´ım, ˇze probˇehne s kladn´ ym v´ ysledkem. Defenzivn´ı programov´ an´ı naopak prokazuje bezchybnost dané ˇcásti k´ odu. Také napˇr´ıklad umoˇzn ˇuje okamˇzitˇe naj´ıt m´ısto, kde reference ukazuje na null nebo na hodnotu mimo oˇcekávan´ y rozsah. Odp˚ urc˚ um jednotkov´ ych test˚ u vad´ı, ˇze jejich produkce zab´ır´ a ˇcas [ 22 ]. Pˇritom je ale dobré si uvˇedomit, jak´ y n´ azor m´ a Jeff De Luca, spoluautor FDD [ 20 ]: ”Jednotkov´ y test nen´ı nˇeco nav´ıc, co nem´ a nic spoleˇcného s implementac´ı. Tvorba jednotkového testu pˇred implementac´ı vlastnosti jednoduˇse nut´ı pˇrem´ yˇslet pˇredem.”Jin´ı v´ yvoj´ aˇri jsou pˇresvˇedˇcen´ı o tom, ˇze defenzivn´ı programov´ an´ı zdrˇzuje bˇeh programu a s pomoc´ı jednotkov´ ych test˚ u jdou odhalit vˇsechny d˚ uleˇzité chyby. Jejich pouˇzit´ı podle nich nen´ı ˇcasovˇe nároˇcnˇejˇs´ı na tvorbu, protoˇze uˇsetˇr´ı ˇcas pˇri implementaci. Nesporn´ a v´ yhoda jednotkov´ ych test˚ u je zˇretelnost, ˇze je kód správn´ y. Ujiˇst’uj´ı v´ yvoj´ aˇre o kvalitˇe a spolehlivosti jeho k´ odu a ukazuj´ı aktuáln´ı stav a pokrok projektu. O nˇem se d´ a ˇr´ıci, ˇze je stoprocentnˇe otestovan´ y a tak m˚ uˇze b´ yt pouˇzit pro rizikové projekty, jejichˇz selh´ an´ı m˚ uˇze m´ıt niˇcivé n´ asledky. Zároveˇ n jejich naps´ an´ım test˚ u pˇred vlastnostmi definujeme rozhran´ı metody, které je pak moˇzné otestovat dˇr´ıv, neˇz vznikne celé tˇelo metody. TDD nepoˇzaduje defenzivn´ı programován´ı. FDD vˇsak doporuˇcuje kombinaci obou metod, coˇz m˚ uˇze vypadat neefektivnˇe. Avˇsak nejde o pˇredch´ azen´ı stejn´ ym chyb´ am dvˇema zp˚ usoby. Je zˇrejmé, ˇze jednotkov´ y test k metodˇe pˇristupuje jako k ˇcerné skˇr´ıˇ nce a kontroluje tedy pouze vstupy a v´ ystupy. Neodhal´ı tedy chyby v podobˇe pˇreteˇcen´ı pamˇeti, nepovedené integrace, poˇskozen´ı dat v pamˇeti, zablokov´ an´ı vláken nebo chyby v uˇzivatelském rozhran´ı [ 23 ]. Pokud vˇsak v´ yvoj´ aˇri pr˚ ubˇeˇznˇe integruj´ı nov´ y k´ od, vzniklé integraˇcn´ı problémy také brzy odhal´ı. Velká nev´ yhoda testován´ı je, ˇze nen´ı pouˇzitelné v pˇr´ıpadech, ˇze sestaven´ı projektu trvá dlouho. Zpˇetná vazba mus´ı b´ yt rychl´ a. Kromˇe tˇechto dvou metod se chybám pˇredch´ az´ı dalˇs´ımi zp˚ usoby. Pˇri postupu podle FDD se snadno kontroluje správnost chov´ an´ı aplikace zkoumán´ım vlastnost´ı jako základn´ıch stavebn´ıch kamen˚ u. Lean pˇredkl´ ad´ a c´ıle a hodnoty, kter´ ych se má softwarová spoleˇcnost drˇzet a m˚ uˇze jednoznaˇcnˇe poznat, jestli se ub´ır´ a správn´ ym smˇerem. Hlavn´ı vˇec´ı je spolupr´ ace s klientem. V´ yvojáˇri pracuj´ıc´ı podle jin´ ych metodik si mohou jen myslet, co je pro nˇe d˚ uleˇzité. Lean nut´ı manaˇzery pˇripravit t´ ym na vˇsechny komplikace, které mohou nastat, nebo jim pˇredch´ azet hlavnˇe zmˇena zad´ an´ı, prodraˇzen´ı projektu zbyteˇcn´ ymi ztr´ atami, nev´ yhodné subdod´ avky od partner˚ u atd. Scrum zase zav´ ad´ı anal´ yzu rizik na konci kaˇzdé iterace. Dennˇe se odhaluj´ı rizika souvisej´ıc´ı se zmˇenami. Podle XP se má kvalita zajiˇst’ovat v´ıce zp˚ usoby. Jsou to revize a kontroly, testován´ı nˇekolikr´ at dennˇe a párové programov´ an´ı. Rozdˇelen´ı metodik podle oblasti, kterou specifikuj´ı Postupov´ an´ı manaˇzer˚ u a u ´vodn´ı fáze projektu definuj´ı metodiky XP, Scrum a FDD. Práci


46

v´ yvojáˇr˚ u a fáze implementace popisuje XP, FDD a TDD. Lean vyd´ avá pouze sadu pravidel, jejichˇz dodrˇzen´ım dos´ ahneme urychlen´ı, zlevnˇen´ı a sn´ıˇzen´ı chybovosti produktu.

3.8.7

Kombinace metodik

V pˇr´ıpadˇe kombinován´ı metodik je Scrum ˇcasto jedna z nich. Druh´ a b´ yv´ a nˇekter´ a z tˇech, které zav´ ad´ı pravidla pro ˇcleny t´ ymu, tedy ne pro manaˇzery. Setkal jsem se s kombinacemi XP a Scrum nebo FDD a Scrum. XP vlastnˇe jde dobˇre kombinovat s jakoukoliv metodikou. Projekt, kter´ y je jako celek ˇr´ızen urˇcitou metodikou, se dekomponuje na podproblémy. Pouˇzije se následuj´ıc´ı algoritmus: Najde se nejz´ avaˇznˇejˇs´ı problém a ˇreˇs´ı se pomoc´ı XP tak dlouho, dokud je nejzávaˇznˇejˇs´ı. Pak se postup opakuje. Do FDD jde snadno vˇclenit TDD. To znamen´ a pouze pˇridat nové pravidlo do FDD, a sice psát jednotkové testy ve ˇctvrté f´ azi n´ avrh podle vlastnost´ı. FDD pˇredepisuje pouze pouˇzit´ı jednotkov´ ych test˚ u v p´ até f´ azi implementace podle vlastnost´ı, avˇsak nez´ aleˇz´ı na poˇrad´ı psan´ı test˚ u a kódu.

3.8.8

Truck factor

Truck factor je pojem zaveden´ y XP a jeho hodnota vyjadˇruje poˇcet lid´ı, kteˇr´ı se orientuj´ı v jedné ˇcásti k´ odu. Nejvyˇsˇs´ı maj´ı projekty ˇr´ızené podle XP, o veˇskerém kódu maj´ı pˇrehled vˇsichni. Scrum a FDD zav´ ad´ı vlastnictv´ı k´ odu, o jedné tˇr´ıdˇe má pˇrehled pouze jeden ˇclovˇek a truck factor je jedna. Avˇsak pˇri FDD jednotlivé metody tˇr´ıdy pouˇz´ıv´ a prakticky cel´ y t´ ym a ˇcasto je truck factor vyˇsˇs´ı neˇz 1.

3.8.9

Psan´ı nadbyteˇ cn´ eho k´ odu

Jak´ akoliv pr´ ace, která nen´ı vyslovenˇe nezbytn´ a, se obecnˇe vymyk´ a agiln´ımu v´ yvoji. Obzvláˇst’ Lean povaˇzuje za neˇza´dané pl´ ytván´ı tvoˇren´ı kaˇzdého kódu, kter´ y se nedoruˇc´ı zákazn´ıkovi [ 8 str. 4 ]. Nabádá k tomu, abychom se za kaˇzdou cenu vyhnuli psan´ı k´ odu, kter´ y nakonec nepouˇzijeme. XP tvrd´ı, ˇze se takov´ ym situac´ım nedá vyhnout, a proto nem´ a cenu ztrácet energii snahou jim pˇredch´ azet. TDD nut´ı program´ atory psát velké mnoˇzstv´ı test˚ u, které z´ akazn´ık pˇr´ımo nepotˇrebuje. Avˇsak Lean nem˚ uˇze ˇr´ıct, ˇze jde o pl´ ytván´ı, protoˇze v´ ysledn´ y produkt z´ıskává na hodnotˇe d´ıky kvalitn´ımu otestov´ an´ı. TDD také doporuˇcuje zahodit zdrojov´ y i testovac´ı kód v pˇr´ıpadˇe, ˇze zdrojov´ y kód nejde v kr´ atké dobˇe upravit tak, aby proˇsel testem. Dobˇre propracovan´ y zp˚ usob, jak nepsat zbyteˇcn´ y k´ od a z´ aroveˇ n nezapomenout na d˚ uleˇzité ˇcásti m´ a FDD. Pˇredepisuje dod´ avky vlastnost´ı, které maj´ı hodnotu pro z´ akazn´ıka, ˇc´ımˇz je zaruˇcena hodnota celého produktu.

ˇ ÍZENÍ PROJEKTU ˚ V PRAXI 3.9. R

3.8.10

47

Dokumentace

Pokud se program´ atoˇri potˇrebuj´ı sezn´ amit s nˇejak´ ym zdrojov´ ym k´ odem, ˇcasto si nejdˇr´ıve prohlédnou uk´ azkov´ y k´ od, kter´ y vol´ a metody, poté tˇela metod a jen v´ yjimeˇcnˇe ˇctou dokumentaci - pokud existuje. Dokud nen´ı projekt cel´ y pˇredan´ y, dokumentovalo by se j´ı nˇeco nestálého, nˇeco neust´ ale promˇenlivého. Dokumentace by se stala neplatnou a tud´ıˇz pro zákazn´ıka bezcennou. Proto se tvorba dokumentace povaˇzuje za nadbyteˇcnou práci aˇz do chv´ıle, kdy ji pˇr´ımo poˇzaduje z´ akazn´ık. Agiln´ı metodiky varuj´ı pˇred psan´ım dokumentace. Pˇresnˇe takov´ ym uk´ azkov´ ym k´ odem, jako je o nˇem ˇreˇc v´ yˇse, m˚ uˇze b´ yt dobˇre napsan´ y jednotkov´ y test [tdd/1]. Pˇri v´ yvoji podle TDD tedy vznik´ a ˇziv´ a dokumentace jako vedlejˇs´ı produkt - v podobˇe testovac´ıho k´ odu. Testovac´ı pˇr´ıpady ukazuj´ı, jak pouˇz´ıvat testovan´ y k´ od. Poskytuj´ı velmi pˇresné informace v pˇrehledné formˇe. Avˇsak kaˇzd´ y si neum´ı zvyknout na pouˇz´ıván´ı test˚ u jako formu dokumentace [ 23 ]. XP upozorˇ nuje, ˇze pr´ avˇe zdrojov´ y kód je to, co ”dokumentuje”projekt. Kaˇzd´ y ˇclen v t´ ymu se v projektu orientuje jen podle nˇej. Z´ aroveˇ n je potˇreba nahradit dokument specifikace poˇzadavk˚ u dialogem, d˚ uvˇerou a moˇznost´ı zmˇen.

3.8.11

Spoleˇ cn´ e vlastnosti

Pˇri peˇclivˇejˇs´ım studiu agiln´ıch metodik si ˇclovˇek vˇsimne následuj´ıc´ıch poznatk˚ u. Vˇsechny se snaˇz´ı pˇrimˇet v´ yvoj´ aˇre k pˇr´ımoˇcarému postupu k c´ıli bez jakéhokoliv zatˇeˇzov´ an´ı se formalitami. Poˇzaduj´ı iterativn´ı, inkrement´ aln´ı v´ yvoj, jehoˇz v´ yhody uˇz byly pops´ any. Vˇetˇsinou povaˇzuj´ı za nejlepˇs´ı, pokud jsou iterace co nejkratˇs´ı. Metodiky nepopisuj´ı pˇresn´ y pr˚ ubˇeh procesu. Nedefinuj´ı ˇzádné konkrétn´ı kroky, jak vyv´ıjet software. Co popisuj´ı nebo sp´ıˇs ukazuj´ı, je zp˚ usob veden´ı projektu. Poskytuj´ı urˇcit´ y souhrn vzor˚ u a pravidla, která pom´ ahaj´ı progresivn´ımu v´ yvoji. Nˇekter´ a pravidla jsou ˇspatnˇe pochopiteln´ a nebo aplikovateln´ a v praxi, dokud si na nˇe ˇclovˇek nezvykne. Kv˚ uli nim se nehod´ı do t´ ymu kaˇzd´ y ˇclovˇek, protoˇze kaˇzd´ y nedok´ aˇze aplikovat metodiky efektivnˇe. Naproti tomu je v agiln´ım v´ yvoji prostor pro pˇrizp˚ usoben´ı metodik pro dan´ y t´ ym a pro u ´pravy postup˚ u, coˇz tradiˇcn´ı metodiky u ´plnˇe neschvaluj´ı. Avˇsak toto m˚ uˇze b´ yt br´ ano jako pozitivum i jako negativum, nebot’ se manaˇzer mus´ı zab´ yvat t´ım, jak metodiku zavést.

3.9

ˇ ızen´ı projekt˚ R´ u v praxi

Bˇehem pr˚ uzkumu zvyklost´ı projektov´ ych manaˇzer˚ u a technik v´ yvoje software jsem doˇsel k v´ ysledk˚ um, z nichˇz nˇekteré jsem jiˇz zaznamenal do pˇredchoz´ıch kapitol. Ostatn´ı zm´ın´ım zde. Zamˇeˇril jsem se na softwarové spoleˇcnosti, jejichˇz v´ yvojové t´ ymy m´ıvaj´ı ménˇe neˇz dvacet pˇet


48

ˇclen˚ u. V tomto rozmez´ı jsem rozliˇsoval mezi menˇs´ımi a vˇetˇs´ımi firmami podle poˇcetnosti t´ ymu. Stanovil jsem mez deset ˇclen˚ u. Vˇetˇs´ı firmy nejˇcastˇeji aplikuj´ı konkrétn´ı vˇseobecnˇe známé metodiky tradiˇcn´ı nebo agiln´ı. Nˇekdy se jim osvˇedˇcuj´ı obˇe moˇznosti v z´ avislosti na velikosti aktu´ aln´ıho projektu. U menˇs´ıch softwarov´ ych spoleˇcnost´ı nejsou agiln´ı metodiky pˇr´ıliˇs ˇcasté. Z deseti osloven´ ych mal´ ych firem je zavedly jen tˇri. Jedna firma uˇz´ıv´ a tradiˇcn´ı techniky a ostatn´ı se spoléhaj´ı na své vlastn´ı metody, pˇr´ıpadnˇe se zcela obejdou bez definovan´ ych postup˚ u. Bl´ıˇze jsem se setkal jen se dvˇema firmami s v´ yvojov´ ym t´ ymem poˇcetnˇejˇs´ım neˇz dvacet pˇet. V´ yvoj ˇr´ıd´ı bud’ agiln´ımi, nebo vlastn´ımi metodikami.

3.9.1

Agiln´ı metodiky

Agiln´ı metodiky jsou zˇrejmˇe vhodné hlavnˇe pro stˇrednˇe velké projekty. Jejich principy se pouˇz´ıvaj´ı jen zˇr´ıdka pro projekty, které zadán´ım nepˇresahuj´ı délku jedné iterace. Hod´ı se naopak pro rozsáhlejˇs´ı systémy, ve kter´ ych má smysl práci rozdˇelovat do v´ıce iterac´ı. Avˇsak pro pˇr´ıliˇs komplexn´ı problémy nejsou agiln´ı metodiky vhodné. T´ ymy o velikosti des´ıtek ˇclen˚ u nejdou ˇr´ıdit agilnˇe s v´ yjimkou Scrum. Pro takové projekty se naopak hod´ı nˇekteré tradiˇcn´ı metodiky, pˇr´ıkladem je RUP a také jsem se dozvˇedˇel o ménˇe známé PRINCE 2. Z jednotliv´ ych technik je nejpouˇz´ıvanˇejˇs´ı Scrum. Zˇrejmˇe jde o d˚ usledek toho, ˇze je pˇr´ıstupná a nezav´ ad´ı ˇza´dn´ a extrémn´ı pravidla jako párové programov´ an´ı nebo jednotkové testov´ an´ı veˇskerého kódu. Naopak denn´ı setk´ av´ an´ı je z´ asada, kterou pracovn´ıci ochotnˇe pˇrij´ımaj´ı. Napˇr´ıklad jim uˇsetˇr´ı mnoˇzstv´ı textu napsaného pˇri komunikaci na dálku a umoˇzn´ı snadno ˇreˇsit problémy. ˇ e republiky jsou ˇceské poboˇcky spoleˇcnost´ı CA Pˇr´ıklady zaveden´ı této metodiky na u ´zem´ı Cesk´ Technologies a ZOOM International. Nesetkal jsem se s pˇr´ıkladem aplikace Lean.

3.9.1.1

V´ yhody, kter´ ych si firmy nejv´ıc cen´ı

Mezi v´ yhody, kter´ ych si firmy nejv´ıc cen´ı, patˇr´ı rychlost a efektivita v´ yvoje. Také jeho kvalita, která je zaruˇcena precizn´ı architekturou a testován´ım. Chybovost je pak n´ızk´ a.

3.9.1.2

Nev´ yhody, kter´ e firm´ am nejv´ıc vad´ı

Naopak nejv´ıc vad´ı, ˇze pˇredem nen´ı pˇresnˇe znám´ y v´ ysledek. Tedy bud’ nen´ı stanovena doba v´ yvoje a t´ım ani cena projektu, nebo je nejistá ˇs´ıˇre funkˇcnosti. V praxi totiˇz nen´ı snaha dodrˇzet definovan´ y ˇcas a urˇcené n´ aklady, jako pˇredepisuje teorie agiln´ıho programov´ an´ı. Typicky tedy klient nerad akceptuje pˇr´ıstup, kter´ y vycház´ı z nemoˇznosti pˇredem domluvit pˇresné podm´ınky. Mnoho z´ akazn´ık˚ u dok´ aˇze v´ yvoj softwaru povaˇzovat jedinˇe za definovan´ y proces, coˇz odporuje agiln´ımu pojet´ı.

ˇ ÍZENÍ PROJEKTU ˚ V PRAXI 3.9. R

3.9.2

49

Ostatn´ı zp˚ usoby ˇ r´ızen´ı projekt˚ u

Vˇetˇsina spoleˇcnost´ı, které nepouˇz´ıvaj´ı agiln´ı metodiky, si vytvoˇrila vlastn´ı metody. V souladu s agiln´ım v´ yvojem d´ avaj´ı pˇrednost osobn´ı komunikaci mezi ˇcleny t´ ymu. V´ yvoj obvykle prob´ıh´ a iterativnˇe nebo po jin´ ych ˇc´ astech tak, aby zákazn´ık pr˚ ubˇeˇznˇe mohl sledovat v´ yvoj.

50


Kapitola 4

Z´ avˇ er Pˇri zkoum´ an´ı zkuˇsenost´ı expert˚ u ve v´ yvoji software jsem v prvn´ı ˇradˇe oslovil vˇsechny, které znám. Na dalˇs´ı jsem vyhledal témˇeˇr sto kontakt˚ u na internetu podle kl´ıˇcov´ ych slov softwarov´ a ” spoleˇcnost“ a softwarov´ a firma“. Poslal jsem jim e-mailem dotazn´ık k vyplnˇen´ı. Odpovˇedi ” zaˇcaly pˇrich´ azet, aˇz kdyˇz jsem se dovolal asi ˇctyˇriceti z nich. Vˇsech odpovˇed´ı na dotazn´ıky bylo jen m´ alo pˇres dvacet. Dalˇs´ı potˇrebné informace jsem vyhledal na diskuzn´ıch f´ orech na internetov´ ych str´ ank´ ach, které jsou uvedeny v seznamu literatury. Jednotlivé metodiky jsem v pˇredeˇslém textu zhodnotil z r˚ uzn´ ych u ´hl˚ u pohledu. Nyn´ı vyzdvihnu nˇekteré z nich jako dominantn´ı z´ astupce z nˇekolika hledisek. Jako nej´ uˇcinnˇejˇs´ı agiln´ı metodika se mi jev´ı XP, avˇsak jen do té doby, dokud je t´ ym schopn´ y ji zvládat. Za kl´ıˇcov´ y omezuj´ıc´ı faktor povaˇzuju povinnost kaˇzdého ˇclena t´ ymu udrˇzet pˇrehled o veˇskerém zdrojovém k´ odu v projektu. Rozhodnˇe se hod´ı jen pro v´ yvojové t´ ymy, které jiˇz maj´ı zkuˇsenosti s agiln´ım pˇr´ıstupem. Scrum je metodika, kter´ a pˇrin´ aˇs´ı nejménˇe netradiˇcn´ıch postup˚ u. Zˇrejmˇe proto patˇr´ı k nejrozˇs´ıˇrenˇejˇs´ım. Proto ji m˚ uˇzeme doporuˇcit kaˇzdému t´ ymu, kter´ y zaˇc´ıná s agiln´ım ˇr´ızen´ım projekt˚ u. Jednoznaˇcnˇe nejjednoduˇsˇs´ı pracovn´ı postup definuje vodop´ adov´ y model. Pro svou jednoduchost a také prvenstv´ı ve vzniku stále patˇr´ı k nejrozˇs´ıˇrenˇejˇs´ım. Projekty nˇekter´ ych v´ yvoj´ aˇr˚ u jsou tak malé, ˇze se pr´ y jejich tv˚ urc˚ um nevyplat´ı ˇr´ıdit se nˇejakou metodikou. Avˇsak jejich pr´ aci lze velmi bl´ızce charakterizovat právˇe vodopádov´ ym modelem. Jako nejjednoduˇsˇs´ı a nejpˇrehlednˇejˇs´ı agiln´ı metodika se jev´ı FDD. Postupuje po podobné sekvenci jako vodop´ adov´ y model, avˇsak na jej´ım konci se postupuje iterativnˇe. Jak uˇz v´ıme, oproti vodop´ adu se zde zav´ ad´ı mnoh´ a dalˇs´ı pravidla - napˇr´ıklad modelov´ an´ı podle domén. TDD je metodika, jej´ıˇz pravidla se nejménˇe dodrˇzuj´ı. Dosud jsem nenarazil na v´ yvoj´ aˇre, kter´ y by mˇel otestvan´ y kaˇzd´ y ˇrádek zdrojového kódu. Narozd´ıl od XP TDD nepˇrináˇs´ı tak negativn´ı v´ ysledky, pokud se jeho pravidla zcela nedodrˇzuj´ı, takˇze neodrad´ı od pouˇzit´ı hned od zaˇcátku. 51

´ ER ˇ KAPITOLA 4. ZAV

52

Nejvˇetˇs´ı a nejsloˇzitˇejˇs´ı projekty lze ˇr´ıdit podle metodik RUP a Scrum of scrum. Pokud projektov´ y manaˇzer t´ ymu pro velmi rozs´ ahl´ y projekt nedok´ azal v´ yvoj uˇr´ıdit pomoc´ı Scrum of scrum m˚ uˇze projekt bud’ dekomponovat nebo vést podle RUP. Je vidˇet, ˇze agiln´ımi metodikami lze pokr´ yt ˇcinnost jen omezeného mnoˇzstv´ı v´ yvojov´ ych t´ ym˚ u. Pokud jsou velmi malé a ˇc´ıtaj´ı tˇreba jen 3 ˇcleny, je pravdˇepodobné, ˇze pouˇzij´ı bud’ nˇekter´ y tradiˇcn´ı nebo zcela nedefinovan´ y postup. Naopak pˇr´ıliˇs velké projekty v souˇcasnosti ned´ avaj´ı prostor pro flexibilitu a ˇcasto se mus´ı v rozporu s agiln´ım pˇr´ıstupem definovat striktn´ı pravidla. Agiln´ı metodiky jsou tedy pˇr´ıstupné hlavnˇe v pˇr´ıpadech, kde produkt nevyv´ıj´ı ani málo ani mnoho lid´ı. Avˇsak je ot´ azka do budoucnosti, jestli se agiln´ı metodiky otevˇrou i pro vˇetˇs´ı projekty, jako to dˇel´ a Scrum, nebo jestli ˇcasem bude nutné je nahradit zase jin´ ym pˇr´ıstupem.

Literatura ´ clav Kadlec (2004), Agiln´ı programov´ Va an´ı, Brno: Vydavatelstv´ı Computer Press. 1. Rational Software Corporation: Rational Unified Process, Best Practices for Software Development Teams http://www.augustana.ab.ca/~mohrj/courses/2000.winter/csc220/ papers/rup_best_practices/rup_bestpractices.pdf 2. R. Max Wideman P.Eng.: Webové stránky projektového manaˇzera http://www.maxwideman. com/papers/linearity/waterfall.htm 3. Manifest agiln´ıho v´ yvoje softwaru vydan´ y autory agiln´ıch metodik (http://www.agilemanifesto.org/) ˇ anky na webu vˇenovanému extrémn´ımu programov´ 4. Don Wells: Cl´ an´ı http://www.extremeprogramming.org/ ˇ anky na webu vˇenovanému agiln´ımu programov´ 5. Bill Wake: Cl´ an´ı http://xp123.com/ 6. Lee Copeland: Extreme Programming http://www.computerworld.com/s/article/66192/Extreme_Programming?taxonomyId= 063 7. Webov´ a publikace autor˚ u Lean development http://www.poppendieck.com/ - odstavec Create Pull and Flow 8. Mary Poppendieck: Principles of Lean Thinking www.poppendieck.com/papers/LeanThinking.pdf 9. V´ aclav Kadlec: Agiln´ı programov´ an´ı 10. Introduction to Scrum, An Agile Process - Popis metodiky Scrum na webov´ ych stránk´ ach spoleˇcnosti Mountain Goat Software http://www.mountaingoatsoftware.com/ 53

LITERATURA

54

11. Popis metodiky Scrum na webov´ ych stránk´ ach organizace Scrum Alliance

http://www.scrumalliance.org/articles/46-advice-on-conducting-the-scrum-of-scrums-meeting 12. The Classic Story of the Pig and Chicken http://www.implementingscrum.com/2006/09/11/the-classic-story-of-the-pig-and-chicken/ 13. Ken Schwaber, Jeff Sutherland: SCRUM http://www.scrum.org/storage/scrumguides/Scrum%20Guide.pdf#view=fit ˇ anky na webu vˇenované Scrum 14. Cl´ http://www.sprintplanning.com/SprintPlanningRules.aspx ˇ anky o FDD na webu spoleˇcnosti Nebulon Pty. Ltd. Jeff De Luca: Cl´ 15. http://www.nebulon.com/fdd/index.html 16. http://www.nebulon.com/articles/fdd/originalfdd.html 17. http://www.nebulon.com/articles/fdd/latestfdd.html 18. http://www.nebulon.com/articles/fdd/download/fddprocessesUSLetter.pdf Diskusn´ı fórum pro autory i uˇzivatele FDD 20. http://www.featuredrivendevelopment.com/node/768 21. http://www.featuredrivendevelopment.com/node/617 22. http://www.featuredrivendevelopment.com/node/566 23. Magaz´ın o v´ yvoji softwaru http://www.methodsandtools.com/archive/archive.php?id=19 24. Peter Coad, Eric Lefebvre, Jeff De Luca: Java Modeling In Color With UML ˇ anky o agiln´ıch technik´ 25. Scott W. Ambler: Cl´ ach na webu hlavn´ıho metodika spoleˇcnosti IBM http://www.agiledata.org/essays/tdd.html Magaz´ın o v´ yvoji softwaru 20. http://www.methodsandtools.com/archive/archive.php?id=20 21. http://www.methodsandtools.com/archive/archive.php?id=59 ˇ anek na webu zamˇeˇreném na v´ 22. Jacob Proffitt: Cl´ yvoj softwaru http://theruntime.com/ blogs/jacob/archive/2008/01/22/tdd-proven-effective-or-is-it.aspx

LITERATURA

55

ˇ anky manaˇzera v Microsoftu http://haacked.com/archive/2008/01/22/ 23. Phil Haack: Cl´ research-supports-the-effectiveness-of-tdd.aspx 24. Tracy Reppert: Storytest-driven development is an extreme programming practice http: //industriallogic.com/papers/storytest.pdf

56

LITERATURA

Pˇ r´ıloha A

Popis ˇ cinnosti modulu do syst´ emu DisCo Jde o seznam u ´kol˚ u, kde v levé ˇc´ asti jsou ˇrazeny u ´koly ke splnˇen´ı a v pravé jsou zpracov´ avané u ´koly. Kaˇzd´ y nesplnˇen´ yu ´kol má b´ yt zobrazen. Kaˇzd´ yu ´kol má tyto vlastnosti: 1. název 2. lokalita (pro moˇznost automaticky sv´ azat nˇekolik u ´kol˚ u za sebe) 3. priorita 4. unikátn´ı poˇradové ˇc´ıslo, které se generuje automaticky podle aktuáln´ı pozice 5. popis

I

II

ˇ ÍLOHA A. POPIS CINNOSTI ˇ ´ PR MODULU DO SYSTEMU DISCO

Obr´ azek A.1: Náhled na aplikaci

Pˇ r´ıloha B

Obsah pˇ riloˇ zen´ eho CD K této pr´ aci je pˇriloˇzeno CD, na kterém jsou uloˇzeny zdrojové kódy. • Adresáˇr DisCo: Program seznamu u ´kol˚ u v jazyce C# • Adresáˇr Literatura: Nˇekeré dokumenty uvedené v seznamu literatury • Soubor Bakalrska_prace_A_Hamr.pdf: Tento dokument

III

Fakulta elektrotechnická

Recommend Documents