User Story ရေးနည်း (ဥပမာများနှင့် လက်ခံချက် စံနှုန်းများ)

user story ဆိုသည်မှာ အသုံးပြုသူ၏ အမြင်ဖြင့် feature ကို တိုတိုရေးထားသော ဖော်ပြချက်ဖြစ်သည်- "[အသုံးပြုသူအမျိုးအစား] အနေဖြင့်၊ [ရည်မှန်းချက်] ကို လိုချင်သည်၊ [အကြောင်းရင်း] ကြောင့်။" ၎င်းအောက်တွင် acceptance criteria ကို ရေးသည်၊ ၎င်းသည် story ပြီးဆုံးသည်ဟု ရေတွက်ရန် သတ်သတ်မှတ်မှတ် အခြေအနေအနည်းငယ် ဖြစ်သည်။ story တစ်ခုစီကို တစ်ထိုင်တည်းတွင် တည်ဆောက်ပြီး စမ်းသပ်နိုင်လောက် သေးငယ်အောင် ထားပါ၊ လူတိုင်း စစ်ဆေးနိုင်အောင် criteria များကို ရေးပါ။

user story များကို agile software team များက ထင်ရှားစေခဲ့သော်လည်း AI app builder ဖြင့် တစ်ယောက်တည်း တည်ဆောက်ရာတွင်လည်း အလားတူ အသုံးဝင်သည်။ ကောင်းသော story သည် ကောင်းသော prompt ဖြစ်သည်။

ပုံစံ

user story တွင် အပိုင်း သုံးပိုင်းရှိသည်-

As a [ဘယ်သူ]၊ I want [ဘာ] so that [ဘာကြောင့်]။

• ဘယ်သူ ဆိုသည်မှာ သတ်မှတ်ထားသော အသုံးပြုသူအမျိုးအစား ဖြစ်သည်- ပထမဆုံးအကြိမ် ဝင်ရောက်သူ၊ ပေးဆောင်သော အဖွဲ့ဝင်၊ ဆေးရုံ receptionist၊ admin။ "user" ဟု မရေးပါနှင့်။
• ဘာ ဆိုသည်မှာ ၎င်းတို့ ကိုယ်တိုင်၏ စကားဖြင့် လုပ်ချင်သော အရာဖြစ်သည်။ မျက်နှာပြင် မည်သို့ အလုပ်လုပ်သည် မဟုတ်ပါ။
• ဘာကြောင့် ဆိုသည်မှာ အသုံးပြုသူ ဂရုစိုက်သော outcome ဖြစ်သည်။ လူများ ကျော်တတ်သော အပိုင်းဖြစ်ပြီး မှားသော အရာကို တည်ဆောက်မိခြင်းကို တားဆီးသည်။

ဥပမာ-

ဂျင်မ်အဖွဲ့ဝင် အနေဖြင့်၊ ကျွန်ုပ်ဖုန်းမှ class booking ကို ဖျက်လိုသည် ၊ ထို့ကြောင့် waitlist ရှိ တစ်စုံတစ်ဦးက ကျွန်ုပ်နေရာကို ယူနိုင်ပြီး no-show ကြေး မပေးရပါ။

"ဘာကြောင့်" က "ဘာ" မပြောခဲ့သော အရာ နှစ်ခုကို ပြောသည်- ဖုန်းပေါ်တွင် အလုပ်လုပ်ရမည်၊ waitlist နှင့် ကြေးစည်းမျဉ်းများ ပါဝင်သည်။

Acceptance criteria

story က ဘာလိုချင်သလဲ ပြောသည်။ acceptance criteria က ဘယ်တော့ ပြီးသလဲ ပြောသည်။ လူနှစ်ဦးက တစ်ခုစီ အောင်မြင်သလား ဆိုသည်ကို သဘောတူနိုင်လောက် တိကျရမည်။

အသုံးများသော ရေးနည်းမှာ Given / When / Then ဖြစ်သည်-

• Given စတင်အခြေအနေ
• When အသုံးပြုသူ တစ်ခုခု လုပ်သည်
• Then ဤသည်မှာ ရလဒ်

ဂျင်မ်ဘွတ်ကင် story အတွက်-

1. Given နာရီ ၁၂ နာရီထက် ဝေးသော booking ရှိသည်၊ when ကျွန်ုပ် Cancel ကို နှိပ်ပြီး အတည်ပြုသည်၊ then booking ဖယ်ရှားပြီး "Booking cancelled" ကို မြင်ရသည်။
2. Given booking ကို ဖျက်ပြီး class တွင် waitlist ရှိသည်၊ when ဖျက်ခြင်း သိမ်းသည်၊ then waitlist ရှိ ပထမဆုံးသူက နေရာနှင့် email ရသည်။
3. Given နာရီ ၁၂ နာရီအတွင်း booking ရှိသည်၊ when ကျွန်ုပ် Cancel ကို နှိပ်သည်၊ then အတည်မပြုမီ နောက်ကျဖျက်ခြင်း ကြေး သက်ရောက်ကြောင်း မြင်ရသည်။
4. Given ကျွန်ုပ် ဖုန်းအကျယ် မျက်နှာပြင်တွင် ရှိသည်၊ then Cancel ခလုတ်သည် ဘေးသို့ scroll မလုပ်ဘဲ မြင်ရသည်။

ရိုးရိုး checklist လည်း အလုပ်ဖြစ်သည်၊ တစ်ခုစီ စမ်းသပ်နိုင်သရွေ့။ "ဖျက်ရလွယ်ကူသည်" သည် စမ်းသပ်၍ မရပါ။ "Cancel သည် booking စာရင်းမှ အများဆုံး ၂ ချက်နှိပ်ရုံ" သည် စမ်းသပ်နိုင်သည်။

အဆင့်လိုက်- ကောင်းသော story ရေးနည်း

အဆင့် ၁: အမှန်တကယ် အသုံးပြုသူနှင့် အမှန်တကယ် ပြဿနာမှ စတင်ပါ

အသုံးပြုသူ အမျိုးအစား တစ်ခုနှင့် ယခု ၎င်းတို့ ခက်ခဲသော အရာကို ရွေးပါ။ customer interview လုပ်ထားလျှင် သူတို့ရဲ့ စကားကို သုံးပါ။ "ကျွန်ုပ် ဖျက်ရန် အမြဲမေ့ပြီး ငွေနှုတ်ခံရသည်" သည် "cancellation feature ထည့်ပါ" ထက် ပိုကောင်းသော စတင်ချက် ဖြစ်သည်။

အဆင့် ၂: တစ်ကြောင်းတည်းသော story ရေးပါ

ပုံစံကို ဖြည့်ပါ။ "ဘာကြောင့်" ကို ယုံကြည်စရာ မရေးနိုင်ပါက feature သည် လိုအပ်ခြင်း ရှိ/မရှိ မေးပါ။

အဆင့် ၃: acceptance criteria သုံးခုမှ ခြောက်ခုထည့်ပါ

အဓိက အောင်မြင်သော ကိစ္စကို ဦးစွာ ဖုံးပါ၊ ထို့နောက် အရေးကြီးသော ကွဲပြားမှုများ- အခန်းကဏ္ဍ ကွဲပြားခြင်း၊ empty state၊ ကန့်သတ်ချက်၊ error။ ခြောက်ခုထက် ပိုရေးနေပါက story သည် ကြီးလွန်းနိုင်သည်။

အဆင့် ၄: scope ပြင်ပ အရာကို မှတ်ပါ

စာကြောင်းတစ်ကြောင်းက အပြန်အလှန် အချိန်အများအပြား ချွေတာသည်- "Scope ပြင်ပ: ငွေပေးထားသော class များအတွက် ငွေပြန်အမ်းခြင်း၊ admin က အဖွဲ့ဝင်များအတွက် ဖျက်ခြင်း။" ၎င်းက တည်ဆောက်နေစဉ် story ကြီးလာခြင်းကို တားသည်။

အဆင့် ၅: INVEST ဖြင့် စစ်ပါ

INVEST သည် ကောင်းသော story အတွက် အသုံးများသော စစ်ဆေးစာရင်း ဖြစ်သည်။ story တစ်ခုသည်-

story တိုင်းကို ရမှတ်ပေးရန် မလိုပါ။ story တစ်ခုက မှားနေသလို ခံစားရပြီး အကြောင်းရင်း သိချင်သောအခါ အသုံးဝင်ဆုံး ဖြစ်သည်။

ကောင်းသော နှင့် မကောင်းသော ဥပမာများ

ကြီးလွန်းသော story ကို ခွဲနည်း

ကြီးမားသော story များက project များကို ရပ်တန့်စေတတ်သည်။ အသုံးများသော ခွဲနည်းများ-

• အသုံးပြုသူ အခန်းကဏ္ဍအလိုက်။ အဖွဲ့ဝင်များက ကိုယ်ပိုင် booking ကို ဖျက်သည်၊ ဝန်ထမ်းများက မည်သူ့ကိုမဆို ဖျက်သည်။
• စီးဆင်းမှုအဆင့်အလိုက်။ class ကို ကြည့်ပါ၊ class ကို ဘွတ်ပါ၊ သတိပေးချက် ရယူပါ။
• ရိုးရှင်းသော ကိစ္စကို အရင်။ အခမဲ့ class ကို ယခု ဖျက်ပါ၊ ကြေးနှင့် ငွေပြန်အမ်းကို နောက် story တွင် ကိုင်တွယ်ပါ။
• data ကွဲပြားမှုအလိုက်။ တည်နေရာတစ်ခုကို အရင် ပံ့ပိုးပြီး အများအပြားကို နောက်မှ ထည့်ပါ။
• အောင်မြင်သည့်လမ်းကြောင်း၊ ထို့နောက် error များ။ အလုပ်လုပ်အောင် အရင်တည်ဆောက်ပြီး class ပြည့်နေခြင်း၊ သက်တမ်းကုန် pass စသည်တို့ကို ထည့်ပါ။

အပိုင်းတစ်ခုစီသည် အသုံးပြုသူက အသုံးပြုနိုင်ပြီး သတိပြုမိနိုင်သင့်သည်။

User story များကို prompt အဖြစ် သုံးခြင်း

acceptance criteria ပါသော user story သည် AI app builder အတွက် ကောင်းသော prompt နှင့် အလွန်နီးစပ်သည်။ ၎င်းသည် AI ကို ဘယ်သူ၊ ဘာ၊ ဘာကြောင့်နှင့် ပြီးဆုံးမှု ကို ပေးသည်။ message တစ်ခုလျှင် story တစ်ခု ပို့ပါ-

ဂျင်မ်အဖွဲ့ဝင် အနေဖြင့်၊ ကျွန်ုပ် ဖုန်းမှ class booking ကို ဖျက်လိုသည်၊ ထို့ကြောင့် waitlist ရှိ တစ်စုံတစ်ဦးက ကျွန်ုပ်နေရာကို ယူနိုင်သည်။ Acceptance criteria: ၁။ My Bookings ရှိ booking တိုင်းတွင် Cancel ရှိပြီး အတည်ပြုအဆင့် ပါသည်။ ၂။ နာရီ ၁၂ နာရီထက် စောစွာ ဖျက်ပါက booking ကို ဖယ်ရှားရုံသာ။ ၃။ နာရီ ၁၂ နာရီအောက်ဆိုလျှင် အတည်မပြုမီ "နောက်ကျဖျက်ခြင်းကြေး $5 သက်ရောက်သည်" ကို ပြပြီး booking တွင် ကြေးကို မှတ်ပါ။ ၄။ class တွင် waitlist ရှိလျှင် ပထမဆုံးသူက နေရာနှင့် email ရသည်။ ၅။ ဖုန်းအကျယ် မျက်နှာပြင်တွင် အလုပ်လုပ်သည်။ Scope ပြင်ပ: ငွေပြန်အမ်းခြင်း၊ ဝန်ထမ်းက အဖွဲ့ဝင်အတွက် ဖျက်ခြင်း။ ဤအရာကို တည်ဆောက်ပြီး preview တွင် criterion တစ်ခုချင်းစီကို စစ်ပြီး မည်သည်တို့ အောင်မြင်သလဲ ပြောပါ။

ရေးပြီးသား idea မှ story များကို AI ကို ရေးခိုင်းနိုင်ပြီး ကိုယ်တိုင် တည်းဖြတ်ပါ-

ကျွန်ုပ်၏ app idea က ဤသို့ဖြစ်သည်- [စာကြောင်း ၂ မှ ၃ ကြောင်း]။ ပထမ version အတွက် user story များကို အသုံးပြုသူအမျိုးအစားအလိုက် အုပ်စုဖွဲ့ရေးပါ၊ တစ်ခုစီတွင် Given/When/Then acceptance criteria ၃ မှ ၅ ခု ပါစေ။ launch အတွက် မရှိမဖြစ်လိုသော အရာများနှင့် နောက်မှ ရနိုင်သော အရာများကို အမှတ်အသားပြပါ။

ရလဒ်ကို အမြဲ ဖတ်ပြီး ကိုယ်တိုင် တည်းဖြတ်ပါ။ AI က သင့်အသုံးပြုသူများကို မသိပါ၊ သင်သိသည်။

acceptance criteria များသည် သင့် test plan အဖြစ်လည်း ဆောင်ရွက်သည်။ story တည်ဆောက်ပြီးနောက် criterion တစ်ခုစီကို ကိုယ်တိုင် ဖြတ်သန်းပါ။ launch မတိုင်မီ app ကို စမ်းသပ်နည်း လမ်းညွှန်သည် ဤအပေါ် တည်ဆောက်ထားသည်။

User story များသည် အခြားစာရွက်စာတမ်းများနှင့် ဘယ်လို ဆက်စပ်သလဲ

• Product requirements document သည် ထုတ်ကုန်တစ်ခုလုံးကို ဖော်ပြသည်- ပြဿနာ၊ အသုံးပြုသူများ၊ scope။ User story များသည် ၎င်းအတွင်းရှိ အသေးစိတ်အပိုင်းများ ဖြစ်သည်။ AI ဖြင့် PRD ရေးနည်း ကို ကြည့်ပါ။
• Bug report သည် ရှိပြီးသား story နှင့် ဆန့်ကျင်ပြီး ပျက်နေသော အရာကို ဖော်ပြသည်။ ကောင်းသော bug report ရေးနည်း ကို ကြည့်ပါ။
• MVP သည် အဓိကတန်ဖိုးကို ပေးသော အနည်းဆုံး story အစုံ ဖြစ်သည်။ MVP ဆိုတာ ဘာလဲ ကို ကြည့်ပါ။

အများဆုံး အမှားများ

• "အသုံးပြုသူအနေဖြင့်…" ကျယ်ပြန့်လွန်းသည်။ အသုံးပြုသူ အမျိုးအစား အမှန်တကယ်ကို နာမည်ပေးပါ။
• "ဘာကြောင့်" ကို ကျော်ခြင်း။ အကြောင်းရင်း မရှိလျှင် ယုတ္တိရှိသော trade-off များ ချနိုင်မည်မဟုတ်ပါ။
• လိုအပ်ချက်အစား ဖြေရှင်းနည်းကို ရေးခြင်း။ "dropdown လိုသည်" သည် တစ်စုံတစ်ယောက်က စဉ်းစားမီ ဒီဇိုင်းကို ထိုးသွင်းခြင်း ဖြစ်သည်။
• စမ်းသပ်၍ မရသော criteria။ "လွယ်ကူသည်"၊ "မြန်သည်" နှင့် "ရိုးရှင်းစွာ နားလည်နိုင်သည်" သည် ဆန္ဒများ ဖြစ်သည်၊ criteria မဟုတ်ပါ။
• အမှန်တကယ် epic ဖြစ်နေသော story များ။ "ကျွန်ုပ်၏ အကောင့်ကို စီမံခြင်း" သည် story ဆယ်ခု ဖြစ်သည်။
• story အားလုံးကို အစကတည်းက ရေးခြင်း။ နောက်ထပ် အရေအတွက်ကို အသေးစိတ်ရေးပါ၊ ကျန်သည်များကို အတိုချုပ် အဖြစ်ထားပါ၊ ရောက်သည့်အခါ ချဲ့ပါ။

Mythex တွင် story များ

Mythex တွင် Plan mode သည် idea ကို story အဖြစ် ပြောင်းရန် ကောင်းသော နေရာဖြစ်သည်- agent က တည်းဖြတ်မီ ချဉ်းကပ်နည်းကို ဆွေးနွေးသည်။ story ပြင်ဆင်ပြီးသောအခါ Build သို့ ပြောင်းပြီး ကူးထည့်ပါ၊ message တစ်ခုလျှင် story တစ်ခု။ တစ်ခုပြီးတိုင်း /test က preview တွင် စီးဆင်းမှုကို click လုပ်ပြီး စစ်နိုင်သည်၊ မှားသွားလျှင် Revert to this point ဖြင့် reply တစ်ခုစီကို ပြန်လှည့်နိုင်သည်။ docs တွင် ထိရောက်သော prompt များ နှင့် AI app builder အတွက် prompt ရေးနည်း လမ်းညွှန်ကို ကြည့်ပါ။

User story စစ်ဆေးစာရင်း

• အသုံးပြုသူ အမျိုးအစား တိကျစွာ နာမည်ပေးထားသည်
• ဒီဇိုင်းမဟုတ်ဘဲ လိုအပ်ချက်ကို ဖော်ပြသည်
• အမှန်တကယ် "ဘာကြောင့်" အကြောင်းရင်း ပါသည်
• acceptance criteria သုံးခုမှ ခြောက်ခု စမ်းသပ်နိုင်သည်
• edge case သို့မဟုတ် error တစ်ခု အနည်းဆုံး ပါသည်
• scope ပြင်ပ အရာကို ဖော်ပြသည်
• တစ်ထိုင်တည်းတွင် တည်ဆောက်ပြီး စမ်းသပ်နိုင်လောက် သေးငယ်သည်
• တည်ဆောက်ပြီးနောက် criteria များကို တစ်ခုချင်း စစ်ပြီး

မေးခွန်းများ