Definiera användarberättelser och agil utveckling
En kärnan i moderna utvecklingsprocesser är agil utveckling . Denna utvecklingsmetodik betonar att använda små, lagom stora användarberättelser för att definiera vad ett system gör ur ett användarperspektiv, inte ett tekniskt. En användare bryr sig om en produkt är snabb, enkel att använda och löser deras problem. De bryr sig inte om det följer en 3-skiktsarkitektur, har Mongo DB eller om det använder Rails eller Asp.net.
Användarberättelser:
- Är lätta att förstå, och alla kan delta
- Arbeta iterativt; de kan och bör ändras eller ändras ofta
- Anpassa utvecklare, användare och affärsspecialister kring gemensamma mål och förväntningar
- Är mycket lättare att läsa än 400-sidiga kravdokument
Storyboard That ger en idealisk plattform för att skapa smidiga användarberättelser och väcka konversation i ett format som är mycket mindre belastande än en textvägg.
Episk
I sammanhanget med användarberättelser är ett "epos" helt enkelt en mycket bred berättelse som senare kommer att delas upp i många specifika användarberättelser. Att börja med ett epos anpassar alla till en enda vision på hög nivå. Den episka berättelsen förankrar ett projekt uppifrån och ner, och om det inte är vettigt att konstruera ett epos, kommer stödarbete också att vara ett slöseri med ansträngning.
I den här historien är det väldigt tydligt vad den långsiktiga visionen är och hur framgång ska se ut. En bra episk berättelse bör innehålla:
- Inställning eller sammanhang
- Skådespelare eller användare
- Mål och syfte
- Aktiviteter och evenemang
Definiera användare
Särskilt när man designar mjukvara är det viktigt att ha en god vision om hur användarna kommer att se ut. Alla användare kommer inte att matcha denna vision exakt, och det kan finnas flera kategorier av användare, men dessa diskreta visioner behöver artikulation. Att tänka på användare skyddar först mot överkonstruktion och överkomplikation, vilket förhindrar att en ny produkt har något för alla och inte är användbar för någon.
Skapa en berättelse
När ett epos väl har etablerats och användare har definierats kan mindre, mer specifika berättelser konstrueras om specifika användarupplevelser. Berättelserna nedan delar upp det som beskrivs ovan i två berättelser: leta upp en beställning och beställa om en produkt.
Dessa berättelser innehåller ingen teknisk information; användarna bryr sig inte om hur resultaten uppnås, så länge den utför de önskade uppgifterna. På liknande sätt avbildas UX generiskt för att undvika att kväva innovation eller tvinga fram en väg. I allmänhet bör berättelser vara:
- Liten – Under 10 dagars arbete
- Värdefullt – När de är klara ska de leverera något användbart
- Uppskattningsbar – Kan skapa en uppskattning av hur mycket ansträngning som är involverad
Söker upp en beställning
Utför en ombeställning
Samtal & planering för testning
Dessa berättelser bör inbjuda till samtal och frågor, som:
- Är det här de rätta berättelserna för att matcha vårt epos?
- Vilka andra berättelser bör skapas?
- Stämmer dessa berättelser med vad vi vet om våra användare?
Det är fullt rimligt att skapa många berättelser; i själva verket borde det uppmuntras. En del av dessa berättelser kommer aldrig att användas, men det är viktigt att se den väg de slår ut. Den här samlingen av berättelser kommer att spola ut ytterligare krav och påverka testning.
Berättelserna ska väcka och informera diskussioner om hur programvaran kommer att testas och vilka affärsregler som måste definieras uttryckligen. Till exempel:
- Hur snabb behöver en uppslagning vara?
- Finns det en tidsgräns för ombeställningar?
- Vad ska systemet göra om det är den andra ombeställningen? Femte?
- Vilka tester och uppföljningsfrågor skulle du ha?
© 2024 - Clever Prototypes, LLC - Alla rättigheter förbehållna.
StoryboardThat är ett varumärke som tillhör Clever Prototypes , LLC och registrerat i US Patent and Trademark Office