A metrikák veszélyei

Régóta tervezünk írni a metrikákról, mert úgy látjuk, hatalmas félreértés övezi őket – agilitástól függetlenül is.

A metrikák eszközök, amik egy szempontból adnak visszajelzést a vizsgált témáról. Ennyi, és nem több. Fontos kihangsúlyozni, hogy a metrikák nem célok! Valamint azt, hogy nagyon veszélyes pusztán pár szám vagy egy grafikon alapján, a helyzet pontos megértése nélkül megpróbálni következtetéseket levonni. Kényelmes és gyors persze, de nagyon kockázatos. A metrika megmutathatja (de nem feltétlen teszi), ha van probléma, de az okokat a legtöbb esetben nem képes felfedni.

Nézzünk egy konkrét példát! Pár hete egy tréningen azt mesélte egy résztvevőnk, hogy a projektjükről budget-vágás miatt el kellett engedni egy csapatot, és jobb híján a burn-down chart alapján döntötték el, melyik csapat legyen ez. Megkérdezte, mit gondolunk erről a megoldásról. Természetesen azt, hogy hatalmas hiba volt. De miért?

Tegyük fel, hogy két vizsgált csapat burn-down-ja így néz ki:

Tegyük fel, hogy az elmúlt 8 sprintben hasonlóan alakultak a görbék a csapatoknál. Ha csak ezt a metrikát figyeljük, a legtöbben valószínűleg az “A” csapatot tekintenék jobbnak, őket kell megtartani. Miért? Gyönyörű a görbe íve, szépen megy lefelé, ráadásul el is fogytak a feladatok, tehát minden bizonnyal mindent leszállítottak, amit beterveztek a sprintbe.

Hol van akkor a csapda?

A teljesség igénye nélkül, pár dolog, amit egy-egy ilyen burn-down chart elfedhet:

  • Ha egy csapat minden sprintje sikeres, az mindig gyanús. Lehet, hogy az “A” csapat túl kényelmesre tervezi a sprinteket, ezért sikeresek folyton?
  • Mi lehet amögött, hogy a “B” csapat nem tudja befejezni a sprintjeit?
    • Rosszul becsülnek?
    • Túlvállalják magukat?
    • Esetleg rossz minőségűek a backlogelemeik és ezért nehéz a tervezés?
    • Túl sok részlet van, ami a sprint közben derül ki?
    • Külső függőségeik vannak, amik akadályozzák őket a szállításban?
  • A “B” csapat görbéje néha elindul felfelé. Mit jelenthet ez?
    • Hibás, gyenge taszkosítás?
    • Esetleg a sprinten belüli tesztelés sorra veszi fel a hibákat? De akkor az “A” csapatnál miért nincs ilyen? Lehet, hogy nem tesztelnek rendesen a sprinten belül, és az általuk átadott feature-ökben később sokkal több hiba kerül elő?

Látható, hogy ugyanaz a chart rengeteg dolgot jelenthet, és ezeknek a jelenségeknek csak egy részében mondhatjuk ki, hogy a csapat a felelős. Óvatosan kezeljük tehát a metrikákat! A helyes megoldás bármilyen helyzetben:

  • Válasszunk megfelelő metrikákat
  • És azok akár jó, akár rossz képet festenek, szánjuk rá az időt, hogy megértsük, pontosan mi történik. Nem lehet megspórolni ezt a lépést, oda kell menni ahol a munka folyik és feltenni a megfelelő kérdéseket (például a fenti listában találhatóakat).

Agilis metrikát ötvenes nagyságrendben simán fel tudnánk sorolni – későbbi post-okban tervezünk is pár példát hozni -, de természetesen nem érdemes mindegyiket, mindig használni. A megfelelő metrikák kiválasztásához inkább két támpontot adunk:

  • Bizonyos metrikákat érdemes a szituációk alapján bevezetni. Ez praktikusan olyan ember feladata, aki közelről látja a folyamatot, tehát scrum esetén a Scrum Masteré. Konkrét példa: egy scrum development team sokat panaszkodott nekünk, hogy nem tudnak rendesen scrumozni, mert az üzleti oldal napi szinten meggondolja magát, megváltoztatja az egyes backlogelemek tartalmát. Teljesen tervezhetetlen az életük, folyamatosan dobják ki a félkész fejlesztéseket és ez nagyon frusztráló. Mély együttérzéssel fogadtuk a problémát, de nem tudtuk megvigasztalni őket, ugyanis ilyen helyzetben, ha mi ülnénk az üzleti oldalon, mi is pontosan így viselkedtünk volna. Miért? Gondoljunk bele. Ebben a folyamatban az üzlet annyit lát, hogy bármit kér, azt a fejlesztőcsapat megcsinálja. Ez nem egy rossz helyzet, semmi indíttatás nincs arra, hogy változtassanak a viselkedésükön. Persze, panaszkodnak a fejlesztők, dehát eddigis mindig panaszkodtak… A megoldás ilyen esetben: keresni egy olyan metrikát, ami rávilágít az okozott problémákra. Megkértük a csapatot, hogy minden sprintben gyűjtsék, hogy mennyi munkát kellett kidobni a folyamatos változások miatt. Ezzel az adattal már nem csak azt látta az üzlet, hogy minden kérésük teljesül, hanem azt is, hogy ha egy kicsit előre tudnának tervezni (két hét nem olyan nagy idő), akkor több mint kétszer annyi fejlesztés elkészülhetne, mint jelenleg. Ez elég erős és meggyőző érvnek bizonyult.
  • A fenti példa azokra a metrikákra vonatkozott, amelyeket időszerűen használunk. Természetesen vannak olyan metrikák, amiket érdemes folyamatosan figyelni. Ezek kiválasztására érdemes az alábbi mátrixot figyelembe venni:

metrics_matrix.png

A mátrix egyik dimenziója azt mutatja, hogy milyen folyamatra vonatkozik a metrika: részfolyamatra (pl.: fejlesztés, tesztelés, üzemeltetés, stb.), vagy a teljes end-2-end value streamre. A másik dimenzió pedig, hogy ez a metrika érdekli-e az ügyfelet. Ügyfél alatt mindig a termék ügyfelét értsük, tehát egy outsourcing vagy alvállalkozó cégnél nem a megrendelőt, hanem a termék vásárlóját.
A legtöbb szervezet az ügyfél számára lényegtelen, részfolyamatra vonatkozó metrikákra koncentrál. Kedvenc példánk erre a code coverage. Nincs baj az ilyen metrikákkal, csak túl vannak hangsúlyozva. Amire az igazi fókuszt helyezni kéne, az a szemközti kvadráns: az ügyfél számára fontos, end-2-end metrikák. Például: time-to-market, hiba trendek, szállított üzleti érték, customer retention …

Befejezésül még egy példa a metrikák megtévesztő erejére: a magyar futballválogatott idén 30 éve nem kapott gólt EB-n. Örülünk? :)