Agilní metriky jsou měření používaná ke sledování pokroku a úspěchu agilního projektového týmu.
Když jsou metriky definovány správným způsobem, poskytují přehled o výkonu, kvalitě, efektivitě testování nebo celkové efektivitě týmu a o tom, jak se vyvíjí v čase.
Konečným cílem agilních metrik je pomoci týmům identifikovat oblasti pro zlepšení a činit rozhodnutí na základě dat, která povedou k lepším produktům, jak tým postupuje.
Společnosti většinou definují metriky, které jsou buď metriky marnosti, nebo hrubá čísla, pěkně rostoucí zleva doprava. Na některých dashboardech mohou vypadat hezky, ale pro samotný tým jsou obvykle k ničemu.
Jejich účelem není jakkoli pomoci týmu, ale spíše vyplnit nějaké zprávy pro vedení a následně uzavřít nějaká strategická rozhodnutí. Bohužel je to pak tým, kdo nechápe, proč toto konkrétní rozhodnutí existuje.
Aby týmy splnily takové nesprávné metriky, falšují své vlastní procesy, aby metriky vypadaly dobře. Výkon týmu se ale vůbec nezlepšuje.
Table of Contents
Základní metriky
Existuje mnoho způsobů, jak metriky oddělit. Snad nejzákladnější je shora dolů a zdola nahoru.
➡️ Shora dolů znamená: My vedení pro vás vytvoří metriky, které chceme, abyste všichni splnili, a vaším konečným cílem je zapadnout do zelených oblastí. Nevadí nám, jestli vy – tým jako oni nebo ne; to je to, co chceme sledovat.
➡️ Zdola nahoru znamená: My – tým se potřebuje v těchto oblastech zlepšit, a proto se musíme na tyto věci zaměřit. Definujeme proto metriky, které nám umožní sledovat pokrok týmu směrem k našim cílům, a můžeme vám – vedení ukázat, jak přesně to v průběhu času zlepšilo naši práci.
Definice dobré metriky
Co by tedy měla každá dobrá metrika obsahovat nebo jak ji popsat?
Nejdůležitější vlastností je změna chování. To znamená, že pokaždé, když se podíváte na výsledek metriky, je jasné, co se musí v týmu změnit, aby bylo možné dosáhnout zlepšení.
Pak to musí být jednoduché. Pokud to nedokážete vysvětlit pár jednoduchými větami tak, aby to pochopili všichni relevantní posluchači, pak něco není opravdu dobré.
Dobrá metrika je srovnatelná v čase. Udělejte snímek výsledků za čas a udělejte to znovu někdy později. Umístěte je vedle sebe. Pokud nemůžete porovnat tyto dva výsledky mezi sebou, měli byste se nad touto metrikou zamyslet.
A konečně, lepší než čistá čísla, kdykoli je to možné, udělejte z něj poměr nebo procento. „10 nových otevřených defektů během sprintu“ toho moc nenapoví. Záleží na tom, jestli máte normálně jeden nebo 100.
Zde je několik příkladů metrik, o kterých se domnívám, že splňují všechna tato definiční kritéria. Mají na mysli konkrétně agilní týmy. Existují tři hlavní kategorie: výkon, kvalita a morálka.
Kategorie metrik
Výkonnostní metriky
Cílem je pochopit, jak dobrý je tým v dohánění příběhů spáchaných ve sprintu. Vyhodnotit, zda překročení závazků není běžné nebo zda jsou přenosové příběhy standardem od sprintu ke sprintu.
Z hlediska agilního výkonu se tým bude snažit dodat plánovaný obsah sprintu, ke kterému se tým zavázal na začátku sprintu.
Neznamená to, že nebudeme flexibilní ve výměně příběhů během sprintu. Vždy by ale mělo jít o vyjednávání vedoucí k výměně, nikoli doplnění. Kapacita týmu neporoste jen proto, že někdo přidal nové příběhy uvnitř sprintu.
Přinášíme tuto metriku, abychom si na takové případy dávali pozor a vedli každého v týmu k ochraně kapacity, kterou má pro sprint.
Tím se buduje spolehlivost a předvídatelnost týmu.
#1. Kapacita sprintu vs. Dodané body příběhu
Sledujte historii kapacity sprintu vs. obsah dodaných příběhových bodů (SP) v průběhu sprintů.
- Malé odchylky od sprintu ke sprintu jsou v pořádku. Obrovské skoky v jakémkoli směru signalizují, že něco není v pořádku.
- Celková kapacita sprintu – dostupný den jednoho člena týmu přidá jeden k celkové kapacitě. Např. Pokud má tým 10 lidí a všichni budou k dispozici v plném sprintu, pak je celková kapacita pro sprint 100.
Ověřte kapacitu sprintu vs. dokončený SP od sprintu po sprint. Pokud se tým (během plánování) zavazuje k výrazně vyššímu množství SP, než je tým obvykle schopen dokončit, zvyšte toto riziko na tým.
Cílem je mít celkový plánovaný SP rovný nebo menší než celkový dokončený SP na sprint.
Stále můžete mít více dokončených SP, než bylo plánováno, pokud tým dokončil (ke konci sprintu) všechny plánované příběhy a tým má stále kapacitu na další příběh.
- Pokud tým opakovaně dodává méně SP, než bylo plánováno, musí tým upravit své plánování a vzít si méně SP do dalšího sprintu.
Nástroje jako monday.com, Atlassian Jira nebo Asana poskytují jednoduchý způsob, jak uložit a extrahovat příběhové body pro každý příběh ve sprintech. Mohou vám to dokonce automaticky vygenerovat po každém plánování sprintu.
#2. Burndown Chart
Toto je jedna z metrik, kterou má pravděpodobně většina scrumových týmů někde ukrytou na palubní desce. Souhlasím, že to může vypadat jako zbytečná věc. Tým to málokdy bere v úvahu. Spíše manažer rád poukazuje na to, jak příběhy vypadají z vysoké úrovně a jak se nevyvíjejí dobře (protože jsou všechny otevřené po celý sprint).
Co bych rád zdůraznil, je, že i přes to byste se jako tým měli jít pro své dobro podívat na graf vyhoření. Pokud jsou všechny příběhy otevřené po celý sprint a uzavřeny pouze v poslední den sprintu, vytváří to nejistotu uvnitř týmu a směrem ke splnění cílů sprintu.
- Prohlédněte si svůj sprintový board pro dokončené příběhy.
- Ověřte si s týmem, proč jsou malé příběhy stále otevřené, i když začaly na začátku sprintu.
- Spolupracujte s týmem na vytvoření tohoto myšlení, nenechte příběhy otevřené déle, než je nutné.
- Ideální diagram vyhoření je obvykle teoretický stav. Čím více se k tomu ale blížíme, tím efektivnější zpracování příběhu máme.
Agilní nástroje pro správu, jako je Asana, vám pro každý sprint dokážou automaticky vygenerovat graf vyhoření.
Zdroj: asana.com
#3. Dokončení cíle sprintu
To sleduje procento cílů sprintu, které jste splnili během každého sprintu.
Cíle sprintu dokumentujete samostatně, např. na stránce Confluence / Jira, pro každý sprint. Stav bude přidělen, zda byly splněny nebo ne ve sprintu.
I když tým nedokončil všechny příběhy ve sprintu, stále mohl dosáhnout cíle sprintu (např. chyběly pouze vedlejší příběhy).
Budeme usilovat o 100% splnění cílů sprintu v každém sprintu. Pokud tomu tak není, zjistěte, čemu tým brání.
- Pokud je v každém sprintu příliš mnoho paralelních témat, snižte jejich množství.
- Pokud je během sprintu přidáno příliš mnoho ad hoc příběhů, snižte to, aby to neovlivnilo původní cíle sprintu.
- Pokud jsou cíle sprintu příliš velké nebo příliš náročné, udělejte to jednodušší. Stejně nemá smysl mít velké sprintové cíle a přitom je do konce sprintu nesplňovat.
Metriky kvality kódu
To bude sledovat, jak dobrý je kód v průběhu času. Pomáhá udržovat zdravé vývojové procesy a snižuje čas strávený řešením problémů. Nebo nečinnost vývojáře způsobená čekáním na spuštění kódu během vývojových a testovacích aktivit.
Zdroj: azuredevopslabs.com
#1. Automatizované testy
Vytvářejte automatizované testy jednotek od vývojářů pro každou změnu, kterou provedou.
- Měřte pokrytí kódem automatickými testy – ke spuštění testů použijte Azure Pipelines nebo SonarCloud. Zaměřte se na 85% pokrytí. Nad 90 % není skutečně efektivní.
- Ujistěte se, že automatické vytvoření testu jednotek je součástí definice hotovo pro nové příběhy.
- Dohnat pokrytí starým testem kódu jako součást technických dluhových příběhů v nevyřízených záležitostech.
#2. Složitost kódu
Vyhodnoťte zbytečné komplikace, které kód v průběhu času získává, a aktivně je opravujte technickými dluhovými příběhy. Nebo jim pokud možno zabránit.
Definujte kódové standardy a pokyny, abyste vzdělávali vývojáře, aby je dodržovali. Ujistěte se, že dodržují pravidla kódování, aby se minimalizovalo nepřiměřené zvýšení složitosti kódu. Pravidelně aktualizované pokyny na základě zkušeností týmu.
Identifikujte pachy kódu – indikátory potenciálních problémů v kódu, jako je duplicitní kód, dlouhé metody a nepoužívané proměnné.
Vzájemné hodnocení zajistí, aby byly na nově vytvořený kód aplikovány standardy kódu.
Pomocí nástrojů, jako jsou řídicí panely a sestavy Azure Ado nebo SonarCloud, zjistěte problémy s kódem.
#3. Ruční kroky při nasazení
Sledujte, kolik manuálních kroků musí tým udělat, aby uvolnil kód do testovacího nebo produkčního prostředí.
- Naším cílem bude časem dosáhnout nuly.
- V případě potřeby vytvořte příběhy o technických dluzích, abyste posunuli potrubí nasazení/vydání až na plán automatizace. Postupně snižujte zbývající manuální kroky v procesech od sprintu ke sprintu.
Morální metriky
Toto je metrika ke sledování toho, jak se tým cítí o své práci a procesech, se kterými se denně zabývá.
#1. Retrospektivní sprint splnění
Můžete sledovat, kolik akčních položek bylo skutečně dokončeno v dalším sprintu.
- Scrum Master bude shromažďovat výsledky retrospektivních schůzek na stránky týmu, aby mohl sledovat dohodnuté akce.
- Tým by pak sledoval pokrok.
- Vedení projektu pak může zkontrolovat, zda úkoly postupují nebo co brání týmu v jejich dokončení. Poté upravte prostředí, aby tým mohl pokročit v dohodnutých akcích.
Minimálně 33 % nebo 1 (podle toho, co je vyšší) akčních předmětů z předchozího sprintu bude přijato do dalších sprintů.
Pokud je nižší, jsou nutné změny, které týmu umožní implementovat zlepšení, na kterých se dohodly.
Nástroje pro řízení projektů obsahují šablony připravené k použití pro retrospektivní aktivity sprintu. Zde je příklad z monday.com:
Zdroj: monday.com
#2. Týmová spolupráce
Programování párů stop.
- Vytvořte přirozený pár v příběhu, který bude spolupracovat, sdílet pozorování, znalosti a úspěch. Vytvářejte dílčí úkoly v rámci příběhů vlastněných různými členy týmu.
Recenze sledovacího kódu z iniciativ kolegů.
- Kolegové jsou požádáni nebo proaktivně podniknou kroky, aby zkontrolovali výstup příběhu někoho jiného.
Metriku lze získat z nástěnky monday.com/Asana/Jira z dílčích úkolů.
Nejméně 50 % příběhů ve sprintu musí sdílet členové týmu. Pokud je to méně, prozkoumejte důvody a podnikněte kroky, kde to dává smysl.
Pro dobrovolné vzájemné recenze sledujte příběhy pomocí vyhrazených dílčích úkolů. Na začátku je 20 % takto zkontrolovaných příběhů kódu dobrý začátek. Postupně v průběhu sprintů budete povzbuzovat a motivovat tým k větší spolupráci a zvýšit ji na 50 % příběhů kódu na sprint jako cíl.
#3. Technický dluh vs. příběhy o nových funkcích
Zdroj: atlassian.com
Pokud dáte týmu příležitost vyřešit své vlastní dluhové příběhy, zvýšíte tým spokojenost s jejich prací.
- Naopak, hromadění problémů s technickými dluhy bez plánu na jejich postupné řešení bude časem tým demotivovat. A řešení se stane nestabilnější, složitější a obtížněji řešitelné bez podstatného přepracování.
Tým ví nejlépe, co s řešením nefunguje dobře, i když to zúčastněné strany nebo koncoví uživatelé nevidí. Takové příběhy mají největší dopad na samotný vývojářský tým. Pro zúčastněné strany mohou být neviditelné. Proto je důležité dát týmu šanci pracovat na příbězích, které mu pomohou uklidit vývojové aktivity.
Cílem je sledovat, kolik vznesených technických dluhových příběhů je v průběhu času vyřešeno a zda počet nevyřízených případů pouze narůstá nebo ne.
Tým může v backlogu označit příběhy jako TechDebt a dát jim prioritu od týmu, takže mohou jít na vrchol a být vybráni ve sprintech.
V závislosti na tom, v jakém stavu se projekt nachází a kolik technických dluhů je identifikováno v backlogu, možná budete chtít zajistit, aby backlog TechDebt nerostl od sprintu ke sprintu o více než 10 %.
Upřednostněte příběhy technologických dluhů a zahrňte je do sprintů, abyste udrželi růst nevyřízených technických dluhů pod kontrolou, aby tým mohl pracovat na příběhech technických dluhů 10–20 % času v každém sprintu.
Závěrečná slova
Každý projekt bude nakonec potřebovat nějaké metriky, ať už proto, že je vedení chce mít, nebo proto, že se tým rozhodne měřit svůj vlastní úspěch.
Nejlepší, co můžete udělat, je začít budovat svou knihovnu metrik připravenou k výběru a použití; Čím dříve, tím lépe. A přitom se ujistěte, že vždy jdete především po metrikách měnících chování.
Dále se podívejte na nezdravé procesy, které mohou zničit váš sprint.