Paano Sumulat ng User Stories (may Halimbawa at Acceptance Criteria)

Ang user story ay maikling paglalarawan ng isang feature mula sa pananaw ng user: “Bilang [uri ng user], gusto ko [layunin] para [dahilan].” Sa ilalim nito, isinusulat mo ang acceptance criteria, ilang tiyak na kondisyong dapat totoo para mabilang na tapos ang story. Panatilihing sapat na maliit ang bawat story para mabuo at masubukan sa isang tagpo, at isulat ang criteria nang ganoon na sinuman ay makakapag-check.

Sikat ang user stories sa mga agile software team, pero kapaki-pakinabang din ang mga ito kapag nagtatayo ka nang mag-isa gamit ang AI app builder. Ang magandang story ay magandang prompt.

Ang format

May tatlong bahagi ang user story:

Bilang [sino], gusto ko [ano] para [bakit].

• Sino ay tiyak na uri ng user: first-time visitor, paying member, receptionist ng klinika, admin. Hindi “ang user” lang.
• Ano ay ang gusto nilang gawin, sa sarili nilang salita. Hindi kung paano gumagana ang screen.
• Bakit ay ang resultang pinapahalagahan nila. Ito ang bahaging madalas nalalaktawan, at ito rin ang pumipigil sa iyong gumawa ng maling bagay.

Halimbawa:

Bilang miyembro ng gym, gusto ko kanselahin ang booking sa klase mula sa phone ko para makakuha ng slot ang nasa waitlist at hindi ako masisingil ng no-show fee.

Ipinapakita ng “bakit” ang dalawang bagay na hindi sinabi ng “ano”: kailangang gumana sa phone, at kasama rito ang waitlist at ang mga patakaran sa bayad.

Acceptance criteria

Sinasabi ng story kung ano ang gusto. Sinasabi ng acceptance criteria kung kailan ito tapos. Dapat sapat na tiyak ang mga ito para magkasundo ang dalawang tao kung pasado ang bawat isa.

Karaniwang paraan ng pagsulat ang Given / When / Then:

• Given ang isang panimulang sitwasyon
• When may ginawa ang user
• Then ito ang resulta

Para sa gym booking story:

1. Given may booking ako nang higit sa 12 oras ang layo, when tinap ko ang Cancel at kinumpirma, then tinatanggal ang booking at nakikita ko ang “Booking cancelled.”
2. Given kinansela ko ang booking at may waitlist ang klase, when na-save ang pagkansela, then ang unang nasa waitlist ang makakakuha ng slot at makakatanggap ng email.
3. Given booking na wala pang 12 oras ang layo, when tinap ko ang Cancel, then nakikita ko na may late-cancellation fee bago ko kumpirmahin.
4. Given nasa screen ako na kasing-lapad ng phone, then nakikita ang Cancel button nang hindi kailangang mag-scroll sa gilid.

Puwede rin ang simpleng checklist, basta bawat item ay masusubukan. Ang “madaling kanselahin” ay hindi masusubukan. Ang “hindi lalampas sa dalawang tap mula sa listahan ng booking ang pagkansela” ay masusubukan.

Hakbang-hakbang: pagsulat ng magandang story

Hakbang 1: Magsimula sa totoong user at totoong problema

Pumili ng isang uri ng user at isang bagay na nahihirapan sila ngayon. Kung nakausap mo na ang mga customer, gamitin ang sarili nilang salita. Mas magandang panimula ang “lagi kong nakakalimutang kanselahin kaya nasisingil ako” kaysa sa “magdagdag ng feature na pagkansela.”

Hakbang 2: Isulat ang isang linyang story

Punan ang template. Kapag hindi mo maisulat nang kapani-paniwala ang “para,” itanong kung kailangan pa ba talaga ang feature.

Hakbang 3: Magdagdag ng tatlo hanggang anim na acceptance criteria

Unahin ang pangunahing matagumpay na kaso, saka ang mahahalagang variation: ibang role, walang laman na estado, limitasyon, o error. Kung lalampas sa anim ang isinusulat mo, malamang masyadong malaki na ang story.

Hakbang 4: Tandaan kung ano ang wala sa saklaw

Isang linya lang ang nakakatipid ng maraming palitan ng mensahe: “Wala sa saklaw: refund para sa bayad na klase; pagkansela ng admin para sa mga miyembro.” Pinipigilan nitong lumaki ang story habang ginagawa mo ito.

Hakbang 5: I-check ito laban sa INVEST

Ang INVEST ay karaniwang checklist para sa magagandang story. Dapat ang story ay:

Hindi mo kailangang markahan ang bawat story. Pinakamakabuluhan ito kapag may parang mali sa isang story at gusto mong malaman kung bakit.

Mabuti at masamang halimbawa

Paano hatiin ang story na masyadong malaki

Doon madalas tumitigil ang mga proyekto sa malalaking story. Mga karaniwang paraan ng paghahati:

• Ayon sa uri ng user. Kinakansela ng miyembro ang sariling booking; kinakansela ng staff ang booking ng kahit sino.
• Ayon sa hakbang sa daloy. I-browse ang mga klase; mag-book ng klase; makatanggap ng paalala.
• Simpleng kaso muna. Kanselahin ang libreng klase ngayon; ang bayad at refund ay sa susunod na story.
• Ayon sa pagkakaiba ng data. Isang lokasyon muna; marami sa susunod.
• Happy path muna, saka ang mga error. Gawing gumagana muna, saka idagdag ang paghawak sa puno na klase, expired na pass, at iba pa.

Dapat may magagamit at mapapansin pa rin ang bawat piraso ng user.

Paggamit ng user stories bilang prompt

Halos magandang prompt para sa AI app builder ang user story na may acceptance criteria. Ibinibigay nito sa AI ang sino, ano, bakit, at kahulugan ng tapos. Isang story sa bawat mensahe ang ipadala:

Bilang miyembro ng gym, gusto kong kanselahin ang booking sa klase mula sa phone ko para makakuha ng slot ang nasa waitlist. Acceptance criteria:

1. Nasa bawat booking sa My Bookings ang Cancel, may hakbang ng kumpirmasyon.
2. Kapag higit sa 12 oras bago ang klase ang pagkansela, tatanggalin lang ang booking.
3. Kapag wala pang 12 oras, ipakita ang “May late-cancellation fee na $5” bago kumpirmahin, at itala ang fee sa booking.
4. Kung may waitlist ang klase, ang unang tao ang makakakuha ng slot at makakatanggap ng email.
5. Gumagana sa screen na kasing-lapad ng phone. Wala sa saklaw: refunds, pagkansela ng staff para sa mga miyembro. Buuin ito, saka i-check ang bawat criterion sa preview at sabihin kung alin ang pumasa.

Puwede mo ring hilingin sa AI na gumawa ng mga story mula sa magaspang na ideya, saka ikaw mismo ang mag-edit:

Ito ang idea ng app ko: [dalawa o tatlong pangungusap]. Sumulat ng user stories para sa unang bersyon, nakapangkat ayon sa uri ng user, bawat isa may 3 hanggang 5 na Given/When/Then acceptance criteria. Markahan kung alin ang mahalaga para sa paglulunsad at alin ang puwedeng maghintay.

Laging basahin at i-edit ang resulta. Hindi kilala ng AI ang iyong users; ikaw ang nakakakilala.

Gumagana rin ang acceptance criteria bilang test plan mo. Kapag natapos na ang story, dumaan ka isa-isa sa bawat criterion. Nakabatay dito ang gabay namin sa testing your app before launch.

Saan kasya ang user stories kasama ng ibang dokumento

• Inilalarawan ng product requirements document ang buong produkto: ang problema, ang users, ang saklaw. Ang user stories ang mga detalyadong bahagi sa loob nito. Tingnan ang how to write a PRD with AI.
• Inilalarawan ng bug report ang isang bagay na sira kumpara sa story na nabuo na. Tingnan ang how to write a good bug report.
• Ang MVP ay ang pinakamaliit na hanay ng stories na naghahatid ng pangunahing halaga. Tingnan ang what is an MVP.

Mga karaniwang pagkakamali

• “Bilang user…” Masyadong malabo. Pangalanan ang tunay na uri ng user.
• Pagkalaktaw sa “para.” Kung walang dahilan, hindi ka makakapagdesisyon nang maayos sa mga trade-off.
• Pagsulat ng solusyon sa halip na pangangailangan. Ang “gusto ko ng dropdown” ay nagkakandado ng disenyo bago pa pag-isipan ng sinuman.
• Criteria na hindi masusubukan. Ang “madali,” “mabilis,” at “intuitive” ay mga hiling, hindi criteria.
• Mga story na talagang epic. Ang “pamahalaan ang account ko” ay sampung story.
• Pagsulat ng bawat story nang maaga. Isulat nang detalyado ang susunod na ilan; panatilihing isang linya ang iba hanggang doon na lang sila dumating.

Mga story sa Mythex

Sa Mythex, magandang lugar ang Plan mode para gawing story ang ideya: pinag-uusapan ng agent ang approach bago mag-edit ng kahit ano. Kapag handa na ang story, lumipat sa Build at idikit ito, isang story sa bawat mensahe. Pagkatapos ng bawat isa, puwedeng i-klik ng /test ang preview at i-check ang daloy, at puwede mong ibalik ang alinmang reply gamit ang Revert to this point kung mali ang nangyari. Tingnan ang effective prompts sa docs, at ang gabay namin tungkol sa writing prompts for AI app builders.

Checklist ng user story

• Pinangalanan ang tiyak na uri ng user
• Inilalarawan ang pangangailangan, hindi ang disenyo
• May tunay na “para” na dahilan
• May tatlo hanggang anim na masusubukang acceptance criteria
• Sakop ang kahit isang edge case o error
• Nakasaad kung ano ang wala sa saklaw
• Sapat na maliit para mabuo at masubukan sa isang tagpo
• Na-check ang criteria pagkatapos gawin, isa-isa

Mga tanong