Kako prepoznaš, prednostno razvrščaš in odplačaš tehnični dolg?

Question

Accepted Answer

**Technical debt** je vrzel med tem, kako je koda zdaj, in kako bi morala biti, ki jo namenoma ali nemamenoma prevzameš, da se premikaeš hitreje. Nekoliko dolga je v redu; naloga je upravljati ga, ne pa ga odpraviti. Ključno je prednostno razvrščanje dolga, ki dejansko *škoduje*.

## Prednostno razvrščanje po vplivu, ne po nadlogi

```text
For each piece of debt, ask:
  - How often does it slow us down or cause bugs? (frequency)
  - How bad is it when it bites? (severity)
  - How risky/expensive is it to fix? (cost)

High frequency + high severity + low cost → fix now
Low frequency + low severity → leave it, document it
```

## Konkreten primer

Krhka modul, ki se zlomi ob vsakem izdajanju in tedensko zaustavlja ekipo, je vredno popraviti. Grda, a stabilna utility, ki je nihče ne dotika, *ni*, čeprav te žali. Refaktoriranje je taščina, ne vrednost.

## Kako financirati delo

Čiste "debt sprinte" redko dobijo odobritev. Boljše taktike:

```text
✓ Budget ~10-20% of each sprint for debt continuously
✓ Pay debt down inside related feature work ("boy scout rule")
✓ Tie debt to business pain: "this is why feature X took 3 weeks"
```

## Zakaj je to pomembno

Neupravljen dolg se skupša: hitrost tiho pada, dokler ekipa komaj še kaj pošlje.

Ampak lovljenje vsakega nedosledka izgubi čas za dolg, ki sploh ne šteje.

Vrednost TL je vedeti razliko in predstaviti primer vodstvu v *poslovnih* pogojih, ne samo inženirskih.