Good Mood

Når du begynder at dykke ned i Agile, er det første, du bemærker, hvordan brugercentreret denne tilgang er. Det skifter fokus fra bare kodning og design til at levere reel værdi til dine slutbrugere, interessenter og forretning generelt.Agile brugerhistorier er en vigtig komponent i denne ideologi, der giver dig mulighed for at definere, hvilke fordele dit produkt vil bringe til din målgruppe (og til sidst, hvordan det vil øge dine KPI ‘ er og andre målinger).,

Vi er ved Stormotion elsker Historier. Som et Agile-drevet Team bruger vi dem aktivt til at få en bedre forståelse af, hvilke fordele vores kunders produkter leverer til deres slutbrugere. De driver også samarbejde og kreativitet og skubber os til ikke-trivielle udviklingsløsninger.,

så i dag vil vi dele vores viden og erfaring om denne sag for at hjælpe dig med at forbedre dine Historieskrivningsevner. God fornøjelse!

What Hvad er en brugerhistorie?

brugerhistorier er et af kerneelementerne i den smidige metode. Men de er ofte rodet med soft .arekrav, hvilket ikke er sandt. Så hvad er en brugerhistorie?

brugerhistorie er et lille (faktisk det mindste) stykke arbejde, der repræsenterer en vis værdi for en slutbruger og kan leveres under en sprint.,

hovedformålet med dette element er at sætte slutbrugere i centrum af samtalen og fange produktfunktionalitet fra deres perspektiv. Således får udviklere en bedre forståelse af hvad, for hvem og hvorfor de bygger.,

Great Bruger Historier altid passe INVESTERE sæt af kriterier, som Bill Varme:

• Uafhængige – de kan udvikles i en vilkårlig rækkefølge og skifter til en Bruger Historien ikke påvirker de andre.
• omsættelige-det er op til holdet at beslutte, hvordan man implementerer dem; der er ingen stift fast arbejdsgang.
• værdifuld-hver brugerhistorie leverer en løsrevet værdienhed til slutbrugere.,
• Estimable-det er ret nemt at gætte, hvor meget tid udviklingen af en brugerhistorie vil tage.
• lille-det skal gå gennem hele cyklen (design, kodning, test) under en sprint.
• testbar-der skal være klare acceptkriterier for at kontrollere, om en brugerhistorie implementeres korrekt.

Bruger-Historie-format (som er brugt af Stormotion team) er ganske almindeligt og kort:

Som jeg ønsker, så

Ser ud som noget vanskeligt, hva’?, Her er et par eksempler på brugerhistorier, der passer til et sammensat ta .a-app-projekt:

• som chauffør vil jeg blokere dårligt opførte passagerer, så de bliver aldrig vist mig igen.
• som passager vil jeg linke kreditkortet til min profil, så jeg kan betale for en tur hurtigere, lettere og uden kontanter.
• som chauffør vil jeg tilføje fotos af min bil i min profil, så jeg kan tiltrække flere brugere.
• som passager ønsker jeg, at flere tilgængelige drivere skal vises, så jeg kan vælge den mest passende mulighed for mig.,

lyder ganske let, men Brugerhistorieudvikling er ikke ofte så enkel. Endnu, senere, vi vil dele nogle af vores gennemprøvede tips, der vil hjælpe dig med at gøre kun gode skud.

Er der noget andet?

på trods af at vi lige har fundet ud af, at Agile brugerhistorier er uafhængige og skal forstås som helt separate arbejdsenheder, er de nogle gange grupperet sammen., Så når du arbejder med dem, vil du sandsynligvis møde og bruge begrebet en episk. Hvad er det?

en episk er et højt niveau af arbejde, der binder sammen med en gruppe relaterede historier.

Vi er ved Stormotion bruge Epics til at beskrive mere komplekse opgaver og skabe et klart hierarki, der giver mulighed for styring af udvikling mere nemt og levere ny værdi til brugerne, mens du arbejder hen imod et større mål. Alligevel forbliver Brugerhistorieformatet det samme.,rement, der skal leveres i løbet af 1 sprint

Kan gennemføres i løbet af et par sprints Repræsenterer en vis værdi, som brugeren vil få efter gennemførelsen Angiver en mere generel opgave (for eksempel implementering af en hel bruger-flow) Ganske let at estimere Sværere at vurdere, da rækkevidden er fleksibel

Forestil dig, at du er ved at oprette en dating app., awesome jeg er

En Historie: Som en admin, jeg vil slette de/blok fotos fra brugernes profiler, så de ikke skræmme andre mennesker med deres nude pics (eller overtræder eu-reglerne) En Historie: Som en app bruger, Jeg ønsker at have et separat område, hvor jeg kan fortælle mere om mig selv, så at folk falder i kærlighed med min personlighed og ikke med min penthouse i centrum af New York

Så, Episke digte, give os en oversigt af vores mål, og hvor vi er på vej mod dem., Det hjælper os også under prioriteringsprocessen, da vi kan kontrollere, hvilke epos der kræver vores opmærksomhed mest, og derfor hvilke historier der skal implementeres først.

Åh, en ting mere!

glem ikke at tilføje en accept kriterier.

et acceptkriterium er et sæt betingelser, der bruges til at bekræfte, når en historie er afsluttet.,

disse forhold giver os en dybere og bedre forståelse, da de indeholder vigtige oplysninger om, hvordan Historier udføre. Lad os genbruge et af Brugerhistorieeksemplerne fra artiklens begyndelse:

som passager ønsker jeg, at flere tilgængelige drivere skal vises, så jeg kan vælge den mest passende mulighed for mig.,

hvilke acceptkriterier kan anvendes på denne historie?

• appen viser drivere, der var online inden for de sidste 20 minutter og ikke har en løbende tur.
• appen viser kun 5 drivere, der er tættest på brugeren.
• en bruger kan gennemse profiler af disse drivere, herunder deres fotos og priser.

som du kan se, kender vi ikke kun værdien af denne historie til brugerne, men forstår også nogle nøgleegenskaber, der kræver særlig opmærksomhed under implementeringen.,

Du kan dog frit vælge, hvor Detaljerede dine acceptkriterier vil være. Det kan variere fra “bare lad det fungere på en hvilken som helst bekvem måde” til endnu mere detaljerede sæt betingelser end i eksemplet ovenfor.

det afhænger meget af dit udviklingshold, så der er ikke noget “korrekt svar”. Hvis dit team har brug for vejledning og klare, med-no-room-for-fortolkning opgaver, Du må hellere holde med detaljerede instruktioner om, hvordan historier skal udføre. Ellers,” bare få det gjort ” tilgang kan arbejde så godt.,

Wowo., det er blevet sagt meget om brugerhistorier. Men hvorfor er de så vigtige for Agile teams?

What Hvad er fordelene ved at oprette brugerhistorier?

Hvis du nogensinde var involveret i at arbejde med Agile frame .orks, ved du allerede, at både Scrum og Kanban-teams har stor gavn af at skrive brugerhistorier.,

I Kanban, hold samle Historier i en Pukkel, og derefter køre dem én efter én at støtte work-in-progress flow. Dette hjælper til konstant at holde på sporet og forbedre udvikling team KPI ‘ er.

Scrum (som vi normalt foretrækker hos Stormotion) hold elsker også brugerhistorier. Vi bruger dem aktivt til at lave estimater, prioritere og planlægge sprints, som hjælper os med at holde os smidige og fleksible til eventuelle ændringer., Dette er især gavnligt, når vi arbejder med Startups, der er på MVP-scenen og har begrænsede ressourcer, før de pitcher deres projekt til Angel-Investorer.

Bortset fra de ovenfor nævnte, der er nogle levende fordele, der er fælles for alle Agile teams:

• at Holde dig fokuseret på den forretningsmæssige værdi., Det hjælper med at gøre din app ikke kun velbygget ud fra det tekniske perspektiv, men også nyttig for slutbrugerne.
• aktiver kreativitet. Da det indeholder en minimal mængde info, er dit team gratis at køre kreative ideer for at finde den bedste løsning til at implementere en historie.
• dit projekt bliver mere håndterbart. Vi hos Stormotion ved, at det er en måde lettere at arbejde med små og estimerbare Agile brugerhistorier snarere end med store komplekse opgaver.
• de inspirerer holdet! Hver udvikler elsker denne søde følelse af en lille gevinst, der motiverer ham til at arbejde endnu hårdere.,

lad os nu dykke ind i processen med at oprette en brugerhistorie!

How Sådan skriver du brugerhistorier: vores arbejdsgang

Vi kommer til den mest spændende del af vores artikel. Men før vi deler vores trin-for-trin instruktion om at skrive en brugerhistorie, er det afgørende at finde ud af 2 væsentlige spørgsmål: hvem og hvornår gør dem.

Hvem er ansvarlig for at oprette en brugerhistorie?,

som en tommelfingerregel er historier hovedsageligt skrevet af produktejere, da det er deres ansvar at holde Backloggen fyldt med opgaver. Glem ikke, at Agile er baseret på kommunikation og meningsudveksling mellem eksperter. Så…

det betyder ikke nødvendigvis, at de kun skal skrives af en produktejer. Jo flere mennesker deltager i samtalen, jo bedre.

i Stormotion er historier skrevet af alle teammedlemmer, der er relateret til projektets forretningsside (salgschefer, marketingfolk, en produktejer osv.,), da det lader os se på den fremtidige app fra perspektivet af enhver potentiel form for bruger. Produktejerens ansvar i dette tilfælde er at bekræfte, at de er i overensstemmelse med INVESTERINGSKRITERIERNE.

Når du er Bruger Historier skabt?

et Historieskrivelsesmøde i vores hovedkvarter afholdes normalt nær projektets start., Vi foretrækker at geare os op for at sikre, at et projekt går godt fra den første dag til den sidste.

senere kan vi bruge vores Scrum-Brugerhistorieliste til at udarbejde mere detaljerede estimater (for eksempel ved slutningen af opdagelsesfasen), prioritere funktionsudvikling for sprints og så videre.

Vi supplerer også den oprindelige liste, da vi arbejder på et projekt med nye historier for at holde os ajour med vores kunders krav.,

Hvad er trinnene til at skrive store Agile brugerhistorier?

lad os Først minde dig om en fælles Bruger Historier skabelon:

Som en , jeg ønsker, så

Synes kort og let at skrive. Af den måde, er du velkommen til at oprette din egen User Story skabelon. Vi hos Stormotion har dog en specifik arbejdsgang, der hjælper os med at levere de bedste historier:

1. lav listen over dine slutbrugere. Definer, hvad deres “smerte” eller “behov” er, som du forsøger at løse.
2. Definer, hvilke handlinger de måske ønsker at tage.,
3. Find ud af, hvilken værdi dette vil bringe til brugere og til sidst til dit produkt. Spørg også dig selv-Vil nogen part betale os for dette?
4. Diskuter acceptkriterier og en optimal implementeringsstrategi.

lad os se dem over nu!

Trin 1: Tænk på “hvem”

Dette er det første og måske det mest grundlæggende trin. Før du skriver en brugerhistorie, skal du faktisk vide, hvem slutbrugerne af dit produkt er. Og vigtigere-hvilke behov de har, som du forsøger at dække.,

under vores Historieskrivende workshopsorkshops forsøger vi at udelade at bruge en sådan rolle som blot “brugeren”. Det kan anvendes til enhver person – fra dine kunder til administratorer – og derfor afspejler det ikke personligheden hos bestemte målgrupper, den måde, de interagerer med applikationen på.

Hvis du ønsker at opnå virkelig gode resultater, du måske ønsker at dykke ned i din målgruppe endnu mere., I stedet for bare at navngive brugere efter deres rolle (for eksempel “en driver”), prøv at oprette en slags køberpersona.

Her er et par flere tips fra vores egen erfaring:

• det handler om brugeren. Ikke om udviklere. Og selv ikke om en produktejer. Hver historie skal være værdifuld for en gruppe af dine slutbrugere.
• tænk ikke kun på brugere som eksterne kunder. Det er sandt, at dine historier Mest handler om dem. Men det er også sandt, at du skal overveje interne brugere som administratorer, redaktører osv.
• Føl lidt empati. Giv din” bruger ” et navn., Tænk på hans mobile vaner, hvilket problem din app vil blive løst for ham, og hvordan du vil gøre denne vej lettere og hurtigere. Husk nogle mennesker, som du kender fra det virkelige liv, og som passer til dette portræt; Føl, hvordan du forholder dig til denne målgruppe.

Trin 2: Tænk på “hvad”

nu har vi et par grupper af slutbrugere. Det næste trin, vi gør, er at definere, hvilken funktionalitet hver bruger forventer, hvordan han vil interagere med appen.,

Disse er de vigtigste regler at huske, når du skriver en indsats for et Kanban eller Scrum Bruger Historien:

• En indsats per en Historie. Hvis du vil skrive noget i retning af “som kunde vil jeg gennemse varer og tilføje dem til indkøbskurven”, skal du hellere opdele det i 2 separate historier.
• Beskriv en hensigt, ikke en funktion., For eksempel, i stedet for “jeg vil administrere min profil” oprette et par historier som “jeg vil være i stand til at registrere”, “jeg vil uploade mit profilbillede”, “jeg vil linke mit kreditkort til min profil” – hver historie har en anden værdi.
• hold det kort. Brugere er ligeglad med hvilket bibliotek du vil bruge til at lade dem gennemse listen over varer, så lad alle tekniske detaljer være til side.
• undgå at beskrive brugergrænsefladen. Vi har defineret historier som omsætningspapirer. Derfor indeholder alle gode Brugerhistorieeksempler ikke nogen UI-detaljer., Så prøv ikke at komponere nogen særlig måde at implementere dem på (vi gør det senere).

Trin 3: Tænk på “hvorfor”

endelig er det sidste stykke af vores User Stories-skabelon dedikeret til en værdi, som brugerne får efter at have udført en handling. Det kan virke som ikke en big deal, men det er ofte den mest vanskelige del af Brugerhistorieudviklingen.,

Men, din afdeling skal altid svare med din målinger og Kpi ‘ er. Det bør enten forbedre U., øge fastholdelsesgraden, forkorte brugernes rejse til problemløsningen eller hvad som helst. Hver historie skal bidrage med noget til det generelle mål for dit produkt.,

Hvis du ikke kan svare på, hvilken værdi Denne funktion bringer til slutbrugere og dit produkt også, så gør du noget forkert.

For eksempel, der er et par Bruger Historier, eksempler med et velskrevet værdi for vores fortsatte mad bestilling app-projekt:

• Som kunde, jeg ønsker at få besked, når der er nye hot tilbyder så at jeg aldrig går glip af de bedste tilbud. .
• som restaurantchef vil jeg supplere skålbeskrivelse i menuen med et foto, så det ser mere attraktivt ud for kunderne. .,

Trin 4: Diskuter en historie

endelig diskuterer vi altid brugerhistorier, når de er oprettet. Selvom det ikke ser ud som noget at tale om.

i Løbet af denne Q&En session, vil vi bede forfatteren af Historien for at give yderligere oplysninger eller for at afklare noget, hvis det er nødvendigt. Det hjælper os med at forstå, hvordan det skal fungere og blive enige om acceptkriterier., På denne måde gennemgår vi alle eksempler på mobilappbrugerhistorier en efter en.

så holder vi en brainstorming session med hele teamet, der arbejder på projektet. Det giver os mulighed for at finde ud af de bedste måder at implementere brugerhistorier fra det tekniske perspektiv.

så det er hvordan man skriver brugerhistorier i et nøddeskal. Vores Stormotion s .uad bruger også følgende tips, når du arbejder på denne opgave:

• Start med Epics., Det er normalt lettere at flytte fra mere komplekse opgaver til mere specifikke, så prøv at skrive Epics og derefter opdele dem i historier.
• Lyt til feedback. Nogle gange behøver du ikke gætte historier – spørg dine rigtige slutbrugere om feedback og brug deres ideer som inspirationskilde.
• introducer ikke detaljer for tidligt. Det er bedre at holde brainstorming sessionen før hver sprint for at diskutere, hvordan man implementerer planlagte historier.

Conclusion konklusion

brugerhistorier er et væsentligt element i den smidige tilgang, der kan give mange fordele til dit projekt., Det er dog vigtigt at skrive dem korrekt, hvilket kræver lidt tid og færdigheder.,T kriterier, hvilket betyder, at de er:

• Selvstændigt
• Omsættelige
• Værdifulde
• Agtværdig
• Lille
• Testbare

Den almindelige Bruger Historier skabelon indeholder brugeren, at den indsats og værdien (eller fordel) og typisk ser ud som dette:

Som jeg ønsker, så

Bruger Historier kan hjælpe dig med at konstant forbedre værdien af dit produkt, vurdere og udvikle indsatsen på en hensigtsmæssig måde og prioritere, har udviklingen i løbet af MVP-og post-MVP faser.,