Š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 architekturami, jako jsou SAFe, LeSS nebo Nexus.

V Microsoftu jedna taková organizace používá agilní k vytváření produktů a služeb odeslaných pod značkou Azure DevOps. Tato skupina má 35 týmů funkcí, které se vydávají do produkčního prostředí každé tři týdny.

Každý tým v Rámci Azure DevOps vlastní funkce od začátku do konce i mimo ni. 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 verze se stane veřejnou. Týmy pak monitorují stav systému a opravují problémy s živými weby.

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, do které patří, potřebuje jasně definovaný backlog, aby bylo úspěšné. Týmy se budou snažit 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 náměty, funkce, scénáře a úkoly.

Náměty

Náměty popisují iniciativy důležité pro úspěch organizace. Náměty můžou k dosažení několika týmů a několika sprintů trvat, ale nejsou bez konce. Náměty mají jasně definovaný cíl. Po dosažení je námět uzavřen. Počet probíhajících námětů by měl být spravovatelný, aby se organizace mohla soustředit. Náměty jsou rozdělené na funkce.

Funkce

Funkce definují nové funkce potřebné k realizaci cíle námětu. Funkce jsou jednotkou vydání; představují, 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ělo by mít velikost, aby se zajistil 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 přírůstkové části. Jeden dokončený text nemusí zákazníkovi poskytnout smysluplnou hodnotu. Dokončený scénář ale představuje software v produkční kvalitě. Scénáře jsou pracovní jednotka týmu. Tým definuje scénáře potřebné k dokončení funkce. Volitelně se scénáře rozdělí do úkolů.

Úlohy

Ú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 náměty označovanou jako iniciativy.

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

Linie autonomie

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

Následující příklad ukazuje řádek autonomie vykreslené pod 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.

Plánování

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.

Pohled

Vize se vyjadřuje prostřednictvím námětů a nastavuje dlouhodobý směr organizace. Náměty 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 se prezentuje na celé schůzce. Vzhledem k tomu, že vize má být ambiciózní a v daném časovém období se může hodně změnit, očekáváme, že dosáhnete přibližně 60 % vize.

Sezóna

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 pro své zákazníky rozsvítit. Správa vlastní sezónní plán a prezentuje vizi a sezónní plány na celodenní schůzce. 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 3 sprintů

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 kalibruje 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 autonomie

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

Jak je uvedeno výše, správa nerozšířuje vlastnictví pod řádek autonomie. Správa poskytuje pokyny s využitím plánů vize a sezóny a pak dává týmům autonomii při vytváření plánů 3 sprintů a sprintů.

Chaty s funkcemi: Kde autonomie splňuje sladění

Chat funkcí je schůzka s nízkou úrovní obřadu, kde každý tým prezentuje plán 3 sprintů pro správu. 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, budou se chaty funkcí konat podle potřeby, obvykle každý sprint 1:tři.

Schůzka chatu funkcí 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í 3 snímky s následujícími snímky:

Funkce

První snímek popisuje funkce, které tým rozsvítí v dalších třech sprintech.

Dluhu

Další snímek popisuje, jak tým spravuje technický dluh. Dluh je cokoli, co nesplňuje kvalitní pruhy managementu. Ředitel technického oddělení nastavuje kvalitní pruhy, které jsou stejné pro všechny týmy (sladění). Mezi příklady pruhů kvality patří počet chyb na inženýra, procento úspěšného testování jednotek a výkonnostních cílů.

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 této vzácné události tým znovu naplánuje a naplánuje druhý chat s funkcemi, aby ho zkontroloval.

Vztah důvěryhodnosti: Připevnění, které drží zarovnání a autonomii pohromadě

Při cvičení Agilní ve velkém měřítku je vztah důvěryhodnosti obousměrná ulice:

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

Správa musí poskytovat jasné plány, aby týmy byly v souladu s týmy a pak důvěřovaly jejich týmům, aby je provedly. 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

Existuje mnoho způsobů, jak tým libovolné velikosti začít vidět výhody 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.