Škálování agilního přístupu pro velké týmy

Slova velká a agilní se často nepoužívají ve stejné větě. Velké organizace získaly pověst pomalého pohybu. To se ale mění. Mnoho velkých softwarových organizací úspěšně provádí transformaci na agilní. Učí se škálovat agilní principy s oblíbenými frameworky, jako jsou SAFe, LeSS nebo Nexus.

V Microsoftu jedna taková organizace používá metodu Agile k vytváření služeb a produktů dodávaných pod hlavičkou Azure DevOps. Tato skupina má 35 funkčních týmů, které nasazují do produkce jednou za tři týdny.

Každý tým v Rámci Azure DevOps vlastní funkce od začátku do konce i mimo ni. Oni vlastní vztahy se zákazníky. Spravují vlastní backlog produktů. Zapisují a kontrolují kód do produkční větve. Každé tři týdny se nasadí produkční větev a vydání se stane veřejným. Týmy pak monitorují stav systému a řeší problémy v produkčním prostředí.

Podle agilních principů jsou autonomní týmy produktivnější. Agilní organizace chce, aby týmy měly kontrolu nad každodenním prováděním. Ale autonomie bez zarovnání by vedlo k chaosu. Desítky týmů pracujících nezávisle by nevytvářely jednotný, vysoce kvalitní produkt. Sladění dává týmům svůj účel a zajišťuje, aby splňovaly cíle organizace. Bez sladění by dokonce i nejlepší týmy selhaly.

Pokud chcete agilní škálování, musíte týmu povolit autonomii a současně zajistit soulad s organizací.

Aby bylo možné spravovat citlivou rovnováhu mezi sladěním a autonomí, musí vedoucí pracovníci DevOps definovat taxonomii, definovat proces plánování a používat chaty s funkcemi.

Definování taxonomie

Agilní tým a větší agilní organizace, k níž patří, potřebují jasně definovaný backlog, aby byly úspěšné. Týmy budou mít potíže uspět, pokud nejsou jasné organizační cíle.

Aby bylo možné stanovit jasné cíle a uvést, jak k nim každý tým přispívá, musí organizace definovat taxonomii. Jasně definovaná taxonomie vytváří nomenklaturu pro organizaci.

Běžnou taxonomií jsou epiky, vlastnosti, příběhy a úkoly.

Eposy

Epiky popisují iniciativy důležité pro úspěch organizace. Epiky mohou trvat několik týmů a několik sprintů, ale mají svůj konec. Epiky mají jasně definovaný cíl. Po dosažení je epos uzavřen. Počet probíhajících epik by měl být zvládnutelný, aby se organizace mohla soustředit. Epické úkoly jsou rozdělené na funkce.

Features

Funkce definují nové funkce potřebné k realizaci cíle námětu. Funkce jsou jednotkou verzování; představují to, co je vydáno zákazníkovi. Publikované poznámky k verzi je možné sestavit na základě seznamu funkcí, které byly nedávno dokončeny. Dokončení funkcí může trvat více sprintů, ale měly by být navrženy tak, aby zajišťovaly konzistentní tok hodnoty pro zákazníka. Funkce jsou rozdělené do scénářů.

Scénáře

Scénáře definují přírůstkovou hodnotu, kterou tým musí dodat k vytvoření funkce. Tým tuto funkci rozdělí na inkrementální části. Jeden dokončený text nemusí zákazníkovi poskytnout smysluplnou hodnotu. Dokončený scénář ale představuje software v produkční kvalitě. Příběhy jsou pracovní jednotkou týmu. Tým definuje scénáře potřebné k dokončení funkce. Volitelně se scénáře rozdělí do úkolů.

Tasks

Úkoly definují práci potřebnou k dokončení scénáře.

Iniciativy

Tato taxonomie není univerzálním systémem. Mnoho organizací zavádí úroveň nad epickými příběhy označovanou jako iniciativy.

Názvy jednotlivých úrovní se dají přizpůsobit vaší organizaci. Názvy definované výše (epiky, funkce, příběhy) se však v softwarovém průmyslu běžně používají.

Linie autonomie

Jakmile je taxonomie nastavená, musí organizace nakreslit čáru autonomie. Hranice samostatnosti je bod, ve kterém vlastnictví úrovně přechází od vedení k týmu. Správa nezasahuje do úrovní, které vlastní tým.

Následující příklad ukazuje linii autonomie nakreslenou pod jejich funkcemi. Správa vlastní náměty a funkce, které poskytují sladění. Týmy vlastní scénáře a úkoly a mají autonomii nad tím, jak se provádějí.

V tomto příkladu vedení týmu neřekne, jak dekompilovat scénáře, plánovat sprinty nebo provádět práci.

Tým ale musí zajistit, aby jejich provádění odpovídalo cílům vedení. I když tým vlastní svůj backlog scénářů, musí svůj backlog sladit s funkcemi, které jim byly přiřazeny.

Planning

Pro škálování agilního plánování potřebuje tým plán pro každou úroveň taxonomie. Je ale důležité iterovat a aktualizovat plán. Tento proces se nazývá plánování postupné vlny.

Plán poskytuje směr pro pevné časové období s očekávanou kalibrací v pravidelných intervalech. Například plán 18 měsíců může být kalibrován každých šest měsíců.

Tady je příklad plánování metod pro každou úroveň taxonomie: náměty, funkce, scénáře, úkoly.

Vize

Vize se vyjadřuje prostřednictvím epik a která nastavuje dlouhodobý směr organizace. Epiky definují, co chce organizace dokončit v příštích 18 měsících. Management vlastní plán a kalibruje ho každých šest měsíců.

Vize je prezentována na celofiremní schůzce. Vzhledem k tomu, že vize má být ambiciózní a v daném časovém období se může hodně měnit, očekáváme, že dosáhnete přibližně 60% vize.

Období

Sezóna je popsána prostřednictvím funkcí a nastavuje strategii pro příštích šest měsíců. Funkce určují, co chce organizace svým zákazníkům zvýraznit. Management vlastní sezónní plán a prezentuje vizi a sezónní plány na všeobecné schůzi. Všechny týmové plány musí být v souladu se sezónním plánem vedení. Očekáváme, že dosáhnete přibližně 80% sezónního plánu.

Plán sprintů (3)

Plán 3 sprintu definuje scénáře a funkce, které tým dokončí během dalších tří sprintů. Tým vlastní plán a upravuje ho každý sprint. Každý tým prezentuje svůj plán správy prostřednictvím chatu funkcí (viz níže). Plán určuje, jak se provádění týmu shoduje se 6měsíčním sezónním plánem. Očekáváme, že dosáhnete přibližně 90% plánu 3 sprintů.

Plán sprintu

Plán sprintu definuje scénáře a funkce, které tým dokončí v dalším sprintu. Tým vlastní plán sprintu a pošle ho celé organizaci, aby byl plně transparentní. Plán zahrnuje to, co tým v minulém sprintu dosáhl, a jeho zaměření na další sprint. Očekáváme, že dosáhnete přibližně 95% plánu sprintu.

Linie autonomnosti

V tomto příkladu je nakreslená linie autonomie, která ukazuje, kde týmy mají plánovací autonomii.

Jak je uvedeno výše, vedení nerozšiřuje vlastnictví pod hranici autonomie. Správa poskytuje pokyny prostřednictvím plánů vize a období a pak dává týmům autonomii při vytváření plánů pro tři sprinty a jednotlivé sprinty.

Chaty o funkcích: Kde se autonomie setkává s kompatibilitou

Schůzka o vlastnostech je neformální schůzka, kde každý tým prezentuje svůj třísprintový plán vedení. Tato schůzka zajišťuje, aby týmové plány odpovídaly cílům organizace. Pomáhá také udržet si přehled o tom, co tým dělá. Zatímco plán 3 sprintů se kalibruje každý sprint, chaty o funkcích se konají podle potřeby, obvykle jednou až třikrát za sprinty.

Schůzka zaměřená na funkce chatu přidělí každému týmu 15 minut. S 12 funkčními týmy je možné tyto schůzky naplánovat tak, aby trvaly přibližně tři hodiny. Každý tým připraví výčet o 3 snímcích s následujícími uspořádáními:

Features

První snímek popisuje funkce, které tým zpřístupní v následujících třech iteracích.

Dluh

Další snímek popisuje, jak tým spravuje technický dluh. Dluh je cokoli, co nesplňuje standardy kvality vedení. Ředitel technického oddělení nastavuje standardy jakosti, které jsou sjednocené pro všechny týmy (zajednocení). Mezi příklady ukazatelů kvality patří počet chyb na inženýra, procento úspěšných jednotkových testů a výkonnostní cíle.

Problémy a závislosti

Mezi problémy a závislosti uvedené na posledním snímku patří cokoli, co má vliv na průběh týmu, například problémy, které tým nedokáže vyřešit nebo závislosti na jiných týmech, které potřebují eskalaci.

Každý tým prezentuje snímky přímo ke správě. Tým představuje, jak plán 3 sprintů odpovídá 6měsíčnímu sezónnímu plánu. Vedení se ptá na objasnění otázek a navrhuje změny ve směru. Mohou také požádat o následné schůzky, aby vyřešili hlubší problémy.

Pokud se plán týmu nepodaří sladit s očekáváními vedení, může vedení požádat o opětovné plánování. V takovém vzácném případě připraví a naplánuje tým druhou diskusi o funkcionalitě, aby ji přezkoumal.

Důvěra: To lepidlo, které drží zarovnání a autonomii pohromadě

Při praktikování Agile ve velkém měřítku je důvěra obousměrný proces.

• Vedení musí důvěřovat týmům, aby udělaly správnou věc. Pokud vedení týmům nedůvěřuje, nebudou týmům poskytovat autonomii.

• Tým získá důvěru tím, že konzistentně dodává vysoce kvalitní kód. Pokud týmy nejsou důvěryhodné, správa jim neudělí autonomii.

Vedení musí poskytnout jasné plány, s nimiž se týmy sladí, a pak svěřit svým týmům jejich realizaci. Týmy musí sladit plány s organizací a spouštět důvěryhodným způsobem.

Vzhledem k tomu, že organizace hledají agilní škálování na větší scénáře, je klíčem poskytnout týmům autonomii a zároveň zajistit, aby byly v souladu s organizačními cíli. Důležité stavební bloky jsou jasně definované vlastnictví a kultura důvěryhodnosti. Jakmile má organizace tuto základnu, zjistí, že agilní funkce může velmi dobře škálovat.

Další kroky

Je mnoho způsobů, jak může tým libovolné velikosti začít vidět výhody již dnes. Podívejte se na některé z těchto postupů, které se škálují.

Seznamte se s funkcemi Azure DevOps pro správu portfolia a viditelnosti napříč týmy.

Microsoft je jednou z největších agilních společností na světě. Přečtěte si další informace o tom, jak Microsoft škáluje plánování DevOps.