Målinger – eller såkalte metrikker på fagspråket – er noe mennesker har holdt på med i tusen år og vi finner dem overalt. Vi måler størrelsen på fiskene vi fanger. Og tar tiden på idrettsutøvere, som de også gjorde i det gamle Hellas. I dag omgir vi oss med metrikker som KPI-er, faktureringsgrader, medarbeiderundersøkelser osv.
Siden starten av den industrielle revolusjonen har masseproduksjonen eksperimentert og kommet frem til omforente metrikker som er verdifulle. Man sjekket hvor lang tid det tok å gjennomføre oppgaver og eksperimenterte med nye produksjonsmåter for så å ta tiden på nytt. Man veide og målte ting som produseres, justerte på maskiner og målte på nytt for å verifisere at justeringen førte til forbedring. Flere av metrikkene kan man finne i Lean-litteraturen.
Forsker og bloggforfatter Tor Thorsrud Sporsem i SINTEF. Foto: Thor Nielsen
IT-bransjen derimot er en ung bransje sammenlignet med produksjon. Vi er fortsatt i utforskningsfasen, og prøver å finne konsensus rundt metrikker for effektivitet og produktivitet.
Vanlige målinger duger ikke
Hvorfor kan vi ikke bare adoptere metrikkene fra masseproduksjonen? Dessverre har vi andre spilleregler i IT-bransjen. For eksempel kan man ofte ikke ta på det som lages. Det kreves ikke store investeringer i materialer, fabrikker eller store logistikksystemer for å lage software som kan selges i stor skala. Man trenger i prinsippet kun noen kunnskapsrike mennesker og infrastruktur som i stor grad kan leies ved å knipse i fingrene.
Med andre ord må IT-bransjen finne sine metrikker selv. Vår gjennomgang av forskningen viser noen tydelige punkter:
- Ikke gi andre enn teamet innsikt i målingene som faktisk skal brukes til forbedring. Det kan føre til uønskede arbeidsmønstre og juks.
For å illustrere dette brukes ofte flyplass-eksemplet. Da en flyplass begynte å måle hvor lang tid det tok å få bagasjen fra flyet til bagasjebåndet, begynte et av teamene å plukke én bag fra flyet, for å haste den alene på en bli til bagasjebeltet og fikk registrert “first bag on belt”. Til tross for ros og belønning ble ikke resultatet noe bedre for passasjerene.
- Målinger gir aldri et fullstendig bilde av virkeligheten. For eksempel er det veldig vanlig å måle antall linjer kode. Om antall linjer kode går drastisk ned kan det skyldes at noen har slette masse kode ved en feiltakelse eller det kan være en bevisst handling for f.eks. å gjøre kodebasen mindre vedlikeholdskrevende – altså en forbedring.
For å kompensere prøver mange å introdusere veldig mange metrikker for å fange det hele bildet. Dette fører ofte til at team slutter å følge med på metrikkene, det blir for mange av dem til at de evner å forholde seg til alle.
- Målinger må være knyttet til et tydelig mål (goal). For eksempel er deployment frequency (1) en metrikk som amerikanske forskere anbefaler for å få effektive team.
Hensikten med målingen er at ny kode skal bli synlig for de som bruker programmet tidlig, så teamet kan få feedback på det de lager så raskt som mulig. En typisk feil mange gjør er at de blir så opptatt av metrikken at de glemmer hensikten (målet) med den. Med andre ord blir man så opptatt av en høy deployment frequency at man glemmer å investere tid i å utforske de viktige tilbakemeldingene fra brukerne av programmet.
- Målinger viser ansatte hva som er viktig for bedriften. Det som måles er det som får fokus. Måler man for eksempel antall linjer kode vil det få fokuset til utviklerne – selv om dette er ikke er noe brukerne ikke bryr seg om. Dette er en typisk fallgruve, man innfører målinger som bidrar til handlingsmønstre som ikke er viktig for bedriftens kjernevirksomhet.
I forskningsprosjektet Transformit skal vi teste metrikkene som Google foreslår for å sjekke om de er valide i Norge. I tillegg skal vi teste noen forslag fra andre amerikanske forskere (2) til hvordan måling kan hjelpe utvikler-team til å forbedre seg.
Lurer du på noe, ta gjerne kontakt med bloggforfatteren. Kontaktinfo og mer om Knowit sin forskningssatsning finner du her.
Referanser :
- Fotnote 1 og 2) Forsgren, N. et al. The SPACE of Developer Productivity. Queue 19, 20–48 (2021).
- Andre referanser til forskning:
- Bouwers, E., Visser, J. & Deursen, A. van. Getting what you measure. Commun Acm 55, 54–59 (2012).
- Forsgren, N. & Kersten, M. DevOps Metrics. Queue 15, 19–34 (2017).
- Kupiainen, E., Mäntylä, M. V. & Itkonen, J. Using metrics in Agile and Lean Software Development – A systematic literature review of industrial studies. Inform Software Tech 62, 143–163 (2015)
