Scrum er ikke tilstrekkelig for å lage gode brukeropplevelser. 5

Det har blitt svært vanlig å kjøre webutviklingsprosjekter som en Scrum-prosess (også kaldt smidig eller agile). Jeg vil anta at det er mange som er inne i ett av de første scrum-prosjektene sine og strever med å finne ut hvordan det gjennomføres på beste mulige måte. Dessverre er det vanlig at man ”glemmer” viktige aspekter ved det å lage gode nettsider i overgangen til scrum.

I innsalg av scrum-metodikken settes den ofte opp mot et tenkt stort softwareutviklingsprosjekt styrt etter vannfallsmetoden. Det er lett å sitte igjen med inntrykket av at det å skrive spesifikasjoner, inkludert alle andre former for planlegging, fra nå av er gammeldags. Dersom man bare setter ned et team til å begynne på kodingen med en gang, og forholde seg smidig til endringer underveis vil alt bli bra. I praksis vil det ikke fungere akkurat på den måten.

Gode webløsninger krever mer enn å produsere kode

Det er nok riktig at det ikke er hensiktsmessig å spesifisere alle tekniske funksjoner i starten av et prosjekt, når man vet minst. Men det nytter heller ikke å løpe av gårde dersom man løper i gal rettning. Jeg mener scrum er en god metodikk for selve arbeidet med teknisk koding. Men det er mange oppgaver rundt det å lage et godt nettsted som ikke er knyttet direkte til det å produsere kodelinjer.  Det kan f.eks. være vel så viktig å finne et konsept som treffer målgruppen, definere hvilke verdier en egentlig ønsker å oppnå med nettstedet, legge strategier for innholdsproduksjon, osv.

Det er ikke nødvendigvis hensiktsmessig å presse alle slike oppgaver inn i en struktur med ukentlige sprinter der målet er å produsere ferdig kode. Begynn heller med noen av disse oppgavene en stund før resten av scrumteamet setter i gang for fullt.

Scrum er raskt, men ikke raskt nok

I scrum går kodingen raskt. På 1-2 uker blir funksjonalitet laget og gjerne publisert. Tanken er at scrumprosessen skjer etter iterasjoner. Ved å teste ut det man har laget, kan man gjøre endringer og lage nye og bedre versjoner. Men i praksis blir det til at man i iterasjonene gjør små justeringer i stedet for å lage helt nye og forbedrede versjoner av funksjonalitet. Etter å ha investert en uke utviklingstid føler man seg tross alt litt budet til å beholde det som er laget.

Det å stadig forbedre nettsider gjennom flere iterasjoner er ikke nytt med scrum. Det er vanskelig å treffe 100% første gangen, så dersom man ønsker å lage virkelig gode nettsider er det nesten nødvendig å prøve og feile noen ganger. Men for at man virkelig skal ha tid og råd til å lage mange versjoner, bør de første versjonene være skisser som bare tar noen minutter å lage. Prototyper kan lages mer eller mindre detaljert avhengig av hilket stadium man er i. Min erfaring er at skisser og enkle prototyper fungerer bra som dokumentasjon i et scrumprosjekt. Det er raskere å produsere prototyper enn kode, og samtidig helt nødvendig for å oppnå høy kvalitet på sluttproduktet raskest mulig.

Dette bør du gjøre før kodingen starter:

1. Skisser løsninger, gjerne raske udetaljerte skisser, og gjerne mange av dem.
2. Snakk sammen om løsningene
   Samle sammen interessenter, diskuter løsningene og velg ut de beste ideene.
   Så lenge man har noe konkret å se på, er det bedre å diskutere løsningen tidlig mens alle muligheter ligger åpne enn i det koden skal skrives.

   

3. Pass på at den informasjonen du har om mål, brukere osv. tas med når løsningene vurderes.
   Vis gjerne løsningene til brukere.
4. Detaljer ut de beste forslagene.
5. Tegn større tegninger og færre av dem. Lag animasjoner eller bruk andre enkle prototypingsteknikker dersom interaksjon er en viktig del av brukeropplevelsen.