Inverse Conway Maneuver a kognitivní zátěž týmů
Jak strukturu týmů vědomě změnit: Inverse Conway Maneuver ve čtyřech krocích, kognitivní zátěž jako limit počtu kontextů na tým, nejčastější organizační anti-vzory a jak reorganizaci obhájit metrikami DORA.
Přehrávač YouTube se načte až po kliknutí · otevřít na YouTube (nové okno) ↗
Přepis dílu komentář tak, jak zazní ve videu
Propad po reorganizaci
Firma se přeskupí na týmy podle kontextů. Od prvního dne každý tým vlastní kód, který nepsal. Prodírá se jím a lead time se prodlouží.
Po třech měsících vedení vyloží čísla jako důkaz neúspěchu a reorganizaci vrátí. Dá se tomu předejít, jen se s propadem musí počítat dopředu.
Inverse Conway Maneuver
Conwayův zákon říká, že systém kopíruje komunikační strukturu firmy. Inverse Conway Maneuver otáčí směr. Kdo chce jinou architekturu, změní nejdřív týmy.
Termín zavedli Jonny LeRoy a Matt Simons v článku z roku 2010. Skelton a Pais ho později rozpracovali. V knize je postup shrnutý do čtyř kroků.
Prvním krokem je cílová architektura, typicky Context Map. Pak se spočítají stream-aligned týmy, zhruba jeden na kontext.
Na třetím kroku, rozpuštění horizontálních týmů, manévr obvykle selže. Frontendisté chtějí sedět s frontendisty. Manažer zase nechce vyměnit tým dvanácti lidí za sedmičlenný.
Čtvrtým krokem je platforma, jen tak tlustá, jak je potřeba. Skelton a Pais k tomu varují, že bez podpory vedení manévr neuspěje. Prakticky to znamená výslovnou podporu CTO.
Známý příklad je Amazon kolem roku 2002. Jeff Bezos tehdy nařídil, že týmy spolu smějí komunikovat jen přes rozhraní služeb. Amazon ten dokument nikdy nezveřejnil. Znění příkazu známe z textu Steva Yeggeho z roku 2011, který v Amazonu dřív pracoval.
Bezos nepředepsal architekturu. Předepsal, jak spolu týmy smějí mluvit, a služby za API z toho vyplynuly.
Martin Fowler k tomu přidává výhradu. U zabetonované architektury reorganizace hned nic nespraví. Spíš vznikne nesoulad mezi lidmi a kódem, který další úpravy brzdí. Fowler proto radí postupovat malými kroky a bedlivě sledovat zpětnou vazbu.
Před startem má kniha kontrolní seznam se sedmi otázkami. Čtyři z nich: existuje Context Map? Stojí za tím CTO? Je na to šest měsíců? Jsou změřená výchozí čísla? Stačí jedno ne a manévr je předčasný. A patří k nim ještě jedna nepříjemná otázka. Jak dlouho potrvá propad a kdo ho vysvětlí vedení?
Kognitivní zátěž
Pojem kognitivní zátěž převzali Skelton a Pais z teorie Johna Swellera. Ta dnes rozlišuje tři typy zátěže.
Intrinsic je složitost samotné domény. Extraneous přidává prostředí, třeba nestabilní CI nebo pět různých deploy procesů. A germane je energie, kterou tým vkládá do učení a zlepšování.
Skelton a Pais z toho odvozují cíl. Intrinsic zátěž držet co nejníž, extraneous odstranit a uvolněný prostor nechat pro germane. Na extraneous zátěž je tu Platform tým.
Přesné měřítko kognitivní zátěže podle autorů neexistuje. Místo něj nabízejí otázku pro tým. Cítíte se efektivní a stíháte včas reagovat na práci, kterou po vás chtějí?
Kniha na stejné myšlence staví vlastní dotazník. Jednou za kvartál půlhodinový workshop a pět otázek, každá za jeden až pět bodů. Když prostor na učení vyjde pod tři, tým nepřebírá žádný nový kontext.
Počet řádků nebo tříd autoři Team Topologies jako měřítko zátěže odmítají. Jazyky jsou různě upovídané a řádky se mezi nimi srovnat nedají. Rozhoduje, kolik kapacity má tým na změny systému.
Častá past. Úspěšný tým dostane od vedení ještě jeden malý kontext, pak další. Po roce jich má čtyři, je vyhořelý a nic nemá dotažené. Kdykoli se kontext přidává, musí někdo výslovně říct, co se odebírá.
Scénáře a anti-vzory
Podoba struktury závisí na velikosti firmy. Pětičlenný startup má jeden stream-aligned tým a modulární monolit. Platform tým mu nahradí managed hosting.
Dvacet lidí znamená dva až tři stream-aligned týmy a malý platform tým. Kniha tuhle fázi považuje za nejrizikovější. Firma už není malá, a na plnou strukturu přesto nemá kapacitu.
Od dvou set lidí dává smysl plná struktura. I tam mají stream-aligned týmy výrazně převažovat. Kniha uvádí orientačně tři čtvrtiny lidí, je to ale její vlastní zobecnění.
Z anti-vzorů kniha vybírá pět. Nejznámější jsou týmy po vrstvách. Úprava na tři dny práce projde třemi týmy a její lead time přesáhne šest týdnů.
Další je monorepo bez hranic modulů. Druhý tým pak fakticky schvaluje každou změnu prvního. Pomůže hranice hlídaná v CI, třeba nástrojem Deptrac nebo PHPArkitect, a vlastnictví zapsané v CODEOWNERS.
Zbývají tři. Center of Excellence, který schvaluje, místo aby učil. Platform tým, u kterého se na databázi čeká pět dní v ticketové frontě. A kontext sdílený dvěma týmy, uvnitř kterého vznikne neoficiální čára mezi naším a vaším kódem.
Komunikace s managementem
Reorganizaci schvaluje vedení a to mluví jazykem metrik. Argument proto stojí na metrikách DORA, které v roce 2018 zveřejnila kniha Accelerate.
Od té doby se sada posunula. V roce 2023 dostala MTTR nový název, failed deployment recovery time, a měří jen zotavení po vadném nasazení. O rok později přibyla pátá metrika, deployment rework rate.
Tři metriky měří průtok, dvě nestabilitu. Podstatné je měřit stejně definovaná čísla dvakrát, před reorganizací a šest měsíců po ní.
O kolik se čísla posunou, dopředu nikdo neví. Kdo slíbí konkrétní procento, bude mít za půl roku problém. Slíbit se dá výchozí měření, termín druhého a rozhodnutí podle výsledku.
Nefungují ani argumenty typu je to elegantnější nebo Evans by to chtěl. Eleganci nikdo neměří a manažer v DDD komunitě není.
Zbývá kultura. Sociolog Ron Westrum v roce 2004 popsal kulturu patologickou, byrokratickou a generativní. Kniha tvrdí, že Team Topologies funguje jen v té generativní. Po selhání se v ní hledají příčiny, ne viníci.
Otázky a shrnutí
Krátká otázka na rozmyšlenou. Tým tráví většinu energie bojem s CI. Jaký typ zátěže to je a kdo ji má odstranit?
Extraneous zátěž, tedy zátěž z prostředí. Odstranit ji má Platform tým.
A jedna z dílu o Event Stormingu. Podle čeho se na stěně hledá hranice kontextu?
Stejné slovo s jiným významem, zlomové události, hranice oddělení a vlastnictví dat. Rozhoduje místo, kde se jich protne víc. Hranice oddělení sama nestačí, organizační schéma bývá historické.
Takže v kostce. Inverse Conway začíná cílovou Context Mapou a podporou CTO. S propadem po reorganizaci počítá předem.
Kognitivní zátěž omezuje, kolik kontextů tým unese. Vedení přesvědčí výchozí měření DORA a termín, kdy se změří znovu.
Příští díl otevírá taktické vzory, entitou a hodnotovým objektem. Kapitolu najdete v knize na ddd-v-symfony.katuscak.cz.