Et kjerneelement av smidig programvareutvikler det gjør brukerne og kundene i fokus, og brukerhistoriene bidrar til å gjøre akkurat det. De setter sluttbrukerne i sentrum av samtalen. I denne artikkelen skal vi diskutere en brukerhistorie i smidig.
Historier bruker ikke-teknisk språk for å gi betingelser for utviklingsteamet og deres innsats. Brukerhistorien hjelper teamet til å forstå sitt eget mål, hvorfor de bygger det. Også hva de bygger og verdien som det skaper på slutten og underveis. Dermed er brukerhistorier en av de viktigste komponentene i et smidig program. De legger til rette for kreativitet, fremgang og et bedre sluttprodukt ved å gi teamet et brukerfokusert rammeverk for sine daglige oppgaver. Alle smidige historier fokuserer på kravene og er med på å skape samtaler gjennom en eller to setninger om ønsket funksjonalitet.
Temaene som er diskutert i denne artikkelen er:
- Hva er brukerhistoriene?
- Hvem er ansvarlig for å skrive en brukerhistorie?
- Når skal jeg skrive brukerhistorier?
- Hvorfor lage brukerhistorier?
- Arbeide med brukerhistorier
Hva er brukerhistorier?
Brukerhistorier er enkle og korte beskrivelser av en funksjon av en bruker eller kunde av systemet. De følger en vanlig mal:
Som en vil jeg ha det.
hvordan du kan unngå fastlåst tilstand i java
La oss få vite mer om brukerhistorier.
- Vanligvis blir brukerhistorier skrevet på klistrelapper og indekskort. Deretter ordnes de på bord eller vegger for planleggings- og diskusjonsformål, og det opprettes derfor samtaler rundt dem.
- Brukerhistorier, som er diskusjoner som dreier seg om og ved hjelp av brukerhistoriene, er veldig viktige og skifter fokus fra å skrive om funksjoner til å faktisk diskutere dem.
- De uttrykkes alltid fra brukerens perspektiv og klassifiseres ikke som en funksjon. En brukerhistorie er den minste delen av et smidig rammesystem.
- Hovedmålet med en brukerhistorie er å uttrykke og overføre hvordan et bestemt stykke arbeid vil gi verdi til brukeren eller kunden. Det er viktig å merke seg at kunder ikke nødvendigvis trenger å være eksterne sluttbrukere, men kan også være kolleger i teamet ditt eller i organisasjonen din.
- Brukerhistorier våger seg ikke i detaljer og består av enkle og få setninger.
Brukerhistorier i Scrum og Kanban
Både Scrum og Kanban bruker brukerhistorier i sine rammer. I Scrum er brukerhistorier et tillegg til sprints og brukes i løpet av sprinten. I KanBan legger team brukerhistoriene inn i etterslaget og bruker dem gjennom arbeidsflyten. Dermed hjelper de med bedre estimering, sprintplanlegging, bedre nøyaktighet i prognoser og større smidighet i Scrum-teamet. På den annen side kan KanBan-teamene håndtere bedre pågående arbeid og forbedre arbeidsflytene sine gjennom brukerhistorier.
Større smidige rammer som epos og initiativer utgjør brukerhistorier. Epics er større emner som er delt inn i mange historier og initiativer som består av mange epics.
Det er to måter å legge til detaljer i brukerhistoriene:
- Ved å dele brukerhistorien i mindre flere historier.
- Ved å legge til betingelser for tilfredshet.
En tilfredshetstilstand refererer til en akseptantest på høyt nivå som gjør seg gjeldende når den smidige brukerhistorien er fullført.
Hvem er ansvarlig for å skrive brukerhistorien?
Det er ingen faste regler angående hvem som kan skrive brukerhistoriene. Produkteieren må sørge for at produktforsinkelsen til brukerhistoriene er på plass, men han trenger ikke nødvendigvis å skrive dem. Ideelt sett, agodt smidig prosjekt vil ha brukerhistorier skrevet av hvert teammedlem, og mer vekt vil bli gitt til at teammedlemmene er like involvert i diskusjonene etter å ha skrevet brukerhistoriene.
Når skal jeg skrive brukerhistorier?
Brukerhistorier er unnfanget gjennom det smidige prosjektet. En workshop om å skrive historier gjennomføres vanligvis i begynnelsen av det smidige prosjektet, slik at hvert teammedlem kan delta og potensielt bidra til å lage et produktetterslep som beskriver ønsket funksjonalitet og sluttmål som deretter kan legges til prosjektet. Noen av brukerhistoriene vil ende opp med å bli episke. I tillegg vil disse eposene senere bli brutt nedi flere mindre historier som passer bedre inn i en iterasjon. Nye historier kan også tilføres fra tid til annen til produktetterslepet i henhold til krav.
hva er anskaffelse i prosjektledelse
Hvorfor lage brukerhistorier?
En brukerhistorie i smidig kan virke som et ekstra trinn i den smidige rammeprosessen, men de gir viktig og verdifull innsikt til teamet og opplyser teen om verdien deres oppgaver gir prosjektet. Brukerhistorier gir en rekke fordeler og fordeler:
- Foster brukerfokus - En oppgaveliste holder vanligvis teamet på tærne med oppgavene som må gjøres og sjekkes av listen, mens brukerhistorier setter hele fokuset på brukerne og hjelper til med å løse problemene når de er skrevet fra brukerens perspektiv. .
- Aktiver samarbeid - Når sluttmålet er klart og definert for teamet, kan de jobbe effektivt sammen for å nå det målet, samt gi tilfredshet og god service til brukeren.
- Driv kreativiteten - Prosessen med å skrive og diskutere brukerhistorier innebærer diskusjoner og idédugnad som hjelper teamet til å tenke kritisk så vel som kreativt, så vel som muligens komme med løsninger for å nå det endelige målet.
- Gi fart - Hver historie gir utvikling til teamet gjennom utfordringer og fremgang.
Arbeide med brukerhistorier
- En brukerhistorie blir konseptualisert og skrevet, så blir den absorbert og implementert i arbeidsflyten. Vanligvis skriver produkteiere, produktsjefer eller programledere brukerhistorier. Deretter sender de dem til gjennomgang.
- Under et sprint- eller iterasjonsplanleggingsmøte tar teamet en beslutning om hvilke historier som vil bli inkludert i løpet av den aktuelle sprinten. I tillegg diskuterer teamene funksjonaliteten og kravene til historien. Krav kan legges til historien etter at teamet er enige om det.
- Et viktig trinn i dette møtet er å vurdere historiene ut fra deres kompleksitet og fullføringstid. En historie skal kunne fullføres på en sprint. Av denne grunn trenger teamet å diskutere historiene.
Brukerhistorier kaster lys over den daglige driften av utviklingsteamet, samt forklarer prosessene som følges av teamet hver dag. Den beste måten å utnytte dem i prosjektet ditt for å avdekke fordelene, er å forstå deres rolle og bidrag til teamets arbeid og levering.
Det er det, folkens! Med dette har vi nådd slutten av artikkelen ‘User Story in Agile’. Du kan også se på mens du er i gang.
Har du spørsmål til oss? Vennligst nevn det i kommentarfeltet til denne a rticle og vi kommer tilbake til deg så snart som mulig.