Hvad er en brugerhistorie?
brugerhistorier er korte, enkle beskrivelser af en funktion fortalt fra perspektivet af den person, der ønsker den nye kapacitet, som regel en bruger eller kunde af systemet. De følger typisk en simpel skabelon:
som en , Jeg vil have det .
brugerhistorier skrives ofte på indekskort eller sticky notes, opbevares i en skotøjsæske og arrangeres på vægge eller borde for at lette planlægning og diskussion., Som Sådan skifter de stærkt fokus fra at skrive om funktioner til at diskutere dem. Faktisk er disse diskussioner vigtigere end uanset hvilken tekst der er skrevet.
kan du vise nogle eksempler på brugerhistorier?
en af fordelene ved agile brugerhistorier er, at de kan skrives på forskellige detaljeringsniveauer. Vi kan skrive en brugerhistorie for at dække store mængder funktionalitet. Disse store brugerhistorier er generelt kendt som epics. Her er et episk agile user story eksempel fra et desktop backup produkt:
- som bruger kan jeg sikkerhedskopiere hele min harddisk.,
da en episk generelt er for stor til, at et smidigt team kan gennemføre i en iteration, opdeles det i flere mindre brugerhistorier, før det arbejdes på. Den episke ovenfor kunne opdeles i snesevis (eller muligvis hundreder), inklusive disse to:
- som strømbruger kan jeg specificere filer eller mapper, der skal sikkerhedskopieres, baseret på Filstørrelse, Oprettet dato og ændret dato.
- som bruger kan jeg angive mapper, der ikke skal sikkerhedskopieres, så mit backupdrev ikke er fyldt med ting, jeg ikke har brug for gemt.
hvordan tilføjes detaljer til brugerhistorier?,
detaljer kan tilføjes til brugerhistorier på to måder:
- ved at opdele en brugerhistorie i flere, mindre brugerhistorier.
- ved at tilføje ” betingelser for tilfredshed.”
når en relativt stor historie er opdelt i flere, mindre smidige brugerhistorier, er det naturligt at antage, at detaljer er tilføjet. Når alt kommer til alt er der skrevet mere.
betingelserne for tilfredshed er simpelthen en accept på højt niveau, der vil være sandt, efter at den agile brugerhistorie er afsluttet., Overvej følgende som et andet smidigt brugerhistorieeksempel:
som vicepræsident for marketing vil jeg vælge en feriesæson, der skal bruges, når jeg gennemgår resultaterne af tidligere reklamekampagner, så jeg kan identificere rentable.detaljer kan tilføjes til det brugerhistoriske eksempel ved at tilføje følgende tilfredshedsbetingelser:
- sørg for, at det fungerer med store detailferier: jul, påske, præsidentens dag, Mors Dag, Fars dag, Labor Day, nytårsdag.
- Supportferier, der spænder over to kalenderår (ingen spænder over tre).,
- feriesæsoner kan indstilles fra en ferie til den næste (såsom Thanksgiving til jul).
- feriesæsoner kan indstilles til at være et antal dage før ferien.
Hvem skriver brugerhistorier?
alle kan skrive brugerhistorier. Det er produktet ejerens ansvar at sørge for, at et produkt backlog af agile user stories eksisterer, men det betyder ikke, at produkt ejeren er en, der skriver dem. I løbet af et godt smidigt projekt skal du forvente at få brugerhistorieeksempler skrevet af hvert teammedlem.,
Bemærk også, at hvem der skriver en brugerhistorie er langt mindre vigtig end hvem der er involveret i diskussionerne om den.
hvornår skrives brugerhistorier?
brugerhistorier er skrevet i hele agile-projektet. Normalt afholdes et historieskrivningsværksted nær starten af det agile projekt. Alle på teamet deltager med målet om at skabe en produkt backlog, der fuldt ud beskriver funktionaliteten, der skal tilføjes i løbet af projektet eller en tre – til seks måneders udgivelsescyklus inden for det.
Nogle af disse smidige brugerhistorier vil uden tvivl være epics., Epics vil senere blive nedbrudt i mindre historier, der passer lettere ind i en enkelt iteration. Derudover kan nye historier skrives og tilføjes til produkt backlog til enhver tid og af nogen.
erstatter brugerhistorier et kravdokument?
Agile projekter, især Scrum-projekter, bruger en Product backlog, som er en prioriteret liste over funktionaliteten, der skal udvikles i et produkt eller en tjeneste. Selvom produkt backlog elementer kan være, hvad holdet ønsker, bruger historier har vist sig som den bedste og mest populære form for produkt backlog elementer.,
mens et produkt backlog kan betragtes som en erstatning for krav dokument af et traditionelt projekt, er det vigtigt at huske, at den skriftlige del af en agile bruger historie (“som bruger, jeg vil …”) er ufuldstændig, indtil diskussionerne om denne historie opstår.
det er ofte bedst at tænke på den skrevne del som en peger på det reelle krav. Brugerhistorier kan pege på et diagram, der viser en arbejdsgang, et regneark, der viser, hvordan man udfører en beregning, eller enhver anden artefakt, som produktejeren eller teamet ønsker.,
anbefalede ressourcer relateret til brugerhistorier
- fordele ved “som bruger vil jeg have” brugerhistorieskabelon.,
- En Prøve Format til et Regneark-Baseret Produkt Backlog
- Fordele af User Stories til Kravene
- Ikke-funktionelle Krav som Bruger Historier
- Introduktion til User Stories
Leave a Reply