Virheiden raportointi: parhaat bugimetriikat
Virheiden raportointi: parhaat bugimetriikat
Mittarit, raportointi ja tiedon käyttäminen tuotekehityksen hallinnassa on todella tärkeää!
Aiemmin olet kenties jo lukenut tämän tai tämän blogin liittyen raportointiin ja metriikoihin. Koska mittarit, raportointi ja yleensäkin tiedon käyttäminen tuotekehityksen hallinnassa on meistä Contribytellä todella tärkeää, aiomme tulevissa blogeissa käsitellä raportointia ja mittareita vielä tarkemmalla tasolla lisää. Tässä blogissa aiheena on virheiden raportointi ja mittarit, eli mitkä ovat parhaat bugimetriikat. Jatkossa avaamme muissa blogeissa myös testauksen metriikoita, backlogin ja johdon metriikoita ja muita tuotekehitykselle tärkeitä mittareita. Käy myös tutustumassa tähän youtube videoon (raportointiin liittyvä työkaluosio alkaa kohdasta 1:40:44) jos raportointi ja mittarit kiinnostavat.
Voiko autoa ajaa sokkona – ilman mittaristoa?
Miten ajat autoa ilman mittaristoa? Tämä on käynyt mielessä nyt muutaman kerran, kun olen totutellut ajelemaan Tesla model 3:lla. Auto ei oikein sovi ihan Pihtiputaan mummolle, nimittäin se on pitänyt nyt buutata ainakin pari kertaa viikossa, kun auton ainoa näyttö (jossa näkyy kaikki mittarit ja muu informaatio) on ollut jääräpäisesti pimeänä, kun pitäisi lähteä ajelemaan. Joka kerran, kun näin käy, autolla kyllä pystyy ajamaan eli se kyllä liikkuu, mutta ei näe sitten ainoatakaan mittaritietoa – ei ajonopeutta, akun varaustilannetta, ei mitään.
Teetkö päätöksiä ilman mittaristoa – siinä tulee hiki otsalle!
Tässä tilanteessa käy aina mielessä, että kyllähän sitä voisi ajella, mutta kun ei uskalla, ilman mittareita. Hauska lisäbugi tilanteessa sinänsä on se, että kun Teslassa mittaristonäyttö crashaa ja pimenee, niin tuuletus menee samalla täysille – ihan kuin tietokoneen henki tajuaisi, että ilman mitään mittaritietoa ajaminen on aika hiostuttavaa puuhaa! No, vitsit sikseen: hyvää tilanteessa on se, että Teslan ohjelmisto päivittyy koko ajan over the air, eli korjauksia on tulossa. Toivottavasti vaan Teslan koodarit seuraavat oikeita mittaristoja valitessaan asioita, joita korjataan. Käydäänpä seuraavaksi läpi joitain yleisiä juurikin virheiden raportointiin liittyviä mittareita.
Virheiden raportointi: Bugeihin liittyvät mittarit
Virheistä voi saada todella paljon erilaisia mittareita. Mittareita on niin paljon, että ”kaikki mittarit” on aivan epärealistinen vaihtoehto. On aivan pakko miettiä, mikä tieto on juuri teille tärkeää, ja sitten etsiä siihen sopivat mittarit. Olen kerännyt tähän listaan yleisimmin virheiden raportoinnissa käytettyjä mittareita.
| Mittari | Trendidata | Selvennys | Käyttötarkoitus ja vinkkejä |
| Virheiden määrä ja vakavuusaste | Suositeltava |
Yksinkertainen mittari, mikä kertoo avoimien virheiden määrän kokonaisuudessaan, ja myös jakauman. Esimerkiksi, auki on 35 bugia, joista
Trenditiedosta näkee, miten tilanne on kehittynyt ajan myötä. Onko meillä tänään vähemmän bugeja auki kuin viime viikolla, kuukausi sitten tai edellisen releasen alla. |
Tämä mittari kertoo nopealla silmäyksellä senhetkisen kokonaistilanteen. Yleensä on eri bugeille sovittu tiimeissä myös erilaiset ”service levelit” eli reagointi. Esimerkiksi, jos fatal ongelma tulee, niin tiimin ”hanskat tippuu” mitä sitten kulloinkin oltiin tekemässä, ja fatal ongelman kimppuun käydään porukalla. Criticaleissa voi olla sovittuna vastaavasti, että ne otetaan ”jonon ohi” aina työn alle, kun sopiva hetki löytyy esimerkiksi jotain muuta saadaan valmiiksi. |
| Inflow vs outflow | Suositeltava | Uusien bugien määrä vs suljettujen bugien määrä |
Tämä tärkeä mittari kertoo tiimille miten hyvin pystytään juuri nyt reagoimaan sisääntulevien bugien määrään. Jos inflow on paljon isompi kuin outflow tilanne on muuttumassa pian kriittiseksi, ja tiimin on syytä panostaa virheiden korjaamiseen ja tilanneanalyysiin nykyistä enemmän. Jos inflow – outflow on hyvin tasapainossa, tilanne on mahdollisesti ok, mutta tilannekuva vaatii myös historiadatan ymmärtämistä ja testauksen tilanteen ymmärtämistä. Inflow voi olla pieni myös tilanteessa jossa järjestelmää ei voi tehokkaasti testata. Tämä mittari onkin syytä yleensä yhdistää erilaisiin testaus coverage mittareihin |
| Virheiden määrä ja vaihe missä virhe löydettiin | Valinnainen |
Tieto siitä, missä vaiheessa kehitystä virhe löytyi. Vaiheet voivat olla esimerkiksi seuraavat
|
Tämä mittari kertoo miten hyvin tiimissä ollaan onnistuttu löytämään ongelmat mahdollisimman aikaisessa vaiheessa. Mitä aikaisemmin ongelmat löydetään, sitä tehokkaampaa niiden korjaaminen on. Ja kalleinta tietenkin on korjata ongelmia, jotka ovat menneet jo asiakkaalle asti. |
| Valinnainen | Joskus tätä mittaria voi muokata myös tiimin sisäiseen käyttöön, eli kuka ongelman oli löytänyt. | Ongelman löytäjätieto kertoo tiimille, kuka on hyvä löytämään ongelmia. Se voi olla hyvä ymmärtää esimerkiksi jos tarvitaan nopeasti tehokasta testausta. | |
| Valinnainen | Vielä yksi vaihtoehto on kirjata feature / component mistä virhe löytyi | Feature / component alue auttaa tiimiä selvittämään, missä bugeja on paljon. Jos joku feature esimerkiksi on bugirikas, kannattaa kaivautua syihin, miksi. Oliko määrittelyssä puutteita? Entä tavassa, missä kehitys ja testaus tehtiin? | |
| Virheiden keskimääräinen elinikä | Valinnainen | Tämä mittari kannattaa laittaa kaavioon, josta näkee historian, eli kuinka avoinna olevien virheiden elinikä on kehittynyt. | Mittari kertoo, jos virhelistalle on alkanut kertyä ”metusalem” virheitä, jotka eivät pääse korjaukseen koskaan. Tällaiset ”bugilistan pohjasakat” eivät ole oikein hyväksi, joko ne kannattaisi korjata pois tai sitten vaan päättää ettei korjata ollenkaan ja dokumentoida tilanne. |
| Korjauksen cycle time | Valinnainen | Kuinka kauan virheen korjaukseen meni aloituksesta sulkemiseen |
Tämä metriikka kertoo sekä tiimin tehokkuudesta että bugien kompleksisuudesta. Se auttaa tiimiä ymmärtämään esimerkiksi sitä, miten kauan auki olevien bugien kanssa menisi aikaa. Vähän samanmallinen mittari on myös Mean time to repair (MTTR) joka kertoo miten nopeasti ongelmat tuotannossa pystytään korjaamaan |
| Virheiden lukumäärä per uusi kehitetty feature / backlog item | Suositeltava | Keskimääräinen lukema virheet per backlog item / EPIC | Tämä metriikka auttaa tiimiä näkemään, miten hyvin pystytään tekemään ”bugitonta” softaa. Tämä pitää tietenkin suhteuttaa siihen, miten iso kokonaisuus on kyseessä. Pitkällä aikavälillä kannattaa pyrkiä tietenkin siihen, että työtä ja toimitatapaa määritellään niin, että virheitä syntyisi vähemmän. |
| Asiakastukipyyntöjen määrä | Suositeltava |
tukipyyntöjä voi verrata joko
|
Tukipyyntöjen määrä aikaan verrattuna kertoo organisaatiolle, jos ollaan vaikka releasoitu epäkypsää softaa asiakkaalle, tai vaikkapa käytettävyydessä tai dokumentaatiossa on puutteita. Jos taas tukipyynnöt keskittyvät jatkuvasti tiettyyn toimintoon tai komponenttiin, voi tiimi priorisoida siihen liittyviä parannuksia backlogilla ylemmäs |
| Mean time between failures (MTBF) | Suositeltava | Kuinka kauan järjestelmä tai toiminto toimii hyvin kunnes tulee ongelma | Tämä mittari kertoo järjestelmän tai toiminnon luotettavuudesta. Jos vaikkapa aikaisemmalla releasella järjestelmä oli toiminut vuosikausia moitteettomasti, mutta upgraden jälkeen toimii vain kuukauden, kunnes kaatuu, on aika selvää, että asiaa pitää nopeasti tutkia ja selvittää syy. |
| App crash rate | Suositeltava | Miten usein sovellus kaatuu | Selkeä mittari, kaatumiset on aina vakava asia. Usein tähän pitää yhdistää logit tai stack-tieto mitä kaatumisen aikana oli tapahtumassa, että kehittäjät voivat alkaa selvittää mahdollista syytä. |
Lataa tästä muistilista itsellesi!
Monia, monia muitakin mittareita voidaan käyttää virheiden raportointiin. Lisää voi lukea vaikka täältä tai täältä. Kuten aiemmin mainitsin, tärkeää on miettiä se, mitä varten mittari tarvitaan, ja vasta sen jälkeen valita mittari.
Miten mittari konfiguroidaan?
Kaikkiin tuotekehityksen työkaluihin saa dashboardeja eli mittaristonäkymiä.
Kaikkiin tuotekehityksen työkaluihin saa dashboardeja eli mittaristonäkymiä. JIRAssa esimerkiksi jokainen voi itse rakentaa itselleen oman dashboardin ja valita sinne sopivaksi katsomansa mittarit. Tiimi voi myös rakentaa projektille oman dashboardin, joka sisältää kaikille tarpeellisia tietoja. JIRAn bugimittarit rakennetaan tekemällä ensin filtteri ja sitten käyttämällä dashboardin gadgettejä rakentamaan sopivan näköinen näyttö suodattimen datan perusteella. Katso tämä video ja opit lisää, tai pyydä meiltä Contribytellä apua mittareiden konfaamiseen.
Onko teillä mietitty mitkä ovat teille oikeat mittarit?
Mitenkäs teidän tiimissä tai organisaatiossa suhtaudutaan mittareihin? Onko teillä mittaristo näkyvillä, ihmisten omilla dashboardeilla tai kahvihuoneessa isolla näytöllä? Miten olette päätyneet niihin mittareihin, joita ruuduilla seurataan? Entäpä oletteko sopineet kenen vastuulla on reagoida johonkin mittarien näyttämiin lukemiin? Lue lisää mittareiden valinnasta tältä webbisivulta.
Arto Kiiskinen
Senior Consultant
Arto on urallaan nähnyt tuotekehitystä monista eri näkökulmista. Hänellä on kokemusta mm. Product Ownerin, Scrum Masterin ja tuotekehitysjohtajan tehtävistä. Niin isojen kuin pientenkin firmojen toimintatavat ovat tulleet tutuiksi. Arto rakastaa parantaa organisaatioiden oppimista sekä tuoteomistajien osaamista, ja kirjoittaa blogeja eri aiheista. Koska retrospektiivit on yksi Arton suosikkiaiheista, ovat jotkut asiakkaat antaneet hänelle lisänimen "Retromies". Vapaa-aikana Arto yrittää elää terveellisesti, ostaa mahdollisimman paljon autoja, katsoo yhä uudelleen Tähtiportti-sarjan jaksoja ja opiskelee Personal Traineriksi. Arto on kirjoittanut kirjan "OWN IT – 8 Simple Secrets of Product Owner Success". Lisää Arton ajatuksia voi lukea täältä.
