Jak Microsoft plánuje s DevOps

Microsoft je jednou z největších společností na světě, které používají agilní metodologie. V průběhu let společnost Microsoft vyvinula proces plánování DevOps, který se škáluje od nejmenších projektů až po obrovské úsilí, jako je Windows. Tento článek popisuje řadu znalostí a postupů, které Microsoft implementuje při plánování softwarových projektů v celé společnosti.

Instrumentální změny

Následující klíčové změny pomáhají zajistit, aby vývojové a expediční cykly byly efektivnější a efektivnější:

• Podporovat kulturní sladění a autonomii.
• Změna zaměření na jednotlivce na týmy
• Vytvářejte nové strategie plánování a výuky.
• Implementujte model více posádky.
• Vylepšete postupy pro stav kódu.
• Podpora transparentnosti a odpovědnosti.

Podpora kulturního sladění a samostatnosti

Peter Drucker řekl: "Kultura jíst strategii pro snídani." Autonomie, mastery a účel jsou klíčové lidské motivace. Microsoft se snaží poskytnout těmto motivátorům PM, vývojářům a návrhářům, aby měli možnost vytvářet úspěšné produkty.

Dva důležití přispěvatelé tohoto přístupu jsou sladění a samostatnost.

• Sladění vychází shora dolů, aby se zajistilo, že jednotlivci a týmy pochopí, jak jejich povinnosti odpovídají širším obchodním cílům.
• Autonomie probíhá odspodu, aby se zajistilo, že jednotlivci a týmy budou mít vliv na každodenní aktivity a rozhodnutí.

Existuje citlivá rovnováhu mezi sladěním a autonomií. Příliš mnoho zarovnání může vytvořit negativní kulturu, ve které lidé dělají jenom to, co jim bylo řečeno. Příliš mnoho samostatnosti může způsobit nedostatek struktury nebo směru, neefektivní rozhodování a špatné plánování.

Změna fokusu mezi jednotlivci a týmy

Microsoft organizuje lidi a týmy do tří skupin: PM, design a engineering.

• Pm definuje, co Microsoft sestavuje a proč.
• Návrh zodpovídá za návrh toho, co Microsoft sestavuje.
• Inženýr vytváří produkty a zajišťuje jejich kvalitu.

Týmy Microsoftu mají následující klíčové charakteristiky:

• Křížové disciplíny
• 10-12 lidí
• Samoobslužná správa
• Jasné charty a cíle po dobu 12–18 měsíců
• Fyzické týmové místnosti
• Nasazení vlastních funkcí
• Vlastní funkce v produkčním prostředí

Snažte se o vertikální týmy

Týmy Microsoftu se používají jako vodorovné, pokrývají veškeré uživatelské rozhraní, všechna data nebo všechna rozhraní API. Microsoft se teď snaží o vertikální týmy. Týmy vlastní své oblasti produktu od konce do konce. Přísné pokyny v určitých úrovních zajišťují jednotnost týmů napříč produktem.

Následující diagram koncepčně znázorňuje rozdíl mezi horizontálními a svislými týmy:

Povolit týmy pro vlastní výběr

Přibližně každých 18 měsíců microsoft spustí "žluté lepivé cvičení", ve kterém si vývojáři můžou vybrat, na kterých oblastech produktu chtějí pracovat na dalších pár obdobích plánování. Toto cvičení poskytuje autonomii, protože týmy si můžou vybrat, na čem mají pracovat, a sladění organizace, protože podporuje rovnováhu mezi týmy. Přibližně 80 % lidí v tomto cvičení zůstává na svých aktuálních týmech, ale cítí se zmocnění, protože měli na výběr.

Vytváření nových strategií plánování a výuky

Dwight Eisenhower řekl: "Plány jsou bezcenné, ale plánování je vše." Plánování Microsoftu se dělí na následující strukturu:

• Sprinty (3 týdny)
• Plány (3 sprinty)
• Sezóny (6 měsíců)
• Strategie (12 měsíců)

Technici a týmy jsou většinou zodpovědní za sprinty a plány. Vedení je primárně zodpovědné za sezóny a strategie.

Následující diagram znázorňuje strategii plánování Microsoftu:

Tato struktura plánování také pomáhá maximalizovat učení při plánování. Týmy můžou získat zpětnou vazbu, zjistit, co zákazníci chtějí, a rychle a efektivně implementovat žádosti zákazníků.

Implementace modelu s více posádkou

Předchozí metody podporovaly "přerušení kultury" chyb a živých incidentů webu. Týmy Microsoftu přišly s vlastním způsobem, jak se soustředit a vyhnout se rušivým prvkům. Týmy se pro každý sprint uspořádají do dvou různých posádk: funkce (F-crew) a zákazník (C-crew).

F-posádka pracuje na potvrzených funkcích a posádka C se zabývá problémy a přerušením živého webu. Tým vytvoří rotující tempo, které členům umožní snadněji plánovat aktivity. Další informace o modelu s více posádkou najdete v tématu Vytváření produktivních týmů zaměřených na zákazníky.

Vylepšení postupů pro stav kódu

Před přechodem na agilní metodologie týmy používaly k tomu, aby se chyby kódu sestavily až do dokončení kódu na konci vývojové fáze. Týmy pak zjistily chyby a pracovali na jejich opravě. Tento postup vytvořil horskou dráhu chyb, které ovlivnily týmovou moralitu a produktivitu, když týmy musely místo implementace nových funkcí pracovat na opravách chyb.

Teams teď implementuje limit chyb vypočítaný vzorcem # of engineers x 5 = bug cap. Pokud počet chyb týmu překročí limit chyb na konci sprintu, musí přestat pracovat na nových funkcích a opravovat chyby, dokud nebudou pod limitem. Týmy teď platí dluh za chyby, jak jdou.

Podpora transparentnosti a odpovědnosti

Na konci každého sprintu každý tým odešle zprávu o tom, co v předchozím sprintu udělal, a to, co plánuje udělat v dalším sprintu.

Cíle a klíčové výsledky (OKR)

Týmy jsou nejúčinnější, když jasně vymezuje cíle, kterých se organizace snaží dosáhnout. Microsoft poskytuje přehled o týmech prostřednictvím cílů a klíčových výsledků (OKRS).

• Cíle definují cíle, které mají být dosaženo. Cíle jsou významné, konkrétní, orientované na akci a ideálně inspirující prohlášení o záměru. Cíle představují velké nápady, ne skutečná čísla.
• Klíčové výsledky definují kroky k dosažení cílů. Klíčové výsledky jsou kvantifikovatelné výsledky, které vyhodnocují průběh a označují úspěch vůči cílům v určitém časovém období.

Okrs odrážejí nejlepší možné výsledky, nejen nejpravděpodobnější výsledky. Vedoucí představitelé se snaží být ambiciózní a ne opatrný. Nutí týmy, aby sledovaly náročné klíčové výsledky, řídí zrychlení cílů a upřednostňuje práci, která se přesouvá k větším cílům.

Přijetí architektury OKR může týmům pomoct lépe pracovat z následujících důvodů:

• Každý tým je v souladu s plánem.
• Týmy se zaměřují na dosažení výsledků , nikoli na dokončení aktivit.
• Každý tým je zodpovědný za pravidelné úsilí.

OkRs mohou existovat na různých úrovních produktu. Může se například jednat o okrs nejvyšší úrovně produktu, okrs na úrovni komponent a týmové okrs. Zajištění sladění okrs je poměrně snadné, zejména pokud jsou cíle nastaveny shora dolů. Jakékoli konflikty, které vznikají, jsou cenné počáteční indikátory nesprávného zarovnání organizace.

Příklad OKR

Cíl: Rozšiřte silnou a šťastnou zákaznickou základnu.

Klíčové výsledky:

• Zvyšte skóre externího net promoteru (NPS) z 21 na 35.
• Zvyšte spokojenost dokumentů z 55 na 65.
• Nový tok potrubí má skóre Apdex 0,9.
• Doba fronty pro úlohy je 5 sekund nebo méně.

Další informace o okrs naleznete v tématu Měření obchodních výsledků pomocí cílů a klíčových výsledků.

Výběr správných metrik

Klíčové výsledky jsou stejně užitečné jako metriky, na kterých jsou založeny. Microsoft používá úvodní indikátory, které se zaměřují na změnu. Tyto metriky v průběhu času vytvářejí pracovní obrázek akcelerace nebo zpomalení produktu. Microsoft často používá následující metriky:

• Změna míry měsíčního růstu přijetí
• Změna výkonu
• Změna času na učení
• Změna četnosti incidentů

Týmy se vyhýbají metrikám, které nenabídnou hodnotu směrem k cílům. I když můžou mít určitá použití, následující metriky nejsou užitečné pro sledování průběhu směrem k cílům:

• Přesnost původních odhadů
• Dokončené hodiny
• Řádky kódu
• Týmová kapacita
• Týmový burndown
• Rychlost týmu
• Počet nalezených chyb
• Pokrytí kódu

Před agilní a po agilní

Následující tabulka shrnuje změny, které vývojové týmy Microsoftu provedly při přijímání agilních postupů.

Před	Po
Milníky 4–6 měsíců	3týdenní sprinty
Horizontální týmy	Vertikální týmy
Osobní pobočky	Týmové místnosti a práce na dálku
Dlouhé cykly plánování	Průběžné plánování a učení
PM, Dev a Test	PM, Design a Engineering
Roční zapojení zákazníků	Průběžná zapojení zákazníků
Větve funkcí	Všichni pracují v hlavní větvi
20+ týmy osob	Týmy 8–12 osob
Plán tajných kódů	Veřejně sdílený plán
Dluh chyby	Nulový dluh
100-page spec documents	Specifikace PowerPointu
Privátní úložiště	Open source nebo InnerSource
Hloubková hierarchie organizace	Zploštěná hierarchie organizace
Čísla instalace definují úspěch	Spokojenost uživatelů definuje úspěch.
Funkce se dodávají jednou za rok	Funkce se dodávají při každém sprintu.

Klíčové poznatky

• Vezměte agilní vědu vážně, ale nepřesvědčíte. Agilní může být příliš striktní. Nechte agilní myšlení a kulturu růst.
• Oslavte výsledky, ne aktivitu. Nasazení funkcí převáží řádky kódu.
• Při každém sprintu můžete vytvořit rytmus a tempo a najít veškerou práci, kterou je potřeba udělat.
• Vytvořte jazykovou verzi, kterou chcete získat při hledání.