kuten totesin artikkelissa ”Miksi mittareilla ei ole merkitystä ohjelmistokehityksessä (ellet yhdistä niitä liiketoiminnan tavoitteisiin)”, mittareiden valitseminen vaatii huomattavaa harkintaa ja huolellisuutta tukemaan erityisiä kysymyksiä, joihin yrityksen on vastattava. Tässä on kriittinen kohta: mittaukset pitäisi suunnitella vain tapa vastata liiketoiminnan kysymyksiin. Ja nuo kysymykset eivät koskaan ole: ”montako Klocia meillä on nyt?”
tämä artikkeli jatkaa siitä, mihin edellinen jäi, keskustelemalla ensin tarkoista mittareista, joita jokaisen joukkueen tulisi alkaa käyttää, tai ainakin suunnitella käyttävänsä pian keinona parantaa havaittavaa suorituskykyä. Huomaa, että tämän artikkelin otsikko väittää, että on olemassa ”9 mittareita, jotka voivat tehdä eron…”—koska se, mikä on todella tärkeää, mikä todella tekee eron, on se, miten näitä mittareita todella käytetään parantamaan liiketoiminnan arvoa. Se käyttö riippuu sinusta. Sitten tämä artikkeli päättyy selittää, miten voit yhdistää nämä mittarit luoda merkitystä, sekä muotoilla ja testata liiketoiminnan arvo hypoteesi.
Aloita mittaamalla oikeat asiat
tässä on yhdeksän objektiivista mittaria (merkitty luotepisteillä), joita kannattaa seurata jatkuvasti, jotta prosesseihin ja tuotantoympäristöihin saadaan lisää parannuksia. Näiden lukujen parantaminen ei takaa, että asiakastyytyväisyytesi taso nousee harppauksin. Mutta ainakin nämä ovat oikeita asioita mitata. Tämän kirjoituksen myöhemmässä osassa ”kaiken kokoaminen” näet syyn siihen.
Agile process metrics
agile and lean-prosesseissa perusmittarit ovat leadtime, cycle time, team velocity ja open/close rates. Nämä mittarit auttavat suunnittelua ja informoivat päätöksiä prosessin parantamisesta. Vaikka ne eivät mittaa menestystä tai lisäarvoa, eikä niillä ole mitään tekemistä ohjelmiston objektiivisen laadun kanssa, ne kannattaa mitata joka tapauksessa. Selitän miksi alla.
- Leadtime—kuinka kauan kestää siirtyä ideasta toimitettuun ohjelmistoon. Jos haluat olla herkemmin asiakkaitasi, pyri vähentämään läpimenoaikaasi tyypillisesti yksinkertaistamalla päätöksentekoa ja vähentämällä odotusaikaa. Leadtime sisältää syklin ajan.
- Jaksoaika—kuinka kauan kestää tehdä muutos ohjelmistojärjestelmään ja toimittaa tuo muutos tuotantoon. Jatkuvia toimituksia käyttävät tiimit voivat mitata sykliaikoja minuutteina tai jopa sekunteina kuukausien sijaan.
- Team velocity—kuinka monta ”yksikköä” ohjelmistoa joukkue tyypillisesti täydentää iteraatiossa (alias ”sprint”). Tätä numeroa tulisi käyttää vain iteraatioiden suunnitteluun. Joukkuenopeuksien vertailu on hölynpölyä, koska mittari perustuu ei-objektiivisiin arvioihin. Kohtelu nopeus kuin menestys toimenpide on sopimatonta, ja tehdä tietyn nopeuden osaksi tavoite vääristää sen arvo estimointi ja suunnittelu.
- Open/close rates—kuinka monta tuotantoasiaa raportoidaan ja päätetään tietyn ajan kuluessa. Yleisellä trendillä on enemmän merkitystä kuin tietyillä luvuilla.
kun jokin tai kaikki näistä mittareista on odotetun vaihteluvälin ulkopuolella tai suuntautuu hälyttävään suuntaan, älä oleta syytä. Keskustele joukkueen kanssa, Hanki koko tarina, ja anna joukkueen päättää, onko syytä huoleen, ja jos on, miten se korjataan.
numeroista ei voi tietää tai olettaa juurisyitä, mutta nämä mittarit antavat käsityksen siitä, mihin olennaiset prosessisi tarvitsevat huomiota. Korkea avoin korko ja alhainen lähellä korko läpi muutaman iteraatioita, esimerkiksi, voi tarkoittaa, että tuotannon kysymykset ovat tällä hetkellä pienempi prioriteetti kuin uusia ominaisuuksia, tai ehkä, että tiimi on keskittynyt vähentämään teknistä velkaa korjata kokonaisia luokkia kysymyksiä, tai että ainoa henkilö, joka osasi korjata ne lopettaa, tai jotain muuta. Numeroista ei voi tietää tai olettaa juurisyitä.
Tuotantoanalytiikka
- keskimääräinen vikojen välinen aika (MTBF)
- keskimääräinen palautumisaika/korjausaika (MTTR)
molemmat mittaavat ohjelmistojärjestelmäsi suorituskykyä sen nykyisessä tuotantoympäristössä.
- sovelluksen kaatumisnopeus—kuinka monta kertaa sovellus epäonnistuu jaettuna kuinka monta kertaa sitä käytettiin. Tämä metriikka liittyy MTBF: ään ja MTTR: ään.
huomaa, että mikään näistä kolmesta mittarista ei kerro yksittäisistä ominaisuuksista tai käyttäjistä, joita asia koskee. Mutta mitä pienemmät luvut, sen parempi. Modern operations-monitoring software tekee kerätä yksityiskohtaisia mittareita yksittäisten ohjelmien ja liiketoimien melko helppoa, mutta se vie aikaa ja huolellista harkintaa perustaa oikea alueet hälytyksiä ja/tai laukaisee skaalaus ylös tai alas (pilvipohjaisten järjestelmien).
haluaisimme, että ohjelmistomme ei koskaan epäonnistuisi, mutta se on tilastollisesti epätodennäköistä. Kun ohjelmistomme ei epäonnistu, haluaisimme, että se ei koskaan menetä kriittisiä tietoja ja palauttaa heti, mutta se voi olla erittäin vaikea saavuttaa. Jos ohjelmisto on tulonlähde, kuitenkin, vaivaa kannattaa.
MTBF: n ja MTTR: n lisäksi hienorakeisemmat mittaukset perustuvat yksittäisiin transaktioihin, sovelluksiin ja niin edelleen, ja ne kuvaavat toimitetun liiketoiminnan arvoa ja vikojen korjaamisen kustannuksia. Jos tapahtumankäsittelysovelluksesi kaatuu kerran sadasta, mutta toipuu sekunnissa tai kahdessa eikä menetä kriittisiä tietoja, että 1 prosentin kaatumisnopeus voi olla tarpeeksi hyvä. Mutta jos jokainen kaatuminen on sovellus, joka toimii 100,000 liiketoimet päivässä, menettää $100 Myynti, ja maksaa $50 korjata takapäässä, että 1 prosentin kaatumisaste tulee olemaan etusijalla. Sen korjaaminen vaikuttaa ratkaisevaan tulokseen merkittävästi.
Tietoturvamittarit
tietoturva on ohjelmiston laadun osa-alue, joka usein unohdetaan vasta myöhemmin (tai liian myöhään). Rakennusprosessissa voidaan käyttää turvallisuusanalyysityökaluja erikoistuneempien arviointien ja stressitestien lisäksi. Tietoturvavaatimukset ovat usein yksinkertaisia ja yleishajuisia, mutta ohjelmistokehitystiimin on oltava tietoinen niistä ja niistä johdetuista mittareista.
tietoturvakäytäntöjen ja niihin liittyvien mittareiden koko kirjo ei kuulu tämän artikkelin piiriin, mutta kuten ketterien prosessimittareiden ja tuotantomittareiden kohdalla, on olemassa muutamia erityisiä mittareita, jotka voivat merkitä paljon asiakkaidesi kokonaistyytyväisyydelle.
- päätetapahtumat-kuinka monta päätetapahtumaa (mobiililaitteet, työasemat jne.) oletko saanut virustartunnan tietyn ajan kuluessa?
- mttr (mean time to repair)—tietoturvamittareissa tämä on aika tietoturva-aukon löytymisen ja käyttöön otetun, toimivan korjaustoimenpiteen välillä. Kuten edellä mainittua tuotannon mttr-mittaria, turvallisuuden MTTR-mittaria olisi seurattava tietyin aikavälein. Jos MTTR-arvo pienenee ajan myötä, kehittäjät ovat entistä tehokkaampia ymmärtämään tietoturvakysymyksiä, kuten bugeja ja niiden korjaamista.
molemmilla mittareilla pienemmät luvut ajan myötä tarkoittavat, että ollaan menossa oikeaan suuntaan. Vähemmän päätepistetapauksia puhuu puolestaan. Kun MTTR-arvo pienenee, kehittäjät ovat yhä tehokkaampia ymmärtämään tietoturvakysymyksiä, kuten bugeja ja niiden korjaamista.
lisää tapoja soveltaa tietoturvamittareita ohjelmistokehitykseen löytyy artikkeleista Application Security for Agile Projects and Security Threat Models: an Agile Introduction.
huomautus source-code metrics
tänään on helppo kytkeä lähdekoodiskanneri build-putkistoon ja tuottaa runsaasti objektiivisia mittareita. On olemassa empiirisiä keskiarvoja ja ehdotettuja vaihteluvälejä sekä loogisia argumentteja näiden mittareiden suhteellisesta merkityksestä. Käytännössä nämä työkalut ovat kuitenkin kaikkein hyödyllisimpiä koodaustyylien täytäntöönpanossa, tiettyjen anti-kuvioiden merkitsemisessä ja poikkeavien tekijöiden ja trendien tunnistamisessa.
numeroihin ei vain kannata ripustautua. Tässä on esimerkki selitykseksi.
Oletetaan, että luokasta löytyy metodi, jolla on naurettava metriikka, kuten 52 miljoonan NPATH-kompleksisuus. Se tarkoittaa, että tarvittaisiin 52 miljoonaa testitapausta, jotta jokainen polku koodin läpi voitaisiin käyttää täysin. Voit muokata koodin yksinkertaisemmaksi rakenteeksi, mutta ennen kuin teet sen, mieti, mitä vaikutuksia sillä olisi liiketoimintaan. Mahdollisuudet ovat, vanha, ruma koodi toimii riittävän hyvin (vaikka sen testi kattavuus voi olla riittämätön). Antikuvion huutaminen tiimille, jotta he voivat välttää toistamasta sitä, on arvokasta oppia, mutta sen korjaaminen ei luultavasti liikuttaisi neulaa millään asiaankuuluvalla bisnesmittarilla.
on parasta, että tiimi hyväksyy sääntöjen noudattamisen tason ja säännöt, joita heidän koodiinsa sovelletaan, mutta muista, että poikkeavien tekijöiden tutkiminen ja huolestuminen suuntavilkuista voi tuhlata paljon aikaa.
then put it all together: Menestys on lopullinen mittari
automaattisten työkalujen käytön ilo laadun mittaamiseen ja mittaamiseen sekä käyttäjäanalytiikkaan on se, että se vapauttaa aikaa keskittyä mittareihin, joilla on oikeasti merkitystä: menestysmittareihin.
kuinka käyttää mittareita menestykseen
yrityksillä on tavoitteita. Tavoitteet herättävät kysymyksiä, kuten ” miltä menestys näyttää?”tai” miten tämä vaikuttaa asiakkaiden käyttäytymiseen?”Oikein kvantifioidut kysymykset tarkoittavat mittareita.
toisin sanoen mittareita tulisi käyttää vain kysymyksiin vastaamiseen, tietyn liiketoiminnan tavoitteen mukaisten hypoteesien testaamiseen. Ja tämä pitäisi tehdä vain niin kauan kuin kysymykset ja vastaukset auttavat ajamaan myönteisiä muutoksia.
eikö kaikilla projekteilla yleensä ole jokin joukko invariantteja tavoitteita, kysymyksiä ja hypoteeseja ja siten mittareita?
Kyllä, mutta vain elinkeinoelämän näkökulmasta. Yritystason mittarit, kuten käyttäjien sitoutuminen, lähimaksut, tulonmuodostus ja niin edelleen, antavat palautetta siitä, miten liiketoiminta pärjää todellisessa maailmassa. Muutokset ohjelmistoihin, jotka vaikuttavat liiketoimintaan, vaikuttavat myös tällaisiin mittareihin.
tarkemmalla resoluutiolla jokaisella ominaisuudella ja käyttäjätarinalla voi olla oma menestysmittarinsa—mieluiten vain yksi, ja sellainen, joka liittyy suoraan asiakkaalle toimitettavaan arvonmittariin. Yhdeksän kymmenestä tarinasta täyttäminen sprintissä ominaisuuksille, joita ei koskaan toimiteta, on tuhlausta, ei menestystä. Tarinoiden toimittaminen, joita asiakkaat eivät halua tai käytä, on tuhlausta, ei menestystä. Tuottaa tarina, joka parantaa joitakin osa käyttäjän onnea on menestys. Tuottaa tarina, joka todistettavasti ei paranna käyttäjän sitoutumista on myös menestys, koska olet oppinut jotain, joka ei toimi, mitätöity liiketoiminnan hypoteesi, ja vapautti resursseja jatkaa muita keinoja.
kuinka muotoilla arvohypoteesi
arvohypoteesi on lausunto siitä, mitä arvelet tapahtuvan tietyn ominaisuuden toimituksen seurauksena. Ohjelmiston, halutun lopputuloksen ja mittareiden välinen suhde muodostaa arvohypoteesin ominaisuudelle (tai järjestelmälle, tai tarinalle, tai päivitykselle jne.). Hypoteesin tulisi ilmaista, miten kohdennetun metriikan odotetaan muuttuvan, millä aikavälillä ja kuinka paljon sitä pidetään tehokkaana. Sinun täytyy puhua tiimin ja tuotteen omistaja, vähintään, selvittää erityinen asia tämä ominaisuus tai tarina on tarkoitus luoda tai parantaa suhteessa liiketoiminnan, jotta voidaan muotoilla sen arvo hypoteesi. Saatat joutua kysymään” miksi ” muutaman kerran (kuten kolmevuotias) kuoria takaisin kerrokset esittämättömiä oletuksia; ole kärsivällinen. Kun ymmärrät, mikä liiketoiminnan arvo on tarkoitus olla, voit alkaa kysyä kysymyksiä, jotka johtavat sinut mittarit, jotka vastaavat kysymykseen.
esimerkiksi” teknisen ” tarinan, jonka tarkoituksena on parantaa verkkokaupan kassaprosessin nopeutta, taustalla voi olla oletus siitä, että nopeampi kassaus lisää myyntiä. Mutta miksi luulemme niin? Luopuvatko monet ostoskärryistään kassan aikana? Jos tämä on konsensus (koska konsensusta tukevat lähtötiedot), niin arvohypoteesi voi olla ”uskomme, että nopeampi kassaprosessi johtaa alennettuun cart-luopumisasteeseen, mikä johtaa korkeampaan myyntiin ja parempaan käyttökokemukseen.”
voit todennäköisesti olettaa, että käyttäjät pitävät nopeammasta kassasta, mutta ei haittaa kysyä, ovatko he huomanneet. Cart-luopumisasteita ja myyntiä voidaan mitata ennen ja jälkeen uuden prosessin, jonkin aikaa. Jos cart-hylkäysprosentti laskee ja myynti kasvaa (yli tilastollisen vaihtelun), näyttö tukee hypoteesia ja voi harkita, onko vielä lisää nopeuden parannuksia perusteltua. Jos ne eivät ole, anna tämän metriikan haalistua taustalle (tai poista se, jos se häiritsee), ja käännä huomiosi seuraavaan hypoteesiin. Jos ostoskorista luopumisaste laskee mutta myynti pysyy ennallaan, mitataan pidemmän aikaa tai arvioidaan uudelleen oletettu yhteys ostoskorista luopumisen ja myynnin välillä. Toisin sanoen, käytä mittareita oppia, ja vain niin kauan kuin ne osoittautuvat hyödyllisiksi ajo parannuksia.
joissakin tapauksissa hypoteesi voi olla selvästi väärä, joten pudotamme Mittarit (ja kumotaan ohjelmistomuutokset!) muutaman päivän kuluttua. Muissa tapauksissa hypoteesi voi olla oikea, joten jatkamme ajaa parannuksia tällä alalla vuosia.
Six heuristics for effective use of metrics
olemme nähneet, kuinka subjektiivisilla ohjelmistomittareilla on paljon enemmän merkitystä liiketoiminnan menestykselle kuin vanhoilla perinteisillä, objektiivisilla laatumittareilla. Saavutetut oivallukset ja oppimismahdollisuudet painavat enemmän kuin tarpeellinen työ löytää ja mitata olennaisia liiketoiminnan mittareita ominaisuuksille. Liiketoimintaolosuhteet ja mahdollisuudet muuttuvat jatkuvasti, joten sen sijaan tiivistää kaavan seurata, joka voi olla hauras, tässä on kuusi nyrkkisääntöä, tai heuristics, auttaa säilyttämään keskittyä ja joustavuutta. Voivat ne auttaa opastaa matkasi laatu ohjelmisto ja liiketoiminnan menestys!
- Metrics ei voi kertoa tarinaa, ainoastaan joukkue pystyy siihen (hattuvinkki Todd Decapulalle).
- lumihiutaleiden vertailu on jätettä.
- voi mitata melkein mitä vain, mutta kaikkeen ei voi kiinnittää huomiota.
- Business success metrics ajaa ohjelmistoparannuksia, ei toisinpäin.
- jokainen ominaisuus tuo lisäarvoa; joko mittaa se tai älä tee sitä.
- mittaa vain se, mikä on nyt tärkeää.