EXIN Agile Scrum Foundation. Vzorový Test. Vydání

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

Download "EXIN Agile Scrum Foundation. Vzorový Test. Vydání"

Transkript

1 EXIN Agile Scrum Foundation Vzorový Test Vydání

2 Copyright 2016 EXIN Všechna práva vyhrazena. Žádná část této publikace nesmí být zveřejněna, reprodukována, kopírována nebo uložena v systému pro zpracování dat. Nesní být dána do oběhu v jakékoliv formě tištěné, fotografické, na mikrofilmu nebo jakýmkoli jiným způsobem bez předchozího písemného souhlasu ze strany EXINu. Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 2

3 Obsah Úvod 4 Vzorový Test 5 Klíč s odpověďmi 15 Hodnocení 35 Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 3

4 Úvod Toto je vzorový test EXIN Agile Scrum Foundation (ASF.CZ). Tento vzorový test zahrnuje 40 otázek s více možnostmi odpovědí. Každá otázka má několik možných odpovědí, z nichž jen jedna je správná. Maximální počet bodů, které lze získat, je 40. Každá správná odpověď je za jeden bod. K úspěšnému složení zkoušky je třeba získat alespoň 26 bodů (65 %). Na tento vzorový test je 60 minut. Z těchto informací nelze odvodit žádná práva. Hodně štěstí! Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 4

5 Vzorový Test 1 / 40 Během denního Scrumu se odpovídá na tři otázky. Která otázka je jednou z těchto tří? A. Jaké překážky jsou v cestě? B. Kdo by měl provést další úkol? C. Jaké požadavky od zákazníka jste obdrželi? 2 / 40 Scrum tým zjistil, že má možné zpoždění při doručování komponenty, na kterou čeká jiný Scrum tým. Jaké je nejlepší fórum k diskuzi o tomto problému a nalezení řešení? A. Denní Scrum jednoho z týmů B. Scrum-of-Scrums C. Vyhodnocení sprintu D. Retrospektiva sprintu 3 / 40 Scrum tým považuje za dobrou praxi jasně definovat kontrolní seznam položek, které musí být hotové před tím, než je uživatelský příběh možné označit za dokončený. Jaký artefakt pro tento účel pravděpodobně použijí? A. Burn-down graf B. Definice Hotovo C. Produktový backlog D. Sprint backlog 4 / 40 Blízko konce sprintu vývojový tým zjistí, že nebude schopen dokončit všechny uživatelské příběhy, ke kterým se zavázal. Jaký je nejlepší průběh činností pro vývojový tým? A. Přidat zdroje a členy týmu za cílem splnění úkolů probíhajícího sprintu. B. Požádat vlastníka produktu o rozhodnutí, které uživatelské příběhy mohou být odloženy do dalšího sprintu. C. Rozhodnout o nové definici hotovo pro položky sprint backlogu. Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 5

6 5 / 40 Často používanou nejlepší praxí je definovat uživatelské příběhy podle zkratky INVEST. S ve slově INVEST znamená malý (anglicky Small). Pokud jde o uživatelský příběh ve sprintu, co musí být small? A. Počet sprintů potřebných k realizaci tohoto uživatelského příběhu B. Počet zapojených členů týmu C. Počet story pointů nebo ideálních hodin D. Délka sepsaného příběhu uživatele 6 / 40 Který z následujících výroků nejlépe popisuje úlohu, kterou denní Scrum hraje ve sledování postupu Scrum projektu? A. Denní Scrum pomáhá Scrum masterovi aktualizovat Burn-down graf. B. Denní Scrum dává vývojovému týmu vhled do pokroku a problémů. C. Denní Scrum umožňuje vlastníkovi produktu přezkoumat pokroky týmu. 7 / 40 S ve slově INVEST znamená malý (anglicky Small). Jaké položky v produktovém backlogu by měly být malé? A. Všechny položky produktového backlogu B. Položky v horní části produktového backlogu C. Položky v dolní části produktového backlogu D. Pouze položky ve sprint backlogu musí být malé 8 / 40 Scrum tým hodnotí uživatelské příběhy. Scrum master navrhne techniku Plánovacího pokeru. Co je účelem Plánovacího pokeru? A. Porovnat uživatelský příběh s referenčními příběhy a potom odhadnout jeho velikost B. Provést vlastní odhad, potom prodiskutovat odhady ostatních. C. Seřadit uživatelské příběhy na základě relativního potřebného úsilí. Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 6

7 9 / 40 Co vyjadřuje Agilní manifest? A. Ceníme si jednání o kontraktu více než spolupráce se zákazníkem. B. Ceníme si dodržování plánu více než reakce na změny. C. Ceníme si procesů a nástrojů více než jednotlivců a interakce. D. Ceníme si funkčního softwaru více než kompletní dokumentace. 10 / 40 Vývojový tým zjistí, že má pro daný sprint přílišný závazek. Kdo by měl být přítomný při přezkumu a úpravě práce sprintu? A. Vývojový tým, Scrum master a vlastník produktu. Je třeba se poradit se všemi zainteresovanými osobami. B. Vývojový tým a Scrum master. Je třeba se poradit s vlastníkem produktu. C. Pouze vývojový tým. Je třeba se poradit s vlastníkem produktu. 11 / 40 Jak je třeba definovat hotovo, když více Scrum týmů pracuje na jednom produktu? A. Všechny Scrum týmy musí mít stejnou definici hotovo. B. Každý Scrum tým musí definovat a používat vlastní definici hotovo. C. Scrum master definuje, kdy je položka hotova. 12 / 40 Scrum tým vybírá položku produktového backlogu (PBI) pro backlog sprintu. Co vše musí vývojový tým udělat, aby dokončil položku produktového backlogu, kterou vybírá? A. Co nejvíce je možné učinit v tomto sprintu před termínem. B. Co nejvíce je zapotřebí pro splnění definice hotovo. C. Analyzovat, navrhovat, programovat, testovat a dokumentovat položku produktového backlogu. 13 / 40 Který z následujících bodů je žádoucí charakteristikou informačních radiátorů? A. Aktuální B. Podrobné C. Poskytované na bázi je třeba vědět D. Stabilní Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 7

8 14 / 40 Jak dlouho by mělo Scrum týmu s 5 členy trvat dokončit plánovací schůzku sprintu pro 3-týdenní sprint? A. 3-6 hodin B. 3-6 dní C. Tak dlouho, jak je zapotřebí 15 / 40 Jaké by mělo být tempo vývoje podle zásad Agile? A. Rychlé B. Zvýšené C. Udržitelné 16 / 40 Proč je třeba denní Scrum pořádat vždy na stejném místě a ve stejnou dobu? A. Rezervace místnosti je zapotřebí provést předem po celou dobu trvání sprintu. B. Konstantní čas a místo jsou nejlepší pro kontinuitu v rámci Scrumu. C. Manažer projektu musí dostávat aktualizace stavu v daný čas každý den. 17 / 40 V minulých 8 sprintech dokončil Scrum tým 85 bodů práce celkem. Scrum tým byl požádán, aby začal pracovat na novém projektu, který má odhadovanou délku 64 bodů. Kolik sprintů bude zapotřebí pro dokončení tohoto projektu? A. 5 sprintů B. 7 sprintů C. 8 sprintů D. 10 sprintů 18 / 40 Tým přechází na Scrum. Mají již roli označovanou jako koordinátor projektu, který usnadňuje interakce, odstraňuje překážky v cestě a jedná jako procesní kouč týmu. Jak by tato role měla být nazývána po přechodu? A. Koordinátor projektu B. Projektový manažer C. Scrum master D. Manažer projektu Scrum Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 8

9 19 / 40 Scrum tým odhaduje uživatelský příběh technikou Plánovacího pokeru. Tým se rozhodne přidělit 5 bodů určitému příběhu, protože vývojáři odhadují 2 body a testeři odhadují 3 body. Jaký výrok ohledně tohoto scénáře platí? A. Body přiděluje Scrum master, nikoli vývojový tým. B. Body jsou přidělovány pro celý příběh, nikoli pro jednotlivé části příběhu. C. Body nejsou nikdy odhadovány, vždy jsou určovány předem. D. Vývojový tým rovněž musí požádat vlastníka produktu o odhad. 20 / 40 Zákazník vyžaduje zprávu, která sumarizuje přidané funkce a zjištěné a opravené závady ihned na konci jednoho sprintu. Kdo může nejlépe připravit tuto zprávu? A. Vlastník produktu B. Scrum master C. Vývojový tým D. Tento typ zprávy by se neměl připravovat. 21 / 40 Jaká je hlavní odpovědnost Scrum mastera, aby zajistil, že Scrum tým pracuje na maximální úrovni produktivity? A. Udržování funkcí s vysokou prioritou v horní části produktového backlogu. B. Nepovolení změn v produktovém backlogu po začátku sprintu. C. Podpora rozhodování vývojového týmu a řešení problémů. 22 / 40 Spolupráce je nejdůležitější parametr pro úspěch Scrum týmu. Jaký pojem nejlépe popisuje tento typ interakce? A. Práce distribuovaného týmu B. Sdílení informačního radiátoru C. Osmotická komunikace Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 9

10 23 / 40 Produktový backlog je seřazen od nejcennějších k nejméně cenným položkám. Existuje několik kritérií, která určují, jak cenná je určitá položka produktového backlogu. Jaká jsou tato kritéria? A. Přínosy, náklady, rizika B. Přínosy, náklady, velikost C. Doba na backlogu, náklady, rizika D. Doba na backlogu, náklady, velikost 24 / 40 Při přezkumu sloupcového Burn-down grafu pro release zjistil nově jmenovaný Scrum master, že dolní část sloupce se mezi 3. a 4. sprintem posunula nad vodorovnou osu. Co se stalo ve sprintu 3? A. Vývojový tým dokončil méně než přidělené příběhy. B. Vývojový tým dokončil více než přidělené příběhy. C. Do produktového backlogu byla přidána práce. D. Z produktového backlogu byla odstraněna práce. 25 / 40 Sprint byl právě dokončen a výsledkem byla katastrofa. Žádný z plánovaných uživatelských příběhů nebyl dokončen a přezkum (Review) byl zrušen. Vrchní vedení chce určit odpovědnost za tuto situaci. Kdo je v konečném měřítku odpovědný za úspěch nebo selhání Scrum projektu? A. Vlastník produktu B. Scrum master C. Vrchní vedení D. Vývojový tým 26 / 40 Kdo ví nejvíce o pokroku směrem k firemnímu cíli nebo releasu? A. Vlastník produktu B. Scrum master C. Vývojový tým Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 10

11 27 / 40 Pro sprint je průběh sledován na Burn-down grafu. Co ukazuje Burn-down graf? A. Množství dokončené práce B. Množství zbývající práce C. Rychlost vývojového týmu 28 / 40 Scrum tým selhal při plnění cílů sprintu. Jeden z klíčových členů vývojového týmu onemocněl a byl mimo 2 dny hned na začátku 4-týdenního sprintu. Co je nejpravděpodobnější důvod toho, proč tým nesplnil cíle sprintu? A. Vlastník produktu není schopný stanovit priority. B. Vývojový tým má nedostatečné dovednosti. C. Tým nenaplánoval sprint efektivně. D. Vývojový tým je přepracovaný. 29 / 40 Váš tým využívá Kanban nástěnku. Je dosažen limit probíhající práce (WIP) ve sloupci na Kanban nástěnce. Co se od vás očekává, když k tomu dojde? A. Přidělení práce spolupracovníkům v dalším sloupci, aby se uvolnila kapacita. B. Rozšíření limitu probíhající práce a pokračování v práci. C. Pomoc spolupracovníkům v daném sloupci překonat úzká hrdla. D. Počkat, dokud není práce přetažena do dalšího sloupce, aby se uvolnila kapacita. 30 / 40 Vlastník produktu chce, aby byl určitý uživatelský příběh dokončen ve dvou dnech. Člen vývojového týmu pracující na příběhu počítá, že to bude trvat pět dní. Scrum master má pocit, že by to mělo trvat tři dny. Odborník na danou problematiku, který pracoval na podobném příběhu v minulosti, si myslí, že je to práce maximálně na jeden den. Jaký odhad by se měl použít pro plánování? A. Vlastníka produktu B. Scrum mastera C. Odborníka na danou problematiku D. Vývojového týmu Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 11

12 31 / 40 Vedení společnosti chce provádět pravidelný audit pro ověření, že Scrum tým dodržuje postupy a zásady Scrum. Kdo má nejlepší postavení k provedení takového auditu? A. Vlastník produktu B. Scrum master C. Vývojový tým D. Testeři 32 / 40 Vlastník produktu jede na 3-týdenní dovolenou. Tým by měl uzavřít aktuální sprint a začít nový sprint na konci prvního týdne dovolené vlastníka produktu. Jaký je nejlepší způsob pokračování rituálů Scrum v této situaci? A. Každý Scrum tým by měl ideálně mít dva vlastníky produktu, aby bylo zajištěno krytí. B. Vlastník produktu by měl být požádán, aby dovolenou o týden odložil. C. Scrum master by měl převzít roli a funkci vlastníka produktu. 33 / 40 Jaká je definice rychlosti týmu? A. Sdílené porozumění, jak rychle musí být sprint dokončen. B. Optimální limit probíhající práce pro každý sprint. C. Počet story pointů, které může tým dokončit v 1 sprintu. D. Součet všech dokončených položek backlogu sprintu. 34 / 40 Scrum tým pracuje na projektu v 2-týdeních sprintech. Během plánovací schůzky patnáctého sprintu, Scrum master řekne: Z posledních 12 sprintů je vidět, že nejsme schopni doručit potenciálně expedovatelné přírůstky ve 2 týdnech. Pojďme zvýšit délku sprintu na 16 dní. Mělo by být trvání prodlouženo? A. Ano, protože Scrum master může změnit délku sprintu. B. Ano, protože minulý výkon sprintu je dobrým důvodem pro změnu. C. Ne, protože délku sprintu nelze z žádného důvodu změnit. D. Ne, protože pouze členové vývojového týmu mohou změnit délku sprintu. Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 12

13 35 / 40 Který typ kontraktu je adaptivní a tak dobře odpovídá způsobu práce Scrum? A. Typ kontraktu Časové jednotky nebo pevné jednotky B. Typ kontraktu S pevnou cenou C. Žádný typ kontraktu. 36 / 40 Podle principů Agile Manifesta, který typ týmu může přijít s nejlepšími požadavky, architekturou a návrhem? A. Se společným místem práce B. Zkušený C. Samostatně organizovaný D. Dobře vyškolený 37 / 40 Plánování v Agile se odehrává na více úrovních včetně denního plánu, plánování sprintu a strategického plánu. Jaký pojem nejlépe popisuje víceúrovňové plánování? A. Plánování po vrstvách B. Plánovací poker C. Plánovací schůzka sprintu 38 / 40 Člen týmu ze Scrum týmu má pocit, že vedoucí technický architekt z jiného týmu může mít určitý hodnotný pohled a zpětnou vazbu na produkt. Jaká je nejlepší událost, kdy požádat o tuto zpětnou vazbu. A. Denní Scrum B. Plánovací schůzka sprintu C. Retrospektiva sprintu D. Vyhodnocení sprintu Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 13

14 39 / 40 Jeden pracovník pracuje na kódu a druhý jeho práci pozoruje, kritizuje a občas si vymění role. Jaká praxe zde bude dodržována? A. Přezkum kódu B. Průběžná integrace C. Párové programování D. Vývoj řízený testováním 40 / 40 Co je Sprint? A. Brainstormingová událost extrémního programování zaměřená na generování návrhových idejí. B. Soupeření mezi dvěma vývojáři o to, kdo z nich dokončí nějakou funkci rychleji. C. Jedna iterace metodologie Scrum. D. Poslední iterace projektu Scrum, kdy týmy pracují dlouhé hodiny k dokončení projektu. Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 14

15 Klíč Odpověďmi 1 / 40 Během denního Scrumu se odpovídá na tři otázky. Která otázka je jednou z těchto tří? A. Jaké překážky jsou v cestě? B. Kdo by měl provést další úkol? C. Jaké požadavky od zákazníka jste obdrželi? A. Správně. Toto je jedna z otázek, na které je třeba odpovědět během denní schůzky Scrum společně s Čeho bylo dosaženo od poslední schůzky? a Co se udělá do další schůzky? (Literatura A: Rituály Scrumu: Denní Scrum) B. Špatně. Během denního Scrumu by měl každý člen týmu odpovědět na tyto tři otázky: 1. Čeho bylo dosaženo od poslední schůzky? 2. Co se udělá do další schůzky? 3. Jaké překážky jsou v cestě? C. Špatně. Během denního Scrumu by měl každý člen týmu odpovědět na tyto tři otázky: 1. Čeho bylo dosaženo od poslední schůzky? 2. Co se udělá do další schůzky? 3. Jaké překážky jsou v cestě? 2 / 40 Scrum tým zjistil, že má možné zpoždění při doručování komponenty, na kterou čeká jiný Scrum tým. Jaké je nejlepší fórum k diskuzi o tomto problému a nalezení řešení? A. Denní Scrum jednoho z týmů B. Scrum-of-Scrums C. Vyhodnocení sprintu D. Retrospektiva sprintu A. Špatně. Denní Scrum by měl být pouze krátkou diskuzí o problémech a pokrocích daného týmu. B. Správně. Scrum-of-Scrums je koordinační schůzka, na které je možné diskutovat závislosti a řešení problémů mezi jednotlivými týmy. C. Špatně. Vyhodnocení sprintu je zamýšleno jako předváděcí schůzka nové funkcionality. D. Špatně. Retrospektiva sprintu by se měla použít ke zlepšení procesů v předchozí iteraci. Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 15

16 3 / 40 Scrum tým považuje za dobrou praxi jasně definovat kontrolní seznam položek, které musí být hotové před tím, než je uživatelský příběh možné označit za dokončený. Jaký artefakt pro tento účel pravděpodobně použijí? A. Burn-down graf B. Definice Hotovo C. Produktový backlog D. Sprint backlog A. Špatně. Burn-down graf ukazuje, kolik práce je již dokončeno. B. Správně. Definice hotovo je dobře srozumitelná a jasně dokumentovaná definice kritérií, které musí být vytvořeny (splněny), aby bylo možné uživatelský příběh (nebo iteraci nebo projekt) označit za hotový. (Literatura A: Artefakt 4: Definice Hotovo ) C. Špatně. Produktový backlog ukazuje zbývající uživatelské příběhy, které je třeba dokončit před releasem. D. Špatně. Sprint backlog ukazuje zbývající uživatelské příběhy, které je třeba dokončit v probíhajícím sprintu. 4 / 40 Blízko konce sprintu vývojový tým zjistí, že nebude schopen dokončit všechny uživatelské příběhy, ke kterým se zavázal. Jaký je nejlepší průběh činností pro vývojový tým? A. Přidat zdroje a členy týmu za cílem splnění úkolů probíhajícího sprintu. B. Požádat vlastníka produktu o rozhodnutí, které uživatelské příběhy mohou být odloženy do dalšího sprintu. C. Rozhodnout o nové definici hotovo pro položky sprint backlogu. A. Špatně. Tento postup nepatří do rámce Scrum. Přidání dalších spolupracovníků do funkčního týmu by mohlo vést k dalšímu zpoždění. Přidání zdrojů může být možností, ale nikdy by nemělo vést k přesčasům. B. Správně. Vlastník produktu by měl rozhodnout, které položky mají největší hodnotu a měly by tedy být provedeny v tomto sprintu. (Literatura A: Role Scrum) C. Špatně. Definice hotovo je daná, aby zákazník obdržel hodnotu, kterou potřebuje. Definice hotovo se nesmí během sprintu měnit. Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 16

17 5 / 40 Často používanou nejlepší praxí je definovat uživatelské příběhy podle zkratky INVEST. S ve slově INVEST znamená malý (anglicky Small). Pokud jde o uživatelský příběh ve sprintu, co musí být small? A. Počet sprintů potřebných k realizaci tohoto uživatelského příběhu B. Počet zapojených členů týmu C. Počet story pointů nebo ideálních hodin D. Délka sepsaného příběhu uživatele A. Špatně. Příběh uživatele by měl být realizován v jednom sprintu. B. Špatně. Všichni členové týmu pracují ideálně na stejné funkci, takže počet členů týmu pracující na jednom příběhu uživatele může být až 9, což exaktně vzato není málo. C. Správně. Příběhy uživatelů v horní části produktového backlogu a tedy i příběhy ve sprintu musí být malé. Musí být malé, aby se zajistilo, že je bude možné realizovat v 1 sprintu a musí být definovány s dostatečnou přesností. (Literatura A: Část 2) D. Špatně. Ne, text musí být dostačující, ale nikoli nezbytně malý. Pokud potřebujete 250 slov na vysvětlení toho, co je zapotřebí, je to v pořádku. 6 / 40 Který z následujících výroků nejlépe popisuje úlohu, kterou denní Scrum hraje ve sledování postupu Scrum projektu? A. Denní Scrum pomáhá Scrum masterovi aktualizovat Burn-down graf. B. Denní Scrum dává vývojovému týmu vhled do pokroku a problémů. C. Denní Scrum umožňuje vlastníkovi produktu přezkoumat pokroky týmu. A. Špatně. Vývojový tým by měl (nebo může) aktualizovat Burn-down graf. Toto není hlavní cíl denního Scrumu. B. Správně. Ano, přesně k tomu denní Scrum slouží. 3 otázky je třeba klást každý den: Co bylo dokončeno od poslední schůzky? Co se udělá do další schůzky? Jaké překážky jsou v cestě? Vše ostatní je třeba diskutovat mimo denní Scrum. (Literatura A: Událost 3: Denní Scrum) C. Špatně. Vlastník produktu může naslouchat, ale vlastník produktu by neměl používat tuto schůzku k získání informací o pokrocích vývojového týmu. Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 17

18 7 / 40 S ve slově INVEST znamená malý (anglicky Small). Jaké položky v produktovém backlogu by měly být malé? A. Všechny položky produktového backlogu B. Položky v horní části produktového backlogu C. Položky v dolní části produktového backlogu D. Pouze položky ve sprint backlogu musí být malé A. Špatně. Product Backlog Items (PBI) s nejvyšší prioritou jsou v horní části a jsou nejpodrobnější, protože se musí realizovat jako první. Čím níže PBI v produktovém backlogu jsou, tím méně podrobné by měly být. Mohou se během času změnit nebo mohou být i vynechány/vymazány z produktového backlogu. B. Správně. Položky v horní části by měly být malé, protože tyto položky jsou dále rozděleny na jednotlivé úkoly a jsou definovány dostatečně přesně, aby mohly být zahrnuty (vytvořeny) v dalším sprintu. (Literatura A, kapitola 1) C. Špatně. PBI s nejvyšší prioritou jsou v horní části a jsou nejpodrobnější, protože se musí realizovat jako první. Čím níže PBI v produktovém backlogu jsou, tím méně podrobné musí být. Mohou se během času změnit nebo mohou být i vynechány/vymazány z produktového backlogu. D. Špatně. Položky sprint backlogu musí být malé, ale položky v horní části produktového backlogu také. 8 / 40 Scrum tým hodnotí uživatelské příběhy. Scrum master navrhne techniku Plánovacího pokeru. Co je účelem Plánovacího pokeru? A. Porovnat uživatelský příběh s referenčními příběhy a potom odhadnout jeho velikost. B. Provést vlastní odhad, potom prodiskutovat odhady ostatních. C. Seřadit uživatelské příběhy na základě relativního potřebného úsilí. A. Špatně. Toto je triangulace. B. Správně. Toto je Plánovací poker. (Literatura A, Odhadování) C. Špatně. To je odhadování na základě podobnosti. Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 18

19 9 / 40 Co vyjadřuje Agilní manifest? A. Ceníme si jednání o kontraktu více než spolupráce se zákazníkem. B. Ceníme si dodržování plánu více než reakce na změny. C. Ceníme si procesů a nástrojů více než jednotlivců a interakce. D. Ceníme si funkčního softwaru více než kompletní dokumentace. A. Špatně. Ceníme si spolupráce zákazníků více než jednání o kontraktu. B. Špatně. Ceníme si reakce na změny více než dodržování plánu. C. Špatně. Ceníme si jednotlivců a interakce více než procesů a nástrojů. D. Správně. Cenění si funkčního softwaru více než kompletní dokumentace je podstatou Agilního manifestu. (Literatura A: Agilní manifest) 10 / 40 Vývojový tým zjistí, že má pro daný sprint přílišný závazek. Kdo by měl být přítomný při přezkumu a úpravě práce sprintu? A. Vývojový tým, Scrum master a vlastník produktu. Je třeba se poradit se všemi zainteresovanými osobami. B. Vývojový tým a Scrum master. Je třeba se poradit s vlastníkem produktu. C. Pouze vývojový tým. Je třeba se poradit s vlastníkem produktu. A. Špatně. Scrum master a vlastník produktu nejsou zapotřebí. Zainteresované osoby je třeba udržovat stranou této diskuze. B. Špatně. Scrum master je nadbytečný. C. Správně. Vývojový tým by se sám měl rozhodnout, jak rozdělit práci. Potřebují si přerozdělit práci mezi sebou. Pokud tento proces potřebuje nějaké vedení, může tým požádat Scrum mastera, aby vedl diskuzi. Je třeba se poradit s vlastníkem produktu pro zajištění toho, že vynechané úlohy mají pro zákazníka nejnižší hodnotu. (Literatura A: Role Scrum) Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 19

20 11 / 40 Jak je třeba definovat hotovo, když více Scrum týmů pracuje na jednom produktu? A. Všechny Scrum týmy musí mít stejnou definici hotovo. B. Každý Scrum tým musí definovat a používat vlastní definici hotovo. C. Scrum master definuje, kdy je položka hotova. A. Správně. Použití stejné definice hotovo zaručuje, že jednotlivé části projektu se k sobě budou hodit a budou ve stejném stavu hotovo. (Literatura: Definice Hotovo a odstupňovaný Scrum) B. Špatně. Je důležité dodržovat stejnou definici hotovo, aby jednotlivé části projektu mohly být bez problémů spojovány. C. Špatně. Scrum master nikdy nesmí určovat, co je hotovo. To je úloha vlastníka produktu jako zástupce zákazníka. 12 / 40 Scrum tým vybírá položku produktového backlogu (PBI) pro backlog sprintu. Co vše musí vývojový tým udělat, aby dokončil položku produktového backlogu, kterou vybírá? A. Co nejvíce je možné učinit v tomto sprintu před termínem. B. Co nejvíce je zapotřebí pro splnění definice hotovo. C. Analyzovat, navrhovat, programovat, testovat a dokumentovat položku produktového backlogu. A. Špatně. Tým předem definuje, co je zapotřebí udělat a pracuje v udržitelném tempu. B. Správně. Definice hotovo řídí, co je zapotřebí udělat před dokončením položky backlogu. (Literatura A: Artefakt 4: Definice Hotovo ) C. Špatně. Kroky, které tým podnikne, nejsou součástí této diskuze. Vše závisí na tom, jaká je definice hotovo. Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 20

21 13 / 40 Který z následujících bodů je žádoucí charakteristikou informačních radiátorů? A. Aktuální B. Podrobné C. Poskytované na bázi je třeba vědět D. Stabilní A. Správně. Nejdůležitější vlastností informačních radiátorů je to, že jsou aktuální. Pokud nejsou aktuální, lidé budou muset nadále hledat jiné zdroje informací, přestože základní ideou je, aby jim informační radiátor přinášel informace. (Literatura: Artefakt 5) B. Špatně. Podrobnosti nejsou nezbytné, pokud radiátor poskytuje určité informace vysoce viditelným způsobem. Displej, který pouze ukazuje zbývající počet dní ve sprintu, není vůbec podrobný, ale může dobře fungovat jako informační radiátor. C. Špatně. Informační radiátory by měly být viditelné pro každého, kdo jde kolem. D. Špatně. Informační radiátory se musí často měnit, aby zůstaly aktuální. 14 / 40 Jak dlouho by mělo Scrum týmu s 5 členy trvat dokončit plánovací schůzku sprintu pro 3-týdenní sprint? A. 3-6 hodin B. 3-6 dní C. Tak dlouho, jak je zapotřebí A. Správně. Plánovací schůzka sprintu je schůzka v timeboxu (má časové ohraničení). Obvykle má pevnou délku 8 hodin pro 4-týdenní sprint nebo je úměrně kratší pro kratší sprinty. (Literatura A: Událost 1: Sprint) B. Špatně. Plánovací schůzka sprintu může jen těžko trvat více než 8 hodin. 3-6 dní je rozhodně příliš mnoho na pouhé plánování. Další plánování je možné provádět během sprintu. C. Špatně. Plánování je důležité, ale nemělo by trvat příliš dlouho. K dalšímu plánování může dojít během sprintu, ale plánovací schůzka sprintu je událost v timeboxu. Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 21

22 15 / 40 Jaké by mělo být tempo vývoje podle zásad Agile? A. Rychlé B. Zvýšené C. Udržitelné A. Špatně. Rychlé tempo může vést k trvalému přepracování a rychlému vyhoření týmu. B. Špatně. Přestože se na počátku může rychlost zvyšovat, není to cílem vývoje v rámci Agile. C. Správně. Klíčovou výhodou udržitelného tempa je, že se vývojáři mohou více soustředit i na tvůrčí činnost a ne jen na práci. Vede to ke šťastnějšímu pracovnímu prostředí a vyšší produktivitě. (Literatura: Postupy Agile) 16 / 40 Proč je třeba denní Scrum pořádat vždy na stejném místě a ve stejnou dobu? A. Rezervace místnosti je zapotřebí provést předem po celou dobu trvání sprintu. B. Konstantní čas a místo jsou nejlepší pro kontinuitu v rámci Scrumu. C. Manažer projektu musí dostávat aktualizace stavu v daný čas každý den. A. Špatně. Rezervace místnosti není podle Průvodce Scrum nezbytná. B. Správně. Účast vývojového týmu je povinná. Je snazší organizovat denní práci okolo konstantní události během celého sprintu. C. Špatně. Není to podle Průvodce Scrum nezbytné. Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 22

23 17 / 40 V minulých 8 sprintech dokončil Scrum tým 85 bodů práce celkem. Scrum tým byl požádán, aby začal pracovat na novém projektu, který má odhadovanou délku 64 bodů. Kolik sprintů bude zapotřebí pro dokončení tohoto projektu? A. 5 sprintů B. 7 sprintů C. 8 sprintů D. 10 sprintů A. Špatně. Na základě současné rychlosti 5 sprintů nestačí. B. Správně. Rychlost týmu je 85/8 = 10,625. Počet sprintů potřebných na dokončení projektu je 64/rychlost (64/10,625 = 6,024), což vychází těsně nad 6. 7 je proto rozumná odpověď, protože bychom nikdy neměli odhady zaokrouhlovat dolů. (Literatura: Odhadování) C. Špatně. 8 je počet minulých sprintů. Není žádný důvod předpokládat, že další projekt by měl obsahovat stejné množství sprintů. Srovnání by bylo možné použít jen v případě, že by délka sprintu a počet bodů byly stejné. D. Špatně. 10 bodů je přibližně současná rychlost v rámci sprintu. Není to počet sprintů potřebných pro nadcházející projekt. 18 / 40 Tým přechází na Scrum. Mají již roli označovanou jako koordinátor projektu, který usnadňuje interakce, odstraňuje překážky v cestě a jedná jako procesní kouč týmu. Jak by tato role měla být nazývána po přechodu? A. Koordinátor projektu B. Projektový manažer C. Scrum master D. Manažer projektu Scrum A. Špatně. Ve Scrumu není žádná role koordinátora projektu. B. Špatně. Ve Scrumu není žádná role projektového manažera. C. Správně. Práce koordinátora projektu je obdobná práci Scrum mastera. Ve Scrumu je důležité neměnit názvy jednotlivých rolí. Pomáhá to udržet Scrum v chodu. (Literatura A: Role Scrum) D. Špatně. Ve Scrumu není žádná role manažera projektu Scrum. Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 23

24 19 / 40 Scrum tým odhaduje uživatelský příběh technikou Plánovacího pokeru. Tým se rozhodne přidělit 5 bodů určitému příběhu, protože vývojáři odhadují 2 body a testeři odhadují 3 body. Jaký výrok ohledně tohoto scénáře platí? A. Body přiděluje Scrum master, nikoli vývojový tým. B. Body jsou přidělovány pro celý příběh, nikoli pro jednotlivé části příběhu. C. Body nejsou nikdy odhadovány, vždy jsou určovány předem. D. Vývojový tým rovněž musí požádat vlastníka produktu o odhad. A. Špatně. Úlohou vývojového týmu je přidělovat tyto odhady. B. Správně. Příběh by měl být odhadnut jako celek. Body pro to, co si tester myslí, že potřebuje, ani pro to, co si myslí vývojář, by neměly být přiděleny. Oba by měli odhadnout celý příběh. (Literatura: Artefakty Scrum) C. Špatně. Body se vždy odhadují. D. Špatně. Vlastník produktu by se neměl podílet na odhadech. 20 / 40 Zákazník vyžaduje zprávu, která sumarizuje přidané funkce a zjištěné a opravené závady ihned na konci jednoho sprintu. Kdo může nejlépe připravit tuto zprávu? A. Vlastník produktu B. Scrum master C. Vývojový tým D. Tento typ zprávy by se neměl připravovat. A. Špatně. Přestože je vlastník produktu hlasem zákazníka, nemá dostatečné sepětí s každodenními činnostmi, aby mohl tuto zprávu vypracovat. B. Správně. Scrum master by mě ve skutečnosti chránit vývojový tým před rušením a má tedy nejlepší pozici sepsat tuto zprávu. (Literatura A: Role Scrum) C. Špatně. Přestože bude možná zapotřebí se s vývojovým týmem poradit, neměl by být žádán o sepsání této zprávy: vývojový tým by se měl soustředit na realizaci další iterace. D. Špatně. Pokud představuje zpráva pro zákazníka hodnotu, měla by být připravena. Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 24

25 21 / 40 Jaká je hlavní odpovědnost Scrum mastera, aby zajistil, že Scrum tým pracuje na maximální úrovni produktivity? A. Udržování funkcí s vysokou prioritou v horní části produktového backlogu. B. Nepovolení změn v produktovém backlogu po začátku sprintu. C. Podpora rozhodování vývojového týmu a řešení problémů. A. Špatně. Toto je odpovědnost Vlastníka produktu. B. Špatně. Žádné změny nejsou povoleny, ale toto je odpovědnost celého týmu, nikoli jen Scrum mastera. C. Správně. Toto je práce Scrum mastera. (Literatura A: Role Scrum) 22 / 40 Spolupráce je nejdůležitější parametr pro úspěch Scrum týmu. Jaký pojem nejlépe popisuje tento typ interakce? A. Práce distribuovaného týmu B. Sdílení informačního radiátoru C. Osmotická komunikace A. Špatně. Distribuovaný tým je tým, který nepracuje společně ve stejném prostoru. B. Špatně. Informační radiátor je zařízení, které vám ukazuje relevantní, aktuální informace. C. Správně. Nechat členy týmu sdílet jednu místnost nejen usnadňuje konverzaci, ale rovněž umožňuje osmotickou komunikaci, při které mohou lidé získat užitečné informace zaslechnutím a mohou si vzájemně pomáhat, když je zapotřebí. (Literatura: Osmotická komunikace) Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 25

26 23 / 40 Produktový backlog je seřazen od nejcennějších k nejméně cenným položkám. Existuje několik kritérií, která určují, jak cenná je určitá položka produktového backlogu. Jaká jsou tato kritéria? A. Přínosy, náklady, rizika B. Přínosy, náklady, velikost C. Doba na backlogu, náklady, rizika D. Doba na backlogu, náklady, velikost A. Správně. Při řazení PBI jsou relevantní tato tři kritéria. (Literatura A, Část 2) B. Nesprávně, velikost je v týmu Agile synonymum pro náklady. C. Nesprávně, doba na backlogu není kritérium, protože se nejedná o systém FIFO nebo LIFO. D. Špatně. Náklady a velikost jsou synonyma a čas na backlogu není relevantní, protože produktový backlog nemá žádná FIFO nebo LIFO. 24 / 40 Při přezkumu sloupcového Burn-down grafu pro release zjistil nově jmenovaný Scrum master, že dolní část sloupce se mezi 3. a 4. sprintem posunula nad vodorovnou osu. Co se stalo ve sprintu 3? A. Vývojový tým dokončil méně než přidělené příběhy. B. Vývojový tým dokončil více než přidělené příběhy. C. Do produktového backlogu byla přidána práce. D. Z produktového backlogu byla odstraněna práce. A. Špatně. Dolní část sloupců je určena tím, kolik práce je nadále zapotřebí provést v tomto releasu, nikoli tím, kolik práce bylo uděláno v tomto sprintu. B. Špatně. Dolní část sloupců je určena tím, kolik práce je nadále zapotřebí provést v tomto releasu, nikoli tím, kolik práce bylo uděláno v tomto sprintu. C. Špatně. Práce přidaná do grafu by sloupec posunula pod nulovou osou, nikoli nad ní. Když linka provedené práce dosáhne nulovou osu, nadále zbývá práce, kterou je třeba udělat: tedy práce, která byla přidána. D. Správně. Ve sloupcovém Burn-down grafu release je práce odstraněná z backlogu produktu indikována posunem dolní části sloupce nahoru. Ukazuje to, že nová nulová osa je na stejné úrovni jako sloupec. Když je tento bod dosažen, není zapotřebí provést více práce, dokonce i když na grafu dosud není 0. (Literatura: Artefakt 5: Sledování pokroků směrem k cíli) Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 26

27 25 / 40 Sprint byl právě dokončen a výsledkem byla katastrofa. Žádný z plánovaných uživatelských příběhů nebyl dokončen a přezkum (Review) byl zrušen. Vrchní vedení chce určit odpovědnost za tuto situaci. Kdo je v konečném měřítku odpovědný za úspěch nebo selhání Scrum projektu? A. Vlastník produktu B. Scrum master C. Vrchní vedení D. Vývojový tým A. Špatně. Přestože by vlastník produktu měl vznést obavy dříve, neodpovídá za celý projekt. B. Špatně. Scrum master odpovídá za to, že tým dodržuje procesy Scrum, nikoli za celý projekt. C. Špatně. Vrchní vedení nehraje v projektu Scrum žádnou roli a nemůže být tedy odpovědné. D. Správně. Vývojový tým je společně odpovědný za úspěch nebo selhání Scrum projektu. (Literatura A: Role 3: Vývojový tým) 26 / 40 Kdo ví nejvíce o pokroku směrem k firemnímu cíli nebo releasu? A. Vlastník produktu B. Scrum master C. Vývojový tým A. Správně. Toto je úloha vlastníka produktu, protože je zástupcem zákazníka. (Literatura A: Role Scrum) B. Špatně. Scrum master ví nejvíce o zaškolování týmu a odstraňování překážek. C. Špatně. Vývojový tým musí pracovat na dokončování položek a nikoli se zdržovat rovněž jejich řazením a sledováním pokroku směrem k firemním cílům. Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 27

28 27 / 40 Pro sprint je průběh sledován na Burn-down grafu. Co ukazuje Burn-down graf? A. Množství dokončené práce B. Množství zbývající práce C. Rychlost vývojového týmu A. Špatně. To je Burn-up graf. B. Správně. Burn-down graf ukazuje množství zbývající práce: je to graf klesající. (Literatura A: Artefakt 5: Sledování pokroků směrem k cíli) C. Špatně. Rychlost můžete odvodit z předchozích Burn-down grafů, ale rychlost přímo nezobrazují. 28 / 40 Scrum tým selhal při plnění cílů sprintu. Jeden z klíčových členů vývojového týmu onemocněl a byl mimo 2 dny hned na začátku 4-týdenního sprintu. Co je nejpravděpodobnější důvod toho, proč tým nesplnil cíle sprintu? A. Vlastník produktu není schopný stanovit priority. B. Vývojový tým má nedostatečné dovednosti. C. Tým nenaplánoval sprint efektivně. D. Vývojový tým je přepracovaný. A. Špatně. Vlastník produktu nerozhoduje, kolik se má učinit ve sprintu, přestože může rozhodnout, co udělat jako první. B. Špatně. Vývojový tým může postrádat dovednosti, ale je třeba naplánovat naučení těchto dovedností v rámci odhadu. C. Správně. Vývojový tým pravděpodobně neodhadl položky backlogu dobře a nenaplánoval práci dobře. Dvoudenní absence by neměla způsobit nesplnění cílů sprintu, zejména pokud k ní došlo na začátku sprintu. (Literatura A: Artefakty Scrum) D. Špatně. Přestože může být tým přepracovaný, je toto spíš dopad špatného plánování, než příčina nesplnění cílů sprintu. Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 28

29 29 / 40 Váš tým využívá Kanban nástěnku. Je dosažen limit probíhající práce (WIP) ve sloupci na Kanban nástěnce. Co se od vás očekává, když k tomu dojde? A. Přidělení práce spolupracovníkům v dalším sloupci, aby se uvolnila kapacita. B. Rozšíření limitu probíhající práce a pokračování v práci. C. Pomoc spolupracovníkům v daném sloupci překonat úzká hrdla. D. Počkat, dokud není práce přetažena do dalšího sloupce, aby se uvolnila kapacita. A. Špatně. To není dovoleno. Kanban dovoluje práci pouze přetahovat, nikoli tlačit dopředu. Tým by měl začít pomáhat spolupracovníkům. B. Špatně. To není dovoleno. Limit WIP by se neměl náhodně změnit, ani změnit, když je limit WIP dosažen. Přesně k tomu limit WIP NESLOUŽÍ. Úzká hrdla jsou ihned řešena, nikoli ignorována. C. Správně. Když je proveden nějaký krok, nemohou lidé přesunout dokončenou práci do dalšího sloupce a uvolnit kapacitu pro novou práci; místo toho by měli čekat na další sloupec a práci převzít. D. Špatně. Když je dosažen limit WIP, není to signál k odpočinku, spíše je to signál úzkého hrdla. Úzké hrdlo by mělo být vyřešeno. Tým musí pomoci spolupracovníkům, což je důvod, proč byl dosažen limit WIP. 30 / 40 Vlastník produktu chce, aby byl určitý uživatelský příběh dokončen ve dvou dnech. Člen vývojového týmu pracující na příběhu počítá, že to bude trvat pět dní. Scrum master má pocit, že by to mělo trvat tři dny. Odborník na danou problematiku, který pracoval na podobném příběhu v minulosti, si myslí, že je to práce maximálně na jeden den. Jaký odhad by se měl použít pro plánování? A. Vlastníka produktu B. Scrum mastera C. Odborníka na danou problematiku D. Vývojového týmu A. Špatně. Vlastník produktu určuje, co je třeba odhadnout, nemá však kontrolu nad samotným odhadem. B. Špatně. Scrum master vede proces odhadování, ale nemá kontrolu nad konečným odhadem. C. Špatně. V metodě Scrum nejsou odborníci na danou problematiku. D. Správně. Jediný odhad, na kterém záleží, je odhad členů týmu pracujících na příběhu. (Literatura A: Událost 2: Plánovací schůzka sprintu) Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 29

30 31 / 40 Vedení společnosti chce provádět pravidelný audit pro ověření, že Scrum tým dodržuje postupy a zásady Scrum. Kdo má nejlepší postavení k provedení takového auditu? A. Vlastník produktu B. Scrum master C. Vývojový tým D. Testeři A. Špatně. Nejedná se o úlohu vlastníka produktu. B. Správně. Jednou z odpovědností Scrum mastera je zaškolovat tým a zajišťovat, že tým dodržuje procesy Scrum. To umožňuje Scrum masterovi provést tento audit. (Literatura A: Role 2: Scrum master) C. Špatně. Nejedná se o úlohu vývojového týmu. D. Špatně. Tester není role ve Scrumu. 32 / 40 Vlastník produktu jede na 3-týdenní dovolenou. Tým by měl uzavřít aktuální sprint a začít nový sprint na konci prvního týdne dovolené vlastníka produktu. Jaký je nejlepší způsob pokračování rituálů Scrum v této situaci? A. Každý Scrum tým by měl ideálně mít dva vlastníky produktu, aby bylo zajištěno krytí. B. Vlastník produktu by měl být požádán, aby dovolenou o týden odložil. C. Scrum master by měl převzít roli a funkci vlastníka produktu. A. Špatně. Scrum tým nepotřebuje dva Vlastníky produktu. B. Špatně. Vlastník produktu by neměl být žádán o odložení dovolené. C. Správně. V dobře naplánovaném sprintu může Scrum master krátkodobě převzít roli vlastníka produktu. Pokud jsou položky backlogu produktu dobře seřazeny, mělo by být zjevné, co je třeba učinit příště. Pokud je nezbytné, může Scrum master převzít tuto úlohu. (Literatura A: Role Scrum) Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 30

31 33 / 40 Jaká je definice rychlosti týmu? A. Sdílené porozumění, jak rychle musí být sprint dokončen. B. Optimální limit probíhající práce pro každý sprint. C. Počet story pointů, které může tým dokončit v 1 sprintu. D. Součet všech dokončených položek backlogu sprintu. A. Špatně. Rychlost specificky ukazuje počet story pointů nebo ideálních hodin či ideálních dní, který tým může dosáhnout. Délka sprintu je určena jinými věcmi. B. Špatně. Optimální limit probíhající práce je pro Kanban nástěnku, nikoli pro sprint. C. Správně. Rychlost je počet jednotek práce dokončených za určitý interval. (Literatura A: Artefakt 2: Sprint backlog) D. Špatně. Nelze vědět, jak moc by to mělo být započteno. Pokud znáte počet story pointů, můžete je použít k odhadu rychlosti, ale rozhodně existuje lepší odpověď. 34 / 40 Scrum tým pracuje na projektu v 2-týdeních sprintech. Během plánovací schůzky patnáctého sprintu, Scrum master řekne: Z posledních 12 sprintů je vidět, že nejsme schopni doručit potenciálně expedovatelné přírůstky ve 2 týdnech. Pojďme zvýšit délku sprintu na 16 dní. Mělo by být trvání prodlouženo? A. Ano, protože Scrum master může změnit délku sprintu. B. Ano, protože minulý výkon sprintu je dobrým důvodem pro změnu. C. Ne, protože délku sprintu nelze z žádného důvodu změnit. D. Ne, protože pouze členové vývojového týmu mohou změnit délku sprintu. A. Špatně. Délka by měla být prodloužena, ale nikoli protože si Scrum master myslí, že je to dobrý nápad. B. Správně. Scrum master poskytuje validní argument na základě slušného množství dřívější práce, že je délku sprintu třeba změnit. (Literatura A: Události Scrum) C. Špatně. Délka sprintu se ideálně nemění, ale opakování strategie, která nefunguje, nedává smysl. Pokud existují platné důvody pro změnu délky sprintu, neváhejte a změňte ji. D. Špatně. Žádný člen týmu nemůže navrhnout tuto změnu. Celý Scrum tým musí probrat, zda je důvod dostatečně validní. Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 31

32 35 / 40 Který typ kontraktu je adaptivní a tak dobře odpovídá způsobu práce Scrum? A. Typ kontraktu Časové jednotky nebo pevné jednotky B. Typ kontraktu S pevnou cenou C. Žádný typ kontraktu. A. Správně. Časové jednotky nebo pevné jednotky toto je preferovaný typ kontraktu, který je kompatibilní s adaptivní povahou projektu. Kontrakty s pevnou cenou a kontrakty s pevným rozsahem (někteří tak musí dokonce činit ze zákona), nejsou vhodné pro metodu Agile. Adaptivita je klíčovou hodnotou. Je těžké být adaptivní, když je cena projektu pevná. Proto typ kontraktu časové jednotky nebo pevné jednotky jednoznačně zapadá do systému Agile a Scrum lépe. (Literatura A, Typy kontraktu a Scrum) B. Špatně. Tento typ kontraktu může být proveden s metodou Scrum, ale práce v systému Agile je obtíženější. Rovněž typ s pevnou cenou není obvykle příliš adaptivní. Co když se zákazník rozhodne, že je třeba implementovat funkci s vysokou hodnotou, protože ROI je velmi vysoký? Nelze to provést ve scénáři s pevnou cenou. C. Špatně. Typ kontraktu Časové jednotky nebo pevné jednotky je adaptivní, proto to nemůže být správná odpověď. 36 / 40 Podle principů Agile Manifesta, který typ týmu může přijít s nejlepšími požadavky, architekturou a návrhem? A. Se společným místem práce B. Zkušený C. Samostatně organizovaný D. Dobře vyškolený A. Špatně. Tým se společným místem práce je vhodný pro zajištění komunikace, ale nemusí nezbytně vést k lepším požadavkům, architektuře nebo návrhu. B. Špatně. Zkušený tým Agile by měl být lepší než nezkušený tým Agile, ale každý tým Agile pravděpodobně výkonem předčí běžný zkušený tým. C. Správně. Nejlepší architektura, požadavky a návrhy jsou výsledkem práce samostatně organizovaných týmů. (Literatura A: Koncept agility) D. Špatně. Dobře vyškolený tým může pracovat dobře, ale tým Agile výkonem předčí i dobře školené pracovníky. Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 32

33 37 / 40 Plánování v Agile se odehrává na více úrovních včetně denního plánu, plánování sprintu a strategického plánu. Jaký pojem nejlépe popisuje víceúrovňové plánování? A. Plánování po vrstvách B. Plánovací poker C. Plánovací schůzka sprintu A. Správně. Když zobrazíte různé úrovně plánování v metodě Scrum ve formě diagramu, vypadají jako vrstvy cibule. (Literatura A: Plánování po vrstvách) B. Špatně. Plánovací poker je metoda odhadování úloh. C. Špatně. Plánovací schůzka sprintu není víceúrovňová, ale je to příklad plánování v rámci Scrum, které se odehrává na jedné z úrovní. 38 / 40 Člen týmu ze Scrum týmu má pocit, že vedoucí technický architekt z jiného týmu může mít určitý hodnotný pohled a zpětnou vazbu na produkt Jaká je nejlepší událost, kdy požádat o tuto zpětnou vazbu. A. Denní Scrum B. Plánovací schůzka sprintu C. Retrospektiva sprintu D. Vyhodnocení sprintu A. Špatně. Není rozumné ptát se na zpětnou vazbu během sprintu. Během sprintu tým nechce měnit položky backlogu sprintu, aby mohl udržet své tempo. B. Plánovací schůzka sprintu by měla být přesně pouze plánovací schůzkou. Nejedná se o vhodnou příležitost k žádosti o zpětnou vazbu. C. Špatně. V rámci retrospektivy sprintu se hodnotí procesy Scrum, který by měly být přezkoumány samotným týmem. D. Správně. Vyhodnocení sprintu je demonstrace sestavovaného produktu a je to tedy nejlepší příležitost pozvat externí zainteresované osoby a získat jejich příspěvek. Produkt předváděný v rámci vyhodnocení sprintu není konečný produkt. Konečný produkt je prezentován v rámci vydání sprintu (releasu). Každé jiné vyhodnocení sprintu je dobrým okamžikem pro žádost o zpětnou vazbu (Literatura A: Událost 4: Vyhodnocení sprintu) Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 33

34 39 / 40 Jeden pracovník pracuje na kódu a druhý jeho práci pozoruje, kritizuje a občas si vymění role. Jaká praxe zde bude dodržována? A. Přezkum kódu B. Průběžná integrace C. Párové programování D. Vývoj řízený testováním A. Špatně. Přezkum kódu znamená, že někdo kontroluje váš kód. Můžete to být vy, nebo někdo jiný. Není to párové programování. B. Špatně. Průběžná integrace znamená, že všichni programátoři musí nahrávat poslední verze kódu do úložiště například každou hodinu. Umožňuje to zajistit, že je předchozí práce hotová a nevyžaduje příliš dalších úprav. C. Správně. Párové programování je postup, kdy dva vývojáři pracují na jednom terminálu jeden jako řidič a druhý jako navigátor. (Literatura A: Postupy Agile) D. Špatně. Vývoj řízený testováním znamená mít připravené scénáře testování před napsáním programu, takže programátor píše jen něco, co projde testem. 40 / 40 Co je Sprint? A. Brainstormingová událost extrémního programování zaměřená na generování návrhových idejí. B. Soupeření mezi dvěma vývojáři o to, kdo z nich dokončí nějakou funkci rychleji. C. Jedna iterace metodologie Scrum. D. Poslední iterace projektu Scrum, kdy týmy pracují dlouhé hodiny k dokončení projektu. A. Špatně. Nic takového neexistuje a není to sprint. B. Špatně. V rámci Scrum není žádné soupeření mezi vývojáři. Bylo by to neproduktivní a není to v souladu se společnou prací a udržitelným tempem. C. Správně. Určitá iterace se označuje jako sprint. (Literatura A: Události Scrum) D. Špatně. Poslední iterace je sprint vydání (releasu). Sprint, ve kterém by tým pracoval dlouhé hodiny či přesčas, neexistuje. Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 34

35 Hodnocení Správné odpovědi na otázky naleznete v tabulce níže. číslo odpověď číslo odpověď 1 A 21 C 2 B 22 C 3 B 23 A 4 B 24 D 5 C 25 D 6 B 26 A 7 B 27 B 8 B 28 C 9 D 29 C 10 C 30 D 11 A 31 B 12 B 32 C 13 A 33 C 14 A 34 B 15 C 35 A 16 B 36 C 17 B 37 A 18 C 38 D 19 B 39 C 20 B 40 C Vzorový test EXIN Agile Scrum Foundation (ASF.CZ) 35

36 Kontaktujte EXIN

EXIN Agile Scrum Foundation Příručka ke zkoušce. Vydání

EXIN Agile Scrum Foundation Příručka ke zkoušce. Vydání EXIN Agile Scrum Foundation Příručka ke zkoušce Vydání 201608 Copyright 2016 EXIN Všechna práva vyhrazena. Žádná část této publikace nesmí být zveřejněna, reprodukována, kopírována nebo uložena v systému

Více

Seznam.cz. Tomáš Pergler. najdu tam, co neznám!

Seznam.cz. Tomáš Pergler. najdu tam, co neznám! Scrum @ Seznam.cz Tomáš Pergler Obsah přednášky Jak funguje Scrum role fáze (meetingy) vstupy / artefakty Jak děláme Scrum v Seznam.cz Praha Brno na dálku Jak reportujeme dál Projekty i maintenance Co

Více

SCRUM představení.

SCRUM představení. SCRUM představení viktor@masicek.net O mě - Viktor Mašíček Vystudoval jsem informatiku na MFF Při studiích jsem už pracoval jako programátor na částečný úvazek Praxe byla důležitá stejně jako škola Nejvíce

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

4IT445 - AGILNÍ VÝVOJ WEBOVÝCH APLIKACÍ AGILNÍ METODIKY VÝVOJE SW ING. JAN ČERNÝ

4IT445 - AGILNÍ VÝVOJ WEBOVÝCH APLIKACÍ AGILNÍ METODIKY VÝVOJE SW ING. JAN ČERNÝ 4IT445 - AGILNÍ VÝVOJ WEBOVÝCH APLIKACÍ AGILNÍ METODIKY VÝVOJE SW ING. JAN ČERNÝ 1 METODIKY K ČEMU JSOU DOBRÉ? BUĎ NEMÁTE ŽÁDNOU NEBO STRIKTNÍ / RIGORÓZNÍ POSTUPY NĚCO MEZI TÍM: AGILNÍ PŘÍSTUP K ČEMU

Více

P R O J E K T O V É Ř Í Z E N Í A M A R K E T I N G 4. 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 4. 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 4 1 Čtyři doplňkové znaky projektu A. Původ B. Produkt C. Trh D. Velikost 2 A. Původ V okamžiku vzniku potenciálního projektu je potřeba znát informace

Více

Semestrální práce z předmětu 4IT421 Téma: CMMI-DEV v.1.3 PA Project Monitoring and Control

Semestrální práce z předmětu 4IT421 Téma: CMMI-DEV v.1.3 PA Project Monitoring and Control VYSOKÁ ŠKOLA EKONOMICKÁ V PRAZE náměstí W. Churchilla 4, 130 67 Praha3 Semestrální práce z předmětu 4IT421 Téma: CMMI-DEV v.1.3 PA Project Monitoring and Control Jméno a příjmení: Michal Hendrich Školní

Více

Návrh softwarových systémů - úvod, motivace

Návrh softwarových systémů - úvod, motivace Návrh softwarových systémů - úvod, motivace Jiří Šebek, Martin Tomášek Návrh softwarových systémů (B6B36NSS) Obsah Motivace Integrace s ostatními obory SI Kdo / co ovlivňuje cílový SW Modely, metodiky

Více

Co je to SCRUM! FRAMEWORK vs METODIKA. Ken Schwaber a Jeff Sutherland ho mají za framework Kde hledat detaily?

Co je to SCRUM! FRAMEWORK vs METODIKA. Ken Schwaber a Jeff Sutherland ho mají za framework Kde hledat detaily? Úvod do SCRUM!! Co je to SCRUM! FRAMEWORK vs METODIKA Ken Schwaber a Jeff Sutherland ho mají za framework Kde hledat detaily? agilemanifesto.org www.mountaingoatsoftware.com/scrum Z čeho to je...! Vychází

Více

Management rizika Bc. Ing. Karina Mužáková, Ph.D. BIVŠ,

Management rizika Bc. Ing. Karina Mužáková, Ph.D. BIVŠ, Management rizika Bc. Ing. Karina Mužáková, Ph.D. BIVŠ, 2015 1 5/ Řízení rizika na úrovni projektu, podniku a v rámci corporate governance. BIVŠ, 2015 2 Definice projektu říká, že se jedná o činnost, která

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

PROBLÉMY A SPECIFIKA VÝVOJE SOFTWARE

PROBLÉMY A SPECIFIKA VÝVOJE SOFTWARE PROBLÉMY A SPECIFIKA VÝVOJE SOFTWARE Vývoj prvních programů byl prováděn nadšenci, programy byly šité na míru. Žádná metodika vývoje SW v té době neexistuje. Vývoj SW byl vnímán jako výzkum. Cíl, co bude

Více

ANALÝZA A PROJEKTOVÁNÍ SYSTÉMŮ Řízení projektů zavádění IS

ANALÝZA A PROJEKTOVÁNÍ SYSTÉMŮ Řízení projektů zavádění IS ANALÝZA A PROJEKTOVÁNÍ SYSTÉMŮ Řízení projektů zavádění IS Roman Danel VŠB TU Ostrava HGF Institut ekonomiky a systémů řízení Literatura Staníček, Z, - Hajkr, J.: Řízení projektů zavádění IS do organizací.

Více

Irská společnost pro autismus - Stanovení míry podpory k zajištění maximální samostatnosti The Irish Society for Autism.

Irská společnost pro autismus - Stanovení míry podpory k zajištění maximální samostatnosti The Irish Society for Autism. Irská společnost pro autismus - Stanovení míry podpory k zajištění maximální samostatnosti 2013 The Irish Society for Autism. 1 Kvalita života Služby poskytované lidem s autismem Irskou společností pro

Více

Kanboard Documentation. The Kanboard Authors

Kanboard Documentation. The Kanboard Authors The Kanboard Authors 21.11.2018 Obsah 1 Úvod 3 2 Uživatelé 5 3 Desky 7 4 Projekty 13 5 Úkoly 19 6 Nastavení 25 i ii Kanboard je bezplatný a otevřený zdroj pro správu projektů společnosti Kanban. Oficiální

Více

Vzor pro provádění národních standardů kvality

Vzor pro provádění národních standardů kvality Vzor pro provádění národních standardů kvality Úvod Pro některé poskytovatele ústavních služeb je provádění národních standardů obtížné. Je to zčásti důsledkem toho, že standardy nemají v současné době

Více

Týmy SiTD. M. Studeníková E.Pařenicová. E. Hesounová E. Benková K. Hubáček L. Juráňová T. Vojkůvka P. Říha

Týmy SiTD. M. Studeníková E.Pařenicová. E. Hesounová E. Benková K. Hubáček L. Juráňová T. Vojkůvka P. Říha Týmy SiTD Četa Alfa Charlie Echo Roger Členové T. Doubrava M. Rosta R. Fačevic T. Římský P. Zlámal J. Zlámal J. Svoboda J. Werner M. Kyral M. Mackovík P. Mlčoch D. Walter M. Grohmannová náhrada za OM Zodpovědnost

Více

komplexní podpora zvyšování výkonnosti strana 1 Využití Referenčního modelu integrovaného systému řízení veřejnoprávní korporace Město Hořovice

komplexní podpora zvyšování výkonnosti strana 1 Využití Referenčního modelu integrovaného systému řízení veřejnoprávní korporace Město Hořovice strana 1 Využití Referenčního modelu integrovaného systému řízení veřejnoprávní korporace Město Hořovice 19.3.2018 Zpracoval: Roman Fišer, strana 2 1. ÚVOD... 3 2. POPIS REFERENČNÍHO MODELU INTEGROVANÉHO

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

Analýza SWOT. Strategický management 05

Analýza SWOT. Strategický management 05 Analýza SWOT Strategický management 05 Využití metody: Plánování, rozhodování Facilitátor: ano Ideální počet účastníků: 4 8 (možno i více) Základní pomůcky: Flipchart, flipové papíry, lektorský kufřík

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

Manažerská ekonomika

Manažerská ekonomika PODNIKOVÝ MANAGEMENT (zkouška č. 12) Cíl předmětu Získat znalosti zákonitostí úspěšného řízení organizace a přehled o současné teorii a praxi managementu. Seznámit se s moderními manažerskými metodami

Více

Objektová tvorba SW, Analýza požadavků 2006 UOMO 53

Objektová tvorba SW, Analýza požadavků 2006 UOMO 53 Objektová tvorba SW, Analýza požadavků 2006 UOMO 53 Osnova Základní principy tvorby SW Fáze tvorby SW v předmětu UOMO Analýza požadavků Modelování typových úloh 2006 UOMO 54 Tvorba SW Dříve umění vyvolených

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

Projekty. Úvodní příručka

Projekty. Úvodní příručka Projekty Úvodní příručka Sledování úkolů Sharepointový seznam úkolů je praktický nástroj, který vám pomůže udržet si přehled o všem, co je potřeba v projektu udělat. Můžete přidávat data zahájení a termíny

Více

Návrh softwarových systém. Návrh softwarových systémů

Návrh softwarových systém. Návrh softwarových systémů Návrh softwarových systém ů - úvod, motivace Jiří Šebek Návrh softwarových systémů (B6B36NSS) Obsah Motivace Integrace s ostatními obory SI Modely, metodiky SI Verzování SW 2 Úvod Motivace SI Velké projekty

Více

Priorita IV. - Udržení transparentního systému financování sociálních služeb z rozpočtu MB a udržení metody KPSS

Priorita IV. - Udržení transparentního systému financování sociálních služeb z rozpočtu MB a udržení metody KPSS z rozpočtu MB a udržení metody KPSS Opatření IV. 1.: Udržení aktualizace transparentního systému rozdělování finančních prostředků. V současné době poskytuje město Mladá Boleslav finanční prostředky na

Více

Seminární práce Vývoj informačního systému. Manažerská informatika 2 Ing. Miroslav Lorenc

Seminární práce Vývoj informačního systému. Manažerská informatika 2 Ing. Miroslav Lorenc Seminární práce Vývoj informačního systému Manažerská informatika 2 Ing. Miroslav Lorenc Vypracoval: Jan Vít (xvitj17) LS 2007/2008 1. ÚVOD...3 1.1. POPIS PROJEKTU...3 2. OBSAH PROJEKTU...3 2.1. SEZNAM

Více

Praktické zkušenosti s nasazením agilní metodiky SCRUM při vývoji středně rozsáhlého softwarového projektu. Dušan Juhás

Praktické zkušenosti s nasazením agilní metodiky SCRUM při vývoji středně rozsáhlého softwarového projektu. Dušan Juhás Praktické zkušenosti s nasazením agilní metodiky SCRUM při vývoji středně rozsáhlého softwarového projektu. Dušan Juhás Motivace Vybrali jsme nový webový framework a potřebovali ho ověřit na reálné aplikaci

Více

Základy řízení bezpečnosti

Základy řízení bezpečnosti Základy řízení bezpečnosti Bezpečnost ve společnosti MND a.s. zahrnuje: - Bezpečnost a ochranu zdraví - Bezpečnost provozu, činností - Ochranu životního prostředí - Ochranu majetku - Ochranu dobrého jména

Více

A. Návrhy na nové aktivity v roce 2015:

A. Návrhy na nové aktivity v roce 2015: AKČNÍ PLÁN ZLEPŠOVÁNÍ PROCESU MÍSTNÍ AGENDY 21 Co je Akční plán zlepšování procesu místní Agendy 21? Součástí každé metody modernizace veřejné správy, každého úspěšného procesu, je formulace přehledného

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

SOFTWAROVÉ INŽENÝRSTVÍ

SOFTWAROVÉ INŽENÝRSTVÍ SOFTWAROVÉ INŽENÝRSTVÍ Plán a odhady projeku Ing. Ondřej Macek 2013/14 ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE Příprava plánu projektu 3 Motivace k plánování Průběh projektu Bolest Dobré plánování Špatné

Více

VÝSTUPNÍ ZPRÁVA Ukázka nové 360 zpětné vazby

VÝSTUPNÍ ZPRÁVA Ukázka nové 360 zpětné vazby www.tcconline.cz VÝSTUPNÍ ZPRÁVA Ukázka nové 60 zpětné vazby Monika Ukázková monikaukazkova@tcconline.cz. listopadu 206 ÚVOD Tato zpráva je výstupem 60 zpětné vazby, která byla realizována společností

Více

Příloha č. 1 Smlouvy o dílo. Popis projektu. Očekávaný přínos projektu

Příloha č. 1 Smlouvy o dílo. Popis projektu. Očekávaný přínos projektu Příloha č. 1 Smlouvy o dílo Popis projektu Individuální projekt Libereckého kraje Podpora procesů střednědobého plánování, síťování a financování sociálních služeb v Libereckém kraji (dále jen projekt)

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

Význam teambuildingu. Kdy jej uskutečnit Závazek. Teambuilding 1

Význam teambuildingu. Kdy jej uskutečnit Závazek. Teambuilding 1 Význam teambuildingu Kdy jej uskutečnit Závazek Teambuilding 1 Teambuilding workshop Je užitečný pro odborníky, kteří hledají nové strategie, techniky a prostředky teambuildingu Umožňuje řídícím manažerům,

Více

Metodický pokyn pro řízení kvality ve služebních úřadech: Kritéria zlepšování

Metodický pokyn pro řízení kvality ve služebních úřadech: Kritéria zlepšování Metodický pokyn pro řízení kvality ve služebních úřadech: Kritéria zlepšování Ing. Štěpánka Cvejnová vedoucí kanceláře náměstka ministra vnitra pro státní službu sekce pro státní službu Ministerstvo vnitra

Více

Procesy, procesní řízení organizace. Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje

Procesy, procesní řízení organizace. Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje Procesy, procesní řízení organizace Výklad procesů pro vedoucí odborů krajského úřadu Karlovarského kraje Co nového přináší ISO 9001:2008? Vnímání jednotlivých procesů organizace jako prostředku a nástroje

Více

SOFTWAROVÉ INŽENÝRSTVÍ 1

SOFTWAROVÉ INŽENÝRSTVÍ 1 Metodický list č. 1 Název tématického celku: Úvod do softwarového inženýrství Základním cílem tohoto tematického celku je vysvětlení smyslu discipliny nazývané softwarové inženýrství. Tematický celek zahrnuje

Více

Návod k požadavkům ISO 9001:2015 na dokumentované informace

Návod k požadavkům ISO 9001:2015 na dokumentované informace International Organization for Standardization BIBC II, Chemin de Blandonnet 8, CP 401, 1214 Vernier, Geneva, Switzerland Tel: +41 22 749 01 11, Web: www.iso.org Návod k požadavkům ISO 9001:2015 na dokumentované

Více

Metodická příručka k uplatnění některých metod při hodnocení dopadů regulace (RIA)

Metodická příručka k uplatnění některých metod při hodnocení dopadů regulace (RIA) 1 Metodická příručka k uplatnění některých metod při hodnocení dopadů regulace (RIA) 2 OBSAH 1. Alternativní formy řešení problému... 3 2. Metody porovnávání dopadů... 4 3 1. ALTERNATIVNÍ FORMY ŘEŠENÍ

Více

WS PŘÍKLADY DOBRÉ PRAXE

WS PŘÍKLADY DOBRÉ PRAXE WS PŘÍKLADY DOBRÉ PRAXE ISO 9001 revize normy a její dopady na veřejnou správu Ing. Pavel Charvát, člen Rady pro akreditaci Českého institutu pro akreditaci 22.9.2016 1 ISO 9001 revize normy a její dopady

Více

Práce s velkými sestavami

Práce s velkými sestavami Práce s velkými sestavami Číslo publikace spse01650 Práce s velkými sestavami Číslo publikace spse01650 Poznámky a omezení vlastnických práv Tento software a související dokumentace je majetkem společnosti

Více

Obsah. 1. část Definice projektových cílů

Obsah. 1. část Definice projektových cílů Předmluva 1 Proč je řízení projektů tak důležité 1 Komu je kniha určena 1 Pojetí výkladu řízení projektů v této knize 2 Užitečné a unikátní rysy knihy 2 Jak je kniha uspořádána 3 Poděkování 4 1. Co je

Více

Obsah. 1.1 Práce se záznamy... 3 1.2 Stránka Dnes... 4. 2.1 Kontakt se zákazníkem... 5

Obsah. 1.1 Práce se záznamy... 3 1.2 Stránka Dnes... 4. 2.1 Kontakt se zákazníkem... 5 CRM SYSTÉM KORMORÁN UŽIVATELSKÁ PŘÍRUČKA Obsah 1 Základní práce se systémem 3 1.1 Práce se záznamy................................. 3 1.2 Stránka Dnes.................................... 4 1.3 Kalendář......................................

Více

Předmluva 11. Poděkování 11 O autorech 12 Úvodem 12 Komu je tato kniha určena 13 Jak byste měli tuto knihu číst 13 Web 14

Předmluva 11. Poděkování 11 O autorech 12 Úvodem 12 Komu je tato kniha určena 13 Jak byste měli tuto knihu číst 13 Web 14 Obsah Předmluva 11 Poděkování 11 O autorech 12 Úvodem 12 Komu je tato kniha určena 13 Jak byste měli tuto knihu číst 13 Web 14 KAPITOLA 1 Úvod do architektury softwaru 15 Použití procesu 16 Stručný popis

Více

PŘÍLOHY NAŘÍZENÍ KOMISE V PŘENESENÉ PRAVOMOCI (EU)

PŘÍLOHY NAŘÍZENÍ KOMISE V PŘENESENÉ PRAVOMOCI (EU) EVROPSKÁ KOMISE V Bruselu dne 13.7.2018 C(2018) 4438 final ANNEXES 1 to 2 PŘÍLOHY NAŘÍZENÍ KOMISE V PŘENESENÉ PRAVOMOCI (EU) kterým se doplňuje nařízení Evropského parlamentu a Rady (EU) 2016/1011, pokud

Více

Umí HR držet krok s byznysem (zkušenosti z agilního řízení)

Umí HR držet krok s byznysem (zkušenosti z agilního řízení) Umí HR držet krok s byznysem (zkušenosti z agilního řízení) Jana Gutierrez Chvalkovska Konference HR v pohybu 23.května 2018 Co nás čeká? Co je to agile? Jak lze využít prvky agilního řízení v HR Příklady

Více

Charakteristické rysy projektů

Charakteristické rysy projektů Řízení projektů Charakteristické rysy projektů Cíl projektu Trojrozměrný cíl (věcné provedení, časový plán, rozpočtové náklady) = trojimperativ Jedinečnost Každý projekt je jedinečný Zdroje Realizace pomocí

Více

WORKFLOW. Procesní přístup. Základ perspektivního úspěšného podnikového řízení. Funkčnířízení založené na dělbě práce

WORKFLOW. Procesní přístup. Základ perspektivního úspěšného podnikového řízení. Funkčnířízení založené na dělbě práce WORKFLOW Procesní přístup Základ perspektivního úspěšného podnikového řízení Funkčnířízení založené na dělbě práce Procesní řízení princip integrace činností do ucelených procesů 1 Funkční řízení Dělba

Více

ÚVOD DO SOFTWAROVÉHO INŽENÝRSTVÍ

ÚVOD DO SOFTWAROVÉHO INŽENÝRSTVÍ ÚVOD DO SOFTWAROVÉHO INŽENÝRSTVÍ Předmětem softwarového inženýrství jsou metodiky pro řízení vývoje softwaru. Proč potřebujeme tyto metodiky? Čím je vývoje softwaru specifický oproti jiným odvětvím? SOFTWAROVÉ

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

Podnikové, programové a projektové cíle. Pavel Reich, Logica Listopad 2011

Podnikové, programové a projektové cíle. Pavel Reich, Logica Listopad 2011 Podnikové, programové a projektové cíle Pavel Reich, Logica Listopad 2011 Co vedení společnosti vrtá hlavou Projekt byl dokončen včas a v rámci plánovaného rozpočtu. Řešení se v zásadě chová, jak bylo

Více

Náhled. Dotazník lze vyplnit pouze na internetu.

Náhled. Dotazník lze vyplnit pouze na internetu. Náhled. Dotazník lze vyplnit pouze na internetu. Dotazník Směrem k hodnocení strategie Evropa 2020 v polovině období z pohledu měst a regionů EU Kontext Příští rok má začít hodnocení strategie Evropa 2020,

Více

Uživatelská příručka systému pro administrátory obcí a manuál pro správce portálu

Uživatelská příručka systému pro administrátory obcí a manuál pro správce portálu Softwarová podpora tvorby rozvojových dokumentů obcí Uživatelská příručka systému pro administrátory obcí a manuál pro správce portálu Verze 1.3 Zpracováno v rámci projektu CZ.1.04/4.1.00/62.00008 ELEKTRONICKÁ

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

Přínosy ITIL a potíže s implementací. Ing. Štěpán Macura

Přínosy ITIL a potíže s implementací. Ing. Štěpán Macura Přínosy ITIL a potíže s implementací Ing. Štěpán Macura Program Přínosy a motivace k ITIL Potíže s implementací Přínosy ITIL Ing. Štěpán Macura macura@cruxit.com Motivace k ITIL Externí (nařízeno vedením)

Více

Řízení prací na vodovodních sítích

Řízení prací na vodovodních sítích Řízení prací na vodovodních sítích Ing. Josef Fojtů 1) Ing. Jiří Tajdus 1), Ing. Milan Koníř 2) 1) QLine a.s., 2) Severomoravské vodovody a kanalizace Ostrava a.s. Cílem příspěvku je představení základních

Více

Příloha 2. Prohlášení o přijetí závazků Žadatelem

Příloha 2. Prohlášení o přijetí závazků Žadatelem Příloha 2 k Vyhlášení výběrového řízení za účelem udělení práv k využívání rádiových kmitočtů pro zajištění sítí elektronických komunikací v kmitočtovém pásmu 3,7 GHz Prohlášení o přijetí závazků Žadatelem

Více

Přidělování CPU Mgr. Josef Horálek

Přidělování CPU Mgr. Josef Horálek Přidělování CPU Mgr. Josef Horálek Přidělování CPU = Přidělování CPU je základ multiprogramového OS = pomocí přidělování CPU různým procesům OS zvyšuje výkon výpočetního systému; = Základní myšlenka multiprogramování

Více

Docházka INTRAWEB. Osobní údaje

Docházka INTRAWEB. Osobní údaje Docházka INTRAWEB Ve docházkovém systému je možno používat také tenkého klienta. Přes internetový prohlížeč je možno sledovat docházku zaměstnanců, žádat o dovolenou, schvalovat docházku, atd. Zákazníci,

Více

PROVÁDĚCÍ ROZHODNUTÍ KOMISE (EU) / ze dne

PROVÁDĚCÍ ROZHODNUTÍ KOMISE (EU) / ze dne EVROPSKÁ KOMISE V Bruselu dne 2.2.2018 C(2018) 533 final PROVÁDĚCÍ ROZHODNUTÍ KOMISE (EU) / ze dne 2.2.2018 o jednotných podrobných specifikacích pro shromažďování a analýzu údajů ke sledování a hodnocení

Více

A. Návrhy na nové aktivity v roce 2015:

A. Návrhy na nové aktivity v roce 2015: AKČNÍ PLÁN ZLEPŠOVÁNÍ PROCESU MÍSTNÍ AGENDY 21 Co je Akční plán zlepšování procesu místní Agendy 21? Součástí každé metody modernizace veřejné správy, každého úspěšného procesu, je formulace přehledného

Více

Softwarový proces. Bohumír Zoubek, Tomáš Krátký

Softwarový proces. Bohumír Zoubek, Tomáš Krátký Softwarový proces Bohumír Zoubek, Tomáš Krátký 1 Úvod Základní pojmy Softwarový proces / Model životního cyklu vývoje software (SDLC, Software Development Lifecycle) Množina aktivit nutných k tomu, aby

Více

EDURO Projektové vzdělávání I

EDURO Projektové vzdělávání I EVROPSKÝ SOCIÁLNÍ FOND EDURO Projektové vzdělávání I PRAHA & EU INVESTUJEME DO VAŠÍ BUDOUCNOSTI Ing. Jitka Svatošová Evropský sociální fond Praha a EU Investujeme do vaší budoucnosti Úvod Úvod - co je

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

POČÍTAČE A PROGRAMOVÁNÍ

POČÍTAČE A PROGRAMOVÁNÍ POČÍTAČE A PROGRAMOVÁNÍ Moderní metody vývoje softwaru, Demontrační příklad piškvorky Miroslav Vavroušek PPI 09 V1.0 Opakovaní z minulé přednášky Vícerozměrná statická a dynamická pole Pole polí Datový

Více

CEMEX Go. Faktury. Verze 2.1

CEMEX Go. Faktury. Verze 2.1 Faktury Verze 2. Faktury Ve snaze inovovat a zlepšovat zkušenosti našich zákazníků společnost CEMEX vytvořila integrované digitální řešení, které vám umožní správu vaší obchodní činnosti v reálném čase.

Více

Rozhodovací procesy 3

Rozhodovací procesy 3 Rozhodovací procesy 3 Informace a riziko Příprava předmětu byla podpořena projektem OPPA č. CZ.2.17/3.1.00/33253 III rozhodování 1 Rozhodovací procesy Cíl přednášky 1-3: Význam rozhodování Rozhodování

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 10. PLÁN RIZIK, PROJEKTOVÁ DOKUMENTACE, VÝBĚROVÉ ŘÍZENÍ A NÁKUPY Vysoká škola technická a ekonomická v Českých Budějovicích Institute of Technology And Business In České Budějovice Tento učební materiál

Více

ČÁST 1. Rozhodující koncepce odhadů. Co je Odhad? 25

ČÁST 1. Rozhodující koncepce odhadů. Co je Odhad? 25 Stručný obsah Část 1: Rozhodující koncepce odhadů 23 Kapitola 1 Co je Odhad? 25 Kapitola 2 Jak dobré odhady děláte? 37 Kapitola 3 Hodnota přesných odhadů 43 Kapitola 4 Odkud se berou chyby v odhadech?

Více

Metodika analýzy. Příloha č. 1

Metodika analýzy. Příloha č. 1 Metodika analýzy Příloha č. 1 Příloha č. 1 1 Účel dokumentu Dokument popisuje závaznou metodiku systémové analýzy, je upraven na míru pro prostředí Podniku. Dokument je provázán s Podnikovou analýzou,

Více

Zavádění řízení kvality ve služebních úřadech. Mgr. Markéta Munková Praha,

Zavádění řízení kvality ve služebních úřadech. Mgr. Markéta Munková Praha, Zavádění řízení kvality ve služebních úřadech Mgr. Markéta Munková Praha, 18. 1. 2018 Zavádění řízení kvality ve služebních úřadech I. Proč zavádět řízení kvality do služebních úřadů a z čeho taková povinnost

Více

Algoritmizace diskrétních. Ing. Michal Dorda, Ph.D.

Algoritmizace diskrétních. Ing. Michal Dorda, Ph.D. Algoritmizace diskrétních simulačních modelů Ing. Michal Dorda, Ph.D. 1 Úvodní poznámky Při programování simulačních modelů lze hlavní dílčí problémy shrnout do následujících bodů: 1) Zachycení statických

Více

ISA 610 POSUZOVÁNÍ PRÁCE INTERNÍHO AUDITU. (Platí pro audity účetních závěrek sestavených za období počínající 15.prosince 2004 nebo po tomto datu)

ISA 610 POSUZOVÁNÍ PRÁCE INTERNÍHO AUDITU. (Platí pro audity účetních závěrek sestavených za období počínající 15.prosince 2004 nebo po tomto datu) POSUZOVÁNÍ PRÁCE INTERNÍHO AUDITU (Platí pro audity účetních závěrek sestavených za období počínající 15.prosince 2004 nebo po tomto datu) O B S A H Odstavec Úvod... 1-4 Rozsah a cíle interního auditu..

Více

Newsletter RIBTEC automatické aktualizace Praktická novinka v servisu a podpoře k softwaru RIBTEC od verzí 15.0

Newsletter RIBTEC automatické aktualizace Praktická novinka v servisu a podpoře k softwaru RIBTEC od verzí 15.0 1.1 Automatické aktualizace RIBTEC Pomocí nového Prostředí automatických aktualizací můžete udržovat Váš software stavební statiky RIBTEC od verzí 15.0 a vyšších na aktuálním stavu. Tento systémový nástroj

Více

Myšlení versus Směrnice?

Myšlení versus Směrnice? Myšlení versus Směrnice? Jak compliance nachází rovnováhu mezi hodnotami a pravidly. Mercedes-Benz Česká republika Marek Sixta Prezentace odráží osobní stanoviska prezentujícího a není oficiálně publikovaným

Více

VÝSTUPNÍ ZPRÁVA. Jan Hodnocený 360 zpětná vazba

VÝSTUPNÍ ZPRÁVA. Jan Hodnocený 360 zpětná vazba VÝSTUPNÍ ZPRÁVA Jan Hodnocený tcconline@203.5149.cz.49766 360 zpětná vazba KAPITOLY Úvod Jak s výstupem pracovat Hodnocené kompetence Škála hodnocení Hodnotitelé Hodnocení dílčích kompetencí Hodnocení

Více

Management. Ing. Jan Pivoňka

Management. Ing. Jan Pivoňka Management Ing. Jan Pivoňka Stanovení osobní vize V souladu s kotvou Konkrétní představa Citový náboj Stimul pro aktivní jednání Krátkodobější cíle motivace Výjimky Jasná vize Pohodoví lidé Úspěch bez

Více

NOVINKY v PROGRAMU DOCHÁZKA ADS

NOVINKY v PROGRAMU DOCHÁZKA ADS NOVINKY v PROGRAMU DOCHÁZKA ADS 4 1.2.2010 Uživatelské prostředí nové grafické prostředí programu rychlé menu ve dvou režimech - pouze ikony, ikony s popisem implementace Drag & Drop při přiřazování kalendáře,

Více

Aplikační software. Řízení lidských zdrojů PRAHA 2014. Zpracoval: Ing. Pavel Branšovský pro potřebu VOŠ a SŠSE

Aplikační software. Řízení lidských zdrojů PRAHA 2014. Zpracoval: Ing. Pavel Branšovský pro potřebu VOŠ a SŠSE Aplikační software Řízení lidských zdrojů PRAHA 2014 Zpracoval: Ing. Pavel Branšovský pro potřebu VOŠ a SŠSE Volně použito podkladů z Internetových serverů www.vikupedie.com a dalších. 1 Procesy a dokumenty

Více

Řešení problémů s projektem

Řešení problémů s projektem 9 Řešení problémů s projektem Vyšší management Projektový manažer Všechny šťastné rodiny jsou si podobné; každá nešťastná rodina je nešťastná po svém. L. Tolstoj, Anna Karenina 1 Obrázek 9.1 Lev Nikolajevič

Více

Zápis z přezkoumání QMS vedením škol SČMSD za období od 6/2009 do 9/2010

Zápis z přezkoumání QMS vedením škol SČMSD za období od 6/2009 do 9/2010 Příloha č. 6 MICOOP-správa škol List číslo: 1 / 6 Druh dokumentu: Zápis z přezkoumání QMS Vydání: 1 Identifikační označení: 1/2010 Výtisk číslo:1 Zápis z přezkoumání QMS vedením škol SČMSD za období od

Více

Systémy pro podporu rozhodování. Hlubší pohled 2

Systémy pro podporu rozhodování. Hlubší pohled 2 Systémy pro podporu rozhodování Hlubší pohled 2 1 Připomenutí obsahu minulé přednášky Motivační příklad Konfigurace DSS Co to je DSS? definice Charakterizace a možnosti DSS Komponenty DSS Subsystém datového

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

Design systému. Komponentová versus procesní architektura

Design systému. Komponentová versus procesní architektura Design systému Komponentová versus procesní architektura Architektura : třídy statické aspekty propojení logický pohled struktura popisu systému Architektura procesů: objekty dynamické aspekty koordinace

Více

Aplikovaná informatika

Aplikovaná informatika 1 Aplikovaná informatika VYUŽITÍ OSOBNÍCH INFORMAČNÍCH SYSTÉMŮ V PRÁCI BEZPEČNOSTNÍHO MANAŽERA ZEMÁNEK, Z. - PLUSKAL, D. Operační program Vzdělávání pro konkurenceschopnost Projekt: Vzdělávání pro bezpečnostní

Více

The Scrum Guide. Průvodce Scrumem: Pravidla hry. říjen 2011. Vyvinuli a udržují Ken Schwaber a Jeff Sutherland Český překlad vytvořila agilia.

The Scrum Guide. Průvodce Scrumem: Pravidla hry. říjen 2011. Vyvinuli a udržují Ken Schwaber a Jeff Sutherland Český překlad vytvořila agilia. The Scrum Guide Průvodce Scrumem: Pravidla hry říjen 2011 Vyvinuli a udržují Ken Schwaber a Jeff Sutherland Český překlad vytvořila agilia.cz Cíl průvodce Scrumem... 3 Scrum v kostce... 3 Základní rámec...

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

Proces vývoje HRIS Vema (Human Resources Information System) Jaroslav Šmarda

Proces vývoje HRIS Vema (Human Resources Information System) Jaroslav Šmarda Proces vývoje HRIS Vema (Human Resources Information System) Jaroslav Šmarda Proces vývoje HRIS Vema Vlastnosti HRIS (Human Resources Information System) HRIS Vema Proces vývoje HRIS Vema Vema, a. s. Přední

Více

SW podpora projektového řízení

SW podpora projektového řízení Browser MS-Project SW podpora projektového řízení Společnost appcore s.r.o. nabízí služby v oblastech systémové integrace, softwarové integrace a řízení organizace. Veškeré služby naší společnosti jsou

Více

2. Začlenění HCI do životního cyklu software

2. Začlenění HCI do životního cyklu software Jan Schmidt 2011 Katedra číslicového návrhu Fakulta informačních technologií České vysoké učení technické v Praze Zimní semestr 2011/12 EVROPSKÝ SOCIÁLNÍ FOND PRAHA & EU: INVESTUJENE DO VAŠÍ BUDOUCNOSTI

Více

Na základě Business Targets autora Simona Greenalla, vydaných nakladatelstvím Macmillan Heinemann English Language Teaching (Oxford).

Na základě Business Targets autora Simona Greenalla, vydaných nakladatelstvím Macmillan Heinemann English Language Teaching (Oxford). LANGMaster International, s.r.o. Branická 107, 147 00 Praha 4 Česká republika Tel.: +420 244 460 807, +420 736 623 459 Fax: +420 244 463 411 e-mail: info@langmaster.cz http://www.langmaster.cz Na základě

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

BEZPEČNOST A OCHRANA ZDRAVÍ

BEZPEČNOST A OCHRANA ZDRAVÍ ZÁKLADNÍ A NEZBYTNÉ ČINNOSTI BEZPEČNOST A OCHRANA ZDRAVÍ PŘI PRÁCI SPOLEČNÉ PROHLÁŠENÍ PŘEDSEDY PŘEDSTAVENSTVA A GENERÁLNÍHO ŘEDITELE SKUPINY VINCI XAVIERA HUILLARDA A EVROPSKÉ RADY ZAMĚSTNANCŮ Bezpečnost

Více

Průvodce aplikací FS Karta

Průvodce aplikací FS Karta Průvodce aplikací FS Karta Základní informace k Aplikaci Online aplikace FS Karta slouží k bezpečnému ukládání osobních údajů fyzických osob a k jejich zpracování. Osobní údaje jsou uloženy ve formě karty.

Více

PRAVIDLA PRO PROVÁDĚNÍ OBCHODŮ

PRAVIDLA PRO PROVÁDĚNÍ OBCHODŮ AKRO investiční společnost, a.s. Slunná 25 162 00 Praha 6 PRAVIDLA PRO PROVÁDĚNÍ OBCHODŮ AKRO investiční společnost, a.s., identifikační číslo 492 41 699, se sídlem Praha 6, Slunná 547/25 (dále jen společnost,

Více

Zkouška ITIL Foundation

Zkouška ITIL Foundation Zkouška ITIL Foundation Sample Paper A, version 5.1 Výběr z více možností Pokyny 1. Měli byste se pokusit odpovědět na všech 40 otázek. 2. Všechny svoje odpovědi vyznačte na samostatný formulář, který

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