Nærbilde av fingre på data-tastatur, med gruppe mennesker uskarpt i bakgrunnen
KRONIKK
For ikke så lenge siden var det "opplest og vedtatt" at IT-systemer utvikles best i små, samlokaliserte team. Men nå har også gitantprosjekter med hell brukt utviklingsmetoder som var tiltenkt små, samlokaliserte team. Artikkelforfatteren har vært med på å klarlegge hvilke tilpasninger Goliat har gjort for å lykkes med Davids resept. Illustrasjonsfoto: ijeab/Thinkstock

Oppblåsbar digital vinnerformel

Kronikk publisert 31.07.17
Publisert også i Dagens Næringsliv

Store norske IT-prosjekter er beviset på at også elefanter kan være smidige. Ny studie viser hva hemmeligheten er.

Når Norge skal digitaliseres, trengs kunnskap om effektiv organisering av IT-prosjekter. «Smidig utvikling» – å spesifisere, utvikle og teste nye IT-systemer bitvis – ble en vinnerformel ved årtusenskiftet. Ifølge læreboken passer den best til små prosjekt. Men i Norge gjør metoden i dag suksess også i gigantprosjekter. Nå har ny norsk forskning vist hva slags tilpasninger som gjør Davids resept anvendbar for Goliat.

De siste 35 årene har snudd opp ned på oppskriftene for gode IT-prosjekter. Her hjemme publiserte SINTEF en håndbok på feltet i 1982. Den anbefalte utviklerne å spesifisere alle krav til et nytt system og så beskrive tekniske valgene, før de gikk i gang med programmering og til slutt testing.

På 90-tallet sprakk imidlertid mange IT-prosjekt på tid og kostnad. En undersøkelse blant prosjektledere konkluderte med at den største risikoen var knyttet til kundens mandat og brukernes manglende medvirkning. Problemet var at brukerne fikk løsninger de ikke ville ha, når systemene endelig var ferdige.

Manifest for smidig utvkling

Som et svar formulerte bransjefolk i 2001 et manifest for smidig utvikling som la vekt på tett brukerinvolvering og hyppige leveranser. Samtidig ble det «opplest og vedtatt» at IT-systemer utvikles best i små, samlokaliserte team. Men de siste ti årene har vist at metoder for smidig utvikling lar seg tilpasse slik at de fungerer også i store prosjekter. Noen av de første bevisene på dette kom i Norge.

Bakteppet er metoder for programvareutvikling som ble til i kjølvannet av manifestet fra 2001. Mest kjent er metoden «Scrum» som gir brukerne mulighet til å omprioritere krav underveis og få demonstrert en enkel første versjon av produktet etter bare noen uker.

Goliat apet etter David

Mange av utfordringene fra 90-årene ble løst med de nye metodene. Inspirert av at disse funger bra for små team, tok bransjen her hjemme i bruk metoder som Scrum også i store utviklingsprosjekter.

I SINTEF var vi nysgjerrige på hva som skjer når metoder tiltenkt små, samlokaliserte team settes inn i prosjekter som kan involvere titalls team og hundrevis av utviklere, prosjektledere og kunderepresentanter.

Derfor grep vi sjansen, da vi med støtte fra Forskningsrådet fikk studere hvordan Statens Pensjonskasse organiserte utviklingen av et stort system til å håndtere pensjonsreformen. Hvilke tilpasninger ville prosjektets omfang tvinge frem i den smidige praksisen som ble valgt?

800 000 arbeidstimer

Funnene har vi publisert internasjonalt. Modellen forvaltningsbedriften brukte, har inspirert mange av de store IT-prosjektene i Norge. Den skiller seg vesentlig fra anbefalinger fra praktikere internasjonalt. Den avviker også fra modeller som er valgt i store prosjekt hos internasjonale giganter som Ericsson i Sverige og Finland og i store prosjekt i USA.

Prosjektet involverte opptil 175 personer. Samlet la de ned 800.000 arbeidstimer og leverte hele 12 versjoner av det nye systemet, med mer og mer funksjonalitet, på fire år. Modellen de brukte, kjennetegnes ved at:

Her er oppskriften

* Design-valg ble tatt tidlig for å tilrettelegge for mange parallelle utviklingsteam. Egne roller på teamnivå sikret kommunikasjon mellom teamene og et eget arkitekturprosjekt.

* Hele 30 brukerrepresentanter ble involvert for å sikre at riktig funksjonalitet ble utviklet. Det var rom for omprioritering. Men på grunn av prosjektets størrelse ble behov beskrevet mer detaljert enn det som anbefales for smidige praksiser.

* Så mye som 14 koordineringsarenaer ble brukt, langt flere enn det vi finner i studier av andre prosjekt og i råd fra praktikere. Arenaene endret seg over tid.

I den nylig publiserte artikkelen konkluderer vi med at resultatet ble en velfungerende modell for utvikling i store IT-prosjekter. Lenge var 12 utviklingsteam i gang samtidig. Likevel ble det mulig å ta viktige tekniske beslutninger, involvere brukere og få til god koordinering på tvers av team og delprosjekt.

Arbeidsmetodene vi beskriver er relevante også for annet kunnskapsarbeid. Spesielt innenfor prosjektledelse er det stor interesse for grepene IT-bransjen har tatt.


Forskningen

  • Hvem: Torgeir Dingsøyr, Nils Brede Moe, Tor Erlend Fægri og Eva Amdahl Seim, alle Sintef.
  • Hva: Exploring software development at the very large-scale: a revelatory case study and research agenda for agile method adaptation
  • Hvor: Empirical Software Engineering, pp. 1-31, 2017. Se: http://rdcu.be/tcT3


Artikkelen sto første gang i Dagens Næringsliv lørdag 29. juli 2017 og gjengis her med DNs tillatelse.