Projektové řízení v cloudu

Bankovní institut vysoká škola Praha Katedra Informatiky a kvantitativních metod

Projektové řízení v cloudu Diplomová práce

Autor:

Bc. Jaroslav Síka, DiS. Informační technologie a management

Vedoucí práce:

Praha

Doc. Ing. Vlasta Svatá, CSc.

duben, 2014

Prohlášení: Prohlašuji, že jsem diplomovou práci zpracoval samostatně a v seznamu uvedl veškerou použitou literaturu. Svým podpisem stvrzuji, že odevzdaná elektronická podoba práce je identická s její tištěnou verzí, a jsem seznámen se skutečností, že se práce bude archivovat v knihovně BIVŠ a dále bude zpřístupněna třetím osobám prostřednictvím interní databáze elektronických vysokoškolských prací.

V Písku dne 25.4.2014

Jaroslav Síka

Poděkování Na tomto místě bych rád poděkoval Doc. Ing. Vlastě Svaté, CSc. za její věnovaný čas, odborné rady a připomínky, které vedly k vytvoření této práce.

Anotace Primárním cílem této diplomové práce „Projektový management v cloudu“ je porovnat tradiční způsoby projektového řízení a nástroje používané pro jeho podporu s moderním projektovým managementem v cloud prostředí. V první části práce se zaměřuji na porovnání tradičních rigorózních metodik s vodopádovým přístupem a agilních metodik s iterativním přístupem k řízení projektu. V navazující kapitole se snažím přiblížit jednotlivé podoby nástrojů projektového managementu a způsoby jejich provozování. Další kapitola plynně navazuje popisem možných modelů poskytování služeb spojených s nástroji projektového managementu. Navazující kapitola pak shrnuje vliv prostředí cloud computingu na zmíněné metodiky projektového řízení a jejich adaptabilní vývoj jako reakci na toto prostředí. V poslední kapitole této práce pak popisuji způsob přenosu projektového managementu do prostředí cloud, společně s popisem jednotlivých kroků a reálným porovnáním nákladů variant on-premise a cloud. Klíčová slova: Projektový management, Cloud computing, Rigorózní metodiky, Agilní metodiky, On-premise, On-demand, Outsourcing, PaaS, IaaS, SaaS, BaaS, Privátní cloud, Veřejný cloud, Hybridní cloud, Komunitní cloud, Migrace, ROI, TCO

Annotation The primary target of this diploma thesis „Cloud project management” is comparison of traditional project management with his support tools opposite modern cloud project management. In the first part I compare traditional waterfall methodologies opposite agile methodologies with iterative approach. In the next chapter I am trying to show some forms of providing project management tools with some of their choices. The next chapter describes models of services providing. The following chapter summarizes impact of cloud environment at described project management methodologies and their reaction as adaptive progress. In the last chapter of this diploma thesis I describe possible migration choice of project management to the cloud together with a description of each step and comparing real costs of alternatives on-premise and cloud. Keywords: Project management, Cloud computing, Waterfall methodologies, Agile methodologies, On-premise, On-demand, Outsourcing, PaaS, IaaS, SaaS, BaaS, Private cloud, Public cloud, Hybrid cloud, Community cloud, Migration, ROI, TCO

Obsah ÚVOD......................................................................................................................................... 7 Cíle a přínosy práce ............................................................................................................. 8 1 METODIKY PROJEKTOVÉHO ŘÍZENÍ.............................................................................. 9 1.1 Rigorózní metodiky ..................................................................................................... 12 1.1.1 RUP (Rational Unified Process) .......................................................................... 12 1.1.2 EUP (Enterprise Unified Process) ........................................................................ 15 1.1.3 PM-CMM (Model zralosti projektového managementu) .................................... 16 1.1.4 OPEN (Object oriented Process, Environment and Notation) ............................. 17 1.2 Agilní metodiky ........................................................................................................... 19 1.2.1 Lean development ................................................................................................ 21 1.2.2 SCRUM Development process ............................................................................ 23 1.2.3 XP (Extrémní programování) ............................................................................... 27 1.2.4 Kanban ................................................................................................................. 31 1.3 Porovnání agilních a rigorózních metodik ................................................................... 37 2 SOFTWAROVÉ NÁSTROJE PRO PODPORU PM............................................................ 39 2.1 On-premise nástroje pro podporu projektového řízení ................................................ 40 2.2 On-demand nástroje pro podporu projektového řízení ................................................ 41 2.3 Porovnání On-premise a On-demand........................................................................... 42 2.4 Výběr aplikace - Gartner Magic Quadrant a MarketScope ......................................... 44 2.6 Genius Project .............................................................................................................. 49 3 MODELY POSKYTOVÁNÍ SLUŽEB ................................................................................ 55 3.1 Distribuční model......................................................................................................... 59 3.1.1 Infrastructure as a Service (IaaS) ......................................................................... 61 3.1.2 Platform as a Service (PaaS) ................................................................................ 61 3.1.3 Software as a Service (SaaS)................................................................................ 62 3.1.4 Business as a Service (BaaS) ............................................................................... 63 3.2 Model nasazení ............................................................................................................ 64 3.2.1 Private cloud (Privátní cloud) .............................................................................. 65 3.2.2 Public cloud (Veřejný cloud) ............................................................................... 66 3.2.3 Hybrid cloud (Hybridní cloud)............................................................................. 66 3.2.4 Community cloud (Komunitní cloud) .................................................................. 67 3.3 Smluvní ujednání o poskytování služeb ...................................................................... 68

3.3.1 SLA (Service Level Agreement) .......................................................................... 68 3.3.2 NDA (Non-disclosure agreement) ....................................................................... 70 4 VLIV PM V CLOUDU NA APLIKACI KLASICKÝCH A AGILNÍCH METODIK ........ 72 4.1 Současný stav ............................................................................................................... 73 4.2 Agilní přístup postupně nahrazuje tradiční metodiky .................................................. 74 4.2 Jaká je správná cesta pro budoucnost?......................................................................... 75 5 PROJEKT PŘEVODU PM DO CLOUDU ........................................................................... 77 5.1 Základní kritéria před přechodem ................................................................................ 77 5.2 Měřitelné úspory nákladů - ROI a TCO ...................................................................... 79 5.3 Sestavení metodického rámce ...................................................................................... 84 5.4 Rizika přesunu ............................................................................................................. 86 5.5 Porovnání TCO on-premise a cloud (SaaS) Genius Project ........................................ 87 ZÁVĚR ..................................................................................................................................... 91 Seznam použité literatury ......................................................................................................... 93 Seznam obrázků a tabulek ........................................................................................................ 98

ÚVOD Projektové řízení jinými slovy nazývané projektový management reprezentuje popsané a ověřené postupy a organizované úsilí jak co nejefektivněji řešit a především realizovat vymezené činnosti, tak aby naplnily očekávaný výsledek a přinesly předpokládanou míru užitku. Jak tedy z tohoto názvu vyplývá, předmětem projektového řízení je projekt. Projektové řízení tedy spojuje aplikaci znalostí, technik, nástrojů a průběhu činností tak, aby splnil cíle vymezené na počátku a výstupem bylo naplnění těchto cílů. Pojem cloud computing pak reprezentuje model používání informačních technologií, jehož hlavní charakteristikou je poskytování škálovatelného a sdíleného softwaru či služeb, které jsou dostupné odkudkoliv a především placené pouze na základě toho, co uživatel skutečně spotřebuje. Oficiálních definicí cloud computingu lze nalézt opravdu velké množství, mezi hlavní patří definice dle NIST1 z roku 2011[34]: „Model umožňující být přístupný bez omezení a překážek, umožňující dle potřeb uživatele přístup ke sdíleným síťovým zdrojům škálovatelně konfigurovatelného výpočetního výkonu (sítě, servery, úložiště dat, služby a aplikace …), jehož charakteristickým rysem je rychlá příprava a dodávka s minimem úsilí a iterací poskytovatele“. Aniž bychom si to uvědomovali, s cloudem se setkáváme každý den, většina on-demand aplikací, jimiž jsou kupříkladu internetová fotoalba či sociální sítě, kde sdílíme digitální obsah, jsou provozována na cloud škálovatelných řešeních. Škálovatelné řešení zajišťuje plynulost provozu při vysokých zátěžích a zákazník (uživatel) získal požadovaný či zaplacený obsah, aniž by musel přemýšlet nad samotným provozem technického pozadí aplikace. Samotná souvislost mezi projektovým řízením a cloud computing je pak ukryta v nástrojích, podpůrných aplikacích, ale třeba i spolupráce pracovníků projektového týmu může probíhat virtuálně v prostředí cloud aplikací. Díky širokému rozpětí cloud computingu toto neplatí pouze pro organizace zaměřené na informační technologie, kde by se nejednalo pouze o nástroje na spolupráci pracovníků, ale o celý pracovní prostor od vývojových nástrojů, podpůrných podnikových aplikací až po samotná data. I běžné firmy působící např. ve stavebnictví mohou pomocí aplikačních nástrojů, dostupných online v cloudovém prostředí spolupracovat, vést porady, sdílet průběh jednotlivé milníků a podřízených úkolů, alokovat jednotlivé pracovníky a na základě analytických pohledů hodnotit průběh projektu. Cílem cloud computingu je odbourání požadavků na vlastní IT infrastrukturu, a tím i nákladů na

1

NIST (Národní Institut pro technologie a standardy) – Vědecké laboratoře v rámci Ministerstva obchodu USA

7

lidské zdroje, hardware, operační systémy, software a vedlejší provozní náklady na spotřebované energie. Dalším nesporným benefitem je pohyb v rámci internetu, přístup ke cloudu je možný kdekoliv na světě, to posouvá daného uživatele či společnost mimo pevně vymezenou geografickou oblast své působnosti. Cloud je však také o ústupcích, nutnost používání a především zažití nových metod a technik, neustálý proces vzdělávání se v rychle rostoucím prostředí technologií a inovací denně používaných prostředků. V následujících

kapitolách

si

proto

detailněji

vysvětlíme

známé

metodiky

projektového řízení, zmíníme se o aplikačních nástrojích a jejich způsobu provozu z hlediska umístění. Vysvětlíme si modely poskytování těchto nástrojů a v neposlední řadě si ukážeme nová omezení a požadavky na projektové řízení, které přichází s cloud computingem. V závěrečné kapitole si na příkladu popíšeme, jaké jsou možnosti migrace do cloud prostředí, stanovení potřebných metrik a opatření k zajištění bezproblémové implementace.

Cíle a přínosy práce Cílem této práce je objasnit rozdíl mezi používáním projektového řízení tradičním způsobem a projektovým řízením přeneseným do cloud prostředí. V práci je uveden výčet známých a ověřených projektových metodik a standardů, rozdělení na metodiky rigorózní s tradičním vodopádovým životním cyklem a metodiky agilní, které se snaží omezit nepodstatné části na minimum a zapojit uživatele do projektu. V dalších kapitolách jsou rozebrány podpůrné softwarové nástroje, jejich srovnání a rozdělení na on-premise nástroje v rámci budovy organizace či datacentra a on-demand nástroje, které jsou poskytovány zákazníkovi většinou jako služba provozována v prostředí cloudu. V další kapitole se zaměřuji na přiblížení modelů poskytování služeb, jejich rozdíly a nutné náležitosti potřebné k ochraně smluvních stran. V návaznosti s předchozími kapitolami přiblížím čtenáři vliv přenosu nástrojů projektového řízení do cloud prostředí na zmíněné metodiky a jejich vhodnost pro použití v tomto prostředí. V poslední části se pak zaměřuji na konkrétní postup přenosu projektového řízení do prostředí cloud, tedy nutné procesní změny podniku, promítnutí do stávajícího způsobu projektového řízení, stanovení metrik a přínosu pro zákazníka. Hlavním úkolem práce je poukázat na moderní způsoby a inovace v projektovém řízení, které vedou k odstranění nadbytečných procesů zatěžujících projektové zdroje a poukazují na výhody použití moderních cloud technologií.

8

1 METODIKY PROJEKTOVÉHO ŘÍZENÍ Formou projektu probíhá realizace dodávek produktů či služeb již ve většině dnešních obchodních případů a to nejen v rámci obchodních vztahů B2B2, ale i B2C3. Projektem pak může být například nasazení nového informačního systému v rámci organizace. Existuje řada subjektů poskytujících své produkty či služby výhradně formou projektů. Ve stavebnictví to bývají stavby na klíč, u organizací zaměřených na IT to může být samostatná aplikace či informační systém. Ať už se jedná o jakékoliv odvětví, projektové řízení se týká většiny společností, aniž by si to uvědomovaly. Za účelem efektivity samotného projektového řízení a naplnění očekávaných cílů, jsou zavedeny standardy, jimiž se na mezinárodní úrovni zabývají různé organizace. Mezi nejznámější z nich patří PMI4, IPMA5, OGC6. Odpověď na otázku jakou metodiku projektového řízení zvolit, je pak závislá zpravidla na těchto základních faktorech: •

organizace – typ, vnitřní kultura, velikost a používaný způsob řízení,

•

projekt – předmět, cíle, rozpočet, časové a lidské zdroje, priority a především rizika,

•

projektový manažer – zkušenosti s projekty a především zvolenou metodikou. V úzkém vztahu s metodikami projektového řízení a jejich certifikací jsou samotné

ISO normy, které umožňují certifikovat systém projektového řízení v dané společnosti. Mezi ISO normy zabývající se projektovým řízením patří [26] [27]: •

ISO 10006 (směrnice ČSN/ISO 10006 pro management jakosti projektů) – součást mezinárodních standardů, které vydává International Organization for Standards7 (standard pro systém managementu projektů), kdy se nejedná o metodiku, ale slouží především jako referenční model obsahující zásady a postupy pro nastavení řízení projektů všech typů, má doporučující povahu a nebyla zamýšlena k certifikaci,

•

ISO 21500 (Guidance to Project Management) – navazuje na předchozí ISO 10006 a má formu průvodce projektového řízení a poskytuje komplexnější přístup

2

B2B (Business to Business) – Obchodní vztah mezi společnostmi B2C (Business to Customer) – Obchodní vztah mezi společnostmi a zákazníky 4 PMI (Project Management Institute) – organizace stojící za metodikou PMBOK (Project Management Body of Knowledge) 5 IPMA (International Project Management Association) – nadnárodní sdružení projektových managerů 6 OGC (Office of Government Commerce) – organizace stojící za metodikou PRINCE2 (PRojects IN Controlled Environment) 7 International Organization for Standardization – Mezinárodní Organizace pro Standardizaci

3

9

k projektovému řízení, vychází ze stávajících standardů a na jejím vývoji pracovali odborníci z 36 zemí pod technickým výborem TC 236. Standardy se nevztahují pouze na metodiky samotné, ale také na samotnou klíčovou postavu projektového manažera, kdy existuje jakýsi profesní standard ICB8 a další systémy profesních certifikací. ICB podrobně popisuje tři okruhy kompetencí v rámci tzv. oka kompetencí (ICB competence eye) [25]: •

technické kompetence,

•

behaviorální kompetence,

•

kontextové kompetence.

Obrázek 1- IPMA ICB competence eye (oko kompetencí) [25]

Na základě těchto kompetencí jsou posuzovány dovednosti manažera. Standard vychází z přístupu, který v roce 1974 publikoval sociální psycholog Robert L. Katz9, kdy součástí publikace bylo zamyšlení se nad manažerskými dovednostmi a hierarchickou úrovní managementu, výsledkem byla obdoba ICB oka kompetencí rozdělena do tří okruhů dovedností (Technické dovednosti, Lidské dovednosti, Koncepční dovednosti). Jelikož téma práce pojednává o projektovém řízení v prostředí cloudu, pak následující kapitoly pojednávající přímo o samotných metodikách obsahují vybrané metodiky zaměřené na IT prostředí a nebudou zaměřeny na klasické obecné metodiky projektového řízení, jimiž jsou např. PRINCE2 nebo PMBOK, které nesouvisí příliš s daným tématem této práce. V metodických přístupech lze rozlišit dvě kategorie metodik a to agilní a rigorózní. Hlavním rozlišujícím kritériem těchto metodik je jejich „váha“, tedy metodiky těžké (objemné, detailně a složitě popsané) a lehké (rychlé a jednoduché řešení je často to nejlepší). Slovo těžké a lehké neznamená, že by jedny byly lehčí na pochopení než druhé, ale myslí se 8 9

ICB (IPMA Competence Baseline) – mezinárodní standard kompetencí projektového řízení Robert L. Katz – publikováno v článku „Skills of an Effective Administrator“ v Harward Business Review

10

zde (nadneseně řečeno) objemnost prostředků při jejich použití. Těmito prostředky může být chápána nutná dokumentace projektu, složité vypracování modelů a další zatěžující administrativní náležitosti. Zatímco rigorózní metodiky se snaží dodržovat osvědčený postup, ze kterého se tvoří pomyslná šablona průběhu projektu, tedy je podle tohoto řešení postupováno i v dalších projektech, agilní metodiky se snaží eliminovat všechny nepotřebné náležitosti a především do procesu zapojit zákazníka, což umožňuje získávat důležitou zpětnou vazbu a pružně reagovat na vzniklé změny. Pro zákazníka je samozřejmě lepší mít možnost průběžně reagovat na vývoj a to hned z několika důvodů. Během vývoje zákazník sám zjišťuje, na co se zapomnělo, co naopak není úplně ideální a především zákazník nikdy není schopen na začátku do detailu popsat, co přesně chce. Rigorózní metodiky se snaží projekt do detailu popsat v počátečních fázích životního cyklu (návrhu). Zákazník nemá možnost hovořit do vývoje a je mu předán až hotový projekt. Pozdější změny a úpravy jsou pak řešeny vznikem dalšího projektu. Agilní metodiky tento problém řeší vývojem v iteracích, kdy je nadneseně projekt předáván po částech a za každou iterací může zákazník navrhnout změny. Tabulka 1 - Porovnání rigorózních a agilních metodik [13]

Vývojový proces projektu

Rigorózní metodiky

Agilní metodiky

Jasně definovaný průběh, opakovatelný postup.

Neopakovatelný proces, požadavky vznikají a jsou řešeny v průběhu.

Změny nutné minimalizovat, vše nutné detailně dohodnout na začátku, popř. provést změnové řízení. Zákazník nemá možnost zasahovat do Možnost zapojení zákazníka projektu. Pouze na začátku a na konci. Reakce na změny

Kvalita projektu

Způsob řešení

Náročnost na znalosti týmu

Lidský faktor

Průběh projektu

Zaměřen na kvalitu vlastních procesů než přímo na výsledek.

Změny jsou vždy plánovány pro další iteraci, možnost přehodnocení požadavků v průběhu. Zákazník aktivně zapojen do projektu, mezi iteracemi má možnost změny či nových požadavků. Prioritou je zákazník a jeho spokojenost, tedy kvalita výsledného produktu.

Obsáhlý popis a dokumentace, snahou Snahou je odstranit vše nepotřebné, je popsat vše na začátku. během vývoje nejsou řešeny možné budoucí požadavky. Každý zaměstnanec má svoji roli a Společné řešení problémů, sdílení musí mít maximální znalosti svého znalostí, díky komunikaci v týmu je úkolu. řešení společné. Na lidi pohlíženo jako na Kladen důraz na schopnosti a nahraditelnou součástku. Snaha dovednosti, lidé jsou součást týmu a ten standardizace. je hnací silou. Vodopádový cyklus, fáze probíhají po Vývoj probíhá v krátkých iteracích sobě. přírůstkově. Za každou iterací část celku.

11

1.1 Rigorózní metodiky Rigorózní metodiky spadají mezi metodiky těžké, a jak již toto označení napovídá, nejsou příliš ideální hned z několika důvodů: •

požadavky musí být předem specifikovány,

•

příliš podrobné, hodně formalit kolem,

•

změny jsou náročné a je lepší je potlačit,

•

nedokáží reagovat přímo na požadavky koncových uživatelů. Rigorózní metodiky vycházejí z předpokladů definovat veškeré požadavky předem

tak, aby jednotlivé dílčí procesy byly opakovatelné. Cílem rigorózních metodik je standardizovat zaměstnance v organizaci a dostat je do role zaměnitelné součástky. Rigorózní metodiky jsou postavené na nedůvěře [13]: „Nevěřím ti, že uděláš práci správně, tak tě musím neustále sledovat a kontrolovat“.

1.1.1 RUP (Rational Unified Process) Identifikace a popis metodiky Autor metodiky: Ivar Jacobson, Grady Booch, James Rumbaugh Rok vzniku: 1998 Přístup k řešení: objektový Metodika RUP definuje objektově orientovaný iterativní přístup k životnímu cyklu aplikace. Metodiku vlastní společnost IBM [03] a původně byla vytvořena společností Rational Software Corporation, která se stala samostatnou divizí společnosti IBM. Metodika spadá do skupiny Use Case Driven Approach10, základem je tedy případ užití definován jako sled prováděných akcí systémem či uvnitř něho, poskytující uživateli určitou hodnotu [42]. Pro modelování se zde používá univerzální modelovací jazyk UML (Unifed Modeling Language).

Charakteristika metodiky Dle metodiky je projekt rozčleněn na čtyři základní fáze, každá z nich pak obsahuje iterace, které představují milníky. Než začne nová iterace, je potřeba, aby byla dokončena iterace předchozí. Dalo by se tedy říci, že metodika RUP probíhá v cyklech.

10

Use Case Driven Approach – přístup řízený případy užití

12

Obrázek 2 - Popis projektu dle metodiky RUP [08]

Fáze metodiky RUP: •

zahájení (Inception Phase) – stanovení vizí projektu a definice cílů, na konci fáze se provede zhodnocení, zda projekt bude pokračovat zvoleným směrem nebo bude nutné upravit a předefinovat cíle,

•

příprava (Elaboration Phase) – účelem metodiky je posunout rozhodnutí, která by mohla být pro projekt kritická do počátečních fází projektu, tak aby uskutečněná změna neměla příliš velký dopad na kritické faktory projektu,

•

konstrukce (Construction Phase) – v této fázi probíhá implementace veškeré funkcionality, díky tomuto bývá tato fáze často zdlouhavá a je na místě provést rozdělení do několika iterací, výsledkem každé iterace by měla být hotová spustitelná část aplikace, kterou je možné prezentovat zákazníkovi, náměty a úpravy od zákazníka se pak řeší v dalších iteracích,

•

zavedení (Transition Phase) – tato fáze je zaměřena na předání již hotového produktu zákazníkovi a drobné (z pohledu projektu nekritické) úpravy nebo předání projektu do dalšího cyklu.

Základní filosofií metodiky RUP je set šesti best practice (nejlepších praktik): •

iterativní vývoj software – spočívá v rozložení projektu do čtyř fází, kdy se každá z těchto fází skládá z iterací definovaných vodopádovým životním cyklem. V tomto rozložení se skrývá několik výhod, mezi něž patří (objektivní posouzení stavu

13

projektu, rovnoměrné vytížení vývojového týmu, existence mezi-verzí, včasná identifikace slabých míst návrhu, lepší zpracování změn),

Obrázek 3 - Iterativní vývoj [08]

•

aktivní správa požadavků – díky neustálému kontaktu se zákazníkem je možné zpřesňovat a upravovat požadavky v průběhu projektu,

•

komponentová architektura – komponenty označují části systému poskytující určitou funkcionalitu, to přináší výhody rozdělení projektu mezi několik týmů, lepší zpracování změn a možnost postupné tvorby software,

•

vizuální modelování – jak již bylo zmíněno, k modelování se používá UML, díky grafickému zpracování dochází k zpřehlednění návrhu,

•

ověřování kvality výsledného produktu – produkt je odevzdán do provozu pouze v případě, že splňuje požadavky kladené na funkcionalitu, spolehlivost a výkon. Metodika RUP se také velice rozsáhle věnuje oblasti testování. Definuje role a

aktivity, kterým se má testování věnovat. Testy jsou rozděleny do několika fází, lze je tak efektivně rozvíjet. Výsledkem testů je zpráva obsahující informace, jaké části testování je třeba změnit.

Výhody a nevýhody Obrovská výhoda metodiky je její propracovanost a robustnost, od počátku projektu je definováno jak postupovat až po úspěšné nasazení. RUP detailně definuje workflow, přesně říká, jaké jsou očekávané vstupy a jak by měli vypadat výstupy. Společnost IBM navíc poskytuje obrovské množství doplňkových nástrojů k usnadnění práce.

14

Zmíněné výhody se snadno mohou obrátit v nevýhody, například zmíněná robustnost může být i přes intuitivní navigaci v metodice pro neznalého člověka obrovskou překážkou. Procesy se odvolávají na mnoho dalších míst v metodice, každý z těchto procesů má svůj postup kroků, které je nutné splnit ještě před zahájením. Další nevýhodou je komplexnost, metodika se snaží obsáhnout široké spektrum případů vývoje software a některé kroky se stávají zbytečnými.

1.1.2 EUP (Enterprise Unified Process) Identifikace a popis metodiky Autor metodiky: Scott Ambler, Larry Constantine (verze 2000), Scott Ambler, John Nalbone, Michael Vizdos (verze 2005) Rok vzniku: 2000, přepracovaná verze 2005 Přístup k řešení: objektový

Charakteristika metodiky EUP (Enterprise Unified Process) je postavena jako rozšíření metodiky RUP (Rational Unified Process) a to hned ve dvou směrech: •

povýšení na Infrastructure Management neboli na úroveň managementu celé organizace,

•

přidání fází Production (provoz a support produktu) a Retirement (popis kroků nutných pro stažení produktu z používání) [09].

Obrázek 4 - Enterprise Unified Process [20]

Cílem metodiky je překonat omezení metodiky RUP (Rational Unified Process), ikdyž stejně jako metodika RUP pokrývá malou skupinu rolí, je prakticky zaměřena pouze na role, které jsou spjaté s vývojem software a to pouze na objektově orientovaný vývoj. Jak již bylo napsáno v předchozích větách, metodika je zaměřena na úroveň managementu celé 15

organizace, je tedy ideální např. pro vytváření globální architektury vnitropodnikového informačního systému nebo řízení celého portfolia projektů.

Výhody a nevýhody Výhodou je rozšíření metodiky o infrastrukturní management, nezaměřuje se tedy pouze úzce na vývoj software, ale umožňuje efektivní řízení celé organizace. EUP je tedy oproti RUP spíše globální metodikou vhodnou nejvíce pro celopodnikové informační systémy. Značnou výhodou je přidání fází provozu, údržby a odstranění produktu. I přes výše zmíněná pozitiva trpí metodika stejnými symptomy jako metodika RUP, její použití je úzce spjaté s vývojem software a rozvojem stávajícího software. Některé procesy tak nelze adaptovat na jiné produkty, stejně pak jako u RUP jsou některé procesy při určitých projektech zbytečné a neproduktivní.

1.1.3 PM-CMM (Model zralosti projektového managementu) Identifikace a popis metodiky Autor metodiky: Institut pro softwarové inženýrství Rok vzniku: 2000 Přístup k řešení: nerozlišuje Model zralosti PM (Capability Maturity Model for Project Management) nebo PMCMM spadá do rodiny modelů zralosti a vznikl jako modifikace Software CMM (někdy také SW-CMM), který byl vyvinut v roce 1991 Institutem pro softwarové inženýrství pro účely hodnocení dodavatelů software pro ministerstvo obrany USA.

Charakteristika metodiky Oproti samotnému CMM je účelem poskytnout organizacím pohled na hlavní aspekty projektového řízení [40]: •

posoudit výkonost projektového řízení oproti předpokládanému průměru,

•

umožnit interní či externí hodnocení projektového řízení,

•

poskytnout nástroj pro pravidelné měření zlepšení. Výsledkem je celkový stupeň zralosti, silné a slabé stránky projektového řízení a

zvýraznění oblastí možného zlepšení, projektový management je pak dělen na stupně zralosti:

16

•

neformální projektový management – málo definované procesy řízení projektu a projektové týmy často spoléhají na vlastní zkušenosti, týmy ani procesy nejsou integrovány,

•

strukturovaný projektový management – klíčové (core) procesy jsou definovány, klíčové role a odpovědnosti jsou jasně stanoveny,

•

integrovaný projektový management – funkční procesy jsou definovány a integrovány, výstupy jsou měřitelné a objektivní,

•

vysoce výkonný projektový management, orientovaná kultura – funkční procesy jsou integrovány od začátku projektů, inteligentní KPI k dispozici pro všechny projekty, organizace má jasnou strategie a plány na zlepšení projektového managementu. Model je strukturován tak, aby hodnotil zkušenosti projektového řízení v organizaci do

tří okruhů: •

organizace a kultura v organizaci,

•

procesy projektového řízení,

•

systémy projektového managementu a informace.

Výhody a nevýhody Značnou výhodou modelů CMM je, že jsou založeny na nejlepších praktických zkušenostech. Výsledkem použití CMM je pak zpřehlednění projektu, upřesnění rolí na projektu, zlepšení kvality a dokumentace. Nevýhody lze spatřit v dokumentaci, která zvyšuje časovou režii. Další nevýhodou mohou být další potřebné zdroje a znalosti nutné k zlepšování procesů. Asi největší překážkou je často nutná změna firemní kultury a celkových postojů k řízení projektů.

1.1.4 OPEN (Object oriented Process, Environment and Notation) Identifikace a popis metodiky Autor metodiky: Brian Henderson–Sellers, Meilir Page Jones, Ian Graham, Donald Firesmith a další z konsorcia OPEN Rok vzniku: 1997 Přístup k řešení: objektový

17

Metodika OPEN je zaměřena na vývoj objektově orientovaných a komponentových aplikací. Konceptuálně vychází z projektu COMMA11 a o její vytvoření se postaralo konsorcium OPEN sdružující přes 40 metodiků, vývojářů a dodavatelů CASE nástrojů [37].

Charakteristika metodiky Metodika definuje procesní rámec OPF (OPEN Process Framework), jinými slovy procesní metamodel, ze kterého jsou generovány organizačně specifické instance. Ty jsou tvořeny výběrem činností, úloh a technik (tří hlavních tříd metaúrovně) a specifickou konfigurací, což je obecně označováno jako proces construction (konstrukce procesu). Dále rozlišuje přizpůsobení procesu, tedy přizpůsobení zmíněných úloh, aby odpovídaly problematice domény. Díky těmto vlastnostem je metodika použitelná jak k problematice domény, tak i danému projektu a lze ji využít pro malé i velké projekty. OPEN pokrývá celý životní cyklus software, jehož součástí je řízení projektu a možnost znovu použitelnosti. OPEN má vazby na metodiku CMM (Model zralosti), čemuž i odpovídá její zaměření na metriky a kvalitu software. OPF obsahuje mnoho metatříd, které jsou rozděleny do 5 ti hlavních skupin, jež vytvářejí knihovnu komponent metodiky OPEN, která pak tvoří instance metodiky: •

pracovní produkty,

•

pracovní jednotky,

•

producenti,

•

etapy,

•

jazyky. Metodika OPEN je velice podrobná a zaměřená pouze na úroveň projektu samotného,

hodnotné jsou možnosti vytváření metodiky z metatříd patřících do OPF.

Výhody a nevýhody Výhodou metodiky OPEN je její možnost přizpůsobení se konkrétním projektům, lze ji využít jak pro malé tak větší projekty. Metodika je velice podrobná a přínosem je možnost vytváření metodiky z metatříd, které jsou součástí OPF. Mezi nevýhody patří zaměření metodiky pouze na úroveň projektu a objektově orientovaný přístup nového řešení. 11

COMMA (Common Object Methodology Metamodel Architecture) – cílem bylo vytvoření metamodelů různých metodik a metod objektově orientované analýzy a návrhu pro vytvoření univerzální metodiky

18

1.2 Agilní metodiky Prostředí dnešní doby je dynamické a díky častým změnám technologií a ekonomiky je kladen důraz na rychlé změny, rychlejší způsob vývoje a to vyžaduje změnu i samotných metodik. Rigorózní metodiky přestávají v takovém prostředí vyhovovat a je kladen důraz na rychle vytvořené řešení a možnost ho přizpůsobovat rychle měnícím se požadavkům. Metodiky, které jsou odpovědí na tyto požadavky, se nazývají agilní. Základní myšlenkou těchto metodik je předkládat zákazníkovi vždy hotovou část software a na základě zpětné vazby ho potom upravit. Představitelé agilních metodik uznávají totožné hodnoty a v roce 2001 se dohodli na sepsání „Manifestu agilního vývoje“ a došlo k vytvoření aliance pro agilní vývoj software. Manifest samotný se opírá o čtyři základní zásady, kde výroky na levé straně ukazují vyšší váhu významu oproti výrokům na straně pravé. Citace samotného Manifestu pak zní [12]: „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ě 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.“ Tyto zásady deklarují 12 principů, o které je třeba se při vývoji opírat, citace [12]: 1. Naší nejvyšší prioritou je vyhovět zákazníkovi časným a průběžným dodáváním hodnotného softwaru. Tento princip popírá znění rigorózních metodik, kde předání celého hotového projektu je úspěch i z pohledu zákazníka a říká, že zákazníka zajímá fungující funkcionalita za každou iterací, aby mohlo být včas reagováno na změny a především neustálé prověřování spokojenosti zákazníka je klíčem k úspěchu projektu. 2. Vítáme změny v požadavcích, a to i v pozdějších fázích vývoje. Agilní procesy podporují změny vedoucí ke zvýšení konkurenceschopnosti zákazníka. Principem agilních metodik je pružné reagování na změny a tím eliminovat možná rizika. Zkrácením iterací je možné lépe reagovat na změny. 3. Dodáváme fungující software v intervalech týdnů až měsíců, s preferencí kratší periody. 19

Zkrácením iterací a agilním způsobem vývoje dostává zákazník vždy fungující část software. 4. Lidé z byznysu a vývoje musí spolupracovat denně po celou dobu projektu. Principem není dodat na začátku podrobný plán projektu, nýbrž hrubý náčrt. Prakticky denní komunikací mezí týmy je možné upřesňovat požadavky a reagovat tak i na malé změny, které by v celkovém konceptu hráli obrovskou roli. 5. Budujeme projekty kolem motivovaných jednotlivců. Vytváříme jim prostředí, podporujeme jejich potřeby a důvěřujeme, že odvedou dobrou práci. Každý projekt stojí na lidském faktoru, dobrá motivace je klíčem k úspěchu. 6. Nejúčinnějším a nejefektnějším způsobem sdělování informací vývojovému týmu z vnějšku i uvnitř něj je osobní konverzace. Agilně řízené projekty nestojí na obsáhlé dokumentaci či manuálech, problematika se vždy nejlépe vysvětlí přímou verbální komunikací. 7. Hlavním měřítkem pokroku je fungující software. Úspěch každé iterace i celého projektu stojí na fungujícím software, který může zákazník vyzkoušet. Na základě předání hotové části za každou iterací je možné měřit úspěch. 8. Agilní procesy podporují udržitelný rozvoj. Sponzoři, vývojáři i uživatelé by měli být schopni udržet stálé tempo trvale. Aby nedocházelo k tzv. únavě týmu, je nutné dodržovat přesnou pracovní dobu, vyhýbat se přesčasům, dokázat lépe organizovat práci a ukázat členům týmu, že základ dobré práce netkví v přesčasech a kvalitní produkt lze vytvořit během standardní pracovní doby. 9. Agilitu zvyšuje neustálá pozornost věnovaná technické výjimečnosti a dobrému designu. Účelem není rychle vytvořit zmetek. Software postavený na kvalitních technologiích a dobrém designu je to co zákazníka zajímá. 10. Jednoduchost--umění maximalizovat množství nevykonané práce--je klíčová. Nejjednodušší řešení bývá často to nejlepší. 11. Nejlepší architektury, požadavky a návrhy vzejdou ze samo-organizujících se týmů. Tento princip ukazuje, že by měl být vždy dán prostor kreativitě lidí v týmu. 12. Tým se pravidelně zamýšlí nad tím, jak se stát efektivnějším, a následně koriguje a přizpůsobuje své chování a zvyklosti. 20

Prostor pro komunikaci v týmu vede často k dobrým nápadům a myšlenkám, které posouvají vývoj do jiné sféry. Principem agilního manifestu není tvořit software složitě a vést zákazníka naším směrem a odevzdat produkt postavený dle obecného modelu. Agilní přístup je o komunikaci mezi zákazníkem a členy týmu, snažit se odevzdávat funkční části, kde zákazník může otestovat funkcionalitu dané části. To umožňuje pružnou reakci na změnu, která není v tak velké měřítku. Průběh takové iterace je znázorněn na následujícím obrázku.

Obrázek 5 - Agilní vývoj [10]

1.2.1 Lean development Identifikace a popis metodiky Autor metodiky: Robert Charette Rok vzniku: 2001 Přístup k řešení: objektový Lean development je metodika, která vychází z přístupů zeštíhlení výroby v automobilovém průmyslu 80. let, známých jako „just in time production“ a byla propagována koncernem Toyota [30]. Lean development pak přenesl tyto principy do vývoje software, kde je jeho základem dokázat se přizpůsobit dynamickému prostředí, rychle a efektivně pak reagovat na změny s třetinovými požadavky na lidské, finanční a časové zdroje.

21

Charakteristika metodiky Dalo by se zjednodušeně říci, že metodika Lean development se opírá o 7 základních principů, popsaných v knize Toma a Marie Poppendieckových [05]: 1. eliminace zbytečností - Principem je eliminovat zbytečné, tedy procesy, které jsou zbytečné a marnotratné, tímto je myšleno vše, co nemá pro finální produkt zřejmou hodnotu, tedy zbytečné výrobní produkty navíc. U vývoje to mohou být zbytečné a nepotřebné kusy kódu, modely atp. V původním textu společnosti Toyota zní originální Japonská definice následovně: „Muda“ (neproduktivní), „Mura“ (nevyrovnané, nekonzistentní), „Muri“ (zatěžující, bezdůvodné). 2. integrovat kvalitu do produktu - Základem tohoto pravidla je eliminovat chyby během vývoje, k tomuto lze využít jak párové programování12, tak další metody jak eliminovat chyby, které ovlivňují kvalitu výsledného produktu. 3. vytváření znalostí - U vývoje software je poznání a tvoření znalostí prvořadé, tak abychom byli produktivní, je potřeba neustálé zvyšování znalostí v týmu, ať už tomu napomáhá společné řešení úkolů a předávání znalostí mezi zkušenými i méně zkušenými členy týmu, vždy je však nutné samotné procesy uzpůsobit tak, aby aktivně docházelo k procesu učení. 5. odložit závazky - Odkládat zásadní rozhodnutí jak jen to je možné a ponechat své možnosti otevřené jak jen to je možné. Toto platí obzvlášť u rozhodnutí, které nelze vzít zpět nebo by jeho oprava byla obtížně řešitelná. Budeme-li o problému vědět více, pak je naše konečné rozhodnutí o to lepší, protože jsme získali všechny možné podklady. Příliš brzké rozhodnutí může způsobit nečekané riziko a z toho plynoucí další problémy. 6. dodat co nejrychleji - U vývoje software je obtížné tento princip dodržet, byť se často jedná o jednoduchou záležitost, lidé zachází příliš hluboko do detailu a myslí na požadavky, které by se mohly vyskytnout někdy v budoucnu a často se ani nevyskytnou. Tímto dochází k vlastní blokaci, kdy si myslíme, že bez informací druhého nejsme schopni sami rozhodnout. Důležité je dokázat pracovat jednoduše, přenést rozhodnutí i do nižších vrstev, tak aby mohl rozhodnout např. i samotný vývojář. 7. respektovat lidi - Nezáleží, zda jste ředitel, vývojář či konzultant, je důležité dokázat vyslechnout názory druhých, respektovat je a dát jim možnost rozhodnout o své práci. Tím

12

Párové programování – aplikování myšlenek dvou vývojářů, nebo-li při vývoji dané části posadit dva programátory k sobě, zdvojnásobí se myšlení nad problémem a zároveň jeden vývojář kontroluje druhého

22

dochází k posilování sebedůvěry, vedoucí k vyšší produktivitě. Potenciálně tak dáváme možnost i níže postavenému zaměstnanci k ventilování dobrých nápadů. 8. optimalizace týmu - Posilování kultury v týmu vede ke zlepšení produktivity práce, vztahů na pracovišti a především k předání kvalitního produktu. Je tedy důležité posilovat tým, aby působil jako funkční celek se společnými cíli. Podstatou Lean metodiky je hodnotný přínos produktu, pokud se toto nepodaří, je považován za marnotratnost a stává se zbytečným. Lean development definuje šest druhů plýtvání: •

nadvýroba,

•

čas trávený čekáním,

•

plýtvání související s přepravou,

•

plýtvání související se zpracováním,

•

neefektivní práce,

•

defekty na výrobcích.

Výhody a nevýhody Výhoda metodiky je bezesporu odstranění zbytečností, což vede k vyšší efektivitě a zrychlení procesu vývoje, což se stává v dnešní době nezbytností. Odbouráním zbytečností a tím získání časových rezerv má i pozitivní vliv na samotné vývojáře. Jako nevýhodu lze spatřit nutnou soudržnost týmu a jeho disciplinovanost. U týmu hnací silou jeho členové, kteří musí disponovat patřičnými znalostmi, tak aby se navzájem doplňovali. Absencí kvalifikovaných členů týmu je od počátku tato metodika neefektivní.

1.2.2 SCRUM Development process Identifikace a popis metodiky Autor metodiky: Ken Schwaber, Jeff Sutherland, Mike Beedle Rok vzniku: 1995 Přístup k řešení: objektový Autory metodiky jsou Mike Beedle a Ken Schwaber a její představení proběhlo v roce 2002. Z agilních metodik patří mezi nejmladší a bývá často modifikována do dalších nových metodik. Název metodiky je inspirován Ragby, kde SCRUM v překladu znamená „mlýn“.

23

Autoři hru připomínají k prostředí vývoje software, který je stejně jako v rugby plný nečekaných událostí a změn, na které je třeba rychle reagovat.

Charakteristika metodiky Metodika se zabývá tím jak vést software během životního cyklu, řeší spolupráci a komunikaci v týmu, jak co nejrychleji reagovat na změny a co nejrychleji dovést projekt k cíli. Jejím úkolem je sledování a eliminace překážek, které by mohli nastat při cestě k cíli. Jako ostatní agilní metodiky vychází z manifestu agilního vývoje, je tedy iterativní, pružná a klade důraz na rychlé dodávky byť částí aplikace za každou iterací, za kterou sbírá zpětné vazby a změny od zákazníků, na které se snaží co nejrychleji reagovat.

Základní pojmy metodiky SCRUM Backlog - Existují dva druhy Backlogů, kdy prvním z nich je Product Backlog, který definuje požadavky zákazníka na software a definuje se priorita každého požadavku, vše je pak setříděno dle logických celků pro větší přehlednost. Položky jsou průběžně aktualizovány, přidávány a mazány, aby odpovídali aktuálním požadavkům. Tým poté z těchto položek vybírá položky k realizaci a ty pak vkládá do jednotlivých Sprint Backlogů a jsou realizovány v rámci uskutečněného Sprintu. Sprint - Pravidelně opakující se iterace, jejich délka je průměrně 30 dnů, kdy na začátku každého sprintu vybere SCRUM Master s týmem pro tento Sprint záznamy z Product Backlogu, tato schůzka se nazývá Sprint Planning Meeting. Výběr je řízen prioritami definovanými zákazníkem a spolu s celky je z nich sestaven Product Backlog. Takto vybrané záznamy se přesunou do Sprint Backlogu, kde tým odhadne pracnost a přejde se k realizaci. Na konci Sprintu je opět schůzka, na které je tématem co vše se stihlo udělat a na jaká nová zjištění se během Sprintu přišlo. Daily Scrum - Jedná se o další typ iterace, která trvá 24hodin. Účelem této krátké iterace, kdy na začátku každé probíhá SCRUM meeting je být neustále informován o probíhajících pracích na projektu a pružně tak reagovat na vzniklé problémy. Flexible Deliverables (Flexibilní předměty dodání) - Výsledný produkt není nikdy přesně určen, jeho podoba odpovídá prostředí, pro které je produkt vyvíjen. SCRUM metodika nenařizuje přesný postup nebo normy, analýza produktu je často lépe vyjádřena pomocí modelu než striktních norem.

24

Effort Estimation (Odhad pracnosti) - Pracnost je odhadována průběžně za pomoci údajů z Product Backlogu, které se průběžně mění a především zpřesňují, jejich určování má na starost Product Owner se členy týmu.

Odpovědnosti a role SCRUM SCRUM Master - Odpovídá za průběh projektu, komunikuje se zákazníkem, ale i s managementem a vývojáři. Jeho úkolem je dokázat odstranit překážky bránící dosažení cílů projektu. Product Owner (vlastník produktu) - Je určen SCRUM Masterem, managementem a zákazníkem, stojí mezi dodavatelem a zákazníkem. Jeho úkolem je udržování Product Backlogu, má hlavní slovo a rozhoduje o úpravě položek, které však smí upravovat jen mezi Sprinty. SCRUM Team (tým) - Úkolem týmu je řešit položky daného Sprintu a zároveň vybírat položky z Product Backlogu a sestavovat aktuální odhad pracnosti a časový plán. Customer (zákazník) - Zákazní se často podílí na sestavení položek pro Product Backlog. Management - Podílí se na sestavení položek celého projektu, provádí důležitá rozhodnutí a má na starost obchodní záležitosti a uzavírání smluv. User (uživatel) - Koncová osoba, pro kterou je produkt tvořen, je zpětnou vazbou.

Fáze vývoje Pregame (Předehra) - Tato fáze se dělí na následující dvě pod-fáze: •

plánování – definice software, jež má být vytvořen, sestavuje se Product Backlog se všemi známými požadavky a ty se řadí dle priorit a odhaduje se potřebné úsilí pro jejich implementaci, které jsou zpočátku nepřesné a upravují se podle situace. V této fázi se sestavuje projektový tým, definují se zdroje a rizika.

•

návrh a architektura – základem je Product Backlog z předchozí fáze, definuje se analýza a plány pro obsah jednotlivých verzí systému. Definuje se návrh software na vysokém stupni abstrakce.

Game (Hra) - Hlavní část metodiky SCRUM (vytváří se produkt), je obvykle členěna do několika Sprintů, každý z nich trvá 30 dnů a probíhají veškeré vývojové fáze, tedy sběr požadavků, analýza, návrh, vývoj, testy a předání. Výsledek každého tohoto Sprintu je prezentován zákazníkovi. 25

Postgame (Dohra) - Tato fáze nastává až poté, co je zpracovaný celý Product Backlog a nedochází k dalším přidáváním požadavků nebo modifikací zákazníkem. V této fázi se vytváří finální Release produktu.

Obrázek 6 - Fáze SCRUM projektu [49]

Schůzky v průběhu projektu [06] Planning Meeting (Plánovací schůzka pro Sprint) - Tato schůzka probíhá před každým Sprintem a je organizována SCRUM Masterem. Schůzka samotná je rozdělena do dvou částí po čtyřech hodinách, kdy na první části je přítomen zákazník, uživatelé, management, product owner a samozřejmě SCRUM Team. Na této schůzce se stanovují cíle Sprintu z Product Backlogu a částí, které budou v průběhu tohoto Sprintu zařazeny, a to vše se sestaví do Sprint Backlogu. Druhé části se již účastní pouze SCRUM Master a SCRUM Team a náplní této schůzky je konkrétní implementace položek. Daily Meeting - Na začátku každého dne svolá SCRUM Master zhruba 15 až 30 minut dlouhou schůzku v závislosti od velikosti týmu. Schůzky se účastní celý tým, kdo přijde pozdě je pokutován SCRUM Masterem a pokud přijde pozdě samotný SCRUM Master, je pokutován každým členem týmu. Nepovinně se také mohou účastnit členové managementu, zákazník, uživatelé i Product Owner, nikdo z nich však nesmí aktivně vstupovat do programu schůzky a měli by mlčet. Každý člen týmu je dotázán na tři otázky, mluví vždy jeden a začíná ten po levici SCRUM Mastera (postupuje se po směru hodinových ručiček) a nemělo by se odbočovat od tématu: •

co udělal od posledního SCRUMU (schůzky),

•

co bude dělat do dalšího SCRUMU (schůzky), 26

•

zda nenarazil na nějaké překážky. Odpovědi se zaznamenají a jsou řešeny po ukončení schůzky kvalifikovaným týmem,

který je schopen danou problematiku řešit. Sprint Review (Hodnotící schůzka) - Probíhá vždy poslední den Sprintu, organizuje ji SCRUM Master a účastní se jí SCRUM Team, Product Owner, management a uživatelé se zákazníkem, kterému se předají výsledky Sprintu. Předává a ukazuje se pouze to, co je uděláno, neprezentují se vlastnosti, které ještě nejsou vyřešeny. S výsledky začíná zástupce dodavatele, který prezentuje výsledky Sprintu a co by mělo být vyškrtnuto z Product Backlogu jako dokončené. Jako druhý dostává slovo zákazník a případné úpravy jsou zaneseny zpět do Product Backlogu, poté následuje diskuze. Na závěr schůzky, která by neměla překročit čtyři hodiny SCRUM Master oznámí příští termín schůzky. Retrospective Meeting (Retrospektivní schůzka) - Schůzka by neměla překročit 3 hodiny, účastní se jí pouze tým, SCRUM Master a Product Owner (jeho účast je nepovinná). Začíná se dvěma otázkami na každého člena týmu: •

Co bylo dobře uděláno během Sprintu?

•

Co by se dalo vylepšit v dalším Sprintu? SCRUM Master zapisuje odpovědi do shrnujícího formuláře a tým upřesňuje, v jakém

pořadí chce hovořit o potenciálních vylepšeních. SCRUM Master zde není pro odpovědi, ale aby pomohl týmu najít správnou cestu k provedení. Objektivní položky mohou být přidány do Product Backlogu. Položky, které nepodávají zřetelný výsledek, jsou vynechány.

Výhody a nevýhody Výhodou metodiky SCRUM je pružnost reakce na vývoj projektu, kdy díky krátkosti iterací se lze zaměřit na problematické části a jejich odbourání. Díky způsobu vývoje a vedení projektu při použití SCRUM dostává každý člen možnost realizace svých nápadů. Nevýhodou je asi jako u většiny agilních metodik nutnost dobrého a motivovaného týmu. Bez kolektivních znalostí a odhodlání členů týmu, nelze projekt dovést ke správnému konci. Někdy bývá problém v nutnosti vyšší účasti zákazníka na projektu.

1.2.3 XP (Extrémní programování) Identifikace a popis metodiky Autor metodiky: Kent Beck, Ward Cunningham, Ron Jeffries 27

Rok vzniku: 1999 Přístup k řešení: objektový Metodika extrémního programování vznikla v roce 1999, jako reakce ne problémy řešení projektů tehdejší doby.

Charakteristika metodiky Metodika řeší projekty extrémně, platí tedy: „Pokud něco funguje, pojďme to využívat v maximální možné míře (extrémně).“ Základní z tohoto plynoucí pravidlo metodiky zní [02]: „Jediným exaktním, jednoznačným, změřitelným, ověřitelným a nezpochybnitelným zdrojem informací je zdrojový kód“ Jak tedy vypovídá i samo toto pravidlo, Extrémní Programování se zaměřuje především na psaní zdrojového kódu. Metodika samotná je velmi striktní a drží se pravidel. Její bezesporu obrovskou výhodou je její populárnost a obrovské zastoupení, lze tedy najít mnoho internetových zdrojů a knih se zaměřením na tuto metodiku. Tvoří ji 12 pravidel, která se rozdělují do následujících tří oblastí:

Byznys praktiky Plánování hry – Během této části zákazník společně s vývojáři sestavuje zadání (User Stories), programátoři zákazníkovi tvoří zpětnou vazbu, on tak získá přehled, jak dlouho požadavky trvají. Požadavky jsou řazeny dle priority. Zákazník se musí rozhodnout, co je důležité a bude implementováno jako první. Zákazník na pracovišti – Požadavkem je, aby byl zástupce zákazníka neustále přítomen na pracovišti u vývojářů, nemyslí se tím zákazník obecně nýbrž osoba, která bude koncovým uživatelem software. Malé verze – Účelem je dodávat zákazníkovi nové verze tak často jak jen to jde, vývojáři pak mají zpětnou vazbu a zákazník zná průběh projektu, na což může lépe reagovat. Metafora – Metafora slouží jako systém jmen a popisů, která jsou snáze zapamatovatelná, jednoduchá a především známa celým týmem a zákazníkem.

Týmové praktiky Párové programování – Dva lidé píší kód u jednoho počítače, kdy zatímco jeden píše kód, druhý přemýšlí nad optimalizací a průběžně dochází k revizi. Role se obměňují a často se obměňuje i pár. 28

Společné vlastnictví – Metodika říká „Kdokoliv může kdykoliv měnit jakoukoliv část kódu“, čímž dochází ke zvýšení „truck faktoru“, aby částem kódu rozumělo více lidí a ne pouze jediný člověk, který může např. odejít ze společnosti. Standardy pro psaní zdrojového kódu – Během vývoje je nutné si vytvořit určité standardy kódu, tak aby kdokoliv z týmu, kdo bude číst kód, chápal jeho obsah. Spadají sem pravidla pro psaní komentářů kódu, specifické pojmenovávání atp. Udržitelné tempo – Přesčasy jsou nežádoucí a kdokoliv je unaven, ten podává menší výkon, je deprimován a začíná dělat chyby, u vývojářů je toto nežádoucí. Je tedy nutné dodržovat pracovní dobu a čas vymezený pro práci.

Programovací praktiky Neustálá integrace – Nutné je, aby veškeré změny byly integrovány co nejdříve, minimálně jednou denně do výsledného produktu a bylo vidět co je hotovo a mohlo se testovat, čímž dochází k okamžité reakci na chyby. Jednoduchý návrh – Pravidlem je vytvářet vždy jen to co je potřeba, návrhy budoucích funkcionalit jsou nežádoucí, jelikož požadavky se stejně mění. Refaktorizace – K vylepšování dochází tím, že se programátoři neustále kontrolují a zjišťují, jaká část kódu by se dala vylepšit a nejlépe zjednodušit. Kód vlastní všichni společně proto ho může upravovat kdykoliv a díky standardům je kód čitelný i pro druhé vývojáře v týmu. Díky sadě testů je vývojář jištěn před vznikem chyb, a pokud vzniknou, jsou snadno eliminovány. Důležité však je, aby při refaktoringu nedocházelo k budování nových funkcionalit, nýbrž pouze vylepšování kódu. Testování - Metodika nemá striktně stanovenou podobu testování, používají se Unit testy a požaduje se, aby funkční testy připravoval zákazník, jelikož nejlépe ví, co potřebuje a chce. Vývojáři začínají vždy psaním testů, až poté píšou vlastní kód. Testy musí být vždy splněny na 100%.

Životní cyklus definován dle autora metodiky [01] Explorační fáze - Na kartičky zadání (Story Cards) zákazník popíše možnosti využití software (User Stories), které by rád viděl v první fázi. Iterace trvá od několika týdnů až po několik měsíců.

29

Plánovací fáze - V této fázi, které zabere několik dnů, dává zákazník priority jednotlivým požadavkům, vývojáři pak odhadují, jak dlouho může implementace jednotlivých kartiček zadání (Story Cards) trvat. Několik kartiček se pak vybere do první iterace. Iterační fáze - Fáze iterací probíhá až do vytvoření výsledku, v první iteraci se stanovuje hrubý model systému, přičemž na začátku každé iterace vybírá zákazník, co se bude implementovat a na konci iterace výslednou část otestuje. Produkční fáze - Tato fáze probíhá až po úspěšném vytvoření části produktu (Release) z předchozí fáze, kdy v této fázi probíhá testování a ověření schopnosti nasazení u zákazníka. Fáze údržby - V této fázi je úkolem udržovat systém na straně zákazníka a vytvářet další iterace. Fáze smrti produktu (Death Phase) - Tato fáze vzniká, až když zákazník nemá žádné další požadavky a nejsou prováděny žádné úpravy produktu, v této fázi vzniká také finální dokumentace.

Role Metodika poměrně přísně určuje, kdo bude mít co na starost a jakou bude mít zodpovědnost. Zákazník (Customer) Konzultant (Consultant) Vývojář (Programmer) Tester Kouč Manager (Big Boss) Stopař

Výhody a nevýhody Mezi velké pozitiva metodiky patří malé zatěžování týmu zbytečnou byrokracií, nejsou definovány žádné typy dokumentů, vše se řeší komunikací a je na dohodě. Díky tomuto je extrémní programování velice oblíbené a vydalo se mnoho rozšíření a pro vývojový tým je celá metodika velice intuitivní. Mezi nevýhody se řadí oblasti, kde lze Extrémní programování využít, což jsou malé a střední projekty, u velkých projektů může docházet k chaosu, autor tedy doporučuje použití u týmů o velikosti 3 až 20 lidí. Další nevýhodou je samotné zavádění, lidé si často hůře zvyknou na změny, které jsou zde obrovské, ať už se

30

jedná zamezení administrativy, kdy nejsou požadovány návrhy, dokumentace a je po nich požadováno, aby přemýšleli jednoduše a nebáli se změn.

1.2.4 Kanban Identifikace a popis metodiky Autor metodiky: Taiichi Ohno Rok vzniku: není přesně znám, cca 70. léta 20. století Přístup k řešení: objektový

Charakteristika metodiky Systém Kanban patří mezi mladší členy agilních metodik, jeho autorem je Taiichi Ohno a vznikl jako produkční systém výroby ve společnosti Toyota. Cílem systému bylo optimalizovat produkci výrobní linky s využitím agilního přístupu, vizuální komunikace a zapojení zaměstnanců. Samotné slovo Kanban v překladu znamená oznamovací štítek či informace. Společnosti zabývající se vývojem software nebo poskytováním služeb chtějí, aby průběh projektu např. vývoje software či projektu implementace služby byl předvídatelný, tedy vědět jaká práce je třeba udělat a kolik času na to bude potřeba. Aby tyto atributy bylo možné sestavit, je třeba mít stanovené určité mechanismy, jako je stanovení priorit a správné pracovní postupy (workflow). I pokud je toto vše správně provedeno, je zde dost velké riziko, že nastanou události, které nebyli předvídané. Ať už se jedná o absenci klíčového zaměstnance, zásadní změny v projektu či jeho prostředí, je nutné dokázat pružně a rychle reagovat na nutné úpravy. Kanban se zabývá aktuálně probíhajícími procesy vývoje či průběhu projektu a poskytuje lepší přehled o stavu prací a jejich průběhu. Kanban jednoduše poskytuje metodu adaptace na nové příchozí požadavky a úkoly, čímž zabraňuje vznikání krizových situací. Kanban také přináší směr jak investovat energii pouze do hodnotné práce. Výsledkem je práce, která je předvídatelná a vykazuje vysokou užitnou hodnotu. Medoda Kanban minimalizuje risk a zvyšuje flexibilitu, to má za následek mnohem odolnější vývojový cyklus.

Proč Kanban? Proč bychom měli dělat změny ve vývojovém týmu? Zde je seznam benefitů, které získáme použitím metody Kanban.

31

optimalizace existujících procesů - Zavedení vizualizace a optimalizace probíhající práce (WIP13) vytvoří změnu s minimálním narušením. produkty s vyšší kvalitou - Optimalizace probíhající práce (WIP) a definice pracovních priorit přináší větší zaměření na kvalitu. zlepšování dodacích lhůt - Mezi probíhající prací (WIP), dodací lhůtou a četností chyb existuje vztah, optimalizací probíhající práce (WIP) lze zlepšit dodací lhůty a ovlivnit četnost chyb. zlepšení spokojenosti zaměstnanců - Spokojený zaměstnanec pracuje lépe a tvoří méně chyb. Redukcí přetěžování zaměstnanců, přeskakování z jedné práce na druhou získá zaměstnanec volnější pracovní tempo a prací na jednom úkolu dochází k lepší soustředěnosti a snížení celkové doby na dokončení. jednodušší priorizace - Kanban umožňuje rychlou reakci na změny a uzpůsobení priorit. transparentní systém návrhu a operací - Transparentní systém umožňuje budovat důvěru u zákazníků a manažerů. Výsledkem je zlepšení spolupráce. vznik vysoce vyspělé společnosti - Se vznikem a implementací vylepšení dochází k lepšímu rozhodování a lepšímu řízení rizik, jelikož vhodně řízené riziko přináší předvídatelné výsledky.

Metoda Kanban Metoda Kanban je souborem definic a principů, klíčových zásad a principů. Kanban je postaven na následujících 5 ti principech [47]: vizualizace workflow – reprezentuje pracovní položky na Kanban boardu (tabuli), optimalizace probíhající práce (WIP) – nastavení limitů, kolik pracovních položek může běžet na ráz (být na tabuli), měření a správa průběhu – sledování pracovních položek, zda probíhají stabilně a dodržují stanovené tempo, vytvoření explicitních procesních pravidel – odsouhlasení pravidel jak bude nakládáno s prací, využití modelů ke zhodnocení možnosti zlepšení – přizpůsobení procesů s využitím systémového myšlení.

13

WIP – z anglické zkratky work-in-progress)

32

V těchto principech je možné vidět souvislost s metodikou Lean Development (viz kapitola Lean Development). Zejména pak v jejích základních principech: „Respektování lidí, odstranění zbytečností, odložení závazku, poskytnutí rychlého řešení, posilovat kvalitu a celek.“ Na vývoj se pak dle jednoduchého přirovnání díváme jako na potrubí, cokoliv v něm zpomaluje průtok je odpad, v tomto případě jsou zde myšleny zbytečné produkty nesouvisející s finálním produktem, tedy vznik zbytečných kusů kódu a dokumentací, které nás stojí čas.

Vizualizace pracovního postupu Principem metody Kanban je vzít pracovní proces a pomocí jednoduchých pomůcek ho udělat přehledný, lépe srozumitelný a dává nám možnost vidět skryté souvislosti a důležité detaily. Společnosti pak umožní jednotný pohled a možnost komunikovat o jednotlivých částech a problémech během procesu.

Obrázek 7 - Kanban vizualizace pracovního postupu [Zdroj: vlastní]

Mapování sítě hodnot Vytvoření sítě hodnot je složitý proces průzkumu získaných informací a tvořivosti, jež tvoří počáteční požadavek na dodávku software. Vizualizace je velice náročná a rozkládá se do posloupnosti jednotlivých kroků vývoje, některé pracovní položky je nutné analyzovat samostatně a detailněji rozložit. Z těchto hodnot je pak sestavena Kanban tabule s kartičkami. Díky zmíněné náročnosti sestavení této sítě je metoda Kanban velice často používána ve spojení s jinou Agilní metodikou, zaměřenou přímo na vývoj, tabule pak může prezentovat jednu samostatnou iteraci např. s využitím metodiky SCRUM, kdy vznikla i samostatná metodika SCRUM-ban.

33

Kanban board (tabule) Úkolem vytvoření tabule je již zmíněná vizualizace aktivit probíhající práce, spíše než popisu konkrétních funkcí nebo popisu pracovních míst. Na tabuli jsou nakresleny sloupce, představující pořadí prováděných činností, každý sloupec reprezentuje určitou část pracovního průběhu nazývané fronty a jeho šířka reprezentuje čas potřebný k vykonání. Při kombinaci např. se SCRUM budou sloupce tvořit buď jednotlivé Sprinty či bude tabule tvořit jeden Sprint. Což nám oproti klasickému SCRUMU, kdy se čeká na release nebo funkční kousek kódu za jednotlivou iterací umožňuje předat již pod-části této části. Vždy je však důležité tvořit tabuli tak, aby byla skutečným obrazem běžícího vývojového procesu, který se dá v průběhu zlepšovat. Na tabuli jsou pak lepeny kartičky, které reprezentují konkrétní úkol nebo klíčovou vlastnost. Karta musí obsahovat minimálně název, referenční číslo a datum, kdy vstoupila do systému.

Optimalizace probíhající práce (Work-In-Progress) Úkolem WIP je podněcovat konverzaci vedoucí ke zlepšení. Je nutné omezit práci, tak aby byl stanoven rozumný limit, kolik položek bude provedeno v každém pracovním kroku. Pokud položky postupují tak jak mají, otevře se nový slot s pracovní položkou, která se zařadí do pracovního toku. Klíčovým je dokázat udržet pracovní tok stále proudit, pokud dojde k zablokování je snahou celého týmu odblokovat problematickou položku. Parametry WIP by měli být následující: •

velikost WIP limitu - měla by být stanovena jako počet pracovních položek na osobu a vynásobit počtem členů v týmu,

•

dohodnuté limity – měli by být výsledkem jednání vývojového týmu a dalších zúčastněných stran,

•

limity fronty - tedy příjmu dalších položek by měli být stanoveny, tak aby byli schopny eliminovat rozdíly mezi příjmem a dobou vyjednávání mezi nimi,

•

manipulace s překážkami – většinou bývá na kraji tabule vytvořen samostatný sloupec, sloužící jako buffer pro problematické položky, ten by neměl být dost široký, aby časově zabíral malou hodnotu, ale měl by dokázat dodat čas navíc potřebný k vyřešení,

34

•

spolupráce (roj) – je myšleno spolupráce pracovníků na problematických položkách, vytvořením tzv. roje, spolupracuje několik pracovníků na problematické položce, čímž dochází ke zrychlení řešení.

Obrázek 8 - Znázornění nastavení WIP limitů [Zdroj: vlastní]

Měření a správa toku Měřením průběhu pracovního toku lze zjistit optimální tempo potřebné k dokončení práce. Pracovní tok by měl být stabilní, pokud často dochází k problémům a zpožděním, většinou je to následek špatně nastavených limitů. Cílem je stanovit takové limity, aby nedocházelo k častým vznikům překážek např. vlivem nedostatku času, pracovník se pak dostane do skluzu a nedokáže plnit úkoly.

Dohodnuté politiky Dohodnutí politik jako např. WIP limitů, schvalování, stanovení priorit vede k většímu porozumění, souladu týmu a méně sporným situacím. Porozuměním je pak možno vytvořit zdravější tým lépe spolupracující na pracovišti.

Použití modelů ke zlepšení Kanban vychází z návrhů Dr. W.E.Edwardse, které říkají, abychom zkoumali systém a své schopnosti. Metoda zahrnuje myšlenku o shromažďování dat výkonosti, tedy době pracovního toku, WIP, atd., které nám poskytují náhled na to co vylepšit a příležitosti k vylepšení. Tyto údaje pak vychází z každodenních check-in setkání Kanban týmu a vedou ke změnám a zdokonalování procesů.

35

Stanovení priorit Priority by měli být stanoveny na základě vlastností jednotlivých položek, které z nich jsou klíčové, které jsou nutné k tomu, abychom mohli pokračovat ve vývoji ostatních, jaká je jejich hodnota v celkovém kontextu, ale také jejich vliv na vznik překážek. Následující metody napomáhají k určení priorit: •

vstupní fronty a doplňovací setkání – na rozdíl od čistě agilních metodik, kde bývá doba iterace pevně stanovena, je u Kanban doba závislá na pracovním toku, během těchto setkání bývají průběžně hodnoceny řešení položek a je možné pružně upravovat priority,

•

kapacitní přidělení dle pracovní položky – každý pracovní proces může mít jiné požadavky, jiný typ řešení, pružným přidělováním pracovníků lze reagovat na vznikající priority,

•

stanovení priorit podle úrovně služby – jednotlivé položky mají prioritu dle naléhavosti řešení, nejvíce kritické položky jsou upřednostňovány a jejich řešení se určuje především dle obchodního dopadu. Položky jsou pak na kartičkách znázorněny buď s pevným datem řešení nebo prioritou či pořadím, tyto kartičky bývají na tabuli i barevně odlišeny, v některých případech bývají tabule rozděleny do vodorovných částí dle priorit,

•

předvídatelnost na základě SLA14 smlouvy – na základě SLA bývá určeno, kdy má být dodána klíčová vlastnost, často bývá i ošetřeno, za jakých podmínek má být vlastnost dodána a z toho vyplývající postihy, priorita se pak řídí položkami SLA smlouvy.

Obrázek 9 - Kanban – určování priorit [Zdroj: vlastní]

14

SLA – Service Level Agreement – smlouva o úrovni poskytovaných služeb

36

Výhody a nevýhody Kanban není zaměřen na vývoj software, nýbrž jeho workflow. Výhodou je vizualizace požadavků a jejich průběh při zpracování. Ve spojení s dalšími agilními metodikami pak dostáváme do ruky nástroj usnadňující práci. Jeho nespornou výhodou je efektivní využití zdrojů a především díky svému původu v automobilovém průmyslu i načasování konkrétních procesů. Nevýhodou pak je úzké zaměření na workflow, metodika tak neřeší celý projekt, jako spíše efektivitu již probíhajících úkonů. Kanban je ve většině případů závislý na dalších metodikách, kde se pak stává doplňujícím nástrojem.

1.3 Porovnání agilních a rigorózních metodik Každá strana mince má bezesporu svoji hodnotu, stejně jako agilní i klasické rigorózní metodiky mají své klady a zápory. Nejvíc však záleží na povaze projektu a především prostředí, kde projekt probíhá. Klasicky lineární a sekvenční přístup k softwaru pro navrhování a vývoj systémů, který bývá nazýván rigorózní či vodopádový pro jeho postupné řešení v povaze k projektu. Každý pomyslný stupeň vodopádu mívá přiřazen samostatný tým s cílem zajistit danou část projektu v stanoveném termínu, což je důležité pro on-time dodávky projektu. Lineární přístup znamená krok za krokem v budování produktu. Problém nastává v situaci, kdy dochází k požadavku na výraznější změnu funkčnosti software, kdy se dostáváme prakticky na začátek a tyto úpravy zpravidla řeší další nový projekt. Tento nedostatek řeší právě zmiňované agilní metodiky, kladoucí důraz na hodnoty a zásady před procesy. Práce v cyklech, tedy například týden, měsíc, atd. Priority projektu jsou přehodnocovány na konci každého cyklu.

Obrázek 10 - Železný trojúhelník - Srovnání agilních a rigorózních metodik [51]

37

Má-li se jednoduše shrnout rozdíl obou metodik, pak rigorózní metodiky jsou o předvídatelnosti, zatímco agilní čerpají z přizpůsobivosti. Agilní metodiky jsou perfektní pro snížení nákladů, zejména pak v oblastech dokumentace a samotných jednání, kdy se snaží náklady udržet tak nízké, jak je to jen možné. Díky tomuto bývají agilní metodiky využívány zejména malými týmy s neustále se měnícími požadavky na projekty, spíše než u větších projektů. Na základě spíše empirické než definované metodiky (rigorózní) jde o lehkost použití a dostatečné usnadnění budoucího vývoje. Nicméně i agilní metodiky zahrnují plánování, především pak stanovení a přizpůsobení plánů tak abychom dosáhli požadovaných výsledků. Agilní metodiky se snaží rozložit projekt na malé kousky velikosti puzzle a pak je postupně spojovat dohromady ve správný čas. Zatímco co tedy existují důvody pro podporu jak rigorózních, tak i agilních metodik, jednoduché zamyšlení vysvětluje, proč mnoho softwarových firem volí agilní metodiky. Agilní metodiky usnadňují vývoj a snižují náklady. Mnoho menších firem volí jistotu a snaží se klientovi vyjít vstříc, agilní metodiky jsou pak menším rizikem, jelikož zákazník sám spolupracuje při vývoji, výsledný produkt je pak plně odrazem toho co zákazník chtěl.

agilní

rigorózní

Tabulka 2 - Srovnání rigorózních a agilních metodik [51]

Výhody

Nevýhody

Zákazník ví co očekávat rozsahem, časem a cenou

Jakmile je dokončen release, nelze se jednoduše vrátit k předchozí fázi Počáteční požadavky nelze měnit, aniž by to nemělo dopad na projekt Testování až na konci je riskantní z důvodu hledání chyb v celém kódu Vyvíjející se požadavky zákazníka nejsou brány v potaz Zákazník má možnost vidět až finální produkt

Minimální dopad v případě fluktuace zaměstnanců zhotovitele Zákazník a management dopředu dohodují, co bude dodáno Průběh je lépe měřitelný, jelikož je dopředu znám rozsah Členové týmu mohou pracovat na více projektech současně Přítomnost zákazníka není po fází požadavků nutná Navrhuje globálně celý systém, návrh je definován již na počátku Hotová část je dodána po každém sprintu Novou funkcionalitu je snazší přidat díky kratším iteracím Priority projektu jsou nastaveny před každým sprintem a vyhodnocovány po každém sprintu Zpětná vazba od zákazníka během průběhu projektu přispívá ke konečnému výsledku Testování každý sprint, nedochází k nečekaným překvapením Vysoká úroveň spolupráce se zákazníkem Krátká doba pro uvedení finálního produktu Vysoká transparentnost

Díky absenci přesného plánu mohou vznikat odchylky Zákazník musí mít čas na zapojení do projektu, jinak nebude odpovídat jejich požadavkům V průběhu mohou být přidávány další sprinty v důsledku požadavků, to prodražuje projekt Iterativní povaha může snižovat kvalitu produktu, protože neklade důraz na cílovou podobu systému

38

Kdy by měla být použita rigorózní metodika: •

pokud nebude mít zákazník možnost měnit rozsah projektu, jakmile započne,

•

pokud je jasná představa o tom, jak by měl vypadat konečný produkt, plán musí být zpracován v předstihu,

•

pokud je přesná definice a kvalita klíčem k úspěchu namísto rychlého dodání.

Kdy by měla být použita agilní metodika: •

pokud je třeba průběžně měnit rozsah projektu,

•

pokud není jasná představa o podobě finálního produktu,

•

pokud je důležitá rychlá výroba před kvalitou produktu,

•

pokud je produkt určen do prostředí s rychle měnícími se standardy (např. vývoj software),

•

pokud jsou k dispozici kvalifikovaní vývojáři, schopni samostatného myšlení.

2 SOFTWAROVÉ NÁSTROJE PRO PODPORU PM Stejně jako jiné obory, tak i projektový management může využívat různé softwarové nástroje, které nám usnadňují práci při realizaci projektu a pomáhají řídit důležité proměnné. Běžný projekt obsahuje velké množství úkolů, členěných do milníků. Úkoly mezi sebou často mají vazby, které je nutné kontrolovat a řídit. Samotné části projektu jsou vázány na určité časové termíny, na úkolech se podílí několik zaměstnanců a je začleněno několik zdrojů. K tomu abychom všechny tyto problematické části mohli lépe kontrolovat, lze využít různé softwarové nástroje, které nám dají možnost shromáždit lépe požadavky, úkoly, přidělené zdroje a spouštět jednotlivé kontrolní mechanismy. Vše dohromady nám poskytuje snadnější kontrolu změn, lepší načasování, kontrolu plnění úkolů a do jisté míry i lepší predikci. Mezi jednu z největších výhod moderních nástrojů patří možnost spolupráce projektového týmu v reálném čase. Nástroje lze rozdělit dle jejich zaměření: nástroje pro podporu řízení – nástroje, které nám pomáhají kontrolovat průběh projektu, sledovat důležité milníky, alokovat zdroje projektu, sledovat kritickou cestu projektu, řídit čerpání zdrojů a kontrolovat celkový stav rozpracovanosti v několika rovinách, nástroje pro komunikaci – nástroje usnadňující komunikaci týmu na projektu, jednoduché využití emailů, komentářů uživatelů v podnikových aplikacích či systémy zasílání zpráv, a v neposlední řadě videokonference, 39

podpůrné nástroje – veškeré vedlejší nástroje, jimiž jsou analytické části aplikace, poskytující vedlejší obsah pro oba výše zmíněné nástroje (generátory diagramů, grafů či generátory sestav s výstupy projektu). Samotné nástroje projektového řízení pak v drtivé míře řeší celé workflow projektu, tyto nástroje jsou často integrovány do podnikových ERP15 systémů či skupinových nástrojů nazývaných Groupware či Collaboration nástroje. V případě části aplikace, která řeší projektové řízení, se pak jedná o následující funkcionalitu: cíle projektu – identifikace fází projektu, členění částí projektu na jednotlivé milníky a úkoly, specifikace klientských požadavků, definice workflow, řízení a alokace zdrojů – v návaznosti na předchozí bod pak detailní přidělování časových a lidských zdrojů jednotlivým úkolům, výpočty času a odchylek, lhůty, pořadí a priority řešení úkolů, závislosti a omezení – závislosti mezi jednotlivými úkoly, často důležité návaznosti, kdy jeden úkol může být řešen až po skončení předchozího, nastavení pořadí a priorit, komunikace na projektu – komunikace v reálném čase prostřednictvím rychlých zpráv, možnosti vkládání komentářů, či přímá interakce s jinými moduly aplikace např. videokonference, dokumentace a znalostní báze – udržování projektové dokumentace, tedy možnost přímo nahlédnout do příloh u jednotlivých úkolů či milníků, udržování báze znalostí a důležitých postupů, analytické části – výstupy diagramů, tisk sestav a vytváření výstupů, nástroje pro výstupy a analýzu časových zdrojů. Pro účely této práce nás zajímá rozdělení softwarových nástrojů dle místa instalace a způsobu přístupu k nim. Aplikace mohou být instalovány dvěma způsoby: •

on-premise - nástroje v rámci jedné budovy či datacentra,

•

on-demand - nástroje, které jsou poskytovány jako služba, či jsou umístěny v rámci cloud prostředí.

2.1 On-premise nástroje pro podporu projektového řízení 15

ERP – Enterprise Release Planning – informační systém integrující a automatizující množství podnikových procesů v závislosti na povaze společnosti, typicky řízení projetků, CRM, využívání zdrojů podniku, majetek a účetnictví, logistiku, výrobu atd.

40

Jak bylo zmíněno v předchozí kapitole, on-premise nástroji se rozumí nástroje, které jsou instalovány a provozovány v rámci budovy či uložené v datacentru na vlastní infrastruktuře, tedy na vlastním hardware za použití vlastních síťových prvků. On-premise model využívá výpočetních zdrojů v rámci organizace a vyžaduje vlastní licencované nebo zakoupené kopie softwaru dodavatele. Organizace je sama zodpovědná za bezpečnost řešení a plynulý provoz použitých technologií. Zároveň je potřeba brát v úvahu náklady na vlastní lidské zdroje, delší dobu integrace, zajištění zálohy kritických dat a spotřebované energie. Výhodou je však plnohodnotný software v organizaci, odpadají nízké odezvy při použití aplikace, která by byla umístěna mimo vlastní infrastrukturu. Z výše zmíněného vyplývá, že on-premise řešení vyjde podstatně dráž oproti modelu on-demand: •

nároky na vlastní hardware (servery, stanice …),

•

zakoupené licence na použitý software a operační systémy,

•

vlastní síťová infrastruktura (aktivní prvky, kabeláž…),

•

spotřebované energie,

•

lidské zdroje (personál).

On-premise nástroje lze pak jemněji dělit dle umístění infrastruktury: •

on-site – v rámci budovy organizace,

•

off-site – hostované v datacentru.

2.2 On-demand nástroje pro podporu projektového řízení Oproti on-premise jsou výhody on-demand či cloud řešení především v nákladech na provoz. Menší organizace si nemohou dovolit vlastní IT z důvodů vysokých pořizovacích a provozních nákladů. On-demand poskytuje řešení pro organizace, které chtějí okamžitě začít používat aplikaci, bez vlastních investic do IT infrastruktury. Aplikace je poskytována jako služba (Application Service Providing16), uživatelé či celé skupiny uživatelů používají aplikaci spouštěnou ze vzdáleného serveru prostřednictvím internetu. Jedná se tedy o odraz potřeby snižování nákladů na software a okamžitého používání. Software je poskytován Application Service Providerem17 a uživatel či organizace pravidelně platí smluvené poplatky. Výše těchto poplatků je pak přímo závislá na úrovni poskytovaných služeb, mohou tedy být doplněny o rozšířenou podporu, či zvýšenou garanci dostupnosti služby. Přístup k software pak probíhá v reálném čase. Správa a údržba software je plně v zodpovědnosti poskytovatele. 16 17

Application Service Providing – Poskytování aplikačních služeb Application Service Provider – Poskytovatel aplikačních služeb

41

Úroveň poskytovaných služeb je stanovena v SLA18 smlouvě, z které pak vychází zodpovědnost smluvních stran, smluvené metriky a pokuty v případě porušení. Tato smlouva zároveň slouží poskytovateli jako ochrana před neadekvátními dotazy či neoprávněnými nároky ze strany uživatele.

2.3 Porovnání On-premise a On-demand Porovnání obou výše zmíněných variant je v drtivé míře závislé na několika známých faktorech.

Strategie: Proč uvažovat o on-demand (cloud) řešení? Náklady - Před zvolením jednoho nebo druhého řešení si je třeba uvědomit, jak velké jsou počáteční náklady na licence, vlastní infrastruktur a personál při on-premise řešení. Zde vítězí jednoznačně on-demand, jak je tomu však v delším časovém horizontu? Možnost rozšíření - Cloud nabízí vysokou škálovatelnost s minimem finančních nákladů. Onpremise by vyžadovalo vysoké investice do nové infrastruktury a licencí, nemluvě o nutnosti disponovat požadovanými znalostmi u vlastních zaměstnanců. Inovace - Cloud většinou nabízí nové inovativní způsoby práce. Je si však třeba uvědomit povahu společnosti a její potřeby, naopak on-premise se dá často chápat jako svazující řešení, které nás uvězňuje u starých zajetých postupů a vzorů.

Finance: Kde lze nalézt ROI? Přesun z investic do nákladů - Cloud computing s sebou přináší jiný model financování, kdy namísto investic do IT oddělení a technologií platíme za poskytnuté služby a jedná se tedy o náklady. Roční investice pak mohou být přehodnoceny a použity k jiným účelům. Je třeba si však dát pozor na výši spotřebovaných služeb, tak abychom se nedostlali mimo vymezený rámec. Investice do infrastruktury - Jestliže využíváme on-premise řešení, pak je nutné počítat s investicemi do vylepšování infrastruktury, tedy aktualizací operačních systémů a aplikací, vylepšování hardware atp. To s sebou nese většinou další náklady skryté v licencích. U ondemand řešení většinou postačí obyčejný webový prohlížeč a vystačíme si s minimálními nároky na hardware, nehledě na to, že poskytované aplikace by měly být vždy aktuální a hardware dostatečně optimalizovaný.

18

Service Level Agreement – Smlouva o poskytování služeb

42

Šetrné „Green“ řešení - Cloud computing je oproti on-premise řešení považován za šetrnější k přírodě. Hlavním kritériem je míra spotřebované energie, kde u on-premise řešení musíme počítat s vyšší spotřebou serverů, klimatizací a počítačů IT personálu. Náklady na implementaci - On-demand řešení je možné okamžitě začít používat, náklady jsou tedy minimální. Cenový model - U on-premise je potřeba brát v úvahu nutnost zaplacení celé infrastruktury naráz, u on-demand platíme pouze měsíční nájem za aplikaci a počet uživatelů.

Provoz: Vliv na zvýšení efektivity. Pružnější práce - Oba druhy by měly vést ke zvýšení efektivity práce. Ke cloudu je možné přistupovat odkudkoliv na světě pouze za pomoci prohlížeče, zaměstnanci nejsou fixováni na kancelář či použití VPN sítí. Outsourcing vedlejších činností - Díky povaze cloudu je možné nechat data zpracovávat cizí organizací a některé pracovní úkony outsourcovat. U on-premise je nutné zajistit dostatečně bezpečný přístup k serverům společnosti a provést podstatně více úkonů vedoucích k zpřístupnění dat. Geografická expanze - Díky cloudu je možno k aplikaci přistupovat odkudkoliv a nabízí se tedy možnost vytvoření poboček v jiných geografických lokalitách, což by u on-premise vyžadovalo značné investice do vybudování potřebné infrastruktury.

Technické požadavky: Co potřebujeme ke správné funkcionalitě? Modernizace technologií - V kontrastu s on-premise je výše nákladů mizivá, je však nutno brát v potaz investice do zabezpečení stávajících prohlížečů, zvýšený datový tok do internetu a celkově vyšší provoz na síti. SSO (Single Sign On) - S on-demand řešeními přichází často i nutnost použití Single Sign On, tedy jednotného přihlášení do více systémů pod jedním uživatelským jménem a heslem. To s sebou nese vyšší nároky na složitost hesel a často i zavedení sekundárního ověřování. Spousta starších uživatelů toto vidí jako obrovskou překážku. Online a Offline režim - S internetovým připojením se setkáváme na každém rohu, jsou však místa, kde internet nenajdeme. Absence připojení je u on-demand řešení fatální problém, zaměstnanec pak nemůže prakticky vůbec pracovat.

43

Podpora zařízení - S masivním nástupem tabletů a chytrých telefonů je stále vyšší tlak na možnost použití BYOD19 zařízení pro firemní účely. S tím jdou ruku v ruce vyšší požadavky na podporu stále širšího spektra prohlížečů.

Poskytovatel: Je nabídka skutečně dostatečná? Životaschopnost - On-demand je prakticky outsourcing části našeho IT. Je tedy nutné brát v potaz životaschopnost dodavatele, jeho zajištění před krachem, postavení na trhu a především kdo je vlastníkem. Možnost přizpůsobení aplikace - Bezespornou výhodou on-premise je možnost provedení námi požadovaných úprav. Bude nám tato možnost nabídnuta i u on-demand řešení? Aktualizace - Vyřazení části aplikace nebo nečekaná změna způsobená aktualizací aplikace je obrovský problém. Je tedy nutné brát v potaz, jak je zajištěno testování těchto změn na straně poskytovatele, tak aby neovlivnili náš provoz. Bezpečnost - Servery umístěné v internetu vyžadují vyšší nároky na bezpečnost, přeci jen onpremise řešení je většinou izolované uvnitř sítě a přístup k němu je možný pouze při splnění určitých bezpečnostních podmínek. Zálohování a obnova dat - Před výběrem řešení je nutné brát v potaz, jaký je scénář zálohování a obnovy dat. Ztráta dat způsobená výpadkem serveru nebo technickými problémy je noční můrou každé společnosti. Podpora a SLA - On-demand řešení spolu nese i nutnost smluvně zajistit požadovanou úroveň služeb. Nastavit pravidla a metriky potřebné pro plynulý chod nenarušující naše obchodní zájmy. Díky tomuto opatření je poskytovatel nucen dodržovat určitou kvalitu poskytovaných služeb a my naopak získáváme jistotu, že jsme svěřili náš provoz do správných rukou. Výše zmíněná fakta jsou hlavními kritérii, která bychom měli zvážit před výběrem jednoho či druhého řešení, tak aby výsledné řešení splnilo naše očekávání a naplnilo požadované cíle.

2.4 Výběr aplikace - Gartner Magic Quadrant a MarketScope Každý zákazník většinou stojí před rozhodnutím, kterou aplikaci vybrat? Ať už jsem rozhodnut pro on-premise či on-demand řešení, jak zjistím, že aplikace splní má očekávání? 19

BYOD (Bring Your Own Device) – nošení vlastního zařízení (notebook, smartphone, tablet …) do organizace

44

V prvním kroku si musíme stanovit, co od aplikace čekáme a jakou cenovou hladinu můžeme zvolit. Často se však stane, že nabídka bude širší a vy budete stát před otázkou, která aplikace je vlastně ta nejvhodnější. V tomto případě je vhodné vyslechnout názory druhých či lépe zkusit najít vyjádření experta pro danou oblast. Nejpovolanějšími bývají známé analytické společnosti, které pravidelně provádějí vyhodnocení daného sektoru s různými faktory hodnocení. Mezi nejznámější z těchto společností patří Gartner, Panorama Consulting Group a Forrester. Společnost Gartner vydává každoročně report analýzy daného sektoru, který se nazývá Gartner Magic Quadrant. Cílem Gartner Magic Quadrant je hodnotit v našem případě software dle dvou hlavních kritérií: •

úplnost vize,

•

schopnost úspěšného uvedení na trh. Samotná metoda hodnocení je prakticky grafické znázornění pomocí 4 kvadrantů,

přičemž každý určuje postavení dané aplikace na trhu [31].

Obrázek 11 - Gartner Magic Quadrant [31]

Leaders (lídři trhu) – Společnosti, které mají vše potřebné k realizaci a zároveň se nebojí inovace. Díky silnému postavení na trhu mají potřebné prostředky k hledání nových výzev a jejich realizaci. Challengers (vyzyvatelé) – Společnosti, které již působí na trhu a dokáží realizovat své nápady. Díky delší působnosti na trhu disponují potřebnými technologiemi a kapacitami, často se však nepouští do velkých inovací z důvodu jisté pozice na trhu.

45

Visionaries (vizionáři) – Společnosti, které mají vizi a odhodlání se prosadit. Tyto společnosti často nedisponují potřebnými prostředky, ale zároveň nemají co ztratit, což je pohání a motivuje jít vpřed. Niche players (úzce specializovaní hráči) – Do tohoto sektoru spadají menší společnosti, které prorazili často s úzce specializovanou aplikací, která vyplnila mezeru v daném sektoru. Pro účely naší práce uvádím příklad on-demand poskytovatelů nástrojů projektového a portfolio managementu.

Obrázek 12 - Gartner Magic Quadrant for Cloud-Based Project and Protfolio Management Services [44]

Gartner MarketScope Úkolem Gartner MarketScope je hodnotit jednotlivé výrobce na základě důležitých kritérií, která určují vyspělost daného softwaru. V rozvíjejícím trhu jsou výrobci a některé výrobky méně známy a tudíž i méně testovány koncovou komunitou uživatelů, kteří by mohli předat objektivní hodnocení, potřebné pro Gartner Magic Quadrant. MarketScope tedy řeší analýzu dynamicky rozšiřujícího se trhu a pomáhá rozpoznat méně známé výrobce. MarketScope pokrývá hodnocení daného segmentu trhu. 46

Obrázek 13 - Gartner MarketScope [33]

Principem hodnocení je tedy omezeno na základní vybrané sady kritérií, která jsou stanovena v oblasti výzkumu společnosti Gartner. Daný výrobce je pak hodnocen dle následujících kritérií [33]: Strong Positive (vysoce pozitivní) Výrobce je vnímán jako dodavatel strategický produktů či služeb. Doporučení pro stávající zákazníky: Pokračovat s plánovanými investicemi. Doporučení pro potenciální zákazníky: Vzít v úvahu tohoto výrobce, jelikož se jedná o skvělou volbu pro strategické investice. Positive (pozitivní) Demonstruje sílu ve specifických oblastech, ostatní oblasti však moho mohou u být stále vyvíjeny nebo v rozporu s jinými oblastmi. Doporučení pro stávající zákazníky: Pokračovat s plánovanými investicemi. Doporučení pro potenciální zákazníky: Vzít v úvahu tohoto výrobce, avšak s možnými známými omezeními. Promising (nadějný) Ukazuje na potenciál v určitých oblastech, ale výkonost zatím není konzistentní. Ukazuje Doporučení pro stávající zákazníky: Zvážit krátkodobé a dlouhodobé dopady případných změn stavu. Doporučení pro potenciální zákazníky: Stojí za uvážení, avšak je nutné brát v potaz zralost tohoto výrobce a příležitosti týkající se vývoje. Caution (pozor) Výrobce se potýká s problémy v jedné nebo více oblastech.

47

Doporučení pro stávající zákazníky: Pochopit problémy v daných oblastech, nutno vytvořit pohotovostní plány, založené na toleranci rizik a možného obchodního dopadu. Doporučení pro potenciální zákazníky: Brát v potaz vzniklé náklady na úpravy a péči o software. Strong negative (vysoce negativní) Má problémy vyrovnat se s vzniklými problémy v mnoha oblastech. Doporučení pro stávající zákazníky: Mít připravené migrační plány pro případ vzniku rizik. Doporučení pro potenciální zákazníky: Hodí se pouze jako krátkodobá investice s rychlou návratností.

Obrázek 14 - Gartner MarketScope pro PPM 2013 [45]

MarketScope lze využít pro definici trhu, ilustruje důležité trendy a dynamiku, které mají společně vliv na sílu daného segmentu trhu. Je důležité mít na paměti, že MarketScope je pouze výčet zástupců nejvýznamnějších hráčů na trhu, jestliže se daný produkt nenachází v seznamu, neznamená to, že by nebyl životaschopný nebo nedokázal konkurovat ostatním. Oba Gartnerovy frameworky lze využít při rozhodování do jakého výrobce či přímo aplikace chceme investovat. Slouží k přehlednému znázornění stavu daného segmentu trhu, což dává analytikům do rukou silná vodítka při rozhodování.

48

V mém případě jsem dle obou těchto frameworků vybral softwarový nástroj pro ukázku a následně pak i pro poslední kapitolu, kde si ukážeme porovnání nákladů on-premise a cloud řešení. Výběr jsem provedl na základě potřeb této práce, aby tedy bylo možné software provozovat jak v on-premise, tak i cloud prostředí. Dále pak také dle referencí, kdy se aplikace umístila na předních pozicích v několika žebříčcích hodnotících nástroje projektového a portfolio managementu.

2.6 Genius Project Genius Project patří mezi aplikace pro řízení podnikových zdrojů, jehož hlavní předností je přizpůsobitelnost podnikovým procesům. Genius Project pokrývá oblast portfolio a projektového managementu s důrazem na flexibilnost a možnost konfigurace dle požadavků projektových týmů. Stejně jako Microsoft Project nabízí možnost použití on-premise, tedy na infrastruktuře zákazníka, tak i on-demand řešení, které je pak spustitelné ve webovém prohlížeči, nabízející totožné funkce jako on-premise řešení. Výhodou je pak možnost přistupovat do firemního cloudu pomocí jakéhokoliv kompatibilního webového prohlížeče, odkudkoliv z planety. Výhodou on-demand řešení je díky nárokům pouze na webový prohlížeč, možnost využití mobilních zařízení jako jsou tablety, chytré telefony a tencí klienti. Genius Project zároveň nabízí možnost integrace do podnikových informačních systémů, kdy je plně kompatibilní s Lotus Notes Domino od společnosti IBM.

Obrázek 15 - Genius Project poskytuje možnost spolupráce s produkty třetích stran [22]

Aplikace je rozdělena do čtyř hlavních skupin [22].

49

Řízení a plánování Řízení nákladů a rozpočtu - Sledování plánovaných a skutečných hodnot rozpočtu, napomáhající ke stanovení úspěšnosti projektu a výkonosti. Aplikace dokáže automaticky přepočítávat mezi jednotlivými měnami, sledovat tok nákladů napříč projekty, hlídat časové a finanční zdroje. Plánování projektu a vytvoření Ganttova diagramu - Tvorba časových harmonogramů, přidělování kapacit na projekty a rozdělování projektů na jednotlivé úkoly. Spravování projektových týmů a alokace zdrojů. Pohodlná tvorba diagramů, možnost tvorby Ganttova diagramu napříč projekty. Řízení zdrojů - Díky kvalitnímu řízení zdrojů lze optimalizovat využití kapacit a minimalizovat potřebný čas, čímž lze efektivně zvýšit návratnost investic. Aplikace umožňuje sledovat kapacity, vytíženost jednotlivých zaměstnanců a alokovat je na potřebné úkoly projektu. Zároveň poskytuje přehledný report o vytíženosti. Simulace - Simulace umožňuje projektovému týmu tvořit možné scénáře a modelovat projekty. Díky této možnosti lze vyhodnocovat jednotlivé varianty a tím získat nejlepší možné řešení.

Obrázek 16 - Genius Project - Řízení a plánování [22]

Týmové nástroje Správa dokumentů - Každý projekt obsahuje mnoho dokumentů, od materiálů od zákazníků, diagramy či zápisy z projektových porad. Aby zainteresovaní pracovníci měli možnost kdykoliv nahlédnout do patřičného diagramu či dokumentace, je systém vybaven 50

sofistikovaným systémem pro ukládání souborů. Tento modul umožňuje správu přístupových práv pro dané dokumenty, vytváření šablon, či vytvoření workflow samotného dokumentu. Sociální nástroje pro spolupráci - Aplikace umožňuje vytvoření vlastní sociální platformy, pracovníci tak mají možnost diskutovat či komentovat jednotlivé etapy či části projektu napříč celou aplikací v reálném čase. Díky tomu odpadá nutnost svolávání častých porad či každou otázku řešit separátně s daným pracovníkem.

Obrázek 17 - Genius Project - Týmové nástroje [22]

Podpora byznys procesů Podpora agilních metodik - Aplikace poskytuje řadu specifických nástrojů podporujících agilní metodiky, především pak SCRUM. Je tedy možné adaptovat definované procesy tak, aby odpovídali postupům definovaným např. ve SCRUM či jiné agilní metodice. Správa požadavků - Organizace často čelí problémům jak se vypořádat s větším počtem projektů a neustále se zvyšujícím objemem požadavků, u kterých je především nutné sledovat prioritu a řešit problematické případy dříve než dojde k problémům. Požadavky navíc musíme dokázat správně rozdělit, tak abychom zvlášť přistupovali k žádostem o změnu, novým požadavkům či opravám chyb. Genius Project umožňuje shromažďovat a organizovat požadavky, definovat priority a důležitá kritéria pro efektivní rozhodování. Konektory pro aplikace třetích stran - Genius Project je schopen provádět obousměrnou spolupráci s aplikacemi třetích stran jako jsou Lotus Notes, SAP, IBM (AS/400), Google Apps a Microsoft nástroje. Pomocí aplikace je tedy možné řídit procesy aplikací třetích stran a veškerá workflow řídit pomocí jedné aplikace. 51

Nástroje podpory - Snad každá společnost vyvíjející software či poskytující IT služby umožňuje svým zákazníkům či oddělením přistupovat k systému hlášení chyb a požadavků, tak aby dokázala reagovat a provést nápravu. Aplikace nabízí plnohodnotné nástroje pro řízení workflow hlášených událostí, definovat procesy a postupy pro různé kategorie hlášení odvíjející se od typu zákazníka či daného projektu. Řízení fází vývoje nových produktů - Genius Project umožňuje rozklíčovat vývoj produktu do jednotlivých fází a integrovat akceptační kritéria pro jednotlivé nápady či požadovaná vylepšení. Vývoj produktu pak podléhá definovaným procesům, které je třeba dodržet, tak aby se dostal požadovaný přírůstek či část projektu do produkční fáze. Fakturační systém - Aplikace má integrovaný vlastní fakturační systém, umožňující pohodlné vytváření faktur ve formátu aplikací Microsoft Word či Adobe PDF. Tato funkcionalita umožňuje např. automatické generování měsíčních dokladů o vyúčtování služeb jednotlivým zákazníkům. Řízení změn a rizik - Provádění změn je součástí každého projektu, je důležité dokázat tyto změny správně řídit, tak aby byla minimalizována možná rizika. Aplikace umožňuje vytvářet migrační plány, analyzovat rizika za pomoci analýzy dopadu a pravděpodobnosti výskytu. Projektový tým pak může vyhodnocovat prognózy a skutečné dopady.

Obrázek 18 - Genius Project - Podpora byznys procesů [22]

52

Dokonalý přehled Nástěnka a reportovací nástroje - Aplikace poskytuje výkonné nástroje pro analýzu různých částí projektu, či přímo částí aplikace samotné. Lze tedy jednoduše sledovat průběh jednotlivých částí projektu, ale i výkonost jednotlivých členů projektového týmu, finančních toků, vyhodnocovat průběh, délku jednotlivých hlášení systému podpory a mnoho dalších analytických pohledů napříč aplikací. Řízení potfolia projektu - Aplikace umožňuje získat ucelený pohled na probíhající projekty. Díky tomuto umožňuje strategicky řídit a určovat prioritu jednotlivých projektů, hledat skryté potenciály a definovat skóre, které lze porovnávat na úrovni portfolia. Díky správné strategii lze efektivně zvyšovat návratnost investic, tedy zvyšovat ROI. Sledování projektu - Efektivním sledováním projektu zajistíte nejen jeho dokonalý průběh, ale i včasné odevzdání. Aplikace umožňuje dokonale monitorovat projekt, především pak sledovat alokaci a přidělování zdrojů, odhadovat a vyhodnocovat náklady, sledovat úkoly a definovat vizuální indikátory upozorňující na nedostatky. Sledování času a nákladů - Genius Project umožňuje sledovat časový rozvrh, vzniklé odchylky a průměrně vyhodnocovat informace. Projektový tým pak získává ucelené výkazy o využití času a jeho efektivitě. Definice procesů (řízení workflow) - Aplikace umožňuje kompletní definici procesů, tedy definovat jednotlivé revize a schvalovací kritéria. Výstupem jednotlivých procesů mohou být automaticky generované dokumenty či definování akceptačních kritérií pro vstup do dalších fází projektu. Aplikace je pak schopna automaticky řídit procesy projektu, definovat požadavky pro vstupy a výstupy. Jak je z popisu aplikace zřejmé, Genius Project se zaměřuje na celkové řízení portfolia projektů, jedná se o kvalitní robustní nástroj, pokrývající oba modely poskytování software, je tedy dostupný jako ucelená aplikace připravená k instalaci do zákazníkovi infrastruktury, tak pro organizace dávající přednost čistě on-demand řešení poskytované formou SaaS (software jako služba).

53

Obrázek 19 - Genius Project - Řízení workflow [22]

Mezi obrovské výhody usnadňující práci projektového manažera patří: •

základní informace umožňující sledování termínů, nákladů a alokace zdrojů,

•

kalendář pro plánování úkolů, schůzek a sdílených událostí napříč týmem,

•

zjištění kritické cesty, sloužící ke zjištění nejdelších možných termínů jednotlivých částí projektu, slouží také k odhadu začátku a konce jednotlivých fází,

•

závislosti napříč projekty, sledování zdrojů, kryjících se na více projektech, jejich alokace, popř. dílčí projekty nutné k úspěšnému dokončení hlavních projektů,

•

ganttovy diagramy napříč projekty, umožňující analytický pohled na stav rozpracovanosti projektu,

•

sledování milníků umožňující rozdělení projektu na stěžejní části,

•

nastavení šablon, priorit, opakujících se úkolů,

•

řízení a analýza rizik.

Obrovským krokem vpřed je plná podpora agilních metodik a přizpůsobení procesů těmto metodikám. Aplikaci je tedy možno nastavit tak, aby projekty a jejich procesy probíhali např. dle systému Kanban, kdy je panel úkolů rozdělen jako Kanban tabule a úkoly jsou reprezentovány kartami. Systém počítá i s velmi oblíbenou metodikou SCRUM, kdy dokáže generovat Burndown grafy, řídit jednotlivé iterace, organizovat úkoly do Backlogů, Sprintů a navíc vše doplňuje o inteligentní systém verzování.

54

Obrázek 20 - Genius Project - Podpora agilních metodik [22]

3 MODELY POSKYTOVÁNÍ SLUŽEB V dnešní době rychle rostoucího počtu startup projektů a neustále se zvyšujícího tempa vývoje, roste stále větší tlak, na akceleraci obchodních procesů, snížení nákladů a možnost provozovat strategické technologie třetí stranou za měsíční úplatu. Toto souvisí především s obecnou úvahou, zda by měli být IT technologie uchovány v rámci organizace nebo mají být dodávány od externích poskytovatelů. Rozhodnutí souvisí přímo s pozitivními aspekty, jako jsou konkurenční výhoda postavení na trhu, vyšší flexibilita, vyšší kvalita a především snížení nákladů. Outsourcing se stal v posledních desetiletích důležitým pojmem, zejména díky rychlému vývoji a nárůstu informací. Největší boom a nástup outsourcingu nastal v roce 1989 [07], kdy společnost Kodak rozhodla z důvodu úspor a zvýšení efektivity provést outsourcing technologií. Důraz byl tehdy kladen na zjištění efektivity v daném sektoru při použití částečného či plného outsourcingu. Odpověď na otázku byla velice složitá a často bez odpovědi, což vedlo častokrát k dilematu, zda nezůstat u tradičního modelu. I přes kritiku a nepřesvědčivé argumenty byl vytvořen řídící tým a díky úspěšnosti projektu získal model outsourcingu velký zájem. Důraz byl v té době kladen na podobu smlouvy mezi outsourcingovými partnery, kdy bylo zjištěno, že smlouva není schopna pokrýt celý projekt outsourcingu a rychle měnící se projekt vyžaduje jistou flexibilitu v těchto partnerských

55

vztazích. Řízení vztahů mezi partnery se stalo klíčovým faktorem pro outsourcingové projekty.

Obrázek 21 - Vývoj IT outsourcingu [Zdroj: vlastní]

Vztah mezi outsourcingem a nynějším cloud computingem lze nejlépe ilustrovat tím, že zákazníci na jedné straně očekávají flexibilní, pružné dodávky IT služeb, na straně druhé však požadují inovaci, která akceleruje jejich obchodní příležitosti. Cloud computing poskytuje technickou základnu pro splnění flexibilních přání zákazníka na obchodní úrovni. Posouvá tak tradiční outsourcing od vztahu zákazník – dodavatel k inovativní formě. Tradiční řetězec hodnot v outsourcingu je rozdělen do oblastí infrastruktury, aplikací a podnikových procesů, které mohou být ještě doplněny o poradenské činnosti. Každá z těchto oblastí má kompletní životní cyklus (naplánování, vytvoření, spuštění). Každá z těchto oblastí může být poskytována externě, např. vývoj aplikací, správa sítě atp. Dokonce i po nákupu vlastního hardware může být určitá část např. poskytování úložného prostoru provozována externí společností. Cloud computing prakticky spojuje tradiční outsourcing s technologiemi, kdy výsledný produkt nabízí jako službu, nekombinuje tedy např. poskytování služeb IT správy dat na hardware zákazníka, ale nabízí zákazníkovi rovnou celou technologii jako službu, tedy konečný softwarový produkt, bez IT zázemí na straně zákazníka. Vysoké efektivity a snížení nákladů je dosaženo pomocí škálovatelnosti (clusterováním serverů) a platbě pouze za spotřebované prostředky. Shrneme-li rozdíl oproti outsourcingu, pak cloud computing integruje hardware i software do balíčku služby. Cloud computing nabízí prostředky různých 56

úrovní, zákazník dostává možnost pronájmu aplikace (Software as a Service), platformy (Platform as a Service) či celé infrastruktury (Infrastructure as a Service). Složením a kombinací těchto služeb lze kompletně podporovat firemní procesy, přístupné pomocí jednoho uživatelského rozhraní. Koncept cloud computingu umožňuje vyvíjet nové komplexní služby orientované na aplikace, složené z on-premise a off-premise či čistě cloud aplikací.

Obrázek 22 - Cloud computing [Zdroj: vlastní]

Z obrázku výše lze vyvodit čtyři hlavni aktéry v rámci cloud computingu: •

agregátor – nabízí služby či řešení, které jsou kombinací již existujících služeb,

•

poskytovatel aplikací – poskytuje a vyvíjí aplikace, které jsou vyvíjeny a nabízeny v cloud prostředí,

•

poskytovatel platformy – nabízí prostředí, ve kterém může být provozována cloud aplikace,

•

poskytovatel infrastruktury – dodává všechny výpočetní a úložné služby potřebné pro běh aplikací. Obrázek ukazuje, že služby mohou být využívány i jinými cloud poskytovateli, lze

tedy říci, že poskytovatel aplikací může provozovat své služby na hardware poskytnutém poskytovatelem platformy či si může dokonce pronajmout celou infrastrukturu. Oproti klasickému outsourcingu, tedy modelu jednoho poskytovatele a jednoho zákazníka, dochází v cloud computingu k nahrazení sítí různých poskytovatelů, v kombinaci s různými poskytovanými úrovněmi služeb. Hlavním rozdílem cloud computingu je jeho 57

flexibilní nasazení bez jakéhokoliv technického zázemí na straně zákazníka. To umožňuje snadnou modifikaci a migraci služeb do cloud prostředí bez velkých investic do IT a především změnu obchodních procesů a jejich inovaci. Samotný cloud computing se dělí především dle služby, kterou poskytuje, ale zároveň také jak je poskytován:

Obrázek 23 – Vývoj cloud computingu [11]

Dle distribučního modelu (Cloud computing verze 1.0) •

IaaS (Infrastruktura jako služba) – poskytovatel poskytuje celou infrastrukturu tedy i middleware,

•

PaaS (Platforma jako služba) – poskytovatel poskytuje platformu pro aplikaci a data,

•

SaaS (Software jako služba) – poskytovatel poskytuje hotovou aplikaci.

Cloud computing od verze 2.0 nově definuje modely: •

BaaS (bussiness jako služba) – často dochází k záměně s (BaaS – Backend jako služba), přesouvá celé podnikání či celou obchodní divizi do cloud prostředí,

•

XaaS (cokoliv jako služba) – jedná se o kombinaci všech předešlých distribučních modelů, v budoucnu se bude jednat o kombinaci a integraci veřejných a privátních cloudů do jednoho prostředí, kde dochází k vytvoření dalších dílčích distribučních modelů (MaaS – Management jako služba, CaaS – Komunikace jako služba, NaaS – sítě jako služba).

Dle modelu nasazení •

Public cloud (veřejný cloud) – cloud je provozován v prostředí internetu, jeho služby jsou dostupné široké veřejnosti,

•

Private cloud (privátní cloud) – cloud je provozován pouze v organizaci a přístupný pouze pro ni, 58

•

Hybrid cloud (hybridní cloud) – cloud kombinující vlastnosti obou předchozích, navenek vystupující jako jeden celek, ale jedná se o propojení privátního a veřejného cloudu pomocí specializované technologie.

•

Community cloud (komunitní cloud) - cloud s vlastnostmi privátního cloudu, který je využíván více než jedním subjektem Jak jsem zmínil v předchozích odstavcích, uživatel má širokou variabilitu výběru, což

klade i požadavky na odlišný způsob jak za služby platit. Oproti outsourcingu máme oproti měsíční platbě za poskytnuté služby další možnosti: •

Pay per use (Pay as you go) – platba za to co zákazník skutečně spotřebuje, např. u pronajímaných cloud virtuálních serverů lze takto platit skutečný spotřebovaný strojový čas, u sítí lze platit skutečná přenesená data atp.,

•

Pre paid (Paid per months, Pay per year...) – předplacené služby, aplikaci možno zaplatit např. na rok dopředu bez ohledu na to, co jsem spotřeboval,

•

Post paid – platba za služby po jejich využití, typický příklad mobilních operátorů, kdy zaplatíme za to, co jsme protelefonovali.

3.1 Distribuční model Vše začalo jako klient-server, virtualizace a SOA20. Rychle rostoucí možnosti výpočetních zdrojů a sdílení strojového času se postupně překlopily do různých forem cloud computingu, kdy na počátku byla Infrastruktura jako služba (IaaS) v podobě možnosti pronájmu celých dedikovaných serverů pro vlastní užití, aniž by se zákazník musel starat o provoz hardware či sítí. V krátké době vznikaly potřeby oddělit i samotnou správu operačního systému a prostředí potřebného pro vývoj a nastoupila Platforma jako služba (PaaS), kde zákazník získal možnost rovnou přistupovat k vývojovému prostředí a využívat vlastní aplikaci, aniž by se zajímal o jakékoliv systémové záležitosti spojené s provozem tohoto prostředí. Od platformy už byl pouze krůček k možnosti pronájmu hotových aplikací tedy Software jako služba (SaaS), kde zákazník rovnou získá aplikaci, kterou potřebuje, okamžitě připravenou ke spuštění. S těmito modely vznikaly další dílčí modely, tedy Management jako služba (MaaS) pokrývající oblast řízení bezpečnosti, kontroly a krizových scénářů při havárii a samotného monitoringu služeb, s ním pak spojené Komunikace jako služba (CaaS) a Sítě jako služba (NaaS) následované Obchodními procesy jako služba (BPaaS).

20

SOA – Service Oriented Architecture – servisně orientovaná architektura

59

Obrázek 24 - Graf analytické společnosti Gartner ukazující nárůst poskytování cloud služeb [17]

Tato evoluce vyvolává obecnou otázku, co bude dál? Dalším krokem je snaha přesunout celý business či část, tedy např. obchodní divizi do cloud prostředí a vzniká tak další model nazývaný Byznys jako služba (BaaS). V podstatě se jedná o službu, kdy zákazník získá soubor aktivit pro spolupráci a transakce k dosažení určitých organizačních cílů. Kompletní obchodní procesy budou zastřešeny do SaaS aplikací poskytovaných v balíčku BPaaS, řízení a monitoring do MaaS, vše spustitelné jako celá platforma pomocí PaaS a hostováno v cloud prostředí jako IaaS. Toto pojetí podnikání umožňuje koncovým uživatelům vzdáleně spouštět a sledovat celé obchodní vertikály v cloudu a vedení pak umožní zaměřit se pouze na své hlavní cíle podnikání. Jednoduše tak umožní poskytovatelům hostovat nejen softwarové řešení, ale i podílet se na řízení organizací, tak aby naplnili požadované cíle.

Obrázek 25 - Srovnání vývoje jednotlivých variant poskytování služeb [Zdroj: vlastní]

60

3.1.1 Infrastructure as a Service (IaaS) Jedná se o poskytování infrastruktury jako služby, tedy poskytovatel dodává zákazníkovi (uživateli) např. kompletní dedikovaný server, často na jedné z virtualizačních technologií. V tomto případě namísto toho, aby uživatel musel sám zakoupit server, vlastnit potřebné síťové prostředí pro jeho umístění, zakoupí připravený server i s těmito prostředky. V podstatě výměnou za nájemné mu třetí strana (poskytovatel) umožní spravovat vlastní, v našem příkladu server na IT infrastruktuře (hardware, síťové prvky, atp.) poskytovatele. Ve srovnání s PaaS a SaaS jsou uživatelé zodpovědní za správu operačního systému, aplikací a jejich licencí. Uživateli tak odpadají náklady na provoz hardware v podobě spotřebovaných energií, IT personál, který by musel provádět jeho správu a údržbu, což napomáhá v rychlejší efektivnější integraci.

Obrázek 26 - Předpokládaný vývoj IaaS na základě průzkumu společnosti Tech Pro Research z roku 2013 [23]

3.1.2 Platform as a Service (PaaS) Nejsložitější ze tří poskytovaných distribučních modelů poskytuje zákazníkovi (uživateli) hotovou platformu připravenou pro vývoj. Jedná se o velmi rychlou a efektivní cestu pro okamžitý start bez nutnosti zakupovat nižší vrstvy tedy hardware, operační systémy a middleware. PaaS tedy umožňuje vytvářet aplikace pomocí softwarových komponent, které jsou řízeny třetí stranou (poskytovatelem). PaaS je vysoce škálovatelné a uživatel se tak nemusí starat o upgrade platformy a vrstev směrem k hardware. Mezi tradiční uživatele PaaS patří společnosti, které chtějí zvýšit efektivitu a často mývají velké množství zaměstnanců.

61

Obrázek 27 - Schéma PaaS distribučního modelu [38]

3.1.3 Software as a Service (SaaS) Software jako služba nám přichází do povědomí asi nejvíce. Prakticky den co den se potkáváme s jejími variantami prostřednictvím užívání některé z cloudových aplikací prostřednictvím internetu. SaaS v drtivé většině případů využívá web k poskytování aplikací, které jsou spravovány a hlavně provozovány poskytovatelem. Uživatel tedy dostává prostřednictvím webového prohlížeče aplikaci, aniž by musel řešit potřebné záležitosti pro její vlastní provoz a licenční poplatky. Aplikace je uživateli poskytována formou pravidelného poplatku tedy pre paid (platba dopředu) či post paid (platba za poskytnuté služby). SaaS slouží organizacím jako nástroje jak efektivně a především okamžitě poskytnout potřebné aplikace. V našem případě se jedná o nejčastější formu poskytování aplikací projektového a portfolio managementu v cloud prostředí. Asi nejlepším případem bývá poskytnutí emailové schránky u providera, kde uživatel získá potřebnou funkcionalitu dostupnou prostřednictvím webového prohlížeče, aniž by sám musel disponovat potřebnými technologiemi pro provoz serveru a middleware.

62

Obrázek 28 - Nárůst SaaS očekává, že 85% aplikací bude v roce 2015 dodáváno jako služba [28]

3.1.4 Business as a Service (BaaS) Business jako služba je nově vznikající distribuční model, kdy po velkém úspěchu předchozích zmíněných modelů vznikají požadavky na přesun celého byznysu do cloudu. Majitelé organizací pak získají strategické nástroje k naplnění obchodních cílů, poskytovatel se tak stane částí strategického řízení společnosti a bude zodpovědný za naplnění požadovaných cílů. BaaS bude sdružovat architekturu, modelování, technickou stránku, návrh a plánování, společně se službami monitoringu a kompetencí potřebných k dodání škálovatelného a spolehlivého řešení s nízkými náklady. Majitelům dá pak do rukou šablony, nástroje, provozní modely, SLA smlouvy a další integrované sady. BaaS přináší následující výhody [11]: •

rychlost – zkušenosti dodavatele a práce založená na znalostech dodá očekávané obchodní výsledky,

•

adaptabilita / agilita – inovace třetích stran zvyšující efektivitu a snižující náklady,

•

škálovatelnost / elasticita – dostupnost služby více společnostem naráz,

•

spolehlivost / opakovatelnost – proces učení a zlepšování procesů opakováním,

•

náklady / flexibilita – modely cen předplatného,

•

analytika – reporty o nákladech, efektivnosti a účinnosti,

•

strategické cíle – vyšší efektivita a inovace podnikatelských schopností tím, že dochází ke kombinaci platforem, aplikací, infrastruktury a znalostí procesů,

•

spolupráce – lepší komunikace mezi byznysem a IT

•

monitoring a odpovědnost – realtime monitoring a řízení podnikových procesů. 63

BaaS v sobě skrývá samozřejmě i řadu nevýhod, mezi nejvíce zmiňované bude nejspíše patřit vyspělost samotného poskytovatele, tak aby poskytnuté služby odpovídaly požadované úrovni. Dalším obrovským otazníkem je bezpečnost samotných dat, procesů a použitých nástrojů. Nicméně podobné problémy zde stály i před vznikem cloud computingu a dá se říci, že jsou překonatelné. Stejně tak i BaaS bude dozrávat a poskytovatelé se poučí z vzniklých chyb tak, aby je eliminovali.

Obrázek 29 - Byznys jako služba [Zdroj: vlastní]

3.2 Model nasazení Účelem cloud computingu je snížení nákladů a zvýšení efektivity, nicméně cloud computing ssebou nese i určitá rizika a nové výzvy pro IT management, což vede k vyšším nákladům. Z tohoto důvodu je pro organizace důležité zvolit správný typ cloudu. Nasazení cloud computingu lze provést několika způsoby, vždy však v závislosti na následujících faktorech: •

kde jsou služby hostované,

•

bezpečnostní požadavky,

•

touha sdílení cloud služeb,

•

schopnost řídit některé či všechny služby,

•

možnosti přizpůsobení. Známy a definovány dle NIST (National Institute of Standard and Technology)

v dokumentu 800-145-The NIST Definition of Cloud Computing [34] jsou čtyři modely nasazení, stanovené dle typu přístupu ke službě: •

public cloud (veřejný cloud),

•

private cloud (privátní cloud),

•

hybrid cloud (hybridní cloud), 64

•

community cloud (komunitní cloud). Z modelů nasazení je jasné, že hlavní požadavky jsou kladeny na bezpečnost dat a

jejich umístění, tedy zda data mohou být dostupná prostřednictvím internetu, či nesmí opustit budovu a přístup k nim se podřizuje tvrdé bezpečnostní politice.

Obrázek 30 - Procentuální zastoupení jednotlivých cloud modelů [24]

3.2.1 Private cloud (Privátní cloud) Tento model nepřináší z hlediska úspor nákladů takové efektivity, je prakticky srovnatelný s budováním a správou vlastní infrastruktury. Díky neustále zvyšujícím se výzvám v oblasti bezpečnosti dat však přináší obrovskou efektivitu. Privátní cloud často odpovídá požadavku zákazníka na vybudování cloudu geograficky položeného ve vlastní budově, či na místě třetí strany, kdy je přístup řízen vysokou bezpečnostní politikou. Z pohledu přístupu pak lze toto řešení ještě dělit: •

on-site cloud – v budově zákazníka

•

off-site (outsourced) cloud – v datacentru poskytovatele V případě mission-critical21 dat se jedná o jediné akceptovatelné a navrhované řešení.

Kromě bezpečnostních důvodů, nařizují použití privátního cloudu normy bezpečnosti dat a aplikací např. SOX, SAS 70, HIPAA, vyžadující aby data byla situována a spravována na 21

Mission Critical Data – Data kritická z pohledu chodu společnosti (účetnictví, strategické plánování…)

65

bezpečném z internetu nepřístupném místě. Mezi organizace, kterým normy nařizují tato pravidla, patří zdravotnické a farmaceutické společnosti. Dalším příkladem mohou být i rozdílné kultury zemí, mající různé normy pro uchování a přístup k citlivým datům. Z toho důvodu většina výrobců podnikových aplikací nabízí možnost data uchovávat na vlastních serverech mimo cloud.

Obrázek 31 - Veřejný vs Privátní cloud [41]

3.2.2 Public cloud (Veřejný cloud) Veřejný cloud a jeho infrastruktura je k dispozici pro širokou veřejnost, vlastněná poskytovatelem služeb. Jedná se o nejčistší formu cloud computingu. V tomto modelu poskytovatel dynamicky poskytuje výpočetní zdroje pomocí internetu, které pak zákazník sdílí s jinými organizacemi. Poskytovatel tyto zdroje často vyúčtovává na základě spotřebovaného strojového času, obdobně jako tomu je u vyúčtování elektrické energie. Tento model je pro většinu zákazníků velice efektivní, jelikož platí pouze to, co skutečně spotřebují a všechny služby jsou dodávány v souladu s nasmlouvanými podmínkami. Nevýhodou je nižší bezpečnost kritických dat, přeci jen servery běžně dostupné z internetu nesplňují vysoké bezpečnostní požadavky.

3.2.3 Hybrid cloud (Hybridní cloud) Model hybridního cloudu se skládá z kombinace dvou cloudů, umožňuje organizacím využít např. zabezpečených dat z privátního cloudu a zároveň stále těží z výhod veřejného cloudu tím, že využívá sdílených dat a aplikací. Hybridní cloud se často využívá také jako tzv. 66

cloud bursting, kdy privátní cloud již nedokáže zvládnout zátěžové špičky a část je vyrovnávána (balancována) pomocí veřejného cloudu. Mnoho výrobců aplikací nabízí k dispozici své API, pomocí kterého může aplikace komunikovat s privátním cloudem např. při čtení dat či opačně. Zákazníci se často neupínají k jednomu řešení a volí variantu v poměru cena a bezpečnost. Hybridní řešení však vyžaduje dokonalou přípravu a kompatibilitu jednotlivých řešení. I při samotném vývoji aplikace musí být počítáno s možností ukládání části dat do zabezpečeného privátního cloudu.

Obrázek 32 - Hybridní cloud [52]

3.2.4 Community cloud (Komunitní cloud) Komunitní cloud by se dal nazvat privátním cloudem pro více organizací, které sdílí stejné bezpečnostní politiky a IT procesy. Oproti privátnímu cloudu se tak náklady dělí počtem společností, které sdílí komunitní cloud. Typickými zákazníky bývají státní organizace veřejné správy, které sdílí totožné databáze obyvatelstva či obdobné informace, tedy např. zdravotní organizace, farmaceutické organizace či bezpečnostní sbory s jurisdikčními úřady, soudy atp. Nemusí se však jednat o samotné sdílení dat, nicméně i o sdílení výpočetních zdrojů. Důležité je však brát v potaz návrh infrastruktury, na kterém se musí shodnout všechny zúčastněné strany. Typicky k tomu dochází u společností se stejným obchodním zájmem, kdy dochází k odstranění duplicitních systémů, např. organizace poskytující účetní agendu se může dohodnout s organizací poskytující mzdy na společném řešení. Typickým příkladem je vznikající Eurocloud Evropské unie [21].

67

3.3 Smluvní ujednání o poskytování služeb U každé poskytované služby je nutné sepsání potřebných dokumentů ošetřujících dostupnost služby, metriky dostupnosti, smluvní pokuty, mlčenlivost a strategii v případě ukončení služeb. U cloud služeb jsou zpravidla tvořeny dva hlavní smluvní dokumenty, které pokrývají zmíněné oblasti. Tyto dokumenty mohou být doplněny dalšími dle požadavků zákazníka či poskytovatele.

3.3.1 SLA (Service Level Agreement) Smlouva o poskytování služeb (SLA) je dokument, který uspokojuje potřebu co nejlépe definovat rozsah, úroveň a intenzitu poskytnutých služeb. SLA je známa především z IT prostředí ve spojení s outsourcingem, kde představuje hlavní pilíř mezi poskytovatelem a zákazníkem, nově také spojená i s cloud computingem či telekomunikacemi. Smlouva zjednodušeně řečeno říká, co je poskytováno, v jaké úrovni, kdy, kým a za kolik peněz. Smlouva slouží jako ochranný nástroj pro zákazníka, ale i poskytovatele. Hlavním cílem SLA je zajistit provoz klíčových služeb, v případě IT klíčových systémů. K čemu je nám úžasný výkonný server, když se k němu nelze spolehlivě připojit nebo k čemu je mi zaplacená internetová reklama, když moje webová prezentace nefunguje. Často stojí za provozem aplikací nemalé částky, které ztrácíme právě díky nedostupnosti služby. Za tímto účelem je sepisována SLA smlouva, která v případě zmíněných příkladů jasně definuje úroveň služeb, smluvní pokuty a tím chrání investice. Každá SLA smlouva obsahuje tři základní položky [43]. Základní specifikace služby, pravidla a podmínky: •

kategorie příjemců,

•

vymezení počtu a umístění příjemců dané kategorie,

•

detailní popis služby,

•

objem poskytnutých služeb,

•

bližší určení poskytovatele,

•

měření - postup, způsob, periodicita, odpovědnost a vykazování výsledků,

•

ověřování – postup, způsob, periodicita, odpovědnost,

•

určení způsobu podpory,

•

navazující služby (školení),

•

cena služby, 68

•

platební podmínky,

•

pravidla pro změny služby,

•

práva a povinnosti obou smluvních stran,

•

ostatní podmínky (bezpečnost, právo informovanosti…).

Tvrdé metriky •

dostupnost služby,

•

standardní a maximální (kritická) doba odezvy požadavku (incidentu),

•

kategorizace požadavků na typy (hlášení poruchy aplikace, poruchy hardware, nefunkčnost aplikace ...).

Měkké metriky •

jiné metriky služby (kvalitativní ukazatele typu „potvrzení školení a prezenční listina", „hodnocení školení", „hodnocení účastníka"…).

Smluvní pokuty •

na základě metrik definuje smluvní pokuty při nedodržení poskytnuté úrovně služby,

•

výpočet dostupnosti.

Exit strategie •

pro případ, kdy se zákazník rozhodne změnit poskytovatele, je vhodné ošetřit, jakým způsobem budou získána data (formát zálohy, cena, způsob dodání), eventuální možnost migrace na jiné řešení. SLA smlouva je základem každého smluvního vztahu mezi poskytovatelem a

zákazníkem, na jejím základě stojí kvalita poskytovaných služeb. Organizace získává určité jistoty a je ušetřena nemilých překvapení v podobě výpadků či přímo nedostupnosti služby. Některé velké organizace věnují SLA smlouvě velké úsilí a vznikají i samostatné metodologie pro její sestavení, příkladem může být následující obrázek definující metodologii SLA smlouvy společnosti Cisco.

69

Obrázek 33 - Metodika SLA pro zajištění cloud služeb společnosti Cisco [15]

3.3.2 NDA (Non-disclosure agreement) Dohoda o mlčenlivosti (NDA) bývá uzavírána zejména v případě, kdy si dvě strany chtějí navzájem sdělit své know-how, citlivá data či jednoduše chtějí omezit druhou stranu ve vynášení informací mimo sjednaný účel spolupráce. Obecná pravidla o mlčenlivosti většinou bývají obsahem SLA smlouvy nicméně obzvlášť u služeb využívaných v cloud prostředí je vhodné ošetřit únik citlivých dat třetím stranám, které bývají zpravidla zneužívána pro marketingové účely či v horších případech k vyzrazení konkurenční výhody. S NDA se lze také setkat již v prvotních krocích tzv. analýzy proveditelnosti, kdy poskytovatel v našem případě cloud služeb může testovat vhodnost aplikací pro migraci do cloud prostředí. Při této analýze se samozřejmě nevyhne citlivým datům, či firemním procesům, které by při vyzrazení mohli ohrozit zákazníka ať už v povaze konkurenčního znevýhodnění tak i vyzrazením tajných (confidental) informací. Český obchodní zákoník obsahuje pojmy k ochraně důvěrných informací, které jsou zakotveny v § 271, kdy umožňuje chránit informace, které jsou smluvními stranami označeny výslovně jako „důvěrné“. V novele z roku 2014 je navíc nově rozšířena i tzv. předsmluvní odpovědnost, která dává za povinnost poskytnout druhé straně všechny skutkové a právní okolnosti vedoucí k úsudku, zda je zřejmý zájem uzavřít smlouvu. Tímto je ochráněna dobrá víra druhé strany, že zájem uzavřít obchodní smlouvu je opravdu zřejmý. Dospěje-li jednání do fáze, kdy je uzavření smlouvy pravděpodobné a jedna 70

ze stran bez důvodu zmaří uzavření smlouvy, pak tato strana jedná nepoctivě a odpovídá druhé straně za vzniklou škodu (do výše vyčíslené ztráty). Za důvěrné však v rámci NDA nelze označit informace, jež jsou obecně známé (např. to, že člověk podniká a v jakém odvětví podniká). Každá NDA obsahuje tyto základní položky: Základní definice důvěrných informací (považované za důvěrné dle § 271 obchodního zákoníku): •

běžně nedostupné technické a obchodní údaje nebo informace (know-how, popis funkcionality softwaru, zdrojové kódy, vnitřní procesy, technické návrhy, výkresy, analýzy, firemní dokumenty, smlouvy a řešení tvořící součást nabídky zhotovitele softwaru, zákonem chráněné patenty či vynálezy a jiné předměty duševního vlastnictví).

Definice závazku mlčenlivosti •

povinnost zajistit informace, aby nedošlo k jejich vyzrazení třetím osobám a dále povinnost tyto informace dále nesdělovat bez souhlasu,

•

definice negativním vymezením co není porušením závazku.

Stanovení smluvních pokut při porušení •

specifikace náhrady škody bývá běžnou součástí a její stanovení by mělo být v kontrastu s předmětem mlčenlivosti, tedy jaká škody by nám tímto mohla být způsobena.

Doba trvání mlčenlivosti •

doba trvání bývá zpravidla stanovena s ohledem na životnost předmětu mlčenlivosti, nicméně bývá i stanoven na neurčito.

Samotné porušení NDA je pak ošetřeno v § 373 obchodního zákoníku ve znění: „Kdo poruší svou povinnost ze závazkového vztahu, je povinen nahradit škodu tím způsobenou druhé straně, ledaže prokáže, že porušení povinností bylo způsobeno okolnostmi vylučujícími odpovědnost.“ Při sestavování NDA bývá často bráno v potaz i spektrum použití, tedy zda má být smlouva sepsána za organizaci a jejího představitele či přímo s konkrétními zaměstnanci. Hlavním kámen úrazu bývá často samotná formulace smlouvy, jelikož špatně sestavená NDA smlouva může být omezením pro poskytovatele z pohledu prezentace vlastních technologií, či

71

produktů, které jsou zrovna implementovány u zákazníka, kde je mlčenlivost ošetřena pomocí NDA.

4 VLIV PM V CLOUDU NA APLIKACI KLASICKÝCH A AGILNÍCH METODIK Cloud a řízení projektů jsou dva různé zavedené pojmy, které si kladou za cíl usnadnit provoz a zvýšit produktivitu. Jak již bylo několikrát zmíněno, projektové řízení je termín pro soubor činností a postupů, jak provést efektivně úkol, tak aby naplnil požadované cíle. Tím je zajištěna vysoká pravděpodobnost úspěchu projektu a zároveň je účinně využito zdrojů projektu. Metodiky řízení projektů zahrnují různé způsoby, jimiž mohou být projekty úspěšně provedeny v závislosti na požadavcích daného projektu. Cloud je jednou z největších inovací v odvětví technologií pro optimalizaci využití zdrojů. Dle požadavků zákazníka poskytuje různé úrovně služeb s vysokou mírou elasticity. Z obou zmíněných pojmů je jasně vidět, že společným jmenovatelem obou je optimalizace zdrojů. Použití cloud služeb v oboru projektového řízení může znamenat různé změny v metodikách provádění projektu. Důsledky zapojení cloud do projektového managementu jsou následující: •

zrychlení procesů – použitím cloudu se posunou běžné úkony prováděné na projektu do zcela jiného rámce, nástroje se stávají dostupné na cestách, což i významně akceleruje samotné procesy,

•

řízení zdrojů – díky významné akceleraci samotných procesů dochází k vyšší aktuálnosti využití zdrojů, optimalizuje se jejich využití a díky centralizované povaze vzniká i významné zlepšení komunikace týmu,

•

řízení integrace – procesy mohou být integrovány do společných celků a vytvářet tak společný přístup což vede k vyšší efektivitě. Cloud v podstatě napomáhá ke zlepšení samotného projektového řízení, zefektivňuje

samotný přístup a zvyšuje efektivitu z hlediska kvality služeb na straně zákazníka, ale zároveň přímo pozitivně ovlivňuje zisk. Vliv je dále patrný především v možnosti pronájmu cloud řešení a jeho okamžitém používání. Velké i menší organizace mohou přímo akcelerovat své procesy, aniž by museli mít povědomí o jakýchkoliv technologických aspektech používání aplikace. S cloud však také vznikají nové požadavky na projektové řízení: •

často nové na míru tvořené metodiky a projektové cykly, 72

•

státní nařízení a pravidla,

•

bezpečnostní standardy,

•

smlouvy s cloud poskytovateli, SLA a NDA smlouvy, pokuty,

•

více odlišných kultur v mezinárodních týmech,

•

nutnost predikce rizik v cloud prostředí.

4.1 Současný stav Oblast IT a moderního projektového řízení IT prožívá revoluční bouři změn. Za tímto boomem stojí především přechod k agilnímu přístupu vývoje software a zvyšující se dostupnosti nástrojů cloud computingu. Agilní vývoj je synonem efektivního postupu jak zeštíhlit projekt a odevzdat produkt v co možná nejkratším čase s maximálním zapojením zákazníka do vývojového procesu. Agilní přístup odráží zdravý rozum během životního cyklu projektu a dalo by se říci, že cloud computing funguje jako jeho akcelerátor. Cílem agilního přístupu je odstranit zbytečné a odevzdat co nejdříve hotovou část produktu. Každý takovýto odevzdaný kus zdokonaluje další vývoj, vývojový tým doslova dospívá a učí se z předešlých úkolů. Díky tomuto lze některé části následně automatizovat a akcelerovat, což přímo nahrává k otázce, proč se spokojit s málem a rovnou nevyužít to, co nám moderní technologie nabízí. Odpovědí je v tomto případě samozřejmě cloud prostředí. Cloud computing je znám především díky své elasticitě, robustní škálovatelnosti a efektivním nakládáním s přidělenými zdroji. Principem cloud computingu je dodat co nejrychleji potřebnou infrastrukturu, platformu či aplikaci, tak aby zákazník mohl okamžitě začít využívat potřebné zdroje. Z pozorování potřeb moderního vývoje a projektového řízení vyplývá, že prioritou je uspokojit zákazníka díky včasnému a průběžnému dodávání softwaru se stále přítomnými nároky na kvalitu a komfort provozu, v čemž nám do vysoké míry napomáhají cloud technologie. Cloud není pouze úzce spjatý s agilním přístupem, i když společně tvoří opravdu dokonalý způsob jak co nejefektivněji dodat potřebný produkt. Cloud computing přináší samozřejmě i nové možnosti a výzvy u klasických rigorózních metodik: •

fáze požadavků – při shromažďování požadavků je nyní nutné brát v potaz nejen tradiční problematické body samotného projektu, ale nově vznikají i problémy v oblasti bezpečnosti, soukromí a celkového výkonu cloud prostředí,

•

fáze návrhu – cloud prostředí vyniká rozsáhlou možností replikace, paralelních dotazů, geograficky distribuovaných komponent a vysokou schopností zotavení po havárii a poskytuje služby pro integraci mobilních zařízení, s těmito schopnostmi získáváme 73

mnoho již hotových scénářů použití, cloud však i v mnoha určitých směrech může svazovat ruce, architektura některých prostředí bývá pevně dána a s těmito omezeními musíme předem počítat, •

fáze vývoje – vznikají vyšší požadavky na vývojáře, kteří musí chápat klasické pojetí vývoje a nově i způsob vývoje v cloud prostředí, především pak znát možnosti jednotlivých distribučních modelů (SaaS, PaaS, IaaS),

•

fáze implementace – rychlost implementace je klíčovým faktorem projektu, v cloud prostředí lze aplikaci nasadit v řádu minut, k dispozici jsou i automatizované procesy,

•

fáze testování – některé cloud platformy mohou být velice složité, nikdy přesně nevíme, jaký middleware se skrývá pod aplikační vrstvou, rychlost prostředí je závislá na momentální zátěži daného cloudu, což nám znesnadňuje přesné určení metrik, na druhou stranu je podstatou cloudu vysoká dostupnost, která nám dává garanci provozu aplikace i v případě kdybychom u klasického prostředí dávno vyčerpali své prostředky,

•

fáze údržby – díky robustnosti cloud prostředí a vysoké dostupnosti je řešení technických chyb otázkou chvilky, na druhou stranu máme menší možnosti si chyby opravit sami. Analytická společnost Gartner v roce 2010 studovala trendy trhu a ve své zprávě Agile

a Cloud Impact Application Development Directions [35] předpověděla, že do roku 2012 budou agilní metodiky stát za 80% vyvíjených produktů. Zbytek budou tvořit hybridní metodiky. Díky cloud prostředí a agilnímu přístupu mohou organizace rychleji dodávat části softwaru.

4.2 Agilní přístup postupně nahrazuje tradiční metodiky Od svého vzniku v roce 1970 byl vodopádový přístup úspěšně užíván k vývoji software. Vývoj probíhal lineárními a sekvenčními procesy až po dokončení aplikace. Proces probíhal v několika fázích s odlišnými cíli. Pochopení a stanovení požadavků zákazníka bylo nutné již v prvotní fázi. Tato fáze pak byla následována fázemi návrhu, vývoje, implementace atd., v závislosti na dané metodice. Tento přístup má bezesporu výhodu v jasně definovaných fázích a standardech, které pomáhají pří stanovení přesného rozpočtu, šetří úsilí a čas díky jasně definovanému plánu. Díky těmto benefitům byl a je vodopádový přístup používán dlouhou dobu. Nicméně vodopádový přístup trpí vlastními nedostatky, první z nich vyplývá již z názvu, jelikož jakmile voda přesáhne okraj vodopádu, nelze již ustoupit stranou. 74

Nastane-li během projektu chyba, je složité ji v dalších fázích odstranit. Základním a nutným požadavkem vodopádového přístupu je, aby zákazník znal všechny své požadavky předem. V reálných případech však platí, že žádný zákazník není schopen vše do detailu předem popsat. Principem cloud computingu je rychle dodávat prostředky např. pro vývojáře, tak aby mohli rychle reagovat na zákaznické požadavky. Agilní metodiky naopak neočekávají, že všechny požadavky budou známy předem, zaměřují se na zjištění požadavků zákazníka během procesu vývoje, přičemž části software jsou uvolňovány pravidelně v průběhu vývoje a vytváří se vysoce interaktivní prostředí mezi vývojářem a uživatelem. Ve spojení s cloud computingem pak umožňují maximální rychlost doručení a především slouží k rychlé reakci na zákazníkovi požadavky, což má za následek zrychlení dodávek a snížení nákladů. Agilní metodiky a cloud se skvěle doplňují.

Obrázek 34 - Vývoj metodik [19]

4.2 Jaká je správná cesta pro budoucnost? Cloud computing je synonymem rychlého doručení služeb a agilní metodiky poskytují vysokou spolehlivost pro spolupráci vývojového týmu a uživatelů. Agilní vývoj si klade za cíl rozebrat projekt do menších dosažitelných segmentů a s maximální účastí uživatelů na každém projektu. Tyto segmenty mohou být plánovány, vyvíjeny a testovány individuálně s důrazem na kvalitu a standardy. Vývojové stádium každé takovéto složky se tak stává jednou iterací. Agilní metodiky navíc kladou obrovský důraz na rozvoj spolupráce a vztahů mezi vývojáři a koncovým uživatelem, pro kterého je celý vývojový proces transparentní a zpětná vazba je požadována ve všech fázích vývoje. Pouze štíhlé agilní metodiky poskytují 75

v souvislosti s cloud vysoce interaktivní a týmové prostředí. Vývojáři mohou dokončit funkci či část aplikace a tu pak poskytovat jako samostatnou cloud službu. Díky dostupnosti cloudu, pak uživatelé sami fungují jako okamžitá zpětná vazba, čímž odpadají prodlevy, které vznikají v klasickém prostředí, než uživatel vyzkouší dokončenou část a podá zpětnou vazbu. Tímto se výrazně zkracuje čas vývoje a zároveň narůstá spokojenost uživatelů. Společnost Capgemini ve spolupráci s HP a Sogeti provedli v roce 2010 průzkum [36], za účelem zjištění přijetí agilních metodik nasazených v cloud prostředí. Studie pokryla zhruba 30000 dotazovaných, složených převážně z cloud expertů, IT managerů, inženýrů a manažerů kvality pracujících ve vedoucích firmách trhu v Evropě, Americe a Asii. Studie došla k závěru, že s nárůstem používání cloud služeb, se organizace začali zaměřovat na zefektivnění provozu za použití štíhlých agilních metodik. 60% společností, které se účastnily průzkumu, plánuje nasazení agilních metodik u svých nových projektů, kde bude využit cloud computing. Organizacím tak tento přístup pomáhá k získání rychlé zpětné vazby od uživatelů a umožňuje jim sledovat normy kvality, v každé části vývojového procesu. Mezi hlavní výhody při použití agilních metodik ve spojení s cloud computingem patří: •

zkrácení doby vývoje,

•

snížení nákladů,

•

zvýšení efektivity využití zdrojů,

•

zvýšení kvality aplikací a jejich dostupnosti.

Z citace Jonathana Rendeho [53] (vice prezident a generální manažer optimalizace aplikací a podnikových technologií pro aplikace a řešení společnosti HP): „Poskytovatelé IT čelí intenzivnímu tlaku na rozvoj nových aplikací, které poskytují konkurenční výhodu, přináší vyšší efektivitu a vytváří měřitelné výsledky. Integrace agilních metodik s cloud computingem umožňuje organizacím posílit své portfolio IT pro lepší poskytování služeb při současném snížení nákladů.“ Závěrem lze tedy říci, že kombinace štíhlých agilních metodik a cloud computingu, přináší to nejlepší z obou světů. Cloud computing je o tom, jak by měly být dnes aplikace dodávány. Výsledek tohoto technologického pokroku je: •

zvýšení výpočetního výkonu, jež činí virtualizaci realitou,

•

zvýšení sofistikovanosti ukládání, jež činí skladování dat hladce škálovatelné,

•

vysoká šířka pásma sítě, zlepšení bezpečnosti a spolehlivosti internetu.

76

Agilní metodiky optimalizují příležitosti, které nám cloud computing dává tím, že dělá verze software iterativní a od uživatelů poskytují rychlejší zpětnou vazbu. To hraje významnou roli ve vývoji organizace.

5 PROJEKT PŘEVODU PM DO CLOUDU Proces přesunu do cloud computingu je proces, který musí být důkladně naplánován a nesmí být opomenut ani maličký detail. Za většinou problémů stojí často špatně optimalizované aplikace pro cloud platformy či nesprávný výběr samotného distribučního modelu. Špatný postup migrace může lehce spálit jakákoliv pozitiva samotného cloud computingu, byť mohou být již na první pohled zřejmá. Na samotný přesun do cloudu bylo již sestaveno několik „best practice“ scénářů a některé společnosti si často sestavují i vlastní metodiky pro přesun, jak tomu může být na příkladu společnosti Oracle [29]. Vždy je však důležité dopředu prozkoumat stávající požadavky na IT prostředí a možné výhody, které nám cloud může přinést v závislosti na požadavcích, na které si je třeba odpovědět ještě před samotnou realizací samotné migrace [16]. Samotným popisem a detailním kritérii jednotlivých prostředí se zabývá kniha „Cloud Computing and SOA Convergence in Your Enterprise: A Step-by-Step Guide“ [04]. Zároveň je potřeba si uvědomit kompatibilitu samotné aplikace, zda pro ni potřebujeme vlastní infrastrukturu a budeme tedy muset začít uvažovat o IaaS modelu, či platformu PaaS nebo je aplikace již vyvíjena s ohledem na cloud a je poskytována samotná tedy SaaS.

5.1 Základní kritéria před přechodem Identifikace vedlejších nákladů Aby bylo možné spustit velmi rozsáhlou aplikaci s velkým množstvím uživatelů v cloudu, je nutné provést investice i ve stávající infrastruktuře, tak aby samotný přesun naznamenal totální blackout22 pro organizaci. Bude nutné zvážit propojení aplikací, závislost dalších systémů, zejména databázových částí, které bývají často sdíleny mezi více aplikacemi. Je třeba zvážit, zda převést pouze určitou část aplikačního portfolia či celou infrastrukturu. Často se stává, že po přechodnou dobu dochází k tzv. dvojitým platbám, kdy musíme určitou aplikaci udržovat pro staré i nové prostředí a tím platit za samotné licence a provoz 2x (staré on-premise řešení a nové cloud řešení). Většina velkých aplikací nepracuje sama, často 22

Blackout – v angličtině je tímto výrazem označován rozsáhlý výpadek elektřiny, termín však přešel do IT prostředí, kde označuje výpadek aplikace

77

vyžadují určitý middleware či podpůrnou aplikaci. Příkladem mohou být databázové systémy, ale i samotné migrační nástroje. Některé z těchto aplikací vyžadují zvláštní licencování a tím i vznikají další vedlejší náklady.

Správně nastavené parametry služby Většina migrací a přesunů probíhá v nočních hodinách, kdy systémy nejsou využívány zaměstnanci. V těchto hodinách často probíhají i zálohy cloud prostředí. Je tedy nutné s dodavatelem tyto záležitosti předem dohodnout a naplánovat, tak aby nedocházelo ke kolizím. Dalším důležitým požadavkem je počítat s nárůstem stávajících dat s ohledem na finanční možnosti. V cloud prostředí jsou účtovány právě spotřebované prostředky. Je tedy nutné např. počítat s nárůstem dat, kdy zejména vývojové týmy provozují několik verzí aplikace (vývojová verze, testovací či beta verze, stable či produkční verze), čímž nám značně narůstají požadavky na diskový prostor a strojový čas serveru.

Volba vhodného prostředí IaaS, PaaS či IaaS U velkých aplikací je na výběr z několika variant prostředí, pokud požadujeme kontrolu nad vlastním systémy, je vhodné pronajmout celou infrastrukturu (IaaS), kde přesunem získáme škálovatelnost a elasticitu, ale stále si sami budeme zodpovídat za patřičná nastavení operačních systémů, middleware i aplikací. Volbou PaaS či SaaS si bezesporu ušetříme náklady na tyto úkony.

Je však nutné zvážit i personální dopady, kdy jsou

zaměstnanci často přesouváni v rámci dceřiných organizací z pozic, které zanikly. V některých zemích jsou zaměstnanci chráněni tzv. předpisy TUPE23 [48], tedy jsou chráněni i v případě změny vedení společnosti či přesunu pod jinou společnost a jejich nároky jsou stejné jako ve společnosti předešlé.

Dostatečná šířka pásma připojení Stejně jako u každé služby na dálku je kladen velký důraz na kvalitu a dostatečnou šířku pásma internetového připojení. V pracovní špičce bude k serveru přistupovat vysoký počet uživatelů. Zatímco poskytovatelé cloud služeb tyto nápory očekávají a jsou schopni je dostatečně vykrýt, organizace často podceňují požadavky na připojení vlastních poboček, kdy použití konektivita často nestačí k vykrytí špiček.

23

TUPE - Transfer of Undertakings - Protection of Employment

78

Zabezpečení Stejně jako u ostatních služeb je zabezpečení prvořadé. Kontrola zabezpečení by měla probíhat v několika úrovních, jak od samotné infrastruktury, až po kontrolu aplikace. Dostatečně zabezpečená aplikace by měla splňovat: • • •

šifrování a ověřování komunikace, tak aby nebylo možné data po cestě odchytávat a zneužít, zabezpečení rozhraní aplikace, tak aby nebyla přístupná jiným než oprávněným požadavkům dílčích aplikací, fyzické firewally, které chrání servery před útoky hackerů.

Efektivita z hlediska nákladů V cílovém důsledku by měl cloud poskytnout úsporu oproti klasickému řešení. Je nutné identifikovat, jak je účtováno využití serveru. U veřejných cloudů je často účtován pouze spotřebovaný čas. Jak je tomu však u privátních cloudů, kde servery poskytující virtuální stroje běží nonstop? Samotné virtuální stroje by měly být dynamicky sestavovány a systémové zdroje by jim měly být přidělovány dle zátěže, tedy reálných požadavků uživatelů.

5.2 Měřitelné úspory nákladů - ROI a TCO Technologická stránka je pouze část z celého procesu přechodu do cloudu. Hlavním podstatou proč přejít do cloudu je úspora, kterou nám cloud oproti klasickému řešení přinese. Počáteční analýza nám zaručí, že návratnost investic se zvýší a náklady se sníží. Počáteční analýza nám také pomůže k zúžení výběru správného cloud providera a pomůže nastínit náklady v horiznotu několika let. U každého projektu implementace či migrace IT technologie, kdy se nemusí nutně jednat o cloud, musíme vedení společnosti předložit informace ohledně celkových nákladů na vlastnictví a návratnost vložených investic. K tomuto nám slouží dva ekonomické ukazatele, ROI (ukazatel rentability – návratnosti investic) a TCO (celkové náklady na vlastnictví). Ještě před samotným popisem ROI a TCO je nutné pochopit dělení nákladů dle jejich povahy.

Dělení nákladů V praxi dělíme náklady na investiční (kapitálové) a provozní (operativní) náklady. Jak již bylo zmíněno několikrát v předchozích kapitolách, cloud přenáší kapitálové náklady do provozních. Nutné investice např. do licencí jsou odbourány a provider cloud řešení tyto náklady zohledňuje v pravidelných poplatcích ve formě nájemného.

79

Kapitálové náklady – CapEx (Capital Expenditure) - Jsou náklady na pořízení fyzického majetku, tedy v našem případě u on-premise řešení nákup serveru, jednotlivých licencí a potřebných síťových prvků. Provozní náklady – OpEx (Operating Expense) - Jsou náklady na provoz, spadají do nich např. náklady na mzdy či náklady za služby. U cloud řešení sem spadají náklady za pronájem. U cloudu se lze také setkat s členěním nákladů dle životního cyklu [14]: Počáteční náklady (Upfront costs) – náklady na technické konzultace, změnu infrastruktury, služby spojené s implementací, integrací a školení zaměstnanců, Opakující se náklady (Recurring costs) – náklady na měsíční nájemné za řešení, podporu ale také náklady na řízení změn poskytovaných služeb či koordinace nutná k začlenění do cloud, Náklady na ukončení (Termination costs) – náklady na přechod k jinému providerovi či návrat k on-premise řešení. Pokud se na výše zmíněné náklady podíváme detailněji, je jasně patrné, že pod upfront náklady se skrývají kapitálové náklady, pod recurring náklady pak provozní náklady. Termination náklady jsou jakýmsi hybridem, kdy na tyto náklady lze nahlížet jako na kapitálové (v případě nákupu nového on-premise řešení a pořízení licencí), ale také jako na provozní náklady, kdy migraci bude nutné využít lidské zdroje či služby třetích stran.

ROI - Return of Investment ROI je ukazatel návratnosti investic a v praxi se používá k hodnocení vložených investic do určitého produktu, projektu či inovace. V našem případě nás bude zajímat ROI při porovnání investice do on-premise řešení v porovnásí s cloud řešením. ROI slouží vedení společnosti jako kritérium rozhodnutí, zda do inovace či projektu investovat a zda se vynaložená investice vrátí a v jakém časovém horizontu. Aby ROI dávalo smysl, je vždy nutné mít adekvátní podklady pro jeho výpočet, v našem případě nás bude zajímat výše ročních nákladů na provoz on-premise řešení a roční výše nákladů cloud řešení. ROI nám tedy slouží k odhadu návratnosti investic. Výsledné ROI se udává v procentech a jeho výpočet je následující:
 

č ý  čá čí    100 čá čí  

80

Při použití rozdělení dle ISACA [14] by ROI bylo následující:    ý ří   ý ří á !"#$  čá čí á !"#$  " %&íí  á !"#$  á !"#$ " % čí '!%#
 

 á !"#$ á !"#$

Výsledek nám pak určuje návratnost investice: •

ROI je menší než 100% - projekt vydělává, není-li hodnota záporná,

•

ROI je rovno 100% - projekt dosáhl bodu zlomu, tedy návratnosti investice,

•

ROI je vyšší než 100% - projekt je v zisku a investice je splacena.

Na jednoduchém příkladu si můžeme ukázat výpočet ROI: IT organizace provozuje úložiště dat s ročním ziskem 1 000 000 korun. Pokud bude provozovat servery ve vlastní infrastruktuře, její roční náklady budou činit 400 000 korun, pokud se rozhodne pro cloud, náklady budou činit 300 000 korun. Jaká investice je výhodnější. On-premise ROI = ((1000000-400000)/400000)x100 = 150% Cloud ROI = ((1000000-300000)/300000)x100 = 233% Ze zadání se nezdál rozdíl až takový, nicméně pokud se podíváme na výsledek, vidíme, že návratnost u obou řešení je hned v prvním roce provozu, zisk je u cloud řešení podstatně vyšší. Identifikace ROI je u cloud řešení často složitá. Reálné náklady a výnosy je nutné často identifikovat v několika rovinách a ty mezi sebou porovnávat. Často se totiž nejedná o přesun celé společnosti do nového prostředí. Přesunuty bývají aplikace, ve kterých je viděn potenciál úspory, stejně tak i služby. Přímé a nepřímé přínosy cloud computingu jsou ovlivněny několika klíčovými faktory: •

rychlost a míra změny – snížení nákladů na přijetí či odmítnutí je v cloud rychlejší než v on-premise, cloud navíc přináší výhody i v samotném procesu rozhodování, díky předpřipraveným službám, což značně redukuje čas potřebný na implementaci,

•

optimalizace TCO – uživatelé si mohou vybrat a sami nastavit podobu výsledné služby, mohou tak přímo ovlivnit náklady svým výběrem, tak aby splňoval požadavky v poměru cena/výkon, 81

•

rychlé přidělování kapacit – cloud je znám především možností škálovatelnosti, služby a tím i náklady lze optimálně měnit v závislosti na aktuální potřebě,

•

zvýšení obchodní marže a kontrola nad náklady – vyšší kontrola nákladů a pružná reakce na požadavky trhu, umožňuje i zvyšování zisků,

•

dynamické používání – elastické poskytování služeb umožňuje koncovým uživatelům optimální provoz aplikace a zároveň umožňuje definovat potřeby uživatelů,

•

optimální využití kapacit – přímý vliv na náklady má optimální využití strojového času a kapacit, cloud je schopen vyrovnat špičky, zároveň také umožňuje úsporu v době menšího užívání,

•

zlepšení podnikatelských dovedností a znalostí – cloud umožňuje přístup k novým zdrojům a řešením, která nám umožňují rozšířit služby i do dalších odvětví.

TCO - Total Cost Ownership Celkové náklady na vlastnictví, které zahrnují veškeré náklady na spuštění systému po celou dobu jeho životnosti a zároveň nám slouží jako nejlepší ukazatel pro porovnání nákladů na on-premise a cloud. TCO zahrnuje nejen poplatky, které zaplatíme poskytovatelům, ale i náklady na samotný provoz (zaměstnance, energie, …). Při prvním pohledu na cloud řešení a on-premise se nám může zdát, že on-premise je ekonomicky efektivnější. Například náklady na licence tvoří u on-premise cca 9% z celkových nákladů na IT. U cloud většinou bývají náklady na spuštění cca 68% z celkových IT nákladů. Pokud se však podíváme na všechny náklady z globálního hlediska a započteme i skryté náklady, pak začnou být výhody cloudu patrné. Co je však důležité si uvědomit je doba životnosti aplikace. S přibývajícími léty je u on-premise nutno počítat s výměnou hardware, a tím i nákupem nových licencí.

Obrázek 35 - Porovnání TCO u on-premise a cloud [32]

82

Jak je z obrázku patrné, u on-premise řešení jsou provozní náklady vyšší než u cloud řešení, kde jsou provozní náklady zanedbatelné. Pokud se na obrázek podíváme detailněji, je jasné, že náklady na cloud řešení budou prakticky konstantní oproti on-premise řešení. S nižšími celkovými náklady bude ROI vysoké a investice do cloud je často pouze zlomkem on-premise řešení. Pokud se vrátím k rozdělení nákladů na investiční a provozní, pak výpočet TCO by byl následující: ('  " á!é á !"#$  *í á !"#$ Při použití rozdělení dle ISACA [14] by pak výpočet byl následující: '!%# ('  čá čí á !"#$  " %&íí  á !"#$  á !"#$ " % čí Tabulka 3 - Porovnání nákladů variant on-premise a cloud

Počáteční náklady Dodatečné náklady

On-premise Softwarové licence Implementace Customizace Údržba Aktualizace softwaru Bezpečnost a integrita dat IT zdroje Školení

Cloud Aktivační poplatek Implementace Customizace Školení

TCO v cloudu je o porozumění investičním (kapitálovým) a provozním nákladům, tedy dokázat pohlédnout na celý životní cyklus nasazeného cloud řešení v delším časovém horizontu. Tyto náklady jsou vždy vyšší než počáteční náklady na pořízení. Abychom mohli lépe identifikovat jednotlivé položky nákladů a porovnat je s cloud řešením, je vhodné se řídit následujícími kategoriemi: 1. Fyzická datacentra a úložiště - Spadají sem náklady na hardware v celém časovém horizontu životnosti vybraného řešení. Tedy veškeré potřebné prvky k provozu (servery, disková pole, síťové prvky, kabeláž, …) s důrazem na možnost poruch, které lze vyvodit ze střední doby poruchy daného zařízení. 2. Softwarové licence - Veškeré počáteční náklady na licence, licence pro upgrade či aktualizace. Běžně bývá pod jedním produktem skryto velké množství dalších licencí (operační systémy, databáze, virtualizační nástroje, licence vzdálené plochy). Často se stává, že licence jsou naddimenzovány a nejsou ani plně využity. 3. Náklady na energie - Náklady na energie (elektřina, klimatizace,…) bývají často podceňovány, u větších data center mohou činit i 60% z celkových provozních nákladů. 83

Velice často se také stává, že náklady bývají vyšší díky předimenzovaným záložním zdrojům, klimatizačním jednotkám či příliš silným zdrojům serverů. 4. Údržba hardware a softwarová podpora - Často skrytým nákladem bývá softwarová podpora, která velice často činí cca 20% z ceny aplikace. Tato podpora se zpravidla platí na roční období, kdy je zajištěn buď přístup k potřebným zdrojům, či přímo pomoc ze strany dodavatele. Stejný problém činí i podpora hardware, záruky a často nesmyslné služby spojené s podporou. Se stářím hardware nutnost podpory roste a tím i rostou náklady. 5. Personál - Náklady na lidské zdroje činí obrovskou částku. O hardware i software je potřeba se starat, operačním systémy je nutné aktualizovat, chránit před viry. Síťové prvky a firewally je nutné neustále kontrolovat. 6. Zotavení po havárii a kontinuita podnikání - Havarijní plány, zálohy a zajištění udržení důležitých dat často skrývá nemalé částky. Zálohy bývají často předimenzovány díky paranoidním scénářům. Data jsou často zálohována zbytečně na několik míst, což přináší nutnost dalšího hardware a licencí.

5.3 Sestavení metodického rámce Stále větší množství organizací uvažuje nad přesunem vlastního portfolia aplikací do cloudu. Málokterá z nich má však předem stanovený plán jak tuto migraci provést. Následující body jsou odrazem toho, v jakém sledu by měli být jednotlivé kroky prováděny a u jakých klíčových faktorů je potřeba dbát zvýšené pozornosti. 1. Analýza potřeb – sestavení seznamu aplikací a jejich analýza V prvním kroku je nutné sestavit seznam všech používaných aplikací napříč organizací. Ke každé aplikaci je vhodné dohledat požadavky na licence, specifické požadavky na provoz a především souvislosti s dalšími aplikacemi. Takto sepsané aplikace se pokusíme spojit do organizačních celků, tedy např. aplikace pro podporu obchodu, kam bychom mohli zařadit CRM, účetní aplikace,… Díky tomuto rozdělení snadno identifikujeme podpůrné aplikace a aplikace, které již nebudou v cloud prostředí potřeba. 2. Bezpečnost – požadavky na bezpečnost a vykrytí špiček užívání Během této fáze je nutné identifikovat bezpečnostní požadavky aplikací, jejich zabezpečení a mechanismy ochrany před neoprávněným přístupem. Zároveň je třeba identifikovat potenciální slabá místa, zda je aplikace připravena na útoky. Na co se nesmí 84

zapomenout je chování aplikace v době špiček. U účetních aplikací to mohou být období uzávěrek, fakturací atp. 3. Výběr aplikací vhodných pro cloud Cloud je v dnešní době pro každého, ale to samé neplatí pro aplikace, ne každá aplikace je vhodná pro cloud. Aplikace s nižším zabezpečením, či aplikace, které vyžadují specifický hardware, nejsou vhodné pro umístění do cloudu. Tak abychom dokázali tyto aplikace identifikovat, je vhodné sestavit následující tabulku. Tabulka 4 - Rekapitulace software a vhodnost pro cloud

Použitelnost pro cloud Název

Účel

Oddělení

Bezpečnost

Nárůst/špičky Nyní

CRM

Efektivita prodeje

Obchod/IT

střední

20% ročně

x

E-mail

Email zaměstnanců

IT

nízká

50% ročně

x

E-obchod

Prodej produktů

Obchod

vysoká

25% ročně na vánoce

ERP

Účetnictví

Finance

vysoká

10% ročně

Později

Nikdy

x x

4. Volba vhodného cloudu Po upřesnění požadavků aplikací lze rozhodnout jaký cloud bude pro danou aplikaci potřeba. Kritériem bývá bezpečnost a zaměření aplikace, je jasné, že např. účetnictví bychom si neumístili do veřejného cloudu, email naopak rádi využijeme kdekoliv na světě. Aplikace tedy umístíme do privátního nebo veřejného či hybridního cloudu. 5. Porovnání a potvrzení přesunu Strategický management či vedení společnosti dostane veškeré podklady a rozhodne, zda bude proveden přesun či ne. Klíčovými faktory zde jsou úspora nákladů a zvýšení efektivity práce. 6. Průzkum trhu Oslovení poskytovatelů cloud řešení. Poslání specifických požadavků a vyžádání nabídky od poskytovatele. 7. Výběr vhodného kandidáta Prozkoumání nabídek a výběr vhodného kandidáta. Jak již bylo zmíněno v této práci, klíčovým faktory není pouze cena, ale i reputace partnera a geografické položení. Technické

85

podmínky nemusím již zmiňovat, již samotný výběr a oslovení potenciálních partnerů muselo splňovat naše podmínky. 8. Navázání spolupráce s vybraným kandidátem Akceptace poskytnuté nabídky, podpis potřebných smluv. Jak by měl vhodný partner vypadat: • • • • • • • •

flexibilní řešení, otevřená architektura cloudu, dostatek potřebných nástrojů, možnost plánovat a spouštět privátní, veřejné a hybridní cloudy, robustní síťové řešení, připravenost na možné síťové špičky, přidaná hodnota v podobě dodatkových služeb, podpora dostupná 24/7 po celý rok, podpora většiny moderních standardů a operačních systémů, kladné hodnocení ostatními uživateli (reference).

9. Spuštění trial verze pro testování Možnost spuštění trial verze, která nám umožní otestovat funkcionalitu a dostupné nástroje. 10. Spuštění aplikací do ostrého provozu a monitoring Pokud jsme s trial testováním spokojeni, můžeme aplikaci spustit v reálném režimu. Partner by měl poskytnout služby spojené s monitoringem provozu a podporou. IT by mělo pravidelně sledovat požadavky aplikace na zdroje a tím optimálně nastavovat cloud prostředí. Optimální nastavení a plné využití elasticity nám umožňuje efektivně využít zdroje a provést úsporu nákladů.

5.4 Rizika přesunu Rizika mají být eliminována kvalitním plánem přesunu a správným výběrem poskytovatele. Nicméně často se stává, že nesprávnou kontrolou či opomenutím dochází k problémům. Nejčastější případy rizik jsou zapříčiněny: •

nesprávně nastavená SLA smlouva, zejména špatné ošetření dostupnosti služby,

•

nečekané změny hardware, které způsobí kolizi,

•

neznalost národních zákonů může přinášet potíže v případě zakázaného obsahu dané země,

•

uzavřená architektura, nelze pružně reagovat a vyvíjet optimalizované řešení, 86

•

špatně zvolené limity, nesprávně nastavená služba způsobující výpadky a nedostatečný výkon.

5.5 Porovnání TCO on-premise a cloud (SaaS) Genius Project Pro porovnání jsem použil již zmíněný produkt Genius Project. Genius Project je zástupcem softwaru pro projektové řízení, v posledních letech se pravidelně umístil mezi top 10 aplikacemi pro podporu projektového řízení, v žebříčku TopTen Reviews [46]. Genius Project poskytuje on-premise i SaaS řešení, pro naše porovnání použijeme modelovou situaci menší konzultační společnosti o celkovém počtu 50 zaměstnanců, vedení společnosti nebudeme do našeho modelu započítávat a k přístupu do systému jim postačí role projektového manažera, která je prakticky na nejvyšší úrovni. Strukturu společnosti bude tvořit 10 projektových manažerů, kteří jsou dle požadavků alokováni k danému projektu a 35 dalších pracovníků, kteří mohou být tvořeni specialisty pro danou oblast a na projektu se podílí jako členové týmu. Budeme předpokládat, že společnost bude současně moci pracovat až na 5 ti projektech současně, proto zvolíme licence pro 5 vlastníků projektu (stakeholderů).

Požadavky na licence budou tedy následující: 5 stakeholder licencí 10 licencí pro projektového manažera 35 licencí pro členy projektového týmu

On-premise řešení Budeme vycházet z předpokladu, že licence bude pořizována na období 3 let, kdy pravidelně dochází ke změně hardware serveru a novému přepočtu nákladů. V případě onpremise řešení, tedy umístěného řešení na straně zákazníka je počítat s následujícími náklady, které si rozdělíme na investiční (CapEx24) náklady a provozní (OpEx25) náklady. CapEx náklady Náklady na hardware serveru, kdy jsem vycházel z doporučené konfigurace serveru pro Genius Project, budou činit 58300 Kč (aktuální cena ke dni 10.3.2014). Server Dell PowerEdge R320 E5

24 25

CapEx – Capital Expenditure – kapitálové - investiční náklady OpEx – Operating Expense – operační – provozní náklady

87

Procesor: Intel Xeon E5-2403 1.80GHz Paměť RAM: 16GB Úložiště: 3x1TB SAS (uspořádány do RAID 5) Napájení: Redundantní hotplug 2x350W Operační systém zvolen Ubuntu Linux LTS26, šířen jako Open Source Náklady na licence (aktuální přepočet z USD ke dni 10.3.2014): Licence za serverovou instanci 88792 Kč Licence pro stakeholdera 2960Kč, cena za 5 licencí činí 14800Kč Licence pro projektového manažera 25621Kč, cena za 10 licencí činí 256210Kč Licence pro člena týmu 10854Kč, cena za 35 licencí činí 379890Kč Cena licence helpdesk modulu činí 69063Kč Cena licence za modul pro podporu agilních metodik činí 59197Kč Cena implementace aplikace, zaškolení a společné první kroky v aplikaci (zahrnující 16dnů spolupráce) činí 536699Kč. Celkové investiční náklady v prvním roce činí 1462951Kč. OpEx náklady Náklady na roční podporu aplikace činí 108523Kč Roční maintenance poplatek zahrnující aktualizace a opravy chyb aplikace ve výši 20% z ceny licencí 180342Kč. Roční maintenance hardware 5% ve výši 2915Kč ročně. Vybraný server dle výrobce spotřebovává v průměru 225W elektrické energie [18], při aktuální ceně elektrické energie 4,50Kč za kWh dle serveru [50] vychází roční náklady 8870Kč za server a 13304Kč ročně za přidružená zařízení (chlazení, UPS, PDU, chiller,…) a ztráty. Roční náklady na internetové připojení činí 48000Kč. Společnost bude zaměstnávat dva IT specialisty, z čehož jeden bude mít na starosti operační systém a hardware serveru, druhý bude mít na starosti administraci aplikace. Průměrný plat IT specialisty dle serveru [39] činní 45000Kč měsíčně hrubé mzdy, náklady zaměstnavatele tak činí 60300Kč měsíčně na každého zaměstnance. Celkové provozní náklady v prvním roce činí 1809153Kč.

26

LTS – Long Term Support – podpora v delším časovém horizontu, u Ubuntu Server produktů zpravidla 5 let

88

Cloud (SaaS) řešení Stejně jako u on-premise řešení budeme počítat s předplatným na 3 roky. Jelikož se jedná o nové řešení na tzv. „zelené louce“ a pro lepší názornost a možnost porovnání, budeme počítat pouze s CAPEX (investičními) a OPEX (provozními) náklady. Náklady na ukončení tedy zcela vynecháme. Jak již bylo řečeno v předchozích kapitolách, cílem cloud je přenést investiční náklady do provozních, což je vidět i na následujícím rozpisu nákladů. CapEx náklady SaaS řešení nemá žádné investiční náklady, mezi jediné náklady patří školení zaměstnanců, naplnění dat a implementace ve výši 536699Kč. Tyto náklady budou pouze v prvním roce. OpEx náklady Jak již bylo řečeno cloud přesouvá investiční náklady do provozních a namísto pořizovací ceny licence se platba provádí v časových intervalech za každého uživatele. Náklady na pronájem licencí (aktuální přepočet z USD ke dni 10.3.2014): Licence stakeholdera 157Kč, pro 5 uživatelů 785Kč za měsíc, 9420Kč za rok. Licence projektového manažera 689Kč, pro 10 uživatelů 6890Kč za měsíc, 82680Kč za rok. Licence člena týmu 532Kč, pro 35 uživatelů 18620Kč za měsíc, 223440Kč za rok. Cena roční podpory činí 108523Kč. Náklady na zaměstnance činí 723600Kč ročně, oproti on-premise dochází k úspoře za jednoho zaměstnance, který by měl na starost provoz serveru a údržbu middleware. Cena za internetové připojení činí 24000Kč ročně, zde dochází k úspoře za potřebnou vyšší rychlost uplink. Celkové roční provozní náklady činí 1171663Kč.

Porovnání nákladů SaaS a On-premise Z výše zmíněných nákladů na obě varianty vychází SaaS výhodněji nejen v prvním roce, ale i v dalších letech. Náklady obou variant v průběhu tří let jsou popsány v následujících tabulkách a znázorněny v grafu.

89

Tabulka 5 - Total Cost Ownership u on-premise za 3 roky v CZK

1.rok Název položky

Počet Kus

Licence aplikace (server)

CAPEX

2.rok

OPEX

3.rok

CAPEX OPEX

CAPEX OPEX

1

88792

88792

0

0

0

0

0

5

2960

14800

0

0

0

0

0

10

25621

256210

0

0

0

0

0

35

10854

379890

0

0

0

0

0

Helpdesk modul

1

69063

69063

0

0

0

0

0

Modul podpory agilních metodik

1

59197

59197

0

0

0

0

0

Implementace, naplnění a školení

1

536699

536699

0

0

0

0

0

1

108523

0

108523

0

108523

0

108523

Maintenance 20% z licencí

1 180341,8

0

180342

0

180342

0

180342

Hardware serveru

1

58300

58300

0

0

0

0

Maintenance 5% z ceny hardware

1

2915

0

0

2915

0

2915

Náklady na zaměstnance

2

60300

0 1447200

0 1447200

0 1447200

1

8869,5

0

8869,5

0

8869,5

0

8869,5

Elektřina - ztráty, UPS, chlazení,…

1

13304

0

13304

0

13304

0

13304

Internetové připojení měsíční poplatek

1

4000

0

48000

0

48000

0

48000

Stakeholder (licence)

nákup licence

Project manager (licence) nákup licence Team member (licence)

Softwarová podpora

nákup licence

roční poplatek

Elektřina - server (225W)

roční poplatek

Celkem

2915

1462951 1809153

0 1809153

0 1809153

3272104

1809153

1809153

Celkem CAPEX+OPEX

Tabulka 6 - Total Cost Ownership u SaaS za 3 roky v CZK

1. rok Název položky

Počet Kus

Licence aplikace (server)

CAPEX

2. rok

OPEX

3. rok

CAPEX OPEX

CAPEX OPEX

0

0

0

0

0

0

0

0

5

157

0

9420

0

9420

0

9420

10

689

0

82680

0

82680

0

82680

35

532

0

223440

0

223440

0

223440

Helpdesk modul

0

0

0

0

0

0

0

0

Modul podpory agilních metodik

0

0

0

0

0

0

0

0

Implementace, naplnění a školení

1 536699 536699

0

0

0

0

0

Stakeholder (licence)

měsíční poplatek

Project manager (licence) Team member (licence)

Softwarová podpora -

měsíční poplatek

měsíční poplatek

roční poplatek

1 108523

0

108523

0

108523

0

108523

Maintenance 20% z licencí

0

0

0

0

0

0

0

0

Hardware serveru

0

0

0

0

0

0

0

0

Maintenance 5% z ceny hardware

0

0

0

0

0

0

0

0

Náklady na zaměstnance

0

60300

0

723600

0

723600

0

723600

0

0

0

0

0

0

0

0

Elektřina - ztráty, UPS, chlazení,..

0

0

0

0

0

0

0

0

měsíční poplatek

1

2000

0

24000

0

24000

0

24000

536699 1171663

0 1171663

0

1171663

1708362

1171663

Elektřina - server (225W) Internetové připojení Celkem

roční poplatek

Celkem CAPEX+OPEX

90

1171663

Porovnání nákladů SaaS a On-premise On premise 3,500,000.00 Kč 3,000,000.00 Kč 2,500,000.00 Kč 2,000,000.00 Kč 1,500,000.00 Kč 1,000,000.00 Kč 500,000.00 Kč 0.00 Kč SaaS 1.rok

On-premise On 1.rok

SaaS 2.rok

On-premise premise 2.rok

SaaS 3.rok

On-premise On 3.rok

Obrázek 36 - Graf porovnání TCO u on-premise on premise a cloud (SaaS)

ZÁVĚR Cílem této práce bylo přiblížit dva různé světy a ukázat možnost jak využít toho nejlepšího z obou. V diplomové práci jsem tedy zmínil nejen samotné zástupce z obou stran metodik projektového řízení, řízení kde důležitým d kritériem bylo objasnění, který ze zástupců metodik poskytuj uživateli co nejméně administrativní zátěže a co možná nejefektivnější cestu ke poskytuje zdárnému cíli projektu. V tomto případě jsem jasně zmínil výhody agilní agilních metodik, které vidím jako opravdu jednu z nejlepších cest budoucnosti. budoucnosti V dalších kapitolách jsem si dal za cíl zmínit aktuální varianty a kritéria softwarových nástrojů pro podporu pprojektového rojektového managementu i s popisem vybraného zástupce, který je následně použit i v závěrečném porovnání. Tak abych mohl naplnit cíl práce, bylo zároveň nutné přiblížit modely poskytování porovnání. IT služeb a provést rozdělení na tradiční používané on-premise premise řeše řešeníí a nové možnosti v podobě cloud computingu a jeho jednotlivých modelů. modelů. Společně s novými modely bylo nutné zmínit i nutné právní způsoby ochrany obchodních vztahů mezi poskytovatelem a zákazníkem, jež plynou z nového způsobu poskytování samotných služeb zákazníkem, služeb. Další kapitola pak měla přiblížit, jak se navzájem ovlivňují metodiky projektového řízení a cloud. Závěrem této kapitoly bylo pozitivní zjištění, jak cloud a agilní metodiky mají společné jmenovatele v podobě zvýšení efektivity a snížení nákladů. Ve Ve spojení spoje pak činí samotný cloud efektivnější a naopak použitím cloudu dochází k akceleraci samotných agilních procesů. Závěrečná kapitola byla věnována samotnému aspektu přesunu do cloud prostředí, kdy jsem vypíchl 91

nejdůležitější kritéria samotného přechodu, upozornil na rizika a navrhl metodický rámec přesunu do cloudu v podobě jednotlivých kroků, které nelze opomenout. Tak abych mohl svá tvrzení podložit, použil jsem reálná čísla z ceníku poskytovatele softwaru pro projektový management, kde jsem provedl srovnání tradičního on-premise řešení s cloud řešením, jehož závěrem bylo obhájení vyšší efektivity v redukci nákladů. Závěrem této práce mohu potvrdit, že cloud přináší nejen zmíněné technické výhody, ale zároveň dokáže plně využít moderních agilních metodik projektového managementu a ve spojení s nimi nejen těžit z efektivního využití nástrojů, ale akcelerovat i samotné metodiky a tím i samotný projektový management. Všechny cíle, které jsem si v této práci vytyčil, tedy považuji za splněné a praktický příklad lze považovat za vhodné doporučení pro samotné využití v praxi.

92

Seznam použité literatury [01] BECK, Kent. Extreme programming eXplained: embrace change. Reading, MA: Addison-Wesley, 2000, xxi, 190 p. ISBN 02-016-1641-6. [02] KADLEC, Václav. Agilní programování: metodiky efektivního vývoje softwaru. 1. vyd. Brno: Computer Press, 2004, 278 s. ISBN 80-251-0342-0. [03] LEFFINGWELL, Dean. Agile software requirements: lean requirements practices for teams, programs, and the enterprise. Upper Saddle River, NJ: Addison-Wesley, c2011, xxxv, 518 p. Agile software development series. ISBN 03-216-3584-1. [04] LINTHICUM, David S. Cloud computing and SOA convergence in your enterprise: a step-by-step guide. Upper Saddle River: Addison-Wesley, 2010, xxiv, 239 s. AddisonWesley information technology series. ISBN 978-0-13-600922-1. [05] POPPENDIECK, Mary a Tom POPPENDIECK. Lean software development: an agile toolkit. 10. print. Boston: Addison-Wesley, 2006. ISBN 03-211-5078-3. [06] SCHWABER, Ken. Agile project management with Scrum. Redmond, Wash.: Microsoft Press, c2004, xix, 163 p. ISBN 07-356-1993-X.

Periodikum [07] Communications of the ACM: a monthly publication of the ACM Publications Office. New York: Association for Computing Machinery,. ISBN 0001-0782.

Elektronická akademická práce [08] ALDORF, Filip. Metodika RUP [online]. Praha, 2005 [cit. 2013-12-23]. Dostupné z: http://objekty.vse.cz/Objekty/Rup2. Diplomová práce. VŠE.

Internetové zdroje [09] AMBLER, Scott. Architecture and Architecture Modeling Techniques. Agile Data [online]. 2002 [cit. 2013-12-5]. Dostupné z: http://www.agiledata.org/essays/enterpriseArchitectureTechniques.html [10] An Agile Approach to CRM. CRM Online [online]. [cit. 2013-12-26]. Dostupné z: http://www.crmonline.com.au/our-services/why-choose-crm-online/our-approach/ [11] ASHAR, Kunal. The Next Generation Enterprise: Business as a Service in the Cloud. In: Blue Atoll [online]. 2013 [cit. 2014-01-30]. Dostupné z: http://blueatoll.com/blog/the-next-generation-enterprise-business-as-a-service-in-thecloud/ 93

[12] BECK, Kent. Manifest Agilního vývoje software. Manifesto for Agile Software Development [online]. 2001 [cit. 2013-12-7]. Dostupné z: http://agilemanifesto.org/iso/cs/ [13] BUCHALCEVOVÁ, Alena. Agilní a rigorózní metodiky. Metodiky budování informačních systémů. In: Materiály k předmětům VŠE [online]. Praha, 2002 [cit. 201312-05]. Dostupné z: http://nb.vse.cz/~vorisek/FILES/4IT215_materialy_k_predmetu/MetodikyIT_Buchalcev ova.ppt [14] Calculating Cloud ROI: From the Customer Perspective. In: ISACA [online]. 2012 [cit. 2014-03-25]. Dostupné z: http://www.isaca.org/KnowledgeCenter/Research/ResearchDeliverables/Pages/Calculating-Cloud-ROI-From-theCustomer-Perspective.aspx [15] Cloud Service Assurance for VMDC Design Guide. In: Cisco Systems [online]. 2013 [cit. 2014-02-03]. Dostupné z: http://www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/VMDC/CLSA/Abr idged_DIG/CLSA_Abridged.pdf [16] COLUMBUS, Louis. First Steps to Creating a Cloud Computing Strategy for 2013. In: Forbes [online]. 2012 [cit. 2014-03-30]. Dostupné z: http://www.forbes.com/sites/louiscolumbus/2012/12/18/first-steps-to-creating-a-cloudcomputing-strategy-for-2013/ [17] COLUMBUS, Louis. Gartner Predicts Infrastructure Services Will Accelerate Cloud Computing Growth. In: Business2Community [online]. 2013 [cit. 2014-01-30]. Dostupné z: http://www.business2community.com/cloud-computing/gartner-predictsinfrastructure-services-will-accelerate-cloud-computing-growth-0412261#!EpeJF [18] Dell Energy Smart Solution Advisor. DELL. Dell Official Site - The Power To Do More [online]. 2014 [cit. 2014-03-10]. Dostupné z: http://essa.us.dell.com/DellStarOnline/DCCP.aspx?c=us&l=en&s=corp&Template=694 5c07e-3be7-47aa-b318-18f9052df893 [19] Dev Corner – Software Development Methodology. In: TechSmith Blogs [online]. 2011 [cit. 2014-03-01]. Dostupné z: http://blogs.techsmith.com/inside-techsmith/dev-cornersoftware-developm/#.UxNEeGeYbIU [20] Enterprise Unified Process (EUP): Strategies for Enterprise Agile. Enterprise Unified Process [online]. [cit. 2013-12-23]. Dostupné z: http://enterpriseunifiedprocess.com/

94

[21] Eurocloud. EUROCLOUD EUROPE. Eurocloud [online]. [cit. 2014-02-03]. Dostupné z: http://www.eurocloud.org/ [22] Genius Project Features. GENIUS INSIDE. Project Management Software - Genius Project [online]. [cit. 2014-01-30]. Dostupné z: http://www.geniusproject.com/features [23] HAMOND, Teena. Research: 67 percent report budget reduction with IaaS implementation. In: ZDNet: Between the Lines [online]. 2013 [cit. 2014-01-30]. Dostupné z: http://www.zdnet.com/research-67-percent-report-budget-reduction-withiaas-implementation-7000020231/ [24] HAMOND, Teena. Research: 96% say IaaS meets expectations. In: ZDNet: Between the Lines [online]. 2013 [cit. 2014-01-31]. Dostupné z: http://www.zdnet.com/research-96say-iaas-meets-expectations-7000013359/ [25] ICB: IPMA Competence Baseline. INTERNATIONAL PROJECT MANAGEMENT ASSOCIATION. IPMA [online]. [cit. 2013-12-23]. Dostupné z: http://ipma.ch/resources/ipma-publications/ipma-competence-baseline/ [26] ISO 10006. In: Sociální síť pro business: ManagementMania.com [online]. 2013 [cit. 2013-12-23]. Dostupné z: https://managementmania.com/cs/iso-10006 [27] ISO 21500. In: Sociální síť pro business: ManagementMania.com [online]. 2013 [cit. 2013-12-23]. Dostupné z: https://managementmania.com/cs/iso-21500 [28] KOMOROV, Gilad. Moving a traditional software on-demand company to the SaaS business model. In: Kampyle SaaS Business Forum [online]. 2012 [cit. 2014-01-30]. Dostupné z: http://saas.kampyle.com/2012/12/31/moving-a-traditional-software-ondemand-company-to-the-saas-business-model/ [29] LASZEWSKI, Tom a NAUDURI. Migrating to the Cloud. In: Oracle [online]. Waltham, 2012 [cit. 2014-03-10]. Dostupné z: http://www.oracle.com/technetwork/articles/cloudcomp/migrating-to-the-cloud-chap-3495856.pdf [30] Lean manufacturing. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2003-04-29 [cit. 2013-12-9]. Dostupné z: http://en.wikipedia.org/wiki/Lean_manufacturing [31] Magic Quadrant Research Methodology. GARTNER INC. Gartner: Technology Research [online]. [cit. 2014-01-20]. Dostupné z: http://www.gartner.com/technology/research/methodologies/research_mq.jsp [32] MAHONEY, Shereen. The Economics of Using Cloud Accounting Systems. In: Brittenford Systems [online]. 2013 [cit. 2014-03-10]. Dostupné z: 95

http://www.brittenford.com/2013/12/the-economics-of-using-cloud-accountingsystems/#.UxsWDPl5NsU [33] MarketScope Research Methodology. GARTNER INC. Gartner: Technology Research [online]. [cit. 2014-01-24]. Dostupné z: http://www.gartner.com/technology/research/methodologies/research_markets.jsp [34] MELL, Peter a Timothy GRACE. The NIST Definition of Cloud Computing. In: National Institute of Standards and Technology [online]. Special Publication 800-145. Gaithersburg, 2011 [cit. 2013-12-19]. Dostupné z: http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf [35] MURPHY, Thomas, Jim DUGGAN, David NORTON, Brian PRENTICE, Daryl PLUMMER a Susan LANDRY. Predicts 2010: Agile and Cloud Impact Application. In: Gartner Research [online]. 2009 [cit. 2014-03-01]. G00172203. Dostupné z: http://www.iqtechpros.com/KnowledgeBase/Agile_and_Cloud_Impact_Application_De velopment.pdf [36] New study from Capgemini identifies cloud-based and agile testing as the key trends. In: LEROUGE, Christel a Therese SINTER. Sogeti Study [online]. Paris: Capgemini Press, Sogeti Press, 2010 [cit. 2014-03-01]. Dostupné z: http://www.sogeti.com/upload/COM/News/Documents/Global/06_16_WQR_release_FI NAL.pdf [37] Object-oriented Process, Environment and Notation. OPEN. The OPEN website [online]. [cit. 2013-12-23]. Dostupné z: http://www.open.org.au [38] Platform as a Service Overview (PaaS). In: Colo & Cloud [online]. [cit. 2014-01-30]. Dostupné z: http://www.coloandcloud.com/editorial/platform-as-a-service-overviewpaas/ [39] Porovnejte svůj plat. Průzkum platů [online]. 2014 [cit. 2014-03-10]. Dostupné z: http://www.platy.cz [40] Project Management Capability Maturity Model. PMIS CONSULTING LTD. Project Management Maturity Consultancy [online]. [cit. 2013-12-6]. Dostupné z: http://www.pmis.co.uk/project-management-consulting-cmm.htm [41] Public Cloud vs Private Cloud. SKALI NET [online]. [cit. 2014-01-30]. Dostupné z: http://www.skali.net/public-cloud-vs-private-cloud [42] Rational Unified Process: Best Practices for Software Development Teams. In: Rational the Software Development Company [online]. 2001 [cit. 2014-04-16]. TP026B, Rev 11/01. Dostupné z: 96

http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_b estpractices_TP026B.pdf [43] SLA smlouva. TOTAL SERVICE S.R.O. [online]. [cit. 2014-02-03]. Dostupné z: http://www.totalservice.cz/cesky/sluzby-a-reseni/ICT-Outsourcing/service-level.html [44] STANG, Daniel a Robert HANDLER. Magic Quadrant for Cloud-Based IT Project and Portfolio Management Services. GARTNER INC. Gartner: Technology Research [online]. 2013 [cit. 2014-01-24]. Dostupné z: http://www.gartner.com/technology/reprints.do?id=1-1FPSB22&ct=130520&st=sb [45] STANG, Daniel a Robert HANDLER. MarketScope for IT Project and Portfolio Management Software Applications. GARTNER INC. Gartner: Technology Research [online]. 2013 [cit. 2014-01-24]. Dostupné z: http://www.gartner.com/technology/reprints.do?id=1-1FNHA47&ct=130515&st=sb [46] STEVENS, Pamela. Online Project Management Review. In: TopTenREVIEWS [online]. 2014 [cit. 2014-03-10]. Dostupné z: http://online-project-managementreview.toptenreviews.com/ [47] The principles of KANBAN method. DAVID J ANDERSON & ASSOCIATES, Inc. DJA [online]. 2010 [cit. 2013-12-26]. Dostupné z: http://www.djaa.com/principleskanban-method [48] Transfer of undertakings (TUPE). In: ACAS [online]. 2014 [cit. 2014-03-10]. Dostupné z: http://www.acas.org.uk/index.aspx?articleid=1655 [49] VERHEYEN, Gunther. The process of ScrumPlus. In: MS Community blog [online]. Belgie, 2010 [cit. 2013-12-27]. Dostupné z: http://mscop.be.capgemini.com/2010/07/15/the-process-of-scrumplus/ [50] Výpočet spotřeby elektrické energie. Vypočítej to: Spotřeba elektřiny [online]. 2014 [cit. 2014-03-10]. Dostupné z: http://www.vypocitejto.cz/energie/spotrebaelektriny.html [51] Waterfall versus Agile – comparing software development methodologies. In: LeaseWeb Labs [online]. 2014 [cit. 2014-02-5]. Dostupné z: http://www.leaseweblabs.com/2014/01/waterfall-versus-agile-comparing-softwaredevelopment-methodologies/ [52] White Paper: "Hybrid Clouds-The Best of Both Worlds". NSK INC. IT Consultants' Insight on Business and Technology [online]. [cit. 2014-02-02]. Dostupné z: http://blog.nskinc.com/hybrid-clouds-the-best-of-both-worlds/

97

[53] World Quality Report Reveals Increasing Cloud Adoption is Fuelling Demand for Application Testing* and Quality Assurance**. In: Capgemini India [online]. 2011 [cit. 2014-03-02]. Dostupné z: http://www.in.capgemini.com/news/world-quality-reportreveals-increasing-cloud-adoption-is-fuelling-demand-for-application-testing-andquality-assurance

Seznam obrázků a tabulek Tabulka 1 - Porovnání rigorózních a agilních metodik [13] Tabulka 2 - Srovnání rigorózních a agilních metodik [51] Tabulka 3 - Porovnání nákladů variant on-premise a cloud Tabulka 4 - Rekapitulace software a vhodnost pro cloud Tabulka 5 - Total Cost Ownership u on-premise za 3 roky v CZK Tabulka 6 - Total Cost Ownership u SaaS za 3 roky v CZK Obrázek 1- IPMA ICB competence eye (oko kompetencí) [25] Obrázek 2 - Popis projektu dle metodiky RUP [08] Obrázek 3 - Iterativní vývoj [08] Obrázek 4 - Enterprise Unified Process [20] Obrázek 5 - Agilní vývoj [10] Obrázek 6 - Fáze SCRUM projektu [49] Obrázek 7 - Kanban vizualizace pracovního postupu [Zdroj: vlastní] Obrázek 8 - Znázornění nastavení WIP limitů [Zdroj: vlastní] Obrázek 9 - Kanban – určování priorit [Zdroj: vlastní] Obrázek 10 - Železný trojúhelník - Srovnání agilních a rigorózních metodik [51] Obrázek 11 - Gartner Magic Quadrant [31] Obrázek 12 - Gartner Magic Quadrant for Cloud-Based Project and Protfolio Management Services [44] Obrázek 13 - Gartner MarketScope [33] Obrázek 14 - Gartner MarketScope pro PPM 2013 [45] Obrázek 15 - Genius Project poskytuje možnost spolupráce s produkty třetích stran [22] Obrázek 16 - Genius Project - Řízení a plánování [22] Obrázek 17 - Genius Project - Týmové nástroje [22] Obrázek 18 - Genius Project - Podpora byznys procesů [22] Obrázek 19 - Genius Project - Řízení workflow [22] 98

Obrázek 20 - Genius Project - Podpora agilních metodik [22] Obrázek 21 - Vývoj IT outsourcingu [Zdroj: vlastní] Obrázek 22 - Cloud computing [Zdroj: vlastní] Obrázek 23 – Vývoj cloud computingu [11] Obrázek 24 - Graf analytické společnosti Gartner ukazující nárůst poskytování cloud služeb [17] Obrázek 25 - Srovnání vývoje jednotlivých variant poskytování služeb [Zdroj: vlastní] Obrázek 26 - Předpokládaný vývoj IaaS na základě průzkumu společnosti Tech Pro Research z roku 2013 [23] Obrázek 27 - Schéma PaaS distribučního modelu [38] Obrázek 28 - Nárůst SaaS očekává, že 85% aplikací bude v roce 2015 dodáváno jako služba [28] Obrázek 29 - Byznys jako služba [Zdroj: vlastní] Obrázek 30 - Procentuální zastoupení jednotlivých cloud modelů [24] Obrázek 31 - Veřejný vs Privátní cloud [41] Obrázek 32 - Hybridní cloud [52] Obrázek 33 - Metodika SLA pro zajištění cloud služeb společnosti Cisco [15] Obrázek 34 - Vývoj metodik [19] Obrázek 35 - Porovnání TCO u on-premise a cloud [32] Obrázek 36 - Graf porovnání TCO u on-premise a cloud (SaaS)

99