Bruker historiene er enkle, men likevel svært kraftige konstruksjoner: de beskriver deler av funksjonaliteten fra en brukers synspunkt, uttrykt i et solid, kompakt måte. De gjenspeiler hva en bestemt klasse av brukernes behov og verdien til å være vunnet. Formatet er veldig enkel og lett å bruke. Det finnes flere varianter, blant annet:
Hvorfor Bruker Historier?
Bruker historier gir en utmerket måte å definere produktet ditt med klarhet., Et sett med veldefinerte, prioritert bruker historier kan hjelpe deg med å formulere funksjonaliteten til produktet ditt ved hjelp av ‘vanlig engelsk» — med ingen tekniske og gjennomføring detaljer.
‘user story’ tilnærming utdanner meningsfylt produktet diskusjoner, både innen produktutvikling team og med eksterne aktører.
Riktig skrevet brukeren historier gi et solid grunnlag for kommunikasjon og samarbeid, med fokus på det som betyr mest for brukeren., I forhold til andre metoder for å registrere og dokumentere brukernes behov og produkt spesifikasjon, de har minst følgende fordeler:
- Bruker historier bidra til å oppnå cross-team klarhet på hva du skal bygge, for hvem, hvorfor og når. Siden de er enkle å definere, forstå og revidere, kan de bli standard måte å kommunisere og oppsummere funksjonaliteten til produktet av både tekniske og ikke-tekniske medlemmer. De er svært nyttig for produkt scope diskusjoner eller som startpunkter for teknisk dyp-dykk. De er viktige elementer i smidig utvikling.,
- Bruker historier oppmuntre til deltakelse av ikke-teknisk medlemmer. Moderne programvare-prosjekter er vanligvis komplekse og involverer et bredt spekter av teknologier, akronymer, og gjennomføring av valg. I mange tilfeller, terminologi eller teknisk språk ikke er allment forstått — selv innenfor en enkelt team — og dermed innføre ‘støy’ og risiko til prosjektet. Bruker historier fjerne denne tekniske dimensjon, slik at et medlem av teamet kan bidra, bare ved å tenke » som en bruker., Teamet kan bruke ikke-teknisk språk og effektivt samarbeide i å definere, utfordrende eller å prioritere bruker historier. Virkningen på samarbeid og team dynamikk kan være betydelig.
- De hjelper i å definere hele produktet — som et sett av solid, klokt-prioritert historier. Produktet utvikling team kan tenke stort, definere super-satt av brukeren historier, og tilordne deretter prioriteringer (som reflekterer forventet verdi for brukeren, kompleksitet, avhengigheter og andre forretningsmessige prioriteringer). Du trenger ikke å foreta vanskelige beslutninger og flagg elementer som ‘out of scope’., I stedet, kan du tilordne en lavere prioritet til de ‘gale’ ideer, mens de beveger seg opp brukeren historier som reflekterer kjernen funksjonaliteten til produktet. Å definere cut lines’ som bestemmer omfang for hver iterasjon, fase eller versjonen, er da et spørsmål om hvilke ressurser som er tilgjengelige og hastigheten av teamet.
Skriver Flott Bruker Historier
formatet er grei, og å skrive historier er enkelt. Men å skrive store de kan være litt vanskelig. Her er noen retningslinjer for å vurdere:
Bruker historier ≠ oppgaver
Bruker historier er ikke oppgaver., Faktisk, en enkelt historie kanskje hundrevis av enkle oppgaver for å være levert. Oppgaver om gjennomføring; bruker historier om definisjon.
Når du skriver dine historier, fokus på å gi klarhet om produktets funksjoner — hva, ikke hvordan.
Opphold high-nivå
Du trenger for å være på høyt nivå, men også nøyaktig og til poenget. Historier må være enkel og solid. Dette vil hjelpe team medlemmer og interessenter dypt forstå brukernes behov, og unngå å bruke tid på å avklare buzzwords, terminologi og forkortelser. Det er bare å bruke enkle og nøyaktige språk.,
Forstå brukere
Du trenger for å oppdage og studere den reelle brukere av produktet ditt — ta vare på sine profiler, synspunkter, forventninger, og de tilhørende ‘smerte poeng.’Brukerundersøkelser og andre teknikker kan generere innsikt til å hjelpe deg med å bedre forstå brukerne og deres behov.
uansett teknikker, må du ha satt av viktige brukere — helst i form av personas — før du begynner å lage bruker historier.,
Tror som bruker
<som en bestemt klasse av brukeren/ person /rolle> en del av en bruker historien, definerer vinkelen, perspektiv — hvordan den bestemte brukeren oppfatter den funksjonalitet som er oppsummert i historien.
Dette er av avgjørende betydning — produktet eieren og hele teamet trenger å tenke fra en brukers synspunkt og forstå de underliggende behov og forventet verdi.,
Tror big
Når man skal beskrive et produkt som et etterslep av user stories, det er ingen god grunn til å begrense din tenkning av budsjett, tid, gjennomføringsevne og pris.
En god praksis er å tenke stort, og la ‘crazy’ user stories inn etterslepet. Den administrative belastningen av å opprettholde en utvidet produktkøen er liten; den verdi som kommer fra det — i form av produkt klarhet, visjon og muligheter — er massiv.,
Bruk epos
Epos kan ta form av høyere nivå historier, som beskriver store deler av funksjonalitet — de krever vanligvis en betydelig mengde arbeid, på tvers av flere sprinter. En annen måte å tenke på epos er så grupperinger/ beholdere av i slekt, mindre historier, som serverer et felles mål. Epos er bra for å organisere dine historier og gir det store bildet.,
ikke kast — prioritere i stedet
Gitt en effektiv prioritering prosessen, er det en god vane å holde berikende din produktkø med ny bruker historier, som beskriver nye brukermedvirkning scenarier, ’tilfeldige ideer,’ eller produksjonen av produktet innovasjon aktiviteter.
for Å behandle potensiell støy, må du riktig gruppe og prioritere den nye oppføringer. I alle fall ikke filtrere ut/fjerne elementer fra produktkøen: de-omfattet elementer er vanligvis glemt, mens de prioriterte elementer forblir synlig og kan bli relevant under de rette forholdene.,
Avhengig av konteksten, og prioriterer bruker historier kan være en vanskelig prosess. Du trenger for å anslå verdien av hver historie, for brukeren og for virksomheten. Du trenger til størrelse, kompleksitet, anslå gjennomførbarhet og kostnader/innsats som kreves for å bygge og slipp-funksjonen. Du trenger for å identifisere cross-avhengigheter i ordrereserven — å håndheve bestemt sortering mellom visse oppføringer.
Oppsett for suksess — ikke bare aksept
Lag ofte definere bruker aksept tester og relaterte kriterier for aksept. Aksept selv er ikke nok — du må sette opp for suksess., Som product manager, trenger du mer enn en bekreftelse på at «det fungerer som det skal «eller» i henhold til spesifikasjoner.’
Du trenger beregninger som også er knyttet til direkte tilbakemeldinger til brukeren, og fanger inn hvordan glad og engasjert ditt virkelige brukere. Mens aksept er god til å styre utviklingen life-cycle av funksjonen, er suksess er om mid/langsiktig effekt og verdiskaping for reelle brukere av produktet. Du må definere både på produkt-og/eller episk og/eller historien nivå.
– Tag-historier, legge til metadata
Komplekse produkter som krever hundrevis av user stories., For enklere navigering og administrasjon, du trenger for å effektivt navn, kategorisere, og tagg dine historier. Etter de første par versjoner av en historie, du bør unngå å gi nytt navn eller drastisk endre sin beskrivelse som dette kan introdusere forvirring og hull i laget.
Riktig administrere metadata av dine historier—status, fremdrift, koblinger, prioriteringer, ressurser, etc. — hjelper til å utforske, overvåke og forstå dine etterslep.
ikke holde seg til klistrelapper!,
Ja, en vegg full av fargerike lapper ser fancy og hjelper teamet vises travel og produktiv 🙂 Men du trenger en alvorlig systemet og spesielle verktøy for å hjelpe deg med riktig administrere, berike, prioritere og dele historier.,
I spesielle tilfeller, som en brainstorming eller ideation økt, er det greit å ta det første settet av brukeren historier ved å bruke klistrelapper—forutsatt at du da å dokumentere alle av dem inn i en skikkelig product management system. Hvis du ikke gjør det, og du må bare holde dine historier på klistrelapper, sjansene er at du vil gå glipp av muligheter i form av klarhet, innovasjon, effektivitet og samarbeid.,
Du fortsatt trenger spesifikasjoner
å Ha et prioritert sett av godt definerte bruker-historier er flott, men det er bare begynnelsen. Laget trenger for å analysere historier — fra et teknisk synspunkt — og skape de nødvendige tekniske gjenstander.
Ideell, historier er knyttet til spesifikk dokumentasjon som gir alle de tekniske detaljene som trengs fra et software engineering perspektiv. De gir startpunkter for detaljert teknisk spesifikasjon-dokumenter og andre detaljerte gjenstander.,
Visualisering hjelper
En alltid på (digitale) visualisering av topp-prioritet bruker historier etter kategori, tema, eller episk kan være svært nyttig for samarbeid og samkjøring mellom grupper og interessenter. Sammen med statistikk, problemer, blokkere og fremgang indikatorer, en historie kart kan presenteres via interaktive skjermer i samarbeid plass.
Bruker historier gi en god måte å raskt og nøyaktig beskriver funksjonaliteten til programvaren eller systemet., De er også svært effektiv i å fange utganger av idédugnader, design spurter, hackathons og andre innovasjon-led-prosesser — hvor en strøm av ideer må være tatt i et kompakt og strukturert måte.