AGILNÍ PŘÍSTUPY V PROJEKTOVÉM ŘÍZENÍ

AGILNÍ PŘÍSTUPY V PROJEKTOVÉM ŘÍZENÍ

Diplomová práce

Studijní program: N6209 – Systémové inženýrství a informatika Studijní obor: 6209T021 – Manažerská informatika

Autor práce: Bc. Martin Garčar

Vedoucí práce: doc. Ing. Klára Antlová, Ph.D.

Liberec 2014

THE AGILE APPROACH IN PROJECT MANAGEMENT

Diploma thesis

Study programme: N6209 – System Engineering and Informatics Study branch: 6209T021 – Managerial Informatics

Author: Bc. Martin Garčar

Supervisor: doc. Ing. Klára Antlová, Ph.D.

Liberec 2014

Tento list nahraďte

originálem zadání.

Prohlášení

Byl jsem seznámen s tím, že na mou diplomovou práci se plně vzta- huje zákon č. 121/2000 Sb., o právu autorském, zejména § 60 – školní dílo.

Beru na vědomí, že Technická univerzita v Liberci (TUL) nezasahuje do mých autorských práv užitím mé diplomové práce pro vnitřní potřebu TUL.

Užiji-li diplomovou práci nebo poskytnu-li licenci k jejímu využití, jsem si vědom povinnosti informovat o této skutečnosti TUL; v tom- to případě má TUL právo ode mne požadovat úhradu nákladů, které vynaložila na vytvoření díla, až do jejich skutečné výše.

Diplomovou práci jsem vypracoval samostatně s použitím uvedené literatury a na základě konzultací s vedoucím mé diplomové práce a konzultantem.

Současně čestně prohlašuji, že tištěná verze práce se shoduje s elek- tronickou verzí, vloženou do IS STAG.

Datum:

Podpis:

Poděkování

Rád bych zde poděkoval paní doc. Ing. Kláře Antlové, Ph.D. za její ochotu a profesionální rady při seznamování s problematikou agilních přístupů, přítelkyni Ing. Tereze Müllerové za její neutuchající podporu a rodičům, kteří při mně stáli po celou dobu studia.

6

Anotace

Tato diplomová práce se zabývá povědomím a vyuţíváním agilních přístupů v rámci projektového řízení na území České republiky. V teoretické části práce je představeno projektové řízení, způsoby řízení projektu za pomoci tradičních nebo agilních metodik, jejich rozdílné vnímání důleţitosti jednotlivých parametrů projektu a představení hlavních zástupců, zpracována je také literární rešerše na dané téma. V praktické části je poté za pomoci dotazníkového šetření zmapován český trh s širokým spektrem společností, které projektového řízení ve svých projektech aktivně vyuţívají. Následuje část vyhodnocení, kde jsou jednotlivá data a odpovědi přehledně zpracovány pomocí grafů a slovního vyjádření. Cílem šetření bylo zjistit, jaké je obecně o agilních přístupech povědomí, jaké typy firem a v jaké míře agilní metody a přístupy vyuţívají, popřípadě, jaké jsou obavy nebo vnímaná rizika z jejich zavedení. Po části vyhodnocení dotazníkového šetření byly zpracovány základní předpoklady úspěšné implementace agilních metodik do firem. V závěru pak proběhlo shrnutí nabytých poznatků z průběhu celé diplomové práce.

Klíčová slova

Agilní přístup Tradiční přístup Projektové řízení Vývoj software

7

Annotation

This thesis deals with the awareness and use of agile approaches in the context of project management in the Czech Republic. In the theoretical part, is to project management, project management methods using traditional or agile methodologies , their differing perceptions of the importance of individual parameters of the project and the presentation of the main representatives treatment is also a literature review on the topic. In the practical part, then with the help of a questionnaire survey mapped Czech market with a wide range of companies that project management in their projects actively used. The following is part of the evaluation , where individual data and a survey of answers using graphs and verbal expression . The aim of the investigation is to determine what is the general awareness of agile techniques , what types of firms and the extent to which agile methods and approaches used , or what fears or perceived risk of their introduction. After evaluation of the survey were processed basic prerequisites for successful implementation of agile methodologies to companies. In conclusion, it was a summary of the acquired knowledge throughout the thesis.

Keywords

The agile approach The traditional approach Project management Software development

8

Obsah

1 Projektový management ... 16

1.1 Standardy a standardizace v oblasti projektového řízení ... 18

1.2 Historie projektového managementu ... 19

1.3 Výhody a nevýhody projektového managementu ... 20

1.4 Projekt ... 21

1.4.1 Kritéria úspěšnosti ... 21

1.4.2 Kritéria neúspěšnosti ... 22

1.4.3 Vyhodnocení projektu ... 23

1.5 Problematika rizik v rámci projektového managementu ... 24

2 Metodiky řízení projektů ... 26

2.1 Klasické metodiky ... 26

2.1.1 Vodopádový model ... 26

2.1.2 Spirálový model ... 28

2.1.3 Rational Unified Process ... 30

2.2 Agilní metodiky ... 31

2.2.1 Dynamic Systems Development Method (DSDM) ... 34

2.2.2 Adaptivní vývoj software (Adaptive Software Development, ASD) ... 35

2.2.3 Lean Development ... 36

2.2.4 Vývoj řízený vlastnostmi ( Feature-Driven Development, FDD) ... 39

2.2.5 Crystal metodiky ( Crystal family of methodologies ) ... 40

2.2.6 SCRUM Development Process ... 41

2.2.7 Extrémní programování ( Extreme Programming – XP) ... 43

2.2.8 Vývoj řízený testy (Test-Driven Development, TDD) ... 44

3 Agilní přístup ... 46

9

3.1 Výhody agilního přístupu ... 48

3.2 Nevýhody agilního přístupu ... 48

3.3 Agilní přístupy v projektovém řízení – Literární rešerše ... 50

4 Průzkum pouţívání agilních metodik v ČR ... 55

4.1 Dotazníkové šetření ... 56

4.2 Vyhodnocení průzkumu ... 64

5 Zásady implementace agilních přístupů ... 82

10

Seznam obrázků

Obr. 1 – Procesní model průběhu projektu ... 17

Obr. 2 – Základny projektového managementu... 23

Obr. 3 – Schéma Vodopádového modelu ... 27

Obr. 4 – Schéma Spirálového modelu ... 29

Obr. 5 – Schéma ASD modelu ... 36

Obr. 6 – Schéma FDD modelu ... 39

Obr. 7 – Schéma Crystal metodik ... 40

Obr. 8 – Schéma Scrum metodiky ... 42

Obr. 9 – Schéma XP metodiky ... 43

Obr. 10 – Schéma Test-Driven Development metodiky ... 45

Obr. 11 – Rozdíl mezi agilními a tradičními přístupy ... 51

Obr. 12 – Komunikace v týmu s agilním přístupem ... 52

Obr. 13 – Vzorek firem ... 66

Obr. 14 - Pouţíváte projektové řízení interně nebo směrem k zákazníkům? ... 67

Obr. 15 – Pouţíváte projektové řízení pro řešení změn v organizaci? ... 67

Obr. 16 - Čas a dodrţení harmonogramu projektu a data dodání ... 68

Obr. 17 - Kvalita ve smyslu otestování produktu a ošetření chybových stavů ... 69

Obr. 18 – Náklady a dodrţení rozpočtu projektu ... 69

Obr. 19 - Šíře zadání ve smyslu rozsahu podporovaných funkcí... 70

Obr. 20 - Jak reagujete na změny poţadavků ze strany zákazníka v průběhu realizace projektu?... 71

Obr. 21 - Pouţíváte vlastní či jinou certifikovanou metodiku projektového řízení? ... 72

Obr. 22 - Slyšeli jste o pojmu „Agilní přístup v projektovém řízení“?... 73

Obr. 23 - Pouţíváte jej, nebo uvaţujete o jeho zavedení? ... 74

Obr. 24 - V případě, ţe neuvaţujte o pouţití některé agilní metodiky, jaká rizika nebo důvody Vás k tomuto odmítnutí agilních přístupů vedou? ... 75

Obr. 25 - V čem spočívají podle Vašeho názoru výhody a silné stránky agilních metodik a přístupů?... 76

Obr. 26 - V čem naopak vidíte nevýhody a slabé stránky agilních metodik a přístupů? ... 76

Obr. 27 - Jaké jsou důvody překročení rozpočtu nebo termínů realizace? ... 78

11 Obr. 28 - Pomocí jakých nástrojů komunikujete se zákazníkem? ... 79 Obr. 29 - Jsou poskytnuté informace od zákazníka pro Vás dostatečné? ... 80

12

Seznam tabulek

Tab. 1 – Ukázka tabulky z dotazníkového šetření určující priority dané společnosti ... 58

13

Seznam zkratek

ASD Adaptive software Development

DSDM Dynamic systems Development Method

FDD Feature-Driven Development

IPMA International Project Management Association LEAN Development Štíhlá výroba

PMBoK Project Management Body of Knowledge

PMI Project management institute

PRINCE 2 Projects IN Controlled Environments

RUP Rational Unified Process

SCRUM Iterativní a inkrementální metodika pro projektové řízení

SPŘ Společnost pro projektové řízení

TDD Test-Driven Development

XP Extreme Programming

14

Úvod

Dnešní moderní doba a neustále se vyvíjející trh nutí firmy, pokud chtějí být úspěšné a konkurenceschopné, sledovat nejnovější trendy a umět se pruţně přizpůsobovat potřebám koncového zákazníka. Ten je stále náročnější a udrţení jeho loajality a získávání dalších je podmíněno onou schopností být dobrý, být neustále lepší. Projektové řízení, o kterém pojednává tato práce je vyuţíváno jiţ od nepaměti. Vţdyť vzpomeňme například na stavbu pyramid. Jak musela práce probíhat, jak usměrnit tolik pracujících lidí, jak stanovit posloupnost prací a jejich návaznosti? Ano, projektové řízení má své kořeny zapuštěny hodně hluboko, byť vypadalo zcela odlišně, neţ před pár lety či dnes. Dnešní dobu můţeme rozdělit na projekty řízené takzvanými tradičními (heavy) metodikami a projekty řízené metodikami agilními (light).

Tradiční metodiky, obecně pak řízení projektů tradičně, je zaloţeno na jasně daném rozsahu projektu s definovanými poţadavky zákazníkem, jeho představy, co by měl projekt umět, jak by měl vypadat. Případná následná úprava je pak vnímána jako hrozba, se kterou nikdo nepočítá. Komunikace se zákazníkem funguje na bázi jednoho setkání na začátku za účelem poznání se, zjištění potřeb a cílů zákazníka, následně pak druhého setkání při představování projektu, tedy ve fázi finální.

Oproti tomu metodiky agilní neboliprojekty řízené agilně, se změnami počítají a jsou za ně rády. Změny jsou vnímány pozitivně, umoţňují rychle a pruţně reagovat na dodatečné připomínky ze strany zákazníka a za běhu je upravit. Smyslem tohoto řízení projektu je totiţ vtáhnutí zákazníka do jeho vlastního projektu, stává se z něj plnohodnotný člen týmu, který je po celou dobu součástí přípravy aţ do finální fáze. Vývojové týmy, vývojáři, mají neustále aktuální informace od zákazníka, který jiţ po několika týdnech, nejčastěji se vyuţívá fúze dvou týdnů aţ měsíce (můţe být ovšem dle potřeb aplikována i denní báze), dostává další část projektu. Je neustále v obraze, vnímá jednotlivé posloupnosti a potřebné úpravy jsou za běhu dotvářeny. To je obrovský rozdíl oproti výše zmíněným metodikám tradičním, které jsou přesným opakem pruţnosti a komunikace. Zákazník totiţ leckdy neví, co vlastně přesně chce a tak úpravy na projektech jsou velmi časté. Tím není míněno, ţe tradiční metodiky musí být zákonitě přeţitek, ţe jsou špatné a dávají se za příklad toho, jak

15 se nemá v moderních projektech postupovat, jsou prostě jen jiné, zaloţené na jiných principech a na některé projekty jsou dokonce vhodnější. Obecně jsou ovšem agilní metodiky jednodušší, nezatíţené spoustou dokumentace a povinnostmi, základ je zde kladen především na velmi dobrou komunikaci a to jak v týmu, tak směrem k zákazníkovi.

Cílem této diplomové práce bylo zanalyzovat (pomocí průzkumu, zaloţeném na dotazníkovém šetření), jaké povědomí mají české firmy o agilních přístupech v projektovém řízení, zdali sami vyuţívají nějakou agilní metodiku, popřípadě jaké jsou obavy, nebo vnímané hrozby jejich eventuálního zavedení.

Teoretická část je zaměřena nejprve na seznámení s projektovým řízením obecně, následně na formy řízení projektu, tedy právě tradiční versus agilní metodiky včetně jejich odlišných přístupů. V kaţdé z těchto typologií řízení jsou pak představeni nejdůleţitější zástupci a to včetně stručného shrnutí jejich fungování. V závěru teoretické části jsou pak shrnuty základní výhody a nevýhody agilních přístupů a zpracována literární rešerše na dané téma.

V praktické části diplomové práce bylo cílem zmapovat, jestli firmy v ČR vyuţívají agilních přístupů, či jaké jsou obavy nebo důvody nezavedení a to za pomoci dotazníkového šetření. Následuje část zpracování a vyhodnocení získaných odpovědí. Na závěr praktické části pak bylo cílem stanovit zásady implementace agilních přístupů do firmy, zhodnotit nabyté zkušenosti a informace z průběhu diplomové práce a pokusit se jasně a stručně shrnout základní benefity a rizika těchto přístupů.

16

1 Projektový management

Pojem projektový management vyjadřuje způsob řízení, díky kterému je moţné realizovat stanovené cíle. Definice projektového managementu je odvozená z managementu (tzn.

vedení, řízení), který můţeme vysvětlit jako proces řízení zabývající se koordinací zdrojů pro dosaţení předem stanovených cílů. V rámci teorie managementu známe několik nezbytných manaţerských činností:

a) Definování projektových cílů

Cíle musí být konkrétní, aby mohly být dosaţeny. Cíle projektu představují určité změny současného stavu (co, kde, v jakém časovém horizontu a kým má být uskutečněno). Cíle musí být měřitelné, reálné a potřebné.

b) Plánování

Stanovení plánu k dosaţení cílů projektu. Vytvoření harmonogramu a rozpočtu. V rámci plánování je nejdůleţitější vědět, kde nyní jsme, kam se chceme dostat a jakým způsobem se tam dostaneme. Plány představují základ pro sledování průběhu projektu. Díky plánům je moţné splnit poţadavky zadavatele a vyvarovat se moţným problémům. Efektivní projektový plán by měl mít následující vlastnosti:

- je schopný identifikovat, co je potřeba k úspěšnému dokončení projektu - součástí plánu musí být harmonogram pro sladění jednotlivých úkolů - určuje potřebné zdroje, zaručí jejich dostupnost v daný čas a jejich řízení - definuje rozpočet nákladů pro jednotlivé úkoly

- obsahuje určitou rezervu pro události, které se nedají předvídat - plán musí být věrohodný pro realizátory i pro management

c) Vedení

Koordinace a vedení všech aktivit projektu a manaţerské řízení lidských zdrojů. Důleţitá je komunikace, poskytování informací o projektu, co se bude dít, proč a koho se rozhodnutí dotkne.

17 d) Monitorování a kontrola

Sledování a kontrolování stavu projektových prací podle harmonogramu a rozpočtu, zjištění odchylek od plánu a jejich případná korekce.

e) Ukončení

Ukončení všech procesů projektového managementu, kontrola, jestli splněný úkol odpovídá ţádanému výstupu, uvolnění členů projektového týmu, odevzdání veškerých výstupů daného projektu a vyhodnocení dosaţených cílů projektu. [20 s. 7, 14 s. 32]

Jednotlivé manaţerské činnosti jsou představené na obrázku č. 1.

Obr. 1 – Procesní model průběhu projektu

Zdroj: METODICKÝ PORTÁL RVP. Řízení projektů – Projektový management. [online].

13. října 2008 [vid. 12. listopadu 2013]. Dostupné v PDF z: http://clanky.rvp.cz/wp- content/upload/prilohy/2698/rizeni_projektu.pdf

18

1.1 Standardy a standardizace v oblasti projektového řízení

Dnešní doba spjatá s celou řadou nejrůznějších opatření, norem, standardů nebo vyhlášek povětšinou nutí dělat věci jiným způsobem, neţ na který jsou lidé zvyklí. Dost často je to způsobené i tím, ţe řada z těchto nařízení a vyhlášek vzniká bez praktických zkušeností a vztahů k dané problematice. Naproti tomu standardy projektového řízení vznikají díky zkušenostem a praktickým dovednostem řady významných osobností z oblasti projektového řízení, kteří na vlastní kůţi zaţili a vyzkoušeli, co je přínosné a co doopravdy funguje.

Na rozdíl od nejrůznějších norem je v projektovém řízení velké mnoţství různých proměnných, jeţ nejsou měřitelné nebo jen velmi obtíţně a to z toho důvodu, ţe vytváření projektů je především o práci s lidmi.

Projektové řízení obsahuje několik standardů, kde v kaţdém z nich působí určitá skupina odborníků, kteří přinášejí své nabyté zkušenosti a cenné znalosti. Jednotlivé standardy vycházejí z podobných myšlenek a jejich nesporná výhoda tkví v tom, ţe si tvůrci nejrůznějších projektů i přes rozdílnost zaměření dokáţí poměrně jednoduše porozumět nastavit efektivní spolupráci. [18 s. 24]

Nejznámější a nejvyuţívanější světové standardy jsou:

a) PMBoK - Standard jenţ pochází z USA, vytvářený PMI (Project management institute), coţ je určitá profesní skupina firem a jednotlivých projektových manaţerů. Má více neţ 350 000 členů, kteří jsou zapojeni aktivně ve více neţ 170 zemích po celém světě.

b) IPMA – Tento standard necílí na jasně stanovenou podobu procesů a s následnou aplikací. Zaměřuje se především na různé schopnosti a dovednosti (kompetence) a to jak manaţerů, tak členů týmu. [18 s. 26]

c) PRINCE 2 - Standard pochází z Velké Británie. Metodologie je vlastněná firmou OGC (Office of Government Commerce). Toto procesní pojetí bylo vytvořeno kvůli poţadavkům britského ministerstva. Vláda ve Velké Británii vyţadovala

19 kvalitní IT projekty, které však dost často neodpovídaly vysokým poţadavkům na kvalitu, velmi často nebyl dodrţen ani harmonogram, rozpočet nebo přesně stanovené cíle. Právě na základě toho vznikla díky OGC metodika, která se stala standardem. Veškeré státní zakázky pak musely striktně podle této metodiky postupovat.

d) ISO 10 006 – Zde se nejedná o komplexní standard ani o samotnou normu, jedná se o směrnici jakosti v managementu projektu. Prozatím nemá ţádný vlastní standard projektového řízení. [18 s. 25]

U všech těchto standardů (kromě ISO 10 006) je moţnost získání certifikace projektových manaţerů. [18 s. 27]

1.2 Historie projektového managementu

Projektový management je znám a vyuţíván jiţ řadu století. Nejstarší projekt je spojován se stavbou egyptských pyramid, Velké čínské zdi nebo v rámci České republiky se stavbou Karlova mostu.

Pojmy projekt a projektový management se objevily v šedesátých letech dvacátého stolení hlavně ve spojení s kosmickými a vojenskými projekty (např. projekt Apollo společnosti NASA).

V sedmdesátých letech dvacátého století se projektové řízení rozšířilo do dalších odvětví díky osobnímu počítači.

Ve dvacátém stolení vzniklo několik asociací projektového managementu, které spojovaly profesionály působící v daném oboru a kteří napomáhají k jeho rozvoji. První organizací byla v šedesátých letech organizace INTERNET, která sdruţovala evropské projektové manaţery.

V devadesátých letech dvacátého století si změnila název na IPMA (tzn. International Project Management Association), aby nemohlo dojít k záměně s internetem. Organizace IPMA představuje v současnosti jednu z největších neziskových organizací na světě. Členy IPMA je zhruba 50 národních asociací projektového managementu. Mezi hlavní aktivity organizace IPMA patří certifikace profesionálů z oboru, publikační činnost a podpora odvětví. Od šedesátých let dvacátého století je obdobná organizace v Americe zvaná PMI (tzn. Project Management Institute).

20 Zmíněné organizace pořádají semináře, vydávají časopisy pojednávající o problémech projektového řízení a vydávají certifikáty.

V České republice působí společnost SPŘ (tzn. Společnost pro projektové řízení) coţ je národní organizace IPMA. Je to nezisková organizace, která sdruţuje jednotlivce a firmy zabývající se projektovým managementem. Vznik společnosti je datován od roku 1990 pod názvem INTERNET SZ a od roku 2001 vydává certifikáty projektových manaţerů podle standardů IPMA. [1 s. 7]

1.3 Výhody a nevýhody projektového managementu

Projektový management je spojený s určitými výhodami a nevýhodami. Mezi hlavní pozitiva projektového řízení patří:

- kaţdý úkol v rámci projektu má přiřazenou odpovědnost

- přiřazená odpovědnost za řízení sniţuje potřebu dohledu od zadavatele projektu

- podle specifikace poţadavků je moţné přesně stanovit cíle projektu

- díky rozpočtu se přesně určí časové a finanční podmínky uskutečnění projektu - v rámci vyšší efektivity vynaloţených prostředků jsou zdroje pro realizaci po

ukončení projektu uvolněny na ostatní projekty nebo rovnou spotřebovány

- pro lepší spoluúčast při řízení kvality je dobré zapojit všechny členy projektového týmu do plánování projektů

- informace získané z řízení projektu mohou být vyuţity pro další realizované projekty

Mezi hlavní negativa projektového řízení patří:

- v průběhu realizace projektu zjištěné specifické poţadavky od zákazníků - působení vlivů, které nejsme schopni ovlivnit

- technologické změny

- organizační změny v rámci společnosti, které mohou nastat aţ v průběhu realizace projektu

- legislativní změny

21 - časové zpoţdění tzn. prodleva mezi plánováním, oceňováním a realizací projektu

[1 s. 7]

1.4 Projekt

Projekt je klíčovým prvkem projektového managementu a dá se vysvětlit definicí podle ISO 10006 jako „jedinečný proces sestávající z řady koordinovaných a řízených činností s daty zahájení a ukončení, prováděný pro dosaţení cíle, který vyhovuje specifickým poţadavkům, včetně omezení daných časem, náklady a zdroji“. [11]

Projekt je jednorázový proces směřující k dosaţení stanovených cílů. Během procesu postupuje projekt řadou etap a fází a u kaţdé etapy se mění úkoly, zdroje a organizace.

1.4.1 Kritéria úspěšnosti

Pokud má být projekt úspěšný, musí splňovat následující podmínky:

- být funkční

- splňovat poţadavky zákazníka

- uspokojovat očekávání všech zúčastněných stran - včasné dodání produktu na trh

- výstupní produkt je v plánované jakosti a ceně

- dosaţení předpokládané návratnosti vloţených prostředků - vliv na ţivotní prostředí a okolí je v normě

Důleţité pro úspěch projektu jsou i tzv. měkké faktory:

- vyřešení sporů s okolím

- připravenost obsluhy z pohledu kvalifikace - správné motivování týmu [18 s. 36]

Tyto faktory jsou pro úspěch projektu velmi důleţité, spousty projektů můţou být v průběhu jejich vývoje radikálně změněny (můţe nastat i situace částečného nebo úplného

22 zastavení projektu) a právě v tuto chvíli je nesmírně důleţité, jakým způsobem dokáţe management komunikovat s lidmi zapojenými do vývoje, správně je namotivovat a ukázat jim směr pro další cestu vývoje daného projektu.

Pokud se firmě podaří dokončit úspěšně projekt, nemusí to automaticky znamenat, ţe je to způsobeno jeho kvalitním řízením. Bohuţel se stále v mnoha případech úspěchů v projektech dosahuje, především díky obrovské snaze a cílevědomosti všech účastníků na projektu, štěstím a neustálou improvizací. Nemusí to být pravidlem a i opačně můţe nastat situace, kdy projekty řízené kvalitně a efektivně skončí neúspěšně, nicméně se zde jedná o málo pravděpodobnou situaci. Kvalitní procesní řízení projektů je nezbytné pro dlouhodobý úspěch v rámci jednotlivých projektů.

1.4.2 Kritéria neúspěšnosti

Projekt se stává neúspěšný v případě mnoha nastalých skutečností, např.:

- nedodrţení termínů - překročení nákladů

- nespokojený zákazník a další zainteresované strany - negativní vlivy na ţivotní prostředí

- nedodrţení poţadované kvality produktu atd. [18 s. 36]

Základními ukazateli projektu jsou dle Svozilové tři základny projektu: čas, náklady a dostupnost zdrojů. Základny projektového managementu jsou znázorněné na obrázku č. 2.

na straně č. 23. [12 s. 23]

23 Obr. 2 – Základny projektového managementu

Zdroj: SVOZILOVÁ, Alena, Pavel MÁCHAL a Branislav LACKO. Projektový management:

metodiky efektivního vývoje softwaru. 1. vyd. Praha: Grada, 2006. ISBN 80-247-1501-5

Jednotlivé základny jsou provázané určitou vazbou. Kaţdé samotné provedení projektu potřebuje časový plán, který stanoví finanční výši rozpočtu projektu. V případě, ţe dojde ke zvýšení finančního rozpočtu projektu, potom je moţné vyuţít efektivnější zdroje a čas potřebný na realizaci se můţe zkrátit a naopak. [1 s. 10]

1.4.3 Vyhodnocení projektu

Smyslem vyhodnocení projektu je úspěchy převést do následujících projektů a z nezdarů se poučit a vyvarovat do budoucna. Vyhodnocení projektu musí být prováděno maximálně objektivně, abychom získali pravdivé poznatky pro zlepšování budoucích projektů.

Vyhodnocení není dobré zbytečně odkládat, ale je třeba počkat na řádné ukončení projektu a na získání všech dosaţených výsledků (kritérií projektu). Projekt by neměl vyhodnocovat vývojový tým z moţného neobjektivního pohledu, ale nelze pověřit vyhodnocením osobu, jeţ do styku s projektem vůbec nepřišla. Ideální je sestavit speciální tým, jenţ se vyhodnocení ujme. Jako základ pouţijeme projektový tým doplněný o několik dalších pracovníků, kteří doposud byli mimo dění projektu.

24 Při vyhodnocování se klade důraz na :

- překročení nákladů

- nesplnění časového harmonogramu

- odchylky od předem dohodnutých návazností činností - odchylky v mnoţství zdrojů na předem určené činnosti - odůvodnění prováděných změn

- vhodnost pouţívání jednotlivých metod a podpůrných nástrojů - fungování projektového týmu zaměřené na celek i jednotlivce - vyhodnocení efektivity podpůrných programů pro řízení projektu - mimořádné události, jeţ zasáhly do průběhu projektu (negativně) - spokojenost s prací a činností subdodavatelů, atd. [18 s. 42]

1.5 Problematika rizik v rámci projektového managementu

V oblasti projektového managementu se v celém průběhu prováděného projektu setkáváme s problémem rizika. Pro zajištění procesu zjištění, kontroly, eliminace a minimalizace nejistých událostí slouţí tzv. management rizik. Řízení rizik obsahuje výběr protiopatření, analýzu nákladů/přínosů, zařazení protiopatření a jeho prověřování. Je to rozhodovací proces, díky kterému se přijímají opatření k omezení negativního působení současných i budoucích rizikových faktorů. Výběr optimálního řešení představuje problémovou fázi řízení rizik.

V první řadě je potřeba určit úroveň rizik, dále je důleţité vyhodnotit ekonomické náklady a přínosy jednotlivých způsobů řešení, které vedou ke sníţení rizika. Dále se provede analýza vlivů jednotlivých řešení na projekt a okolí. Po zjištění výsledků se rozhodne o přijmutí opatření sniţující riziko a jeho sledování.

Pokud zjistíme, ţe riziko je nepřijatelné je potřeba zastavit probíhající proces a přijmout opatření na jeho sníţení. Pokud je riziko přijatelné, ale ne zanedbatelné, sestaví se plán s preventivními opatřeními a s cílem omezit rizika. V případě, ţe riziko nelze sníţit určitými opatřeními, zpracovávají se tzv. krizové plány.

25 Efektivní řízení rizik je moţné pouze kdyţ:

- je známa strategie subjektu včetně rizikové strategie a jeho hlavní cíle - je k dispozici odpovídající informační systém pro řízení rizik

- management klade velký důraz na řízení rizik a stanovuje odpovědné osoby - management musí analyzovat, monitorovat a vyhodnocovat rizika uvnitř i zvenčí - dále musí definovat cíle v rámci sniţování rizik (např. minimalizace nákladů) - zavést nejvhodnější metodu sniţování rizik a počítat s tím, ţe zavedení metody

s sebou můţe přinést rizika nová [4 s. 24]

Rizika se dělí na :

- objektivní – nezávislé na aktivitách podniku, jeho zaměstnancích a vlastnících (např. přírodní katastrofy, politická situace, apod.)

- subjektivní – závislá na činnostech podniku, zaměstnanců a vlastníků

(např. nedostatečná kvalifikace, nedbalost, neschopnost se přizpůsobit, apod.) - provozní – stávky, havárie

- trţní – problémy s odbytem, změny devizových kurzů - inovační – nové výrobky, technologie

- investiční a finanční – dluhové financování [18 s. 72]

26

2 Metodiky řízení projektů

Abychom si lépe vysvětlili důvody, proč vznikly agilní metodiky v rámci projektového řízení, představíme si tři základní klasické metody. Lépe si přiblíţíme problematiku a pochopíme celý historický vývoj.

2.1 Klasické metodiky

Tradiční přístup v projektovém řízení zavádí tzv. těţké procesy, kde přesně definuje formální náleţitosti dokumentu, specifikaci poţadavků a pouţití určitých nástrojů. Správa poţadavků je zaloţena na standardizovaných procesech, které určují způsob zadávání, zpracování a kontrolu poţadavků.

Z klasických metod jsem pro ukázku vybral tři příklady, které jsou významné v historii projektového řízení. Krátce tedy představíme vodopádový model, spirálový model a Rational Unified Process ( RUP ).

2.1.1 Vodopádový model

Vodopádový model je obecně povaţován za první celistvou metodiku řízení projektů. Jeho hlavní předností je jednoduchost, jak v jeho pochopení, tak i v řízení. Kaţdá jednotlivá fáze je zakončena zpracováním předem daných dokumentů a přechod mezi jednotlivými fázemi je provázen schvalovacím řízením. Máme díky tomu dobrý přehled o stavu projektu, a jaká část je jiţ splněna. Charakteristickým rysem vodopádového modelu jsou sekvenčně seřazené fáze bez iterací. Mezi jednotlivými fázemi je schvalovací proces, přes který musí všechny dokumenty projít, aby vývoj mohl pokročit do další fáze.

Mezi základní fáze modelu patří:

- určení problému, seznámení se se zákazníkem a s cílovými oblastmi - analýza a definování poţadavků

- návrh

27 - zavedení

- testování a začlenění - provoz a údrţba

Schéma posloupnosti jednotlivých fází je znázorněno na obrázku č. 3.

Obr. 3 – Schéma Vodopádového modelu

Zdroj: FAKULTA INFORMATIKY MASARYKOVY UNIVERZITY. Ţivotní cyklus informačního systému. [online]. 5. února 2010 [vid. 2. března 2014]. Dostupné z:

http://www.fi.muni.cz/~smid/mis-zivcyk.htm

Na obrázku je znázorněna posloupnost jednotlivých fází vodopádového modelu. Jak je z obrázku patrné, šipky mezi jednotlivými fázemi ukazují oběma směry, tzn., pokud zjistíme, ţe jsme udělali v předchozí fázi chybu, můţeme se k ní vrátit, chybu opravit a postoupit opět k další fázi, nicméně je potřeba dbát na schválení veškeré dokumentace při přechodu. Tato moţnost však platí pouze u fáze přímo předcházející současné. Vrátit se do kterékoliv fáze modelu je moţné pouze ve fázi údrţby, coţ je velmi nepraktické, protoţe z praxe víme, ţe změny v poţadavcích nastávají zpravidla dříve neţ ve fázi údrţby. Pokud

28 se tedy dodatečné poţadavky objeví aţ v pozdějších fázích vývoje, velmi to celý proces zdrţí. U vodopádového modelu je komunikace se zákazníkem potřeba v počáteční fázi specifikace poţadavků a v konečné fázi údrţby a při předání. V dnešní době se snaţíme komunikaci zařadit do celého vývojového procesu a tak je tento rys další negativním prvkem modelu, protoţe zákazník po celou dobu vývoje vůbec neví, co se děje, ani v jaké fázi se proces nachází.

Jednoduchost modelu je především výhodou pro menší projekty, pro větší se stává nevýhodou. Hlavní překáţkou je nedostatečná flexibilita modelu, kdy vývoj funguje přes striktně dané fáze. [2 s. 3]

V dnešní době se vodopádový model pouţívá spíše jako ukázka, jak se ve vývoji postupovat nemá.

2.1.2 Spirálový model

Vzhledem k tomu, ţe vodopádový model začal být brzy po svém vzniku nevyhovující, objevily se snahy o vymyšlení nového modelu, který by odstranil nedostatky. V roce 1985 přišel Barry Boehm se svým novým spirálovým modelem.

Spirálový model vychází z modelu vodopádového, ale nese dvě úplně nové a důleţité vlastnosti:

- analýza rizik – je prováděna v kaţdém cyklu a stanovuje příští směr vývoje projektu. Jakákoliv událost nebo situace můţe být rizikem a ohrozit projekt a to se bere v úvahu. U kaţdého rizika se stanoví pravděpodobnost jeho výskytu a stupeň nebezpečí. Analýza rizik má za úkol včas odhalit nevhodné postupy nebo skryté problémy. [2 s. 5]

- iterativní přístup – hlavní myšlenkou iterativního přístupu je uplatňování poznatků získaných v jednom cyklu ve všech následujících cyklech a zvyšovat tak kvalitu kaţdého cyklu. První výhodou je uţší kontakt se zákazníkem, který je intenzivně zapojen do vývoje aplikace. Délka jednotlivých cyklů je zhruba dva

29 týdny, takţe kaţdé dva týdny dostane zákazník aktuální verzi aplikace, kterou můţe vyzkoušet, připomínkovat a zvykat si na ni. Díky průběţné komunikaci se odhalí poţadavky zákazníka včas a nedojde tak k navýšení nákladů v pozdější fázi a to je jedna z dalších nesporných výhod. Můţe nastat nicméně i situace kdy zákazník bude předkládat stále nové a nové poţadavky a je pak na projektovém manaţerovi, aby stanovil určité hranice, v rámci kterých se můţe zákazník pohybovat, tak aby se projekt dokončil ke spokojenosti obou stran. [13]

Schéma spirálového ţivotního cyklu je zakresleno na obrázku č. 4.

Obr. 4 – Schéma Spirálového modelu

Zdroj: TESTOVÁNÍ SOFTWARU. Spirálový model. [online]. 11. července 2011 [vid. 2. března 2014]. Dostupné z: http://testovanisoftwaru.cz/manualni-testovani/modely- zivotniho-cyklu-softwaru/spiralovy-model/

30 Vývoj probíhá po spirále, a jak obrázek ukazuje, začíná se uprostřed a kaţdý z kvadrantů vyjadřuje nějakou fázi v iteraci, a jak se spirála postupně točí, tak se jednotlivé fáze opakují.

Spirálový model představuje hlavní výhodu nezávislosti na konkrétní metodice, komplexnost a vhodnost i pro větší projekty naopak pro malé projekty je aţ příliš komplikovaný a nevhodný. Díky neustálé analýze rizik se sniţuje moţnost nevhodného postupu a chyba se odhalí daleko dříve neţ u modelu vodopádového. Nicméně zásadním problémem stále zůstává, ţe v kaţdém cyklu je sice vytvořen prototyp, ale ten se můţe zaměřovat pouze na určité malé části systému a výsledný produkt je tedy předán aţ po dokončení posledního cyklu.

V současné době se spirálový model pouţívá stále měně často, protoţe jiţ jsou daleko propracovanější metodiky, ale také proto, ţe je spirálový model těţkopádný a nepruţný pro moderní typy aplikací. [2 s. 6]

2.1.3 Rational Unified Process

Rational Unified Process (dále jen RUP), komerční produkt firmy Rational je rozsáhlá a detailně propracovaná metodika. Mluvíme jiţ o metodice oproti předchozím dvěma modelům. Rozdíl mezi modelem a metodikou je, ţe model popisuje fáze, kterými produkt prochází, ale metodika popisuje, co se v které fázi má přesně dít, jaké postupy se mají aplikovat a jakého výsledku se má docílit.

Vývoj podle RUP probíhá v iterativních cyklech. Kaţdý cyklus se skládá ze 4 fází (v závorce je uvedené rozdělení doby v jednotlivých fázích):

1. Zahájení (10%) 2. Projektování (30%) 3. Realizace (50%) 4. Předání (10%)

31 Metodika RUP je poskytována ve formě internetových stránek, které fungují jako online instruktor a vede vývojáře celým průběhem vývojového procesu. Dodává rady, instrukce, pokyny a příklady ke konkrétním fázím vývoje.

Mezi největší výhody RUP patří přizpůsobivost pro řadu různých projektů a to díky tomu, ţe v počáteční fázi je modifikace samotné metodiky přímo na míru konkrétního projektu.

Dále se dá metodika upravit pro menší projekt i tým. Různé potřebné nástroje, šablony a průvodci jsou součástí metodiky.

V současné době patří metodika RUP k jedné z nejpouţívanějších metodik mezi velkými softwarovými giganty a snaha ji vyuţívat je i ze strany menších firem. [2 s. 7, 3 s. 24]

2.2 Agilní metodiky

V této části diplomové práce bude vysvětleno, co si vlastně pod pojmem agilní metodiky představit, jaké jsou hlavní zásady a principy, které byly v rámci Manifestu agilního vývoje (2001) definovány, jaký je rozdíl mezi jiţ výše zmíněnými tradičními metodikami a čím jsou a mohou být přínosem při dodrţování jistých pravidel. Dále bude uvedeno několik konkrétních agilních metodik, včetně jejich popisu a vhodnosti uplatnění.

Pokud bychom ve slovníku zjišťovali, co vlastně pojem agilní znamená, zjistíme, ţe ono slovo v překladu znamená čilý, hbitý nebo třeba aktivní. Všechny slova přesně vystihují, co je jeho podstatou. Konkrétně pak pod souslovím agilní metodika si můţeme představit vývoj, kde primárním cílem je co nejrychleji zrealizovat funkční projekt (software) bez zbytečných technických dokumentací či zdrţování se administrativními postupy. Na rozdíl od tradičních přístupů se tyto metody zaměřují na vytvoření častých výstupů z projektu a vnímají zákazníka jako plnohodnotného člena týmu. Programátoři pak vyuţívají jeho zpráv a připomínek pro další vývoj a úpravy. Chce-li firma zavést tuto technologii, nejprve je třeba vyzkoušet ji na pilotním projektu a po prokázání účinnosti a proveditelnosti přesunout na výrobní projekty. [28]

32 Průzkum, který v roce 2010 realizoval uznávaný kanadský softwarový inţenýr pan Scott Ambler přinesl jasné výsledky. Projekty, které jsou realizovány pomocí tradičních metodik (tradičním způsobem) daleko častěji nedodrţí termín dokončení, nákladovost, či funkčnost neţ projekty, které jsou řešeny agilně. [14 s. 35]

Zásadní rozdíl je v přístupu jednotlivých metod k zákazníkovi. Tradiční metodiky věří, ţe zákazník je schopen definovat jasně své poţadavky hned na začátku projektu a ty zůstanou po celou dobu neměnné. To ovšem velmi často vede k potíţím, kdy ve fázi předvedení (viz vodopádový model ţivotního cyklu, kdy vývojáři berou projekt v podstatě za dokončený), zákazník zjistí, ţe projekt nesplňuje to, co od toho ţádal, popřípadě, ţe si to představoval jinak. V tu chvíli se vrací celý koloběh cyklu na začátek a je jasné, ţe v takovou chvíli se finanční rozpočet musí navyšovat nehledě na to, ţe není jisté, zdali zákazník po opětovném předvedení nebude reagovat stejně.

Tradiční metodiky zkrátka začaly být velmi sloţité a málo flexibilní a nestačily pruţně odráţet poţadavky zákazníků. Ani postupné vylepšování těchto metod nepomohlo k vyřešení problémů. Proto bylo potřeba udělat radikální změnu a tou bylo agilní pojetí v projektovém řízení, kterému se budeme věnovat.

Agilní metodiky jsou schopné velmi rychle a pruţně vytvořit řešení. Jde o nejrůznější metodiky, které vznikaly od druhé poloviny devadesátých let a jejich podstatou je myšlenka, ţe jediný způsob, jak zjistit, ţe navrţený systém je správný, je ho vytvořit nebo alespoň jeho část a na základě zpětné vazby od zákazníka jej poupravit. [9 s. 10]

V roce 2001 se několik uznávaných projektových manaţerů a konzultantů okolo agilních přístupů ve vývoji sešlo v Utahu, aby společně našli způsob, jak řešit problémy projektů.

Výsledkem bylo podepsání tzv. Manifestu agilního vývoje software.

V Manifestu představují, čemu dávají přednost (přičemţ prvky na levé straně mají větší relativní význam neţ prvky na pravé straně):

- individuality a komunikace před procesy a nástroji - provozuschopnost software před obsaţnou dokumentací - spolupráce se zákazníkem před sjednáváním kontraktu

33 - reakce na změnu před plněním plánu [3 s. 33]

V rámci agilního přístupu je produkt vyvíjen postupně v tzv. iteracích (opakující se bloky, kde můţeme zakomponovat změnu). Na konci kaţdé iterace je produkt dodán v prototypu zákazníkovi a na základě zpětné vazby se upravuje podle poţadavků na změnu. Na konci jsou všechny poţadavky splněny a vývoj končí dokonalým řešením.

Agilním metodikám bývá vytýkána nedostatečná dokumentace. U agilního přístupu ale není cílem projektu dokumentace, ale spíše efektivnější přímá komunikace.

Manifest dále představuje základní principy, které je potřeba při vývoji produktu dodrţovat. Na jejich základě bylo definováno 10 hlavních principů, které si představíme v následujících odstavcích.

a) Nejdůležitější prioritou je včasně a průběžně dodávat hodnotný software zákazníkovi – pro zákazníka je důleţité, aby věděl, ţe v kaţdém cyklu dostává fungující produkt a jeho potřeby byly uspokojeny.

b) Vítají požadavky na změny i v průběhu vývoje za účelem zvýšení konkurenceschopnosti – je důleţité, aby fungující produkt byl dodáván v krátkých intervalech od dvou týdnů do dvou měsíců a byla zajištěna efektivní realizace změn.

c) Každodenní spolupráce uživatelů a vývojářů – na začátku se definují jen hrubé poţadavky a na základě časté komunikace se postupně upravují i mění.

d) Pro úspěch projektu je velmi důležité motivovat jedince zapojené do vývoje a vytvořit jim vhodné podmínky pro práci – o úspěchu a neúspěchu projektu rozhodují hlavně lidé, kteří by měli být vhodně motivováni a musí projekt podporovat.

e) Důraz na osobní komunikaci, která je nejefektivnějším přenosem informací – pomocí přímé komunikace se pochopí problém mnohem lépe, rychleji a s menšími náklady.

f) Fungující produkt je hlavní míra úspěchu

34 g) Důraz na zdravý vývoj – je důleţité vymezit pracovní prostor

(cca 40 hodin týdně), aby tým zůstal v dobré kondici

h) Pozornost kladená na technickou vyspělost a dobrý návrh – kvalita návrhu je nezbytná k realizaci změn, návrh se vytváří v průběhu projektu.

i) Klíčová je jednoduchost – maximalizovat práci, která se nemusí udělat.

j) Nejlepší architektury, návrhy a požadavky vychází ze samo organizujících se týmů – klade důraz na kreativitu lidí, častou komunikaci a upravování metodiky.

[3 s. 33]

Do agilních metodik můţeme zařadit následující typy, které si v další části práce podrobněji představíme:

- Dynamic Systems Development Method (DSDM)

- Adaptivní vývoj software ( Adaptive Software Development, ASD) - Lean Development

- Vývoj řízený vlastnostmi ( Feature-Driven Development, FDD ) - Crystal metodiky ( Crystal family of methodologies )

- SCRUM Development Process

- Extrémní programování ( Extreme Programming, XP ) - Vývoj řízený testy ( Test-Driven Development, TDD )

2.2.1 Dynamic Systems Development Method (DSDM)

Metodika DSDM vznikla v první polovině devadesátých let dvacátého století ve Velké Británii. Základním principem této metodiky je, ţe se stanový nejdříve čas a náklady a na základě toho se teprve upraví rozsah produktu.

Metodika DSDM má ze všech agilních metodik nejlépe propracovaný systém školení a kvalitní dokumentaci a je oblíbená jak v Evropě, tak v USA.

Metodika má základ v devíti principech:

a) Zapojovat aktivně zákazníka

35 b) Členové týmu mají určené rozhodovací pravomoci

c) Časté dodávky produktů

d) Podpora podnikových cílů při dodávce výstupu nebo mezi výstupem e) Iterativní a inkrementální vývoj

f) Moţnost změny v průběhu vývoje g) Definice poţadavků na hrubé úrovni h) Kontrola v průběhu celého vývoje

i) Neustálá spolupráce a komunikace mezi členy týmu

Metodika DSDM prochází v rámci vývoje několika fázemi. Mezi počáteční fáze, které probíhají pouze jednou, patří úvod do projektu, studie proveditelnosti a obchodní studie.

Hlavní fáze, které probíhají iterativně, jsou funkční model (sběr a proto typování poţadavků), návrh a implementace navrţeného řešení.

Metodika DSDM je projektovou metodikou, která je zaměřena spíše na softwarově inţenýrskou oblast. Zaměřuje se pouze na vývoj nového řešení a podobně jako RUP je dodávána ve formě online manuálu. [3 s. 35, 4 s. 41]

2.2.2 Adaptivní vývoj software (Adaptive Software Development, ASD)

Metodika ASD je moţná jednou z nejagilnějších metodik pro vývoj software. Autorem je Jim Highsmith. Metodika ASD pouţívá místo fází plánování, návrhu a realizace fáze spekulace, spolupráce a učení. Spekulace oproti plánu dává mnohem větší prostor na změny, představuje nejistotu a podporuje experimentování. Odchylky od plánu jsou tedy chápany spíše jako příleţitosti k učení a ne jako chyby. Spolupráce je velmi důleţitá fáze, spolupráce v rámci týmu vede ke sběru velkého mnoţství informací, které je následně potřeba zkoumat a pouţít na řešení problému. A v rámci poslední fáze učení je potřeba neustále prověřovat znalosti a učit se z minulých chyb i úspěchů. Schéma metodiky ASD je znázorněné na obrázku č. 5 na stránce č. 36.

36 Obr. 5 – Schéma ASD modelu

Zdroj: PACE UNIVERSITY. Software Engineering. [online]. 22. ledna 2012 [vid. 2. března 2014].

Dostupné z: http://csis.pace.edu/~marchese/cs615sp/L2New/CS615l2n.htm

Metodika ASD se zabývá nejen oblastí softwarového inţenýrství, ale i oblastí řízení.

Je vhodná pro projekty, které jsou charakteristické vysokou rychlostí, změnami a neurčitostí. Velkým plusem této metodiky je kladený důraz na fázi učení.

Metodika ASD je určena pro projekty charakterizované vysokou rychlostí, změnami a neurčitostí [3 s. 37]

2.2.3 Lean Development

Metodika Lean Development neboli štíhlá výroba je inspirována postupy uplatňovanými ve výrobě především v osmdesátých letech dvacátého století, je stavěná na schopnosti přizpůsobit se rychle a efektivně poţadavkům a vytvářet stabilní, stále se zlepšující vnitřní procesy. Lean Development si klade nelehké cíle, v rámci procesu vyuţívat třetinový čas,

37 třetinové lidské síly, s třetinovými investicemi do nástrojů a sníţení mnoţství chyb na třetinu. Metodika vznikla v Japonsku a jejím autorem je Robert Charette. Jedná se o soubor nejrůznějších metod a nástrojů, které si kladou za hlavní cíl dlouhodobě stabilizovat a neustále zvyšovat efektivitu a produktivitu práce. Je moţné zavádět tyto nástroje odděleně, maximalizace efektu ovšem bude firma dosahovat v případě komplexní implementace.

Filosofií je především dlouhodobé a nepřetrţité vyuţívání malých zlepšení, které v součtu utváří stabilní rozvoj efektivnější výroby. Veškeré systémy mají tendenci v čase sniţovat svojí efektivitu, vhodné vyuţití jednotlivých nástrojů ovšem tento dopad dokáţe minimalizovat a naopak přispívat k celkovému rozvoji a zvýšení produktivity výroby.

Moţným a častým negativem při zavádění bývá samotná filosofie štíhlé výroby, jeţ je zaloţena na malých změnách, které mnoho manaţerů jednotlivých organizací bere jako nedůleţité a kterými není potřeba se zabývat.

Následně si představíme několik hlavních pravidel štíhlé výroby v oblasti vývoje produktu:

a) odstranit zbytečné – odstranit vše, co nepřináší hodnotu finálnímu produktu b) maximalizovat tok – zkrátit čas vývoje

c) učinit rozhodnutí co nejpozději – rozhodovat se na základě jistoty a ne předpokladů d) zvýšit odpovědnost členů týmů

e) plnit poţadavky zákazníků

f) zpětná vazba od zákazníků – případné provádění oprav v průběhu vývoje g) motivovat a vytvářet vhodné podmínky pro zlepšování procesů při vývoji

Metodika je tolerantní ke změnám a je zaměřena spíše na řízení vývoje neţ na softwarově inţenýrskou oblast. [3 s. 38]

Pro jednodušší pochopení představíme 7 + 1 zásad druhů plýtvání v rámci štíhlé výroby.

Tyto zásady jsou velmi důleţité a je třeba je nejprve pochopit, sjednotit týmy, jinak zavádění nebude efektivní.

38 Mezi základní 7 + 1 zásad patří:

Čekání – čekání na materiál, polotovary, odzkoušení, kontrolu nebo čekání na následující úkon

Vysoké zásoby – týká se chybného plánování, špatné kvality, nepřehlednosti či zakrývání skutečných problémů

Zbytečná doprava a manipulace – špatné dispozice materiálu, mezisklady a jiné Výroba chybných dílů – dodatečné mzdy, materiály nebo energie, nejrůznější opotřebení, potřebné místo pro opravy či dodatečná kontrola

Nadvýroba – dopad špatného plánování, ekonomická ztráta

Nepotřebné procesy – nepotřebné operace, chod výrobních strojů bez vyuţití

Zbytečné pohyby – nekvalitně a chybně organizované pracoviště špatně organizované jednotlivé procesy

Nevyuţitý lidský potenciál – lidé jsou povaţováni za nejcennější a nejnákladnější zdroje a veškeré druhy plýtvání, které byly uvedeny výše vedou k plýtvání právě s lidským potenciálem a to je jednoznačně nejhorší dopad.

Smysl štíhlé výroby spočívá v pruţně se přizpůsobujících poţadavcích ze strany zákazníka s cílem následného dodání zákazníkovi:

Přesně to, co si zákazník ţádá V čase, v jakém si to ţádá V potřebném mnoţství

Ve správném pořadí

Ve správné kvalitě bez obsaţných chyb Při nejniţších moţných nákladech [22]

39 2.2.4 Vývoj řízený vlastnostmi ( Feature-Driven Development, FDD)

Autory metodiky FDD jsou Jeff De Luca a Peter Coad. Tato agilní metodika stojí na iterativním vývoji a základním principem je myšlenka, ţe celý vyvíjený systém se dá rozdělit na mnoţinu vlastností a ty pak postupně implementovat. Vlastnosti musí být měřitelné, srozumitelné a realizovatelné. Autoři se snaţili, aby byl vývoj produktu jednodušší, efektivnější a čitelnější.

Metodika FDD je sloţená z pěti procesů:

a) Vytvoření celkového (globálního) modelu b) Vytvoření seznamu vlastností

c) Plánování podle vlastností d) Návrh podle vlastností e) Realizace podle vlastností

Celý proces je vidět na obrázku č. 6.

Obr. 6 – Schéma FDD modelu

Zdroj: SOFTWARE DEVELOPMENT AND OTHER STUFF. Feature-Driven Development.

[online]. 1. dubna 2013 [vid. 4. března 2014]. Dostupné z: ttp://www.step10.com/SoftwareProcess/

FeatureDrivenDevelopment/index.html

Poslední dva procesy se opakují v iteracích trvající zhruba dva týdny. To zaručí, ţe zákazník dostane finální produkt podle svých představ. Metodika FDD se dá pouţít jak pro malé projekty, tak i pro rozsáhlé projekty velkých společností. [3 s. 40, 2 s. 16]

40 2.2.5 Crystal metodiky ( Crystal family of methodologies )

Crystal metodiky jsou určené pro různé druhy projektů. Jejich autorem Crystal metodik je Alistair Cockburn.

Hlavním principem Crystal metodik je komunikace a lehkost produktu. Metodiky se přizpůsobují kaţdému produktu individuálně. Výběr vhodné metodiky se provádí podle velikosti projektu, která se stanoví na základě počtu členů týmu, důleţitosti systému (Komfort (C-Comfort), Drobný finanční obnos (D-Discretionary money), Významný finanční obnos (E-Essential money), Ţivot (L-Life)) a podle hlediska pro které je metodika optimalizována. Metodiky jsou pojmenovány podle barev. Nejjednodušší metodika je nazvaná Clear poté následuje Yellow, Orange, Red, Maroon, Blue, Violet atd.

Schéma Crystal metodik je znázorněno níţe na obrázku č. 7.

Obr. 7 – Schéma Crystal metodik

Zdroj: ALISTAIR COCKBURN. Crystal light methods. [online]. 1. ledna 2005 [vid. 4. března 2014]. Dostupné z: http://alistair.cockburn.us/Crystal+light+methods

Metodiky doporučují mnoţství a rozsah dokumentace, rozdělení týmů, průběh projektu a postupy při vývoji.