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.
Storyboard That gir en ideell plattform for å lage smidige brukerhistorier og skape samtale i et format som er mye mindre belastende enn en tekstvegg.
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:
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.
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:
Disse historiene bør invitere til samtale og spørsmål, for eksempel:
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:
En smidig brukerhistorie er en enkel, tydelig beskrivelse av en programvarefunksjon fra en brukers perspektiv. Den fokuserer på hva brukeren ønsker å oppnå, ikke tekniske detaljer, noe som gjør utviklingen mer brukersentrert.
For å lage effektive brukerhistorier, start med et overordnet episk, definer brukerne dine, og del opp oppgaver i små, oppnåelige mål. Bruk tydelig språk og fokuser på reelle brukerbehov i stedet for tekniske løsninger.
Brukerhistorier er viktige i smidig utvikling fordi de hjelper med å tilpasse utviklere, brukere og interessenter mot felles mål, oppmuntrer til hyppig tilbakemelding, og gjør prosjektene lettere å håndtere og forstå.
Et epos er en bred, overordnet historie som setter prosjektets visjon. En brukerhistorie er en mindre, spesifikk oppgave eller funksjon hentet fra epikken, fokusert på et enkelt brukerbehov.
Storyboards illustrerer brukerhistorier visuelt, noe som gjør konseptene lettere for elever å forstå. De fremmer samtale, tydeliggjør krav og oppmuntrer til deltakelse i smidige planleggingsaktiviteter.