Viisi parasta ohjelmistosuunnittelun tunnuslukua ja miten niitä huijataan

Tekijä Bill Harding,Ohjelmoija/CEO
Julkaistu 31.3.2020.Päivitetty viimeksi 17.4.2020.

Kun puhutaan insinöörityön tunnusluvuista, kuulee usein kaksi ristiriitaista truismia:

Mitä mitataan, se paranee.-Peter Drucker

Ja

Kun mittari muuttuu tavoitteeksi, se lakkaa olemasta hyvä mittari.-Goodhartin laki

Kumpikin näistä lausunnoista kuvaa teknisiä suorituskykyindikaattoreita osittain, mutta yhdessä ne viittaavat siihen, että mittaamista on mahdollista käyttää parantamiseen.

Huono uutinen on se, että se vaatii jonkin verran sitoutumista oppimiseen, erityisesti niiltä, jotka tulevat kaukaisista (eli ei-teknisistä) rooleista.Hyvä uutinen on se, että huolella valitut mittarit voivat toimia ja toimivat jatkossakin huolimatta siitä, että niistä ”tulee tavoite”. Itse asiassa monien suosittelemiemme mittareiden osalta voidaan todeta, että mitä enemmän työntekijä ”pelaa järjestelmää”, sitä enemmän se palvelee yrityksen pitkän aikavälin etuja. Lopputavoitteena ovat mittarit, jotka toimivat edelleen hyvin, vaikka niitä ”huijataan”. On viisi mittaria, jotka täyttävät tämän riman.

Kohderyhmä: Jokainen johtaja, joka on yrittänyt saada insinööritiimiltään enemmän valmiita tikettejä, tuntee taistelun.He haluavat toteuttaa oikeudenmukaisia, tietoon perustuvia toimia, jotka parantavat heidän nopeuttaan. He tietävät, että vaistoon perustuvien päätösten tekeminen on kallista ja skaalautumatonta. Silti kun he katsovat tehtävälistaansa, se on täynnä tehtäviä, jotka tuntuvat kiireellisemmiltä kuin ”mittauksen parantaminen”. Käytännössä mittaamisen omaksuminen tapahtuu usein katastrofaalisen epäonnistumisen jälkeen, kuten virheellisen julkaisun rakentamisen tai sen jälkeen, kun kehittäjä ei ole sulkenut yhtään tikettiä kuukauteen.

Jopa silloin, kun on selvää, että mittaamisen on tapahduttava, on epäselvää, mistä aloittaa. Voit googlettaa ”engineering KPIs”, klikata koko ensimmäisen tulossivun läpi ja jäädä epäselväksi siitä, mitä seuraavaksi pitäisi tehdä. Esimerkkinä mainittakoon usein mainostettu mittari ”Team Velocity”. Lähes jokaisessa Google-tuloksessa suositellaan tiimin nopeuden mittaamista, mutta kukaan ei halua kertoa, mitataanko sitä… suljettuina lippuina? Koodiriveillä? Tarinapisteissä? Mitä se sitten onkin, johtajilla ei ole aikaa selvittää sitä. Heidän on saatava tästä 15 000 jalkaa pitkästä teoriavuoresta jotain sellaista, jota he voivat ymmärtää, johon he voivat luottaa ja josta he voivat hyötyä… mieluiten välittömästi.

Tämän artikkelin lähtökohtana on, että olet johtaja, joka haluaa ymmärtää ohjelmistosuunnittelun mittareita juuri tarpeeksi hyvin tehdäkseen tiimistäsi tehokkaamman. Johtajana oleminen tarkoittaa, että olet liian kiireinen oppiaksesi teoriasta, paitsi silloin, kun se liittyy suoraan siihen, miten voit hyötyä teoriasta.

Mittareiden on oltava käytännöllisiä, jotta todelliset yritykset voivat kokeilla niitä

Voit ennen tämän artikkelin kirjoittamista sulatella 20:ssä parhaassa Google-tuloksessa ehdotettuja metriikoita ohjelmistoteknisten mittareiden alalla. Kuten voitte kuvitella, jokaisella lähteellä oli omat teoriansa siitä, mitkä metriikat ovat tärkeimpiä.Artikkelit jakoivat metriikat usein ryhmiin, kuten ”prosessimetriikat” ja ”projektimetriikat”. Noudatamme heidän ohjeistustaan metriikoiden ryhmittelyssä, mutta ryhmämme ovat ”laatumittarit” ja ”kaikki muu”.”

Tässä on, mikä kelpaa laatumittariksi:

  • Liiketoiminta-arvo.Onko mahdollista piirtää suora viiva metriikka => luodusta liiketoiminta-arvosta?
  • Mitattavissa.Voidaanko määritellä tietty luku ja sen mittayksiköt (esim, pisteet, prosenttiosuus), jotta sitä voidaan seurata ajan mittaan ja suhteuttaa tapahtumiin ja kokeiluihin?
  • Toimintakykyinen.Voidaanko sen avulla säännöllisesti toteuttaa toimia, jotka johtavat myönteisiin tuloksiin? Mieluiten niin, että vääriä positiivisia tuloksia on mahdollisimman vähän?
  • Saatavilla/kätevä.Voiko keskiverto ohjelmistosuunnittelutiimi käyttää tätä mittaria muuttamatta nykyisiä kehitysprosessejaan?
  • Suosittu.Onko mittarilla tarpeeksi seuraajia, jotta se on hyvin dokumentoitu ja uskottava?
  • Sijoittaminen ”laatumittareiden” joukkoon edellyttää kaikkia viittä edellä mainittua kriteeriä sekä tyydyttävää vastausta venytyskysymykseemme:jos luotamme tähän mittariin ja kehittäjät optimoivat sen perusteella, mitä sitten tapahtuu?Vuosien ajan rakentaessamme ja iteroidessamme omaa kehitysmetriikkaamme (”Line Impact”) olemme oppineet, että myrkylliset sivutuotteet ovat odotettavissa oleva seuraus mittaamisesta, ellei metriikka ole täsmällisesti linjassa pitkän aikavälin liiketoimintaarvon kanssa.Esimerkkinä näytämme myöhemmin, kuinka kehittäjät, jotka yrittävät pelata ”läpimenoaika”-mittarilla, heikentävät johdon läpinäkyvyyttä.

    Quality engineering KPI:t

    Tässä on viisi ohjelmistomittaria, jotka täyttävät kaikki vaatimukset ja auttavat johtajia johtamaan tehokkaampaa tiimiä.

    🏦 OKR-pohjainen

    Esimerkki OKR-malli

    Yksi monista esimerkki-OKR-malleista, jotka ovat saatavilla Weekdonen kautta osoitteessa Okrexamples.com

    Jokainen liiketoiminta-arvon maksimointiin keskittyvä lista pitäisi aloittaa tästä. Johtavat yritykset, kuten Google, käyttävät OKR:iä ensisijaisena akselina, jonka perusteella he arvioivat johtavia insinöörejä. OKR-lähtöisten mittareiden haittapuoli on se, että ne ovat määritelmällisesti yrityskohtaisia. Tämä tekee mahdottomaksi yleistää kaavaa, jolla ne voidaan tallentaa, tai yleistää polkua, jota pitkin niitä huijataan.

    Miten niitä voi huijata?Riski OKR:ien huijaamisesta on pieni, koska ne ovat yleensä liiketoimintakeskeisiä. OKR-lähtöisten mittareiden suurin vaara on se, että koska ne tyypillisesti laaditaan kertaluonteisesti (tai määräajoin), ne eivät ehkä ole yhtä luotettavia kuin mittarit, joita on tutkittu vuosien ajan. Esimerkiksi OKR:n asettamista tavoitteeksi ”ottaa käyttöön vähemmän kuin 10 virhettä kuukaudessa” voidaan huijata siten, että ei oteta käyttöön yhtään uutta ominaisuutta. Olettaen, että molemmat osapuolet toimivat vilpittömässä mielessä, OKR-pelaamisen pitäisi käytännössä olla harvinaista.

    Miten sen saa?Olemassa olevien mittaritaulujen avulla tai tekemällä yhteistyötä Weekdonin kaltaisten yritysten kanssa, jotka auttavat tarjoamaan OKR-inspiraatiota.

    📐Line Impact

    Esimerkki insinöörityön KPI Line Impact: luotettava lähdekoodin metriikka

    10 repos graphed by their Line Impact, a metric that quantifies the pace at the pace that source code is evolving,image courtesy GitClear

    Line Impact on metriikka, joka on suunniteltu mittaamaan, kuinka paljon kognitiivista energiaa ohjelmistokehitykseen käytetään.Tämä video tarjoaa havainnollisen selityksen siitä, miten se on mahdollista. Lyhyt selitys on, että Line Impact kumoaa kaiken välivaiheen toiminnan (”churn”), jota tapahtuu, kun ominaisuutta kehitetään, jolloin jäljelle jää keskittynyt ruumiillistuma tehdystä työstä. Line Impact säilyy eri kielillä, joten Line Impactin tuottamiseen kuluu yhtä paljon aikaa riippumatta siitä, kirjoittaako kehittäjä Java-, Python-, Javascript- tai mitä tahansa muuta merkittävää ohjelmointikieltä (yli 30 tuettua kieltä).

    Liiketoiminnallisen arvon kannalta Line Impact on rinnakkainen Story Pointsin kanssa: se havainnollistaa, miten tehtävän kustannukset vaihtelevat sen mukaan, kenelle se on annettu. Tämän perusteella sitoutunut johtaja voi käyttää Domain Experts -raporttia sovittaakseen Jiran aihepiirin asiantuntijoille, mikä voi nopeuttaa tuotteen nopeutta huomattavasti.

    Miten sitä käytetään?Kaikkiin mittareihin, jotka väittävät tietolähteekseen ”Lines of Code” (LoC) (kuten Line Impact), on syytä suhtautua varovaisesti. Huolimattomasti toteutettuna pienetkin puutteet prosessoinnissa suurentuvat ääneksi, joka peittää signaalin.Siksi GitClear rakensi markkinoiden parhaat koodin tarkastustyökalut:jotta johtajat ja kehittäjät voivat tarkastella, miten Line Impact -mittari jaetaan komitoittain ja tiedostokohtaisesti.Läpinäkyvyys on tehokas vastalääke pelaamisen torjumiseksi.

    Lisäsuojaa tarjoavat ilmoitukset, jotka aktivoituvat, kun kehittäjä tekee työtä epätavallisella vauhdilla. Nämä ja muut toimenpiteet ovat tehneet Line Impactin pelaamisesta niin vaikeaa, että GitClear ei ole vielä saanut asiakasta, joka olisi ilmoittanut, että hänen tiiminsä olisi onnistunut pelaamaan Line Impactia.Tästä huolimatta olisi vilpillistä väittää, että mittari olisi jotenkin läpäisemätön pelaamiselle, joten tässä on luettelo tunnetuista tavoista, joilla voi kerätä nopeaa Line Impact -vaikutusta.Lyhyesti sanottuna, jos kehittäjä kirjoittaa testejä, poistaa vanhaa koodia ja lisää dokumentaatiota, hän ansaitsee huomattavan osuuden Line Impact -vaikutuksesta.

    Miten saat sen?Rekisteröidy 15 päivän ilmaiseen kokeilujaksoon. Jos pidät siitä,hinnat alkavat 9 dollarista aktiivista kehittäjää kohden.katso lyhyt selitysvideo Line Impactista täältä.on prem-versio saatavilla.

    🎲 Story Points

    engineering KPIs: Jira burndown report

    Story Point-pohjainen ”release burndown”-raportti,saatavilla Jiran kautta

    Story Points voisi väittää olevansa insinöörityön KPI:istä ”klassisin”. Story Pointsin laskemiseen on monia eri tapoja. Kaikki muodot johtavat arvioon kehittäjien odotetusta ajasta jonkin tehtävän suorittamiseen. Johtajat voivat käyttää Story Points -pisteitä laskemaan tehtävän aiheuttamat kustannukset, esim. jos kehittäjä ansaitsee 10 000 dollaria kuukaudessa, lippu on arvioitu 10 Story Points -pisteellä = puolet kuukaudesta, kustannukset ovat 10 000 dollaria * 0,5 = 5 000 dollaria.Jonkin version käyttäminen tästä laskutavasta auttaa priorisoimaan tehtäviä sen perusteella, mitkä tuottavat suurimman suhteen ennakoidun arvon ja ennakoitujen toteutuskustannusten välillä.

    Miten pelataan?Suurin huomio tässä yhteydessä kiinnittyy siihen, miten Story Points -pisteitä lasketaan. Helpoin tapa ”pelata” Story Points -pisteillä on se, että kehittäjätiimi vääristää arviointiasteikkoa, yleensä vaikeuden yliarvioimiseksi. Yksi vaihtoehto tämän ongelman ratkaisemiseksi on sallia tehtävien valitseminen ”tehtävämarkkinoilla”, jossa yliarvostetut tehtävät voidaan jakaa tasaisesti kehittäjien kesken suhteellisen kalibroinnin säilyttämiseksi. Toinen tapa puuttua tähän on kalibroida säännöllisesti uudelleen vakio, jota käytetään tarinapisteiden muuntamiseen ”kehittäjäpäiviksi”. Huomaa, että koska Story Points -pisteiden toteutus vaihtelee usein tiimeittäin, niitä ei ole suositeltavaa käyttää tiimien välisen suorituskyvyn vertailuun.

    Miten se saadaan?Useimmat ongelmanseurantapalvelut tällä puolella GitHubia mahdollistavat Story Points -pisteiden määrittämisen. Mitä tulee niiden tarkasteluun, Jira tarjoaa ”next-gen velocity report”-raportin, jonka tarkoituksena on näyttää ajan mittaan valmistuneet Story Points -pisteet.Jira tarjoaa myös ”release burndown report” -raportin, joka käyttää Story Points -pisteitä arvioidakseen, miten tiimi on kehittynyt kohti sprintin tavoitteita. GitClear tarjoaa myös alkeellisia (toistaiseksi) graafeja, jotka havainnollistavat Story Pointscompleted over the time.

    🐞 Bug Rate / Escaped Defects

    Tämä mittari määritellään eri lähteissä eri tavoin, mutta ne kaikki pyrkivät samaan olennaiseen kysymykseen: kuinka monta virhettä pääsee ulos maailmaan, ja kuinka hyvin reagoimme niihin?Stackify suhteuttaa sen tiettyihin numeerisiin termeihin:

    Virheiden karkaamisprosenttisi ilmaistaan prosentteina, jotka perustuvat siihen, kuinka monta virhettä löydät, ennen kuin ne päätyvät tuotantoon, tai kuinka moni niistä pääsee tuotantoon, miten haluat. Jokainen ohjelmistoprojekti ja tiimi on erilainen, mutta ehdotamme, että pyritään löytämään 90 % kaikista vioista ennen kuin ne päätyvät tuotantoon.

    Stackifyn määritelmä lähtee siitä oletuksesta, että joku nimeää kentän ongelmanseurantaan, jotta voidaan kirjata, missä kehitysvaiheessa vika tapahtui. Tiimeille, joilla ei ole aikaa perustaa ja seuratakehitysvaiheita, korvaava määritelmä voi olla:

    Miten usein uudessa ominaisuudessa kirjoitettu koodi muuttuu koodiksi, jota muutetaan vian korjaamisen aikana?

    Tietoihin sidottu vastaus tähän kysymykseen annetaan GitClear-käyttäjille, mutta sitä on vaikea laskea manuaalisesti (jos et ole GitClear-käyttäjä).Taatusti käytettävissä oleva varamittaus vikaprosentille voi olla ”mikä on luotujen vikojen ja ratkaistujen vikojen suhde”?

    Miten sitä voi pelata?Tätä mittaria on vaikea pelata. Kehittäjä voi ottaa vastaan useampia pieniä lippuja, mutta jokainen lippu lisää virheiden riskiä, jos hän ei ole varovainen. Tämä riski virheprosentin käytössä on se, että se tarvitsee vastapainoa ”edistykselle”, kuten tarinapisteille tai linjavaikutukselle, sillä muuten kehittäjä voi viipyä yhden ongelman parissa koko sprintin ajan varmistaen 0 %:n virheprosentin.

    Miten se saadaan?Jos tiimilläsi on kaistanleveyttä ongelmien merkitsemiseen sen kehitystyön vaiheen mukaan, jossa ne ovat tapahtuneet, niinEscaped Defects (vältetyt virheet) voidaan laskea manuaalisesti millä tahansa ongelmanseurantajärjestelmällä. GitClear on toinen käytettävissä oleva vaihtoehto, jolla voidaan laskea vioiksi muuttuneiden ominaisuuksien prosenttiosuus.

    ✅ Pull Request Completion Rate

    Esimerkki insinöörityön KPI:stä Pull Requests: tilastot GitClearissa

    Näyte GitClearin tarjoamista pull request -tilastoista

    Miten monta prosenttia pull request -pyynnöistä on suljettu viikon sisällä avaamisesta? Tähän liittyy useita yksityiskohtaisempia kysymyksiä, kuten ”onko tiimi sitoutunut vastaamaan nopeasti uusiin vetopyyntöihin”, ”pystyvätkö he yhteistyöhön” ja ”ovatko kehittäjät kiillottaneet koodinsa ennen sen lähettämistä yhdistettäväksi?”

    Miten sitä pelataan?Vetopyyntöjen loppuunsaattamisprosentti -testin saavuttaminen tarkoittaa sitä, että PR-pyynnöt suljetaan aina viikon kuluessa. Tätä on suhteellisen vaikea pelata, mutta sen vastapainoksi on oltava jokin liikkeellepaneva voima, kuten Story Points tai Line Impact, muuten kaikki tiimin kannustimet ovat työn kiillottaminen sen sijaan, että se lähetettäisiin (tai lähetettäisiin PR-katselmukseen).

    Miten sen saa?Kaikki ”nimimerkkien” Engineering Insight -palveluntarjoajat (GitClear, Pluralsight, Code Climate, Pinpoint) tarjoavat tilastotietoja, jotka havainnollistavat tiimin pull request -prosessin tehokkuutta.Autamme vertailemaan palveluntarjoajia tässä.

    Kunnianosoitukset

    ”Huipputason” mittareiden alapuolella on väliin jäävä taso. Nämä ovat mittareita, joilla on toivottavia ominaisuuksia tärkeiden puutteiden rinnalla. Ne voivat silti tuottaa arvoa, kunhan johtaja osaa ottaa huomioon niiden rajoitukset.

    Lead Time/Cycle Time

    Lead Time -graafi visualisoituna Azure Devopsin kautta

    Vaikka se on listattu (kahdesti!) Pluralsightin Top 5 -mittareiden luettelossa,Cycle Time on hyvä ajatus, joka on erittäin altis pelaamiselle.

    ”Lead Time” määritellään useimmiten seuraavasti: ”Mikä on väli, joka kuluu sen välillä, kun tehtävä jätetään ongelmanseurantaan ja kun se toimitetaan asiakkaalle?”. Sen serkku, ”Cycle Time”, on Lead Timen osajoukko, joka määritellään seuraavasti: ”aika, joka kuluu sen välillä, kun tuotetiimi poimi sen jonosta, ja sen välillä, kun se saapuu tuotantoon.”

    Miten sillä voi pelata?Lead Timen suorituskyky riippuu jossakin määrin mekanismista, jolla Jirat arkistoidaan, mikä tarkoittaa, että sen sovellettavuus eri tiimeissä on heikko. Cycle Time on riippuvainen konventioista, joiden mukaan committeri päättää tehdä ensimmäisen commitinsa. Näin ollen tällä mittarilla on helppo pelata, jos kehittäjä säästää sitoumuksensa paikallisesti ja julkaisee ne kerralla välittömästi ennen PR:n lähettämistä. Tämä epäonnistuminen on se, minkä vuoksi Cycle Time jää ”kunniamaininta”-osioon. Se ei myöskään ole ihanteellinen: kannustamalla kehittäjää tallentamaan sitoutumisiaan ilman työntöä, joukkuetovereiden on mahdotonta puuttua asiaan työn ollessa kesken.Tämä sivuvaikutus vähentää läpinäkyvyyttä johtajan ja hänen kehittäjiensä välillä.

    Miten se saadaan?Azure Devops Services tarjoaa edellä esitetyn graafin.Jira tarjoaa myös version siitä.Kaikki tärkeimmät Engineering Insight -tarjoukset (GitClear, Pluralsight, Code Climate Velocity, Pinpoint) toteuttavat jonkinlaisen version Lead Time -laskennasta.

    Testien kattavuus

    Testien kattavuuden jonkinlaisen mittarin kuvaaminen on järkevä tavoite, jota kannattaa harkita. Se ei kuitenkaan aivan kelpaa Top Tier -mittariksi kahdesta syystä:

  1. Se on epätäydellinen ratkaisu. Riittävän testauksen on sisällettävä toiminnallisia ja integrointitestejä yksikkötestien ohella, eikä mikään automaattinen ratkaisu voi tietää, millä sivuilla sovelluksen tai verkkosivuston sisällä on käytävä, vaan tämä vaatii edelleen ihmisen ohjausta
  2. Se on hyvin vaikea sitoa takaisin ylimpiin liiketoimintamittareihin. Testien kattavuutta kannattaa arvioida osana johtavan kehittäjän suunnitelmaa, jolla seurataan koodin laatua, mutta se ei liity liiketoimintahyötyyn tarpeeksi suoraan, jotta se voisi tehdä leikkauksen itsestään. Samankaltainen, mutta liiketoiminnallisempi metriikka koodivirheiden seuraamiseen on ”Bug Rate / Escaped Defects.”

”Everything Else” Metrics

Yllä oleva luettelo on suhteellisen lyhyt verrattuna muiden kirjoittajien ehdottamiin aiempiin metriikoihin.Täydellisyyden vuoksi käydään läpi joitakin muualla yleisimmin mainittuja mittareita ja miksi ne eivät päässeet mukaan.

Team Velocity

Tämä oli yksi suosituimmista muissa artikkeleissa mainituista mittareista. Sitä suosittelevatTechBeacon,InfoPulsejaSeaLights.io.Kirjoittajat tuntuvat kuitenkin olevan varovaisia määrittelemään tämän tärkeän mittarin yksiköt.TechBeacon määrittelee sen ”kuinka monta ’yksikköä’ ohjelmistoa tiimi tyypillisesti saa valmiiksi iteraation aikana”. Ei mitenkään konkreettista. InfoPulse ei yritä määritellä yksiköitä. SeaLightsin mukaan yksiköt ovat ”Story Points”. Näin ollen päättelemme, että ”nopeuden” käsite on riittävästi kuvattu Story Pointsilla tai Line Impactilla.

Code Churn

GitPrimen toimitusjohtaja (jonka Pluralsight on nyt ostanut) oli niiden joukossa, jotka kannattivat Code Churnin huomioon ottamista.Väitämme vastauksessamme, että Code Churnin seuraukset ovat kaikkialla kartalla, mikä vaikeuttaa toimimista korkeaan vaihtuvuuteen. Mittareiden on oltava toimintakelpoisia.

Release/Sprint Burndown

SeaLights ja InfoPulse suosittelevat kiinnittämään huomiota siihen, miten tiimi kehittyy kohti sprinttitavoitteitaan.Olemme samaa mieltä siitä, että tämä on tärkeää, mutta se on jo käsitelty yllä olevassa ”Story Points” -osiossa.

Mean time to repair / Mean time between failures

Tässä kourallisessa artikkeleita, jotka puolustavat näitä mittareita, yksikään ei uskalla kuvata, mihin yksiköihin mittari perustuu tai mitä palvelua voidaan käyttää näiden datapisteiden keräämiseen.Tutkimus osoittaa, että Atlassian tarjoaa apuartikkelin aiheesta.Jos tämä artikkeli ei olisi jo nyt 2500 sanan mittainen, MTTR saattaisi mahtua ”Kunniamaininnat”-osioon. Mutta sitä ei ole helppo yhdistää liiketoiminta-arvoon, eikä se ole suoraviivaista tavalliselle tiimille saada käyttöönsä muuttamatta rutiinejaan.

Jäikö meiltä jotain huomaamatta?

Leave a Reply

Vastaa

Sähköpostiosoitettasi ei julkaista.