Toto je objekt systému MBI.

MBI (Management Byznys Informatiky) je portál obsahující zobecněná řešení v řízení provozu a rozvoje IT, resp. podnikové informatiky.

Pokud máte zájem získat více informací o tomto objektu (vazby na další objekty, přílohy, apod.), ale i získat mnoho dalších užitečných materiálů, můžete tak učinit ZDE / (registrace je bezplatná).

Metoda : Large Scale Scrum (LeSS)
Large Scale Scrum (LeSS)
Kód metody

Standarní kód metody v MBI

:
M531
Popis, obsahové vymezení

Obsahové vymezení metody - rekapitulace základních principů ve vztahu k řízení informatiky

1. Large Scale Scrum (LeSS) - celková charakteristika

1.1. Koncepce LeSS

LeSS je zkratkou pro Large Scale Scrum. Tato metodika umožňuje využít principy Scrumu, štíhlého a agilního vývoje ve velkých skupinách produktů. Jeho tvůrci jsou Craig Larman a Bas Vodde (LeSS, 2016). Jak sami autoři poznamenávají, LeSS není nový a vylepšený Scrum, je to prostě Scrum. Jedná se především o implementaci principů, prvků a účelu Scrumu v kontextu větších projektů.

1.2. Základní principy metodiky LeSS
  • Empirická kontrola procesu – prozkoumání a adaptace produktu, procesů, organizačního návrhu a praktik k vytvoření situačně vhodné organizace založené na Scrumu, spíše než následování předného vzorce. Empirická kontrola procesu vyžaduje a vytváří transparentnost.
  • Transparentnost – založená na hmotných „hotových“ částech, krátkých cyklech, spolupráce, obecných definicích a odstranění strachu z pracoviště.
  • Více s méně – za prvé, empirická kontrola procesů zajišťuje více učení s méně definovanými procesy, za druhé ve štíhlém uvažování přináší větší přidanou hodnotu s méně zbytečnostmi a režijními náklady, za třetí, ve škálování podporuje více účasti, účelu a radosti s méně rolemi, artefakty a specializovanými skupinami.
  • Koncentrace na celostní produkt – jeden backlog, jeden product owner, jeden pontecionálně doručitelný produkt, jeden sprint. To vše bez ohledu na počet týmů. Zákazník chce produkt, ne jeho část.
  • Soustředění se na zákazníka – je nutné identifikovat hodnotu a odpad z pohledu zákazníka. Toho se dá dosáhnout redukcí času cyklu z jeho perspektivy, častějším získáváním jeho zpětné vazby a pochopením všech členů týmu, jak se jejich dnešní práce vztahuje k platícímu zákazníkovi.
  • Neustálé zlepšování k dokonalosti – vytváření a dodávání produktu vždy, bez chyb, který vyhovuje zákazníkovi, zlepšuje životní prostředí a dělá život lepším. Sprinty by měly vždy vést k podstatnému zlepšování.
  • Systémové uvažování – optimalizace, porozumění a pozorování celého systému (ne jen jeho částí) a zkoumání dynamiky systému. Je nutné se vyhnout lokálním optimalizacím, které se soustřeďují na efektivitu a produktivitu jedinců nebo jednotlivých týmů. Zákazníky zajímá obecný čas cyklu od konceptu po peníze a jejich tok, ne jednotlivé kroky.
  • Štíhlé uvažování – vytvoření organizačního systému, který je založen manažerech jako učitelích, kteří učí systémové a štíhlé uvažování a snaží se o zlepšení. Všechny snahy by měly směřovat k dokonalosti a měly by být založeny na pilířích respektu k lidem a neustálého zlepšování.
  • Teorie front – porozumění tomu, jak se systémy s frontami chovají v prostředí vývoje, a aplikace těchto vhledů na řízení velikosti fronty, limitů právě zpracovávaných úkolů, multitaskingu, pracovních balíčků a variability.

1.3. Fáze LeSS

LeSS má obecně stejné fáze jako Scrum s některými rozdíly, a to (LeSS, 2016):

  • Plánování sprintu, část 1 – s product ownerem se schůzky účastní všichni členové všech týmů. Samořízené týmy by se měly samy rozhodnout, jak si rozdělí části produktového backlogu. Členové týmů mezi sebou diskutují příležitosti, aby našli sdílenou práci a spolupracovali na souvisejících úkolech.
  • Plánování sprintu, část 2 – tato část se uskutečňuje nezávisle, často paralelně, v každém týmu.
  • Denní Scrum – je organizovaný nezávisle každým týmem, i když někteří členové týmu A se mohou jako pozorovatel účastnit mítinku týmu B.
  • Koordinace – pro zlepšení sdílení informací a lepší koordinaci mohou týmy nebo jejich zástupci organizovat různé typy společných schůzek.
  • Obecný PBR – dobrovolná a krátká PBR (Product Backlog Refinement) schůzka zahrnuje product ownera a všechny členy všech týmů. Základním účelem je rozhodnout, které týmy implementují jaké části produktového backlogu, a vybrat tak užší selekci pro týmový hloubkový PBR. Je to také příležitost prohloubit vztahy mezi product ownerem a členy týmů.
  • Product Backlog Refienement – stejně jako ve Scrumu jednoho týmu, v LeSSu se předpokládá PBR jednoho týmu. Možností je také multitýmový PBR, kdy je v jedné místnosti více týmů, aby se usnadnila koordinace a zlepšilo sdílení informací.
  • Vyhodnocení sprintu – účastní se ho product owner, zástupci každého týmu a relevantní zákazníci či uživatelé, případě další stakeholdeři. Doporučuje se uspořádání po vzoru trhu, tzn. v jedné velké místnosti je několik oddělení, ve kterých se diskutují jednotlivé součásti produktu.
  • Obecná retrospektiva – ve Scrumu tato schůzka není. Jejím účelem je prozkoumat zlepšení celkového systému, místo koncentrace na jeden konkrétní tým. Maximální délka trvání je 45 minut na týden sprintu. Účastní se jí product owner, ScrumMaster a rotující zástupci z každého týmu.

Pro praktickou část jsou důležité zejména následující principy metodiky LeSS.

1.4. Area product owner (APO, vlastník produktu pro danou oblast)

Area product owner (APO, vlastník produktu pro danou oblast) se specializuje na oblast kolem zákazníka a jedná jako vlastník produktu ve vztahu k týmům v této oblasti. APO se věnuje stejným úkolů jako vlastník produktu, ale je více omezený, i když jeho hlavním cílem je zákazník (LeSS, 2016). Vztah mezi vlastníkem produktu a APO je znázorněn na obrázku .

Několik APOs a vlastník produktu dohromady tvoří tým (tým vlastníka produktu). Tento tým přijímá rozhodnutí o prioritizaci napříč produktem, ale konečné rozhodnutí je vždy na vlastníkovi produktu, stejně jako rozhodnutí o rozsahu a plánování. Týmy jsou rozděleny do oblastí požadavku na základě priorit. Oblasti jsou různých velikostí ve smyslu náročnosti a tak obsahují různý počet týmů. Příliš malé oblasti se neosvědčují, protože jejich výsledkem je příliš velký počet APOs a backlogů. Příliš velké oblasti jsou na druhou stranu velmi zatěžující pro jednoho APO. Ideálním počtem jsou minimálně čtyči a maximálně 10 týmů na jednu oblast (LeSS, 2016).

Hlavním důvodem pro zavedení role APO je zamezit tomu, aby byl vlastník produktu přetížen. V případě, že by žádný APO v týmu nebyl, musel by vlastník produktu řídit příliš mnoho týmů, produktový backlog by se stal příliš velkým a týmy by byly příliš obecně orientované a neschopné si vytvořit vlastní specializaci.

1.5. Multifunkční týmy

Základem metodiky LeSS jsou samořízené a multifunkční týmy. Samořízené týmy si sami rozhodují o tom, jak budou pracovat. Proto je ale nutné vytvořit správné prostředí. Přechod na samořízené týmy znamená změnu klasické role manažera z řízení na vytváření tohoto prostředí. Multifunkční (cross-functional) týmy jsou definovány jako skupina lidí s jasným účelem, který reprezentuje více funkcí nebo disciplín ve společnosti, jejichž kombinované úsilí je nezbytné k dosažení účelu týmu (Parker, 2003). Z definice vyplývá, že týmy ve Scrum jsou multifunkční. Jejich členové se věnují produktovému marketingu (vlastník produktu), vývoji software a testování. Takové týmy odstraňují organizační překážky mezi vývojem a testováním a umisťují tyto činnosti do jednoho týmu. Všechny klíčové funkce zahrnuté v projektu jsou součástí multifunkčního týmu, obvykle se jedná minimálně o inženýring, marketing a samotnou výrobu (LeSS, 2016).

1.6. Zpřesňování produktového backlogu

Zpřesňování produktového backlogu (product backlog refinement) je nutné v rámci každého sprintu, aby se jednotlivé položky backlogu upřesnily pro budoucí sprinty. Klíčovými aktivitami jsou rozdělení velkých položek, upřesnění položek do té doby, než jsou hotové a odhadování (LeSS, 2016). Stejný zdroj doporučuje nestrávit nad zpřesňováním více než 10 % času vyhrazeného na sprint. Většinou se tato činnost provádí uprostřed daného sprintu.

1.7. Plánování sprintu, část 1

Plánování sprintu, část 1 (Sprint Planning One) se soustřeďuje na výběr hotových úkolů z těch, které byly nabídnuté vlastníkem produktu, uzavřením nezodpovězených otázek a definicí cíle sprintu (LeSS, 2016). Mělo by jít o relativně rychlou a jednoduchou schůzku. To může být dosaženo tím, že se omezí počet účastníků, vlastník produktu prezentuje úkoly s nejvyšší prioritou, týmy si rozdělí úkoly mezi sebe a diskutují se nezodpovězené otázky.

1.8. Plánování sprintu, část 2

(Sprint Planning Two) se zabývá vytvářením plánu činností tak, abych se stihla zpracovat každá položka backlogu určená pro daný sprint (LeSS, 2016). Tato část plánování je stejná pro všechny týmy. Schůzka může probíhat pro několik týmů v jedné místnosti tak, aby bylo možné sdílet zkušenosti, znalosti a koordinovat činnosti.