Annak ellenére, hogy a gyakorlati készségek és a konkrét programozási nyelvek, eszközök és technológiák ismerete a kulcsa a teljes munkaidős szoftverfejlesztői állás megszerzésének, van egy másik értékes mutató, amely sok tekintetben a siker előfeltételének tekinthető ebben a szakmában: termelékenység. A termelékenység mérését minden professzionális szoftverfejlesztőnek meg kell értenie és figyelembe kell vennie, mivel a teljesítménymutatók alapvetően fontosak minden szoftverfejlesztő csapat számára a mai üzleti környezetben.
Miért számít az Ön produktivitása fejlesztőként?
Az agilis fejlesztés, a DevOps és a zsugorodó szoftverkiadási ciklusok korszakában, amikor a fejlesztőknek a lehető leggyorsabban el kell szállítaniuk a termékek új verzióit, a vállalatok többféle termelékenységi mérőszámot használnak az egyes programozók és a csapat egészének teljesítményének értékelésére. Fejlesztői szemmel nézve a teljesítménymérés számos értékes célt szolgálhat, segítve nyomon követni programozási készségeinek fejlődését, ami lehetővé tenné a folyamatos szakmai fejlődést. A rendkívül produktív kódolók azok, akik pofás fizetési ajánlatokat kapnak, és a legizgalmasabb projekteken kezdenek dolgozni. De még akkor is, ha nem vagy éppen nagy teljesítményű, és csak bármilyen munkát szeretne a szoftverfejlesztés területén, és abban ésszerűen sikeres lenni, továbbra is legalább alapvető ismeretekkel kell rendelkeznie a teljesítménymutatókról, és arról, hogy ezeket hogyan használják fel a munkahelyi ráfordítások termelékenységének mérésére. Erről fogunk ma beszélni.
Mik azok a szoftverfejlesztés termelékenységi mutatói?
A szoftverfejlesztési mérőszámok a programozási munka azon területei, ahol kvantitatív mérések alkalmazhatók a fejlesztő teljesítményének, munkaminőségének és termelékenységének nyomon követésére. Minden termelékenységi mérőszám a fejlesztési folyamatból származó adatok gyűjtésén és a termelékenység mérésén alapul. Mivel a szoftverfejlesztéssel kapcsolatban jóformán semmi sem egyszerű és egyértelmű, azt mondhatjuk, hogy a programozási termelékenység mérése is meglehetősen következetlen és széttagolt az iparágon belül. Vagy egyszerűen fogalmazva, a különböző csapatok és vállalatok teljesen eltérő teljesítménymutatókat használhatnak, és számos oldalról közelíthetik meg ezt a kérdést. Így nem kell vesződnie azzal, hogy megtanuljon minden egyes mérőszámot, amelyet a szoftverfejlesztő csapatok használhatnak.
Milyen típusú szoftverfejlesztési termelékenységi mérőszámok léteznek?
Természetesen számos különböző termelékenységi mérőszám létezik, amelyek a teljesítmény mérését különböző szinteken és szögekből közelítik meg. Íme az ilyen termelékenységi mutatók leggyakoribb típusai:
Formális méretközpontú mérőszámok.
Ezek a mérőszámok a programozó munkavégzésének méretének mérésére összpontosítanak, például a kódsorokra (LOC), a kódutasítások hosszára, a kód bonyolultságára stb. Ezeket a mutatókat egyre inkább elavultnak tekintik a mai szoftverfejlesztési iparágban.
Idő- és funkcióközpontú termelékenységi mutatók.
A waterfall szoftverfejlesztésben használt hagyományos termelékenységi mérőszámok közül választhat, mint például az aktív napok, a meghatározott időn belül szállított funkciók köre, a kódlemorzsolódási arány, a hozzárendelt feladatok száma stb.
Agilis fejlesztési folyamat mérőszámai.
Az agilis fejlesztési folyamat mérőszámai, mint például a sprint leégési jelentés, sebesség, átfutási idő, ciklusidő és mások, ma valószínűleg a leggyakrabban használt mérőszámok a szoftverfejlesztő csapatok körében. Az agilis mérőszámokról a cikk későbbi részében részletesebben fogunk beszélni.
Operatív analitikai mérőszámok.
Ez a mérőszámkészlet a szoftver teljesítményének mérésére összpontosít a jelenlegi éles környezetben. A hibák közötti átlagos idő (MTBF), az átlagos helyreállítási idő (MTTR) és az alkalmazás összeomlási aránya a leggyakrabban használt mérőszámok itt.
Mérőszámok tesztelése.
A szoftvertesztelés saját mérőszámokkal rendelkezik a rendszertesztelés minőségének mérésére, például az automatizált tesztek százalékos aránya, a kódlefedettség stb.
Ügyfél-elégedettségi mutatók.
Végül minden szoftver végső mérőszáma a végfelhasználói élmény, és ehhez is létezik egy sor mérőszám, mint például a vásárlói erőfeszítések pontszáma (CES), az ügyfél-elégedettségi pontszám (CSAT), a nettó promóter pontszáma (NPS). és mások.
Agilis szoftverfejlesztési mérőszámok
Amint látja, nagyon könnyű eltévedni a szoftvertermelékenységi mérőszámok minden bonyodalmában. A rendszeres szoftverfejlesztőknek azonban csak az Agilis mérőszámokat kell jól ismerniük, amelyeket a szoftverfejlesztő csapatok manapság gyakran használnak a csapat produktivitásának mérésére a szoftverfejlesztési életciklus különböző részein. Soroljuk fel a fő és leggyakrabban használt Agilis mérőszámokat.
1. Sprint Burndown.
A Sprint Burndown jelentések az egyik legfontosabb mérőszám az agilis scrum fejlesztőcsapatok számára. Mivel az agilisban a fejlesztési folyamatot időhöz kötött sprintek szervezik, a Sprint Burndownt a feladatok végrehajtásának nyomon követésére használják a sprint során. Mértékegységként az órákat vagy történetpontokat használják. A cél a következetes előrehaladás elérése és a munka elvégzése a kezdeti előrejelzéseknek megfelelően. A Sprint Burndown segít a csapatoknak a munkatempó mérésében, és szükség esetén módosítani azt.
2. Csapatsebesség.
A sebesség egy másik kulcsfontosságú mutató, amely szintén az órákon vagy a történetpontokon alapul, mint mértékegységen. Azt méri, hogy egy csapat átlagosan mennyi munkát végez a sprint során, és a projekt teljes időtartama alatt becsléshez és tervezéshez használják. A nyomon követési sebesség fontos annak biztosítása érdekében, hogy a csapat egyenletes teljesítményt nyújtson.
3. Történeti pontok.
Egyéni fejlesztőcsapattagok szintjén a történetpontok értékes mérőszámot jelentenek, mivel a programozó által az egyes kiadások során leadott történetek mérete a kódoló termelékenységének mutatója.
4. Ciklusvezérlő diagram.
A teljes időt méri attól a pillanattól, amikor egy feladaton vagy egy másik lemaradási elemen elkezdődött a munka a befejezéséig. Lehetővé teszi a ciklusidők nyomon követését és szabályozását, így kiszámíthatóbb eredményeket biztosít.
5. Átbocsátóképesség és nyújtott érték.
A projektmenedzserek elemzik a fejlesztőkhöz rendelt feladatokat, és értéket rendelnek hozzájuk. Ezt a mérőszámot azután a csapat teljesítményének vagy más szóval az elvégzett hozzáadott értéket képviselő munka mennyiségének mérésére használják.
6. Code Churn.
A kódlemorzsolódás egy másik mérőszám, amelyet érdemes megemlíteni, mivel mind a csapat egészének termelékenységének mérésére, mind az egyes programozók teljesítményének nyomon követésére használják. A kódlemorzsolódás azt méri, hogy a fejlesztő milyen gyakran távolítja el vagy módosítja a korábban hozzáadott kódsorokat, és a korábban megírt kód hány százalékát módosítják vagy dobják ki.
Szakértői vélemények
Végül, hogy némi perspektívát adjunk, néhány idézet az üggyel kapcsolatban tapasztalt szoftverfejlesztési szakemberektől. „Remélem, nem akarja „összehasonlítani” a mérőszámait valamilyen standarddal, vagy akár egy másik cég másik csapatának teljesítményével. Mindenütt, ahol dolgoztam, egyedi eltérések mutatkoztak a történetpontok, a sebesség, az órai becslések, a feladatok stb. meghatározásában, ami valóban szinte lehetetlenné tenné az egyik vállalat csapatának teljesítményének összehasonlítását egy másik csapat teljesítményével. cég” – jegyezte meg Cliff Gilley, korábbi műszaki termékmenedzser és az Agile Coach. „Kicsit furcsállom a mérőszámokat, amikor a csapat teljesítményének irányításáról van szó. Ha egyszer csak egy vagy két változóra figyelsz, nagyon könnyen beleeshetsz (szándékosan vagy más módon) a mérőszám kijátszásába, és becsaphatod magad, hogy javítasz – amikor csak a mutató javítását csinálod. Például a sebességen alapuló mérőszámok „javulhatnak”, ha a csapat kisebb történetekre költözik (kevesebb munka történetenként – így több történet készül el –, így a sebesség nő). Ez jó dolog lehet, ha a történetek hasznos felhasználói történetek, amelyek kisebb növekedést jelentenek az üzleti értékben. Ez rossz dolog lehet, ha a történetek kisebb és „technikai” feladatokká válnak, amelyek önmagukban nem adnak valódi értéket” – mondta Adrian Howard, egy másik iparági szakember.. „Ha pull-alapú rendszerben dolgozom, nagyra értékelem az áteresztőképességet és a ciklusidőt. Az első általános információkat ad csapatunk kapacitásáról, és idővel nagyon erős előrejelző mérőszámmá válhat. A második hasznos csővezetékeink hatékonyságának általános mérőeszközeként. Ha a ciklusidő magas, ideje elkezdeni a folyamatot nézegetni, mert van egy korlát, amelyet valószínűleg az könnyítés/kihasználás felé tehetünk. De a mutatók csak eszközök. Ne vesszen el bennük, és semmiképpen ne kezdjen el tervezni egy adott mérőszám felé. Gondold át, mit alkotsz csapatként, és hogyan dolgozol természetesen, majd építsd fel a rendszert az emberek köré. A mutatók segítségével láthatja, hogyan támogatja a rendszer mindenki munkáját. Vagy nem” – foglalta össze Dave Cerra, egy videojáték-fejlesztő producer .
