Agilní metriky představují měřitelné ukazatele, které slouží k monitorování pokroku a úspěšnosti agilního týmu při realizaci projektů.
Správně nastavené metriky poskytují cenný pohled na výkonnost, úroveň kvality, efektivitu testování a celkovou výkonnost týmu. Umožňují také sledovat, jak se tyto aspekty vyvíjejí v čase.
Hlavním úkolem agilních metrik je poskytnout týmům data potřebná k identifikaci oblastí, kde je možné dosáhnout zlepšení, a podpořit rozhodování na základě faktů. To vše směřuje k vytváření kvalitnějších produktů.
Bohužel, mnohé společnosti stanovují metriky, které jsou buď irelevantní (tzv. „metriky marnosti“), nebo se jedná o hrubá, uměle navyšovaná čísla. Graficky mohou vypadat působivě, ale pro samotný tým nemají prakticky žádný užitek.
Takové metriky často neslouží k podpoře týmu, nýbrž k vytváření reportů pro vedení a k podkladům pro strategická rozhodnutí. Následkem toho tým často nechápe, proč byla daná rozhodnutí přijata.
Aby týmy splnily nerelevantní metriky, uchylují se k manipulaci s vlastními procesy, což ve výsledku zkresluje skutečný stav a nijak nezlepšuje výkonnost.
Základní přístupy k metrikám
Metriky je možné rozdělit dle různých kritérií. Základní rozdělení je na metriky „shora dolů“ a „zdola nahoru“.
➡️ Metriky „shora dolů“: Vedení definuje metriky, které mají týmy plnit. Hlavním cílem je dosáhnout požadovaných hodnot, bez ohledu na to, zda s nimi tým souhlasí nebo ne. Důraz je kladen na sledování, nikoli na zlepšení.
➡️ Metriky „zdola nahoru“: Tým sám si stanovuje oblasti, ve kterých se potřebuje zlepšit, a definuje metriky, které mu umožní sledovat pokrok a jeho vliv na práci. Cílem je zlepšení výkonnosti na základě dat.
Jak definovat kvalitní metriku
Jaké vlastnosti by měla mít každá dobrá metrika?
Zásadní je schopnost vyvolat změnu chování. Jinými slovy, na základě metriky musí být jasné, jaké kroky má tým podniknout pro zlepšení.
Dále by metrika měla být srozumitelná a snadno vysvětlitelná i pro laiky. Pokud je popis komplikovaný, metrika pravděpodobně není dobře definovaná.
Důležitá je i porovnatelnost v čase. Zaznamenané výsledky by měly být srovnatelné s předchozími výsledky, aby bylo možné identifikovat trendy.
Pokud je to možné, je lepší používat poměry a procenta než absolutní čísla. Například „10 nově otevřených chyb v průběhu sprintu“ nemá takovou vypovídací hodnotu jako „procento otevřených chyb oproti celkovému počtu bodů úkolů“.
Následují příklady metrik, které splňují uvedená kritéria, s důrazem na agilní týmy. Tyto metriky jsou rozděleny do tří hlavních kategorií: výkonnost, kvalita a morálka.
Kategorie metrik
Výkonnostní metriky
Cílem těchto metrik je zhodnotit, jak efektivně tým plní úkoly slíbené na začátku sprintu. Důležité je posoudit, zda dochází k častému překračování závazků, nebo zda je přesouvání úkolů mezi sprinty běžné.
Z agilního hlediska se tým snaží dokončit plánovaný obsah sprintu, ke kterému se na začátku zavázal.
To neznamená, že nemůžeme být flexibilní a vyměňovat úkoly během sprintu. Vždy by ale mělo jít o výměnu za jiný, a ne o pouhé přidávání. Kapacita týmu není nekonečná.
Tyto metriky slouží k tomu, aby si tým uvědomil svou kapacitu a chránil ji.
Budováním spolehlivosti a předvídatelnosti se zvyšuje i důvěra v tým.
#1. Kapacita sprintu vs. Dodané body úkolů
Sledujte poměr mezi kapacitou sprintu a množstvím dodaných bodů úkolů v jednotlivých sprintech.
- Malé odchylky mezi sprinty jsou v pořádku. Výrazné skoky v jakémkoli směru naznačují problém.
- Celková kapacita sprintu se počítá jako součet dostupných pracovních dnů členů týmu. Například tým s 10 členy, kteří jsou k dispozici po celou dobu sprintu, má kapacitu 100.
Porovnávejte plánovanou a dokončenou kapacitu sprintu v průběhu času. Pokud tým opakovaně plánuje výrazně více bodů, než je schopen dokončit, měl by se zamyslet nad rizikem.
Cílem je, aby se plánované body rovnaly nebo byly menší než dokončené body.
Může se stát, že tým dodá více bodů, než bylo plánováno, pokud dokončí veškeré naplánované úkoly a má stále kapacitu na další.
- Pokud tým opakovaně dodává méně bodů, než bylo plánováno, měl by upravit své plánování a snižovat zátěž na příští sprint.
Nástroje jako monday.com, Atlassian Jira nebo Asana umožňují jednoduché ukládání a extrakci bodů úkolů pro každý úkol ve sprintu. Dokážou i automaticky generovat přehled po každém plánování sprintu.
#2. Graf vyhoření
Tato metrika bývá často součástí dashboardů scrumových týmů. Někteří členové týmu ji mohou považovat za zbytečnou, ale měla by být brána v potaz. Manažeři ji rádi používají ke kontrole postupu, ale týmy by se na ni měly dívat s cílem vylepšit procesy.
Pokud jsou všechny úkoly otevřené po celou dobu sprintu a uzavírají se až poslední den, vzniká nejistota ohledně splnění cílů sprintu.
- Prohlédněte si tabuli sprintu a podívejte se na dokončené úkoly.
- Zjišťujte, proč jsou malé úkoly stále otevřené i přesto, že byly zahájeny na začátku sprintu.
- Spolupracujte s týmem, aby nedocházelo ke zbytečnému prodlužování trvání úkolů.
- Ideální graf vyhoření je obvykle teoretický. Čím více se k němu blížíme, tím efektivněji zpracováváme úkoly.
Agilní nástroje pro správu, jako je Asana, dokážou graf vyhoření automaticky generovat pro každý sprint.
Zdroj: asana.com
#3. Dokončení cíle sprintu
Tato metrika sleduje procento cílů sprintu, které byly splněny během každého sprintu.
Cíle sprintu se dokumentují zvlášť, například na stránce Confluence nebo Jira, a u každého cíle je zaznamenáno, zda byl splněn či nikoliv.
I když tým nedokončí všechny úkoly ve sprintu, může dosáhnout cíle sprintu (například pokud chyběly jen vedlejší úkoly).
Cílem je 100% splnění cílů sprintu. Pokud tomu tak není, je třeba zjistit, co týmu brání.
- Pokud je v každém sprintu příliš mnoho paralelních témat, snižte jejich počet.
- Pokud je během sprintu přidáváno příliš mnoho ad-hoc úkolů, omezte je, aby neovlivnily původní cíle sprintu.
- Pokud jsou cíle sprintu příliš velké nebo příliš náročné, zjednodušte je. Nemá smysl dávat si vysoké cíle, které stejně nedosáhnete.
Metriky kvality kódu
Tyto metriky sledují, jak se kvalita kódu vyvíjí v průběhu času. Pomáhají udržovat zdravé vývojové procesy a omezují čas strávený opravováním chyb. Snižují také prostoje vývojářů 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
Vývojáři by měli vytvářet automatizované jednotkové testy pro každou provedenou změnu.
- Měřte pokrytí kódu automatizovanými testy pomocí nástrojů jako Azure Pipelines nebo SonarCloud. Cílem je dosáhnout 85% pokrytí. Hodnoty nad 90 % již nemusejí být efektivní.
- Automatické vytváření jednotkových testů by mělo být součástí definice hotového úkolu.
- Pokryjte i starý kód testy v rámci technických dluhů.
#2. Složitost kódu
Vyhodnocujte komplikace v kódu a aktivně je odstraňujte technickými dluhy. Důležité je i předcházet komplikacím.
Definujte standardy kódování a instrukce pro vývojáře. Dbejte na to, aby dodržovali pravidla kódování. Pravidelně aktualizujte instrukce na základě zkušeností týmu.
Identifikujte „pachy kódu“ – indikátory potenciálních problémů, jako je duplicitní kód, dlouhé metody a nepoužívané proměnné.
Vzájemné kontroly kódu zajistí, že standardy kódování budou aplikovány na nový kód.
Pro identifikaci problémů s kódem používejte nástroje jako Azure Ado nebo SonarCloud.
#3. Ruční kroky při nasazení
Sledujte, kolik manuálních kroků musí tým provést, aby mohl kód nasadit do testovacího nebo produkčního prostředí.
- Cílem je postupně dosáhnout nuly.
- Vytvořte si příběhy technických dluhů pro automatizaci procesu nasazování. Postupně snižujte manuální kroky od sprintu ke sprintu.
Morální metriky
Tyto metriky slouží ke sledování, jak se tým cítí v souvislosti se svou prací a procesy.
#1. Splnění akčních bodů z retrospektiv
Sledujte, kolik akčních bodů z retrospektivy bylo skutečně dokončeno v následujícím sprintu.
- Scrum Master by měl zaznamenávat výsledky retrospektiv na týmové stránce, aby bylo možné sledovat dohodnuté akce.
- Tým by měl sledovat pokrok.
- Vedení může kontrolovat, zda jsou akční body plněny, a pomoci týmu překonat překážky.
Minimálně 33 % nebo 1 (podle toho, co je vyšší) akčních bodů z předchozího sprintu by mělo být implementováno v dalším sprintu.
Pokud je splnění akčních bodů nižší, jsou nutné změny, které umožní týmu implementovat dohodnutá zlepšení.
Nástroje pro řízení projektů často obsahují předpřipravené šablony pro retrospektivní aktivity. Zde je příklad z monday.com:
Zdroj: monday.com
#2. Týmová spolupráce
Sledujte programování v párech.
- Vytvořte přirozené páry u jednotlivých úkolů. Podporujte sdílení postřehů, znalostí a úspěchů. Vytvářejte podúkoly v rámci větších úkolů, které budou vlastnit různí členové týmu.
Sledujte recenze kódu.
- Členové týmu by měli kontrolovat výstupy práce svých kolegů.
Metriku lze získat z nástěnek v systémech monday.com/Asana/Jira z podúkolů.
Minimálně 50 % úkolů by mělo být sdíleno členy týmu. Pokud je toto číslo nižší, hledejte důvody a podnikněte kroky.
Pro dobrovolné vzájemné recenze kódu sledujte úkoly pomocí vyhrazených podúkolů. Na začátku je dobrý cíl 20% recenzovaných úkolů, postupně byste měli tým motivovat ke zvýšení spolupráce na 50 % úkolů v každém sprintu.
#3. Technický dluh vs. příběhy o nových funkcích
Zdroj: atlassian.com
Pokud dáte týmu možnost řešit technické dluhy, zvýšíte jeho spokojenost s prací.
- Naopak, hromadění technického dluhu bez plánu jeho postupného odstraňování bude tým časem demotivovat. Řešení technických problémů se stane složitější a obtížněji zvladatelné.
Tým nejlépe ví, co ve stávajícím řešení nefunguje dobře, i když to zainteresované strany nebo koncoví uživatelé nevidí. Tyto příběhy mají největší dopad na samotný vývojářský tým, ale pro ostatní mohou být neviditelné. Je důležité dát týmu šanci pracovat na úkolech, které mu pomohou zlepšit vývojové aktivity.
Cílem je sledovat, kolik příběhů technického dluhu je v průběhu času vyřešeno a zda se počet nevyřízených případů pouze nezvyšuje.
Tým může v backlogu označovat příběhy jako „TechDebt“ a dávat jim prioritu, aby se dostaly na vrchol a byly vybrány v jednotlivých sprintech.
V závislosti na tom, v jakém stavu se projekt nachází a kolik technického dluhu je identifikováno v backlogu, můžete zajistit, aby backlog TechDebt nerostl od sprintu ke sprintu o více než 10 %.
Upřednostňujte příběhy technických dluhů a zahrnujte je do sprintů. Tým by měl trávit 10–20 % času každého sprintu prací na příbězích technického dluhu.
Závěrečná slova
Každý projekt nakonec potřebuje metriky, ať už je vyžaduje vedení, nebo se je tým rozhodne používat pro sledování svého úspěchu.
Důležité je začít budovat svou knihovnu metrik připravených k použití. Čím dříve začnete, tím lépe. A vždy se soustřeďte především na metriky, které vedou ke změně chování.
Zamyslete se i nad nezdravými procesy, které mohou zničit váš sprint.