Minden eredményes szoftverfejlesztő csapat nyomon követi fejlesztéseit egy sor kiválasztott mutatószámon, az úgynevezett KPI mérési metrikákon keresztül. Ez az 5 legfontosabb KPI (Key Performance Indicator) fejlesztési mérőszám, amelynek nyomon követését még ma el kell kezdenie.

Munkálkodott már olyan mérnöki csapatban, ahol nem mértek KPI mérőszámokat? Ha igen, akkor valószínűleg tudja, milyen nehéz megmondani, hogy a csapat a kiadási ütemterv szerint halad-e vagy sem.

Az igazság az, hogy ha el akarja érni az üzleti céljait, akkor biztosítania kell, hogy a szoftvere minden követelménynek megfeleljen. Ehhez KPI mérnöki mérőszámokat kell bevezetnie a fejlesztési folyamatokba.

A szoftverfejlesztő csapat számára KPI mérnöki mérőszámok felállításával elkerülheti a rossz minőséget és a határidők elmulasztását. Amit kapni fog, az egy produktív csapat és egy kiváló minőségű termék.

Itt van öt alapvető KPI fejlesztési mérőszám, amelyet nyomon kell követnie, hogy elérje üzleti céljait.

Sprint Burndown

Mi a Sprint Burndown?

Az agilis csapatok sprintekbe szervezik a fejlesztést. A sprint burndown azt méri, hogy a csapat mennyi munkát végzett egy sprint alatt.

Melyek az előnyei?

• A sprint burndown kiválóan alkalmas arra, hogy a csapat tisztában legyen a felmerülő akadályokkal.
• A sprint lebontás mérésével ellenőrizheti, hogy a csapat teljesíti-e az előrejelzést.
• A sprint lebontási táblázat segítségével a csapat irányíthatja a haladását. Ha a csapat felismeri, hogy esetleg nem éri el a sprintcélt, a csapattagok megfelelő lépéseket tehetnek, hogy a pályán maradjanak.

Hogyan lehet mérni?

Az agilis csapatok sprintbontási diagramokat használnak a munkafolyamatok vizualizálására. A diagramnak van egy x-tengelye, amely az időt, és egy y-tengelye, amely az elvégzendő munka mennyiségét mutatja. Az időt órákban vagy történetpontokban mérheti. Vagy kitalálhat saját statisztikákat is. A fő cél itt az, hogy a sprint végére az összes előre jelzett munka elkészüljön.

Az egyik eszköz, amit használhat, a Jira Sprint Breakdown chart. Használatához létre kell hoznia egy Jira Software fiókot, és egy Jira Software Scrum projektet.

Egy függőleges tengelyt fog látni, amely a történetpontokat ábrázolja. A vízszintes tengely az időt mutatja. A grafikonon a piros vonal a sprintből hátralévő munka mennyiségét jelzi. A szürke vonal a tényleges munkavonal. Ha a piros vonal a szürke vonal alatt van, akkor ez azt jelenti, hogy a csapat jó úton halad. Ha azonban a piros vonal a szürke vonal felett van, az azt jelenti, hogy a projekt késésben van az ütemtervtől.

Release Burndown

Mi az a Release Burndown?

A Release Burndown áttekintést nyújt a kiadás előrehaladásáról. Hasonló a Sprint burndownhoz, de nagyobb terjedelmű. Segít a csapatoknak ellenőrizni, hogy sikerül-e egy adott időpontra kiadni a terméket. Ha rájönnek, hogy le vannak maradva az ütemtervtől, tájékoztathatják a felhasználókat és az érdekelt feleket a késésről. Vagy ha nem, akkor csökkenthetik a munkaterületet, hogy időben kiadják a terméket.

Melyek az előnyei?

• Ellenőrizheti, hogy csapata milyen gyorsan dolgozik a backlogon.
• Betekintést nyerhet abba, hogy a hozzáadott és eltávolított munkák hogyan befolyásolják a csapat előrehaladását.
• Megjósolhatja, hogy hány sprintre lesz szüksége a csapatának a munka befejezéséhez.

Hogyan lehet mérni?

A kiadás leégését egy, a sprint lebontási diagramhoz hasonló diagram segítségével lehet mérni. A különbség annyi, hogy most a vízszintes tengely a sprinteket, a függőleges tengely pedig a hátralévő munkát (napok, órák vagy történetpontok) jelöli.

Nézzük meg például az alábbi képet. Ez egy Jira release burndown diagram. Láthatjuk, hogy a csapat kezdetben négy sprintet és 43 történetpontot határozott meg. E négy sprint alatt a csapat 43-ról 26-ra csökkentette a történetek számát. A csapat azt is előre jelezte, hogy a termék kiadása további hét sprintet vesz igénybe, ami összesen 11-et eredményez.

Ciklusidő

Mi a ciklusidő?

A ciklusidő egy KPI fejlesztési mérőszám, amely azt méri, hogy a csapat mennyi időt tölt egy feladat elvégzésével. A ciklusidő-diagramokat a Scrum Masterek és a terméktulajdonosok használják a fejlesztési folyamat hatékonyságának ellenőrzésére.

Melyek az előnyei?

• A csapat általános teljesítményéről nyújt információt.
• Lehetővé teszi a jövőbeli feladatok elvégzésének becslését.
• Észre lehet venni a szűk keresztmetszeteket és lassulásokat a munkafolyamatban.

Hogyan lehet mérni?

A ciklusidő egyenlő a befejezési dátum mínusz a kezdeti dátum. Ha például a csapat december 1-jén kezdi a munkát, és december 10-én fejezi be, akkor a ciklusidő kilenc nap.

Ha a csapat december 1-jén kezdi a munkát, és még aznap befejezi a feladatot, akkor a ciklusidő nem nulla, hanem egy lesz. Azon projektek esetében, amelyek ugyanazon a napon kezdődnek és fejeződnek be, a ciklusidő egyenlő a befejezési dátum mínusz a kezdeti dátum +1.

A napokat hetekkel, órákkal vagy akár sprintekkel is helyettesítheti.

Figyeljen a ciklusidő-diagramok használatára a munkafolyamatok vizualizálására. Ezek a diagramok azt mutatják, hogy mennyi időbe telt egy kérdés befejezése a befejezés napjához képest.

Nézzük meg például az alábbi diagramot. Az x-tengelyen a feladat lezárásának dátuma, az y-tengelyen pedig a ráfordított idő látható. A zöld körök a feladatok. A tömör kör a feladatok halmazát jelzi, míg a nyitott kör egyetlen feladatot. Ha olyan eszközt használ, mint a Jira, akkor az egérrel a kör fölé futtatva láthatja a feladat kulcsát, kódját és az átfutási időt. A piros vonal az átlagos átfutási időt, a kék vonal pedig a gördülő átlagos átfutási időt jelöli.

A végcél az, hogy a csapat konzisztens ciklusidővel rendelkezzen a hasonló történetpontértékkel rendelkező munkaelemek esetében. Az alacsonyabb értékek azt jelentik, hogy a csapat hatékonyan dolgozik, míg a magasabb értékek szűk keresztmetszeteket jelezhetnek a munkafolyamatban.

Team Velocity

Mi a Team Velocity?

A Velocity egy másik agilis KPI mérnöki metrika, amely azt méri, hogy egy csapat mennyi munkát végez el egy sprint során. A munka mennyiségét általában történetpontokban vagy órákban mérik.

A terméktulajdonosok a sebességet arra használják, hogy kiszámítsák, milyen gyorsan képes a csapat végigdolgozni a backlogot. A sebességmutató minden csapat esetében egyedi, és nem szabad összehasonlítani a sebességet a csapatok között.

Tegyük fel például, hogy a backlogban 300 történetpontot szeretnénk befejezni. Tudja, hogy a fejlesztőcsapat átlagosan körülbelül 50 történetpontot fejez be iterációnként. Ezen információk birtokában megjósolhatja, hogy a csapatnak hat iterációra lesz szüksége a szükséges munka elvégzéséhez.

Melyek az előnyei?

• Nagyon hasznos az előrejelzéshez.
• Segíthet megtervezni a jövőbeli sprinteket.
• Segíthet megérteni, hogy a csapat elakadt-e, vagy hogy a folyamatváltoztatások működnek-e.

Hogyan mérheted?

Ha stabil csapatod van, legalább 5-7 sprint mérésével sikerül megállapítanod egy átlagos sebességet. Ha a szokásos sprinted heti rendszerességű, és a csapat öt hét alatt 250 történetpontot fejez be, akkor az átlagos sebességed 50 történetpont hetente.

Nézzük meg az alábbi Jira Velocity diagramot. A kék sávok a kötelezettségvállalást, a zöldek pedig a ténylegesen elvégzett munkát jelzik. Az 1. sprintben a csapat 16 történetpontot tervezett, és 16 történetpontot végzett el. Ez azt jelzi, hogy a becsléseik helyesek voltak. A második sprintben azonban a csapat 19 történetpontot tervezett, de csak 12-t végzett el. Ez azt sugallja, hogy legközelebb csökkenteniük kell a tervüket.

A következetlen folyamatképzés azt jelzi, hogy problémák vannak a fejlesztésben, és változtatásokra van szükség.

Kumulatív áramlás

Mi az a kumulatív áramlás?

A kumulatív áramlás megjeleníti a jegyek állapotát egy bizonyos időszak alatt. Megmutatja a jegyek egyik státuszból a másikba történő váltását a projekt előrehaladtával.

Melyek az előnyei?

• Hasznos a szűk keresztmetszetek azonosításához.
• Segíti a csapatokat abban, hogy a munkaáramlás következetes legyen.
• Megmutatja, mennyire stabil a munkafolyamat.
• Segít megérteni, hogyan teheti kiszámíthatóbbá a folyamatát.

Hogyan lehet mérni?

A kumulatív munkafolyamat mérésének legegyszerűbb módja a diagramok használata. Ezek vizualizálják az áramlás három legfontosabb szoftvertechnikai mérőszámát, köztük a ciklusidőt, az átfutási sebességet és a folyamatban lévő munkát.

Nézzük meg az alábbi diagramot. A vízszintes x-tengely az időt, míg a függőleges y-tengely a munkaelemeket jelöli. A különböző színek a különböző munkafolyamat-állapotokat jelölik. Ha a sávok párhuzamosan haladnak, az azt jelenti, hogy az áteresztőképesség stabil. Ez azt jelzi, hogy a munkafolyamatába belépő új feladatok száma megegyezik a munkafolyamatból kilépők számával.

Ha egy sáv gyorsan szűkül, az azt jelenti, hogy több kapacitással rendelkezik, mint amennyire szüksége van. Az áramlás optimalizálása érdekében át kell helyeznie a kapacitást.

Ha egy sáv gyorsan szélesedik, az azt jelenti, hogy több kártya érkezik a megfelelő szakaszba, mint ahány feladat elhagyja azt.

Összegzés

A fent vázolt KPI fejlesztési metrikák nyomon követése a termékfejlesztési folyamat sikeres kimeneteléhez vezethet. Sikerül végül abbahagynia a projekt előrehaladásának másodlagos megítélését, és részletes betekintést nyerhet a fejlesztési életciklus minden egyes szakaszába.

Ha véget akar vetni a gyenge minőségű termékek, az elmulasztott határidők és a kódhibák ördögi körének, kezdje el a KPI-fejlesztés bevezetését még ma. Sikerülni fog, hogy csúcsminőségű terméket adjon ki a vele járó kockázatok nélkül.