Skip to main content

Scrum ဆိုတာဘာလဲ (အပိုင်း-၁)



Agile ဆိုတာဘာလဲ ခေါင်းစဥ်နဲ့ ရှေ့မှာ Agile အကြောင်း ရေးခဲ့ပါတယ်။ Agile က အသုံးများတဲ့ Project Management နည်းစနစ်ဖြစ်လာတာနဲ့အမျှ Agile အတွက် အသုံးပြုတဲ့ Framework တွေကိုလည်း လေ့လာဖို့လိုအပ်လာပါတယ်။ ဒါကြောင့် ဒီတစ်ပတ်ဆောင်းပါးမှာ Agile နည်းအတွက် အသုံးအတွင်ကျယ်ဆုံးဖြစ်တဲ့ Scrum Framework နဲ့ပတ်သက်ပြီး ဝေမျှချင်ပါတယ်။ Agile နဲ့ Scrum လို့ပြောရင် နှစ်ပတ်တစ်ခါ Sprint Run တာလို့ပဲ များသောအားဖြင့် သိကြပါတယ်။ နှစ်ပတ်တစ်ခါ Sprint အပြင် ဘာတွေရှိသေးလဲ၊ ဘယ်လိုတွေ အလုပ်လုပ်လဲဆိုတာ လေ့လာကြည့်ရအောင်။

Scrum Framework မှာ ပါဝင်တဲ့ အကြောင်းအရာတွေကများလို့ အပိုင်း (၂) ပိုင်းခွဲရေးပါမယ်။
  1. Scrum ဆိုတာဘာလဲ၊ Sprint ဆိုတာဘာလဲ နဲ့ Scrum Meetings တွေအကြောင်းကို ရှင်းပြပါမယ်။
  2. Scrum မှာ ပါဝင်တဲ့ Team Member တွေနဲ့ အသုံးပြုတဲ့ Artifact တွေအကြောင်းကို ရေးသွားပါမယ်။
(ဒီဆောင်းပါးက Scrum.org ရဲ့ Scrum Guide™ ကို အခြေခံပြီး ရေးထားတာဖြစ်ပါတယ်။)



Scrum ဆိုတာဘာလဲ

Scrum ဆိုတာ Teamwork ကို ထိထိရောက်ရောက်အသုံးချပြီး လုပ်ငန်းလုပ်ဆောင်စေတဲ့ Framework ဖြစ်ပါတယ်။ Team Member တွေ အချင်းချင်း ပူးပေါင်းဆောင်ရွက်ပြီး ရှုပ်ထွေးခက်ခဲတဲ့ Project တွေကို အောင်အောင်မြင်မြင် Deliver လုပ်ဖို့ရာ Scrum ကို အသုံးပြုကြပါတယ်။ Agile ရဲ့ Framework ဖြစ်တဲ့ Scrum က Requirement အပြောင်းအလဲတွေကို ကောင်းကောင်းလက်ခံနိုင်ပါတယ်။ Scrum ကို နားလည်ရလွယ်ကူပြီး ပေ့ါပေ့ါပါးပါးရှိတဲ့ Project Management Framework ဖြစ်ပြီး၊ ကျွမ်းကျင်ဖို့တော့ ခက်ခဲတယ်လို့ ဆိုကြပါတယ်။

Scrum က Agile ရဲ့ Iterative (ထပ်တလဲလဲ) နဲ့ Incremental (ထပ်တိုး) နည်းလမ်းကို အသုံးပြုပြီး Product ကို Customer ဆီကို စဥ်ဆက်မပြတ် ထုတ်ပေးပါတယ်။ Scrum က Team တွေကို
  • အတွေ့အကြုံတွေကနေ သင်ယူဖို့
  • ကိုယ်တိုင် ပြဿနာတွေ ဖြေရှင်းဖို့နဲ့
  • အဲဒီအတွေ့အကြုံတွေကနေ ဆက်ပြီး Improve လုပ်သွားဖို့  တွန်းအားပေးပါတယ်။

Sprint ဆိုတာဘာလဲ

Sprint ဆိုတာ Iterative (ထပ်တလဲလဲ) Develop လုပ်၊ Deliver လုပ်ဖို့အတွက် အချိန်တစ်ခု သတ်မှတ်တာဖြစ်ပါတယ်။ ကိုယ့် Team ပေါ်မူတည်ပြီး ၁ပတ်ကနေ ၄ပတ်အတွင်း စိတ်ကြိုက်သတ်မှတ်နိုင်တယ်၊ များသောအားဖြင့် ၂ပတ် လို့ သတ်မှတ်ကြပါတယ်။ အဲဒီ သတ်မှတ်တဲ့ အချိန် ၂ ပတ် အတွင်းမှာ Development Team က Product Backlog ထဲက Priority စီထားတဲ့ Task တွေကို ၂ပတ်စာ ပြီးမြောက်မယ့် ပမာဏ ရွေးယူပြီး Develop လုပ်ပါတယ်။ ၂ပတ် ပြည့်ရင်တော့ Sprint ပြီးပြီဖြစ်လို့ ပြီးသွားတဲ့ Task တွေကို Review လုပ်ပြီး Customer ဆီ Deliver လုပ်လို့ရတာတွေကို Deliver လုပ်ပါတယ်။ ၂ပတ် ပြည့်ရင် စက်ဝိုင်းတစ်ပတ် ပြန်လည်သလို Sprint အသစ် ပြန်စပါတယ်။ Sprint တစ်ခုထဲမှာ လုပ်ရတဲ့ Meetings (သို့) Events လေးခု ရှိပါတယ်။

Scrum Events 4 ခု

1. Sprint Planning
Sprint အစမှာ Product Backlog ထဲ Priority မြင့်တဲ့ Task တွေကို Development Team က ရွေးယူ၊ Sprint Backlog ထဲထည့်ပြီး Develop လုပ်ဖို့ အသေးစိတ်ဆွေးနွေးတဲ့ Meeting ပါ။ Scrum Team တစ်ခုလုံး Meeting တက်ပြီး
  • ဒီ Sprint မှာ ဘာတွေလုပ်မှာလဲ (What) နဲ့
  • ဘယ်လို Develop လုပ်မှာလဲ (How) ကို ဆွေးနွေးတာဖြစ်ပါတယ်။
2. Daily Standup
နေ့စဥ် Development Progress ကိုသိဖို့ ၁၅ မိနစ်လုပ်တဲ့ Meeting ဖြစ်ပါတယ်။ Development Team က တစ်ယောက်ချင်း Progress ကို ပြောပြပြီး အဓိက အချက် ၃ ချက်ဖြစ်တဲ့
  • မနေ့က ဘာတွေလုပ်လဲ
  • ဒီနေ့ ဘာတွေလုပ်မလဲ
  • Block ဖြစ်နေတာ ဘာရှိလဲ စတာတွေကို လိုတိုရှင်း ဆွေးနွေးတာဖြစ်ပါတယ်။
3. Sprint Review
Sprint အဆုံးမှာ ၂ပတ် အတွင်း ပြီးသွားတဲ့ Task (“Done” Work) တွေကို Development Team က Demo ပြပြီး၊ Product Owner နဲ့ Stakeholder တွေက Review လုပ်ပါတယ်။ လိုတာတွေကို Product Backlog ထဲ ထပ်ထည့်တာမျိုးတွေရှိပြီး ဘာတွေက Customer ဆီ Deliver လုပ်လို့ရမလဲဆိုတာ ဆွေးနွေးပါတယ်။

4. Sprint Retrospective
Sprint Retrospective ကတော့ Sprint အဆုံးမှာ ဒီ Sprint အတွင်း အဆင်ပြေခဲ့တာ၊ အဆင်မပြေခဲ့တာ နဲ့ နောက် Sprint တွေမှာ တိုးတက်အောင် ဘာတွေလုပ်လို့ရမလဲ ဆွေးနွေးတဲ့ Meeting ဖြစ်ပါတယ်။ Team အတွက် ရခဲ့တဲ့ အတွေ့အကြုံတွေကနေ ဆက် Improve လုပ်သွားဖို့အတွက်ပါ။

Backlog Refinement
Backlog Refinement က Product Backlog ဆောင်းပါးမှာ အသေးစိတ်ရေးခဲ့တဲ့ Backlog Grooming Meeting ကို ပြောတာဖြစ်ပါတယ်။ Backlog ကို ပြန်ရှင်းလင်းတာဖြစ်ပြီး မဖြစ်မနေ Sprint တိုင်းမှာ ထည့်လုပ်ရတဲ့ Meeting တော့မဟုတ်ပါဘူး။ သို့သော် နှစ်ပတ်တစ်ခါလုပ်မလား၊ တစ်လတစ်ခါလုပ်မလား စသဖြင့် သတ်မှတ်ပြီး ပုံမှန်လုပ်သင့်ပါတယ်။

ဒီပုံထဲကအတိုင်း Scrum Meeting တွေကို Scrum Team ကလူတွေက ပူးပေါင်း လုပ်ဆောင်သွားတာဖြစ်ပါတယ်။ “Scrum ဆိုတာဘာလဲ (အပိုင်း-၂)” မှာ Scrum Team Roles တွေနဲ့ Scrum Component တွေဖြစ်တဲ့ Product Backlog, Sprint Backlog စတာတွေကို ထပ်ရေးသွားပါမယ်။ စုပြုံနေမှာစိုးလို့ Agile Mindset အတိုင်း “One bite at a time” ပါ။

တစ်ခုသတိထားရမှာက ဒီဆောင်းပါးမှာ Scrum Framework သုံးရင် အခြေခံပါရတဲ့ Meetingတွေကို ဖော်ပြခဲ့တာဖြစ်လို့ Agile မှာ သုံးကြတဲ့ Meeting တွေ အကုန်လုံးတော့ မပါဝင်ပါဘူး။ ဥပမာ Roadmap အတွက် လိုတဲ့ Meeting တွေ စသဖြင့်ပါ။ Scrum ရဲ့ အဆိုအရလည်း ဒီ Meeting တွေအပြင် Team က လိုတဲ့အခြား Meeting တွေကိုလည်း လိုအပ်သလို ဖြည့်စွက်လုပ်ဆောင်နိုင်ပါတယ်။

နောက်ထပ် ဖတ်ချင်တဲ့ Topic တွေရှိရင်လည်း ဒီ Google Form ကနေတဆင့် အကြံပေးနိုင်ပါတယ်။ ProductBaze မှ Product သမားအချင်းချင်း idea တွေ၊ knowledge နဲ့ experience တွေ share ဖို့ နွေးနွေးထွေးထွေးဖိတ်ခေါ်ပါတယ်။ ProductBaze အကြောင်း (၁) မိနစ်စာ မိတ်ဆက် post လေးကို ဒီ link မှာ ဖတ်လို့ရပါတယ်။ ProductBaze ကို ဆက်သွယ်ချင်ရင် productbaze@gmail.com သို့ ပေးပို့ ဆက်သွယ်နိုင်ပါတယ်။

Follow us on Facebook and Linkedin for latest updates.

Comments

Popular Posts

SMART Goal ဘယ်လိုတည်ဆောက်မလဲ

Personal အတွက်ဖြစ်စေ၊ လုပ်ငန်းခွင်မှာဖြစ်စေ.. ရည်မှန်းချက်ကြီးမားတာ ကောင်းပေမယ့် ကိုယ်စိတ်ကူး ပေါ်ရာ ကိုယ်ဖြစ်ချင်ရာ ရည်မှန်းချက်တွေ ရမ်းသမ်းချမှတ်တာက လက်တွေ့မကျတဲ့၊ ချသာ ချမှတ်ထားပြီး အသုံးမဝင် Effective မဖြစ်တဲ့ ရည်မှန်းချက်တွေ ဖြစ်နေနိုင်ပါတယ်။ မဖြစ်နိုင်တဲ့ Goal နောက်ကိုလိုက်ရင်း ရင်းနှီးမြှုပ်နှံရတဲ့ အချိန်တွေ၊ ငွေကြေးတွေ၊ Resource တွေလည်း ဆုံးရှုံးမှုတွေဖြစ်စေနိုင်ပါတယ်။ “SMART Goal ဖြစ်ဖို့တော့ လိုမယ်နော်” ဆိုတဲ့ စကားမျိုး ကြားဖူးကြပါလိမ့်မယ်။ SMART Goal ဆိုတဲ့ concept ကို စီးပွားရေးလောက၊ Marketing အပြင် နယ်ပယ်အသီးသီးမှာ တွင်တွင်ကျယ်ကျယ်အသုံးပြုကြပါတယ်။ SMART Goal ဆိုတာ တိုတိုပြောရရင် တိကျရှင်းလင်းပြီး လက်တွေ့ကျတဲ့ Goal တွေချမှတ်ခြင်းလို့ ပြောနိုင်ပါတယ်။ မိမိ Business အတွက်၊ Product အတွက်၊ Team အတွက်၊ Personal အတွက် Goal တွေ ချမှတ်တဲ့အခါ လက်တွေ့ဖြစ်နိုင်ချေရှိတဲ့ ရည်မှန်းချက်ကို သေချာသတ်မှတ်ပေးနိုင်တဲ့ SMART Objective နည်းလမ်းကို သုံးကြည့်သင့်ပါတယ်။ SMART Goal ဆိုတာက ကိုယ့်ချမှတ်ရေးဆွဲမယ့် Goal တွေက S (Specific) - ဘာကိုရရှိအောင်လုပ်မယ်ဆိုတာ တိတိကျကျဖြစ်ရမယ် M (

Cross-Functional Team အကြောင်း တစေ့တစောင်း

Cross-functional Team ဆိုတာ အပြောလည်းများသလို အသုံးလည်းများပါတယ်။ Product Team တွေမှာလည်း Cross-functional Team ပုံစံကို တော်တော်များများ အသုံးပြုကြပါတယ်။ ProductBaze ဆောင်းပါးအချို့မှာလည်း ထည့်ရေးဖူးပြီး၊ Product Squad ဆောင်းပါးမှာ Squad တည်ဆောက်ပုံက Cross-functional Team ပုံစံကို အခြေခံတဲ့အကြောင်းရေးရင်းနဲ့ Cross-functional Team အကြောင်းလေးကိုပါ မိတ်ဆက်ပေးဖို့ ဖြစ်လာပါတယ်။ ပုံမှန် Organization တွေမှာ Department တွေ, Team တွေက လုပ်ငန်းသဘောသဘာဝ တူညီရာ (Tech, Marketing, Sales, Operation…) စသဖြင့် အသီးသီး ဖွဲ့စည်းထားကြပြီး ဖွဲ့စည်းပုံကလည်း အထက်ကနေ အောက် Hierarchy အတိုင်းဖြစ်ကြပါတယ်။ Decision တစ်ခုလိုအပ်ရင်လည်း Hierarchy အတိုင်း အပေါ်ကို ပြန်တက်ပြီး Request လုပ်ကြရသလို၊​ Company တစ်ခုထဲက Team အသီးသီးက အခြား Department တွေ ဘာလုပ်နေလဲဆိုတာ သိဖို့ ထင်သလောက် မလွယ်ကူပါဘူး။ Silos Team (တသီးတသန့် အလုပ်လုပ်တဲ့ Team) တွေ ဖြစ်လာပြီး Direction တွေ ညှိရခက်တတ်ပါတယ်။ Cross-functional Team ဆိုတာက Organization ထဲမှာ ကျွမ်းကျင်မှုမတူ (သို့မဟုတ်) ဌာနမတူတဲ့ လူတွေကို Team အနေနဲ့ဖွဲ့ပေးပြီး Project တစ်

ကိုယ့် Boss ကို ဘယ်လို Manage လုပ်မလဲ

“Manage My Boss” ဆိုတဲ့ ခေါင်းစဉ်ကြီးဖတ်လိုက်ရလို့ တမျိုးကြီးဖြစ်သွားမယ်ထင်ပါတယ်။ သို့ပေမယ့် ကျွန်တော် အခုပြောပြမယ့် “How to Manage your Boss” က Management အကြောင်း လေ့လာတဲ့အခါတွေမှာလည်း ပါဝင်လေ့ရှိသလို အပြင်လုပ်ငန်းခွင်မှာလည်း တကယ်အရေးပါတဲ့ ကိစ္စရပ်ပါပဲ။ ကိုယ်ကိုယ်တိုင်က Middle Management Level လို့ပြောကြတဲ့ Manager ဖြစ်နေမယ်၊ ကိုယ့်အောက်မှာ Team Members တွေရှိသလို၊ ကိုယ့်အပေါ်မှာလည်း ကိုယ် Report လုပ်ရတဲ့ Senior Manager သော်လည်းကောင်း၊ Head သော်လည်းကောင်း၊ C-Level သော်လည်းကောင်း ကိုယ့် Boss ရှိမယ်ပေ့ါ။ Management Term အရဆိုရင် ကိုယ့် Team ကို Manage လုပ်ရတာကို “Managing Down” or “Downward Management” လို့ ခေါ်ပြီး၊ ကိုယ့် Boss ကို Manage လုပ်တာကို “Managing Up” or “Upward Management”လို့ခေါ်ပါတယ်။ အဲ့တော့ အခုဆွေးနွေးမှာက Upward Management အကြောင်းပါ။ အိုကေ… ကိုယ့် Boss ကို ဘယ်လို Manage လုပ်တာလဲ??? ကိုယ်က Manage လုပ်ခံရမှာမဟုတ်ဘူးလား??? ကိုယ့်အတွက်ရော ဘယ်လို အကျိုးရှိမှာလဲ??? “Boss ကို Manage လုပ်တယ်ဆိုတာ ဘာလဲ” ကနေ စရအောင်ပါ။ Boss ကို Manage လုပ်တဲ့ အဓိက Goal က Boss ကို အပြည

အသုံးများတဲ့ Product Testing တွေ

Webinar တစ်ခုမှာ Product Testing တွေအကြောင်းထည့်ပြောတော့ နောက်ဆုံးအမေးအဖြေအချိန်မှာ အမေးခံရဖူးတာလေး မှတ်မှတ်ရရရှိလို့ပါ။ “A/B Testing ဆိုတာ Alpha Testing, Beta Testing ကို ပြောတာလား” ဆိုတဲ့ မေးခွန်းပါ။ သိတဲ့သူအတွက်တော့ ဘာမှမဆိုင်တဲ့ Testing တွေမှန်း တန်းသိနိုင်ပေမယ့် တစ်ဖက်မှာလည်း မေးလည်းမေးချင်စရာ အခေါ်အဝေါ်က ခပ်ဆင်ဆင်တူနေတာကိုးလို့ တွေးမိပါတယ်။ ဒါကြောင့် ဒီဆောင်းပါးမှာ မကြာမကြာလည်း ပြောဖြစ်ကြပြီး၊ အသုံးလည်းများ၊ အသုံးလည်းဝင်တဲ့ Alpha Testing, Beta Testing နဲ့ A/B Testing တို့အကြောင်းကို တီးမိခေါက်မိအောင် ရေးချင်ပါတယ်။ Feature Development တွေပြီးတဲ့အခါ Product Owner နဲ့ Development Team တွေ User Acceptance Testing (UAT) ကို အတူတကွ ပြုလုပ်ကြပါတယ်။ QA က အဓိက Test တာဖြစ်နိုင်ပေမယ့် အားလုံးက ပူးပေါင်းလုပ်ဆောင်ကြရတာပါ။ Product (သို့) Feature က UAT လည်းပြီးပြီ၊ Release လုပ်တော့မယ်လို့ စ Plan တဲ့အခါ Alpha Testing နဲ့ Beta Testing အခန်းကဏ္ဍဆီ ရောက်ပါတယ်။ Alpha Testing Alpha Testing ဆိုတာ လွယ်လွယ်ပြောရရင် ကိုယ့်လူနဲ့ကိုယ် အရင်စမ်းသပ်တဲ့ Testing အမျိုးအစားပါ။ မိမိရဲ့ Software

၅ မိနစ်စာ Product Roadmap

Product တစ်ခုစလုပ်ရင် အလိုအပ်ဆုံးက Product Roadmap လို့ပြောလို့ရမယ်။ Product Roadmap က မိမိ လုပ်မယ့် Product အကြောင်း Overview ပြောပြပေးနိုင်သလို၊ မိမိ Product Goal တွေကို ဘယ်လိုရောက်အောင် လျှောက်မလဲဆိုတာကို ချပြပေးလို့ပါပဲ။ Product Roadmap မရှိရင် ကိုယ်ထင်ရာ လုပ်မိနေနိုင်ပြီး မိမိ Goals တွေကို လက်လှမ်းမမှီနိုင်ဖြစ်သွားလိမ့်မယ်။ Product Roadmap ရှိတော့ ကိုယ့် Team Member တွေဖြစ်ဖြစ်၊ CEO ဒါမှမဟုတ် Investor တွေနဲ့ပဲပြောပြော အသုံးဝင်ပါလိမ့်မယ်။ ဒါဆို Product Roadmap ဘယ်လိုဆွဲရမလဲလို့မေးမယ် ။ အလုပ်အဖြစ်ဆုံး Product Roadmap Template ဆိုပြီးတော့မရှိပါဘူး။ မိမိ Roadmap ကို ကြည့်မယ့်လူပေါ်မူတည်ပြီး Roadmap ဒီဇိုင်းတွေကပြောင်းလဲရပါမယ်။ ဥပမာ… CEO က Timeline တွေနဲ့ ဘယ်နေ့ဘာ Feature ပြီးမှာလဲကို ကြည့်ချင်နေတဲ့အချိန် ကိုယ်က Feature List ပဲ သွားပြလို့မရပါဘူး။ Template မရှိပေမယ့် ဒီနေရာမှာ Share ပေးချင်တာက ကျွန်တော့် အတွက် အလုပ်ဖြစ်ခဲ့တဲ့ Roadmap Key Components တွေနဲ့ တခြား popular ဖြစ်တဲ့ Product Roadmap တွေကို ဝေမျှပေးသွားပါမယ်။ Product Roadmap မှာ အတွေ့အများဆုံးက Quarterly Roadmap (Q1,