olvasási idő: 13 perc
a szoftverfejlesztés agilis megközelítése régóta bevett gyakorlat. A HP online felmérése szerint az informatikai szakemberek 16% – a A tiszta agilis, 51% – a az it felé hajlik, 24% pedig agilis hibrid megközelítést alkalmaz. Ma a vízesés fejlesztését leggyakrabban agilis differenciálóként említik, mi az agilis nem. Széles körben megvitattuk az agilis projektmenedzsment módszertanokról szóló fehér könyvünk fő különbségeit.
az agilis menedzsment alkalmazkodóképessége és rugalmassága, valamint a változásokra való gyors reagálás ellenére a munkafolyamat központosított és ellenőrzött maradhat. Az agilis teljesítménymutatók (Key performance Indicators) iránymutatást nyújtanak a stratégiai tervezéshez, értékeléshez és az operatív folyamatok javításához.
a hagyományos értékgazdálkodási rendszerek általában a feladatok teljesítésére összpontosítanak kategorikus ütemezés és költség keretein belül. Az agilis megoldásokkal azonban az ügyfelek és a csapattagok azonnali eredményeket látnak, és módosítják az időkereteket és az erőfeszítéseket, hogy olyan terméket szállítsanak, amely megfelel az ütemterv követelményeinek. Milyen eszközöket és technikákat igényel ez a tudás? Itt található az agilis fejlesztési mutatók teljesítményértékelésének áttekintése.
Agile software development KPI-k
ebben a cikkben nem fogjuk megvizsgálni az összes lehetséges agile development metrikát és KPI-t. Az egésznek a tetejébe, lehet kitalálni a saját is, hogy megfeleljen a projekt legjobb. Leírjuk azonban a leggyakoribb KPI-ket, amelyeket több szoftverfejlesztési szempontból használnak:
- sebesség
- Sprint burndown
- Release burndown
- ciklusidő
- kumulatív áramlás
- áramlási hatékonyság
- kód lefedettség automatizált tesztekkel
- teszt automatizálás ellen kézi tesztelés
- McCabe ciklomatikus komplexitás (MCC)
- kód lemorzsolódás
ezek a legfontosabbak, amelyeket először meg kell vizsgálnod
folyamatban lévő munka mérése
sebesség
a sebesség a sprintben elvégzett munka mennyiségét (számos funkciót) méri. Bár ez nem előrejelző vagy összehasonlító eszköz, a velocity ötletet ad a csapatoknak arról, hogy mennyi munkát lehet elvégezni a következő Sprintben.
a sebességindex minden csapat számára egyedi, és úgy kell beállítani, hogy felmérje, mennyire reális az elkötelezettség. Például, ha a projekt lemaradása 200 történetpontot tartalmaz, és a csapat sprintenként átlagosan 10 történetpontot teljesít, ez azt jelenti, hogy a csapatnak körülbelül 20 sprintre lesz szüksége a projekt befejezéséhez.
minél tovább követi a sebességet, annál nagyobb a kötelezettségek és a költségek közötti megfelelés pontossága
egy olyan csapat számára, amely éppen elfogadta az agilis módszertant, vagy akár új termékbe kezdett, az első néhány Sprint sebességbecslése valószínűleg hibás lesz. De ahogy a csapatok tapasztalatot szereznek, a sebesség eléri a csúcsot, majd eléri a kiszámítható áramlás és a várható teljesítmény fennsíkját. A következetes áramlás csökkenése jelzi a fejlődés problémáit és feltárja a változás szükségességét.
Tippek a sebességmérő használatához
harci következetlenség 3-5 sprint után. Ha a sebesség hosszú idő után következetlen marad, fontolja meg mind a külső, mind a belső tényezők értékelését, amelyek megakadályozzák az egyértelmű becslést.
változtassa meg a sebességkövetést a csapat és a feladat változásai után. Amikor egy csapattag elhagyja a projektet, vagy több tagot/feladatot ad hozzá, újraszámolja a sebességet vagy indítsa újra a számítást.
három Sprint elegendő a korai előrejelzésekhez. A jövőbeli teljesítmény előrejelzéséhez használja a három korábbi Sprint átlagát.
Sprint burndown chart
a sprint burndown chart a sprint vége előtt elvégzendő munka mennyiségét mutatja. Az eszköz különösen értékes, mert a befejezett elemek felsorolása helyett a cél felé haladást jeleníti meg. Nagyon hasznos a tervezési hibák feltárásában is, amelyeket egy csapat a sprint elején elkövetett.
a fekete vonal alatti diagramon az előrejelzett (ideális trend) vonal látható, amely megmutatja, hogy a csapatnak milyen sebességgel kell leégnie a történetpontokat, hogy időben befejezze a sprintet. A kék vonal jelzi a munka teljes mennyiségét és előrehaladását a sprint során. Láthatjuk, hogy az ötödik és hatodik napon egy csapatnak nem sikerült elérnie az előre jelzett haladást. A hetedik napon azonban foglalkoztak a kérdéssel, és a munka visszatért a helyes útra. Az ilyen folyamatos frissítések lehetővé teszik a csapatok számára, hogy a napi stand-up találkozók során foglalkozzanak a felmerülő problémákkal.
a munka teljesítményén kívül a burndown diagramok feltárhatják a tervezési problémákat
Tippek a sprint burndown megközelítéséhez
A történet pontjainak még hatályban kell lenniük. Ha a munkafolyamat nem következetes, előfordulhat, hogy egyes feladatokat egyenetlen darabokra bontottak. Az ideális trend és a valóság közötti eltérés mértéke egyértelműen rávilágít erre a problémára.
nem tervezett feladatok elszámolása. A burndown diagram hasznos a rejtett és nyomon nem követett feladatok körének megértéséhez. Ha a munka mennyisége csökken, ahelyett, hogy csökken, a projektnek sok nem becsült vagy nem tervezett feladata van, amelyekkel foglalkozni kell.
használja a burndown chart felmérni csapat bizalmát. Figyelembe véve a jelenlegi arányokat, kérdezze meg csapatát, mennyire bízik abban, hogy időben befejezi a sprintet. Minél hosszabb ideig alkalmazza ezt a mutatót, annál pontosabbak a sprint becslései.
a kiadás becslése burndown diagrammal
a kiadás burndown diagramja jelzi a kiadás előtt elvégzendő munka mennyiségét. A diagram bemutatja az előrehaladás áttekintését, és lehetővé teszi a módosítások végrehajtását az időben történő kézbesítés biztosítása érdekében.
a diagram hagyományos változata hasonló a sprint burndown diagramhoz, de áttekintést ad a teljes projektről, ahol az y tengely Sprint, az x tengely pedig a hátralévő munka mértéke (napok, órák vagy történetpontok). De mi van, ha több munka kerül a projektbe, vagy a becsült munka nem felel meg az elvárásoknak?
az alábbi táblázatban egy csapat négy sprintben tervezte befejezni a projektet, és kezdetben 45 történetpontot kapott. Míg az első és a második Sprint során a haladás a tervek szerint ment, a harmadik sprintnél a becsült munka növekedett, ami negatív értékekben tükröződik az y tengelyen. A harmadik sprint során 5 új történetpont jelent meg. Nem fejezték be, és a negyedik sprint további 5 történetpontot adott hozzá. Ezért az előrehaladást és a kiadási időt módosítani kellett.
a release burndown chart rendkívül hatékony olyan helyzetekben, ahol sok változó követelmény van, és lehetővé teszi a csapat számára, hogy minden sprint alatt a pályán maradjon
hogyan segíthet a release burndown chart?
valós idejű előrejelzés a kiadáskor. Miután a projekt változásokon megy keresztül, ami minden alkalommal megtörténik Az iteratívan fejlődő termékekkel, látnia kell, hogy ezek a változások hogyan befolyásolják a megjelenés dátumát. A release burndown chart lehetővé teszi a megjelenési dátum valós időben történő előrejelzését a munkaterület frissítéseinek megfelelően.
határidő előrejelzések. Megbecsülheti, hogy a csapat képes-e időben befejezni a termékkiadást, vagy előre láthatja, hogy a határidőnek tovább kell haladnia a hozzáadott feladatok figyelembevételével.
a sprintek számának becslése. Annak felmérése, hogy hány sprintre van szükség a munka befejezéséhez, szintén fontos tényező, amelyet figyelembe kell venni a kiadási burndown diagramon.
Folyamatállapot értékelése és szűk keresztmetszetek keresése
ciklusidő
a ciklusidő mutató azt írja le, hogy mennyi időt töltöttek el egy tevékenységgel, beleértve minden egyes alkalommal, amikor a munkát újra meg kellett nyitni és újra be kellett fejezni. A ciklusidő kiszámítása információt nyújt az Általános teljesítményről, és lehetővé teszi a jövőbeli feladatok elvégzésének becslését. Míg a rövidebb ciklusidő a jobb teljesítményt szemlélteti, azokat a csapatokat értékelik a legjobban, amelyek következetes cikluson belül teljesítenek.
az alábbi táblázat segítségével azonosíthatja a feladat elvégzéséhez szükséges átlagos időt, rajzolhat egy közép-vagy vezérlőkorlátot, amelyet nem szabad átlépni, és észreveheti, hogy mely feladatok elvégzése szokatlanul sokáig tartott.
a szórás vonalat húz a feladat elvégzéséhez szükséges normál és nem ajánlott napok száma között
egy adott időszak összes ciklusát is egymásra rakhatja, és betekintést nyerhet más adatokkal való összehasonlításából. További vizsgálat elvégzésével következtetéseket vonhat le a munka minőségéről.
itt láthatja, hogy a márciustól júniusig elvégzett feladatok száma nőtt, csakúgy, mint a hibák száma
hogyan kell használni a ciklusidőt
keresse meg a hasonlóságokat. Jó gyakorlat olyan hasonló elemek megtalálása, amelyek kiszámíthatatlan ciklusidőket igényelnek, feltárva az ismétlődő problémákat, akár a mérnöki, akár a menedzsment területén.
jóslatok rajzolása. Adatvezérelt döntéseket hozhat úgy, hogy előrejelzi az új feladatok elvégzésének idejét a múltbeli hasonló feladatok alapján.
Kövesse nyomon a tempót. A diagram leírja, hogyan tarthatja meg ugyanazt a munkatempót, és meghatározza, hogy vannak-e olyan belső problémák, amelyek csökkentik a munka sebességét.
kumulatív folyamatábra (CFC)
a kumulatív folyamatmutatót a projekt minden szakaszában a különböző típusú feladatok számát mutató diagramterület írja le, az x tengely jelzi a dátumokat, az y tengely pedig a történetpontok számát. Fő célja, hogy könnyen megjelenítse a feladatok különböző szakaszokban történő elosztását. A diagramon lévő vonalaknak többé-kevésbé meg kell maradniuk, még akkor is, ha a “kész” feladatokkal rendelkező sávnak folyamatosan növekednie kell.
a diagram sok kritikus információt tár fel, például hirtelen szűk keresztmetszeteket vagy emelkedéseket bármelyik sávban
a CFC nagy hasznát veszi a Kanban csapatok számára, mint a csapat munkájának egyszerű vizualizálása. A diagram megfelel a Kanban háromlépcsős munkafolyamatának is. Itt három fő feladatkategóriát is feltérképezhet: tennivaló, folyamatban és befejezett.
ezenkívül a diagram segít azonosítani, ha a work-in-progress (WIP) határértékeket túllépik. Mivel az agilis fejlesztés egyik legértékesebb eszköze, a WIP-korlátok célja a befejező munka kultúrájának ápolása és a multitasking megszüntetése azáltal, hogy beállítja az egyes projektállapotok maximális munkamennyiségét.
milyen kérdésekre hívja fel a figyelmet a CFC?
- a lemaradás növekedése azokat a megoldatlan feladatokat jelzi, amelyek jelenleg túl alacsony prioritásúak vagy elavultak
- az inkonzisztens áramlás és a hirtelen szűk keresztmetszetek jelzik, hogy mely területeket kell kisimítani a későbbi szakaszokban
- az egyes sávok szélessége mutatja az átlagos ciklusidőt
- a “folyamatban lévő” terület jelentős kiszélesítése azt jelentheti, hogy a csapat nem tudja befejezni a teljes projekt időben
áramlási hatékonyság
az áramlási hatékonyság nagyon hasznos mutató a kanban fejlesztésében, amelyet a fejlesztés többnyire figyelmen kívül hagy csapatok. Míg az áramlás hatékonysága kiegészíti a kumulatív áramlást, betekintést nyújt a tényleges munka és a várakozási idők közötti eloszlásba. Ez egy ritka eset, amikor egy fejlesztő dolgozik egy dolog egy időben várakozás nélkül. A valóság általában összetettebb. A “folyamatban lévő munka” pedig olyan név, amely nem mindig felel meg az állapotnak.
például a kódnak számos függősége lehet, és nem kezdheti el a munkát egy másik funkció befejezése előtt, vagy a prioritások megváltoznak, vagy az érdekelt felek jóváhagyására vár. Annak mérése, hogy mennyi időt vár a munkával szemben, még hasznosabb lehet, mint a tényleges munkával kapcsolatos folyamatok egyszerűsítése.
a legalacsonyabb hatékonysági mutatók áttekintésével megértheti a fő szűk keresztmetszeteket
hogyan kell használni az áramlási hatékonyságot
számítási képlet. Hacsak nem alkalmaz olyan projektmenedzsment szoftvert, amely magában foglalja ezeket a mutatókat, kiszámíthatja az áramlás hatékonyságát ezzel az egyszerű képlettel: munka/(munka+várakozás) * 100%. Ezután digitálisan megjelenítheti, vagy akár rajzolhatja a grafikont az irodai táblára.
határozza meg a normál áramlási hatékonyságot. Mint minden más mutatónál, lehetetlen az összes projekt normál adatait igényelni. Egyesek szerint a 15 százalékos jel a legtöbb projektnél rendben van, ami alapvetően azt jelenti, hogy egy történetpont vagy egy másik munka 85 százalékot vár a 15 százalékos feldolgozási idővel szemben. David J. Anderson, a LeanKanban School of Management menedzsment szakértője azt javasolja, hogy a legtöbb csapat számára 40% – ot vagy annál magasabb legyen a cél.
bontsa le a munka részleteit az áramlás hatékonyságának rögzítése előtt. A diagram lehetővé teszi a pontos időszakok megtekintését, amikor a hatékonyság a legalacsonyabb volt. És ezeket az adatokat nagyon óvatosan kell elemezni, mivel a valódi okot és annak orvoslását nem fedik fel olyan könnyen. Az intenzív tevékenységek megkezdése előtt alaposan vizsgálja meg az okokat.
növelje az áramlás hatékonyságát blokkoló elemzéssel. Az előző pont megvalósításának jó eszköze az áramlás hatékonyságának növelése blokkoló klaszterelemzéssel. Ha valamilyen munkát blokkolnak, akkor színes matricát vagy más vizuális jelet érdemel, hogy felhívja ezekre a blokkolókra a csapat figyelmét, hogy reagálhassanak rájuk.
megjelölheti, hogy a munka egy része hány napig van blokkolva, és prioritásként kezelheti a felbontást
a blokkolók általában klaszterekben halmozódnak fel, mivel sok függőségük van egymással. Jobb blokkoló elemzést lehet végezni, ha csoportosítja őket kezdve a magas szintű hasonlóságok, mint a belső és külső blokkolók, majd meghatározza tovább tervezés, Hiányzó tartalom, vagy más hiányzó funkciók. Blokkoló elemzés egy egyszerű módja annak, hogy vizsgálja meg a völgyek áramlási hatékonyság.
Kódminőség mérése
kód lefedettség
kód lefedettség meghatározza, hogy hány sornyi kód vagy blokk kerül végrehajtásra az automatizált tesztek futtatása közben. A kód lefedettség kritikus mutató a tesztvezérelt fejlesztési (TDD) gyakorlat és a folyamatos szállítás szempontjából. Hagyományosan a metrikát egyszerű megközelítéssel értelmezik: minél nagyobb a kód lefedettség, annál jobb. Ennek méréséhez szüksége lesz az egyik rendelkezésre álló eszközre, például a kezeslábasra. De mindegyik nagyjából ugyanúgy működik: a tesztek futtatásakor az eszköz felismeri, hogy a kódsorok közül melyiket hívják meg legalább egyszer. A hívott vonalak százalékos aránya a kód lefedettsége.
kezeslábas, például, lebontja a kód lefedettség minden fájl mérési és jelölje ki a fedett és fedetlen vonalak
hogyan kell használni kód lefedettség
Fókuszban a fedetlen vonalak és nem túlbecsülni a lefedett is. Ha a kódsort egyszer vagy még többször hívják meg, ez nem feltétlenül jelenti azt, hogy az általa támogatott funkció tökéletesen működik, és a felhasználók elégedettek maradnak. A kódsor meghívása nem mindig elegendő a tesztelési feladat lezárásához. Másrészt a fedetlen vonalak százalékos aránya azt mutatja, amit egyáltalán nem fedtek le, és érdemes lehet tesztelni.
rangsorolja a fedett kódot, és ne célozza meg a 100% – ot. Bár ez ellentmondásosnak tűnik, a 100 százalékos lefedettség nem jelenti azt, hogy megfelelően tesztelte a kódot. A projektnek megvan a kódja, ami számít, a többi pedig egy kódbázis. Mivel az automatizálás tesztelése általában drága kezdeményezés, prioritásként kell kezelnie a funkciókat és a megfelelő kódrészleteket.
Tesztautomatizálás kézi tesztelés ellen
ez a mérés azt határozza meg, hogy egy funkción belül hány sornyi kód van már lefedve automatizált tesztekkel a manuálisan teszteltekkel szemben. Ez közvetlenül követi az előző mutatót, de van egy speciális felhasználási esete. A tesztautomatizálás aránya a kézi teszteléssel szemben csak akkor használható, ha kritikusan szükség van automatizálásra a regressziók fedezésére. Regressziós tesztelést végeznek annak ellenőrzésére, hogy valami megszakadt-e a szolgáltatásfrissítések után. És ha a termék folyamatos fejlesztéseken megy keresztül – amit meg kell tennie-a regresszió tesztelését automatizálni kell. Ha nem, akkor a kézi minőségbiztosítási szakembereknek minden frissítés után ismételten meg kell ismételniük ugyanazokat a tesztforgatókönyveket.
a kódfedéshez használt eszközökkel rajzolhatja meg ezt a mutatót
az automatikus tesztfedezet funkciónkénti felvázolása lehetővé teszi, hogy rangsorolja azokat a funkciókat, amelyek 1) A frissítések utáni regressziótól szenvedhetnek, és 2) amelyek esetében az automatizált tesztek kritikusak. Általában nincs elég idő és emberi erőforrás, hogy mindent lefedjen automatizált tesztekkel egyszerre, kivéve, ha a tesztvezérelt fejlesztési keretben dolgozik. Tehát jobb, ha rangsorolja azokat a funkciókat, amelyek biztosan befolyásolják a felhasználói élményt.
McCabe Cyclomatic Complexity (MCC) kód
kód komplexitás méréseket használnak, hogy értékelje a Kockázatok problémák során kód tesztelés és karbantartás. Minél nagyobb a kód összetettsége, annál nehezebbé válik annak biztosítása, hogy elfogadható számú hibával rendelkezzen, és magas karbantarthatóságot tartson fenn. A kód bonyolultságának mérésére a leggyakoribb megközelítés a McCabe Ciklomatikus komplexitási mutató (MCC). Az MCC komplexitási eredményeinek megrajzolására szolgáló egyik képlet a következő:
MCC = élek-csomópontok + visszatérési utasítások
MCC a képen egyenlő 3
ezzel a mutatóval a fejlesztők nem becsülik meg a kód bonyolultságát szubjektíven nézve. Mivel a mérnökök képességei különböznek, értékelésük eltérő, ami hosszabb távon nagyobb kihívást jelent a kód refaktorálása vagy a hibák kijavítása. Számos MCC mérési eszköz létezik a piacon, amelyek kombinálhatók más kódösszetételi mutatókkal, például a kódhierarchia mélységével és a kódsorok számával.
az MCC specifikációkat és buktatókat használ
egyensúlyozza az emberi és gépi észlelést a kód összetettségéről. Az MCC használatának egyik fő oka az, hogy a kódot olvashatóvá tegye a többi fejlesztő számára. A kód olvashatósága csökkenti az új fejlesztők hosszú távú bevonásának kockázatát, akiknek a régi kóddal kell foglalkozniuk. Ez egyszerűsíti a refaktorálást is az úton. A probléma itt az, hogy az MCC modell elfogadhatatlannak tekinthet néhány összetett, mégis olvasható módszert. És ha arra kényszerítesz egy fejlesztőt, hogy komplex módszereket sok almódszerre alakítson át, akkor ellentétes eredményeket érhet el: sok egyszerű logikával rendelkező módszer még nehezebbé válhat az ember számára, mint egyetlen, mégis összetett módszer.
ne tegye az MCC-t korlátozó mutatóvá. Egyes szervezetek gyakorolják a code commits megszüntetését, amelyek nem felelnek meg az MCC tesztnek. Bár ez potenciálisan növelheti a kód egyszerűségét, természetes, hogy összetett kód van az osztályok, módszerek és függvények szintjén. A teljes blokkolás nem mindig előnyös. Jó gyakorlat az Általános kódösszetétel KPI beállítása a fejlesztők számára, ami arra ösztönzi őket, hogy tudatosabban közelítsék meg a kódolást és gondolkodjanak az egyszerűségről.
alkalmazza az MCC-t a kód felülvizsgálatához. Az MCC tesztek másik értékes gyakorlata az, hogy a kódvizsgálatok során alkalmazzák, hogy szűkítsék a munka körét az egyes kóddarabok felülvizsgálatára, ahol a hibák kockázata a legnagyobb.
Code churn
A Code churn nagyon hasznos vizualizációja azoknak a trendeknek és ingadozásoknak, amelyek egy kódbázissal történnek mind a teljes folyamat, mind a kiadás előtti idő szempontjából. A lemorzsolódás azt méri, hogy hány sornyi kódot adtak hozzá, távolítottak el vagy változtattak meg. Néha a Grafikonok mindhárom mérést mutatják.
ez a Microsoft példája mindhárom paramétert tartalmazza, de szelektíven használhatja őket
bár a követőkód lemorzsolódása kissé primitív mutatónak tűnhet, lehetővé teszi a kód stabilitásának felmérését a különböző fejlesztési szakaszokban. A legkisebb stabilitásra számíthat a korai sprintek során, és a legmagasabb stabilitásra – az ezzel járó legalacsonyabb lemorzsolódással – közvetlenül a kioldás előtt. Ha a kód nagyon instabil, és a kiadás dátuma közeledik,riasztson.
Code churn használati esetek
keresse meg a szabályszerűségeket. A kódváltozások rendszeres tüskéi azt mutatják, hogy a feladatgenerálási megközelítés nem eléggé koncentrált, és sok nagy feladatot hoz létre ismétlődő alapon.
szabálytalan, de magas tüskék vizsgálatot igényelnek. Ha szabálytalan, de erőteljes tüskék vannak a kódváltozásokban, megvizsgálhatja, hogy mely feladatok okozták az ilyen szeizmikus csúcsokat a kódban, és átgondolhatja a függőségek szintjét, különösen, ha az új kódsorok száma növelte a megváltozott sorok számát is.
figyeljen a trendekre. A termék stabilitása meglehetősen kritikus lesz a kiadás előtt. Mint említettük, a lemorzsolódási aránynak csökkenő tendenciát kell mutatnia, minél közelebb kerül a csapat a kiadáshoz. A növekvő tendencia a termék esetleges instabilitását jelenti a kiadás után, mert valószínű, hogy az új kódot nem vetik alá megfelelő tesztelésnek.
cél a haladás, nem ellenőrzés
csakúgy, mint bármely más teljesítménymutatók, agilis mutatók nem mindig külön választ, vagy cselekvésre tipp, hogy pecsét a siker. Azonban az általuk nyújtott ismereteket fel kell használnia a vita megkezdéséhez, az értékelés elvégzéséhez és a saját tervének felajánlásához a problémás kérdések kezelésében.
míg a mutatók számszerű betekintést nyújtanak a csapat teljesítményébe és a munkával való általános elégedettségbe, ne rögzítsük őket. Figyelembe véve, hogy az agilis mutatók nem szabványosítottak, nincs értelme összehasonlítani a különböző csapatok sikereit. Inkább győződjön meg róla, hogy elfogadja a csapat visszajelzését, rendszeres megbeszéléseket kezdeményez, és táplálja a közös célok és támogatás légkörét.