(Den ubehagelige?) Sannheten om brukerhistorier

(Den ubehagelige?) Sannheten om brukerhistorier

Brukerhistorier har seilt opp som en etterhvert ganske vanlig måte å beskrive krav på. Digitale løsninger er i dag sterkt integrert i våre daglige liv, selv om vi etter manges meninger så vidt har begynt å skrape i overflaten av hvor dette vil utvikle seg videre.  

Uansett, språket vi benytter for å beskrive de ønskede egenskapene på disse digitale løsningene har forvandlet og utviklet seg side-om-side med systemene språket ønsker å beskrive. I så måte har språket blitt bedre på å beskrive den forventede interaksjonen mellom menneske og maskin som eksisterer i sin samtid.

Dette er noe brukerhistorier funger bra til. Brukerhistorier setter tross alt fokus på brukeren og det er absolutt et bra verktøy til nettopp dette. Hvorfor kan jeg da velge å titulere en bloggpost med et hint om at det finnes noe mer med brukerhistorier enn du kanskje er klar over?

Brutt ned, og noe forenklet oppleves det slik:

  1. Brukerhistorier blir betraktet som krav. Dette er bare delvis sant. 
  2. Det store fokuset på formatet på brukerhistorier skjuler verktøyets virkelige styrker. 
  3. Hensikten med brukerhistorier er ofte dårlig forklart, både innad i det tekniske miljøet og ut mot bestiller-siden av bordet.

Bestilling av software er vanskelig

Å definere krav til software er vanskelig. Det er vanskelig uansett hvilket verktøy man velger å bruke. Det består av rigide matematiske konsepter som stadig skal settes sammen til nye «symfonier». Software skal omsette noens tanker og følelser, til noe som for mange er uhåndgripelig. Det skal hjelpe og begeistre, og det skal være til nytte og til glede. Ikke rart dette er vanskelig å kommunisere mellom mennesker. I tillegg kompliseres utfordringen gjerne ytterligere ved for eksempel at bestillingen gjøres av noen som ikke kan så mye om softwareutvikling, eller som tror de kan det. Eller, så vet kanskje ikke bestilleren egentlig hva han eller hun ønsker å løse, og mangler et vokabular for å si akkurat det.

Bestilling av software er vanskelig! Aldri tro noe annet. Brukerhistorier vil ikke løse at det er vanskelig. Brukerhistorier er en av flere muligheter for å håndtere at det er vanskelig. Et verktøy altså, for å tilby en mulighet i en gitt situasjon.

Utviklingen av brukerhistorier

Skal vi forstå hvordan brukerhistorier kan hjelpe oss å håndtere denne vanskelighetsgraden, må vi gå noen steg tilbake og forstå hvor brukerhistorier kommer fra.

Brukerhistorier har sin opprinnelse fra XP-miljøet tilbake på 90-tallet. Den gangen var det vanligere med store allvitende dokumenter. Dokumentene "hadde tenkt på alt", kunne refereres til for alt og hadde svar på alle spørsmål - selveste kravdokumentasjonen. Hvor denne teknikken kommer fra får være en historie for en annen dag. Uansett, så viser det seg at slike store kravdokumenter ikke ser ut til å fungere spesielt bra for komplekse IT-systemer. Flere og flere i, og rundt, det såkalte XP-miljøet hadde altså sett dette, og eksperimenterte med andre måter å takle bestilling av software på. Ut fra dette kom bl.a. det som senere skulle utvikle seg til å bli brukerhistorier slik vi kjenner det i dag.

I 1999 slapp Kent Beck boken “Extreme Programming Explained: Embrace Change”. Her ble det for første gang beskrevet at det var anbefalt å stykke opp bestillingen og håndtere den på en mer muntlig og uformell stil, istedenfor å skrive enorme kravdokumenter på forhånd. På den tiden var dette kjent i XP-miljøet (som Beck var en del av), men det hadde ikke blitt formalisert i en fagbok tidligere.

The Three C-formula: Card, Conversation, Confirmation

En kan anta at ideen ble sett på som radikal (og har man vært i IT-bransjen en stund, så vet man at enkelte opplever slike tanker som radikalt selv den dag i dag), men den hadde tiltrekningskraft på en del kloke hoder. En av disse var Ron Jeffries, som et par år senere, i 2001, sto for «The Three C-formula» for å fange essensen i en brukerhistorie. Altså et notat (card), gjerne en post-it lapp, som kort beskriver historien. Samtale (Conversation), som holdes på ulike tidspunkt og ulike steder mellom interessenter som berøres av en gitt funksjon. Og til sist konfirmasjon (Conformation) på at det som ble diskutert i samtalene er oppnådd. Sistnevnte skal helst være formelt og etterprøvbart.

Card

Dette notatet Jeffries beskriver, er nettopp det: et notat. Når en benytter seg av brukerhistorier som verktøy, fremfor f.eks. use cases eller andre lettvektverktøy i dette domenet, er grunnen at verktøyet legger til rette for å sette brukerbehov i førersetet for behovskartlegging og kravbestilling. Notatet, eller tittelen om du vil, bør reflektere dette; altså å inkludere hvem sitt behov du skal dekke med akkurat denne brukerhistorien, og hva dette behovet er. Det er imidlertid ingen lov som sier at du må gjøre det. Et notat / en tittel kan også endres underveis, og bør kanskje det, i det vi beveger oss over i Conversation.

Conversation

Jeffries gjorde et poeng av at samtaler holdes på ulike tidspunkt, på ulike steder og mellom ulike interessenter som berøres av en det du prøver å beskrive. Det er dette som er gullet i brukerhistorie-verktøyet da det er her verdien du leter etter skapes. Samtaler, formelle og uformelle, er hvor problemer diskuteres, løsninger utformes og engasjement skapes. Så fort du har notert ned en brukerhistorie, bør du søke å skape en diskusjon rundt brukerhistorien. Du bør snakke med en brukertype som representerer brukeren i historien din, andre produkteiere, utviklere, testere, UX’ere, UI’ere, kundeansvarlig, sjefen din og teknisk ansvarlig. For hver interessent du snakker med, øker du din kunnskap om behov, løsning og mulighet. Det kan hende dere allerede har snakket med deres brukerrepresentant. Hvis ikke, er det kanskje på tide? Du bør snakke med dataanalytikeren din, for å finne brukermønstre og trender i ditt eget produkt du kanskje ikke kjenner til ennå.

Er det slik hos dere at det sitter én person og dikterer ned brukerhistorie med de vakreste «Som bruker ønsker jeg at»-setninger? Hvor blir det da av diskusjonene, eller verifikasjonene?

Er det slik at brukerhistorier ofte blir diskutert opp og ned i mente når de er lagt inn i en sprint eller lignende? Da er det isåfall noe feil. En brukerhistorie kan godt være gjenstand for diskusjon og endring i en sprint, men dette bør begrenses. Det meste bør være på plass og diskusjonen om hvorfor, og om, bør definitivt være over.

Enhver organisasjon må finne sin egen vei for behovskartlegging og det finnes mange gode verktøy for akkurat dette. Uansett hvordan den veien er eller blir til, er det ved behovskartlegging og kravstilling smart å stille seg sprøsmålet: er det dere som ønsker at brukeren ønsker seg dette, eller er det faktisk en verdi her?

Confirmation

Dette kan kanskje kalles akseptansekriterier på godt norsk. Det er resultatet av samtalene dine. Dette er hvordan behovet brukerhistorien forsøker å beskrive, skal dekkes. Akseptansekriterier bør være formelt, men det bør ikke være teknisk. F.eks. «Jeg skal kunne logge meg inn med brukernavn og passord» er formelt og ikke-teknisk. Det samme er «Jeg skal også kunne logge meg inn med Facebook». Disse er etterprøvbare og kan automatiseres. Akseptansekriterier blir for teknisk nå du f.eks. begynner å definere design, systemarkitektur, valg av teknologi, etc. Da har du beveget deg utenfor virkeområdet til verktøyet, brukerhistorier. Når det gjelder design, har du UI- og UX-ekspertise i teamet ditt og de har andre verktøy til å løse dette. Valg av teknologi og rammeverk har du arkitekter og annet teknisk personell til å håndtere. Du bør holde deg til hva brukeren bryr seg om, som er "Å logge inn", i eksemplet ovenfor.

«Som … ønsker jeg … slik at …»-formatet

Hvor kommer dette «Som … ønsker jeg … slik at …» fra? I følge beskrivelsen av brukerhistorier på Wikipedia, dukket dette også opp rundt 2001. Siden har det utviklet seg i mange forskjellige varianter. Noen sier at en helst skal si «For å … som … ønsker jeg …». Andre hevder at det rette er «Som <persona>, vil jeg …, så at …». Jeg leste for litt siden om noe de kalte Job Stories, som endrer litt på det hele og har formatet «Når … vil jeg … slik at …». En evolusjon av brukerhistorier kanskje, men jeg vil fortsatt kalle det en brukerhistorie.

Det finnes neppe et fasitsvar på dette. I all beskjedenhet vil jeg heller påstå at tittelformatet ikke spiller noen rolle. Vil du droppe hele formatet og finne ditt eget? Ikke noe problem! Vil du bare gi kravbeskrivelsen et nick-name, f.eks. innlogging. Kjør på, hvis det funker for deg, teamet ditt og organisasjonen din!

Det ser ut til at mange har glemt at det er innholdet som teller. Du får ikke bedre software ved å ha den beste «Som … ønsker jeg at …»-setningen. Misforstå meg rett, det er ikke noe galt med dette formatet (personlig er jeg veldig glad i å bruke det selv), men dens eneste hensikt er å minne deg på at det er en jobb som skal gjøres. Det er et notat. En tittel. Det er ikke der du henter verdien i verktøyet brukerhistorier. Brukerhistorier handler om samtaler og diskusjoner.

Konklusjon

Jeg hevdet tidligere at det bare er delvis sant at brukerhistorier skal betraktes som krav. Ja, du kan vel kanskje kalle akseptansekriteriene dine for krav om du vil, men som det er skrevet over; det er ikke her verdien ligger. Akseptansekriteriene, som for øvrig er et mer innbydende navn enn krav, er utledet og formalisert av de historiene, du og dine kollegaer, kunder og brukere har konversert om, som er det virkelige poenget med brukerhistorier. En brukerhistorie blir derfor noe levende, som vil endre form og farge over tid. Det er erkjennelsen av dette som gjør at jeg også kan hevde at tittelformat ikke er så viktig som enkelte tilsynelatende skal ha det til fra tid til annen.

Jeg ga også en påstand om at hensikten med brukerhistorier ikke er godt nok forstått. Jeg har for så vidt ingen empiri på dette, men det er mer en følelse jeg sitter med. Uansett, jeg håper og tror at dere som har tatt bryet med å lese hele dette innlegget har lært litt mer om verktøyet brukerhistorier. Og folkens: øvelse gjør mester!

Kilder:

 

Om bloggeren:
Andreas trives i det vanskelige mellomsjiktet mellom IT og Forretning. Han har over ti år i IT-bransjen, som utvikler, arkitekt og de senere år i roller som Scrum Master, Product Owner, prosjektledelse etc. Han er en innovativ person med stor lidenskap for IT og dens betydning i samfunnet.

comments powered by Disqus