Programvareutviklingens natur

Når vi skal bestemme oss for hvordan vi angriper problemløsning kan det være en fordel å forstå seg på de særegenhetene som gjelder for det området vi skal inn på. Mange disipliner er gamle og godt kjente og man har mengder av empiri som forteller hvordan det lønner seg å jobbe. Og innenfor veldig mange ingeniørdisipliner finner vi ganske detaljerte forskrifter og regelverk som skal sikre høy kvalitet. Dette finner vi ikke for programvare, både fordi faget er ganske nytt, men også fordi det er for komplekst til at det finnes riktige svar. Jeg mener programvare har en rekke særegenheter som gjør overføringsverdien fra andre disipliner svært liten.
 
Det er nok først og fremst historiske årsaker til at vi vanligvis angriper programvareutvikling med tradisjonelle prosjektstyringsmetoder. Vi drar med oss erfaringer fra samlebåndet, fra andre ingeniørdisipliner og prosjektstyringsfaget. Er dette en god idé?
 

7 typiske særtrekk for programvareutvikling

1. Vi kan velge å levere i små inkrementer

I motsetning til fysiske produkter, kan programvare kuttes opp i småbiter og leveres en for en. Vi kan også i stor grad velge hvilken rekkefølge vi leverer disse i. Vi har disse valgene, men det betyr ikke at det nødvendigvis ligger til rette for det. Mange har store hindringer, bygget opp over tid, som må overvinnes for å klare å levere små inkrementer.

2. Selve produktet er i praksis usynlig

Selve produktet er beskrevet med kodelinjer. Svært få er i stand til å forstå tilstanden på slik kildekode. Er dette “god” kode eller ikke? Dette aktualiserer spørsmålet: Hvordan skal kunden kunne forvisse seg om at hun får “høy kvalitet” – når kvaliteten er gjemt inne i uforståelige kodelinjer?

3. Løsningsrommet er nærmest uendelig

Om du setter 100 programmerere til å løse det samme problemet, vil du få 100 ulike løsninger. Det er en ekstrem frihetsgrad, sammenlignet med de fleste andre ingeniørdisipliner.

4. Nytt hver gang; innovasjon er en opplagt del av jobben

Vi bruker programvare for å løse nye problemer. Hvis det er løst før forsøker vi å bruke andres løsninger. Hverdagen til utviklere er at de må finne løsningen når de står oppe i den. Og man oppdager stadig at i samtaler mellom utviklere og brukere genereres det ideer som man ikke hadde tenkt på før.

5. Stor kompleksitet

Det er lite grad av repeterbarhet i programvareutvikling. Alle omgivelser er litt ulike, rammebetingelser varierer, brukere er mennesker (komplekse vesener) og det er dynamikk. Teamene som lager programvare er også i høy grad komplekse sosiale systemer med flyktig kausalitet. Vi vet at ytelsen kan variere voldsomt mellom individer – og antageligvis enda mer mellom team.

6. Dynamikk

Krav og behov vil endre seg mens vi gjør jobben. Dette varierer selvsagt med typen systemer vi snakker om, men trenden er klar overalt – det blir mer og mer dynamikk. Dynamikken kan også komme av av vi finner bedre løsninger enn vi hadde sett for oss i starten, samt at det i skjæringspunktet mellom utviklere og brukere oppstår en positiv kreativitet.

7. Livsløpskonstnaden avgjøres av vedlikeholdsvennligheten

Hvor mye det koster å gjøre én endring i programvaresystemer varierer med 10-er potenser. I godt strukturerte, vedlikeholdsvennlige systemer med innebygde tester, vil en endring trygt kunne gjennomføres på minutter. I komplekse, monolittiske systemer uten automatikk, ser vi at enhver endring potensielt får alvorlige bi-effekter slik at vi ikke våger å sette i drift uten at en masse regresjonstester kjøres. En begrenset endring kan da koste dagsverk, kanskje ukesverk. Konsekvens: Det er sub-optimalt å fokusere mye på kostnadene til prosjektet som lager funksjonaliteten. Alle programvaresystemer er mer eller mindre gjenstand for videreutvikling og det initielle prosjektet blir etterhvert en liten andel av totalen. Om dette prosjektet etterlater seg dårlig strukturert kode blir økonomien på sikt dårlig.

Konsekvenser

Så, om vi aksepterer at punktene over gir en riktig virkelighetsforståelse, hvilke konsekvenser har det for vår angrepsmåte? Hvilke modeller for organisering, styring og ledelse er best under slike forhold?
PullVsPush
Hva bør vi velge?
I Pull-systemet gir vi et tverrfaglig team fullmakt til å organisere seg på best mulig måte og å utvikle produktet løpende i tett samarbeid med kunden/brukerne. Teamet prioriterer rekkefølgen i samarbeid med kunden.
I Push-systemet forsøker vi å forstå helheten, legger en plan og jobber med hele produktet hele veien mens vi akkumulerer opp hele produktet til en stor leveranse på slutten. De ulike fasene utføres av ulike spesialister eller roller, mens prosjektleder styrer framdrift iht plan og rammer.
NB: Det er ingen premie for riktig svar!
Tips: Se presentasjonen Unngå Teknisk Gjeld på Slideshare

Leave a Reply