XP2020 2. dag: Teknisk gæld i agil udvikling

Anbefaling af bogen om teknisk gæld

Tirsdag startede med konferencens hovedtaler Philippe Kruchten’s key note om teknisk gæld i agil udvikling. Key noten vil være hovedemnet her.

Konferencens Key Note om teknisk gæld i agil udvikling

Konferencens hovedtaler var Philippe Kruchten, som talte om myter og realiteter om teknisk gæld i IT-udvikling. Måske et lidt sjovt emne taget i betragtning af at det er en konference om agil teori, metoder, tilgange og praksis. Foredraget argumenterede dog for at man IKKE er immun over for teknisk gæld, selvom man arbejder agilt. Det er åbenbart en af myterne om teknisk gæld – altså at agile tilgange forhindrer dette.  Det var ikke en key note jeg havde glædet mig til, men den lukkede sig op og blev meget spændende. Kruchtens slides kan ses her.

Phillippe Kruchten

Phillippe Kruchten har været med meget længe. Hvis man går på Google er hans første publikation fra 1910, men det er nu nok en fejl. Han ledede den gruppe ved Rational Software, der udarbejdede the ”Rational Unified Process” udfra arbejde af Ivar Jacobsen, Jim Rumbaugh og Grady Booch.  Nogen husker måske bogen  The unified software development process  (1999, Addison-wesley.) ? Kruchten er mest kendt for The 4+1 View Model of architecture der knytter sig til beskrivelsesmetodernei RUP.

Nå det er egentlig sagen uvedkomende og blev slet ikke nævnt i foredraget, men jeg nævner for at sætte Kruchten ”på kortet”.

Teknisk gæld

Teknisk gæld er den ekstra udgift til rework, der stammer fra at vælge en ”nem” (delvis /kortsigtet) løsning nu i stedet for en bedre og mere langsigtet løsning. Hvis ikke der tages hånd om gælden, kan den ”trække renter” og blive meget dyrere at ordne senere. Ofte er teknisk gæld blevet sammenlignet med boliglån, men i modsætning hertil, slog Kruchen fast, behøver man ikke altid ”betale” den tekniske gæld. Teknisk gæld kan være både positivt, hvis den ikke gør skade (så har man da sparet de penge) og negativ hvis den f.eks. forhindrer en i eller væsentlig fordyrer nyudvikling man gerne vil foretage.  MCConnell (2013) skiver ”betaler du ikke enter er det nok ikke en gæld”.

Desværre er teknisk gæld ikke synlig og meget svær at måle. Der er forsket meget hvordan man identificerer og måle denne gæld, uden den store afklaring. Det er simpelthen svært. Kruchen foreslog at det heller ikke er nyttigt, da effekten af gælden i forhold til fremtidige behov og muligheder er det vigtige – ikke størrelsen af gælden i sig selv. Der er udviklet en del værktøjer til at analysere og identificere teknisk gæld der stammer fra koden, men den dyreste gæld er den arkitektoniske gæld. Vi kender dem alle sammen: minimal viable product der blev hængende, arkitektur deadlocks, mangel på indkapsling mm.

Teknisk gæld i den agile verden

En stor del af de agile slagord peger direkte på det positive i praksis, der skaber et teknisk product der kan indeholde meget teknisk gæld. ”Udskyd beslutninger så længe som muligt”. “YAGNI” = You Ain’tGonnaNeed It–Men når du gør så er det teknisk gæld. Det er ofte gentagne gange af YAGNI der ophober teknisk gæld. Nogen siger endda ”vi er stadig agile fordi vi ikke er ramt af teknisk gæld” og Kruchen tilføjede – ”endnu”.

Problemet kan vel karakteriseres med “ude af øje – ude af sind”. Man mister nemt indsigten i og overblikket over hvilke gældsætninger man har gjort over tid gennem agil udvikling, hvilket gør det svært at vedblive at udvikle hurtigt og til tiden, da gælden gør koden unødigt kompleks og forhindrer yderligere ”gældsætning”. Man må til at betale af på gælden.

Kruchen foreslår selvfølgelig at man overvåger og leder ens tekniske gæld bevidst og fremadrettet. Og måske særligt at gøre dette når man arbejder agilt. Herefter flød foredraget over af gode råd som jeg ikke fangede ret mange af. Et par eksempler på de mere håndfaste er: at kategorisere issues som gæld, når de er det, at at markere potentiel gæld i kodens kommentarer og angive hvor akut refactoring er, samt altid at planlægge at afbetale noget gæld i hver iteration.

Phillipe Kruchten har skrevet en bog om emnet, som kan anbefales.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *