Teknisk skuld vad gäller systemutveckling är kostnader som kommer sig av extra arbete i framtiden som beror på att man har valt en enkel lösning på ett problem. Den förklaringen som finns på Wikipedia är så bra som någon.

Ett enklare sätt att uttrycka det är att man alltid får ta konsekvenserna av dåliga beslut.

Problemen med teknisk skuld ger sig även till känna i agila projekt. När man har bråttom att slutföra ett användningsfall under en iteration i ett projekt är det lätt hänt att kompromissa. Man vill helt enkelt bli klar i tid.

Läs också: Här är det mest hatade språket

Kompromisserna kan bero på krav på funktionalitet, prestanda eller skalbarhet. Eller på att det är jobbigt att uppgradera nödvändiga komponenter i en lösning.

Hur ska man hantera teknisk skuld? Till att börja med, hur ska man kunna veta att den finns?

Ett sätt är naturligtvis att utvecklarna i ett projekt dokumenterar beslut som de tror, eller vet, kommer leda till teknisk skuld. Ett sätt att göra det är i form av kommentarer i kod, men då kan det bli svårt att få en överblick över läget.

Större ärenden bör tas med i backloggen (”att-göra-listan”) för ett projekt. Då blir det i bästa fall naturligare att åtgärda problemen snabbt. Det ger åtminstone förutsättningar för disciplinerade team att göra det.

Ett riktmärke, skriver Infoworld, är att 30 procent av backloggen bör vara reserverad för att åtgärda teknisk skuld. Det baseras på att mjukvaruleverantörer ofta debiterar motsvarande andel av priset för mjukvara som avgifter för supportkontrakt. Man kan tycka att orsakssambandet borde gå i motsatt riktning, men i praktiken är det så hör många leverantörer av mjukvara resonerar.

Läs också: Nu finns det ett smart sätt att mäta takten i ditt utvecklingsprojekt

Andelen av backloggen som reserveras för teknisk skuld kan så klart variera, till exempel en mindre andel för nya applikationer och en större för äldre.

Här är fyra sätt att hantera teknisk skuld i agila projekt och även i andra typer av projekt:

  • För större ärenden som rör teknisk skuld, till exempel sådana som påverkar en applikations livscykel, kan det vara klokt att avsätta en version, eller flera, av applikationen för att åtgärda dem. När man jobbar med en sådan version gäller det att inte införa ny eller förändrad funktionalitet. Ett sådant sätt att arbeta underlättar både tester och att hantera rotorsaker till problem.
  • Produktägaren och teamet kan med fördel tillsammans försöka identifiera teknisk skuld som påverkar användare i hög grad, som har mest negativ inverkan på utvecklares produktivitet eller är upphov till olika typer av risker. Prioritera sådana ärenden och ta med dem i backloggen.
  • Formulera acceptanskrav för användningsfall som underlättar att adressera teknisk skuld.
  • Försök att mäta teknisk skuld i ett projekt och formulera mätetal med kritiska nivåer för när man behöver agera.