Hannes Lindblom

Bara listerna kvar - teknisk skuld ur ett kvalitetsperspektiv

2019-08-26 Artikelbanken Blogg Test Läst 839 gånger

När jag och min fru en gång i tiden skulle renovera några rum i vår dåvarande lägenhet hade vi ett väldigt ambitiöst upplägg. Under två veckors tid tog vi ledigt från jobbet och lade all vår tid på slipning, målning, tapetsering och allt det där andra som hör renovering till. Efter de där två veckorna hade vi fått fint i både vardagsrum, sovrum och gästrum. Äntligen kunde vi pusta ut, nu var det ju bara listerna kvar. Ni som någon gång renoverat kan nog ana vad som hände sen. Listerna blev liggande i veckor, som sen blev till månader. Även om det var fint i rummen kände vi hela tiden att det inte kändes helt klart, och de där listerna som låg i en hög blev till ett jobbigt störningsmoment som hela tiden sög lite energi. När vi slutligen en dag efter drygt ett år tog oss i kragen och fick upp listerna var det en stor lättnad för oss båda.

Historien om listerna har jag med mig i min roll inom test och kvalitetsarbete. När är något egentligen klart? Hur hanterar man de ofärdiga områden som är produkter av genvägar man tog en gång i tiden? Begreppet teknisk skuld är något som används flitigt inom mjukvaruvärlden och är något som gäckar de flesta utvecklingsteam. Fritt översatt från den engelska Wikipedia-artikeln så definieras teknisk skuld som ”indirekt kostnad för det framtida extraarbete som kommer att krävas på grund av att en snabb eller enkel kortsiktig lösning har valts över att göra uppgiften på rätt sätt”. Teknisk skuld kan uppstå av många anledningar, till exempel:

  • En tvingande deadline där mjukvaran bara måste ut, nästan oavsett skick.
  • En PoC eller tidig prototyp som var så framgångsrik att trycket blev för stort att driftsätta produkten omgående, även om den inte var färdigutvecklad eller ens menad att lanseras (det var ju bara en prototyp…)
  • Ett team som har tagit på sig för många uppgifter parallellt och därmed inte lyckas slutföra någon uppgift hela vägen (precis vad som hände med listerna).
  • Okunskap om att något behöver göras överhuvudtaget eller göras på ett visst sätt. Till exempel kanske det finns en kodstandard på ett företag som inte alla team vet om att de behöver tillämpa.

Varför betala tillbaka skulden?

Det kanske är uppenbart för många, men frågan kan ändå komma att ställas: ”Varför ska vi lägga tid på att åtgärda detta? Det funkar ju som det är nu och det kommer inte ge kunderna något extra värde?”. Vid en första anblick rent kortsiktigt kanske det ser ut så. Men stämmer det verkligen? För att kunna motivera varför det ska läggas tid och pengar på att fixa något som ändå fungerar behöver man lyfta blicken och se det långsiktigt. Ju mer det tekniska skuldberget växer desto svårare blir det att utveckla nya saker och fortsätta vara lättrörlig. För att gå tillbaka till exemplet med renoveringen och listerna så skapar ofärdiga saker onödigt kognitivt brus och suger energi. Det försvårar ju dessutom att ha en hög med lister som ligger i vägen någonstans och tar plats. På samma vis försvårar slarvigt skriven kod utvecklingsarbetet. Den är sannolikt svårare att sätta sig in i, svårare att ändra utan att ha sönder annan funktionalitet eller kräver ändringar på många ställen. Saknas det automatiska tester minskar tryggheten att våga ändra i koden. Saknas dokumentation blir det svårare för nya teammedlemmar att sätta sig in arbetet. En briljant liknelse jag såg drog paralleller mellan teknisk skuld och datorspelet Tetris. Varje hål man lämnar i högen bygger upp skuldberget, och ju högre skuldberget stiger, desto svårare blir det att hänga med när nya bitar kommer och desto högre blir stresspåslaget.

Hur kan man arbeta med teknisk skuld?

Oavsett hur den tekniska skulden uppstår behövs det en strategi för hur den ska hanteras, eller för att följa liknelsen, betalas tillbaka. Jag kommer nedan att diskutera några olika angreppssätt för att antingen förebygga att skulden uppstår eller hur den kan hanteras när den väl är ett faktum.

Gör det ordentligt från början

Det låter ju uppenbart och lite sådär idealistiskt klämkäckt, men så långt det är möjligt är det i de flesta fall ändå bäst att försöka göra saker på rätt sätt från början. Att skaffa sig mer teknisk skuld bör vara ett undantag, ett kort som bara spelas i speciella situationer. Det är väldigt lätt att detta sätts i vana annars och att skuldberget sakta smyger uppåt. Det medför dessutom en extra kostnad att behöva återbesöka ett område längre fram i tiden jämfört med att fixa det på en gång, när allt finns färskt i huvudet.

Det ska dock tilläggas att denna princip kompliceras av idéerna om att få snabb återkoppling från kunden via så kallade Proof of Concepts, Minimal Viable Products och experiment via A/B-testning. Vad är rätt ambitionsnivå när man inte vet om funktionen kommer att kastas eller behållas?

Kom överens om en Definition of Done

För att kunna göra saker ordentligt från början kan det ju underlätta om det finns en gemensam förståelse för vad det innebär. Ett team som inte har kommit överens om en Definition of Done, det vill säga ett slags kontrakt på vad ”klar” egentligen betyder, riskerar att hamna i ständiga diskussioner och missförstånd om en specifik uppgift är klar eller inte. Det blir väldigt lätt att man börjar ta tag i nya saker istället för att göra det allra sista och slutföra den förra saken (listerna återigen). Det är också lätt att missförstå varandra och börja prata om att något är klart när det inte är testat än, inte är dokumenterat än, och så vidare. Med en tydlig definition på vad klar egentligen betyder blir det lättare att undvika fällorna att uppgifter blir halvklara, eller att fel saker kommuniceras till produktägare eller andra intressenter.

Kommunicera tydligt när teknisk skuld adderas

I de lägen man väljer att addera till sin tekniska skuld bör detta kommuniceras tydligt, både inom teamet och till externa intressenter: ”Vi gör medvetet detta avsteg nu, men vi kommer att åtgärda det inom kort för det är ingen hållbar lösning långsiktigt”. På detta vis kommer det inte som en överraskning längre fram för någon, och ibland kanske det budskapet faktiskt medför att uppgiften får ta lite längre tid och göras rätt från början.

Koppla ihop teknisk skuld och affärsnytta

Det är inte alltid så lätt att få prioritet på uppgifter som berör teknisk skuld då affärsnyttan inte alltid är uppenbar, och det är lätt att frestelsen att lägga till ny spännande funktionalitet vinner över det förnuftiga att fixa något för att förbättra förutsättningarna långsiktigt. För att få gehör för denna typ av arbete kan det vara bra att försöka översätta behovet till verksamhets- eller affärsspråk. Det vill säga, om vi inte gör om koden i det här området kommer vi framtiden att minska vår kapacitet att leverera värde till våra kunder. Det kan vara svårt att komma med konkreta siffror på vad varje del av skulden innebär i ökat underhåll. Däremot så är det mer görbart att hålla koll på andelen tid som läggs på buggfixning, felsökning och annat som inte har med leverans av värde till kunden att göra. Om denna tid ökar gradvis är det en kraftfull signal att den tekniska skulden behöver minskas.

Dokumentera den tekniska skulden

Teknisk skuld som inte dokumenteras i någon form glöms lätt bort eller förträngs medvetet. Ett strukturerat angreppssätt värt att prova är att införa en teknisk skuld-backlogg som med fördel huserar i samma verktyg som används i det dagliga utvecklingsarbetet (till exempel Jira, TFS eller ReqTest). Vinsten med detta är bland annat att det går det lätt att länka till de utvecklingsartefakter som den tekniska skulden härstammar ifrån, och på så sätt får man en spårbarhet av händelseförloppet. 

Arbeta strukturerat med avbetalningarna

I vissa sammanhang jag verkat i har teamen strukturerat avsatt tid för att betala tillbaka den tekniska skulden. Ibland har någon teammedlem fått dedikerad tid under en tidsbegränsad period och ibland har jag sett Scrum-team regelbundet köra förvaltningssprintar där allt fokus ligger på den tekniska skulden. Att införliva den tekniska skulden i arbetssättet på detta vis kan ha sina fördelar i att saker regelbundet förbättras och inte glöms bort. Men det finns också en risk i att man lättare väljer att öka sin tekniska skuld, just för att ”det där kan vi fixa i en framtida förvaltningssprint”. Så det är ett tveeggat svärd.

Slutord

I rollen som testare och i andra kvalitetsrelaterade roller blir diskussioner om teknisk skuld ofta något du behöver blanda dig i. Inte minst för att det ofta kan bli saker som testbarhet, automatiska tester eller dokumentation som riskerar att drabbas när det går för fort framåt. Förhoppningsvis har du fått med dig ett och annat tips från artikeln som kan hjälpa dig angripa ämnet i ditt sammanhang. Om inget annat så kanske du ser till att göra ett rum i taget och få upp listerna på en gång nästa gång du renoverar.

Dela artikeln