Användarberättelse

Inom mjukvaruutveckling och produkthantering är en användarberättelse en informell, naturlig språkbeskrivning av funktioner i ett mjukvarusystem. De är skrivna från en slutanvändares eller användares perspektiv och kan registreras på registerkort, Post-it-lappar eller digitalt i projektledningsprogram. Beroende på projektet kan användarberättelser skrivas av olika intressenter som klient, användare, chef eller utvecklingsteam.

Användarberättelser är en typ av gränsobjekt . De underlättar meningsskapande och kommunikation; och kan hjälpa programvaruteam att dokumentera sin förståelse av systemet och dess sammanhang.

Historia

1997: Kent Beck introducerar användarberättelser vid Chrysler C3-projektet i Detroit.
1998: Alistair Cockburn besökte C3-projektet och myntade frasen "En användarberättelse är ett löfte för en konversation."
1999: Kent Beck publicerade den första upplagan av boken Extreme Programming Explained , och introducerade Extreme Programming (XP) och användningen av användarberättelser i planeringsspelet .
2001: Ron Jeffries föreslog en "Three Cs"-formel för att skapa användarberättelser:
- Kortet (eller ofta en post-it - lapp ) är en påtaglig fysisk symbol för att hålla begreppen;
- Samtalet är mellan intressenterna (kunder, användare, utvecklare, testare, etc.) . Den är verbal och ofta kompletterad med dokumentation;
- Bekräftelsen säkerställer att målen för samtalet har uppnåtts .
2001: XP-teamet på Connextra i London utformade användarberättelseformatet och delade exempel med andra.
2004: Mike Cohn generaliserade principerna för användarberättelser utöver användningen av kort i sin bok User Stories Applied: For Agile Software Development som nu anses vara standardreferensen för ämnet enligt Martin Fowler . Cohn namnger Rachel Davies som uppfinnaren av användarberättelser. ^{[ citat behövs ]} Medan Davies var en teammedlem på Connextra, tillskriver hon laget som helhet uppfinningen. ^{[ citat behövs ]}
2014: Efter en första artikel 2005 och ett blogginlägg 2008 publicerade Jeff Patton 2014 tekniken för kartläggning av användarberättelser, som avser att med ett systematiskt tillvägagångssätt förbättra identifieringen av användarberättelser och att strukturera berättelserna för att ge bättre synlighet till deras ömsesidiga beroende.

Princip

Användarberättelser skrivs av eller för användare eller kunder för att påverka funktionaliteten i systemet som utvecklas. I vissa team är produktchefen (eller produktägaren i Scrum ), primärt ansvarig för att formulera användarberättelser och organisera dem i en produktbacklog . I andra team kan vem som helst skriva en användarberättelse. Användarberättelser kan utvecklas genom diskussion med intressenter, baserat på personas eller helt enkelt påhittade.

Vanliga mallar

Användarberättelser kan följa ett av flera format eller mallar.

Den vanligaste är Connextra-mallen , som anges nedan. Mike Cohn föreslog att klausulen "så att" är valfri men fortfarande ofta till hjälp.

Som en jag kan , så att

Chris Matts föreslog att "jaga värdet" var det första steget för att framgångsrikt leverera programvara, och föreslog detta alternativ:

För att som en , Jag kan

En annan mall baserad på Five Ws specificerar:

Som , Jag vill därför att

En mall som vanligtvis används för att förbättra säkerheten kallas "Evil User Story" eller "Abuse User Story" och används som ett sätt att tänka som en hackare för att överväga scenarier som kan inträffa i en cyberattack. Dessa berättelser är skrivna utifrån perspektivet av en angripare som försöker kompromissa eller skada applikationen, snarare de typiska personligheterna som finns i en användarberättelse:

Som missnöjd anställd vill jag utplåna användardatabasen för att skada företaget

Exempel

Screeningquiz (episk story): Som HR-chef vill jag skapa ett screeningquiz så att jag kan förstå om jag vill skicka eventuella rekryter till funktionschefen.

Återkallelse av frågesport: Som chef vill jag bläddra bland mina befintliga frågesporter så att jag kan komma ihåg vad jag har på plats och ta reda på om jag bara kan återanvända eller uppdatera en befintlig frågesport för den position jag behöver nu.

Begränsad backup: Som användare kan jag indikera mappar som inte ska säkerhetskopieras så att min backup-enhet inte fylls upp med saker jag inte behöver sparas.

Användande

En central del av många agila utvecklingsmetoder, som i extrem programmerings planeringsspel , beskriver användarberättelser vad som kan byggas i mjukvaruprojektet. Användarberättelser prioriteras av kunden (eller produktägaren i Scrum ) för att indikera vilka som är viktigast för systemet och kommer att brytas ner i uppgifter och uppskattas av utvecklarna. Ett sätt att uppskatta är via en Fibonacci-skala .

När användarberättelser är på väg att implementeras bör utvecklarna ha möjlighet att prata med kunden om det. Novellerna kan vara svårtolkade, kan kräva viss bakgrundskunskap eller kraven kan ha ändrats sedan berättelsen skrevs.

Användarberättelser kan utökas för att lägga till detaljer baserat på dessa konversationer. Detta kan innefatta anteckningar, bilagor och acceptanskriterier.

Acceptanskriterier

Mike Cohn definierar acceptanskriterier som "anteckningar om vad berättelsen måste göra för att produktägaren ska acceptera den som komplett." De definierar gränserna för en användarberättelse och används för att bekräfta när en berättelse är färdig och fungerar som avsett.

Lämplig mängd information som ska ingå i acceptanskriterierna varierar beroende på team, program och projekt. Vissa kan inkludera "föregångarekriterier", "Användaren har redan loggat in och har redan redigerat sin information en gång". ^{[ Detta citat behöver ett citat ]} Vissa kanske skriver acceptanskriterierna i typiskt agilt format, Given-When-Then . Andra kan helt enkelt använda punktpunkter hämtade från ursprungliga krav som samlats in från kunder eller intressenter. ^{[ citat behövs ]}

För att en berättelse ska anses vara gjord eller komplett måste alla acceptanskriterier vara uppfyllda.

Fördelar

Det finns inga bra bevis för att användningen av användarberättelser ökar mjukvarans framgång eller utvecklarnas produktivitet. Användarberättelser underlättar dock sensemaking utan onödig problemstrukturering, vilket är kopplat till framgång.

Begränsningar

Begränsningar för användarberättelser inkluderar:

Uppskalningsproblem : Användarberättelser skrivna på små fysiska kort är svåra att underhålla, svåra att skala till stora projekt och besvärliga för geografiskt distribuerade team.
Vaga, informella och ofullständiga : Användarberättelsekort betraktas som konversationsstartare. Eftersom de är informella är de öppna för många tolkningar. För att vara kortfattade anger de inte alla detaljer som behövs för att implementera en funktion. Berättelser är därför olämpliga för att nå formella överenskommelser eller skriva juridiska kontrakt.
Brist på icke-funktionella krav : Användarberättelser innehåller sällan prestanda eller icke-funktionella kravdetaljer, så icke-funktionella tester (t.ex. svarstid) kan förbises.
Representerar inte nödvändigtvis hur tekniken måste byggas: Eftersom användarberättelser ofta skrivs ur affärsperspektivet, när ett tekniskt team börjar implementera, kan det upptäcka att tekniska begränsningar kräver ansträngningar som kan vara bredare än omfattningen av en enskild berättelse . Att ibland dela upp berättelser i mindre kan hjälpa till att lösa detta. Andra gånger är "bara tekniska" berättelser mest lämpliga. Dessa "bara tekniska" berättelser kan utmanas av affärsintressenterna eftersom de inte levererar värde som kan demonstreras för kunder/intressenter.

Relation till epos, teman och initiativ/program

I många sammanhang används användarberättelser och även sammanfattade i grupp av ontologiska, semantiska och organisatoriska skäl. Initiativ kallas också Program i vissa skalade agila ramverk. De olika användningsområdena beror på synvinkeln, t.ex. att se antingen ur ett användarperspektiv som produktägare i förhållande till funktioner eller ett företagsperspektiv i förhållande till uppgiftsorganisation.

En berättelsekarta i aktion, med epos på toppen för att strukturera berättelser

Medan vissa föreslår att använda "episkt" och "tema" som etiketter för alla tänkbara typer av gruppering av användarberättelser, tenderar organisationsledningen att använda det för att starkt strukturera och förena arbetsbelastningar. Till exempel Jira använda en hierarkiskt organiserad att-göra-lista , där de namngav den första nivån av att göra-uppgifter "användarberättelse", den andra nivån "epos" (gruppering av användarberättelser) och den tredje nivå 'initiativ' (gruppering av epos). Initiativ är dock inte alltid närvarande i produktledningsutvecklingen och lägger bara till ytterligare en nivå av granularitet. I Jira finns "teman" (för spårningsändamål) som gör det möjligt att korsrelatera och gruppera objekt från olika delar av den fasta hierarkin .

I den här användningen ändrar Jira betydelsen av teman i ett organisationsperspektiv: t.ex. hur mycket tid lade vi ner på att utveckla temat "xyz". Men en annan definition av teman är: en uppsättning berättelser, epos, funktioner etc för en användare som bildar en gemensam semantisk enhet eller mål . Det finns förmodligen inte en gemensam definition eftersom det finns olika tillvägagångssätt för olika stilar av produktdesign och utveckling. I denna mening föreslår vissa också att inte använda någon form av hårda grupper och hierarkier.

Tema

Flera epos eller många mycket stora berättelser som är nära besläktade sammanfattas som teman. En vanlig förklaring av epos är också: så mycket arbete som kräver många spurter, eller i skalade ramar - ett Release Train eller Solution Train.

Initiativ

Flera teman, epos eller berättelser grupperade hierarkiskt.

Episk

Flera teman eller berättelser grupperade efter ontologi och/eller semantiskt förhållande.

Berättelsekarta

Kartläggning av användarberättelser

En berättelsekarta organiserar användarberättelser enligt ett narrativt flöde som presenterar den stora bilden av produkten. Tekniken utvecklades av Jeff Patton från 2005 till 2014 för att hantera risken för projekt som översvämmas av mycket detaljerade användarberättelser som distraherar från att förverkliga produktens huvudmål. ^{[ citat behövs ]}

Kartläggning av användarberättelser använder workshops med användare för att först identifiera de huvudsakliga affärsaktiviteterna. Var och en av dessa huvudaktiviteter kan involvera flera typer av användare eller personas.

Den horisontella tvärgående narrativa linjen dras sedan genom att identifiera huvuduppgifterna för den enskilda användare som är involverad i dessa affärsaktiviteter. Linjen hålls under hela projektet. Mer detaljerade användarberättelser samlas in och samlas in som vanligt med användarberättelsepraxis. Men varje ny användarberättelse infogas antingen i det narrativa flödet eller relateras vertikalt till en huvuduppgift.

Den horisontella axeln motsvarar täckningen av produktmålen och den vertikala axeln motsvarar de individuella användarnas behov.

På så sätt blir det möjligt att beskriva även stora system utan att tappa helheten.

Berättelsekartor kan enkelt ge en tvådimensionell grafisk visualisering av produktbackloggen : Överst på kartan finns rubrikerna under vilka berättelser grupperas, vanligtvis kallade "epos" (stora, grovkorniga användarberättelser), "teman" (samlingar av relaterade användarberättelser) eller "aktiviteter". Dessa identifieras genom att orientera sig mot användarens arbetsflöde eller "ordningen du skulle förklara systemets beteende". Vertikalt, under eposerna, tilldelas och ordnas de faktiska berättelsekorten efter prioritet. Den första horisontella raden är ett "vandrande skelett" och nedanför representerar det ökande sofistikering. ^{[ förtydligande behövs ]}

Användarresakarta

En användarresekarta avser att visa helheten men för en enskild användarkategori. Dess narrativa linje fokuserar på kronologin av faser och åtgärder som en enskild användare måste utföra för att uppnå sina mål.

Detta gör det möjligt att kartlägga användarupplevelsen bortom en uppsättning användarberättelser. Baserat på feedback från användare kan de positiva och negativa känslorna identifieras under hela resan. Friktionspunkter eller ouppfyllda behov kan identifieras på kartan. Denna teknik används för att förbättra designen av en produkt, vilket gör det möjligt att engagera användare i deltagande metoder.

Jämföra med användningsfall

Ett användningsfall har beskrivits som "en generaliserad beskrivning av en uppsättning interaktioner mellan systemet och en eller flera aktörer, där en aktör är antingen en användare eller ett annat system." Även om användarberättelser och användningsfall har vissa likheter, finns det flera skillnader mellan dem.

	Användarberättelser	Användningsfall
Likheter	Generellt formulerad i användarnas vardagsspråk. De ska hjälpa läsaren att förstå vad programvaran ska åstadkomma.	Skrivet på användarnas vardagliga affärsspråk, för att underlätta kommunikation med intressenter.
Skillnader	Tillhandahålla en småskalig och lättanvänd presentation av information, med små detaljer, och förbli således öppen för tolkning, genom samtal med kunder på plats.	Användningsfall organiserar krav för att bilda en berättelse om hur användare förhåller sig till och använder ett system. Därför fokuserar de på användarens mål och hur interaktion med ett system uppfyller målen. Användningsfallsflöden beskriver sekvenser av interaktioner och kan formuleras i termer av en formell modell. Ett användningsfall är avsett att ge tillräckliga detaljer för att det ska förstås på egen hand.
Mall	Som en , Jag kan så att .	Titel: "mål som användningsfallet försöker uppfylla" Huvudframgångsscenario: numrerad lista med steg Steg: "en enkel beskrivning av interaktionen mellan skådespelaren och ett system" Extensions: separat numrerade listor, en per Extension Extension: "ett tillstånd som resulterar i olika interaktioner från .. det huvudsakliga framgångsscenariot". En anknytning från huvudsteg 3 är numrerad 3a osv.

Kent Beck , Alistair Cockburn , Martin Fowler och andra diskuterade detta ämne vidare på c2.com-wikin (hemmet för extrem programmering) .

Se även

Vidare läsning

Daniel H. Steinberg, Daniel W. Palmer, Extreme Software Engineering , Pearson Education, Inc., ISBN 0-13-047381-2 .
Mike Cohn, User Stories Applied , 2004, Addison Wesley, ISBN 0-321-20568-5 .
Mike Cohn, Agile Estimating and Planning , 2006, Prentice Hall, ISBN 0-13-147941-5 .
Affärsanalytikertid
Payton Consulting "Hur användarhistorier skiljer sig från IEEE-krav