}w!"#$%&'()+,-./012345

Rozměr: px
Začít zobrazení ze stránky:

Download "}w!"#$%&'()+,-./012345

Transkript

1 }w!"#$%&'()+,-./012345<ya MASARYKOVA UNIVERZITA V BRNĚ FAKULTA INFORMATIKY Agilní metodiky vývoje software DIPLOMOVÁ PRÁCE Bc. Tomáš Kotrla Brno, Podzim 2005

2 Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí práce: Mgr. Barbora Zimmerová ii

3 Poděkování Rád bych poděkoval Ing. Václavu Kadlecovi za představení zajímavého odvětví agilních metodik, Mgr. Barboře Zimmerové za cenné rady a trpělivost projevenou při mém vedení a své matce za podporu a zázemí, které jsem měl během celého studia. iii

4 Shrnutí Agilní metodiky vývoje softwaru jsou v poslední době rychle se rozvíjejícím odvětvím softwarového inženýrství, kterému mnozí odborníci předpovídají slibnou budoucnost. Agilní metodiky jsou vyhledávané zejména pro svoji schopnost rychle poskytnout fungující základ systému a flexibilně reagovat na měnící se požadavky. Práce se věnuje odvětví agilních metodik vývoje software a pro důkladnější zkoumání si vybírá metodiky Extrémní programování, Crystal metodiky a Dynamic Systems Development Method, které popisuje a srovnává. Součástí práce je náčrt řešení případové studie pomocí vybraných metodik. iv

5 Klíčová slova vývoj software, agilní metodiky, Extrémní programování, XP, Crystal metodiky, Crystal Clear, Dynamic Systems Development Method, DSDM v

6 Obsah 1 Úvod Struktura práce Agilní metodiky Charakteristika agilních metodik Srovnaní s klasickým přístupem Manifest agilního vývoje software Hodnocení agilních metodik Vybrané agilní metodiky Extrémní programování Principy Role Postupy Životní cyklus Hodnocení Crystal metodiky Principy Role Postupy Životní cyklus Hodnocení Dynamic Systems Development Method Principy Role Postupy Životní cyklus Hodnocení Srovnání vybraných metodik Principy Role Postupy Případová studie Výchozí podmínky Extrémní programování Crystal Clear Dynamic Systems Development Method Srovnání životních cyklů Závěr Literatura vi

7 Seznam obrázků 2 Agilní metodiky Srovnání tradičních a agilních přístupů 3 3 Vybrané agilní metodiky Životní cyklus podle XP Volba odpovídající metodiky z rodiny Crystal Cykly projektu řízeného metodikou Crystal Clear Životní cyklus podle DSDM 36 4 Případová studie Ukázka karty zadání Ukázka úkolové karty Ukázka bleskové plánovací karty 49 1

8 Seznam tabulek 2 Agilní metodiky Vlastnosti agilních metodik 8 4 Případová studie Část karet zadání vybraných do první iterace 46 2

9 Kapitola 1 Úvod Potřeba vývoje software je stejně stará, jako první počítače. Tato disciplína se musela vypořádat s řadou problémů a prodělala tak mnoho změn. Od, ve své době, revolučního vývoje podle modelu vodopád se přes spirálový model dostala až k současným sofistikovaným přístupům k vývoji software. Úspěšným zástupce takových přístupů je metodika firmy IBM s názvem Rational Unified Process [8], zkráceně RUP. V poslední době se však objevili nové metodiky, které směle slibují rychlejší a levnější dodávky software. Jsou souhrnně označované jako agilní. Přitahují na sebe čím dal tím větší pozornost a část odborné veřejnosti jim předpovídá slibnou budoucnost. Úkolem a cílem práce je získat přehled o agilních metodikách a následně je zhodnotit. Druhým úkolem je výběr tří metodik a jejich vzájemné srovnání. Posledním úkolem je pak ukázka vývojového cyklu pomocí případové studie. 1.1 Struktura práce Práce je rozdělena na pět kapitol, v první uvádím zadání práce a definuji její cíle. V kapitole 2. Agilní metodiky charakterizuji agilní metodiky, věnuji se důvodům jejich vzniku, srovnávám je s tradičními přístupy a hodnotím jejich vlastnosti. Na začátku kapitoly 3. Vybrané agilní metodiky si vybírám trojici agilních metodik, kterým se v práci více věnuji. Každou stručně představuji, uvádím její principy, definované role v týmech, předepsané postupy, typickou podobu vývojového cyklu a vyjadřuji hodnocení dané metodiky. Na závěr srovnávám principy, role a postupy vybraných metodik, přičemž se zaměřuji většinou jen na rozdíly. V kapitole 4. Případová studie se snažím stručně ukázat průběh projektu ve vybraných metodikách a nakonec metodiky srovnat na základě jejich vývojových cyklů. Poslední kapitola je závěrem práce, kde shrnuji výsledky práce a zabývám se možnostmi dalšího bádání v oblasti agilních metodik. 1

10 Kapitola 2 Agilní metodiky Tato kapitola se věnuje obecně všem agilním metodikám, popisuje jejich přístup k vývoji software, uvádí jejich společné principy a rozdíly oproti tradičním přístupům. Kapitola je ukončena stručným hodnocením obsahujícím výčet pozitivních a negativních vlastností agilních metodik. 2.1 Charakteristika agilních metodik V angličtině se agilní metodiky označují jako agile methodologies. Toto spojení lze přeložit jako čilé, hbité nebo živé metodiky. Dříve se užíval pojem lightweight methodologies, který měl zdůraznit lehkost metodik (z pohledu produkované dokumentace), tento pojem má však více různých významů, a tak se od jeho používání postupně upustilo. Samotné překlady uvedené v předchozím odstavci výstižně popisují cíle agilních metodik, vývoj software má být hbitý (software je dodán v co nejkratším čase), lehký (vývoj se omezuje jen na potřebné činnosti a tvorbu nutných dokumentů) a živý (software musí být úspěšně dodán, tedy celý projekt má přežít). Vzhledem k rostoucímu počtu firem v oboru ICT 1 získává ekonomická stránka vývoje software na významu. Pokud chce firma v konkurenci obstát, musí být schopná dodat software v co nejkratším čase a udržet přitom minimální náklady. Důvod je zřejmý, zakázku získá konkurenční firma, která je schopná vyvinout software rychleji a levněji. Je nutné si uvědomit, že se při vývoji uvažují dva různé časy. Prvním je celkový čas, který zabere realizace softwarového řešení, tedy od počátečního sepsání smlouvy až po akceptaci konečného řešení. Druhým a významnějším uvažovaným časem je doba potřebná k dodání první fungující části software 2, kterou již může zákazník používat při své práci. Minimalizace právě druhého uvažovaného času je pro vývoj software klíčová z dvou hlavních důvodů. Fungující část software zákazníkovi přináší užitek a tím i určitý příjem, který snižuje náklady na vývoj zbývajících částí software. Čím dříve zákazník uvidí systém v provozu, tím dříve získává vývojový tím zpětnou vazbu. Dalším významným faktorem je psychologie práce ve skupině. Agilní metodiky považují motivované lidi v týmu za klíčový předpoklad pro úspěšný vývoj. Proto se agilní metodiky zaměřují na pracovní prostředí, na zajištění podpory všem členům týmu, aby mohli 1. Informační a komunikační technologie (Information and Communications Technology) 2. Tento čas je často označován zkratkou TTM (Time To Market) 2

11 2.2. SROVNANÍ S KLASICKÝM PŘÍSTUPEM odvádět svou práci co nejlépe, na vzájemnou komunikaci mezi členy týmu i mezi týmem a zákazníkem. Z pohledu agilních metodik jsou lidé významnější, než dodržované postupy, produkované dokumenty nebo používané nástroje. 2.2 Srovnaní s klasickým přístupem Předchozí část kapitoly byla úvodem do oblasti agilních metodik, v této části jsou zdůrazněny základní principy agilních metodik včetně jejich srovnání s tradičními přístupy. Výstižně tyto různé přístupy srovnává obrázek 2.1 převzatý z přednášky Agilní metodiky [4] Aleny Buchalcevové. Obrázek 2.1: Srovnání tradičních a agilních přístupů Z obrázku 2.1 je patrné, že tradiční přístupy považují za fixní funkcionalitu, tedy podepsanou specifikaci na začátku projektu, která se dále v průběhu projektu nemění. Implementace takové specifikace následně zabere nějaký čas a spotřebuje určité zdroje (platy vývojářů a kapitál firmy). Hodnoty těchto proměnných jsou při plánování v úvodní fázi odhadnuty, během průběhu projektu se však mohou a často také mění, vývoj pak trvá déle a stojí víc. Agilní metodiky oproti tradičnímu přístupu zaměňují fixní a volné proměnné. Na začátku se odhadnou a pevně naplánují potřebné zdroje a čas, funkcionalita je ponechána jako volná proměnná jejíž hodnota je upravována podle aktuální úspěšnosti projektu, jinými slovy v případě problémů se implementace části funkčnosti odloží v zájmu dodržení termínu. Zdrojový kód jako nositel informace Jak uvádí Václav Kadlec ve své knize Agilní programování [3], agilní metodiky produkují mnohem méně formální dokumentace, vycházejí totiž z přesvědčení, že základním, jednoznačným, exaktním, nezpochybnitelným a spolehlivým nositelem informace je zdrojový 3

12 2.2. SROVNANÍ S KLASICKÝM PŘÍSTUPEM kód. Toto přesvědčení nesdílí tradiční přístupy, které vývoj software staví na tvorbě různě objemných dokumentací (formální specifikace, detailní návrh, apod.) před samotným psaním zdrojového kódu. Důraz na dokumentaci je způsoben strachem z neúspěšného projektu, nutností rozumného udržení znalostí a mnohdy přímo vynucen uzavřenou smlouvou. Iterativní a inkrementální vývoj Plán projektu podle agilních metodik sestává z velmi krátkých iterací, během nichž se postupně vyvíjí inkrementy výsledného software. Získává se tak dříve zpětná vazba a eliminuje riziko, kdy vývojový tým na konci dodá něco, co zákazník vůbec nechtěl. Zároveň tým dříve zjistí integrační problémy. Výhody iteračního a inkrementálního vývoje jsou nesporné, našli si proto své místo i mezi tradičními přístupy (spirálový model, iterace a buildy v metodice RUP). Agilní metodiky se tedy liší jen tím, že jejich iterace bývají většinou kratší. Přímá osobní komunikace Mnoho komplikací během vývoje způsobuje špatná komunikace a problémové vztahy mezi členy týmu. Agilní metodiky se tyto komplikace snaží řešit utužováním vzájemných vztahů a zavedením časté osobní komunikace do základních činností vývoje. V každém týmu je osoba zodpovědná za včasné zjištění a vyřešení všech komunikačních problémů. Osobní komunikace je považována za nejlepší způsob předání informace. Tradiční přístupy se většinou zabývají více činnostmi vývoje než vztahy mezi lidmi. Řešení společenských problémů je spíše ponecháno na umu vedoucích pracovníků. Osobní komunikace není tradičními přístupy samozřejmě potlačována, je však vyžadována komunikace podle určených formálních pravidel. Důvodem je snaha o zaznamenání všech důležitých rozhodnutí a o udržení uceleného systému znalostí. Blízká spolupráce s uživatelem Agilní týmy během své práce často komunikují s budoucími uživateli, upřesňují si tak potřebné informace o fungování zákazníkova obchodu nebo o požadavcích na software. Tato komunikace je ve stejné míře během celého projektu, v ideálním případě jsou zástupci budoucích uživatelů přímo členy týmu. Tradiční přístupy oproti tomu s uživateli komunikují na začátku během psaní specifikace, v průběhu během občasných doplňujících schůzek, případně při předvádění prototypů a nakonec během akceptace dodaného software. Lze tedy říci, že komunikace je celkově menší a v průběhu projektu nerovnoměrně rozprostřená. Průběžné testování Vyvíjený software se často během projektu mění, proto je důležité jeho důkladné regresní testování často a pravidelně prováděné v průběhu celého vývoje. Znovu otestování celého software je většinou nelehký úkol, je tedy nutné software navrhovat tak, aby jeho testování 4

13 2.3. MANIFEST AGILNÍHO VÝVOJE SOFTWARE bylo co nejsnazší a aby ho bylo možné realizovat pomocí nástrojů pro automatizované testování. Metodika Extrémní programování dokonce trvá na vytváření příslušných testů dříve, než programátor přistoupí k implementaci daného požadavku. Při tradičním přístupu etapa testování navazuje na etapu implementace. Detaily provádění samotných testů jsou většinou specifické pro konkrétní projekt. Zpravidla je vyžadováno, aby testování a implementaci prováděly různé osoby a snížila se tak pravděpodobnost opakování chybného porozumění specifikaci. 2.3 Manifest agilního vývoje software Jednotliví autoři se snažili při vytváření metodik reagovat na nové potřeby kladené na úspěšný vývoj software. Dřívější potřebu spolehlivého software v současnosti doplňují nové potřeby jako ekonomická stránka vývoje nebo psychologie skupinové práce, zmiňované již v úvodu této kapitoly. Nejdříve každý autor považoval svou metodiku za ojedinělou, v únoru 2001 ze společného setkání v Utahu vyplynul opak, vznikající metodiky měly řadu společných tezí. Vznikla tak Aliance pro agilní vývoj software [1], zastřešující jejich společnou činnost a byl sepsán Manifest agilního vývoje software [2], kde jsou vyjmenovány společné teze, některé překlady jmen tezí uvedených dále jsou převzaty z knížky Agilní programování [3] od Václava Kadlece. Základní myšlenky manifestu jsou: přijmout a umožnit změnu požadavků je efektivnější než jí bránit, požadavek na změnu se určitě objeví. Na základě uvedených myšlenek autoři manifestu dávají přednost: individualitám a komunikaci před procesy a nástroji, provozuschopnému software před obsáhlou dokumentací, spolupráci se zákazníkem před vyjednáváním formálních smluv, reakci na změnu před striktním plněním plánu. Na základě uvedených myšlenek a předností formulovali autoři manifestu následující teze. Užitná hodnota pro zákazníka Zákazník má větší užitek z dodaného fungujícího software než z rozsáhlé dokumentace v podobě UML-diagramů a ERA-modelů. Metodiky proto davají větší prioritu vyvíjenému software než jeho dokumentaci. 5

14 2.3. MANIFEST AGILNÍHO VÝVOJE SOFTWARE Vítané změny Prostředí, ve kterém zákazník podniká, se většinou rychle mění, proto požadavky identifikované na začátku projektu (při psaní specifikace) nemusí být na konci projektu žádané, mohou se výrazně změnit nebo dokonce zrušit. Přidaní nového požadavku až v průběhu realizace projektu může znamenat významnou konkurenční výhodu pro zákazníka. Z těchto důvodů metodiky nefixují požadavky v úvodních fázích, ale přizpůsobují vývoj a plánovaní měnícím se požadavkům. Časté dodávky Vývoj software je iterativní a inkrementální. Dodávky nových verzí jsou v co možná nejkratším intervalu. Tím získává tým od zákazníka včasnou zpětnou vazbu a zákazníkovi přináší bežící software očekávaný užitek. Zákazníci spolupracují s týmem Vítané změny znamenají, že vývojový tým nemá detailní specifikaci k dispozici od začátku implementace, proto jsou nutné časté konzultace se zaměstnanci zákazníka k upřesnění specifikace. Klíčová motivace Základem úspěšného vývoje jsou lidé. Ti musí být patřičně motivovaní a musí jim být dána dostatečná důvěra a kompetence k dělání klíčových rozhodnutí. Vzájemná konverzace Přímá konverzace je nejrychlejší a nejefektivnější formou přenosu informace. Pokud ji podmínky umožňují, je snadnější než psaní a čtení dokumentace. Úspěch posuzujeme podle fungování Fungující software je primárním ukazatelem průběhu projektu. Udržitelný vývoj Lidé nevydrží efektivně tvořit, pokud musejí být v práci dlouhodobě přesčas. Udržitelný vývoj znamená, že lidé dlouhodobě nepřekračují standardní pracovní dobu. Perfektní návrh a řešení Vzhledem k častým změnám v požadavcích je nutné mít perfektní návrh a řešení, které umožní rychlé zapracování změn do již vyvinutého systému. Změna návrhu nebo zdrojových kódů je považována za přirozenou věc při agilním vývoji, neznamená tedy selhání některé předchozí činnosti. Návrh a implementace probíhají současně, navzájem se prolínají ve velmi krátkých cyklech. 6

15 2.4. HODNOCENÍ AGILNÍCH METODIK Jednoduchost Základem úspěchu je udělat minimum práce přinášející maximum užitku. Vyvíjený software je postupně skládán z jednoduchých částí, které lze snadno změnit. Očekávání častých změn způsobuje maximální možné odkládání implementace požadavků. Samoorganizující se tým Nejlepší výsledky mají samoorganizující se týmy obsahující schopné a kreativní členy, kteří spolu často komunikují. Zdokonalování Během vývoje se často hledají slabá místa a způsoby jejich odstranění. Stejně tak se hledají silné stránky a jejich možné vylepšení. Celkově tato snaha vede ke zvýšení efektivity vývojového týmu. 2.4 Hodnocení agilních metodik Osobně si myslím, že žádná metodika (ani tradiční přístup) nemůže zaručit úspěch každého projektu. Za nejvýznamnější faktor ovlivňující úspěch projektu považuji vlastnosti a schopnosti všech zainteresovaných lidí, které mají mnohem větší vliv než používaná metodika nebo nástroje. Vycházím z předpokladu, že tým rozumných, schopných a zkušených lidí si sám najde pro něj vhodné a potřebné postupy, jak kvalitně a v požadovaný čas (pokud je reálný) vyvinout požadovaný software. Pokud v týmu převládají lidé opačných vlastností a pokud ještě zastávají vedoucí pozice, pak rozsáhlejší a složitější projekt s velkou pravděpodobností skončí neúspěchem. Z jednotlivých prací a metodik autorů agilního manifestu je patrné, že jejich názory jsou stejné jako můj (uvedený v předešlém odstavci). Agilní metodiky tak nelze chápat jako univerzální návody jak tvořit software, ale je nutné je brát jako soubor doporučení, rad, návodů a možných přístupů, který nám poskytují na základě svých dlouhodobých zkušeností autoři metodik. Agilní metodiky obsahují řadu postupů, jejichž nevhodné použití týmu přinese další komplikace. V případech kdy tyto postupy použít lze, dokáží naopak urychlit a usnadnit vývoj software. Je tedy na odpovědnosti vedoucích pracovníků rozhodnout, zda lze metodiku nebo její část použít. V tabulce 2.1 uvádím kladné a záporné body použití agilních metodik, jejich poměr je vyrovnaný. Iterativní a inkrementální vývoj je nespornou výhodou, jsou určeny pevné termíny dodání jednotlivých verzí. Ty bohužel mají nezaručený rozsah, protože nelze dopředu určit, jaké komplikace se objeví a jak zredukují rozsah prováděné iterace. Není známý postup, jak rozsah zaručit, pravděpodobně žádný takový postup ani nemůže existovat. Pro zákazníka je lepší vědomí, že v daném termínu dostane verzi s nezaručeným obsahem, než čekání neznámou dobu na verzi v plném rozsahu. 7

16 2.4. HODNOCENÍ AGILNÍCH METODIK Kladné iterativní a inkrementální vývoj brzy první verze zdůrazňují význam komunikace regresní testování flexibilní reakce na změny optimalizace metodik Záporné nezaručené rozsahy verzí smlouva nelze formalizovat omezují dokumentaci testuje přímo autor nadprůměrné schopnosti nelze na částečný úvazek Tabulka 2.1: Vlastnosti agilních metodik Metodiky přistupují k implementační fázi velmi rychle, během krátké doby tak vyvinou první verzi software s omezenou funkčností. I tak ale většinou lze software již komerčně využít. Na začátku projektu te těžké odhadnout přesně cenu vývoje a podrobně určit jednotlivé milníky. Lze tedy těžce sepsat nějakou formálnější smlouvu. Pro agilní metodiky je vhodnější zákazník, který týmu důvěřuje a je ochoten přistoupit na neformálně sepsanou smlouvu. Pro zákazníka by mohl být vhodný tzv. team outsourcing, tedy pronajmutí a řízení celého týmu. Měl by tak lépe pod kontrolou své výdaje a práci týmu. Komunikace je pro vývoj důležitá. Myslím si, že každý tým na světě si toho je vědom. Považuji za klad agilních metodik, že se snaží o nastavení podmínek k efektivní komunikaci. Nelze však spoléhat pouze na přímou komunikaci. Důležité závěry a poznatky musí být poznamenané na nějaké místo, kde je půjde v případě potřeby snadno dohledat. Pokud by se dokumentace zcela vynechala, tým by se mohl dostat do problémů. Nelze spoléhat na vědomosti a znalosti obsažené jen v hlavě programátorů a zdrojovém kódu, lidé zapomínají a jejich vlastní kód jim časem nebude dávat smysl. Testování je další nesporně výhodná vlastnost. Rizikem však je, pokud programátor testuje vlastní výtvor. Připouštím však, že v agilním pojetí vývoje nelze čekat, až vytvoří test někdo další. Regresní testování poskytuje týmu velkou míru jistoty, protože jeho pomocí lze najít zavlečenou chybu ve všech částech systému. Z rostoucím objemem systému však i roste rozsah potřebných testů a tím rostou i náklady na jejich tvorbu, údržbu a běh. Proto považuji za vhodnější použití metody Risk Based Testing 3 (RBT), kdy se testování zaměřuje jen na nejvýznamnější část systému. Určení takové části je ale nejkomplikovanějším prvkem RBT. Agilní metodiky jsou ceněné pro svou schopnost flexibilní reakce na změnu požadavků. Aby toho byly schopné, potřebují mít v týmu schopné lidi. Tohle je ale slabé místo metodik, protože na trhu práce nemusí být dostatečný počet uchazečů, kteří mají požadované znalosti a zkušenosti. V průběhu projektu pravidelně věnují agilní metodiky určitý čas a úsilí k optimálnějšímu nastavení svých parametrů. Kontrolují správnost odhadů, hledají možná zlepšení. Vývojový proces se tak postupem času stává lépe ovladatelným a efektivnějším. 3. Informace lze nalézt na <www.riskbasedtesting.com/> 8

17 2.4. HODNOCENÍ AGILNÍCH METODIK Agilní metodiky je těžší realizovat v týmech zaměstnávajících studenty na částečný úvazek, protože nejsou k dispozici po celou dobu a přicházejí tak o část komunikace. Její zprostředkování nepřítomným je možné, ale zatíží a zpomalí to tým prací navíc. Agilní metodiky jsou zajímavým přístupem k tvorbě software, své uplatnění naleznou při projektech, ve kterých nejsou na začátku zcela jasné požadavky nebo se v průběhu projektu značně mění. Slibují časté a pravidelné dodávky software. Vyžadují úzkou spolupráci s uživateli. Agilní metodiky nelze použít při projektech, kde je provádění změn v průběhu projektu nákladné nebo dokonce nemožné. 9

18 Kapitola 3 Vybrané agilní metodiky Mezi nejznámější agilní metodiky patří Extrémní programování (XP) SCRUM Development Process Crystal metodiky Vlastnostmi řízený vývoj (FDD) Dynamic System Development Method (DSDM) Adaptivní vývoj software (ASD) Lean Development Testy řízený vývoj (TDD) Pro důkladnější zkoumání byly vybrány metodiky Extrémní programování, Crystal metodiky a Dynamic System Development Method, tato a následující kapitola 4 Případová studie se jim postupně věnují. Informace o ostatních metodikách je možné nalézt v přednášce Aleny Buchalcevové Agilní metodiky [4], v knize Václava Kadlece Agilní programování [3], v diplomové práci Tomáše Hajdina Agilní metodiky vývoje software [6] nebo v práci Agile software development methods [11]. Každá podkapitola nejprve metodiky stručně charakterizuje. Následně jmenuje principy, na kterých jsou metodiky postavené. Zabývá se rolemi, které lze identifikovat v týmech ctících danou metodiku. Poté uvádí postupy metodik odvozené z jejich principů. Je popsán životní cyklus vývoje software podle zvolené metodiky. Na závěr je uvedeno stručné hodnocení metodiky. Některé detaily metodik jsou prezentovány až v následující kapitole 4 Případová studie, spolu s náčrtem řešení studie vybranou metodikou. Poslední podkapitola obsahuje přehledné srovnání vybraných metodik. 10

19 3.1. EXTRÉMNÍ PROGRAMOVÁNÍ 3.1 Extrémní programování Extrémní programování (XP) je jednou z nejznámějších agilních metodik. Pojmy XP a agilní metodiky jsou dokonce někdy nesprávně považovány za ekvivalentní. Tato podkapitola podrobněji popisuje tuto metodiku na základě informací získaných z knihy Extrémní programování [12], jejímž autorem je Kent Beck. Kniha byla přeložena do češtiny před třemi lety, metodika jistě prošla řadou zlepšení, které zde tak nejsou zahrnuty. Extrémní programování vznikalo během devadesátých let minulého století na základě praktických zkušeností jeho autorů, kterými jsou Kent Beck a Ward Cunningham. Je postavené na známých a běžných postupech, ale dotahuje tyto postupy do extrémů. Když se vyplácí revize, tak se reviduje neustále. Pokud je nutné testovat, tak se testuje několikrát denně. XP pomocí svých principů a postupů dovádí do extrému všechny části vývoje software jako jsou revize kódu, testování aplikace, návrh architektury, integrace systému a iterační vývoj. Stejně tak se XP snaží bojovat proti rizikům jako zpoždění harmonogramu, zrušení celého projektu, krachující systém, zvětšující se míra poruchovosti, nepochopení zadání, průběžné změny zadání, přemíra funkcí a fluktuace pracovníků. Základem celého vývoje software je pro XP psaní zdrojového kódu a testování. Prostřednictvím zdrojového kódu komunikují členové týmu. Výsledky spouštěných testů vypovídají o stavu projektu. XP vychází z představy, jak by vývoj vypadal, kdyby na něj bylo dost času. Vývojáři by psali dobře strukturovaný a řádně otestovaný kód. Psaní zdrojového kódu a testovaní se v metodice XP prolíná. Programátoři během dne střídavě píší jednotlivé testy a implementace, nejdříve test jedné funkčnosti, následně její implementaci. Když test projde, přechází se na další funkčnost. Tento způsob vývoje řízeného testy je možné použít jako samostatnou metodiku Test Driven Development (TDD), Kent Beck ji popisuje v knize Programování řízené testy [10]. Informace lze také nalézt v knize Václava Kadlece Agilní programování [3] nebo diplomové práci Tomáše Hajdina Agilní metodiky vývoje software [6]. Další důležitou činností v XP je poslouchání. Kent Beck tvrdí, že nejlepším způsobem komunikace je rozhovor, a proto je XP navrženo tak, aby maximálně podporovalo a vynucovalo vzájemnou komunikaci jak mezi jednotlivými programátory, tak mezi programátory a zákazníkem. Konkrétně to zajišt ují postupy s jménem párové programování a zákazník na pracovišti, které jsou spolu s dalšími postupy vysvětleny v kapitole Postupy. Poslední podstatnou činností pro XP je navrhování. Navrhování provádějí všichni programátoři každý den. XP klade důraz na zdrojový kód, a tak programátory nenutí ke kreslení diagramů, pokud to sami nechtějí. Návrh systému začíná psaním testů, kdy si musí programátoři dobře rozmyslet rozhraní vyvíjené aplikace, nebot právě toto rozhraní testují. Dalším postupem, kdy se programátoři plně věnují navrhování je refaktorizace, tedy změna zdrojového kódu při zachování funkčnosti. Více je postup refaktorizace popsán v kapitole Postupy, detaily pak obsahuje kniha Refaktoring [9], jejímž autorem je Martin Fowler. Při své práci se snaží programátoři navrhnout a udržet vyvíjený systém v nejjednodušší možné podobě, která může ještě fungovat a přitom přináší zákazníkovi očekávaný užitek. Pro řízení vývojového procesu uvažuje XP čtyři řídící proměnné, jsou to náklady, čas, 11

20 3.1. EXTRÉMNÍ PROGRAMOVÁNÍ kvalita a šíře zadání. Zákazníci nebo manažeři zadávají hodnoty tří libovolně zvolených proměnných, vývojový tým pak určí odpovídající hodnotu zbývající proměnné. Tento přístup vychází z jednoduchých úvah. Například když má málo lidí v krátkém čase udělat moc práce, jsou ve stresu a výsledky jejich snažení nedosahují odpovídající kvality. Ve většině případů stres a nereálné požadavky způsobí zpoždění projektu a s tím i zvýšené náklady. Právě z těchto důvodů XP říká, že týmu nelze nadiktovat hodnoty všech řídících proměnných, ale musí mu být dáno právo určit odpovídající hodnotu zbývající proměnné. Pokud nejsou manažeři s odpovědí spokojeni, mohou si vybrat jiné tři proměnné, ale nikdy nesmí určovat hodnoty všech čtyř proměnných. Za nejvhodnější volnou proměnou pak XP považuje právě šíři zadání Principy Tato část práce prezentuje principy XP tak, jak jsou uvedené v knize Kenta Becka Extrémní programování [12]. Prvních pět principů je považovaných za hlavní, zbytek pak za doplňkové. Rychlá zpětná vazba Doba reakce je důležitá kvůli učení. Společnost se naučí, jak může systém nejlépe přispívat, a tento poznatek předá zpětnou vazbou během dnů či týdnů, a nikoliv během měsíců nebo let. Programátor se naučí, jak systém nejlépe navrhnout, implementovat a testovat, a tento poznatek předá zpětnou vazbou během vteřin či minut, a nikoliv během dnů, týdnů nebo měsíců. Předpoklad jednoduchosti Dělejme systém co nejjednodušší, složitější věci přidávejme až když jsou opravdu třeba. Vyvíjíme pro dnešek, ne pro zítřek. Věříme ve své schopnosti kdykoliv přidat požadovanou funkčnost, nemusíme s ní tedy počítat předem. Jednoduchý systém se lehce testuje, je přehledný a snadný na údržbu. Přírůstková změna Nelze udělat velkou změnu najednou. Návrh, plán a velikost týmu se musí měnit postupně. Nemůžeme vše navrhnout okamžitě, svůj návrh upřesňujeme za základě znalostí již vyvinutého systému a zjištěných problémů. Stejně tak nevíme, jak přesně bude vývoj probíhat, proto nemůže provést důkladné plánování hned na začátku. Nejprve vytvoříme hrubý odhad, který postupně upřesňujeme pro každou iteraci. Je nesmyslné mít na začátku projektu tým čítající deset programátorů, pokud máme práci sotva pro dva. Dokonce i přijmutí XP je postupné, po malých krocích. Nejdříve se použije XP na část, se kterou má náš vývoj největší problémy. Využití změny 12

21 3.1. EXTRÉMNÍ PROGRAMOVÁNÍ Nejlepší strategie je ta, která zachovává nejvíce možností a přitom skutečně vyřeší ten nejnaléhavější problém. Tento princip souvisí s předpokladem jednoduchosti. Vyvíjený systém je nejjednodušší možný, který pokrývá všechny klíčové požadavky. Přidanou hodnotou využití změny je pak možnost rychle reagovat na změněný požadavek a uvedení nové funkčnosti do provozu dřív než konkurence. Kvalitní práce Práce bude tým bavit, jen pokud ji bude odvádět kvalitně, tedy kvalita není ve skutečnosti volná proměnná, může nabývat jen dvou hodnot a to vynikající a neuvěřitelně skvělá. Kvalitní práce je důležitou složkou XP, tuto metodiku není možno provozovat s týmem neobsahujícím velmi zkušené programátory. Tým se nemusí skládat jen z výborných programátorů, musí však obsahovat alespoň nějaké, kteří budou svým vlivem zdokonalovat méně zkušené programátory. Výuka poznatků Metodika XP se zaměřuje na výuku strategií k získávání poznatků o tom, kolik testování, navrhování, refaktorizace a všeho ostatního bychom měli provádět. Těmto strategiím dává přednost před dogmatickými postupy, jak dělat určitou činnost. Malá počáteční investice Nízké rozpočty nutí programátory a zákazníky, aby zredukovali své požadavky a přístupy. Většinou všichni vystačí s nižšími prostředky, než které by chtěli. Prostředky však mohou být také příliš malé. Hraní na výhru Vývoj programového vybavení hraný na výhru dělá všechno, co týmu pomůže vyhrát a nedělá nic, co k výhře nepomůže. Opakem je hraní, aby se neprohrálo, kdy se vše dělá předpisově, aby jsme byli krytí, když se projekt nepovede. Konkrétní experimenty Neotestovaná rozhodnutí představují riziko, že nebudou správná. To znamená, že debata o návrhu nebo o požadavcích by měla vyústit v řadu experimentů, které prověří jejich realizovatelnost. Všechna abstraktní rozhodnutí by měla být takto otestovaná. Otevřená a upřímná komunikace Dobrá komunikace je jeden z nejnutnějších předpokladů úspěšného vývoje software. Pokud je dlouhá doba odezvy, nebo někdo něco podstatného nesdělí ostatním, protože zapomněl nebo se bál, má to negativní vliv na celkový vývoj. Programátoři proto musejí mít absolutní svobodu, aby mohli vyjadřovat své obavy a získávat podporu, aby mohli sdělit nedobrou zprávu zákazníkům a manažerům, aby ji mohli sdělit včas a aby za ní nebyli potrestáni. 13

22 3.1. EXTRÉMNÍ PROGRAMOVÁNÍ Práce v souladu s lidskými instinkty Lidé rádi vyhrávají. Lidé se rádi učí. Lidé se rádi stýkají s jinými lidmi. Lidé mají rádi, když jsou součástí týmu. Lidé jsou rádi, když mají kontrolu. Lidé jsou rádi, když se jim věří. Lidé rádi odvádějí dobrou práci. Lidé jsou rádi, když jejich software funguje. XP se shoduje s pozorováním programátorů v divočině cituje Kent Beck ve své knize [12]. Přijetí odpovědnosti Odpovědnost musí být přijata, nikoliv předána. Pokud však tým dospěje k rozhodnutí, že je třeba splnit určitý úkol, někdo si ho bude muset vybrat bez ohledu na jeho nepříjemné stránky. Místní přizpůsobení XP nemůže být univerzální kuchařkou. Každý tým, který chce XP přijmout, si ho musí přizpůsobit vlastním podmínkám. XP může jen upozornit na následky při odbočení od některých jeho principů. Cestování nalehko Udržované nástroje by měli splňovat tři vlastnosti, měl by jich být malý počet, měli by být jednoduché a hodnotné. Potřeba jsou jen testy a zdrojový text. Poctivé měření Měření je podstatné při vývoji, protože slouží ke sledování a kontrole jeho průběhu. Důležité je pro měření zvolit odpovídající přesnost, která bude mít dostatečnou vypovídající hodnotu a nebude zatěžovat tým více než je nutné Role XP v týmu uvažuje následující role. Některé mohou být obsazené stejným člověkem. Například povinnosti kouče a stopaře většinou plní jeden člověk. Kouč Má na starosti celý tým. Je k dispozici jako vývojový partner, zejména pro nové programátory. Sleduje dlouhodobé cíle refaktorizací. Pomáhá programátorům s jednotlivými technickými dovednostmi jako testování, formátování a refaktorizace. Vysvětluje proces manažerům na vyšších úrovních. Tým by měl řídit spíše jemným nasměrováním než pomocí autoritativních příkazů. Stopař Jeho úkolem je sledovat aktuální metriky a hlídat, zda projekt pokračuje podle plánů a přání. Zároveň zajišt uje, aby tým viděl, jak si na tom právě stojí. Toho dosahuje vyvěšováním různých statistik na tabule v pracovní místnosti. 14

23 3.1. EXTRÉMNÍ PROGRAMOVÁNÍ Programátor Je základem týmu, odhaduje pracnost zadání a jednotlivých úkolů během plánovací hry. Psaním unit testů analyzuje požadavky a navrhuje rozhraní vyvíjeného systému. Komunikuje se zákazníkem a ostatními programátory při upřesňování požadavků a jejich řešení. Během párového programování dva programátoři píší testy, zdrojové kódy a integrují změny do systému. Zákazník Rozhoduje, co se má dělat. Během plánovací hry píše karty zadání, následně upřesňuje nejasnosti, a tak se učí psát karty přesněji. V případě komplikací při vývoji rozhoduje, která část funkčnosti má menší prioritu a může být přesunuta do následující iterace a dodána až v další verzi. Zákazník s pomocí testera vytváří testy funkcionality, které slouží jako akceptační testy pro dodaný systém. Tester Většinu testování v XP zajišt ují programátoři, role testera pomáhá zákazníkovi vybírat a psát testy funkcionality. Zajišt uje správný chod všech testovacích nástrojů. Má na starosti pravidelné spouštění testů funkcionality a seznámení týmu s výsledky těchto testů. Konzultant Pomáhá týmu ve specifických problémech, na které tým občas narazí. Problémy však nikdy neřeší sám někde v ústraní, ale vždy s alespoň jedním programátorem, který se tímto od něj učí. Velký šéf Zodpovídá za vývojový proces jako celek. Zajišt uje nové lidi, když jsou potřeba. Neměl by se týmu plést do cesty, pokud nemá podezření, že se tým ubírá špatným směrem. V takovém případě je na týmu, aby svoje jednání obhájilo. Když to tým nedokáže, směřoval vývoj nejspíše špatným směrem a velký šéf splnil svou povinnost, když nenechal tým dál pokračovat, ale naopak ho přiměl k zastavení a zamyšlení Postupy XP je založeno na dvanácti postupech, které jsou stručně popsány v této kapitole, více informací lze najít v knize Extrémní programování [12]. Tyto postupy použité samostatně mohou způsobit projektu vážné problémy, ale dohromady tvoří silný celek, který urychluje vývoj software. Plánovací hra Plánovací hra slouží v XP k řízení projektu. Zákazník jejím prostřednictvím rozhoduje o šíři celkového zadání, stanovuje priority požadavků, určuje jaké funkčnosti spolu souvi- 15

24 3.1. EXTRÉMNÍ PROGRAMOVÁNÍ sejí a mají se tak objevit společně v další verzi uvolněného software, podle svých záměrů (například účast na veletrhu) upravuje datum, kdy se mají jednotlivé verze uvést do provozu. Programátoři během plánovací hry odhadují potřebný čas na vývoj jednotlivých požadavků, radí zákazníkovi při technických rozhodnutích (například volba databáze) a vytvářejí podrobný harmonogram právě začínající iterace. Malé verze Pro zákazníka je důležité, aby novou funkčnost mohl začít používat co nejdřív, proto XP dodává malé verze a v krátkých časových intervalech v řádu měsíce nebo dvou, v případě rozsáhlejšího systému maximálně po půl roce. Metafora Metafora zajišt uje komunikaci mezi vývojovým týmem a zákazníkem. Je společným příběhem, kterým popisuje zákazník provádění stávajících procesů ve své společnosti a programátoři mluví o chování vyvíjeného software. V XP metafora zastupuje význam architektury. Jednoduchý návrh Vyvíjený software má neustále nejjednodušší možnou podobu, která pokrývá aktuální požadavky zákazníka. Nic se nevyvíjí dříve, než je to potřeba, protože se může stát, že to nebude potřeba nikdy. Testování Programátoři pomocí testů jednotek ověřují svůj zdrojový kód a udržují si tak víru ve své schopnosti a důvěru k dříve vyvinuté části systému. Zákazník z výsledků testů funkcionality pozná, jaká část systému je již úspěšně vyvinutá a kolik funkčnosti ještě chybí. Refaktorizace Programátoři pomocí refaktorizace udržují zdrojové kódy, tak aby neobsahovaly duplicity, aby šlo lehce přidat novou funkčnost, aby zvýšili čitelnost zdrojového kódu, aby zlepšili návrh aplikace atd. Při této činnosti jim pomáhají hotové testy, které jim dávají jistotu, že se chování systému nezměnilo. Důležité je, aby programátoři rozlišovali, kdy refaktorují a kdy vyvíjí novou funkčnost, a nikdy tyto dvě činnosti neprováděli současně. Párové programování Při XP se zdrojový kód píše v páru, jeden programátor píše nový test, kód nebo refaktoruje, druhý mu přitom radí a hlídá, jestli výsledek činnosti prvního odpovídá celkové strategii. První programátor při své práci uvažuje jen o části systému, kterou mění či doplňuje. Důsledky pro systém jako celek musí mít na mysli druhý, v případě potřeby musí prvního opravit. Páry se mění většinou dvakrát za den. 16

25 3.1. EXTRÉMNÍ PROGRAMOVÁNÍ Společné vlastnictví Všichni členové týmu mají stejnou odpovědnost za celý vyvíjený systém, proto pokud objeví někde chybu nebo příležitost ke zlepšení, mají pravomoc (dokonce povinnost) chybu opravit nebo zlepšení realizovat sami, namísto aby upozornily odpovědnou osobu a čekali, až tato osoba bude mít čas. Nepřetržitá integrace Procesy testování a integrace se opakují v XP během velmi krátkého času, vždy alespoň jednou za den. Pro integraci je vyhrazen přímo jeden počítač, ke kterému si dvojice sednou, když dokončí implementaci svého úkolu. Na tomto vyhrazeném počítači pak provedou integraci s již vyvinutým systémem, to znamená vyřeší všechny případné kolize, provedou překlad zdrojových kódů a následně spustí testy. Pokud testy neprojdou na sto procent, musí chyby odstranit nebo svůj kód zahodit a začít znovu implementovat. 40hodinový týden Přesčasy jsou známkou problémů při vývoji software. Unavení programátoři nemůžou vyvíjet rychle a kvalitně, proto XP zakazuje přesčasy v dvou následujících týdnech. Pokud je potřeba, aby byl tým v práci dlouhodobě přesčas, je nezbytné rychle identifikovat a odstranit problém, který to způsobil. To může nakonec samozřejmě způsobit i přeplánování zbytku iterace. Zákazník na pracovišti Všechny agilní metodiky mají společný požadavek, aby byl zákazník kdykoliv k dispozici pro upřesnění nejasností v zadání a poskytnutí konzultací z oboru podnikání zákazníka. Nejvhodnější je, pokud je zákazník v jedné místnosti s týmem a je tak možná rychlá a přímá komunikace. Zákazník sice musí být k dispozici kdykoliv, těžko ho však bude tým neustále zahlcovat dotazy, a tak se může zákazník po většinu času věnovat vlastní práci. Standardy pro psaní zdrojového textu Standardy jsou nutné kvůli společnému vlastnictví kódu, všichni programátoři musí znát a dodržovat standardy, které si celý tým vzal za své, aby se snadno a rychle vyznali v kódu, který psal někdo jiný Životní cyklus Metodika XP se přizpůsobuje podmínkám projektu a potřebám týmu, životní cyklus se proto bude projekt od projektu lišit. V této části práce je popsáno, jak probíhá ideální životní cyklus. Průzkum (Exploration) 17

26 3.1. EXTRÉMNÍ PROGRAMOVÁNÍ Každý projekt začíná průzkumem. Během této fáze si programátoři zkouší navrhnout a částečně realizovat různé architektury plánovaného systému. Ze svých pokusů pak vyberou nejvhodnější architekturu. Zároveň se učí odhadovat, kolik času jim zaberou jednotlivé úkoly, porovnáním odhadovaného a skutečně potřebného času. Pokud úspěšné zvládnutí začínajícího projektu vyžaduje po programátorech znalosti nové technologie, seznamují se s touto technologií právě v této fázi. Zároveň tato fáze slouží k ověření výkonnostních limitů požadovaného systému. Ověření je prováděno pomocí vhodných prototypů. Ve stejné době se zákazník učí psát své požadavky v podobě karet zadání, aby byly srozumitelné pro programátory. V této etapě by měl sepsat požadavky na první verzi systému. Délka etapy je závislá na znalostech a zkušenostech programátorů s danými nástroji, technologiemi a oborem podnikání zákazníka, pohybuje s v rozmezí několika týdnů až měsíců, přičemž by neměla přesáhnout půl roku. Plánování Etapa plánování navazuje na etapu průzkumu. Pokud se během průzkumu zákazník i tým dostatečně připraví, pak samotná etapa plánování trvá jeden či dva dny, během nichž se vyberou karty zadání pro první verzi systému a dohodne se termín jejího uvolnění. Tento termín bývá v období následujících dvou až šesti měsíců. Pokud je tým schopen první verzi dodat dřív, je to jen dobře, ale většinou se to nestává. Naopak doba delší než šest měsíců znamená zvýšení rizika. Iterace do uvolnění první verze Iterace, které probíhají do uvolnění první verze, trvají jeden až čtyři týdny. Pro první iteraci se vybírají taková zadání, aby pokryla celý systém, tedy aby výsledkem první iterace byla kostra systému. Která zadání jdou do dalších iterací rozhoduje zákazník na základě svých priorit. Na konci každé iterace by měla být malá oslava dodání plánované funkcionality. Výsledkem poslední iterace je pak první verze software určená k nasazení do ostrého provozu. Zprovozňování Tato etapa slouží k nasazení první verze systému k zákazníkovi. Nejprve je nutné systém důkladně otestovat, případně pomocí paralelního testování nového a starého systému. Zároveň se v této době tým pokouší o vyladění výkonu, protože má už dostatek znalostí o systému a zároveň má k dispozici provozní hardware. Během této etapy většinou dochází ke zkrácení iterace ze tří týdnů na jeden. Zároveň dochází i ke zpomalení vývoje, protože veškeré změny musejí být lépe promyšleny, nebot systém je už nasazen do ostrého provozu. Nové myšlenky tykající se implementace se sepíší a odloží do následujících iterací. Nasazení systému je vhodné uzavřít menší oslavou, jde totiž o významný okamžik celého projektu. 18

27 3.1. EXTRÉMNÍ PROGRAMOVÁNÍ Údržba Po nasazení systému do ostrého provozu dochází ke zpomalení vývoje. Jedním z důvodů je, že programátoři musejí vedle implementace nových úkolů zároveň zajišt ovat servis běžící aplikace. Proto je vhodné v tento okamžik přibrat nové programátory do týmu. Jejich rychlé zaškolení je realizováno pomocí párového programování se zkušenějším kolegou. Vývoj dalších verzí začíná vždy průzkumem, v rámci něhož se můžeme pokusit o odvážnou změnu architektury nebo může zákazník přijít s novým přelomovým zadáním. Tým však musí být více opatrný, protože pracuje s ostrými daty a běžícím systémem. Zároveň se musí snažit o co nejčastější slučování nového zdrojového kódu s provozním, aby se později vyhnul velkým integračním problémům. Tým může předem odhadovat, jak jeho efektivitu sníží souběžný servis běžícího systému. Důležité je tyto odhady během údržby potvrdit nebo vyvrátit pomocí měření. Stejně tak je vhodné programátory poskytující servis postupem času prostřídat. Během servisu se mohou naučit mnoho důležitých věcí, na druhou stranu jim jejich práce nepřijde tak zábavná, jako při implementaci nových úkolů. Smrt Smrt znamená konec vývoje systému. Ten může nastat ze dvou důvodů. Méně častým důvodem je, že zákazník nemá už žádné nové zadání, které by chtěl realizovat a systém je dokonale vyladěný, tudíž vývojový tým nemá, co by víc udělal. Častěji je však ukončení vývoje způsobeno neschopností vývojového týmu přidat efektivně novou funkcionalitu. Během této etapy se sepisuje několikastránkový dokument o vyvinutém systému, který by měl týmu pomoci, kdyby se k systému po čase vrátil. Taktéž je vhodné prozkoumat příčiny, které vedly k ukončení vývoje, a vzít si z nich poučení do dalších projektů. Jednotlivé etapy životního cyklu vývoje software podle metodiky XP shrnuje obrázek 3.1 převzatý z práce Agile software development methods [11] Hodnocení Metodika XP se hodí do prostředí, ve kterém se požadavky často mění nebo přicházející až během samotného vývoje, nebot je změně otevřená, požadavky v podobě karet zadání můžou přijít kdykoliv a nejpozději v následující iteraci na ně tým i reaguje. Na druhou stranu XP potřebuje prostředí, ve kterém je cena změny víceméně konstantní, nelze ho tedy použít tam, kde cena změny s postupem času rapidně roste. V těchto případech je nejdříve nutná důkladná analýza a celý vývoj by nešel s XP skloubit. Dále v XP vidím čtyři potencionální rizika. Hrozí, že programátory refaktorizace zaujme tak, že ji budou dělat pořád a nevyvinou žádnou novou funkcionalitu. Vývoj se může dostat do slepé uličky, ze které nebude cesta ven, jen proto, že se celou dobu navrhuje pro dnešek a nemyslí se na zítřek. Dalším nedostatkem je fakt, že během plánování se dostatečně neuvažuje závislosti mezi jednotlivými úkoly. A za poslední nedostatek, částečně řešený pomocí 19

28 3.2. CRYSTAL METODIKY Obrázek 3.1: Životní cyklus podle XP párového programování, považuji skutečnost, že zdrojový kód a jeho test píše stejný člověk, tudíž hrozí, že jeho chyba bude jak v kódu, tak v testu a ve výsledku způsobí funkční test a tedy neodhalení této chyby. Metodiku XP celkově považuji za zajímavou možnost, jak vyvíjet software. Spíše než její samostatné použití bych však doporučil kombinaci s jinou metodikou, která bude robustnější a odstraní nedostatky XP. Články o společném použití XP a metodik jako RUP, SCRUM, Prince a dalších lze najít na serveru Aliance agilního vývoje software [?]. 3.2 Crystal metodiky Crystal není jméno jedné metodiky, ale slouží k označení celé rodiny metodik, které vymyslel Alistair Cockburn. Jednotlivé metodiky jsou pojmenované podle barev a navzájem se odlišují svou vhodností pro různě velké týmy a různě složité projekty. Čím tmavší barva je, tím je metodika robustnější a vhodnější pro rozsáhlejší, případně kritičtější projekty. Jednotlivé barvy jsou čirá, žlutá, oranžová, červená, hnědá, modrá a fialová. Tyto metodiky nejsou přesné kuchařky, ale obsahují řadu rad, jak je přizpůsobit vlastním potřebám. Vhodná metodika pro projekt se volí na základě hodnot tří následujících vlastností projektu. První vlastností je velikost vývojového týmu, tedy kolik lidí se účastní vývoje. Druhou vlastností je kritičnost projektu, která ohodnocuje dopad selhání systému a může nabývat čtyř hodnot. 20

29 3.2. CRYSTAL METODIKY Ztráta komfortu (C) je nejmenší dopad, kdy lze systém i nadále používat, ale uživatele to stojí zvýšené úsilí. Malá ztráta peněz (D) má větší dopad, v tomto případě firma kvůli selhání ztratí nějaké finance. Velká ztráta peněz (E) je podobný dopad, jako předchozí, tentokrát ovšem firma ztrácí nezanedbatelnou část svých financí. Ztráta lidských životů (L) je nejhorším možným dopadem. Poslední vlastností, podle které se řídí výběr správné metodiky, je priorita projektu. Tato vlastnost vyzdvihuje tu stránku projektu, která má pro nás největší význam. Můžeme se rozhodnout, zda budeme průběh projektu optimalizovat pro maximální produktivitu vývoje nebo dáme přednost například důkladnému měření postupujícího projektu. Volbu vhodné metodiky ilustruje obrázek 3.2 převzatý z práce Agile software development methods [11]. Čtverečkovaně jsou na obrázku označeny oblasti, které jsou nedosažitelné nebo pro které neexistuje příslušná Crystal metodika. Obrázek 3.2: Volba odpovídající metodiky z rodiny Crystal Robustnější metodiky jsou postupně navrhovány a ověřovány v praxi. Já se v této práci zaměřil na základní metodiku s čirou barvou (Crystal Clear), která spadá do kategorie D6, 21

30 3.2. CRYSTAL METODIKY tedy je určená pro tým čítající od dvou do osmi lidí, kdy při selhání firma ztrácí malou část financí. Má volba byla ovlivněna ostatními metodikami, nebot jsem chtěl srovnávat metodiky určené pro přibližně stejně velké týmy. Mou volbu ovlivnil také fakt, že v knihovně je k dispozici poměrně nová kniha Crystal Clear [5], ze které jsem tak mohl čerpat Principy Metodika Crystal Clear vychází ze sedmi principů, z nichž první tři jsou nutné pro fungování metodiky a další čtyři jen zvyšují pravděpodobnost úspěšnosti celého projektu, posouvají projekt dál v zóně bezpečnosti (Safety zone). Alistair Cockburn v druhé kapitole své knihy Crystal Clear [5] uvádí dále jmenované principy jako vlastnosti metodiky Crystal Clear. Pravidelné dodávky (Frequent delivery) Pro vývoj systémů je důležité pravidelné uvolňování nových verzí. Získáváme tak častou a pravidelnou zpětnou vazbu od uživatelů. Stejně tak má vedení lepší přehled o průběhu vývoje. Z pohledu tohoto principu nemá délka jedné iterace takový vliv, jako interval mezi uvolněním jednotlivých verzí systému. Pro programátory může být důležité, aby zadaní nebylo během iterace měněno a oni se tak mohli plně soustředit na řešení jednotlivých úkolů. Zdokonalování procesů (Reflective improvement) Při práci je důležité poučení se z vlastních chyb. Proto se tým jednou za čas sejde, aby prodiskutoval proces vývoje, našel jeho silné i slabé stránky a pokusil se najít způsob, jak proces v dalších iteracích vylepšit. Pravidelnost, stejně jako průběh a druh výstupu těchto zdokonalovacích schůzek, je ponechána na úvaze týmu. Metodika jen trvá na jejich konání a dává nezávazné rady. Podprahová komunikace (Osmotic communication) Jedná se o velmi důležitý princip, objevující se i v jiných metodikách, který lze bohužel snadno realizovat jen v malých týmech s vhodným návrhem pracovního místa. Spočívá ve společné práci všech vývojářů na jednom místě. Každý člen týmu je tak přítomen a podprahově vnímá každou relevantní komunikaci. Pokud má co říct, může rychle a efektivně sdílet své vědomosti. Přátelské prostředí (Personal safety) Cílem je pracovní kolegy vnímat jako přátele. Programátor se nesmí bát oznámit šéfovi problémy s vývojem některé části systému. Musí umět upozornit kolegu na chybu v jeho kódu nebo naopak být schopen požádat o pomoc s vlastním kódem. Nesouhlasné názory na návrh architektury se nesmí projevit ve vzájemných citech. Takové prostředí se kladně projeví i při zdokonalování vývojového procesu. 22

31 3.2. CRYSTAL METODIKY Pozornost (Focus) V tomto principu se skrývají dvě velké myšlenky. Vývojář musí mít na paměti, které dva úkoly z probíhající iterace má na starost. Práce na těchto úkolech má pro něj pak největší prioritu. Aby se této práci mohl plně věnovat zajišt uje druhá myšlenka. Vývojář dělá minimálně dva pracovní dny práci pro jeden projekt, pak může další dva dny dělat pro jiný projekt. Nemusí tedy často přeskakovat mezi úkoly pro různé projekty. Každý den má zaručené dvě hodiny, kdy nebude od své práce vyrušován. Dostupnost uživatelů Programátoři během vývoje si často potřebují ujasnit zadání, proto je potřeba aby kompetentní (expertní) uživatel byl dostupný v dostatečně krátkém čase. Je potřeba rozlišit konzultace s uživateli od konzultací s doménovým expertem (Bussiness expert), který je většinou přímo součástí týmu. Realizováno to je například tak, že uživatel je pravidelně jednou týdně osobně k dispozici na společné schůzce se všemi programátory a zbytek týdne konzultuje s vývojáři případné problémy telefonicky. Technické vybavení Rychlý a kvalitní vývoj systémů je potřeba podpořit patřičným technickým vybavením a osvědčenými postupy. Použití konfiguračního managementu a spouštění automatizovaných testů musí být pro tým samozřejmostí. Významnou roli také hrají krátké iterace a především častá integrace nových částí s existujícím systémem. Uvedené principy jsou společné pro všechny metodiky rodiny Crystal, s výjimkou principu Podprahová komunikace. Tento princip je v ostatních metodikách rodiny hůře realizovatelný, protože vývojový tým je už moc velký, případně rozmístěn do více kanceláří Role Crystal clear se od ostatních barev liší především tím, že se projektu účastní pouze jeden tým, který sdílí společnou kancelář. Tento tým obsahuje maximálně osm lidí, proto jeden člověk většinou zastává několik z uvedených rolí. Práci rolí tester nebo písař, naopak většinou dělá kdokoliv v týmu, kdo má zrovna čas. Sponzor (Executive Sponsor) Stejně jako metodiky DSDM má tato role na starost financování projektu, na který se dívá z dlouhodobého pohledu. V krátkodobém poměru balancuje priority jednotlivých požadavků, rozsah a cenu plánovaných verzí. 23

32 3.2. CRYSTAL METODIKY Uživatel (Expert user) Jedná se o zástupce uživatelů, kteří budou používat nebo již používají vyvíjený systém. Týmu je užitečný svými konzultacemi a testováním jak funkčních vlastností, tak použitelnosti systému. Zná četnosti jednotlivých obchodních procesů a souvisejících operací. Radí při návrhu systémových rozhraní. Hlavní vývojář (Lead designer) Člověk v této roli dělá stejnou práci jako ostatní obsazení v roli vývojář, rozdíl je však v tom, že znalosti hlavního vývojáře v oblasti návrhu architektury, programování systému a projektových procesů jsou na mnohem vyšší úrovni. Důležité nebo složité úkoly proto obstarává tato role. V malém týmu, který má Crystal Clear, se málokdy najde víc než jeden člověk schopný zastávat tuto roli. Vzhledem k důležitosti role bývá tento jediný člověk často přetěžován. Je tedy potřeba, aby maximum svých jednodušších úkolů delegoval na ostatní. Vývojář (Designer-programmer) Navrhování bez programování může produkovat těžce realizovatelné návrhy, protože osobě chybí právě zpětná vazba z programování. Proto každý člověk v roli vývojáře systém navrhuje i programuje. Doménový expert (Business expert) Na rozdíl od uživatele musí mít tato role všeobecný přehled o podnikání zákazníka. Ví jak jednotlivé procesy podnikání probíhají, jakými se řídí pravidly, jak často se mění apod. Koordinátor (Coordinator) Koordinuje práci ostatních, zaznamenává a zpřehledňuje průběh projektu pro sponzora. Musí mít dobré společenské cítění, schopnosti podporovat diskusi a urovnávat spory. Tester (Tester) Testuje vyvíjený systém a objevené chyby zaznamenává do seznamu chyb (Bug report). Písař (Writer) Má na starost tvorbu uživatelské dokumentace (User Help Text) Postupy V metodice Crystal Clear se místo o praktikách mluví o strategiích a technikách. Metodika ovšem nediktuje použití žádné strategie ani techniky, v této oblasti dává týmu úplnou svobodu. Tým tedy může zůstat u svých naučených postupů, případně může použít postupy z jiné metodiky než z rodiny Crystal. 24

33 3.2. CRYSTAL METODIKY Pro usnadnění přijmutí Crystal Clear jako nové metodiky Alistair Cockburn ve své knize [5] dává zájemcům do začátku alespoň výběr doporučených postupů. Jedná se o následujících pět strategií a sedm technik. Strategie jsou: Průzkum (Explory 360) Nejdříve se zkoumá, zda má celý projekt vůbec smysl. Jestli je realizovatelný za rozumných ekonomických podmínek. Jestli má tým dostatek zkušeností s potřebnými technologiemi. Celý průzkum trvá od několika dnů po jeden až dva týdny, jeho výsledkem je bud spuštění projektu nebo jeho zamítnutí. Při rozhodování se zjišt uje přidaná hodnota plánovaného systému pro zákazníka. Identifikují se hlavní případy užití, budoucí uživatelé systému, požadavky na systém. Vytváří se doménový model, zkouší se technologie, odhaduje se hrubý plán vývoje. Na závěr se všechny získané poznatky prodiskutují na společném workshopu. Motivující úspěch (Early victory) Dosažený úspěch lidi dobře motivuje v jejich další práci. Toho se dá využít tak, že projekt začneme realizací nejsnazších požadavků. S velkou pravděpodobností budeme úspěšní, motivuje tým do další iterace, uživatelé brzo uvidí první náčrt systému, zákazník bude spokojený, že vývojový proces funguje. Tahle strategie je pravým opakem doporučení udělat nejkomplikovanější věci jako první, abychom co nejdříve snížili riziko neúspěchu. Cockburn doporučuje nechat nejtěžší věci až jako druhý úkol. Následně dodává, že z ekonomického hlediska je nejvýhodnější nejdříve realizovat požadavky s nejvyšším přínosem pro obchod. Běžící kostra (Walking skeleton) Cílem úvodní fáze projektu je co nejdříve vytvořit fungující kostru budoucího systému. Tato kostra postrádá ze začátku téměř veškerou požadovanou funkcionalitu. Jejím úkolem je však propojit jednotlivé části systému jako například rozhraní a databázi, čímž se zvýší možnost paralelního vývoje v následujícím období. Je nutné si uvědomit, že tato kostra neslouží k ověření technologií, ale je už skutečným základem vyvíjeného systému, řádně prověřeným pomocí testů. Během následujícího období bude nejspíše zdrojový kód kostry měněn a zdokonalován, pro vývoj je však důležité mít nějakou funkční podobu co nejdříve. Inkrementální architektura (Incremental Rearchitecture) Běžící kostru je nutné zdokonalit. To lze nejlépe realizovat pomocí inkrementálních změn architektury navrhovaného systému. Zároveň s prováděnými změnami architektury jsou inkrementálně měněny funkcionalita a rozhraní systému. Rozsáhlou architekturu nelze navrhovat jinak než inkrementálně, mozek žádného návrháře nedokáže rozumně uchopit tak rozsáhlou abstrakci, i o části architektury lze efektivně 25

34 3.2. CRYSTAL METODIKY přemýšlet po dobu maximálně dvou týdnu. Informační tabule (Information Radiators) Smyslem informačních tabulí je prezentovat informace o průběhu projektu na snadno dostupných místech. Jde o informace, jejichž opakované sdělování vedení by tým zbytečně zdržovalo. Také jsou takto prezentovány informace užitečné pro samotný tým. Doporučené techniky jsou: Nastavení metodiky (Methodology shaping) Na začátku projektu se nejprve nastaví prvotní parametry metodiky. Děje se tak na společném workshopu, kde členové týmu diskutují o svých přednostech a slabinách. Hledají se postupy, které přednosti vyzvednou a maximálně eliminují rizika plynoucí ze slabin. Zdokonalující workshop (Reflection workshop) Jednou za čas, většinou po uvolnění nové verze, se tým sejde a probere své pocity z probíhajícího procesu vývoje. Tato schůzka slouží k průběžnému upravení parametrů metodiky nastavených předešlou technikou. Tým určuje postupy, které chce i nadále zachovat. Opět se identifikují problémy s vývojem a hledá se způsob jejich odstranění. Navrhují se nové postupy, které mají vyzkoušet během následující iterace. Bleskové plánování (Blitz planning) Toto plánování se používá pro horizont příštích tří měsíců. Při plánování se sejdou sponzor, zástupci budoucích uživatelů a celý vývojový tým. Jako alternativu lze použít i plánovací hru metodiky XP. Na kartičky se sepíší všechny identifikované úkoly. Tyto úkoly vývojový tým doplní o své odhady pracnosti. Pokud je k realizaci potřeba konkrétní člověk, je jeho jméno doplněno na kartičku. Plánování je realizováno přesouváním kartiček na stole podle priorit pro zákazníka, návazností jednotlivých úkolů a s přihlédnutím na zatížení případných lidí, kteří jsou na kartičce uvedení jako nutní k realizování úkolu. Věštění doby trvání (Delphi estimation) Na začátku je těžké přesně určit dobu trvání jednotlivých úkolů. Nemáme jinou možnost než použít expertní odhady. Odhadují se počet tříd, jejich náročnost, potřebné znalosti vývojářů. Konkrétní příklad uvádí Cockburn ve své knize. Denní schůzky (Daily stand-ups) Tato technika pochází z metodiky SCRUM. Každé ráno se celý tým sejde na pár minut a probere, co kdo udělal, co bude dělat a jaké má problémy. Tyto problémy jsou během schůzky pouze identifikovány, nikoliv řešeny, proto celá schůzka netrvá déle než čtvrt hodiny. Problémy se případně řeší až po schůzce v kruhu zainteresovaných lidí. 26

35 3.2. CRYSTAL METODIKY Optimalizace rozhraní (Essential interaction design) Tuto techniku Cockburn přejímá od Jeffa Pattona a ve své knize [5] ji detailně popisuje. Já na tomto místě práce jen krátce naznačím její význam a cíle. Různé skupiny budoucích uživatelů budou pracovat se systémem různým způsobem, proto mají na systém různé požadavky a různé očekávání. Asi se nám nepodaří vyhovět všem skupinám, musíme tedy identifikovat jednu nebo dvě nejdůležitější a pro uživatele těchto skupin optimalizovat rozhraní vyvíjeného systému. Miniprojekt (Process miniature) Pro člověka seznamujícího se s novou metodikou je ze začátku těžké chápat závislosti mezi jednotlivými procesy. Cockburn doporučuje uspořádat pro nováčky malý projekt trvající maximálně den, při kterém si vše vyzkouší a uvidí závislosti mezi jednotlivými procesy. Blízké programování (Side-by-side programming) Jde o lehčí verzi párového programování, které definuje metodika XP. Cockburn považuje za vhodnější, pokud programátoři pracují každý na svém úkolu na vlastním počítači. Sedí však dostatečně blízko sebe, takže vidí na monitor druhého a jsou mu k dispozici ke konzultaci. Přírůstkové grafy (Burn charts) Technika určená k jednoduché, rychlé a přehledné prezentaci pokroku při vývoji. Na viditelné místě je umístěn a pravidelně aktualizován graf, na jehož horizontální ose je čas a na vertikální měřitelná jednotka pokroku. Vhodnou jednotkou na ose pokroku je taková, která je během celého procesu vývoje známá. Nebude jí tedy počet řádků zdrojového kódu (celkový počet je znám až na konci poslední iterace), lepší je použití například počet případů užití. Při úvodním plánování se do grafu nanese k jednotlivým milníkům předpokládané procento implementovaných případů užití ze všech požadovaných a těmito body je proložena křivka. Opakovaně (například na konci každé iterace) je do grafu zaneseno skutečné procento navržených, naprogramovaných a otestovaných případů užití Životní cyklus Projekt řešený metodikou Crystal Clear je tvořen skupinou do sebe vnořených cyklů různých délek. Těmito cykly jsou vývoj, iterace, dodávka a celý projekt. Jejich vzájemné uspořádání ukazuje obrázek 3.3. Ve zbytku podkapitoly jsou postupně popsány jednotlivé etapy, k čemuž jsou hojně používány pojmy vysvětlené v předchozích částech práce Postupy a Role. Projekt začíná etapou nazvanou mapování. Během ní je nejdříve sestaven tým, důraz je kladen na vhodné obsazení rolí sponzor, hlavní vývojář a uživatel. Tým je podle potřeby doplněn o asi dva až pět vývojářů. Dále je realizována strategie průzkum nebo některá její 27

36 3.2. CRYSTAL METODIKY Obrázek 3.3: Cykly projektu řízeného metodikou Crystal Clear alternativa převzatá například z metodiky RUP. Následuje technika nastavení metodiky. Na závěr se vytvoří prvotní plán projektu. K jeho tvorbě může být použita již zmiňovaná technika bleskové plánování, nebo některá její alternativa používaná metodikou DSDM, SCRUM, nebo XP. Po etapě mapování následují časově dlouhé cykly pojmenované dodávka, skládající se z jedné nebo několika iterací, popsaných dále. Minimálně na konci etapy je nový inkrement dodán alespoň některým uživatelům, kteří otestují novou funkcionalitu a především informují tým o použitelnosti nových obrazovek. Během dodávky je alespoň jednou uskutečněn zdokonalující workshop, kdy je přezkoumán a vylepšen proces vývoje. Délka jedné iterace se může pohybovat mezi jedním týdnem a dvěma měsíci. Obě uvedené hodnoty jsou extrémní a vyžadují velkou opatrnost. Při dlouhé iteraci nesmí tým zapomenou na průběžné ukázky systému uživatelům kvůli včasné zpětné vazbě. Krátká iterace zase vyžaduje rozdělení požadavků na velmi malé úkoly realizovatelné v tak krátké době. Iterace v sobě obsahuje plánování, jednotlivé pracovní dny, integrační cykly, ukončení a oslavu. Délka integračního cyklu je závislá na schopnostech týmu. Četnost integrace může být různá, 3.3 naznačuje provádění integrace několikrát za den, stejně tak existují projekty, kde se integrace provádí jednou za den, tři dny, týden i více. Čím delší je interval mezi jednotlivými integracemi, tím větší je riziko problémů. Snadnost etapy integrace významně ovlivňuje technické vybavení, jak je již zmíněno v části Principy. Mezi uvažované cykly patří i týden a den, které mají v každém týmu specifický průběh. Pondělní přivítání po víkendu, krátké konstatování stavu a podobně. Na začátku každého dne je vhodné uspořádat krátkou denní schůzku, jak ji zavádí metodika SCRUM. 28

37 3.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD Posledním zde popsaným cyklem je vývoj, který je součástí integračního nebo denního cyklu (podle častosti integrace). V tomto cyklu se ve skutečnosti skrývá návrh, programování, testování a hledání chyb Hodnocení Celou rodinu metodik Crystal shledávám velmi zajímavou pro jejich obrovskou flexibilitu. Žádná metodika nemůže být univerzální pro každý projekt. Metodiky Crystal z tohoto konstatování přímo vycházejí, projekt začíná volbou a konfigurací vhodné metodiky z rodiny podle daných doporučení. Samotná vybraná metodika je pak spíše sadou doporučení, kterými se tým může řídit. Dokonce i u povinných úkolů má tým možnost vybrat si způsob jejich realizace, například použít alternativní postup jiné metodiky. Zmíněná flexibilita může být bohužel pro některé týmy i překážkou. Začínající vývojáři většinou uvítají berličku v podobě striktně definovaných postupů zaručeně vedoucích k úspěšnému řešení projektu. Metodiky rodiny crystal jsou orientovány více na lidi než implementaci. Dostupné jsou zatím jen metodiky pro malé a středně velké týmy a pro lehké a středně obtížné projekty. 3.3 Dynamic Systems Development Method Dynamic Systems Development Method (DSDM) je vytvářena konsorciem DSDM od roku 1984, první verze metodiky byla uvolněna až v roce Dlouho dobu lze vysvětlit faktem, že konsorcium si dalo za cíl vytvořit podpůrné prostředí pro rychlý vývoj software. Vedle doporučených postupů tak metodika obsahuje rovněž framework, nad kterým jsou aplikace vyvíjeny. Dále metodiku doplňují vývojové nástroje a šablony vytvářených dokumentů. Od prvního uvolnění konsorcium usilovně metodiku rozšiřuje a vylepšuje, v době psaní této práce je k dispozici Framework for Business Centred Development verze 4.2. Metodika DSDM je nejvíce rozšířená ve Velké Británii, je však používána i v jiných státech Evropy a Severní Ameriky. Přístup k metodice a frameworku je bohužel limitován, k jeho použití je potřeba licence. Z tohoto důvodu jsem při popisu metodiky DSDM čerpal z neauthentizované části portálu Konsorcia DSDM [7], knihy Agilní programování [3] od Václava Kadlece a dále z práce Agile software development methods [11]. DSDM vychází z myšlenky, která je společná většině agilních metodik, pevně definovat potřebný čas a náklady na vývoj software, přičemž rozsah vyvinutého systému je pak závislou proměnnou. Zdárné dokončení projektu zajišt uje použití dvou praktik časový blok a MoSCoW, které jsou detailně popsány v části Postupy. 29

38 3.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD Principy Metodika DSDM je založena na devíti principech, z nichž většina vychází z manifestu agilního vývoje [2]. Aktivní účast zákazníka Kvalifikovaní zástupci budoucích uživatelů musí být k dispozici po celou dobu vývoje systému, aby týmu zajišt ovali častou a přesnou zpětnou vazbu. Tým má pravomoc k rozhodování Čekání na potvrzení dalšího postupu od vedení neúměrně prodlužuje vývoj systému. DSDM tým má na základě komunikace s kvalifikovanými zástupci zákazníka pravomoc rozhodnout o dalším směru vývoje. Důraz na časté dodávky Nové verze systému jsou uvolňovány co nejdříve je to možné. Zrychluje se tak zpětná vazba od uživatelů systému, dříve se objeví změnové požadavky a zjistí nepochopené zadání. Vhodnost systému pro podnikání Zákazník očekává systém, který mu přinese svým používáním očekávaný užitek. Splnění tohoto očekávání je pro něj důležitější než vědomí, že systém využívá nejnovější technologie a prošel důkladným regresním testováním. Iterační vývoj a inkrementální dodávky Systém je vhodnější dodávat postupně pomocí inkrementů než celý najednou na konci vývoje. Chyby v systému jsou tak objeveny a odstraněny dříve. Iterace jsou nejvhodnější postup vývoje software. Vratné změny Během vývoje je snadné vydat se špatnou cestou, je však důležité mít možnost se z této cesty rychle dostat zpět. Veškeré prováděné změny proto musí jít lehce vrátit do původního stavu. Požadavky na vysoké úrovni Vysoká abstrakce při práci s požadavky umožňuje opožděné rozhodování, požadavky jsou postupně upřesněny až v době, kdy je jejich detailní podoba jistá nebo kdy je detailní popis nutný pro další vývoj. 30

39 3.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD Průběžné testování Testování se provádí v průběhu celého vývoje, aby se eliminovalo riziko, že ke konci už na testování nebude čas, tudíž se neprovede, nebo provede nedostatečně. Vzhledem k inkrementálnímu vývoji se provádí regresní testování, tedy opakovaně se přetestuje celý zatím vyvinutý systém, což zvyšuje pravděpodobnost odhalení zavlečených chyb. Spolupráce Dokonalá spolupráce a dostatečná komunikace je základem úspěšného vývoje systému. Důležitá je jak mezi členy týmu při společném řešení požadavků, tak mezi týmem a uživateli při rozhodování o přidaných funkcionalitách v nové verzi systému Role DSDM uvažuje dohromady patnáct různých rolí. Přehled a stručný popis nejvýznamnějších rolí následuje. Vývojář (Developer) Tato role spolu s následující jsou jediné, které mají v týmu na starost samotný vývoj systému. Jde o obecné označení pro zaměstnance, kteří mají na starost analýzu, návrh, programování nebo testování vyvíjeného systému. Senior vývojář (Senior developer) Do této role je povýšen některý ze zaměstnanců v roli vývojáře, pokud má větší zkušenosti nebo znalosti než jeho kolegové. Tento člověk jim pak dělá vedoucího. Technický koordinátor (Technical coordinator) Navrhuje architekturu vyvíjeného systému a je zodpovědný za její technickou kvalitu. Zároveň hlídá projekt po technické stránce, má na starost konfigurační management. Zástupce uživatelů (Ambassador user) V této roli je obsazen jeden z budoucích uživatelů systému. Jeho úkolem je zajišt ovat komunikaci mezi vývojovým týmem a budoucími uživateli. Týmu musí poskytnout znalosti uživatelů a tlumočit jejich požadavky. Uživatele pak musí naopak informovat o průběhu projektu a výsledcích vývoje. Rádce (Adviser user) Zastupuje předchozí roli v případech, kdy se jedná o specifické požadavky. Může se jednat například o zaměstnance zákazníka z ICT nebo finančního oddělení. 31

40 3.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD Vizionář (Vissionary) Je člověk, který přišel s myšlenkou nového systému. Jeho úkolem je zajistit, aby se všechny základní požadavky na systém identifikovaly v rané části celého projektu. V následném čase pak hlídá, že projekt směřuje správným směrem a realizuje identifikované požadavky. Výkonný ředitel (Executive sponsor) Je člověk na straně zákazníka, který má na starost financování celého projektu. Z toho vyplývá, že při rozhodování má poslední slovo. Projektový manažer (Project manager) Tradiční role, která má na starosti hladký průběh projektu. Netradiční u metodiky DSDM je, že tuto roli může zastávat i někdo ze strany zákazníka. Týmový předák (Team leader) Má na starost celý tým, kontroluje a napomáhá jejich práci a odbourává případné komunikační bariéry. Tester (Tester) Má na starost ty testy, které nemůže realizovat zákazník sám. Písař (Scribe) Účastní se všech workshopů, porad a schůzek a zodpovídá za jejich dokumentaci. Mimo jiné zapisuje i všechny nalezené požadavky. Moderátor (Facilitator) Nepovinná role, která se stará o hladký průběh workshopů, porad a schůzek. Specialisté (Specialist) V roli specialistů jsou odborníci na různé oblasti vývoje software. Může se jednat například o doménové experty, správce kvality, test architekty nebo systémové integrátory. V závislosti na velikosti projektu se účastní vývoje jeden nebo více týmů. Mezi velkým a malým projektem se z pohledu řízení téměř nerozlišuje, protože se vychází z předpokladu, že velký projekt lze rozdělit na menší nesouvisející části, které mohou řešit jednotlivé týmy nezávisle na sobě. Tým je složen ze dvou až šesti lidí. Minimum je dáno požadavkem, že v každém týmu musí být alespoň uživatel a vývojář. Maximum šesti lidí je výsledkem dlouhodobých zkušeností z používání metodiky DSDM. 32

41 3.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD Postupy Vzhledem k nutné licenci pro použití DSDM se mi podařilo získat informace bohužel jen o dvojici nepodstatnějších postupů, v terminologii DSDM nazvaných technikami. Časový blok (Timebox) Celý projekt i jednotlivé iterace mají pevně stanovené datum ukončení, které nelze za žádných okolností odložit. Délka iteračních bloků se typicky pohybuje v rozmezí dvou až šesti týdnů, podle náročnosti plánované iterace. Během bloku se postupně realizují požadavky, které jsou seřazeny podle priorit. Žádná iterace díky tomu nepřekročí plánované datum ukončení, může se však stát, že některé z méně důležitých požadavků se nestihnou realizovat. Každý blok obvykle projde postupně třemi fázemi: zkoumáním, zdokonalením a konsolidací. První ověřuje, zda projekt zdárně pokračuje ke svému cíly. Druhá zajišt uje zlepšování procesů na základě poznatků získaných během předešlého vývoje. Poslední pak slouží k dokončení všech nepřesných a nedokončených aspektů. MoSCoW Slovo MoSCoW vzniklo jako složenina čtyř písmen označující jednotlivé úrovně priorit. Jedná se postup, kterým DSDM přiřazuje jednotlivým požadavkům různé priority, podle kterých je během vývoje s požadavky nakládáno. DSDM uvažuje následující úrovně priorit. Nezbytné (Must) jsou požadavky, které musejí být nezbytně realizovány, jinak je ohrožen průběh celého projektu. Doporučené (Should) jsou požadavky, které by měli být realizovány, neohrožují však životaschopnost projektu. Možné (Could) jsou požadavky, jejichž nesplnění nezpůsobuje projektu žádné vážně problémy. Odložitelné (Won t) jsou požadavky, které lze realizovat kdykoliv později. DSDM dále uvádí další techniky, které souvisí s vývojem software. Jedná se o známé pojmy softwarového inženýrství, proto zde techniky pouze vyjmenuji bez jejich detailnějšího popisu. Uváděnými technikami jsou modelování, tvorba prototypů, testování a konfigurační management. Všechny tyto techniky nejsou obecně vhodné pro každý projekt, jejich použití záleží na konkrétním případě. 33

42 3.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD Životní cyklus Během vývoje podle metodiky DSDM projde projekt sedmi etapami uvedenými dále. První tři jsou sekvenční, další čtyři pak inkrementální a iterativní. Jednotlivé iterace mají pevnou, předem danou délku, to vyplývá z použití časových bloků, zmíněných již dříve v části Postupy. Úvod projektu (Pre-project) Jedná se o krátkou etapu předcházející samotnému vývoji sloužící k ujištění, že je projekt dobře nakonfigurován a všechny související procesy správně nastartovány. Studie proveditelnosti (Feasibility study) V této etapě se rozhoduje, jestli je systém realizovatelný pomocí DSDM. Rozhodnutí je závislé na technických možnostech a hrozících rizicích. Během této etapy vznikají dva dokumenty, jsou to Zpráva o proveditelnosti (Feasibility report) a Rámcový plán vývoje (Outline plan for development). Pokud projekt vyžaduje týmu málo známou technologii, vytváří se během této etapy prototyp, který ověří proveditelnost. Délka této první etapy smí být maximálně několik týdnů. Obchodní studie (Business study) V této etapě se zkoumají základní charakteristiky fungování firmy zákazníka a požadovaných technologií. DSDM doporučuje během této etapy uspořádat workshop, na kterém se s experty zákazníka projdou aspekty vyvíjeného systému a určí priority jednotlivých úkolů. Při této etapě se vytváří dokument Definice prostředí firmy (Business Area Definitions), ve kterém jsou identifikovány prováděné procesy a zainteresovaní lidé ve zkoumané firmě. Dalšími produkovanými dokumenty jsou Definice architektury (System Architecture Definition) a Rámcový plán pro prototyp (Outline Prototyping Plan). První uvedený dokument v sobě obsahuje prvotní návrh architektury vyvíjeného systému, tento návrh se během dalších etap může měnit. Druhý dokument navrhuje strategie pro vývoj prototypu a obsahuje informace důležité především pro konfigurační manažery. Stanovení modelu funkcí (Functional model iteration) Tato etapa je první inkrementální a iterační. Během jednotlivých iterací probíhá jak analýza tak kódování. Jedním z výstupů této etapy je Funkční model (Functional Model), tedy kód prototypu. Dále tato etapa produkuje dokumenty Priority funkcionalit (Prioritized functions), Revize funkčního modelu (Functional prototyping review documents), Nefunkční požadavky (Non-function requirements) a Analýza rizik dalšího vývoje (Risk analysis of futher development). Během etapy se průběžně testuje. Návrh a implementace (Design and build iteration) 34

43 3.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD Při této etapě se navrhuje a vytváří vyvíjený systém. Během iterací se zároveň upravuje vzhled a celý systém se sestavuje dohromady. Jako zpětná vazba slouží připomínky uživatelů, kteří během této etapy systém zkouší. Hlavním produktem etapy je otestovaný systém, který splňuje přinejmenším předem domluvenou minimální množinu kladených požadavků. Nasazení (Implementation) Během této poslední etapy se vyvinutý systém nasadí do ostrého provozu u zákazníka. Zároveň probíhá školení uživatelů nového systému. V případech, kdy je tato etapa časově náročnější, může probíhat v podobě několika iterací. Součástí etapy je dodání dvou dokumentů, Uživatelský manuál (User manual) a Zhodnocení projektu (Project Review Report). Závěr projektu (Post-project) Tato etapa následuje po nasazení systému u zákazníka. Před koncem celého projektu se ověřuje, zda systém běží efektivně a zda nasazení systému přineslo očekávaný užitek. Po skončení předposlední etapy nasazení mohou nastat čtyři možnosti, jak bude celý projekt pokračovat, všechny uvádí následující přehled: všechny požadavky na systém byly splněny a vývoj končí větší množství požadavků bylo odloženo, nebo byly některé požadavky objeveny v pozdější části vývoje, pak se celý životní cyklus opakuje od první etapy méně kritické funkčnosti byly vynechány, cyklus se opakuje od třetí etapy nebyl čas na některé technické požadavky, pak se cyklus opakuje od čtvrté etapy Celý životní cyklus vývoje software podle metodiky DSDM ještě shrnuje obrázek 3.4 převzatý z webových stránek Konsorcia DSDM [7]. Na obrázku je zároveň vidět, že zpětný přechod na předchozí etapu je možný i dříve než po dokončení nasazení Hodnocení Metodika DSDM mi připadá důsledně propracovaná a velmi dobře dokumentovaná. Je poznat, že se usilovně zdokonaluje už deset let. Licencovaný přístup k této metodice, dle mého názoru, významně omezuje její výrazné rozšíření mezi vývojářskou společnost. Méně restriktivní přístup by mohl zdokonalování metodiky urychlit, protože by se do tohoto procesu zapojilo mnohem více lidí. Za zajímavou považuji myšlenku časových bloků a navržené úrovně priorit jednotlivých požadavků. Kombinace těchto dvou postupů s velkou pravděpodobností zaručí, že verze 35

44 3.3. DYNAMIC SYSTEMS DEVELOPMENT METHOD Obrázek 3.4: Životní cyklus podle DSDM vyvíjeného systému budou dodány včas. Celkový čas trvání projektu se samozřejmě může i přesto protáhnout. Zajímavou zkušeností by byl vývoj nad frameworkem DSDM a jeho srovnání s jinými. Bohužel to kvůli licencím není možné. V opačném případě by šla posoudit jeho úroveň a odhadnout jakým způsobem urychlí a pomůže při vývoji software. Výhodné může být použití metodiky DSDM spolu s metodikou RUP, XP nebo Prince2. Této problematice se věnuje řada článků odkazovaných z portálu Aliance agilního vývoje software [1]. Zájemci o detailnější poznání této metodiky články doporučuji k přečtení. Závěrem ještě uvedu, že podle práce Agile software development methods [11] je tato metodika vhodnější pro projekty z obchodní sféry než pro inženýrské nebo vědecké projekty. 36

45 3.4. SROVNÁNÍ VYBRANÝCH METODIK 3.4 Srovnání vybraných metodik Obsahem této kapitoly je srovnání vybraných metodik. V úvodu je každá metodika představena pomocí jediného odstavce, ve zbývajících sekcích jsou postupně srovnány principy, role a postupy. Extrémní programování je metodika určená pro jeden tým (do deseti programátorů). Zaměřuje se především na psaní kódu a ostatní disciplíny vývoje ponechává stranou. Je to nejznámější a asi nejrozšířenější agilní metodika, která se pomalu usídluje i u nás. Lze se inspirovat z dobrých programátorských návyků (testovaní a refaktoring), které metodika prezentuje. Bez doplnění dalšími přístupy (třeba metodikou RUP) je samostatně ve větších firmách nepoužitelná. Částečné osvojení může však softwarové firmě přinést užitek. Crystal metodiky jsou skupinou metodik, které si dávají za cíl pokrýt všechny možné projekty, vybráním správné metodiky ze skupiny a nastavením odpovídajících parametrů. Zatím jsou však k dispozici jen metodiky pro malé a středně velké týmy a pro lehké a středně složité projekty. Celkově jsou metodiky spíš zaměřeny na lidský faktor a poradenství, detailní popis postupů ve většině případů neposkytují. Metodiky jsou velmi flexibilní, postupy a činnosti týmu pouze doporučují, případně dávají na výběr z několika alternativních možností, kde některé jsou převzaté i s ostatních agilních metodik (XP, SCRUM, DSDM). Metodika Dynamic Systems Development Method je postavená na vlastním frameworku, který umožňuje rychlý vývoj aplikací. Kromě frameworku mají vývojáři podporu i ve vývojových nastrojích a v šablonách dokumentů. Postupy jsou z části povinné, z části doporučené. Metodika nepokrývá celou oblast vývoje, je proto vhodná kombinace s jinou metodikou, která jí doplní. Příkladem takové metodiky může být RUP. Použití metodiky a frameworku je omezeno licencí. To bohužel zabraňuje masivnějšímu rozšíření Principy Nemá smysl znovu podrobně rozebírat principy jednotlivých metodik, pro připomenutí však alespoň uvedu jejich seznam. Extrémní programování Rychlá zpětná vazba Předpoklad jednoduchosti Přírůstková změna Využití změny Kvalitní práce Výuka poznatků Malá počáteční investice 37

46 3.4. SROVNÁNÍ VYBRANÝCH METODIK Hraní na výhru Konkrétní experimenty Otevřená a upřímná komunikace Práce v souladu s lidskými instinkty Přijetí odpovědnosti Místní přizpůsobení Cestování nalehko Poctivé měření Crystal metodiky Pravidelné dodávky Zdokonalování procesů Podprahová komunikace Přátelské prostředí Pozornost Dostupnost uživatelů Technické vybavení Dynamic Systems Development Method Aktivní účast zákazníka Tým má pravomoc k rozhodování Důraz na časté dodávky Vhodnost systému pro podnikání Iterační vývoj a inkrementální dodávky Vratné změny Požadavky na vysoké úrovni Průběžné testování Spolupráce 38

47 3.4. SROVNÁNÍ VYBRANÝCH METODIK Srovnání Všechny tři porovnávané metodiky vycházejí z manifestu agilního vývoje software [2], a tak se jejich principy téměř neliší. Principům, které lze najít ve všech třech metodikám, se zde nebudu věnovat, uvedu jen zbývající. Jen XP má přijetí odpovědnosti, jako jediná tak uvažuje psychologický efekt vybrání si úkolu místo jeho přidělení. Crystal metodiky zase jako jediné zajišt ují nerušený čas (pozornost), což je rozdílné od XP, kde se předpokládá, že jeden programátor druhému kdykoliv pomůže Role Stejně jako při srovnání principů nejdříve připomenu role jednotlivých metodik. Extrémní programování (XP) Kouč Stopař Programátor Zákazník Tester Konzultant Velký šéf Crystal Clear (CC) Sponzor Uživatel Hlavní vývojář Vývojář Doménový expert Koordinátor Tester Písař 39

48 3.4. SROVNÁNÍ VYBRANÝCH METODIK Dynamic Systems Development Method (DSDM) Vývojář Senior vývojář Technický koordinátor Zástupce uživatelů Rádce Vizionář Výkonný ředitel Projektový manažer Týmový předák Tester Písař Moderátor Specialisté Srovnání U všech metodik lze identifikovat tři skupiny rolí: programátorské, uživatelské a řídící. U první skupiny metodiky shodně rozlišují programátory podle zkušeností. U XP kouč své zkušenosti a znalosti pomocí párového programování rychle předává mezi ostatní, zvyšuje tak svou technickou zastupitelnost. Hlavní vývojář u CC takto jednoduše své povědomí o architektuře nepředává, v případě problémů proto bývá přetížen, protože je nezastupitelný. Je důležité, aby si v týmu vychoval alespoň jednoho náhradníka. Uživatelských rolí je nejvíce u DSDM, lze z toho tedy usuzovat, že se metodika detailně zaměřuje na různé vazby mezi týmem a zákazníkem. Otázkou je, zda to má smysl. Možným důvodem by mohla být skutečnost, že DSDM je i pro velké projekty, kdy se vývoje účastní více týmů. Za takových okolností by adresování komunikace na různé role na straně zákazníka v závislosti na řešeném problému dávalo smysl. Ve všech metodikách je role tester chápána jako specialista na proces testování, který je v této oblasti oporou ostatním členům týmu, případně zákazníkovi. Je to dáno faktem, že jedna ze společných vlastností všech agilních metodik je regresní automatizované testování, v týmech tedy nejsou lidé, kteří by na základě testovacích scénářů ručně testovali vyvíjený software. 40

49 3.4. SROVNÁNÍ VYBRANÝCH METODIK Metodiky také společně uvádějí role specializovaných odborníků, kteří vývojářům poskytují podporu v neznámých oblastech. Kromě role moderátor u DSDM neexistuje jiná role specifická pro některou metodiku. Celkově lze říci, že vybrané metodiky se z pohledu rolí liší jen v jemnosti dělení, například role obsazené lidmi od zákazníka, konkrétně zákazník, případně velký šéf v XP oproti zástupce uživatelů, rádce, vizionář, výkonný ředitel, případně projektový manažer a specialisté v DSDM Postupy Opět nejdříve uvedu seznam principů pro připomenutí. Extrémní programování (XP) Plánovací hra Malé verze Metafora Jednoduchý návrh Testování Refaktorizace Párové programování Společné vlastnictví Nepřetržitá integrace 40hodinový týden Zákazník na pracovišti Standardy pro psaní zdrojového kódu Crystal Clear (CC) Průzkum Motivující úspěch Běžící kostra Inkrementální architektura 41

50 3.4. SROVNÁNÍ VYBRANÝCH METODIK Informační tabule Nastavení metodiky Zdokonalující workshop Bleskové plánování Věštění doby trvání Denní schůzky Optimalizace rozhraní Miniprojekt Blízké programování Přírůstkové grafy Dynamic Systems Development Method (DSDM) Časový blok. MoSCoW Srovnání Postupy DSDM časový blok a MoSCoW jsou alternativní k plánovací hře v XP a bleskovému plánování v CC. Všechny slouží k plánování rozsahu verze na základě odhadovaného času a přidělené priority, každá však jiným způsobem. Nejsnáze lze pochopit a použít plánovací hru, bleskové plánování je však přehlednější. Další postupy metodiky DSDM jsem bohužel nezjistil, takže dále srovnám jen metodiky XP a CC, přičemž se zaměřím jen na rozdíly, tedy postupy které v druhé metodice nemají alternativní postup nebo postupy. Pokud není některý postup dále uveden, znamená to tedy, že k němu lze najít alternativu. U metodiky XP jsou ojedinělými postupy metafora a společné vlastnictví. Příběh k snadnějším úvahám o software se u CC nevyskytuje, ani nic podobného. Postup, kdy je zdrojový kód všech a může ho tak kdokoliv měnit není také zrovna typickým. Proti metafoře nic nenamítám, ale myslím si, že za kód by měl být někdo zodpovědný. Zároveň i chápu, že pokud chce být XP rychlé, nemůže čekat až chybu opraví někdo jiný. Optimum vidím v kompromisu, kdy kód může měnit kdokoliv, ale pověřená osoba musí změnu přijmout. U metodiky Crystal Clear lze najít také dva jedinečné postupy, jsou to optimalizace rozhraní a miniprojekt. Metodika XP se zaměřuje na kód, pro tvorbu uživatelských rozhraní žádný podpůrný postup nemá. Miniprojekt je zajímavý, protože radí jak nováčkům v týmu 42

51 3.4. SROVNÁNÍ VYBRANÝCH METODIK rychle ukázat nejdůležitější body metodiky. Částečně to lze přirovnat k párovému programování se zkušeným partnerem nebo postupnému přijímání u metodiky XP. Velká podobnost je mezi párovým programováním a blízkým programováním. 43

52 Kapitola 4 Případová studie Tato kapitola obsahuje srovnání vybraných metodik pomocí řešení případové studie. Stručné zadaní a okolnosti myšleného projektu jsou obsahem části 4.1 Výchozí podmínky. Následují ukázky řešení pomocí vybraných metodik. V poslední části 4.5 Srovnání životních cyklů je shrnutí rozdílů mezi vybranými metodikami. Kapitola se zaměřuje především na rozdíly při hledání požadavků, plánování projektu a na odlišnosti v integraci. Závěrem ještě musím zdůraznit, že jsem se nepokoušel projekt skutečně řešit, odhady pracnosti jednotlivých požadavků jsou pouze tipovány bez důkladnějšího rozboru. Je proto pravděpodobné, že jsem někde přestřelil. Tato kapitola má jen ilustrovat řešení projektu vybranými metodikami, korektní časové odhady proto zde nejsou důležité. Při reálném řešení by byly co možná nejpřesnější odhady klíčové a pověřené role by je museli expertně odhadnout. 4.1 Výchozí podmínky Jednotlivé metodiky mají za úkol vyvinout software pro podporu správy squashových kurtů. Soukromý podnikatel (dále zákazník) zakoupil existující squashové centrum, které právě opravuje. Centrum chce znovu otevřít během jednoho měsíce (22 pracovních dnů), požaduje tedy software v co nejkratším možném termínu. Od dodaného software zákazník očekává skladovou evidenci prodávaného doplňkového zboží (rakety, obuv, míčky,... ), správu časové rezervace jednotlivých herních kurtů a evidenci pravidelných návštěvníků kategorizovaných do různých skupin (profesionálové, studenti, běžní hráči,... ). Software musí poskytovat potřebné podklady pro vedení učetnictví. Produkované statistiky vytíženosti kurtů v závislosti na čase a různých skupinách hráčů pomohou zákazníkovi při volbě otevíracích hodin a cenové politiky. Svým průzkumem zákazník zjistil, že hráči mají zájem o možnost rezervace kurtů pomocí webového rozhraní. Takovou službu žádné konkurenční centrum zatím neposkytuje, proto by ji zákazník chtěl uvést na místní trh jako první hned při znovuotevření centra. Software bude realizovat šestičlenný tým zkušených vývojářů. Ve studii se předpokládá, že složení týmu je pevně dáno, protože je uvažována malá softwarová firma s jedním vývojovým týmem, a tým má s použitou metodikou již zkušenosti, což je předpoklad pro efektivní použití metodik. Ve studii se tedy neuvádí procesy budování týmu a obsazování členů do rolí. 44

53 4.2. EXTRÉMNÍ PROGRAMOVÁNÍ Podmínky zde schválně nejsou uvedeny podrobněji, nebot je tak lépe patrné, kdy, jak a jestli vůbec metodiky podrobnosti objeví. 4.2 Extrémní programování Studie ukazuje průběh projektu podle ideálního životního cyklu popsaného v Životní cyklus, začíná tedy fází Průzkum, kdy jsou od zákazníka zjištěny požadavky a je složen vývojový tým. Průzkum Požadavky jsou od zákazníka získány pomocí uživatelských příběhů (User stories), které píše zákazník a lze je chápat jako případy užití. Příklad uvádí, jak by vypadal jeden takový uživatelský příběh v případě uvažovaného squashové centra. Obsluha vybere z nabídky požadované datum, ze zobrazeného harmonogramu dne zjistí, zda je v požadovaný čas volný některý z hracích kurtů. Pokud ano, rezervuje hráči kurt na danou dobu a informuje hráče o jeho rezervaci. V opačném případě zkouší hráči navrhnout rezervaci ve volném čase, který je k požadovanému nejblíže. V případě zájmu, rezervuje kurt na novou dobu, jinak není provedena žádná rezervace. Když je rezervace prováděna pro nového hráče, je tento hráč zároveň vložen do evidence. Příklad 4.2.1: Ukázka uživatelského příběhu (rezervace kurtu) Konzultací mezi zákazníkem a celým týmem jsou uživatelské příběhy doplněny a vznikají karty zadání, jednu ukazuje obrázek 4.1. Zákazník určuje prioritu. Typ činnosti může nabývat tří hodnot: nová, opravná nebo zlepšovací. Ostatní položky jsou vyplněny až v následných etapách. Obrázek 4.1: Ukázka karty zadání 45

54 4.2. EXTRÉMNÍ PROGRAMOVÁNÍ Za normálních okolností by tato etapa trvala několik týdnů, v případě že by tým neměl zkušenosti s požadovanou technologií i několik měsíců. Dále se však předpokládá, že software lze úspěšně realizovat pomocí technologie J2EE 1, kterou tým už důkladně zná a může tak začít hned pracovat. Zákazníkovi přitom bylo vysvětleno, že je nereálné dodat vše do plánovaného otevření centra. Zákazník tedy v této fázi specifikuje pouze klíčovou funkcionalitu, kterou potřebuje nejdříve a ostatní uživatelské příběhy budou sepsány a realizovány až v dalším průběhu projektu. Celá fáze tak byla zkrácena na jeden a půl dne a zákazník zvolil jako klíčovou část software, která má na starost rezervaci hracích kurtů a správu hráčů. Projekt pokračuje fází plánování, kdy jsou vybrány karty zadaní do první iterace Plánování Plánování normálně zabere jeden až dva dny, v této studii je zkráceno na půl dne, z předchozí etapou tedy projekt zabral zatím dva dny. Na etapu zprovoňování se vedení rozhodlo vyčlenit týden před otevřením squashového centra. Na následující etapu iterací do uvolnění první verze zbývájí tedy tři týdny. Plánování je realizováno pomocí plánovací hry a iterační plánovací hry, které jsou vysvětleny v knížce Extrémní programování [12] na straně 76 až 83. Vývoj (celý tým) odhadne pracnost jednotlivých karet zadání. Vedení (zde kouč a zákazník) setřídí karty podle přidané hodnoty pro zákazníka. Vývoj setřídí karty podle rizika nepřesnosti odhadu. Vedení zvolí šíři zadání verze, tedy sadu karet zadání které budou implementovány. Podrobnější popis průběhu plánovací hry by byl nad rámec této studie, ta je omezená na konstatování, že kouč rozhodl před nasazením uskutečnit dvě iterace o délce dva a jeden týden, do kterých vybral karty zadání, které jdou napříč celým prvotním software, jehož jádro má být dodáno před otevřením centra. Do verze byly zahrnuty například karty zadání uvedené v tabulce 4.1. Karta Stručný popis Odhad (dny) Rezervace kurtů přidání, rušení a přehled rezervací kurtů 4 Evidence hráčů přidání, rušení a přehled hráčů 2 Vytvoření prvotního modelu 2 databáze a persistence dat 5 Simulace nehotového modelu potřebná k testům ostatních částí 2... Tabulka 4.1: Část karet zadání vybraných do první iterace Iterace do uvolnění první verze 1. Java 2 Platform, Enterprise Edition <http://java.sun.com> 46

55 4.2. EXTRÉMNÍ PROGRAMOVÁNÍ Iterace předcházející uvolnění první verze trvají jeden až čtyři týdny. Tým ve této studii kvůli podmínkám (brzké otevření centra) provede jen dvě iterace. Během první je vytvořena kostra systému, trvá dva týdny. Druhá slouží k doplnění systému o karty zadání s nejvyšším přínosem pro zákazníka, které lze v daném čase zvládnout. Na začátku každé iterace probíhá iterační plánovací hra sloužící k převedení vybraných karet zadání pro danou iteraci na úkolové karty pro programátora. Příklad úkolové karty je na obrázku 4.2. Každý programátor vezme část z karet zadání a rozebere tyto zadání na jednotlivé úkoly, které jsou napsány do úkolových karet. Pracnost jedné úkolové karty má být v řádu několika málo dnů (počet odhaduje tým z předchozích zkušeností), pokud tedy nějaký úkol zabere delší čas, musí být dále rozdělen na menší úkoly. Naopak nenáročné úkoly jsou sloučeny do jedné úkolové karty. Obrázek 4.2: Ukázka úkolové karty Časovým odhadem příslušné úkolové karty přebírá programátor odpovědnost za její implementaci. Při plánování iterace sečte každý programátor odhady na svých úkolových kartách a výsledný počet násobí zátěžovým faktorem (viz další odstavec). Když je některý programátor přetížen, předá část svých karet méně zatíženým kolegům (již během plánování). Pokud jsou Přetíženi všichni, je nutné se vrátit do plánovací hry a přehodnotit rozsah celé iterace. Veškeré odhady během plánovací hry i iterační plánovací hry předpokládají, že programátor bude mít jen jeden odhadovaný úkol a při jeho implementaci nebude rušen, vznikají tak odhady v tzv. ideálním čase. Zátěžový faktor je určen k přepočítání ideálního času na kalendářní, tedy skutečnou délku. I pro zkušené programátory má tento faktor minimální hodnotu dva, tedy ve skutečnosti jim úkol zabere alespoň dvakrát tolik času, než je odhadováno, protože se během vývoje musí věnovat i ostatní činnosti. Ve studii má tým zkušené programátory, takže hodnota jejich faktoru je dva, na první iteraci tedy mají pět ideálních dnů. Programátor zastávající roli kouče je většinou i stopařem, ostatní činnost ho bude více zaměstnávat, proto na první iteraci bude mít dva ideální dny. Stejně tak programátor v roli testera, který bude zákazníkovi pomáhat s psaním testů funkcionality. V týmu je šest programátorů, dva ideální dny mají dva členové, od ostatních se čeká pět ideálních dnů. V součtu tedy během první iterace (deset kalendářních dnů) plánuje šestičlenný tým implementovat úkoly v rozsahu dvaceti čtyř dnů. Během každého dne je implementace řízena testy, příklady lze najít v knize Programo- 47

Agilní metodiky vývoje software

Agilní metodiky vývoje software MASARYKOVA UNIVERZITA V BRNĚ FAKULTA INFORMATIKY ^TIS m p Agilní metodiky vývoje software DIPLOMOVÁ PRÁCE Bc. Tomáš Kotrla Brno, Podzim 2005 Prohlášení Prohlašuji, že tato diplomová práce je mým původním

Více

Agilní metodiky vývoje software

Agilní metodiky vývoje software MASARYKOVA UNIVERZITA V BRNĚ FAKULTA INFORMATIKY #ris m p Agilní metodiky vývoje software DIPLOMOVÁ PRÁCE Bc. Tomáš Kotrla Brno, Podzim 2005 Prohlášení Prohlašuji, že tato diplomová práce je mým původním

Více

TREND 07-201 POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE

TREND 07-201 POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE Tel. +420 543426329 TREND 07-201 POPIS ODPOVĚDNOSTI PRACOVNÍKA MANAŽER VÝVOJE Autor: Vít Chvál Verze dokumentu: 1.0 Datum poslední změny: 18.2.2013 Obsah: 1 Pracovník 3 2 Pracovní činnosti (Náplň práce)

Více

Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT)

Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT) Příloha č. 3. Charta projektu plné znění (pro jiné OSS než MŠMT) Charta projektu má za cíl poskytnout úplné a pevné informační základy pro schválení projektu. Následně je Charta projektu rozpracována do

Více

Řízení reálných projektů, agilní metodiky

Řízení reálných projektů, agilní metodiky Agent Technology Group Katedra kybernetiky Fakulta elektrotechnická - České vysoké učení technické Praha, 2009 Osnova Lze vyvíjet software bez metodiky? - bohužel ano menší komerční firmy (zejména vývoj

Více

X36SIN: Softwarové inženýrství. Životní cyklus a plánování

X36SIN: Softwarové inženýrství. Životní cyklus a plánování X36SIN: Softwarové inženýrství Životní cyklus a plánování 1 Kontext Minule jsme si řekli, co to je deklarace záměru, odborný článek, katalog požadavků, seznam aktérů a seznam událostí. Seznam aktérů a

Více

Agile Software Development

Agile Software Development Agile Software Development Agile Software Development Jiri Fabian www.jirifabian.net O čem to bude O metodologiích RUP Agile XP Scrum Co je softwarový vývoj Umění? Manufaktura? Modelování? Co je softwarový

Více

Ročníkový projekt. Jaroslav Žáček jaroslav.zacek@osu.cz

Ročníkový projekt. Jaroslav Žáček jaroslav.zacek@osu.cz Ročníkový projekt Jaroslav Žáček jaroslav.zacek@osu.cz Cíle předmětů Vytvoření fungující aplikace, která splňuje definované požadavky Vyzkoušet si celý životní cyklus projektu - specifikace zadání, formování

Více

Příloha č. 2. Charta projektu plné znění (pro MŠMT/ČŠI a příspěvkové organizace zřízené MŠMT)

Příloha č. 2. Charta projektu plné znění (pro MŠMT/ČŠI a příspěvkové organizace zřízené MŠMT) Příloha č. 2. Charta projektu plné znění (pro MŠMT/ČŠI a příspěvkové organizace zřízené MŠMT) Charta projektu má za cíl poskytnout úplné a pevné informační základy pro schválení projektu. Následně je Charta

Více

Návrh a management projektu. Řízení a koordinace projektu

Návrh a management projektu. Řízení a koordinace projektu Návrh a management projektu Řízení a koordinace projektu ČVUT FAKULTA BIOMEDICÍNSKÉHO INŽENÝRSTVÍ strana 1 Ing. Vladimír Jurka 2013 Program přednášky Komunikační nástroje Dokumenty řízení projektu Řízení

Více

Zuzana Šochová 30.10.2008. MFF Modelování a realizace softwarových projektů

Zuzana Šochová 30.10.2008. MFF Modelování a realizace softwarových projektů Zuzana Šochová 30.10.2008 1 Metody řízení projektů Týmová spolupráce Agilní metody Scrum proces Backlog úloh a odhady Jak plánovat Tým a zákazník 2 Executive support User involvement Experienced project

Více

End-to-end testování. 26. dubna Bořek Zelinka

End-to-end testování. 26. dubna Bořek Zelinka End-to-end testování 26. dubna 2013 Bořek Zelinka Bořek Zelinka Unicorn Systems, Test architekt Unicorn, 2004 Testování Quality Assurance ČVUT, Fakulta stavební, 2004 2 Agenda Princip end-to-end testů

Více

Agenda. Docházka Odhadování Neohlášený test Vedení projektů Historie projektů

Agenda. Docházka Odhadování Neohlášený test Vedení projektů Historie projektů Odhadování pracnosti a PM Agenda Docházka Odhadování Neohlášený test Vedení projektů Historie projektů PM, odhadování, historie Odhadování Snaha určit rozsah. Důležité pro stanovení ceny a termínu Do nabídek.

Více

Agile. nejžádanější způsob vývoje software. Tomáš Tureček. Business consultant, Lean&Agile coach Tieto tomas.t.turecek@tieto.com

Agile. nejžádanější způsob vývoje software. Tomáš Tureček. Business consultant, Lean&Agile coach Tieto tomas.t.turecek@tieto.com 2010 Tieto Corporation Agile nejžádanější způsob vývoje software Tomáš Tureček Business consultant, Lean&Agile coach Tieto tomas.t.turecek@tieto.com 2012 Tieto Corporation Tieto Aktivity ve více než 20

Více

Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W

Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Klasické metodiky softwarového inženýrství I N G M A R T I N M O L H A N E C, C S C. Y 1 3 A N W Osnova přednášky Co to je softwarové inženýrství Softwarový proces Metodika a metoda Evoluce softwarových

Více

I. JAK SI MYSLÍM, ŽE MOHU BÝT PRO TÝM PROSPĚŠNÝ:

I. JAK SI MYSLÍM, ŽE MOHU BÝT PRO TÝM PROSPĚŠNÝ: Test týmových rolí Pokyny: U každé otázky (I - VII), rozdělte 10 bodů mezi jednotlivé věty podle toho, do jaké míry vystihují vaše chování. V krajním případě můžete rozdělit těchto 10 bodů mezi všechny

Více

SOUBOR OTÁZEK PRO INTERNÍ AUDIT (Checklist)

SOUBOR OTÁZEK PRO INTERNÍ AUDIT (Checklist) SOUBOR OTÁZEK PRO INTERNÍ AUDIT (Checklist) Oblast 1. STRATEGICKÉ PLÁNOVÁNÍ Jsou identifikovány procesy v takovém rozsahu, aby byly dostačující pro zajištění systému managementu jakosti v oblasti vzdělávání?

Více

Zavádění projektového řízení ve společnosti

Zavádění projektového řízení ve společnosti Zavádění projektového řízení ve společnosti Monika Pidrmanová 26.10.2011 ZÁKLADNÍ POJMY Projekt = Jedinečný proces sestávající z řady koordinovaných a řízených činností s daty zahájení a ukončení, prováděný

Více

Plánování ve stavební firmě

Plánování ve stavební firmě Co je to podnikatelský plán? Podnikatelský plán je dokument, který popisuje podnik (ideu pro stávající nebo začínající) a způsob, jak dosáhne ziskovosti Plán by měl zahrnovat: všechny náklady a marketingový

Více

Psychodiagnostika Hogan a 360 dotazník

Psychodiagnostika Hogan a 360 dotazník Psychodiagnostika Hogan a 360 dotazník Na svých pozicích řešíte množství situací a vztahů, které jsou pro vás náročnější než jiné a pravděpodobně si kladete otázku proč. Jednou z možností, jak na tuto

Více

Blacksmith Consulting S. l.

Blacksmith Consulting S. l. Blacksmith Consulting S. l. RYCHLÉ VYTVOŘENÍ MODELU PODNIKÁNÍ JAKO NÁSTROJ TESTOVÁNÍ REALIZOVATELNOSTI NOVÝCH NÁPADŮ Mikulov, červenec 2013 Základní principy metodiky - Naučit se podnikat, organizovat

Více

Vysoká škola technická a ekonomická v Českých Budějovicích. Institute of Technology And Business In České Budějovice

Vysoká škola technická a ekonomická v Českých Budějovicích. Institute of Technology And Business In České Budějovice 8. DISPOZICE PROJEKTU, MANAŽER PROJEKTU, ČLENOVÉ PROJEKTOVÉHO TÝMU, PLÁNOVACÍ PROCES Vysoká škola technická a ekonomická v Českých Budějovicích Institute of Technology And Business In České Budějovice

Více

XINF1. Jaroslav Žáček jaroslav.zacek@osu.cz

XINF1. Jaroslav Žáček jaroslav.zacek@osu.cz XINF1 Jaroslav Žáček jaroslav.zacek@osu.cz Tutoriály 24.10. - 3h 6.11. - 2,2h 27.11. - 1,5h Tutoriály budeme věnovat nejen teorii, ale také cvičení a workshopům. Přečtěte si skripta dříve, než týden před

Více

PODNIKATELSKÝ PLÁN. Střední odborná škola a Gymnázium Staré Město. Ing. Miroslava Kořínková III/2 Inovace a zkvalitnění výuky prostřednictvím ICT

PODNIKATELSKÝ PLÁN. Střední odborná škola a Gymnázium Staré Město. Ing. Miroslava Kořínková III/2 Inovace a zkvalitnění výuky prostřednictvím ICT Název školy Číslo projektu Autor Název šablony PODNIKATELSKÝ PLÁN Střední odborná škola a Gymnázium Staré Město CZ.1.07/1.5.00/34.1007 Ing. Miroslava Kořínková III/2 Inovace a zkvalitnění výuky prostřednictvím

Více

Jednotný NIS Prezentace k zahájení projektu pro Radu kraje Vysočina. Projektový manažer - Ing. Ivan Sokolov, Ph.D.

Jednotný NIS Prezentace k zahájení projektu pro Radu kraje Vysočina. Projektový manažer - Ing. Ivan Sokolov, Ph.D. Prezentace k zahájení projektu pro Radu kraje Vysočina Projektový manažer - Ing. Ivan Sokolov, Ph.D. Obsah Úvod Cíle projektu Rozsah projektu Projektové řízení základní východiska Základní organizační

Více

ZVÝŠENÍ KVALITY ŘÍZENÍ NA MĚSTSKÉM ÚŘADU LANŠKROUN V RÁMCI OP LIDSKÉ ZDROJE A ZAMĚSTNANOST. Reg. č. CZ.1.04/4.1.01/89.00080 KOMPETENČNÍ MODEL

ZVÝŠENÍ KVALITY ŘÍZENÍ NA MĚSTSKÉM ÚŘADU LANŠKROUN V RÁMCI OP LIDSKÉ ZDROJE A ZAMĚSTNANOST. Reg. č. CZ.1.04/4.1.01/89.00080 KOMPETENČNÍ MODEL ZVÝŠENÍ KVALITY ŘÍZENÍ NA MĚSTSKÉM ÚŘADU LANŠKROUN V RÁMCI OP LIDSKÉ ZDROJE A ZAMĚSTNANOST Reg. č. CZ.1.04/4.1.01/89.00080 PRAHA, 2013 Kompetenční model je nástroj práce se zaměstnanci MěÚ Lanškroun. Slouží

Více

Podnikatelský plán. Název projektu. Logo. Jméno živnostníka / firmy

Podnikatelský plán. Název projektu. Logo. Jméno živnostníka / firmy Podnikatelský plán Název projektu Logo Jméno živnostníka / firmy (Cílem tohoto návodu je pomoci Vám k vytvoření podnikatelského plánu k Vaší myšlence do podnikání. Není potřeba odpovědět na všechny otázky,

Více

Příspěvek je věnován základním informacím o způsobu volby vhodné strategie řízení kontinuity činností v organizaci.

Příspěvek je věnován základním informacím o způsobu volby vhodné strategie řízení kontinuity činností v organizaci. Mgr. Monika Johaníková Ochrana & Bezpečnost 2013, ročník II., č. 3 (podzim), ISSN 1805-5656 Stanovení strategie řízení kontinuity činností Anotace Příspěvek je věnován základním informacím o způsobu volby

Více

Podklady pro ICT plán

Podklady pro ICT plán Podklady pro ICT plán Škola: ICT - Hodnocení: Vstupní hodnocení Indikátor Aktuální stav k 1.3.2012 Plánovaný stav k 28.2.2014 1. řízení a plánování Na vizi zapojení ICT do výuky pracuje jen omezená skupina

Více

Jedno globální řešení pro vaše Mezinárodní podnikání

Jedno globální řešení pro vaše Mezinárodní podnikání Jedno globální řešení pro vaše Mezinárodní podnikání Obsah 2 Známe váš svět, jsme jeho součástí 4 Správné řešení pro vaše mezinárodní podnikání 6 Standardní řešení s jedinečnými výhodami 8 Jedno globální

Více

Hodnotocentrické metodiky

Hodnotocentrické metodiky 2 Hodnotocentrické metodiky Vyšší management Projektový manažer Jedna metodika těžko bude tou jedinou správnou,... pro každý projekt a realizační tým existuje jiný správný způsob práce. 1 Alistair Cockburn

Více

Metodické doporučení MPSV č. 3/2009 k vytvoření individuálního plánu péče o dítě

Metodické doporučení MPSV č. 3/2009 k vytvoření individuálního plánu péče o dítě Metodické doporučení MPSV č. 3/2009 k vytvoření individuálního plánu péče o dítě VYTVOŘENÍ INDIVIDUÁLNÍHO PLÁNU PÉČE O DÍTĚ V okamžiku, kdy sociální pracovnice a přizvaní odborníci a organizace dokončili

Více

ŠVP Gymnázium Ostrava-Zábřeh. 4.8.16. Úvod do programování

ŠVP Gymnázium Ostrava-Zábřeh. 4.8.16. Úvod do programování 4.8.16. Úvod do programování Vyučovací předmět Úvod do programování je na naší škole nabízen v rámci volitelných předmětů v sextě, septimě nebo v oktávě jako jednoletý dvouhodinový kurz. V případě hlubšího

Více

Obsah. Úvod 9 Poděkování 10 Co je obsahem této knihy 10 Pro koho je tato kniha určena 11 Zpětná vazba od čtenářů 11 Errata 11

Obsah. Úvod 9 Poděkování 10 Co je obsahem této knihy 10 Pro koho je tato kniha určena 11 Zpětná vazba od čtenářů 11 Errata 11 Úvod 9 Poděkování 10 Co je obsahem této knihy 10 Pro koho je tato kniha určena 11 Zpětná vazba od čtenářů 11 Errata 11 KAPITOLA 1 Co je třeba znát aneb důležité pojmy 13 Krátce o požadavcích 13 Stakeholdeři

Více

ŘÍZENÍ PROJEKTŮ a LOGICKÝ RÁMEC

ŘÍZENÍ PROJEKTŮ a LOGICKÝ RÁMEC ŘÍZENÍ PROJEKTŮ a LOGICKÝ RÁMEC 5.listopadu 009 Kopřivnice Lektor: Ing. Roman Branberger, UNICUS s.r.o. romanbra@vol.cz PROGRAM: 0900 095 SPOLEČNÝ ÚVOD (ZAČÁTEČNÍCI/POKROČILÍ) Zahájení, program práce,

Více

CHARAKTERISTIKA PŘEDMĚTU INFORMATIKA (4 leté studium)

CHARAKTERISTIKA PŘEDMĚTU INFORMATIKA (4 leté studium) CHARAKTERISTIKA PŘEDMĚTU INFORMATIKA (4 leté studium) 1. Obsahové vymezení Hlavním cílem předmětu je umožnit všem žákům dosažení pokročilé úrovně informační gramotnosti získat dovednosti v ovládání výpočetní

Více

Představení projektu Metodika

Představení projektu Metodika Představení projektu Metodika přípravy veřejných strategií Strategické plánování a řízení v obcích metody, zkušenosti, spolupráce Tematická sekce Národní sítě Zdravých měst Praha, 10. května 2012 Obsah

Více

SWOT ANALÝZA. Příloha č. 2, Pracovní list č. 1 SWOT analýza 28.4.2014. SWOT analýza - obsah. SWOT analýza. 1. Základní informace a princip metody

SWOT ANALÝZA. Příloha č. 2, Pracovní list č. 1 SWOT analýza 28.4.2014. SWOT analýza - obsah. SWOT analýza. 1. Základní informace a princip metody SWOT ANALÝZA 1 SWOT analýza - obsah 1. Základní informace a princip metody 2. Vnější a vnitřní faktory 3. Užitečné tipy a příklady z praxe 2 SWOT analýza I. ZÁKLADNÍ INFORMACE A PRINCIP METODY 3 1 SWOT

Více

P R O J E K T O V É Ř Í Z E N Í A M A R K E T I N G 1. Akad. rok 2015/2016, LS Projektové řízení a marketing - VŽ 1

P R O J E K T O V É Ř Í Z E N Í A M A R K E T I N G 1. Akad. rok 2015/2016, LS Projektové řízení a marketing - VŽ 1 P R O J E K T O V É Ř Í Z E N Í A M A R K E T I N G 1 Akad. rok 2015/2016, LS Projektové řízení a marketing - VŽ 1 Vznik a historie projektového řízení Akad. rok 2015/2016, LS Projektové řízení a marketing

Více

Proces je definovaný soubor činností, který vyžaduje jeden nebo více druhů vstupů a tvoří výstup, který má pro zákazníka hodnotu

Proces je definovaný soubor činností, který vyžaduje jeden nebo více druhů vstupů a tvoří výstup, který má pro zákazníka hodnotu Proces je definovaný soubor činností, který vyžaduje jeden nebo více druhů vstupů a tvoří výstup, který má pro zákazníka hodnotu EPC(Event driven Process Chains) s funkcemi, událostmi, organizačními jednotkami

Více

Školení v rámci zemědělské a lesnické činnosti 2014

Školení v rámci zemědělské a lesnické činnosti 2014 Vindex JIH, s.r.o. Platnéřská 191 110 00 Praha IČO: 25173278 Název projektu: Školení v rámci zemědělské a lesnické činnosti 2014 Číslo projektu: 13/0181310b/131/000199 Financováno z Programu Rozvoje Venkova

Více

ICT plán. Škola: gyricany - Hodnocení: Vstupní hodnocení. Indikátor Aktuální stav k 22.3.2012 Plánovaný stav k 30.6.2014. 1. řízení a plánování

ICT plán. Škola: gyricany - Hodnocení: Vstupní hodnocení. Indikátor Aktuální stav k 22.3.2012 Plánovaný stav k 30.6.2014. 1. řízení a plánování ICT plán Škola: gyricany - Hodnocení: Vstupní hodnocení Indikátor Aktuální stav k 22.3.2012 Plánovaný stav k 30.6.2014 1. řízení a plánování Na vizi zapojení ICT do výuky pracuje jen omezená skupina učitelů.

Více

Business Development Rozvoj podniku

Business Development Rozvoj podniku Marketing vytváření obchodních příležitostí pomocí: udržením stávajících zákazníků přilákáním nových zákazníků Tržby vyhráním zakázky Zákaznická služba Cíle společnosti, které ovlivňují marketingové činnosti:

Více

TÝMOVÝ VÝSTUP. Týmový výstup 360 zpětné vazby. 360 zpětná vazba

TÝMOVÝ VÝSTUP. Týmový výstup 360 zpětné vazby. 360 zpětná vazba TÝMOVÝ VÝSTUP Týmový výstup 360 zpětné vazby 360 zpětná vazba ÚVOD Týmový výstup nabízí přehled výsledky napříč zvolenou skupinou. Výstup odpovídá strukturou individuálním výstupním zprávám a pracuje s

Více

CobiT. Control Objectives for Information and related Technology. Teplá u Mariánských Lázní, 6. října 2004

CobiT. Control Objectives for Information and related Technology. Teplá u Mariánských Lázní, 6. října 2004 CobiT Control Objectives for Information and related Technology Teplá u Mariánských Lázní, 6. října 2004 Agenda Základy CobiT Pojem CobiT Domény CobiT Hodnocení a metriky dle CobiT IT Governance Řízení

Více

Strategický plán udržitelného rozvoje města Sokolov

Strategický plán udržitelného rozvoje města Sokolov Strategický plán udržitelného rozvoje města Sokolov Implementační dokument MĚSTO SOKOLOV May 29, 2015 Autor: Profesionální servis s.r.o. Mgr. Bc. Jindřich Hlavatý, PhD. Mgr. Bc. Miloš Podlipný Pro účely

Více

Určeno studentům středního vzdělávání s maturitní zkouškou, předmět: Marketing a management, téma: Marketingový výzkum

Určeno studentům středního vzdělávání s maturitní zkouškou, předmět: Marketing a management, téma: Marketingový výzkum Určeno studentům středního vzdělávání s maturitní zkouškou, předmět: Marketing a management, téma: Marketingový výzkum Pracovní list vytvořila: Mgr. Radka Drobná Období vytvoření VM: duben 2012 Klíčová

Více

PSYCHOLOGICKO SOCIÁLNÍ DOVEDNOSTI

PSYCHOLOGICKO SOCIÁLNÍ DOVEDNOSTI Slezská univerzita v Opavě Obchodně podnikatelská fakulta v Karviné PSYCHOLOGICKO SOCIÁLNÍ DOVEDNOSTI Distanční studijní opora Monika Chobotová Jarmila Šebestová Karviná 2011 Projekt OP VK 2.2 (CZ.1.07/2.2.00/15.0176)

Více

Přípravné činnosti projektu. Mgr. Lenka Svrčinová Ing. Jan Ministr, Ph.D.

Přípravné činnosti projektu. Mgr. Lenka Svrčinová Ing. Jan Ministr, Ph.D. Přípravné činnosti projektu Mgr. Lenka Svrčinová Ing. Jan Ministr, Ph.D. Obsah prezentace Seznámení s problematikou Procesy a roviny před implementací projektu Obchodní rovina Implementační rovina Řešení

Více

Příloha č.3 Otázka pro hodnocení manažera

Příloha č.3 Otázka pro hodnocení manažera Příloha č.3 Otázka pro hodnocení manažera 1. Sleduje profesní a technický vývoj? 2. Připravuje a dodržuje realistický rozpočet? 3. Zaměřuje se na podstatné informace a neztrácí se v nedůležitých detailech?

Více

Význam inovací pro firmy v současném. Jan Heřman 26. říjen 2012

Význam inovací pro firmy v současném. Jan Heřman 26. říjen 2012 Význam inovací pro firmy v současném období Jan Heřman 26. říjen 2012 Uváděné údaje a informace vychází z výzkumného záměru IGA 2 Inovační management, který je realizován v letech 2012 2013. Je registrován

Více

POŘÍZENÍ A IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ

POŘÍZENÍ A IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ POŘÍZENÍ A IMPLEMENTACE INFORMAČNÍCH SYSTÉMŮ ŽIVOTNÍ CYKLUS IS Stejně jako stroje a technologické linky, které jsou pořízeny, provozovány a následně, po opotřebování vyřazeny, má i informační systém svůj

Více

Struktura Pre-auditní zprávy

Struktura Pre-auditní zprávy Příloha č. 1 k Smlouvě o Pre-auditu: Struktura Pre-auditní zprávy 1. Manažerské shrnutí Manažerské shrnutí poskytuje nejdůležitější informace vyplývající z Pre-auditní zprávy. 2. Prohlášení o účelu a cílů

Více

Rozdíly mezi normou ISO 9001:2008 a ISO 9001:2015.

Rozdíly mezi normou ISO 9001:2008 a ISO 9001:2015. Rozdíly mezi normou ISO 9001:2008 a ISO 9001:2015. 1. Struktura Nová norma obsahuje 10 hlavních ustanovení: 1. OBLAST PLATNOSTI Kdy/proč by organizace měla použít tuto normu? 2. NORMATIVNÍ DOKUMENTY Prázdný

Více

V.3. Informační a komunikační technologie

V.3. Informační a komunikační technologie 1/6 V.3. Informační a komunikační technologie V.3. II 2. stupeň V.3. II. 1 Charakteristika předmětu Obsahové, časové a organizační vymezení Předmět je zařazen v hodinové dotaci do ročníku. Žáci mohou být

Více

Dobré UX jako nejlepší marketingový nástroj mobilních aplikací. Vladimír Korbel

Dobré UX jako nejlepší marketingový nástroj mobilních aplikací. Vladimír Korbel Dobré UX jako nejlepší marketingový nástroj mobilních aplikací Vladimír Korbel Osnova Co je to User Experience (UX)? Proč je UX důležitá UX přínosy pro business Dobrý design v kontextu mobilních aplikací

Více

EFEKTIVNÍ KOMUNIKACE V ORGANIZACI

EFEKTIVNÍ KOMUNIKACE V ORGANIZACI EVROPSKÝ SOCIÁLNÍ FOND PRAHA & EU: INVESTUJEME DO VAŠÍ BUDOUCNOSTI V ORGANIZACI JAK SE EFEKTIVNĚ DOMLUVIT A ZÍSKAT INFORMACE 1. KOMUNIKAČNÍ PROCES 2 2. ORGANIZAČNÍ STRUKTURA KOMUNIKACE 4 3. FORMÁLNÍ A

Více

RUP - Disciplíny. Jaroslav Žáček jaroslav.zacek@osu.cz

RUP - Disciplíny. Jaroslav Žáček jaroslav.zacek@osu.cz RUP - Disciplíny Jaroslav Žáček jaroslav.zacek@osu.cz Disciplíny Množství disciplíny v dané iteraci Disciplíny podle RUP Šest základních: Business modeling - pro pochopení problémové domény Requirements

Více

Úvod do problematiky vývoje Vývoj informačních systémů

Úvod do problematiky vývoje Vývoj informačních systémů Úvod do problematiky vývoje informačních systémů Vývoj informačních systémů Management Klasický management - slouží k udržování a rozvíjení zavedených systémů, které jsou prostředkem pro nepřetržitou,

Více

SPECIFIKA CERTIFIKACE PODLE ČSN EN ISO 9001:2001 V ORGANIZACÍCH, KTERÉ SE ZABÝVAJÍ VÝVOJEM SOFTWARE

SPECIFIKA CERTIFIKACE PODLE ČSN EN ISO 9001:2001 V ORGANIZACÍCH, KTERÉ SE ZABÝVAJÍ VÝVOJEM SOFTWARE SPECIFIKA CERTIFIKACE PODLE ČSN EN ISO 9001:2001 V ORGANIZACÍCH, KTERÉ SE ZABÝVAJÍ VÝVOJEM SOFTWARE Václav Šebesta Ústav informatiky Akademie věd ČR, e-mail: vasek@cs.cas.cz Abstrakt Jestliže ještě před

Více

DOTAZNÍK PRO URČENÍ UČEBNÍHO STYLU

DOTAZNÍK PRO URČENÍ UČEBNÍHO STYLU DOTAZNÍK PRO URČENÍ UČEBNÍHO STYLU Projekt MOTIVALUE Jméno: Třida: Pokyny Prosím vyplňte vaše celé jméno. Vaše jméno bude vytištěno na informačním listu s výsledky. U každé ze 44 otázek vyberte a nebo

Více

RUKOVĚŤ ÚSPĚŠNÉHO ŽADATELE V RÁMCI VÝZVY 06

RUKOVĚŤ ÚSPĚŠNÉHO ŽADATELE V RÁMCI VÝZVY 06 RUKOVĚŤ ÚSPĚŠNÉHO ŽADATELE V RÁMCI VÝZVY 06 v rámci INTEGROVANÉHO OPERAČNÍHO PROGRAMU pro prioritní osu 2 Oblasti intervence 2.1 Zavádění ICT v územní veřejné správě VÝZVA ČÍSLO 06 KOMTINUÁLNÍ ROZVOJ SLUŽEB

Více

Expresní analýza PLM. jako efektivní start implementace PLM. www.technodat.cz. jindrich.vitu@technodat.cz

Expresní analýza PLM. jako efektivní start implementace PLM. www.technodat.cz. jindrich.vitu@technodat.cz jako efektivní start implementace PLM www.technodat.cz jindrich.vitu@technodat.cz 1 úvod: definice, cíl a výstup analýzy 2 etapy expresní analýzy PLM 3 sběr dat a podkladů a jejich analýza 4 dokument Expresní

Více

shine. light of change.

shine. light of change. shine. light of change. Jak rozpoznat, je-li člověk vhodný jako projektový manažer? Michael Motal Záměr Ukázat Iniciovat Jak podpořit rozhodování Jak zvážit smysluplnost investice do člověka Výměnu názorů

Více

Informační systém pro centrální správu lokální sítě a služeb ISP

Informační systém pro centrální správu lokální sítě a služeb ISP MASARYKOVA UNIVERZITA Fakulta informatiky PV098 Řízení implementace IS semestrální práce Informační systém pro centrální správu lokální sítě a služeb ISP Jiří Kratochvíla, učo 207622, semestr 6, ročník

Více

KOMPETENČNÍ MODEL NÁZEV PROJEKTU: ZVÝŠENÍ KVALITY POSKYTOVANÝCH VEŘEJNÝCH SLUŽEB MĚSTEM KRÁLÍKY A ŘÍZENÍ MĚÚ PRO KLIENTA

KOMPETENČNÍ MODEL NÁZEV PROJEKTU: ZVÝŠENÍ KVALITY POSKYTOVANÝCH VEŘEJNÝCH SLUŽEB MĚSTEM KRÁLÍKY A ŘÍZENÍ MĚÚ PRO KLIENTA Kontaktní osoba: Ing. Petr Sára, Ph.D. Mobil: +420 605 941 994 E-mail: sara@mc-triton.cz NÁZEV PROJEKTU: ZVÝŠENÍ KVALITY POSKYTOVANÝCH VEŘEJNÝCH SLUŽEB MĚSTEM KRÁLÍKY A ŘÍZENÍ MĚÚ V RÁMCI OPERAČNÍHO PROGRAMU

Více

3. Je defenzivní programování technikou skrývání implementace? Vyberte jednu z nabízených možností: Pravda Nepravda

3. Je defenzivní programování technikou skrývání implementace? Vyberte jednu z nabízených možností: Pravda Nepravda 1. Lze vždy z tzv. instanční třídy vytvořit objekt? 2. Co je nejčastější příčinou vzniku chyb? A. Specifikace B. Testování C. Návrh D. Analýza E. Kódování 3. Je defenzivní programování technikou skrývání

Více

Metoda HOS. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz

Metoda HOS. Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz Metoda HOS Doc.Ing.Miloš Koch,CSc. koch@fbm.vutbr.cz 41 1 Hodnocení vyváženosti IS/IT 3 2 1 321 Vysoká úroveň Střední úroveň Nízká úroveň 0 Hardw are Softw are Orgw are Metoda HOS 3 41 2 Úroveň IS 3 2

Více

Dotazy Odpovědi k zadávacímu řízení Komplexní rozvoj zaměstnanců společnosti ELLA-CS, s.r.o., číslo 3532

Dotazy Odpovědi k zadávacímu řízení Komplexní rozvoj zaměstnanců společnosti ELLA-CS, s.r.o., číslo 3532 Dotazy Odpovědi k zadávacímu řízení Komplexní rozvoj zaměstnanců společnosti ELLA-CS, s.r.o., číslo 3532 http://www.esfcr.cz/zakazky/komplexni-rozvoj-zamestnancu-spolecnosti-ella-cs-s-r-o Dotaz č. 1 k

Více

CA Business Service Insight

CA Business Service Insight SPECIFIKACE PRODUKTU: CA Business Service Insight CA Business Service Insight agility made possible Díky produktu CA Business Service Insight budete vědět, které služby jsou v rámci vaší společnosti využívány,

Více

Masarykova univerzita Právnická fakulta. Katedra finančního práva a národního hospodářství. Osobní management. Sebepoznání

Masarykova univerzita Právnická fakulta. Katedra finančního práva a národního hospodářství. Osobní management. Sebepoznání Masarykova univerzita Právnická fakulta Katedra finančního práva a národního hospodářství Osobní management Sebepoznání Zpracoval: Dušan Hlavatý, 348467 Datum zadání práce: 13. 4. 2011 Datum odevzdání:

Více

AGILNÍ METODIKY VÝVOJE SOFTWARE

AGILNÍ METODIKY VÝVOJE SOFTWARE AGILNÍ METODIKY VÝVOJE SOFTWARE Postupy předchozích metodik, založené na důsledné analýze a propracovaném návrhu jsou obecně nejlepší. Ale Děláte web půl roku? Konkurence mezitím spustila dva Zdánlivě

Více

Řízení podniku a prvky strategického plánování

Řízení podniku a prvky strategického plánování 6.2.2009 Řízení podniku a prvky strategického plánování Semestrální práce z předmětu KMA/MAB Vypracoval: Tomáš Pavlík Studijní č.: Obor: E-mail: A05205 GEMB - Geomatika pavlikt@students.zcu.cz 1 Úvod Podnikové

Více

CZ.1.07/1.3.49/01.0002

CZ.1.07/1.3.49/01.0002 Název projektu: Rozvoj klíčových kompetencí zástupců ředitele na školách a školských zařízeních Reg. č. projektu: Modul : Uplatnění řízení týmů a projektů v praxi Pro vyžití ve školních projektech Jde

Více

Projekt Partner ČSOB Leasing. 02/12/2013 Jaromír Mayer Domain Process Manager Head of Department

Projekt Partner ČSOB Leasing. 02/12/2013 Jaromír Mayer Domain Process Manager Head of Department Projekt Partner ČSOB Leasing 02/12/2013 Jaromír Mayer Domain Process Manager Head of Department ČSOB Leasing, a.s. představení společnosti Je dlouhodobý leader na leasingovém trhu ČR Držitel certifikátu

Více

Odstrašující příklady z IT praxe. Jan Vaněk a kolegové

Odstrašující příklady z IT praxe. Jan Vaněk a kolegové Odstrašující příklady z IT praxe Jan Vaněk a kolegové Kdo za to může: uživatel nebo ajťák? Specifika IT průmyslu IT a zvláště SW = jeden z nejsložitějších typů výrobků vůbec Počet variant, parametrů,

Více

Vstupní a výstupní hodnocení v rámci projektu EU peníze středním školám

Vstupní a výstupní hodnocení v rámci projektu EU peníze středním školám Vstupní a výstupní hodnocení v rámci projektu EU peníze středním školám Škola: Gymnázium, Krnov, p.o. Indikátor Počáteční stav k 1.5.2012 1. řízení a plánování Na vizi zapojení ICT do výuky pracuje jen

Více

Podnikatelský záměr - PZ (Osnova)

Podnikatelský záměr - PZ (Osnova) Příloha č. 5 Podnikatelský záměr - PZ (Osnova) 1 Identifikační údaje žadatele o podporu 1.1 Obchodní jméno, sídlo, IČ/DIČ 1.2 Jméno a příjmení osoby statutárního zástupce žadatele/osoby oprávněné jednat

Více

Y13ANW ÚVOD DO WEBOVÝCH METODIK. Ing. Martin Molhanec, CSc.

Y13ANW ÚVOD DO WEBOVÝCH METODIK. Ing. Martin Molhanec, CSc. Y13ANW ÚVOD DO WEBOVÝCH METODIK Ing. Martin Molhanec, CSc. Metodika softwarové inženýrství Popisuje, jakým způsobem realizovat softwarové dílo (produkt, program, informační systém, webové sídlo, službu,

Více

Přemýšlíte o investici do nového stroje? Příštích 60 sekund vám můžete ušetřit hodně peněz...

Přemýšlíte o investici do nového stroje? Příštích 60 sekund vám můžete ušetřit hodně peněz... Přemýšlíte o investici do nového stroje? Příštích 60 sekund vám můžete ušetřit hodně peněz... Správně hned od začátku Rozdíl je v chytrém způsobu práce Začít správně hned od začátku je více než dobrý nápad,

Více

19.11.2013. Projektový management. Projektový management. Další charakteristiky projektu. Projekt

19.11.2013. Projektový management. Projektový management. Další charakteristiky projektu. Projekt Projektový management Lekce: 8 Projektový management Doc. Ing. Alois Kutscherauer, CSc. Projektový management je typ managementu uplatňovaného k zabezpečení realizace jedinečných, neopakovatelných, časově

Více

Leady & MERK Integrace Microsoft Dynamics CRM s aplikacemi Leady a MERK

Leady & MERK Integrace Microsoft Dynamics CRM s aplikacemi Leady a MERK Integrace Microsoft Dynamics CRM s aplikacemi Leady a MERK Strana 1 z 12 Obsah 1. Leady... 3 a. Shrnutí... 3 b. Popis modulu... 3 c. Technické podrobnosti o modulu... 5 2. MERK... 6 a. Shrnutí... 6 b.

Více

Průzkum PRÁCE NA DÁLKU 2013 v ČR 708 respondentů, leden duben 2013

Průzkum PRÁCE NA DÁLKU 2013 v ČR 708 respondentů, leden duben 2013 Průzkum PRÁCE NA DÁLKU 2013 v ČR 708 respondentů, leden duben 2013 I přes prokazatelné přínosy neumí firmy v ČR pracovat na dálku chybí jim k tomu podmínky i dovednosti! www.pracenadalku.cz 1 ZÁKLADNÍ

Více

Vnitřní kontrolní systém a jeho audit

Vnitřní kontrolní systém a jeho audit Vnitřní kontrolní systém a jeho audit 7. SETKÁNÍ AUDITORŮ PRŮMYSLU 11. 5. 2012 Vlastimil Červený, CIA, CISA Agenda Požadavky na VŘKS dle metodik a standardů Definice VŘKS dle rámce COSO Role interního

Více

Stav používání agilních metodik v ČR

Stav používání agilních metodik v ČR Alena Buchalcevová Katedra informačních technologií Vysoká škola ekonomická v Praze buchalc@vse.cz Abstrakt: Tradiční rigorózní metodiky vývoje softwaru přestávají v prostředí neustálých změn vyhovovat

Více

PROJEKTOVÁ VÝUKA, ŘÍZENÍ PROJEKTŮ A VÝZNAM CERTIFIKACE PRO BUDOUCÍ KARIÉRNÍ RŮST

PROJEKTOVÁ VÝUKA, ŘÍZENÍ PROJEKTŮ A VÝZNAM CERTIFIKACE PRO BUDOUCÍ KARIÉRNÍ RŮST PROJEKTOVÁ VÝUKA, ŘÍZENÍ PROJEKTŮ A VÝZNAM CERTIFIKACE PRO BUDOUCÍ KARIÉRNÍ RŮST Ing. Jan Doležal Agenda 2 Projektové řízení a projektová výuka Jaké jsou požadavky praxe? Význam a možnosti certifikace

Více

Role marketingu a vliv na obchodní výsledky

Role marketingu a vliv na obchodní výsledky 2 Role marketingu a vliv na obchodní výsledky Marketing B2B firem v ČR Jaké slovo má marketing ve firmě a jak ovlivňuje skutečné obchodní výsledky firmy? Šmeralova 12, 170 00 Praha 7 Vavrečkova 5262, 760

Více

3. Očekávání a efektivnost aplikací

3. Očekávání a efektivnost aplikací VYUŽÍVANÍ INFORMAČNÍCH SYSTÉMŮ V ŘÍZENÍ FIREM Ota Formánek 1 1. Úvod Informační systémy (IS) jsou v současnosti naprosto nezbytné pro úspěšné řízení firem. Informačním ním systémem rozumíme ucelené softwarové

Více

TOGETHER WE CAN projekt interních koučů v UniCredit Bank

TOGETHER WE CAN projekt interních koučů v UniCredit Bank TOGETHER WE CAN projekt interních koučů v UniCredit Bank Firma: UniCredit Bank Czech Republic, a.s. Na Příkopě 858/20 111 21 Praha 1 www.unicreditbank.cz Kontaktní osoba: Lenka Štěpánová Learning & Development

Více

- Tvorba a implementace procesního řízení - Vytvoření procesní mapy včetně metodické příručku pro její tvorbu.

- Tvorba a implementace procesního řízení - Vytvoření procesní mapy včetně metodické příručku pro její tvorbu. Zavedení procesního řízení - Tvorba a implementace procesního řízení - Vytvoření procesní mapy včetně metodické příručku pro její tvorbu. - Tvorba procesního modelu MMB, podpora identifikace a mapování

Více

Projekt Metodika přípravy veřejných strategií. Akční plán aktivit v oblasti strategické práce na rok 2013

Projekt Metodika přípravy veřejných strategií. Akční plán aktivit v oblasti strategické práce na rok 2013 Projekt Metodika přípravy veřejných strategií Akční plán aktivit v oblasti strategické práce na rok 2013 Listopad 2012 Obsah Obsah... 2 1. Kontext vzniku akčního plánu... 3 2. Přehled aktivit... 4 3. Akční

Více

Kronika projektu OPPA

Kronika projektu OPPA Kronika projektu OPPA Základní informace o projektu Název Projektu: společnostech Casablanca Registrační číslo projektu: V rámci programu: Operační program Praha Adaptabilita Prioritní osa: 1 - Podpora

Více

Jsme firma, která už působí na trhu několik let. Za tu dobu jsme nasbírali

Jsme firma, která už působí na trhu několik let. Za tu dobu jsme nasbírali K.O.D.A. s.r.o Jsme firma, která už působí na trhu několik let. Za tu dobu jsme nasbírali dost zkušeností v našem oboru. Zabýváme se vývojem informačního systému pro výrobní podniky a dále konzultačními

Více

17.3 - Motivace - inovace - zkušenost a vzdělávání

17.3 - Motivace - inovace - zkušenost a vzdělávání EVROPSKÝ SOCIÁLNÍ FOND 17.3 - Motivace - inovace - zkušenost a vzdělávání PRAHA & EU INVESTUJEME DO VAŠÍ BUDOUCNOSTI Klíčová aktivita č. 5 - Kurz a podpora a zkvalitnění výuky 3D počítačového modelování,

Více

Úvodní přednáška. Význam a historie PIS

Úvodní přednáška. Význam a historie PIS Úvodní přednáška Význam a historie PIS Systémy na podporu rozhodování Manažerský informační systém Manažerské rozhodování Srovnávání, vyhodnocování, kontrola INFORMACE ROZHODOVÁNÍ organizace Rozhodovacích

Více

Agilní metodiky vývoje softwaru

Agilní metodiky vývoje softwaru vývoje softwaru : důraz na průběžnou komunikaci mezi vývojovým týmem a zákazníkem důraz na tvorbu kvalitního kódu a funkcí, které mají přímou obchodní hodnotu pro zákazníka týmovou spolupráci a samoorganizaci

Více

Kariéra projektového manažera začíná u nás!

Kariéra projektového manažera začíná u nás! CHECK-LIST Auditovaná fáze projektu: Auditor: Název projektu: Zpracoval: Datum: Plánování projektu Návod na vyplnění: Při vyplňování Check-listu posuzujte skutečný obsah auditované dokumentace, vhodně

Více

Vedení projektů, Odhadování, historie

Vedení projektů, Odhadování, historie Vedení projektů, Odhadování, historie Agenda Docházka Pár slov o došlých specifikacích Vedení projektů Pár slov SW projektu na MFF Odhadování Historie projektů Dotazy Project management Co je to projekt?

Více

Realizace klientsky orientovaných služeb veřejné správy

Realizace klientsky orientovaných služeb veřejné správy Realizace klientsky orientovaných služeb veřejné správy Agenda Představení společnosti Capgemini Aktuální stav implementace služeb veřejné správy Přínosy rozvoje služeb veřejné správy Trendy dalšího vývoje

Více