en av de största utmaningarna i mjukvaruutveckling är den nästan omöjliga uppgiften att samla tydliga krav och sedan få dessa krav att förbli oförändrade under kodutvecklingen. I vattenfall inställning till mjukvaruutveckling-trots ansträngningar att definiera, dokumentera och godkänna alla möjliga oförutsedda innan utvecklingen börjar-den levererade produkten är sällan vad kunden vill.
det smidiga alternativet? Skapa användarhistoria.,
en av de största fördelarna med att använda en smidig inställning till mjukvaruutveckling är att kraven inte ställs i sten, utan i stället förväntas förändras, med konstant feedback från intressenter och företag. Agila metoder som Scrum och extreme programming (XP) ersätter traditionella, långa krav dokument med en prioriterad produkt eftersläpning består av koncisa användarhistorier, vars detaljer kommer närmare när historien är redo att genomföras.,
även om användarhistorikskapande är mer konst än vetenskap, kommer den här handledningen att ge dig information, exempel och steg som du behöver för att skapa användarhistorier av hög kvalitet.
historien om användarhistorier
XP introducerade först begreppet användarhistorier 1998 och jämförde dem för att använda kundcase. Ivar Jacobson introducerade användningsfall som ett sätt att dokumentera krav genom att definiera interaktioner mellan en roll (en person som använder systemet) och själva systemet för att uppnå ett mål med hjälp av Unified Modeling Language (UML).,
denna metod var populär i objektorienterad utveckling och används fortfarande som en nyckelprocess i mjukvaruutvecklingsramar, såsom Unified Process (UP), IBM Rational Unified Process (RUP) och Oracle Unified Method (OUM). Användning av användningsfall, snarare än användarhistorier, möjliggör iterativ och inkrementell utveckling och anses vara en smidig inställning till kravdefinition.,
med introduktionen av de mycket kortare användarhistorierna och populariteten hos XP och Scrum blev en produktback som bestod av användarhistorier det mer allmänt kända tillvägagångssättet för agile requirements definition. Många utövare tror fortfarande att användarhistorier är det enda acceptabla smidiga tillvägagångssättet. Alistair Cockburn, en av de Agile manifest undertecknarna, föredrar dock använda fall till användarhistorier.
även om det finns gott om starka åsikter om betydelsen av ”agile”, är både användningsfall och användarhistorier kompatibla med det tillvägagångssättet., Vissa säger att användarhistorier så småningom blir liknande att använda fall när laget är överens om detaljerna i genomförandet. I de tidiga stadierna är användarhistorien helt enkelt en kort mening, men den är inte komplett förrän detaljerna och acceptanskriterierna definieras.
skapa användarhistorier
det finns olika åsikter om definitionen av en användarhistoria och hur man bäst går om att skapa en., Några riktlinjer för en bra användarhistoria inkluderar följande:
- Det ska skrivas av någon som representerar företagsanvändare (vanligtvis produktägaren)
- Det bör inledningsvis innehålla korta beskrivningar av ”vem, vad och varför”, men inte ”hur”
- Det ska producera en vertikal skiva arbetskod
- Det ska vara tillräckligt liten för att det kan kodas och testas i en iteration (vanligtvis en en-till-fyra-veckorsperiod)
olika mallar, tekniker och akronymer används för att hjälpa produktägare att skriva användarhistorier., Tre av de vanligaste teknikerna är role-feature-reason Mall, De tre C: erna (kort, konversation, bekräftelse) och INVEST (oberoende, förhandlingsbar, värdefull, uppskattningsbar, liten, testbar).
exempel
säg att du utvecklar ett program som gör det möjligt för utbildare att ladda upp kursmaterial och locka studenter som är intresserade av att ta en klass. Här är hur du skulle tillämpa användar story tekniker.,
Role-Feature-Reason
som Mike Cohn av Mountain Goat Software förklarar, Roll-feature-reason mall, eller RGB (Roll, mål, nytta), ser ut så här:
”som en Jag vill så att .”
Även om det finns variationer, håller denna korta meningsstruktur fokus på vem, vad och varför. Detta hindrar produktägaren från att ge utvecklingsteamet för mycket information om hur de ska genomföra en lösning. Genom att fokusera på who, vad, och varför, utvecklingsteamet har befogenhet att hitta den bästa tekniska lösningen.,
exempel 1: Ge en tränare möjlighet att lägga till en kurs
som tränare vill jag kunna lägga till en ny kurs så att jag har potential att locka nya studenter.
exempel 2: Ge en student möjlighet att söka efter en kurs
som student, skulle jag vilja kunna söka kurserbjudanden, så att jag kommer att kunna hitta ett erbjudande som mest intresserar mig.
rollen (who)
rollen beskriver vem som kommer att dra nytta av den här funktionen. Observera att rollen inte bara är ” användaren.,”Det finns olika typer av användare, och så vill vi att rollen ska vara mer specifik än ”användare” men beskriva vilken typ av användare som kommer att dra nytta av historien. Produktägare har ofta till uppgift att komma i sina användares sinne för att förstå vad som skulle vara mest värdefullt för dem.
exempel 1 Roll = tränare
exempel 2 Roll = student
funktionen (Vad)
det här steget beskriver mycket kortfattat vad användaren vill ha. Detta representerar närmast det krav som du beskriver i traditionell mjukvaruutveckling., Men du vill vara försiktig så att du inte är för specifik eller beskriver hur du skriver koden. Det kommer att bestämmas så småningom, men inte när du först skapar användarhistorien. Användarhistorien ska skrivas ur användarens perspektiv som kommer att dra nytta av funktionen, inte ur utvecklarens perspektiv som kommer att koda den.
exempel 1 Feature = Lägg till en ny kurs
exempel 2 Feature = sök kurserbjudanden
anledningen (varför)
slutligen vill vi ange varför användaren vill ha den här funktionen. Vilket värde kommer användaren att få från det?, Detta hjälper produktägaren att utvärdera hur man prioriterar användarhistorien på eftersläpningen. Om värdet eller nyttan inte kan artikuleras kan det vara något som inte är nödvändigt. Att förstå värdet hjälper ofta utvecklingsteamet att hitta innovativa sätt att implementera koden för att lösa de objektiva sätt som kan skilja sig från vad produktägaren har i åtanke.,
exempel 1 Reason = attract new students
exempel 2 Reason = find an offer that most interests me
The Three C ’S: Card, Conversation, Confirmation
the Three C’ S formula, utvecklad av Ron Jeffries, hjälper till att nå en överenskommelse mellan företaget och det tekniska laget om innebörden av användarhistorien. De tre C: s vägleda dem genom den progressiva utarbetandet av en berättelse, från ett kort uttalande till en fullt utvecklad användarhistoria.,
kort
användarhistoriken börjar avsiktligt kort, med ett enkelt uttalande som kan passa på ett 3×5-indexkort, som vanligtvis följer det Roll-feature-benefit-format som jag just täckte. Till exempel:
som tränare vill jag kunna lägga till en ny kurs så att jag har potential att locka nya studenter.
konversation
även om användarhistoriken börjar som ett enkelt uttalande måste detaljer dyka upp innan laget börjar arbeta med historien., I stället för att beskriva vad som behövs i dokumentationen kommer laget att innehålla 1) representation från verksamheten (vanligtvis produktägaren) och 2) utvecklingsteamet själv, inklusive utvecklare, testare, affärsanalytiker eller någon annan i laget.
denna konversation gör det möjligt för utvecklingsteamet att ställa frågor för att säkerställa att de har en tydlig förståelse för vad som efterfrågas och värdet som tillhandahålls. Till exempel:
utvecklare: kommer tränaren att behöva ladda upp kursmaterialet på en webbplats?,
produktägare: Nej, tränaren kommer bara att lägga till information om kursen som kommer att erbjudas, och funktionen bör innehålla ett sätt för studenten att komma på en intresselista. Denna historia ger tränaren möjlighet att annonsera en kurs.
Utvecklare: vilka fält ska inkluderas?
produktägare: kurstitel, abstrakt, datum och tider, plats.
utvecklare: kommer detta bara att vara för reklam ansikte mot ansikte klasser?
produktägare: Ja., Vi kan lägga till ett virtuellt klassalternativ senare, men den här historien kommer bara att omfatta att lägga till kursinformation för ansikte mot ansikte klasserbjudanden.
Utvecklare: vilken information ska samlas in när en potentiell student ber om att få på en intresselista?
produktägare: namn, telefonnummer och e-postadress.
teamet kommer att uppdatera användarhistorien med den information de har samlat in från konversationen, och de kommer att diskutera implementeringen-eller ” hur ” – som ofta skapar specifika uppgifter som måste göras för att slutföra historien., Även om användarhistorien är skriven ur användarens perspektiv skriver utvecklingsteamet uppgifterna för utvecklarna och innehåller de tekniska implementeringsdetaljerna.
bekräftelse
utvecklingsteamet måste ha en klar förståelse för hur funktionen kommer att fungera i olika situationer, inklusive felförhållanden. De måste få bekräftelse på godkännandekriterierna från produktägaren. Det här är de kriterier som måste uppfyllas för att historien ska anses vara klar och accepterad., Här är ett exempel på acceptanskriterier:
- en tränare kan lägga till en ny kurs genom att ange kurstitel, abstrakt, datum och tider och plats i ett formulär och trycka på en ”Lägg till kurs” – knapp.
- om några fält saknas eller datum eller tider är ogiltiga visas felmeddelanden.
- när kursen väl har lagts till kommer den att visas offentligt på kursens hemsida och det kommer att finnas en knapp för en student att uttrycka intresse.,
- knappen intresse tillåter en användare att ange namn, e-postadress och telefonnummer, och dessa data kommer att lagras och associeras med den nya kursen.
INVEST: attributen för en solid användarhistoria
INVEST är en akronym som hjälper till att utvärdera om du har en användarhistoria av hög kvalitet. Så här gäller attributen i akronymen för den historia vi har arbetat med.
i = Independent—kan den här historien slutföras av laget? Vi vill att laget ska kunna slutföra hela historien snarare än att vara beroende av ett annat lag för att göra GUI, till exempel.,
N = Förhandlingsbar—historien är inte så detaljerad att den beskriver exakt hur länge fälten ska vara eller ge detaljer om datumformat och liknande. Mest sannolikt kommer det att finnas gemensamma rutiner eller bibliotek som gör det möjligt för utvecklingsteamet att genomföra på det sätt som är mest meningsfullt för dem.
v = värdefull – produktägaren beskriver att värdet som söks är förmågan för tränaren att kunna annonsera kommande klasser. Detta är tydligt i” Varför ” av det ursprungliga uttalandet och omprioriteras i konversationen.,
e = Estimable-laget kommer att ställa tillräckligt med frågor och samla detaljerna för att känna sig trygga i sin förmåga att uppskatta historien.
s = Small—laget måste känna sig säkra på att de kommer att kunna slutföra historien inom en sprint. Om de inte gör det, kan de dela upp historien. Till exempel, i vår provberättelse, kan de bestämma sig för att göra förmågan att samla studentinformationen till en annan historia och helt enkelt visa information om klassen för den här historien.
t = testbar—med tydliga acceptanskriterier kan både den lyckliga sökvägen och felförhållandena testas.,
anpassa till en vision
Jag har täckt grunderna för att skapa en användarhistoria, men du behöver fortfarande förstå den stora bilden innan du skapar dina egna användarhistorier. Det finns mycket arbete du måste göra på framsidan, på en högre nivå, för att avgöra vad de högsta värde funktioner som ska levereras till kunderna. De sönderdelas slutligen i användarhistorier.
det är viktigt för laget att först förstå den höga visionen och se till att funktionerna, och i slutändan användarhistorierna, anpassas till den höga visionen.,
vanligtvis bryter du ner produkten i grupperingar som går med namn som ”teman” eller ”funktioner.”Även om märkningen av dessa eftersläpningsobjekt kan skilja sig beroende på den smidiga metoden och verktygen du använder för att beskriva dem, är tanken att se till att de anpassar så att arbetet kan spåras upp till din vision, vilket säkerställer att du uppfyller målen och värdena för produktvisionen.
starta inte ett projekt igen genom att skapa användarhistorier.börja med att skapa en vision., I vårt exempel visar jag helt enkelt ett provvisionsuttalande, vilket leder till vissa provfunktioner, som ytterligare kan sönderdelas i användarhistorier.
Vision
tillhandahålla en högkvalitativ webbplats som gör det möjligt för utbildare att annonsera kurser och låta eleverna ta dessa kurser.
funktioner
- ge en kurserbjudande sida som gör det möjligt för studenter att anmäla sig till kurser.
- ge en hemsida som kommer att berätta för användarna vad vår webbplats handlar om.
- tillhandahålla en registreringsprocess som tillåter användare att logga in, skapa en profil och hålla reda på sina klasser.,
- ge en blogg som hjälper till att annonsera våra erbjudanden och få publicitet för vår hemsida.
användarhistorier
- ge tränare möjlighet att lägga till en kurs på kurserbjudande sidan.
- ge eleverna möjlighet att söka efter en kurs.
i exemplet ovan kan du se hur användarhistorierna uppstod. Användarhistorierna var en del av en funktion för att ”ge en kurserbjudande sida” som anpassar sig till högnivåvisionen.,
Impact mapping
även om anpassning till en vision kommer att hjälpa dig fylla din ursprungliga eftersläpning, det är inte det enda sättet att göra det. Det finns många verktyg och tekniker som produktchefer kan använda för att skapa de historier som går i en ny eftersläpning och som stämmer överens med visionen.
en strategisk planeringsteknik som används för att förstå helheten, impact mapping, populariserades av Gojko Adzic, författare till femtio snabba idéer för att förbättra dina användarhistorier och Impact Mapping: att göra en stor inverkan med mjukvaruprodukter och projekt., Impact mapping är en Tankekarta som börjar med målet, som bör ta itu med frågan om värde och varför du bygger produkten.
nästa nivå listar ”skådespelare” eller personer som hjälper till att uppnå målet. Därefter listar kartan de beteenden eller ”effekter” som aktörerna kommer att utföra för att uppnå det målet. Den slutliga nivån på kartan presenterar de” resultat ” som laget kan genomföra. Dessa möjliggör och stöder aktörerna att skapa önskade effekter. Det är från dessa leveranser som du härleda programfunktioner och berättelser.,
- mål: göra allmänt tillgängliga kurser som eleverna kommer att vilja ta
- aktörer: utbildare, studenter
- effekter: utbildare kommer att ge högkvalitativa klasser som är av intresse för studenter; studenter kommer att ge remisser och rekommendationer
- Deliverables: högkvalitativa klasser som är tillgängliga för studenter
- potentiella berättelser:
- ”som tränare vill jag annonsera klasser, så att jag kan få studenter.
- ” som tränare vill jag få feedback från studenter, så att jag ständigt kan förbättra.,”
- ”som tränare vill jag ta reda på vad eleverna vill ha, så jag kan lägga till i min läroplan.”
- ”som student vill jag hitta klasser som mest intresserar mig.”
- ” som student vill jag hitta klasser som jag kan ta online, så att jag inte behöver resa.”
- ” som student vill jag läsa recensioner från andra, så att jag kan bestämma vilka klasser som bäst passar mig.”
kartläggning av användarhistorier på detta sätt möjliggör spårbarhet i tankeprocessen om hur berättelserna i slutändan skapar värde och hur du använder dem för att uppnå slutmålet., Tanken är inte att genomföra allt, men att hitta den kortaste vägen genom kartan för att uppnå ditt mål.
dela upp berättelser
ett av de vanligaste problemen agila lag stöter på är när berättelser är för stora och inte kan slutföras i en iteration. När laget skapar de uppgifter som är förknippade med historien inser de att det finns för många okända, eller att de uppgifter som berörs tar mer tid än laget har tillgängligt i en enda iteration. Lag tar ibland upp detta genom att dela upp en större historia i mindre historier.,
kom dock ihåg att du vill att en användarberättelse ska leverera arbetsprogramvara som ger användaren ett mervärde. I stället för att skapa en användarhistoria som bara delvis kommer att slutföra en funktion, dela upp berättelser i ”vertikala skivor” som kommer att leverera end-to-end funktionalitet.
Vänd dig till samhället för djupare lärande
Detaljerade lösningar på hur man löser de tuffaste problemen med krav och användarhistorier är unika för varje situation. Men ett gemensamt drag hos framgångsrika agila utövare är att de är angelägna om att hjälpa andra och dela med sig av vad de vet.,
Cohns userStories-webbplats gör det möjligt för dem som arbetar med produktåterställningar och användarhistorier att dela produkter, resurser och kunskap. Produktsidan innehåller en imponerande lista över verktyg, många tillgängliga gratis, med möjligheter till användarrecensioner och inmatning. Cohn konstaterar på Webbplatsen att han hoppas kunna utöka webbplatsen så att produkten eftersläpningar kan delas.
det kommer aldrig att bli ett one-size-fits-all-svar på hur man skriver perfekta användarhistorier., Men med tiden, med en hälsosam blandning av erfarenhet, råd från experterna och experiment med föreslagna verktyg och tekniker, kan du ständigt förbättra.