Good Mood

Når du begynner å dykke inn i Smidig, er det første du legger merke til er hvor bruker-sentrert denne tilnærmingen er. Det skifter fokus fra bare koding og design for å levere reell verdi til dine brukere, interessenter, og næringslivet generelt.

Smidig Bruker Historier er en viktig del av denne ideologien, som lar deg definere hva fordelene som produktet vil føre til målgruppen (og, til slutt, hvordan vil det øke din Kpier og andre beregninger).,

Vi på Stormotion elsker Historier. Som en Smidig-drevet Team vi aktivt bruke dem til å få en bedre forståelse av hva som gagner våre kunders produkter levere til sine sluttbrukere. De kan også drive samarbeid og kreativitet, og presser oss til ikke-trivielle utvikling av løsninger.,

Så i dag kommer vi til å dele vår kunnskap og erfaring om denne saken å hjelpe deg å forbedre din Historie-skrive ferdigheter. Nyt!

🤔 Hva er en Bruker Historien?

User Stories er et av kjerneelementene av Smidig metodikk. Imidlertid, de er ofte mikset med krav til programvare som ikke er sant. Så hva er en Bruker Historien?

User Story er en liten (faktisk, den minste) stykke arbeid som representerer noen verdi til en sluttbruker, og kan leveres i løpet av en sprint.,

Det viktigste målet for dette elementet er å sette brukerne i sentrum av samtale og fange funksjonalitet for et produkt fra deres perspektiv. Dermed, utviklere få en bedre forståelse av hva, for hvem, og hvorfor de er bygget.,

Flott Bruker Historier alltid passe INVESTERE sett av kriterier av Bill Wake:

• Selvstendig – de kan være utviklet i en hvilken som helst rekkefølge og endringer til en Bruker Historien ikke påvirke de andre.
• Omsettelige – det er opp til laget å bestemme hvordan implementere dem; det er ingen stivt festet arbeidsflyt.
• Verdifull – hver User Story leverer en frittstående enhet av verdi for sluttbrukere.,
• Beregnes – det er ganske lett å gjette hvor mye tid utviklingen av en Bruker Historien vil ta.
• Små – det bør gå gjennom hele syklusen (design, koding, testing) i løpet av en sprint.
• Standby – det bør være klare kriterier for aksept for å sjekke om en Bruker Historien er implementert på riktig måte.

Bruker-Historie-format (som brukes av Stormotion team så vel) er ganske vanlig og kort:

Som jeg ønsker, slik at

Ser ut som noe vanskelig, ikke sant?, Her er noen Bruker Historier eksempler som passer inn i noen made-taxi app prosjekt:

• Som sjåfør, jeg ønsker å blokkere dårlig oppførte seg passasjerene, så de er aldri vist meg igjen.
• Som passasjer, jeg ønsker å knytte kortet til min profil, slik at jeg kan betale for en tur raskere, enklere og uten penger.
• Som sjåfør, jeg ønsker å legge til bilder av bilen min i profilen min, slik at jeg kan tiltrekke seg flere brukere.
• Som passasjer, jeg vil ha flere tilgjengelige drivere skal vises slik at jeg kan velge det mest passende alternativet for meg.,

Høres ganske enkelt ut, men Brukeren utvikling i Historien er ikke ofte det enkle. Ennå senere, vil vi dele noen av våre påvist tips som vil hjelpe deg å gjøre bare gode skudd.

Er det noe annet?

til Tross for at vi bare har funnet ut at Smidig Bruker Historier er uavhengige og bør forstås som helt separate enheter i arbeidet, og noen ganger de er gruppert sammen., Så når du arbeider med dem du er sannsynlig å møte og bruke konseptet i en Episk. Hva er det?

En Epic er en høy-nivå kropp arbeid som band sammen med en gruppe av relaterte Historier.

Vi på Stormotion bruk Epos til å beskrive mer komplekse oppgaver og skape et tydelig hierarki som gjør det mulig å administrere utvikling mer enkelt og levere ny verdi til brukerne mens du arbeider mot et større mål. Likevel, Brukeren Historien format seg selv forblir den samme.,rement som skal leveres i løpet av 1 sprint

Kan være implementert i løpet av et par spurter Representerer noen verdi som brukeren vil få etter implementering Indikerer en mer generell oppgave (for eksempel gjennomføring av en hel bruker-flow) Ganske lett å anslå Vanskeligere å anslå, siden omfanget er fleksibel

Tenk deg at du bygger en dating-appen., awesome jeg er

En Historie: Som administrator, jeg ønsker å slette/blokkerer bilder fra brukernes profiler slik at de ikke skremme av andre mennesker med sine nude pics (eller brudd på community rules) En Historie: Som en app bruker, Jeg ønsker å ha et eget felt der jeg kan fortelle mer om meg selv, slik at folk til å bli forelsket i min personlighet, og ikke med min penthouse i sentrum av New York

Så, Epos gi oss en høy-nivå visningen av målene våre og hvordan vi beveger oss mot dem., Det hjelper også oss i løpet av prioritering prosess, da kan vi sjekke Epos som krever vår oppmerksomhet de og, derfor, som Historier som bør gjennomføres først.

Oh, en ting!

ikke glem å legge til en aksept kriterier.

En aksept kriterier er et sett med betingelser som brukes til å bekrefte når en Historie er ferdig.,

Også, disse forholdene gir oss en dypere og bedre forståelse siden de inneholder viktig informasjon om hvordan Historier utføre. La oss gjenbruk en av Brukeren Historien eksempler fra begynnelsen av artikkelen:

Som passasjer, jeg vil ha flere tilgjengelige drivere skal vises slik at jeg kan velge det mest passende alternativet for meg.,

Hva aksept kriterier som kan brukes til denne Historien?

• appen viser drivere som var online i løpet av siste 20 minutter, og ikke har en pågående tur.
• appen viser kun en 5-drivere som er nærmest brukeren.
• En bruker kan bla gjennom profiler av disse driverne, inkludert deres bilder og priser.

Som du kan se, nå er vi ikke bare vet verdien av denne Historien til brukerne, men også forstå noen viktige egenskaper som krever spesiell oppmerksomhet under gjennomføringen.,

Men du er fri til å velge hvor detaljert kriterier for godkjenning vil være. Det kan være alt fra «bare la det virke i noen enkel måte» til enda mer detaljert sett av betingelser enn i eksemplet ovenfor.

Det er i stor grad avhenger av din utvikling team, så det er ingen «riktig svar». Hvis laget ditt trenger veiledning og klart, med-ingen-rom-for-tolkning oppgaver ville du bedre feste med detaljerte instruksjoner om hvordan historier skal utføre. Ellers er det «bare få det gjort» – tilnærming kan fungere så godt.,

Wow, det er blitt sagt mye om Brukeren Historier. Men hvorfor er de så viktige for Smidige team?

👍 Hva Er Fordelene med å Opprette Bruker Historier?

Hvis du var aldri involvert i arbeidet med Fleksible rammeverk, du allerede vet at både Scrum og Kanban lag stor nytte av å skrive Bruker-Historier.,

I Kanban, lagene samle Historier i et Etterslep, og deretter kjøre dem én etter én for å støtte den work-in-progress flyt. Dette bidrar til å stadig holde seg på sporet og bedre utvikling team Resultatindikatorer.

Scrum (som vi vanligvis foretrekker på Stormotion) lag også gjerne Bruker Historier. Vi aktivt bruke dem til å gjøre beregninger, prioritere og planlegge spurter som hjelper oss å holde oss smidige og fleksible for endringer., Dette er spesielt nyttig når vi arbeider med Startups som er på MVP-Scenen, og har begrensede ressurser før pitching sine prosjekt for å Angel Investorer.

Bortsett fra det som er nevnt ovenfor, er det noen levende fordeler som er felles for alle Smidig lagene:

• Holde deg fokusert på forretningsverdi., Det bidrar til å gjøre app ikke bare godt-bygget fra teknisk perspektiv, men også nyttig til sluttbrukerne.
• Aktiver kreativitet. Siden det inneholder en minimal mengde av informasjon på ditt lag er gratis å drive kreative ideer for å finne den beste løsningen for å gjennomføre en Historie.
• prosjektet blir mer håndterlig. Vi på Stormotion vet at det er en måte lettere å jobbe med små og beregnes Smidig Bruker Historier snarere enn med store, komplekse oppgaver.
• De inspirerer til teamet! Alle utviklere elsker denne søte følelsen av en liten seier som motiverer ham til å jobbe enda hardere.,

Nå, la oss dykke inn i prosessen med å opprette en Bruker Historien!

📝 Hvordan å Skrive Bruker-Historier: Vår Arbeidsflyt

Vi er å bli den mest spennende del av vår artikkel. Men, før vi deler vår steg-for-steg instruksjon på å skrive en Bruker Historien, er det avgjørende å finne ut 2 viktige spørsmål: hvem og når du gjør dem.

Som er ansvarlig for å opprette en Bruker Historien?,

Som en tommelfingerregel, Historier er i hovedsak skrevet av Produktet Eiere siden det er deres ansvar å holde Ordrereserven er fylt med oppgaver. Men, ikke glem at Smidig er basert på kommunikasjon og meninger utveksling mellom eksperter. Så…

Det betyr ikke nødvendigvis at de bør være skrevet kun av et Produkt Eier. Flere personer bli med i samtalen, jo bedre.

På Stormotion, Historier er skrevet av alle gruppens medlemmer som er relatert til business-siden av prosjektet (salg ledere, markedsførere, et produkt eier osv.,), siden det la oss se på fremtiden app fra perspektivet av alle mulige slag av brukeren. Ansvar Produkt Eier i dette tilfellet er å bekrefte at de er matche INVESTERE kriterier.

Når er Bruker Historier opprettet?

En Story-skriving møte i vår HQ er vanligvis holdt nær starten av prosjektet., Vi foretrekker å gir oss opp for å sørge for at et prosjekt går bra fra første dag til den siste.

Senere, er vi i stand til å bruke vår Scrum Bruker Historien listen for å utarbeide mer detaljerte estimater (for eksempel ved slutten av Discovery Scenen), prioritere funksjon utvikling for spurter og så videre.

Også, vi supplere den opprinnelige listen som vi jobber med et prosjekt med nye historier for å holde up-to-date med våre kunders behov.,

Hva er fremgangsmåten for å skrive store Smidig Bruker Historier?

Først, la oss minne deg selv på en vanlig Bruker Historier mal:

Som en , for jeg vil så at

Synes kort og lett å skrive. Forresten, du er velkommen til å opprette din egen Bruker Historien mal. Men, vi i Stormotion har en bestemt arbeidsflyt som hjelper oss med å levere de beste Historiene:

1. Kontroller listen av sluttbrukerne. Definere hva deres «smerte» eller «trenger» er, som du prøver å løse.
2. Definere hvilke tiltak de ønsker å ta.,
3. Finne ut hvilken verdi dette vil føre til brukerne, og til slutt til produktet. Også spør deg selv – vil en part som betaler oss for dette?
4. Diskutere kriterier for aksept og en optimal implementering av strategi.

La oss se dem over nå!

Trinn 1: Tenk på «Hvem»

Dette er den første, og kanskje den mest grunnleggende trinn. Før du skriver en Bruker Historien bør du egentlig vite hvem som er sluttbrukere av produktet er. Og mer viktig – hvilke behov de har, som du prøver å dekke.,

i Løpet av vår Historie-skriving workshops, vil vi prøve å hoppe over ved å bruke en slik rolle som rett og slett «brukeren». Det kan brukes på alle person – fra dine kunder til admins – og, derfor, at det ikke gjenspeiler personligheten til bestemte målgrupper, og måten de samhandler med programmet.

Hvis du ønsker å oppnå veldig gode resultater, kan du ønsker å dykke inn i publikum enda mer., I stedet for bare å navngi brukere etter deres rolle (for eksempel, «driver») prøver å skape noen form for en kjøper persona.

Her er noen flere tips fra vår egen erfaring:

• Det er alt om brukeren. Ikke om utviklere. Og selv ikke om et Produkt Eier. Hver Historie bør være verdifull for noen gruppe av sluttbrukerne.
• tror ikke på brukere som eksterne kunder. Det er sant at deres Historier vil bli for det meste om dem. Men det er også sant at du har til å vurdere interne brukere som administratorer, redaktører etc.
• Føle en viss empati. Gi din «bruker» et navn., Tenk på sin mobile vaner, hva problemet appen din kommer til å få løst for ham og hvordan du kommer til å gjøre denne banen enklere og raskere. Husk at noen folk som du kjenner fra det virkelige liv, og som passer til dette stående; kjenn hvordan du forholder deg til denne målgruppen.

Trinn 2: Tenk på «Hva»

Nå har vi noen grupper av sluttbrukere. Neste trinn vi gjør er å definere hva funksjonalitet hver brukeren forventer, hvordan han kommer til å samhandle med appen.,

Disse er de viktigste reglene for å huske når du skriver en handling for en Kanban eller Scrum Bruker Historien:

• Én handling per en Historie. Hvis du ønsker å skrive noe sånt som «som en kunde ønsker jeg å bla gjennom elementer og legge dem til handlevognen» vil du bedre delt det inn i 2 separate Historier.
• Beskrive en intensjon, og ikke en funksjon., For eksempel, i stedet for «jeg ønsker å administrere min profil» opprett et par Historier som «jeg ønsker å være i stand til å registrere deg», «jeg ønsker å laste opp min profil-bilde», «jeg ønsker å knytte kredittkortet mitt til min profil» – hver Historie har en annen verdi.
• Hold det kort. Brukere bryr meg ikke hva du biblioteket du vil bruke til å la dem gå gjennom listen over elementer så la alle de tekniske detaljene til side.
• Unngå å beskrive UI. Vi har definert Historier som omsettelige, husker du det? Derfor er alle gode Brukeren Historien eksempler inkluderer ikke noen UI detaljer., Så ikke prøv å skrive noen spesiell måte til å gjennomføre dem (vi vil gjøre dette senere).

Trinn 3: Tenk på «Hvorfor»

til Slutt, den siste biten av våre Bruker Historier mal er dedikert til en verdi at brukerne får når du utfører en handling. Det kan virke som ikke en stor avtale, men det er ofte de mest vanskelige delen av Brukeren utvikling i Historien.,

Imidlertid delen skal alltid samsvarer med dine beregninger og Kpier. Det bør enten forbedre UX, øke oppbevaring priser, forkorte brukernes reise til problemet løsning eller hva som helst. Hver Historien bør bidra med noe til det generelle målet om ditt produkt.,

Hvis du ikke kan svare på hvilken verdi denne funksjonen fører til sluttbrukere og produktet så vel, så gjør du noe galt.

For eksempel, er det noen Bruker Historier eksempler med en godt skrevet verdi for våre pågående mat bestille app prosjekt:

• Som en kunde, jeg ønsker å bli varslet når det kommer nye hot tilbyr, slik at jeg aldri går glipp av de beste tilbudene. .
• Som en restaurant manager, jeg ønsker å utfylle rett beskrivelse i menyen med et bilde slik at det ser mer attraktive for kundene. .,

Trinn 4: Diskutere en Historie

til Slutt, vi alltid diskutere Bruker Historier etter at de har blitt opprettet. Selv om det virker som ingenting å snakke om.

i Løpet av denne Q&En økt, vi spør forfatteren av Historien for å gi mer informasjon eller avklare noe hvis det er nødvendig. Det hjelper oss å forstå hvordan det skal fungere og bli enige om kriterier for aksept., På denne måten vil vi vurdere alle mobile app bruker historier eksempler én etter én.

Da holder vi en idédugnad med hele teamet som jobber på prosjektet. Det tillater oss å finne ut de beste måter å implementere Bruker Historier fra tech perspektiv.

Slik at det er hvordan man skal skrive Brukeren Historier i et nøtteskall. Våre Stormotion Troppen også bruker følgende tips når du arbeider på denne oppgaven:

• Start med Epos., Det er vanligvis enklere å flytte fra mer komplekse oppgaver til mer spesifikke de så prøv å skrive Epos og deretter delt dem inn i Historiene.
• Lytte til tilbakemeldinger. Noen ganger trenger du ikke å gjette Historier – spør din reelle sluttbrukere for tilbakemeldinger og bruke sine ideer som en kilde til inspirasjon.
• ikke innføre detaljer for tidlig. Det er bedre å holde idédugnad før hver sprint for å diskutere hvordan de skal gjennomføre planlagt Historier.

💡 Konklusjon

User Stories er et viktig element i Smidig tilnærming som kan gi mange fordeler til prosjektet., Det er imidlertid viktig å skrive dem riktig som krever litt tid og ferdigheter.,T kriterier, noe som betyr at de er:

• Selvstendig
• Omsettelige
• Verdifull
• Beregnes
• Liten
• Testbare

Den vanlige Brukeren Historier mal inneholder brukeren, handling og verdien (eller nytte) og vanligvis ser ut som dette:

Som jeg ønsker, slik at

Bruker Historier kan hjelpe deg til å stadig forbedre verdien av produktet, anslår innsats for utvikling på en hensiktsmessig måte og prioritere funksjonen utvikling i løpet av MVP-og post-MVP stadier.,