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.
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.
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:
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.
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:
Dessa berättelser bör inbjuda till samtal och frågor, som:
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: