tapasztalataink a leggyakoribb agilis mutatók használatáról

tapasztalataink a leggyakoribb agilis mutatók használatáról

az agilis mutatók használata a csapat termelékenységének mérésére az Agile filozófiájának kulcsfontosságú része. A csapatvezetőknek és minden tagnak látnia kell munkájuk következményeit, és ezeket az adatokat a munkafolyamat javítására és a hatékonyság növelésére kell felhasználniuk.

a végfelhasználók és az ügyfelek is profitálhatnak az agilis projekt metrikák használatából, amelyek a termék eredményének értékelésére összpontosítanak. A metrikák lehetővé teszik a scrum mesterek, fejlesztők, tervezők és tesztelők számára, hogy mérjék az alkalmazás teljesítményét, és nyomon kövessék, hogy az aktuális és korábbi feladatok jobbá teszik-e a terméket.

ebben a cikkben áttekintjük a fontos agilis mutatókat, és megosztjuk tapasztalatainkat az agilis metrikák irányítópultjának egy valós projektre történő alkalmazásáról. Kiderül, hogy a csapat sikeres vezetéséhez és az eredmények eléréséhez nem csak azt kell tudnia, hogy mely mutatókat kell alkalmazni, hanem azt is, hogyan kell csinálni — megosztjuk, hogyan találtuk ki.

a közös agilis metrikák típusai

az agilis metrikák osztályozása nincs kőbe vésve — mindig változik és átalakul. Mégis, az évek során láttuk az agilis mutatók három fő típusának növekedését különböző agilis keretrendszerekben.

1. Kanban metrics — ezek a mutatók a befektetett idő (ciklusidők) és a szállított eredmények (áteresztőképesség) és arányuk mérésén alapulnak.
2. Scrum metrics — mérőszámok, amelyek a munkafolyamat tervezésére és megértésére összpontosítanak, és bemutatják, hogy egy adott időszakban mennyi munkát végeztek;
3. Lean metrics — a termelési hatékonyság és a termékminőség folyamatos mérése MŰSZAKI értékeléssel a jellemzők tesztelésével, a lehetséges hibák ellenőrzésével és a negatív hatások előrejelzésével.

mindhárom mérőszámot használjuk a szoftverfejlesztési folyamat és az eredmények főbb szempontjainak felmérésére: a termék minősége, a csapat termelékenysége és egészsége.

agilis minőségi mutatók

Mielőtt elkezdené mérni a csapat sebességét és hatékonyságát, tudnia kell, hogy általában jó irányba halad-e. Mi a haszna az összes fejlesztési feladat gyors teljesítésében, ha maga a feladat rosszul alakul ki? Minden szoftverfejlesztő csapat és menedzser prioritása annak biztosítása, hogy minden tevékenység a termék fejlesztésével kapcsolatos — ez a minőség mérésével és a negatív tendenciák észlelésével történik.

megszökött hibák

minden agilis projektnek vannak sprintjei vagy munkaciklusai, amelyek végén egy bizonyos feladatot szállítanak. A munka befejezése után a csapat menedzserének fel kell mérnie az esztergált eredmények minőségét. Minden változtatás, szerkesztés és kijavítatlan hiba megszökött hiba — olyan probléma, amelyet a fejlesztők kijavíthattak volna, de nem. jegyezze fel pontos számát és természetét, hogy megtudja, milyen hibák kerülik el általában a fejlesztők szemét.

miután készített egy jelentést a megszökött hibákról és összegyűjtött kézzelfogható statisztikákat, meg kell beszélnie az eredményeket a csapatával. Győződjön meg arról, hogy minden csapattag tudja, hogy a csapat általában milyen hibákat hagy ki. Ha egyedi javaslatai vannak, beszélje meg őket a csapat tagjaival egy az egyben.

sikertelen telepítések

ha a terméket telepítették, de nem adták ki, vagy nem sikerült vonzani a felhasználókat, akkor ez sikertelen telepítésként kerül rögzítésre. Néha egy sikertelen telepítés történik az egyik érdekelt fél döntéseivel, vagy az üzleti modell megbízhatatlannak bizonyul. Bármi is volt a probléma oka, rögzítenie kell az összes sikertelen telepítést a kudarc okaival együtt.

új telepítés kiadása előtt a csapat mindig megnézheti a korábban sikertelen telepítések listáját, és megvizsgálhatja, hogy ez nem megy-e ugyanazon a folyamaton. A korábbi verziók meghibásodásának okainak elemzése lehetővé teszi a jövőbeli problémák elkerülését.

Release Net Promoter Score (NPS)

a Net Promoter Score az a mutató, amely magában foglalja a felhasználók reakcióinak kvantitatív (számok, statisztikák, Átlagos értékelések) és kvalitatív visszajelzések (vélemények, közvetlen visszajelzések, üzenetek, e-mailek, hívások) értékelését. Miután a csapat összegyűjtötte és elemezte a visszajelzéseket, minden csapattag javasol egy pontszámot, amely értékeli, hogy a felhasználó mennyire ajánlja a terméket (általában a pontszámok 1-től 10-ig terjednek).

agilis projektmenedzsment mérőszámok

a korábbi kudarcok és sikerek teljes története után elemezheti az összes jelenlegi befejezetlen projekt irányát, és a korábbi tapasztalatok alapján releváns feladatokat adhat ki. Miután meghatározta a fejlesztés irányát — a termék “mit kell tennie”, “fel kell mérnie a csapat hatékonyságát — ez a” hogyan csináljuk ” tényező. Az agilis projektmutatók segítségével megtudhatja, hogy a csapattagok megfelelnek-e az elvárásainak, megértik-e feladataikat, kezelik-e a határidőket, és hogy az összes folyamat koordinált és szinkronizált-e.

átfutási idő

az átfutási idő egy olyan mutató, amely lehetővé teszi a csapatok számára, hogy ellenőrizzék, mennyi kellett ahhoz, hogy a termékhátralék bejegyzés megérkezzen a sprint végére. Használható a termékek nyomon követésére bármely fejlesztési szakaszban, feladatonként, vagy a teljes időköltség felmérésére, az ötletektől a kiadásig. Ez egy hosszú távú mutató, amelyet a fejlesztők használhatnak jövőbeli munkájuk megtervezése és az árak becslése során.

ügyeljen arra, hogy rögzítse az átfutási időt az egyes projektek. A legjobb, ha mind a teljes projektet lefedő nagyobb képstatisztikákat, mind a Sprint metrikákat szervezett-így minden egyes szakaszt külön megvizsgálhat.

ciklusidő

ha az átfutási idő a csapat hosszú távú teljesítménymutatói közé tartozik, akkor a ciklusidő az egyes feladatokra összpontosít. Ez a mutató egy ciklus időtartamát értékeli, ahol egy tevékenység egy ciklust vesz fel, kiszámítja a ciklusok számát projektenként, és méri az elért eredményeket a végfelhasználó számára, ha a termék már bétatesztelt vagy kiadott.

a ciklusidővel a csapatok azonnal láthatják, ha egy feladat túl sok időt vesz igénybe, vagy ha néhány csapattag nem teljesíti a céljait. Ez a rövid távú mutató sokkal könnyebbé teszi a projektmenedzsmentet, és segít gyorsan meghatározni a felmerülő problémákat.

Sprint burndown

ezt a mutatót mind rövid, mind hosszú távon alkalmazzák. A menedzserek valós időben készíthetnek sprint burndown Scrum jelentéseket, hogy nyomon követhessék csapatuk előrehaladását az aktuális projektben — ehhez meg kell becsülniük a sprintek teljes számát és előre kell jelezniük a várható időköltségeket. Hosszú távon is használható-a vezetők elemezhetik a korábbi projektekről szóló jelentéseket, meghatározhatják azokat a szakaszokat, amelyek meghiúsultak a várt időkeretekben, és elemezhetik a késések okait.

a legfontosabb, hogy a sprint burndown lehetővé teszi a csapatok munkafolyamatának dinamikájának nyomon követését. Egyes tagok hajlamosak lassabban dolgozni az első szakaszokban, míg mások a projekt vége felé kiégnek. A sprint burndowns segítségével a csapatvezetők felismerhetik ezeket a tendenciákat, meghatározhatják azok okait, és segíthetik a tagokat a munka elosztásában és az időgazdálkodásban.

Epic & Release burndown

ez a mutató hasonló a Sprint Burndown-hoz — az egyetlen kulcsfontosságú különbség az, hogy a csapat termelékenységére összpontosít a kiadás előtt és után. A vezetők új követelményeket adhatnak hozzá, és olyan feladatokat is beépíthetnek, amelyek a végfelhasználók visszajelzésein alapulnak. Ez a sprint burndown továbbfejlesztett változata, mivel magában foglalja a projekt megjelenése után adott feladatokat is.

Velocity

ez a mutató értékeli a befejezett történetpontok számát egy adott időszakban. Az előzmények alapján előre láthatja a jövőbeli történetpontok időbeli költségeit. A csapat sebességének csökkenése bizonyos sprinteken félreértésre utalhat a csapattagok között, vagy olyan feladatokat jelölhet meg, amelyek nehezebbek a korábban vártnál.

további agilis mérőszámok

az agilis mérőszámok segítenek a csapatnak jobban megismerni a projektet, és nyomon követni a termékfejlesztés számos fontos aspektusát. Vannak agilis mutatók is a felsővezetők számára, amelyek lehetővé teszik a nagyobb képet a fejlődésről és a csapat jólétéről. Tapasztalataink szerint ezek a további mutatók segítenek mérni a munka bármely aspektusát. Mégis meghatároztuk azokat a kulcsfontosságú jellemzőket, amelyek a legtöbbet mondják el a végtermékről, és segítenek a teljes eredmény elérésében.

kumulatív áramlás

a metrika neve egyértelműen közli célját — az összes projektfolyam összegyűjtését és egyetlen diagramban történő értékelését. Egy ilyen grafikon nagy léptékű nézetet nyújt Önnek — elküldhető a projekt érdekeltjeinek, akiknek nincs idejük részletesebb agilis jelentések elemzésére.

a diagram általában a következő folyamatokat írja le:

• feladatok a lemaradásban: hány feladat van a lemaradó csapattagokban az adott időkereten belül;
• jóváhagyott munka: hány feladatot végeztek el a tervezett tevékenységek között — a csapatmenedzser azonnal látja a tervezett és a véglegesített tevékenységek közötti különbségeket;
• Puffertevékenységek: minden jóváhagyásra váró munka pufferzónában van meghatározva;
• folyamatban: ki kell értékelnie az aktuális munkaterhelést.

Code churn

ez a mutató a kódbázis változásainak trendjeit mutatja A kiadás előtt. A lemorzsolódási diagramok azt mutatják, hogy egyszerre mennyi kódot adtak hozzá, távolítottak el vagy változtattak meg. A korai sprinteknél sok csúcs és esés lesz a grafikonon, mert a kód még mindig instabil, de a projekt előrehaladtával a kód lemorzsolódási gráfnak stabilnak kell lennie, drasztikus hullámvölgyek nélkül.

a kiadás előtt a lemorzsolódásnak hanyatlást kell kapnia — a kód hozzáadása vagy szerkesztése a kiadás előtt azt jelenti, hogy nem megy át elegendő tesztelésen. Összességében, ha szabálytalanság van az agilis diagramokon, vizsgálja meg az okokat.

vezérlő diagram

a vezérlő diagram olyan diagram, ahol a csapat láthatja a ciklusidők időtartamára vonatkozó információkat. Az ideális eredmény az lenne, ha a diagram vonala folyamatosan csökkenne az idővel — ez a csapat sebességének növekedését jelentené-egyetlen ciklusonként kevesebb időre van szükség. Egy másik fontos szempont a következetesség — a ciklusidőknek a feladat típusától függetlenül is meg kell maradniuk — ez azt jelenti, hogy helyes a munkaelosztás.

egészségügyi mutatók

a szoftverfejlesztő csapatoknak hosszú távú prioritásokra kell összpontosítaniuk, mint például a tagok közötti kommunikáció zavartalansága és annak ellenőrzése, hogy mindenki elégedett-e. Az agilis egy rugalmas módszertan, ami azt jelenti, hogy alkalmazkodni tud a különböző tagok érdekeihez, amint a vezetők tudják, mire kell figyelniük. Így tudjuk meg, hogy csapatunk minden tagja elégedett-e a munkafolyamattal.

boldogság

ha megbízható, informális kapcsolataid vannak a csapatodban, könnyebb egy nyitott párbeszéddel kezdeni minden taggal. Kérd meg mindenkit, hogy értékelje tapasztalatait a vállalatnál 1 – től 5-ig. Feltehetsz segítő kérdéseket — melyek a munkájuk legjobb és legrosszabb aspektusai, mit lehetne javítani, és mi növelheti a boldogságot? Ha a csapatnak nincsenek barátságos kommunikációs szokásai, az anonim felmérések használata objektívebb eredményekhez vezethet.

csapat morál

csapat morál és boldogság nem ugyanaz a dolog. A boldogság inkább a kényelemhez kapcsolódik, míg a csapat morálja a termelékenységhez, az önértékeléshez, a saját szakmai tulajdonságainak értékeléséhez kapcsolódik. Ismét megkérheti az alkalmazottakat, hogy értékeljék moráljukat 1 – től 5-ig, és tegyék fel a következő kérdéseket;

• segített-e a vállalatnál végzett munka a készségek fejlesztésében?
• mennyire tárja fel teljes potenciálját a jelenlegi munkaterheléssel?
• élvezi a munkáját?
• látja munkájának egyértelmű eredményeit?
• lelkesedik az új projektekért?

a cél itt az, hogy megértsük, hogy a csapat fejlesztési áramlása a helyes irányba halad. Néha a szoftverfejlesztő csapat vezetője nyereséges, de unalmas feladatokat végez, figyelmen kívül hagyva a tagok érdekeit. Ez a felmérés segít megnézni, hogy az alkalmazottak izgatottak – e és kihívást jelentenek-e munkájuk miatt.

csapattagok forgalma

ha a csapatvezetők gyakran helyettesítik a csapattagokat, az azt jelenti, hogy a munkakörnyezet valószínűleg egészségtelen. Egy bizonyos mértékű forgalom az idő múlásával egészséges-sőt, nem akarja, hogy évekig hozzáadjon embereket, mivel ez stagnálást jelentene. Vigyázzon azonban a tevékenység hirtelen megugrására-hónapokra, amikor több ember elhagyta a csapatot, vagy sokan csatlakoztak. Ha hirtelen sok új résztvevő van, akkor figyelmet kell fordítania a beszállási folyamatra, mielőtt közvetlenül a projekttel kapcsolatos munkába lépne.

előnyök mérése a végfelhasználók számára

az agilis csapatoknak tudniuk kell, hogy a termék mennyire felel meg a végfelhasználó és a vállalkozás tulajdonosának igényeinek. Ez egy átfogó kódelemzéssel történik, amely meghatározza a kód minőségét és használhatóságát a végső felhasználó számára, valamint a lehetséges karbantartási komplikációkat.

statikus kódelemzés

ez a kódelemzés egyszerű típusa, amikor a szoftver inaktív. Csak a nyílt forráskódú eszközökkel történő automatikus figyeléssel azonosíthatja a biztonsági problémákat, észlelheti a műszaki adósságot és hibákat, és problémás kódrészleteket küldhet a szemétgyűjtőnek.

dinamikus kódelemzés

a dinamikus kódelemzéshez a csapatnak olyan szoftvert kell futtatnia, amely értékeli a végfelhasználók tapasztalatait. Arra ösztönözzük fejlesztőinket és tesztelőinket, hogy mindig a felhasználók cipőjébe helyezzék magukat, feltárva a leggyakoribb forgatókönyveket. Például bemutathatják kollégáikat és családtagjaikat a megoldásnak, visszajelzést kérve — kivéve, ha azt a megállapodás nem tiltja. A legfontosabb, hogy van egy QA szakemberekből álló csapatunk, akik teljes mértékben felelősek a dinamikus kódelemzésért — bár úgy gondoljuk, hogy minél többen járulnak hozzá az agilis mutatók teszteléséhez, annál jobb a végtermék minősége.

a legjobb agilis mutatók alkalmazása

a rendelkezésre álló agilis mutatók közül ki kell választania azokat, amelyek hosszú távon relevánsak lesznek a csapata és a projektek számára. Ezeknek a kulcsfontosságú jellemzőknek a nyomon követésének szokásnak kell lennie, miközben nem szabad elvonnia a figyelmét a sürgetőbb munkáról. Így zökkenőmentesen beépítettük az agilis mutatókat a munkafolyamatunkba.

Fókuszban a teljesítmény, a költségvetés és a minőség

meg kell győződnie arról, hogy az összes mutató kiválasztása után tiszta képet kap a munka minőségéről, terheléséről, időköltségeiről és költségvetéséről. Először rövid távú mutatókat állítunk fel, amelyek az aktív projektjeinkhez kapcsolódnak: ciklusidő és sebesség az agilis teljesítményértékeléshez, kódelemzés a kódminőség értékeléséhez, valamint kumulatív áramlás az összes fejlesztési folyamat és azok költségeinek nyomon követése érdekében.

az első sprint során a következőket kell tennünk:

• határozza meg, hogy hány Sprint és ciklus lesz a projektben;
• becsülje meg a teljes projekt időköltségeit, figyelembe véve az ügyfél igényeit;
• versenyképes megoldások értékelése a végtermék összetettségének megértése érdekében;
• gyűjtsön visszajelzést csapattagjainktól a projekt legizgalmasabb, legnehezebb és legnehezebb szempontjaival kapcsolatos elvárásaikról.

így megtudhatjuk, mennyi időt töltünk a projekt befejezésével, hasonló megoldásokon alapuló minőségi szabványokat állítunk fel, és hogy csapatunk motivált-e a feladatok elvégzésére vagy sem (ez hatalmas hatással van a termelékenységre).

mutatók az első sprint után

itt arra összpontosítunk, hogy visszajelzést kapjunk az ügyféltől és a csapat minden tagjától. Az első sprint után szeretnénk tudni, hogy a munkafolyamatban részt vevő összes fél megérti a folyamatot és jól érzi magát. Emellett hangsúlyozzuk a kódminőség értékelését — még a kódelemzést és a technikai adósságértékelést is tervezzük a következő sprintek részeként. Amint megírtuk az első kódsorokat, prioritásunk a minőség fenntartása.

a sebesség

után jön a sebesség a projektjeink egyik legfontosabb mutatója, de nem a legfontosabb. A kezdeti szakaszban tartózkodunk attól, hogy megítélésünket a sebességszámokra alapozzuk. Az első lépések gyors végrehajtásának stratégiája katasztrófa, amely arra vár, hogy megtörténjen — a csapat kihagyhatja a tervezést, vagy elfelejti feltenni az ügyfélnek néhány fontos kérdést. Nem siettetjük a termék első lépéseit, hagyjuk, hogy az ügyfelek és a csapattagok megtalálják a tempót.

csapatunk sebességének növelése az egyik prioritásunk, amikor a végrehajtás helyén vagyunk. Amint minden funkciót és dizájnt lefektetünk, arra törekszünk, hogy minimalizáljuk az időköltségeket, és minden feladatot a lehető leggyorsabban elvégezzünk.

egyéni mutatók

minden használt mutatónak elérhetőnek kell lennie a teljes csapat és az egyes tagok számára egyaránt. A fejlesztőknek, tesztelőknek, tervezőknek látniuk kell munkájuk ütemét és eredményeit, nem csak egy csapat egészét. Ennek megvalósításához termelékenységi eszközöket és időkövetőket használunk, mint például a Jira és a Hubstaff. Az összes általános jelentés szinkronizálva van az egyes jelentésekkel — a tagok láthatják, hogy az óráik hány százalékát teszik ki a teljes produktív időnek.

Gyakran Ismételt Kérdések

mi a KPI az Agile-ban?

az Agile kulcsfontosságú teljesítménymutatói mérhető értékek, amelyek megmutatják a csapat hatékonyságát az üzleti célok elérésében. A magas szintű KPI-k a hosszú távú eredményekre összpontosítanak, amelyek sok tényezőtől függenek — hány felhasználót vonzott a végtermék, az átváltási arányok, a visszajelzések minősége. Az alacsony szintű KPI-k rövid távú értékek, amelyeket nem befolyásol számos kapcsolódó tényező — a projektre fordított idő (általában órákban számítva), a projekt költségvetése (tevékenységenkénti beruházás) stb.

az Agile egy folyamatos fejlesztésen alapuló fejlesztési módszertan — a szoftverfejlesztés elemzi az adatokat és alkalmazkodik hozzájuk. A csapat elemzi az agilis teljesítménymutatókat és a munka minőségét, és azonnal végrehajtja a változtatásokat a következő Sprintben.

mik azok a Sprint mutatók?

a Sprint mutatók olyan mutatók, amelyek értékelik a szoftverfejlesztő csapat eredményeit, ellenőrizve, hogy mennyi értéket szállítottak a végfelhasználónak az egyes sprintek végére . Ez az érték új funkcióval, tervezési fejlesztésekkel vagy hibatörléssel mérhető.

a sprint metrics következő célja a csapat hatékonyságának mérése üzleti szempontból — milyen gyorsan került a piacra a megoldás, mi az ügyfél visszajelzése és a konverziós szintek. Végül a mutatóknak meg kell mutatniuk a fejlesztők elégedettségét a projektjükkel és a csapat általános irányával.

miért fontosak a mutatók az agilis projektek számára?

az agilis módszertan lényege, hogy a fejlesztők minden sprint után mindig javításokat végezhetnek a folyamatban. A kézzelfogható adatok, statisztikák és grafikonok lehetővé teszik a fejlesztők számára, hogy megértsék, milyen változtatásokat hajtsanak végre a következő Sprintben, és lehetővé teszik a végtermék minőségének értékelését — különben könnyű lenne elkapni a technikai és szervezeti részleteket.

mi az agilis sprint?

a sprint egy világosan meghatározott időszak a kezdési és befejezési dátummal, amikor a csapat meghatározott számú feladatot végez. A sprintek képezik a Scrum, Agile és DevOps alapját — a csapatok kisebb, kezelhető darabokra osztják a munkaterhelésüket, és nyomon követik az egyes sprintek eredményeit. Ezen időszakok mindegyikét mini-projektként kezelik, előzetes tervezéssel, kockázatértékeléssel, felelősségi feladatokkal és sprint utáni elemzéssel.

minden projekt Sprint sorozatból áll. Mivel minden sprint kiértékelésre kerül, könnyű észrevenni a problémákat korán, és eltávolítani őket a következő Sprintben — így a munkafolyamat folyamatosan optimalizálva van.

melyek a szoftverfejlesztés mutatói?

a szoftverfejlesztési mutatók kvantitatív értékek, amelyek lehetővé teszik a szoftverfejlesztési projekt minőségének, teljesítményének és a csapat egészségének mérését. Segítenek a fejlesztési folyamat javításában a projekt előrehaladtával, és felhasználhatók a csapat jövőbeli munkájára a szervezet és a tervezés javítása érdekében.

a szoftverfejlesztési mutatóknak hat fő típusa van:

• formális kódmutatók-ezek objektív kvalitatív értékek, amelyek kiszámítják, hogy mennyi munkát végeztek a kódsorok számának meghatározásával (LOC), az utasítás elérési útjának hosszával stb.
• fejlesztői hatékonysági mutatók — a csapat kiszámíthatja a hozzárendelési kódot, az aktív napokat és a feladatra fordított időt.
• agilis folyamatmérők — amikor a projektet sprintekre bontják, a csapat mérheti a projekt kisebb részeinek hatékonyságát – átfutási idő (mennyi időt töltöttek egy adott fejlesztési szakaszra, amely több sprintet is tartalmazhat), ciklusidő (egy sprint általában egyetlen ciklus alá esik), és sebesség (hány feladatot végeztek egy adott időkeretben).
• működési mutatók — ezek a mutatók ellenőrzik a szoftver futási jellemzőit, és meghatározzák, hogy a vállalat munkatársai mennyire hatékonyak az eszköz karbantartásában harmadik fél segítsége nélkül. A meghibásodások és a helyreállítás átlagos ideje között eltelt idő (MTTR) ellenőrizze, hogy a szoftver hogyan fog működni természetes körülmények között, és mennyire van felszerelve a házon belüli csapat a terhelés kezelésében.
• Tesztmutatók — ezek a mutatók értékelik a kód lefedettségét — a tesztelt kód mennyiségét, a hibák számát és a technikai adósság százalékos arányát.
• ügyfél — elégedettség-a csapat betekintést kap a végfelhasználók reakcióiba a termékre a nettó Promóteri pontszám, az ügyfél-elégedettségi pontszám és az ügyfél-Erőfeszítési pontszám mérésével. Ezek a mutatók azt értékelik, hogy a felhasználók ajánlanák-e a terméket, és elégedettek-e az eredménnyel.

az agilis mutatók a szoftverhálózatok részét képezik, és más kategóriákat is tartalmazhatnak, amint azt az útmutatónkból észreveheti.

mik azok az SDLC mutatók?

az SDLC egy szoftverfejlesztési életciklus — olyan szakaszok halmaza, amelyeken egy tipikus technológia a koncepció, a végrehajtás és a véglegesítés során megy keresztül. Egy átlagos SDLC a következő szakaszokból áll:

• a meglévő rendszerek értékelése és azok jellemzőinek, előnyeinek, problémáinak meghatározása;
• az új projekt funkcionalitására, tervezésére, célközönségére stb.vonatkozó követelmények meghatározása.;
• a rendszer megtervezése és egy tipikus felhasználói útvonal felvázolása;
• a szoftver fejlesztése, ami kódírást, hardver előkészítést és funkciók létrehozását jelenti;
• a szoftver teljesítményének, funkcionalitásának, biztonságának, felületének stb.tesztelése.;
• a szoftver telepítése a természetes környezetben, ahol a technológia hosszú távon fut;
• a rendszer fenntartása a kód frissítésével, bizonyos töredékek cseréjével vagy szerkesztésével, valamint a hibák eltávolításával.

az SLDC minden szakasza a következő jellemzőkkel mérhető.

• követelmények: a csapatnak össze kell gyűjtenie a projekt összes követelményét, és értékelnie kell mindegyikük végrehajtását idő és pénz szempontjából;
• Szoftverminőség: az összes agilis minőségi mutató használható az SDLC fejlesztési szakaszában;
• tesztesetek: a csapatnak ki kell számítania az elvégzett teszttevékenységek számát, sebességét és a végső kód lefedettségét;
• hibák: munkájuk hatékonyságának méréséhez a fejlesztőknek és a tesztelőknek tisztában kell lenniük a fejlesztés során felmerülő problémák pontos számával;
• feladatok: az idő mérése a feladatonként elköltött és megkeresett pénz lehetővé teszi annak értékelését, hogy a csapat minden tagja produktív-e vagy sem.

az útmutatónkban leírt összes mutató a szoftverfejlesztési életciklus különböző szakaszaiban használható. A projektnek a legnagyobb szüksége van a kiadáshoz közelebbi megfigyelésre, mert a problémák felhalmozódhatnak, és könnyű kihagyni a termék kritikus hibáját.

mi az áteresztőképesség az agilis mutatókban?

ez a mutató számítja ki a sprintenként befejezett történetek számát. A Scrumban egy hasonló mutatót Sprint sebességnek neveznek.

következtetés

az agilis mutatók szilárd alapot teremtenek a megalapozott döntések meghozatalához egy szoftverfejlesztési projekt során. A fejlesztők felhasználhatják ezeket a felismeréseket, hogy növeljék hatékonyságukat a következő sprintekben, és folyamatosan javítsák termékük minőségét. Érdemes azonban megjegyezni, hogy a fejlesztési mutatók nem válhatnak abszolút prioritássá a szoftverfejlesztési projektben. A fejlesztőknek elsősorban a projekt igényeire és a közönség preferenciáira kell támaszkodniuk.

a Jelvix-nél személyre szabott megközelítést alkalmazunk a mutatók projektre történő alkalmazásához. Először megbeszéljük a projekt MVP-jét az ügyféllel, kutatjuk a célközönséget, elemezzük a versenyképes megoldásokat, majd csak ezután választjuk ki a projektnek leginkább megfelelő mutatókat. Nem törekszünk arra, hogy minden egyes KPI — t alkalmazzunk-ehelyett azokat választjuk ki, amelyek a legjobban tükrözik a projekt igényeit.