SCRUM

Stránka ve výstavbě

Na této stránce se právě pracuje. Prosím needitujte tuto stránku, dokud na ní zůstává tato šablona. Předejdete tak editačnímu konfliktu. Jestliže uběhla od poslední editace doba alespoň dvou dnů, neváhejte tuto šablonu odstranit.

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. 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ří:

• Extrémní programování,
• SCRUM
• Crystal Clear
• Adaptivní vývoj
• Feature Driven Development atd.

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.

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.

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.

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).

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.)

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.

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ý teamleader 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. 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.

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.

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. 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.

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. 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.

Praktiky a artefakty

Proces řízení projektu

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.

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í.

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. Vlastník produktu 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 a odhad.

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.

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.

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

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.

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 schůzku moderuje. 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

Ke 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, 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í 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 Retrospectivemá standardně několik fází: úvod, sběr dat, hlubší porozumění informacím, brainstorming možností a shrnutí konkrétních akcí.

Odkazy

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