Lucrez la o aplicație pentru a ajuta la crearea unei liste de produse alimentare pe baza meselor (și a ingredientelor și cantității acestora) pe care le furnizează utilizatorul. Până în prezent, epopeile cu care am venit sunt:

1.) Cercetare (unități de măsură, produse alimentare și categorii populare etc.)

3.) Scenarii (au hrană și rețetă posibilă, au nevoie de mese etc.)

4.) Frigiderul meu (caracteristică care permite utilizatorului să stocheze ceea ce are deja în frigider)

5.) Unități de măsură (detectare locală? Cum permitem utilizatorului să comute între sistemele imperiale și cele metrice)

6.) Lista de produse alimentare (cum se afișează, cea mai bună modalitate de afișare, e-mail/sms lista de produse alimentare pentru sine, e-mail/sms către alții etc.)

7.) Mâncare (trebuie să găsim cel mai comun mod de măsurare a fiecărui aliment, să afișăm caloriile etc.)

Creez epopee pe componente majore ale aplicației. Acesta este modul corect de a le încadra?

3 Răspunsuri 3

Conform informațiilor pe care le-ați furnizat, pare a fi ok. Nu aș crea o epopee numită cercetare, ci aș folosi în schimb vârfuri.

„Creez epopee pe componentele majore ale aplicației. Este acesta modul corect de a le încadra?”

Aș sugera încadrarea epopeilor ca o funcționalitate care poate fi livrată și testată în semi-izolare.

Dintre cele pe care le-ați menționat:

Cercetarea și scenariile nu mă simt ca epopee: cercetarea este un vârf și documentarea scenariilor face parte din lucrarea de documentare a epopeilor

Capacitate de conectare, Frigiderul meu și Unități de măsură - Acestea au sens pentru mine ca propriile lor epopee

Alimentație - Cercetarea alimentară intră sub vârful cercetării. Presupunând că există un afișaj/depozitare separat pentru alimente (nu la fel ca frigiderul), am putut vedea că aceasta este propria epopee.

Lista de produse alimentare - Aceasta se simte ca epopee multiple. Stocarea și afișarea listei de produse alimentare ar putea fi una, dar trimiterea listei reale ar putea fi o epopă separată.

Nu am intrat în MVP, dar ca parte a listării epopeilor dvs., ar trebui să aveți o idee clară despre ceea ce este absolut necesar. Dacă obiectivul dvs. este doar stocarea produselor alimentare, atunci conectarea și partajarea nu sună ca MVP.

managementul

Acest lucru nu este în conformitate cu metodologia Agile și cu principiile de gestionare a produselor; asta înseamnă că nu vei fi mulțumit de rezultat la final.

Amintiți-vă, la sfârșitul unei Epic, doriți ca utilizatorul să poată face cel puțin ceva.

Înainte de a crea Epics, ar trebui să decideți care este MVP-ul dvs., produsul dvs. minim viabil. De exemplu: dacă obiectivul dvs. este să creați o listă de produse alimentare pe baza meselor pe care le oferă utilizatorul.

  • nu ar trebui să includă datele de conectare, deoarece utilizatorul vă poate folosi aplicația chiar dacă nu există date de conectare și poate obține satisfacție instantanee.
  • ar trebui să fie simplu. Să luăm o poveste despre utilizator: Bob este capabil să deschidă aplicația și să introducă mese pe care îi place să mănânce: spaghete, burgeri și pizza pentru întreaga săptămână. Vrea să vadă o listă de alimente: tăiței pentru paste, sos pentru paste, carne măcinată.

Apoi, doriți să decideți cât timp va dura acest lucru: să spunem 3 sprinturi (de exemplu, 6 săptămâni). Deci poate că primul Sprint va fi să creeze pagina de introducere a utilizatorului, următorul Sprint va fi pagina de ieșire, apoi următorul Sprint va fi stratul logic.

Acest lucru se întâmplă numai după ce ați realizat proiectarea și cercetarea într-o poveste a utilizatorului și potrivirea pieței.