SCRUM: Porovnání verzí
(Není zobrazeno 24 mezilehlých verzí od stejného uživatele.) | |||
Řádek 1: | Řádek 1: | ||
− | |||
− | |||
==Agilní metodiky== | ==Agilní metodiky== | ||
[[Agilní metody projektování. Principy, role, organizace, nástroje|Agilní metodika]] (anglicky agile methodology) je pracovní metoda, která spočívá v rozdělení velkých a složitých projektů na malé úkoly, které jsou mnohem rychleji splnitelné. Když pracujeme na menších úkolech, jsme také méně náchylní k rozptýlení, a obecně tento typ práce přináší lepší výkony z hlediska produktivity. <ref name="WJ">LACORT, Javier. Agilní metodika: O co se jedná a jak ji uplatnit? Welcome to the Jungle [online]. 3. června 2020 [cit. 2021-06-18]. Dostupné z: https://www.welcometothejungle.com/cs/articles/agilni-metodika</ref> Agilní metodika klade důraz na průběžnou [[Komunikace|komunikaci]] mezi vývojovým týmem a zákazníkem a také na týmovou spolupráci a samoorganizaci týmu. Dále také klade vyšší důraz na výslednou hodnotu pro zákazníka před dokumenty a papíry. Na změny se nepohlíží negativně, ale jsou vítány jako příležitost býti lepší. | [[Agilní metody projektování. Principy, role, organizace, nástroje|Agilní metodika]] (anglicky agile methodology) je pracovní metoda, která spočívá v rozdělení velkých a složitých projektů na malé úkoly, které jsou mnohem rychleji splnitelné. Když pracujeme na menších úkolech, jsme také méně náchylní k rozptýlení, a obecně tento typ práce přináší lepší výkony z hlediska produktivity. <ref name="WJ">LACORT, Javier. Agilní metodika: O co se jedná a jak ji uplatnit? Welcome to the Jungle [online]. 3. června 2020 [cit. 2021-06-18]. Dostupné z: https://www.welcometothejungle.com/cs/articles/agilni-metodika</ref> Agilní metodika klade důraz na průběžnou [[Komunikace|komunikaci]] mezi vývojovým týmem a zákazníkem a také na týmovou spolupráci a samoorganizaci týmu. Dále také klade vyšší důraz na výslednou hodnotu pro zákazníka před dokumenty a papíry. Na změny se nepohlíží negativně, ale jsou vítány jako příležitost býti lepší. | ||
Řádek 42: | Řádek 40: | ||
===Scrum Master=== | ===Scrum Master=== | ||
− | Role Scrum Mastera není úplně standardní. Není to manažer, klasický | + | Role Scrum Mastera není úplně standardní. Není to manažer, klasický team leader a ani to není nadřízený, je to člen týmu, stejně jako ostatní. Scrum Master pracuje jako spojení mezi týmem a jakýmkoliv rušivým elementem zvenku. Role Scrum mastera je chránit tým a vytvářet prostředí, kde by členy týmu nikdo neměl rušit, podporovat tým, odstraňovat problémy a pomáhat jeho efektivnější práci. <ref name="AS">STARASTSINA, Arina. Metodika SCRUM pro malé IT projekty. Brno: Masarykova univerzita, Fakulta informatiky, 2016, 80 s. Vedoucí diplomové práce: RNDr. Jaroslav Ráček, Ph.D [cit. 2021-06-09]. Dostupné z: https://is.muni.cz/th/ppe67/Diplomova_prace_Arina_Starastsina.pdf</ref> Scrum Master má na starosti samotný proces Scrumu — školí principy Scrumu lidem zainteresovaným na projektu, implementuje vhodně Scrum do kultury firmy a kontroluje dodržování pravidel a praktik Scrumu. Náplní jeho práce je odstraňovat překážky, které brání týmu v dosažení maximální efektivity. <ref name="RF">FIANTA, Roman. Použití SCRUM pro menší a střední webové projekty. Brno: Masarykova univerzita, Fakulta informatiky, 2011, 97 s. Vedoucí diplomové práce: RNDr. Jaroslav Ráček, Ph.D [cit. 2021-06-09]. Dostupné z: https://is.muni.cz/th/l98on/dp.pdf</ref> |
'''Scrum Master by měl být:''' | '''Scrum Master by měl být:''' | ||
Řádek 54: | Řádek 52: | ||
===Product Owner=== | ===Product Owner=== | ||
− | Product Owner je vlastník produktu, který má určovat priority a rozhoduje o tom, na čem se bude dále pracovat. Má na starosti vizi projektu. Product Owner by měl být týmu pravidelně k dispozici, ale na rozdíl od Scrum Mastera se nemusí starat o potřeby týmu a neustále s ním komunikovat. <ref name="AS">STARASTSINA, Arina. Metodika SCRUM pro malé IT projekty. Brno: Masarykova univerzita, Fakulta informatiky, 2016, 80 s. Vedoucí diplomové práce: RNDr. Jaroslav Ráček, Ph.D [cit. 2021-06-09]. Dostupné z: https://is.muni.cz/th/ppe67/Diplomova_prace_Arina_Starastsina.pdf</ref> Představuje zájmy [[Stakeholder|stakeholderů]], tedy lidí, kteří bud’ financují projekt, nebo hodlají používat funkcionalitu jím poskytovanou či budou nějakým jiným způsobem projektem ovlivněni. Vlastník produktu je zodpovědný za tvorbu požadavků, návratnost investic ([[Return on Investment (ROI)|ROI]]) a plán vydání (release plan). Požadavky jsou zachyceny v artefaktu nazývaném Product backlog. <ref name="RF">FIANTA, Roman. Použití SCRUM pro menší a střední webové projekty. Brno: Masarykova univerzita, Fakulta informatiky, 2011, 97 s. Vedoucí diplomové práce: RNDr. Jaroslav Ráček, Ph.D [cit. 2021-06-09]. Dostupné z: https://is.muni.cz/th/l98on/dp.pdf</ref> | + | Product Owner je vlastník produktu, který má určovat priority a rozhoduje o tom, na čem se bude dále pracovat. Má na starosti vizi projektu. Product Owner by měl být týmu pravidelně k dispozici, ale na rozdíl od Scrum Mastera se nemusí tolik starat o potřeby týmu a neustále s ním komunikovat. <ref name="AS">STARASTSINA, Arina. Metodika SCRUM pro malé IT projekty. Brno: Masarykova univerzita, Fakulta informatiky, 2016, 80 s. Vedoucí diplomové práce: RNDr. Jaroslav Ráček, Ph.D [cit. 2021-06-09]. Dostupné z: https://is.muni.cz/th/ppe67/Diplomova_prace_Arina_Starastsina.pdf</ref> Představuje zájmy [[Stakeholder|stakeholderů]], tedy lidí, kteří bud’ financují projekt, nebo hodlají používat funkcionalitu jím poskytovanou či budou nějakým jiným způsobem projektem ovlivněni. Vlastník produktu je zodpovědný za tvorbu požadavků, návratnost investic ([[Return on Investment (ROI)|ROI]]) a plán vydání (release plan). Požadavky jsou zachyceny v artefaktu nazývaném Product backlog. <ref name="RF">FIANTA, Roman. Použití SCRUM pro menší a střední webové projekty. Brno: Masarykova univerzita, Fakulta informatiky, 2011, 97 s. Vedoucí diplomové práce: RNDr. Jaroslav Ráček, Ph.D [cit. 2021-06-09]. Dostupné z: https://is.muni.cz/th/l98on/dp.pdf</ref> |
===Scrum tým=== | ===Scrum tým=== | ||
− | Týmová spolupráce je velice důležitá pro agilní vývoj. Ve Scrumu se tým bere jako nedělitelný celek, proto nezáleží na selhání jednoho člena, vždy za vše odpovídají všichni. Tým musí zahrnovat Scrum Mastera, který pomůže vývojovému procesu a komunikaci týmu s vnějším světem a Product Ownera, který ví vše o produktu a určuje směr a priority ve vývoji. <ref name="AS">STARASTSINA, Arina. Metodika SCRUM pro malé IT projekty. Brno: Masarykova univerzita, Fakulta informatiky, 2016, 80 s. Vedoucí diplomové práce: RNDr. Jaroslav Ráček, Ph.D [cit. 2021-06-09]. Dostupné z: https://is.muni.cz/th/ppe67/Diplomova_prace_Arina_Starastsina.pdf</ref> Tým je zodpovědný za vyvíjení funkcionality, tedy z hlediska [[Software|softwaru]] za tvorbu kódu. Ideální počet členů týmu je obvykle uváděn jako 5–9 osob. Mike Cohn uvádí velmi stručnou poučku pro velikost týmu: pokud nasytíte tým dvěma pizzami, máte správnou velikost. <ref name="RF">FIANTA, Roman. Použití SCRUM pro menší a střední webové projekty. Brno: Masarykova univerzita, Fakulta informatiky, 2011, 97 s. Vedoucí diplomové práce: RNDr. Jaroslav Ráček, Ph.D [cit. 2021-06-09]. Dostupné z: https://is.muni.cz/th/l98on/dp.pdf</ref> | + | Týmová spolupráce je velice důležitá pro agilní vývoj. Ve Scrumu se tým bere jako nedělitelný celek, proto nezáleží na selhání jednoho člena, vždy za vše odpovídají všichni. Tým musí zahrnovat Scrum Mastera, který pomůže vývojovému procesu a komunikaci týmu s vnějším světem a Product Ownera, který ví vše o produktu a určuje směr a priority ve vývoji. <ref name="AS">STARASTSINA, Arina. Metodika SCRUM pro malé IT projekty. Brno: Masarykova univerzita, Fakulta informatiky, 2016, 80 s. Vedoucí diplomové práce: RNDr. Jaroslav Ráček, Ph.D [cit. 2021-06-09]. Dostupné z: https://is.muni.cz/th/ppe67/Diplomova_prace_Arina_Starastsina.pdf</ref> Tým je zodpovědný za vyvíjení funkcionality, tedy z hlediska [[Software|softwaru]] za tvorbu kódu. Ideální počet členů týmu je obvykle uváděn jako 5–9 osob. Mike Cohn uvádí velmi stručnou poučku: ''pro velikost týmu: pokud nasytíte tým dvěma pizzami, máte správnou velikost.'' <ref name="RF">FIANTA, Roman. Použití SCRUM pro menší a střední webové projekty. Brno: Masarykova univerzita, Fakulta informatiky, 2011, 97 s. Vedoucí diplomové práce: RNDr. Jaroslav Ráček, Ph.D [cit. 2021-06-09]. Dostupné z: https://is.muni.cz/th/l98on/dp.pdf</ref> |
==Praktiky a artefakty== | ==Praktiky a artefakty== | ||
Řádek 70: | Řádek 68: | ||
===Product backlog=== | ===Product backlog=== | ||
− | Jedná se o prioritizovaný seznam všeho, co může být potřeba v produktu a je jediným zdrojem požadavků na jakoukoliv změnu v produktu. | + | Jedná se o prioritizovaný seznam všeho, co může být potřeba v produktu a je jediným zdrojem požadavků na jakoukoliv změnu v produktu. Product Owner je zodpovědný za obsah, dostupnost a prioritizaci backlogu. Produktový backlog je dynamický a stále se mění tak, aby obsahoval to, co produkt potřebuje. Existuje po dobu existence produktu. Je to vlastně seznam všech vlastností, požadavků, rozšíření a oprav chyb, které představují všechny změny, které budou provedeny v produktu v příštích vydání. Položky v produktovém backlogu mají popis, prioritu (nejvyšší priorita = nejvyšší hodnota pro byznys → nejvíce rozpracované – podklad pro backlog sprintu) a odhad. <ref name="KSJS">SCHWABER, Ken a SUTHERLAND, Jeff. Průvodce Scrumem - pravidla hry. Scrum Guides [online]. 2014 [cit. 2021-06-20]. Dostupné z: https://scrumguides.org/docs/scrumguide/v1/Scrum-Guide-CS.pdf</ref> <ref name="lipkova">LIPKOVÁ, Helena. Agilní metody vývoje SW. Projektování podnikových informačních systémů [online]. [cit. 2021-07-14]</ref> |
===Sprint backlog=== | ===Sprint backlog=== | ||
− | Jedná se o množinu úkolů vybraných z produktového backlogu včetně plánu dodání produktového přírůstku a splnění cíle sprintu. Backlog sprintu je prognóza vývojového týmu jaká funkcionalita bude dodána v následujícím sprintu a kolik práce bude potřebné k dodání této funkcionality. Ukazuje všechnu práci, kterou si vývojový tým vytýčil jako nezbytnou ke splnění cíle daného sprintu. Backlog sprintu je natolik podrobný, že změny jeho průběhu mohou být sledovány na denní bázi, tj. na Daily Scrumu. <ref name="KSJS">SCHWABER, Ken a SUTHERLAND, Jeff. Průvodce Scrumem - pravidla hry. Scrum Guides [online]. 2014 [cit. 2021-06-20]. Dostupné z: https://scrumguides.org/docs/scrumguide/v1/Scrum-Guide-CS.pdf</ref> | + | Jedná se o množinu úkolů vybraných z produktového backlogu včetně plánu dodání produktového přírůstku a splnění cíle sprintu. Backlog sprintu je prognóza vývojového týmu jaká funkcionalita bude dodána v následujícím sprintu a kolik práce bude potřebné k dodání této funkcionality. Ukazuje všechnu práci, kterou si vývojový tým vytýčil jako nezbytnou ke splnění cíle daného sprintu. Backlog sprintu je natolik podrobný, že změny jeho průběhu mohou být sledovány na denní bázi, tj. na Daily Scrumu. <ref name="KSJS">SCHWABER, Ken a SUTHERLAND, Jeff. Průvodce Scrumem - pravidla hry. Scrum Guides [online]. 2014 [cit. 2021-06-20]. Dostupné z: https://scrumguides.org/docs/scrumguide/v1/Scrum-Guide-CS.pdf</ref> Pokud se nějaký úkol nestíhá, musí se vrátit do Product backlog. Release backlog = seznam dokončených ticketů. <ref name="lipkova">LIPKOVÁ, Helena. Agilní metody vývoje SW. Projektování podnikových informačních systémů [online]. [cit. 2021-07-14]</ref> |
===Definition of Done=== | ===Definition of Done=== | ||
− | Definuje globální podmínky, dle kterých lze určit, zda je položka kompletně zpracována. Je zásadní pro dosažení transparentnosti v agilní praxi a každý produkt nebo systém by měl mít popsanou svou vlastní Definition of Done jako standard pro veškerou svou práci. Scrum tým by neměl začínat pracovat, dokud se společně nedohodne na své Definition of Done. <ref name="BA">BUSCHOVÁ, Ludmila. Zavedení agilní metody Scrum v IT organizaci. Praha: Vysoká škola ekonomie a managementu, Management firem, 2020, 134 s. Vedoucí diplomové práce: doc. Ing. Lucie Vnoučková, Ph.D. [cit. 2021-06-20]. Dostupné z: https://theses.cz/id/wjaxlq/341447_bpdp_final.pdf</ref> | + | Definuje globální podmínky, dle kterých lze určit, zda je položka kompletně zpracována. Je zásadní pro dosažení transparentnosti v agilní praxi a každý produkt nebo systém by měl mít popsanou svou vlastní Definition of Done (DoD)jako standard pro veškerou svou práci. Scrum tým by neměl začínat pracovat, dokud se společně nedohodne na své Definition of Done. <ref name="BA">BUSCHOVÁ, Ludmila. Zavedení agilní metody Scrum v IT organizaci. Praha: Vysoká škola ekonomie a managementu, Management firem, 2020, 134 s. Vedoucí diplomové práce: doc. Ing. Lucie Vnoučková, Ph.D. [cit. 2021-06-20]. Dostupné z: https://theses.cz/id/wjaxlq/341447_bpdp_final.pdf</ref> Nastavuje se při zavádění metodiky obecně, poté se vybírá, co je potřeba pro konkrétní projekt jako DoD. <ref name="lipkova">LIPKOVÁ, Helena. Agilní metody vývoje SW. Projektování podnikových informačních systémů [online]. [cit. 2021-07-14]</ref> |
==Meetingy a aktivity ve Scrumu== | ==Meetingy a aktivity ve Scrumu== | ||
− | Pro kontrolu a adaptaci procesu předepisuje metoda Scrum čtyři formální aktivity, kterými jsou Sprint Planning, Daily Scrum Meeting, Sprint Review a Sprint Retrospective. | + | Pro kontrolu a adaptaci procesu předepisuje metoda Scrum čtyři formální aktivity, kterými jsou Sprint Planning, Daily Scrum Meeting, Sprint Review a Sprint Retrospective. |
− | ===Daily Scrum=== | + | ===Daily Scrum (Daily Stand-up)=== |
− | Jedná se o pravidelnou každodenní schůzku, která probíhá obvykle ráno u Scrum tabule nebo na jiném místě tak, aby členové týmu neseděli na svých pracovních místech, ale naopak stáli. Koná vždy ve stejnou dobu na stejném místě a každý člen Development týmu hovoří o tom, co udělal během předchozího dne, jakou práci bude dělat v aktuální den a případně o překážkách, které mu brání v práci. Celá tato schůzka by měla trvat maximálně 15 minut. | + | Jedná se o pravidelnou každodenní schůzku, která probíhá obvykle ráno u Scrum tabule nebo na jiném místě tak, aby členové týmu neseděli na svých pracovních místech, ale naopak stáli. Koná se vždy ve stejnou dobu na stejném místě a každý člen Development týmu hovoří o tom, co udělal během předchozího dne, jakou práci bude dělat v aktuální den a případně o překážkách, které mu brání v práci. Celá tato schůzka by měla trvat maximálně 15 minut. <ref name="BA">BUSCHOVÁ, Ludmila. Zavedení agilní metody Scrum v IT organizaci. Praha: Vysoká škola ekonomie a managementu, Management firem, 2020, 134 s. Vedoucí diplomové práce: doc. Ing. Lucie Vnoučková, Ph.D. [cit. 2021-06-20]. Dostupné z: https://theses.cz/id/wjaxlq/341447_bpdp_final.pdf</ref> Product Owner se Daily Stand-upů nezúčastňuje. <ref name="lipkova">LIPKOVÁ, Helena. Agilní metody vývoje SW. Projektování podnikových informačních systémů [online]. [cit. 2021-07-14]</ref> |
===Sprint Planning=== | ===Sprint Planning=== | ||
− | Práce, které mají být provedeny v rámci jednoho Sprintu, jsou plánovány na schůzce Sprint Planning, kde plánování provádí celý Scrum tým. Schůzka začíná tím, že Product Owner představí týmu Sprint Goal. Scrum Master | + | Práce, které mají být provedeny v rámci jednoho Sprintu, jsou plánovány na schůzce Sprint Planning, kde plánování provádí celý Scrum tým. Schůzka začíná tím, že Product Owner představí týmu Sprint Goal. Schůzku moderuje Scrum Master. V ideálním případě by měl Sprint Planning probíhat na začátku týdne. Plánování Sprintu je časově omezeno na maximálně osm hodin pro Sprint trvající jeden měsíc a u kratších Sprintů je schůzka obvykle kratší. Se Sprint Planningem souvisí také Backlog Grooming, což je schůzka pro lepší porozumění obsahu Product Backlogu. Backlog Grooming má trvat 30 minut a tým by zde měl řešit problémy, jako jsou nedostatek podrobností nebo chybějící kontextové [[Informace|informace]], které bude potřebovat v následujících dvou sprintech. |
===Sprint Review=== | ===Sprint Review=== | ||
− | + | Je pořádáno po ukončení aktuálního a zároveň před zahájením nového Sprintu. U Sprintů, které trvají jeden měsíc, je Sprint Review zhruba čtyřhodinová schůzka, u kratších Sprintů je událost obvykle kratší. Při této schůzce Development tým demonstruje výsledek své práce. Schůzky se účastní Scrum Master, Product Owner, Development tým, ale také například zákazníci a vývojáři z jiných projekt. | |
===Sprint Retrospective=== | ===Sprint Retrospective=== | ||
− | Po Sprint Review, ale ještě před Sprint Planningem by mělo proběhnout přezkoumání dokončeného Sprintu | + | Po Sprint Review, ale ještě před Sprint Planningem by mělo proběhnout přezkoumání dokončeného Sprintu – Sprint Retrospective. Na tomto setkání by měl Scrum Master pomoci týmu zamyslet se nad získanými zkušenostmi, protože hlavním cílem tohoto setkání je zlepšování skrze získané zkušenosti. Sprint Retrospective poskytuje formální příležitost k zaměření se na kontrolu a adaptaci na úrovni jednotlivých lidí, vztahů, procesů a nástrojů. Sprint Retrospective má standardně několik fází: úvod, sběr [[Data|dat]], hlubší porozumění informacím, [[Brainstorming|brainstorming]] možností a shrnutí konkrétních akcí. <ref name="BA">BUSCHOVÁ, Ludmila. Zavedení agilní metody Scrum v IT organizaci. Praha: Vysoká škola ekonomie a managementu, Management firem, 2020, 134 s. Vedoucí diplomové práce: doc. Ing. Lucie Vnoučková, Ph.D. [cit. 2021-06-20]. Dostupné z: https://theses.cz/id/wjaxlq/341447_bpdp_final.pdf</ref> Sprint Retrospective se již neúčastní Product Owner. <ref name="lipkova">LIPKOVÁ, Helena. Agilní metody vývoje SW. Projektování podnikových informačních systémů [online]. [cit. 2021-07-14]</ref> |
==Odkazy== | ==Odkazy== |
Aktuální verze z 14. 7. 2021, 14:38
Obsah
Agilní metodiky
Agilní metodika (anglicky agile methodology) je pracovní metoda, která spočívá v rozdělení velkých a složitých projektů na malé úkoly, které jsou mnohem rychleji splnitelné. Když pracujeme na menších úkolech, jsme také méně náchylní k rozptýlení, a obecně tento typ práce přináší lepší výkony z hlediska produktivity. [1] Agilní metodika klade důraz na průběžnou komunikaci mezi vývojovým týmem a zákazníkem a také na týmovou spolupráci a samoorganizaci týmu. Dále také klade vyšší důraz na výslednou hodnotu pro zákazníka před dokumenty a papíry. Na změny se nepohlíží negativně, ale jsou vítány jako příležitost býti lepší.
Mezi příklady agilních metodik patří:
SCRUM
SCRUM patří mezi nejpoužívanější metodiku agilního řízení projektu. Vytvořili jej Ken Schwaber a Jeff Sutherland v roce 1990. Název SCRUM v sobě skrývá metaforu s hrou rugby. „Scrumage“, neboli „mlýn“ představuje herní situaci, kdy se shromáždí celý tým a společně se ve mlýně snaží získat a udržet míč. V dané situaci musí celý tým tlačit stejným směrem, což je právě příhodná metafora pro Scrum tým. [3]
Scrum poskytuje vhodný rámec pro řízení jak malých, tak i složitějších projektů prostřednictvím produktových požadavků, každodenních schůzek a retrospektiv. Skládá se z týmů a jejich přidružených rolí, událostí, artefaktů a pravidel. [4]
Vývoj prostřednictvím této metodiky probíhá v tzv. iteracích (sprint), jež obvykle trvají okolo dvou týdnů až jednoho měsíce. Tyto iterace jsou zakončeny setkáním (Sprint Review Meeting), kterého se účastní všechny zainteresované osoby včetně zákazníků, přičemž účast zákazníků není nutně vyžadována. Výstupem každé iterace je funkční prototyp a určení náplně dalšího sprintu. V celém průběhu sprintu probíhají každodenní maximálně patnáctiminutová porada celého vývojového týmu, která slouží k určení dalšího postupu na základě dosavadních výsledků. Výhodou Scrumu je schopnost pružně reagovat na změny vznikající v průběhu projektu. [5]
Charakteristika projektů vedených pomocí metodiky Scrum:
- vývoj v krátkých iteracích (2 až 4 týdny);
- fixní náklady a termíny;
- flexibilní určení výstupů;
- malé týmy;
- časté analýzy rizik a revize;
- velký důraz na komunikaci a spolupráci mezi všemi zúčastněnými (včetně zákazníka). [5]
Základní principy metodiky Scrum
SCRUM vychází ze tří pilířů:
- transparentnost (důležité aspekty procesu musí být viditelné těm, kteří mají vliv na výsledek. Např. všichni účastníci musí používat společný jazyk, kterým popisují proces)
- kontrola (uživatelé Scrumu musí kontrolovat artefakty a postup směrem k cíli tak často, aby se daly odhalit nepřijatelné odchylky v procesu)
- adaptace (jestliže revizor na základě kontroly rozhodne, že jeden nebo více aspektů procesu jsou mimo přijatelné hranice a že výsledný produkt bude nepřijatelný, pak je nutné tento proces adaptovat. Změna musí být provedena co nejdříve, aby byla minimalizována budoucí odchylka.) [6]
Všichni by měli mít jasný přehled o tom, co a proč se dělá a v jakém stavu to je. [3]
Role
Scrum definuje tři role - Scrum Master, Product Owner a Scrum tým.
Scrum Master
Role Scrum Mastera není úplně standardní. Není to manažer, klasický team leader a ani to není nadřízený, je to člen týmu, stejně jako ostatní. Scrum Master pracuje jako spojení mezi týmem a jakýmkoliv rušivým elementem zvenku. Role Scrum mastera je chránit tým a vytvářet prostředí, kde by členy týmu nikdo neměl rušit, podporovat tým, odstraňovat problémy a pomáhat jeho efektivnější práci. [7] Scrum Master má na starosti samotný proces Scrumu — školí principy Scrumu lidem zainteresovaným na projektu, implementuje vhodně Scrum do kultury firmy a kontroluje dodržování pravidel a praktik Scrumu. Náplní jeho práce je odstraňovat překážky, které brání týmu v dosažení maximální efektivity. [8]
Scrum Master by měl být:
- zodpovědný za co nejvyšší efektivitu týmu;
- skromný (stavět zájmy týmu nad své vlastní);
- schopný spolupráce (vytvářet prostředí, kde se členové týmu nebojí klást otázky a kolektivně řešit problémy);
- zavázaný k úspěšnému dokončení Sprintu jako všichni ostatní členové týmu;
- schopný ovlivnit ostatní, jelikož z hlediska Scrumu není nadřízeným týmu a může tak spoléhat pouze na přirozenou autoritu a schopnost moderovat tok diskuse;
- erudovaný, jelikož vedoucí osobnost orientující se v problematice projektu zvyšuje šanci týmu na úspěch. [8]
Product Owner
Product Owner je vlastník produktu, který má určovat priority a rozhoduje o tom, na čem se bude dále pracovat. Má na starosti vizi projektu. Product Owner by měl být týmu pravidelně k dispozici, ale na rozdíl od Scrum Mastera se nemusí tolik starat o potřeby týmu a neustále s ním komunikovat. [7] Představuje zájmy stakeholderů, tedy lidí, kteří bud’ financují projekt, nebo hodlají používat funkcionalitu jím poskytovanou či budou nějakým jiným způsobem projektem ovlivněni. Vlastník produktu je zodpovědný za tvorbu požadavků, návratnost investic (ROI) a plán vydání (release plan). Požadavky jsou zachyceny v artefaktu nazývaném Product backlog. [8]
Scrum tým
Týmová spolupráce je velice důležitá pro agilní vývoj. Ve Scrumu se tým bere jako nedělitelný celek, proto nezáleží na selhání jednoho člena, vždy za vše odpovídají všichni. Tým musí zahrnovat Scrum Mastera, který pomůže vývojovému procesu a komunikaci týmu s vnějším světem a Product Ownera, který ví vše o produktu a určuje směr a priority ve vývoji. [7] Tým je zodpovědný za vyvíjení funkcionality, tedy z hlediska softwaru za tvorbu kódu. Ideální počet členů týmu je obvykle uváděn jako 5–9 osob. Mike Cohn uvádí velmi stručnou poučku: pro velikost týmu: pokud nasytíte tým dvěma pizzami, máte správnou velikost. [8]
Praktiky a artefakty
Reprezentují práci a její hodnoty různými způsoby, které jsou užitečné pro poskytování transparentnosti a dále jsou příležitostí pro kontrolu a adaptaci. [6]
Sprint
Jádrem Scrumu je Sprint – časově ohraničený rámec, během kterého je vytvořen použitelný produktový přírůstek. Každý Sprint začíná plánovací schůzkou – Sprint Planning – během, které se Product Owner a Development tým dohodnou na tom, co přesně bude během sprintu realizováno. Celý Sprint se skládá z plánování Sprintu, denních schůzek, vývojové práce, Sprint Review a retrospektivy Sprintu. Cílem Sprintu není dokončit všechny položky ze Sprint Backlogu, ale dosáhnout stanoveného cíle Sprintu – Sprint Goal. Finální výsledky Sprintu tým prezentuje na Sprint Review.
Sprint Goal
Cíl Sprintu (Sprint Goal), je jednou z nejpodstatnějších částí Scrumu. Je to sada cílů, která je vytvářena během schůzky Sprint Planning a lze jí dosáhnout implementací Product Backlogu. Slouží také ke kontrole pokroku, k řešení rizik, pomáhá stanovit priority, podporuje týmovou práci a umožňuje efektivní rozhodování. [4]
Product backlog
Jedná se o prioritizovaný seznam všeho, co může být potřeba v produktu a je jediným zdrojem požadavků na jakoukoliv změnu v produktu. Product Owner je zodpovědný za obsah, dostupnost a prioritizaci backlogu. Produktový backlog je dynamický a stále se mění tak, aby obsahoval to, co produkt potřebuje. Existuje po dobu existence produktu. Je to vlastně seznam všech vlastností, požadavků, rozšíření a oprav chyb, které představují všechny změny, které budou provedeny v produktu v příštích vydání. Položky v produktovém backlogu mají popis, prioritu (nejvyšší priorita = nejvyšší hodnota pro byznys → nejvíce rozpracované – podklad pro backlog sprintu) a odhad. [6] [9]
Sprint backlog
Jedná se o množinu úkolů vybraných z produktového backlogu včetně plánu dodání produktového přírůstku a splnění cíle sprintu. Backlog sprintu je prognóza vývojového týmu jaká funkcionalita bude dodána v následujícím sprintu a kolik práce bude potřebné k dodání této funkcionality. Ukazuje všechnu práci, kterou si vývojový tým vytýčil jako nezbytnou ke splnění cíle daného sprintu. Backlog sprintu je natolik podrobný, že změny jeho průběhu mohou být sledovány na denní bázi, tj. na Daily Scrumu. [6] Pokud se nějaký úkol nestíhá, musí se vrátit do Product backlog. Release backlog = seznam dokončených ticketů. [9]
Definition of Done
Definuje globální podmínky, dle kterých lze určit, zda je položka kompletně zpracována. Je zásadní pro dosažení transparentnosti v agilní praxi a každý produkt nebo systém by měl mít popsanou svou vlastní Definition of Done (DoD)jako standard pro veškerou svou práci. Scrum tým by neměl začínat pracovat, dokud se společně nedohodne na své Definition of Done. [4] Nastavuje se při zavádění metodiky obecně, poté se vybírá, co je potřeba pro konkrétní projekt jako DoD. [9]
Meetingy a aktivity ve Scrumu
Pro kontrolu a adaptaci procesu předepisuje metoda Scrum čtyři formální aktivity, kterými jsou Sprint Planning, Daily Scrum Meeting, Sprint Review a Sprint Retrospective.
Daily Scrum (Daily Stand-up)
Jedná se o pravidelnou každodenní schůzku, která probíhá obvykle ráno u Scrum tabule nebo na jiném místě tak, aby členové týmu neseděli na svých pracovních místech, ale naopak stáli. Koná se vždy ve stejnou dobu na stejném místě a každý člen Development týmu hovoří o tom, co udělal během předchozího dne, jakou práci bude dělat v aktuální den a případně o překážkách, které mu brání v práci. Celá tato schůzka by měla trvat maximálně 15 minut. [4] Product Owner se Daily Stand-upů nezúčastňuje. [9]
Sprint Planning
Práce, které mají být provedeny v rámci jednoho Sprintu, jsou plánovány na schůzce Sprint Planning, kde plánování provádí celý Scrum tým. Schůzka začíná tím, že Product Owner představí týmu Sprint Goal. Schůzku moderuje Scrum Master. V ideálním případě by měl Sprint Planning probíhat na začátku týdne. Plánování Sprintu je časově omezeno na maximálně osm hodin pro Sprint trvající jeden měsíc a u kratších Sprintů je schůzka obvykle kratší. Se Sprint Planningem souvisí také Backlog Grooming, což je schůzka pro lepší porozumění obsahu Product Backlogu. Backlog Grooming má trvat 30 minut a tým by zde měl řešit problémy, jako jsou nedostatek podrobností nebo chybějící kontextové informace, které bude potřebovat v následujících dvou sprintech.
Sprint Review
Je pořádáno po ukončení aktuálního a zároveň před zahájením nového Sprintu. U Sprintů, které trvají jeden měsíc, je Sprint Review zhruba čtyřhodinová schůzka, u kratších Sprintů je událost obvykle kratší. Při této schůzce Development tým demonstruje výsledek své práce. Schůzky se účastní Scrum Master, Product Owner, Development tým, ale také například zákazníci a vývojáři z jiných projekt.
Sprint Retrospective
Po Sprint Review, ale ještě před Sprint Planningem by mělo proběhnout přezkoumání dokončeného Sprintu – Sprint Retrospective. Na tomto setkání by měl Scrum Master pomoci týmu zamyslet se nad získanými zkušenostmi, protože hlavním cílem tohoto setkání je zlepšování skrze získané zkušenosti. Sprint Retrospective poskytuje formální příležitost k zaměření se na kontrolu a adaptaci na úrovni jednotlivých lidí, vztahů, procesů a nástrojů. Sprint Retrospective má standardně několik fází: úvod, sběr dat, hlubší porozumění informacím, brainstorming možností a shrnutí konkrétních akcí. [4] Sprint Retrospective se již neúčastní Product Owner. [9]
Odkazy
Reference
- ↑ LACORT, Javier. Agilní metodika: O co se jedná a jak ji uplatnit? Welcome to the Jungle [online]. 3. června 2020 [cit. 2021-06-18]. Dostupné z: https://www.welcometothejungle.com/cs/articles/agilni-metodika
- ↑ KOMENDA, Antonín. Agilní metodiky vývoje softwaru. [online]. [cit. 2021-06-18]. Dostupné z: https://cw.fel.cvut.cz/old/_media/courses/a4b33si/prednaskove_materialy/si4-agile.pdf
- ↑ 3,0 3,1 SCRUM – rámec agilního přístupu. PM Consulting - Projektové řízení, změny, agile, management 3.0, týmy [online]. [cit. 2021-06-18]. Dostupné z: https://www.pmconsulting.cz/pm-wiki/scrum/
- ↑ 4,0 4,1 4,2 4,3 4,4 BUSCHOVÁ, Ludmila. Zavedení agilní metody Scrum v IT organizaci. Praha: Vysoká škola ekonomie a managementu, Management firem, 2020, 134 s. Vedoucí diplomové práce: doc. Ing. Lucie Vnoučková, Ph.D. [cit. 2021-06-20]. Dostupné z: https://theses.cz/id/wjaxlq/341447_bpdp_final.pdf
- ↑ 5,0 5,1 Co je agilní metodika Scrum? POTIFOB - Projects On Time In Full On Budget [online]. [cit. 2021-06-18]. Dostupné z: https://potifob.cz/SCRUM
- ↑ 6,0 6,1 6,2 6,3 SCHWABER, Ken a SUTHERLAND, Jeff. Průvodce Scrumem - pravidla hry. Scrum Guides [online]. 2014 [cit. 2021-06-20]. Dostupné z: https://scrumguides.org/docs/scrumguide/v1/Scrum-Guide-CS.pdf
- ↑ 7,0 7,1 7,2 STARASTSINA, Arina. Metodika SCRUM pro malé IT projekty. Brno: Masarykova univerzita, Fakulta informatiky, 2016, 80 s. Vedoucí diplomové práce: RNDr. Jaroslav Ráček, Ph.D [cit. 2021-06-09]. Dostupné z: https://is.muni.cz/th/ppe67/Diplomova_prace_Arina_Starastsina.pdf
- ↑ 8,0 8,1 8,2 8,3 FIANTA, Roman. Použití SCRUM pro menší a střední webové projekty. Brno: Masarykova univerzita, Fakulta informatiky, 2011, 97 s. Vedoucí diplomové práce: RNDr. Jaroslav Ráček, Ph.D [cit. 2021-06-09]. Dostupné z: https://is.muni.cz/th/l98on/dp.pdf
- ↑ 9,0 9,1 9,2 9,3 9,4 LIPKOVÁ, Helena. Agilní metody vývoje SW. Projektování podnikových informačních systémů [online]. [cit. 2021-07-14]
Doporučená literatura
- MYSLÍN, Josef. Scrum: průvodce agilním vývojem softwaru. 1. vydání. Brno: Computer Press, 2016. 167 stran. ISBN 978-80-251-4650-7.
- PRIES, Kim H. Scrum project management [online]. Boca Raton, FL: CRC Press, 2010 [cit. 2021-06-18]. Dostupné z: https://ebookcentral.proquest.com/lib/natl-ebooks/detail.action?docID=589930.
- SCHIEL, James. The ScrumMaster study guide [online]. Boca Raton, Fla.: Auerbach Publications, 2012. Auerbach series on applied software engineering [cit. 2021-06-18]. Dostupné z: https://ebookcentral.proquest.com/lib/natl-ebooks/detail.action?docID=826954.
- ŠOCHOVÁ, Zuzana. Skvělý ScrumMaster. Překlad Milan Daněk. 1. vydání. Brno: Computer Press, 2018. 168 stran. ISBN 978-80-251-4927-0.
- BUCHALCEVOVÁ, Alena. Metodiky budování informačních systémů. Vyd. 1. Praha: Oeconomica, 2009. 205 s. Vysokoškolská učebnice. ISBN 978-80-245-1540-3.
Související články
- Agilní metody projektování. Principy, role, organizace, nástroje
- Metodiky projektového managementu, jejich obsah a smysl
- Řízení lidských zdrojů na projektech, OBS
- Znalostní management a znalosti v organizacích
- Software
Klíčová slova
SCRUM, software, agilní metodiky, řízení projektu, projekt