Som en som fortsatt er ny i agile, er jeg ikke sikker på om jeg helt forstår forholdet eller forskjellen mellom user story, feature og epic.
Ifølge dette spørsmålet er en feature en samling historier. Et av svarene antyder at en feature faktisk er et epos. Betraktes features og epics som det samme, altså en samling relaterte brukerhistorier?
Prosjektlederen vår insisterer på at det er en hierarkisk struktur:
Epos -> Funksjoner -> Brukerhistorier
Og at i utgangspunktet må alle brukerhistorier falle innenfor denne strukturen. Derfor må alle brukerhistorier falle inn under en paraplyfunksjon, og alle funksjoner må falle inn under en epic.
For meg høres det vanskelig ut. Kan noen forklare hvordan brukerhistorier, funksjoner og epics henger sammen? Eller finnes det en artikkel som tydelig beskriver forskjellene?
Det er egentlig et veldig generisk begrep. Det er mange måter å tolke dem på, og det varierer i litteraturen og hvordan folk oppfatter dem. Ta alt jeg sier med en stor klype salt.
Vanligvis omfatter en Epic en svært global og ikke særlig veldefinert funksjonalitet i programvaren din. Det er veldig bredt. Det vil vanligvis brytes ned til mindre brukerhistorier eller funksjoner når du prøver å forstå dem og få dem til å passe inn i en smidig iterasjon. Eksempel:
**Episk
Feature og User Story er mer spesifikk funksjonalitet som du enkelt kan teste med akseptansetester. Det anbefales ofte at de er detaljerte nok til å få plass i én enkelt iterasjon.
Funksjoner beskriver vanligvis hva programvaren gjør:
**Funksjon
Brukerhistorier har en tendens til å uttrykke hva brukeren ønsker å gjøre:
**Brukerhistorie Som bankansatt, ønsker jeg å kunne endre kundeinformasjonen min slik at jeg kan holde den oppdatert.
Jeg tror egentlig ikke det er noe hierarki mellom de to, men du kan ha et hvis du vil, eller hvis det passer til hvordan du jobber. En brukerhistorie kan være en spesifikk begrunnelse for en funksjon, eller en spesifikk måte å gjøre det på. Eller det kan være omvendt. En funksjon kan være en måte å realisere en brukerhistorie på. Eller de kan betegne det samme. Du kan bruke begge deler: brukerhistorier for å definere hva som gir forretningsverdi, og funksjoner for å beskrive begrensninger i programvaren.
Brukerhistorie: Som kunde ønsker jeg å betale med de mest populære kredittkortene. Funksjon støtter myndighetenes GOV-TAX-02 XML API.
Det er også et spørsmål om scenarioer, som vanligvis er en måte en Feature/User story vil bli utført på. De kan vanligvis kobles til en spesifikk akseptansetest. For eksempel
Scenario : Ta ut penger Gitt at jeg har 2000$ på bankkontoen min Når jeg tar ut 100$ Så mottar jeg 100$ i kontanter Og saldoen min er 1900$
Det er slik vi definerer disse begrepene der jeg jobber. Disse definisjonene er langt fra en matematisk definisjon eller et standardisert begrep. Det er som forskjellen mellom en høyre- og en venstrepolitiker. Det kommer an på hvor du bor. Det som anses som høyreorientert i Canada, kan anses som venstreorientert i USA. Det er veldig varierende.
Seriøst, jeg ville ikke brydd meg for mye om det. Det viktige er at alle i teamet er enige om en definisjon, slik at dere kan forstå hverandre. Noen metoder, som scrum, har en tendens til å definere dem mer formelt, men velg det som fungerer for deg, og la resten ligge. Når alt kommer til alt, handler ikke smidig om Individer og samspill fremfor prosesser og verktøy og Fungerende programvare fremfor omfattende dokumentasjon?
Episk: En veldig stor brukerhistorie som etter hvert brytes ned i mindre historier.
User story: En definisjon av et krav på svært høyt nivå, som inneholder akkurat nok informasjon til at utviklerne kan gi et rimelig estimat av innsatsen for å implementere det.
http://www.telerik.com/agile-project-management-tools/agile-resources/vocabulary.aspx
Funksjon: Et kjennetegn eller en egenskap ved en programvare eller et bibliotek (f.eks. ytelse, portabilitet eller funksjonalitet).
Det er bare nedbrytning av problemer. Det er bare historier, bare i forskjellige størrelser.
Personlig foretrekker jeg ikke å merke størrelsene, men hvis du gjør det, er det også greit. Spør PM-en din hva definisjonen er i arbeidsområdet ditt.