användarhistorier

Vad är en användarhistoria?

användarhistorier är korta, enkla beskrivningar av en funktion som berättas ur den person som önskar den nya kapaciteten, vanligtvis en användare eller kund av systemet. De följer vanligtvis en enkel mall:

som en , Jag vill så .

användarhistorier skrivs ofta på indexkort eller klisterlappar, lagras i en skokartong och arrangeras på väggar eller bord för att underlätta planering och diskussion., Som sådan skiftar de starkt fokus från att skriva om funktioner för att diskutera dem. I själva verket är dessa diskussioner viktigare än vad text skrivs.

kan du visa några exempel på användarhistoria?

en av fördelarna med smidiga användarhistorier är att de kan skrivas på olika detaljnivåer. Vi kan skriva en användarhistoria för att täcka stora mängder funktionalitet. Dessa stora användarhistorier är allmänt kända som epics. Här är ett episkt agile user story-exempel från en stationär säkerhetskopieringsprodukt:

• som användare kan jag säkerhetskopiera hela min hårddisk.,

eftersom en episk är i allmänhet för stor för ett agile team att slutföra i en iteration, delas den upp i flera mindre användarhistorier innan det fungerar på. Epic ovan kan delas upp i dussintals (eller möjligen hundratals), inklusive dessa två:

• som en strömanvändare kan jag ange filer eller mappar för säkerhetskopiering baserat på filstorlek, datum skapat och datum modifierat.
• som användare kan jag ange att mappar inte ska säkerhetskopieras så att min backup-enhet inte fylls i med saker som jag inte behöver sparas.

hur läggs detalj till i användarhistorier?,

detalj kan läggas till användarhistorier på två sätt:

• genom att dela upp en användarhistoria i flera mindre användarhistorier.
• genom att lägga till ”villkor för tillfredsställelse.”

när en relativt stor historia delas upp i flera, mindre smidiga användarhistorier är det naturligt att anta att detaljer har lagts till. När allt kommer omkring har mer skrivits.

villkoren för tillfredsställelse är helt enkelt en hög nivå acceptanstest som kommer att vara sant efter den smidiga användarhistorien är klar., Tänk på följande som ett annat agile user story-exempel:

som vicepresident för marknadsföring vill jag välja en semestersäsong som ska användas när jag granskar resultatet av tidigare reklamkampanjer så att jag kan identifiera lönsamma.

detalj kan läggas till att användaren story exempel genom att lägga till följande villkor för tillfredsställelse:

• se till att det fungerar med stora retail helgdagar: jul, påsk, presidentens dag, mors dag, fars dag, Labor Day, nyårsdagen.
• Support helgdagar som sträcker sig över två kalenderår (ingen spänner över tre).,
• semester säsonger kan ställas in från en semester till nästa (t.ex. Thanksgiving till jul).
• semester säsonger kan ställas in för att vara ett antal dagar före semestern.

vem skriver användarhistorier?

vem som helst kan skriva användarhistorier. Det är produktägarens ansvar att se till att en produkt eftersläpning av smidiga användarhistorier finns, men det betyder inte att produktägaren är den som skriver dem. Under loppet av en bra smidig projekt, du bör förvänta dig att ha användar story exempel skrivna av varje gruppmedlem.,

Observera också att vem som skriver en användarhistoria är mycket mindre viktig än vem som är inblandad i diskussionerna om den.

när skrivs användarhistorier?

användarhistorier skrivs under hela det agila projektet. Vanligtvis hålls en historieskrivande verkstad nära början av det smidiga projektet. Alla i teamet deltar med målet att skapa en produkt eftersläpning som helt beskriver funktionaliteten som ska läggas till under projektets gång eller en tre – till sex månaders frigöringscykel inom den.

några av dessa smidiga användarhistorier kommer utan tvekan att vara epics., Epics kommer senare att sönderdelas i mindre historier som passar lättare in i en enda iteration. Dessutom kan nya historier skrivas och läggas till produktstocken när som helst och av någon.

ersätter användarhistorier ett kravdokument?

smidiga projekt, särskilt Scrum sådana, använder en produkt eftersläpning, som är en prioriterad lista över de funktioner som ska utvecklas i en produkt eller tjänst. Även produkt eftersläpning objekt kan vara vad laget önskar, användarhistorier har dykt upp som den bästa och mest populära formen av produkt eftersläpning objekt.,

medan en produkt eftersläpning kan ses som en ersättning för kravdokumentet för ett traditionellt projekt, är det viktigt att komma ihåg att den skriftliga delen av en smidig användarhistoria (”som användare vill jag …”) är ofullständig tills diskussionerna om den historien uppstår.

det är ofta bäst att tänka på den skriftliga delen som en pekare till det verkliga kravet. Användarhistorier kan peka på ett diagram som visar ett arbetsflöde, ett kalkylblad som visar hur man utför en beräkning, eller någon annan artefakt produktägaren eller laget önskar.,

rekommenderade resurser relaterade till användarhistorier

• fördelar med ”som användare vill jag ha” användarhistorikmall.,
• ett Provformat för ett kalkylblad-baserad produkt eftersläpning
• fördelar med användarhistorier för krav
• icke-funktionella krav som användarhistorier
• introduktion till användarhistorier

kurser relaterade till användarhistorier

gratis nedladdning: 200 Användarhistoriexempel

få ett skott av inspiration och spara tid att skriva användarhistorier genom att se exempel skrivna och används av Mike Cohn.