Hogyan azonosítja, rangsorolja és törleszti a technikai adósságot?

Question

Accepted Answer

A **technikai adósság** az a különbség, hogy a kód milyen és hogyan kellene lennie, felvett (szándékosan vagy sem) a gyorsabb előrehaladáshoz. Bizonyos adósság elfogadható; a feladat ennek kezelése, nem annak megszüntetése. A lényeg az olyan adósság prioritása, amely valóban *károsít*.

## Miért fontos ez

```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
```

## Konkrét példa

Egy törékeny modul, amely minden kiadásnál meghibásodik és hetente blokkolja a csapatot, megérdemli a javítást. Az egy csúnya-de-stabil segédprogram, amit senki sem érint, *nem*, még ha meg is sértett. Ennek újrafaktorálása hiúság, nem érték.

## Hogyan finanszírozzon munkát

A tiszta "adósság sprintek" ritkán kapnak jóváhagyást. Jobb taktikák:

```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"
```

## Miért fontos ez

A kezelt adósság összetett: a sebesség csöndesen csökken, amíg a csapat alig tud szállítani.

De minden hiányosság üldözése pazarolta az időt olyan adósságra, amely nem számít.

A TL értéke a különbség ismerete és az ügy vezetőségnek való előterjesztése *üzleti* kifejezésekben, nem csak mérnöki kifejezésekben.