Om du sysslar med mjukvaruutveckling måste du ha hört talas om användarberättelser. Kanske skriver du dem till och med som chef. Eller så är du kund och din programvaruutvecklare vill att du ska formulera funktionsförfrågningar som user stories.

I det här inlägget hittar du allt du någonsin velat veta om user stories.

Vad är en user story inom programvaruutveckling?

En user story är ett format för att formulera programvarufunktioner och/eller krav. Som ”användaren” antyder är användarberättelser skrivna i första person singular och beskriver en funktion så som den uppfattas av appens användare.

En typisk användarberättelse följer den här strukturen (om vi talar om den agila utvecklingsprocessen):

Som ,
Jag vill ,
Så att .

Den första delen (som en…) anger användarens roll i programmet, vilket normalt är förknippat med vad man får göra där.

Den andra delen (funktionen) pekar på den funktionalitet som används i det här fallet.

Den tredje delen (det önskade resultatet) är det värde som användaren vill få ut av funktionen. Här är några exempel.

Exempel 1

Som registrerad användare vill
jag bli underrättad när en vän ska gå på ett evenemang i närheten
Så att jag kan reagera på nyheten eller ansluta mig till dem på evenemanget.

Exempel 2

Som passagerare
vill jag få 10 % rabatt på var tionde resa
Så att jag belönas för att jag konsekvent spenderar pengar på tjänsten.

Det finns goda skäl för denna typ av struktur. När produkt-/projektansvariga hanterar programvarukrav som kommer från olika källor är det ibland svårt för dem att uppnå enhetlighet. Vilken kategori av användare funktionen täcker eller var affärsvärdet ligger kan också vara oklart. Formatet user story hjälper till att fånga dessa kritiska detaljer.

Approach to Composing User Stories

User stories kan skrivas på olika sätt, beroende på vem som ska arbeta med dem.

The Gherkin Way

Gherkin är ett klartextspråk som beskriver ett beteende utan att specificera dess implementering. Här är ett enkelt exempel på Gherkin-syntaxen:

Feature: Guest contributor functionality
In order to contribute to blog XXY
As a guest author
I want to be able to publish articles on the website


Scenario: I edit my own article
Given I am a contributor
And I am logged in to my account
When I am on a separate article page
And I am the author of this article
Then I can see the "edit" button
And I can click it
And I can use a popup interface for editing my article

Scenario: I edit somebody else's article
Given I am a contributor
And I am logged in to my account
When I am on a separate article page
And I am NOT the author of this article
Then I CANNOT see the "edit" button

Som du kanske har märkt definierar indrag strukturen i Gherkin. De grundläggande parametrarna är Given/When/Then, och dessa kan vid behov kompletteras med flera And’s. Syntaxen går dock längre än dessa grundläggande parametrar. Om du verkligen är fast besluten att behärska Gherkin finns här en trevlig handledning.

Men även om Gherkin kanske inte är det bästa valet när du samlar in de första kraven för projektet kan det vara fördelaktigt (särskilt för QA-teamet) när du vidareutvecklar user stories. Användarberättelser som skrivs i Gherkin är lätta att konvertera till testfall.

Det agila sättet

Många program för agil projekthantering erbjuder en funktion för att skriva in användarberättelser. Vi har till exempel använt Taiga-appen i några av våra interna projekt. Den hjälper dig att organisera arbetet kring användarhistorier som kan delas upp i enskilda uppgifter i backloggen.

Källa: Om du tänker efter är det helt logiskt att ha användarhistorier som backlog-objekt och sedan lägga till flera uppgifter till en användarhistoria. Varför det? Därför att, låt oss säga att du har en funktion (=användarhistoria) och tre personer som arbetar med den; du behöver separata uppgifter för dessa personer. Du behöver en designer för att utforma gränssnittet, en HTML/JavaScript-programmerare för att programmera gränssnittet och DevOps för att släppa gränssnittet i produktion.

Andra verktyg som Pivotal Tracker (som introducerar begreppet ”epics” för att gruppera relaterade berättelser tillsammans) låter dig också skapa berättelser som kan vara av olika typer: Funktioner, arbetsuppgifter, fel eller utgåvor.

Källa: Det finns ett enkelt och okomplicerat sätt att formulera användarberättelser – exempel på detta såg du i början av det här inlägget.

Vem ska skriva användarberättelser?

Vems ansvar är det då att skriva användarberättelser? Tja, det beror på. Om ditt team har kommit överens om att fånga funktioner i form av användarberättelser är det mest troligt att de kommer från aktieägarna genom produktägaren. Så det kan vara PO som faktiskt skriver ner dem.

Det kan också vara en projektledare eller en QA som kanske också arbetar med kunden för att diskutera funktioner och krav. Eller kanske du är en 15-personers startup och du är VD, CTO och CMO? I det här fallet kan du föregå med gott exempel och börja använda user stories för att dokumentera funktioner.

Många inom IT talar också om ”user story development”, vilket är en process där man först registrerar detaljer på hög nivå (t.ex. börjar med en enkel lista över funktioner) och sedan utvecklar dem till mer detaljerade berättelser genom att lägga till uppgifter, scenarier osv.

Slutsatser

I slutändan hjälper det dig att hålla fokus på affärsmålen genom att formulera funktioner i form av user stories. Det hjälper dig också att göra kraven fullständiga. Och som sagt, den exakta mallen/fälten du använder kan vara olika, beroende på situationen.