Skrumáž

Aktuální verze stránky ještě nebyla zkontrolována zkušenými přispěvateli a může se výrazně lišit od verze recenzované 2. září 2022; kontroly vyžadují 27 úprav .

Skrumáž
Oficiální stránka	scrum.org
Mediální soubory na Wikimedia Commons

Scrum ( /skrʌm/ [1] ; scrum „  scrum“) je odlehčený rámec, který pomáhá lidem, týmům a organizacím vytvářet hodnotu prostřednictvím adaptivních řešení složitých problémů [2] .

Scrum najde uplatnění nejen v oblasti vývoje softwaru, ale i v jiných výrobních odvětvích [3] .

Kromě řízení projektů vývoje softwaru může být Scrum také používán týmy softwarové podpory jako přístup k řízení a údržbě vývoje softwaru.

Je třeba rozlišovat mezi Scrum [4] a Agile [5] .

Historie

Primárními zdroji metodiky Scrum byly: produkční systém Toyota a cyklus OODA (smyčka OODA nebo smyčka OODA nebo smyčka Boyd) konceptu využití vojenského letectví, který zahrnuje čtyři složky: pozorovat (“pozorovat”) , orientovat se („orientovat“), rozhodnout („rozhodnout“), jednat („jednat“). [6]

Samotný přístup poprvé popsali Hirotaka Takeuchi a Ikujiro Nonaka v The New Product Development Game (Harvard Business Review, leden–únor 1986). Poznamenali, že projekty řízené malými multidisciplinárními týmy mají tendenci systematicky přinášet lepší výsledky, a vysvětlili to jako „ragbyový přístup“.

V roce 1991 DeGrace a Stahl ve své knize Unholy Problems, Righteous Solutions [7] označili tento přístup jako scrum , což je sportovní termín vytvořený v článku Takeuchiho a Nonaky. Ken Schwaber použil přístup, který přinesl Scrum do jeho společnosti počátku 90. let . Metodologie Scrum byla poprvé představena široké veřejnosti zdokumentovaná, jasně definovaná a popsaná společně Schwaberem a Jeffem Sutherlandem [6] na OOPSLA'95 [8] v Austinu . K. Schwaber a D. Sutherland spolupracovali v průběhu dalších let na zpracování a popisu všech svých zkušeností a osvědčených postupů pro průmysl do jednoho celku, v metodologii, která je dnes známá jako Scrum.

Schwaber spojil své síly s Mikem Beadle v roce 2001 , aby metodu podrobně popsal v Agile Software Development with Scrum [9] .

V roce 2002 Schwaber spolu s dalšími založil Scrum Alliance [10] a vytvořil řadu certifikovaných Scrum akreditací. Schwaber opustil Scrum Alliance na konci roku 2009 a založil Scrum.org Archived 10. prosince 2019 ve Wayback Machine , který je kurátorem řady souběžných akreditací Professional Scrum [11] .

Od roku 2009 oficiálně definuje Scrum veřejný dokument s názvem The Scrum Guide [12] . Byl revidován více než 5krát. V roce 2018 Schwaber a komunita Scrum.org spolu s lídry z komunity Kanban zveřejnili Kanban Guide for Scrum Teams [13] .

Definice

Scrum

Scrum (angl. „scrum“ – výraz z ragby, označuje výchozí stav týmů před vhozením míče) – minimální požadovaná sada událostí, artefaktů, rolí, na kterých je postaven proces vývoje Scrumu, umožňující pevné krátké časové úseky. času, nazývané sprinty ( sprinty ), s cílem poskytnout koncovému uživateli fungující produkt s novými obchodními příležitostmi, pro které je určena nejvyšší priorita. Metodika je založena na myšlenkách vyjádřených v článku Taekuchiho a Nonaky " The New New Product development Game ", stejně jako na týmové práci, podobné tomu, jak v ragby tým spolupracuje na dosažení společného cíle. Příležitosti pro implementaci v dalším sprintu určí tým na začátku sprintu na Sprint Planning Meeting . K odhadu nadcházejícího množství práce ve sprintu se nejčastěji používají relativní odhady a praxe plánování pokeru (Planning Poker).

Na konci sprintu se Scrum tým sejde na sprint review meetingu (Sprint Review – starý název Demonstration) se zákazníkem a předloží mu přírůstek obchodního produktu (verze produktu s kompletní sadou funkcí, které mohou již předána zákazníkovi a uživateli k použití), což se jí podařilo ve sprintu. Cílem Sprint Review je získat zpětnou vazbu od zákazníka, abyste pochopili, na co je třeba v budoucnu klást důraz a jaký by měl být další přírůstek obchodního produktu.

Přísně pevná krátká doba trvání sprintu (od 1 do 4 týdnů) snižuje rizika a umožňuje rychle získat zpětnou vazbu od zákazníka za účelem úpravy vize produktu.

Sprint

Sprint [14]  je časový úsek dostatečný k dokončení plánovaného souboru operací Scrumu, jehož účelem je vytvořit přírůstek obchodního produktu. Pevně ​​opraveno v čase. Délka jednoho sprintu je od 1 do 4 týdnů. Čím kratší je sprint, tím flexibilnější je vývojový proces, verze vycházejí častěji, zpětná vazba od zákazníka přichází rychleji, méně času se stráví prací špatným směrem, ale hodně času se stráví schůzkami o plánování sprintu, retrospektivy . Na druhou stranu při delších sprintech Scrum Team snižuje náklady na schůzky, předvádění produktů atd. Různé týmy volí délku sprintu podle specifik své práce, mezifunkčních týmů a požadavků, často zkušební a chyba. Chcete-li odhadnout množství práce ve sprintu, můžete použít předběžný odhad měřený v bodech příběhu. Předběžný odhad délky sprintu je zaznamenán v projektovém backlogu ( product backlog ; viz níže).

Artefakty Scrumu

Burndown chart

Graf, který ukazuje množství odvedené práce a množství práce, které zbývá ve vztahu k času na vývoj projektu, se nazývá vyhořelý graf.

Tyto grafy je třeba denně aktualizovat, aby v reálném čase ukazovaly pokrok a náklady v práci na sprintu a projektu a jsou k dispozici všem členům týmu Scrum: Scrum Master a Product Owner.

Graf vyhoření sprintu ukazuje, kolik úkolů bylo dokončeno a kolik zbývá udělat v aktuálním sprintu.

Nevyřízené projekty

Protokol přání projektu (project backlog) obsahuje seznam požadavků na funkčnost, seřazený podle důležitosti, a podle toho pořadí implementace. Položky v tomto protokolu se nazývají uživatelské příběhy ( uživatelské příběhy ) nebo nevyřízené položky ( nevyřízené položky ). Backlog projektu je otevřen pro editaci pro všechny účastníky procesu Scrum. Osoba odpovědná za udržování projektového backlogu je vlastníkem produktu Scrum.

Nevyřízený sprint

Sprint Wishlist (Sprint Backlog) – obsahuje funkcionalitu vybranou vlastníkem produktu z projektového backlogu. Všechny funkce jsou rozděleny do úkolů, z nichž každý je hodnocen Scrum týmem. Na schůzce plánování sprintu používá tým plánovací pokerovou metodu k odhadu množství práce, kterou je třeba vykonat k dokončení sprintu [15] .

Scrum deska

Scrum Board je nástroj k otevřenému předvedení stavu probíhající práce Scrum týmu. Scrum board se skládá ze tří sloupců: „to do“ ( to-do ), „in progress“ ( in progress ), „done“ ( done ).

Scrum Board obsahuje celý rozsah Backlogu sprintu, který tým vybral v Plánování sprintu pro implementaci v aktuálním sprintu. Karty obchodních úkolů jsou obvykle umístěny na tabuli shora dolů v sestupném pořadí priority (nahoře – nejdůležitější, dole – nejméně důležité). Je dobrou praxí rozložit obchodní úkoly na konkrétní práci (technickou, organizační a další), kterou tým potřebuje k realizaci obchodního úkolu.

Obchodní úkoly a konkrétní pracovní karty se přesouvají ze sloupce do sloupce podle toho, jak je tým vezme k provedení (Probíhá) a dokončuje (Hotovo). Aby byl zajištěn přehled o postupu práce týmu, je v grafu vyhoření zobrazeno „úbytek práce“ po dnech.

Nejčastěji na začátku práce týmy používají desky s flipcharty nakreslenými na listech, přičemž názvy prací jsou napsány na nalepovací samolepky a nalepeny na tabuli. Jak schůzka postupuje, tým fyzicky přesouvá poznámky ze sloupce do sloupce.

Často se také používají elektronické desky, v nichž jsou implementovány podobné mechanismy. Například Atlassian Jira , Trello nebo kaiten [16] .

Cíl sprintu

Je to stručný popis obchodního cíle sprintu. Cíl sprintu jako artefakt pomáhá týmu činit informovaná obchodní rozhodnutí. Tento artefakt je nezbytný pro to, aby se projektový tým mohl nezávisle rozhodnout při hledání alternativních způsobů řešení obchodního problému.

Přírůstek produktu

Produktový přírůstek je kus produktu připravený k použití, který musí být implementován do konce sprintu. Tým Sprint Review (Demonstration) předvádí přírůstek produktu Scrum Masterovi, Product Ownerovi, zákazníkům a dalším zainteresovaným stranám [4] , aby od nich získal zpětnou vazbu a rozhodl se o dalším směřování vývoje produktu [17] .

Uživatelský příběh

Požadovaná obchodní funkčnost, která je přidána do nevyřízeného projektu, se často označuje jako uživatelský příběh. Struktura příběhu je často: "Jako uživatel <typ uživatele> chci provést <akci>, abych získal <výsledek>." Tato struktura je výhodná, protože je jasná jak vývojářům, tak zákazníkům.

Odhad úsilí potřebného k dokončení uživatelského příběhu (úkoly sprintu)

Sutherland v knize [6] popsal následující jím používanou a zkušenostmi potvrzenou účinnou metodu hodnocení pracnosti plnění sprintových úkolů v některých jednotkách pracnosti - člověkohodinách a podobně.

Vyhodnocení úkolů provádějí vývojáři projektu společně se Scrum Masterem a Product Ownerem. Správnou metodou pro odhadování úkolů je plánování pokeru . Ukazuje se, že takové hodnocení pracovního vstupu je mnohem přesnější než hodnocení prováděné jinými lidmi.

Každý vývojář musí dát své vlastní posouzení složitosti úkolu, nezávisle na ostatních, pomocí čísel z Fibonacciho řady (1, 2, 3, 5, 8, 13, 20, 40, 100). Místo čísel 21, 34, 55 se používají čísla 20, 40, 100. Odhady lze zaznamenat na papírky, případně k tomu použít speciální kartičky (viz plánovací poker ) a je třeba je zároveň otevřít . Tato organizace hodnocení zabrání efektu ukotvení .

Pokud všechny hodnoty zvolené vývojáři spadají do intervalu nejvýše tří po sobě jdoucích Fibonacciho čísel, pak se jako konečné hodnocení úkolu skupinou použije průměrný odhad všech vývojářů ve skupině. Pokud zvolené skóre spadá mimo tento interval, pak vývojáři s nejvyšší a nejnižší hodnotou musí vysvětlit důvody své volby, načež se hodnotící kola opakují, dokud sada odhadů nespadne do intervalu tří po sobě jdoucích Fibonacciho čísel. Jak ukazuje praxe, použije-li se pro sestavení konečného odhadu složitosti úlohy varianta s průměrováním odhadů ležících v intervalu větším než tři po sobě jdoucí Fibonacciho čísla, pak se výsledek ukazuje jako mnohem méně přesný.

Ačkoli jsou zpočátku úkoly, a tedy i příběhy a projekt jako celek, odhadnuty v určité jednotce pracovního vstupu, tyto odhady jsou následně použity jako relativní pracovní vstup jako body (body) k určení rychlosti (produktivity) práce. tým Scrum (Velocity).

Je samozřejmé, že výše uvedenou metodiku hodnocení pracnosti jednotlivých úkolů a projektu jako celku lze využít nejen ve Scrumu, ale i v jiných způsobech realizace projektu.

Definice Hotovo (DoD)

Kritéria, která určují připravenost položky z nevyřízených položek uživatele.

Rychlost týmu Scrum (Velocity)

Celkový počet bodů, které tým Scrum získal v předchozím sprintu. Tato metrika pomáhá týmu pochopit, kolik příběhů může dokončit v jednom sprintu.

Role v procesu Scrum

Podle metodiky Scrum ve výrobním procesu je možné definovat role, rozdělené do dvou skupin: „prasata“ a „kuřata“. Od roku 2011 v manuálu Scrum chybí metafory „prasata“ a „kuřata“, protože pro kuřata neexistují žádné speciální rituály [18] . Průvodce Scrum je o prasatech. Tyto termíny byly vypůjčeny z anekdoty: [6]

Prase jde po silnici. Kuře se na ni podívá a říká: "Otevřeme restauraci!" Prase se podívá na kuře a odpoví: "Dobrý nápad, jak tomu chceš říkat?" Kuře se zamyslí a řekne: "Proč tomu neříkat Slanina a vejce?" "To nepůjde," odpovídá prase, "protože se pak budu muset plně věnovat projektu a vy se zapojíte jen částečně."

Prasata vytvářejí produkt, zatímco kuřata mají zájem, ale ne takový zájem - protože jim je jedno, jestli je projekt úspěšný nebo ne, moc je to neovlivní. Požadavky, přání, nápady a vliv kuřat jsou brány v úvahu, ale není jim dovoleno být přímo zapojeni do průběhu projektu Scrum.

Klíčové role v metodologii Scrum („prasata“)

Prasata jsou plně zahrnuta do projektu a do procesu Scrum. Scrum Master - vede porady (Scrum meetingy), sleduje dodržování všech principů Scrumu, řeší konflikty a chrání tým před rušivými vlivy, usnadňuje schůzky, odpovídá za evidenci, ukládání a vydávání inventáře Scrumu. Tato role neznamená nic jiného než správné vedení procesu Scrum. Scrum Master je tedy služebným vůdcem .

Hlavním nástrojem Scrum mastera je kufr facilitátora , který obsahuje krabičky na karty, čtvercové a kulaté karty, lepicí karty, špendlíky, fixy, kancelářský nůž, lepicí pásku , karty Planning Poker, magnety, nůžky, hlasovací body.

Scrum Product Owner - Zastupuje zájmy koncových uživatelů a dalších zainteresovaných stran v produktu .

Vývojový tým (Scrum Development Team) je multifunkční tým projektových vývojářů složený ze specialistů různých profilů: testeři , architekti , analytici , programátoři atd. Velikost týmu je od 5 do 9 lidí. Tým je jediným plně zapojeným účastníkem vývoje a odpovídá za výsledek jako celek. Nikdo jiný než vývojový tým, scrum master a produktový vlastník nemůže během sprintu zasahovat do vývojového procesu. Vzájemná funkčnost týmu vám umožňuje plánovat náklady na implementaci obchodních požadavků co nejefektivněji a dodávat reálné podnikové aplikace plně v souladu s měnícími se požadavky zákazníků v krátkém čase.

Scrum tým je ve skutečnosti kolektivním obrazem týmu skládajícího se z vývojového týmu, scrum mastera a produktového vlastníka. Tým je zcela soběstačný a není závislý na externích specialistech ani zákaznících.

Další role (vedlejší role) v metodologii Scrumu ("Kuře")

• Uživatelé (Uživatelé)
• Stakeholdery jsou jednotlivci, kteří projekt iniciují (firemní zákazníci) a pro které bude projekt Scrum přínosem. Jsou zapojeni do boje pouze během setkání Sprint Review.

Příběhy uživatelů

Povinná pole

• ID  - jedinečný identifikátor, sériové číslo používané k identifikaci příběhů v případě, že jsou přejmenovány.
• Jméno (Jméno)  - stručný popis děje. Mělo by být jednoznačné, aby vývojáři, Scrum Master i Product Owner pochopili, o co jde, a odlišili jeden uživatelský příběh od druhého.
• Důležitost  - míra důležitosti tohoto příběhu, podle vlastníka produktu, získaná jako výsledek jednání se zákazníkem. Obvykle je to celé číslo, někdy se pro tento účel používají Fibonacciho čísla . Čím větší hodnota, tím vyšší priorita.

• Obchodní proces  – stručný popis obchodního procesu.
• Počáteční odhad  – odhad množství práce vykonané před začátkem sprintu potřebné k implementaci příběhu. Měřeno v příběhových bodech. Přibližně odpovídá počtu "ideálních člověkohodin ".
• How to demo  - stručný popis, jak na konci sprintu předvést zákazníkovi, Scrum Masterovi a Product Ownerovi splněný úkol. Toto pole může obsahovat název (identifikátor) nebo kód automatického testu pro akceptační test.
• Kritéria přijetí  jsou významné detaily implementace příběhu, objasňující požadavky vlastníka produktu, shromážděné všemi členy Scrum týmu při plánování sprintu [19] .

Další pole

Někdy se také používají další pole v projektovém backlogu, hlavně proto, aby pomohli vlastníkovi produktu upřednostnit produkt.

• Kategorie ( stopa ). Například „ovládací panel“ nebo „optimalizace“. Pomocí tohoto pole může produktový vlastník snadno vybrat všechny položky v kategorii „optimalizace“ a nastavit jim nízkou prioritu.
• Komponenty ( komponenty ) – označuje, které komponenty (například databáze, server, klient) budou ovlivněny při implementaci uživatelského příběhu.
• Iniciátor požadavku ( žadatel ). Vlastník produktu může chtít ukládat informace o všech zákaznících, kteří se zajímají o daný obchodní problém. Je to proto, aby byli informováni o postupu práce během sprintu.
• ID v systému sledování závad ( bug tracking ID ) - pokud se při vývoji používá samostatný systém sledování chyb , je v tomto případě užitečné ukládat do popisu historie odkazy na všechny chyby, které se toho týkají.

Hlavní setkání Scrum

Následující schůzky slouží ve Scrumu k dosažení pravidelnosti, kontroly vývoje a zároveň k minimalizaci počtu schůzek, které nejsou ve Scrumu předdefinovány [20] .

Schůze plánování sprintu

Koná se na začátku každého sprintu.

Na této schůzce je naplánováno veškeré množství práce, která musí být během sprintu dokončena. Plán by měl být výsledkem práce všech členů Scrum týmu.

Délka schůzky je dána délkou sprintu, zkušenostmi týmu a dalšími faktory, neměla by však přesáhnout 8 hodin. Tyto časové osy sleduje ScrumMaster.

Schůzka plánování sprintu odpovídá na otázky jako:

• Co je cílem tohoto sprintu, nebo co lze v tomto sprintu udělat?
• Jak přesně bude dosaženo cíle sprintu, abyste získali produktový přírůstek?

O první otázce se rozhoduje společně. Product Owner diskutuje o cílech, které mají být splněny pro sprint, s ohledem na produktový backlog, předchozí produktový přírůstek atd., přidává nové uživatelské příběhy do backlogu a odstraňuje dokončené. Vývojový tým se snaží předpovědět funkcionalitu, která bude během sprintu vyvinuta. Všichni členové Scrum týmu by také měli společně pochopit a zhodnotit veškerou práci nadcházejícího sprintu.

Chcete-li správně naplánovat sprint, zvažte následující:

• Nevyřízené projekty;
• Předchozí přírůstek projektu;
• Předpokládaný potenciál vývojového týmu během sprintu;
• Minulé výsledky vývojového týmu.

S druhou otázkou pracuje pouze vývojový tým. Protože cíl sprintu již byl definován, vývojový tým musí přesně pochopit, jak jej lze dosáhnout. Rozhodnou se, jak zavedou plánovanou funkcionalitu, aby získali nový přírůstek hotového produktu na sprint.

Vývojový tým obvykle začíná návrhem systému a prací potřebnou k převedení backlogu sprintu na produktový přírůstek. Práce plánovaná na první dny sprintu je podrobnější, často se ke konci schůzky rozděluje na kusy jednoho dne nebo méně. Vývojový tým nezávisle organizuje práci v backlogu sprintu, a to jak během plánování sprintu, tak podle potřeby během sprintu.

S přihlédnutím k názoru vývojového týmu může Product Owner ujasnit vybrané úkoly-cíle z backlogu nebo s nimi vytvořit kompromisní řešení. Pokud vývojáři usoudí, že práce je příliš mnoho nebo příliš málo, pak mohou oni a produktový vlastník přehodnotit vybrané úkoly-cíle. Vývojový tým může také pozvat další odborníky, aby poskytli technické nebo věcné rady.

Na konci setkání vývojový tým vysvětlí vlastníkovi produktu a Scrum Masterovi, jak budou pracovat nezávisle na dosažení cílů sprintu.

Denní setkání Scrum

Tyto schůzky pořádá vývojový tým za případné účasti produktového vlastníka a Scrummastera každý den na stejném místě a ve stejnou dobu, netrvají déle než 15 minut. Na těchto schůzkách vývojový tým plánuje práci na dnešní pracovní den. Tyto schůzky zjednodušují týmovou práci a zvyšují produktivitu tím, že prověřují práci, která byla vykonána od předchozího Daily Scrum, a plánují práci, která bude před námi.

Tato každodenní setkání pomáhají vidět, jak práce postupuje směrem k dosažení cíle sprintu. Zvyšují pravděpodobnost, že vývojový tým splní stanovené cíle. Během schůzek by vývojový tým měl pochopit, jak by se měl společně organizovat, aby dosáhl cílů sprintu a realizoval plánovaný přírůstek.

Strukturu takových schůzek určuje vývojový tým, v případě potřeby a je-li to vhodné, může být struktura schůzek změněna, přičemž hlavní důraz by měl být kladen na dosažení cíle sprintu, nicméně existují závazná pravidla:

• Denní Scrum by neměl být delší než 15 minut;

• Daily Scrum se koná každý pracovní den, Daily Scrum pass není povolen;

• Příklady otázek, které lze v Daily Scrum zvážit:

• • Co jsem včera udělal, co pomohlo vývojovému týmu dosáhnout cíle ve sprintu?

• • Co dnes udělám, abych pomohl vývojovému týmu dosáhnout cíle sprintu?

• • Vidím nějaké překážky, které mně nebo vývojovému týmu brání v dosažení cíle sprintu?

Vývojový tým nebo členové týmu se často setkávají bezprostředně po denním scrumu k hlubším diskusím nebo k přizpůsobení či přeplánování zbytku práce.

Scrum Master garantuje tato setkání, ale vývojový tým je zodpovědný za provoz Daily Scrum. Scrum Master také školí vývojový tým, aby udržoval denní Scrum do 15 minut a musí zajistit, aby schůzka nebyla narušena.

Účelem takových schůzek je zlepšit týmovou komunikaci, snížit počet dalších schůzek, identifikovat budoucí rizika a potíže a usnadnit rychlé rozhodování.

To je hlavní prostředek kontroly práce vývojového týmu.

Sprint recenze

Provádí se na konci sprintu pro kontrolu přírůstku produktu a v případě potřeby upraví backlog. Během hodnocení výsledků sprintu se účastní Scrum tým a všechny zainteresované strany. Cílem tohoto neformálního setkání a prezentace přírůstku je získat zpětnou vazbu a rozvíjet spolupráci.

Souhrnná kontrola sprintu obsahuje následující prvky:

• Produktový vlastník ukazuje, které položky nevyřízeného záznamu byly dokončeny a které ne.
• Vývojový tým diskutuje o tom, co šlo dobře, co bylo obtížné a jak byly vyřešeny.
• Vývojový tým předvádí práci, kterou dokončil ve sprintu, a jaký produktový přírůstek obdržel.
• Produktový vlastník diskutuje o aktuálním stavu nevyřízené položky. Na základě dosaženého výsledku také předpovídá pravděpodobné cíle a termíny.
• Na základě analýzy trhu a/nebo potenciálního publika se diskutuje o tom, co je nejhodnotnější udělat dál.
• Kontrola časové osy, rozpočtu, příležitostí a trhu k doplnění nevyřízeného stavu.

Výsledkem je aktualizovaný backlog, který definuje cíle pro další sprinty. Nevyřízené položky lze upravit jako celek tak, aby vyhovovaly novým příležitostem.

Retrospektivní setkání (Sprint Retrospective)

Účelem retrospektivního setkání je vypracovat návrhy na zlepšení procesu (postupy, techniky, operace) realizace projektu. V průběhu retrospektivní analýzy minulého sprintu se vytváří plán na zlepšení procesu implementace projektu pro další sprint. Setkání se koná po přezkoumání výsledků sprintu před plánováním dalšího sprintu a nemělo by trvat déle než 3 hodiny. Dohlíží na průběh setkání Scrum Master.

Hlavní cíle setkání jsou:

• Analýza posledního dokončeného sprintu z hlediska lidí, procesů a nástrojů.
• Identifikace hlavních efektivních rozhodnutí pro zlepšení procesu implementace projektu přijatých pro poslední sprint a hledání způsobů, jak je dále zlepšit.
• Tvorba implementačního plánu, zlepšení procesu implementace projektu Scrum týmem.

Scrum Master povzbuzuje tým, aby poskytoval návrhy na zlepšení efektivity vývojového procesu. Během každé retrospektivy sprintu by měl tým hledat a navrhovat způsoby a prostředky ke zlepšení pracovních procesů.

Na konci ohlédnutí za sprintem by měl tým identifikovat návrhy na zlepšení pro implementaci v příštím sprintu. Zatímco takové návrhy lze implementovat kdykoli, retrospektiva sprintu poskytuje příležitost zaměřit se na analýzu interakcí týmu a jeho přizpůsobení aktuálním podmínkám.

Zrušení sprintu

Sprint lze zrušit, pokud je cíl sprintu zastaralý. Pouze Product Owner má právo zrušit sprint [21] .

Další schůzky Scrum

Tyto schůzky nemusí být součástí celkového pracovního postupu Scrumu, ale v některých situacích se určitě konají. Používají se, když je více než 7-11 vývojářů, tedy více, než je doporučená velikost týmu Scrum.

Scrum of Scrums

Pokud je tým více než 11 lidí, pak je tým větší než doporučená velikost Scrumu. Scrum of Scrums [22] byl navržen k rozšíření Scrum .

Poté je tým rozdělen do několika Scrum týmů. Každý má svého Scrum Mastera a Product Ownera.

Týmy provádějí Daily Scrum.

Po každodenním setkání Scrum následuje shromáždění Scrum of Scrums (SoS [23] ). To znamená následující. Z každého týmu je vybrán zástupce. Zástupci jsou rozděleni do 5-9 osob. Každému týmu je přidělen hlavní Scrum Master [24] a Chief Scrum Product Owner [25] z řad Scrum Masterů a Product Ownerů zapojených do projektu. Tým zástupců různých Scrum týmů se nazývá Scrum of Scrums Team [26] . V tomto složení se koná 15minutový stálý rally Scrum of Scrums (SoS) nebo Meta Scrum nebo Scaled Daily Scrum (SDS) [27] .

Ken Schwaber doporučuje provádět Scrum of Scrums každý den [28] .

Některé Scrum of Scrums týmy však nedělají každý den, ale 2-3x týdně [28] . To porušuje základní principy Scrumu a je to klasický příklad Scrumu [29] [30] . To vám neumožňuje plně využít výhod Scrumu [31] .

Scrum of Scrums umožňuje více Scrum týmům diskutovat o práci se zaměřením na společné oblasti a vzájemnou integraci. Hlavní Scrum Master položí všem členům týmu Scrum of Scrum čtyři otázky [28] , přičemž první tři otázky opakují otázky Daily Scrum:

• Co udělal každý tým od předchozího setkání Scrum of Scrums, aby dosáhl cíle sprintu?
• Co udělá každý tým do příštího denního setkání Scrum of Scrums, aby dosáhl cíle ve sprintu?
• Existují nějaké problémy, které brání týmu v dosažení cíle sprintu?
• Musí druhý tým udělat něco z úkolů vašeho týmu, aby mu pomohl dosáhnout cíle sprintu?

Pomocí metodiky Scrum of Scrums můžete počet vývojářů nadále zvyšovat. Pokud Scrum of Scrums nepokrývá celý tým, může se setkat Scrum of Scrum of Scrum (Scrum-3, SoSoS) [32] , Scrum of Scrum of Scrum of Scrum (Scrum-4, SoSoS [33] ) [34] a tak dále [35] . Nejnovější MetaScrum se nazývá Executive Meta Scrum (EMS) [36] nebo Executive Action Team (EAT) [37] . Tento přístup umožňuje zorganizovat práci 4096 lidí za pouhou hodinu [34] .

Pořadí scrumu scrumů je stejné jako u denního scrumu [26] :

• ve stejnou dobu, na stejném místě,
• každý se může dívat, ale mluví jen „prasata“,
• hlavní Scrum Master, Chief Scrum Product Owner a Scrum of Scrums Team se účastní rally,
• trvá přesně 15 minut
• stojí všichni účastníci Scrum of Scrums (Daily Standup rally).

Řazení nevyřízených položek (grooming)

Nevyřízené položky jsou organizovány tak, aby vývojový tým a vlastník produktu mohli [38] :

• Přidejte, odeberte, slučujte nebo rozdělujte elementy produktového backlogu (PBI), rozložte elementy backlogu na elementy úloh na úrovni programování.
• Vyjasněte nebo uveďte nové odhady složitosti úkolů atd.
• Změňte pořadí položek nevyřízených produktů.
• Diskutujte a vyjasněte obchodní požadavky.

Další scrum škálovací techniky

Kromě klasické metodiky Scrum of Scrums (SoS), LeSS [39] [40] [41] [42] (od 2 do 8 týmů), Nexus [43] , RAGE [44] , DAD [45] , APM [46] ] [47] , SAFe [48] . U velmi velkých projektů se místo LeSS používá LeSS Huge [40] (8+ příkazů) . Pouze metody SoS [49] a Nexus [50] byly vyvinuty Sutherlandem a Schwaberem [40] a jsou vyučovány v certifikačních kurzech CSM a PSM.

Školení a certifikace Scrum

Ve Scrumu hrají klíčovou roli kvalifikovaný Scrum Master, Scrum Product Owner a Scrum Team. Zakladatelé a certifikovaní trenéři Scrumu (CST®) poskytují školicí kurzy k certifikaci profesionálů Scrumu. Povinným základem pro všechny jsou dovednosti Scrum Mastera. Dále přichází specializace na Scrum Master, Scrum Product Owner a Scrum Developer (člen Scrum týmu). Těm, kteří úspěšně složí zkoušku, jsou vydány certifikáty: Certified ScrumMaster (CSM®), Certified Scrum Product Owner (CSPO®), Certified Scrum Developer (CSD®), Professional Scrum Master (PSM™), Professional Scrum Product Owner (PSPO™) , Professional Scrum Developer (PSD™). Ti, kteří si chtějí dále zlepšovat znalosti a dovednosti Scrumu, mohou po základních kurzech CSM, CSPO od Scrum ALLIANCE a složení zkoušky na nich, kteří mají alespoň 1 rok praxe ve své roli Scrum, absolvovat Advanced Certified Scrum Master (A -CSM), Advanced Certified Scrum Product Owner, Advanced Certified Scrum Developer [51] . Pro vývojáře existuje samostatná sada kurzů souvisejících s TDD , DevOps atd. [52] . Ti, kteří absolvovali kurzy CSM, CSPO, CSD, A-CSM, A-CSPO, A-CSD a složili zkoušky a mají alespoň 3 roky zkušeností v příslušné roli Scrum, mohou absolvovat CSP®-SM, CSP® -PO kurzy, CSP-D® [53] . V rámci certifikace scrum.org mají kurzy také několik úrovní: PSM-I, PSM-II, PSM-III, PSPO-I, PSPO-II, PSPO-III [54] .

Další školení je možné po vydání certifikátu Scrum trenéra - Certified Scrum Trainer (CST®) nebo Professional Scrum Trainer (PST ™).

Certifikace CST je otevřena jednotlivcům s certifikací CSP-SM nebo CSP-PO nebo CSP-D a alespoň 5 let zkušeností v příslušné roli Scrum [55] .

Certifikace PST uznává trenéry Scrum Master Trainers (PSSMT), Product Owner Trainers (PSPOT) a trenéry vývojových týmů (PSDT) [56] [57] [58] . Přijetí a certifikace školitele (TTT) vyžaduje:

• na certifikát PSSMT - PSM III;
• na PSPOT - certifikáty PSM I a PSPO I;
• na certifikátech PSDT - PSM I a PSD I.

Certifikace Scrum je platná dva roky. Během těchto dvou let, aby bylo možné obnovit certifikát na další dva roky, musí být přijat určitý počet jednotek Scrum Education Unit (SEU®) [59] . Jednotky Scrum Education Unit se udělují za absolvování kurzů Scrum, účast na Global Scrum Gathering℠ [60] a Regional Scrum Gathering℠ [61] , výuku Scrumu a další aktivity zaměřené na zlepšení vašich dovedností Scrum [59] . Takový systém ukazuje, že vaše znalosti Scrumu jsou aktuální a jste vždy připraveni je aplikovat a předávat ostatním. To výrazně zvyšuje hodnotu certifikátu Scrum. Jednotky Scrum Education Unit se udělují následovně: 1 hodina školení Scrum (účast na shromáždění, výuka, účast na webináři atd.) se rovná 1 SEU®. Obnovení certifikátu vyžaduje:

• CSM®, CSPO®, CSD® - 20 SEU®;
• A-CSM®, A-CSPO®, A-CSD® - 30 SEU®;
• CSP®-SM, CSP®-PO, CSP-D®, CAL II-40 SEU®.

Pokud je certifikátů více, počet SEU® potřebných pro obnovu se vypočítá pomocí speciální kalkulačky: [62] .

Ne přesně Scrum

Scrumbut

ScrumBut je použití pouze části principů Scrumu při zachování přesvědčení pracovat na Scrumu [29] [30] . Nejen, že vám to brání v plném využití výhod Scrumu [29] , ale také to snižuje výkon ve srovnání s úplnou absencí metodiky.

Studie ukázaly, že ScrumBut snižuje roční zisky ze 400 % na 0–35 % [31] . Zároveň byla produktivita práce podle „vodopádu“ brána jako 100% a podle Scrumu jako 400%. Rozsáhlá studie příčin a důsledků ScrumBut je provedena v práci „ScrumBut in Professional Software Development“ [63] .

Klasické příklady ScrumBut [29] :

• Provádění Daily Scrum nebo Scrum of Scrums není každý den;
• Nedostatek retrospektiv;
• Sprinty delší než 4 týdny;
• Nedostatek definice Hotovo.

Velké množství příkladů ScrumBut je uvedeno na webu Scrum Alliance, Scrum ALLIANCE® [64] .

Scrum And

Kromě ScrumBut zvažte ScrumAnd [65] . Předpokládá se, že ScrumAnd používá Scrum a další osvědčené postupy. Může však být obtížné odlišit ScrumBut od ScrumAnd [66] . Například se ptají: máme sprint 6 měsíců, je to ScrumBut nebo ScrumAnd? Autoři [66] to jednoznačně připisují ScrumBut a poskytují metodu pro rozlišení mezi ScrumBut a ScrumAnd. Je třeba si uvědomit, že metodika Scrum je soběstačná a jak ScrumBut, tak ScrumAnd vedou ke snížení efektivity procesu vývoje obchodních aplikací. [67] .

Poznámky

1. ↑ "scrum" anglicko-ruský překlad . lingvo.abbyyonline.com. Staženo: 4. května 2016. (neurčitý)
2. ↑ Schwaber Ken, Sutherland Jeff. Scrum Guide (listopad 2020). (Ruština)
3. ↑ Archivovaná kopie . Získáno 19. října 2018. Archivováno z originálu dne 20. října 2018. (neurčitý)
4. ↑ 1 2 5 klíčových nástrojů metody SCRUM (27. dubna 2017). Získáno 21. října 2018. Archivováno z originálu dne 2. října 2019. (neurčitý)
5. ↑ Agile - agilní přístup k řízení projektů (4. 11. 2016). Získáno 21. října 2018. Archivováno z originálu 3. října 2019. (neurčitý)
6. ↑ 1 2 3 4 Jeff Sutherland. SKRUMÁŽ. Revoluční metoda projektového řízení = SCRUM. Umění udělat dvakrát tolik práce za poloviční čas. - Mann, Ivanov a Ferber, 2016. - 288 s. - ISBN 978-5-00057-722-6 .
7. ↑ Leslie Hulet Stahl: Wicked Problems, Righteous Solutions: A Catalog of Modern Engineering Paradigms Yourdon Press Computing Series, 1990 (první vydání), ISBN 0-13-590126-X
8. ↑ OOPSLA 2006 . Datum přístupu: 26. ledna 2010. Archivováno z originálu 25. června 2010. (neurčitý)
9. ↑ Schwaber, Ken; Beedle, Miku. Agilní vývoj softwaru s Scrum  (neopr.) . - Prentice Hall , 2002. - ISBN 0-13-067634-9 .
10. ↑ Maximini, Dominik. Kultura scrumu: Zavádění agilních metod v organizacích. Management pro profesionály  // Cham: Springer. - 8. ledna 2015. Staženo 25. srpna 2016 .. - S. 26 . — ISSN 9783319118277 .
11. ↑ Partogi, Joshua. Certifikovaný Scrum Master vs Professional Scrum Master // Lean Agile Institute. — 7. července 2013. Staženo 10. května 2017.
12. ↑ Ken Schwaber; Jeff Sutherland. Průvodce scrumem. — Scrum.org, Staženo 27. října 2017..
13. ↑ Scrum.org představuje Scrum s kurzem Kanban, který umožňuje větší transparentnost mezi vývojovými týmy (staženo 2. března 2018). Staženo 22. 5. 2019. Archivováno z originálu 18. 11. 2018. (neurčitý)
14. ↑ Sprint - trhnutí; házet; krátký běh.
15. ↑ Ken Schwaber. Agilní řízení projektů se Scrumem . - Microsoft Press, 2004. - 163 s. — ISBN 073561993X .
16. ↑ Vizuální projektový a týmový management @ Kaiten . Získáno 15. března 2021. Archivováno z originálu dne 22. ledna 2021. (neurčitý)
17. ↑ Co je Scrum - Agile pro začátečníky . Získáno 20. října 2018. Archivováno z originálu 21. října 2018. (neurčitý)
18. ↑ Kuřata a prasata . Získáno 23. července 2019. Archivováno z originálu 23. ledna 2017. (neurčitý)
19. ↑ Kritéria přijetí pro požadavky v Agile . Devprom ALM. Staženo 3. dubna 2016. Archivováno z originálu 1. dubna 2016. (neurčitý)
20. ↑ Průvodce scrum | Průvodci scrumu . scrumguides.org. Staženo 3. června 2020. Archivováno z originálu dne 16. června 2020. (neurčitý)
21. ↑ Archivovaná kopie . Získáno 15. března 2021. Archivováno z originálu dne 14. ledna 2021. (neurčitý)
22. ↑ (PDF) Řešení Scrum of Scrum pro velké týmy využívající metodologii Scrum . Získáno 21. října 2018. Archivováno z originálu 21. října 2018. (neurčitý)
23. ↑ Scrum of Scrums (SoS) Definice | inovace . Získáno 21. října 2018. Archivováno z originálu 21. října 2018. (neurčitý)
24. ↑ Role hlavního Scrum Mastera | Blog SCRUMstudy . Získáno 21. října 2018. Archivováno z originálu 25. října 2018. (neurčitý)
25. ↑ Endava . Získáno 21. října 2018. Archivováno z originálu 21. října 2018. (neurčitý)
26. ↑ 1 2 Setkání Scrum of Scrums - Manifest . Získáno 21. října 2018. Archivováno z originálu 21. října 2018. (neurčitý)
27. ↑ Jeff Sutherland spouští průvodce Scrum@Scale | Blog Henny Portman . Získáno 21. října 2018. Archivováno z originálu 21. října 2018. (neurčitý)
28. ↑ 1 2 3 Informační články předložené členy Scrum Alliance (odkaz není k dispozici) . Získáno 21. října 2018. Archivováno z originálu 21. října 2018. (neurčitý) 
29. ↑ 1 2 3 4 Co je ScrumBut? | Scrum.org . Získáno 21. října 2018. Archivováno z originálu 21. října 2018. (neurčitý)
30. ↑ 1 2 ITKaiZenClub „Scrum, ale...“ aneb typické problémy při implementaci Scrumu, 8. února | DOU
31. ↑ 1 2 (PDF) Scrum+:: Je to "ScrumBut" nebo "ScrumAnd" . Získáno 21. října 2018. Archivováno z originálu 21. října 2018. (neurčitý)
32. ↑ Scrum tým a Scrum of Scrums . Získáno 21. října 2018. Archivováno z originálu 21. října 2018. (neurčitý)
33. ↑ Agilní organizace se Scrum@Scale, Vimar Spa skutečným příkladem
34. ↑ 1 2 Agilní ve vojenském hardwaru. Jak se SAAB Gripen stal nákladově nejefektivnějším vojenským letadlem na světě Archivováno 20. října 2018 na Wayback Machine / Sutherland a Joe Justice , 2017 
35. ↑ Scaling Agile Series Část 2: Pohled na dva ze čtyř populárních agilních škálovacích rámců: SoS a LeSS - Gorilla Logic . Získáno 21. října 2018. Archivováno z originálu 21. října 2018. (neurčitý)
36. ↑ Výkonný MetaScrum | AgileGenesis . Získáno 15. března 2021. Archivováno z originálu dne 18. dubna 2021. (neurčitý)
37. ↑ Výkonný akční tým – Scrum Inc. Získáno 15. března 2021. Archivováno z originálu dne 28. února 2021. (neurčitý)
38. ↑ "Hledám Backlog Comb Blog of Proactive Business (odkaz není k dispozici) . Datum přístupu: 8. prosince 2018. Archivováno 27. prosince 2018. (neurčitý) 
39. ↑ Large-Scale Scrum (LeSS) – Alexey Krivitsky – Agile Coach and Scrum Trainer . Staženo 2. listopadu 2018. Archivováno z originálu dne 4. listopadu 2018. (neurčitý)
40. ↑ 1 2 3 Jak škálovat Agile? | otevřené systémy. DBMS | Nakladatelství "Otevřené systémy" . Staženo 2. listopadu 2018. Archivováno z originálu dne 4. listopadu 2018. (neurčitý)
41. ↑ Úvod do LeSS - Large Scale Scrum (LeSS) . Staženo 4. listopadu 2018. Archivováno z originálu 5. listopadu 2018. (neurčitý)
42. ↑ LeSS - Scrum at scale - ScrumTrek Blog . Staženo 4. listopadu 2018. Archivováno z originálu 5. listopadu 2018. (neurčitý)
43. ↑ Průvodce zařízením Nexus | Scrum.org . Staženo 4. listopadu 2018. Archivováno z originálu 5. listopadu 2018. (neurčitý)
44. ↑ RAGE | Škálované agilní transformace | proces | cPrime . Staženo 4. listopadu 2018. Archivováno z originálu 4. listopadu 2018. (neurčitý)
45. ↑ Archivovaná kopie (odkaz není dostupný) . Staženo 4. listopadu 2018. Archivováno z originálu 5. listopadu 2018. (neurčitý) 
46. ↑ Agilní projektové řízení – co a proč | APM . Staženo 4. listopadu 2018. Archivováno z originálu 5. listopadu 2018. (neurčitý)
47. ↑ Agilní řízení projektů pomocí Scrumu . Staženo 4. listopadu 2018. Archivováno z originálu 5. listopadu 2018. (neurčitý)
48. ↑ Archivovaná kopie (odkaz není dostupný) . Staženo 4. listopadu 2018. Archivováno z originálu 5. listopadu 2018. (neurčitý) 
49. ↑ Scrum of Scrums | Scrum.org . Staženo 2. listopadu 2018. Archivováno z originálu dne 4. listopadu 2018. (neurčitý)
50. ↑ Průvodce zařízením Nexus | Scrum.org . Staženo 2. listopadu 2018. Archivováno z originálu 5. listopadu 2018. (neurčitý)
51. ↑ Pokročilá certifikace ScrumMaster (A-CSM℠) . Získáno 15. března 2021. Archivováno z originálu dne 17. března 2021. (neurčitý)
52. ↑ Hledání kurzu – Scrum Alliance
53. ↑ Certified Scrum Professional Certifikační kurz ScrumMaster® (CSP-SM) . Získáno 15. března 2021. Archivováno z originálu dne 17. března 2021. (neurčitý)
54. ↑ Certifikace Scrum Master z domova Scrumu . Získáno 15. března 2021. Archivováno z originálu dne 3. března 2021. (neurčitý)
55. ↑ Proces žádosti o certifikaci Certified Scrum Trainer (CST) . Získáno 19. října 2018. Archivováno z originálu dne 20. října 2018. (neurčitý)
56. ↑ Proces výběru a aplikace trenéra PSD | Scrum.org . Získáno 19. října 2018. Archivováno z originálu dne 20. října 2018. (neurčitý)
57. ↑ Proces výběru školitelů PSPO a aplikace | Scrum.org . Získáno 19. října 2018. Archivováno z originálu dne 20. října 2018. (neurčitý)
58. ↑ Proces výběru a aplikace trenéra PSM | Scrum.org . Získáno 19. října 2018. Archivováno z originálu dne 20. října 2018. (neurčitý)
59. ↑ 1 2 Kredity Scrum Education Units® (SEU®) za školení . Získáno 15. března 2021. Archivováno z originálu dne 20. dubna 2021. (neurčitý)
60. ↑ Informace o akci Global Scrum Gathering a sponzorství . Získáno 15. března 2021. Archivováno z originálu dne 4. března 2021. (neurčitý)
61. ↑ Regionální shromáždění Scrum Alliance . Získáno 15. března 2021. Archivováno z originálu dne 28. ledna 2021. (neurčitý)
62. ↑ Školení a certifikace Agile a Scrum | Scrum Aliance . Získáno 15. března 2021. Archivováno z originálu dne 21. dubna 2021. (neurčitý)
63. ↑ Archivovaná kopie . Získáno 21. října 2018. Archivováno z originálu 21. října 2018. (neurčitý)
64. ↑ Informační články předložené členy Scrum Alliance (odkaz není dostupný) . Získáno 21. října 2018. Archivováno z originálu 21. října 2018. (neurčitý) 
65. ↑ Postoj "ScrumAnd" (vyžaduje přemýšlení a disciplínu) | Scrum.org . Získáno 15. března 2021. Archivováno z originálu dne 14. dubna 2021. (neurčitý)
66. ↑ 1 2 (PDF) Scrum+:: Je to „ScrumBut“ nebo „ScrumAnd“ . Získáno 21. října 2018. Archivováno z originálu 21. října 2018. (neurčitý)
67. ↑ https://www.researchgate.net/publication/254048455_Scrum_Is_it_ScrumBut_or_ScrumAnd

Viz také

• Implementace softwaru

Odkazy

• Oficiální kniha pravidel Scrumu archivována 9. září 2012 na Wayback Machine
• Přehled metodiky Scrumu Archivováno 14. března 2016 na Wayback Machine

Literatura

• Henrik Kniberg. Scrum a XP: poznámky z předních linií = Scrum a XP ze zákopů. - C4Media, 2007. - S. 140. - ISBN 978-1-4303-2264-1 .
• Mike Cohn. Scrum: Agile Software Development = Uspět s Agile: Software Development pomocí Scrumu. - M. : "Williams" , 2011. - S. 576. - ISBN 978-5-8459-1731-7 .
• Jeff Sutherland. SKRUMÁŽ. Revoluční metoda projektového řízení = SCRUM. Umění udělat dvakrát tolik práce za poloviční čas. - Mann, Ivanov a Ferber, 2016. - 288 s. - ISBN 978-5-00057-722-6 .
• Kenneth Rubin. Essential Scrum: Praktický průvodce nejoblíbenějším agilním procesem. - M. : "Williams" , 20161. - S. 544. - ISBN 978-5-8459-2052-2 .

V bibliografických katalozích	J9U : 987007534934605171 LCCN : sh2001003039

Vývoj softwaru
Proces	Vývojové fáze Analýza požadavků Design Programování Testování Dokumentace
Koncepty na vysoké úrovni	Softwarová architektura Paradigma Metodologie Vývojový proces Kvalitní
Pokyny	Programování ( Aspect Oriented Objektově orientovaný orientovaný na problém )
Vývojové metodiky	Agilní čistý pokoj PŘÍPAD NAHORU. RUP Otevřít RAD Skrumáž Bezpečný Model Spotify Lékaři bez hranic XP DSDM
Modelky	Iterativní kaskádové Spirála Model V Model Dual Vee CMM CMMI Data funkční model IDEF Informační Metamodel objektový model zobrazit model UML
Pozoruhodné postavy	Kent Beck Gradi Butch Fred Brooks Ward Cunningham Ole-Johan Dahl Tom Demarco Edsger Dijkstra Donald Knuth Alan Kay Martin Fowler Anthony Hoare Ivar Jacobson Bertrand Meyer Niklaus Wirth Edward Jordan Steve McConnell James Rambo Barry Boehm Humphrey Michael A. Jackson Craig Larman Robert Martin James David Parnas Winston Royce