Pět nejlepších klíčových ukazatelů výkonnosti v softwarovém inženýrství a jak se podvádí

Od Billa Hardinga,programátora/výkonného ředitele
Vydáno 31. března 2020.Poslední aktualizace 17. dubna 2020.

Když se mluví o inženýrských klíčových ukazatelích výkonnosti, často lze zaslechnout dva protichůdné truismy:

Co se měří, to se zlepšuje.-Peter Drucker

A

Když se z měřítka stane cíl, přestává být dobrým měřítkem.Goodhartův zákon

Obě tato tvrzení částečně popisují inženýrské KPI, ale dohromady naznačují, že je možné použít měření ke zlepšení. Jak může manažer, který se řídí daty, překlenout tuto propast?“

Špatnou zprávou je, že to vyžaduje určité odhodlání učit se, zejména pro ty, kteří přicházejí ze vzdálených(tj. netechnických) rolí. dobrou zprávou je, že pečlivě zvolené metriky mohou fungovat a fungují i přesto, že se „stanou cílem“. U mnoha metrik, které vám doporučíme, platí, že čím více si zaměstnanec „hraje se systémem“, tím více to slouží dlouhodobým zájmům podniku. Konečným cílem jsou metriky, které nadále fungují, i když se s nimi „hraje“. Tuto laťku splňuje pět metrik.

Cílová skupina: Akčně smýšlející manažer

Každý manažer, který se snažil ze svého inženýrského týmu vytáhnout více dokončených tiketů, zná ten boj. chce přijmout spravedlivá, daty podložená opatření, která zlepší jejich rychlost. Vědí, že rozhodování na základě instinktů je drahé a neškálovatelné. Přesto když se podívají na svůj seznam úkolů, je plný úkolů, které se zdají naléhavější než „zlepšit měření“. V praxi k zavedení měření často dochází až po katastrofickém selhání, jako je chybné sestavení verze nebo zjištění, že vývojář už měsíc neuzavřel žádné tikety.

I když je jasné, že je třeba měření zavést, je nejednoznačné, kde začít. Můžete zadat do Googlu „inženýrské KPI“, proklikat se celou první stránkou výsledků a zůstat v nejistotě, jaké další kroky podniknout. Vezměme si jako příklad často uváděnou metriku „rychlost týmu“. Téměř každý výsledek na Googlu doporučuje měření „Team Velocity“, ale nikdo nechce říct, zda se měří v… uzavřených tiketech? V řádcích kódu? Příběhových bodech? Ať už je to cokoli, manažeři nemají čas to zjišťovat. Potřebují se dostat z této patnáctitisícové hory teorie dolů do něčeho, čemu mohou rozumět, čemu mohou věřit a z čeho mohou mít užitek… nejlépe okamžitě.

Organizačním předpokladem tohoto článku je, že jste manažer, který chce porozumět softwarovému inženýrstvímetrice natolik dobře, aby byl váš tým efektivnější. Být manažerem znamená, že jste příliš zaneprázdněni na to, abyste se učili o teorii, s výjimkou případů, kdy to přímo souvisí s tím, jak můžete z této teorie těžit.

Metriky musí být praktické, aby je mohly vyzkoušet skutečné podniky

Před napsáním tohoto článku jsme strávili metriky navržené 20 nejlepšími výsledky Google v oblasti softwarových metrik. Jak si asi dokážete představit, každý zdroj měl své vlastní teorie o tom, které metriky jsou nejdůležitější. jejich články často rozdělovaly metriky do skupin jako „procesní metriky“ a „projektové metriky“. Budeme se řídit jejich názorem na seskupování metrik, ale naše skupiny budou „metriky kvality“ a „vše ostatní“.

Tady je uvedeno, co lze kvalifikovat jako metriku kvality:

  • Obchodní hodnota. je možné nakreslit přímku z metriky => vytvořené obchodní hodnoty?
  • Měřitelné. můžeme definovat konkrétní číslo a jeho měrné jednotky (např, body, procenta), aby ji bylo možné sledovat v časea korelovat s událostmi a experimenty?
  • Akční.Může pravidelně informovat o opatřeních, která vedou k pozitivním výsledkům? Nejlépe s minimem falešně pozitivních výsledků?
  • Dostupná/pohodlná.Může průměrný tým softwarových inženýrů získat přístup k této metrice, aniž by musel měnit své stávající vývojové procesy?
  • Populární.Má dostatek příznivců, aby byla dobře zdokumentovaná a důvěryhodná?
  • Zařazení do kategorie „Metriky kvality“ vyžaduje všech pět výše uvedených bodů a uspokojivou odpověď na naši otázku:pokud této metrice věříme a vývojáři ji následně optimalizují, co se stane potom?Během let strávených vytvářením a iterací naší vlastní vývojové metriky („Line Impact“) jsme se naučili, že toxické vedlejší produkty jsou očekávaným důsledkem měření, pokud není metrika přesně sladěna s dlouhodobou obchodní hodnotou.Jako příklad si později ukážeme, jakvývojáři, kteří se snaží hrát si s metrikou „Lead Time“, způsobují sníženou transparentnost pro management.

    Kvalitní inženýrské KPI

    Tady je pět softwarových metrik, které zaškrtávají všechny položky a pomáhají manažerům vést efektivnější tým.

    🏦 OKR-driven

    Ukázková šablona OKR

    Jedna z mnoha ukázkových šablon OKR, které jsou k dispozici prostřednictvím Weekdone na adrese Okrexamples.com

    Každý seznam, který je zaměřen na maximalizaci obchodní hodnoty, by měl začít zde. Přední společnosti, jako jeGoogle, používají OKRjako hlavní osu, podle které hodnotí vedoucí inženýry. Nevýhodou metrik založených na OKR je, že jsou z definice specifické pro obchodní specifika. To znemožňuje zobecnit vzorec, podle kterého by se daly zachytit, nebo zobecnit cestu, kterou se budou hrát.

    Jak je hrát?Riziko, že se budou OKR hrát, je nízké, protože jsou obvykle zaměřeny na podnikání. Hlavní nebezpečí metrik řízenýchOKR spočívá v tom, že vzhledem k tomu, že jsou obvykle formulovány jednorázově (nebo periodicky), jsou možná méně spolehlivé než metriky, které byly ověřovány roky. Vždy na vás číhají možné okrajové případy: Například nastavení metriky OKR na „zavedení méně než 10 chyb za měsíc“ by mohlo být zahráno tím, že nebudou spuštěny žádné nové funkce. Za předpokladu, že obě strany jednají v dobré víře, by mělo být hraní s OKR v praxi vzácné.

    Jak ho získat?Prostřednictvím existujících měřicích panelů nebo spoluprací se společnostmi, jako jeWeekdone, které pomáhají poskytovat inspiraci OKR.

    📐Line Impact

    Příklad inženýrského KPI Line Impact: spolehlivá metrika zdrojového kódu

    10 repozitářů zobrazených v grafech podle jejich Line Impact, metriky, která kvantifikuje tempo, jakým se vyvíjí zdrojový kód,obrázek se svolením GitClear

    Line Impact je metrika určená k měření toho, kolik kognitivní energie se vkládá do vývoje softwaru.Toto video nabízí názorné vysvětlení, jak je to možné. Stručné vysvětlení spočívá v tom, že Line Impact anuluje všechny mezidobí („churn“), k nimž dochází při vývoji funkce, a zanechává tak koncentrované ztělesnění vykonané práce. Line Impact se zachovává napříč jazyky, takže generování Line Impact trvá konzistentní dobu bez ohledu na to, zda vývojář píšeJavu, Python, Javascript nebo jakýkoli jiný hlavní programovací jazyk (podporováno je více než 30 jazyků).

    Z hlediska obchodní hodnoty je Line Impact obdobou Story Points: ukazuje, jakse náklady na úkol mění v závislosti na vývojáři, kterému je úkol přidělen. Na základě toho může angažovaný manažer využít sestavu Domain Experts k přiřazení Jirase k odborníkům na danou oblast, což může dramaticky urychlit rychlost produktu.

    Jak si s ní hrát?Ke každé metrice, která jako zdroj dat uvádí „řádky kódu“ (LoC) (jako Line Impact), je třeba přistupovat obezřetně. Při neopatrné implementaci se jemné nedokonalosti ve zpracování zvětšují do šumu, který vytěsňuje signál.

    Proto společnost GitClear vytvořila nejlepší nástroje pro revizi kódu na trhu: aby manažeři a vývojáři mohli kontrolovat, jak je Line Impact udáván na základě jednotlivých commitů a souborů.

    Přídavná ochrana přichází v podobě oznámení, která se spustí, když vývojář přispěje prací neobvyklou rychlostí. Tato a další opatření dostatečně ztížila hraní s nástrojem Line Impact, takže společnost GitClear zatím neobdržela zprávu od zákazníka, který by hlásil, že jeho tým s nástrojem Line Impact úspěšně hrál.Přesto by bylo neupřímné tvrdit, že je tato metrika nějak odolná proti hraní, takže zde je seznam známých cest, kterými lze získat rychlý Line Impact.Podstata spočívá v tom, že pokud vývojář napíše testy, odstraní starý kód a přidá dokumentaci, získá nezanedbatelný podíl Line Impact.

    Jak ho získat?Zaregistrujte se k bezplatné 15denní zkušební verzi. Pokud se vám zalíbí, ceny začínají na 9 dolarech za aktivního vývojáře.

    🎲 K dispozici je verze On prem.

    🎲 Story Points

    inženýrské KPI: Jira burndown report

    Story Points-based „release burndown“ report,available via Jira

    Story Points could claim to be the most „classic“ of engineering KPIs. Existujemnohorůznýchzpůsobůvýpočtu Story Points. Všechny formy se vztahují k odhadu očekávaného času vývojáře na dokončení nějakého úkolu. Manažeři mohou pomocí Story Points vypočítat náklady, které z úkolu vyplývají, např. pokud vývojář vydělá$10k/měsíc, tiket se odhaduje na 10 Story Points = polovina měsíce, pak náklady činí $10 000 * 0,5 = $5 000. Použití některé verze tohoto výpočtu pomáhá stanovit priority úkolů na základě toho, které přinášejí nejvyšší poměrProjected Value/Projected Implementation Cost.

    Jak na to?Největší pozornost zde patří tomu, jak se Story Points vypočítávají. Nejjednodušší způsob, jak „hrát“ Story Points, je, že vývojový tým zkreslí stupnici hodnocení, obvykle směrem k nadhodnocení obtížnosti. Jednou z možností, jak to řešit, je umožnit výběr úkolů na „trhu úkolů“, kde mohou být nadhodnocené úkoly rovnoměrně rozděleny mezi vývojáře, aby se zachovala relativní kalibrace. Další možností, jak to řešit, je pravidelně rekalibrovat konstantu používanou k přepočtuStory Points na „vývojářské dny“. Všimněte si, že vzhledem k tomu, že implementace Story Points se často liší podle týmů, není vhodné je používat k porovnávání výkonnosti napříč týmy.

    Jak je získat?Většina všech issue trackerů na této straně GitHubu umožňuje zadávat Story Points. Co se týče jejich zobrazení, Jira nabízí „next-gen velocity report“ určený k zobrazení splněných Story Points v čase.Nabízí také „release burndown report“, který využívá Story Points k odhadu, jak tým postupuje směrem ke svým cílům pro daný sprint. GitClear také nabízí primitivní (zatím) grafy, které ilustrují Story Pointscompleted v průběhu času.

    🐞 Bug Rate / Escaped Defects

    Tuto metriku definují různé zdroje různými způsoby, ale všechny se dostávají ke stejné základní otázce:kolik chyb se dostává do světa a jak dobře na ně reagujeme?Stackify ji vztahuje ke konkrétním číselným vyjádřením:

    Vaše míra úniku chyb je vyjádřena v procentech na základě toho, kolik chyb najdete, než se dostanou do výroby, nebo kolik se jich dostane do výroby, jak chcete. Každý softwarový projekt a tým se bude lišit, ale doporučujeme usilovat o nalezení 90 % všech závad dříve, než se dostanou do výroby.

    Definice společnosti Stackify předpokládá, že člověk označí pole ve svém systému sledování problémů, aby zachytil, v jaké fázi vývoje se chyba vyskytla. Pro týmy, které nemají čas na nastavení a sledovánífází vývoje, může být náhradní definicí:

    Jak často se kód vytvořený v nové funkci stává kódem změněným v průběhu řešení chyby?

    Na tuto otázku je uživatelům GitClear poskytována odpověď vázaná na data, ale je obtížné ji vypočítat ručně (pokud nejste uživatelem GitClear). zaručeně dostupným náhradním měřením míry výskytu chyb může být „jaký je poměr vytvořených a vyřešených chyb“?

    Jak si s ní hrát?Tuto metriku je obtížné hrát. Vývojář může převzít více malých tiketů, ale každý tiket přináší zvýšené riziko chyb, pokud si nedá pozor. Toto riziko používání míry chyb spočívá v tom, že potřebuje protiváhu pro „pokrok“, jako jsou Story Points nebo Line Impact, jinak by se vývojář mohl zdržet u jediného problému po celý sprint, čímž by si zajistil 0% míru chyb.

    Jak ji získat?Pokud má váš tým kapacitu na označování problémů podle fáze vývoje, ve které se vyskytly, pak lze ručně vypočítatEscaped Defects prostřednictvím libovolného nástroje pro sledování problémů. GitClear je další dostupnou možností, jak vypočítat procento funkcí, které se staly chybami.

    ✅ Míra dokončení žádostí o stažení

    Příklad inženýrského KPI Žádosti o stažení: statistiky na GitClear

    Ukázka statistik žádostí o stažení, které poskytuje GitClear

    Jaké procento žádostí o stažení bylo uzavřeno do týdne od otevření? To na sebe nabaluje několik podrobnějších otázek, jako například „je tým zapojen do rychlé reakce na nové žádosti o stažení“, „je schopen spolupracovat“ a „vyladili vývojáři svůj kód před odesláním ke sloučení?“

    Jak to hrát?Vyhovět testu „Míra dokončení žádostí o stažení“ znamená vždy uzavřít žádosti o stažení do týdne. To je relativně těžko hratelné, ale musí to být vyváženo hnací silou, jako jsou Story Points nebo Line Impact, jinak budou všechny pobídky týmu směřovat k tomu, aby práci raději leštili, než aby ji odeslali (nebo předložili k posouzení PR).

    Jak to získat?Všichni „značkoví“ poskytovatelé Engineering Insight (GitClear, Pluralsight, Code Climate, Pinpoint) nabízejí statistiky, které ilustrují efektivitu týmového procesu pull requestů.

    Honorable mentions

    Pod metrikami „nejvyšší úrovně“ najdeme mezistupeň. Jedná se o metriky, kterémají žádoucí vlastnosti vedle důležitých nedostatků. Stále mohou přinášet hodnotu, pokud manažer ví dost na to, aby počítal s jejich omezeními.

    Doba vedení/doba cyklu

    Graf doby vedení vizualizovaný prostřednictvím Azure Devops

    Ačkoli je uvedena (dvakrát!) v seznamu 5 nejlepších metrik společnostiPluralsight,Cycle Time je dobrý nápad, který je velmi náchylný ke hře.

    „Lead Time“ je nejčastěji definován jako „Jaký je interval mezi okamžikem, kdy je úkol založen v systému sledování problémů, a okamžikem, kdy je doručen zákazníkovi?“. Jeho bratranec, „Cycle Time“, je podmnožinou Lead Time a je definován jako „doba mezi okamžikem, kdy jej produktový tým vytáhl z fronty, a okamžikem, kdy se dostal do výroby.“

    Jak s ním hrát?Výkonnost Lead Time do jisté míry závisí na mechanismu, kterým se Jiras vyplňuje, což znamená, že jeho použitelnost napříč týmy je nízká. Cycle Time závisí na konvencích, podle kterých se revizor rozhodne provést svou první revizi. S touto metrikou se tedy dá jednoduše hrát, pokud vývojář ukládá své commity lokálně a vydává je v jednom zátahu bezprostředně před odesláním PR. Právě toto selhání odsouvá dobu cyklu do sekce „Čestné zmínky“. Také to není ideální: tím, že vývojáře motivujeme k ukládání svých commitů bez tlačení, znemožňujeme spoluhráčům zasáhnout do probíhající práce.Tento vedlejší efekt snižuje transparentnost mezi manažerem a jeho vývojáři.

    Jak jej získat?Azure Devops Services poskytuje výše uvedený graf.Jira nabízí také jeho verzi.Všechny hlavní nabídkyEngineering Insight (GitClear, Pluralsight, Code Climate Velocity, Pinpoint) implementují určitou verzi výpočtu Lead Time.

    Pokrytí testů

    Snaha zachytit určitou míru pokrytí testů je rozumným cílem, který je třeba zvážit. Jako metrika nejvyšší úrovně se však zcela nehodí ze dvou důvodů:

  1. Jedná se o neúplné řešení. Adekvátní testování musí vedle jednotkových testů zahrnovat i funkční a integračnítesty a žádné automatizované řešení nemůže vědět, které stránky je třeba navštívit v rámci aplikace nebo webu, k tomu je stále zapotřebí lidského vedení
  2. Je velmi obtížné navázat na špičkové obchodní metriky. Pokrytí testů je vhodné hodnotit jako součást plánu vedoucího vývojáře pro sledování kvality kódu, ale nesouvisí přímo s obchodními hodnotami natolik, aby to bylo samo o sobě. Související, ale více obchodně-funkční metrikou pro sledování vad kóduje „Míra chyb / uniklých defektů“.

Metriky „všeho ostatního“

Výše uvedený seznam je relativně krátký ve srovnání s korpusem minulých metrik, které navrhli jiní autoři.Pro úplnost si projděme některé z nejčastěji zmiňovaných metrik jinde a důvody, proč se do výběru nedostaly.

Týmová rychlost

Tato metrika byla jednou z nejoblíbenějších metrik citovaných v jiných článcích. Doporučují jiTechBeacon,InfoPulseaSeaLights.io.Zdá se však, že autoři si dávají pozor na definici jednotek této důležité metriky.TechBeacon ji definuje jako „kolik ‚jednotek‘ softwaru tým obvykle dokončí během jedné iterace“. Není to sotangible. InfoPulse se o specifikaci jednotek nepokouší. SeaLights říká, že jednotkami jsou „Story Points“. Došli jsme tedy k závěru, že pojem „rychlost“ je dostatečně zachycen pomocí Story Points nebo Line Impact by proxy.

Code Churn

Ředitel společnosti GitPrime (nyní převzaté společností Pluralsight) patřil k těm, kteří se zasazovali o zohlednění Code Churn.V reakci na to tvrdíme, že důsledky Code Churn jsou všelijaké, což velmi ztěžuje jednání v případě vysoké odchodovosti. Metriky musí být akční.

Release/Sprint Burndown

SeaLights a InfoPulse doporučují věnovat pozornost tomu, jak tým směřuje ke svým sprintovým cílům. souhlasíme, že je to důležité, ale již je to zahrnuto v části „Story Points“ výše.

Střední doba do opravy / Střední doba mezi poruchami

Mezi hrstkou článků, které tyto metriky obhajují, se žádný neodvažuje popsat, v jakých jednotkách je metrika založena nebo jakou službu lze ke shromažďování těchto datových bodů použít. průzkum zjistil, že společnost Atlassian nabízí na toto téma článek s nápovědou. kdyby tento článek neměl už 2 500 slov, MTTR by se mohl dostat do sekce „Čestné zmínky“. Ale není snadné je propojit s obchodní hodnotou a není jednoduché, aby k nim průměrný tým získal přístup, aniž by změnil své rutinní postupy.

Přehlédli jsme něco?

.

Leave a Reply

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.