Martin Koksrud Bekkelund

Martin Koksrud Bekkelund

Teknologi • Samfunn • Politikk

Smidighetens forbannelse

27.08.13

Smidig produktutvikling av programvare er den foretrukne og for tiden den desidert beste måten vi har for å levere programvare. Det betyr allikevel ikke at smidig produktutvikling er uten fallgruver.

Blant de viktigste argumentene for å benytte smidig produktutvikling finner vi raskere leveranser og redusert risiko. Men stokker man beina feil i smidig produktutvikling, risikerer man å bygge opp teknisk gjeld over tid.

Små funksjoner, kortsiktige mål

Smidig produktutvikling fokuserer som oftest på mål som ligger øverst i prioriteringslisten, eller backlog-en. En slik backlog består som regel av use case som beskriver en avgrenset mengde funksjonalitet. I smidig er det et mål i seg selv at et slikt use case er så avgrenset og lite som mulig. Dette fordi risikoen ved å utvikle noe lite er mindre enn hvis man skal utvikle noe stort. I tillegg er det raskere.

Den lille brikken og det store bildet

Problemet med slik avgrensing er at man risikerer å utelate intensjonen om hvordan denne funksjonaliteten enten inngår i et større bilde, eller hvordan funksjonaliteten skal videreutvikles over tid. I smidig hiver man seg gjerne over oppgaven slik den er beskrevet, uten å se oppgaven i et større perspektiv. Problemet er som oftest å spore i organisasjoner med liten erfaring i smidig produktutvikling.

Uten en stø kurs

Resultatet av smidig produktutvikling tatt til det ekstreme, er at man bryter ned oppgaver i små deler, leverer ofte, når sprinter og kortsiktige mål, men at man risikerer å ende opp med en løsning som er et arkitektonisk lappeteppe og i verste fall oppleves inkonsistent for brukerne. Tenker man ikke langsiktig risikerer man å bygge opp teknisk gjeld i form av en grisete datamodell og dårlig kode, noe det vil ta betydelig tid å utbedre.

Løsningen

Det finnes ingen metode for å unngå problemet. Det krever erfaring. Og erfaring forteller at man skal benytte litt ekstra tid til å diskutere langsiktige konsekvenser og mål når use case utarbeides. Hvordan ser vi for oss at denne funksjonen skal videreutvikles i fremtiden? Er denne funksjonen en del av en større helhet? Bør vi gjøre om på noe annet i koden eller datamodellen som en konsekvens? Ofte kan det være lønnsomt å utarbeide flere use case samtidig, dersom funksjonen inngår i en større helhet, slik at man danner seg et bilde av hvordan funksjonaliteten logisk henger sammen.

Jeg har tidligere lagt frem et notat om hvordan vi arbeider med smidig produktutvikling i Posten. Det skader ikke å trekke det frem igjen. Last det ned, bruk det, del det og kom gjerne med tilbakemeldinger.

Last ned…
PDF • 6,6 MB

Hvor nyttig er denne artikkelen for deg?

Hva kan bli bedre?

Jeg blir veldig glad hvis du legger igjen noen stikkord om hva du tenker!

Generelt

Som leser kan du gi et bidrag til produksjonen, til driften og til å skaffe utstyr til testing for å sikre regelmessige, uavhengige artikler, tester og vurderinger av høy kvalitet.

Gi et bidrag

Husk å abonnere på nyhetsbrevet, det er gratis og du får alle artikler rett i innboksen.

 

Flere artikler

Enda flere artikler? Besøk arkivet.

Om Martin

Martin Koksrud Bekkelund

Dette er Martin Koksrud Bekkelund sitt private nettsted, hvor han skriver om forbrukerteknologi, teknologiledelse og hvordan teknologi, samfunn og politikk påvirker hverandre. Martin er innehaver av konsulentselskapet Nivlheim. Les mer...

 

Mastodon Facebook LinkedIn Thingiverse GitHub Ko-Fi PayPal

© 1995-2024 Martin Koksrud Bekkelund
OpphavsrettRSS og abonnementKontaktPersonvern og informasjonskapsler