Scrum – utviklerens revansje? av Glen Farley
Publisert i ComputerWorld Norge, 27. mars 2009. Glen har bedt meg om å legge artikkelen ut her sånn at den blir tilgjengelig på Internett.
Innmarsjen av smidige utviklingsmetoder er et svar på reelle problemer med tradisjonelle, tungvinte utviklings- og prosjektmetoder. Det er også det siste i en lang rekke av forsøk fra utviklere til å ta tilbake kontroll over utviklingsprosessen. Flere generasjoner av utviklere har kjempet imot prosesser, dokumenter og verktøy som de mener kveler kreativitet og fleksibilitet i programmering – det som virkelig skaper verdien i programvare. Som en Scrum-entusiast satte det på spissen nylig på Software 2009 – “All process is overhead.”
Utviklingsmetoder og verktøy har kommet og gått men kampen mellom “struktur” og “kreativitet” har rast i lang tid.
Da jeg begynt som utvikler på stormaskiner sent på 70-tallet var den første gyldne tidsalder allerede på vei ut. Akt én begynt med utviklere kledd i hvite frakker bak lukkede dører, som drysset automasjon over sine takknemlige og for det meste helt uforstående brukere. Etter hvert ble utviklerne dyttet av scenen av blant annet systemanalytikere, dataarkitekter, testledere, m. fl. Innføring av “strukturerte metoder” nådde sitt “høydepunkt” med produkter som genererte programkode fra diagrammer – utviklere skulle utryddes.
Akt to kom på 80-tallet da pc-er dukket opp. Da kunne utviklere herje fritt igjen – alle strukturer og prosesser fra stormaskinsalderen var midlertidig borte på den nye “frontier” hvor en mye større brukermasse måtte igjen trygle utviklerne direkte om funksjonalitet. Men snart ble det litt for mye spaghettikode, for mange systemer som ikke snakket så godt sammen, masse feil og sprukne budsjetter. Så begynt “strukturfascister” å forbedre og bygge ut utviklingsprosessen igjen.
På slutten av 90-tallet kom akt tre og en ny smak av frihet og status for utviklere – Internett. På den tiden hadde jeg gått over til “the dark side” og blitt til prosjektleder. I 1997-99 opplevde jeg flere ganger godt voksne bedriftsledere i mørk dress som lyttet trollbundet til noen-og-tyve-årige utviklere i t-skjorter, som beskrev hvordan HTML og web’en skulle forandre verden og de som ikke skaffet seg et nettsted kunne regne med konkurs. Alle gamle konsulentfirmaer og programvarehuset ble tatt på sengen og kappet om å ansette de nye talenter. “Cowboy”-utvikling var nå “web-enabled” og hele verdens befolkning var nå mulige brukere. Etterhvert ble webapplikasjoner mer komplisert og krav til brukervennlighet, lønnsomhet og kvalitet økte. Snart måtte utviklere dele prosessen med en ny generasjon av strukturister og ikke-utviklere, Denne gangen med titler som interaksjonsdesigner, informasjonsarkitekter og grafisk designer. Disse folkene ville definere i detalj hvordan applikasjoner skulle fungere og derfor fjernet de mer og mer av kreativiteten og innovasjon fra utviklerens hverdag. Det som muligens provoserte utviklerne mest, var at mange av de nye fagfolkene påstod at de nå representerte brukerne. Og vi prosjektledere var fortsatt tilstede med våre prosesser, statusrapporter og tidsplaner og vi påstod at vi representerte systemeier. Mange utviklere følte at det nå var alt for mange lag mellom dem og deres kunder. Til tross for all den nye strukturen, gikk utviklingsprosjekter fortsatt ofte over budsjett, applikasjoner var vanskelig å vedlikehold og krav var enten uklare eller i varig endring. Konkurransefortrinn, særlig på web, forduftet etter måneder istedenfor år, og produkter måtte derfor defineres og utvikles enda raskere. Gamle endringshåndtering- og rapporteringsprosesser skapte mer og mer konflikt og avstand mellom prosjektet og eier. Så kom smidige prosesser for å løse disse problemene. De overordnet prinsipper var skrevet ned i den berømt “Manifesto for Agile Software Development” i 2001 og signert av 17 karer (kvinner er fortsatt underrepresentert i utvikling, men det er et annet tema.) Alle hadde, ikke overraskende, utviklingsbakgrunn.
Smidige prosesser prøver å skjære bort alt som ikke bidrar direkte til å skape de mest verdifulle funksjoner, omfavner endring gjennom hyppige omprioriteringer av hva som skal bygges og skifter ansvar for utvikling tilbake til et utviklingsteam, dog denne gangen, en tverrfaglig gruppe hvor brukerne og produkteier også er sterk involvert. Prosjektlederen er byttet ut med en Scrum master som fasiliterer prosessen og fjerner hindringer, men ikke styrer det selvdrevne teamet. Mange mener at Scrum øker produktivitet og engasjementet i utviklingsprosjekter. Det finnes ennå begrenset forskning rundt Scrum, men erfaringen viser at Scrum, som alle tilnærminger, fungerer bra i noen tilfeller og dårlig i andre. Suksess med Scrum forutsetter blant annet selvdrevne, kompetente og fleksible teammedlemmer, beslutningsdyktige og fleksible prosjekteiere, og et høyt nivå av tillitt. Scrum fungerer best når den suppleres med noen leveranser fra tradisjonell prosjektledelse, for eksempel overordnet risikostyring og kommunikasjonsplanlegging og må passe på å ta hensyn til øvrige krav i en organisasjon rundt arkitektur og vedlikehold. Scrum oppfordrer teammedlemmer til “å tenke sjæl.” Dette må inkludere å tilpasse selve Scrum og graden av struktur til hver enkel prosjektkontekst, uten å kvele den fleksibilitet og engasjementet som kjennetegner mange smidige prosjekter.
Smidige utviklingsprosesser var og er et svar på reelle problemer med tradisjonelle, tungvinte utviklings- og prosjektmetoder, men de er også en reaksjon på at utviklerne hadde mistet grepet, igjen, på utviklingsprosessen.
Glen Farley har jobbet som utvikler, prosjektleder, ScrumMaster og direktør. farley@online.no
Posted on 2009.05.27 at 8:17
Comments are off for this post.