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 zdraví kódu.
• Podpora transparentnosti a odpovědnosti.

Podpora kulturního sladění a samostatnosti

Peter Drucker řekl: "Kultura zkonzumuje strategii k snídani." Autonomie, znalost a účel jsou klíčové lidské motivace. Microsoft se snaží poskytnout tyto motivátory produktovým manažerům, vývojářům a návrhářům, aby se cítili být zmocněni k vytváření úspěšných produktů.

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 sjednocení může vytvořit negativní kulturu, ve které lidé dělají jen to, co se jim řekne. Příliš mnoho samostatnosti může způsobit nedostatek struktury nebo směru, neefektivní rozhodování a špatné plánování.

Změna zaměření od jednotlivců k týmům

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

• Produktový manažer definuje, co Microsoft sestavuje a proč.
• Design je odpovědné za vytváření toho, co Microsoft vyvíjí.
• Inženýr vytváří produkty a zajišťuje jejich kvalitu.

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

• Mezioborové
• 10-12 lidí
• Samospráva
• Jasné směrnice a cíle na 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 Microsoft byly dříve organizovány horizontálně, pokrývaly všechna 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, které si samy vybírají

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:

• Sprint (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 kulturu přerušování chyb a incidentů na živých stránkách. 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ádek: Feature (F-crew) a Customer (C-crew).

F-posádka pracuje na závazných funkcích a C-posádka se zabývá problémy a výpadky na živém 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í praktik zdravého kódu

Před přechodem na Agilní metodiky týmy nechávaly chyby v kódu narůstat, dokud nebyl kód kompletně dokončen 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ý. Tlačí týmy k tomu, aby sledovaly náročné klíčové výsledky, podporuje urychlení naplnění cílů a upřednostňuje práci, která přispívá k dosažení větších cílů.

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 OKR na úrovni produktu, na úrovni komponent a na úrovni týmu. Zajištění sladění OKR 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 s dokumentací z 55 na 65.
• Nový tok potrubí má skóre Apdex 0,9.
• Čekací doba ve frontě na ú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á vedoucí ukazatele, které se soustředí 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ý graf úbytku práce
• Rychlost týmu
• Počet nalezených chyb
• Pokrytí kódu

Před Agile a po Agile

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í kanceláře	Týmové místnosti a práce na dálku
Dlouhé cykly plánování	Průběžné plánování a učení
Vedoucí projektu, Vývojář a Testování	PM, Design a Inženýrství
Roční zapojení zákazníků	Průběžná zapojení zákazníků
Funkční větve	Všichni pracují v hlavní větvi
20+ členné týmy	Týmy 8–12 osob
Tajný plán	Veřejně sdílený plán
Dluh chyb	Nulový dluh
stostránkové specifikační dokumenty	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

• Berte agilní vědu vážně, ale nebýt příliš direktivní. Agilní metodika může být příliš přísná. 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.
• Budujte kulturu, kterou chcete, abyste získali chování, které hledáte.