Abstrakt: Měřit lze ve vývoji software téměř cokoli, ale ne každé měření přináší užitek. Špatně zvolené metriky vedou k toxickému chování, zatajování problémů a paralýze týmu. Dobré metriky naopak otevírají rozhovor, odhalují problémy včas a poskytují podklady pro rozhodování. Tento článek shrnuje praxí ověřený přístup k softwarovým metrikám, představuje kategorie ukazatelů, jejich obchodní význam a typická úskalí. Cílí na technické vedoucí a manažery, kteří chtějí budovat datově podloženou inženýrskou kulturu bez sklouznutí k mikromanagementu.
1. Co se pokazí, když metriky chybí nebo škodí
Klasickou chybou je hodnocení vývojářů podle počtu napsaných řádků kódu. Důsledek je předvídatelný: tým produkuje rozvláčný kód, redukuje refaktoring a vyhýbá se elegantním řešením. Stejně škodlivé je sledování počtu nahlášených chyb bez kontextu, které vede k jejich zatajování, nebo měření času stráveného v editoru, které lze obejít trivialitou.
Goodhartův zákon shrnuje tento problém: jakmile se ukazatel stane cílem, přestává být dobrým ukazatelem. Každá metrika bude dříve nebo později manipulována, pokud na ní závisí osobní hodnocení nebo odměna. Kvalitní program měření s touto skutečností počítá od začátku.
Druhým extrémem je naprostá absence dat. Tým, který se rozhoduje pouze na základě intuice, přehlíží zhoršující se trendy, dokud nepřerostou v krizi. Vyvážený přístup spočívá v pečlivém výběru malého počtu ukazatelů, které otevírají rozhovor a ukazují směr.
2. Metriky kvality kódu
Cyklomatická komplexita měří počet nezávislých cest skrz funkci a slouží jako indikátor obtížnosti údržby a testování. Funkce s komplexitou do pěti je obvykle snadno čitelná, hodnoty mezi šesti a deseti odpovídají běžnému kódu, hodnoty nad dvacet značí riziko a vše nad padesát je prakticky neudržovatelné. Sledování trendu komplexity v čase odhaluje postupný rozklad kvality dříve, než se projeví na rychlosti dodávek.
Duplicita kódu představuje druhý základní ukazatel. Rozlišuje se přesná shoda, sémantická duplicita a strukturální vzory. Vysoká duplicita zvyšuje náklady na údržbu, šíří chyby napříč kódem a komplikuje refaktoring. Cílem není nulová duplicita za každou cenu, ale udržení podílu duplicit pod definovaným prahem, typicky kolem tří procent v novém kódu.
Pokrytí testy bývá přeceňováno. Vysoké procento pokrytí samo o sobě negarantuje, že testy skutečně chytí chyby. Doplňujícím ukazatelem je takzvané mutační testování, které do kódu vkládá drobné změny a kontroluje, zda je testy odhalí. Mutační skóre nad osmdesát procent svědčí o testech, které skutečně testují chování, nejen procházejí kódem.
3. Technický dluh v obchodních termínech
Pro vedení společnosti není relevantní, že má systém několik tisíc problematických míst v analyzátoru kódu. Relevantní je, kolik to stojí. Metodika SQALE převádí technické problémy na odhadovaný čas potřebný k jejich nápravě. Po vynásobení interními nebo externími sazbami získává firma přímý finanční odhad dluhu.
Stejně důležitý je takzvaný úrok z dluhu, tedy průběžné náklady plynoucí z toho, že dluh nebyl splacen. Projevují se zpomalením rychlosti vývoje, zvýšenou chybovostí, prodloužením zaškolování nových členů týmu a zvýšením fluktuace. Tým s rozsáhlým technickým dluhem dodává nové funkce typicky o desítky procent pomaleji než tým s čistým kódem.
Strategie splácení dluhu vyhrazuje pevný podíl kapacity, obvykle dvacet procent, na trvalou údržbu kvality. Tento podíl zachycuje takzvané pravidlo skauta, podle kterého má být kód po každé změně čistší než před ní.
4. Procesní metriky DORA
Výzkumný program DORA identifikoval čtyři ukazatele, které spolehlivě odlišují elitní inženýrské organizace od průměrných. Frekvence nasazení udává, jak často tým posouvá kód do produkce. Elitní týmy nasazují vícekrát denně, slabé týmy jednou za půl roku či méně.
Doba od kódování k nasazení vyjadřuje plynulost dodávkového řetězce. Elitní týmy dosahují méně než hodiny od potvrzení změny po její nasazení, slabé týmy potřebují měsíce. Klíčové je úzké hrdlo: nejvíce času typicky pohlcuje čekání na přezkum a manuální testovací kroky.
Míra selhání nasazení měří podíl změn, které způsobí incident v produkci. Elitní týmy se drží pod patnácti procenty, slabé týmy překračují polovinu. Vysoká hodnota signalizuje slabou automatizaci testování a nedostatečné prostředí před nasazením.
Doba obnovy služby ukazuje, jak rychle dokáže tým reagovat na incident. Elitní týmy se vracejí do funkčního stavu během minut díky automatickému vrácení změn a kvalitnímu monitoringu, slabé týmy potřebují dny.
5. Metriky zdraví týmu
Vedle technických ukazatelů je nutné sledovat zdraví lidí. Faktor přejetí autobusem označuje minimální počet členů týmu, jejichž odchod by ochromil systém. Hodnota jedna představuje kritické riziko a vyžaduje okamžité opatření v podobě párového programování, dokumentace a rotace na klíčových modulech.
Změnová aktivita souborů, takzvaný churn, odhaluje místa, která se mění příliš často a tím signalizují nestabilitu nebo špatný návrh. Soubory s vysokou frekvencí změn a zároveň vysokou komplexitou jsou kandidáty na refaktoring s nejvyšší prioritou.
Dalším důležitým ukazatelem je čas na obnovení po přerušení. Vývojář potřebuje zhruba patnáct minut soustředění, aby se dostal do produktivního stavu. Pokud je v denním kalendáři roztříštěn více než z poloviny, jeho efektivita prudce klesá. Sledování poměru souvislého času k fragmentovanému poskytuje data pro úpravu pracovního prostředí.
6. Tvorba přehledu pro různé role
Stejná data slouží různým rolím v různé podobě. Technický ředitel sleduje měsíční trendy technického dluhu, produktivity týmu a spolehlivosti systému. Produktový manažer pracuje s rychlostí dodávky funkcí, kvalitou v očích zákazníka a dopadem na obchodní ukazatele. Inženýrský manažer se zaměřuje na denní operace a zdraví týmu. Generální ředitel potřebuje stručný měsíční přehled obchodního dopadu a klíčových rizik.
Doporučenou strukturou je vícevrstvý přehled, ve kterém vyšší vrstvy zobrazují agregované zdravotní indikátory a umožňují propracování do detailů. Každá metrika v přehledu musí mít definovanou prahovou hodnotu pro akci a jasného vlastníka. Ukazatel bez vlastníka časem zaniká, protože se na něj nikdo nedívá.
7. Deset zásad pro práci s metrikami
Praxí osvědčené zásady tvoří jádro úspěšného programu. Začínat obchodní otázkou, ne technickou možností. Měřit týmy, ne jednotlivce, aby se předešlo soutěžení. Automatizovat sběr, protože manuální metriky do tří měsíců umírají. Sledovat trendy, nikoli absolutní hodnoty. Vyvažovat předstihové a zpožděné indikátory.
Držet portfolio malé. Šest jasných ukazatelů přináší více než čtyřicet sedm rozsáhlých. Zajistit, aby tým metriky denně viděl. Počítat s manipulací a navrhovat ukazatele tak, aby manipulace byla viditelná. Pravidelně přehodnocovat, co se dříve osvědčilo, nemusí platit dnes. Pamatovat na lidský rozměr: metriky slouží lidem, nikoli naopak.
Závěr
Nejlepší metriky postupně mizí do pozadí a umožňují týmu soustředit se na hodnotu pro zákazníka. Nejhorší metriky se stávají cílem samy o sobě a nahrazují skutečný cíl práce. Cestou ke zralé inženýrské organizaci je trpělivý výběr několika málo ukazatelů, jejich automatizovaný sběr a pravidelný rozhovor nad výsledky. Metriky jsou kompas, který ukazuje směr, ale samotnou cestu musí ujít tým.
Reference
- Fenton, N., Bieman, J.: Software Metrics: A Rigorous and Practical Approach
- Forsgren, N., Humble, J., Kim, G.: Accelerate
- DORA State of DevOps Reports — https://dora.dev/
- Fowler, M.: Technical Debt Quadrant — https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
- SonarQube — https://sonarqube.org/
- PITest (mutační testování) — https://pitest.org/
- Stryker — https://stryker-mutator.io/
