Metodiky projektového riadenia a ich implementácia v praxi

Transcription

1 Bankovní institut vysoká škola Praha Katedra matematiky, štatistiky a informačných technológií Metodiky projektového riadenia a ich implementácia v praxi Diplomová práca Autor: Bc. Patrik Charous Informačné technológie a management Vedúci práce: Ing. Václav Šebek, CSc. Praha Apríl 2014

2 Prehlásenie: Prehlasujem, ţe som diplomovú prácu vypracoval samostatne a v zozname uviedol všetku pouţitú literatúru. Svojim podpisom potvrdzujem, ţe odovzdaná elektronická podoba práce je identická s jej tlačenou verziou, a som oboznámený so skutočnosťou, ţe sa práca bude archivovať v kniţnici BIVŠ a ďalej bude sprístupnená tretím osobám prostredníctvom internej databázy elektronických vysokoškolských prác.... V Prahe dňa Bc. Patrik Charous

3 Poďakovanie: Na tomto mieste chcem poďakovať môjmu vedúcemu diplomovej práce Ing. Václavovi Šebkovi, CSc. za jeho čas, usmernenia, cenné rady, ústretovosť a pochopenie pri dlhom procese písania tejto práce. Vďaka patrí aj môjmu výbornému kamarátovi a partnerovi v spoločnosti PURE IDEAS s.r.o. Jakubovi Chládkovi, za jeho podnetné nápady a večné diskusie pri zakladaní firmy a navrhovaní spôsobu jej fungovania. V neposlednej rade chcem poďakovať mojej rodine, hlavne rodičom Ing. Vladimíre a Ivanovi Charousovým a priateľke Mgr. Šárke Balounovej, ktorý ma trpezlivo a neúnavne podporovali počas celých mojich štúdií, počas písania tejto práce i pri všetkých vrcholoch a pádoch či uţ v osobnom, študijnom, alebo pracovnom ţivote. Takisto mojmu strýkovi Doc.Ing. Milanovi Kovačkovi, CSc., ktorý ma odmalička učil ku kritickému a komplexnému mysleniu.

4 Anotácia Diplomová práca spracováva problematiku projektového riadenia, ktorá sa v poslednej dobe javí ako kritická pre mnoho organizácií. Zameriava sa pritom na riadenie softwarových projektov, konkrétne na riadenie webových projektov. Popisuje základné pojmy projektového riadenia a najznámejšie metodiky vývoja software a projektového riadenia. V praktickej časti je popísaná konkrétna firma, identifikované skupiny projektov a navrhnutý spôsob riadenia pre danú skupinu projektov, predvedený na pilotonom projekte. Kľúčové slová: projekt, projektové riadenie, metodika, vývoj software, tradičné metodiky, agilné metodiky, Scrum, Feature driven development, Lean development, PRINCE2, PMBOK Annotation Final thesis deals with the topic of project management which has recently appeared like an essential topic for many organizations. It is aimed at management of software projects specifically for managing of web projects. In the thesis basic concepts of project management and the best known methodics of software development and project management are described in detail. The practical part contains a description of a specific company, identified groups of projects and suggested way of management for that group of projects performed on a pilot project. Key words: project, project management, methodologies, software development, traditional methodologies, agile methodologies, Scrum, Feature Driven Development, Lean Development, PRINCE2, PMBOK

5 Obsah Úvod... 8 Dosiahnutý stupeň poznania... 9 Metódy spracovania práce Základné pojmy Projekt Webový projekt Startup Projektové riadenie Projektové riadenie webových projektov Metodika Metódy Kľúčové zistenia o projektoch a odporučenia Zloţitosť vývoja software Najčastejšie príčiny zlyhania IT projektov Najväčšie výzvy v riadení webových projektov Metodiky obecne a ich kritéria rozdelenia Kritéria metodík Metodiky vývoja software Tradičné metodiky vývoja software Vodopádový model Spiralový model Rational Unied Process (RUP) Agilné metodiky vývoja software Rozdiel medzi agilným a tradičným prístupom Manifest agilného programovania Prehľad agilných metodík Scrum Role

6 4.5.2 Artefakty Scrumu Priebeh Zhodnotenie Feature Driven Development Praktiky Role Procesy Metodiky projektového riadenia PRINCE PMBOK Slobodná firma Princípy slobody v práci Popis vybranej firmy Predmet podnikania Analýza stávajúceho stavu riadenia projektov Návrhy pre oblasť riadenia projektov Ciele zavedenia metodiky projektového riadenia Skupiny projektov Malé projekty - parametrizované webové projekty Stredné projekty - customizované webové projekty Veľké projekty - komplexné projekty Pilotný projekt Návrh metodiky pre stredné projekty Vhodnosť metodiky PRINCE Napasovanie metodiky PRINCE Zistenia a problémy pri napasovaní Obecný návrh metodiky Definícia princípov Témy Organizácia Nástroje Procesy Predprojektová fáza Iniciačná fáza

7 8.5.3 Doručovacia fáza Finálna doručovacia fáza Post-projektová fáza Návrh metodiky pre malé projekty Vyhodnotenie Vyhodnotenie projektu a metodiky Splnenie stanovených kritérií Zistené problémy Záver Zoznam použitej literatúry Zoznam použitých skratiek Zoznam tabuliek Zoznam obrázkov Prílohy

8 Úvod V dnešnej digitálnej kultúre a v dobe tzv. digitálneho darvinizmu [8], sa veci okolo nás vyvíjajú a menia omnoho rýchlejšie ako kedykoľvek predtým, a preto sme nútený, ak chceme byť úspešný, či uţ v našom biznise, alebo aj v osobnom ţivote, takisto drţať krok a neustále sledovať a zavádzať zmeny, lebo ako uţ povedal Charles Darwin: Nie je to ten najsilnejší ţivočíšny druh, ktorý preţije, ani ten najinteligentnejší. Ale ten, čo sa vie najlepšie prispôsobiť zmene. Základným nástrojom na realizáciu zmeny je projekt. Úlohou Project manaţmentu, je realizácia projektu (zmeny) za splnenia určitých kritérií (čas, cena, atď.). V dnešnej dobe keď sme obklopený projektmi zo všetkých strán, by riadenie projektu nemalo byť zaloţené iba na skúsenostiach a intuícií jednej osoby, ale by malo dodrţovať určité pravidlá, vyuţívať rokmi preverené vedomosti, techniky, štandardy. Výhodou pouţitia metodiky, je nielenţe vyuţívame vedomosti, ktoré sú uţ rokmi overené a vylepšované, ale takisto aj nejaký druh štandardizácie projektov, ktorý zaručuje lepšiu spoluprácu, či uţ v rámci firmy, alebo medzi viacerými firmami. Neexistuje univerzálna metodika, ktorá by bola vhodná pre riadenie kaţdého projektu. Cieľom preto bolo špecifikovať, čo je, poprípade nie je projektová metodika, popísať najznámejšie a najpouţívanejšie z nich, aby mal čitateľ predstavu a mohol si vybrať metodiku, ktorá sa najviac hodí jeho potrebám, poprípade skĺbiť niekoľko metodík dohromady a vyuţiť z kaţdej to najvhodnejšie pre riadenie konkrétneho projektu. A keďţe je práca písaná v rámci katedry Informačných technológii, samozrejme sa budeme primárne baviť o metodikách vyuţívaných v rámci oblasti ICT. Cieľom je takisto navrhnúť vlastné metodiky projektového riadenia, ktoré by reflektovali potreby konkrétnej firmy, za vyuţitia vedomostí a princípov zo svetovo uznávaných metodík. Prvá kapitola vymedzuje základné pojmy z oblasti projektového riadenia, keďţe ani u nás, ani vo svete nie sú tieto pojmy jednoznačne vydefinované. V tejto kapitole sú popísané kategórie a kritéria metodík. 8

9 V nasledujúcej kapitole je popísaná doména projektov, ktorej sa navrhovaná metodika týka. Kapitola obsahuje vymedzenie webových projektov, odlišnosti od iných projektov, nástrahy ktoré tieto projekty so sebou prinášajú a hlavne na čo sa treba zamerať, keď chceme tieto projekty úspešne riadiť. V oblastí informačných technológií je primárnym jazykom jazyk anglický a mnoho termínov pre ich obecnú pouţívanosť je prebratých i v našich zemepisných šírkach. Pri násilnom preklade niektorých pojmov, dokonca dochádza ku skresleniu významu, preto v prípade obecne pouţívaných pojmov, alebo v prípade pojmov, kde je preklad nejednoznačný, nejednotný, alebo dokonca zavádzajúci, pouţívam radšej originálne znenie. Na záver práce preto uvádzam i slovník pojmov, kde je moţné nájsť anglické pojmy a ich slovenské preklady. Kedţe firma pre ktorú sa metodika riadenia navrhovala je česká a primárne má českých klientov, tak dokumenty sú v češtine. Dosiahnutý stupeň poznania Autor tejto práce pracoval najprv niekoľko rokov ako programátor-analytik v oblasti vývoja software pre firmy Trgiman a Arakis & Belleville (projekty ako implementácia administračního rozhrania pre Opencard, návrh a implementácia CMS, programovanie webových prezentácií). Posledné 4 roky pracoval ako projektový a produktový manaţer, najprv vo webovej agentúre Lundegaard (realizácia portálu pre Škoda Transportation, IS pre správu skladov pre Barandov Studio, rezervačný systém pre Zentivu, atď.) následne v konzultačnej firme Trask solution, kde bol nasadený ako konzultant a projektový manaţér na riadenie kľúčových IT projektov v spoločnosti Telefonica O2. V danej oblasti autor teda vychádza z vlastných skúseností, či uţ z oblasti programovania a návrhu, alebo z oblasti projektového riadenia. Ako rozcesník v oblasti základných pojmov a prehľadu v danej problematike slúţili študijné podklady od Ing. Václava Šebeka, CSc., a na zorientovanie sa v kriteriách na metodiky a rozdelení jednotlivých metodík dokumenty a hlavne kniha od doc. Ing. Alena Buchalcevová, Ph.D Metodiky budování informačních systémů [3]. Veľkú inšpiráciu autor čerpal z metodiky PRINCE2, v rámci ktorej absolvoval i certifikáciu. Školenie metodiky mu poskytlo hlavne utvrdenie si terminilógie, základných pojmov a procesov. Kompletný popis metodiky je 9

10 v knihe Managing Successful Project with PRINCE2, ktorá je oficiálnou príručkou pre PRINCE2, avšak primárne autor pracoval s knihou The PRINCE2 Training Manual od Franka Turleyho 1 [2], čo je kompaktnejšia verzia oficiálnej príručky, ktorá je písaná čitateľnejším štýlom a slúţi na prípravu na certifikáciu. Pri návrhu vlastnej metodiky autor čerpal inšpiráciu z knihy Get Agile!: Scrum for UX, Design & Development [5] od Pietra Jongeriusa, pracujúceho v holandskej digitálnej agentúre, ktorá je momentálne jednou z mála kníh, ak nie jedinou, ktorá dáva praktické rady v implementácií agilnej metodiky v oblasti webových projektov. Vedomosti v konkrétnych oblastiach si autor dopĺňal z ďalších zdrojov, ktorých prehľad je uvedený na konci práce. Metódy spracovania práce Diplomovú prácu som vypracoval v niekoľkých etapách. V prvej etape som si navrhol hrubú osnovu práce v podobe hlavných kapitol a podkapitol, definíciu cieľa a formuláciu dielčich cieľov jednotlivých kapitol. V druhej etape som analyzoval dostupné zdroje, ktoré pojednávajú o danej téme, jednak tlačenú literatúru, ale i online zdroje. V ďalšej etape som spracoval teoretickú časť, kde som analyzoval existujúce metodiky na riadenie softwarových projektov. Pre túto časť som pouţil analytickokomparatívnu metódu práce. Vydefinoval som kritéria metodík a následne popísal najznámejšie metodiky. Poznatky, ktoré som získal v teoretickej časti, vyústili v ich syntézu v podobe návrhu vlastnej metodiky pre konkrétnu firmu, ktoré boli predvedené na konkrétnom projekte. V záverečnej etape som sformuloval získané poznatky, vyhodnotil navrhnuté riešenie a navrhol odporučenia. 1 jeden z najznámejších školiteľov PRINCE2 10

11 Typografické konvencie V texte sa často vyskytujú odkazy na rôzne metodiky a ich prvky (napr. fáze, etapy, procesy, atď.). Pretoţe sa jedná o názvy, tak ich uvádzame s veľkým počiatočným písmenom, aby boli odlíšené od ostatného textu. Text práce je písaný v slovenskom jazyku, takisto i niektoré výňatky z dokumentov sú prepísané do slovenského jazyka, avšak keďţe návrhy sú pre českú firmu, ktorá má väčšinou českých klientov, tak reálne ukáţky a prílohu sú v originálnom znení, tzn. v češtine. 11

12 1 Základné pojmy Predtým ako sa pustíme do samotných metodík projektového riadenia, je nutné si najprv definovať, čo si predstavujeme pod základnými pojmami, s ktorými budeme v nasledujúcom texte pracovať. 1.1 Projekt Častým problémom vyskytujúcim sa v prostredí organizácií, je čo moţno resp. nemoţno pokladať za projekt. Jednoznačná, všeobecne uznávaná definícia pojmu projekt neexistuje, preto si predstavíme viacej definícií. Ako sme uţ povedali, projekt predstavuje zmenu, takţe z povahy projektu, musí byť kaţdý projekt jedinečný, tj. dva identické projekty z princípu nemoţu existovať. Ak napr. v spoločnosti existujú sa opakujúce projekty, a sú rovnaké, tak potom sa uţ jedná o procesy [2]. Začnime najprv obecnou definíciou, prevzatou z Wikipédie: Projekt je časovo ohraničené úsilie, smerujúce k vytvoreniu unikátneho produktu alebo služby. PMBOK zas definuje projekt ako dočasne vynaloţené úsilie k vytvoreniu unikátneho produktu, sluţby alebo výsledku [4]. Ďalšia populárna metodika PRINCE2, si pod pojmom projekt predstavuje: Projekt je dočasná organizácia vytvorená za účelom poskytnutia jedného alebo viacerých produktov na základe schváleného obchodného zámeru (Busines Case)." [1]. Pod pojmom organizácia chápeme projektový tým, ľudí ktorý sa podieľajú na projekte a ich vzájomné vzťahy. Obchodný zámer je dokument, ktorý obsahuje informácie ako prečo je daný projekt dobrý nápad, z obchodného hľadiska, informácie ohľadom výhod, nákladov, času, atď. Bez obchodného zámeru a teda vyšpecifikovaných výsledkov, nemôţeme hovoriť o projekte. PRINCE2 navyše predpokladá, ţe tí, ktorí sú zodpovední za projekt, nemusia mať skúsenosť z práce spolu za účelom vytvorenia podobného súboru výstupov alebo výsledkov pre toho istého zákazníka z minulosti, ţe koordinácia medzi tými, čo pracujú na projekte, musí byť dobre organizovaná a zodpovednosti zdieľané a jasne definované medzi tými, ktorí vykonávajú prácu, ktorí ju manaţujú a tými, ktorí ju sponzorujú (financujú). 12

13 PRINCE2 projekt má nasledovné charakteristiky: konečný a definovaný ţivotný cyklus definované a merateľné produkty (výstupy) korešpondujúci súbor aktivít na dosiahnutie produktov podnikania definované mnoţstvo zdrojov organizačnú štruktúru s definovanými zodpovednosťami týkajúcimi sa riadenia projektu. 1.2 Webový projekt Pretoţe webový projekt sa líši od ďalších typov projektov (vývoj software, správa IS,a tď.), ako si ukáţeme v nasledujúcom texte, je nutné si definovať tento pojem. Momentálne neexistuje oficiálna definícia, alebo aspoň obecne uznávaná definícia, tak si musíme vydefinovať, čo si pod týmto pojmom predstavujeme v tejto práci. Na základe vlastných skúseností a diskusií s klientami, pod pojmom webový projekt budeme chápať: Akýkoľvek projekt, ktorého výstup je prístupný cez internetový prehliadač ďalším užívateľom, pričom nezáleží na koncovom zariadení cez ktoré sa zobrazuje (cez PC, mobil, tablet, atď.) Nie sú to iba webové stránky (i keď tvoria veľké percento), ale sú to takisto aplikácie, reklama, projekty na sociálnych sieťach, atď. Dôleţitým znakom je, ţe s výstupným produktom pracuje veľa rôznorodých uţívateľov na rozličných zariadeniach. Napríklad tento pojem nezahrňuje desktopové, ani mobilné aplikácie, ktoré sú vyvinuté priamo pre nejaký OS. Z tejto definície nám vyplýva mnoho úskalí a špecifík, ktoré si rozoberieme v nasledujúcich kapitolách. 13

14 1.3 Startup Eric Ries definuje startup ako: Organizácia vytvorená za účelom niečoho za extrémnej neistoty [6]. Táto definícia platí pre jednu osobu v garáţi, takisto ako pre skupinu profesionálov. Takţe môţeme povedať ţe je to projekt za extrémnych podmienok. Startupy môţu byť v rôznych oblastiach, ale obecne sa predpokladá aj my predpokladáme, ţe sa jedná primárne o internetové projekty. 1.4 Projektové riadenie je: Takisto pojem projektové riadenie ma viacero definícií. Jednou z najpouţívanejších Projektové riadenie je proces riadenia a koordinácie ľudských, materiálnych a finančných zdrojov počas životnosti projektu pri použití moderných techník riadenia, zameraný na dosiahnutie vopred stanovených cieľov v danom rozsahu, nákladoch, čase, kvalite a spokojnosti účastníkov projektu. Stanovený cieľ musí byť dosiahnutý pri rešpektovaní definovanej stratégie a pri využití špecifických postupov, nástrojov a techník na plánovanie a riadenie procesov jednotlivých projektov. Ďalšou definíciou je: Projektový manažment je aplikáciou vedomostí, zručností, nástrojov a techník na projektové aktivity za cieľom dosiahnutia projektových požiadavkov [4]. Projekt niekedy riadi profesionálny projektový manaţér a niekedy aktivity projektového manaţmentu zastrešuje ďalší člen projektového týmu. Existuje niekoľko obecne prijímaných právd pre akýkoľvek projekt, s ktorými pracuje kaţdá metodika projektového riadenia: o vţdy existuje zákazník, projekt je vţdy doručovaný niekomu o vţdy existuje projektový tým, pričom nezáleţí na veľkosti o vţdy musí byť definovaný cieľ, inak nemá zmysel realizovať daný projekt o vţdy ide o riadenie ţelezného trojuholníku 14

15 Cena Kvalita Čas Ţelezný trojuholník reprezentuje 3 kľúčové elementy projektu: cenu, kvalitu a čas. Úpravou jednej z týchto premenných afektujeme ďalšie dve. Napríklad, keď chceme zníţiť čas dokončenia projektu, musíme buď risknúť zníţenie kvality, alebo zaplatiť viacej pracovníkov, aby bola zaistená rovnaká kvalita za menší čas, čím sa nám navyšuje cena. 1.5 Projektové riadenie webových projektov Základy projektového riadenia sú rovnaké, ale v rámci webových projektov existuje veľa výziev, problémov, spôsobených špecifickosťou týchto projektov, ktoré často spôsobujú nedodanie projektov na čas, v danom rozpočte a k obecnej spokojnosti interných, alebo externých zákazníkov. Na tieto výzvy sa zameriame v nasledujúcich kapitolách. Zo skúsenosti môţeme povedať, ţe neexistuje jednotný prístup ideálny pre všetky webové projekty, preto sa pokúsime navrhnúť nový spôsob riadenia určený špeciálne pre tento typ projektov. 1.6 Metodika Vedľa pojmu metodika nachádzame veľa ďalších termínov, ktorý majú podobný význam ako napr. Best practices, procesný, popr. metodický framework, metodický prístup, alebo len jednoduchý termín súbor pravidiel. V tejto práci budeme pouţívať pojem 15

16 metodika, ktorý je často kvôli zlému prekladu z angličtiny zamieňaný s pojmami metodológia, popr. metóda, avšak tieto pojmy majú úplne iný význam. Obecná definícia metodiky je: V rámci vývoja software, metodika predstavuje súhrn doporučených praktík a postupov, pokrývajúcich celý ţivotný cyklus vytváranej aplikácie. Bez projektovej metodiky riadenia projektu, všetci ktorý zadávajú projekt, riadia projekt a tí ktorý na ňom pracujú, majú rozdielne predstavy akoby veci mali byť organizované a ako a kedy by dané veci mali byť dokončené. Zainteresovaný nebudú mať jasno o tom aké sú ich zodpovednosti a právomoci a projekt bude vţdy zahalený neistotou. Bez projektovej metodiky sú projekty málokedy dokončené načas a v poţadovaných nákladoch, toto hlavne platí pre rozsiahle projekty. 1.7 Metódy Pre riešenie jednotlivých problémov, môţu byť v rámci pouţitia metodiky uplatnené niektoré techniky, metódy. Často sa však význam pojmu metodika, zamieňa s pojmom metóda, kvoli tomu v krátkosti spomeniem aspoň niekoľko najznámejších príkladov. Projektové metódy nie sú náplňou tejto práce, avšak budeme ich vyuţívať v určitých situáciách v rámci našich metodík. Známou metódou v problematike vývoja softwaru je COCOMO, ktorá je empirickým algoritmickým modelom pre odhadovanie nákladov na softwarový projekt. Naproti tomu Earned Value management metóda, odhaduje vývoj projektu (stav, kde sa momentálne projekt nachádza) porovnaním toho, čo bolo doposiaľ spravené s odhadmi, ktoré boli spravené na začiatku projektu. Pouţitím týchto meraní moţe projektový manaţér odhadnúť, koľko zdrojov bude potrebných na záver projektu. Ďalšou veľmi známou metódou je metóda kritickej cesty (Critical Path Method CPM) ktorá patrí medzi základné metódy časovej analýzy projektov. 16

17 2 Kľúčové zistenia o projektoch a odporučenia 2.1 Zložitosť vývoja software Na vývoj software má vplyv prostredie vývoja, tak i cieľové prostredie. Premennými veličinami pri vývoji software sú podľa [7]: dostupnosť kvalifikovaných špecialistov (pre nové technológie, nástroje, metody a domény je malý počet kvalifikovaných odborníkov), stabilita technológie pre implementáciu (nové technológie sú menej stabilné), stabilita a schopnosti nástrojov, efektívnosť pouţívaných metod, dostupnosť expertov na vecnú oblasť i technologii, nová funkcionalita a jej vzťah k existujúcej funkcionalite, metodika a jej flexibilita, konkurencia, čas, zdroje, ďalšie premenné. Celková zloţitosť vývoja software je funkciou týchto premenných, pričom tieto premenné sa v priebehu projektu nemenia: zloţitosť = f(premenné prostredia vývoje + premenné cieľového prostredia) Rastie zloţitosť projektu, je treba zaraďovať do procesu viacej kontrolných prvkov(napríklad riadiť riziká apod.). 17

18 2.2 Najčastejšie príčiny zlyhania IT projektov Podľa štúdie z roku 2009 [13] iba 32% IT projektov je úspešných (na čas, v danom rozpočte, plne funkčných), 44% je neúplne dokončených (neskoro dodaných, nad plánovaný rozpočet, s neúplnou funkcionalitou, alebo nedostatočnou kvalitou) a dokonca 24% projektov zlyhalo úplne (boli zrušené, alebo výstupy nikdy pouţívané). Nielen z tohto prieskumu vyplýva, ţe zlyhania projektov (nedodrţanie časového plánu, prekročenie rozpočtu, nedodrţanie poţadovanej funkčnosti alebo kvality) sú veľmi časté. Niektoré príčiny zlyhania sú neustále vyzdvihované, niektoré sú rýchlo zabudnuté. Existuje mnoho a rôznych príčin zlyhania projektov. Ako sa spomína v manuáli PRINCE2 a z vlastnej skúsenosti, tak môţeme spomenúť aspoň hlavné príčiny zlyhania projektov. 1. Požiadavky sú nejasné, nepresné, rozporuplné, nikto nenesie zodpovednosť za ich špecifikáciu. 2. Zdroje, nedostatok zdrojov (ľudských), konflikty u alokovania zdrojov, zlé koordinovanie zdrojov a aktivít, častá fluktuácia kľúčových zamestnancov, atď. 3. Preťažovanie ľudí. Pracovanie ľudí aţ na príliš mnoho projektoch, čo spôsobuje časté prepínanie kontextu u zamestnancov a z toho vyplývajúcu dlhšiu dobu potrebnú na splnenie jednotlivého úkolu. 4. Odhady. Často krát slabé odhady trvania a nákladov, vedú k tomu, ţe projekty sú dokončené neskôr a za omnoho vyššiu cenu. 5. Časový plán je zvyčajne príliš tesný, bez časových rezerv, nerealistický, prehnane optimistický, deadliny nie sú určované koľkokrát na základe skúseností a reálnych odhadov, ale sú určované zhora, podľa obhodného oddelenia, koľkokrát dokonca podľa samotného klienta. 6. Plánovanie je zaloţené na nedostatočných údajoch, koľkokrát nepočíta s mnohými vecami (ktoré vyplynú na povrch aţ počas samotnej implementácie), je zaloţené na slabých odhadoch. 7. Monitorovanie stavu pokroku je často podceňovaná poloţka, takţe často nevieme presný stav projektu, kde presne sa nachádzame, aţ kým nie je neskoro. 18

19 8. Riziká sú často neidentifikované, alebo iba obecné, nič nehovoriace riziká. A ak sú riziká aj dostatočne identifikované, tak počas projektu nie sú dostatočne manaţované. 9. Komunikácia je často nedostatočná medzi všetkými zúčastnenými stranami, čo má vacsinou za následok, ţe sa vyvynie produkt, ktorý nesplňa poţiadavky, ale príde sa na to aţ príliš neskoro. 10. Nedostatok kontroly a merania kvality, sposobuje ţe finálny produkt je neakceptovateľný, popr. nepouţiteľný. 2.3 Najväčšie výzvy v riadení webových projektov Pretoţe sa v práci budeme zaoberať primárne o oblasť webových projektov, tak v tejto kapitole prejdeme najväčšie výzvy v rámci týchto projektov a následne sa pokúsime odlíšiť v čom sa líšia od ostatných projektov, čo nám pomôţe určiť, na čo sa máme zamerať pri návrhu metodiky. Na základe prieskumu od britskej firmy E-consultancy [15], kde chceli identifikovať najväčšie problémy s úspešným doručením webových projektov, na základe reakcií respondentov, zistili, ţe medzi najväčšie problémy patrili: meniace sa poţiadavky (50% z celkového počtu respondentov) nerealistické očakávania od zákazníkov, stakeholderov (33%) nedodanie potrebných vstupov od zákazníkov v potrebný čas (31%) podcenenie odhadov vývojármi (27%) neschopnosť vyjadrenia poţiadavkov (27%) slabá spolupráca (19%) nedostatok procesov (15%) nedostatok zručností (14%) Samozrejme problémy webových projektov sú podobné ako ďalších projektov, avšak v omnoho väčšej miere. Najviac organizácií má problémy s vecami, ktoré vyplývajú z povahy webových projektov. Najväčším problémom s ktorým sa stretávajú projektový manaţéri, sú meniace sa poţiadavky počas trvania projektu. Avšak táto vlastnosť je hlavnou vlastnosťou webových projektov a nemôţeme jej zabrániť. 19

20 Ironicky väčšina organizácií (87,67% podľa prieskumu), mieni, ţe poţiadavky musia byť flexibilné. Fakt, ţe 50% organizácií to povaţuje za najväčší problém, iba dokazuje nepripravenosť firiem na zmeny v poţiadavkách, keď je to potrebné, alebo keď sa to uţ stalo. Všetky metodiky zvačša obsahujú mechanizmus na riadenie zmien v projekte. Ale je nutné si uvedomiť, ţe je rozdiel medzi riadením zmeny ako výnimky v projekte a zahrnúť zmeny ako súčasť procesu, čo je nevyhnutné hlavne v prípade webových projektov. Na základe týchto problémov ďalších výzkumov firma E-consultancy identifikovala, ţe webové projekty sa líšia od ďalších IT projektov hlavne: meniacimi sa zákazníkovými poţiadavkami a rýchlymi zmenami na trhu je potrebná široká škála ľudí a zručností, spolupráca medzi roznorodými mnoţinami zručností (grafické zručnosti, marketingové zručnosti, technické zručnosti, atď. ) veľa stakeholderov (marketingový pracovník, produktový manaţer, majitelia, koncový uţivatelia, atď.) často krátke a fixné termíny dokončenia veľký stupeň nepredvídateľností potreba interakcie s cieľovým zákazníkom Na základe týchto poznatkov výzkumu a vlastných skúseností moţne identifikovať poţiadavky na riadenie webových projektov: štrukturovaný prístup k projektom avšak schopnosť prisposobiť metodiku riadenia rozsahu projektu a okolnostiam nastavenie spolupráce vytvorenie vysoko spolupracujúceho prostredia zameriavať sa viac na riadenie prostredia ako na riadenie procesov prístup pomáhajúci s vyvíjajúcimi sa a meniacimi sa poţiadavkami zameranie sa na koncového uţivateľa 20

21 riadenie očakávaní stakeholderov 21

22 3 Metodiky obecne a ich kritéria rozdelenia So všetkými nástrahami a problémami nám majú pomocť práve metodiky. Avšak mnoho problémov, má mnoho riešení, tak preto existuje i mnoho metodík. Existencia mnoho rôznych metodik, je daná tým, ţe rôzne technológie vyţadujú rôzne metódy a techniky, rôzne organizácie majú rôzne firemné kultúry, kaţdý jedinec i tým je jedinečný a takisto kaţdý projekt, uţ z princípu definície je jedinečný napr. jeho dolezitostou, rozsahom, atd. Preto je veľmi doleţité vybrať správny sposob riadenie na kaţdý projekt. Lebo kde jedna metodika funguje, tak inom projekte moţe byť na prítaţ. 3.1 Kritéria metodík Toto veľké mnoţstvo metodík predstavuje problém pri jej výbere. Problémom je i to, ţe metodiky nie sú popísané jednotným sposobom a takisto nie sú jednoznačne kategorizované ani v slovenskej, popr. českej, ani v svetovej odbornej literatúre. V nasledujúcom texte sme výchádzali z rozdelenia od českej autorky doc. Aleny Buchalcevovej, ktorá najprv definuje kritéria, na základe ktorých potom metodiky kategorizuje (Buchalcevová, 2009), ktoré autor doplňuje o svoje návrhy Kritérium zameranie metodiky Hlavným kritériom je zameranie metodiky, ktoré určuje na čo všetko sa metodika zameriava. globálne metodiky (enterprise methodologies) metodiky zamerané na vývoj, údrţbu, rozvoj celopodnikového IS/ ICT projektové metodiky metodiky pre vývoj, implementáciu software Cieľom práce sú projektové metodiky, preto i v nasledujúcom texte budeme pod pod pojmom metodika myslieť metodiky so zameraním na projekty, i konrétne príklady uvádzať z tejto oblasti. 22

23 Kritérium rozsah metodiky Rozsahom metodiky sa z pravidla chápe počet fáz ţivotného cyklu, ktoré metodiky pokrýva. Pre potreby kategorizácie je rozsah metodiky definovaný ako prienik 3 hľadísk: fáze ţivotného cyklu role dimenzie Toto vymedzenie vychádza z pojatia A. Cockburna [10], kde doc. Buchalcevová ho rozšírila o dimenziu. Rozsah fázi ţivotného cyklu určuje, kde metodika začína a končí. Role sú typové skupiny pracovníkov. Jednotlivé metodiky sa líšia počtom a typom rolí, ktoré zahrňujú. Vývoj software má okrem jednotlivých fáz i celú radu aspektov, preto je vhodné naň pozerať i z roznych dimenzí. Prehľad dimenzí: Dimenzie vyvíjaného systému hardware HW typy, parametry a počty počítačů, periferních zařízení, komunikačních sítí a dalších technických prostředků technologie platforma (operačný systém), architektúra programového systému, data/informace funkcie/procesy obsah a štruktúra datové základne a ich fyzické uloţení procesy probíhající v podniku a moţnost jejich podpory informačním systémom, funkce informačního systému užívateľské rozhraní uţívateľské rozhraní systému organizační/legislativní potrebná štruktúra pracovníkov, špecifikácia zákonov, noriem a smernícc, ktoré musia byť pri tvorbe IS/ICT respektovány ekonomická zahrnuje finanční náklady tvorby a provozu IS/ICT a přínosy podniku z uţití IS/ICT, zdroje Tabuľka 1 Dimenzie vyvíjaného systému 23

24 Na základe vyššie zmieneného, môţeme metodiky podľa rozsahu rozdeliť na: čiastočné metodiky - zaoberajúce sa iba časťou ţivotného cyklu vývoja software (napr. iba návrh a implementácia) metodiky vývoja software - pokrývajúce celý ţivotný cyklus vývoja software. Tieto metodiky pokrývajú primárne vývoj software ako takého, od návrhu, aţ po finálne nasadenie. Tieto metodiky sa môţu vyuţívať i v rámci metodiky projektového riadenia metodiky projektového riadenia - pokrývajúce cyklus celého projektu (od úvodných analýz, cez schválenie rozpočtu, určenie týmu, aţ po finálne nasadenie, vyhodnotenie a nasledujúci rozvoj) i všetky dimenzie (vrátane organizačno/ legislatívnej i ekonomickej dimenzie) Kritérium váha metodiky Kritérium váha metodiky vychádza z prác Alistaira Cockburna (Cockburn, 2008), ktorý zavádza charakteristiky metodiky označované skratkou PARTS precision, accuracy, relevance, tolerance, scale. Charakteristika Preklad Popis precision Podrobnosť vyjadruje ako podrobne sa metodika danými témami zaoberá accuracy Presnosť vyjadruje, ako presne je dané téma spracované relevancy Relevancia určuje, či sa metodika zaoberá danou témou tolerance Tolerancia určuje toleranciu, tj. aké mnoţstvo odchyliek je povolené scale miera definuje mieru zaostrenia (niekoľko vecí môţe byť zabalených do jednej) Tabuľka 2 Charakteristika metodík Z týchto charakteristík sú potom odvodené pojmy veľkosť, hustota a váha metodiky. Veľkosť metodiky vyjadruje počet kontrolných prvkov v metodike. Hustota metodiky vyjadruje mieru podrobnosti a tesnosť tolerancie metodiky, poţadovanú detailnosť a konzistenciu prvkov. 24

25 Váha metodiky je potom súčin veľkosti metodiky a hustoty metodiky (Cockburn, 2008). Následne sa potom kritéria Váha, delia metodiky na ľahké a ťaţké. ťaţké metodiky majú presne definované procesy, činnosti a artefakty, označujú sa takisto ako i rigorózne ľahké metodiky definujú namiesto presných procesov, skor princípy a praktiky, označujú sa takisto ako agilné metodiky Kritérium typ riešenia Projekty z oblasti IT sa netýkajú primárne iba vývoja nových riešení, ale v mnohých prípadoch moţe takisto isť i integráciu riešení, úpravu existujúcich, alebo implementáciu aplikačného software. Je zrejmé, ţe u kaţdého typu riešenia sa bude projekt riadiť inak. vývoj nového riešenia rozšírenie, úprava existujúceho riešenia či uţ sa jedná o úpravu nejakého opensource riešenia (WordPress, Joomla CMS), alebo plateného, poprípade úprava vlastného riešenia (firemné CMS) úprava, redesign, rozšírenie stávajúceho riešenia integrácia riešenia implementácia typového riešenia napríklad implementácia SAP, Siebel (Oracle CRM), SalesForce (CRM), atd Kritérium doména Doména predstavuje určitú oblasť pre ktorú software vytváraný. Je zrejmé, ţe kaţdá oblasť potrebuje iný sposob riadenia a má iné poţiadavky na metodiku. V reále sa vačšina firiem zameriava iba na určitú mnoţinu domén. Domény by sme si mohli rozdeliť na hlavné domény a subdomény, ale nie je cieľom tejto práce pokryť všetky. Príkladom moţu byť: Customer Relationship Management e-learning e- commerce 25

26 Content Management Enterprise Resource Planning Business Inteligence Office Information System Webové projekty Kritérium prístup k riešeniu Kritérium prístup má zmysel aplikovať hlavne pri novom vývoji software. Toto kritérium zohľadňuje základné paradigma, na ktorom je metodika zaloţená. V současnosti sa moţeme stratnúť s nasledujúcimi prístupmi: štrukturovaný vývoj objektový vývoj komponentový vývoj Keď sme si uţ špecifikovali, čo je a čo nie je metodika, webové projekty, kritéria podľa čoho ich moţme rozdeľovať, moţme si teraz predstaviť najznámejšie metodiky. Najprv začneme metodikami vývoja software, a v následujúcej kapitole preberieme projektové metodiky. Kedţe firma pre ktorú bude následne metodika navrhovaná sa primárne zaoberá vývojom nových riešení, tak i v texte tejto práce budeme popisovať metodiky, ktoré sú primárne určené na vývoj nového software (kritérium typ riešenia) a vyuţívajú objektový, alebo komponentový prístup (kritérium prístup k riešeniu). Metodiky si rozdelíme najprv na základe kritéria rozsahu, na metodiky vývoja software, ktoré pokrývajú ţivotný cyklus vývoja software a na metodiky projektového riadenia, ktoré pokrývajú cyklus celého projektu (od procesov na schválenie projektu, cez akceptáciu projektu aţ po vyhodnotenie projektu). Ďalej metodiky vývoja software si na základe váhy rozdelíme na dve kategórie, ťaţké metodiky rigorózne a na ľahké metodiky - agilné metodiky. 26

27 V praktickej časti navrhneme metodiku projektového riadenia určenú primárne na vývoj nových riešení a zameranú na doménu vývoja webových projektov, primárne z oblasti content managementu (správy obsahu) a e-commerce. Čo sa týka váhy metodiky, tak by sme mohli povedať, ţe sa jedná o kombináciu, moţeme nazvať vyváţená metodika, lebo si definujeme presne procesy, ale ľahkým štýlom. 27

28 4 Metodiky vývoja software Metodiky vývoja software moţme podľa kritéria váhy rozdeliť na taţké (tradičné, rigorózne) a ľahké (agilné) metodiky, kde oboje majú rozny pohľad na vývoj softwaru. Kaţdá metodika je vhodná na iný druh projektov, čo treba pri výbere metodiky zváţiť. Kedţe sa cieľom práce nie je detailne popísať všetky metodiky, tak v nasledujúcom texte detailnejšie popíšeme tie veci, popr. metodiky, z ktorých sa najviac vychádzalo pri návrhu vlastnej metodiky a zvyšné veci popíšeme iba orientačne, aby sa zachovala kontinuita práce. 4.1 Tradičné metodiky vývoja software Rigorózne metodiky vychádzajú z modelov, tak preto si najprv popíšeme v skratke základné modely, tj. Vodopádový model a následne spirálový model. A následne hlavného reprezentanta rigorózných metodík RUP. 4.2 Vodopádový model Ako sme spomínali, tak sa nejadná o metodiku, ale iba o model, 2 je to jeden z prvých modelov, a mnoho metodík z neho vychádza tak si ho v skratke popíšeme. Ide o prvý a pravdepodobne najznámejší model ţivotného cyklu vývoja software. Ten začal byť prvýkrát členený na jednotlivé aktivity. Postupuje sa sekvenčne podľa logickej postupnosti, bez akýchkoľvek iterácií. Pri kaţdom prechode medzi dvoma fázami dochádza ku schvaľovaciemu procesu. Behom vývoje sa môţeme pohybovať medzi fázami vţdy buť o jednu dopredu, alebo dozadu. Model má veľa podob, ale obecne fáze vývoja vodopádového modelu sú: 1. Definícia problému 2. Analýza a špecifikácia poţiadavkov 3. Návrh systému 4. Integrácia a testovanie systému 2 model popisuje iba fáze, metodika čo presne sa má robiť, postupy 28

29 5. Údrţba systému 4.3 Spiralový model Takisto ako v prípade vodopádového modelu ide len o model a spirálový model vychádza z tohto modelu. Prináša 2 úplne nové vlastnosti a to iteratívny prístup a podrobnú analýzu rizík. Iteratívny prístup bol dosledkom toho, ţe u veľa projektov sa nepodarilo stanoviť presnú a úplnú špecifikáciu poţiadavkov, čo činilo vodopádový model skoro nepouţiteľným. Obrázok 1 Schéma ţivotného cyklu špirálového modelu Rational Unied Process (RUP) Rational Unified Process (ďalej len RUP), ktorý je komerčným produktom firmy Rational (ktorá bola neskôr kúpená firmou IBM), je rozsiahla (hrubá metodika) a detailne prepracovaná metodika vývoja software. 29

30 Vývoj podľa RUP prebieha v iteratívnych cykloch. Prvý cyklus sa nazýva úvodný vývojový cyklus a jeho výsledkom je funkčný softvérový produkt implementujúci najpodstatnejšiu časť funkcionality. Tu však vývoj nekončí, ale pokračuje v rôznom mnoţstve rozvíjajúcich cyklov. Ich presný počet závisí od rozsahu projektu. Kaţdý cyklus sa skladá zo 4 fáz : Zahájenie (Inception) - stanovenie rozsahu projektu a posúdenie podmienok pre jeho realizáciu. Rozpracovanie (Elaboration) - vyriešenie hlavných problémov spojených s vytváraním softvérového systému a implementácie základných prvkov architektúry systému. Konštrukcia (Construction) - detailný návrh všetkých častí systému, ich implementovanie a testovanie. Nasadenie (Transition) - zameranie predovšetkým na presun systému od vývojárov k jeho uţívateľom a zabezpečenie korektného a stabilného fungovania v reálnom prostredie. Kaţdú fázu projektu pretínajú nasledovné disciplíny: modelovanie business modelu zákazníka (business modeling) zber poţiadaviek (requirements) design a analýza (analysis & design) implementácia (implementation) testovanie (test) nasadenie (deployment) menové a konfiguračné poţiadavky (configuration & change management) projektové riadenie (project management) správa prostredie (environment) 30

31 Obrázok 2 RUP fáze a disciplíny (www) Najväčšou výhodou i nevýhodou zároveň metodiky RUP je jeho robustnosť, všeobecnosť a prispôsobivosť pre celú radu najrôznejších projektov. Jedna z úvodných fáz pri pouţití RUP je modifikácia samotnej metodiky na mieru konkrétnemu projektu, ktorý začíname realizovať. Nie je problém upraviť metodiku ani pre malý tím a jednoduchší projekt. 4.4 Agilné metodiky vývoja software Technologický vývoj ide stále dopredu, dokonca podľa futuristu a inovátora Ray Kurzweila 3, sa technológie nevyvíjajú iba lineárne, ale exponenciálne (Kurzweil), vďaka nepretrţitému zdokonaľovaniu technológií, na základe ktorých vznikajú ďalšie a ďalšie technológie. Softwarový trh sa preto od časov svojho vzniku podstatne zmenil, i keď sa jedná o relatívne krátku dobu. Napríklad vývoj webových aplikacií sa natoľko zjednodušil a existuje uţ toľko nástrojov, ţe vytvoriť jednoduchú internetovú prezentáciu, ktorá obsahuje obecne pouţívané komponenty, zvládne skoro kaţdý priemerný uţivateľ internetu. V dobe písania tejto práce (rok 2014) dokonca uţ existuje i aplikácia na tvorbu mobilných aplikácií pre smartphony. A pritom trh smartphonov a aplikácií pre ne existuje cca 4 roky. 3 Okrem mnoho ďalších vecí je i technologickým riaditeľom vo firme Google 31

32 S týmto zjednodušovaním a dostupnosťou nových a nových riešení rastie i konkurencia a okrem kvality sa začína dávať väčší doraz na rýchlosť a nízku cenu vývoja. Dnešné firmy nezaujíma rozsiahla analýza, nepriestrelný návrh, ale potrebujú dodať hotové riešenia rýchlo a relatívne kvalitne, aby nestratili krok s konkurenciou. Rozdielny prístup sa v oblasti vývoja software moţe uplatňovať i kvoli inym specifikám tohto oboru oproti ostatným. Napr. zásadným rozdielom je ţe vývoj prototypu nemá materiálne náklady, narozdiel od oborov ako je stavebníctvo, alebo strojírenstvo. Pričom sposob riadenia sa kopíroval práve z týchto oborov. Preto je moţné i bez detailného návrhu vyvynúť dané riešenie, ktoré je následne moţné upravovať. Napr. u stavby domu toto nie je moţné. Práve kvoli vyššie zmieňovaným dovodom, začali okolo roku 2000 vynikať metodiky, ktoré umoţnili vyvýjať software rýchlo a pritom boli schopné reagovať na priebeţnú zmenu zadania agilné 4 metodiky Rozdiel medzi agilným a tradičným prístupom Rozdiel medzi agilným a tradičným pojatím vývoja software moţme vidieť na nasledujúcom obrázku. 4 Názov vznikol z anglického slova agile hbytý, čilý, bystrý 32

33 tradičný prístup vs. agilný prístup funkcionalita čas zdroje fixné premenné čas zdroje funkcionalita Obrázok 3 Tradičný vs. agilný prístup pri vývoji software [3] Tu môţeme jasne vidieť odlišnosť týchto prístupov. Tradičné metodiky, počítajú s funkcionalitou ako s fixnou veličinou, to znamená, ţe na začiatku vývoja sa vyšpecifikujú presné poţiadavky, ktoré sa musia dodrţať, aby bol výsledný produkt akceptovaný a čas a zdroje sú premenné, s ktorými môţeme hýbať (súvisí so ţelezným trojuholníkom). Preto sa u projektov vyvíjaných pomocou tradičnej metodiky, stretávame tak často s prekročením termínu dodania alebo s prekročením nákladov, či uţ u klienta, alebo dodávateľa, oproti pôvodnej špecifikácii. Agilné metodiky majú opačný prístup, tj. ako fixné sú na začiatku projektu nastavené čas a zdroje (či uţ finančné, ľudské, atď.) a funkcionalita je premenná. To znamená, ţe zákazník môţe dostať riešenie, ktoré zatiaľ implementuje časť funkcionality (s najvyššou prioritou), avšak vďaka agilnému pojatiu, je to v termíne, za dané peniaze a podľa skutočných poţiadavkou zákazníka, ktoré sa v priebehu implementácie mohli zmeniť. Dôleţité je, ţe nemusia byť implementované funkcie, ktorým zákazník spolu s dodávateľom definoval najniţšiu prioritu, takţe riešenie môţe byť takisto akceptovateľné. 33

34 Jedna z najdôleţitejších poučiek agilného programovania nám vraví, ţe jedinou cestou ako preveriť správnosť navrhnutého riešenia, je čo najrýchlejšie ho vyvinúť, predloţiť zákazníkovi a podľa spätnej väzby upraviť. Rigorózne a agilné metodiky predstavujú 2 skupiny metodík, ktoré vychádzajú z roznych predpokladov a rozneho pohľadu na vývoj software. Výsledkom je iný obsah a zameranie kaţdej kategórie metodík a iný okruh projektov. Základné rozdiely sú v nasledujúcej tabuľke (buchalcevova 50) Predpoklady Obsah Rigorózne metodiky - SW procesy ide popísať - poţiadavky je moţné definovať dopredu - presne definované procesy, činnosti, artefakty Agilné metodiky - SW procesy nejde presne popísať - dopredu len hrubý nástrel poţiadavkov - iba generatívne pravidlá, praktiky a princípy Použitie - Tabuľka 3 Porovnanie rigoróznych a agilných metodík Manifest agilného programovania Vznik agilného prístupu sa datuje k roku 2001, i keď väčšina techník bola uţ pouţívaná predtým. Vtedy sa stretli najvýznamnejší predstavitelia nových prístupov a pri snahe odprostiť vývojový proces od všetkých zbytočností zostavili Manifest agilného programovania [9], pod ktorým sa všetci rovno podpísali a súčasne bola zaloţená Aliancia pre agilný vývoj. Kaţdá z agilných metodík je svojím spôsobom špecifická, ale všetky sú postavené na rovnakých princípoch. Manifest stavia na 2 základných princípoch: o umoţniť zmenu je omnoho efektívnejšie, ako sa jej snaţiť zabrániť 34

35 o je potrebné byť pripravený reagovať na nepredvídateľné udalosti, pretoţe tie nepochybne nastanú Autori na základe týchto dávajú prednosť [9]: individualitám a interakcií Pred procesmi a nástrojmi fungujúcemu software Pred obsiahlou dokumentáciou spolupráci so zákazníkom Pred zjednávaním zmlúv reakciou na zmenu Pred plnením plánu Zároveň dodávajú, ţe i keď je určitá hodnota i v poloţkách na ľavej strane, oni si viacej váţia poloţiek na pravej strane. Manifest deklaruje 10 hlavných princípov agilných metodik, ktoré sú v nasledujúcich odstavcoch blíţšie charakterizované (Fowler, a iní, 2001): 1. Najvyššou prioritou je včas a kontinuálne dodávať software, ktorý zákazníkom prináša hodnotu. Zákazníka nezaujímajú dokumenty, diagramy alebo integrácie stávajúcich systémov, ale zaujíma ho, či dostane fungujúci software v kaţdej iterácií a či poskytovaná funkcionalita uspokojuje jeho potreby. Tradičné prístupy predpokladajú, ţe splnenie plánu = úspech projektu = hodnota pre zákazníka. V dnešnej dobe je však nutné, aby hodnota pre zákazníka bola neustále overovaná, pretoţe je predmetom zmeny. 2. Zmenu požiadavkou je možné previesť i v neskorších fázach vývoja, pretože tým môže zákazník získať konkurenčnú výhodu. Agilný prístup sa snaţí realizovať zmeny efektívne a riadiť rizika negatívnych dopadov. Je treba realizovať krátke iterácie a na ich konci dodávať fungujúci software. Iteratívny vývoj je presadzovaný i tradičnými metodikami, agilné prístupy však kladú doraz na zkrátenie cyklu dodanie prírastkov. 3. Užívatelia a vývojári spolupracujú denne na projekte. Agilné prístupy radikálne menia koncept špecifikácie poţiadavkou. Východiskom je presvedčenie, ţe nie je moţné dohodnúť a popísať všetky poţiadavky na začiatku 35

36 projektu. Preto definujú na začiatku len hrubé poţiadavky, ktoré sa potom na základe kaţdodenných jednaní s klientom zpodrobňujú a dokonca i menia. To zdôrazňuje spoluúčasť zákazníkov na definovaniu poţiadavkou a prenesenie časti zodpovednosti za projekt na zákazníka. 4. Motivovaný jedinci, ktorí majú vytvorené podmienky pre prácu a majú podporu vedenia, sú kľúčovým faktorom úspechu projektu. I keď nasadíme všetky moţné prostriedky a nástroje, sú to nakoniec ľudia, ktorý rozhodujú o úspechu, alebo neúspechu projektu. Ľudia musia byť vhodne motivovaný a projekt musí byť podporovaný všetkými zainteresovanými. 5. Najefektívnejším spôsobom prenosu informácií v rámci vývojového týmu je osobná komunikácie. Agilným metodikám býva vytýkaná nedostatočná dokumentácia. Dokumentácia ale nie je cieľom projektu. Zmyslom dokumentácie je pochopenie problému, ktorého sa omnoho lepšie, rýchlejšie a s menšími nákladmi dosiahne pouţívaním priamych techník komunikácie. 6. Primárnou mierou úspechu je fungujúci software. Ani plnenie plánu, ani existujúca dokumentácia návrhu nezaistí úspech projektu. Je potreba mať fungujúci systém. 7. Agilné procesy predpokladajú zdravý vývoj. Vývojári beţne pracujú nadčasy a i o víkendoch, čo zákonite zniţuje ich produktivitu. Je potreba vymedziť pracovný priestor (cca 40 hodin týţdenne), v ktorom rámci zostane tým v dobrej kondícií. 8. Perfektné technické riešenie i návrh.. Agilní prístupy zdôrazňujú kvalitu návrhu, ktorá je potrebná pre realizáciu zmien. Návrh nie je samostatnou etapou, ktorá je úplne dokončená pred zahájením implementácie, ale je to iteratívna činnosť robená v priebehu projektu. 9. Zásadnou požiadavkou je jednoduchosť riešenia, tzn. umenie maximalizovať množstvo neurobenej práce. 36

37 Pri vývoji software môţeme pouţiť mnoţstvo postupov a metód. V agilných projektoch je kladený dôraz na jednoduché postupy. 10. Najlepšie architektúry, požiadavky a návrhy vznikajú zo samoorganizujúcich sa tímov. Tento princíp zdôrazňuje kreativitu ľudí, častú komunikáciu a prisposobovanie metodiky Prehľad agilných metodík V tejto kapitole si v skratke popíšeme najznámejšie agilné metodiky. Podrobný popis jednotlivých metodík nie je cieľom tejto práce, v prípade záujmu si čitateľ môţe prečítať viac v pouţitej literatúre Extrémne programovanie (Extreme Programming, XP) Najznámejší zástupca agilných metodík. Táto metodika je vhodná pre menšie projekty a malé tímy, vyvíjajúci software podľa zadania, ktoré je nejasné alebo sa rýchlo mení. Jedná sa o tradičné činnosti, ktoré sú však dovedené do extrému. Vďaka tomu by malo byť extrémne programovanie schopné lepšie prispôsobiť sa meniacim poţiadavkám zákazníkov a dodávať software vyššej kvality. Vychádza z presvedčenia, ţe jediným exaktným, jednoznačným, merateľným, overiteľným a nezpochybniteľným zdrojom informácií je zdrojový kód. Základnými hodnotami XP sú: Komunikácia - komunikáciu je tu myslená spolupráca a odovzdávanie si informácií v tíme i spoločne so zákazníkom, jedine touto cestou dospejeme k úspešnému zakončeniu projektu. Jednoduchosť - postupuje sa vývojom vytvorenie čo najjednoduchšieho kódu aplikácie. Odozva - je veľmi dôleţitá spätná väzba zákazníka na novo zapracované zmeny vo vyvíjanom software. Odvaha - je u programátora potrebná, ak napríklad narazí na závaţný problém, ktorého oprava pravdepodobne spôsobí kaskádu súvisiacich problémov. Ďalej XP pozostáva z 12 základných praktík, ktoré môţeme rozdeliť do 3 základných oblastí: business praktiky 37

38 tímové praktiky programovacie praktiky Scrum Kedţe z tejto metodiky sa veľa vychádza pri návrhu vlastnej, tak táto metodika bude podrobnejšie popísaná v samostatnej kapitole Lean development Lean development vychádza z lean manufacturing, ktoré vychádza zo snahy zabrániť problémom na ktoré narazili japonský výrobcovia automobilov pri riadení produkcie (primárne Toyota). Avšak tieto komplikácie boli podobného charakteru ako problémy pri vývoji software. Lean development nespočíva v popisu vývoja software, ale radí akým sposobom zefektívniť vývoj software. Hlavnými princípmi lean developmentu (Lea12), (Poppendieck, 2010): eliminácia plytvania všetky produkty a medziprodukty zvyšujú náklady, preto je nutné odstrániť všetky zbytočné dokumenty, funkcionality, procesy, atď. Nie je nič horšie ako robiť veci efektívne, ktoré pritom nie sú potreba. Systematicky sa majú hľadať a eliminovať zdroje plytvania. rozvíjanie učenia vývoj software je kontinuálny proces behom ktorého členovia tímu získavajú nielen technické vedomosti, ale i vedomosti z danej domény, z oblasti komunikácie, atď. Preto najlepšie ako skvalitniť vývoj je zefektívniť získavanie skúseností. rozhodovanie sa čo najneskoršie vývoj software je vţdy spojený s určitou neistotou, čím je systém komplexnejší tým viacej chýb môţe vzniknúť pri včasnom návrhu. Preto radšej odďaľovať rozhodnutia na čo najneskôr, kým môţu byť zaloţené na faktoch, radšej ako na predpokladoch. doručovať dodávky čo najskôr čím skôr je koncový produkt dodaný klientovi, tým skôr je získaná spätná reakcia, ktorá môţe byť následné zapracovaná povzbudzovanie pracovníkov k ľuďom sa nemá pristupovať ako ku zdrojom, ale ľudia potrebujú ciele, výzvy a zodpovednosť 38

39 Integrita autori rozdeľujú vnímanú integritu a konceptuálnu integritu. Vnímaná integrita je zákazníkove vnímanie produktu, kým konceptuálna integrita sa zameriava na všetky zloţky produktu, ako architektúra, komponenty, atď. Aby spolu dobre pasovali a aby sa dosiahlo vnímanej integrity sa zaisťuje pomocou testovania a refaktorizácie. Vidieť celok dnešné systémy nejde povaţovať len za jednoduchý súčet ich častí, ale i za výsledok ich interakcie. Pri meraní neefektívnosti, alebo chybovosti sa nemajú hodnotiť jednotlivé časti, ale celok Crystal metodiky Uţ z názvu je zrejmé, ţe sa nejedná len o jednu metodiku, ale o celú rodinu metodík. Autor vychádza z toho, ţe aj tá najlepšia metodika nemôţe vyhovovať kaţdému projektu a je lepšie prispôsobiť metodiku na mieru danému projektu. Dalo by sa povedať, ţe prvou fázou vývoja je vlastne vytvorenie metodiky. Kritériami pre výber správnej metodiky je napríklad veľkosť projektu, veľkosť vývojového tímu alebo kritickosť projektu Feature Driven Development (TDD) Keďţe z tejto metodiky sa veľa vychádza pri návrhu vlastnej, tak táto metodika bude podrobnejšie popísaná v samostatnej kapitole Test Driven Development Autori metodiky nepovaţujú testovanie len za jednu fázu vo vývoji, ale priraďujú mu najvyššiu dôleţitosť. TDD zavádza, ţe pre kaţdú sebe menšiu funkcionalitu, najprv napíšeme test, ktorý ju dokáţe dostatočne otestovať a aţ potom ju implementujeme. Naviac implementujeme presne také mnoţstvo, ktoré je schopné prejsť testom, nič naviac. Následne zdrojový kód optimalizujeme a odstránime duplicity. TDD zavádza jednotkové testovanie (unit testing), kde za jednotku sa povaţuje. 39

40 4.5 Scrum Scrum je agilná metodika unikátna v tom ako pristupuje k celkovému riadeniu projektu. Scrum je zaloţený na poznaní, ţe vývoj prináša veľa nepredvídateľných udalostí, tým sa stáva zloţitým a preto je potrebné mať metodiku, ktorá dokáţe rýchlo a flexibilne reagovať na zmeny. Skôr ako na samotné procesy implementácie, sa zameriava na manaţérske riadenie. Bol vyvinutý pre podporu riadenia vývojového procesu. I podľa definície (metodického) rámca (frameworku) (viď kapitola 2), alebo podľa definície od jedného zo zakladateľov Ken Schwabera 5, Scrum je skôr framework, alebo manaţérska metodika. Srum nie sú procesy alebo techniky na vybudovanie produktu, ale skôr sa jedná o framework s ktorým je moţné pouţiť rozne procesy a techniky [7]. Neuvádza konkrétne nástroje, technologie, postupy, ktoré by mali vývojári pouţiť, ale zaoberá sa tým, ako by mal tým počas celého vývoja spolupracovať a komunikovať. Avšak mnoho zdrojov pouţíva výraz metodika, tak pre konzistenciu tohotu textu budeme takito pouţívať Scrum s týmto spojením Role Dôleţitou vlastnosťou, ktorá odlišuje Scrum od tradičných metodík, je zapojenie zákazníka do tímu a rozhodovaní o prioritách implementovaných funkcionalít. Tím je rozdelený na dva základné typy rolí - kurčatá a prasatá. Ich pomenovanie vychádza z bájky o kurčaťu a prasaťu, ktorí sa rozhodnú zaloţiť reštauráciu a premýšľa, ako ju pomenujú. Kura príde s nápadom "Ham & Eggs", čo sa prasaťu nepáči, pretoţe kurčaťa by sa proces iba týkal, kde prasa by bolo priamo zapojené. Ak by reštaurácia bola firma, potom kurčatá budú zákazníci, ktorí poskytnú poţiadavky a prostriedky na realizáciu projektu, prasatá potom zamestnanci firmy, ktorí zapojením vlastného úsilia vytvoria produkt. 5 spolu s Jeff Sutherland-om formuloval povodnu verziu Scrumu 40

41 Stakeholdery Jediný reprezentanti tzv. kurčiat. Všetky zainteresované strany v rámci projektu. Jedná sa o koncových uţívateľov vyvíjaného systému, investorov, manaţérov firmy, ktorá software vyvíja Scrum team Scrum tím pozostáva z vlastníka produktu, vývojového tímu a scrum mastera. Vývojový tím moţe obsahovať interaction designera, front-end vývojára, back-end vývojára, copywritera, atď. Tím sa vyznačuje ţe je samo-organizujúci a multi-funkčný. Samo-organizujúci tím si sám určuje ako dokončiť zadanú prácu radšej ako byť riadený niekým mimo tím. Multifunkčný tím má všetky kompetencie potrebné na dokončenie úlohy, bez potrebnosti ďalších ľudí mimo tímu. Model tímu v Scrum-e, je navrhnutý tak, aby optimalizoval flexibilitu, produktivitu a kreativitu (Ken Schwaber, 2011) Scrum master Primárna rola je uľahčovanie vecí a motivovanie tímu. Takisto zaisťuje, ţe denné zrazy, retrospektívy sa vţdy konajú v dohodnutý čas, a bez prekáţok. Scrum master sa stará o tím, motivuje ho, vylepšuje spoluprácu, ukazuje a diskutuje problémy a zaisťuje celkovo pozitívnu atmosféru Product owner Vlastník produktu, predstavuje záujmy stakeholderov. Vlastník produktu je zodpovedný za tvorbu poţiadavkou, návratnosť investíc (ROI) a plán vydania (release plan). Poţiadavky sú zachytené v artefakte product backlog pomocou uţivateľských príbehov, ktoré píše pomocou scrum mastra. Vlastník produktu taktieţ určuje prioritu jednotlivých poloţiek v product backlogu. Priority určuje po diskusií s členmi tímu. Väčšinou vlastník produktu prichádza zo strany zákazníka. Vlastník produktu sa takisto musí pravidelne účastniť schôdzok tímu, aby priamo odpovedal otázky a robil rovno rozhodnutia. Toto je dôleţité kvôli pokroku vývoja, preto je dôleţité aby táto osoba mala dostatočné poverenie na rozhodnutia z firmy z ktorej pochádza. 41

42 4.5.2 Artefakty Scrumu Product backlog Product backlog obsahuje všetky poţiadavky na funkcionalitu produktu. Zodpovednosť za product backlog nesie bez výnimky Vlastník produktu (Product owner). Product backlog sa stále mení podľa aktuálnych potrieb a nikdy nie je úplný. Vlastník produktu pomocou určenia priority, má priamy vplyv na poloţky budúceho šprintu. Presnú podobu backlogu Scrum nedefinuje, často sa jedná o obyčajný dokument v Exceli alebo lepiace kartičky na tabuľi. Poloţky product backlogu sú spočiatku definované len v hrubých obrysoch, detaily sú spresnené, aţ keď je na ne zameraná pozornosť ako na poloţky s vysokou prioritou. Pre poloţky backlogu sa najcastejšie pouţívajú uţívateľské príbehy. Product backlog by mal podľa [9] dodrţiavať zásady DEEP. Vhodne detailný (Detailed appropriately) - spolu s rastúcou prioritou poloţiek, a teda aj zvyšujúci sa pravdepodobnosťou ich skorého zaradenia do šprintu, rastie aj miera detailu, do ktorej sú rozpracované. Z počiatku sa jedná o rozsiahle uţívateľské príbehy (eposy), tie sa postupom času zpresňujú do uţivateľských príbehov. Odhadnutý (Estimated) jednotlivým poloţkám sú priradené odhady. Aktuálny (Emergent) - product backlog sa neustále mení. Prioritizovaný (Prioritized) - poloţky, ktoré sľubujú priniesť produktu najvyššiu hodnotu, majú najvyššiu prioritu Priebeh Projekt podľa Scrumu prechádza tromi fázami. Predohra (pre game) sa skladá z plánovania a prípravy na projekt (voľba nástrojov, identifikácia rizík, analýza, tvorba product backlogu atď.). V hre (game) prebieha samotný vývoj pomocou cyklu iterácií. A v dohre (post game) prebieha uzavretie projektu. Akonáhle schváli zákazník, ţe produkt splňuje poţiadavky, tak nasleduje táto fáza (finálne testovanie, integrácia, prípravy na spustenie projektu, atď.). 42

43 Princípom tejto metodiky, ako všetkých agilných metodík je iteratívny a inkrementálny vývoj. V tomto prípade sa jedná o 3-8 fází, tzv. šprintov (sprint), kaţdý z nich trvá pribliţne mesiac. Metodika nedefinuje ţiadne konkrétne procesy. Obrázok 4 SCRUM proces Na začiatku projektu stojí vízia, ktorá môţe byť formulovaná i vcelku vágne, s upresnením sa totiţ počíta neskôr. Vlastník produktu na základe vízie spíše poţadovanú funkcionalitu, ktorá maximalizuje návratnosť investícií. Spraví tak pomocou product backlogu a prioritizáciu jeho poloţiek. Poloţky z backlogu, ktoré majú podľa vlastníka produktu najvacsiu hodnotu pre výsledný produkt, ohodnotí najvačšiou prioritou. Jednotlivým iteráciam sa v Scrumu hovorí šprinty. Hoci doporučovaná dĺţkou pre jeden šprint je zhruba 30 kalendárnych dní, Scrum je flexibilný natoľko, ţe sa beţne stretávame aj so šprintami, ktoré trvajú menej ako týţdeň. Na začiatku kaţdého šprintu prebieha plánovanie šprintu (Sprint planning meeting). Toto stretnutie nesmie trvať dlhšie ako osem hodín (pre kratšie ako 30-dňové šprinty je potom táto hodnota adekvátne niţšia). V prvej polovicu prideleného času vlastník produktu pomocou prioritizácie prvkov v product backlogu povie tímu, čo sa poţaduje. Tím potom po úvahe oznámi vlastníkovi produktu, koľko z poţadovaných funkcí stihne vypracovať v nadchádzajúcom šprinte, čo je zanesené do šprint backlogu. V druhej polovici stretnutia tím plánuje priebeh šprintu. Týmto plánovaním začína plynúť čas šprintu. Týmu je ponechaná voľnosť ako výsledku dosiahne, tým riadi sám seba, ako sme si spomínali v predchádzajúcej kapitole. 43

44 Existuje veľa spôsobov ako ohodnotiť poloţky backlogu, napr. pomocou plánovacieho pokru, známeho z extrémneho programovania (Jongerius). Konkrétna technika bude popísaná v praktickej časti, pri návrhu metodiky. Poloţky sa odhadujú tímovo, nezávisle na tom, ktorý člen ich bude implementovať (Jongerius), priradenie práce konkrétnemu členovi tímu prebieha aţ na príslušných denných zrazoch (daily scrum). Výstupom jednotlivých šprintov je pouţiteľný hotový prírastok produktu, ktorý sa predvedie zákazníkovi, aby mohol poskytnúť spatnú väzbu. Hotový prírastok produktu garantuje vţdy funkčnú verziu produktu, ktorá moţe byť nasadená, v prípade rozhodnutia zákazníka. Preto je doleţité si definovať, kedy je hotovo. Denné zrazy sú jedným z najdôleţitejších a najinovatívnejších prvkov Scrum-u. Toto stretnutie trvá iba 15 minút a prebieha výhradne postojačky, aby bola u úcastníkov podporená tendencia ku stručnosti vyjadrovania. Denné zrazy umoţňujú korigovať smerovanie projektu a synchronizovať vývojárov, ktorý na ňom pracujú. Kaţdý člen tímu pri zraze odpovedá na nasledujúce tri otázky: Čo som na projekte urobil od posledného fenného zrazu? Čo plánujem urobiť na projekte do budúceho denného zrazu? Aké prekáţky stoja v ceste splnenia úkolov v rámci tohoto šprintu a projektu? Šprint je ukončený dvoma schodzkami. Na revízií šprintu (sprint review meeting) prezentuje tím vlastníkovi produktu a prípadným ďalším stakeholderom spravenú prácu. Cieľom tohto neformálneho stretnutia je povzbudiť všetkých k ďalšej práce tímu. Vzhľadom k faktu, ţe výstupom šprintu je funkcný prírrastok, môţe dôjsť k dohode tento prírastok nasadiť do reálneho provozu. Druhé stretnutie, retrospektíva šprintu (sprint retrospective meeting), sa zaoberá vnútornými procesmi tímu a Scrum Master na ňom dodáva tímu motiváciu a podnety k zlepšeniu efektivity a zábavnosti práce. 44

45 4.5.4 Zhodnotenie Hlavnou výhodou je, ţe Scrum pruţne reaguje na zmeny, ktoré vznikajú v priebehu projektu. Vďaka kaţdodennej komunikácií, reflektovaniu zmien a hľadaniu rizík, je ľahké zmeniť smerovanie projektu podľa prianí zákazníka. Nevýhodou, ak to tak môţeme nazvať, je iba zameranie na riadenie projektu, teda metodika neposkytuje ţiadne konkrétne procesy, postupy. I samotný autori metodiky uvádzajú, ţe nasadenie Scrumu je najvhodnejšie ak firma uţ pouţíva nejakú metodiku, má definované procesy, či uţ implementačné alebo iné a Scrumom sa snaţí sa snaţí zlepšiť sposob riadenia projektov. 4.6 Feature Driven Development Metodika povaţuje za kľúčové piliere projektu vlastnosti, prvky (features) projektu a ľudí. Vraví, ţe výsledný produkt je to jediné k čomu by mala naša snaha smerovať. Vlastnosť je definovaná ako malý funkčnosť funkcionality, ktorý prináša uţitnú hodnotu pre zákazníka. Doleţitými vlastnosťami sú: merateľnosť potreba rozhodnúť, či implementovaná vlastnost, je zhodná s poţadovanou vlastnosťou od zázníka zrozumiteľnosť musí byť zrejmé čoho sa vlastnost týka a čo je výsledkom realizovatelnosť doba implementácie, nemoţe presiahnuť dobu jednej iterácie, inak sa vlastnosť rozdelí na menšie FDD predpisuje i formát vlastností: akcia - označuje činnosť v rámci vlastnosti predmet artefakt, na ktorom sa daná akcia robí podrobnosti upresňujú vlastnosť, pridávajú ďalšie poţiadavky, alebo ju špecializujú na konkrétny účel Hlavná myšlienka je, ţe výsledný produkt je moţno rozdeliť na jednotlivé vlastnosti a tie postupne vyvíjať. Kvalita aplikácie, projektu, je zaručená, čo najlepšou implementáciou kaţdej z vlastností. Snaha autorov, takisto ako v prípade Scrum-u, alebo obecne agilných metodík, je podať návod ako pracovať efektívne, produktívne, bez zbytočných rozvratov a hlavne ako tráviť pracovný čas čo najpríjemnejšie, bez zbytočných byrokratických úkonov. 45

46 4.6.1 Praktiky Takisto ako iné metodiky vývoja software je FDD postavené na kľúčovej skupine praktík. Tieto praktiky nie sú nové, ale prínos FDD spočíva v správnej kombinácií týchto techník a praktík, ktoré sa navzájom ovplivňujú. Celkový výsledok potom prináša omnoho lepsšie výsledky ako jednotlivé časti. Praktiky, z ktorých sa skladá FDD a sú (Palmer, 2002): doménové objektové modelovanie vývoj podľa vlastností vlastníctvo tried (Individual Class Ownership), tímy pre vlastnosti (Feature Teams), inšpekcia (Inspections) pravidelné buildy (Regular Builds), riadenie konfiguracií (Configuration Management), reporting/viditelnosť výsledkov (Reporting/Visibility of Results) Role Takisto ako FDD striktne udáva ako sa majú vlstnosti popisovať, tak presne špecifikuje i role, ktoré majú presne definované čo je ich úlohou v jednotlivých fázach vývoja. Projektový manažér - je administratívnym i finančným vedúcim projektu. Jednou z jeho úloh je zaisťovať projektovému týmu dobré pracovné podmienky, aby všetcia členovia tímu boli spokojný a mali z práce radosť a nič im nenarušovalo efektivitu práce. Zodpovedá za rozsah projektu, časový harmonogram a obsadenie tímu. Hlavný architekt - je zodpovedný za celkový návrh systému. Organizuje s tímom schodzky a workshopy kvoli návrhu a zodpovedá za celkový návrh. Táto funkcia moţe byť rozdelená na doménového architekta a technického architekta. Vývojový manažer - má na starosti aktivity spojené s kaţdodenným vývojom. Jeho úkolem je riešiť problémy vovnútri tímu. Túto rolu často obsadzuje rovnaký človek ako 46

47 projektového manaţera alebo hlavného architekta, lebo zodpovednosti sa kryjú. Hlavný programátor - tuto rolu vačšinou zastupuje skúsený vývojár, ktorý sa podieľa na analýze poţiadavkov a návrhu systému. Je zodpovedný za vedenie malých tímov, ktoré v jednotlivých iteráciach navrhujú a vyvíjajú nové vlastnosti. Z mnoţiny vlastností vyberá tie, ktoré sa budú implementovaťa určuje vlastníkov tried. Pravidelne podáva spravu o pokroku v projekte za svoj tím. Vlastník triedy - je pod vedením hlavného programátora a jeho prácou je návrh, kódovanie, testovanie a dokumentácia jednotlivých konkrétnych vlastností. Je zodpovedný za vývoj triedy, ktorej je vlastníkom. Z vlastníkov tried sa formujú tímy pre vlastnosti, ktoré sa menia podľa toho, ktoré triedy v rámci iterácie, implementované vlastnosti ovplivňujú. Doménový expert moţe byť koncový uţivateľ, klient, sponzor, obecne človek, ktorý dokonale rozumie cieľovej oblasti. Predáva tieto poznatky vývojárom aby zaistil, ţe sa vyvíja skutočne to, čo má. Ďalej FDD definuje mnoho ďalších rolí, ktoré uţ nebudeme popisovať ako napr. manaţer dodávok, jazykový špecialista, nástrojár administrátor, tester, atď Procesy FDD definuje narozdiel od Scrum-u popisuje vývoj softwaru vo forme procesov. Zameriava sa hlavne na proces návrhu a implementácie. Význam procesov však nepreceňuje, lebo cieľom nie je splnenie predpísaného procesu, ale vytvorenie fungujúceho software, ktorý splňuje poţiadavky zákazníka. FDD definuje ľahké procesy, kde kaţdý z nich popísaný na 2 stránkach (Buchalcevová). Popis procesu má byť čo najkratší, doporučuje sa pouţiť vzor ETVX (Luca). Vstupy (Entry) jasne vyšpecifikované vstupné kritéria. Proces sa zaháji vstupmi, alebo, tzv. spúštačmi (triggers). Úlohy (Tasks) vymenovanie všetkých úloh, ktoré je potrebné splniť v rámci procesu. 47

48 Verifikácia (Verification) nástroje verifikácie. Po prevedení všetkých úloh v rámci procesu, nastáva verifikácia, ktorá zaisťuje, ţe všetky výstupné kritéria boli splnené. Výstupy (exit) - výstupné podmienky procesu (fyzické výstupy, dokumenty, prototypy,atď.). Podrobnejšie bude tento vzor a jeho pouţitie popísané v kapitole 8. Procesy definované FDD môţeme vidieť na obrázku niţšie. Obrázok 5 Procesy FDD [12] Vypracovanie celkového modelu Náplňou tohto procesu je vypracovanie hrubého modelu celej domény. Vývojári i doménový experti (moţu byť priamo i klienti) pracujú spoločne pod vedením hlavného architekta. Vývojári a doménový experti vytvoria kostru modelu a uţivatelia potom špecifikujú pouţitie systému. Vzniknutý model prezentuje základný účel systému a je smerodatný pre všetkých zúčastnených. Je abstraktný a nezachádza do podrobností. Je Je objektový a zapísaný pomocou UML. Výstupom je najčastejšie diagram tried a alternatívy riešenia Vypracovanie zoznamu vlastností V ďalšej fázy hlavný programátor, hlavný architekt a doménový expert zostaví tím pre vytvorenie zoznamu vlastností. Výstupnými kritériami sú hotový zoznam hlavných oblastí domény, zoznam obchodných procesov ku kaţdej oblasti a zoznam vlastností. 48

49 Príklad obchodného procesu moţe byť prihlasenie uţívateľa do systému pomocou uţivateľskeho mena a hesla. Tento proces vyvolá niekoˇko krokov, ktorým potom odpovedajú jednotlivé vlastnosti, napr.kontrola existencie u6ivate+lsk0ho mena, overenie správnosti hesla, pridelenie prístupových práv. Zoznam vlastností musí byť kradený podľa priorít a má pokrývať čo najviac poţiadavkov na systém. V tejto fázi však není ešte definitívny Plánovanie podľa vlastností Najprv sa stanoví dátum ukončenia vývoja produktu. To má byť definitívne a jemu sa majú prispôsobiť ostatné medzníky, ako dokončenie implementácie jednotlivých vlastností. Následne sa pridelia vedúci programátori obchodným procesom a vlastníci tried. Títo ľudia odpovedajú dokončeniu ich práce do určitého dátumu. Na základe priorít a vzájomných závislostí medzi vlastnosťami sa rozhodne o poradí, v ktorom sa budú implementovať. Nejde však o striktnú a nemennú postupnosť. 49

50 5 Metodiky projektového riadenia Kým metodiky vývoja software, sa zaoberajú riadením samotného vytvorenia software, tak projektové metodiky majú širší záber, podľa kritéria rozsahu majú vačší rozsah, pokrývajú celé riadenie projektu od začiatku aţ do konca, vrátane celej administratívy i samotného vývoja software. Tieto metodiky sa môţu vzájomne kombinovať. Dalo by sa povedať, ţe metodika projektová riadenia je nad metodikou vývoja software. V terminologií PRINCE2 by metodiku vývoja software mohol vyuţívať team manaţer v rámci fáze Manaţovanie doručenia produktu (Managing Product Delivery). Fáze projektovej metodiky moţu byť namapované na fáze metodiky vývoja software, napríklad jedna fáza projektovej metodiky moţe pozostávať z viacerých fáz metodiky vývoja software. Keďţe v dnešnej dobe existuje takisto nepreberné mnoţstvo metodík projektového riadenia (a to i iba tých oficálnych a pritom ešte veľa vačších firiem má svoje vlastné metodiky), a nie je ani moţné v rozsahu tejto práce a ani cieľom spraviť ucelený prehľad, tak v nasledujúcich riadkoch si detailnejsšie rozoberieme iba tie najznámejšie a najpouţívanejšie vo svete. 5.1 PRINCE2 PRINCE2 moţeme podľa kritéria váhy zaradiť medzi taţké metodiky, lebo detailne definuje všetky procesy. Vlastníkom, tvorcom tejto metodiky je Office of Governemt Commerce (OGC), ktorý je súčasťou britskej vlády. Táto inštitúcia vytvorila aj dalšiu známu metodiku pre riadenie sluţieb ITIL. Metodika PRINCE2 (Projects in Controlled Environment) bola vytvorená viac ako sto päťdesiatimi spoločnosťami s mnohoročnými skúsenosťami v oblasti projektového riadenia a je dnes najrozšírenejšou PM metodikou v Európe. Pri popise metodiky sme výchádzali primárne z (Turley, 2010). PRINCE2 stojí na siedmich princípoch, tvorí ju sedem procesov a popisuje sedem tém. Vzhľadom k nutnosti prispôsobiť metodiku PRINCE2 v rámci aktuálneho prostredia 50

51 projektu, je nutné porozumieť týmto princípom, bez dodrţiavania všetkých siedmych princípov, nemoţme povedať, ţe sa jedná o projekt riadený pomocou PRINCE2. Dokumenty je moţné zdruţovať, zjednodušovať, prípadne nepouţiť. Procesy môţu byť veľmi zjednodušené a kaţdý z nich má veľa moţností pouţitia podľa veľkosti projektu. Princípy ale zostávajú a zaručujú, ţe projekt je projektom PRINCE2, čiţe projektom v kontrolovanom prostredí. Podpora prispôsobenia metodiky zahrnutá priamo v manuáli je významnou prednosťou tejto metodiky. Princípy PRINCE2: priebeţné zdovodňovanie projektu poučovanie sa zo skúseností definované role a zodpovednosti riadenie pomocou etáp dohľad nad projektom na základe výnimiek doraz na produkty nutnosť upraviť metodiku podľa aktuálneho prostredia Ďalšou významnou prednosťou PRINCE2 je popisnosť charakteru nielen na úrovni procesov, ale aj dokumentov. PRINCE2 necháva síce na jednej strane priestor na prispôsobenie, na strane druhej ale vedie projektového manaţéra všetkými kľúčovými činnosťami, počnúc projektovým mandátom, ktorý projekt spúšťa, aţ po schválenie ukončenia projektu riadiacou radou. Rozdeľuje začiatok projektu na dva kroky. V prvom kroku dá projektový manaţér dohromady základné podklady pre to, aby mohol projektový výbor posúdiť, či sa vôbec púšťať do často nákladného plánovania. Iba v prípade, ţe riadiaci výbor je presvedčený o zmysluplnosti a finančnej návratnosti projektu, dáva svoje schválenie a začína fáza stanovovania projektových stratégií, plánovanie projektu, nastavenie komunikácie, projektových kontrol a v neposlednom rade naplánovanie projektu a spísanie obchodného prípadu (business case). 51

52 Obrázok 6 Štruktúra PRINCE2 [2] V PRINCE2 jednoznačný proces určujúci fungovanie riadiaceho výboru. Právomoci a zodpovednosti za vývoj projektu sú jednoznačne stanovené a rozdelené medzi projektového manaţéra a riadiaci výbor projektu. PRINCE2 dáva dokonca plnú zodpovednosť za projekt do rúk sponzora projektu predsedajúceho riadiacemu výboru, a nie samotnému projektovému manaţérovi. Toto rozdelenie vnáša do metodiky jasný poriadok a hlavne menej skúseným projektovým manaţérom vymedzuje pravidlá hry. Po naplánovaní projektu a vypracovanie obchodného prípadu (zdôvodnenie projektu či obhájenie investície) opäť prichádza schválenie riadiaceho výboru, ktorý dáva pokyn k začatiu následnej etapy. Práve striktné rozdelenie projektu na etapy dáva zodpovedným manaţérom moţnosť včas identifikovať prípadné problémy a zasiahnuť. V projektoch PRINCE2 by teda nemalo dochádzať k tomu, ţe vedenie projektu pozná aţ príliš neskoro nevyhnutné prekročenie rozpočtu alebo zásadné nedodrţanie časového harmonogramu. Etapy projektu podľa PRINCE2, môţeme vidieť na nasledujúcom obrázku: 52

53 Obrázok 7 Fáze projektu PRINCE2 [2] (vlastná úprava autor) Predprojektová a post-projektová etapa, nie sú súčasťou rozsahu projektu. Minimálny počet etáp který môţe mať projekt sú 2 a to Iniciačnú etapu a Ukončovaciu etapu. Projekt PRINCE2 je riadený siedmimi procesmi a ich aktivitami (podprocesmi), ktoré siahajú od predprojektovej prípravy a vytvorenia rámcového zdôvodnenia projektu aţ po ukončenie projektu: Pre-projektová príprava (Starting up a Project) Predprojektová príprava sa začína obdrţaním Mandátu projektu s jednoduchým popisom produktu projektu. Na začiatku zahájenia sa vymenuje výkonný riaditeľ projektu (Executive) a projektový manaţér, následne sa zozbierajú relevantné ponaučenia z minulosti a vymenuje celý riadiaci tím projektu. Pre kaţdý projekt je nutné zohľadniť, či je projekt realizovateľný a stojí za vynaloţené úsilie, čas a financie - teda vytvoriť jeho rámcové zdôvodnenie (outline business case). Je nutné nadefinovať spôsob, akým sa ku projektu pristúpi (Project Approach), zostaviť Popis projektu (Project Brief) a naplánovať iniciačnú etapu. Iniciácia projektu (Initiating a Project) V rámci tohto procesu sa vytvárajú stratégie riadenia rizík, kvality, konfigurácie a komunikácie, ako aj registre rizík, problémov (issues) a kvality. Ďalej je nutné vytvoriť plán projektu, v jeho rámci dekomponovať produkt projektu na jednotlivé produkty a naplánovať ich dodanie. Následne projektový manaţér spresní Zdôvodnenie projektu, nastaví kontrolné mechanizmy (ovládače) projektu a dokumenty podáva na schválenie Projektovej rade, ktorá autorizuje projekt. Strategické riadenie projektu (Directing a Project) 53

54 Proces, ktorý siaha od začiatku aţ po koniec projektu. Projektová rada strategicky riadi projekt a vykonáva rozhodnutia, ktoré presahujú právomoci projektového manaţéra. Schvaľuje iniciáciu i začiatok realizácie projektu, kaţdý plán etapy či výnimky, dáva ad hoc usmernenia, jedná s vedením organizácie či programu (corporate/ programme management) a potvrdzuje ukončenie projektu. Riadenie etapy (Controlling a Stage). Je proces, závislý na rôznych iných procesoch, v ktorom projektový manaţér zadáva úlohy vedúcim tímov, zisťuje progres ich plnenia, zachytáva a vyhodnocuje problémy (issues) a následne ich sám rieši alebo postupuje projektovej rade, pokiaľ ohrozujú toleranciu etapy. Projektový manaţér pravidelne podáva projektovej rade správy o stave etapy. Riadenie dodávky produktu (Managing Product Delivery). Vedúci tímu na začiatku procesu akceptuje pracovný balík (teda popis toho, čo má dodať a ako pri tom postupovať) od projektového manaţéra. Pracovný balík zrealizuje (počas realizácie podáva projektovému manaţérovi správy o kontrolných bodoch). Keď daný pracovný balík dokončí, dodá ho projektovému manaţérovi, ktorý v procese Riadenie etapy príjme dokončený pracovný balík. Riadenie hraníc etapy (Managing a Stage Boundary). Tento proces zvyčajne začína blízko konca beţiacej etapy. Keď sa etapa končí, treba ju vyhodnotiť a naplánovať ďalšiu etapu. Druhý prípad je, ţe projektová rada posúdi výnimku oznámenú projektovým manaţérom za natoľko závaţnú, ţe mu uloţí vypracovať Plán výnimky. V tomto procese sa vytvára Správa o ukončení etapy, plánuje sa nová etapa, aktualizuje sa Plán projektu aj Zdôvodnenie projektu a tieto dokumenty projektový manaţér odovzdáva na schválenie projektovej rade. Ukončenie projektu (Closing a Project). Je proces, ktorý projektový manaţér vykoná na konci poslednej etapy. Projektový manaţér pripraví ukončenie projektu, zabezpečí formálne odovzdanie produktov i vyhodnotenie projektu a podá projektovej rade návrh na ukončenie projektu. Projektová rada musí následne tento návrh schváliť (v procese Strategické riadenie projektu), čím sa projekt končí. Prehľad procesov a etáp a ich vzájemné prepojenie moţme vidieť v prílohe A. 54

55 Okrem spomínaných siedmich procesov identifikoval PRINCE2 sedem tém a rozpracoval ich tak, aby dávali projektovému manaţérovi dostatočné vodítko pri zachovaní priestoru pre modifikáciu: Business Case vysvetľuje, ako postaviť zmysluplné zdôvodnenie projektu. Organization popisuje jednotlivé role a väzby medzi nimi. Plans hovorí o jednotlivých úrovniach plánu a ukazujú spôsoby a techniky, ako postaviť kvalitný plán. Téma Progress ponúka nastavenie kontrol medzi riadiacim výborom a projektovým manaţérom. Risk definuje prípadné hrozby alebo príleţitosti a navrhuje, ako takéto hrozby identifikovať a proaktívne sa im brániť. Téma Quality stavia do popredia zákazníkom definované očakávania kvality výsledného produktu a ukazuje cestu projektom tak, aby na konci bola kvalita zabezpečená a preukázaná. Téma Change pomáha projektu vyrovnať sa so zmenami rozsahu v priebehu dodávky a pomocou navrhnutého riadenia konfigurácií udrţiava poriadok vo verziách, a dodávke vôbec. 5.2 PMBOK PMBOK (Project Management Body of Knowledge) je takisto veľmi často povaţovaný za projektovú metodiku, pričom tomu tak nie je, nie je to ale ani metóda. Podľa samotnej definície v PMBOK, je to framework pre projektový manaţment[4], je to zbierka uznávaných štandardov pre projektový manaţment. Kedţe je to ale medzinárodne uznávaný štandard pre projektové riadenie, tak si ho rozoberieme podrobnejšie. PMBOK je prácou mnoho autorov a podlieha priebeţným revíziám. Vlastníkom PMBOK je renomovaná americká nezisková organizácia PMI (Project Management Institute) zaloţená v roku PMI určuje štandardy, usporadúva výskumy a vzdeláva v oblasti projektového riadenia a odvodených disciplínach. K dnešnému dňu sa pýši jej certifikátom PMP (Project Management Professional) viac ako päťsto tisíc projektových manaţérov. 55

56 Štandard PMBOK je zaloţený na piatich procesných skupinách a deviatich znalostných oblastiach. Prvá procesná skupina Initiation obsahuje len dva kroky. Vytvorenie charty projektu a identifikáciu zainteresovaných ľudí a skupín. Jadrom procesných skupín je Planning, ktorého kľúčovým výstupom je práve plán projektu. Projektový plán sa buduje na základe troch podstatných vstupov: rozsahu, rozpočtu a času. Ďalšie procesné skupiny Executing, Monitoring & Controlling, Closing. Kedţe PMBOK není metodikou, tak má omnoho slabšie popísaný procesný model. Ale o to viac má prepracované znalostné oblasti. Väčšia hĺbka je vidieť takmer vo všetkých vedomostných oblastiach podporujúcich plánovanie projektu. Medzi znalostné oblasti PMBOK patrí: Project Integration Management Integration Management spojuje a integruje všetky ostatné oblasti. Project Scope Management definuje kroky vedúce k vytvoreniu rozsahu projektu a k jeho udrţaniu. Zahrňuje i riadenie zmien. Prvým krokom je zber poţiadavkov Project Time Management oblasť zaoberajúca sa vytvorením harmonogramu na základe činností. PMBOK kladie veľký doraz na kritickú cestu a prácu s ňou. Project Cost Management primárnou témou je vytvorenie rozpočtu, ale takisto PMBOK v tejto oblasti rozoberá aj metodu Earned Value Management. Project Quality Management oblasť zaoberajúca sa zaručením kvality Project Human Resources Management Project Communications Management detailný pohľad na riadenie komunikácie, a hlavne na prácu s jednotlivými zainteresovanými stranami Project Risk Management predstavenie kvantitatívnych metód na odhad rizik Project Procurement Management stručné rozobranie problematiky riadenia zmlúv, takisto aj rozdelenie typov zmlúv. 56

57 5.3 Slobodná firma I keď v tomto prípade sa nejedná o projektovú metodiku, rozhodol som sa zmieniť i tento koncept v tejto práci. Jedná sa skor o koncept firmy a majitelia spoločnosti PURE IDEAS sa dohodli, ţe budú fungovať na základe tohto konceptu. Kedţe nie je cieľom práce detailne popisovať tento koncept, tak aspoň zmienim základné princípy, ktoré v mnohom ovplivnili definíciu vlastných firemných princípov a celkové smerovanie firmy. Viacej informacií o tomto koncepte je moţné sa dočítať vo výbornej knihe od českého autora Tomáša Hajzlera, ktorý je hlavným propagátorom tejto revolučnej myšlienky v čechách Peníze, nebo ţivot. I keď sa to na prvý pohľad nemusí zdať tak koncept slobodnej firmy má mnoho spoločného s agilným vývojom. Ako spomína Tomáš Hajzler Tak ako sa premenil napríklad web zo statického 1.0 na interaktívny 2.0, mení sa i svet firiem. Stále vačší počet prechádza od riadenia k seberiadeniu, od hierarchie k spoločenstvu, či od striktných pravidiel k princípom. Uvedomujú si, že v 21. Storočí je možné prežiťiba ak budú ich ľudia (i v práci) robiť to v čomm sú najlepší a čo ich opravdu baví. Na princípoch slobodnej firmy funguje napríklad legendárna Harrley-Davison, nábytkársky gigant IKEA, kultovná outdoorová Patagonia a mnoho ďalších zahraničných firiem. Z českých s slovenských firiem stojí určite za zmienku veľká digitálna agentúra Et Netera, alebo veľmi populárne kníhkupetstvo Martinus. Zaujímavým faktom je, ţe okrem vysoké miery nasadenia a nadšenia, vykazuje vačšina týchto firiem trvalý rast v dvojciferných číslach Princípy slobody v práci Firma, v ktorej moţu ľudia robiť, to čo ich skutočne baví sa od tej v ktorej manaţéri zamestnancom definujú pracovné povinnosti, liší predovšetkým v princípoch na ktorých stavia. Tu je desať základných princípov slobody v práci [14]: 1. Zmysel a vízia Keď organizácia a jej zamestnanci poznajú dovod přečo ich firma, projekt existuje a sdieľajú spoločný smer. 2. Dialog a naslúchanie Keď netrváme na jednej pravdě, ale dokáţeme pripustiť rozne uhly pohľadu. 57

58 3. Fair play a dostojnosť Keď sa dokáţeme chovať ku kaţdému človeku férovo, tj. podľa jeho zásluh. 4. Transparentnosť - Keď myšlienky voľne plynú a informácie zdieľame slobodne a zodpovedne. 5. Zodpovednosť Keď je kaţdý človek i organizácia ako celok zodpovedný jeden druhému i spoločnosti za svoje správanie. 6. Jednotlivo a spoločne Keď jednotlivci rozumejú a berú za svoje to, ako prispievajú k dosiahnutiu spoločných cieľov. 7. Možnosť voľby Keď organizácia podporuje kaţdého zamestanca k tomu, aby sa sám rozhodoval. 8. Celistvosť Keď sa kaţdý jednotlivec i organizácia ako celok drţí zdieľaných etických a morálnych princípov. 9. Decentralizácia Keď sa moc rozprestrie do všetkých úrovní a častí organizácie. 10. Reflexia a zhodnotenie Keď všetci cítia potrebu priebeţnej spätnej väzby, potrebu učiť sa z minulosti. 58

59 6 Popis vybranej firmy Softwarová spoločnost PURE IDEAS s.r.o. ( je novovzniknutá softwarová spoločnosť, ktorá vznikla spojením odborníkov z rôznych oborov a firiem za účelom zefektívnenia spolupráce, fungovania na nových princípoch a na základe toho získania väčších zaujímavých zakázok. Aj kvoli tomu vznikla potreba presne definovať procesy, role, dokumenty, atď., na základe čoho vznikla aj táto diplomová práca. Spoločnosť má v súčasnej dobe 2 majiteľov so 60% a 40% podielom. Za svoje závazky ručí celým svojím majetkom a základné jmění činí nyní Kč. 6.1 Predmet podnikania Hlavným predmetom podnikania je primárne vývoj internetových a systémových riešiení webových portálov, intranetov, extranetov, mobilných a multidotykových aplikácií, firemných a produktových stránok, systémov po správu a riadenia obsahu, vývoja informačných systémov, aplikácí na mieru, atď. Pomáha svojím klientom vyuţívať príleţitostí v oblasti obchodu, komunikácie a marketingu, ktoré im prinášajú interaktívne média a nové technologie. Ponúka takisto konzultácie v oblasti uţivatelského designu, vývoja a implementácie webových, mobilných aplikácií, projekt manaţmentu a online marketingu. Okrem toho firma vyvíja i vlastné produkty, na základe ktorých testuje vţdy nejnovšie technológie a trendy. 6.2 Analýza stávajúceho stavu riadenia projektov Doteraz kaţdý projekty riešil popri svojej hlavnej práci. Kaţdý zo zainteresovaných mal svoju ţivnosť, či uţ grafik, programátor, kóder a keď niekto prišiel s novou zakázkou, tak celý projekt fakturoval na svoju ţivnosť a následne sa dohodol s ostatnými o prevedení práce. Nevýhodou tohto fungovanie bolo, ţe napr. keď získal zákazku grafik, tak s klientom prebral iba veci týkajúce sa grafiky a následne potom pri implementácií sa zistilo, ţe niektoré veci nepôjdu spraviť, alebo to bude veľmi časovo a finančne náročné. 59

60 Takţe na začiatku vačšinou nebola spravená dostačujúca analýza a vedomosti jednotlivých zúčastnených sa takisto nijak vzájomne nevyuţívali. Keďţe nebola prevedená poriadne analýza zákazníkových poţiadavkou (väčšinou iba z jedného uhlu pohľadu, buď od grafika, alebo programátora), tak nebolo moţné ani odhadnúť časovú a finančnú stránku projektu. Cena bola väčšinou určovaná zákazníkom a jeho rozpočtom na daný projekt. A vo väčšine prípadov zákazník v priebehu projektu prichádzal s novými a novými nápadmi, úpravami, ktoré sa museli implementovať v rámci dohodnutej ceny. Čo malo samozrejme za následok oneskorené dodanie projektu, za omnoho vyššie náklady, ktoré však uţ zákazník nechcel zaplatiť, čo spôsobovalo jednak straty na strane dodávateľov a jednak nespokojnosť zákazníka, čo v niektorých prípadoch viedlo aj k jeho strate. 60

61 7 Návrhy pre oblasť riadenia projektov 7.1 Ciele zavedenia metodiky projektového riadenia Z vyššie uvedených dôvodov, vyplynula potreba sa spojiť, preto vzniku novej spoločnosti a zavedenie projektovej metodiky, ktoré umoţnia: Obecne ciele zavedenia metodiky sú: efektívne riadenie projektov podľa ich rozsahu o 1/3 niţšia cena oproti konkurencií skutočný rozsah projektu neprevýši plánovaný rozsah viac ako o 20% dodanie projektu v poţadovaný termín (+/- 20%) maximálna spokojnosť zákazníka s výstupom - dodanie poţadovanej funkcionality, tzn. po projekte sa následne nebudú riešiť ad hoc práce za ďalšie peniaze v rámci implementovaných vlastností eliminácia plytvania Avšak pri návrhu procesov, sa budeme zameriavať hlavne na posledný bod elimininácia plytvania, budeme drţať hesla od Leonarda da Viciho jednoduchosť je najvyššia forma dokonalosti a od Alberta Einsteina sprav veci také jednoduché ako je len možné, ale nie jednoduchšie. Čo sa dá zjednodušiť? Všetko, čo otravuje našich zákazníkov aj našich spolupracovníkov. Je to riešenie, kde menej je viac. Cesta, ktorá nás oslobodí, prinesie nám prehľad vo veciach, produktivitu a čas. 7.2 Skupiny projektov Keďţe je neefektívne a viac-menej nemoţné riadiť kaţdý projekt rovnako, napr. u malého projektu je nezmyselné vytvárať status reporty, keď sa projekt spraví v rámci jednej iterácie a u komplexných projektov je nedostačujúce robiť status report raz za dva týţdne. Tak je dôleţité si identifikovať skupiny projektov, ktoré majú spoločné vlastnosti 61

62 a pre kaţdú túto skupinu navrhnúť spôsob riadenia, ktorý reflektuje potreby daného projektu. Avšak čo je malý projekt a čo je veľký projekt? Pojem malý je relatívny pojem. Napr. u veľkej korporácie je malý projekt s rozpočtom v rádoch miliónov, kde u malej firmy to je projekt v rádoch tisícov. Nie je také jednoznačné určiť kedy sa jedná o malý projekt, iba na základe ceny a doby trvania, ale dôleţité sú aj iné aspekty. Na určenie skupín projektov nám dáva návod PRINCE2, za vyuţitia šiestich premenných/ výkonnostných cieľov projektu. ČAS ROZSAH NÁKLADY VÝHODY KVALITA RIZIKO Obrázok 8 Šesť premenných projektu [2] Na základe týchto aspektov si môţeme nadefinovať skupiny a rozhodnúť sa aký riadiaci prístup pouţijeme. Po analýze projektov sme identifikovali 3 skupiny projektov. Zhrnutie vlastností jednotlivých skupín vzhľadom k premenným projektu podľa PRINCE2, môţeme vidieť v nasledujúcej tabuľke: 1.skupina (malé projekty) Čas Veľmi krátky čas realizácie. Do 5 MD 2.skupina (stredné projekty) Stredný čas realizácie. 10 MD a viac 3.skupina (veľké projekty) Stredný aţ dlhý čas realizácie. Nemoţno určiť. Náklady Vyuţitie iba interných Vyuţitie i externých Vyuţitie externých kapacít. kapacít. Fixná koncová kapacít. Fixná koncová Variabilná cena. 62

63 cena. Rozsah Jeden hlavný výstup (upravený preddefinovaný web). Rozsah je jednoduchý a presne definovaný. cena. Počíta sa i s navýšením. Viacej výstupov (grafický návrh, nové komponenty, online kampaň, atď.) Rozsah je pribliţne definovaný. Viacej výstupov. Rozsah je komplexný a nedá sa definovať. Riziko Veľmi malé riziko, ak Malé riziká, stredné Vysoké riziko, veľké nejaké. Malé zmeny. zmeny. So zmenami sa zmeny. Primárne sa zo počíta vo vývojovom zmenami nepočíta. procese. Kvalita Jednorazové posúdenie Niekoľko násobné Samostatná disciplína kvality. posúdenie kvality. Výhody Jasne definované Jasne definované Rámcovo definované výhody. výhody. výhody. Tabuľka 4 Rozdelenie projektov Malé projekty - parametrizované webové projekty Webové prezentácie, ktoré sa riešia parametrizáciou štandardného riešenia, tj. nevzniká nič nové. Typickými znakmi pre tieto projekty je, ţe sa jedná o webové prezentácie, ktorých riešenie je postavené na vyuţití a minimálnom upravení CMS, ktoré ja vlastným produktom firmy. Pouţívajú iba funkčnosť, komponenty, ktoré poskytuje CMS a vyuţívajú upravené preddefinované grafické návrhy. Grafické poţiadavky nemajú obmedzenie, ale čo sa týka funkčných poţiadavkou, tak tie sú limitované funkčnosťou CMS. Tento typ webových prezentácií je určený pre klientov, ktorý potrebujú typické, rýchle a kvalitné riešenie za prijateľnú cenu, ktoré sa do budúcna môţe upravovať a rozširovať presne podľa ich potrieb. Jedná sa o projekty určené pre určitú skupinu 63

64 zákazníkov, s podobnými poţiadavkami, kde sa takisto predpokladá úprava štandardného riešenia. Sú riešené realizáciou tzv. balíčkov. Balíček vzniká vydefinovaním si skupiny klientov a ich potrieb. Samozrejme obsah balíčkov sa časom vylepšuje, na základe získania nových skúseností. Typickým príkladom je napríklad balíček pre firemnú prezentáciu, alebo balíček pre reštaurácie. Napr. balíček pre reštaurácie ponúka základné riešenie pre reštaurácie, ktoré obsahuje: tvorbu loga, popr. CI (Corporate Identity) jedinečný grafický návrh, zaloţený na úprave preddefinovaných šablón štandardnú mobilnú verziu webu (ktorá reflektuje potreby reštaurácií) základné moduly pre reštaurácie : denná ponuka, novinky, menu, galéria, napojenie na sociálne siete, atď Stredné projekty - customizované webové projekty Do tejto skupiny spadajú webové projekty, u ktorých si klient poţaduje jedinečný grafický návrh (nestačí úprava grafických šablón), alebo mu nestačí funkcionalita, ktorú poskytuje CMS, popr. verzia CMS určená pre určitý balíček. Poţiadavky klienta nie sú nijako limitované, ale v rámci počiatočnej analýzy je moţné určiť pribliţný rozsah a cenu Tieto riešenia sú takisto primárne postavené, vybudované nad CMS, ale doprogramovávajú sa aj funkcionality nad rámec funkcionality poskytovanej CMS, poprípade sa funkcionalita CMS upravuje presne podľa poţiadaviek klienta. Typicky sa jedná o projekty od 10 MD, horná hranica je neobmedzená a podieľa sa na ňom uţ viacej ľudí Veľké projekty - komplexné projekty Portálové riešenia, vývoj softwaru na zákazku, ktorý nie je postavaný na CMS, komplexné webové projekty s reklamnými kampaňami alebo interné projekty - startupy 64

65 (projekty, ktoré si firma vyvíja pre vlastné potreby, za účelom budúceho zisku. Tieto projekty slúţia aj na vyuţitie internej kapacity.). Táto posledná skupina projektov je najkomplexnejšia a nedajú sa ani presne definovať spoločné znaky pre tieto projekty. Nedá sa ani vymedziť pribliţný rozsah časovej náročnosti, lebo to môţu byť projekty v rozsahu 50 MD, ale takisto aj projekty v rozsahu 200 a viac MD. Nedá sa finálne vyšpecifikovať konečný rozsah. Je známy iba hlavný cieľ, myšlienka, ale konkretizácia riešenia a poţiadavkou mení upresňuje, priebeţne. Čo je spôsobené tým, ţe sa primárne jedná o vývoj nových softwarových riešení, ktoré si klient nemôţe porovnať uţ s existujúcimi riešeniami (napr. ako sú webové stránky konkurencie), popr. vývoj nového software a tak koľkokrát zistí, čo presne chce, aţ keď uţ vidí funkčné riešenie. Samozrejme je úlohou analytika smerovať klientove poţiadavky určitým smerom, aby k zásadným zmenám nedochádzalo, a tým pádom aj prerábaniu produktu, avšak z praxe vieme, ţe zmenám sa vyhnúť skoro nikdy nedá, i keď bola počiatočná analýza čo najlepšia. 7.3 Pilotný projekt Nasledujúci návrh riadenia sme otestovali na pilotnom projekte. Pre prehľadnosť, lepšie súvislosti a kvôli nadbytočnému opakovaniu textu, budeme v rámci návrhu metodiky vţdy uvádzať i konkrétne príklady, kde si popíšeme ako to prebiehalo v reálnom projekte, popíšeme si konkrétne výstupy a situácie na ktoré sa narazilo. Kvôli rozsahu danej problematiky budeme uvádzať príklady iba kľúčových, alebo niečím zaujímavých vecí, s ktorými sme sa stretli pri realizácií tohto projektu. Náš pilotný projekt sme realizovali pre veterinárnu kliniku Centravet s.r.o., ktorej majiteľkou je MvDr. Diana Halaszová. Prvotnou poţiadavkou s ktorou sme boli kontaktovaný bolo vytvoriť e-shop so základnými informáciami o klinike, ale nakoniec po diskusiách a našich návrhoch, sme redefinovali cieľ na vytvorenie webovej prezentácie pre kliniku spolu s informačným portálom pre jej klientov, ktorý bude napojený na e-shop. 65

66 8 Návrh metodiky pre stredné projekty V tejto kapitole si povieme, z ktorých metodík sme vychádzali. Vzhľadom k rozsahu danej problematiky detailnejšie popíšeme iba metodiku riadenia pre 2. skupinu projektov, do ktorej patril i pilotný projekt. Avšak sposob riadenia projektov z 1. skupiny bude vychádzat takisto z týchto návrhov, tak si ho popíšme aspoň rámcovo. V zásade pojde o výrazné zjednodušenie. Z definície 3. skupiny projektov, nemá cenu navrhovať metodiku, ale sposob riadenia bude takisto vychádzať z nasledujúcich návrhov. Pojde o rozšírenie tejto metodiky hlavne za vyuţitia princípov z lean developmentu. Kvoli rozsahu sa ale sposobom riadenia 3.skupiny nebudeme zaoberať v tejto práci. 8.1 Vhodnosť metodiky PRINCE2 Pôvodný zámer bol jednotlivé metodiky pre definované kategorie projektov navrhnúť metodiky pomocou tzv. tailoringu (napasovania) metodiky PRINCE2. Podľa autorov samotnej metodiky je PRINCE2 natoľko obecná, ţe je moţné ju napasovať na všetky druhy projektov Napasovanie metodiky PRINCE2 Často vytýkanou nevýhodou PRINCE2 uţ po celé roky bolo nemoţnosť pouţitia pre malé projekty, čo sa týka hlavne našej prvej skupiny a z časti aj našej druhej skupiny projektov. Verzia PRINCE2 z roku 2009 (PRI1) uţ obsahuje kapitolu, ktorá sa zaoberá napasovaním (tailoring) prostredia PRINCE2 metodiky, čo je významným krokom oproti predchádzajúcim verziám, ale stále nám nerieši všetky záleţitosti. S vyuţitím týchto vedomostí sa môţu vytvoriť akési šablóny škálovania PRINCE2 pre dané skupiny (PRI). Ako sme uţ spomínali, PRINCE2 môţe byť pouţitá na akýkoľvek projekt, otázkou iba zostáva ako najlepšie PRINCE2 pouţiť pre konkrétny projekt. Napasovanie projektu nám odpovedá na otázku: Aké je správne mnoţstvo plánovania, kontroly, monitorovania a pouţitia procesov pre daný projekt? 66

67 Častou chybou manaţérov je namiesto napasovania metodiky pouţívanie iba tzv. PINO prístupu PRINCE in name only, vyznačuje sa vyuţitím iba niektorých časti metodiky a nedodrţaním konceptu. Cieľom napasovania metodiky nie je si vybrať izolovane kúsky z metodiky, pretoţe to potom uţ nebude viac PRINCE2 projekt, cieľom je nájsť vhodný level projektového manaţmentu, ktorý nebude bremenom projektu, ale naopak poskytne vhodný level kontroly. Keď metodiku nenapasujeme vhodne pre kaţdý projekt, tak projekt nebude manaţovaný efektívne a môţe dôjsť k tzv. robotickému projekt manaţmentu, kde je metóda slepo nasledovaná. Napasovanie metodiky je o premýšľaní ako najlepšie aplikovať projektovú metodiku, aby sme zaistili rovnováhu medzi dobrou projektovou kontrolou a čo najniţšou administratívou. V našom prípade majú projekty z 1. a 2. natoľko podobné vlastnosti a rozsah, ţe pre ne moţme obecne navrhnúť spôsob riadenia, ktoré sa bude pouţívať pre všetky projekty z tejto skupiny a nemá cenu sa zakaţdým zamýšľať ako treba upraviť metodiku. Pre 3.skupinu by bolo moţné navrhnúť len akési hranice riadenia projektov, ale u kaţdého projektu sa bude musieť pred začatím projektu metodika upraviť presne podľa potrieb. 1.skupina 2.skupina 3.skupina Aplikovanie Daný projekt sa môţe Daný projekt sa môţe Projekt sa bude riadiť PRINCE2 riadiť iba ako riadiť ako malý projekt. ako normálny projekt Pracovný balík 6. Jedna fáza dodania. PRINCE2. Štandardný Zjednodušený projektový projektový výbor. výbor. Projektový manaţér Kombinované niektoré zastáva rolu tímového manaţérske produkty. manaţéra. Kombinované manaţérske produkty. 6 Workpackage 67

68 8.1.2 Zistenia a problémy pri napasovaní Avšak pri napasovaní metodiky vzišlo niekoľko zásadných problémov a zistení: 1. Problém s napasovaním metodiky. Pri snahe napasovať čo najoptimálnejšie metodiku sme nakoniec skĺzli k PINO prístupu, čo sa nepovaţuje za riadenie projektov pomocou PRINCE2. I pri zoštíhlení metodiky podľa návrhu, existuje mnoho dokumentov, ktoré avšak nepokrývali potreby internetových projektov. Nakoniec by bolo potreba definovania ďalších dokumentov a procesov nad rámec PRINCE2. 2. Zameranie metodiky. Metodika je primárne určená na projekty väčšieho rozsahu, i keď v najnovšej verzii vďaka kapitole napasovaniu metodiky, mala byť metodika určená i pre riadenie menších projektov. Ďalej metodika je natoľko obecná, napríklad vo Veľkej Británii sa vyuţívala i na riadenie projektov z oblasti stavebníctva, ţe nerieši hlavné problémy s ktorými sa potykajú internetové projekty. 3. Riadenie zmenových požiadavkou. Metodika nepočíta so zmenou, zmenu berie ako výnimku. Čo je v našom prípade na základe analýzy v kapitole 2.2 zásadný problém. 4. Nedostatočná literatúra. Keďţe v našom prípade primárne riešime malé aţ stredné projekty, tak neexistuje dostatočná literatúra a hlavne konkrétne príklady ako riadiť tieto projekty pomocou PRINCE2. Momentálne existuje jedna kniha v anglickom origináli PRINCE2 for small-scale projects od Chrisa Fergusona (Ferguson, 2011), ktorá avšak obsahuje natoľko obecné príklady (napríklad projekt s riešením záhrady), ţe pre riadenie webových projektov neprináša ţiadnu pridanú hodnotu. 8.2 Obecný návrh metodiky Napriek tomu ţe návrh metodiky na riadenie webových projektov pomocou napasovania metodiky PRINCE2 sa ukázalo ako nevhodné, tak pri návrhu vlastnej metodiky sme vyuţili štruktúru metodiky, niektoré artefakty, alebo niektoré procesy, ktoré sme si upravili podľa potreby. 68

69 Navrhovaná metodika sa podľa PRINCE2 bude skladať z 3 hlavných častí: princípy témy procesy Pri návrhu procesov budeme v niektorých veciach takisto vychádzať z metodiky PRINCE2, ktorá nám dáva postupy jednotlivých činností ako vystavať daný projekt. Avšak tieto postupy skombinujeme s agilným spôsobom riadenia, primárne podľa metodík SCRUM a FDD, ktoré vznikli primárne na riadenie projektov z oblasti IT a reflektovali zistené problémy v oblasti riadenia týchto projektov. Aby sme mohli vymedziť navrhovanú metodiku, tak ju vymedzíme podľa definovaných kritérií z kapitoly 3.1: Kritérium metodiky Zameranie metodiky Rozsah Váha metodiky Typ riešenia Typ metodiky Projektová Metodika projektového riadenia Stredná Vývoj nového riešenia Doména Správa obsahu, e-commerce, produktové stránky Prístup k riešeniu Objektový, komponentový Procesy si zaradíme do niekoľko fáz, ako môţeme vidieť v PRINCE2, FDD, ale v určitej miere i v SCRUMe. Predprojektová fáza táto fáza obsahuje skôr obchodné procesy. Cieľom je získanie poţiadavkou od klienta, určenie rozsahu. Výstupom je primárne predbeţná ponuka. 69

70 Iniciačná fáza v tejto fáze budú za sebou sekvenčne nasledovať procesy ktoré slúţia na získanie obecných informácií o projekte, návrh a ohodnotenie projektu. Primárne tu budeme vychádzať z procesov FDD, ktoré si upravíme podľa potrieb ale takisto zo Scrumu v prípade tvorby produktového backlogu. Výstupom tejto fáze je získanie všetkých potrebných informácií na finálnu ponuku a podpísanie zmluvy. Doručovacia fáza v tejto fáze prebieha iteratívny vývoj, tu sme sa primárne inšpirovali Scrumom, kde v rámci doručovania jednotlivých časti výsledného produktu vyuţívame princípy šprintov. V rámci kaţdého šprintu však pridávame i vlastné procesy. Finálna doručovacia fáza keďţe výsledkom kaţdého šprintu bude spustiteľý vystup, tak v tejto fáze sa primárne uţ nebude vytvárať nová funkcionalita, ale otestuje sa hlavne stavajúca a prebehne optimalizácia riešenia pre všetky typy zariadení. Na záver prebehne akceptácia a samotné spustenie projektu. Poprojektová fáza táto fáza slúţi na vyhodnotenie projektu, spísanie získaných poznatkov, poprípade začlenenie nových komponent do základnej verzie CMS. 8.3 Definícia princípov Naše ciele ktoré sme si dali na zavedenie metodiky, dosiahneme i definíciou princípov, ktorých sa budeme drţať a ktoré nás budú navádzať počas celého projektu, pri rozhodovaní i pri výbere nástrojov. Takisto ako PRINCE2 dáva svojim princípom veľkú váţnosť[1]: ak nie je dodržovaný aspoň jeden z týchto princípov, tak nemôžeme už povedať, že sa jedná o projekt riadený pomocou PRINCE2, tak i v našom prípade vţdy budeme tieto princípy dodrţovať, aby sme mohli povedať, ţe projekt bol riadený podľa našej metodiky a v prípade nedodrţania i jedného z týchto princípov, nemusí byť zaručený úspech projektu. 70

71 Na definíciu vlastných princípov vychádzame z princípov PRINCE2, agilného manifestu, lean developmentu a vlastných skúseností z oblastí vývoja webových projektov. Princípy boli definované postupne a takisto sa počíta do budúcna s ich úpravou, pridávaním, popr. odstránením na základe skúseností. Niţšie sú uvedené princípy i vysvetlenie ako sa k nim dospelo. V reálu sú princípy definované jednou maximálne 2 vetami, vystavené na viditeľnom mieste a dostupné kaţdému pracovníkovi v online podobe. Princípy ktoré boli počiatočne nadefinované sú: Obchodné zdôvodnenie projektu na začiatku sa definujú ciele projektu, na ktoré sa bude myslieť počas všetkých fáz a aktivít. V prípade, ţe sa zistí, ţe akákoľvek časť nepodporuje obchodné zdôvodnenie, alebo ciele projektu, tak sa jej vývoj môţe okamţite ukončiť. Poučovanie sa zo skúseností vţdy na začiatku kaţdého projektu sa skontroluje či sa uţ nerealizoval podobný projekt, v prípade tvorby nových komponent, sa skontroluje či uţ podobná komponenta neexistuje, poprípade či sa nedá upraviť nejaká existujúca (napr. entita kalendár). Na základe skúseností z predchádzajúcich projektov, budeme vychádzať i pri odhadovaní ceny a času. Eliminácia plytvania budeme minimalizovať tvorbu nepotrebných dokumentov, reportov, ktoré nikto nečíta, diagramy na ktoré sa nikto nepozerá a špecifikácie, ktoré sa nakoniec vôbec nepodobajú koncovému produktu. Priama a ad-hoc komunikácia nahradzuje časovo nákladné a náročné mítingy, písanie rozsiahlej dokumentácie a návrh modelov a ich následné prepracovávanie. Samozrejme však budeme pouţívať určité návrhy a modely, ale budeme sa však snaţiť minimalizovať čas ich tvorbou, maximalizovať ich uţitočnosť a miesto abstrakcie sa snaţiť čo najrealistickejšie ich predviesť. Aké diagramy a čo všetko sa bude navrhovať sa určí na začiatku projektu, podľa náročnosti projektu a hlavne podľa potrieb klienta. Časová ohraničenosť ako v reálnom ţivote, vţdy chceme viac a vţdy to nemôţeme mať. Časové ohraničenie všetkých udalostí nám zaručí, ţe sa vţdy budeme venovať dôleţitým veciam a nebudeme riešiť nepodstatné. Preto kaţdá schôdzka musí byť časovo ohraničená. Napasovanie metodiky pri kaţdom projekte, sa vţdy nastaví metodika podľa potrieb projektu a podľa potrieb klienta. Primárne sa jedná o nastavenie šprintov, dohoda o pouţití diagramov a hĺbke špecifikácie. 71

72 Definované role a zodpovednosti - v kaţdej firme a v kaţdom projekte ľudia potrebujú vedieť čo majú robiť a čo môţu očakávať od druhých. Definovanie rolí a ich zodpovedností je jedným z princípov PRINCE2 a podľa môjho názoru jedným z najdôleţitejších, minimálne ak sa nedodrţí tento princíp, môţe to spôsobiť najväčšie straty, či uţ časové, alebo finančné. Dobrým implementovaním tohto princípu by sme mali byť schopný odpovedať na otázku Čo sa očakáva odo mňa a čo ja môţem očakávať od druhých?. Spokojnosť tímu a následne zákazníka nadovšetko pretoţe keď je spokojný a šťastný tím, tak podavá maximálne výsledky, čo v konečnom dôsledku má vplyv na koncové riešenie a tým pádom i na zákazníka. 8.4 Témy Témy obsahujú základné pravidlá a techniky, ktoré sa môţu vyuţívať naprieč procesmi a ich jednotlivými úlohami. Reálne je kaţdá téma je popísaná v samostatnom dokumente a dostupná všetkých pracovníkom a pravidelne sa podľa získaných poznatkov rozširuje, poprípade mení. Keďţe väčšina tém vychádza z uţ existujúcich techník, tak detailnejšie budeme popisovať iba témy, ktoré sú špecifické pre našu firmu. Momentálny zoznam vypracovaných tém je nasledujúci: Organizácia Riadenie zmien Odhadovanie rozsahu a nacenenie projektu Nastavenie projektu a plánovanie podľa vlastností Riadenie rizík Komunikácia Nástroje Organizácia Obecné role vo webových projektoch V predchádzajúcich kapitolách sme si definovali v rámci metodík mnoho rolí. 72

73 Role ktoré sa vyskytujú v online svete majú svoje špecifiká, líšia sa od rolí v iných projektoch, poprípade majú zauţívaný iný názov. Preto si tieto role v skratke popíšeme. Autor vychádza z vlastných skúseností z digitálnych agentúr, či uţ českých, alebo zahraničných. Stakeholderi všetci ktorý finálne schvaľujú výsledný produkt, projekt. Môţu to byť majitelia firiem, CEO, investory, ale i ľudia pre ktorých je výsledný projekt určený. Vlastník produktu ako v prípade Scrumu, osoba ktorá reprezentuje klientove poţiadavky. V prípade väčších firiem to môţe typicky byť marketingový špecialista, brand manaţér, obchodník. V prípade menších firiem sú to často priamo majitelia. Obchodník primárne vyhľadáva nové obchodné príleţitosti, Account manažér stará sa uţ o získaných zákazníkov, navrhuje moţnosti ďalšej spolupráce, či uţ rozšírenie stávajúcich projektov, alebo realizáciu ďalších. Account manaţér má byť prvá osoba, ktorú klient po skončení projektu kontaktuje. Projektový manažér má na starosti riadenie celého projektu a všetkých jeho aspektov od podpísania zmluvy aţ po finálne nasadenie a predanie projektu do servisu. Scrum master má na starosti vedenie jednotlivých šprintov Online konzultant navrhuje koncepty a návrhy moţných riešení. Online konzultant sa hlavne podiela na tvorbe návrhov a konceptov podľa najnovších trendov, alebo podľa potrieb klienta Business analytik - špecifikuje poţadovanú funkcionalitu od zákazníka, poprípade danú doménu, vyjadruje to špecifickým jazykom jednoznačným pre vývojárov (najčastejšie pomocou UML, alebo vlastných diagramov). Posobí primárne vo fáze analýzy a návrhu. Copywriter má na starosti veškeré texty. Interakční dizajnér sa zaoberá návrhom interakcií. Navrhujú dialóg s koncovým uţívateľom výsledného produktu, v našom prípade väčšinou s webovou stránkou, alebo GUI aplikácie. UI/ UX konzultant - je zodpovedný za návrh, který je nejen funkční a pouţiteľný, ale také uţitočný, zmysluplný, riešiaci reálne problémy, a v neposlednej rade tieţ estetický a emotívny. 73

74 Vizuálny grafik - na základe návrhu a poţiadavkou od analytikov, konzultantov a vlastníka produktu pripravuje grafický návrh, vizuálnu identitu. Architekt má na starosti architektúru riešenia z technického hľadiska Vývojár - má na starosti implementáciu back-endu. Na základe výstupov od architekta programuje tried, funkcie, ktoré následne volá kóder. Kóder primárne ma na starosti kódovanie front-endu, tzn. nakóduje grafické návrhy od vizuálneho grafika. Okrem stálych členov týmu, ktorý sa pravidelne podieľajú na realizácií projektu, sú takisto role ktoré sa podieľajú na projekte len v určité momenty. Typicky sú to role, ktoré riešia dohliadajú na kvalitu riešenia, poprípade riešia kľúčové veci. Ako môţeme vidieť, tak v oblasti webových projektov existuje veľké mnoţstvo rolí. Väčšinou jednu rolu zastáva jedna osoba v prípade ţe sa jedná o rozsahovo obrovské projekty, alebo je projekt náročný na určitú oblasť. Napríklad ak sa rieši e-banking portál, tak pre mnoho funkcií a veľmi dôleţitú prehľadnosť je samozrejme uţívateľské rozhranie a interakčný dizajn veľmi dôleţitý na úspešnosť projektu, tak určite je vhodné mať experta na UX/ UI, popr. interakčného dizajnéra. V prípade, ţe sa nejedná o tak náročný projekt, čo sa týka GUI, tak tieto role môţe samozrejme zastať i vizuálny dizajnér (a často i zastáva). Samozrejme s väčším počtom zúčastnených ľudí narastá i cena. Toľko rolí súvisí i s tradičným fungovaním firiem (hierarchickým fungovaním), kde bol donedávna trend veľkej špecializácie. Tento trend bol podporovaný i veľkými investíciami do IT. Čo bolo spôsobené tým, ţe je IT je relatívne mladý obor, kde najprv neboli ani také pokročilé technológie a nástroje, popr. ustálené metodiky fungovania, tak rozpočty na projekty boli omnoho vyššie ako sú v súčasnej dobe. Avšak neplatí vţdy, ţe čím viac pracovníkov, tak tým lepšie a rýchlejšie riešenie. Rýchlosť zvládnutia úlohy stúpa iba do určitého počtu pracovníkov, a samozrejme záleţí na type úlohy ako sa dá distribuovať. Ak je na riešenie nejakého úkolu presiahnutý medzný počet pracovníkov, tak nielenţe sa dokončenie úlohy nezrýchli, ale sa dokonca začne spomaľovať. 74

75 Ale s príchodom krízy, kde sa investície do IT projektov výrazne zníţili vo všetkých oblastiach a s neskutočným rozvojom IT sa i rozpočty na projekty zníţili a tým pádom i počet osôb, zastávajúcich jednotlivé role Návrh rolí V oblasti webových projektov, keďţe sa jedná o spojenie veľa zručností a vedomostí, avšak rozsah vedomostí v danej doméne, nie je aţ taký rozsiahly (napríklad ako v prípade rozsiahlych systémov ako SAP, popr. Oracle) a hlavne jednotlivé obory sú prepojené, je vhodné, ak nie nevyhnutné, ak chceme celkový čas dokončenia a následne i celkovú časovú náročnosť, popr. cenu projektu zníţiť, aby jednotlivý zamestnanci zastávali viacero roli, tam kde je to moţné. Samozrejme to zvyšuje nároky na takéhoto pracovníka a preto to predpokladá seniorných pracovníkov s mnohoročnými skúsenosťami, poprípade je nutné do takéhoto pracovníka investovať. Na seniorných pracovníkoch je postavený i Scrum, kde je povedané, ţe danú rolu musí zastavať vţdy aspoň jeden seniórny zamestnanec. To má za následok hlavne efektívnu a rýchlu spoluprácu, kde jednotlivý pracovníci sú schopný robiť rýchle rozhodnutia, kvalitné návrhy a realizovať i kvalitné výstupy, čo má v konečnom dosledku dopad na rýchlosť a kvalitu finálnych produktov. Keďţe v rámci našich projektov členovia tímu zastávajú väčšinou tú istú mnoţinu rolí, tak aby sme nemuseli vţdy písať osobu a všetky role, ktoré zastáva, tak si definujeme tzv. super role, ktoré pozostávajú z viacerých rolí a ktoré budeme v nasledujúcom texte pouţívať a popisovať detailnejšie ich zodpovednosti. Obchodník primárne vyhľadáva nové obchodné príleţitosti, ale takisto zastáva rolu online konzultanta, takţe dokáţe klientovi navrhnúť pribliţnú koncepciu návrhu na základe uţ existujúcich riešení firmy. Hlavne primárne vytvára predbeţnú ponuku, maximálne s nejakými konzultáciami od ďalších členov tímu. Projektový manažér okrem riadenia samotného projektu, má na starosti i rolu account manaţéra i rolu Scrum mastra. Takisto ale zastrešuje rolu business analytika, pomáha vlastníkovi produktu vyšpecifikovať poţiadavky na produkt, výsledný web, pomocou uţivateľských príbehov a smeruje takisto vlastníka produktu. 75

76 Vlastník produktu ako v prípade Scrumu, osoba ktorá reprezentuje klientove poţiadavky. Vo väčšine prípadov prichádza zo strany klienta, tak mu nemôţeme priraďovať ďalšie role. V prípade interných projektov je to zamestnanec firmy a v tomto prípade moţe vlastník produktu zastávať i ďalšie role. Má primárne na starosti produktový backlog a rozhoduje o prioritách poloţiek v backlogu. Priority určuje po diskusií s členmi tímu. Vlastník produktu píše i uţívateľské príbehy s pomocou projektového manaţéra. Vlastník produktu sa takisto musí pravidelne zúčastniť schôdzok tímu, aby priamo odpovedal otázky a robil rovno rozhodnutia. Grafik táto super rola zastrešuje interakčného grafika, vizuálneho grafika i UX/ UI návrhára. Na základe návrhu a poţiadavkou pripravuje grafický návrh. Pretoţe firma je názoru, ţe kaţdý grafik má svoj štýl a kaţdý stýl je vhodný pre iného klienta, tak sa spolupracuje s viacerými grafikmi na forme externej spolupráce. Programátor - má na starosti implementáciu back-endu. Tvorbu databáze, prípravu tried, funkcí, ktoré potom pouţíva kóder. Kóder primárne ma na starosti kódovanie front-endu. Dokáţe ale takisto pracovať uţ komponentmi CMS a poskladať nový web podľa poţiadavkou. Role top manaţmentu zostávajú nemenné iba osoba riaditeľa zastáva viacej rolí. Kreatívny riaditeľ má na starosti kvalitu grafických návrhov. Na pravidelnej bázi konzultuje výstupy s grafikami Navrhovaná organizačná štruktúra Z navrhovaných rolí budeme vychádzať pri navrhovaní organigramu firmy. Navrhovaná organizačná štruktúra je tzv. plochou štruktúrou, ktorá je typická minimálnou hierarchiou. Navrhovaný organigram môţeme vidieť na nasledujúcom obrázku: 76

77 Obrázok 9 Navrhovaný organigram pre spoločnosť PURE IDEAS Firma pozostáva z niekoľkých oddelení, ktoré zastrešuje riaditeľ. Riaditeľ ma priamo na starosti i Obchodného a Projektové oddelenie. Riaditeľ má na starosti rozvoj obchodu a nastavenie projektových procesov. Vývojové oddelenie má na starosti Technický riaditeľ pod ktorého spadá takisto i Servisné oddelenie, ktoré má samostatných kóderov. Technický riaditeľ má na starosti kvalitu výstupov vývojárov, kóderov i architektov. Na pravidelnej báze konzultuje a zastrešuje takisto i rozvoj nových technológii. Kreatívne oddelenie má na starosti Kreatívny riaditeľ, ktorý má pod sebou grafikov a copywriterov, ktorý spolupracujú primárne na externej báze a má na starosti štandardy a kvalitu grafických návrhov. Takisto ale úzko spolupracuje s obchodným oddelením, hlavne pri tvorbe ponúk. Realizačný tým pozostáva vţdy z Projektového manaţéra, Grafika a Vývojového tímu, ktorý je ustálený, tzn. programátori a kóderi pracujú vţdy spolu na daných projektoch. Jeden Projektový manaţér má na starosti viacej vývojových tímov, vţdy ale primárne spolupracuje s tými istými tímami. Tým je zaručená vyššia efektivita spolupráce, kedţe spolupracovníci vedia, čo môţu od koho čakať. Grafik sa priradí podľa projektu 77

78 (kaţdý grafik je vhodný na iný typ projektov) na základe dostupných kapacít a rozhodnutia Kreatívneho riaditeľa. Riaditelia nespolupracujú na projektov na dennodennej báze, ale vţdy iba v rozhodujúcich momentoch Súčasný stav Momentálne pre spoločnosť PURE IDEAS pracujú 4 ľudia, ktorý tvoria jeden tím. V prípade potreby externe spolupracuje s grafikmi alebo kódermi. Takţe riaditeľ (autor práce) zastrešuje i rolu projektového manaţéra, kreatívny riaditeľ (Martin Mareš) zastrešuje i rolu grafika, technický riaditeľ (Jakub Chládek) zastrešuje i rolu architekta, programátora a kódera. Ďalej programátor (Zneděk Janura), ktorý má na starosti implementáciu vybraných častí. V tomto zloţení sa tím podieľal i na vývoji pilotného projektu. Do budúcnosti je cieľom mať maximálne 20 zamestnancov, ktorý budú v prípade potreby tvoriť niekoľko tímov, ktoré sa budú podľa potreby dopĺňať. Na niektoré veci nie je potrebný celý tím typicky na parametrizované webové projekty (1.skupina), alebo servisné poţiadavky, ale iba jednotlivý pracovníci Nástroje Keďţe základom kvalitného riadenia nie je len metodika, ale aj technické poprípade softwarové riešenie, ktoré pouţijeme na implementáciu metodiky, v tejto kapitole sa zameriame na tieto produkty a vyberieme ten najvhodnejší pre naše potreby. Výber zlého výberu nástroja môţe mať veľké dopady na projekt. Je to ako s lyţovaním, i keď výborne zvládate techniku, ale máte nekvalitné lyţe, tak výsledok a pocit z jazdy nie je bohvieaký Komunikácia a dátové úložisko Ako sme uţ spomínali v predchádzajúcich kapitolách, základom fungovania týmu je komunikácia. Keďţe tým funguje primárne na diaľku, tak poţiadavky na komunikačný nástroj sú o to dôleţitejšie. Spolu s komunikáciou súvisí i úloţisko dokumentov na ktoré sa často v rámci komunikácie odkazuje. Kritériom pre správnu voľbu boli: - dostupnosť zo všetkých zariadení 78

79 - rýchlosť komunikácie keďţe tým komunikuje dennodenne primárne na diaľku, rýchlosť a kvalita komunikačného nástroja je kľúčová - komplexnosť, ideálne riešenie od jedného dodávateľa Kritéria na úloţisko: - dostupnosť na všetkých zariadeniach - moţnosť paralelného editovania dokumentov Najprv bola skúšaná kombinácia u, Skypu a Dropboxu. Počas projektu sme ale objavili riešenie od Googlu, ktoré bolo novo spustené s mnoha novými vlastnosťami - Google Apps. Toto riešenie zahrňuje instant messeging Hangsout spojené i s video hovormi, zdieľané úloţište Disk Drive, ktoré ukladá všetky dokumenty a súbory obecne do cloudu, takţe všetky dokumenty sú prístupné z akéhokoľvek zariadenia PC, mobilu, tabletu, ale toto umoţňoval i Dropbox. Avšak veľkou výhodou je moţnosť paralelného editovania dokumentov uţívateľmi. Táto vlastnosť sa ukázala pre nás ako kľúčová a preto sme i uprostred projektu prešli na pouţívanie tohto riešenia Nástroj na projektové riadenie V prípade jednoduchých projektov (1.kategorie) si na riadenie jednotlivých úloh vystačíme s excelovskou tabuľkou. Avšak pri zloţitejších projektoch (od 2. kategórie), na spravovanie veľkého mnoţstva úloh a podúloh, dokumentov a diskusie, na spravovanie osôb a času dokončenia uţ potrebujeme nástroj, ktorý nám môţe veľmi uľahčiť i urýchliť prácu. Na trhu existuje nepreberné mnoţstvo software na riadenie projektov. Či uţ sa jedná o desktopové aplikácie, alebo o tzv. cloudové riešenia. Poţiadavky na tento nástroj boli: cloudové riešenie prehľadná správa úloh a podúloh moţnosť tvorenia zoznamov, priraďovanie jednotlivých úloh, zadávanie stavu, diskusia na jednom mieste napojenie na Google apps 79

80 cena Po testovaní niekoľkých nástrojov sme sa nakoniec rozhodli pre nástroj Teamwork 7, hlavne kvôli výbornej práci s úlohami a podúlohami, kde je moţne si úlohy triediť do zoznamov, ktoré môţu reflektovať Produktový backlog ako si povieme v nasledujúcich kapitolách. 8.5 Procesy Ako sme si uţ povedali v predchádzajúcej kapitole, procesy budú rozdelené do niekoľkých etáp: Predprojektová fáza Iniciačná fáza Doručovacia fáza Finálna doručovacia fáza Poprojektová fáza Na popis procesov budeme vychádzať z metódy ETVX (viď ) pomocou tzv. ľahkých procesov, preto si to teraz popíšeme trochu detailnejšie i s doplnením ako budeme v našom prípade procesy popisovať. Popis procesov podľa ETVX môţeme vidieť na nasledujúcom diagrame

81 Obrázok 10 Diagram ETVX Diagram ETVX popisuje 4 nasledujúce charakteristiky procesov: Vstupné kritéria (Entry) definujú poţiadavky na začatie procesu. Proces sa zaháji vstupmi, alebo, tzv. spúšťačmi (triggers). Vstupy sú zvyčajne výstupmi z predchádzajúceho procesu. Spúšťač je udalosť, ktorá spúšťa daný proces (vyplnenie kontaktného formulára, podpísanie zmluvy). Úlohy (Tasks) vymenovanie všetkých úloh, ktoré je potrebné splniť v rámci procesu. Realizácia úloh sa predpokladá sekvenčne. Verifikácia (Verification) nástroje verifikácie. Po prevedení všetkých úloh v rámci procesu, nastáva verifikácia, ktorá zaisťuje, ţe všetky výstupné kritéria boli splnené v danej kvalite. Výstupné kritéria (exit) - výstupné kritéria identifikujú podmienky, ktoré musia byť splnené na ukončenie procesu. Môţe sa jednať ako o hmotné podmienky (fyzické výstupy, dokumenty, prototypy, atď.), tak i o nehmotné podmienky (určenie vlastníka produktu). Cieľom definície ľahkých procesov je prehľadne a jednoducho popísať, čo je treba spraviť a aké sú potrebné výstupy. Ako sa uţ jednotlivé úlohy budú konkrétne realizovať, záleţí na účastníkoch procesu. Môţe sa vychádzať s doporučení v jednotlivých témach, alebo zvoliť iný spôsob zameranie je na výsledky. 81

82 V nasledujúcom texte kaţdý proces najprv popíšeme textovo. V tele tejto práce bude popis obšírnejší a bude pojednávať i prečo sme sa tak rozhodli, poprípade vysvetľovať postup. V rámci popisu sa bude rovno uvádzať i príklad ako prebiehala realizácia v pilotnom projekte. Pre vizuálne oddelenie, text, ktorý sa týka konkrétnej realizácie bude písaný kurzívou. Následne bude nasledovať sumarizačná tabuľka, ktorá bude obsahovať podľa vyššie uvedeného: - názov fáze projektu - názov procesu - jednotlivé úlohy, kde kaţdá bude obsahovať: názov úlohy, popis úlohy, či je prevedenie úlohy povinné alebo nie, účastníkov úlohy, kde osoba, ktorá je primárne zodpovedná za danú úlohu, bude zvýraznená tučným písmom - verifikáciu - výstupné kritéria Reálny popis procesu bude vţdy v jednom dokumente a maximálne na 1 stránku poďla doporučení ETVX. Všetky procesy sú uloţené v sdielanom úloţišti Google Drive a dostupné všetkým pracovníkom. Konkrétny popis procesu môţeme vidieť v prílohe Predprojektová fáza Táto fáza obsahuje všetky procesy od prvého kontaktu so zákazníkom aţ po schválenie predbeţnej ponuky zákazníkom Proces kick-off projektu Predprojektová príprava sa začína vypracovaním Popisu projektu s jednoduchým popisom výstupu projektu a základných poţiadavkou. Zadanie je buď dodané priamo od klienta, ale väčšinou je zostavené v spolupráci s obchodníkom, ktorý navedie klienta k tomu, čo pribliţne poţaduje, či uţ sú to konkrétne komponenty, podobné riešenie, alebo popis iných výstupov a aké je cenové rozpätie. 82

83 Určí sa projektový manaţér, ktorý bude mať eventuálne projekt na starosti. Následne projektový manaţér zozbiera relevantné ponaučenia z minulosti a podľa kapacít sa predbeţne určí projektový tím. Pre kaţdý projekt je nutné zohľadniť, či je projekt realizovateľný a stojí za vynaloţené úsilie, čas a financie - teda vytvoriť jeho rámcové zdôvodnenie. Je nutné nadefinovať spôsob, akým sa ku projektu pristúpi, hlavne ho zaradiť do ktorej skupiny projektov spadá a na základe toho, ako sa k nemu bude pristupovať. Či sa jedná o 1. kategóriu, ak áno, tak o ktorý balíček, alebo o 2., alebo 3. kategóriu. Výstupom tejto fáze je hlavne rozhodnutie, či vôbec firma chce realizovať tento projekt, tj. či má naň kapacity, popr. či sa pre ňu vyplatí. V prípade projektu Centralvetu, i keď majiteľka povedala na začiatku maximálnu cenu, za ktorú si výsledný projekt predstavuje, za ktorú by projekt ziskový, tak keďže sa jednalo o pilotný projekt testovania metodiky a vývoj portálového riešenia, z ktorého sa v budúcnosti može stať balíček a následne sa ponúkať ďalším zákazníkom, tak na internom kick-off meetingu sa rozhodlo, že sa bude realizovať. Fáza: Pre-projektová Vstupné kritéria Úlohy Popis projektu Počiatočné určenie tímu Kick-off meeting Verifikácia Výstupné kritéria Proces: Kick-off projektu Priradený obchodník, ak sa nejedná o zakázku, ktorú zaistil obchodník sám, zodpovedná osoba za klienta Cieľom je spracovať základný popis projektu, z ktorého sa bude následne vychádzať. Povinný Účasníci: obchodník, zákazník Cieľom tejto úlohy je počiatočné určenie ľudí, ktorý budú mať na starosti dokončenie finálnej ponuky. Povinný Účasníci: obchodník, CEO, CTO Cieľom je zorganizovanie kick-off meetingu, na ktorom sa rozhodne, či sa bude v projekte pokračovať a ako. Povinný Účasníci: obchodník, CEO, CTO, projektový manažér, projektový tím Interná v rámci tímu Popis projektu, rozhodnutie či realizovať projekt, ak áno tak ako 83

84 Proces - Príprava predbežnej ponuky Cieľom tohto procesu je príprava predbeţnej ponuky. Predbeţná ponuka slúţi na včasné identifikovanie, či zákazník bude chcieť realizovať projekt, alebo nie, aby sa zbytočne neinvestoval čas a zdroje v rámci podrobnejšej analýzy. Vyšpecifikuje sa najprv štruktúra webu, pomocou sitemapy, na ktorú budeme mapovať jednotlivé komponenty. Takto si zmapujeme, čo všetko pribliţne zákazník chce, aké komponenty uţ existujú, a ktoré môţeme znovu pouţiť, upraviť, poprípade, ktoré komponenty musíme vytvoriť nanovo. V rámci tohto procesu sa prevedie i strategický výskum, čo je získanie základných informácií o firme a o plánovanom projekte. Odpovedá na otázky typu: Aká je vízia a misia spoločnosti? Aký je cieľ produktu? Aká je konkurencia, popr. konkurenčné projekty, alebo projekty, ktoré sú inšpiráciou? Je definovaná značka? Má firma CI? Ktoré kanále chce klient pouţiť na oslovenie zákazníka? Následne sa definuje produktové prehlásenie. V prípade Centralvetu najprv prudoktové prehlásenie bolo: Vytvorenie e-shopu, so základnými informáciami o klinike. Nakoniec po konzultáciách sa dospelo k produktovému prehláseniu: Vytvorenie portálu, kde majitelia domácich zvierat nájdu všetky potrebné veci na jednom mieste, s napojením na e-shop. Na základe špecifikovanej štruktúry, strategického výskumu, skúseností z predchádzajúcich projektov, poprípade po konzultácií s technickým riaditeľom, popr. vývojármi, obchodník pripraví predbeţnú ponuku, ktorá obsahuje navrhované riešenie s moţnosťami realizácie, s navrhovanými moţnými komponentmi i rozšíreniami i nad rámec poţiadavkou od zákazníka a s minimálnou a maximálnou cenou a s moţným dátumom 84

85 dokončenia, kedy je moţné dodať projekt. Dátum dokončenia samozrejme záleţí na rozsahu projektu a nastavení spolupráce s klientom. V rámci projektu Centralvet boli navrhnuté 3 riešenia: - plné využitie open-source riešenia CMS Wordpress, ako v prípade vybudovania portál, tak i na vybudovanie e-shopu - čiastočné využitie open-source riešenia s doprogramovaním určitých komponent - vybudovanie vlastného riešenia Výstupom tohto procesu je predbeţná ponuka, výber klienta z jednej z moţností realizácie, a výber klienta čo všetko by chcel realizovať podľa navrhovaných riešení. A buď schválenie alebo neschválenie predbeţnej ponuky zákazníkom. V prípade neschválenia Predbeţnej ponuky to firmu nestojí veľa času a námahy. Takisto sa na tomto procese podieľa primárne Obchodník, takţe to ani nezaberá kapacity spolupracovníkom. V prípade schválenia predbeţnej ponuky sa určí za klienta Vlastník produktu. V prípade Centralvetu Vlastníkom produktu bola priamo i majiteľka veterinárnej kliniky, čo je ideálny prípad. V prípade Centralvetu sa nakoniec kvôli komplexnosti a plánovanému rozširovaniu portálu vybrala 3. možnosť, i keď bola najdrahšia a časovo najnáročnejšia, avšak najbezpečnejšia a bez akýchkoľvek limitov. Ukážku príkladu Prebežnej ponuky možeme vidieť v prílohe. Fáza: Pre-projektová Vstupné kritéria Úlohy Štruktúra webu Proces: Príprava predbežnej ponuky Popis projektu, určený projektový tím, rozhodnutie o pokračovaní v projekte Cieľom je identifikovať rozsah a štruktúru projektu pomocou sitemapy. Strategický výzkum Predbežná ponuka Cieľom je odpovedať na základné otázky ohľadom výsledného produktu. Povinný Účastníci: obchodník, zákazník Cieľom je připravit predbeţnú ponuku, ktorá obsahuje detailnejšiu špecifikáciu riešenia, varianty moţného riešenia, rámcové ceny a dátumy dodania Povinný Účasníci: obchodník, zákazník 85

86 Schválenie predbežnej ponuky Obchodník konzultuje so zákazníkom predbeţnú ponuku, ktorá je buď schválená, upravená, alebo neschválená. Zákazník si vyberie variantu realizácie. Povinný Účastníci: obchodník, zákazník Verifikácia Výstupné kritéria Interná v rámci tímu Predbeţná ponuka, rozhodnutie o schválení/ neschválení, určenie vlastníka produktu Tabuľka 5 Proces - Príprava predbeţnej ponuky Iniciačná fáza Na základe výstupov z pre-projektovej fáze a hlavne po schválení predbeţnej ponuky a výberu moţnej varianty riešenia, sa spraví detailnejšia analýza jednej z moţností o ktoré klient prejavil záujem. Rozpracuje sa rozsah, určí sa finálna cena a dátum dokončenia. Rozsah sa môţe meniť. Takisto sa dohodne spolupráca so zákazníkom, tj. nastavenie šprintov, určí sa vlastník produktu, zo strany klienta. V terminologií Scrumu, by sme mohli nazvať túto fázu Šprint Proces - Vytvorenie celkového modelu projektu Tento proces je ekvivalentom procesu FDD vytvorenie celkového modelu. U webových projektov nestačí popísať iba pomocou diagramu tried. Najprv sa vydefinujú role, ktoré budú vystupovať v rámci výsledného projektu. V prípade Centralvetu boli definované následujúce: Užívateľ bežný návštevník portálu, ktorý si môže prehliadať základné informácie Registrovaný užívateľ užívateľ, ktorý môže realizovať definované akcie, ktoré bežný uživateľ nemože. Administrátor môže spravovať editovať celý portál. Redaktor má obmedzené možnosti oproti administrátorovi, primárne môže spravovať články ktoré napísal. Na základe štruktúry webu a komponent, sú vytvorené oblasti, pre ktoré budeme písať uţívateľské príbehy podľa nasledujúcej šablóny: 86

87 [krátka verzia] - Ako [rola] chcem [uţivateľská potreba], aby som mohol [výsledná schopnosť] Uţívateľské príbehy sú písane do Google sheetu (obdoba excelovského dokumentu) a sú rozdelené na 3 časti: front-end, administrácia, nefunkčné poţiadavky. Dokument s uţívateľskými príbehmi primárne pripraví projektový manaţér v konzultácií s členmi tímu a následne ich podľa príkladu dopíše a rozšíri vlastník produktu. Príkladom užívateľských príbehov je: Filtrovanie článkov Ako užívateľ, chcem byť schopný si vyfiltrovať články na základe témy a mazlíčka, ktorého sa týkajú. Vloženie komentára Ako registrovaný užívateľ, chcem byť schopný vložiť komentár pod článok, aby som mohol vyjadriť svoj názor. Projektový manaţér paralelne vytvára uţ i slovník pojmov, do ktorého sa zapisujú všetky entity a ich atribúty, ktoré identifikujeme. Tento slovník budeme updatovať počas celého projektu. Na základe slovníku s definovanými entitami sa vytvorí diagram tried, ktorý zachycuje vzťahy medzi entitami. backlog. Z nadefinovaných uţívateľských príbehov projekt manaţér pripraví Produktový Fáza: Iniciačná Vstupné kritéria Úlohy Uživateľské role Uživateľské príbehy Vytvorenie modelu Produktový backlog Proces: Vytvorenie celkového modelu projektu Schválená predbeţná ponuka, vybraná jedna z moţností riešenia, určený riešiteľský tím, vlastník produktu za klienta Cieľom je vydefinovať uţiveteľské role vo výslednom produkte. Povinný Účasníci: projektový manažér, vlastník produktu Cieľom je napísanie uţivateľských príbehov. Povinný Účasníci: projektový manaţér, vlastník produktu Cieľom je vytvorenie celkového modelu - slovníku pojmov s definovanými atributami, finalizácia sitemap, identifikovanie oblastí, business class diagramu, poprípade iných diagramov ktoré sú nutné. Povinný Účasníci: projektový manažér, tím Vytvorenie celkového modelu, vytvorenie produktového backlogu. 87

88 Povinný Účasníci: projektový manažér, tím, vlastník produktu Verifikácia Výstupné kritéria Interná v rámci tímu i s vlastíkom produktu Identifikované role, sfinalizovaná sitemap, napísanie uţívateľských príbehov, slovník pojmov, produktový backlog Tabuľka 6 Vytvorenie celkového modelu projektu Proces - Nastavenie a naplánovanie projektu Cieľom tohto procesu je nastavenie spolupráce a naplánovanie časového plánu projektu. Celý riešiteľský tím sa stretne nad pripraveným Produktovým backlogom a všetkým poloţkám sa určí rozsahv MD (mandays - človekodni). Vyuţije sa metódy plánovacieho pokru. Scrum doporučuje aby sa plánovacieho pokru zúčastnoval i Vlastník produktu, avšak mi budeme s Vlastníkom produktu určovať aţ priority. Keď budú mať všetky poloţky určený rozsah, tak spoločne s Vlastníkom produktu sa určia priority jednotlivých poloţiek, lebo i na základe ich rozsahu, sa môţe rozhodnúť aká je pre neho daná poloţka dôleţitá. Definuje sa tzv. minimálny funkčný produkt. Minimálny funkčný produkt musí fungovať extrémne dobre a splňovať zákazníkove hlavné ciele. Takisto sa definuje Definícia kedy hotovo, tzn. kedy Vlastník produktu povaţuje daný poţiadavok za splnený. Ďalej sa dohodne nastavenie šprintov, tzn. ako dlho bude trvať šprint, koľko dní z pracovného týţdňa sa bude venovať projektu, kedy budú prebiehať zrazy, atď. Nastavenie šprintov súvisí s dátumom dokončenia, čím viacej dní sa bude venovať projektu, tým kratšie bude projekt trvať. V prípade Centralvetu sa dohodlo nasledujúce: Doba trvania Šprintu Počet členov tímu Plánovanie Šrintu čo? 6 dní Šprint sa bude realizovať 3 dni z týţdňa utorok, streda 4 + Vlastník produktu 1 hodina 88

89 Plánovanie Šrintu ako? Recenzia Šprintu Retrospektíva Šprintu Denný zraz 1 hodina 1 hodina 1 hodina 30 min Tabuľka 7 Nastavenie Šprintu Na základe týchto informácii Projektový manaţér určí celkové mnoţstvo času ktorý je potrebný a celkový počet šprintov a pribliţné rozdelenie, čo sa bude v ktorom Šprinte realizovať. V prípade Centralvetu, keď Vlastník produktu uvidel aké je časovo náročná implementácia produktu, tak sa celkový projekt rozdelil na 2 fáze: 1. realizácia portálu 2. realizácia e-shopu a následné prepojenie Takisto sa dohodlo, že každá fáza sa bude realizovať ako samostatný projekt. Redefinovali sme si takisto prodtuktové vyhlásenie na: Vytvorenie značky Centralvet a následne portálu, ktorý poskytne všetky potrebné informácie pre majiteľov mazlíčkov. Cieľom je mať čo najvačší počet registrovaných alebo pravidelných uživateľov. 1. Fáza projektu bola rozdelená do 7 Šprintov: Vytvorenie CI a grafického návrhu Nakódovanie základných šablón a nasadenie na CMS Proces - Finálna ponuka Projektový manaţér skompletizuje finálnu špecifikáciu, výsledný rozsah a predbeţný harmonogram a dátum dokončenia. 89

90 Obchodník na základe podkladov pripraví finálnu ponuku s finálnou cenou (ako sme si povedali, finálna cena nemusí odpovedať rozsahu, tak ako tomu bolo i v tomto prípade) a zmluvu. Hlavným výstupom je podpísanie zmluvy zákazníkom. Vstupné kritéria: špecifikácia webu, naplánované šprinty Úlohy: (obchodník) pripraviť finálnu špecifikáciu (projektový manaţér), príprava zmluvy Verifikácia: interná kontrola v rámci tímu i vlastníkom produktu, externá so stakeholderami Výstupné kritéria: pripravená finálna ponuka, zmluva, eventuálne podpísanie zmluvy Doručovacia fáza Proces - Základný grafický návrh Na základe skúseností sme zistili, ţe klienti majú najviac pripomienok a zistia, ako si to vlastne výsledný web predstavovali, aţ keď vidia skoro hotové riešenie. Nejde ani tak o to, ako je to technicky realizované, ako to funguje, ako sa to administruje, skôr ako to vyzerá. Klienti si na základe wireframeov, nedokáţu predstaviť, ako finálny web bude vyzerať. Tak väčšinou schvália predkladané prepracované návrhy bez pripomienok. Keď ale potom po niekoľkých týţdňoch vidia výsledok, tak si uvedomia, ţe si to takto vlastne vobec nepredstavovali. Preto podľa zásad agilného vývoja, na začiatku sa do detailov nerozpracováva návrh všetkých komponent, čo zbytočne zaberá čas. Wireframy preto berieme iba na vytvorenie akéhosi konceptu, na dohodu o základných veciach. Preto v rámci procesu grafik navrhne iba základ, z čoho sa potom bude všetko odvíjať. V prípade, ţe klient nemá zatiaľ svoju korporátnu identitu, alebo ju chce prerobiť, tak sa najprv vytvorí CI. V mnoho prípadoch sa jedná iba skôr o vytvorenie logo a výber korporátnych farieb, s ktorými sa bude pracovať. Klient v spolupráci s projektovým manaţérom vytvorí dokument Zadanie grafickej práce. Na základe tohto dokumentu grafik navrhne domovskú stránku a typická podstránku, ktorá obsahuje všetky základné prvky. 90

91 Pomocou základných grafických prvkov (nadpisy, tlačítka, textové polia, tabulka,atď.) sa moţu v ďalších fázach realizovať i ďalšie funkcionality a klient má stále predstavu ako to pribliţne bude vyzerať. V prípade, ţe v projekte uţ nebudú potrebné vyslovene grafické práce tak grafik reviduje grafický návrh aţ v poslednom procese fáze realizácie Revízia grafického návrhu, kde sa v prípade nutnosti, nespokojnosti, prerobí grafika všetkých component podľa zásad User experience. Pretoţe rozsah grafiky je určený, tak podľa zásady časového ohraničenia je čas dodania vţdy určený na týţdeň, alebo 2 týţdne, v prípade ţe sa navhhuje i CI. Šablóna dokumentu vţdy obsahuje následné prvky: cieľ webovej prezentácie krátky popis firmy, na čo má slúţiť webová prezentácia cieľová skupina definícia cieľovej skupiny. Napr. skúsený internetový uţívatelia do 30 rokov poţiadavky na grafiku mnoţina adjektiv, ktoré sú poţadované od grafického návrhu. Napr. web má pôsobiť moderne a prívetivo. farby rámcový výber hlavnej farby, alebo konkrétny výber farby s odkazom na webovú stránku Ak má klient predstavu tak i doplnkových, následne sa konzultuje s grafikom. inšpirácia zoznam webových prezentácii, ktoré sa páčia klientovi, s popisom, čo sa mu nich páči. Vţdy je ale prvý ten hlavný. popis loga textový popis loga, aké obrazce môţe obsahovať, plus konkrétne odkazy. Názov firmy, plus podtext. domovská stránka popis prvkov ktoré má obsahovať, napr. vyhľadávanie, kalendár, atď. Priloţený wireframe. typická podstránka popis prvkov ktoré má obsahovať: o nadpisy H1, H2, H3, H4 o typický text, perex 91

92 o formulár : textové pole, radio button, checkbox, tlačitko o tabuľka o sociálne siete Základné prvky uvedené vyššie musí grafický návrh vţdy obsahovať. V prípade potreby, môţu byť dopísané i ďalšie. Konkrétny príklad je v pilotnom projekte a v prílohe Iteratívny proces - realizácia 1 až n šprintov Realizácia prebieha iteratívne, za vyuţitia princípov Scrumu. Na začiatku kaţdého šprintu sa tím znova celý stretne, ak sa nedohovorí inak. A z produktového backlogu sa odhadne koľko uţivatelských príbehov stihne tím implementovať v rámci jedného šprintu. Ohodnotenie poloţiek v produktovom backlogu je realizované pomocou plánovacieho pokru. Kaţdý člen tímu dostane karty s číselnými hodnotami, ktoré moţno priradiť poloţkám backlogu. Tím prechádza jednotlivé poloţky, ku ktorým vţdy prebehne Stručné vysvetlenie od Vlastníka produktu nasledované diskusiou tímu o spôsobe, ako moţno poloţku implementovať. Následne kaţdý člen zvolí kartu s bodovou hodnotou, ktorá podľa naj najviac zodpovedá náročnosti poloţky. Túto kartu poloţí rubom nahor. Ako náhle sú s týmto krokom všetci hotoví, karty sa naraz otočí. pokiaľ sa zahrané karty bodovými hodnotami zhodujú, poloţka je odhadnutá. ak nie, hráči, ktorých karty so svojimi hodnotami najviac líši, podajú krátke vysvetlenie a začne ďalšie kolo, kým tím nedosiahne konsenzus. Keď je definovaný rozsah celého šprintu, tak ho identifikujeme jednou vetou, heslom pre daný šprint. Keď je definovaný rozsah šprintu, tak sa určí ktoré uţivateľské príbehy je potrebné najprv navrhnúť. Vývojári si sami určia či je potrebné najprv spraviť návrh, ktorý schváli následne vlastník produktu a priradia sa k jednotlivým návrhom. Následne sa naplánuje šprint. Keď je všetko na šprint odsúhlasené začne samotná realizácia. Pravidelne sa členovia tímu stretávajú na denných zrazoch kaţdé ráno a na retrospektívach popoludní. Fáza: Pre-projektová Proces: Šprint 92

93 Vstupné kritéria Úlohy Realízácia šprintu Retrospektíva šprintu Recenzia šprintu Grafický návrh Cieľom je realizácia určeného rozsahu Účasníci: projektový manažér, vlastník produktu, tím Tím prezentuje vlastníkovi produktu a prípadným ďalším stakeholderom spravenú prácu. Povinný Účasníci: projektový manažér, vlastník produktu, tím Cieľom je optimalizácia vnútorných procesov Šprintu. Povinný Účasníci: projektový manažér, vlastník produktu, tím Verifikácia Výstupné kritéria Interná v rámci tímu Spustiteľná časť definovej funkcionality Šprint 2 Nakódovanie šablón a nasadenie na CMS Cieľom tohto Šprintu bolo nakódovanie grafických šablón a ich následné nasadenie na CMS Šprint 3 Implementácia článkov, registrácia a prihlasovanie Cieľom tohto Šprintu bola implementácia registrovania a prihlasovania uţivateľov a následne implementácia článkov. Ukáţka administračného prostredia správy článku je prílohe Šprint 4 Implementácia kalendáru akcií Pri plánovaní Šprintu sme navrhli Vlastníkovi produktu, ţe kalendár akcií môţeme realizovať pomocou uţ hotovej komponenty a tým ušetriť čas. Vlastník súhlasil na úkor nejakých funkcionalít kalendára a získaný čas sme realizovali aplikáciu prehľad parkov, na ktorú sa kalendár často odkazuje Šprint 4 Implementácia aplikácie výber psa V rámci tohto šprintu sme pri analýze zistili, ţe ak chceme realizovať aplikáciu výber vhodného psa, je najskôr nutné ma prehľad všetkých plemien psov. Na základe tohto 93

94 zistenia sa Vlastník produktu rozhodol, ţe radšej sa zníţia poţiadavky na aplikáciu, aby sa mohol vyvinúť i tento modul a všetko sa stihlo v rámci jedného Šprintu. Takţe sme nakoniec implementovali i správu psích plemien. Keďţe ešte nakoniec zvyšoval čas, tak sme implementovali ešte podobnú aplikáciu na výber vhodnej mačky Finálna doručovacia fáza Finálna revízia projektu I keď podľa Scrumu, po kaţdom Šprinte je výsledok plne funkčný a pripravený na spustenie, tak keďţe sa vţdy jedná o komplexný projekt s veľa prepojenými prvkami, tak po skončení implementácie jednotlivých Šprintov sa vţdy deje Finálna revízia, ktorá má na starosti malé úpravy a zmeny. Do tohto procesu okrem Vlastníka procesu vstupujú i prípadný stackeholderi projektu. Keďţe sa jedná vţdy o malé zmeny, typicky grafické malé úpravy, alebo textové úpravy, tak na realizáciu týchto zmien sú určené iba 2 dni. Na riadenie týchto zmien stačí vyuţitie Google sheetov, ktorý sú nazvané Webové dodelávky a CMS dodelávky. Tieto súbory vychádzajú zo štruktúry Produktového backlogu a k jednotlivým častiam, komponentám sa píšu pripomienky a jednoducho priraďujú komentáre návrhu na zmeny. V tomto prípade znova vyuţijeme vlastností Google apps, ktoré umoţňujú paralelnú editáciu a písanie komentárov, k jednotlivým poloţkám riadkom Google sheetu. Pripomienky primárne píšu Vlastník produktu a stakeholderi, ale takisto Projektový manaţér a Technický riaditeľ. Jednotlivé pripomienky schvaľuje, poprípade vysvetľuje Kreatívny riaditeľ a Technický riaditeľ aby bola splnená poţadovaná kvalita finálneho výstupu z pohľadu UI/ UX. Reálna ukáţka dokumentu Webové dodelávky môţeme vidieť na nasledujúcom obrázku: Po zapracovaní všetkých pripomienok sa robí finálna optimalizácia pre všetky podporované prehliadače. 94

95 Fáza: Doručovacia Vstupné kritéria Úlohy Zozbieranie pripomienok Realizácia pripomienok Optimalizácia webu Proces: Finálna revízia projektu Cieľom je dostať projekt do takej fáze, aby mohol byť spustený. Cieľom je zozbieranie všetkých pripomienok, či uţ od Vlastníka produktu, alebo tímu. Povinné Účasníci: vlastník produktu, projektový manaţér, technický riaditeľ, programátor, kóder Zapracovanie všetkých pripomieniok. Povinné Účasníci: obchodník, zákazník Cieľom je optimalizovať finálne riešenie pre všetky prehliadače, poprípade i mobilné zariadenia. Verifikácia Výstupné kritéria Interná v rámci tímu Upravená finálna prezentácia obsahujúca všetky poţiadavky. Tabuľka 8 Proces Finálna revízia projektu Akceptácia Projektový manaţér prihravý Akceptačný protokol a nechá si ho podpísať klientom. Klient môţe podpísať Akceptačný protokol a vybrať si z 2 stavov: akceptované s výhradami, akceptované bez výhrad. V prípade akceptovania s výhradami sa znova zozbierajú poţiadavky a realizuje sa proces Finálna revízia projektu. Keďţe Vlastník produktu rozhodoval o všetkých zmenách uţ počas implementácie, tak neakceptovanie sa nepredpokladá. V prípade Centralvetu, keďţe Vlastník produktu v procese Finálna revízia nevenoval revízií projektu veľa času a dodal iba zopár pripomienok, tak všetky pripomienky potom dodal pri podpísaní akceptačného protokolu, takţe sa znova realizoval predchádzajúci proces. 95

96 Spustenie projektu Po úspešnej akceptácií projektu, sa projekt spustí do ostrého provozu. Po spustení sa všetkým potrebným uţívateľom pošle dokumentácia, ktorá obsahuje všetky prístupy a manuál. Fáza: Doručovacia Vstupné kritéria Úlohy Spustenie projektu Vytvorenie dokumentácie Školenie Podpísaný akceptačný protokol. Proces: Spustenie projektu Cieľom je spustenie projektu, nasadenie na Povinné Účastníci: technický riaditeľ Cieľom je vytvorenie uţívateľskej dokumentácie, ktorá obsahuje všetky potrebné prístupy a manuál a jej následné rozoslanie kompetentným osobám. Povinné Účastníci: projektový manažér Cieľom je vyškoliť potrebných pracovníkov na prácu s CMS. Nepovinné Účastníci: projektový manažér, zamestnanci klienta Verifikácia Výstupné kritéria externá s klientom Spustený web, vytvorená dokumentácia Tabuľka 9 Proces spustenie projektu Post-projektová fáza Vyhodnotenie projektu Na záver prebieha vyhodnotenie projektu. Ideálne najprv i v neformálnom prostredí, napríklad v reštaurácií, kde sa stretnú všetci členovia tímu, popr. majitelia, ale takisto ak je moţne i stakeholdery. Kaţdý člen týmu vypíše formulár ohľadom fungovania v projekte, aké videl problémy v rámci projektu a návrhy ich riešenia ak má. Takisto za klienta i vlastník produktu. Vlastník napíše a ohodnotí spokojnosť s finálnym produktom a spôsobom 96

97 fungovania. Projektový manaţér zozbiera všetky pripomienky a zhrnie ich do finálneho dokumentu Vyhodnotenie projektu ktorý obsahuje: názov klienta a názov projektu popis klienta, popis projektu, cieľ odhadovaný čas, odhadované náklady dôvod odchýlky hodnotenie klienta pripomienky, návrhy V prípade Centralvetu sme zorganizovali večeru v reštaurácií so všetkými členmi tímu i Vlastníkom produktu (v našom prípade i majiteľkou) a rovno som spísal všetky pripomienky, problémy i sme diskutovali na ich riešením. Fáza: Post-projektová Vstupné kritéria Úlohy Vyhodnocovací meeting Vytvorenie projektu Verifikácia Výstupné kritéria Úspešne spustený web. Proces: Vyhodnotenie projektu Zorganizovanie neformálneho stretnutia s účelom získať spätnú väzbu ohľadom projektu. Nepovinne Účastníci: projektový manažér, vlastník produktu, stakeholderi, tím Spísanie všetkých pripomienok, vyskytnutých problémov a návrhov ich riešenia Povinné Účastníci: projektový manažér Interná a externá s klientom Napísaný dokument Vyhodnotenie projektu Tabuľka 10 Proces Vyhodnotenie projektu Prechod do servisného módu V rámci tohto procesu projektový manaţér prihravý servisnú zmluvu pre klienta a vytvorí prístupy do servisného programu a zaškolí zodpovedných ľudí. Následne predá projekt Servisnému oddeleniu. Fáza: Post-projektová Vstupné kritéria Úspešne spustený web. Proces: Prechod do servisného módu 97

98 Úlohy Servisná zmluva Predanie servisnému oddeleniu Verifikácia Výstupné kritéria Cieľom je vybranie vhodného servisného programu pre kliena a podpísanie servisnej zmluvy Povinné Účastníci: projektový manažér, vlastník produktu, stakeholderi, tím Cieľom je predanie projektu servisnému oddeleniu Povinné Účastníci: projektový manažér Interná a externá s klientom Napísaný dokument Vyhodnotenie projektu Tabuľka 11 Prechod do servisného módu 98

99 9 Návrh metodiky pre malé projekty Ako sme si povedali v predchádzajúcej kapitole, tak metodika pre malé projekty bude vychádzať z metodiky pre stredné projekty. Výsledok týchto projektov nie je však jedinečný, jedná sa vţdy o vytvorenie parametrizovaného riešenia podľa balíčku, takţe podľa definície procesu a projektu, sa jedná o proces. Finálny proces vznikne vynechaním niektorých procesov vybraním iba potrebných procesov z jednotlivých fáz. Takisto tieto procesy sa budú realizovať v skrátenej forme. Hlavne sa vynechá iteratívna časť, lebo z definície týchto projektov sa projekt bude realizovať iba v rámci jedného Šprintu. Avšak i v tomto prípade vyuţijeme fungovanie pomocou Šprintu. Obrázok 11 Diagram procesov parametrizovaného riešenia 99

100 10 Vyhodnotenie 10.1 Vyhodnotenie projektu a metodiky Splnenie stanovených kritérií Splnenie jednotlivých kritérií, ktoré sme si stanovili na začiatku Efektívne riadenie projektov podľa ich rozsahu úspešne sa nám podarilo rozdeliť si projekty do skupín podľa ich vlastností a na základe toho riadiť pilotný projekt. O 1/3 niţšia cena oproti konkurencií nie je moţné posúdiť Skutočný rozsah projektu neprevýši plánovaný rozsah viac ako o 20% - odhad bol na 18 MD, čo sme v reále prekročili. Avšak toto prekročenie bolo sposobené politickými dovodami, tzn. chceli sme mať čo najkvalitnejší referenčný projekt Dodanie projektu v poţadovaný termín (+/- 20%) povodný datum dokončenia bol stanovený na , ale kvoli posunutiu zo strany klienta sa projekt dokončil aţ v decembri Preto nie je moţné relevantne posúdiť. Maximálna spokojnosť zákazníka s výstupom - dodanie poţadovanej funkcionality, tzn. po projekte sa následne nebudú riešiť ad hoc práce za ďalšie peniaze v rámci implementovaných vlastností. Po Vyhodnocovacom meetingu sme dostali feedback od zákazníka, ţe je maximálne spokojný s výsledným riešením. eliminácia plytvania snaţili sme sa v kaţdom šprinte vyuţívať len tie dokumenty, návrhy, ktoré boli nezbytne nutné. 100

101 Zistené problémy Tento projekt bol prvým projektom z 2. skupiny projektov realizovaných podľa navrhovanej metodiky. Takţe sa dalo očakávať viacej problémov Šprint Natrafili sme na problém s dodrţaním rozsahu a časového obmedzenia šprintu. Navrhované riešenie: Lepšie definovať DKH definícia kedy hotovo Vlastník produktu Zistili sme ze vlastník produktu môţe mať problém so zhostením sa úlohy vedenia a smerovania rozvoja projektu, produktu. V prípade tohto projektu bola vlastníkom produktu majiteľka veterinárnej kliniky, pre ktorú sa portál realizoval. Keďţe nemala skúsenosti s podobným projektom, ani skúsenosti v danej oblasti, tak mala problém s určením priorít a celkovo smerovania produktu. Navrhované riešenie: Na začiatku určiť skúsenosti vlastníka produktu a podľa toho mu nechávať voľnosť v rozhodovaní. V prípade menej skúseného vlastníka nenechávať rozhodnutia na ňom, ale skor navrhovať moţnosti riešenia a navádzať ho k správnemu riešeniu. Čím menej moţností tým lepšie. Menej skúsený zákazníci, vlastníci produktov sú väčšinou v menších firmách, kde nemajú na oblasť marketingu, poprípade IT špecializovaného zamestnanca. V prípade skúsenejšieho vlastníka produktu (marketingový specialista, niekdo z IT) je moţnosť nechať rozhodovanie na ňom Očakávania vs. funkcionalita vs. cena V tomto projekte sme takisto narazili na prehnané očakávania od tohto spôsobu vývoja a problém s určením priorít jednotlivých poţiadavkou, hlavne v prípade rušenia nejakej funkcionality v prípade prekročenia vymedzených počtu MD. Klientovi sa veľmi páčil tento prístup, avšak z našej bol tento projekt stratový. Čo bolo ale spôsobené i politikou spoločnosti, lebo firma potrebovala kvalitnú referenciu na 101

102 daný typ projektu, tak vyhovela všetkým poţiadavkám i členovia týmu navrhovali i ďalšie rozšírenia. Navrhované riešenie: Rozpracovať ako ďalšiu z tém Manaţment očakávaní. Cieľom tejto témy bude primárne návrh techniky ako určiť dostatočne včas klientovi hranice, tak aby bol plne spokojný a aby i firma nešla do veľkých strát. 102

103 Záver V tejto práci sme si vymedzili pojem metodika a spravili prehľad najznámejších metodík riadenia vývoja software. I keď existuje mnoho metodík, ktoré sa neustále vylepšujú, riadenie projektov v oblasti vývoja software stále zostáva vysoko nepredvídateľnou disciplínou, čo je spôsobené tým, ţe vývoj software, je ešte stále pomerne mladým oborom v porovnaní s ďalšími. Na otázku, ktorá z daných metodík je najlepšia neexistuje jednoznačná odpoveď a takisto neexistuje metodika, ktorá by bola vhodná pre všetky projekty. Ideálne je preto poznať viacero metodík a pre daný projekt, situáciu vybrať tú najvhodnejšiu, poprípade spojiť viacero metodík. To sme spravili pri návrhu spôsobu riadenia projektov v konkrétnej firme. Najprv sme si vydefinovali jednotlivé skupiny projektov a ich spoločné vlastnosti a následne pre ne navrhli spôsob riadenia. Keďţe sa jedná o rozsiahlu problematiku, tak neboli popísané všetky detaily, čo by v rámci rozsahu tejto práce nebolo ani moţné. Avšak sa navrhol základ riadenia projektov, hlavne pre 2. skupinu projektov. Metodika bola vyskúšaná i v pilotnom projekte, na základe ktorého sme zistili úskalia našej metodiky a navrhli ich riešenie do budúcnosti. Do budúcna sa predpokladá na základe skúsenosti úprava týchto procesov, poprípade nasadenie iných metód, popr. nástrojov. Pretoţe metodika je stále ešte mladá, tak sa predpokladá do budúcna jej postupné menenie na základe získaných poznatkov. Pomocou metodiky firma realizovala uţ i ďalšie 2 projekty, z ktorých vzišlo takisto mnoho zistení. Projektov z prvej skupiny firma uţ realizovala niekoľko desiatok a primárne sa prišlo na to, ţe je potrebné proces ešte viac zjednodušiť. 103

104 Zoznam použitej literatúry Tlačené monografie [1] OGC. Managing successful projects with PRINCE2. 5. vyd. London: TSO, ISBN [2] TURLEY, Frank. The PRINCE2 Training Manual. London: TSO, [3] BUCHLACEVOVÁ, Alena. Metodiky budování informačních systémů. Praha : Oeconomics, ISBN [4] Project Management Institut. A Guide To The Project Management Body Of Knowledge. Project Management Institut, Inc., [5] JONGERIUS, Pieter. Get Agile!: Scrum for UX, Design & Development. Fabrique, ISBN [6] RIES, Eric. The Lean Startup. New York : Crown Business, ISBN [7] SCHWABER, Ken. Agile Project Management With Scrum. Redmont : Microsoft Press, ISBN [8] SOLIS, Brain. The End of Business as Usual. Hoboken : John Wiley & Sons, Inc., Elektronická monografie [9] Manifesto for Agile Software Development [online] [cit ]. Dostupné z WWW: < [10] COCKBURN, Alistair. Methodology space [online]. c2008 [cit ]. Dostupné z WWW: < [11] FERGUSON, Chris. PRINCE2 for small-scale projects [online]. c2011 [cit ]. Dostupné z WWW: < > [12] LUCA, Jeff. The Original FDD Processes [online] [cit ]. Dostupné z WWW: < > 104

105 [13] Standish Group Chaos report [online]. Standish Group, 2013 [cit ]. Dostupné z WWW: < > [14] HAJZLER, Tomáš. Svoboda v práci [online] [cit ]. Dostupné z WWW: < [15] KAY, Sonia. Web Project Management - The practices behind succesfull web project [online]. E-consultancy, 2007 [cit ]. Dostupné z WWW: < > 105

106 Zoznam použitých skratiek Skratka COCOMO CPM CMS EV OGC PB PINO PM PMBOK PRINCE RUP XP WF Význam Constructive Cost Model Critical Path Method Content management system Earned Value Office of Government Commerce Project Board PRINCE in name only Project Management Project Management Body of Knowledge Projects in Controlled Environments Rational Unified Process extreme Programmin Wireframe 106

107 Zoznam tabuliek Tabuľka 1 Dimenzie vyvíjaného systému Tabuľka 2 Charakteristika metodík Tabuľka 3 Porovnanie rigoróznych a agilných metodík Tabuľka 4 Rozdelenie projektov Tabuľka 5 Proces - Príprava predbeţnej ponuky Tabuľka 6 Vytvorenie celkového modelu projektu Tabuľka 7 Nastavenie Šprintu Tabuľka 8 Proces Finálna revízia projektu Tabuľka 9 Proces spustenie projektu Tabuľka 10 Proces Vyhodnotenie projektu Tabuľka 11 Prechod do servisného módu

108 Zoznam obrázkov Obrázok 1 Schéma ţivotného cyklu špirálového modelu Obrázok 2 RUP fáze a disciplíny Obrázok 3 Tradičný vs. agilný prístup pri vývoji software [3] Obrázok 4 SCRUM proces Obrázok 5 Procesy FDD [12] Obrázok 6 Štruktúra PRINCE2 [2] Obrázok 7 Fáze projektu PRINCE2 [2] (vlastná úprava autor) Obrázok 8 Šesť premenných projektu [2] Obrázok 9 Navrhovaný organigram pre spoločnosť PURE IDEAS Obrázok 10 Diagram ETVX Obrázok 11 Diagram procesov parametrizovaného riešenia

109 Prílohy Príloha č. 1: Procesy v PRINCE2 Príloha č. 2: Ukáţka rozahu tématu v PMBOK - Manaţment rozsahu projektu Príloha č. 3: Wireframe pre Centralvet Príloha č. 4: Pôvodný grafický návrh Príloha č. 5: Grafický návrh po revízií Príloha č. 6: Zmena fungování navigace z pohledu UX Príloha č.7: Ukáţka práce s nástrojom Teamwork Príloha č.7: Ukáţka administračného rozhrania editácie článku Zvyšné dokumenty sú kvôli rozsahu dostupné v cloudovom úloţišti Google Drive na adrese: ing 109

110 Príloha 1 Diagram procesov PRINCE2 110

111 Príloha 2 Príklad rozsahu jednej témy v PMBOK 111

112 Príloha 3 Wireframe domovskej stránky pre projekt Centralvet 112

113 Príloha 4 Pôvodný grafický návrh 113

114 114

115 115

116 116

117 117