Az öt legjobb szoftverfejlesztési KPI, és hogyan csalnak

Bill Harding,Programozó/CEO
Megjelent 2020. március 31-én.Utolsó frissítés 2020. április 17-én.

Amikor a mérnöki KPI-kről beszélnek, gyakran hallani két egymásnak ellentmondó közhelyet:

Amit mérnek, az javul.-Peter Drucker

És

Amikor egy intézkedés céllá válik, megszűnik jó intézkedésnek lenni.Goodhart törvénye

Mindkét állítás részben a mérnöki KPI-ket írja le, de együttesen azt sugallják, hogy a mérés segítségével lehet javítani. Hogyan hidalhatja át ezt a szakadékot egy adatvezérelt vezető?

A rossz hír az, hogy némi elkötelezettséget igényel a tanulás iránt, különösen azok számára, akik távoli (azaz nem műszaki) szerepekből érkeznek.A jó hír az, hogy a gondosan kiválasztott mérőszámok a “célponttá válás” ellenére is működhetnek és működnek is. Sőt, az általunk ajánlott mérőszámok közül sok esetében minél többet “játszik a rendszerrel” egy alkalmazott, annál inkább szolgálja az üzlet hosszú távú érdekeit. A végcél olyan mérőszámok, amelyek továbbra is jól működnek, miközben “kijátsszák” őket. Öt olyan mérőszám van, amely megfelel ennek a követelménynek.

Célközönség:

Minden olyan vezető, aki próbált már több befejezett jegyet kicsikarni a mérnöki csapatából, ismeri a küzdelmet.Igazságos, adatokkal alátámasztott intézkedéseket akarnak tenni, amelyek javítják a sebességet. Tudják, hogy a megérzéseken alapuló döntések meghozatala költséges és nem skálázható. Mégis, ha ránéznek a teendőik listájára, az tele van olyan feladatokkal, amelyek sürgetőbbnek tűnnek, mint a “mérés javítása”. A gyakorlatban a mérés felkarolása gyakran egy katasztrofális kudarc után történik, mint például egy hibás kiadás, vagy amikor észreveszik, hogy egy fejlesztő egy hónapig nem zárt le egyetlen jegyet sem.

Még ha egyértelmű is, hogy mérésre van szükség, nem egyértelmű, hogy hol kezdjük. A Google “mérnöki KPI-k” kifejezésre kattintva végigkattinthatod a találatok első oldalát, és továbbra sem tudod, hogy milyen további lépéseket kell tenned. Vegyük például a gyakran emlegetett “Team Velocity” mérőszámot. Szinte minden Google találat a “Team Velocity” mérését ajánlja, de senki sem akarja megmondani, hogy ezt… lezárt jegyekben mérik-e? Kódsorokban? Történeti pontokban? Bármi legyen is az, a menedzsereknek nincs idejük kitalálni. Le kell jutniuk ebből a 15 000 láb magas elmélethegyből valami olyasmire, amit megérthetnek, amiben megbízhatnak, és amiből hasznot húzhatnak… lehetőleg azonnal.

A cikk szervező előfeltevése az, hogy Ön olyan menedzser, aki szeretné megérteni a szoftvermérnöki méréseket, de csak annyira, hogy hatékonyabbá tegye a csapatát. Vezetőnek lenni azt jelenti, hogy túlságosan elfoglalt vagy ahhoz, hogy elméletet tanulj, kivéve, ha az közvetlenül kapcsolódik ahhoz, hogyan profitálhatsz az elméletből.

A metrikáknak gyakorlatiasnak kell lenniük, hogy valódi vállalkozások kipróbálhassák őket

A cikk megírása előtt megemésztettük a Google első 20 találata által javasolt metrikákat aszoftvermetrikák területén. Amint azt elképzelheti, minden forrásnak megvolt a saját elmélete arról, hogy mely mérőszámok a legfontosabbak.Cikkeik gyakran csoportosították a mérőszámokat olyan csoportokba, mint a “folyamatmérőszámok” és a “projektmérőszámok”. Mi is követjük a metrikák csoportosítását, de a mi csoportjaink a “minőségi metrikák” és a “minden más” lesznek.”

Íme, mi minősül minőségi metrikának:

  • Üzleti érték.Lehetséges-e egyenes vonalat húzni a metrika => létrehozott üzleti értékből?
  • Mérhető.Meghatározhatunk egy konkrét számot és annak mértékegységét (pl., pont, százalék), hogy időben nyomon követhető legyen, és összefüggésbe hozható legyen az eseményekkel és kísérletekkel?
  • Akcióképes.Rendszeresen tájékoztathat olyan cselekvésekről, amelyek pozitív eredményekhez vezetnek? Lehetőleg minimális hamis pozitív eredményekkel?
  • Elérhető/kényelmes.Egy átlagos szoftverfejlesztő csapat hozzáférhet ehhez a mérőszámhoz anélkül, hogy megváltoztatná a meglévő fejlesztési folyamatait?
  • Népszerű.Van elég követője ahhoz, hogy jól dokumentált és hiteles legyen?
  • A “Minőségi mérőszámok” vödörbe való felvételhez mind az öt fenti feltételnek teljesülnie kell, valamint kielégítő választ kell adnia az alábbi kérdésre:ha megbízunk ebben a mérőszámban, és a fejlesztők később optimalizálnak rá, akkor mi történik?A saját fejlesztési mérőszámunk (“Line Impact”) kialakításával és iterálásával töltött évek során megtanultuk, hogy a mérés várható következménye a mérgező melléktermék, hacsak a mérőszám nincs pontosan összehangolva a hosszú távú üzleti értékkel.Később példaként bemutatjuk, hogy a “Átfutási idő” mérőszámot kijátszani próbáló fejlesztők hogyan csökkentik az átláthatóságot a vezetőség számára.

    minőségi mérnöki KPI-k

    Itt van öt olyan szoftveres mérőszám, amely minden szempontból segít a vezetőknek hatékonyabb csapatot vezetni.

    🏦 OKR-vezérelt

    Példa OKR sablon

    Egy a sok példa OKR sablon közül, amely a Weekdone-on keresztül elérhető az Okrexamples.com oldalon

    Minden olyan lista, amely az üzleti érték maximalizálására összpontosít, itt kellene, hogy kezdődjön. Az olyan vezető vállalatok, mint a Google, az OKR-eket elsődleges tengelyként használják a vezető mérnökök értékeléséhez. Az OKR-alapú mérőszámok hátránya, hogy definíciójuknál fogva specifikusak az üzleti sajátosságokra. Ez lehetetlenné teszi egy olyan formula általánosítását, amellyel megragadhatók, vagy annak az útnak az általánosítását, amelyen keresztül kijátszhatók.

    Hogyan lehet kijátszani?Az OKR-ek kijátszásának kockázata alacsony, mivel általában üzletközpontúak. Az OKR-alapú mérőszámok fő veszélye az, hogy mivel jellemzően egyszeri (vagy időszakos) alapon kerülnek megfogalmazásra, talán kevésbé megbízhatóak, mint az évek során átvilágított mérőszámok. Mindig leselkednek lehetséges szélsőséges esetek.Például, ha egy OKR-t úgy állítunk be, hogy “havonta kevesebb mint 10 hibát vezessünk be”, azt úgy lehet kijátszani, hogy nem indítunk be új funkciókat. Feltételezve, hogy mindkét fél jóhiszeműen cselekszik, az OKR kijátszása a gyakorlatban ritkán fordulhat elő.

    Hogyan szerezhetjük meg?A meglévő mérési műszerfalakon keresztül, vagy olyan cégekkel együttműködve, mint a Weekdon, amelyek segítenek OKR inspirációt nyújtani.

    📐Line Impact

    Példa mérnöki KPI Line Impact: megbízható forráskód metrika

    10 repos grafikonon a Line Impact, egy metrika, amely számszerűsíti a forráskód fejlődésének ütemét,kép a GitClear jóvoltából

    ALine Impact egy olyan metrika, amely azt méri, hogy mennyi kognitív energia kerül a szoftverfejlesztésbe.Ez a videó illusztrált magyarázatot nyújt arra, hogy ez hogyan lehetséges. A rövid magyarázat az, hogy a Line Impact kiiktatja az összes köztes tevékenységet (“churn”), ami egy-egy funkció fejlesztése során történik, és így egy koncentrált megtestesülése marad a végzett munkának. A Line Impact konzerválódik a különböző nyelveken, így a Line Impact előállításához azonos mennyiségű időre van szükség, akár Java, Python, Javascript, vagy bármely más nagyobb programozási nyelven (több mint 30 támogatott) ír a fejlesztő.

    A Line Impact az üzleti érték szempontjából párhuzamos a Story Points-hoz: azt mutatja, hogy egy feladat költsége hogyan ingadozik attól függően, hogy melyik fejlesztőre bízzák. Ebből kiindulva egy elkötelezett menedzser a Domain Experts jelentést használhatja arra, hogy a Jiras-t a témával foglalkozó szakértőkhöz illessze, ami drámaian felgyorsíthatja a termék sebességét.

    Hogyan játsszunk vele?Minden olyan mérőszámot, amely a “Lines of Code” (LoC) adatforrást használja (mint a Line Impact), óvatosan kell megközelíteni. Ha gondatlanul alkalmazzák, a feldolgozás apró tökéletlenségei felnagyítódnak, ami kiszorítja a jeleket.Ezért építette a GitClear a legjobb kódellenőrző eszközöket a piacon:így a vezetők és a fejlesztők áttekinthetik, hogy a Line Impact hogyan kerül kiosztásra commitonként és fájlonként.Az átláthatóság hatásos ellenszer a játék ellen.

    A további védelem olyan értesítések formájában érhető el, amelyek akkor lépnek működésbe, amikor egy fejlesztő szokatlan sebességgel járul hozzá a munkához. Ezek és más intézkedések eléggé megnehezítették a Line Impact kijátszását ahhoz, hogy a GitClear még nem kapott olyan ügyfelet, aki arról számolt volna be, hogy a csapatuk sikeresen kijátszotta volna a Line Impactet.Ennek ellenére álságos lenne azt állítani, hogy a mérőszámot valahogy nem lehet kijátszani, ezért itt van egy lista az ismert utakról, amelyeken keresztül gyors Line Impact-et lehet gyűjteni.A lényeg az, hogy ha egy fejlesztő teszteket ír, régi kódot töröl és dokumentációt ad hozzá, akkor a Line Impact jelentős részét ki fogja érdemelni.

    Hogyan szerezze meg?Regisztráljon a 15 napos ingyenes próbaverzióra. Ha megtetszett,az árak aktív fejlesztőnként 9 dollárnál kezdődnek.Itt láthat egy rövid magyarázó videót a Line Impactről.On prem verzió elérhető.

    🎲 Story Points

    mérnöki KPI-k: Jira burndown report

    Story Point alapú “release burndown” jelentés,elérhető a Jira-n keresztül

    A Story Points a mérnöki KPI-k közül a legklasszikusabbnak mondható. A Story Points kiszámításának számos különböző módja van. Minden formája visszavezethető a fejlesztők valamilyen feladat elvégzéséhez szükséges várható idő becslésére. A menedzserek a Story Pontok segítségével kiszámíthatják a feladathoz kapcsolódó költségeket, pl. ha egy fejlesztő 10 000 $/hó keres, a jegy becsült értéke 10 Story Pont = fél hónap, akkor a költség 10 000 $ * 0,5 = 5 000 $.Ennek a számításnak valamilyen változata segít a feladatok rangsorolásában aszerint, hogy melyek adják a legmagasabb arányt aProjected Value/Projected Implementation Cost (Előrejelzett érték/előrejelzett megvalósítási költség) között.

    Hogyan játszunk vele?A legtöbb figyelmet itt a Story Pontok kiszámításának módjára kell fordítani. A Story Points “kijátszásának” legegyszerűbb módja az, ha a fejlesztőcsapat torzítja az értékelési skálát, általában a nehézség túlbecslése felé. Az egyik lehetőség ennek kezelésére az, hogy a feladatokat egy “feladatpiacon” lehet kiválasztani, ahol a túlértékelt feladatokat egyenletesen szét lehet osztani a fejlesztők között a relatív kalibráció fenntartása érdekében. Egy másik lehetőség ennek kezelésére az, hogy rendszeresen újrakalibrálják a sztori pontok “fejlesztői napokra” történő átváltásához használt állandót. Ne feledje, hogy mivel a Story Points megvalósítása gyakran csapatonként eltérő, nem tanácsos a csapatközi teljesítmény összehasonlítására használni.

    Hogyan szerezze meg?A GitHub legtöbb problémakövetője lehetővé teszi a Story Points megadását. A megtekintésüket illetően a Jira egy “next-gen velocity report”-ot kínál, amely kifejezetten a teljesített Story Points időbeli bemutatására szolgál.Kínálnak egy “release burndown report”-ot is, amely a Story Points segítségével megbecsüli, hogy a csapat hogyan halad a sprint céljai felé. A GitClear kezdetleges (egyelőre) grafikonokat is kínál, amelyek az idő múlásával teljesített Story Pontokat szemléltetik.

    🐞 Bug Rate / Escaped Defects

    Ezt a mérőszámot különböző források különböző módon határozzák meg, de mind ugyanazt az alapvető kérdést célozzák meg: hány hiba kerül ki a világba, és mennyire jól reagálunk rájuk?A Stackify konkrét számokkal fejezi ki ezt:

    A hibaelkerülési arányt százalékban fejezzük ki az alapján, hogy hány hibát találunk, mielőtt a gyártásba kerülnének, vagy hány hiba jut el a gyártásig, ahogy tetszik. Minden szoftverprojekt és csapat más és más lesz, de azt javasoljuk, hogy törekedjünk arra, hogy a hibák 90%-át megtaláljuk, mielőtt azok a gyártásba kerülnek.

    A Stackify definíciója feltételezi, hogy valaki kijelöl egy mezőt a hibakövetésben, hogy rögzítse, a fejlesztés melyik fázisában történt a hiba. Azoknak a csapatoknak, amelyeknek nincs idejük a fejlesztési fázisok beállítására és nyomon követésére, egy helyettesítő definíció lehet:

    Hányszor válik egy új funkcióban írt kód egy hiba megoldása során módosított kóddá?

    Ezekre a kérdésekre a GitClear felhasználóknak adathoz kötött választ adunk, de manuálisan nehéz kiszámítani (ha nem vagy GitClear felhasználó).A hibaarány garantáltan rendelkezésre álló tartalék mérése lehet a “mi a létrehozott hibák és a megoldott hibák aránya”?

    Hogyan lehet kijátszani?Ezt a mérőszámot nehéz kijátszani. Egy fejlesztő több kis jegyet is elvállalhat, de minden egyes jegy a hibák növekvő kockázatát hordozza magában, ha nem vigyáz. A hibaarány használatának kockázata az, hogy szükség van egy ellensúlyra a “fejlődéshez”, mint például a Story Points vagy a Line Impact, különben egy fejlesztő az egész sprint alatt egyetlen problémával foglalkozhat, biztosítva a 0%-os hibaarányt.

    Hogyan kapható?Ha a csapata rendelkezik a sávszélességgel, hogy a problémákat a fejlesztés azon fázisa szerint címkézze, amelyben felmerültek, akkor aEscaped Defects manuálisan kiszámítható bármelyik problémakövetőn keresztül. A GitClear egy másik elérhető lehetőség a hibákká vált funkciók százalékos arányának kiszámítására.

    ✅ Pull Request Completion Rate

    Példamérnöki KPI Pull Requests: statisztikák a GitClear-on

    A GitClear által szolgáltatott pull request statisztikákból vett minta

    A pull request-ek hány százalékát zárták le a megnyitást követő egy héten belül? Ez több részletesebb kérdést is felvet, mint például “a csapat elkötelezett abban, hogy azonnal válaszoljon az új pull-kérelmekre”, “képesek-e együttműködni” és “a fejlesztők csiszolták-e a kódjukat, mielőtt beadták volna egyesítésre?”

    Hogyan játsszuk ki?A “Pull request completion rate” teszt teljesítése azt jelenti, hogy mindig egy héten belül lezárjuk a PR-eket. Ezt viszonylag nehéz kijátszani, de ellensúlyozni kell egy olyan hajtóerővel, mint a Story Points vagy a Line Impact, különben a csapat minden ösztönzője az lesz, hogy inkább csiszolja a munkát, mintsem hogy elküldje (vagy PR felülvizsgálatra adja be).

    Hogyan lehet elérni?Az összes “neves” Engineering Insight szolgáltató (GitClear, Pluralsight, Code Climate, Pinpoint) kínálstatisztikákat, amelyek szemléltetik a csapat pull request folyamatának hatékonyságát.Itt segítünk összehasonlítani a szolgáltatókat.

    Honorable mentions

    A “top tier” metrikák alatt találunk egy köztes szintet. Ezek olyan mérőszámok, amelyekkívánatos tulajdonságokkal rendelkeznek a fontos hiányosságok mellett. Még mindig értéket nyújthatnak, amennyiben egy menedzser eléggé tisztában van a korlátaikkal.

    Lead Time/Cycle Time

    Lead Time graph as visualized via Azure Devops

    Míg a listán szerepel (kétszer!) aPluralsight Top 5 Metrics listáján, a Cycle Time egy jó ötlet, amely nagyon érzékeny a játékra.

    A “Lead Time”-ot leggyakrabban úgy definiálják, hogy “Mennyi az az időintervallum, amikor egy feladatot iktatnak az issue trackerben és amikor azt átadják az ügyfélnek?”. Unokatestvére, a “Cycle Time” a Lead Time egy részhalmaza, amelyet úgy határoznak meg, hogy “az az idő, amely a termékcsapat által a sorból való kiemelés és a gyártásba kerülés között telik el.”

    Hogyan játszhatunk vele?A Lead Time teljesítménye bizonyos mértékig attól a mechanizmustól függ, amellyel a Jiras iktatásra kerül, ami azt jelenti, hogy a csapatok közötti alkalmazhatósága alacsony. A Cycle Time attól függ, hogy a committer milyen konvenciók szerint választja az első commitot. Így ez a mérőszám könnyen kijátszható, ha egy fejlesztő helyben elmenti a commitjait, és közvetlenül a PR benyújtása előtt egy munkafolyamatban kiadja őket. Ez a hiba az, ami a Cycle Time-ot a “Tiszteletre méltó említések” szekcióba sorolja. Szintén nem ideális: azáltal, hogy a fejlesztőt arra ösztönzik, hogy a commitjait nyomkodás nélkül mentse el, a csapattársaknak lehetetlen beavatkozniuk, amíg a munka folyamatban van.Ez a mellékhatás csökkenti az átláthatóságot a menedzser és a fejlesztők között.

    Hogyan szerezhetjük meg?Az Azure Devops Services biztosítja a fenti grafikont.A Jira is kínálja ennek egy változatát.Az összes nagyobb Engineering Insight ajánlat (GitClear, Pluralsight, Code Climate Velocity, Pinpoint) implementálja a Lead Time számítás valamilyen változatát.

    Tesztlefedettség

    A tesztlefedettség bizonyos mértékének megragadása ésszerű cél. Ez azonban két okból nem éri el a Top Tier mérőszámok közé való besorolást:

  1. Ez egy hiányos megoldás. A megfelelő tesztelésnek az egységtesztek mellett funkcionális és integrációs teszteket is tartalmaznia kell, és egyetlen automatizált megoldás sem tudja, hogy mely oldalakat kell meglátogatni az alkalmazáson vagy weboldalon belül, ehhez még mindig emberi irányításra van szükség
  2. Ez nagyon nehezen kapcsolható vissza a top-line üzleti mérőszámokhoz. A tesztlefedettséget érdemes értékelni a vezető fejlesztő tervének részeként a kódminőség nyomon követésére, de nem kapcsolódik eléggé közvetlenül az üzleti értékhez ahhoz, hogy önmagában a vágást elvégezze. Egy kapcsolódó, de inkább üzleti célú metrika a kódhibák nyomon követésére a “Bug Rate / Escaped Defects.”

“Everything Else” Metrics

A fenti lista viszonylag rövid a más szerzők által javasolt korábbi metrikák korpuszához képest.A teljesség kedvéért tekintsünk át néhányat a máshol leggyakrabban említett metrikák közül, és hogy miért nem kerültek be a válogatásba.

Team Velocity

Ez volt az egyik legnépszerűbb metrika, amelyet más cikkek idéztek. Ezt ajánlja aTechBeacon,azInfoPulseésaSeaLights.io.A szerzők azonban óvatosnak tűnnek e fontos metrika mértékegységének meghatározásában.ATechBeacon úgy definiálja, hogy “hány “egységnyi” szoftvert készít el a csapat jellemzően egy iteráció alatt”. Nem megfogható. Az InfoPulse nem próbálkozik az egységek meghatározásával. A SeaLights szerint az egységek a “Story Points”. Így arra a következtetésre jutottunk, hogy a “sebesség” fogalmát a Story Points vagy a Line Impact megfelelően megragadja.

Code Churn

A GitPrime (amelyet most a Pluralsight felvásárolt) vezérigazgatója is azok közé tartozott, akik a Code Churn figyelembevétele mellett érveltek.Válaszul azzal érvelünk, hogy a Code Churn következményei mindenhol a térképen vannak, ami nagyon nehézzé teszi a magas elvándorlás elleni fellépést. A mérőszámoknak cselekvőképesnek kell lenniük.

Release/Sprint Burndown

A SeaLights és az InfoPulse azt ajánlja, hogy figyeljünk arra, hogy a csapat hogyan halad a sprint céljai felé.Egyetértünk azzal, hogy ez fontos, de a fenti “Story Points” szakasz már foglalkozik vele.

Mean time to repair / Mean time between failures

Az e mérőszámokat népszerűsítő maroknyi cikkek közül egyik sem merészkedik bele annak leírásába, hogy milyen egységeken alapul a mérőszám, vagy milyen szolgáltatást lehet használni ezen adatpontok összegyűjtésére.A kutatás szerint az Atlassian egy segédcikket kínál a témában.Ha ez a cikk nem lenne már 2500 szó hosszú, az MTTR bekerülhetne a “Honorable Mentions” szakaszba. De nem könnyű visszavezetni az üzleti értékhez, és egy átlagos csapat számára sem egyszerű hozzáférni a rutinok megváltoztatása nélkül.

Maradtunk le valamiről?

Leave a Reply

Vélemény, hozzászólás?

Az e-mail-címet nem tesszük közzé.