Definere brukerhistorier og smidig utvikling
En kjerne i moderne utviklingsprosesser er smidig utvikling . Denne utviklingsmetodikken legger vekt på å bruke små, små brukerhistorier for å definere hva et system gjør fra et brukerperspektiv, ikke et teknisk. En bruker bryr seg om et produkt er raskt, enkelt å bruke og løser problemet. De bryr seg ikke om den følger en 3-lags arkitektur, har Mongo DB, eller om den bruker Rails eller Asp.net.
Brukerhistorier:
- Er lett å forstå, og alle kan delta
- Arbeid iterativt; de kan og bør endres eller endres ofte
- Juster utviklere, brukere og forretningsspesialister rundt felles mål og forventninger
- Er mye lettere å lese enn 400 siders kravdokumenter
Storyboard That gir en ideell plattform for å lage smidige brukerhistorier og skape samtale i et format som er mye mindre belastende enn en tekstvegg.
Episk
I sammenheng med brukerhistorier er et "epos" ganske enkelt en veldig bred historie som senere vil bli delt opp i mange spesifikke brukerhistorier. Fra og med en episk innrømmer alle med en enkelt visjon på høyt nivå. Den episke historien forankrer et prosjekt ovenfra og ned, og hvis det ikke gir mening å konstruere et epos, vil støttearbeid også være sløsing med krefter.
I denne historien er det veldig klart hva den langsiktige visjonen er og hvordan suksess skal se ut. En god episk historie bør inneholde:
- Innstilling eller kontekst
- Skuespillere eller brukere
- Mål og målsettinger
- Aktiviteter og arrangementer
Definere brukere
Spesielt når du designer programvare, er det viktig å ha en god visjon om hvordan brukerne vil se ut. Ikke alle brukere vil matche denne visjonen nøyaktig, og det kan være flere kategorier av brukere, men disse diskrete visjonene trenger artikulasjon. Å tenke på brukerne beskytter først mot overkonstruksjon og overkomplikasjon, forhindrer et nytt produkt i å ha noe for alle og være nyttig for ingen.
Å lage en historie
Når et epos er etablert og brukerne er definert, kan mindre, mer spesifikke historier konstrueres om bestemte brukeropplevelser. Historiene nedenfor bryter ned skissert ovenfor i to fortellinger: slå opp en bestilling og ombestille et produkt.
Disse fortellingene inneholder ikke teknisk informasjon; brukerne bryr seg ikke om hvordan resultatene oppnås, så lenge de utfører de ønskede oppgavene. På samme måte er UX avbildet generisk, for å unngå å kvele innovasjon eller tvinge en vei. Generelt bør historier være:
- Liten - Under 10 dagers arbeid
- Verdifull - Når de er ferdig, skal de levere noe brukbart
- Estimable - Kan lage et ballparkestimat på hvor mye innsats som er involvert
Slå opp en bestilling
Utfører en ombestilling
Samtale og planlegging for testing
Disse historiene bør invitere til samtale og spørsmål, for eksempel:
- Er dette de riktige historiene for å matche vårt epos?
- Hvilke andre historier bør skapes?
- Er disse historiene i samsvar med det vi vet om brukerne våre?
Det er helt rimelig å lage mange historier; faktisk bør det oppmuntres. Noen av disse historiene vil aldri bli brukt, men det er viktig å se veien de la ned. Denne samlingen av historier vil skylle ut ytterligere krav og påvirke testing.
Historiene skal provosere og informere diskusjon om hvordan programvaren skal testes og hvilke forretningsregler som må defineres eksplisitt. For eksempel:
- Hvor raskt må et oppslag være?
- Er det en tidsbegrensning på ombestillinger?
- Hva bør systemet gjøre hvis det er den andre ombestillingen? Femte?
- Hvilke tester og oppfølgingsspørsmål vil du ha?
© 2024 - Clever Prototypes, LLC - Alle rettigheter forbeholdt.
StoryboardThat er et varemerke for Clever Prototypes , LLC , og registrert i US Patent and Trademark Office