Flere ledende konsulenthus prøver å få kundene over på den såkalte «smidige» modellen for programvareutviklingen, kanskje bedre kjent gjennom den engelske betegnelsen «agile».
Les også:
- [11.09.2009] Slik kan «smidighet» skaleres
- [22.08.2008] Nå bør du bli Scrum-master
- [12.06.2006] Smidig utfordring til «databasefolket»
- [13.09.2005] Ny metode fenger utviklere
I forrige uke var en av «agilistenes» fremste talspersoner, kanadieren Scott Ambler, invitert til Norge av Bouvet for å tale den smidige utviklingsmodellens sak. Ambler er forfatter er flere bøker om emnet – blant titlene er Agile Modeling, Agile Database Techniques og Managing Agile Projects – og tok seg tid til en prat med digi.no.
Ambler setter den smidige metoden opp mot det han vekselvis kaller «den serielle metoden» og metoden med «Big Requirements Up Front» («BRUF»).
BRUF er det alle kjenner: Kunden bruker en måneds tid på å mane fram sine drømmer (les «kravspesifikasjoner»); konsulenten noterer flittig, trekker seg tilbake, og tolv måneder seinere presenterer gårsdagens løsning på gårsdagens problem. Bouvet bruker betegnelsen «vannfallsmetoden», og sier de sliter med å få kombinert lønnsomhet og fornøyde kunder når innkjøpsprosessen i offentlig sektor er utformet etter vannfallsmetoden.
Den smidige metoden går ut på å dele utviklingsprosessen i korte etapper med kontinuerlig kundekontroll.
Kunde og konsulent blir enig om å starte med det viktigste, og bryte det ned i noe som kan realiseres i løpet av for eksempel et par tre kvartaler. Dette brytes igjen ned i underetapper der resultatene presenteres for kunden for diskusjon, endring og godkjenning før man går videre til neste. Når noe er avansert nok til å settes i produksjon, går man videre til neste etappe.
– Det viktigste poenget med dette, er at det er direkte lønnsomt, sier Ambler, og trekker fram to kurver der verdi, det utviklingen trekker av ressurser minus det applikasjonen leverer, måles mot tid.
Her er kostnadene for «Big Requirements Up Front»: Det tar 16 måneder før applikasjonen begynner å skape verdier, og 26 måneder før den har levert mer enn det kostet å utvikle den.
Her er kostnadene for samme prosjektet realisert gjennom den smidige metoden. Applikasjonen er delt opp i tre leveranser, henholdsvis R1, R2 og R3. Hele leveransen tar like lang tid, 16 måneder, men kostnadsbildet er vesentlig forskjellig:
Etappe R1 kan settes i produksjon etter åtte måneder, så følger R2 fire måneder etter det igjen. Applikasjonen begynner altså å levere verdi allerede etter åtte måneder, og to måneder før den siste etappen, R3, settes i produksjon, har applikasjonen tjent inn alle sine utviklingskostnader.
– Det er en stor fordel ved den smidige metoden, som denne sammenlikningen ikke avdekker, understreker Ambler. – Det er at jeg, utvikleren, straks får vite fra kunden om jeg gjør en god jobb eller ikke.
Det Ambler mener med dette, er at den kontinuerlige vekselvirkningen mellom utvikler og kunde, og det konstante fokuset på at man først leverer det man trenger mest, innebærer at applikasjonen ikke belemres med funksjonalitet man ikke trenger.
Dette er et viktig poeng: Ambler viser til en undersøkelse gjort av Standish Group (se artikkelen Examining the «Big Requirements Up Front (BRUF) Approach») av vellykkede serielle prosjekter. Den viser at 45 prosent av funksjonaliteten i de vellykkede prosjektene gjennomført etter denne metoden, aldri ble brukt.
– I tillegg kommer 19 prosent som sjeldent brukes: Vi må anta at noe av dette er bortkastet. Og tallene er optimistiske, fordi undersøkelsen stiller ikke det utfyllende spørsmålet: Hva er det du trenger, men som ikke ble levert? Med den smidige metoden får man korreksjoner underveis, og man unngår både å levere ting som ikke trengs, og å unnlate å levere det det er behov for. Det gir kort sagt bedre kvalitet.
Og den reelle verdien, ifølge Ambler, er enda høyere enn det som går fram av de direkte kostnadssammenlikningene ovenfor.
– Noen sier «45 prosent bortkastet er ikke så ille». Andre sier «Da gjør vi det bedre, vi har målt den overflødige funksjonaliteten til 35 prosent, og det synes vi er ganske bra». Tenk på det! 35 prosent av det man bruker kostbare ressurser på, er bortkastet, og enda synes man det er helt i orden. Dette er et eksempel på en situasjon man stadig opplever innen IT: Rommet er fullt av elefanter, men det er forbudt å snakke om det, og alle forholder seg tause.
Det er brukernes holdning som er hovedproblemet, mener Ambler.
– Brukerne har latt seg lære opp til å følge den serielle prosessen. Alle «vet» at det ikke er tillatt å komme i ettertid for å endre på kravspesifikasjonene, noe som for øvrig er tøv, det skyldes at IT-folk selv skyr endringer og gjør alt de kan for å hindre dem. Men følgen av dette er at kundene gjør alt de kan for å fylle opp med spesifikasjoner i forkant. Mange av de funksjonene som aldri tas i bruk kan føres tilbake til dette.
Ambler innrømmer at han ikke kjenner til forskning rundt dette forholdet. Men han er likevel sikker i sin sak.
– Løsningen er enkel: Kutt ut de store kravspesifikasjonene. Slutt å følge reglene som myndighetene pålegger. Se heller på kravspesifikasjonene som en prioritert liste. Å gå videre med prosjektet innebærer å trekke én måneds arbeid fra toppen av listen.
Bivirkningene av denne alternative – smidige – metoden er heldige for alle.
– Brukerne får det de trenger, ikke det de spesifiserer. De har kontroll over budsjettet: Å trekke en måneds arbeid fra prioriteringslisten er som å trekke et fast antall betalte konsulenttimer. Når vi har brukt opp timene, skal vi vise hva vi har gjort. Det tvinger oss, utviklerne, til å gjøre jobben får. Vi leverer programvare som virker. Og det er det eneste resultatet et utviklingsprosjekt skal levere.
I stedet for panisk overspesifisering, og masse uønsket funksjonalitet etter mange lange måneder, oppnår kunden kontroll over utviklingsprosjektets budsjett, omfang og framgang.
– Kunde kan betale for prosjektet så lenge de vil. De kan behandle sin IT-investering som nettopp det, en investering. Leverer utviklerne bra arbeid, lar du dem fortsette. Gjør de en dårlig jobb, kan de holde pengene tilbake. Du opplever aldri å bli stilt overfor noe stort og kostbart som du i praksis ikke kan si nei til.
Ambler mener å ha lang erfaring for at det er vanskelig å si nei til noe du i praksis allerede har betalt mange millioner for. For en vanlig norsk observatør, er det vanskelig å ikke si seg enig.
