Martin Koksrud Bekkelund

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

Generelt