En av de største utfordringene i utvikling av programvare er det nesten umulig oppgave å samle tydelige krav og så får de krav til å forbli uendret under koden utvikling. I fossen tilnærming til utvikling av programvare—til tross for innsatsen for å definere, dokument, og godkjenne alle mulige beredskap før utviklingen begynner—det leverte produkt er sjelden hva kunden ønsker.
smidig alternativ? Brukeren historien om skapelsen.,
En av de største fordelene med å bruke en smidig tilnærming til utvikling av programvare er at kravene ikke er satt i stein, men i stedet er forventet å endre seg, med stadige tilbakemeldinger fra interessenter og virksomheten. Smidige metodikker som Scrum og extreme programming (XP) erstatte tradisjonelle, lange krav-dokumenter med en prioritert produktkø består av konsis bruker historier, detaljene som dukker opp nærmere når historien er klar til å bli implementert.,
selv Om brukeren historien etablering er mer kunst enn vitenskap, så er denne veiledningen vil gi deg informasjon, eksempler, og hva du trenger for å skape høy kvalitet bruker-historier.
historien om brukeren historier
XP først introduserte begrepet user stories i 1998, og sammenlikne dem til å bruke tilfeller. I Object-Oriented Software Engineering: En Use Case Drevet Tilnærming, Ivar Jacobson introdusert bruke tilfeller som en måte å dokumentere kravene ved å definere interaksjoner mellom en rolle (en person som bruker systemet) og systemet i seg selv for å oppnå et mål ved hjelp av Unified Modeling Language (UML).,
Denne tilnærmingen ble populære i objekt-orientert utvikling, og er fortsatt brukes som en viktig prosess i utvikling av programvare rammeverk, for eksempel Unified Process (UP), IBM Rational Unified Process (RUP), og Oracle Enhetlig Metode (OUM). Ved hjelp av use cases, snarere enn brukeren historier, som gir iterativ og inkrementell utvikling og er betraktet som en smidig tilnærming til krav definisjon.,
Med innføringen av mye kortere bruker historier og populariteten av XP og Scrum, en produktkø består av user stories ble mer kjent tilnærming til smidig krav definisjon. Mange utøvere tror fortsatt at brukeren historier er den eneste akseptable smidig tilnærming. Imidlertid, Alistair Cockburn, en av Agile Manifesto er undertegnet, foretrekker å bruke tilfeller bruker historier.
selv Om det er mange sterke meninger om betydningen av «smidig», som begge tilfeller og bruker historier er kompatible med denne tilnærmingen., Noen sier brukeren historier etter hvert bli lik bruke tilfeller når teamet er enig i mot detaljene i gjennomføringen. I de tidlige stadiene, user story er rett og slett en kort setning, men det er ikke komplett før detaljene og aksept kriterier er definert.
Opprette bruker historier
Det er varierende meninger om definisjonen av en bruker historien og hvordan du best kan gå om å opprette en., Noen retningslinjer for en god bruker historien er følgende:
- Det burde være skrevet av noen som representerer business-brukere (vanligvis produktet eier)
- Det bør i utgangspunktet inneholde en kort beskrivelse av «hvem, hva, og hvorfor,»men ikke «hvordan»
- Det skal produsere en vertikal del av arbeidet kode
- Det bør være liten nok til at det kan være kodet og testet i en iterasjon (vanligvis en en-til-fire-ukers periode)
Forskjellige maler, teknikker og forkortelser er brukt for å hjelpe produktet eiere brukeren skrive historier., Tre av de mest vanlige teknikkene er rolle-funksjon-grunn mal, Tre C ‘ s (kort, samtale, bekreftelse), og INVESTERE (uavhengige, omsettelige, verdifulle, beregnes, små, testbare).
Eksempler
Si at du er å utvikle et program som ville tillate trenere til å laste opp kursmateriell og tiltrekke seg studenter som er interessert i å ta en klasse. Her er hvordan du ville bruke brukeren historien teknikker.,
Rolle-Funksjon-Grunnen
Som Mike Cohn av Mountain Goat Programvare forklarer, rolle-funksjon-grunn mal, eller RGB (rolle, mål, nytte), ser noe som dette:
«Som jeg ønsker, slik at .»
Selv om det er variasjoner, denne korte setningen struktur holder fokus på hvem, hva og hvorfor. Dette forhindrer at produktet eier fra å gi teamet for mye informasjon om hvordan de skal implementere en løsning. Ved å fokusere på hvem, hva, og hvorfor, utvikling team har kompetanse til å finne den beste tekniske løsningen.,
Eksempel 1: Gi en trener med muligheten til å legge til et kurs
Som en trener, jeg ønsker å være i stand til å legge en ny kurs, slik at jeg vil ha potensial til å tiltrekke seg nye studenter.
Eksempel 2: Gi en student med evne til å søke etter et kurs
Som en student ønsker jeg å kunne søke på de kurstilbud, slik at jeg vil være i stand til å finne et tilbud som mest interesserer meg.
Den rolle (who)
Den rollen beskriver som vil dra nytte av denne funksjonen. Legg merke til at denne rollen er ikke bare «brukeren.,»Det finnes ulike typer av brukere, og slik vi vil ha den rollen å være mer konkret enn «bruker», men beskriver den type bruker som vil dra nytte av historien. Produktet eiere er ofte oppgave med å få i sinnet av sine brukere for å forstå hva som ville være den mest verdifulle for dem.
Eksempel 1 Role = trainer
Eksempel 2 Role = studenten
funksjonen (hva)
Dette trinnet veldig kort beskriver hva brukeren ønsker. Dette best representerer det krav om at du beskrive i tradisjonell programvareutvikling., Imidlertid, du ønsker å være forsiktig for ikke å bli for spesifikk eller beskrive hvordan å skrive koden. Som vil bli fastsatt til slutt, men ikke når du først opprette brukeren historie. Brukeren historien skal være skrevet fra perspektivet til brukeren som vil dra nytte av funksjonen, ikke fra perspektivet av den utvikler som vil være koding det.
Eksempel 1 Feature = legg til en ny kurs
Eksempel 2 Feature = søk kurset tilbud
Den grunn (hvorfor)
til Slutt, vi ønsker å oppgi hvorfor du ønsker denne funksjonen. Hvilken verdi vil brukeren få fra det?, Dette bidrar til produktet eier vurdere hvordan en skal prioritere de bruker historien på ordrereserven. Hvis verdi eller nytte kan ikke være formulert, kan det være noe som ikke er nødvendig. Forstå verdien ofte hjelper teamet med å finne innovative måter å implementere koden for å løse mål—måter som kan være forskjellig fra hva produktet eier har i tankene.,
Eksempel 1 Grunn til = tiltrekke seg nye studenter
Eksempel 2 Grunnen = finn et tilbud som mest interesserer meg
De Tre P-er: – Kortet, Samtale, Bekreftelse
De Tre C ‘ s formula, utviklet av Ron Jeffries, bidrar til å nå en avtale mellom bedriften og den tekniske team på betydningen av brukeren historie. De Tre C ‘ s guide dem gjennom den progressive utarbeidelsen av en historie, fra en kort uttalelse til en fullt utviklet brukeren historie.,
Kort
bruker historien starter ut med hensikt kort, med en enkel setning som kan passe på en 3×5 index-kort, vanligvis følgende rolle-funksjonen-nytte-format som jeg bare dekket. For eksempel:
Som en trener, jeg ønsker å være i stand til å legge en ny kurs, slik at jeg vil ha potensial til å tiltrekke seg nye studenter.
Samtale
selv Om brukeren starter historien som en enkel uttalelse, detaljer må komme før teamet begynner å jobbe på historien., Snarere enn å beskrive hva som er nødvendig dokumentasjon, vil laget ta 1) representasjon fra næringslivet (vanligvis produktet eier), og 2) utvikling team i seg selv, inkludert utviklere, testere, business analytikere, eller noen andre på laget.
Denne samtalen lar teamet til å stille spørsmål for å sikre at de har en klar forståelse av hva som blir bedt for og verdien blir gitt. For eksempel:
Utvikler: Vil trener trenger å laste opp kursmateriell inn på en nettside?,
Produkt eier: Nei, trener vil bare være å legge til informasjon om kurs som vil bli tilbudt, og funksjonen bør inneholde en mulighet for studenten til å komme på en interesseliste. Denne historien gir trener evnen til å annonsere et kurs.
Utvikler: Hvilke felt som skal inkluderes?
Produkt eier: Kurs tittel, sammendrag, datoer og klokkeslett, plassering.
Utvikler: Vil dette bare være for annonsering ansikt-til-ansikt klasser?
Produkt eier: Ja., Vi kan legge til en virtuell klasse alternativet senere, men denne historien vil bare dekke legge til kurset informasjon for ansikt-til-ansikt klasse tilbud.
Utvikler: Hvilken informasjon skal være samlet når en potensiell student ber om å få på en interesse-liste?
Produkt eier: Navn, telefonnummer og e-postadresse.
laget vil oppdatere brukerens historie med den informasjonen de har samlet fra samtalen, og de vil diskutere implementering—eller «hvordan»—som ofte skaper spesifikke oppgaver som må utføres for å fullføre historien., Selv om brukeren historien er skrevet fra perspektivet av brukeren, utvikling team skriver oppgaver for utviklere og omfatter den tekniske gjennomføringen detaljer.
Bekreftelse
teamet må ha en klar forståelse av hvordan funksjonen fungerer i forskjellige situasjoner, inkludert feil forhold. De trenger å få bekreftelse angående kriterier for aksept fra produkteier. Dette er kriterier som må være oppfylt for at historien kan anses å være utført og godkjent., Her er et eksempel på kriterier for godkjenning:
- En trener er i stand til å legge en ny kurs ved å skrive inn course title, abstract, datoer og klokkeslett, og sted til et skjema, og trykker en på «legg til kurset» – knappen.
- Hvis noen felt er det mangler eller datoer eller klokkeslett er ugyldig, feilmeldinger vil vises.
- Når kurset er riktig lagt, vil det bli vist offentlig på fagets hjemmeside, og det vil være en knapp for en student å uttrykke interesse.,
- interessen knappen vil tillate en bruker å skrive inn navn, e-postadresse og telefonnummer, og disse dataene vil bli lagret og knyttet til den nye kursen.
INVEST: attributter for en solid bruker historien
INVEST er et akronym som bidrar til å vurdere om du har en høy kvalitet bruker-historien. Her er hvordan attributter i akronym gjelder historien vi har jobbet med.
jeg = Selvstendig—Kan denne historien være utfylt av teamet? Vi ønsker teamet å være i stand til å fullføre hele historien snarere enn å være avhengig av et annet team for å gjøre det grafiske BRUKERGRENSESNITTET, for eksempel.,
N = Omsettelige—historien er ikke så detaljert som å beskrive nøyaktig hvor lenge felt bør være eller gi detaljer om dato formater og lignende. Mest sannsynlig vil det være felles rutiner eller biblioteker som vil tillate teamet for å implementere på den måten som er mest fornuftig for dem.
V = Verdifull—produktet eieren beskriver at verdien blir søkt, er muligheten for den som trener for å være i stand til å annonsere kommende klasser. Dette er klart i det «hvorfor» av den opprinnelige setningen og re-understreket i samtalen.,
E = Beregnes—laget vil stille nok spørsmål og samle informasjon for å føle seg trygg i sin evne til å anslå historien.
S = Liten—laget trenger for å føle deg trygg på at de vil være i stand til å fullføre historien i en sprint. Hvis de ikke gjør det, de kan dele historien. For eksempel, i vårt eksempel historie, de kan bestemme seg for å gjøre evne til å samle studenten informasjon bli en annen historie, og viser bare informasjon om klassen for denne historien.
T = Testbare—Med klare kriterier for aksept, både glade banen og feiltilstander som kan testes.,
sett inn en visjon
jeg har dekket det grunnleggende for å skape en bruker historien, men du fortsatt trenger å forstå det store bildet før du kan opprette din egen bruker historier. Det er mye arbeid du må gjøre opp foran, på et høyere nivå, for å finne ut hva den høyeste verdien funksjoner som skal leveres til kundene. De som til syvende og sist er dekomponert i brukernes historier.
Det er viktig for laget å først forstå høyt nivå visjon og å sørge for at de har, og til slutt bruker historier, og juster til at høy-nivå syn.,
Vanligvis, du bryter produktet ned i grupperinger som går under navn som «tema» eller «funksjoner.»Om merking av disse etterslep elementer kan variere avhengig av smidig metode og verktøy du bruker for å beskrive dem, tanken er å sørge for at de juster slik at arbeidet kan spores opp til visjonen din, som vil sørge for at du møter mål og verdier av produktet visjon.
Igjen, trenger du ikke å starte et prosjekt ved å opprette bruker historier; start med å lage en visjon., For vårt eksempel vil jeg bare vise et eksempel på visjon, noe som fører til noen eksempler på funksjoner, som kan være videre dekomponeres i user stories.
Vision
Gi en høy kvalitet nettsted som vil tillate trenere til å annonsere kurs og gir elevene mulighet til å ta disse kursene.
Funksjoner
- Gi et kurs som tilbyr side som vil tillate studentene å melde deg på kurs.
- Sørge for en hjemme side som vil fortelle brukerne hva nettstedet handler om.
- Sørge for en registrering prosess som tillater brukere å logge på, kan du opprette en profil, og holde styr på sine klasser.,
- Sørge for en blogg som vil bidra til å markedsføre våre tilbud og få publisitet for vår nettside.
User stories
- Sørge trener med muligheten til å legge til en kurs på kurs, og tilbyr side.
- Sørge for studenter med evne til å søke etter et kurs.
I eksempelet ovenfor, kan du se hvordan brukeren historiene stammer. Brukeren historier var en del av en funksjon for å «gi et kurs som tilbyr side» som passer til high-nivå syn.,
Impact mapping
selv Om justere til en visjon som vil hjelpe deg å fylle ut din første etterslep, det er ikke den eneste måten å gjøre det. Det er mange verktøy og teknikker for produktet ledere kan bruke for å lage historier som går i en ny etterslep og som er i samsvar med visjonen.
En strategisk planlegging teknikk som brukes til å hjelpe deg med å forstå det store bildet, impact mapping, ble popularisert av Gojko Adzic, forfatter av Femti Rask Ideer for å Forbedre Din Bruker Historier og Impact Mapping: å Gjøre en stor innvirkning, med programvare produkter og prosjekter., Impact mapping er et tankekart som starter med mål, som bør ta opp spørsmålet om verdi og hvorfor du bygge produktet.
neste nivå viser de «aktører», eller folk som vil bidra til å oppnå målet. Neste, kartet viser atferd, eller «påvirkning» at aktører vil utføre for å oppnå dette målet. Det siste nivået av kartet presenterer «leveransen» at laget kan implementere. Disse aktivere og støtte aktører for å skape den ønskede virkningene. Det er fra denne leveransen som du utlede programvare funksjoner og historier.,
- Mål: Gjøre allment tilgjengelig kurs som studentene ønsker å ta
- Skuespillere: Trenere, studenter
- Konsekvenser: Trenere vil gi høy kvalitet klasser som er av interesse for studenter, elever vil gi henvisninger og anbefalinger
- Leveransen: Høy kvalitet klasser som er tilgjengelig for studenter
- Potensielle historier:
- «Som en trener, jeg ønsker å annonsere klasser, slik at jeg kan få studenter.
- «Som en trener, jeg ønsker å få tilbakemeldinger fra studentene, slik at jeg kan stadig forbedre oss.,»
- «Som en trener, ønsker jeg å finne ut hva studentene ønsker, så kan jeg legge til min pensum.»
- «Som en student ønsker jeg å finne klasser som er av størst interesse for meg.»
- «Som en student ønsker jeg å finne klasser at jeg er i stand til å ta online, slik at jeg ikke trenger å reise.»
- «Som en student ønsker jeg å lese anmeldelser fra andre, slik at jeg kan bestemme hvilke klasser som best vil passe meg.»
Kartlegge brukeren historier på denne måten, kan sporbarhet i tankeprosessen om hvordan historiene til syvende og sist skape verdi og hvordan du bruker dem til å oppnå målet., Ideen er ikke å gjennomføre alt, men å finne den korteste veien gjennom kart for å oppnå dine mål.
Dele historier
En av de mest vanlige problemene smidige team kjøre inn er når historier er for store, og ikke kan være ferdig i en iterasjon. Når teamet skaper de oppgaver som er forbundet med den historien, de innser at det er for mange ukjente, eller at oppgavene vil ta mer tid enn laget har tilgjengelig i en enkelt iterasjon. Lag noen ganger løse dette ved å splitte en større historie i mindre historier.,
Husk, imidlertid, at du ønsker en bruker historien for å levere fungerende programvare som vil øke verdien for brukeren. Snarere enn å opprette en bruker historien som bare delvis fullført en funksjon, delt historier i «vertikale skiver», som vil levere ende-til-ende-funksjonalitet.
Slå til fellesskapet for dypere læring
Detaljerte løsninger på hvordan man kan løse de vanskeligste problemene knyttet til krav og bruker historier er unike for hver enkelt situasjon. Men et felles trekk for vellykket smidig utøvere er at de er ivrige etter å hjelpe andre, og fortelle hva de vet.,
Cohn ‘ s userStories nettstedet lar de som arbeider med produktet backlogs og bruker historier å dele produkter, ressurser og kunnskap. Produktene siden inneholder en imponerende liste av verktøy, mange er gratis tilgjengelig, med muligheter for brukeren vurderinger og innspill. Cohn notater på nettstedet at han håper å utvide området slik at produktet backlogs kan være felles.
Det aldri kommer til å bli en one-size-fits-all svaret på hvordan å skrive perfekte bruker historier., Men, over tid, med en sunn blanding av erfaring, råd fra eksperter, og eksperimentering med forslag til verktøy og teknikker, som du kan stadig forbedre oss.