9 mutató, amely különbséget tehet a mai szoftverfejlesztő csapatok számára

amint azt a “miért nem számítanak a mutatók a szoftverfejlesztésben (hacsak nem párosítja őket üzleti célokkal)” cikkben megjegyeztem, a mutatók kiválasztása jelentős gondolkodást és gondosságot igényel, hogy támogassa azokat a konkrét kérdéseket, amelyekre egy vállalkozásnak valóban válaszolnia kell. Itt van a kritikus pont: a méréseket csak az üzleti kérdések megválaszolásának módjaként kell megtervezni. És ezek a kérdések soha nem, ” hány KLOCs vagyunk most?”

ez a cikk ott folytatódik, ahol az előző abbahagyta, először megvitatva azokat a konkrét mutatókat, amelyeket minden csapatnak el kell kezdenie használni, vagy legalábbis azt tervezi, hogy hamarosan felhasználja az észrevehető teljesítmény javításának módját. Ne feledje, hogy a cikk címe azt állítja, hogy vannak “9 mutató, amelyek különbséget tehetnek…”—mert ami igazán fontos, ami valóban különbséget tesz, az az, hogy ezeket a mutatókat hogyan használják az üzleti érték javítására. Ez a használat rajtad múlik. Ezután Ez a cikk azzal zárul, hogy elmagyarázza, hogyan kombinálhatja ezeket a mutatókat a jelentés létrehozásához, valamint megfogalmazhatja és tesztelheti az üzleti értékhipotézist.

Kezdje a helyes dolgok mérésével

íme kilenc objektív mutató (felsoroláspontokkal jelölve), amelyeket folyamatosan figyelemmel kell kísérnie, hogy fokozatosan javítsa a folyamatokat és a termelési környezetet. Ezeknek a számoknak a javítása nem garantálja, hogy az ügyfelek elégedettségi szintje ugrásszerűen emelkedni fog. De legalább ezeket a helyes dolgokat kell mérni. A cikk egy későbbi szakaszában, “mindent összerakva,” látni fogja, miért.

agilis folyamatmérők

az agilis és lean folyamatok esetében az alapvető mutatók az átfutási idő, a ciklusidő, a csapatsebesség és a nyitási/zárási sebesség. Ezek a mutatók segítik a tervezést és tájékoztatják a folyamatok javításával kapcsolatos döntéseket. Bár nem mérik a sikert vagy a hozzáadott értéket, és semmi közük a szoftver objektív minőségéhez, mindenképpen meg kell mérni őket. Az alábbiakban elmagyarázom, miért.

• Leadtime—mennyi ideig tart Az ötlettől a szállított szoftverig. Ha jobban szeretne reagálni az ügyfeleire, dolgozzon az átfutási idő csökkentésén, általában a döntéshozatal egyszerűsítésével és a várakozási idő csökkentésével. Az átfutási idő magában foglalja a ciklusidőt.
• ciklusidő—mennyi időbe telik, amíg változtat a szoftverrendszeren, és ezt a változást a gyártásba szállítja. A folyamatos szállítást használó csapatok ciklusidejét hónapok helyett percben vagy akár másodpercben is mérhetik.
• Csapatsebesség—hány “egység” szoftver a csapat általában befejezi egy iteráció (más néven “sprint”). Ezt a számot csak iterációk tervezésére szabad használni. A csapatsebességek összehasonlítása értelmetlen, mert a metrika nem objektív becsléseken alapul. A sebesség sikermérőként való kezelése nem megfelelő, és egy adott sebesség céltá tétele torzítja annak értékét a becsléshez és a tervezéshez.
• nyitási/zárási arányok—hány termelési problémát jelentenek és zárnak le egy adott időszakon belül. Az általános tendencia fontosabb, mint a konkrét számok.

ha ezek a mutatók bármelyike vagy mindegyike a várt tartományon kívül esik, vagy riasztó irányba mutat, ne feltételezzen okot. Beszéljen a csapattal, szerezze meg az egész történetet, és hagyja, hogy a csapat eldöntse, van-e ok az aggodalomra, és ha igen, hogyan oldja meg.

a számok alapján nem lehet tudni vagy feltételezni a kiváltó okokat, de ezek a mutatók betekintést nyújtanak abba, hogy az alapvető folyamatokra hol kell figyelni. A magas nyitási arány és az alacsony zárási arány például néhány iteráció során azt jelentheti, hogy a termelési kérdések jelenleg alacsonyabb prioritást élveznek, mint az új funkciók, vagy talán azt, hogy a csapat a technikai adósság csökkentésére összpontosít, hogy teljes problémaosztályokat javítson, vagy hogy az egyetlen személy, aki tudta, hogyan kell kijavítani őket, kilép, vagy valami más. A számok alapján nem lehet tudni vagy feltételezni a kiváltó okokat.

termelési analitika

• a meghibásodások közötti átlagos idő (MTBF)
• a helyreállítás/javítás átlagos ideje (MTTR)

mindkettő a szoftverrendszer teljesítményének általános mércéje a jelenlegi termelési környezetben.

• Application crash rate—hányszor egy alkalmazás sikertelen osztva hányszor használták. Ez a mutató az MTBF-hez és az MTTR-hez kapcsolódik.

vegye figyelembe, hogy e három mutató egyike sem mesél az egyes funkciókról vagy az érintett felhasználókról. Mégis, minél kisebb a szám, annál jobb. Modern műveletek-monitoring szoftver teszi összegyűjtése részletes mutatókat az egyes programok és tranzakciók meglehetősen egyszerű, de időbe telik, és gondos gondolkodás, hogy hozzanak létre megfelelő tartományok riasztások és/vagy kiváltó méretezés felfelé vagy lefelé (a felhő-alapú rendszerek).

szeretnénk, ha a szoftverünk soha nem bukna meg, de ez statisztikailag valószínűtlen. Ha a szoftverünk meghibásodik, azt szeretnénk, hogy soha ne veszítse el a kritikus adatokat, és azonnal helyreálljon, de ezt rendkívül nehéz elérni. Ha a szoftver a bevételi forrása, azonban, az erőfeszítés érdemes.

az MTBF-en és az MTTR-en túl a finomszemcsésebb mérések egyedi tranzakciókon, alkalmazásokon és így tovább alapulnak, és tükrözik a szállított üzleti értéket és a hibák kijavításának költségeit. Ha a tranzakció-feldolgozó alkalmazás százból egyszer összeomlik, de egy-két másodperc alatt felépül, és nem veszít kritikus információkat, akkor az 1 százalékos összeomlási arány elég jó lehet. De ha minden összeomlás egy olyan alkalmazásból származik, amely napi 100 000 tranzakciót futtat, 100 dolláros eladást veszít, és 50 dollárba kerül a hátsó végén, akkor az 1 százalékos összeomlási Arány prioritás lesz. A rögzítés jelentősen befolyásolja az alsó sort.

biztonsági mutatók

a biztonság a szoftver minőségének olyan aspektusa, amelyet gyakran később (vagy túl későn) figyelmen kívül hagynak. A biztonsági elemzési eszközök felhasználhatók az építési folyamatban, a speciálisabb értékelések és stressztesztek mellett. A biztonsági követelmények gyakran egyszerűek és általánosak, de a szoftverfejlesztő csapatnak figyelembe kell vennie őket és az ezekből levezetett mutatókat.

a biztonsági gyakorlatok és a kapcsolódó mutatók teljes skálája túlmutat a cikk hatályán, de az agilis folyamatmérőkhöz és a termelési mutatókhoz hasonlóan van néhány konkrét mutató, amelyek sokat jelenthetnek az ügyfelek általános elégedettségéhez.

• végpont események—hány végpont (mobil eszközök, munkaállomások stb.) tapasztalt vírusfertőzést egy adott időszak alatt?
• MTTR (mean time to repair)—a biztonsági mutatókban ez az idő a biztonsági rés felfedezése és a telepített, működő javítás között. A fent említett gyártási MTTR mutatóhoz hasonlóan a biztonsági MTTR-t meghatározott időintervallumokon keresztül kell nyomon követni. Ha az MTTR értéke idővel csökken, akkor a fejlesztők egyre hatékonyabbá válnak a biztonsági problémák, például a hibák megértésében és azok kijavításában.

mindkét mutató esetében a kisebb számok idővel azt jelentik, hogy a helyes irányba halad. Kevesebb végpont incidens önmagáért beszél. Ahogy az MTTR értéke csökken, a fejlesztők egyre hatékonyabbá válnak a biztonsági problémák, például a hibák megértésében és azok kijavításában.

a biztonsági mutatók szoftverfejlesztésre történő alkalmazásának további módjait az alkalmazásbiztonság agilis projektekhez és biztonsági fenyegetési modellekhez: agilis Bevezetés című cikkekben találja.

megjegyzés a forráskód-mutatókról

ma már könnyen csatlakoztatható egy forráskód-szkenner a build csővezetékhez, és objektív mérőszámok készíthetők. Vannak empirikus átlagok, javasolt tartományok és logikai érvek ezen mutatók relatív fontosságáról. De a gyakorlatban ezek az eszközök a leghasznosabbak a kódolási stílusok érvényesítésében, bizonyos anti-minták megjelölésében, valamint a kiugró értékek és trendek azonosításában.

csak nem érdemes letenni a számokat. Íme egy példa, magyarázatként.

tegyük fel, hogy talál egy módszert egy nevetséges mutatóval rendelkező osztályban, például 52 millió NPATH komplexitással. Ez azt jelenti, hogy 52 millió tesztesetre lenne szükség a kód minden útjának teljes körű gyakorlásához. A kódot egyszerűbb struktúrává alakíthatja át, de mielőtt ezt megtenné, fontolja meg, mi lenne az üzleti hatás. Valószínű, hogy a régi, csúnya kód elég jól működik (bár a teszt lefedettsége nem megfelelő). Az anti-minta felhívása a csapatnak, hogy elkerüljék annak megismétlését, értékes tanulás, de a rögzítése valószínűleg nem mozgatná a tűt egyetlen releváns üzleti mutatón sem.

a legjobb, ha a csapat elfogadja a megfelelőségi szintet és a szabályokat, amelyeknek a kódja ki van téve, de vegye figyelembe, hogy a kiugró értékek vizsgálata és a trend blipek aggodalma sok időt pazarolhat.

ezután tegye össze az egészet: A siker a végső mutató

az automatizált eszközök használatának öröme a minőségi mutatók és a felhasználói elemzések nyomon követésében és mérésében az, hogy időt szabadít fel arra, hogy a valóban fontos mutatókra összpontosítson: a siker mutatóira.

hogyan használjuk a mutatókat a sikerhez

a vállalkozásoknak céljaik vannak. A célok olyan kérdéseket vetnek fel, mint például: “hogyan néz ki a siker?”vagy” hogyan befolyásolja ez az ügyfelek viselkedését?”A megfelelően számszerűsített kérdések mutatókat jelentenek.

másképp fogalmazva: a mutatókat csak kérdések megválaszolására, egy adott üzleti célt támogató hipotézisek tesztelésére szabad használni. És ezt csak addig kell megtenni, amíg a kérdések és válaszok segítenek a pozitív változások előmozdításában.

Nos, nem minden projektnek van általában néhány invariáns célja, kérdése és hipotézise, és így metrikája?

igen, de csak az üzlet szempontjából. Az olyan üzleti szintű intézkedések, mint a felhasználói elkötelezettség, a közeli árak, a bevételtermelés stb., visszajelzést adnak arról, hogy az üzlet hogyan működik a valós világban. Az üzletet érintő szoftverváltozások az ilyen típusú mutatókat is érintik.

finomabb felbontásban minden funkciónak és felhasználói történetnek lehet saját sikermutatója—lehetőleg csak egy, és olyan, amely közvetlenül kapcsolódik az ügyfélnek átadott érték méréséhez. Tízből kilenc történet befejezése sprintben olyan funkciók számára, amelyeket soha nem szállítanak, pazarlás, nem siker. Olyan történetek átadása, amelyeket az ügyfelek nem akarnak vagy használnak, pazarlás, nem siker. Sikeres egy olyan történet átadása, amely javítja a felhasználói boldogság bizonyos aspektusait. Egy olyan történet átadása, amely bizonyíthatóan nem javítja a felhasználói elkötelezettséget, szintén sikeres, mert megtanult valamit, ami nem működött, érvénytelenítette az üzleti hipotézist, és felszabadította az erőforrásokat más utak követésére.

hogyan kell megfogalmazni egy értékhipotézist

az értékhipotézis egy állítás arról, hogy mit gondol, mi fog történni egy adott jellemző átadásának eredményeként. A szoftver, a kívánt eredmény és a mutatók közötti kapcsolat képezi a funkció (vagy rendszer, vagy történet, vagy frissítés stb.). A hipotézisnek ki kell fejeznie, hogy a célzott metrika várhatóan hogyan változik, milyen időkereten belül, és mennyire tekinthető hatékonynak. Legalább beszélnie kell a csapattal és a terméktulajdonossal, hogy kitalálja, hogy ez a funkció vagy történet milyen konkrét dolgot kíván létrehozni vagy javítani az üzleti életben annak értékhipotézisének megfogalmazása érdekében. Lehet, hogy néhányszor meg kell kérdeznie a “miért”-t (mint egy hároméves), hogy lehúzza a meg nem nevezett feltételezések rétegeit; légy türelmes. Ha megérti, hogy mi az üzleti érték, akkor elkezdheti feltenni azokat a kérdéseket, amelyek a kérdésre válaszoló mutatókhoz vezetnek.

például egy “technikai” történet, amely javítja az e-kereskedelmi fizetési folyamat sebességét, alapul véve feltételezheti, hogy a gyorsabb fizetés több eladást eredményez. De miért gondoljuk ezt? Sokan elhagyják a bevásárlókocsikat a fizetési folyamat során? Ha ez a konszenzus (mivel ezt a konszenzust alapadatok támasztják alá), akkor az értékhipotézis lehet: “úgy gondoljuk, hogy a gyorsabb fizetési folyamat csökkenti a kosárelhagyási arányokat, ami magasabb eladásokhoz és jobb felhasználói élményhez vezet.”

valószínűleg feltételezheti, hogy a felhasználók szeretik a gyorsabb fizetést, de nem árt megkérdezni, hogy észrevették-e. A kosárelhagyási arány és az értékesítés mérhető az új folyamat bevezetése előtt és után, egy ideig. Ha a kosárelhagyási arány csökken és az értékesítés növekszik (a statisztikai ingadozásokon túl), a bizonyítékok alátámasztják a hipotézist, és megfontolhatja, hogy indokolt-e még további sebességjavítás. Ha nem, hagyja, hogy ez a mutató elhalványuljon a háttérben (vagy távolítsa el, ha zavaró), és fordítsa figyelmét a következő hipotézisre. Ha a kosárelhagyási arány csökken, de az értékesítés változatlan, hosszabb ideig mérje meg, vagy gondolja át a kosárelhagyás és az értékesítés közötti feltételezett kapcsolatot. Más szavakkal, használjon mérőszámokat a tanuláshoz, és csak addig, amíg hasznosnak bizonyulnak a fejlesztések vezetéséhez.

bizonyos esetekben a hipotézis egyértelműen téves lehet, ezért eldobjuk a mutatókat (és visszavonjuk a szoftver módosításait!) néhány nap múlva. Más esetekben a hipotézis helyes lehet, ezért évekig folytatjuk a fejlesztéseket ezen a területen.

hat heurisztika a mutatók hatékony használatához

láttuk, hogy a szubjektív szoftvermutatók sokkal többet számítanak az üzleti siker szempontjából, mint a régi hagyományos, objektív minőségi mutatók. A funkciók releváns üzleti mutatóinak megtalálásához és méréséhez szükséges erőfeszítéseket felülmúlják a megszerzett betekintések és tanulási lehetőségek. Az Üzleti feltételek és lehetőségek folyamatosan változnak, ezért ahelyett, hogy összefoglalnánk a követendő képletet, amely törékeny lehet, itt van hat hüvelykujjszabály vagy heurisztika, amelyek segítenek fenntartani a fókuszt és a rugalmasságot. Segítsék Önt a minőségi szoftverek és az üzleti siker felé vezető úton!

1. a metrikák nem tudják elmondani a történetet; ezt csak a csapat tudja megtenni (Todd DeCapula kalaphegyével).
2. a hópelyhek összehasonlítása hulladék.
3. szinte bármit meg lehet mérni, de nem lehet mindenre figyelni.
4. az üzleti siker mérőszámai vezérlik a szoftverfejlesztéseket, nem pedig fordítva.
5. minden funkció hozzáadott értéket képvisel; vagy mérje meg, vagy ne tegye meg.
6. csak azt mérje meg, ami most számít.