De aller fleste av oss har vel etterhvert blitt ganske godt kjent med brukerhistorier på formatet:
Som Rolle ønsker jeg Funksjonalitet slik at jeg kan oppnå Mål
Dette er et aldeles supert format for å konkretisere behov — Beskrivelsen er direkte, kortfattet og oppfordrer deg til å begrense omfanget til noe som er mulig å estimere og utvikle. Problemet i mange av dagens prosjekter er at dette benyttes som hele spesifikasjonen. Verktøy som Jira og Azure DevOps hjelper ikke til her da de optimaliserer arbeidsflyten for å minimere menneskelig interaksjon og samhandling.
Helt siden dagene med eXtreme Programming (‘XP’ som er forløperen til alle dagens smidigmetodikker) rundt årtusenskiftet var forutsetningen at en brukerhistorie er utgangspunktet for en diskusjon rundt krav og implementasjon, ikke sluttproduktet som kan benyttes som det fulle og hele utgangspunktet for utvikling.
I XP var ikke dette et reelt problem siden hele forutsetningen for metoden var at behovshaver og utvikler satt sammen og utformet produktet i fellesskap. I dagens ‘smidige’ utviklingsløp er dette etter min erfaring sjelden tilfelle.
La oss ta et litt mer konkret eksempel:
Som saksbehandler ønskjer jeg systemstøtte for å vurdere omfanget av tiltaket som behandles slik at videre behandling har et korrekt bilde av saken.
Dette kan implementeres ganske enkelt i retning av:
Da kan man vurdere omfanget og systemet støtter at man lagrer vurderingen. Problem løst.
Eller kanskje brukeren ikke egentlig var så veldig opptatt av bare lagringen? Kanskje ønsket var noe mer i retning av:
Her har systemet gått gjennom variable i saken som skal behandles og skalert til en felles skala fra 1-10, kanskje til og med sammenlignet med tilsvarende saker, slik at jeg som saksbehandler umiddelbart kan vurdere omfanget av saken.
I det første tilfellet betyr systemstøtte “systemet er i stand til å lagre informasjon om”, i det andre tilfellet betyr det samme ordet “systemet gir meg hjelp og støtte til å gjøre en bedre jobb”. Personlig har jeg sett utallige tilfeller av at personer i samme prosjekt mener det er helt unødvendig å diskutere et så enkelt ord som ‘systemstøtte’ og samtidig har totalt forskjellig oppfatning av hva ordet betyr.
Slik smidig utvikling fungerte i XP var ikke det et problem – alle involverte i prosjektet satt i samme rom, og hvis man lurte på noe kunne man bare snu på hodet og bli enige om hva man skulle lage. I dagens større prosjekter med “Scrum-of-Scrum-of-Scrums” der man har egne fagteam som kanskje sitter i en annen verdensdel og lager brukerhistoriene er det ikke like enkelt.
Derfor er det viktig at man faktisk gjennomfører den diskusjonen som en brukerhistorie er ment å avstedkomme.
Nøyaktig hvordan man fremtvinger og gjennomfører en slik diskusjon er underordnet, men min personlige favoritt er å benytte planning poker. Planning poker er en utbredt estimeringsmetode i flere varianter av smidigmetodikk, men vi tar en liten repetisjon:
Utviklingsteamet sitter fortrinnsvis rundt et bord og går gjennom brukerhistorier. Ved hver brukerhistorie har man en “budrunde” der utviklerne byr på omfang av oppgaven ved hjelp av kort. Det finnes online varianter, men personlig foretrekker jeg fysiske kort om mulig. Det er viktig at man viser kortene samtidig slik at den enkeltes budgiving ikke blir påvirket av andre. I vårt tilfelle kan dette se ut som:
Kortene følger Fibonacci sekvensen slik at avstanden mellom budene blir større ettersom budene vokser slik at usikkerheten illustreres. Dersom det er signifikant avstand mellom budene – i dette tilfellet 2 og 13 betyr det at man ikke har samme oppfattning av oppgavens omfang. og man diskuterer hva som faktisk skal gjøres før man repeterer budrunden, forhåpentligvis med et mer samstemt resultat.
La oss ta et eksempel igjen:
Som beboer ønsker jeg nytt gulv slik at jeg slipper fliser i føttene:
Her har den ene snekkeren estimert legging av sponplater som tar 4 timer mens den andre utvikleren tenker at det må ganske mye mer til. For å oppnå enighet så. kan eksempelvis produkteier/beboer/behovshaver informere om at nei, vi trenger ikke fiskebensparkett og vi er ganske sikre på at vi ikke har asbest i det gulvet, så asbestsanering trenger vi heller ikke. Resultatet blir et tall som ligger et sted mellom de to opprinnelige, men hovedgevinsten her er at alle er enige om hva som skal gjøres. (mange foretrekker relativ estimering med story- points eller liknende, jeg har ingen sterke preferanser, men erfaring tilsier at utviklere ofte har en ganske god formening om hvor mye man får gjort på en time)
Det er jo riktig fint, men erfaring tilsier at dette heller ikke alltid virker. Ofte kommer utviklerne med besnærende like estimater, slik at man ikke trenger noen diskusjon og så drar de av gårde og lager noe annet enn det behovshaver egentlig hadde ment. I et riktig ille scenario så oppdages ikke det før man har rullet ut i produksjon og man får skuffede og oppgitte brukere.
Derfor er det viktig at produkteier/behovshaver/fagside eller lignende er med i budrunden. Grunnen til at det ofte ikke er tilfellet er at “men produkteier har ikke nok kunnskap om programmering til at han kan gi et meningsfylt bud”.
- Hvis du har fungert som produkteier i mer enn 17 sekunder så vil jeg tro at du faktisk har litt erfaring i hvor lang tid ting tar.
- Du har i hvert fall garantert en mening om dette er en stor eller liten sak. Ingen produkteier jeg har truffet ville estimert de to variantene av “systemstøtte for omfangsvurdering” over til samme verdi
Denne artikkelen er skrevet av Richard Rostad i Promis Qualify