kokemuksemme yleisimpien Agile Metrics

kokemuksemme yleisimpien Agile Metrics

Agile Metricsin käyttämisestä tiimin tuottavuuden mittaamiseen on keskeinen osa Agilen filosofiaa. Tiimipäälliköiden ja kaikkien jäsenten tulisi nähdä työnsä seuraukset ja käyttää näitä tietoja työnkulun parantamiseen ja tehokkuuden lisäämiseen.

myös loppukäyttäjät ja asiakkaat voivat hyötyä ketteristä projektimittareista, jotka keskittyvät tuotteen tuloksen arviointiin. Mittareiden avulla scrum-mestarit, kehittäjät, suunnittelijat ja testaajat voivat mitata sovelluksen suorituskykyä ja seurata, jos nykyiset ja aiemmat tehtävät tekevät tuotteesta paremman.

tässä artikkelissa tarkastelemme ketteriä mittareita, joilla on merkitystä, ja jaamme kokemuksemme tämän ketterän mittariston soveltamisesta tosielämän projektiin. On käynyt ilmi, että johtaaksesi tiimiä menestyksekkäästi ja tuottaaksesi tuloksia, sinun ei tarvitse vain tietää, mitä mittareita sovelletaan, vaan miten se tehdään — jaamme, miten selvitimme sen.

Types of common Agile metrics

Agile metrics-luokitus ei ole kiveen hakattu-se muuttuu ja muuttuu jatkuvasti. Silti olemme vuosien varrella nähneet kolmen päätyypin ketterien mittareiden nousun erilaisissa ketterissä kehyksissä.

1. Kanban metrics – nämä mittarit perustuvat sijoitetun ajan (sykliajat) ja tuotettujen tulosten (läpimeno) mittaamiseen sekä niiden suhteeseen.
2. Scrum metrics — mittarit, jotka keskittyvät työnkulun suunnitteluun ja ymmärtämiseen sekä sen osoittamiseen, kuinka paljon työtä tiettynä ajanjaksona tehtiin;
3. Lean metrics — tuotannon tehokkuuden ja tuotteiden laadun jatkuva mittaaminen teknisellä arvioinnilla testaamalla ominaisuuksia, tarkistamalla mahdolliset virheet ja ennakoimalla kielteisiä vaikutuksia.

käytämme kaikkia kolmea mittaustyyppiä arvioidaksemme ohjelmistokehitysprosessin pääkohtia ja tuloksia: tuotteen laatu, tiimin tuottavuus ja terveys.

Agile quality metrics

ennen kuin aloitat joukkueen nopeuden ja tehokkuuden mittaamisen, sinun on tiedettävä, oletko yleisesti ottaen menossa oikeaan suuntaan. Mitä hyötyä on kaikkien kehitystehtävien nopeassa toimittamisessa, jos itse tehtävät muodostuvat väärällä tavalla? Jokaisen ohjelmistokehitystiimin ja johtajan prioriteettina on varmistaa, että kaikki toiminnot liittyvät tuotteen parantamiseen — tämä tapahtuu mittaamalla sen laatua ja havaitsemalla negatiiviset taipumukset.

karanneet viat

jokaisessa ketterässä projektissa on pyrähdyksiä tai työjaksoja, joiden päätteeksi tietty tehtävä suoritetaan. Kun työ oli valmis, joukkueen manageri joutuu arvioimaan turned – it-tulosten laatua. Kaikki muutokset, muokkaukset ja kiinnittämättömät virheet ovat karanneita vikoja — kysymyksiä, jotka kehittäjät olisivat voineet korjata, mutta eivät.

kun olet tehnyt raportin karanneista vioista ja kerännyt konkreettisia tilastoja, sinun on keskusteltava tuloksista tiimisi kanssa. Varmista, että jokainen joukkueen jäsen tietää, millaisia virheitä joukkue yleensä jää. Jos sinulla on yksittäisiä ehdotuksia, keskustele niistä tiimin jäsenten kanssa kahdenkeskisesti.

epäonnistuneet käyttöönotot

jos tuote otettiin käyttöön, mutta sitä ei julkaistu tai se ei onnistunut houkuttelemaan käyttäjiä, tämä kirjataan epäonnistuneeksi käyttöönotoksi. Joskus epäonnistunut käyttöönotto tapahtuu jonkin sidosryhmän päätöksille tai liiketoimintamalli osoittautuu epäluotettavaksi. Mikä tahansa oli ongelman syy, sinun täytyy tallentaa kaikki epäonnistuneet käyttöönotot sekä syyt niiden epäonnistumiseen.

ennen uuden käyttöönoton julkaisemista tiimi voi aina katsoa aiemmin epäonnistuneiden käyttöönottojen listaa ja tutkia, voiko tämä käydä läpi saman prosessin. Aiempien versioiden epäonnistumisen syiden analysointi mahdollistaa tulevien ongelmien välttämisen.

Release Net Promoter Score (NPS)

Net Promoter Score on mittari, jolla arvioidaan käyttäjien reaktioita määrällisesti (numerot, tilastot, keskimääräiset arviot) ja laadullisesti (arvostelut, suora palaute, viestit, sähköpostit, puhelut). Kun tiimi on kerännyt ja analysoinut palautteen, jokainen tiimin jäsen ehdottaa pisteytystä, joka arvioi, kuinka paljon käyttäjä todennäköisesti suosittelee tuotetta (tyypillisesti pisteet asetetaan rajoille 1-10).

Agile project management metrics

kun sinulla on täysi historia aiemmista epäonnistumisista ja onnistumisista, voit analysoida kaikkien keskeneräisten projektien suunnan ja antaa relevantteja tehtäviä aiempien kokemusten perusteella. Kun olet määrittänyt kehityksen suunnan-tuotteen ”mitä tehdä”,” sinun täytyy arvioida tiimin tehokkuutta — se on ”miten meillä menee” – tekijä. Agile project Metricsin avulla voit tietää, vastaavatko tiimin jäsenet odotuksiasi, ymmärtävätkö heidän tehtävänsä, hallitsevatko määräajat ja koordinoidaanko ja synkronoidaanko kaikki prosessit.

läpimenoaika

läpimenoaika on metri, jonka avulla joukkueet voivat tarkistaa, kuinka paljon kesti, että tuotekannatusmerkintä saapui sprintin loppuun. Sen avulla voidaan seurata tuotteita missä tahansa kehitysvaiheessa, tehtävä tehtävältä tai arvioida kokonaisaikakustannuksia ideoinnista julkaisuun. Se on pitkän aikavälin mittareita, joita kehittäjät voivat käyttää suunnitellessaan tulevaa työtään ja arvioidessaan hintoja.

muista tallentaa läpimenoaika jokaiselle projektillesi. On parasta pitää sekä isomman kuvan tilastot, jotka kattavat koko projektin, ja on järjestetty sprint metrics — niin voit tutkia jokaisen vaiheen erikseen.

Jaksoaika

jos läpimenoaika on pitkän aikavälin tiimin suoritusmittareita, Jaksoaika keskittyy yksittäisiin tehtäviin. Tällä mittarilla arvioidaan yhden syklin kesto, jossa yksi jakso suoritetaan yhdessä tehtävässä, lasketaan jaksojen määrä projektia kohti ja mitataan saavutettuja tuloksia loppukäyttäjän kannalta, jos tuote on jo beta-testattu tai julkaistu.

jaksoajalla tiimit voivat heti nähdä, viekö yksi tehtävä liikaa aikaa tai jos osa tiimin jäsenistä ei saavuta tehtäviään. Tämä lyhyen aikavälin mittari tekee projektinhallinnasta paljon helpompaa ja auttaa nopeasti paikantamaan ongelmat niiden ilmetessä.

Sprint burndown

tätä mittaria sovelletaan sekä lyhyellä että pitkällä aikavälillä. Managerit voivat luoda sprint burndown Scrum-raportteja reaaliajassa seuratakseen tiiminsä edistymistä nykyisessä projektissa — tätä varten heidän on arvioitava sprinttien kokonaismäärä ja ennustettava todennäköiset aikakustannukset. Sitä voidaan käyttää myös pitkän aikavälin-johtajat voivat analysoida raportteja aiemmista hankkeista, paikantaa vaiheita, jotka epäonnistuivat odotetut aikataulut, ja analysoida syitä viivästyksiä.

mikä tärkeintä, sprint burndown mahdollistaa joukkueiden työnkulun dynamiikan seuraamisen. Joillakin jäsenillä on taipumus ottaa työ alkuvaiheessa hitaammin, kun taas toiset palavat loppuun projektin loppupuolella. Sprint burndowneilla tiiminjohtajat voivat havaita nämä taipumukset, selvittää niiden syyt ja auttaa jäseniä työnjaossa ja ajanhallinnassa.

Epic & Release burndown

tämä mittari muistuttaa Sprint Burndownia — ainoa keskeinen ero on se, että se keskittyy joukkueen tuottavuuteen ennen julkaisua ja sen jälkeen. Johtajat voivat lisätä uusia vaatimuksia ja sisällyttää tehtäviä, jotka perustuvat loppukäyttäjien palautteeseen. Se on parannettu versio sprint burndown, koska se sisältää myös tehtäviä annetaan julkaisun jälkeen projektin.

nopeus

tämä metriikka arvioi valmistuneiden tarinapisteiden määrän tiettynä ajanjaksona. Historiasi perusteella voit ennakoida aikakuluja tuleviin tarinapisteisiin. Joukkueen nopeuden lasku tietyillä sprinteillä voi viitata joukkueen jäsenten väärinkäsityksiin tai aiemmin ennakoitua kovempiin tehtäviin.

Agile metrics

Agile metrics auttaa tiimiä tuntemaan projektinsa paremmin ja seuraamaan monia merkittäviä tuotekehityksen osa-alueita. Ylemmille johtajille on olemassa myös ketteriä mittareita, joiden avulla näkee isomman kuvan kehityksestä ja joukkueen hyvinvoinnista. Kokemuksemme mukaan nämä ylimääräiset mittarit auttavat mittaamaan mitä tahansa osa-aluetta työssäsi. Määrittelimme kuitenkin tärkeimmät ominaisuudet, jotka kertovat eniten lopputuotteesta ja auttavat saavuttamaan täydellisen tuloksen.

kumulatiivinen virtaus

metrijärjestelmän nimi viestii selvästi sen tarkoituksesta-kerätä kaikki projektivirrat ja arvioida ne yhteen kaavioon. Tällaisen kaavion avulla saat suuren mittakaavan näkymän-se voidaan lähettää hankkeen sidosryhmille, joilla ei ole aikaa analysoida yksityiskohtaisempia ketteriä raportteja.

kaavio kuvaa yleensä seuraavia prosesseja:

• tehtävät backlog: kuinka monta tehtävää backlog-tiimin jäsenillä on annetulla aikataululla;
• hyväksytty työ: kuinka monta tehtävää suunniteltujen joukossa on suoritettu — tiimipäällikkö näkee heti erot suunnitellun ja viimeistellyn toiminnan välillä;
• Puskuritehtävät: kaikki hyväksyntää odottava työ on määritelty puskurivyöhykkeellä;
• kesken: sinun on arvioitava nykyinen työmäärä.

Code churn

tämä metriikka näyttää koodipohjan muutosten trendit ennen julkaisua. Churn diagrammit osoittavat, kuinka paljon koodia lisättiin, poistettiin tai muutettiin kerran kerrallaan. Alussa sprints, on monia piikkejä ja kaatuu kuvaajan, koska koodi on vielä epävakaa, mutta projektin edetessä, koodi Kirnu kuvaaja pitäisi tulla vakaa, ilman rajuja ylä-ja alamäkiä.

ennen julkaisua Kirnun pitäisi saada laskukoodi — lisäämällä tai muokkaamalla koodi ennen varsinaista julkaisua tarkoittaa, ettei sitä testata riittävästi. Kaiken kaikkiaan, kun on epäsäännöllisyys Ketterä kaavioita, tutkia syitä.

Kontrollikaavio

kontrollikaavio on kaavio, jossa ryhmä näkee tiedot jaksojensa kestosta. Ihanteellinen tulos olisi linja kaavion tasaisesti menossa alas aikaa — se merkitsisi kasvua joukkueen nopeus-vähemmän aikaa tarvitaan per yksi sykli. Toinen tärkeä näkökohta on johdonmukaisuus-sykli kertaa täytyy pysyä jopa riippumatta tehtävän tyyppi – se tarkoittaa, että sinulla on oikea työnjako.

Health metrics

Software development tiimien on keskityttävä pitkän aikavälin prioriteetteihin, kuten pitää viestintä jäsenten välillä sujuvana ja tarkistaa, ovatko kaikki tyytyväisiä. Agile on joustava menetelmä, eli se voi mukautua eri jäsenten etuihin heti, kun esimiehet tietävät, mihin kannattaa kiinnittää huomiota. Näin selvitämme, ovatko kaikki tiimimme jäsenet tyytyväisiä työnkulkuun.

Onnellisuus

jos tiimissä on luotettuja, epävirallisia suhteita, on helpompi aloittaa avoimella dialogilla jokaisen jäsenen kanssa. Pyydä kaikkia arvioimaan kokemuksensa yrityksestä 1: stä 5: een. Voit tehdä auttavia kysymyksiä: Mitkä ovat heidän työnsä parhaat ja huonoimmat puolet, mitä voisi parantaa ja mikä voisi lisätä onnellisuutta? Jos tiimillä ei ole ystävällismielisiä viestintätapoja, anonyymien kyselyjen käyttäminen voi johtaa objektiivisempiin tuloksiin.

joukkuemoraali

joukkuemoraali ja onnellisuus eivät ole samoja asioita. Onnellisuus liittyy enemmän mukavuuteen, kun taas joukkueen moraali on sidottu tuottavuuteen, itsetuntoon, omien ammatillisten ominaisuuksien arviointiin. Jälleen, voit pyytää työntekijöitä arvioimaan heidän moraali 1-5 ja kysyä seuraavat kysymykset;

• Auttoiko yrityksessä työskentely taitojesi parantamisessa?
• kuinka paljon sinun täyttä potentiaaliasi tutkitaan nykyisellä työmäärällä?
• nautitko työstäsi?
• Näetkö työsi selvät tulokset?
• Oletko innostunut uusista projekteista?

tässä pyritään ymmärtämään, että joukkueen kehitysvirta menee oikeaan suuntaan. Joskus ohjelmistokehitystiimin johtaja ottaa tuottoisia, mutta tylsiä tehtäviä jäsenten kiinnostuksen sivuuttaen. Kyselyn avulla näet, innostuvatko ja haastavatko työntekijät työnsä.

tiimiläisten vaihtuvuus

jos tiimipäälliköt usein vaihtavat tiimiläisiä, työympäristö on todennäköisesti epäterveellinen. Tietty vaihtuvuus ajan myötä on terveellistä-itse asiassa et halua lisätä ihmisiä vuosiin, koska se tarkoittaisi pysähtyneisyyttä. Kannattaa kuitenkin varoa äkillisiä piikkejä aktiivisuudessa-kuukausia, jolloin useampi jätti joukkueen tai moni liittyi mukaan. Jos mukaan tulee yhtäkkisesti paljon uusia osallistujia, on kiinnitettävä huomiota perehdytysprosessiin ennen kuin siirrytään suoraan projektiin liittyvään työhön.

loppukäyttäjien hyödyn mittaaminen

ketterien tiimien tulee tietää, kuinka hyvin tuote sopii loppukäyttäjän ja yrittäjän tarpeisiin. Tämä tehdään kattavalla koodianalyysillä, joka määrittää koodin laadun ja sen käytettävyyden loppukäyttäjälle sekä mahdolliset huoltokomplikaatiot.

Staattinen koodianalyysi

se on yksinkertainen koodianalyysin Tyyppi, kun ohjelmisto ei ole aktiivinen. Pelkästään seuraamalla koodia automaattisesti avoimen lähdekoodin työkaluilla voit tunnistaa tietoturvaongelmia, havaita teknisen velan ja vikoja sekä lähettää ongelmallisia koodinpätkiä roskankerääjälle.

dynaaminen koodianalyysi

dynaaminen koodianalyysi edellyttää, että tiimisi suorittaa ohjelmiston loppukäyttäjien saamien kokemusten arvioimiseksi. Kannustamme kehittäjiämme ja testaajiamme asettumaan aina käyttäjien saappaisiin ja tutkimaan yleisimpiä skenaarioita. He voivat esimerkiksi esitellä ratkaisun kollegoilleen ja perheenjäsenilleen pyytäen palautetta — ellei se ole sopimuksessa kiellettyä. Mikä tärkeintä, meillä on QA-ammattilaisten tiimi, joka on täysin vastuussa dynaamisesta koodianalyysistä – vaikka uskomme, että mitä useampi ihminen osallistuu mittareiden testaamiseen Agilessa, sitä parempi on lopputuotteen laatu.

kuinka soveltaa parhaita ketteriä mittareita

kaikista saatavilla olevista ketteristä mittareista on valittava ne, jotka ovat merkityksellisiä tiimisi ja projektisi kannalta pitkällä aikavälillä. Pitää kirjaa näistä keskeisistä ominaisuuksista pitäisi olla tapana, vaikka se ei pitäisi häiritä sinua kiireellisempää työtä. Näin yhdistimme ketterät mittarit saumattomasti työnkulkuumme.

keskity suoritukseen, budjettiin ja laatuun

sinun on varmistettava, että kun olet valinnut kaikki mittarit, sinulla on selkeä kuva työsi laadusta, kuormituksesta, ajankuluista ja budjetista. Ensinnäkin perustamme lyhyen aikavälin mittareita, jotka liittyvät aktiivisiin projekteihimme: syklin aika ja nopeus ketterään suorituskyvyn arviointiin, koodianalyysi koodin laadun arviointiin ja kumulatiivinen virtaus kaikkien kehitysprosessien ja niiden kustannusten seuraamiseen.

ensimmäisen sprintin aikana tehdään seuraavat:

• määrittele kuinka monta sprinttiä ja sykliä projektissa tulee olemaan;
• arvioi koko projektin ajankulut ottaen huomioon asiakkaan tarpeet;
• arvioimalla kilpailukykyisiä ratkaisuja lopputuotteen monimutkaisuuden ymmärtämiseksi;
• kerää tiimimme jäseniltä palautetta heidän odotuksistaan projektin jännittävimmistä, haastavimmista ja vaikeimmista puolista.

tällä tavalla voimme tietää, kuinka paljon aikaa käytämme projektin loppuun saattamiseen, laatustandardien asettamiseen samankaltaisten ratkaisujen pohjalta ja onko tiimimme motivoitunut työskentelemään tehtävien parissa vai ei (sillä on valtava vaikutus tuottavuuteen).

ensimmäisen sprintin jälkeen

täällä keskitytään saamaan palautetta asiakkaalta ja kaikilta tiimin jäseniltä. Ensimmäisen sprintin jälkeen haluamme tietää, että kaikki työnkulun osapuolet ymmärtävät prosessin ja tuntevat olonsa mukavaksi. Korostamme myös koodin laadun arviointia – suunnittelemme jopa koodin analysointia ja teknisen velan arviointia osana jokaista seuraavaa sprinttiämme. Heti kun ensimmäiset rivit koodia kirjoitettiin, sen laadun säilyttäminen on meille tärkeintä.

Velocity comes after

Velocity is one of the most important metrics in our projects, but not the key one. Emme perusta arviointiamme nopeuslukuihin alkuvaiheessa. Strategia nopeasti läpi ensimmäisten vaiheiden on katastrofi odottaa tapahtua-tiimi voi ohittaa suunnittelu, tai unohtaa kysyä asiakkaalta useita tärkeitä kysymyksiä. Emme kiirehdi tuotteen alkuvaiheita, vaan annamme asiakkaiden ja tiimin jäsenten löytää tahtinsa.

joukkueemme vauhdin nostamisesta tulee yksi prioriteeteistamme, kun olemme suorittamispisteessä. Heti kun kaikki ominaisuudet ja suunnittelu on säädetty, pyrimme minimoimaan ajankulut ja suorittaa kaikki tehtävät mahdollisimman nopeasti.

yksittäiset mittarit

jokaisen käytetyn mittarin tulisi olla saatavilla sekä koko tiimille että yksittäisille jäsenille. Kehittäjien, testaajien, suunnittelijoiden pitäisi pystyä näkemään työnsä vauhti ja tulokset, ei vain tiimin kokonaisuutena. Sen toteuttamiseksi käytämme tuottavuustyökaluja ja aikajäljittimiä, kuten Jira ja Hubstaff. Kaikki yleiset raportit synkronoidaan yksittäisten – jäsenet voivat nähdä, mikä prosenttiosuus kokonaistuottavasta ajasta heidän tuntia tehdä.

Frequently asked questions

mikä on KPI ketterässä?

ketterän keskeiset tulosindikaattorit ovat mitattavissa olevia arvoja, jotka osoittavat tiimin tehokkuuden liiketoiminnan tavoitteiden saavuttamisessa. Korkean tason KPI: t keskittyvät pitkän aikavälin tuloksiin, jotka riippuvat monista tekijöistä-kuinka monta käyttäjää lopputuote houkutteli, muuntokurssit, palautteen laatu. Matalan tason KPI: t ovat lyhyen aikavälin arvoja, joihin eivät vaikuta monet toisiinsa liittyvät tekijät — projektiin käytetty aika (lasketaan yleensä tunteina), projektin budjetti (investointi tehtävää kohti) jne.

Agile on jatkuvaan parantamiseen perustuva kehitysmenetelmä — ohjelmistokehitys analysoi dataa ja sopeutuu siihen. Tiimi analysoi ketterän KPIs: n suorituskykyä ja työn laatua ja toteuttaa muutokset heti seuraavassa sprintissä.

Mitä ovat Sprinttimittarit?

Sprinttimittarit ovat mittareita, jotka arvioivat ohjelmistokehitystiimin suoritteita ja tarkistavat, kuinka paljon arvoa loppuasiakkaalle on toimitettu kunkin sprintin loppuun mennessä . Tämä arvo voidaan mitata uudella ominaisuudella, suunnitteluparannuksilla tai vian poistolla.

sprint Metricsin seuraava tavoite on mitata tiimin tehokkuutta liiketoiminnan kannalta — kuinka nopeasti ratkaisu toimitettiin markkinoille, mikä on asiakkaan palaute ja konversiotasot. Lopuksi mittareiden on osoitettava kehittäjien tyytyväisyys projektiinsa ja siihen suuntaan, mihin tiimi on ylipäätään menossa.

miksi mittarit ovat tärkeitä ketterissä projekteissa?

ketterän menetelmän koko pointti on, että kehittäjät voivat aina tehdä korjauksia prosessissa jokaisen pyrähdyksen jälkeen. Konkreettisten tietojen, tilastojen ja kaavioiden avulla kehittäjät voivat ymmärtää, mitä muutoksia tehdään seuraavaa sprinttiä varten, ja arvioida lopputuotteen laatua — muuten olisi helppo jäädä kiinni teknisiin ja organisatorisiin yksityiskohtiin.

mikä on pikajuoksu ketterässä?

pikajuoksu on selkeästi määritelty ajanjakso, jonka alku-ja päättymispäivä on, kun joukkue on asetettu suorittamaan tietty määrä tehtäviä. Sprintit ovat Scrumin, Agilen ja DevOpsin perusta — joukkueet jakavat työmääränsä pienempiin hallittaviin osiin ja seuraavat jokaisen sprintin tuloksia. Jokainen näistä ajanjaksoista käsitellään miniprojektina, jossa tehdään etukäteen suunnittelu, riskinarviointi, vastuutehtävät ja Sprintin jälkeinen analyysi.

jokainen projekti koostuu sprinttisarjasta. Koska jokainen sprintti arvioidaan, ongelmat on helppo havaita jo varhaisessa vaiheessa ja poistaa seuraavalla Sprintillä — joten työnkulku on jatkuvasti optimoitu.

mitkä ovat mittarit ohjelmistokehityksessä?

ohjelmistokehityksen mittarit ovat kvantitatiivisia arvoja, joiden avulla voidaan mitata ohjelmistokehitysprojektin laatua, suorituskykyä ja tiimin terveyttä. Ne auttavat parantamaan kehitysprosessia projektin edetessä ja niitä voidaan käyttää tiimin tulevaan työhön organisaation ja suunnittelun parantamiseksi.

ohjelmistokehityksen mittareita on kuusi päätyyppiä:

• formaali koodi metrics – nämä ovat objektiivisia laadullisia arvoja, jotka laskevat, kuinka paljon työtä tehtiin määrittämällä koodin rivien (LOC) lukumäärä, Opetuspolun pituus ja muut.
• kehittäjien tehokkuusmittarit — tiimi voi laskea tehtäväkoodin, aktiivipäivät ja tehtävään käytetyn ajan.
• Agile process metrics — kun projekti on jaettu sprintteihin, tiimi voi mitata projektin pienempien osien tehokkuutta – läpimenoaika (kuinka paljon aikaa käytettiin tiettyyn kehitysvaiheeseen, joka voi sisältää useita sprinttejä), sykliaika (yksi sprintti kuuluu yleensä yhden syklin alle) ja nopeus (kuinka monta tehtävää tehtiin tietyllä aikavälillä).
• Operational metrics — nämä mittarit tarkistavat ohjelmiston käyntiominaisuudet ja määrittävät, kuinka tehokkaasti yrityksen henkilökunta ylläpitää työkalua ilman kolmannen osapuolen apua. Mean Time Between Failures and Mean Time to Recover (Mttr) tarkista, miten ohjelmisto toimii luonnollisissa olosuhteissa ja miten talon tiimi on varustettu kuorman käsittelyssä.
• Testimittarit-nämä mittarit arvioivat koodin kattavuutta-kuinka paljon koodia testattiin, kuinka paljon vikoja oli ja kuinka suuri osuus teknisestä velasta oli.
• asiakastyytyväisyys — tiimi saa tietoa loppukäyttäjien reaktioista tuotteeseen mittaamalla Net Promoter Scoren, Customer Satisfaction Scoren ja Customer Effort Scoren. Nämä mittarit arvioivat vastaavasti, suosittelevatko käyttäjät tuotetta ja ovatko he tyytyväisiä tulokseen.

ketterät mittarit ovat osa ohjelmistoverkkoja, ja ne voivat sisältää myös muita kategorioita, kuten oppaastamme huomaa.

Mitä ovat SDLC-mittarit?

SDLC on ohjelmistokehityksen elinkaari – joukko vaiheita, jotka tyypillinen teknologia käy läpi sen suunnittelun, toteuttamisen ja viimeistelyn aikana. Keskimääräinen SDLC koostuu seuraavista vaiheista:

• nykyisten järjestelmien arviointi ja niiden ominaisuuksien, etujen ja ongelmien määrittely;
• uuden projektin toiminnallisuuden, suunnittelun, kohdeyleisön jne.vaatimusten määrittely.;
• järjestelmän suunnittelu ja tyypillisen käyttäjäpolun hahmottaminen;
• ohjelmiston kehittäminen, mikä tarkoittaa koodin kirjoittamista, laitteiston valmistelua ja ominaisuuksien luomista;
• ohjelmistojen suorituskyvyn, toimivuuden, tietoturvan, käyttöliittymän jne. testaus;
• ohjelmiston käyttöönotto sen luonnollisessa ympäristössä, jossa tekniikka toimii pitkään;
• Järjestelmän ylläpito päivittämällä koodia, korvaamalla tai muokkaamalla tiettyjä fragmentteja ja poistamalla bugeja.

jokainen SLDC-vaihe voidaan mitata seuraavien ominaisuuksien perusteella.

• vaatimukset: työryhmän on kerättävä kaikki projektiin liittyvät vaatimukset ja arvioitava niiden toteutuminen ajallisesti ja rahallisesti;
• ohjelmiston laatu: kaikkia ketteriä laatumittareita voidaan käyttää SDLC: n kehitysvaiheessa;
• testitapaukset: tiimin on laskettava suoritettujen testitoimintojen määrä, sen nopeus ja lopullinen koodikattavuus;
• viat: työn tehokkuuden mittaamiseksi kehittäjien ja testaajien on oltava tietoisia kehityksen aikana ilmenevien ongelmien tarkasta määrästä;
• tehtävät: käytetyn ajan mittaaminen ja rahaa ansaittu per tehtävä mahdollistaa arvioida, jos kaikki tiimin jäsenet ovat tuottavia tai ei.

kaikkia oppaassamme kuvattuja mittareita voidaan käyttää ohjelmistokehityksen elinkaaren eri vaiheissa. Projekti on suurin tarve valvoa lähempänä julkaisua, koska ongelmat voivat kasaantua, ja se on helppo missata kriittinen vika tuotteessa.

mikä on läpimeno ketterässä mittarissa?

se on metri, joka laskee valmistuneiden tarinoiden määrän sprinttiä kohti. Scrumissa vastaavaa metristä kutsutaan Sprinttinopeudeksi.

Conclusion

Agile metrics loi vankan pohjan tehdä tietoon perustuvia päätöksiä koko ohjelmistokehitysprojektin ajan. Kehittäjät voivat käyttää näitä oivalluksia lisätäkseen tehokkuuttaan seuraavissa sprinteissä ja parantaakseen jatkuvasti tuotteensa laatua. Kuitenkin, on syytä huomata, että kehitys metrics ei pitäisi tulla ehdoton prioriteetti ohjelmistokehitysprojektissa. Kehittäjien tulisi luottaa ennen kaikkea projektin tarpeisiin ja yleisön mieltymyksiin.

Jelvixillä käytetään henkilökohtaista lähestymistapaa metriikan soveltamiseen projektiin. Ensin keskustelemme asiakkaan kanssa projektin MVP: stä, tutkimme kohdeyleisöä, analysoimme kilpailukykyisiä ratkaisuja ja vasta sitten valitsimme projektiin parhaiten sopivat mittarit. Emme pyri soveltamaan jokaista KPI: tä — sen sijaan valitsemme ne, jotka vastaavat projektin tarpeita eniten.