När du börjar dyka in i smidig, är det första du märker hur användarcentrerad detta tillvägagångssätt är. Det skiftar fokus från bara kodning och design för att leverera verkligt värde till dina slutanvändare, intressenter och företag i allmänhet.
smidiga användarhistorier är en viktig del av denna ideologi som låter dig definiera vilka fördelar din produkt kommer att ge din målgrupp (och så småningom hur det kommer att öka dina nyckeltal och andra mätvärden).,
Vi på Stormotion Love Stories. Som ett Agile-driven Team använder vi dem aktivt för att få en bättre förståelse för vilka fördelar våra kunders produkter levererar till sina slutanvändare. De driver också samarbete och kreativitet, driver oss till icke-triviala utvecklingslösningar.,
så idag kommer vi att dela med oss av vår kunskap och erfarenhet i denna fråga för att hjälpa dig att förbättra dina historieskrivande färdigheter. Njut!
vad är en användarhistoria?
användarhistorier är en av kärnelementen i den smidiga metoden. Men de är ofta jumbled med programvarukrav som inte är sant. Så vad är en användarhistoria?
användarhistorien är en liten (faktiskt den minsta) del av arbetet som representerar ett visst värde för en slutanvändare och kan levereras under en sprint.,
huvudsyftet med detta element är att sätta slutanvändarna i centrum för konversationen och fånga produktfunktionalitet ur deras perspektiv. Således får Utvecklare en bättre förståelse för vad, för vem och varför de bygger.,
bra användarhistorier passar alltid INVEST – uppsättningen kriterier av Bill Wake:
- oberoende-de kan utvecklas i vilken sekvens som helst och ändras till en användarhistoria påverkar inte de andra.
- förhandlingsbart – det är upp till laget att bestämma hur man implementerar dem; det finns inget strikt fast arbetsflöde.
- värdefullt – varje användarhistoria levererar en fristående värdeenhet till slutanvändarna.,
- Estimable – det är ganska lätt att gissa hur mycket tid utvecklingen av en användarhistoria kommer att ta.
- liten – det ska gå igenom hela cykeln (design, kodning, testning) under en sprint.
- testbar – det bör finnas tydliga acceptanskriterier för att kontrollera om en användarhistoria genomförs på lämpligt sätt.
Användarhistorikformatet (som också används av Stormotion-laget) är ganska enkelt och kort:
ser ut som inget svårt, va?, Här är några exempel på användarhistorier som passar några uppbyggda taxi-appprojekt:
- som förare vill jag blockera dåligt uppförde passagerare så att de aldrig visas mig igen.
- som passagerare vill jag länka kreditkortet till min profil så att jag kan betala för en åktur snabbare, enklare och utan kontanter.
- som förare vill jag lägga till bilder på min bil i min profil så att jag kan locka fler användare.
- som passagerare vill jag att flera tillgängliga drivrutiner ska visas så att jag kan välja det lämpligaste alternativet för mig.,
låter ganska enkelt men Användarhistorieutveckling är inte ofta så enkelt. Men senare delar vi några av våra beprövade tips som hjälper dig att bara göra bra skott.
finns det något annat?
trots att vi just har listat ut att smidiga användarhistorier är oberoende och bör förstås som helt separata arbetsenheter, ibland är de grupperade tillsammans., Så när du arbetar med dem kommer du sannolikt att träffas och använda begreppet episk. Vad är det?
en episk är en hög nivå av arbete som band tillsammans med en grupp relaterade berättelser.
Vi på Stormotion använder Epics för att beskriva mer komplexa uppgifter och skapa en tydlig hierarki som gör det lättare att hantera utvecklingen och leverera nytt värde till användarna samtidigt som man arbetar mot ett större mål. Ändå förblir användarhistorikformatet detsamma.,div id=”5d4080c6fe”>kan implementeras under några sprints
föreställ dig att du bygger en datingapp., awesome jag är
Så, Epos förse oss med en hög nivå av våra mål och hur vi är på väg mot dem., Det hjälper oss också under prioriteringsprocessen eftersom vi kan kontrollera vilka Epics som kräver vår uppmärksamhet mest och därför vilka historier som bör genomföras först.
Åh, en sak till!
glöm inte att lägga till ett godkännandekriterium.
ett godkännandekriterium är en uppsättning villkor som används för att bekräfta när en berättelse är klar.,
dessa villkor ger oss också en djupare och bättre förståelse eftersom de innehåller viktig information om hur berättelser fungerar. Låt oss återanvända ett exempel på användarhistoriken från början av artikeln:
vilka acceptanskriterier kan tillämpas på denna berättelse?
- appen visar drivrutiner som var online inom de senaste 20 minuterna och inte har en pågående åktur.
- appen visar endast 5 drivrutiner som är närmast användaren.
- en användare kan bläddra profiler av dessa drivrutiner, inklusive deras bilder och priser.
som du kan se, nu vet vi inte bara värdet av den här historien för användarna utan förstår också några viktiga egenskaper som kräver särskild uppmärksamhet under genomförandet.,
Du kan dock välja hur detaljerade dina acceptanskriterier kommer att vara. Det kan sträcka sig från ”bara låt det fungera på något bekvämt sätt” till ännu mer detaljerade uppsättningar av villkor än i exemplet ovan.
det beror mycket på ditt utvecklingsteam så det finns inget ”rätt svar”. Om ditt team behöver vägledning och tydliga, med-No-room-for-Tolkning uppgifter du skulle bättre hålla med detaljerade instruktioner om hur berättelser ska utföra. Annars kan tillvägagångssättet” bara få det gjort ” också fungera.,
Wow, det har sagts mycket om användarhistorier. Men varför är de så viktiga för smidiga lag?
vad är fördelarna med att skapa användarhistorier?
om du någonsin var involverad i att arbeta med smidiga ramar vet du redan att både Scrum och Kanban-lag har stor nytta av att skriva användarhistorier.,
i Kanban samlar lag berättelser i en eftersläpning och kör dem en efter en för att stödja arbetsflödet. Detta bidrar till att ständigt hålla sig på rätt spår och förbättra utvecklingsteam KPI.
Scrum (som vi brukar föredra på Stormotion) lag älskar också användarhistorier. Vi använder dem aktivt för att göra uppskattningar, prioritera och planera sprints som hjälper oss att hålla oss smidiga och flexibla för eventuella förändringar., Detta är särskilt fördelaktigt när vi arbetar med Startups som är på MVP-scenen och har begränsade resurser innan pitching sitt projekt till Angel investerare.
förutom ovan nämnda finns det några levande fördelar som är gemensamma för alla smidiga lag:
- Håll dig fokuserad på affärsvärdet., Det bidrar till att göra din app inte bara välbyggd ur det tekniska perspektivet utan också användbar för slutanvändarna.
- aktivera kreativitet. Eftersom det innehåller en minimal mängd information, ditt team är fri att driva kreativa idéer för att hitta den bästa lösningen för att genomföra en berättelse.
- ditt projekt blir mer hanterbart. Vi på Stormotion vet att det är ett sätt lättare att arbeta med små och uppskattningsbara smidiga användarhistorier snarare än med stora komplexa uppgifter.
- de inspirerar laget! Varje utvecklare älskar denna söta känsla av en liten vinst som motiverar honom att arbeta ännu hårdare.,
låt oss nu dyka in i processen att skapa en användarhistoria!
hur man skriver användarhistorier: vårt arbetsflöde
Vi kommer till den mest spännande delen av vår artikel. Men innan vi delar vår steg-för-steg-instruktion om att skriva en användarhistoria är det viktigt att räkna ut 2 viktiga frågor: vem och när gör dem.
vem är ansvarig för att skapa en användarhistoria?,
som tumregel skrivs berättelser huvudsakligen av produktägare eftersom det är deras ansvar att hålla eftersläpningen fylld med uppgifter. Men glöm inte att Agile är baserad på kommunikation och åsikter utbyte mellan experter. Så…
det betyder inte nödvändigtvis att de bara ska skrivas av en produktägare. Ju fler människor går med i konversationen, desto bättre.
Vid Stormotion skrivs berättelser av alla gruppmedlemmar som är relaterade till projektets affärssida (försäljningschefer, marknadsförare, produktägare etc.,), eftersom det låter oss titta på framtida app ur alla potentiella typer av användare. Produktägarens ansvar i detta fall är att bekräfta att de matchar INVESTERINGSKRITERIERNA.
när skapas användarhistorier?
ett historieskrivande möte i vårt HQ hålls vanligtvis nära projektets början., Vi föredrar att utrusta oss för att se till att ett projekt går bra från den första dagen till den sista.
senare kan vi använda vår Scrum-Användarberättelselista för att förbereda mer detaljerade uppskattningar (till exempel i slutet av upptäcktsfasen), prioritera funktionsutveckling för sprints och så vidare.
Vi kompletterar också den ursprungliga listan när vi arbetar med ett projekt med nya historier för att hålla oss uppdaterade med vår kunds krav.,
vilka är stegen för att skriva stora smidiga användarhistorier?
låt oss först påminna dig om en gemensam användarhistorik Mall:
som en, Jag vill så att
verkar kort och lätt att skriva. Förresten är du välkommen att skapa din egen Användarhistorikmall. Men vi på Stormotion har ett specifikt arbetsflöde som hjälper oss att leverera de bästa berättelserna:
- gör upp listan över dina slutanvändare. Definiera vad deras ”smärta ” eller” behov ” är, som du försöker lösa.
- definiera vilka åtgärder de kanske vill vidta.,
- ta reda på vilket värde detta kommer att ge användarna och, så småningom, till din produkt. Fråga dig själv-kommer någon fest att betala oss för detta?
- diskutera acceptanskriterier och en optimal genomförandestrategi.
låt oss titta över dem nu!
Steg 1: Tänk på ”vem”
detta är det första och kanske det mest grundläggande steget. Innan du skriver en användarhistoria borde du faktiskt veta vem slutanvändarna av din produkt är. Och viktigare – vad behöver de har, som du försöker täcka.,
under våra historieskrivande workshops försöker vi utelämna att använda en sådan roll som helt enkelt ”användaren”. Det kan tillämpas på någon person – från dina kunder till administratörer – och därför återspeglar det inte personligheten hos särskilda målgrupper, hur de interagerar med ansökan.
om du vill uppnå riktigt bra resultat kanske du vill dyka in i din publik ännu mer., Istället för att bara namnge användare efter deras roll (till exempel ”en förare”) försöker skapa någon form av en köpare persona.
här är några fler tips från vår egen erfarenhet:
- Det handlar om användaren. Inte om Utvecklare. Och inte ens om en produktägare. Varje berättelse bör vara värdefull för någon grupp av dina slutanvändare.
- tänk inte bara på användare som externa kunder. Det är sant att dina berättelser kommer att vara mest om dem. Men det är också sant att du måste överväga interna användare som administratörer, redaktörer etc.
- känna lite empati. Ge din” användare ” ett namn., Tänk på hans mobila vanor, vilken fråga din app kommer att få lösas för honom och hur du kommer att göra denna väg enklare och snabbare. Kom ihåg några människor som du känner från det verkliga livet och som passar detta porträtt; känna hur du relaterar till denna målgrupp.
steg 2: Tänk på ”vad”
nu har vi några grupper av slutanvändare. Nästa steg vi gör är att definiera vilken funktionalitet varje användare förväntar sig, hur han kommer att interagera med appen.,
det här är de viktigaste reglerna att komma ihåg när du skriver en åtgärd för en Kanban-eller Scrum-användarhistoria:
- en åtgärd per en berättelse. Om du vill skriva något som ”som kund vill jag bläddra i objekt och lägga till dem i vagnen” du skulle bättre dela upp den i 2 separata berättelser.
- Beskriv en avsikt, inte en funktion., Till exempel, i stället för ”jag vill hantera min profil” skapa några historier som” jag vill kunna registrera”,” jag vill ladda upp mitt profilfoto”,” jag vill länka mitt kreditkort till min profil ” – varje berättelse kommer att ha ett annat värde.
- håll det kort. Användare bryr sig inte om vilket bibliotek du ska använda för att låta dem bläddra i listan över objekt så lämna alla tekniska detaljer åt sidan.
- Undvik att beskriva användargränssnittet. Vi har definierat historier som förhandlingsbara, minns du? Det är därför alla bra användar Story exempel inte innehåller några UI detaljer., Så försök inte att komponera något speciellt sätt att genomföra dem (vi gör det senare).
steg 3: Tänk på ”varför”
slutligen är den sista delen av vår användarhistoriska Mall dedikerad till ett värde som användarna får efter att ha utfört en åtgärd. Det kan tyckas som inte en stor sak, men det är ofta den mest knepiga delen av Användarhistorieutveckling.,
din sektion ska dock alltid motsvara dina mätvärden och KPI: er. Det bör antingen förbättra UX, öka retentionsfrekvensen, förkorta användarnas resa till problemlösningen eller vad som helst. Varje berättelse bör bidra något till det allmänna målet för din produkt.,
om du inte kan svara på vilket värde den här funktionen ger slutanvändare och din produkt också, gör du något fel.
det finns till exempel några exempel på användarhistorier med ett välskrivet värde för vårt pågående matbeställningsprogram:
- som kund vill jag få meddelanden när det finns nya heta erbjudanden så att jag aldrig missar de bästa erbjudandena. .
- som restaurangchef vill jag komplettera diskbeskrivningen i menyn med ett foto så att det ser mer attraktivt ut för kunderna. .,
steg 4: diskutera en historia
slutligen diskuterar vi alltid användarhistorier efter att de har skapats. Även om det verkar som inget att prata om.
under denna Q&en session ber vi Författaren av berättelsen att ge mer information eller klargöra något om det behövs. Det hjälper oss att förstå hur det ska fungera och komma överens om acceptanskriterier., På så sätt granskar vi alla användarhistorier i mobilappen en efter en.
då håller vi en brainstormingsession med hela teamet som arbetar med projektet. Det tillåter oss att ta reda på de bästa sätten att genomföra användarhistorier från tech perspektiv.
så det är hur man skriver användarhistorier i ett nötskal. Vår Stormotion Squad använder också följande tips när du arbetar med den här uppgiften:
- börja med Epics., Det är vanligtvis lättare att flytta från mer komplexa uppgifter till mer specifika, så försök skriva Epics och dela dem sedan i historier.
- lyssna på feedback. Ibland behöver du inte gissa historier-fråga dina riktiga slutanvändare för feedback och använd deras idéer som inspirationskälla.
- introducera inte Detaljer för tidigt. Det är bättre att hålla brainstormingsessionen före varje sprint för att diskutera hur man genomför planerade berättelser.
slutsats
användarhistorier är en viktig del av det smidiga tillvägagångssättet som kan ge många fördelar för ditt projekt., Det är dock viktigt att skriva dem korrekt vilket kräver lite tid och färdigheter.,T kriterier, vilket innebär att de är:
- oberoende
- Förhandlingsbar
- värdefull
- uppskattningsbar
- liten
- testbar
den gemensamma användarhistoriska mallen innehåller användaren, åtgärden och värdet (eller fördelen) och ser vanligtvis ut så här:
användarhistorier kan hjälpa dig att ständigt förbättra värdet på din produkt, uppskatta utvecklingsinsatser på ett lämpligt sätt och prioritera funktionsutveckling under MVP-och post-MVP-stegen.,
