Programmering

Hvordan man skriver smidige brugerhistorier: 7 retningslinjer

Grundlæggende er agile brugerhistorier korte, enkle værktøjer til at dokumentere en enkelt handling eller hensigt, som den målrettede bruger ønsker at nå et mål. De enkleste brugerhistorier har formatet ”Som en brugertype eller rolle, Jeg vil gerne handling eller hensigtså det grund eller fordel”Der svarer på mindst tre enkle spørgsmål om, hvem, hvad og hvorfor historien står i efterslæbskøen.

Når hold modnes, og organisationer bruger agile på tværs af flere teams og initiativer, får agile brugerhistorier ofte meget mere definition og struktur for at sikre, at der er en fælles forståelse af hensigten og de underliggende krav.

Kom godt i gang med at skrive smidige brugerhistorier

Der er masser af ressourcer til at hjælpe nye produktejere, forretningsanalytikere, scrummasters og tekniske kundeemner med at forstå det grundlæggende ved at skrive brugerhistorier. Nogle steder at starte inkluderer artikler fra Atlassian, FreeCodeCamp, Agile Modeling og disse 200 brugerhistoriske eksempler. En af de mere komplette opskrivninger findes i Alexander Cowans bedste smidige brugerhistorie. Der er bøger om historisk skrivning, herunder Kortlægning af brugerhistorieaf Jeff Paton og Peter Economy og Brugerhistorier anvendtaf Mike Cohn. Du kan også tage kurser i historisk skrivning fra Udemy, Learning Tree, VersionOne og Lynda.

Et grundlæggende princip, der først deles af Bill Wake, er at invester i gode historier. Investerestår for ”uafhængig, omsættelig, værdifuld, estimerbar, lille og testbar”, som udgør en god tjekliste for agile historieforfattere. “En agil lederguide til at skrive brugerhistorier” er en artikel, der forklarer, hvordan man ansøger investereprincipper.

Det grundlæggende er relativt let, men alligevel hører og vidner jeg ofte om afbrydelser mellem interessenter, produkt ejere, udviklere og testere omkring kvaliteten af ​​kravene, eller om en historie virkelig er færdig. Der er undertiden modstridende synspunkter på det krævede detaljeringsniveau, hvor de skal passe ind i tekniske krav, og hvilke artefakter der skal oprettes med brugerhistorier.

Med disse spørgsmål i tankerne er her syv retningslinjer, der ligger ud over det grundlæggende om skrivning af smidige brugerhistorier.

1. Skriv historier til det publikum, der vil bruge dem

Før du skriver historier, skal du huske på, at historier er beregnet til at blive læst og forstået af mennesker, der deltager i udviklingsprocessen med forskellige behov og ansvarsområder. Historieforfattere og bidragydere bør holde publikum i tankerne og udarbejde historier for at imødekomme de kollektive behov:

  • Produktejere er måske ikke dem, der skriver historierne, især hvis din organisation uddelegerer denne funktion til forretningsanalytikere, eller hvis der er flere personer involveret i historisk skrivning. Produktejere vil sikre sig, at historien fuldt ud fanger brugernes behov og hensigt. De skal læse gennem de detaljerede acceptkriterier, men ønsker ikke nødvendigvis at være nedbøjet med tekniske implementeringsoplysninger. Produktejere skal også forstå, hvordan historien er tilpasset det større billede, så de skal have en aktiv interesse i, hvordan epos og funktioner defineres, og hvordan historier tildeles dem.
  • Interessenter vil ikke læse historiens detaljer, men vil bore ned fra epos og læse historiens resume. Hvis du har mange interessenter, kan du overveje at bruge et beskrivende format til resuméer og flytte “Som en brugertype eller rolle”Beskrivelse til starten af ​​beskrivelsen af ​​brugerhistorien.
  • Tekniske kundeemner er ofte den første person fra holdet, der gennemgår historier, og de vil undersøge kravene for at se, om en historie er for stor og skal opdeles i flere historier, eller se om historien har brug for noget teknisk arbejde på forhånd for at bestemme det bedste opløsning.
  • Modtageren er den person, der er ansvarlig for at gennemgå detaljerne og rapportere om fremskridt på daglige standupmøder. Tilsynsførende skal gennemgå historier for afhængigheder, der kan blive blokke under sprinten.
  • Teammedlemmer gennemgår ofte alle historier for at forstå deres tildelte historier i sammenhæng med andre historier, der er tildelt sprinten.
  • Testere bestemmer, om der er huller eller risici, der ikke er identificeret i acceptkriterierne, og overvejer derefter, hvordan de bedst implementeres i automatiserede testrammer.
  • Holdets analytiker, der muligvis er programleder eller medlem af projektledelseskontoret, vil have historier fuldt mærket og kategoriseret, så meningsfulde målinger kan trækkes ud af efterslæbet.

2. Start med brugeren i tankerne

Selvom agile brugerhistorier muligvis kræver mange detaljer, er det meget vigtigt at starte med brugeren i tankerne. Historien skal være definerende hvadhandling eller hensigt, som brugeren ønsker at udføre og hvorfordette imødekommer et behov, en kerneværdi eller et mål, der stammer fra oplevelsen.

For mere komplekse applikationer er det en vigtig disciplin at definere forskellige brugerpersoner, der illustrerer behov, værdier og brugsmønstre for forskellige brugertyper, og det kan forbedre historisk skrivning. I "10 tip til at skrive gode brugerhistorier" foreslår Roman Pichler, at "personamålene hjælper dig med at finde de rigtige historier. Spørg dig selv, hvilken funktionalitet produktet skal give for at nå personas mål. ” Brug af personas til at styrke brugermål giver en rigere betydning af hvorforen historie er vigtig og hjælper med at prioritere efterslæbet.

3. Svar på, hvorfor historien er vigtig

At forstå, dokumentere og diskutere brugerbehov eller mål for brugerpersona er kun en dimension omkring hvorforproduktejeren prioriterer historier. Historien skal også give forretningsværdi, noget der er svært at kvantificere, men kan være kvalificerbarpå historien, funktion, episk eller frigivelsesniveau.

Besvarer hvorforkan være vigtigt for udviklerne, når de har beføjelse til at foreslå forskellige implementeringsmuligheder. For eksempel kan en funktion, der forbedrer loginoplevelsen for brugere, også gavne virksomheden, hvis den nye oplevelse også genererer bedre kundedata. En udvikler kan reflektere over denne ekstra forretningsværdi og optimere implementeringen til dette mål, selvom historiens acceptkriterier ikke er specifikke for dette krav.

4. Definer acceptkriterier uden at ordinere en løsning

Den mest betydningsfulde disciplin at fokusere på i historisk skrivning er ved at udarbejde acceptkriterier. Disse er ofte punktopstillede lister over korte pass-or-fail-udsagn, der dokumenterer krav, begrænsninger, metrics og forventninger. Disse acceptkriterier bruges ofte på flere måder:

  • Tekniske kundeemner og hold bruger dem til at estimere historiepoint baseret på kompleksitet og indsats.
  • Udviklere indsnævrer implementeringsmulighederne til dem, der opfylder acceptkriterier.
  • Produktejere kan reducere omfanget eller kompleksiteten af ​​acceptkriterier for at drive implementeringer med lavere estimater.
  • Modtageren kommunikerer blokke eller problemer, der opfylder vanskelige kriterier under standups.
  • Kvalitetssikringsingeniører bruger acceptkriterier til at udvikle automatiserede tests.
  • Produktejeren gennemgår nøglekriterier under den smidige demo for at sikre, at historien er Færdig.

At skrive acceptkriterier er ikke trivielt. Acceptkriterier for acceptkriterier fremhæver nogle af problemerne, såsom at give for mange kriterier, definere kriterier, der er for vage eller dokumentere komplekse kriterier, der ikke let kan verificeres. Nogle forfattere bruger acceptkriterier, der definerer en struktur for korte, atomare og testbare kriterier.

5. Brug historier til at definere hvad og hvorfor; definere opgaver om, hvordan man implementerer

En af de kritiske fejl, jeg ser hold lave omkring historisk skrivning, er at være detaljeret og specifik omkring implementeringen. Disse dårligt skrevne historier investerer meget i at beskrive hvordanat implementere ofte på bekostning af at beskrive hvadbrugeren har brug for, hvorfordet adresserer deres mål, og hvordet driver forretningsværdi.

Der er et par grunde til, at dette kan ske.

Uerfarne produkt ejere kan bruge historier til at male deres implementeringsvisioner. Med andre ord kan de specificere for meget brugerdesign og funktionelle implementeringer i stedet for at dele målbrugeroplevelsen og fordelene. Nogle produkt ejere forveksler deres konceptualisering af, hvordan noget magtarbejde (den proces, hvorved de kommer til at forstå kravene) med, hvordan det skulle gernearbejde, ved et uheld at gøre et internt implementeringseksempel til en ekstern implementeringsspecifikation.

Andre produktejere overskrider måske deres grænser ved at bede holdet om at "bygge mig dette." Det er en af ​​mine 20 dårlige opførsler hos produktejere, som jeg har anbefaling til produktejere om at samarbejde med teamet omkring løsninger.

Den anden grund til, at historier kan blive rodet med implementeringsdetaljer, er, at nogle hold og tekniske kundeemner ønsker dette niveau af detaljer. Nydannede tekniske teams, der arbejder på at forbedre eksisterende applikationer, kan ønske dette niveau af detaljer, indtil de bedre forstår, hvordan applikationen fungerer og fuldt ud forstår brugernes behov. Nogle distribuerede hold, der arbejder med offshore-udviklere eller freelancere, vil måske også dokumentere implementeringsoplysningerne for at sikre, at disse medlemmer forstår deres ansvar.

For sådanne teams er den bedste ting at gøre at linke til implementeringsdiagrammer og dokumentere, hvem der gør hvad og hvordan som opgaver knyttet til historien. De fleste agile styringsværktøjer tillader opgaver eller underopgaver, og dette detaljeringsniveau er normalt adskilt fra historiens krop. Et diagram i dette indlæg gør et godt stykke arbejde, der illustrerer dette vigtige princip om at bruge smidige historier til at nedbryde brugeroplevelser og forretningsprocesser og tilføje opgaver for at definere implementeringen til individuelle stykker arbejde.

6. Tag dine historier for at skabe analyser og øge forbedringer

Når historier er skrevet, bearbejdet og afsluttet, ser mange hold ud til at registrere metrics og udføre analyser, der kan skabe procesforbedring eller bruges til at lave forretningssager for ekstra investering.

Her er nogle eksempler:

  • Mærk historier som teknisk gæld for at kvantificere gældens størrelse, procentdelen af ​​holdets hastighed, der blev brugt til at adressere den, og den samlede gæld afsluttet med hver frigivelse.
  • Definer funktionelle og tekniske spikehistorier for at skabe eksperimenter og innovation, og rapporter derefter om, hvor det har forretningspåvirkning.
  • Hvis dit team estimerer agile brugerhistorier, skal du bede teamet om at tagge historier i slutningen af ​​sprinten for at signalere, om de overvurderede eller undervurderede for at forbedre nøjagtigheden af ​​estimaterne.
  • Brug etiketter, komponenter og brugerdefinerede felter til at hjælpe med at søge i efterslæbet efter historiske forståelser eller metrics. For eksempel at vide, hvilke historier der påvirkede API'erne, eller hvilke krav der førte til de sidste funktionelle forbedringer af et specifikt område af applikationen, kan gøres, når historier tagges til funktionelle og tekniske komponenter.
  • Tag historier, der indsamler eller behandler følsomme oplysninger, såsom personligt identificerbare oplysninger (PII), e-handelstransaktioner eller branchestyrede data såsom HIPAA-data for at muliggøre gennemgang af sikkerhed og overholdelse.
  • Giv feedback til produktejeren og teamet. Ud over at markere en historie Færdig, kunne en produktsejer også give feedback til teamet, såsom at anerkende en godt arbejde. På samme måde kan teamet give feedback til produktejeren om den overordnede kvalitet og fortolkbarhed af en brugerhistorie.

7. Definer smidige historiens skabeloner og stilguider

Større organisationer, der arbejder med flere adræt hold og produkt ejere, vil måske udarbejde standarder og stilguider til historisk skrivning. Konsistensen hjælper nye produktejere med at lære skriftlige færdigheder hurtigere og forbedrer også teammedlemmernes effektivitet i at forbruge informationen.

En anden grund til at designe historiens skabeloner er, at forskellige typer produkter og applikationer egner sig til forskellige brugerhistoriske udtryk og artefakter. Nogle eksempler:

  • Forretningsproceshistorier kræver muligvis links til workflowdiagrammer og angiver også roller og tilladelser.
  • Kundevendte applikationshistorier skal have links til wireframes og omfatte præstationskriterier.
  • API-historier skal dokumentere forventede brugsmønstre og metrics.
  • Business intelligence og datavisualiseringshistorier skal give retningslinjer for, hvilke felter og information der er behov for til den anmodede analyse.

Skabeloner hjælper med at bygge bro over kommunikationen mellem teams og produkt ejere om, hvad man skal fokusere på, når man skriver smidige historier.

Og er det ikke meningen med smidige historier? Agile historier om at skrive historier, retningslinjer og principper er der for at hjælpe teams med at vide, hvad der er vigtigt for brugerne og for virksomheden, inden de overvejer, hvordan de skal implementeres.

$config[zx-auto] not found$config[zx-overlay] not found