Designprosess

Standard metodikk for interaksjonsdesign må komme i tillegg til scrum dersom man ønsker gode resultater

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

Utforsk ulike konsept før du binder deg til en rettning.

Utforsk ulike konsept før du starter å gå i en rettning. Det er bedre å snu tidlig enn å snu sent.

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.

Skisse

Skisser er raskere å lage enn kode og er en viktig del av utviklingen.

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.
    Snakk sammen om skissene
  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.
Stem denne posten nedStem denne posten opp (+41 rating, 12 votes)
Loading ... Loading ...

5 kommentarer


Aleksander Dragnes
7. september 2009
kl. 14:37

Scrum er en mye misforstått tilnærming til programvareutviklingsprosessen.

Gjermund har rett i at et av de grunnleggende prinsippene er at det ikke skal gå lang tid fra man setter igang med design av noe til det er ferdig utviklet, men det kan ta mer enn en uke, gjerne opp til en måned. En utviklingssprint omfatter heller ikke akseptanse og produksjonssetting.

Et annet prinsipp i Scrum er at teamene skal være tverrfaglige. Det er rom for en brukeropplevelesspesialist på et team. Riktignok må hun finne seg i å gjøre mer enn bare arbeid med brukeropplevelse.

Jeg skulle tro at det går greit å levere et par sider med god brukeropplevelse for et team med en brukeropplevelsespesialist i løpet av en måneds tid.


Lars G. Teigen
7. september 2009
kl. 14:57

Design må ikke nødvendigvis være noe som skjer i forkant av en sprint. Man trenger selvfølgelig noen hovedføringer – et businesscase og et løsningsrom/konsept før man kan definere en product backlog, men så snart dette er på plass kan man begynne å designe de ulike casene i backloggen.

Designprosesser kan kjøres iterativt i et SCRUM regime. Hovedspørsmålet er kanskje om noen iterasjoner kun skal levere design, prototyper, spesifikasjoner (eller andre dimensjoner som prosjektet baseres på), mens man i andre iterasjoner kjører design og utvikling av konkrete funksjoner tett integrert i samme sprint.


Martin Gjesdal
7. september 2009
kl. 23:42

Kjempebra artikkel. Skal i gang å lage en portal ved hjelp av Scrum og dette var nyttig input. For meg ser det ut til at det er mest kritisk på hvilket tidspunkt utviklerne skal involveres. Når de først er i gang, tenker jeg at mye av spesifiseringsarbeidet allerede er unnagjort og resten av utviklingen kan skje via Scrum hvor man han har en brukeropplevelsesspesialist eller to på hvert team.

Skriv gjerne mer om dette! :)


Jose Redondo
9. september 2009
kl. 08:54

Veldig interessant artikkel. Midt i blinken ift foredraget jeg skal kjøre imorgen på webdagene om hvordan man kan bruke scrum eller smidige metoder i kreative prosesser hvor jeg selvfølgelig inkluderer brukeropplevelse som en viktig del av det.


Svein Ølnes
9. september 2009
kl. 15:40

Så sant, så sant. Utan å ha detaljkunnskapar om metoden, er eg skeptisk til ideen om å isolera utviklarar/programmerarar frå andre delar av utviklingsteamet, slik eg opplever blir gjort. Det er som du er inne på, for stort fokus på fart (alle sprintane som skal utførast), men om det blir sprinta i feil retning, hjelper det lite om det går fort.

Ei meir heilheitleg tilnærming til utviklingsprosessen er viktig, saman med enkle hjelpemiddel (les: blyant og papir) i starten.

Gi oss din kommentar

eller