Skip to main content

Agile ဆိုတာဘာလဲ

Agile က Software Development တွေမှာ အဓိကသုံးတဲ့ နည်းစနစ်ဖြစ်ပြီး၊ Develop လုပ်နေတဲ့ ကာလတောက်လျှောက်မှာ Requirements အပြောင်းအလဲတွေကို ကောင်းကောင်းလက်ခံနိုင်တဲ့ နည်းစနစ်ဖြစ်တာကြောင့် အလွန်အသုံးများလာကြပါတယ်။ Project Management အတွက် Agile ကို တွင်တွင်ကျယ်ကျယ်သုံးလာတာနဲ့ အမျှ Project Manager, Product Manager, Scrum Master, Business Owner, Delivery Manager နဲ့ Software Engineers တွေပါ Agile အကြောင်းကို လေ့လာဖို့လိုအပ်လာပါတယ်။ ဒါကြောင့် ဒီဆောင်းပါးမှာ Agile နဲ့ပတ်သက်ပြီး မိတ်ဆက် ပြောပြသွားပါမယ်။



Agile ဆိုတာဘာလဲ

Agile ဆိုတာ Software Industry မှာ Product (သို့) Service တစ်ခုကို Customer ဆီကို အစောဆုံးနဲ့ စဥ်ဆက်မပြတ် ထုတ်ပေးနိုင်ဖို့ အသုံးပြုတဲ့ နည်းစနစ်ဖြစ်ပါတယ်။ Agile နည်းက မြန်ဆန်ပေ့ါပါးပြီး အပြောင်းအလဲတွေကို လိုက်လျောညီထွေ လက်ခံနိုင်တဲ့ နည်းစနစ်ဖြစ်တာကြောင့်၊ Market လိုအပ်ချက်၊ Customer လိုအပ်ချက်တွေနဲ့အညီ Product ကို အချိန်မီ ထုတ်ပေးနိုင်စေပါတယ်။ Product တစ်ခုလုံးကို အစ-အဆုံး ပြီးအောင် တည်ဆောက်ပြီးမှ Customer ကို ပေးသုံးတာမဟုတ်ပဲ… Customer ရဲ့ လိုအပ်ချက်ပေါ်မူတည်ပြီး Feature တွေကို ထပ်ခါထပ်ခါ (Iterative)...  ထပ်တိုး (Incremental) ထုတ်ပေးသွားနိုင်ဖို့ရာ Agile ကို အသုံးပြုကြပါတယ်။

Agile နည်းမှာ “One Bite at A Time” စကားရပ်အတိုင်း တစ်ကြိမ်မှာ ကိုယ့် Team က Develop လုပ်နိုင်မယ့် ပမာဏကို သတ်မှတ်၊ Develop လုပ်ပြီး၊ Customer ဆီကို ထုတ်ပေးပါတယ်။

အရင်က Software Development အတွက် အစဥ်အလာအတိုင်း Waterfall Model ကို လက်ခံသုံးစွဲခဲ့ကြပါတယ်။ အခုနောက်ပိုင်းတော့ ပေ့ါပါးမြန်ဆန်ပြီး ပြင်လွယ်ပြောင်းလွယ်ရှိတဲ့ Agile နည်း ကို ပိုမိုတွင်တွင်ကျယ်ကျယ် အသုံးပြုလာကြပါတယ်။
Agile နဲ့ နည်းလမ်းဟောင်း Waterfall Model ကွာခြားချက်တွေကို အကျဥ်းချုံး ဖော်ပြပါမယ်။

Agile vs Waterfall
Agile မှာ
  • Project (သို့) Product တစ်ခုလုံးစာ အစ-အဆုံး အသေသတ်မှတ်ထားတဲ့ Requirement တွေ Timeline တွေ မရှိပါဘူး။
  • စဥ်ဆက်မပြတ် Develop လုပ်ပြီး Customer ကို ထပ်တလဲလဲ ထုတ်ပေးတဲ့ (Iterative and Incremental) နည်းနဲ့ အလုပ်လုပ်ပါတယ်။
  • Customer Feedback တွေကို ပုံမှန်ရယူပြီး ရှေ့ဆက် Development တွေမှာ Improve လုပ်သွားနိုင်တယ်။
  • Develop လုပ်နေစဥ်မှာ Business အတွက် အပြောင်းအလဲတွေကို အချိန်မီ လိုက်လျောညီထွေ လက်ခံပြောင်းလဲနိုင်ပါတယ်။
Waterfall Model မှာ
  • ကြိုတင်သတ်မှတ်ထားတဲ့ Fixed Requirement နဲ့ Timeline အတိုင်းအလုပ်လုပ်တယ်။
  • တစ်ဆင့်ပြီးမြောက်မှ နောက်တစ်ဆင့်ကို လုပ်ဆောင်ပါတယ်။
  • Development လုံးဝ ပြီးသွားမှ Deliver လုပ်တာမို့၊ Project မတိုင်ခင်နဲ့ အပြီးမှာသာ Customer က ပါဝင်မှုရှိပါတယ်။ အစ-အဆုံး ပြီးမှ Customer Feedback ကိုရတာ ဖြစ်ပါတယ်။
  • Project ကို စလိုက်ပြီးတာနဲ့ လမ်းတဝက်မှာ Requirement အပြောင်းအလဲဖြစ်ရင် ပြင်လို့မလွယ်တာကြောင့် Timeline တစ်ခုလုံးကို အကျိုးသက်ရောက်မှုရှိပါတယ်။
  • အချိန်ယူ Develop လုပ်ပြီးမှ Market နဲ့ Customer တွေရဲ့ လိုအပ်ချက်နဲ့မကိုက်ရင် Business အတွက် ဆုံးရှုံးမှုများပါတယ်။


Agile ကို ဘာလို့ အသုံးများလာတာလဲ

ဒီနေ့ခေတ်မှာ ဘယ်စီးပွားရေးမဆို ပြုပြင်ပြောင်းလဲဖို့ ခက်ခဲလို့ မရတော့ပါဘူး၊ Market Trend နောက် မြန်မြန်ဆန်ဆန် မလိုက်နိုင်လို့မရတော့ပါဘူး၊ ပြောင်းလဲလာတဲ့ Customer Demend တွေကို အချိန်နဲ့တပြေးညီ ထည့်မစဥ်းစားလို့ မရတော့ပါဘူး။ အဲ့ဒီအချက်တွေအတွက် Agile က အကောင်းဆုံးနည်းလမ်းဖြစ်လို့ Agile ကို လက်ခံသုံးစွဲလာကြတာပါ။

Waterfall နဲ့ ခြားနာစွာပဲ Agile က လိုအပ်တဲ့ အပြောင်းအလဲတွေကို Business အတွက် ဆုံးရှုံးမှုမရှိအောင် အချိန်မီ လက်ခံပြောင်းလဲ Develop လုပ်ပေးနိုင်ပါတယ်။ ဒါ့အပြင် Agile Culture က Team ကို အာရုံစိုက်ပြီး၊ Product Team နဲ့ Customer တွေရဲ့ ဆက်သွယ်မှုကို အာရုံစိုက်ပါတယ်။ Customer အတွက် အသုံးတည့်တဲ့ Solution တွေ ထုတ်ပေးဖို့ကို Documentation တွေထိုင်ရေးဖို့ထပ် ပို အလေးထားပါတယ်။ ဒီအချက်တွေကပဲ Agile ကို ပိုမိုအသုံးများလာစေတာဖြစ်ပါတယ်။ နောက်ပိုင်းမှာ Software Industry တင်မကပဲ အခြား Industry တွေမှာလည်း Agile ကို လက်ခံအသုံးပြုလာကြပါတယ်။

Agile မှာ အသုံးများတဲ့ Framework များ
Agile က Agile နည်းဥပဒေနဲ့ ကိုက်ညီတဲ့ Framework တွေ၊ Methodologies တွေအတွက် ဘုံသတ်မှတ်ထားတဲ့ အခေါ်အဝေါ် (Umbrella Term) တစ်ခုလည်းဖြစ်ပါတယ်။ ဒါကြောင့် Agile အတွက် အသုံးပြုလို့ရတဲ့ Framework တွေ အမျိုးမျိုးရှိပြီး အသုံးများတာတွေက -
  • Scrum
  • XP (Extreme Programming)
  • Kanban
  • Lean
  • DSDM (Dynamic systems development method)
စတဲ့ Framework တွေဖြစ်ပါတယ်။

Scrum Framework ကတော့ အသုံးအတွင်ကျယ်ဆုံး Framework လို့ ပြောလို့ရပါတယ်။ မြန်မာနိုင်ငံမှာလည်း Agile ကို Scrum နဲ့ အသုံးပြုတဲ့ Organization တွေ များစွာတွေ့ရပါတယ်။ Scrum Framework အကြောင်းကို နောက်ထပ်ဆောင်းပါးမှာ အသေးစိတ် သီးသန့်ထပ်ရေးထားပါတယ်။

နောက်ဆုံးအနေနဲ့ ဖြည့်စွက်ပြောချင်တာက Agile ကို Scrum, Kanban စသဖြင့် ဘယ် Process Framework နဲ့ပဲ သုံးသုံး Agile Manifesto မှာပါတဲ့ နည်းဥပဒေတွေကို လိုက်နာလုပ်ဆောင်ဖို့ လိုအပ်ပါတယ်။ မဟုတ်ရင် Scrum သုံးနေရုံနဲ့လည်း Agile မဖြစ်ပါဘူး။ ကျွန်တော်ကိုယ်တိုင်လည်း Waterfall နဲ့ အသားကျနေတဲ့ Organization တွေမှာ… မပြည့်စုံတဲ့ ထော့ကျိုး Agile တွေ၊ ခြေတစ်ချောင်းထောက် Scrum တွေ Run ခဲ့တဲ့ အတွေ့အကြုံရှိဖူးတာမို့၊ Agile ရဲ့ ကောင်းကျိုးတွေ မိမိ Product မှာ များများရဖို့ တတ်နိုင်သလောက် Agile နည်းကျသင့်တာကို သတိထားဖို့ အကြံပြုပါရေစ။ Agile နည်းဥပဒေ ၁၂ ချက် ကိုတော့ Agile Manifesto Website မှာ မြန်မာလို လေ့လာနိုင်ပါတယ်။

နောက်ထပ် ဖတ်ချင်တဲ့ 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 (

ကိုယ့် 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 ကို အပြည

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 တစ်

အသုံးများတဲ့ 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,