Teknisk gjeld - hvor mye er forsvarlig? Per Otto Bergum Christensen, Objectdesign 27 August, Smidig fagdag i SPK Om meg Per Otto Bergum Christensen Siv.ing, Datateknikk, NTNU Senior konsulent, Objectdesign Tre siste prosjekter: Statens Pensjonskasse, JEE Arkitekt Statens Vegvesen, JEE Arkitekt/ScrumMaster Aetat, JEE Arkitekt/Teamleder Objectdesign Hva er Teknisk gjeld? Objectdesign Hva er teknisk gjeld? Metafor etablert av Ward Cunningham i 1992 Ward Cunningham sammenligner det å ta “snarveier” ved utvikling som det å ta opp lån i banken Opptak av teknisk gjeld gir raskere utviklingstid på kort sikt, men krever renter i form av lavere framtidig effektivitet Objectdesign Hvordan etableres Teknisk gjeld? Valg av løsninger som gir merkostnad på medium/lang sikt Manglende fokus på design av løsning Utsatt testing, kompetansedeling, dokumentasjonsarbeid Kode som ikke følger retningslinjene til organisasjonen Fokus på produksjon som langt overgår fokus på innovasjon Og så videre.. . Objectdesign Teknisk gjeld kategorisert Uforsiktig Forsiktig “Vi har ikke tid til design” Bevisst “Vi må levere nå og leve med konsekvensene” Ubevisst “Hva er lagdeling?” “Nå vet vi hvordan vi skulle gjort det” http://www.martinfowler.com/bliki/TechnicalDebtQuadrant.html Objectdesign Fordel ved teknisk gjeld Fordel ved Teknisk gjeld “Time to market” Leveranser som ikke tærer for hardt på startkapitalen Rask tilbakemelding fra brukere på løsning og konsept Verifikasjon av ny teknologi, arkitektur, design, etc Objectdesign Ulempe ved teknisk gjeld Ulempe ved teknisk gjeld Gjeldsrenter spiser av budsjettet for ny funksjonalitet Gjeldsrenter kan øke kost på feilretting, overlevering & drift 100% 75% 50% 25% 0% Release 1 Release 2 Renter av teknisk gjeld Release 3 Release 4 Release 5 Tilgjengelig for ny funksjonalitet Objectdesign Hvor mye teknisk gjeld er forsvarlig? Objectdesign Eksempel #1 “store lån” Objectdesign Oppgave for en Leverandør Lag en applikasjon med knapp deadline Applikasjonen skal støtte en mengde produkter med tilhørende beregninger, samt lagring av produktporteføljen Budsjett er låst til 1000t Objectdesign Utfordring: max 1000t 150t 350t Graftegning Skjermbilder Beregnings motor 400t 500t Database Objectdesign Løsning 500t Database “Sterkt forenklet design” Database 100t Objectdesign Resultat Løsningen ble levert “On Time, on Budget” Løsningen må omskrives for å støtte standard databasefunksjonalitet Teknisk gjeld = 50% av initielt budsjett Renter: Databasespørringer koster 10x av en standard implementasjon og må lages som batch-applikasjoner Objectdesign Eksempel #2 “et potensielt lite lån, av mange.. .” Objectdesign Vanlig utfordring for et Scrum team Modul A “Good Stuff” Modul B Uplanlagt oppgave: Modul B trenger “Good stuff” fra modul A, men en regel sier at B ikke kan avhenge av A Objectdesign Løsningsforslag I Modul B Modul A 30t “Good Stuff” Trekk ut “Good stuff” og la A og B avhenge av denne Objectdesign Løsningsforslag II Modul A “Good Stuff” 2min Modul B Bryt regelen om at Modul B ikke kan avhenge Modul A og sett opp en avhengighet likevel Objectdesign Løsningsforslag III Modul A “Good Stuff” 2min Modul B “Good Stuff” Kopier “Good stuff” fra A til B Objectdesign Resultat av løsningsforslagene I. 30 timer uplanlagt vil “ødelegge” iterasjonen for teamet Teknisk gjeld = 0t II. En feil avhengighet vil kreve ekstra arbeid framover Teknisk gjeld = 30t + Opprydning av “kompenserende løsninger” Renter = Ekstraarbeid med kompenserende løsninger for feil avhengighet III. En kopi vil kreve ekstra arbeid framover Teknisk gjeld = 30t + Fjerning av kopi Renter = Dobbeltarbeid knyttet til feil og endringer Objectdesign Det er ikke hvor men mye, hvordan som er viktig. Objectdesign Regel nr 1: Ikke ta opp små lån Store enkeltlån er bedre enn mange små Totalt rente på små lån er langt høyere enn på store lån Små lån er ofte ikke forankret hos kunden Små lån bør nedbetales raskt, f.eks påfølgende iterasjon Objectdesign Regel nr 2: Vær forsiktig Uforsiktig Forsiktig Ikke alt som kan tenkes å gi raskere utviklingshastighet er smart Konsekvensen av en snarvei bør være kjent før den velges Objectdesign Regel nr 3: Vær metodisk Etabler brukerhistorier på produktkøen for nedbetaling av bevisst teknisk gjeld Bevisst Ubevisst Utnytt retrospektiver for å identifisere teknisk gjeld som har blitt etablert ubevisst Objectdesign Regel nr 4: Vær åpen Teknisk gjeld vil tynge de som kommer “etterpå” 100% 75% 50% 25% 0% Release 5 Release 6 Release 7 Renter av teknisk gjeld Release 8 Release 9 Tilgjengelig for ny funksjonalitet Release 10 Objectdesign Takk for meg! Objectdesign