Az agilis mérőszámok olyan mérések, amelyeket egy agilis projektcsapat előrehaladásának és sikerének nyomon követésére használnak.
A megfelelő módon meghatározott mérőszámok betekintést nyújtanak a csapat teljesítményébe, minőségébe, tesztelési hatékonyságába vagy általános eredményességébe, és betekintést nyújtanak a csapat teljesítményébe, minőségébe, a tesztelés hatékonyságába vagy általános hatékonyságába, és betekintést nyújtanak a csapat teljesítményébe, minőségébe, a tesztelés hatékonyságába vagy általános eredményességébe, valamint ezek időbeli alakulásába.
Az agilis mérőszámok végső célja, hogy segítsék a csapatokat a fejlesztésre szoruló területek azonosításában, és olyan adatvezérelt döntések meghozatalában, amelyek a csapat előrehaladtával jobb termékekhez vezetnek.
A legtöbb esetben a vállalatok olyan mutatókat határoznak meg, amelyek vagy hiúsági mutatók, vagy nyers számok, szépen balról jobbra növekedve. Lehet, hogy jól néznek ki néhány műszerfalon, de általában haszontalanok magának a csapatnak.
Céljuk nem az, hogy bármilyen módon segítsék a csapatot, hanem az, hogy néhány jelentést kitöltsenek a vezetés számára, majd néhány stratégiai döntést meghozzanak. Sajnos ilyenkor a csapat nem érti, miért létezik ez a döntés.
Az ilyen rossz mérőszámok teljesítésére szolgáló kerítésben a csapatok meghamisítják saját folyamataikat, hogy a mutatók jól nézzenek ki. De a csapat teljesítménye egyáltalán nem javul.
Tartalomjegyzék
Alapvető mérőszámok
Számos módja van a mutatók elkülönítésének. Talán a legalapvetőbb a felülről lefelé és alulról felfelé.
➡️ A felülről lefelé történő megközelítés azt jelenti: Mi, vezetés olyan mutatókat hozunk létre számodra, amelyeknek szeretnénk, hogy mindannyian megfeleljenek, és a végső cél az, hogy ezek zöldterületeibe illeszkedjen. Nem bánjuk, ha Ön – egy csapat szereti őket, vagy sem; ezt szeretnénk követni.
➡️ Az alulról felfelé építkezés azt jelenti: Nekünk – a csapatnak fejlődnünk kell ezeken a területeken, ehhez pedig ezekre a dolgokra kell koncentrálnunk. Ezért olyan mérőszámokat határozunk meg, amelyek segítségével nyomon követhetjük a csapat előrehaladását a céljaink felé, és megmutathatjuk Önnek – vezetés, hogyan javította a munkánkat az idő múlásával.
A jó mérőszám definíciója
Tehát mit kell tartalmaznia egy jó mérőszámnak, vagy hogyan kell leírni?
A legfontosabb tulajdonság a viselkedés megváltoztatása. Ez azt jelenti, hogy minden alkalommal, amikor megnézzük a mérőszám eredményét, egyértelmű, hogy minek kell változnia a csapaton belül a fejlesztések eléréséhez.
Akkor egyszerűnek kell lennie. Ha nem tudod néhány egyszerű mondattal úgy elmagyarázni, hogy minden érintett hallgató megértse, akkor valami nem igazán jó.
A jó mérőszám idővel összehasonlítható. Készítsen pillanatfelvételt az eredményekről egy idő után, majd ismételje meg valamikor később. Helyezze őket egymás mellé. Ha nem tudja összehasonlítani a két eredményt egymással, akkor érdemes átgondolnia ezt a mérőszámot.
Végül a tiszta számoknál jobb, ha csak lehetséges, arányt vagy százalékot kell megadni. „10 új nyitott hiba a sprint alatt” nem sokat mond. Attól függ, hogy általában 1 vagy 100 van.
Íme néhány példa azokra a mérőszámokra, amelyek véleményem szerint megfelelnek ezeknek a meghatározási feltételeknek. Kifejezetten agilis csapatokra gondolnak. Három fő kategória van: teljesítmény, minőség és morál.
A mérőszámok kategóriái
Teljesítmény adatok
A cél az, hogy megértsük, milyen jó a csapat a sprint során elkövetett történetek felzárkóztatásában. Annak értékelésére, hogy a túlzott elkötelezettség nem a szokásos üzletmenet, vagy az átviteli történetek szabványosak-e sprintről sprintre.
Az agilis teljesítmény szempontjából a csapatnak arra kell törekednie, hogy tervezett sprint tartalmat biztosítson, amely mellett a csapat a sprint elején elkötelezte magát.
Ez nem jelenti azt, hogy ne legyünk rugalmasak a történetek cseréjében a sprint során. De ennek mindig egy cseréhez vezető tárgyalásnak kell lennie, nem pedig kiegészítésnek. A csapat kapacitása nem fog növekedni csak azért, mert valaki új sztorikat adott hozzá a sprintben.
Azért hozzuk ezt a mérőszámot, hogy vigyázzunk az ilyen esetekre, és a csapatban mindenkit irányítsunk, hogy megvédje a sprinthez szükséges kapacitását.
Ez növeli a csapat megbízhatóságát és kiszámíthatóságát.
#1. Sprint kapacitás kontra kiadott történetpontok
Tekintse meg a sprint kapacitásának történetét a szállított történetpontok (SP) tartalmával szemben a sprintek során.
- Kis eltérések a sprinttől a sprintig rendben vannak. Hatalmas ugrások bármely irányba jelzik, hogy valami nincs rendben.
- Teljes Sprint kapacitás – egy csapattag szabad napja eggyel növeli a teljes kapacitást. Pl. Ha a csapat 10 fős, és mindegyik elérhető lesz a teljes sprintben, akkor a sprint teljes kapacitása 100 fő.
Ellenőrizze a sprint kapacitását a teljesített SP-hez képest sprintről sprintre. Ha a csapat (a tervezés során) lényegesen nagyobb összegű SP-re kötelezi el magát, mint amennyit a csapat általában teljesíteni tud, emelje fel ezt a kockázatot a csapat számára.
A cél az, hogy az összes tervezett SP egyenlő vagy kevesebb legyen, mint a sprintenkénti teljes teljesített SP.
Továbbra is több teljesített SP-vel rendelkezhet a tervezettnél, ha a csapat teljesítette (a sprint vége felé) az összes tervezett történetet, és a csapatnak még van kapacitása a további sztori elvégzésére.
- Ha a csapat ismételten kevesebb SP-t szállít a tervezettnél, a csapatnak módosítania kell a tervezést, és kevesebb SP-t kell bevinnie a következő sprintbe.
Az olyan eszközök, mint a monday.com, az Atlassian Jira vagy az Asana, mind egyszerű módot kínálnak a történetpontok mentésére és kinyerésére a sprintek minden egyes történetéhez. Sőt, minden sprinttervezés után automatikusan generálhatják ezt Önnek.
#2. Leégési diagram
Ez az egyik mérőszám, amely valószínűleg a legtöbb scrum-csapatnak van valahol elrejtve a műszerfalon. Egyetértek azzal, hogy ez akár haszontalan dolognak is tűnhet. A csapat ritkán veszi figyelembe. A menedzser inkább arra szeretne rámutatni, hogy a történetek magas szintről hogyan néznek ki, és hogy nem haladnak jól (mivel az egész sprintben nyitottak).
Amit szeretném kiemelni, az az, hogy ennek ellenére neked, mint csapatnak, menj el és nézd meg a leégési diagramot a saját érdekedben. Ha az összes történet az egész sprint alatt nyitva van, és csak a sprint utolsó napján zárják le, ez bizonytalanságot kelt a csapaton belül és a sprintcélok teljesítése felé.
- Tekintse át a sprinttáblát az elkészült történetekért.
- Kérdezze meg a csapatot, hogy megállapítsa, miért nyitottak még mindig kis történetek, még akkor is, ha a sprint elején kezdődtek.
- Dolgozzon együtt a csapattal, hogy kialakítsa ezt a gondolkodásmódot, és ne tartsa nyitva a történeteket a szükségesnél tovább.
- Az ideális leégési diagram általában egy elméleti állapot. Azonban minél közelebb jutunk hozzá, annál hatékonyabb a történetkezelés.
Az olyan agilis menedzsmenteszközök, mint az Asana, automatikusan generálhatnak egy leégési diagramot minden egyes sprinthez.
Forrás: asana.com
#3. Sprint cél teljesítése
Ez nyomon követi az egyes sprintek során elért sprintcélok százalékos arányát.
A Sprint célokat külön dokumentálja, pl. a Confluence oldalon / Jira minden egyes sprinthez. A státuszt hozzá kell rendelni attól függetlenül, hogy a sprint során teljesítették-e vagy sem.
Még ha a csapat nem is teljesített minden történetet egy sprint alatt, akkor is elérheti a Sprint célt (pl. csak a melléktörténetek hiányoznak).
Minden sprintben a 100%-os sprintcélok teljesítésére törekszünk. Ha ez nem így van, derítse ki, mit akadályoz meg a csapat.
- Ha túl sok párhuzamos téma van minden sprintben, csökkentse ezek számát.
- Ha túl sok ad hoc történetet adnak hozzá a sprint során, csökkentse ezt, hogy ne befolyásolja az eredeti sprintcélokat.
- Ha a sprintcélok túl nagyok vagy túl nagy kihívást jelentenek, egyszerűsítse. Amúgy semmi értelme nagy sprintcélokat kitűzni, miközben azokat a sprint végére nem teljesítik.
Kódminőségi mutatók
Ez nyomon követi, hogy a kód mennyire jó az idő múlásával. Segít fenntartani az egészséges fejlődési folyamatokat, és csökkenti a problémák megoldására fordított időt. Vagy a fejlesztő tétlenségi ideje, amelyet a fejlesztői és teszttevékenységek során a kód végrehajtására való várakozás okoz.
Forrás: azuredevopslabs.com
#1. Automatizált tesztek
Hozzon létre automatizált egységteszteket a fejlesztők által minden egyes változtatáshoz.
- Mérje meg a kódlefedettséget automatizált tesztekkel – használja az Azure Pipelines vagy a SonarCloud szolgáltatást a tesztek futtatásához. Cél a 85%-os lefedettség. 90% felett nem igazán hatékony.
- Győződjön meg arról, hogy az automatizált egységteszt létrehozása része az új történetek kész definíciójának.
- Érje el a régi kódteszt-lefedettséget a technikai adósságtörténetek részeként.
#2. A kód összetettsége
Értékelje a kód által idővel felmerülő szükségtelen bonyodalmakat, és aktívan javítsa ki a technikai adósságtörténetekkel. Vagy lehetőség szerint akadályozza meg, hogy megtörténjenek.
Határozzon meg kódszabványokat és irányelveket, hogy a fejlesztőket betartsa. Győződjön meg arról, hogy betartják a kódolási szabályokat, hogy minimalizálják a kód bonyolultságának indokolatlan növekedését. A csapat tapasztalatai alapján rendszeresen frissítette az irányelveket.
Kódszagok azonosítása – a kód lehetséges problémáinak jelzői, mint például a duplikált kód, a hosszú metódusok és a nem használt változók.
A szakértői felülvizsgálatoknak biztosítaniuk kell a kódszabványok alkalmazását az újonnan létrehozott kódra.
A kódproblémák felfedezéséhez használjon olyan eszközöket, mint az Azure Ado vagy a SonarCloud irányítópultok és jelentések.
#3. Kézi lépések a telepítésben
Kövesse nyomon, hány kézi lépést kell végrehajtania a csapatnak a kód teszt- vagy éles környezetbe való kiadásához.
- A célunk az lesz, hogy idővel elérjük a 0-t.
- Ha szükséges, hozzon létre műszaki adósságtörténeteket, hogy a telepítési/kibocsátási folyamatot az automatizálási ütemtervig érje el. Fokozatosan csökkentse a hátralévő manuális lépéseket a sprintről a sprintre.
Moráli mérőszámok
Ez egy olyan mérőszám, amely nyomon követi, hogyan vélekedik a csapat a munkájukról és a napi folyamatokról.
#1. Sprint Retrospektív Teljesítés
Nyomon követheti, hogy a következő sprintben hány akcióelemet hajtottak végre.
- A Scrum Master összegyűjti a Retrospektív találkozó eredményeit a csapat oldalaira, hogy nyomon követhesse az egyeztetett akcióelemeket.
- A csapat ezután nyomon követi a fejlődést.
- A projektvezetés ezután áttekintheti, hogy a műveleti elemek előrehaladnak-e, vagy mi akadályozza meg a csapatot a végrehajtásukban. Ezután módosítsa a környezetet, hogy lehetővé tegye a csapat számára az előrelépést az egyeztetett műveleti tételekben.
Az előző sprint akcióelemeinek legalább 33%-a vagy 1 (attól függően, hogy mi a magasabb) átkerül a következő sprintbe.
Ha ennél kevesebb, akkor változtatásokra van szükség ahhoz, hogy a csapat végrehajthassa az egyeztetett fejlesztéseket.
A projektmenedzsment eszközök használatra kész sablonokat tartalmaznak a sprint retrospektív tevékenységekhez. Íme egy példa a monday.com oldalról:
Forrás: monday.com
#2. Csapat együttműködés
Pályapár programozás.
- Alkossatok természetes párokat történetenként, hogy együtt dolgozzanak, megosszák a megfigyeléseket, a tudást és a sikert. Hozzon létre részfeladatokat a különböző csapattagok tulajdonában lévő történetek alatt.
Követőkód-értékelések a társak kezdeményezéseiből.
- A társakat felkérik, vagy proaktívan intézkednek valaki más történetének áttekintésére.
A mérőszám a monday.com/Asana/Jira tábláról kinyerhető a részfeladatok közül.
A sprint történeteinek legalább 50%-át a csapattagoknak meg kell osztaniuk. Ha ez kevesebb, vizsgálja meg az okokat, és tegyen lépéseket, ahol van értelme.
Önkéntes szakértői értékelések esetén kövesse nyomon a történeteket a dedikált részfeladatokkal. Kezdetben az így áttekintett kódtörténetek 20%-a jó kezdet. Fokozatosan a sprintek során ösztönözni és motiválni kell a csapatot az együttműködésre, és célként növelni kell a kódsztorik 50%-át sprintenként.
#3. Műszaki adósság kontra új funkcionalitás történetek
Forrás: atlassian.com
Ha lehetőséget adunk a csapatnak saját adósságtörténeteik megoldására, az növeli a csapat elégedettségét a munkájukkal.
- Éppen ellenkezőleg, a technológiai adósságproblémák felhalmozódása anélkül, hogy terv lenne a fokozatos megoldásukra, idővel demotiválja a csapatot. És a megoldás instabilabbá, összetettebbé válik, és lényeges átdolgozás nélkül nehezen megoldható.
A csapat tudja a legjobban, hogy mi nem működik jól a megoldással, még akkor is, ha az érintettek vagy a végfelhasználók nem látják. Az ilyen történetek a legnagyobb hatással magukra a fejlesztői csapatra. Az érintettek számára láthatatlanok lehetnek. Ezért fontos, hogy lehetőséget adjunk a csapatnak, hogy olyan történeteken dolgozzanak, amelyek segítik őket a fejlesztési tevékenységek lebonyolításában.
A cél annak nyomon követése, hogy hány felvett technikai adósságtörténetet oldanak meg idővel, és hogy az ilyen sztorik hátraléka csak nő-e vagy sem.
A csapat TechDebt-ként címkézheti a történeteket a lemaradásban, és elsőbbséget adhat nekik a csapattól, így továbbjuthatnak a csúcsra, és kiválaszthatják őket a sprintekben.
Attól függően, hogy melyik állapotban van a projekt, és hány technológiai tartozást azonosítottak a lemaradásban, érdemes lehet biztosítani, hogy a TechDebt lemaradás sprintről sprintre ne növekedjen 10%-nál nagyobb mértékben.
Rögzítse a technológiai adósságtörténeteket, és vegye fel őket a sprintekbe, hogy kordában tartsa a technológiai adósságállomány növekedését, így a csapat minden sprint alkalmával 10-20%-ban dolgozhat a technológiai adósságtörténeteken.
Végső szavak
Minden projektnek végül szüksége lesz bizonyos mérőszámokra, akár azért, mert a vezetés akarja ezeket, akár azért, mert a csapat úgy dönt, hogy saját sikerét méri.
A legjobb, amit tehet, ha elkezdi felépíteni a metrikákból álló könyvtárát, amely készen áll a kiválasztásra és felhasználásra; minél előbb, annál jobb. És közben ügyeljen arra, hogy mindenekelőtt mindig a viselkedésmódosító mérőszámokat használja.
Ezután nézze meg az egészségtelen folyamatokat, amelyek tönkretehetik a sprintet.