Både norske og internasjonale aktører i it-bransjen advarer mot slurv i bruk av såkalt smidig prosjektmetode, som blir stadig mer populær.
Her er spesielt Scrum nærmest blitt erklært som det endelige svaret på hvordan it-prosjektene skal komme i mål.
Prinsippet er at nye systemer bygges gradvis opp ved at det hele tiden utvikles nye funksjoner med korte mellomrom. Tradisjonelle metoder går ut på å fullføre utviklingen av et komplett system før det overleveres.
Les mer:
Fotfeste
It-leverandørene har jobbet hardt de siste årene for å overbevise kunder om at dette er den rette måten å jobbe på for å ha kontroll med kostnadene og at de nye løsningene faktisk fungerer etter hensikten.
Og denne smidige løsningen har begynt å få fotfeste siden den startet som en protest mot de trege, tradisjonelle metodene, som krever bunkevis med dokumentasjon for hvert skritt. og massiv innsats på papiret før noe faktisk leveres.
Glemmer arkitekturen
– Men dette går ofte utover kvaliteten på arbeidet. Fokus på hyppige leveranser fører til at man glemmer helhetsbildet i form av en grunnleggende arkitektur med elementer som sikkerhet og muligheter til å skalere opp en løsning, advarer programmerer Simon Brown.
It-arkitekten fra Jersey i England er sterk tilhenger av smidige metoder, men har kunnet gjøre det til halvt levebrød å lære opp it-leverandører og kunder i hvilke feller man skal unngå.
Går svært galt
– Hvorfor har bransjen havnet i denne situasjonen?
– Fordi man ønsker å være kjappe og effektive. Smidig metode handler i utgangspunktet om å gjøre veien til mens man går, inkludert arkitekturen. Det kan fungere, men andre ganger fungerer det overhodet ikke. Da kan det gå galt. Og når det først skjer, kan det gå svært galt, svarer Brown.
Konsekvensene er ofte forsinkelser, dårligere kvalitet og masse ekstra arbeid på slutten av prosjektet. Mye av hensikten med de smidige metodene var nettopp å unngå dette.
Forklaringsproblem
Konsulentselskapet Bouvet deler Browns erfaringer, men i praksis kan det være vanskelig å gå mer detaljert til verks.
– Vi ser at software engineering som grunnleggende håndverk havner i bakgrunnen. Det kan henge sammen med at både dette og it-arkitektur ikke er fremtredende i utdanningen lenger. Og når kundene har snappet opp at Scrum betyr raske leveranser, kan det være vanskelig å forklare dem at slike investeringer må tas i starten, sier avdelingsdirektør for utvikling, Simen Sommerfeldt.
Password
Simon Browns kroneksempel på hastverk er fra et større it-selskap som han ikke våger å navngi. Det bestilte nye nettsider fra en ekstern leverandør, og det hele ble gjort i beste radikale scrum-stil: Rask utviklingstakt med minimalt arkitekturarbeid og tynn dokumentasjon.
– De fikk hele tiden små deler som fungerte hver for seg, men til slutt satt kunden med nettbaserte tjenester som ikke hadde nok kapasitet og et system som var ganske enkelt å hacke seg inn i. Blant annet var passordet satt til «password», illustrerer Brown.
Konkurrentene underbyr
Bouvet har hyret inn Brown til å skolere norske kunder om behovet for systemutvikling, og spesielt arkitektur.
– Utfordringen handler en del om økonomi. Hvis vi legger inn tilbud på en kontrakt, bruker vi gjerne Scrum, men baker en porsjon solid arkitektur og en viss mengde dokumentasjon inn i prisen. Her kan konkurrenter droppe dette og underby oss - uten at det bryter med kravene i tilbudsforespørselen, forklarer Sommerfeldt.
Gammelt og nytt
Løsningen er å få en systematisk innblanding av tradisjonelle metoder i de smidige.
– Både rapporter og styringsgrupper kan være på sin plass, selv om et lag med utviklere samarbeider tett og godt med oppdragsgiver. Og i bunn må det ligge en software design som viser hvor man skal, sier Sommerfeldt.
Knut Dischington var tidligere prosjektleder for Eress-prosjektet hos Jernbaneverket. Eress avregner strømforbruk på togene i stadig flere europeiske togselskap.
Les mer:
Ville gått galt
Han legger ikke skjul på at ting ville ha gått galt hvis man ikke hadde mikset gammelt og nytt tankegods.
– Her ønsket oppdragsgiveren å benytte tradisjonell prosjektmetode, der vi snekret ferdig alt før løsningen ble levert. Heldigvis gikk de gikk med på å arbeide «smidig», med tett samarbeid, hyppige leveranser og mulighet for å teste funksjonene underveis. Ut fra kravene til løsningen var det likevel avgjørende at vi etablerte en skikkelig arkitektur i forkant, spesielt med hensyn til endringer i regelverk og skaleringsbehov. Tradisjonelle metoder ville ha feilet, men det ville også scrum ha gjort uten de nødvendige innsmett fra tradisjonelle metoder, sier Dischington.
