Definere brugerhistorier og smidig udvikling
En kerne for moderne udviklingsprocesser er agil udvikling . Denne udviklingsmetodik understreger at bruge små, bidstore brugerhistorier til at definere, hvad et system gør ud fra et brugerperspektiv, ikke et teknisk. En bruger er ligeglad med, om et produkt er hurtigt, let at bruge og løser deres problem. De er ligeglade med, om den følger en 3-lags arkitektur, har Mongo DB, eller om den bruger Rails eller Asp.net.
Brugerhistorier:
- Er let at forstå, og alle kan deltage
- Arbejd iterativt; de kan og bør ændres eller ændres ofte
- Juster udviklere, brugere og virksomhedsspecialister omkring fælles mål og forventninger
- Er meget lettere at læse end 400-siders kravdokumenter
Storyboard That giver en ideel platform til at skabe smidige brugerhistorier og skabe samtale i et format, der er meget mindre belastende end en tekstmur.
Episk
I forbindelse med brugerhistorier er en "epos" simpelthen en meget bred historie, der senere vil blive opdelt i mange specifikke brugerhistorier. Starter med en episk tilpasser alle med en enkelt vision på højt niveau. Den episke historie forankrer et projekt oppefra og ned, og hvis det ikke giver mening at konstruere et epos, vil understøttende arbejde også være spild af kræfter.
I denne historie er det meget klart, hvad den langsigtede vision er, og hvordan succes skal se ud. En god episk historie bør omfatte:
- Indstilling eller kontekst
- Skuespillere eller brugere
- Mål og mål
- Aktiviteter og arrangementer
Definere brugere
Især når man designer software, er det vigtigt at have en god vision om, hvordan brugerne vil se ud. Ikke alle brugere vil matche denne vision præcist, og der kan være flere kategorier af brugere, men disse diskrete visioner har brug for artikulation. At tænke på brugerne beskytter først mod overkonstruktion og overkomplikation, forhindrer et nyt produkt i at have noget for enhver smag og ikke er nyttigt for nogen.
Oprettelse af en historie
Når først et epos er etableret, og brugerne er defineret, kan der konstrueres mindre, mere specifikke historier om bestemte brugeroplevelser. Historierne nedenfor opdeler ovenstående i to fortællinger: at slå en ordre op og ombestille et produkt.
Disse fortællinger indeholder ikke tekniske oplysninger; brugerne er ligeglade med, hvordan resultaterne opnås, så længe den udfører de ønskede opgaver. På samme måde er UX afbildet generisk for at undgå at kvæle innovation eller tvinge en vej. Generelt skal historier være:
- Lille - Under 10 dages arbejde
- Værdifuld - Når de er færdige, skal de levere noget brugbart
- Estimable - i stand til at oprette et ballpark -skøn over, hvor stor indsats der er involveret
Slår en ordre op
Udfører en genbestilling
Samtale og planlægning til test
Disse historier bør invitere til samtale og spørgsmål, såsom:
- Er det de rigtige historier, der matcher vores epos?
- Hvilke andre historier skal skabes?
- Er disse historier i overensstemmelse med det, vi ved om vores brugere?
Det er helt rimeligt at skabe mange historier; faktisk bør det opmuntres. Nogle af disse historier vil aldrig blive brugt, men det er vigtigt at se den vej, de satte ned. Denne samling historier vil skylle yderligere krav og påvirke testning.
Historierne skal fremkalde og informere diskussion om, hvordan softwaren vil blive testet, og hvilke forretningsregler, der skal defineres eksplicit. For eksempel:
- Hvor hurtigt skal et opslag være?
- Er der en tidsbegrænsning for genbestillinger?
- Hvad skal systemet gøre, hvis det er den anden genbestilling? Femte?
- Hvilke tests og opfølgende spørgsmål ville du have?
© 2024 - Clever Prototypes, LLC - Alle rettigheder forbeholdes.
StoryboardThat er et varemærke tilhørende Clever Prototypes , LLC og registreret i US Patent and Trademark Office