ZÁPADOČESKÁ UNIVERZITA V PLZNI FAKULTA EKONOMICKÁ
Diplomová práce
Agilní projektový management Agile project management
Petr Flaška
Plzeň 2019
(Zadání)
Prohlašuji, že jsem diplomovou práci na téma
„Agilní projektový management“
vypracoval samostatně pod odborným dohledem vedoucího diplomové práce za použití pramenů uvedených v přiložené bibliografii.
V Plzni dne ... ...
podpis
Poděkování
Rád bych poděkoval vedoucímu diplomové práce Doc. Ing. Jiřímu Vackovi, Ph.D.
za cenné profesionální rady, připomínky a metodické vedení práce. Dále bych rád poděkoval Lence Bohuslavové a Tomáši Častovi za poskytnuté materiály a čas věnovaný řešení mých dotazů a podnětů při zpracovávání praktické části diplomové práce.
Obsah
Úvod ... 9
1 Projektový management, standardy PM a projekt ... 10
1.1 Projektový management ... 10
1.2 Standardy projektového řízení ... 11
1.2.1 IPMA ... 12
1.2.2 PMBOK ... 12
1.2.3 PRINCE2 ... 13
1.3 Projekt ... 14
1.3.1 Definice projektu - Logický rámec ... 15
1.3.2 Účastníci projektu ... 17
1.4 Životní cyklus projektu a projektové fáze ... 18
1.4.1 Předprojektová fáze ... 19
1.4.2 Projektová fáze ... 20
1.4.3 Vyhodnocovací fáze ... 22
1.5 Řízení projektů v IT ... 23
2 Tradiční vodopádový přístup řízení projektů ... 24
2.1 Životní cyklus projektu - klasický (vodopádový) přístup ... 24
3 Agilní přístup řízení projektů ... 26
3.1 Životní cyklus projektu - agilní přístup ... 27
3.2 Agilní Manifest ... 28
4 Srovnání tradičního vodopádového přístupu a agilního přístupu ... 30
4.1 Porovnání simulace tradičního řízení a agilního řízení ... 32
5 Agilní metodiky ... 33
5.1 Scrum ... 33
5.1.1 Základní fungování metodiky Scrum ... 35
5.1.2 Role Scrum Týmu ... 35
5.1.3 Scrum události ... 37
5.1.4 Scrum Artefakty ... 39
5.1.5 Proces Scrumu ... 42
6 Případová studie ... 44
6.1 Představení společnosti AIMTEC a.s. ... 44
6.2 Produkty společnosti AIMTEC, a.s. ... 45
6.3 Systém DCIx ... 46
7 Popis projektu ... 48
8 Analýza řízení projektů v organizaci ... 49
8.1 Metodika ... 49
8.2 Projektové role ... 50
8.3 Projektové dokumenty ... 52
8.4 Fáze projektu ... 54
8.4.1 Předprojektová fáze ... 54
8.4.2 Příprava projektu ... 54
8.4.3 Analýza ... 56
8.4.4 Instalace HW a SW, nastavení systému ... 58
8.4.5 Příprava dat a nastavení systému ... 58
8.4.6 Prototypování ... 59
8.4.7 Integrační test ... 60
8.4.8 Příprava produktivního provozu ... 60
8.4.9 Produktivní provoz s podporou ... 61
8.5 Změnové řízení ... 62
8.6 Řízení vývojových aktivit ... 63
8.6.1 Plánování Sprintu ... 63
8.6.2 Využití Softwaru JIRA v průběhu Sprintu ... 65
8.6.3 Ukončení Sprintu ... 67
9 Zhodnocení řízení projektů ... 69
9.1 Výhody zvoleného způsobu řízení projektů ... 70
9.2 Nevýhody zvoleného způsobu řízení projektů ... 71
10 Doporučení pro zdokonalení řízení projektů ... 73
Závěr ... 75
Seznam zkratek ... 76
Seznam obrázků ... 78
Seznam tabulek ... 79
Seznam použité literatury ... 80
Úvod
Agilní projektový management má své uplatnění při řízení projektů hlavně v oblasti IT, kde dochází velmi často ke specifikaci požadavků na projekt i v pozdějších fázích projektu. Právě schopnost pružně reagovat na požadavky a zvládnutí změn se stává v moderních firmách standardem a agilní projektový management pomáhá společnostem k dosažení těchto výhod. Agilní projektový management má v dnešní době jistý přesah odvětví, ve kterém vznikl, a agilní metodiky jsou používány ve firmách s různým zaměřením, jelikož dynamické podnikatelské prostředí určuje aktuální trend, na který by konkurenceschopná firma měla být připravena.
Cílem této diplomové práce v teoretické části je představení agilního projektového managementu prostřednictvím literatury. Cílem praktické částí diplomové práce je analýza projektového řízení ve společnosti AIMTEC, a.s. a vypracování doporučení pro zdokonalení řízení projektů.
V teoretické částí práce jsou nejdříve prezentovány základy projektového managementu a tradiční přístup řízení projektů. Dále jsou formulovány základní principy a fungování agilního přístupu řízení projektů a provedena komparace obou principů. Následně je zbývající část teoretické práce věnována principům fungování metodiky Scrum.
V praktické části je představena společnost AIMTEC, a.s., její produkty a divize, ve které probíhala analýza řízení projektů. Představen je rovněž projekt, kterým je implementace informačních systému DCIx MES a DCIx WMS do výroby a logistiky zákazníka.
Nejprve je popsána metodika řízení projektů společnosti, důležité role a dokumenty projektového řízení. Následná analýza řízení projektů v organizaci je popisována podle jednotlivých fází. Samostatnou kapitolu poté tvoří analýza řízení vývojových aktivit společnosti, kde je popsáno praktické fungování modifikovaného Scrumu.
Závěrem práce je zhodnoceno projektové řízení společnosti, popsány výhody a nevýhody zvoleného způsobu řízení projektů a následně jsou doporučena možná zdokonalení řízení projektů.
1 Projektový management, standardy PM a projekt
1.1 Projektový management
Projektovým řízením, jinak také projektovým managementem, rozumíme soubor aktivit, doporučení, norem a soubor nejlepších možných zkušeností s řízením projektů.
Různorodost projektů uvedla disciplínu projektové řízení do formy všeobecně platných skutečností, které představují specifickou filozofii řešení daných problematik. Jednoduše lze říci, že znalostí projektového managementu dosáhneme určitého komplexního projektového myšlení a nelze čekat, že najdeme přesné odpovědi, směrnice a návody na konkrétní projektové situace. Tato filozofie představuje způsob přistupování k návrhu a realizaci projektu především tak, aby bylo dosaženo určeného cíle ve stanoveném termínu s dodržením rozpočtu, při využití dostupných zdrojů a bez dalších negativních vedlejších efektů.
Aby bylo dosaženo tzv. úspěšného projektu, je potřeba charakterizovat projektový management především:
• systémovým přístupem (představuje myšlení a vyhodnocování jevů v souvislostech),
• systematickým, metodickým postupem (správně využívat stejné či podobné prvky řízení na různé projekty),
• strukturováním problému a strukturováním v čase (rozložení problému na menší dílčí úkoly a jejich časové určení),
• využíváním přiměřených prostředků (výběr vhodných metod a procesu řízení),
• používáním interdisciplinární týmové práce (osvojení si práce v projektovém týmu za dosažením lepších výsledků),
• využíváním počítačové podpory,
• aplikováním zásad trvalého zlepšování (neustále se poučovat z chyb a úspěchů z minulosti),
• integrováním procesů, zdrojů, lidí apod. (Doležal a kol. 2016).
Existuje několik definic projektového managementu, které je možné najít v publikacích.
Pohledy autorů na projektový management jsou různé, avšak všechny vycházejí z podobných principů a docházejí ke společným závěrům. Příkladem jsou níže přeložené definice, které zní následovně:
„Projektový management je souhrn aktivit spočívající v plánování, organizování, řízení a kontrole zdrojů společnosti s relativně krátkodobým cílem, který byl stanoven pro realizaci specifických cílů a záměrů“ (Kerzner 2006, s. 4).
The Project Management Institute (PMI) definuje projektový management takto:
„Projektový management je aplikace znalostí, schopností, nástrojů a technologií na aktivity projektu tak, aby splnily požadavky projektu“ (PMBOK 2013, s. 47).
Wysocki představuje jiný pohled na definování projektového managementu tím, že do definice přímo zapojuje zákazníka a tvrdí:
„Project management je organizovaný přístup, řízený zdravým rozumem, který využívá zapojení klienta, za účelem dodání požadavků klienta, které splňují očekávanou obchodní hodnotu“ (Wysocki 2013, s. 29).
Podle Philipse (2010) je úspěšný projektový management hlavně týmovou prací.
Projektový manažer musí mít efektivní projektový tým, na který se lze spolehnout.
Při jeho vytvoření doporučuje upřesnit schopnosti, které jsou potřeba ke zvládnutí projektu a na základě těchto schopností vybrat příslušné členy týmu, kteří tyto atributy mohou nabídnout.
1.2 Standardy projektového řízení
Standardů projektového řízení je známo více, stejně tak i možností, jak daný projekt řídit.
Pro přehledné řízení projektů v dynamickém prostředí, ve kterém se pohybujeme, vznikají standardy projektového řízení, jako ucelené znalosti, doporučení a způsoby, jak s projekty pracovat. Tato doporučení mají svůj sociálně-kulturní původ a odlišné pohledy na řízení projektů. Standardy mají však velmi podobnou filozofii a na rozdíl od standardů jiných oborů jsou dílem mnoha významných manažerů a osobností z praxe.
Světově nejrozšířenější jsou IPMA, PMI a PRINCE2 (Doležal a kol. 2009).
1.2.1 IPMA
IPMA – International Project Management Association působí na pěti kontinentech, kde se snaží rozvíjet kompetence v projektovém řízení. IPMA se zaměřila na kompetenční pojetí pro ověření znalosti a zkušenosti projektových manažerů, vychází tedy z kompetencí technických, behaviorálních i kontextových. Tyto znalosti certifikuje značkou ICB (IPMA Competence Baseline) a vychází z něj Národní standard kompetencí projektového řízení, který je vydáván Společností pro projektové řízení Česká republika.
Nejvýznamnější metody a techniky jsou tvorba logického rámce, SWOT analýza, řešení konfliktů zdrojů, metody návratnosti a oceňování investice a kvantitativní metody řízení rizik (Máchal a kol. 2015).
Podle Doležala a kol. (2016) není ICB orientována na procesní řízení, jelikož standard nediktuje určitě procesy, ale spíše doporučuje procesní kroky, které lze aplikovat do určité projektové situace. Hlavním principem je tedy správná aplikace konkrétními osobami, což vede k poměrně velkému prostoru pro kreativitu.
1.2.2 PMBOK
Jinými slovy Project Management Body of Knowledge (Máchal a kol. 2015) je standard vytvořený Project Management Institute (PMI), což je profesní sdružení firem a projektových manažerů, které čítá přes 2,9 milionu profesionálů. Bylo založeno roku 1969 v Pensylvánii (USA). Hlavní parametry standardu PMI jsou stanoveny v tzv.
PMBOK Guide (8) (A Guide to Project Management Body of Knowledge), který definuje základní principy projektového řízení světově uznatelného standardu. Základním pohledem je v tomto případě procesní pojetí dané problematiky projektového řízení, které je zde rozděleno do pěti hlavních procesních skupin, deseti oblastí znalostí, jednotlivých procesů a jejich vazeb. Procesní skupiny tvoří: Iniciace, Plánování, Realizace, Monitoring a kontrola, Ukončení. Tyto skupiny jsou navzájem propojeny finálním produktem, který je projektem realizován. Mezi oblasti znalostí pak patří: Řízení integrace projektu, Řízení rozsahu projektu, Time management, Řízení nákladů projektu, Řízení kvality projektu, Řízení lidských zdrojů projektu, Řízení komunikace projektu, Řízení rizika projektu, Řízení nákupu projektu a Řízení zájmových stran projektu. PMI klade důraz především na metody řízení dosažení hodnoty projektu (Earned Value Management – EVM), hierarchickou strukturu (Work Breakdown Structure – WBS), metodu kritické cesty
1.2.3 PRINCE2
PRINCE2 představuje Projects In Controlled Enviroments a jedná se o metodiku také procesního charakteru. Certifikaci provádí APGM (Association of Project Management Group). Původní metodika byla založena na projektech, týkajících se informačních technologií, později byla implementována britskou vládou a její efektivnost probudila zájem i soukromých podniků. V současné době je používána více než milionem projektových manažerů a představuje standard pro řízení projektů podporovaných z prostředků Evropské unie. Strukturu metodiky PRINCE2 tvoří principy, témata a procesy. Mezi principy řadíme nepřetržitá opodstatněnost investice, jasně definované role a zodpovědnost, orientace na produkty, řízení po etapách, řízení na základě výjimky, učit se ze zkušeností, přizpůsobení metody PRINCE2 prostředí projektu. Témata představují investice, organizace, kvalita, plány, riziko, změna, progres. Dalším elementem jsou procesy a tvoří je zahájení projektu, nastavení projektu, směrování projektu, kontrola etapy, řízení dodávky produktu, řízení přechodu mezi etapami, ukončení projektu. Metodika PRINCE2 sleduje dále vzájemné interakce mezi procesy a tématy. Mezi používané metody PRINCE2 patří matice odpovědností, či princip stanovení cílů metodou SMART tzn. S – specific, specifický, M – measurable, měřitelný, A – agreed, akceptovatelný, R – realistic, reálný, T – trackable, sledovatelný (Máchal a kol. 2015).
1.3 Projekt
Projektový management se zabývá hlavně plánováním a realizací projektů. Projekty představují činnosti nebo soubory činností, které transformují určité vstupy na výstupy a vedou k vytvoření jedinečného produktu nebo služby. Vstupy rozumíme lidské zdroje, know-how, finanční zdroje, materiál, výrobní stroje apod. Výstupy tvoří samotný výrobek či služba. Abychom mohli takový soubor činností nazývat projektem, je nutné si uvědomit také omezenost časovým intervalem. Kombinace těchto faktorů tvoří každý projekt unikátní, jedinečný (Skalický a kol. 2010).
Jednoduchou definici projektu uvádí PMBOOK:
„Projekt je dočasné úsilí podniknuté pro vytvoření jedinečného produktu, služby nebo výsledku “ (Project Management Institute 2008, s.442).
Projekt tak vytváří jedinečnou aktivitu s velmi přesně definovanými požadavky a výsledky, ke kterým vede řada procesů a aktivit, jež je nutné splnit pro splnění cíle projektu. Tyto aktivity a procesy vyžadují důslednou koordinaci a kontrolu hlavně v oblasti načasování, následnosti činností, nákladů a rozsahu. Důležité je také uvědomit si, že projekt musí být svojí váhou velmi důležitý pro vrcholový management, jenž za účelem splnění projektu vytváří dočasnou organizační jednotku, která překračuje standardní strukturu organizace, a říká se jí projektový tým (Meredith a Mantel 2012).
Je vhodné vymezení projektu dále rozvést a uvést si další definici:
„Projekt je sekvence unikátních, komplexních a propojených aktivit, která má jasný cíl nebo účel a musí být zhotovena ve specifickém čase, při nepřekročení rozpočtu a podle zadaných specifikací“ (Wysocki 2013, s.4).
Z textu výše vyplývá, že projekt je řízen z hlediska tří hlavních parametrů, které představují rozsah (kvalita), čas (doba trvání) a zdroje. Tyto tři veličiny tvoří tzv.
projektový imperativ či projektový trojúhelník, který jednoduše graficky zobrazuje spojitost zmíněných parametrů a podstatu řízení projektu. Funkcionálně projektový trojúhelník zobrazuje a klade důraz na správné rozložení a nalezení ideální kombinace právě rozsahu, času a zdrojů (Doležal a kol. 2016).
Obrázek č. 1: Projektový trojúhelník
Zdroj: (Skalický a kol. 2010, str.48) Zpracoval: Petr Flaška, 2019
Praktický význam projektového trojúhelníku vysvětluje Skalický, Jermář, Svoboda (2010, s.47) následovně:
„Zvětšuje-li se rozsah projektu nebo se požaduje vyšší kvalitativní stupeň projektového produktu, většinou se zvyšují nároky na peníze a čas. Při omezených nákladech se musíme spokojit s jiným, levnějším provedením díla. A chceme-li provést projekt v kratším termínu a na vysokém kvalitativním stupni, znamená to většinou zvýšení nákladů.“
1.3.1 Definice projektu - Logický rámec
Každý projekt obsahuje jedinečný obsah, je proto vhodné detailně analyzovat, co předmětem projektu je a co už je za hranicí definice dodávaného projektu. Tato detailní specifikace usnadňuje firmám řešit případné spory o rozsah dodávky projektu, pomáhá také při řešení případných změn požadavků ze strany zákazníka. Obsahuje vždy název projektu, účel projektu, co je přesným cílem projektu, jaké jsou dílčí výstupy a v neposlední řadě jasně definované projektové omezení z hlediska trojimperativu, tedy času, nákladů a rozsahu či kvality projektu (Doležal a kol. 2016).
Svozilová (2016) uvádí, že vypracování definice předmětu projektu tvoří následující postup:
- Vytvoření vize a zadání projektu, kde impulsem jsou strategické potřeby.
- Sběr požadavků uživatelů a sestavení požadavků na kvalitu.
- Zpracování definic, odborných posudků a návrhů, kde impulsem jsou technologické a funkční požadavky.
- Vypracování definice předmětu projektu, jež bere v potaz i na ostatní požadavky a omezení.
Standardní definici projektu představuje Logický rámec (Logical Frame Matrix). Logický rámec poskytuje informace k přípravě plánování, realizaci a následné kontrole projektu.
Je tvořen maticí, která obsahuje čtyři sloupce, kde se v prvním sloupci uvádí účel/strategický záměr projektu, dále cíl projektu, dílčí výstupy projektu a také klíčové činnosti, tedy aktivity. V druhém sloupci jsou uvedeny objektivní ukazatele dosažení stanoveného záměru, cíle, dílčích výstupů a zdroje k dílčím činnostem. Třetí sloupec obsahuje způsob ověření nebo také často zdroje pro ověření údajů ve druhém sloupci.
U klíčových činností se ve druhém sloupci uvádějí zdroje. V posledním, tedy čtvrtém sloupci, se vyplňují předpoklady pro dosažení záměru, cíle a dílčích výstupů nebo také často případná rizika splnění daného sloupce. Důležitým pohledem je orientace zdola nahoru, který definuje vzájemnou nadřazenost řádků logického rámce (Skalický a kol. 2010).
Vzájemné vazby logického rámce jsou uvedeny v tabulce č.1 a popsány níže.
Tabulka č. 1: Logický rámec
Strategický záměr, účel)
Objektivně ověřitelné ukazatele
Zdroje informací k ověření (způsob ověření)
Nevyplňuje se
Cíl Objektivně ověřitelné
ukazatele
Zdroje informací k ověření (způsob ověření)
Předpoklady, za kterých Cíl skutečně přispěje a bude v souladu s přínosy Výstupy (postupné
cíle)
Objektivně ověřitelné ukazatele
Zdroje informací k ověření (způsob ověření)
Předpoklady, za kterých Výstupy skutečně povedou k Cíli
Klíčové činnosti (aktivity)
Zdroje (finanční, lidské, materiální)
Časový rámec aktivit Předpoklady, za kterých Klíčové činnosti skutečně povedou k Výstupům Zde některé organizace uvádějí, co NEBUDE v projektu řešeno Případné předběžné
podmínky
Zpracoval: Petr Flaška, 2019
Znázorněné šipky ukazují závislost a nadřazenost řádků logického rámce v obou směrech.
Logiku je možné vyjádřit následovně: splněním předběžných podmínek pro projekt můžeme vykonávat jednotlivé aktivity projektu s přiřazenými zdroji a v daných termínech při zvážení zmíněných rizik. Splněním celého řádku jsou splněny předpoklady, které vedou ke splnění postupných cílů, tedy dílčích výstupů projektu. Ověřením plnění výstupů a uvážením přiřazených rizik naplňujeme předpoklady pro splnění cíle. Se stejnou logikou postupujeme dále, až k naplnění strategického záměru projektu, tedy jeho účelu (Skalický a kol. 2010).
1.3.2 Účastníci projektu
Účastníky projektu tvoří všechny zájmové skupiny projektu, neboli zainteresované strany (stakeholders). Jsou to osoby nebo organizace, které mají svůj podíl na ovlivňování realizace projektu nebo jeho výsledku (pozitivně i negativně). Tyto zájmové skupiny je třeba analyzovat a vhodně identifikovat. Pro tento účel je doporučeno vytvořit registr zainteresovaných stran, případně matici vliv/zájem, která je více popsaná v mé bakalářské práci (Doležal a kol. 2016).
Stakeholders lze rozdělit podle rozložení jejich individuálních nebo skupinových cílů na:
• Zákazník projektu – zákazník projektu má zájem na realizaci projektu, často je také jeho zadavatelem, investorem a uživatelem. Představuje společnost, nebo její část, pro kterou budou výsledky projektu nositelem strategického záměru nebo změny.
• Sponzor projektu – sponzor projektu představuje manažera zákazníka projektu, který disponuje autoritou k rozhodování o aspektech projektu týkajících se jeho časového rozvržení, rozsahu projektu či rozpočtu.
• Dodavatel/realizátor projektu - tvoří společnost nebo její část, jež je přímým účastníkem kontraktu a je odpovědna za samotnou realizaci projektu.
Dodavatel projektu projevuje zájem na plnění podmínek kontraktu a získání s tím spojených odměn (Svozilová 2016).
Toto rozdělení v základu popisuje princip zainteresovaných stran v komerčním prostředí.
Skalický a kol. (2010) popisují zainteresované strany více podrobněji a uvádějí je následovně: zákazník, projektový manažer, projektový tým, řídící výbor, investor, podpůrný tým, mateřská organizace, externí člen projektového týmu, správní výbor a
projektová kancelář. Časté je také rozdělení na přímé účastníky projektu a nepřímé účastníky projektu. Přímými účastníky rozumíme osoby přímo podílející se na projektových činnostech. Nepřímými účastníky rozumíme osoby a organizace, kterých se projekt nepřímo týká, nepodílejí se na něm, ale ovlivňuje je (např. státní správa, občané, environmentální organizace).
1.4 Životní cyklus projektu a projektové fáze
Zamyslíme-li se nad projektem obdobně jako nad procesem, lze popsat jednotlivé fáze, které jsou charakteristické pro většinu projektů. Stanovení počtu a charakteristik fází vychází z podstaty projektového řízení konkrétní společnosti nebo konkrétního projektu.
Obecně ale platí, že fáze životního cyklu projektu definují, jaký typ práce má být vykonán v určitém stupni rozvoje projektu, jak jsou tvořeny a jak ověřovány a hodnoceny konkrétní výstupy v jednotlivých fázích, a v neposlední řadě určují, kdo se v určitých fázích projektu do projektových aktivit zapojuje (Svozilová 2016).
Nejobecnějším způsobem jsou projektové fáze znázorněny na obrázku č. 2.
Obrázek č. 2: Projektové fáze
Zdroj: (Doležal a kol. 2016) Zpracoval: Petr Flaška, 2019
Předprojektová fáze
Uvedení projektu (zahájení)
Plánování
Realizace
Ukončení projektu
Vyhodnocovací (poprojektová) fáze
Podle Wysockiho (2013) je životní cyklus projektu tvořen sekvencí procesů, které zahrnují:
- Scoping (procesy definující rozsah) - Planning (procesy plánovací)
- Launching (procesy zahájení projektu)
- Monitoring and controlling (procesy monitorovací a kontrolní) - Closing (procesy uzavření projektu).
Během všech fází projektu je projektový manažer povinen se zaměřit na vedení projektového týmu a na udržení správných vztahů se všemi projektovými stakeholdery.
Pro úspěšné splnění projektu je totiž klíčové řízení lidských zdrojů a komunikací v projektu, což vyžaduje vynikající vůdčí, komunikační a politické schopnosti. Je zodpovědný za efektivní plánování, řízení realizace, monitoring a integraci změn do celého životního cyklu projektu (Schwalbe 2007).
1.4.1 Předprojektová fáze
Důležité je uvědomit si, že ve fázi iniciace projektu dochází k rozhodnutí, které říká, že za dosažením určitého cíle je potřeba realizovat projekt. Je tedy nutné stanovit globální cíl projektu a analyzovat projektové prostředí pomocí předprojektových studií.
Předprojektové studie lze pochopit jako obecné posudky sloužící převážně pro rozhodnutí, zda opravdu konkrétní projekt realizovat. Tyto posudky jsou později rozpracovány a zpřesňovány (Doležal a kol. 2016).
Do obsahu předprojektové fáze se dle (Skalický a kol. 2010) se zpravidla zařazuje identifikace projektové příležitosti tzv. studie příležitostí (Opportunity Study) a studie proveditelnosti (Feasibility Study).
Studie příležitosti
Studie příležitosti stojí na neustálém sledování a vyhodnocování podnikatelského okolí, které zahrnuje například sledování poptávky po produktech a službách, vyhodnocení projektových příležitostí a rizik, sledování nových inovací v oboru a podobně. Výstupem této studie je soubor zmíněných poznatků, kterým je třeba v budoucnu věnovat pozornost, ale také těch, kterých se vyvarovat, jelikož by vedly k velkým rizikům či malé efektivnosti vloženého kapitálu (Skalický a kol. 2010).
Z interního hlediska se spolu s výše uvedenými výstupy ve studii příležitosti objevují také první formulace obsahu projektu, finanční propočty či disponibilita personálních zdrojů (Doležal a kol. 2009).
Studie proveditelnosti
Studie proveditelnosti představuje nejdůležitější část předprojektové fáze, jinak také technickoekonomická studie. Jedná se především o rekapitulaci cílů, analýzu současného stavu a rozhodnutí o nejvhodnější variantě řešení daného projektu. Technickoekonomická studie zahrnuje také podrobnější finanční analýzu projektu, dále rozpad technického řešení, nároky na koncové uživatele a podobné praktické aspekty, které je třeba definovat před samotným spouštěním projektu. Tato studie se také zabývá hlavními reakcemi na nejbezpečnější rizika projektu či například dopadem investice na životní prostředí (Skalický a kol. 2010).
Doležal a kol. (2016) tvrdí, že v některých případech, pokud se jedná o malý projekt, je zpracována pouze předprojektová úvaha, která kombinuje výše uvedené postupy a dokumenty. Obecně v této fázi je třeba dosáhnout odpovědí na strategické otázky – odkud jdeme, kam chceme dojít, jakou cestu zvolíme, proč chceme projekt realizovat a zda je realizace vůbec smysluplná. Po schválení studie proveditelnosti nemusí být projekt spuštěn okamžitě, ale je možné, že management čeká na vhodnou dobu spuštění projektu. Předprojektová fáze tímto končí a ve vhodný okamžik je projekt spuštěn zahajovací fází či uvedením projektu.
1.4.2 Projektová fáze Plánování projektu
Projektová fáze začíná uvedením, nebo také představením projektu, v tuto chvíli je zpracována zakládací identifikační listina projektu - Project Charter, která by měla být doplněna o definici předmětu projektu. Po definici těchto základních dokumentů a sestavení základního řídícího týmu je přikročeno k fázi řízení projektu „plánování“, kde jsou projektové plány detailně rozpracovány. Tyto plány spolu s vypracováním harmonogramu projektu tvoří základní a nezbytné dokumenty Plánu řízení projektu - Project Management Plan (Doležal a kol. 2016).
Podle Schwalbe (2007) je Plán řízení projektu třeba „ušít“ na míru, proto se malé projekty spokojí s plánem řízení projektu, obsahujícím chartu projektu (zakládací listinu), stanovení rozsahu a Ganttův diagram. Plán by v každém případě měl být tak podrobný, jak je pro daný projekt třeba. V základním přehledu projektu bychom přinejmenším měli najít název projektu a jeho stručný popis, jméno zadavatele, jméno manažera projektu, jména klíčových členů týmu, ucelené části projektu, seznam důležitých referenčních materiálů, organizační diagramy, odpovědnosti v projektu, cíle managementu, kontroly projektu, řízení rizik, personální zajištění projektu a technické procesy. V další části plánu řízení projektu by měly být rozpracovány klíčové pracovní balíčky, přehled časového plánu, podrobný časový plán, přehled rozpočtu, podrobný rozpočet a ostatní informace související se zmíněnými položkami obsahu.
Plán řízení projektu doprovází projekt v celé jeho životnosti. Tento soubor je základním dokumentem shrnujícím metody řízení daného projektu, rozdělování finančních toků, čerpání nákladů, časový přehled, řízení rizikových situací, řízení změn, kontroly postupu práce a v neposlední řadě slouží jako zdroj informací pro zákazníka projektu (Svozilová 2011).
Jednotlivé plány projektu jsou teoreticky i prakticky podrobněji popsány v mé bakalářské práci na téma „Projekt a jeho plán“.
Realizace projektu
Po schválení Plánu řízení projektu přejdeme k fyzické realizaci projektu. Tato fáze vyžaduje aktivní řízení, reporting, monitorování a kontrolu projektu a všechny dílčí aktivity, které je třeba vykonat a byly naplánovány podle Plánu řízení projektu za účelem dosažení výsledného produktu. Lze tedy říci, že v této fázi dochází k přeměně projektových plánů na realizaci (Doležal a kol. 2016).
Svozilová (2016, str. 199) uvádí k procesu řízení projektových prací:
„Vlastní řízení v průběhu projektu a koordinace je souhrnem všech aktivit, které jsou zaměřeny na výkon, časování a sladění interakcí plánovaných prací v projektu a jejich integraci do podoby předepsané v Definici předmětu projektu.“
Ukončení projektu
Výstupy výsledného projektu je poté třeba předat zákazníkovi, k tomu slouží předávací protokol. V ideálním případě, pokud jsou výstupy akceptovány, a to prostřednictvím
akceptačního protokolu, směřují k ukončení projektové fáze, ve které jsou ukončeny všechny projektové procesy a dochází k vytvoření projektové zprávy, jež vede ke zpětnému vyhodnocení projektu v poprojektové fázi (Doležal a kol. 2016).
Schwalbe (2007) uvádí k procesu ukončení projektu následující aktivity, které je třeba vykonat a vedou k ukončení projektu:
- administrativní postupy pro ukončení, - smluvní postupy pro ukončení,
- finální produkt, služba nebo jiný výsledek projektu, - procesní aktiva v organizaci (projektové dokumentace).
1.4.3 Vyhodnocovací fáze
Vyhodnocovací fáze nebo také „poprojektová“ navazuje na ukončení projektu v projektové fázi. Nyní už dochází k vyhodnocení průběhu projektu a také jeho přínosů.
Tyto výstupy je třeba zanalyzovat a poučit se z chyb, které je třeba při příštích projektech neopakovat. Oproti tomu pozitivní zkušenosti a poznatky z ukončeného projektu je nutné využít pro další příležitosti. K tomu slouží dokument sběr poučení (lessons log), jenž je místem pro zaznamenávání pozitivních či negativních zkušeností z projektu (Doležal a kol. 2016).
1.5 Řízení projektů v IT
Tato práce je zaměřena na agilní projektový management, který se převážně používá v oblasti informačních technologií, a to hlavně při řízení vývoje software. Projekty vývoje softwaru mohou být velice rozmanité. Od malých projektů, které je schopné dodávat malý projektový tým, až po velké projekty zahrnující stovky členů, analyzující podnikatelské potřeby a vytvářející nový software. Je na charakteristice konkrétního projektu, do jaké míry je třeba příslušný software upravovat, nastavovat nebo vytvořit zcela nový software na míru zákazníkovi. Některé projekty tohoto typu požadují i vzájemnou interakci mezi několika aplikacemi. S většími projekty souvisí také dodávky příslušného hardware a jeho nastavení. Je tedy na schopnostech a zkušenostech projektového manažera příslušné fáze IT projektu uzpůsobit potřebám konkrétního projektu (Schwalbe 2007).
Projekty v IT při nevhodně zvoleném modelu řízení neplní rozpočet nebo nejsou dodávány včas. Častým problémem je nedostatečná definice projektu ze strany požadavků zákazníka, jelikož zákazník má mnohdy jen malou představu o tom, co tvoří výsledný produkt. V tradičním přístupu řízení projektů softwarové firmy nutí své zákazníky předem přesně definovat požadavky, jež zpracují analytici a odešlou pracovníkům do vývojového oddělení, kde separátně probíhá samotný vývoj (Šochová a Kunce 2014). Naproti tomu v agilním přístupu k řízení projektů většinou nejsou požadavky definovány přesně, ale upřesňují se v průběhu projektu za spoluúčasti zákazníka (Nicolas a Steyn 2017).
Přístupy k řízení (nejen) IT projektů:
• Tradiční (vodopádový) přístup,
• Agilní přístup.
2 Tradiční vodopádový přístup řízení projektů
Základem vodopádového způsobu řízení projektů je pevně daný cíl projektu, který je definován už při zadávání projektu a má jasně dané řešení problému. Toto řešení je plně pochopeno a známo projektovému týmu, jež se se řídí určeným plánem, který vede ke splnění zadaného cíle a prochází přesně stanovenými postupnými fázemi projektu (Wysocki 2013).
Schwalbe (2014) nazývá životní cyklus tradičně řízených projektů jako prediktivní životní cyklus, z něhož je možné předem předvídat jednotlivé kroky projektu, přibližný rozsah, lze předem předvídat hrubý časový plán a s tím spojené náklady. Dále říká, že tradiční způsob řízení projektů se používá především v projektech, kde je třeba intenzivně kontrolovat rizika, a tedy i na projektech, které jsou velmi komplexní, mají velký rozsah a vysoké náklady. Díky lineárnímu přístupu u obsáhlejších projektů je tedy jednodušší zajistit dodání výstupů jednotlivých fází a tím i dodání celého projektu.
2.1 Životní cyklus projektu - klasický (vodopádový) přístup
Goodpasture (2016) tradiční přístup v souvislosti s životním cyklem označuje PDLC (Plan-Driven Life Cycle), což v překladu znamená plánem-řízený životní cyklus. Dále tvrdí, že řada autorů uvádí jako příklad životního cyklu projektu softwarový vývoj, jež má specifické fáze projektu. Lze si tedy místo projektu vývoje softwaru dosadit i jiný projekt a jeho fáze.
Bassil (2012) ve svém článku o simulaci vodopádového modelu řízení definuje tradiční způsob při plnění jednotlivých projektových fází jako inkrementální postup shora dolu, který graficky připomíná vodopád. Z definice tedy vyplývá, že není možné vrátit se k předcházející fázi při nedokončení fáze aktuální. Jednotlivé fáze projektu na sebe lineárně navazují a celkově tedy vodopádový přístup tvoří sekvenční model. Dále uvádí fáze SDLC (Software Development Life Cycle) následovně: analýza, design, implementace, testování, údržba. Tyto fáze jsou spolu s principem vodopádového řízení projektu znázorněny na obrázku č. 3, kde však podle Casteren (2017) analytické fázi předchází sběr požadavků na systém a software. Bassil (2012) je uvádí pod jednou fází – analýza. Fáze implementace představuje Program Design a Coding podle obrázku.
Obrázek č. 3: Vodopádový přístup vývoje software
Zdroj: Casteren (2017) Popis jednotlivých fází
Analýza – často uváděná jako Software Requirement Specification (SRS), tedy specifikace požadavků na software zahrnuje obsáhlou analýzu, jež definuje funkční i nefunkční požadavky na software.
Design – tvoří proces plánování a návrhu softwarového řešení.
Implementace (kódování) – představuje realizaci zákaznických specifikací do konkrétní softwarové podoby.
Testování – proces, který kontroluje stabilitu softwarového řešení a zároveň validuje schopnost programu řešit daný problém.
Údržba – rozumíme jí proces modifikace softwarového řešení po jeho dodání, jež zpravidla představuje opravení nově vzniklých chyb nebo zvýšení výkonu (Bassil 2012).
3 Agilní přístup řízení projektů
Tradiční vodopádový způsob řízení projektu vykazuje, především při vývoji software, řízení revolučních technologií a inovativních produktů, určité nedostatky. Tyto nedostatky se projevují především jako omezenost flexibilně reagovat na náhlé změny v projektu, jež by jinak vedly ke zpoždění dodávky projektu, zvýšení nákladů nebo změně rozsahu (Schwalbe 2014). Požadavky na vývoj, jako jsou specifické zákaznické potřeby, rychlost vývoje, vysoká kvalita, správná funkčnost, předvídatelnost, stabilita, za předpokladu nízkých nákladů tvoří tzv. doručenou hodnotu pro zákazníka. Pro zabezpečení doručené hodnoty pro zákazníka vznikly agilní hodnoty, principy a metody.
Společně utvářejí agilní přístup pro řízení projektů, někdy také agilní projektový management (Highsmith 2004). Agilní přístup vychází z předpokladu, že nemusí být znám předem daný přesný rozsah projektu či postup k dosažení projektového cíle, avšak snaží se co nejpřesněji definovat požadavky zákazníka, a to i v průběhu projektu.
Předpokládá určitou flexibilitu v projektovém plánování, kdy specifikace projektu jsou často dodatečně upraveny (Nicolas a Steyn 2017). Agilní přístup byl tedy vytvořen k rychlé reakci na změny v průběhu projektu. Agilní řízení doprovází agilní metody, jež se vyznačují inkrementálním, pružným a iterativním způsobem vývoje a řízení (Schwalbe 2014).
Původy agilního přístupu datuje Hillel Glazer a kol. (2008) před padesátá léta 20. století a přisuzuje je vědě a výzkumu, především NASA (National Aeronautics and Space Administration) a US Air Force (Letectvo Spojených Států Amerických) ve spojení s aktivitami týkajícími se spíše hardwaru, ale také softwaru. Prvního předchůdce agilního přístupu uvádí Dr. W. Edwardse Deminga, který začal propagovat (PDSA) model, tedy Plan-Do-Study-Act cyklus, v překladu Plánuj-Dělej-Studuj-Jednej.
Augustine (2005) tvrdí, že agilní projektový management má kořeny v CAS (Complex Adaptive Systems), jenž definuje projekt jako komplexní systém skládající se z mnoha interakčních činitelů, které se řídí jednoduchými, lokalizovanými pravidly s konstantní zpětnou vazbou. Celý systém se vyznačuje sebe-organizací, kolektivní inteligencí a sjednocením. Adaptivní systémy spočívají v tom, že reagují různě za různých okolností a společně se vyvíjejí s prostředím.
Podle Šochová a Kunce (2014) agilní znamená žít agilní filozofií, která značně zasahuje
iterativní, zábavný, hravý, komunikativní a rychle reagující na změnu. Agilní především představuje orientace na kvalitu výsledku, před dodržováním striktních procesů a vítá změnu, před předem stanoveným plánem.
Highsmith (2010 s.18) uvádí k základním agilním hodnotám dvě definice, které v překladu znějí:
„Agilita je schopnost vytvářet a být připraven na změnu za účelem získání zisku v dynamickém podnikatelském prostředí.“
„Agilita je schopnost najít balanc mezi flexibilitou a stabilitou.“
Principy agilního přístupu a hlavní hodnoty jsou popsány v kapitole 3.2 Agilní Manifest.
3.1 Životní cyklus projektu - agilní přístup
Životní cyklus vývoje softwarového projektu SDLC řízený agilním přístupem je znázorněn na obrázku č. 4.
Obrázek č. 4: Spirálovitý životní cyklus projektu
Zdroj: (Nicolas a Steyn 2017)
Z obrázku je patrné, že životní cyklus projektu v agilním pojetí probíhá tzv. spirálovitě, kde jednotlivé fáze představují iterace, které mají opakující se stavbu a opakují se v rozmezí dní až měsíců (Schwalbe 2014). Podobně jako ve vodopádovém přístupu řízení zde figurují fáze životního cyklu vývoje software, jako je analýza požadavků, vývoj, testování apod.. Po každé ukončené iteraci však následuje zhodnocení a poučení se
z iterace předchozí a plánování další iterace s nově vzniklými požadavky. Princip tvoří samotný cyklus, kde na konci iterace jsou „ideálně“ uvolňovány částečné prototypy, které se inkrementálně vyvíjejí do podoby finálního produktu (Nicolas a Steyn 2017).
V praxi se často při komplexních projektech, které zahrnují větší balíček i nevývojových operací, používá kombinace vodopádového životního cyklu s prvky agilních metodik použitých v určité fázi projektu a vznikají tak hybridy zmíněných přístupů řízení.
3.2 Agilní Manifest
V únoru roku 2001 v americkém městě Snowbird v Utahu se sešlo sedmnáct hlavních představitelů softwarového inženýrství jako Alistair Cockburn, Jim Highsmith, Ken Schwaber, Kent Beck, Andrew Hunt, Mike Beedle, James Grenning a další. Představitelé různých metodik se shodli na základních principech agilního myšlení, vytvořili Agilní Alianci a výstupem této schůzky bylo vytvoření Agilního Manifestu vývoje software (Cockburn 2002). Text Agilního Manifestu je uváděn v řadě dalších literaturách, jako například (Goodpasture 2016, s. 4) a v doslovném překladu uvádí:
„Objevujeme lepší způsoby, jak vyvíjet software, pracujeme podle těchto způsobů a pomáháme ostatním takto pracovat. Při této práci jsme dospěli k následujícím hodnotám:
• Jednotlivci a vzájemné ovlivňování je více než procesy a nástroje
• Fungující software je více než obsáhlá dokumentace
• Spolupráce se zákazníkem je více než vyjednávání o smlouvě
• Reagování na změny je více než dodržování plánu.
Jakkoli jsou body napravo hodnotné, bodů nalevo si ceníme více“
Pro upřesnění agilního přístupu bylo dále definováno 12 principů, které v překladu znějí:
• Naší nejvyšší prioritou je uspokojit zákazníka včasným a průběžným dodáváním hodnotného softwaru.
• Vítáme změny v požadavcích, a to dokonce i v pozdější fázi vývoje. Agilní procesy podporují změny vedoucí k zákazníkově konkurenční výhodě.
• Dodáváme často fungující software, a to v intervalech několika týdnů až měsíců,
s preferencemi kratší periody.
• Lidé z byznysu a vývojáři musí spolupracovat denně po celou dobu projektu.
• Budujeme projekty kolem motivovaných jednotlivců. Vytváříme jim prostředí, podporujeme jejich potřeby a důvěřujeme, že svou práci dokončí.
• Nejúčinnější a nejefektivnější metodou sdělování informací, jak vývojovému týmu, tak i uvnitř něj, je osobní konverzace (komunikace tváří v tvář).
• Fungující software je hlavním měřítkem pokroku.
• Agilní procesy podporují udržitelný rozvoj. Sponzoři, vývojáři i uživatelé by měli být schopni udržovat trvale udržovat krok s odvětvím.
• Neustálá pozornost, věnovaná technické dokonalosti a dobrému designu, zvyšuje agilitu.
• Jednoduchost–umění maximalizovat množství nevykonané práce–je nezbytným základem.
• Nejlepší architektury, požadavky a návrhy se objevují ze samo-organizujících se týmů.
• Tým se pravidelně zamýšlí nad tím, jak se má stát efektivnějším, a následně tak koriguje a přizpůsobuje své chování a zvyklosti“ (Goodpasture 2016, s. 6.) Agilní Manifest takto efektivně popisuje principy agilního projektového managementu.
Jak je z principů Agilního Manifestu patrné, být agilní neznamená jen využívat zvolenou agilní metodu, nýbrž přistoupit na určité zásady, které do hloubky mění tradiční podnikovou kulturu a chování podniku.
4 Srovnání tradičního vodopádového přístupu a agilního přístupu
V tabulce č. 2 je tradiční vodopádový přístup srovnán s moderním agilním přístupem řízení projektů podle Serradora a Pinto (2015).
Tabulka č. 2: Porovnání tradičního a agilního přístupu
Tradiční přístup Agilní přístup Základní předpoklad Systémy jsou plně
specifikovatelné,
předpověditelné. Projektové plány jsou tvořeny pečlivým a rozsáhlým plánováním.
Vysoce kvalitní adaptivní software, vyvinut malými týmy používající principy
kontinuálního zlepšování a testování, založeno na rychlosti zpětné vazby a změně.
Manažerský styl Řízení a kontrola Vedení a spolupráce
Řízení znalostí Explicitní Tacitní
Komunikace Formální Neformální
Vývojový model Orientovaný na životní cyklus projektu
Orientovaný na model evolučního doručování Požadovaná organizační
struktura
Byrokratický, velmi formální, zaměřený na rozsáhlé organizace
Organický (flexibilní a participativní), zaměřený na malé a střední podniky.
Kontrola kvality Striktní kontrola, důrazné plánování a testování
Průběžná kontrola požadavků, návrhu a řešení; kontinuální testování
Zdroj: (Serrador a Pinto 2015) Zpracoval: Petr Flaška, 2019
Casteren (2017) uvádí charakteristiky jednotlivého způsobu řízení:
1) Velikost projektů – vodopádový přistup je vhodnější k řízení obsáhlých projektů více, nežli agilní metodiky.
2) Vztah k zákazníkovi – využití agilních metod je nejvíce efektivní při přímém zapojení zákazníka a vývojového týmu. Naproti tomu vodopádový přístup využívá příslušné dokumentace k řízení vztahů se zákazníkem.
3) Plánování a kontrola – formální plánování, koordinace, kontrola a sledování se vyznačuje ve vodopádovém stylu řízení. Agilní přístup spoléhá více na plánovací část samotnou než na výsledné formální dokumenty.
4) Komunikace – agilní metodiky upřednostňují komunikaci „face to face“, zatímco vodopádový způsob řízení vyžaduje dokumentovanou komunikaci.
5) Požadavky – formální vodopádový model těžko reaguje na rychle se měnící požadavky, zatímco agilní přístup je navržen pro rychlou reakci na změny.
6) Vývoj a testování – agilní přístupy upřednostňují maximalizaci hotové práce.
Naproti tomu vodopádový přístup si zakládá na architektuře software a příslušné dokumentaci.
7) Zákazník – agilní přístupy vyžadují aktivní, oddané, znalé zákazníky, kteří reagují průběžně. Vodopádový přístup vyžaduje detailní spolupráci hlavně na začátku a konci projektu.
8) Vývojáři – vodopádový přistup se spokojí s vývojáři, kteří se rádi řídí plánem, mají adekvátní znalosti. Agilní přístup vyžaduje vývojáře talentované, schopné spolupráce, komunikativní a flexibilní.
9) Podniková kultura – agilní metody jsou úspěšné více v podnikové kultuře
„chaosu“ než v organizacích řízených řádem, vodopádový přístup právě naopak.
4.1 Porovnání simulace tradičního řízení a agilního řízení Obrázek č. 5: Simulace Waterfall, Scrum, Kanban
Zdroj: Cocco a kol. (2011)
Uvedený graf vychází ze simulace tradičního přístupu řízení projektů a agilních metodik (Scrum, Kanban) v programu Vensim. Osa X představuje množství hodin a osa Y vyobrazuje množství práce, které je třeba vykonat v závislosti na změnách požadavků. Z obrázku je patrné, že při určitých změnách v požadavcích je Scrum a Kanban (přerušované osy) tým efektivnější, jelikož je schopný na změny reagovat průběžně a tím docílit i dřívějšího splnění patřičných změn. Naproti tomu vodopádový přístup je schopný zavést změnu až při dokončení určité fáze projektu, a tím prodlužuje čas dodání příslušných změn, ale i množství nahromaděných nových požadavků, na které je třeba reagovat (Cocco a kol. 2011).
Uvedená simulace dokazuje schopnost agilních metodik rychleji a efektivněji reagovat na změny v požadavcích, což je jeden z hlavních důvodů vzniku agilních metodik.
5 Agilní metodiky
Clinton Keith (2010) ve své knize Agile Game Development with Scrum popisuje jako jeden z důvodů odklonění se od tradičního modelu řízení v herním průmyslu nedostatečné reakce na inovace. Vytvořit plnohodnotný počítačový herní titul může trvat několik měsíců až let. Než tedy produkt dorazí na trh, je nutné, aby byl schopný pojmout stávající, případně i budoucí inovace, jelikož investor nechce investovat do výrobku, který postrádá inovace a nejnovější dostupné technologie. Dalším z důvodů je redukce nákladů v odvětví, protože ne všechny herní tituly vytvoří dostatečný zisk, aby byly pokryty veškeré náklady, které se týkají se především stráveného času vývojovým týmem. Dále také uvádí velký pracovní tlak na vývojáře, jenž byl ve standardním modelu vytvářen.
Tlak spočíval především v práci přesčas. Průměrný vývojář tak opouštěl odvětví do deseti let a průmysl tedy nemohl stavět na zkušenostech a vůdcovství. Přelom přišel s vytvořením nových herních platforem a produktů, jako je např. IPhone nebo další online distribuční modely prodeje aplikací a her. Tyto platformy vytvořily nové příležitosti pro malé kreativní, pružné a talentované vývojářské teamy, které si začaly osvojovat právě agilní metodiky jako jsou Scrum, Extreme Programming, Lean a Crystal Clear. Právě metodika Scrum je v následující části podrobně vysvětlena.
5.1 Scrum
Schwaber (2003) uvádí ve svém článku Scrum and The Perfect Storm, že pokud organizace selhává v dosažení svým cílů, není to nutně proto, že její zaměstnanci nepracovali dostatečně. Více častěji organizace nedosahuje svých cílů právě proto, že byla narušena ostatními faktory a ztratila své soustředění na stanovené cíle. Hlavním důvodem, proč byla zformována metodika Scrum, je to, aby pomohla týmu soustředit se na jeho úkoly a pomohla mu předcházet zmíněnému selhání. Na žádost Object Management Group (společenství standardů oblasti počítačového průmyslu), Jeff Sutherland a Ken Schwaber sepsali své poznatky o řízení ve vývoji softwarových produktů a roku 1995 představili metodiku Scrum.
Jim Highsmith (2002, str. 137) tvrdí, že Scrum pomáhá týmu držet se klíčových projektových aktivit. V překladu uvádí: „Dělejte méně důležitých věcí správně a projekt bude úspěšný. Pokud ale uděláte tyto věci špatně, nezáleží na tom, kolik stovek dalších věcí uděláte správně, projekt nebude úspěšný.“
Metodika Scrum vychází přednostně z iterativního a inkrementálního přístupu, jelikož přijímá to, že proces vývoje je nepředvídatelný. Změny rozsahu projektu, technologie, funkcionality, nákladů a plánu jsou akceptovány, kdykoli je to vyžadováno (Schwaber 1996). Metoda dopomáhá vytvářet organizace, které jsou schopné vyvíjet software na míru zákazníka rychle, lépe a flexibilně reagovat při zvyšování stupně kontroly a snižování celkových projektových rizik (Schwaber 2002). V současnosti je Scrum nejpoužívanější agilní metodikou, která si zakládá na týmové spolupráci, zapojení zákazníka a pravidelné zpětné vazbě, jež se provádí v krátkých časových intervalech, kterým se říká Sprint (Šochová a Kunce 2014). Fáze Scrumu lze na základě (Schwaber 2002) přirovnat k spirálovitému životnímu cyklu produktu.
Autoři (Keith 2010, Goodpasture 2016) a další uvádějí různé principy a předpoklady Scrum metodiky. V souhrnu vycházejí především z principů Agilního Manifestu, kterému je věnována kapitola 3.2 Agilní Manifest. Schwaber a Sutherland (2017) k principům fungování Scrumu navíc uvádějí tři hlavní pilíře: transparentnost, inspekce, adaptace.
K fungování Scrumu Schwaber (1996, s. 3) v překladu uvádí:
„Scrum rozkládá obsáhlé produkty do menších zvládnutelných dílů – několik produktových vlastností, které malé týmy vytváří v rámci několika měsíců.
Velkým týmům Scrum umožňuje pracovat jako malé týmy – rozdělením práce na části, dále týmy pokračují v práci paralelně, ale postupně se synchronizují a stabilizují, výstupem jsou produktové inkrementy. Průběžně při těchto činnostech hledají a napravují problémy.“
Pro správné fungování Scrum metodiky je podle Šochová a Kunce (2014) vhodné implementovat artefakty tzv. Agilního programování jako jsou Pair Programming (programování ve dvojici, kde jeden člen navrhuje postup a druhý programuje), Review (kontrola naprogramované části jiným členem týmu), Sdílený kód (možnost úpravy kódu jinými členy týmu), Automatické testování, Jednoduchý design, Kontinuální integrace kódu apod..
5.1.1 Základní fungování metodiky Scrum Obrázek č. 6: Kostra Scrum metodiky
Zdroj: (Schwaber 2007)
Obrázek č. 5 znázorňuje základní fungování Scrumu. Spodní cyklus tvoří iterace vývojových aktivit, které cirkulují jedna za druhou. Vstupem iterace je seznam požadavků a činností na produkt zvaný Product Backlog a výstupem je přírůstek výsledného produktu. Horní cyklus představuje denní kontroly, které probíhají v průběhu iterace a kde se jednotliví členové týmu scházejí za účelem kontroly průběhu aktivit (Schwaber a Sutherland, 2017).
5.1.2 Role Scrum Týmu
Jednotlivé role Scrum týmu tvoří Product Owner (někdy uváděn jako Product Master), The Development Team (v překladu vývojový tým, často uváděn jen jako tým) a Scrum Master (Schwaber, 2007). Scrum Team lze nazvat „self-organised“ (sebe-organizační), což jednoduše znamená, že tým si sám určuje, jak nejlépe dosáhne zadaných úkolů.
Scrum tým je navržen tak, aby optimalizoval flexibilitu, kreativitu a produktivitu, dodával produkt iterativně, inkrementálně a maximalizoval příležitosti pro zpětnou vazbu (Schwaber a Sutherland 2017).
Scrum Master
Scrum Master zodpovídá za podporu a fungování Scrum metodiky, tak jak je definována v teorii, nebo organizací. Pomáhá každému členu Scrum týmu pochopit principy, pravidla, fungování Scrumu a představuje mentora pro celý Scrum tým. Slouží také pro zřetelnou komunikaci s ostatními stakeholdery mimo vývojový tým. Ve vztahu k Product Ownerovi Scrum Master zajišťuje, že cíle, rozsah a struktura produktu jsou, pokud je to možné, plně pochopeny všemi ve Scrum týmu. Pomáhá týmu jasně a stručně pochopit Product Backlog položky. Je znalý, praktikuje agilní principy a umožňuje spuštění Scrum událostí, když jsou vyžadovány. V rámci organizace Scrum Master napomáhá adaptaci Scrum metodiky, plánuje Scrum implementaci v organizaci. Dále spolupracuje s dalšími Srum Masters v organizaci za účelem zvýšení efektivity aplikace Scrum metodiky. Ve vztahu k vývojovému týmu figuruje jako „coach“ agility a multifunkčnosti, pomáhá organizovat tým ve společnosti zavádějící metodiku Scrum. Odstraňuje překážky, které by mohly ovlivnit týmový postup. Svojí funkcí tak pomáhá týmu vytvářet hodnotný produkt (Schwaber a Sutterland 2017). Ve srovnání s klasickým projekt manažerem Scrum Master nerozhoduje za tým. Může členům týmu určovat, co mají dělat, ale nerozhoduje o způsobu dosažení cíle (Nicolas a Steyn, 2017). Keith (2010) uvádí odpovědnost za monitoring postupu práce, za plánování týmových retrospektivních a hodnotících schůzek. To, jestli je Scrum Master členem týmu, určuje potřeba v konkrétní společnosti. Podle Šochové a Kunceho (2014) je role Scrum Mastera pro úspěch produktu klíčová. Tato role vyžaduje komunikativního, schopného člověka, který vnímá potřeby týmu, umožňuje klidný průběh práce, dokáže moderovat, koučovat a zároveň zvyšuje motivaci, kvalitu a efektivitu týmu. Ve shrnutí je zodpovědný vytvoření „self-organized“
týmu.
Product Owner
Product Owner představuje roli vlastníka produktu, definuje vize výsledného produktu a odpovídá za transparentní komunikaci mezi Scrum týmem, zákazníkem a společností (stakeholders). V organizaci práce určuje priority jednotlivých činností nebo funkcionálních celků, na kterých tým pracuje. Má na starosti ROI (Return On Investment) – návratnost projektu (Šochová a Kunce 2014). Je zodpovědný za maximalizaci hodnoty produktu, která vychází z práce vývojového týmu. Činnosti na projektu jsou dány prostřednictvím Product Backlogu a musí být transparentně
a srozumitelně formulovány. Požaduje-li tým změnu v Product Backlog, musí se obrátit právě na Product Ownera. Jeho rozhodnutí by mělo být respektováno organizací, jelikož právě on určuje požadavky na vývojový tým (Schwaber a Sutherland, 2017). Product Owner také neustále aktualizuje Product Backlog a diskutuje ho s vývojovým týmem (Nicolas a Steyn 2017). Product Ownera tvoří osoba nebo tým (interních) zákazníků. Ve společnosti, vytvářející konkrétní produkt, to může být produkt manažer. Často je Product Owner tvořen více manažery a technickým personálem (případně vývojovým týmem), společně se pak podílejí na výše zmíněných činnostech a výstupech (Highsmith 2002).
The Development Team / Project Team
The Development Team v překladu znamená vývojový tým. Nicolas a Steyn (2017) uvádí v obecnějším použití Project Team – projektový tým. Tento tým se skládá z profesionálů, jejichž zaměření je dáno převážně charakterem projektu. Mohou to být analytici, programátoři, testeři a další. Členové týmu primárně pracují na činnostech ze svého oboru, ale podílejí se i na ostatních činnostech, jelikož se očekává, že tým si navzájem pomáhá, kdy je třeba. Další z důležitých vlastností (Šochová a Kunce 2014) je sdílená znalost, multifunkčnost a vzájemná zastupitelnost členů, v případě jejich absence. Podle Schwaber a Sutherland (2017) tento tým dodává inkrement v podobě „hotových“ činností na konci každého Sprintu, za které společně členové týmu odpovídají. Tým je strukturován a pověřen organizací tak, aby fungoval „self-organized“ a dokonce ani Scrum Master nemá právo určovat, jakým způsobem tým přemění Product Backlog do požadovaného výstupu. Scrum neurčuje specifické tituly uvnitř projektového týmu, bez ohledu na to, co daná osoba vykonává. Projektový tým už dále netvoří žádné sub-týmy.
Velikost týmu určuje charakter projektu a činnosti, které vedou k úspěšnému plnění práce v průběhu sprintu. Obvykle je tým tvořen třemi až devíti členy, méně či více se jeví jako kontraproduktivní.
5.1.3 Scrum události
Předem dané události se ve Scrumu používají k vytvoření pravidelnosti a k minimalizaci potřeby schůzek, které nejsou definovány ve Scrumu. Tyto události mají danou maximální dobu trvání. Pevné trvání má Sprint, jakmile začne, nelze měnit jeho časový údaj. V případě ztráty účelnosti použití Sprintu lze Sprint zrušit (k tomu dochází ve specifických případech). Ostatní události mohou skončit dříve vždy, když je dosaženo účelu události (Schwalbe a Sutherland 2017). Každý Scrum událost zvyšuje
transparentnost tak, že tým může spolehlivě kontrolovat postup práce a přizpůsobit plány k dosažení požadovaného výstupu (Scrum Alliance 2019).
Sprint
Iterace jsou jedny ze základních principů agilních metodik. Nejpoužívanější iterací je Sprint. Tvoří jádro fungování Scrumu. Z pozorování bylo zjištěno, že opakující se věci jsou pro lidi z psychologického hlediska příjemnější a snadněji si na ně zvyknou. Proto je ve Scrumu celý vývojový proces rozdělený na jednotlivé cykly – Sprinty (Šochová a Kunce 2014). Sprint je maximálně měsíc trvající časový interval, kdy je týmem vytvořena „hotová“ produktová část v podobě inkrementu, který představuje určitou funkční část produktu, nebo produktový prototyp. Déle trvající Sprinty mohou vést k většímu riziku, k nárůstu komplexnosti řešeného problému a k změně definice toho, co má být v rámci Sprintu vytvořeno. Nový Sprint začíná hned po shrnutí a zhodnocení Sprintu minulého. Sprint se skládá z plánování Sprintu, Daily Scrumu, práce na vývojových činnostech, Sprint Rewiew a Sprint Retrospective. V průběhu Sprintu se neprovádí žádné dramatické změny, které by vedly ke změně jeho cíle (Schwaber a Sutherland 2017).
Sprint Planning (Kick-off) Meeting / Plánování Sprintu
Plánování Sprintu je společnou prací celého Scrum týmu, který se schází před začátkem Sprintu. Během této činnosti je naplánováno, čeho má být v průběhu sprintu dosaženo.
Plánování Sprintu odpovídá na otázku, jaký může být dodán inkrement v následujícím sprintu, a kolik a jaké práce je potřeba k jeho dodání (Schwaber a Sutherland 2017).
Vstupem do této činnosti jsou Product Backlog, poslední produktový inkrement, kapacita práce vývojového týmu a také jeho produktivita v minulém Sprintu. Výstupem poté Sprint Backlog, který je plánem pro plánovaný Sprint (Scrum Alliance 2019).
Daily Scrum (Daily Sprint, StandUp) Meeting
Tým se schází každý den v průběhu sprintu na cca 15 minut, aby zhodnotil průběh práce.
Slouží k diskuzi vývojového týmu za účelem rekapitulace toho, na čem pracovali členové den předtím a co bude jejich náplní v aktuální den, případně diskutují vzniklé komplikace (Nicolas a Steyn 2017). Scrum Master umožňuje každému členu týmu vyjádřit se, přičemž není účelem přijít s jakýmkoli řešením (Goodpasture 2016), avšak Daily Scrum slouží pro optimalizaci spolupráce a výkonosti týmu kontrolou vykonané práce od
posledního Daily Scrumu (Schwaber a Sutherland 2017).
Sprint Review
Sprint Review se koná na konci každého Sprintu z důvodu kontroly výsledného inkrementu a přizpůsobení Product Backlogu, pokud je třeba. V průběhu schůzky Scrum tým a stakeholders diskutují, čeho bylo ve Sprintu dosaženo, ale také čeho dosaženo nebylo. Meeting může trvat až několik hodin, záleží na velikosti Sprintu. Zúčastnění jsou pozváni Product Ownerem. Vývojový tým diskutuje o tom, co šlo dobře a co špatně v průběhu Sprintu, případně co zlepšit do následujícího Sprintu. Tým také odpovídá na otázky ohledně výsledného inkrementu. Product Owner míří diskuzi spíše k Product Backlog, případně termínu dodání produktu. Dochází k přehodnocení časové osy, rozpočtu, potencionální kapacity týmu, případně dalších požadavků na produkt (Schwaber a Sutherland 2017). Výsledek tvoří revidovaný Product Backlog. Sprint Review slouží k tomu, aby členové týmu sdíleli priority následujícího Sprintu (Scrum Alliance 2019).
Sprint Retrospective
Sprint Retrospective tvoří příležitost pro Scrum tým, za účelem sebekontroly a vytvoření plánu pro sebe zlepšení v následujícím Sprintu. Scrum Master zajišťuje, aby schůzka byla pozitivní a produktivní ze strany všech členů (Schwaber a Sutherland 2017). Sprint Retrospective tvoří finální událost Sprintu, odehrává se hned po Sprint Review. Nejdříve tým objasňuje, jak bylo práce ve Sprintu dosaženo, bere v potaz lidské vztahy, procesy a nástroje. Dále společně tým diskutuje, co by mohlo být předmětem zlepšení do dalšího Sprintu. Nakonec tým vytvoří zmíněný plán zlepšení vybraných aspektů (Scrum Alliance 2019).
5.1.4 Scrum Artefakty
Metodika Scrum používá artefakty, které jsou používány v průběhu Scrum procesu a jsou dále popsány.
Product Backlog
Product Backlog je tvořen seznamem všech požadavků, funkcí, zlepšení na systém nebo produkt, který je projektem vytvářen. Za jeho obsah, pořadí činností a dostupnost je zodpovědný Product Owner. Product Backlog je neustále aktualizován podle nově
