Hvordan måler og forbedrer du den tekniske helsen til et team og en kodebase?

Question

Accepted Answer

**Teknisk helse** er hvor bærekraftig et team kan levere, kodekvalitet, systemtilpålitelighet og leveringshastighet sammen. Du kan ikke forbedre det du ikke måler, men målet er *innsikt for å drive forbedring*, aldri et tall å nå. Metrikker er en lommelykt, ikke en resultatavle.

## Hva du skal måle

```text
DELIVERY (DORA metrics — well-researched, balanced):
  - Deployment frequency        - Lead time for changes
  - Change failure rate         - Time to restore service

QUALITY / RELIABILITY:
  - Production incident rate & severity
  - Test coverage trend (direction, not a vanity %)
  - Escaped-bug rate

TEAM / FLOW:
  - Cycle time, time-in-review (slow review = hidden bottleneck)
  - Recurring pain points (survey the team — they know)
```

## Bruk DORA, balansert

De fire DORA-metrikene er verdifulle fordi de *balanserer* hastighet og stabilitet, du kan ikke manipulere den ene uten å skade den andre. Høy deploy-frekvens med høy feilrate er et rødt flagg, ikke en seier. Spor settet, ikke et enkelt tall.

## Et konkret eksempel

Lead time for changes kreper oppover. Du graver deg inn og finner at PR-er sitter i gjennomgang i dagevis. Metrikken pekte deg mot en reell flaskehals, et gjennomgangsprosess-problem, som du aldri ville ha oppdaget ved magefølelse. Du fikser prosessen, og metrikken forbedres som en *bieffekt*.

## Den store fellen: manipulering

I det øyeblikket en metrikk blir et mål, optimaliserer folk tallet, ikke resultatet (Goodharts lov). Dekningsmål avler verdiløse tester; hastighetsmål avler oppblåste estimater. Bruk metrikker til å *finne* problemer, snakk deretter med mennesker, aldri til å rangere eller straffe dem.

## Hvorfor det betyr noe

Uten signaler forverres teknisk helse usynlig til teamet er mysterisk sakte og ingen kan si hvorfor.

God måling gjør det usynlige synlig, slik at du kan investere hvor det teller, og bevise effekten når du gjør det.