I forrige artikkel snakket vi om sikkerhetsgjeld og hvordan man unngår å bli en gjeldsslave. Å betale ned økende gjeld hindrer gjelden i å løpe løpsk, men den langsiktige løsningen for å håndtere sikkerhetsgjeld mener vi er å jobbe mer bærekraftig.
Vi skal i denne artikkelen se nærmere på hvordan bærekraftig produktutvikling kan se ut og til slutt gi fire konkrete tips til hvordan man unngår uansvarlig produktutvikling.
Ikke gjort opp sikkerhetsgjelden din? - Uansvarlig! mener disse utviklerne
Dette må ligge til bunns
Vi fortsetter å melde at man må slutte med IT-prosjekter hvor det går i store leveranser, urealistiske og rigide tidsplaner, detaljert ressursplanlegging og tids- og kostnadsestimater. Vi må bli smidigere nå!
Her har man dårlige forutsetninger for å raskt omstille seg dersom det måtte komme endringer i prioriteringer og omstendighetene rundt det man lager. Å jobbe produktfokusert i et tverrfaglig autonomt team gir derimot teamet fart, fokus og rask omstillingsevne.
Økende grad av sikkerhetshendelser og sikkerhetsgjeld er enda flere argumenter for at vi må jobbe smidigere med sikkerhet, og takle raske omprioriteringer med fokus og spisskompetanse.
«En kraftig økning i cyberangrep de siste årene tilsier at uansvarlig produktutvikling er et høyrisikospill»
Bærekraft er lik rett balanse
På prioriteringsvektskålen hvor man allerede har teknisk gjeld og ny funksjonalitet, må man nå i tillegg plassere sikkerhetsgjeld og balansere dette opp mot hverandre.
– Derfor har omstillingsevnen aldri vært viktigere enn nå.
Bente Hoff, avdelingsdirektør i NSM, sa januar 2022 til NRK:
Vi hadde en tredobling i alvorlige dataangrep fra 2019 til 2020. Den utviklingen fortsatte med en økning også i 2021.
En kraftig økning i cyberangrep de siste årene tilsier at uansvarlig produktutvikling er et høyrisikospill.
Når vi jobber bærekraftig med produktutvikling i autonome og tverrfaglige team, hvor teamet kontinuerlig jobber med teknisk gjeld, sikkerhetsgjeld og ny funksjonalitet, får vi den balansen i vedlikehold og den omstillingsevnen som disse tider krever.
Men hvordan vet du at ditt produkt har for høy sikkerhetsgjeld? Hvilke symptomer kan man se etter? Hvilke tiltak kan man innføre for å betale ned gjelden?
Og klarer vi å sikte mot bærekraftig produktutvikling?
Du vet hva teknisk gjeld er. Men har du hørt om sikkerhetsgjeld?
#1. Du holder fortsatt på med IT-prosjekter
Leveransefokus skaper falske frister som fører til stress for å nå fristene. IT-prosjektet leverer funksjonalitet i henhold til det som er bestilt. Og prosjektteamet legger fra seg arbeidet når leveransen er ferdig overlevert, puster ut og starter på nye oppgaver.
Bygg tverrfaglige og autonome produktteam!
En gruppe tverrfaglige personer samlet rundt et produkt eller domene, får autonomitet via et tydelig mandat og fokus. Ved å jevnlig prioritere oppgaver sammen med en produkteier som ivaretar forretningsperspektivet, så vil man raskere kunne svare på behov, prioritere og levere verdi.
Tips: spill teamene gode ved å bygge DevOps-verktøystøtte for kontinuerlige leveranser, og sørg for at de leverer mange små endringer jevnlig enn få og store.
Teknikker som for eksempel funksjonsbrytere lar deg lansere uferdig funksjonalitet, og man kan dermed innhente tilbakemeldinger med ekte brukere når bryteren er påslått. Slik vil man risikostyre bedre både risiko for, og konsekvenser av, at feil skjer. I tillegg leverer man verdi mer målrettet og behovsprøvd!
«Dyrk derfor heller en kultur hvor produktteamet har et tydelig ansvar og eierskap til det de lager og jobber på en bærekraftig måte»
#2. Vedlikehold overlates til andre
Interne overleveringskultur til egne forvaltere skaper skille mellom de som utvikler og de som driver vedlikehold.
Vedlikehold i seg selv er ofte ikke spennende nok, dermed jobber utviklerteamet heller med spennende nyutvikling enn å prioritere vedlikehold som gjerne overlates til egne forvalterne.
Bygg en kultur med eierskap til det man lager!
Unngå overleveringer mellom personer og team — sørg istedet for at produktteamet har en overlapp i kalendertid med personen som besitter kompetansen man ønsker å tilegne seg.
Dyrk derfor heller en kultur hvor produktteamet har et tydelig ansvar og eierskap til det de lager og jobber på en bærekraftig måte. Når man selv må stå opp på natten for å fikse den litt for raske endringen på tampen av arbeidsdagen, så reflekterer man litt ekstra neste gangen man "skal bare". Nå er det ditt problem i stedet for de på forvaltning.
Tips: ha en vedlikeholdsdag i uken der man jobber med teknisk gjeld (Kaizen-dag! Hack-day!).
Men ikke glem sikkerhetsgjeld også da. Kanskje arrangere en hack-deg-selv-dag i ny og ne?
- Slutt med Java, start med Kotlin! ber Vegard, som mener Java er teknisk gjeld
#3. Man kaller digitale produkter for "ferdig levert" og skifter fokus
Det nye stjerneproduktet får all oppmerksomhet og nye sårbarheter i eksisterende produktportefølje går uoppdaget hen.
Ingen overvåker eller kjenner ansvar for produktet som tidligere ble erklært for "ferdig" og som det ikke skal jobbes mer med. Alle pengene er investert i det nye stjerneproduktet.
Bærekraftig produktutvikling i hele produktporteføljen!
En portefølje med digitale produkter og tjenester trenger jevnlig prioritering av vedlikehold opp mot ny funksjonalitet på tvers av hele porteføljen.
Alle produktteamene i porteføljen må jobbe bærekraftig.
Tips: sørg for gjøre jevnlig sårbarhetsskanning på kode slik at man kan raskt oppdatere de produktene man har ansvaret for. Dermed holder man det svakeste leddet i porteføljen "i sjakk", og gir trusselaktørene en dør mindre å komme inn igjennom.
«Uansett om man måler eller ikke bør man holde hele verdikjeden varm ved å gjøre flere små og ufarlige endringer jevnlig»
#4. Det som bare "er der" og som ingen tør å ta i
Bitrot er et begrep for data som råtner over tid. Det samme kan sies om tekniske løsninger som har ligget så lenge at de har råtnet på rot.
Verktøy for å kompilere, testmiljø, integrasjoner, utviklingsverktøy osv. har sluttet å fungere fordi ingen har vedlikeholdt verdikjeden til løsningen man lagde
Med andre ord er den tekniske gjelden direkte synlig. Man har antageligvis høy sikkerhetsgjeld attpåtil.
Hold verdikjeden "varm" (nok)!
Forsøk en data-drevet tilnærming hvor en måler tid siden forrige produksjonssetting eller hvor lang tid man har hatt kjente sårbarheter i produksjon, og sett grenseverdier som trigger handling av teamet.
Uansett om man måler eller ikke bør man holde hele verdikjeden varm ved å gjøre flere små og ufarlige endringer jevnlig. Ved å jevnlig oppdatere produktet sørger man for å holde hele verdikjeden i bruk samt beholde kompetansen i teamet for å jobbe med produktet. Det kommer godt med den dagen en kritisk sårbarhet blir oppdaget og man må handle raskt.
log4shell-sårbarheten som ble kjent i november 2021 traff bredt og rammet mange da det biblioteket var en avhengighet både direkte og indirekte hos mange, og da merket man hvor lett eller vanskelig det var å oppdatere produktene sine. Det ble en viktig vekker.
Tips: "vedlikeholdsdagen" er en fin dag i uken å gjøre gjøre oppdateringer på. Bruk verktøy som varsler om oppdateringer, som for eksempel Dependabot.
Håvard har tre enkle regler for en vedlikeholdbar kode: - Dette er viktig!
Balanser gjeld opp mot ny funksjonalitet
Sørg for at teamet balanserer teknisk gjeld og sikkerhetsgjeld opp mot ny funksjonalitet, og kan gjøre dette på en bærekraftig måte hvor man unngår å brenne lyset i begge ender.
Unngå uansvarlig produktutvikling ved å avdekke sikkerhetsgjelden du har, og håndter sikkerhetsgjelden du har igjen på en bærekraftig og smidig måte.
I neste artikkel skal vi se nærmere på hvorfor man bør ha en sikkerhetsutvikler i teamet, og hvorfor vi mener denne rollen er essensiell i hvordan man bør jobbe tverrfaglig og smidig med sikkerhet.