Brukerhistorie

Fra Wikipedia, den frie encyklopedi

En brukerhistorie er en naturlig beskrivelse av funksjonen til en programvare sett fra et brukerperspektiv.[1] Det brukes som et verktøy i programvareutvikling for å utforme krav til hvordan programvaren skal fungere fra et brukerperspektiv. De kan for eksempel skrives på papir, Post-it-lapper eller digital programvare.[2] Avhengig av prosjektet kan brukerhistorier skrives av ulike interessenter som en klient, bruker, leder eller et utviklingsteam.

Brukerhistorier er en type grenseobjekt. De fasiliterer meningssøk (engelsk: sensemaking) og kommunkasjon, og kan hjelpe utviklerteamet med å dokumentere sin forståelse av systemet og dets kontekst.[3]

Prinsipp[rediger | rediger kilde]

Brukerhistorier skrives enten av eller for brukere eller kunder for å påvirke funksjonaliteten til systemet som utvikles. I noen lag er den produktansvarlige (eller produkteieren i Scrum) som er primært ansvarlig for å formulere brukerhistorier og organisere dem i en produktkø. I andre lag kan hvem som helst skrive en brukerhistorie. Brukerhistorier kan utvikles gjennom diskusjon med interessenter være basert på personas eller bare funnet på etter eget forgodtbefinnende.

Typiske maler[rediger | rediger kilde]

Brukerhistorier kan lages i flere ulike formater.

Det vanligste oppsettet er Connextra-malen (Connextra template) angitt nedenfor.[4][5] Mike Cohn har foreslått at "slik at"-klausulen er valgfri, men fortsatt ofte er nyttig.[6] 

Som en <rolle> kan jeg <evne>, slik at <motta fordel>

Chris Matts foreslo at å "jakte på verdien" ("hunting the value") var det første steget i å levere programvare, og foreslo følgende alternative mal:[7] 

For å <motta fordel> som en <rolle>, kan jeg <mål/ønske>

En annen mal basert på de store h-ene (hvem, hva, hvortid, hvor, hvorfor) er:[8] 

Som <hvem> <når> <hvor>, vil jeg <hva> fordi <hvorfor>

Eksempler[rediger | rediger kilde]

Screening-quiz (eposhistorie)
"Som HR-leder vil jeg lage en screeningsquiz slik at jeg kan forstå om jeg vil sende mulige kandidater til fagleder".[9]
Quiz-oversikt
Som leder vil jeg bla gjennom mine eksisterende quizer, slik at jeg kan huske hva jeg har og finne ut om jeg kan gjenbruke eller bør oppdatere quizzen for den stillingen jeg trenger å fylle nå.[9]
Begrenset sikkerhetskopiering
Som bruker kan jeg angi hvilke mapper jeg ikke trenger å sikkerhetskopiere, slik at lagringsplassen ikke blir fylt opp med ting jeg ikke trenger.[10]

Bruk[rediger | rediger kilde]

En sentral del av mange smidige utviklingsmetoder, som for eksempel planlegging spillet i ekstrem programmering, er at brukerhistorier beskriver hva som kan bygges i programvareprosjektet. Brukerhistorier prioriteres av kunden (eller produkteieren i Scrum) for å indikere hvilke funksjoner som er viktigst for systemet, og vil deretter bli brutt ned til oppgaver og estimert av utviklerne. En måte å estimere på er via Scrum sin variant av Fibonacci-skalaen.

Når brukerhistorier skal implementeres bør utviklerne ha mulighet til å kommunisere med kunden om det. Korte historier kan være vanskelige å tolke, kan kreve litt bakgrunnskunnskap eller kravene kan ha endret seg siden historien ble skrevet.

Brukerhistorier kan utvides ved å legge til detaljer basert på samtaler med produkteieren. Dette kan omfatte notater, vedlegg og akseptkriterier.

Akseptansekriterier[rediger | rediger kilde]

Mike Cohn definerer akseptkriterier som "notater om hva brukerhistorien må gjøre for at produkteieren skal akseptere det som komplett".[11] Kriteriene definerer grensene for en brukerhistorie, og brukes til å bekrefte når en historie er fullført og fungerer som ønsket.

Den riktige mengden informasjon som skal inkluderes i akseptkriteriene varierer etter lag, program og prosjekt. Noen kan inkludere "forgjengerkriterier" som at "brukeren har allerede logget inn og har allerede redigert informasjonen sin en gang". Noen skriver akseptkriterier i det typisk smidige formatet "gitt-når-da". Andre bruker bare kulepunkter hentet fra krav opprinnelig samlet fra kunder eller interessenter. 

For at en historie skal anses ferdig eller fullført må alle akseptkriterier være oppfylt.

Fordeler[rediger | rediger kilde]

Det er ingen gode bevis på at bruk av brukerhistorier øker programvaresuksess eller utviklerproduktivitet. Brukerhistorier letter imidlertid sensemaking uten unødig problemstrukturering, hvilket er knyttet til suksess.[12]

Begrensninger[rediger | rediger kilde]

Begrensninger med brukerhistorier inkluderer:

  • Oppskaleringsproblem: Brukerhistorier skrevet på små fysiske lapper er vanskelige å vedlikeholde, vanskelig å skalere til store prosjekter og utfordrende for geografisk spredde lag.
  • Vage, uformelle og ufullstendige: Brukerhistorier regnes som samtalestartere. Siden de er uformelle kan de åpne for mange ulike tolkninger. Gjennom å være korte oppgir de ikke alle detaljene som er nødvendige for å implementere en funksjon. Brukerhistorier er derfor upassende som basis for å inngå formelle avtaler eller skrive juridiske kontrakter.[13]
  • Mangel på Ikke-funksjonelle krav: Brukerhistorier inneholder sjelden detaljer om ytelse eller ikke-funksjonelle krav, hvilket medfører at ikke-funksjonelle tester (for eksempel av responstid) kan bli oversett.
  • Representerer ikke nødvendigvis hvordan teknologien må bygges: Siden brukerhistorier ofte skrives er vinklet fra et forretningsperspektiv kan det hende at det teknisk teamet som begynner å implementere finner at tekniske begrensninger krever innsats som er mye bredere enn skopet til en individuell historie. Noen ganger kan det å dele opp en brukerhistorie i flere små bidra til å løse dette, mens andre ganger kan "rene tekniske historier" (technical-only) være mer passende. Disse rene tekniske historiene kan bli utfordret av interessentene på at de ikke leverer verdi som kan demonstreres for kunden eller interessentene.

Sammenligning med epos, temaer og initiativer[rediger | rediger kilde]

I mange sammenhenger blir brukerhistorier både brukt og sortert i grupper av semantiske og organisatoriske årsaker. Bruken avhenger av ståsted, for eksempel om man ser fra et brukerperspektiv som produkteier i forhold til funksjoner, eller fra et bedriftsperspektiv med tanke på organisering av oppgaver.

Eksempel på bruk av et historiekart, med epos på toppen for å strukturere historier.

Mens noen foreslår å bruke "epos" og "temaer" som etiketter for enhver tenkelige form for gruppering av brukerhistorier, har begrepene en tendens til å bli brukt til sterk strukturering og estimering av arbeidsbelastninger. Eksempelvis har programvaren Jira en tilsynelatende hierarkisk organisert gjøreliste hvor det første nivået av gjøremål kalles "user-story", det andre nivået kalles "epics" (gruppering av brukerhistorier ), og det tredje nivået kalles "initiatives" (gruppering av epos). Initiativer er imidlertid ikke alltid til stede i produktutviklingsverktøy, og legger bare til et annet nivå av granularitet. I Jira eksisterer "temaer" (themes) for sporingsformål og gjør det mulig å kryssrelatere og gruppere elementer fra ulike deler av det faste hierarkiet.[14][15]

Under denne bruken endrer Jira betydningen av temaer i et organisasjonsperspektiv (for eksempel hvor mye tid vi brukte på å utvikle temaet "xyz"). Dog er en annen definisjon på temaer at en gruppe med brukerhistorier, epos, funksjoner, osv. utgjør en felles semantisk enhet eller et mål. Det finnes sannsynligvis ikke en felles definisjon fordi ulike tilnærminger finnes for ulike metoder for produktdesign og -utvikling. I denne forstand foreslår noen også å ikke bruke noen form for harde grupper og hierarkier.[16][17][18][19][20][21]

Epos
Store brukerhistorier eller flere brukerhistorier som er nært beslektede kan summeres til et epos. En annen vanlig definisjon på et epos er en brukerhistorie som er for stor for en sprint.
Initiativ
Flere epos eller brukerhistorier som er grupperte sammen hierarkisk. Mest kjent fra Jira.[22]
Temaer
Flere epos eller historier gruppert sammen etter et felles tema eller semantisk forhold.

Størrelse[rediger | rediger kilde]

Vanlige tilnærminger til dimensjonering av brukerhistorier inkluderer:

  • Historiepoeng (story points): Brukerhistorier blir ofte gitt en "størrelse" basert på lagets oppfatning av hvor lang tid den kan ta å levere, og dette gjøres da da ofte ved å tildele et visst antall historiepoeng til historien. Et historiepoeng er en vilkårlig og inkonsekvent indikator på lagets oppfatning av størrelse på et tidspunkt. Poengfordelingen er vanligvis basert på en Fibonacciskala.
  • T-skjortestørrelser: Denne metoden ligner historiepoeng ved at den er basert på lagets mening. Det er en mindre granulær indikator på arbeidets størrelse enn historiepoeng.
  • COSMIC function points: Dette er en 2. generasjons ISO-standardisert funksjonell dimensjoneringmetodikk egnet for smidig programvareutvikling hvor ikke alle krav på forhånd er kjent.
  • IFPUG function points: En 1. generasjons funksjonell dimensjoneringsmetodikk.

Kart over brukerhistorier[rediger | rediger kilde]

Kart over brukerhistorier.

En kart over brukerhistorier eller brukerhistorikart (story map[23]) organiserer brukerhistorier i henhold til en fortellende flyt som presenterer det store bildet av produktet. Teknikken ble utviklet av Jeff Patton fra 2005 til 2014 for å minske risikoen for at prosjekter ble oversvømmet med svært detaljerte brukerhistorier som distraherte fra å realisere produktets hovedmål. 

Under kartlegging av brukerhistorier har man gjerne arbeidsmøter (workshops) sammen med brukere for å identifisere de viktigste aktivitetene til virksomheten.[24] Hver av disse aktivitetene kan involvere flere typer brukere eller "personas".

Linjen for det horisontale tverrgående narrativet trekkes deretter ved å identifisere hovedoppgavene til den enkelte brukeren som er involvert i disse forretningsaktivitetene. Denne horisontale linjen holdes gjennom hele prosjektet. Mer detaljerte brukerhistorier samles inn i tråd med vanlig praksis for brukerhistorier, men hver nye brukerhistorie blir enten satt inn i fortellingsflyten eller relatert vertikalt til en hovedoppgave.

Den horisontale aksen korresponderer med dekningen av produktmålene, og den vertikale aksen til behovene til de enkelte brukerne. På denne måten blir det mulig å beskrive selv store systemer uten å miste det store bildet.

Kart over brukerhistorier kan enkelt gi en todimensjonal grafisk visualisering av produktkøen. Øverst på kartet ser man overskriftene som historiene er grupperte under, vanligvis referert til som "epos" (store grovkornede brukerhistorier), "temaer" (samlinger av relaterte brukerhistorier[25]) eller "aktiviteter". Disse identifiseres ved å orientere seg etter brukerens arbeidsflyt eller den rekkefølgen man ville forklart systemets oppførsel. Vertikalt (under eposene) blir de faktiske brukerhistoriene satt inn og ordnet etter prioritet. Den første horisontale raden er et "vandrende skjelett" (walking skeleton[26]), og de under representerer økende raffinement.[27]

Kart over brukerens reise[rediger | rediger kilde]

Et brukerreisekart[28] (user journey map[29]) har til hensikt å vise det store bildet, men for en enkelt brukerkategori. Dens fortelling fokuserer på kronologi av faser og handlinger som en enkelt bruker må utføre for å oppnå sine mål.

Brukerreisekartet gjør det mulig å kartlegge brukeropplevelsen utover et sett med brukerhistorier. Basert på tilbakemeldinger fra brukerne kan de positive og negative følelsene gjennom hele brukerreisen identifiseres, og friksjonspunkter eller uoppfylte behov kan identifiseres på kartet. Denne teknikken brukes til å forbedre utformingen av et produkt,[30] og gjør det mulig å engasjere brukere i en deltakende tilnærming.

Sammenligning med brukstilfeller[rediger | rediger kilde]

Et brukstilfelle har blitt beskrevet som "en generalisert beskrivelse av et sett av interaksjoner mellom systemet og en eller flere aktører, hvor en aktør er enten en bruker eller et annet system".[31] Mens brukstilfeller og brukerhistorier har noen likheter er det flere forskjeller mellom dem:

Brukerhistorier Brukstilfeller
Likhet
  • Generelt formulert i brukernes hverdagsspråk. De skal hjelpe leseren med å forstå hva programvaren skal oppnå.
  • Skrevet i brukernes daglige forretningsspråk, for å lette kommunikasjon med interessenter.
Forskjell
  • Gir en kort og brukervennlig presentasjon med få detaljer, og forblir dermed åpen for tolkning. Blir til gjennom samtaler med kunder.
  • Brukstilfeller organiserer krav for å danne en fortelling om hvordan brukerne forholder seg til og bruker et system. Derfor fokuserer de på brukermål og hvordan samspill med et system tilfredsstiller målene.[32]
  • Brukstilfelle-flyter beskriver sekvenser av interaksjoner, og kan formuleres som en formell modell. Et brukstilfelle er ment å gi tilstrekkelig detalj til at det skal kunne forstås på egenhånd.
Mal Som en < type bruker > kan jeg < noen mål> slik at <noen grunn>.[10]
  • Tittel: "målet brukstilfellet prøver å tilfredsstille"
  • Viktigste suksess-scenario: Nummerert liste over steg
    • Steg :" En enkel uttalelse av samspillet mellom aktøren og et system"
  • Utvidelser: Separate nummererte lister, en per utvidelse
    • Utvidelse:" En tilstand som resulterer i forskjellige interaksjoner fra hoved-suksessscenariet nr. x". (En utvidelse fra hovedsteg 3 er nummerert 3a, etc.)

Kent Beck, Alistair Cockburn, Martin Fowler og andre har publisert en videre diskusjon på c2.com wiki (hjemmesiden til ekstrem programmering) hvor de sammenligner brukerhistorier og brukstilfeller.[33]

Sammenligning med produktbeskrivelse[rediger | rediger kilde]

I PRINCE2 kan man bruke produktbeskrivelser i kombinasjon med smidige brukerhistorier.[34]

Se også[rediger | rediger kilde]

Referanser[rediger | rediger kilde]

  1. ^ «User Stories :: PRINCE2 Agile® wiki». prince2agile.wiki (engelsk). Besøkt 21. januar 2022. 
  2. ^ Dimitrijević, Sonja; Jovanović, Jelena; Devedžić, Vladan (2015). «A comparative study of software tools for user story management». Information and Software Technology. 57: 352–368. doi:10.1016/j.infsof.2014.05.012. «a great number of software tools that provide, inter alia, support for practices based on user stories have emerged in recent years.» 
  3. ^ Ralph, Paul (2015). «The Sensemaking-coevolution-implementation theory of software design». Science of Computer Programming. 101: 21–41. arXiv:1302.4061 Åpent tilgjengelig. doi:10.1016/j.scico.2014.11.007. 
  4. ^ Cohn, Mike (2004). User Stories Applied: For Agile Software Development. Addison-Wesley. ISBN 0321205685. OCLC 54365622. 
  5. ^ «Glossary: User Story Template». Agile Alliance. Arkivert fra originalen 3. februar 2020. Besøkt 3. februar 2020. 
  6. ^ Cohn, Mike. «Advantages of the "As a user, I want" user story template». Arkivert fra originalen 18. desember 2016. Besøkt 18. desember 2016. 
  7. ^ Marcano, Antony. «Old Favourite: Feature Injection User Stories on a Business Value Theme». Arkivert fra originalen 2. juli 2012. Besøkt 23. februar 2017. 
  8. ^ «User Story». Arkivert fra originalen 3. februar 2020. Besøkt 3. februar 2020. 
  9. ^ a b Cowan, Alexander. «Your Best Agile User Story». Arkivert fra originalen 25. mars 2016. Besøkt 29. april 2016. 
  10. ^ a b Cohn, Mike. «User Stories». Arkivert fra originalen 30. april 2016. Besøkt 27. april 2016. 
  11. ^ Cohn, Mike. «The Two Ways to Add Detail to User Stories». Arkivert fra originalen 8. april 2019. Besøkt 8. april 2019. 
  12. ^ Ralph, Paul; Mohanani, Rahul. «Is Requirements Engineering Inherently Counterproductive?». 2015 IEEE/ACM 5th International Workshop on the Twin Peaks of Requirements and Architecture. IEEE. ISBN 978-1-4673-7100-1. doi:10.1109/TwinPeaks.2015.12. Arkivert fra originalen 22. juni 2021. Besøkt 4. februar 2020. 
  13. ^ «Limitations of user stories». Ferolen.com. Arkivert fra originalen 13. april 2014. Besøkt 9. april 2014. 
  14. ^ «Epics, Stories, Themes, and Initiatives». Arkivert fra originalen 30. januar 2019. Besøkt 8. februar 2019. 
  15. ^ «User Stories». Arkivert fra originalen 5. februar 2019. Besøkt 8. februar 2019. 
  16. ^ Britsch, Marcel. «The Basics: Epics, Stories, Themes & Features». Arkivert fra originalen 21. september 2017. Besøkt 8. februar 2019. 
  17. ^ Cohn, Mike. «User Stories, Epics and Themes». Arkivert fra originalen 4. februar 2019. Besøkt 8. februar 2019. 
  18. ^ «Scrum Alliance Member-Submitted Informational Articles». Arkivert fra originalen 11. september 2018. Besøkt 11. september 2018. 
  19. ^ Guay, Constantin. «Scrum tips: Differences between epics, stories, themes and features». Arkivert fra originalen 19. november 2018. Besøkt 8. februar 2019. 
  20. ^ «User Stories, Epics & Themes». Arkivert fra originalen 9. februar 2019. Besøkt 8. februar 2019. 
  21. ^ Cohn, Mike. «You Don't Need a Complicated Story Hierarchy». Arkivert fra originalen 10. mai 2019. Besøkt 8. februar 2019. 
  22. ^ «Configuring initiatives and other hierarchy levels - Atlassian Documentation». Arkivert fra originalen 5. februar 2020. Besøkt 5. februar 2020. 
  23. ^ Patton, Jeff. «The new user story backlog is a map». Arkivert fra originalen 14. mai 2017. Besøkt 17. mai 2017. 
  24. ^ Patton, Jeff (Software developer). User story mapping. Economy, Peter,, Fowler, Martin, 1963-, Cooper, Alan, 1952-, Cagan, Marty (First utg.). Beijing. ISBN 978-1-4919-0490-9. OCLC 880566740. 
  25. ^ Cohn, Mike. «User Stories, Epics and Themes». Arkivert fra originalen 27. september 2017. Besøkt 26. september 2017. 
  26. ^ Cockburn, Alistair. «Walking Skeleton». Arkivert fra originalen 24. september 2013. Besøkt 4. mars 2013. 
  27. ^ «Story Mapping». Agile Alliance. Arkivert fra originalen 23. juni 2016. Besøkt 1. mai 2016. 
  28. ^ «Metodekortstokk, tjenestedesign | Innomed» (PDF). 
  29. ^ Experience, World Leaders in Research-Based User. «Journey Mapping 101». Arkivert fra originalen 19. mars 2020. Besøkt 15. mars 2020. 
  30. ^ Richardson, Adam (15. november 2010). «Using Customer Journey Maps to Improve Customer Experience». Harvard Business Review. ISSN 0017-8012. Besøkt 15. mars 2020. 
  31. ^ Cohn, Mike. «Project Advantages of User Stories as Requirements». Arkivert fra originalen 18. april 2012. Besøkt 26. september 2017. 
  32. ^ Fowler, Martin. «UseCasesAndStories». Arkivert fra originalen 27. september 2017. Besøkt 26. september 2017. 
  33. ^ «User Story And Use Case Comparison». Arkivert fra originalen 2. september 2016. Besøkt 26. september 2017. 
  34. ^ «Slik bruker du PRINCE2s produktbeskrivelser i kombinasjon med smidige brukerhistorier [video]». www.prosjektbloggen.no (norsk). Besøkt 21. januar 2022. 
Hentet fra «https://no.wikipedia.org/w/index.php?title=Brukerhistorie&oldid=24267851»