agilní vedení projektů - theses · 2015 _____ bc. kristýna kočová ... ipma b – projektový...
TRANSCRIPT
Univerzita Hradec Králové
Fakulta Informatiky a managementu
Katedra informačních technologií
Agilní vedení projektů
Diplomová práce
Autor: Bc. Kristýna Kočová
Studijní obor: Informační management
Vedoucí práce: doc. Ing. Vladimír Bureš, Ph.D.
Praha Srpen 2015
Prohlášení
Prohlašuji, že jsem tuto diplomovou práci pod vedením doc. Ing. Vladimíra Bureše, Ph.D.
vypracovala samostatně a v seznamu použité literatury jsem uvedla všechny odborné
zdroje a literaturu, z kterých jsem čerpala.
V Praze dne 19. 8. 2015
______________________________
Bc. Kristýna Kočová
Poděkování
Ráda bych poděkovala vedoucímu práce panu doc. Ing. Vladimíru Burešovi, Ph.D., za jeho
odborné rady a cenné připomínky, kterými přispíval při vypracování této diplomové
práce. Dále bych ráda poděkovala společnosti za povolení užití firemních metodik
a především kolegům Ondřeji Kavulovi a ing. Marku Endlicherovi za jejich odborné rady
a sdílení zkušeností.
Anotace
Cílem diplomové práce je identifikace Agilního vedení projektů a aplikace tohoto
vedení v telekomunikační společnosti. Teoretická část práce se věnuje charakteristice
základních pojmů projektového řízení, dále se zaměřuje na srovnání těchto řízení, jako
je waterfall a agile. Výzkumná část práce mapuje transformaci společnosti do agilního
vedení, které zavedla před třemi lety a dále analyzuje agilní principy za rok 2014 a první
pololetí roku 2015.
V závěru práce jsou uvedeny časté problémy a nedostatky, které se vyskytují při zavádění
agilních metod ve společnostech. Na základě těchto problému je zde závěrečné
doporučení pro implementaci agilních metod ve firmách.
Klíčová slova
agilní metodika, Scrum, Waterfall, telekomunikace, projekt, projektové řízení
Annotation
The aim of this Diploma thesis is the identification of Agile project management
and application management of the telecommunications company. The theoretical part
is focused on the characteristics of the basic concepts of project management, focusing
on a comparison of these proceedings, such as waterfall and agile. The research part
of this thesis is presented the agile transformation, which was introduced three years ago,
and analyzes agile principles for year 2014 and the first half of 2015.
In conclusion are given frequent problems and shortcomings that exist in implementing
agile methods in companies. On the basis of the problem is the final recommendations
for the implementation of agile methods in companies.
Keywords
agile approach, Scrum, Waterfall, telecommunication, project, project management
Obsah
1 Úvod ............................................................................................................................................................. 1
2 Teoretická východiska .......................................................................................................................... 2
2.1 Projektové řízení ............................................................................................................................ 2
2.1.1 Mezinárodní standardy projektového řízení .............................................................. 3
2.1.2 Projekt ....................................................................................................................................... 7
2.1.3 Fáze projektu .......................................................................................................................... 9
2.1.4 Projektový manažer .......................................................................................................... 11
2.2 Tradiční vodopádový model ................................................................................................... 12
2.2.1 Fáze vodopádového modelu .......................................................................................... 12
2.3 Iterativní metodiky a agilní hnutí ......................................................................................... 16
2.3.1 Rational Unified Proces (RUP) ...................................................................................... 17
2.3.2 Enterprise Unified Process (EUP) ................................................................................ 18
2.3.3 Agilní hnutí ........................................................................................................................... 19
2.4 Agilní metodiky ............................................................................................................................ 20
2.4.1 Příklady agilních metodik ............................................................................................... 21
3 Praktická část ........................................................................................................................................ 28
3.1 Cíl a metodologie práce ............................................................................................................ 28
3.2 Telekomunikační společnost .................................................................................................. 29
3.3 Projektová organizace ............................................................................................................... 31
3.3.1 Před agilní transformací .................................................................................................. 31
3.3.2 Po agilní transformaci ...................................................................................................... 32
3.4 Pilotní agilní projekt .................................................................................................................. 33
3.5 Agilní transformační program ............................................................................................... 35
3.5.1 Etapy agilní transformace ............................................................................................... 35
3.5.2 Evoluční modely agilní governance ............................................................................ 38
3.5.3 Finální model škálované agilní governace (SAFe) ................................................. 38
3.5.4 Zhodnocení výhod a nevýhod tohoto modelu škálovaného řízení ................. 41
3.6 Cíle transformace a jejich naplnění ...................................................................................... 42
3.6.1 Snížení TTM (Time to market) ukazatele ................................................................. 42
3.6.2 Kvalita dodávek................................................................................................................... 44
3.6.3 Flexibilita, reakce na změny a celková spokojenost business oddělení ........ 45
3.6.4 Kulturní změna – jak je nasazena agilní metodika ................................................ 50
4 Diskuze..................................................................................................................................................... 54
5 Závěr ......................................................................................................................................................... 56
Seznam použité literatury ......................................................................................................................... 58
Internetové zdroje ....................................................................................................................................... 59
Interní zdroje společnosti ......................................................................................................................... 60
Seznam použitých obrázků ....................................................................................................................... 61
Seznam tabulek ............................................................................................................................................. 61
Seznam grafů .................................................................................................................................................. 61
Seznam příloh ................................................................................................................................................ 62
1
1 Úvod
Každý den pracuje tisíce lidí na tom, aby právě jejich nabídka produktů a služeb byla
co nejzajímavější a aby upoutala oko vybíravého zákazníka. V dnešní době je trh
přesycený a přijít s novým nápadem je velice obtížné. Pokud však konkurence přijde
na trh s inovací či úplně novým produktem, musí nabídka na trhu reagovat okamžitě.
Vzhledem k neustálým tlakům na snižování nákladů a času na implementaci jsou firmy
mnohdy nuceni měnit své projektové řízení a jednotlivé fáze vývoje.
Diplomová práce popisuje jednotlivé přístupy projektového managementu. Od tradičního
vodopádového modelu, přes méně známé iterativní metodiky a poměrné mladé agilní
metodiky, se kterými se firmy dnes mnohem častěji potkávají a osvojují si právě jejich
principy. Tyto principy pak nahrazují již zaběhlé vodopádové řízení. Firmy
se transformují do flexibilnějšího a levnějšího modelu vývoje. Ne vždy však zvolí správnou
cestu transformace.
Práce mapuje změny z vodopádového modelu vedení projektů do agilních metodik
vybrané telekomunikační společnosti. Vyhodnocuje její výsledky z pohledu
Time to Market, kvality dodávek, větší flexibility a spolupráce.
2
2 Teoretická východiska
Teoretická část diplomové práce se zaměřuje na pojmy týkající se projektového
řízení. Přibližuje mezinárodní standardy projektového řízení a věnuje se zejména
jednotlivým projektovým přístupům. Představuje projekt a jeho fáze, činnosti
projektového manažera a projektového týmu. Velká oblast teoretické části je věnována
agilním metodikám a jejich vývoji.
Řízení projektů sahá do několika technologických odvětví - stavebnictví, strojírenství
či informačních technologií. Tato diplomová práce popisuje projektové řízení z oblasti
informačních technologií. Konkrétně řízení IT dodávek, které souvisejí s projekty
zaštiťující vývoj produktů a služeb.
2.1 Projektové řízení
Historie projektového řízení sahá až do období druhé světové války. Tehdy bylo
využíváno strategické projektové řízení především armádou USA. Ta se dále značnou
měrou podílela na zavedení softwarové podpory projektového řízení, která později
zapříčinila další rozvoj v této oblasti. [15]
Projektové řízení se v dnešní podobě zabývá koordinací sady činností a procesů v určitém
časovém rámci. Cílem této koordinace je implementace či změna, která je výsledkem
organizovaného úsilí s jasně definovaným cílem a časem dodání. Účelem projektového
řízení je tedy zajištění efektivního řízení projektu, jeho jednotlivých částí a činností s nimi
spojených. A to tak, aby přinesly požadovaný výsledek v předpokládaném čase a za
předpokládané náklady [20].
Tématu řízení projektů na domácí i mezinárodní úrovni se věnuje několik profesních
organizací, nebo organizací vydávající tzv. standardy projektového řízení. [20]
3
2.1.1 Mezinárodní standardy projektového řízení
Standardizace projektového řízení sahá až k 60. létům 20. století. Tehdy se projektové
řízení teprve vyvíjelo. V současné době je ale mnohem komplexnější a potřeba osvojení
standardů tohoto řízení je žádoucí. Mezi nejznámější a nejrozšířenější standardy
projektového řízení patří PRINCE2, PMI (PMBOK) a IPMA.
Jednotlivé metodiky obsahují již zavedené pojmy, metody a především souhrn
doporučení, liší se zejména svým rozsahem použití a místem původu. Metodika PRINCE2
usiluje o vytvoření návodu a postupů, jak projekty správně řídit, zatímco standardizace
PMI se zase zaměřuje spíše na procesní stránku řízení a IPMA nahlíží na projektové řízení
zejména z pohledu kompetencí projektového manažera. [9]
2.1.1.1 PRINCE2
Metodika PRINCE2 (Project IN Control Enviroment) vznikla ve Velké Británii, v době
rozkvětu vývoje IT – 1995. Tehdy sloužila především k odstranění nedostatků
projektového řízení ve státní sféře. Tehdy byl veliký problém s nezkušeností nových
projektových manažerů, jejich časově náročné zaškolování a v poslední řadě s jejich
častou fluktuací mezi jednotlivými projekty.
Tato metodika je zaměřena především na životní cyklus projektu. Sleduje vzájemné
interakce mezi jednotlivými procesy a řídí se těmito procesy: [9]
1) Zahájení projektu – reálný návrh projektu
2) Nastavení projektu – z pohledu času, nákladů, kvality dodávky, rozsahu, možných
rizik a plánovaných přínosu
3) Směřování projektu – fáze schvalování investičního záměru a nastaveného plánu
dodávky
4) Kontrola etap – monitorování jednotlivých fází projektu a koordinace
projektového týmu
5) Řízení dodávky produktu – zajištění kvality, průběžné akceptace
4
6) Řízení přechodu mezi etapami – průběžné plánování dalších etap, vyhodnocení
možných rizik
7) Ukončení projektu – formální ukončení projektu, vyhodnocení projektu
Obrázek 1 Fáze projektu
Tato metodika je uznávaná na území Evropské unie a manažeři projektového řízení
mohou získat dvě certifikace: PRINCE2 Foundation a PRINCE2 Practioner. Doba platnosti
těchto certifikátů je neomezená a certifikáty se vydávají v 19 různých jazycích, včetně
češtiny a slovenštiny. Jedná se o jednu z nejpoužívanějších metodik projektového řízení.
2.1.1.2 PMI (PMBOK)
Metodika PMBOK, kterou vyvíjela americká organizace PMI v roce 1987. PMBOK
je procesně orientovaná sada doporučení, která se opírá o 5 skupin procesů, které jsou
provázány s dalšími znalostními oblastmi. Do skupiny procesů patří procesy iniciační,
plánovací, realizační, monitorovací a ukončovací. Tyto procesy odpovídají zároveň
jednotlivým fázím projektového řízení. Znalostní oblasti obsahují například řízení kvality
projektu, řízení rizik, řízení lidských zdrojů či řízení integrace projektu. [9]
Zahájení projektu
Nastavení projektu
Nasměrování projektu
Kontrola etap
Řízení dodávek
Plánování
Ukončení projektu
5
I metodika PMBOK vychází z životního cyklu projektu. Vzhledem k různým velikostem a
komplexitě jednotlivých projektů, rozlišuje dále PMBOK tři základní typy životních cyklů
projektu [9]:
Obrázek 2 Tři základní životní cykly [9]
Toto rozdělní odpovídá také postupnému vývoji projektového řízení, kdy se s postupnými
nároky na snížení času dodání a zvyšováním flexibility vývoje uzpůsobovalo samotné
projektové řízení. Tomuto tématu jsou více věnovány kapitoly 2.2 Tradiční vodopádový
model, 2.3 Iterativní metodiky a agilní hnutí a 2.4. Agilní metodiky
Standardy PMBOK jsou uznávané po celém světě a řadí se mezi nejrozšířenější metodiky
projektového řízení. Jejich využití je velice komplexní a sahá do všech odvětví, které
využívají projektové řízení.
PMBOK nabízí celou řadu certifikací, mezi nejznámější patří PMP – Project Management
Professional a PgMP – Program Management Professional.
Prediktivní životní cykly
• řízené plánem
• rozsah, čas a náklady jsou známé téměř ihned
• dobře známe výsledný produkt
Iterativní a přírůstkové životní
cykly
• obsahují opakující se fáze - aktivity projektu
• rozvoj produktu pomocí iterací
• výsledný produkt se ladí v průběhu projektu
Adaptivní životní cykly
• řízené změnou
• zejména agilní metody
• obdobné jako u iterativních cyklů -adaptivní cykly jsou ale mnohem rychlejší
6
2.1.1.3 IPMA
IPMA (Internation Project Management Association) je nadnárodní sdružení
projektových manažerů, které vzniklo ve Švýcarsku. Má více než 55 členů na pěti
kontinentech. Členové tohoto sdružení rozvíjejí především kompetence projektového
řízení, budují rozvoj vztahů mezi společnostmi, vládou, universitami, nebo také
vzdělávacími agenturami. Standardy IPMA patří k nejstarším metodikám projektového
řízení a jsou uznávány zejména na území evropských států včetně České Republiky. [5]
Hlavní funkcí IPMA je vnímání projektového řízení jako profese, která má své standardy,
znalosti, schopnosti a globální působnost. [9]
IPMA nabízí celkem 4 certifikace a každá z nich má své vymezené kompetence [5]:
1) IPMA A – Ředitel projektů
2) IPMA B – Projektový senior manažer
3) IPMA C – Projektový manažer
4) IPMA D – Projektový praktikant
Samotné certifikace jsou procesy zaměřené na posouzení způsobilosti jednotlivých
kandidátů řídit projekty či programy. Důraz je kladen především na schopnosti osvojit si
znalosti a dovednosti projektového řízení.
V České republice se těmto certifikacím věnuje Společnost pro projektové řízení,
o. s.(SPŘ). Tato organizace je profesním orgánem v České Republice, který se zajímá
především o rozšiřování působění projektového managementu a jednotlivých manažerů.
[5]
2.1.1.4 Srovnání standardů projektového řízení
Uvedené standardy mají komplexního řešení a dají se snadno aplikovat na širokou škálu
projektů, bez ohledu na to zda se značně liší svým rozsahem, odvětvím či náročností jejich
zpracování. Jednotlivé standardy se přesto liší ve svých doporučeních a zavedených
metodách a mají své výhody i nevýhody při jejich využití.
7
Přehled těchto silných a slabých stránek standardů projektového řízení PRINCE2, PMI
(PMBOK) a IPMA je uvedena v následující tabulce:
Tabulka 1 Silné a slabé stránky standardů projektového řízení
2.1.2 Projekt
Projekt zajišťuje několik typů dodávek, které jsou určené například zákazníkům
nebo aktivitám samotné společnosti. Může se jednat o dodávky, které zavádějí nové
služby či produkty pro zákazníky, ale také například o interní dodávky uvnitř firmy.
Nejčastěji jsou jimi implementace informačního systému, zavádění nového CRM
či podpora řízení organizačních změn, s kterými se daná společnost potýká.
“Projekt je 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.”
[20, http://managementmania.com/cs/projekt, Definice z normy ISO 10006]
STANDARDIZACE SILNÉ STRÁNKY SLABÉ STRÁNKY
PRINCE2
PROCESNĚ ZAMĚŘENÁ METODIKA
Aplikovatelná standardizace na jakýkoliv typ a velikost projektu Do detailu propracované metody Lze kombinovat i s jinými modely procesního řízení
Chybí komplexní pojetí projektového řízení Nezabývá se dovednostmi projektového manažera Přináší značnou administrační zátěž
PMI
PROCESNÍ ŘÍZENÍ
PROJEKTŮ
Zaměření na procesy projektového řízení Obecné pojetí, které umožňuje aplikaci na jakýkoliv projekt Světově využívaný standard
Neposkytuje jasný návod k řízení projektu Chybí praktické příklady užití nástrojů a technik projektového řízení
IPMA
KOMPETENČNÍ ŘÍZENÍ
PROJEKTŮ
Přesné a jasné vymezení znalostí a dovedností projektového manažera Definice různých úrovní projektového manažera Využití v jakémkoliv sektoru
Použití základní terminologie projektového řízení Chybí detailní zaměření na jednotlivé metody projektového řízení
8
Každý projekt je nutné koordinovat a na začátku této koordinace si vymezit tři vrcholy
tzv. Magického trojúhelníku projektového řízení [6]:
Obrázek 3 Magický trojúhelník projektového řízení – trojimperativ [6]
1) Cíl projektu: jasně definované cíle poptávané dodávky, na základě kterých se odvíjí
požadavky projektu a jeho celkové plánování a koordinace
2) Čas: zadavatel projektu by měl vědět, do kdy chce požadované cíle dodat, tento čas
je ale zároveň závislý na požadavcích, specifikách a složitostech zadané dodávky,
mnohdy se může značně lišit od představy realizace zadavatele
3) Náklady: před spuštěním projektu by měl být připravený rozpočet, ze kterého
se budou čerpat potřebné zdroje, ty jsou nejčastěji využity na interní lidské zdroje,
externí dodavatele a provozní náklady
Charakteristikou tohoto trojúhelníku je vzájemná provázanost. V případě, kdy je nutné
měnit cíle daného projektu, musí projektový manažer počítat s navýšením nákladů
na daný projekt a případně i navýšení časové náročnosti. [6]
Vždy je potřebné projekt předem naplánovat a analyzovat všechny možné dopady.
Samotný projekt pak může trvat několik týdnů, měsíců, ale i roků. Vždy záleží
na náročnosti provedení, objemu samotné dodávky a vytíženosti jednotlivých článků
projektu, které se mohou věnovat hned několika aktivitám na ráz. [4]
Průběh samotného projektu je rozdělen do několika fází, které na sebe systematicky
navazují.
9
2.1.3 Fáze projektu
Základním rámcem pro zkoumání vazeb a procesů oblasti projektového managementu
je životní cyklus projektu. „Přestože je každý projekt unikátní, z hlediska řízení projektů
mají všechny projekty společné určité znaky. Především se jedná o shodné projektové fáze,
které jsou podobným způsobem definovány ve všech standardech a normách v projektovém
řízení“ [22, http://managementmania.com/cs/projekt, kapitola Projekt]
Každý projekt prochází fází návrhu a koncepce projektu. Na začátku je známá idea
projektu, jeho cíl a samotný přínos firmě. V tomto počátečním kroku projektu hraje
nejčastěji hlavní roli zadavatel - business vlastník, který přijde s konkrétní vizí a návrhy.
Ty je nutné před samotným spuštěním projektu obhájit a posunout projekt do realizace.
Návrh projektu ale není jedinou částí realizace. Aby se mohl projekt obhájit a byl znám
přínos požadovaných změn či nových implementací, je nutné vypočítat tzv. business case.
Business case nám říká, zda se nám investice do projektu vrátí, případně i za jak dlouho
její návratnost očekáváme. Abychom jej mohli spočítat, potřebujeme znát i druhou část
analýzy, která spočívá v plánování. Je nutné stanovit, na jaká oddělení bude mít samotný
vývoj dopad a kolik kapacit bude nutné věnovat samotnému vývoji. Při samotném
plánování je důležité nezapomenout na rizika, která mohou vzniknout jak v rámci vývoje,
tak i po předání projektu a myslet tak i na záložní plán. [9]
První dvě fáze projektu – návrh a plánování jsou součástí analýzy projektu, která
má za cíl shrnout business požadavky, rozvrhnout kapacity v podobě lidských zdrojů
•Návrh
Analýza projektu
•Plánování
Analýza projektu
•Implementace
Realizacee
•Dokončení
Realizace
Obrázek 4 Životního cyklus projektu, [11]
10
a zmapovat dopady na IT systémy. Dle výstupů z provedené analýzy lze spočítat business
case, na základě kterého pustíme projekt do samotné realizace.
Důležitou fází realizace je implementace nadefinovaných požadavků a součinnost
jednotlivých týmů, které na projektu pracují. V této fázi je oproti plánovací fázi větší dopad
na technologickou část, která samotný vývoj provádí. Plánovací fáze by se dala nazvat tzv.
business fází, kdy se dávají dohromady především představy, které formují vizi
samotného projektu. V implementační fázi se ovšem můžeme setkat s tím, že je mnohdy
ustoupeno od prvotních požadavků, protože je jejich realizace dražší než se původně
odhadovalo.
Poslední částí realizační fáze a také poslední fází projektu je dokončení. V této části
projektu je ve většině případů nutné systémové a uživatelské testování, které je nezbytné
před samotným předáním projektu. Zde se odhalí zejména defekty a neplánované chyby.
Vznikají pak opravné instalace a někdy i nouzová řešení. Po otestování přichází na řadu
předání projektu. [16]
V případě, že se jedná o velké projekty, které běží několik měsíců, odpovídá za koordinaci
projektový manažer.
Obrázek 5 Životní fáze projektu, [16]
11
2.1.4 Projektový manažer
Projektový manažer je plně zodpovědný za předání všech částí projektu – vymezení
rozsahu dodávky, plánování jednotlivých kroků, stanovení rozsahu potřebných zdrojů
k realizaci projektu a vedené projektového týmu. [12]
Vedoucí projektu má tři druhy základních kompetencí (dle IPMA):
Technická – znalost IT prostředí, osvojení procesních toků
Behaviorální – efektivní komunikace, přirozená autorita
Kontextová – koncepční a pohotové myšlení
Práce manažera projektového řízení je závislá na tom, jakou mírou detailu plánuje
jednotlivé části projektů, na jeho organizačních schopnostech a vedení. Manažer musí
nalézat cestu v případě řešení problémů, která mohou z projektu vzejít a přijmout
tak plnou zodpovědnost. [12] K efektivnímu plánování jednotlivých kroků projektu složí
například Ganttův diagram, který slouží zejména ke grafickému znázornění různých
návazností mezi jednotlivými kroky, které mají přidělenou časovou osu, nejčastěji
buď v rozsahu týdnů či měsíců. Na základě tohoto diagramu lze lehce odhadnout doba
trvání projektu a jeho jednotlivých fází. Pro efektivnější koordinaci projektu
je pro projektové manažery například CPM metody, která pracuje se síťovou analýzou
a stanovuje dobu trvání projektu na základě kritické cesty. Kritickou cestou je nejdelší
možná cesta od počátku až do konce projektu. Mezi další pomocné metody projektového
řízení patří například metody CCM či PERT, RACI matice či Ishikawův diagram.
V projektovém řízení je nutné své znalosti neustále prohlubovat a rozšiřovat. Existuje
řada certifikací, které vycházejí z mezinárodních projektových standardů, mezi
nejznámější se řadí:
Certifikace projektového manažera dle IPMA
Certifikace projektového manažera dle PMI
Certifikace projektového manažera dle PRINCE2
Jednotlivé projektové standardy jsou probrány v kapitole 2.1.1. Mezinárodní standardy
projektového řízení.
12
2.2 Tradiční vodopádový model
Vodopádový model představuje proces po sobě jdoucích vývojových činností, které
na sebe postupně navazují. Až když je předcházející činnost kompletní, může se přejít
do další fáze procesu.
První zmínka o tomto procesním modelu je spjata s Winstonem W. Roycem, který tento
proces kritizoval a označil jej za nefunkční. Přesto vodopádový model v době svého vzniku
představoval obrovský pokrok, hlavně díky rozdělení procesu do jednotlivých fází. [3]
A právě přechod mezi těmito jednotlivými fázemi vděčil zmiňované kritice. Vzhledem
k tomu, že se může pokračovat ve vývoji výhradně až po dokončení předchozí činnosti,
existuje tu vysoké riziko, jehož konsekvencí je zpoždění jednotlivých fází, které
jsou na sobě závislé, a dále je tu velice nízká flexibilita na změny v projektu. Pokud
v průběhu vývoje zjistíme, že je nutné upravit některé požadavky, jedná se o velice
náročné změny a to jak z časového tak i finančního hlediska. [15]
2.2.1 Fáze vodopádového modelu
Obrázek 6 Fáze Vodopádového modelu [3]
Specifikace požadavků
Návrh
Implementace
Integrace
Testování
Instalace
Údržba
13
2.2.1.1 Specifikace požadavků
V první fázi vodopádového modelu je nutné hlavně pochopit cíl projektu. K čemu bude
daný produkt či systém používán, komu je určen, případně v čem má usnadnit práci nebo
co má nahradit. Výstupem první fáze je úvodní studie, která shrnuje tyto poznatky, tedy
informace o zákazníkovi, důvody dodání a hlavní potřeby a požadavky.
2.2.1.2 Návrh
Druhým krokem je analýza business požadavků, jejich pochopení a případná další
specifikace a důraz na realizovatelnost. V této fázi je nutný také přesný popis systému
a jeho funkcionalit. Výstupem je pak odsouhlasení navržených funkcionalit systému a jeho
architektura.
2.2.1.3 Implementace
V implementační fázi dochází k samotnému vývoji aplikací či produktů v podobě, která
byla odsouhlasena. V případě, že je nutná změna ve vývoji, je nutné projít schvalovacím
procesem.
2.2.1.4 Integrace
Po implementaci navržených funkcionalit jsou nezbytně nutné integrační testy, které mají
za úkol odhalit a posléze odstranit vzniklé chyby. Je nutné, aby testování probíhalo
komplexně a produkt či systém se choval podle stanoveného popisu.
14
2.2.1.5 Testování
Po integračních testech přichází na řadu ještě uživatelské testování, které by mělo odhalit
další případné chyby či odchylky chování. Je nutné, aby se funkcionality ověřily z pohledu
uživatele a zákazník tak dostal to, co požadoval.
2.2.1.6 Instalace
Instalace či spuštění samotného produktu či systému by po předchozích fázích měla
proběhnout hladce a uživatele by neměl překvapit žádný defekt.
2.2.1.7 Údržba
Závěrečnou fází, která by se neměla opomíjet je fáze údržby. Málokdy se stane,
že je výsledný produkt bezúdržbový a nepotřebuje žádné budoucí opravy či modifikace.
Je proto nutné produkt udržovat ve funkčním stavu a případně jej s dalším vývojem
vylepšovat.
2.2.1.8 Problémy tradičních metodik
Řízení IT projektů a specificky řízení vývoje SW se postupem času stalo samostatnou
inženýrsko-manažerskou disciplínou. Ta se postupně začala vzdalovat tradičně
pojímanému projektovému řízení, jehož základy jsou v oborech, jako je stavebnictví,
elektrotechnika, strojírenství nebo automobilový průmysl. Tato nová svébytná disciplína
vyžadovala také jiné a modernější přístupy k řízení projektu a rovněž zboření některých
paradigmat, jež v aplikaci na vývoj software nefungovaly tak spolehlivě, jako v jiných
odvětvích.
15
Jednou z prvních publikací, která se tímto tématem zabývala již v roce 1975, je kniha
Mythical Man-Month, jejíž autor Frederick Brooks poukazuje zejména na nespolehlivost
přesného plánování v tzv. člověko-měsících nebo případně člověko-dnech, tak jak se tato
jednotka používala doposud. Je to dáno především neexistencí šablonovitých postupů
a jednotkových úkonů, které lze normovat. Softwarový vývoj totiž představuje
dle deterministických postupů spíše výzkum, nežli konstrukci. Dalšími faktory
jsou pak technická neznalost zadavatele, komplexita a řešení IT projektů
a neustále se vyvíjející technologie a nové postupy. [2]
Do větší hloubky se tomuto tématu věnuje George Stepanek v knize Software Project
Secres: Why Software Project Fails, kde analyzuje do hloubky odlišnosti softwarových
projektů a příčiny jejich častého selhání. Přináší logický model příčin a následků,
proč většina SW projektů řízených tradičním přístupem, selhává a proč je nutná změna.
[17]
Také mnoho průzkumů učiněných v 80. a 90. letech ukázalo, že úspěšnost SW projektů
je žalostně nízká. Podíl projektů, které splní „železný trojúhelník“ projektového řízení,
tedy těch, co jsou dodány včas, v plném rozsahu a za dodržení rozpočtu, je pouze kolem
20%, některé výzkumy pak uvádějí dokonce jen 13%. [1]
Tento stav vedl k úvahám, jakým způsobem čelit nízké důvěryhodnosti projektového
řízení v oblasti vývoje SW a úvahám o potřebách zavedení specifických postupů a metodik
právě pro tuto oblast.
16
2.3 Iterativní metodiky a agilní hnutí
Iterativní metodiky reagují na kritiku vodopádového modelu projektového řízení.
Konkrétně na nutnost dokončení jednotlivých fází, které na sebe postupně navazují.
Iterativní metody řízení jsou založené na jednotlivých iteracích – fází projektu, stejně jako
je tomu u vodopádového řízení. Avšak tyto fáze mohou probíhat současně v cyklech.
Jednotlivé fáze tak mohou opakovat jednu či více aktivit projektu dle potřeby. [9]
Tyto metodiky umožňují flexibilněji reagovat na požadavky businessu.
Obrázek 7 Logický model příčin a následků [17]
17
Jedním z prvních „reakčních“ přístupů byl tzv. V-Model, který je v určitých modifikacích
používán dodnes a je základem moderních iterativních metod. [25]
Obrázek 8 V-model [25, https://en.wikipedia.org/wiki/V-Model]
V-Model byl tedy určitým předobrazem iterativních metodik, jež se rozvinuly především
v 90. letech minulého století a byly standardizovány korporacemi i nezávislými instituty.
Nejznámějším a ve své době nejrozšířenějším reprezentantem je Rational Unified Process
(RUP) vyvinutý americkou firmou Rational (dnes součást IBM) a Enterprise Unified
Process, (EUP) který je rozšířenou verzí RUP.. [25]
2.3.1 Rational Unified Proces (RUP)
Metoda RUP vyjadřuje vývoj procesu čtyřmi fázemi, ve kterých se postupně prolínají
jednotlivé kroky samotného vývoje. Těmito fázemi jsou: [1]
1) Zahájení
2) Projektování
3) Realizace
4) Předání
18
Ve fázi zahájení by mělo docházet ke specifikaci business požadavků a stanovení cíle
projektu. Fáze projektování je zejména o analýze a dizajnu proveditelnosti a architektury
systému. V realizační fázi dochází k implementaci a testování produktu, který je ve
výsledku předán zákazníkovi.
Jedná se o robustní a propracovanou metodiku, která je vhodná zejména na větší projekty.
Hlavní principy této metodiky spočívají zejména v iterativním vývoji, vizualizaci (UML
diagramy) a průběžnému ověřování kvality. [1]
2.3.2 Enterprise Unified Process (EUP)
Enterprise Unified Prosecc byla poprvé představena před 15 lety a je rozšířenou verzí
metodiky RUP. Její rozšíření spočívá zejména v zahrnutí organizace do samotného vývoje
a dále rozšiřuje 4 základní fáze o provoz a údržbu. [1]
Obrázek 9 Fáze vývoje, RUP [1]
19
Obrázek 10 Fáze vývoje, EUP [1]
Metodiky EUP překonávají nedostatky RUP, zahrnují především budování architektury na
úrovni celé společnosti a řízení portfolia.
2.3.3 Agilní hnutí
V druhé polovině 90. let se pak objevují metodiky, které si prozatím neříkají „agilní“,
označení se vžije až později, ale jejich společným znakem je iterativní, minimalistický
přístup a důraz na rychlé tempo vývoje po malých inkrementech. Těmito metodikami
jsou zejména Dynamic Systems Development Method (1994), Scrum (1995), a Extremme
Programming – XP (1999). [1]
Od roku 2001 pak mluvíme o tzv. agilním hnutí, jež se sjednotilo v rámci Agile Manifesto.
17 předních světových vývojářů a expertů na SW inženýrství zformulovalo na konferenci
v Utahu prohlášení známé jako Agile Manifesto [19]:
Manifest Agilního vývoje software
„Objevujeme lepší způsoby vývoje software tím, že jej tvoříme a pomáháme
při jeho tvorbě ostatním. Při této práci jsme dospěli k těmto hodnotám:
Jednotlivci a interakce před procesy a nástroji
Fungující software před vyčerpávající dokumentací
Spolupráce se zákazníkem před vyjednáváním o smlouvě
20
Reagování na změny před dodržováním plánu
Jakkoliv jsou body napravo hodnotné, bodů nalevo si ceníme více.“[19, Manifest agilního
vývoje]
Manifesto agilního vývoje je pak společným základem pro principy a hodnoty, na nichž
staví všechny moderní agilní metoidiky. Agile je tedy zastřešujícím pojmem, sám o sobě
však metodikou není.
2.4 Agilní metodiky
Dnešní podoba agilních metodik navazuje na zmíněný Agilní manifest a striktně
dodržuje jeho 12 základních principů [21]:
1. Časné a průběžné dodávky hodnotného softwaru
2. Vítání změny v požadavcích, i v průběhu vývoje za účelem zvýšení
konkurenceschopnosti
3. Dodávka fungujícího software a preferencí kratších period
4. Spolupráce lidí z byznysu na projektu po celou dobu vývoje
5. Motivace lidí zapojených do projektu
6. Důraz na osobní konverzaci
7. Za hlavní měřítko pokroku se považuje fungující produkt
8. Agilní procesy podporují udržitelný rozvoj
9. Pozornost upřená na technickou výjimečnost a design
10. Jednoduchost je klíčová- maximalizace nevykonané práce
11. Nejlepší návrhy vycházejí ze samo-organizujících se týmů
12. Tým pravidelně pracuje na své efektivitě
21
Oproti vodopádovému modelu je k SW vývoji přistupováno postupně. Životní cyklus
agilního vývoje začíná obdobně, tedy definicí požadavků. Tyto požadavky se ale dále
prioritizují a jsou rozděleny do jednotlivých úkolů, které jsou dodány v tzv. sprintech.
Nejdříve je vyvinut prototyp, který je s přibývajícími iteracemi postupně zdokonalován.
V průběhu agilního vývoje je možné požadavky upravovat, přidávač či odebírat. Další
úpravy ve vývoji pokryje vždy další sprint, který zároveň pokrývá vzniklé defekty. [1]
Obrázek 11 Životní cyklus agilního vývoje [27]
Agilní metodiky lze shrnout do těchto pěti pravidel [10]:
1. Vývoj se centralizuje na zákazníka
2. Tým pracuje samoorganizovaně
3. Udržitelné tempo vývoje
4. Vývoj od základních funkcionalit a produktů
5. Akceptace změn v průběhu vývoje
2.4.1 Příklady agilních metodik
Mezi agilní metody projektového řízení můžeme zařadit hned několik přístupů a metodik,
které jsou využívány a uznávány po celém světě. Mezi nejznámější agilní metodiky
například řadíme [1]:
22
Scrum
Kanban
XP (Extreme Programming)
FDD (Feature-Driven Development) – rozdělení práce jednotlivým
programátorům, pět fází vývoje
Lean Development – souhrn pravidel, která slouží k efektivitě a zrychlení
vývojového procesu, hlavní myšlenkou je eliminace zbytečných požadavků
DSDM (Dynamic Systems Development Method)
(První tři zmíněné jsou blíže představeny v následujících podkapitolách.)
V praxi se často setkáváme se vzájemným propojením jednotlivých agilních přístupů.
Za nejrozšířenější metodiku agilního řízení je považována metoda Scrum.
To prokázaly i výsledky průzkumu „State of Agile Survey“, který společnost VersionOne
každým rokem pořádá. [26]
Obrázek 12 Přehled nejvyužívanějších agilních metodik, [26]
23
2.4.1.1 Scrum
U zrodu této metodiky Scrum stáli na začátku 90. let Ken Schwaber a Jeff Sutherland.
Scrum je postaven na vzájemné a efektivní spolupráci týmu, je to metodika velice
adaptivní a rychlá. Pro samotný vývoj je charakteristická vysoká flexibilita a definice
požadavků se v průběhu vývoje mohou upravovat. [23]
Obrázek 13 Scrum [18]
„Scrum is designed to add energy, focus, clarity, and transparency to project planning
and implementation. It will:
Increase speed of development
Align individual and corporate objectives
Create a culture driven by performance
Support shareholder value creation
Achieve stable and consistent communication of performance at all levels
Enhance individual development and quality of life“[23. Scrum papers, str. 3.]
24
ROLE
Scrum tým kompaktní tým, ve kterém je product Owner, Scrum Master a Development Team Plná alokace zdrojů Tým funguje samovolně a sedí v jedné místnosti
Product Owner Osoba zodpovědná za budget Zástup business a zákazníka
Scrum Master „Hrající kapitán týmu“ Osoba zodpovědná za sprint a dodávky s ním související Kouč týmu, který je zodpovědný za jeho správné fungování
Development team Tým, ve kterém je plné zastoupení vývojářů (od analytika, programátora, designéra,…)
EVENTS
Sprint Základní časová jednotka, iterace Jedná se o krátké časové úseky, ve kterých tým vyvíjí Jedná se většinou o 2týdenní úseky
Sprint planning Na začátku každého sprintu, jedná se o seznámení s požadavky
Daily Scrum Každodenní 15minutové setkání, tzv. StandUp Tým je v neustálém obraze o stavu jednotlivých požadavků
Retrospective Vyhodnocení sprintu Probíhá vždy po jeho ukončení
ARTEFACTS
Backlog Seznam jednotlivých požadavků, které je nutné zpracovat Požadavky mají různé priority a jsou přiřazené do jednotlivých sprintů
User Stories Požadavek Je psán ve stylu: Já jako zákazník chci mít přehled mých služeb online
ScrumBoard Tabule, kam tým zanáší jednotlivé úkoly a posouvá je dle jejich aktuálních stavů Podobné Kanbanu
Burn down chart Grafické znázornění průběhu sprintu
Tabulka 2 Agile concept [13, Autor]
Tato metodika je jednou z nejpoužívanějších agilních metod ve světě, využívají
ji například korporace, jako jsou SAP, ORACLE, HewletPackard, IBM, McAfee a mnoho
dalších nejen světových firem. [26]
25
2.4.1.2 Kanban
Kanban vznikl v roce 1970, původně v automobilovém průmyslu. Toyota jej začala
uplatňovat ve své sériové výrobě a urychlila tím svůj výrobní proces. Kanban znamená
v japonštině „Vizuální karta“ a tomu slovnímu spojení odpovídají i samotné principy [8]:
1) Vizualizace workflow
2) Omezení rozdělané práce (WIP)
3) Dodržení dodací lhůty
Obrázek 14 Kanban board [8]
Metoda Kanban je známá užitím tabule, která slouží k vizualizaci agilního vývoje.
Jednotlivé požadavky jsou rozděleny do jednotlivých úkolů, které jsou dále rozděleny
dle priorit. Agilní tým na tabuli ihned vidí pokroky a splněné úkoly a může se efektivně
věnovat dalším požadavkům, která čekají na svá zpracování. Metoda je velice jednoduchá
a účinná. Velice často je využívána v kombinaci s metodikou Scrum či Extrémního
Programování. [8]
Koncept samotného Kanbanu je také úzce spjatý s metodou Just In Time (JIT).
Dle samotného zakladatele Taiičiho Óno je Kanban právě jedním z prostředků, díky
kterým se dá výsledků JIT dosáhnout.
26
2.4.1.3 XP – Extrémní programování
Disciplína Extrémního programování je další známou agilní metodikou softwarového
vývoje. Stejně tak, jako je tomu u Kanbanu i Extrémní programování vzniklo
v automobilovém průmyslu za účelem optimalizace výrobního procesu v 90. letech
20. století. Tato metodika je postavena na využití osvědčení a známých principů
softwarového vývoje v extrémní formě. Tzn., že pokud se osvědčí nějaká metoda – častější
testování, zkrácení iterací, nebo například simplifikace programu, využívají se tyto
metody vždy, v každé iteraci a v maximální možné podobě. [1] Extrémní programování
uznává tyto základní hodnoty [1]:
1) Komunikace – důraz na komunikaci v týmu i mezi programátorem a zákazníkem
2) Jednoduchost – je nutné programovat jen to, co je nezbytně nutné
3) Zpětná vazba – v rámci průběžného testování, zpětná vazba od zákazníků
4) Odvaha – opravit chybu, která bude znamenat mnoho změn, odvaha zahodit kód
Vedle základních hodnot extrémního programování je dalších 12 praktik. Jsou
jimi například „Zákazník na pracovišti“, která slouží zejména k uživatelskému testování
a je využívaná i mimo XP, „Společné vlastnictví kódu“, kdy celý tým odpovídá za veškeré
změny v programování a žádný z programátorů nemá výhradní právo na určitou část. [1]
Další zajímavou praktikou je tzv. Párové programování. Jedná se o spolupráci dvou
programátorů, kteří pracují na jednou produkčním kódu, společně jej vyvíjejí a diskutují
nad ním. [1].
Stejně tak jako je tomu i u jiných agilních metod i Extrémní programování má své fáze
vývoje, které se mírně liší od ostatních agilních metod.
27
Zadání
•Sepsání User Stories
•Seznam funkčních požadavků
Plánování
•Vytvoření časového harmonogramu
•Měření aktuální rychlosti vývoje
•StandUp schůze
Design
•Zavedení metafory pro systém
•Důraz na simplifikaci
Programování
•Spolupráce se zákazníkem
•Párové programování
•Optimalizace až v posledním kroku
•Žádné přesčasy
Testování
•Důkladné testování
•Průběžné testování
Dodávka
•Akceptační prostředí
•Testování zákazníkem
Akceptace
•Pokud se splní všechna akceptační kritéria, zákazník přebírá produkt
Obrázek 15 Fáze Extrémního programování
28
3 Praktická část
Praktická část diplomové práce vyhodnocuje agilní transformační program,
pro který se korporace rozhodla v roce 2012. Rozhodnutí o jeho spuštění bylo opřeno
o vyhodnocení agilně řízeného pilotního projektu. Tento pilotní projekt byl testován
na agilní metodice Scrum.
Data jsou čerpána z citlivých interních zdrojů společnosti. S ohledem na interní politiku
korporace nebudou v praktické části zveřejněna jména projektů, produktů, agilních týmů
a ani samotné telekomunikační společnosti.
3.1 Cíl a metodologie práce
Diplomová práce popisuje změny společnosti, která prošla transformací řízení
IT projektů. Tato transformace přinesla společnosti zavedení agilních principů a metodik
a tzv. bi-modální řízení, nebi-li dvourychlostní IT.
Metodologie práce je postavena na studiu interních principů a metodik vybrané
společnosti, na základě kterých byly provedené jednotlivé analýzy a porovnání. Výčet
těchto zdrojů je uveden v seznamu interních zdrojů.
Praktická část práce se zaměřuje ve své první polovině na srovnání projektové organizace,
tedy jak fungovala před a po agilní transformaci, která byla odstartována pilotním
projektem. Dále analyzuje jednotlivé fáze agilní transformace a hodnotí škálovatelnost
řízení – SAFe.
Ve druhé polovině je vyhodnocena probíhající transformace z pohledu jejích stanovených
cílů. Hodnotí se celková doba projektů – Time to market (TTM), kvalita dodávek, flexibilita
spolupráce a kulturní změna.
Hodnoty time to market jsou sledovány ve vývojovém grafu, který mapuje dodávky
od prvopočátku transformace, která probíhá od roku 2012.
29
Kvalita jednotlivých dodávek je měřena z výsledků jednotlivých releasů společnosti
v porovnání s reporty incidentů a servisních požadavků, které na tyto releasy reagují.
Dále proběhlo dotazníkové šetření, které mapovalo pohled business zadavatelů.
Hodnotila se především spolupráce, rychlost a kvalita dodávek a srovnání agilních
a waterfall přístupů.
Poslední analýza se věnuje vyhodnocení agile maturity assesment. Tento asesment slouží
jako zpětná vazba vývojových týmů. Z těchto získaných dat je provedeno porovnání
napříč všemi týmy.
3.2 Telekomunikační společnost
Vybraná telekomunikační společnost na českém trhu působí již od roku 1996. Jedná
se o akciovou společnost, jejímž většinovým vlastníkem je nadnárodní mateřská
společnost.
V posledních třech letech prošla dvěma fúzemi a rozšířila si tak své portfolio zejména
v business segmentu. Korporace má poměrně velké portfolio služeb, nabízí svou mobilní,
datovou i pevnou síť pro volání a připojení k internetu a datová centra. Aktuálně má cca
6 milionů zákazníků a téměř 3000 zaměstnanců.
Firma má tzv. divizní organizační strukturu, která je rozdělena do celkem šesti divizí. Jsou
jimi Úsek generálního ředitele, Technologický úsek, Úsek lidských zdrojů, Finanční úsek,
Úsek rezidentních a business zákazníků.
30
Obrázek 16 Organizační struktura společnosti[32]
Veškeré požadavky, které mají dopad na síťovou strukturu či IT systémy řeší
technologický úsek. Zejména pak úseky Service Excellence a Solution & Services, kam
spadá i Technical Project Management (TPM). Tyto požadavky zadává nejčastěji devize
rezidentních či business zákazníků.
Veškeré požadavky pak prochází schvalováním na Prioritization and Lounch Meeting
(PLM), kde jej schvalují VicePrezidenti jednotlivých divizí. Veškeré schvalovací procesy
a postupy má na starosti orgán tzv. Projektové organizace.
Generální ředitel
Managing Director Division
Transformation & Integration
Strategy
Programme Management
Facility Services
Counsel
Technology Division
Solution&
Services
TD Strategy & Services
Network Development
Service Excellence
Service Operations
Human Resources
Division
HR - Compensations, Benefits & Planning
HR Management
HR Development
Finance Division
Purchasing & Logistics
Controlling
Customer Finance
Treasury
Internal Audit
Residential Segment Division
Category & Product
Management
Customer Services
Operations
eBusiness Management
Residential Sales
CSS Channels Dev. & Supply
Chain
Market Communication
Innovation & Transformation CS-
Europe
Resident Marketing
Business Segment Division
Wholesale
Business Sales
CS & Sales Support
SME Group
Business Marketing
31
3.3 Projektová organizace
Základní role projektového řízení a řízení portfolia produktů a služeb vymezuje
v telekomunikační společnosti tzv. Projektová metodika (PPMM). Ta popisuje veškeré
role projektového řízení společnosti a jejich kompetence.
3.3.1 Před agilní transformací
Veškeré požadavky, které mají dopad na vývoj a změnu v IT musejí projít schválením
viceprezidentů. Ti se scházejí každých 14 dní na tzv. PLM (Prioritization and Launch
Meeting), kde kromě schvalování či zamítnutí nových požadavků otevírají již schválené
aktivity do dalších fází projektového řízení. Na PLM probíhají prioritizace spuštění
jednotlivých projektů, které mezi sebou „soupeří“. Hlavní roli hraje především finanční
přínos společnosti, předpokládané náklady, nebo reakce na konkurenci.
Vedle PLM je pro projektovou organizaci důležitý útvar Projektové kanceláře. Projektová
kancelář je administrativní podporou pro řízení projektu v korporaci a připravuje
podklady pro PLM. Dále má na starosti správu jednotlivých požadavků a na základě
rozhodnutí PLM vytváří tzv. roadmapu, která je vytvářena vždy na následující rok.
Obrázek 17 Projektová organizace, interní zdroje společnosti
32
Roadmapa obsahuje veškeré projekty, které byly pro daný rok schváleny k realizaci,
zároveň dochází k její průběžné aktualizaci vždy za každý kvartál.
Vedle této permanentní strany projektové organizace stoji role projektového manažera,
projektového týmu, business ownera a sponzora.
3.3.1.1 Project Sponsor
Jedná se o ředitele divize, která projekt sponzoruje ze svého rozpočtu (rozpočtu
divize)
Má na starosti nominaci vlastníka projektu - Business Ownera a projektového
manažera
Účastní se jako předseda Steering Committee (eskalační orgán, který rozhoduje
o strategických změnách v projektech a sleduje jejich průběh)
3.3.1.2 Business Owner (Vlastník projektu)
Manažer, zástupce business, který formuluje jednotlivé požadavky projektu
a jeho očekávání
3.3.1.3 Project Manager
Je zodpovědný za srozumitelné zadání projektu
Plánuje jeho časování a zdroje
Zpracovává projektovou dokumentaci
Předává výstupy projektu a projekt uzavírá
Je zodpovědný za dodávku projektu ve stanoveném čase a rozsahu
3.3.2 Po agilní transformaci
Projektová organizace se po agilní transformaci ve svém jádru nezměnila, naopak
se rozšířila o agilní role, které na PLM vystupují vedle těch klasických. Vedle projektového
manažera přibyl scrum master a k business ownerovi product owner.
Po agilní transformaci je větší důraz na škálovatelnost jednotlivých projektů.
33
3.4 Pilotní agilní projekt
Projekt byl z pohledu korporace menšího rozsahu a jeho dopad byl cirka
na 10 systémů. Ač byl tento projekt schválen do projektových aktivit daného roku, byl
zejména kvůli kolizím zdrojů neustále odkládán. Jeho start byl značně zpožděn a hrozilo,
že se nenasadí vůbec a jeho finanční prostředky nebudou v daném roce vyčerpány.
Zejména z těchto důvodů byl projekt nominován jako pilotní pro agilní vývoj. A na základě
jeho výsledků se měla korporace rozhodnout, zda spustí transformační program.
Zadavatel projektu neměl zcela jasně specifikované business požadavky a souhlasil
s jejich iterativním zpřesňováním. Další výhodou této metodiky byla vidina postupného
spouštění na zákazníky v demo verzi. Díky pilotnímu spuštění na zákazníky se ověřilo,
zda produkt zákazníkům vyhovuje a jaké změny by měly být implementovány. Bohužel
společnost neměla dostatek prostředků na to, aby mohla tento projekt porovnat z pohledu
klasického vodopádového řízení a agilního. Proto byla připravena důkladná analýza,
která zmapovala zdroje, náklady a časovou náročnost, která by byla vynaložena,
pokud by se produkt spouštěl klasicky a dále se čekalo na výsledek pilotního agilního
projektu.
Již z prvotních analýz bylo zřejmé, že použití Scrum metodiky bude levnější, ale především
méně časově náročnější než při použití standardních metodik. Dále se předpokládalo,
že si zákazníci budou moci v průběhu vývoje „osahat“ demo verzi.
Tabulka 3 Pilot - Scrum vs. Waterfall [34]
34
Management společnosti souhlasil s použitím agilních metodik na pilotním projektu.
Toto otestování znamenalo:
1) Sestavení agilního týmu
2) Seznámení agilního týmu s novou projektovou metodikou – Scrum
3) Seznámení business zadavatele s novou projektovou metodikou – Scrum
4) Vývoj ve sprintech a dodržování Scrum metodiky
5) Dodržet nastavený plán a cíle projektu
6) Retrospektiva – vyhodnocení
V průběhu pilotu bylo zjištěno, že korporace nebyla zcela připravena na agilní přístupy
a to zejména z pohledu flexibility ostatních oddělení. Technologické dodávky byly
mnohdy delší, než byl samotný sprint a tím byl agilní vývoj mnohdy zpožděn. I přes tyto
úskalí byl projektový plán dodržen a po 6 měsících byl dodán produkt se základními
funkcionalitami.
Obrázek 18 Retrospektiva Pilotního projektu[34]
Výsledky pilotního projektu byly velice přesvědčivé a management souhlasil se spuštěním
Agilního transformačního programu.
35
3.5 Agilní transformační program
Společnost se v roce 2013 rozhodla na základě výsledků pilotního projektu
pro Agilní transformační program. Tento program byl naplánován na několik let a byl
rozdělen do čtyř etap. Blíže tyto etapy popisuje obrázek Agile Transition.
Obrázek 19 Agile Transition
3.5.1 Etapy agilní transformace
1) Fáze: Agilní piloty (2012 – 2013)
V roce 2012 probíhal ve společnost tzv. LeanCo program (Lean Company), který měl
za úkol zvýšení zákaznické spokojenosti a relevance produktů, dále posílení firemní
kultury a zákaznické orientace a zvýšení efektivity činností společnosti. V rámci
možností zvyšování firemní efektivity vzešel nápad agilních přístupů a jejich
otestování na pilotním projektu. Vybraný projekt se týkal dodávky nových
funkcionalit na korporátním webu v oblasti eBusiness. Projekt měl být veden
36
klasickým waterfall přístupem a jeho vývoj se neustále odkládal. Nakonec byl zvolen
pilotním projektem. Pilotnímu projektu je věnovaná předchozí kapitola.
Pilotní projekt ukázal výhody agilních přístupů a splnil hlavní očekávání
managementu společnosti a to zejména v rychlosti dodávky prioritních funkcionalit.
Po celkovém vyhodnocení projektu dostala agilní transformace formální podporu.
Postupně začaly vznikat nové agilní týmy a navázala se spolupráce s mateřským
koncernem k získání a předávání know-how.
2) Fáze: Agilní transformační program
K tomu aby byly agilní metodiky zavedeny správně a efektivně, vznikl tým v rámci
programu Agile Transition. Tento tým byl složen ze zástupců jednotlivých oddělení
napříč společností.
Zvyšoval se neustále počet agilních týmů z různých odvětví – Marketing a produkty,
eBusiness, IT. S rostoucím počtem agilních týmů a větší komplexnosti dodávek
vyvstala potřeba škálování těchto nových týmů. Pro tyto potřeby byl zvolen model
Scaled Agile Framework (SAFe). V orvní polovině roku 2014 tak vznikl koncept
škálování Agilních metodik. Vzniklo tak rozdělení na strategické agilní týmy, trains,
37
vývojové agilní týmy („kolečka“) a nově také vznikla organizační jednotka
v IT – „Agile factory“.
Obrázek 20 Škálování agilních týmů
Zároveň byla tato transformace konzultována s přední poradenskou společností
Gartner group, která se zabývá především výzkumem v oblasti IS/ICT technologií.
Nově tak vznikly diskuze týkající se konceptu Bi-modální organizace. Jejím prvním
krokem bylo rozdělení systémů:
Systems of Innovation
Systems of Differentiation
Systems of Records
Obrázek 21 Bi-modální organizace
3) Fáze: Bi-modální organizace
Aktuálně se ve společnosti vedle agilního transformačního programu rozbíhá fáze
Bi-modální organizace. Její principy se začaly aplikovat již v rámci Agile Transition
fáze.
Hlavní změny, které tato fáze přináší se týkají především konceptu paced-layer
architektury, použitých technologií a samotného způsobu vývoje včetně releasování
změn.
38
Velice důležitý článek bi-modální organizace je spolupráce agile týmů s waterfall
týmy. Nově by tak měly vzniknout waterfall subdodávky agile týmům, zejména z těch
oblastí vývoje, které prozatím nejsou na agilní metodiky připravené, nebo je u nich
velice těžké, či nemožné tyto změny zavést.
Koncept těchto změn je plánován minimálně do konce příštího roku, tedy 2016.
4) Fáze: DevOps
Dalším vývojovým stupněm samotné transformace je fáze DevOps. V této fázi se jedná
zejména o kontiunální deployment a integraci s týmy Operations. Vznikne tak užší
spolupráce, která je zásadní zejména pro podporu větší flexibility a samotné zapojení
do agilních dodávek, které nahradí waterfall subdodávky.
Tato závěrečná fáze je plánována minimálně na období 2016 – 2017.
3.5.2 Evoluční modely agilní governance
Zpočátku musely nově vzniklé agilní týmy splňovat nezbytně nutné formální požadavky
aplikované na standardní waterfall projekty. Byly to například Projekt Charter, výpočet
Business Case či standardní projektový reporting. Od roku 2014 se ale agilní způsob
dodávek stal plnohodnotnou součástí standardní projektové metodiky společnosti.
Po přijetí agilních metodik do společnosti přišlo již zmíněné škálování agilních týmů,
které bylo dalším důležitým krokem.
Vzhledem k tomu, že se agile každým rokem ve společnosti etabluje, je nutné s každým
usazením dalších zjednodušení a omezení nezbytných formalit neustále upravovat
projektové metodiky a s ní provádět i kulturní změny ve společnosti.
3.5.3 Finální model škálované agilní governace (SAFe)
39
SAFe je založen na řadě neměnných Lean a Agile dogmat. Jedná se o základní principy
a ekonomické základy, které jsou zároveň opřeny o jednotlivé role a postupy. Těmi
principy jsou [24]:
Take an economic view
Apply systems thinking
Assume variability, preserve options
Build incrementally with fask, integrated learning cycles
Base milestones on objective evaluation of work systems
Visualize and limit WIP, reduce batch size, and manage queue lengths
Apply cadence, synchronize with cross-doamin planning
Unlock the intrinsic motivvation of knowledge workers
Decentralize decision- making
Obrázek 22 Fungování SAFe [24]
Společnost tak musela v rámci SAFe podniknout následující kroky:
40
1) Změnit kulturu společnosti a tyto změny plně podporovat
2) Změnit model výpočtu Business Case
3) Přijmout možní změny scope projektů
4) Akceptovat prototypy a testování se zákazníky
5) Předat větší zodpovědnost na Business ownery
6) Přijmout Agile SW Life-Cycle Management a Agile principy
Mezi další důležité aspekty SAFe patří rozdělení zpracování požadavků na jednotlivé
týmy, tedy mezi agilní část týmů či waterfall týmy. Toto rozdělení aktuálně ve společnosti
probíhá ve fázi analýzy projektu. Hlavní pravidlo pro rozdělování je dopad na systémy.
Pokud se vývoj více dotýká Agile factory, je projekt dodáván agilně a naopak.
Obrázek 23 Výzvy Agile Transition
41
V rámci 3. fáze Agilní transformace se ale letos ladí znění projektové metodiky,
které právě tato rozhodovací pravidla upravuje.
Obrázek 24 Rozhodovací pravidla
3.5.4 Zhodnocení výhod a nevýhod tohoto modelu škálovaného řízení
Společnost je schopna díky škálovanému řízení odbavovat komplexnější dodávky,
které jdou i napříč systémy a odděleními. Vývojové týmy se mohou plně věnovat agilním
dodávkám a nemusí se soustředit na koordinaci kompletních dodávek či koordinaci
subdodávek. Společnost tak odhaduje, že takto dokáže odbavit až o 50% poptávky více.
Lidé v celé Agile Factory si lépe osvojují agilní metodiky a učí se lépe používat základní
agilní principy.
Model SAFe, který přináší koncept trainů a vývojových týmů po jednotlivých systémech
je ale jistým kompromisem ve srovnání s využitím výhod agilního přístupu. Vývojové
týmy nedodávají E2E (end to end, od začátku do konce), jsou závislá na koordinační vrstvě
(train) a v agilním vývojovém týmu nejsou zastoupeny všechny role (např. integrační
tester), musí tak spoléhat na již zmíněnou koordinaci train týmů.
Další nevýhodou je problematika s nastavením role Product Ownera, která nebyla od
začátku efektivně nastavena. Role PO se ale aktuálně upravuje spolu s projektovou
metodikou společnosti.
42
3.6 Cíle transformace a jejich naplnění
Na počátku samotné transformace se nastavili následující cíle pro první fázi programu:
1) Feasibility Study (Studie proveditelnosti) agilní transformace – konkrétně se jednalo
o mapování a následnou identifikace vhodných oblastí pro agilní dodávky
2) Nastartovat agilní piloty napříč společností
3) Plán pro Agile rollout
4) Dopad na snížení firemních metrik – KPI, finanční úspory, TTM
První hodnotící fáze agilní transformace, která končila na přelomu roku 2013, dopadla
velice dobře. V prvním roce transformace šlo 20% požadavků agilním vývojem a v prvním
kvartálu pro rok 2014 byl plán na 50% celkových dodávek. Týmy si postupně osvojovaly
agilní metodiky, ale v první fázi přijali jen některou část agilních principů, značný vliv
na to měly i samotné waterfall subdodávky. Přesto to mělo velice kladný dopad na firemní
metriky, konkrétně TTM (Time to market) byl snížen o plánovaných 15%. Tento výsled
byl ovlivněn zvýšením agilních dodávek v průběhu roku. Ukazatele KPI se bohužel
vzhledem k jejich různorodé měřitelnosti nepodařilo porovnat.
3.6.1 Snížení TTM (Time to market) ukazatele
Ukazatel TTM (Time to market) sleduje dobu, která uběhne od idey, přes realizaci
a uvedení produktu či služby na trh. Adopcí Agile přístupů mohou firmy dosáhnout
snížení TTM až o 50% a to právě díky efektivnosti a rychlosti této metodiky. Snížení TTM
bylo tak jedním z hlavních motivátorů agilní transformace.
Z analýzy vývoje TTM je patrné, že v okamžiku kdy se v jednom kvartálu uzavírá projekt,
který ve společnosti běžel několik let, ukazatel TTM vyskočí. S růstem agilních dodávek
je z grafu vidět, že se ukazatel TTM podařilo opravdu snížit. Pro detailnější porovnání
43
je ale statistický soubor příliš malý. Vzhledem ke škálovatelnosti projektů zde nastávají
dvě situace:
1) V tuto chvíli existuje malý počet agilně dodávaných velkých projektů oproti
waterfall
2) A naopak velký počet agilně dodávaných malých projektů oproti waterfall
43
Agile
Agile-Whs
Fast Tracks
RfS & 3rd level supp. & Consultancy
Projects
Program nového CRM
0
20
40
60
80
100
120
140
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Jan-12 May-12 Sep-12 Jan-13 May-13 Sep-13 Jan-14 May-14 Sep-14 Jan-15
AV
ERA
GE
FAST
TR
AC
K T
IME-
TO-M
AR
KET
IN D
AYS
S&S
RES
OU
RC
ES (
INT.
+ E
XT.
FTE
)
TIME
Agile vs. other demands /shorter T2M (FT demand) influenced by Agile Delivery
Agile Agile-Whs Fast Tracks
Graf 1 Time2Market
44
3.6.2 Kvalita dodávek
Kvalita jednotlivých dodávek je závislá na velikosti releasů, jejich obsahu a formy
dodávek. Na grafu vidíme přehled těchto releasů od roku 2014 a do první poloviny roku
2015. Velikost jednotlivých dodávek (Agile x Waterfall) je měřena počtem MD’s. Dále
je v grafu znázorněno ratio chybovosti každého releasu. Tento poměr je postaven
na reportu vzniklých incidentů a servisních požadavků, které jsou konsekvencí
spuštěných dodávek.
Z grafu je patrné, že ne vždy ovlivňuje velikost jednotlivých dodávek chybovost. Například
v březnovém release v roce 2014 bylo dodáváno poměrné malé množství změn, přesto
měl tento release největší chybovost za poslední rok. Vždy záleží i na samotné
charakteristice dodávky a její celkové koordinaci.
Z dat za poslední rok, tedy od druhé poloviny 2014 dokonce první poloviny 2015 vyplývá,
že chybovost jednotlivých dodávek, které byly vedeny agilně či standardně, je ve většině
případů stejná. V jednom období dokonce chybovost agilních dodávek značně převyšuje.
V Celkovém důsledku, ale nebyla chybovost extrémní (viz graf 2 Chybovost dodávek).
R1402 R140323 R140428 R140615 R140817 R141130 150125 R150517
Size Agile 1200 1200 800 1260 1440 850 258 947
Size Waterfall 1500 1500 900 1630 2300 1357 2154 1553
Ratio of production issues0,0392592590,030370370,0511764710,0217993080,0264705880,0217489810,033167496 0,0164
0
500
1000
1500
2000
2500
3000
3500
4000
0
0,01
0,02
0,03
0,04
0,05
0,06
Pro
du
ctio
n is
sue
s (a
bso
lute
#)
PRODUCTION ISSUE RATIO TO SIZE OF RELEASES
Graf 2 Chybovost releasů
45
Graf 3 Chybovost dodávek
Obrovským vlivem na samotnou kvalitu dodávky je vždy práce jednotlivých týmů, dopady
na jednotlivé systémy, vzájemná spolupráce a také stabilita produkčního prostředí. V další
fázi agilní transformace je tak nutné dbát i na zlepšení těchto ukazatelů
3.6.3 Flexibilita, reakce na změny a celková spokojenost business oddělení
Pro zmapování business pohledu na agilní vedení v telekomunikační společnosti byla
vybrána forma dotazníkového šetření. Dotazník byl k dispozici na Google forms po dobu
jednoho pracovního týdne.
V rámci dotazníkového šetření bylo osloveno 25 kolegů, kteří pracují na oddělení úseku
Marketingu a Péče o zákazníka v jedné telekomunikační společnosti. Oslovení
respondenti jsou business ownery a nejčastějšími zadavateli požadavků a změn.
Dotazník se skládá z devíti otázek, které byly zaměřené na Agile Development, vzájemnou
spolupráci s agilním týmem a kvalitu agilních dodávek.
3,26%
4,43%
1,19%
2,46%
1,71%
3,13%
2,06%
1,30%
2,50%2,73%
0,00%
0,50%
1,00%
1,50%
2,00%
2,50%
3,00%
3,50%
4,00%
4,50%
5,00%
R140817 R141130 R150125 R150305 R150517
PRODUCTION ISSUE RATIO
Agile Failure Ratio Waterfall Failure Ratio
46
První část dotazníku se týká Agile Development. Agile Development říká, v čem se agilní
metodiky odlišují a to celkem ze 4 pohledů – viditelnost, adaptabilita, business hodnota
a řízení rizika.
Viditelnost: Projekty řízené agilně mají oproti vodopádovým projektům
viditelnější pokroky ve vývoji, které podporuje především průběžné testování
Adaptabilita: Agilní tým je flexibilnější přístup, umožňuje náběr nových požadavků
v průběhu vývoje a prioritizaci jednotlivých user stories.
Business hodnota: Oproti waterfall projektů jsou agillní dodávky postavené
na průběžném vývoji, který nejprve dodá základní funkcionality a poté každým
dalším sprintem dodává další funkcionality a vylepšení.
Řízení rizika: Průběžné dodávky, které jsou zároveň i otestované, předcházejí
tomu, že před předáním celého projektu bude služba funkční, nebo funkční z větší
části.
Obrázek 25 Agile Development [25, http://www.versionone.com/agile-101/agile-software-development-benefits/]
47
Respondenti měli vyjádřit, zda agilní metodiky uvnitř společnosti odpovídají výše
uvedeným tvrzením.
Z grafů je patrné, že většina dotazovaných souhlasí s tvrzením Agile Development.
Tedy, že i u nich ve společnosti je agilní metodika viditelnější, flexibilnější a méně riziková,
než je tomu u waterfallu.
Další část dotazníkové šetření byla zaměřena na práci s agilním týmem. Respondenti měli
posoudit, zda jim více vyhovuje spolupráce s vývojáři z agilního prostředí a zhodnotit,
co jim chybí a co naopak oceňují. Většina (14 z 15 dotazovaných) je spokojenější s prací
agilních týmů.
0 2 4 6 8 10
Souhlasím
Spíše souhlasím
Spíše nesouhlasím
Nesouhlasím
Nedokáži posoudit
[VISIBILITY - viditelnější pokroky ve vývoji, průběžné
testování]
0 2 4 6 8 10
Souhlasím
Spíše souhlasím
Spíše nesouhlasím
Nesouhlasím
Nedokáži posoudit
[ADAPTABILITY - flexibilní přístup, prioritizace user stories v průběhu vývoje]
0 2 4 6 8 10
Souhlasím
Spíše souhlasím
Spíše nesouhlasím
Nesouhlasím
Nedokáži posoudit
[BUSINESS VALUE - dodání "základního balíčku" na který
se nabalují další vylepšení]
0 2 4 6 8 10
Souhlasím
Spíše souhlasím
Spíše nesouhlasím
Nesouhlasím
Nedokáži posoudit
[RISK - nižší riziko nefunkčnosti díky
průběžnému testování]
Graf 1 Agile development - Viditelnost Graf 2 Agile development - Adaptabilita
Graf 4Agile development - Business hodnota Graf 5 Agile development - Rizikovost
48
Graf 6 Práce agilního týmu
Zástupci business oceňují zejména flexibilní spolupráci, provázanost s týmem, či odhalení
chyb v častějším testování jednotlivých dodávek. „Flexibilita, méně byrokracie.“ „Oceňuji
zejména možnost průběžně prioritizovat jednotlivé US, či EPIC.“ „Agilní přístup je velmi
výhodný v průběžném trackování dodávek, neztrácí se motivace členů týmů - průběžně
dodávají a vidí výsledky své práce, snadněji se odhalí vysoká/nízká výkonnost členů agilního
týmu.“
Nedostatky vidí naopak v tom, že ne všechny týmy jsou ve společnosti agilní a spousta
„neagilních“ týmu, brzdí právě agilní dodávky. Dále je tu vazba na tzv. releasy, pevně
stanovená okna dodávek a úprav v systémech, která ve společnosti probíhají několikrát
do roka. Někteří vidí i hrozby nad prioritizací, která je jak výhodou, tak i nevýhodou
agilního vývoje. „Na druhou stranu svádí k zanášení změn (užší spolupráce s vývojáři), které
nebyly plánovány nebo nejsou součástí backlogu. Je potřeba disciplína i na straně PO.“
„Závislost na releasu.““ Použití agile na multidomain FT je velice náročné na koordinaci, tlak
na prioritizaci zvyšuje pravděpodobnost zanedbání zdánlivě nedůležité chyby.“
Další část dotazníku je zaměřena na kvalitu a rychlost Agilních dodávek. Respondenti jsou
sice s agilním přístupem spokojenější a oceňují rychlost a flexibilitu dodávek.
Ve srovnání kvalit agilních oproti waterfallovým dodávkám už takovou změnu nevidí.
S rychlostí a kvalitou jsou ale v každém případě spokojeni.
Ano93%
Nedokáži posoudit7%
Vyhovuje Vám více práce s agilním týmem?
Ano Nedokáži posoudit Ne
49
Poslední část dotazníkového šetření byla zaměřena na celkovou spokojenost a závěrečná
doporučení. Respondenti známkovali agilní metodiky společnosti na škále od 1 do 5 (jako
ve škole). Výsledný průměr činí 1,6. Respondenti jsou sice spokojeni s aktuálním stavem,
ale mají plnou řadu doporučení, která by jim spolupráci se zástupci technického oddělení
společnosti zjednodušila a zpříjemnila. Nejčastěji zmíněné doporučení jsou:
Lepší testovací prostředí
Rozšíření agilního vedení i mimo IT
Prioritizace napříč agilních dodávek
Lepší kontrola nákladů
„Chybí nám jedno testovací prostředí dedikované pro agilní vývoj - bez něj jsme příliš vázání
na releasy a nejsme schopni vždy průběžně testovat v rámci jednotlivých Sprintů.“ „Je mi líto
testerů, protože mohou sice agilně testovat, ale pokud jim každým buildem rozbijou
už to co otestovali, je to takový nekonečný příběh...““Větší interní PR i v oblastech mimo IT.
Ano87%
Nedokáži posoudit
13%
Myslíte si, že jsou agilní dodávky rychleji dodávány?
Ano Nedokáži posoudit Ne
Ano60%Nedokáži
posoudit20%
Ne20%
Myslíte si, že jsou agilní dodávky kvalitnější?
Ano Nedokáži posoudit Ne
Ano
Spíše ano
Nedokáži posoudit
Spíše ne
Ne
0 2 4 6 8
Jste s kvalitou agilního vedení spokojeni?
Ano
Spíše ano
Nedokáži posoudit
Spíše ne
Ne
0 2 4 6 8
Jste spokojeni s rychlostí agilních dodávek?
Graf 10 Jsou agilní dodávky rychlejší? Graf 7 Jsou agilní dodávky kvalitnější?
Graf 9 Spokojenost s rychlostí Graf 8 Spokojenost s kvalitou
50
Touto metodikou lze dodávat i projekty mimo IT oblast, ale řekla bych, že se toho využívá
spíš méně.““ Lepší sladění s ostatními procesy ve firmě vč. tzv releasů.“
Na dotazníkové šetření reagovalo 15 z oslovených kolegů. Náhled na celé dotazníkové
šetření je uveden v příloze.
3.6.4 Kulturní změna – jak je nasazena agilní metodika
Ve vybrané telekomunikační společnosti je agilní metodika nasazena již třetím rokem.
A každý rok se společnost snaží přiblížit agilní vedení ideálnímu stavu. Je proto nutné
zjistit jak si agilní metodiky ve společnosti vedou. Výsledky se opírají o analýzy TTM
a reportů kvalit dodávek. Důležité je ale také vědět jak je nastavena spolupráce
a jak změny pociťují vývojářské týmy. Pro zmapování aktuálního stavu používání agilních
postupů v jednotlivých týmech byl zvolen tzv. Agile Maturity Assessment. Tento
assesment má celkem tři fáze – Self – assesment, Assesment review a závěrečná diskuze.
Každý tým hodnotí po jejich jednotlivých oblastech agilní metodiky na předem stanovené
0%10%20%30%40%50%60%70%80%90%
Team
Scrum Master (SM)
Product Owner (PO)
Product Backlog (PB)
Definition of Done(DoD)
Estimation
Sprint (Pre-)PlanningMeeting
SprintDaily Scrum Meeting
(Stand-up)
Customer Demo
Retrospective
Impediment backlog
Velocity
Burndown chart
Sprint Backlog (ScrumBoard)
Agile Practices Adoption
Obrázek 26 Agile maturity assesment
51
škále a porovnávají svoje výsledky s etalonem, jímž je „100% čistý agilní přístup“. V tomto
případě jde o metodiku Scrum v její teoretické podobě. Týmy si následně stanovují
své rozvojové cíle, a plánují, kam by se za určité období rády dostaly ve vztahu
k implementaci praktik dané metodiky.
Telekomunikační společnost má v tuto chvíli těchto týmů devět. Bohužel ne všechny týmy
fungují čistě „agilně“. Assesment umožní týmu dát si sám sobě zpětnou vazbu a zamyslet
se nad možným zlepšením a zároveň společnosti odpoví na otázky:
Jak agilní tým funguje dnes?
Jak agilní tým vzájemně spolupracuje?
Jaké hlavní oblasti může zlepšit?
Jakou zpětnou vazbu si samotný tým odnesl a kam se chce posunout?
Splnil svá očekávání z minulého assesmentu?
Dle níže uvedené tabulky, která vyhodnocuje Agile Maturity assesment, vyplývá, že týmy
které pracují v Train módu, daleko lépe splňují principy a metody agilního řízení.
Tento stav je ovlivněn typem dodávky, kterou vývojové týmy doručují. Jedná se většinou
o týmy, které jsou plně závislé na standardní subdodávce (waterfall)
nebo jsou z heterogenního oddělení, které navíc zastřešuje několik nesourodých oblastí a
systémů.
U většiny týmů je ale vidět nadšení pro agilní principy a velká snaha o jejich dodržování.
90% týmů musí více pracovat nad retrospektivou a vyhodnocováním proběhnutých
sprintů. I díky tomuto vyhodnocení získají více zkušeností pro další fungování.
Fungování většiny agilních týmu je velice dobře nastaveno a připraveno pro další vlny
transformace.
52
Tým 1 Tým 2 Tým 3 Tým 4 Tým 5 Tým 6 Tým 7 Tým 8 Tým 9
Scrum
Ethalon100% 100% 100% 100% 100% 100% 100% 100% 100%
Agreed
assesment
final score
58% 65% 77% 63% 67% 53% 54% 81% 71%
Team
ethalon78% 90% 93% 91% 89% 87% 82% 97% 93%
Progress
to ethalon72% 70% 82% 68% 70% 56% 60% 83% 71%
Využití
agilních
principů
82% 90% 100% 80% 70% 50% 30% 100% 100%
Celkové
fungování
týmu
100% 98% 100% 100% 90% 80% 60% 100% 100%
Vzájemná
spolupráce100% 100% 100% 100% 100% 90% 70% 100% 100%
Oblasti ke
zlepšení
Plánování
aktivit
Plánování
vlastních
aktivit
Podpora
týmové
komunikac
e
Použití
Scrum
Board
Koučing ze
strany SM
Nevynechá
vat
Planning a
Retrospekt
ivu
Customer
demo
Koučing ze
strany SM
Customer
demo
Podpora
týmové
spolupráce
Scrum
Board
Plánování
vlastních
aktivit
Retrospekt
iva
Plánování
aktivit
Posílení
StandUp
budování
zastupiteln
osti
Využití
Velocity a
Burndown
Chartru
Využití
Velocity a
Burndown
Chartru
TRAIN TÝMY Vývojové týmy
53
Plánovaný
posunPlánování
Zapojení
nového PO
Retrospect
iva
Zapojení
nováčků
Rozpad
EPIC na
jednotlivé
UC
Retrospektiv
aStand Up
Prioritizac
e
Práce s
backlogem
Retrospekt
iva
Retrospekt
iva
Burndown
chart
Retrospekti
va
Zavedení
Customer
dema
Sprint
review
meeting
Customer
demo
Retrospekt
ivaPlánování
Splněná
očekávání
Výborná
spolupráce
PO a SM
Nabírání
zkušeností
Sehranost
týmu
Spolupráce
s business
Aplikace
agilních
principů
Silná role
PO
I přes
nesourodé
oblasti
snaha o
agilní
fungování
Souhla PO
a SM
Motivace
SM
Velocity a
burndown
chart
Velice
dobrý
začátek
fungování
Velice
dobře
nastavená
spolupráce
s
vývojovými
týmy
Velocity a
Burndown
chart
Výměna
PO
Tým pracuje
agilně
protože
musí
Osvojení
role SM
Výborná
spolupráceNový PO
Tabulka 4 Srovnání agilních týmů
54
4 Diskuze
Společnost prošla od roku 2012 obdobím velkých transformačních a organizačních
změn. Proběhly celkem dvě velké akvizice a následné rozšíření portfolia společnosti. Dále
se společnost potýkala s pozastavení a opětovným spuštěním náročného IT programu,
které značně ovlivnilo i samotnou agilní transformaci. Nelze tak Agilní transformaci očistit
od vlivů těchto změn a naměřit tak exaktní hodnoty v tomto období (2013 – 2015).
Vyhodnocení je podloženo tzv. měkkými faktory, které jsou opřeny o subjektivní
spokojenost – dotazníkové šetření.
Výsledky probíhající agilní transformace jsou pro společnost velice uspokojivé. Z analýz
je patrné, že si společnost osvojuje agilní metodiky, díky kterým se jí daří zrychlit vývoj
nových produktů a postupně i snižovat jejich náklady.
Z pohledu prvotně přijatých změn a opatření, se společnosti podařilo naplnit každé z nich.
1) Sestavení agilního týmu
2) Seznámení agilního týmu s novou projektovou metodikou – Scrum
3) Seznámení business zadavatele s novou projektovou metodikou – Scrum
4) Vývoj ve sprintech a dodržování Scrum metodiky
5) Dodržet nastavený plán a cíle projektu
6) Retrospektiva – vyhodnocení
Vzniklo hned několik nových týmů, které přijaly agilní metodiku Scrum a snaží
se dodržovat její principy. Business zadavatelé byli seznámeni a vtaženi do těchto
vývojových vlaků. Společnosti se podařilo dodržet i nastavený plán a průběžně se jí daří
splňovat nastavené cíle agilní transformace. Jediný bod, ve kterém společnost nedrží
svých slov je průběžné vyhodnocování. V Bi-modálním režimu je sice předběžné
vyhodnocení transformace obtížné, vzhledem k různorodým projektům, jejich velikostí
a použité metodice projektového řízení.
55
Vzhledem k široké škále portfolia aplikací a IT služeb je vždy výhodou, pokud společnosti
podporují a využívají oba tyto přístupy řízení projektů, tedy jak klasické vodopádové, tak
agilní. Je nutné si vždy uvědomit, jaké tempo změn je nutné nastavit, jak robustní řešení
daný projekt představuje.
U obrovského programu, jako je například komplexní změna CRM systému, není možné
vyvíjet agilně. Program samotný je tak obrovský a složitý, že by jej agilní principy sotva
z poloviny pokryly. Společnosti však mohou využít v těchto programech agilních
subdodávek a spojit tak efektivně oba tyto přístupy.
Firmy by se obecně neměli bát těchto transformačních programů, důležité je vždy vhodně
vybrat pilotní projekt, na kterém se agilní principy dají efektivně otestovat. Nejlepší
analýzou je srovnání stejného projektu, který ve stejný čas firmy vyvíjí jak agilně
tak i waterfallově. Srovnání je pak jednoznačné a ve většině případů viditelné na první
pohled. Na tyto pilotní programy však společnosti mnohdy nemají dostatek prostředků
a tak se musí spokojit se srovnáním jednotlivých analýz a odhadů.
Vedle vhodně vybraného pilotního programu je také důležité vybrat člověka – kouče,
který nás naučí agilní metodiky přijmout a následně správně vykonávat. Na trhu je dnes
spousta firem, které přímo tyto služby nabízí, jedná se buď o komplexní poradenství, nebo
„zapůjčení“ pracovníka na dobu určitou – většinou po dobu transformačního programu.
Společnosti by se tak měly rozhodovat nejen na základě očekávání, které jim agilní
metodiky přinesou ale i na základě výše investice, která je v rámci agilní transformace
čeká.
56
5 Závěr
Diplomová práce je věnována problematice projektového řízení. To je v teoretické
části porovnáno z pohledu tradičních a agilních metod řízení. Porovnání vychází
z uvedených zdrojů odborné literatury a online zdrojů.
Teoretická část představuje projektové řízení obecně a dále uvádí jeho mezinárodní
standardy. Je zde také věnována pozornost popisu projektu a jeho dílčích částí, životnímu
cyklu projektu a charakteristice jeho fází. Dále práce popisuje zodpovědnosti a role
projektového manažera.
V druhé části teoretický východiska popisují tradiční vodopádový model a upozorňují
na jeho slabé stránky. Dále mapují postupní vývoj agilních metodik, které se postupně
vyvíjely z iterativních přístupů. Agilním metodikám je zde věnována větší část. Jsou zde
představeny základní principy a doporučení, která jsou pro agilní řízení charakteristická.
Dále jsou zde představeny nejvyhledávanější agilní metodiky – Scrum, Kanban a Extremní
programování.
Praktická část je věnována představení telekomunikační společnosti a její projektové
organizaci a dále pak analýze agilní transformace, kterou se společnost vydala. Praktická
část uvádí, z jakých důvodů se společnost rozhodla pro agilní transformaci a popisuje zde
vybraný pilotní projekt, který samotnou transformaci odstartoval.
Výzkum je věnován zejména jednotlivým fázím agilní transformace, nastavení jejích cílů
a následně jejich plnění. Data byla čerpána z interních zdrojů společnosti. Na základě
těchto dat bylo měřeno dodržení snížení time to market ukazatele. Cílem společnosti bylo
tento ukazatel snížit o 15 %. Z výsledků analýzy vyplývá, že zavedením transformačního
programu se těmto cílům společnosti dostává. Dalším cílem bylo pro firmu zkvalitnění
jednotlivých dodávek. Analýza probíhala nad daty z jednotlivých objemu releasů
a nad reporty mapující incidenty a servisní požadavky, které řeší jejich defekty. Zde
se neukázal jasný trend v tom, že by agilní projekty jednoznačně přispívaly ke zvýšení
kvality dodávek. Důležité však je, že přijetí agilní transformace nezpůsobilo propad
kvality těchto dodávek. Firma se tak může zaměřit na efektivnější spolupráci jednotlivých
agilních týmů, průběžného testování a flexibilitě.
57
V rámci diplomové práce dále probíhalo dotazníkové šetření, které mělo za cíl zhodnotit
celkový přístup a spokojenost business zadavatelů k agilním metodikám. Bylo vybráno
20 respondentů z divizí marketingu a peče o zákazníka, kteří nejdříve hodnotili zda agilní
principy odpovídají nastavení agilních metodik ve společnosti, dále hodnotili vzájemnou
spolupráci s vývojovými týmy, jejich flexibilitu, dále kvalitu a rychlost agilních dodávek
a v poslední řadě agilní metodiky známkovali na škále od 1 – 5 jako ve škole. Výsledky
toho dotazníkové šetření říkají, že jsou business zadavatelé s agilním řízením spokojeni.
Líbí se jim především vysoká flexibilita a rychlost dodání. Poukazují ale také na problémy
subdodávek waterfall týmů a nutnost spouštění dodávek s releasy. Celkové průměrné
hodnocení nastavených agilních principů ve společnosti je 1,6.
Poslední analýzou praktické části bylo srovnání výsledků Agile maturity assesmnet.
V tomto hodnocení se provádí zpětná vazba týmu, kdy se hodnotí zejména posun
samotného týmu, osvojení principů agilní metodiky a společně se hledají slabé stránky
a prostory ke zlepšení. Zároveň je zde využita metoda etalonu kdy si týmy nastaví nové
cíle pro další období a následně vidí, jak se k daným cílům přiblížili. Z výsledků „maturity“
vyplývá, že si většina týmů agile principy osvojila a má za cíl tyto principy neustále
prohlubovat a posouvat se v agilním vývoji dál. Je zde ale také značný prostor k vylepšení,
zejména retrospektiv – vyhodnocení každého vývojového úseku.
Celkově se společnost s transformačním programem vyrovnala úspěšně. Zaměstnanci
společnosti přijali agilní metodiky ve větší míře kladně a společně se snaží tyto metodiky
dodržovat a neustále si je osvojovat. V jednotlivých ukazatelích je postupně vidět,
že stanovené cíle se pomalu dostavují. Pro společnost je v tuto chvíli důležité,
aby si v následujících letech udržela plán jednotlivých fází transformačního programu
a nastavila si reálné a měřitelné cíle tohoto programu.
Pokud bychom měli dojít k závěru, který z uvedených přístupů, zda agilní či vodopádový,
je lepší než ten druhý, zjistíme, že ani jedno tvrzení by nebylo správné. Každý přístup
se hodí na vybrané typy projektů a dodávek a pro firmu je v dnešní době jen výhodou,
pokud ovládá oba typy projektového řízení.
„Agile development will not solve any of your problems—it will just make them
so painfully visible that ignoring them is harder.“
Ken Schweber, father of Scrum
58
Seznam použité literatury
[1] BUCHALCEVOVÁ, Alena, Metodiky budování informačních systémů, Praha:
Grada, 2005. ISBN 80-247-1075-7
[2] BROOKS, Frederick, Mythical Man-Month: Essays on Software Engineering,
Addison-Wesley Publishing Company, 1995, ISBN 978-02-018-3595-3
[3] DOLEŽAL, Jan a kolektiv, Projektový management podle IPMA, Praha: Grada
Publishing a.s., 2009, ISBN 978-80-247-2848-3
[4] DOLEŽAL, Jan, KRÁTKÝ, Jiří, CINGL, Ondřej, 5 kroků k úspěšnému projektu,
Praha: Grada Publishing a.s., 2013, ISBN 978-80-247-4631-9
[5] DOLEŽAL, Jan, MÁCHAL, Pacel, LACKO, Bronislav a kolektiv, Projektový
management podle IPMA - 2., aktualizované a doplněné vydání, Praha: Grada
Publishing, 2012, ISBN 978-80-247-4275-6
[6] FIALA, Petr, Projektové řízení: modely, metody, analýzy, Praha: Professional
Publishing, 2004, ISBN 978-80-86419-24-4
[7] KORECKÝ, Michal, Management rizik projektů, Praha: Grada Publishong, 2011,
ISBN 978-80-247-3221-3
[8] KNIBERG, Henrik, SKARIN, Mattias, Kanban and Scrum - Making the Most of
Both, C4 Media Inc, 2010, ISBN 978-0-557-13832-6
[9] MÁCHAL, Pavel, KOPEČKOVÁ, Martina, PRESOVÁ, Radmila, Světové standardy
projektového řízení pro malé a střední firmy, Praha: Grada Publishing, 2015,
ISBN 978-80-247-5321-8
59
[10] MAYER, Bertrand, Agile!: The Good, the Hype and the Ugly, Springer Science
& Business Media, 2014, ISBN 978-331-90-5155-5
[11] NĚMEC, Vladimír, Projektový management, Praha: Grada Publishing, 2002,
ISBN 978-80-247-0392-0
[12] NEWTON, Richard, Úspěšný projektový manager, Praha: Grada Publishing a.s.,
2008, ISBN 987-80-247-2544-4
[13] PICHLER, Roman, Agile Product Management with Scrum: Creating Products
that Customer Love, Addison-Wesley Professional, 2010, ISBN 978-0-321-
60578-8
[14] SCHWABER, Ken, The Enterprise and Scrum, Microsoft Press, 2007, ISBN 987-
0-7356-2337-8
[15] SCHWALBE, Kathy, Řízení prijektů v IT, Brno: Computer Press, 2011, ISBN 978-
80-251-2882-4
[16] SVOZILOVÁ, Alena, Projektový management, Praha: Grada Publishing a.s.,
2006, ISBN 978-80-247-1501-5
[17] STEPANEK, George, Software Projects Secrets: Why Projects Fail, Apress,
2013, ISBN 978-14-302-5102-6
Internetové zdroje
[18] Do Better Scrum, http://www.agile42.com [online],
Dostupné z http://www.agile42.com/en/agile-info-center/do-better-scrum/
[19] Manifest Agilního vývoje software, http://agilemanifesto.org [online],
Dostupné z http://agilemanifesto.org/iso/cs/
[20] Metody řízení podniku, http://managementmania.com [online],
60
Dostupné z https://managementmania.com/cs/metody-rizeni-projektu
[21] Principy agilního vývoje, http://agilemanifesto.org [online],
Dostupné z http://agilemanifesto.org/iso/cs/principles.html
[22] Projekt, http://managementmania.com [online],
Dostupné z https://managementmania.com/cs/projekt
[23] Scrum papers, http://assets.scrumfundation.com [online],
Dostupné z http://assets.scrumfoundation.com/downloads/2/scrumpapers.pdf
[24] SAFe, http:// http://scaledagileframework.com [online]
Dostupné z http://scaledagileframework.com/safe-lean-agile-principles/
[25] V-Model, http://en.wikipedia.org [online],
Dostupné z https://en.wikipedia.org/wiki/V-Model
[26] What Is Scrum, http://www.versione.com [online],
Dostupné z http://www.versionone.com/agile-101/what-is-scrum/
[27] Životní cyklus agilního vývoje, http://shastha.in/ [online],
Dostupné z http://shastha.in/designing/img/Agile%20Process.jpg
Interní zdroje společnosti
[28] Agile Competence center, interní prezentace
[29] Agile Maturity Assesment, interní prezentace
[30] Agile Transition, interní dokumentace k agilní transformaci
[31] Bimodal Transition Programm, interní prezentace
[32] Organizační struktura a projektová organizace společnosti
[33] Project and Portfolio Management Methodology, interní směrnice
[34] Release evaluation report, interní reporty
[35] Release production report, interní reporty
[36] Steering Committee, interní prezentace k pilotnímu projektu
61
Seznam použitých obrázků
Obrázek 1 Magický trojúhelník projektového řízení – trojimperativ [6] .................................. 8
Obrázek 2 Životního cyklus projektu, [11] ............................................................................................ 9
Obrázek 3 Životní fáze projektu, [16] ................................................................................................... 10
Obrázek 4 Fáze Vodopádového modelu [3] ....................................................................................... 12
Obrázek 5 Logický model příčin a následků [17]............................................................................. 16
Obrázek 6 V-model [25, https://en.wikipedia.org/wiki/V-Model] .......................................... 17
Obrázek 7 Životní cyklus agilního vývoje [27] .................................................................................. 21
Obrázek 8 Přehled nejvyužívanějších agilních metodik, [26]Error! Bookmark not
defined.
Obrázek 9 Kanban board [8] .................................................................................................................... 25
Obrázek 11 Projektová organizace, interní zdroje společnosti .................................................. 31
Obrázek 10 Retrospektiva Pilotního projektu[34] .......................................................................... 34
Obrázek 12 Agile Transition .................................................................................................................... 35
Obrázek 13 Škálování agilních týmů ..................................................................................................... 37
Obrázek 14 Bi-modální organizace ....................................................................................................... 37
Obrázek 15 Fungování SAFe [24] ........................................................................................................... 39
Obrázek 16 Výzvy Agile Transition ....................................................................................................... 40
Obrázek 17 Rozhodovací pravidla ......................................................................................................... 41
Obrázek 18 Agile Development .............................................................................................................. 46
Obrázek 19 Agile maturity assesment ................................................................................................. 50
Seznam tabulek
Tabulka 1 Agile concept [13, Autor] ..................................................................................................... 24
Tabulka 2 Pilot - Scrum vs. Waterfall [34] .......................................................................................... 33
Seznam grafů
Graf 1 Time2Market .................................................................................................................................... 43
Graf 2 Chybovost releasů ........................................................................................................................... 44
Graf 3 Chybovost dodávek ........................................................................................................................ 45
62
Graf 4Agile development - Business hodnota ................................................................................... 47
Graf 5 Agile development - Rizikovost ................................................................................................. 47
Graf 6 Práce agilního týmu ....................................................................................................................... 48
Graf 7 Jsou agilní dodávky kvalitnější? ................................................................................................ 49
Graf 8 Spokojenost s kvalitou .................................................................................................................. 49
Graf 9 Spokojenost s rychlostí ................................................................................................................. 49
Graf 10 Jsou agilní dodávky rychlejší? ................................................................................................. 49
Seznam příloh
Příloha 1 Dotazníkové šetření na Google Forms .............................................................................. 63
Příloha 2 Vyhodnocení dotazníkového řešení .................................................................................. 65
63
Příloha 1 Dotazníkové šetření na Google Forms
64
65
Příloha 2 Vyhodnocení dotazníkového řešení
DPLM -
dotazník_výsledky.xlsx
