Teknisk sundhed er, hvor bæredygtigt et team kan levere, kodekvalitet, systemtillidelighed og leveringshastighed sammen. Du kan ikke forbedre det, du ikke måler, men målet er indsigt til at drive forbedringer, aldrig et tal at ramme. Målinger er en lommelygte, ikke en scoreboard.
Hvad skal måles
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)
Brug DORA, balanceret
De fire DORA-målinger er værdifulde, fordi de balancerer hastighed og stabilitet, du kan ikke spille et uden at skade det andet. Høj deployfrekvens med en høj fejlrate er et rødt flag, ikke en sejr. Spor sættet, ikke et enkelt tal.
Et konkret eksempel
Lead time for changes stiger. Du graver dybere og finder ud af, at PR'er sidder i review i dagevis. Metrikken pegede dig hen til en rigtig flaskehals, et review-procesproblems, som du aldrig ville have spottet ved mavefornemmelse. Du fikser processen, og metrikken forbedres som en bivirkning.
Den store fælde: gaming
I det øjeblik en metrik bliver et mål, optimerer folk tallet, ikke resultatet (Goodharts lov). Dækningmål avler værdiløse tests; velocity-mål avler oppustede estimater. Brug målinger til at finde problemer, derefter tal med mennesker, aldrig til at rangere eller straffe dem.
Hvorfor det betyder noget
Uden signaler forværres teknisk sundhed usynligt, indtil teamet på mystisk vis er langsomt, og ingen kan sige hvorfor.
God måling gør det usynlige synligt, så du kan investere, hvor det tæller, og bevise virkningen, når du gør det.