SarPhat Author
အတိုချုံးပြောရရင် Software Development လုပ်တဲ့အခါမှာ Website/Web App ပဲလုပ်လုပ် Android, iOS, API ဘာပဲလုပ်လုပ် ပုံမှန်ဆိုရင် Developer က Customer ကတောင်းဆိုလာတဲ့အချက်တွေပေါ် မူတည်ပြီး ရေးတာဖြစ်တယ်... အဲ့တော့ Software ပြီးသွားခါမှ သွားပြ.. မကြိုက်ရင် ပြန်ပြင်... အချိန်တွေ ကုန်လာကော... Agile မှာကျတော့ လူတွေကို Role တွေ ခွဲလိုက်တယ်... DSDM, Scrum, Kanban စတဲ့ Framework တွေရှိတယ်... Customer နဲ့စကားပြောတယ်... သူတို့လိုချင်တဲ့ Software ကို Customer နဲ့ ဆွေးနွေးရင်း ပုံဖော်တယ်... Data တွေ ကောက်ယူထားတယ်... ပြီးတော့ Software ကိုအစိတ်အပိုင်းတွေ အများကြီးခွဲပြီး ဒီအဆင့်ပြီးရင်တော့ ဒါပြမယ်... ဒီမှာတော့ ဒါပြီးမယ်ဆိုပြီး Customer နဲ့ သဘောတူညီမှုယူတယ်... တချို့ Product တွေကျတော့ ပြိုင်ဘက် Software တွေ Company တွေရဲ့အချက်အလက်တွေ သူတို့အားသာချက် အားနည်းချက်တွေကိုပါ Data ကောက်ယူပြီး Customer ကို ဒါထည့်လိုက်ရင် ပိုကောင်းသွားမယ်ဆိုပြီးအကြံပေးရတယ်... DSDM မှာတော့ Business Analyst, Business Sponsor, Technical Advisor စတာမျိုးတွေ ခွဲတယ်... Scrum မှာတော့ Product Owner/Manager, Project Sponsor ဒါမျိုးတွေ ခွဲတယ်.. အဓိကကတော့ Project ကိုအဆင့်လိုက် Release လုပ်ပြီး မြင်သာတဲ့ Output တစ်ခုထုတ်ဖို့ပဲ... Fail Fast, Fail Often လုပ်ချင်တာ... အကြာကြီးရေးပြီး Customer လိုချင်တာနဲ့မကိုက်ရင် ပြန်ရေးရတော့ အချိန်ပိုကြာလို့ အပိုင်းလိုက် ခွဲပြတယ်... မလိုချင်ရင် ချက်ခြင်း ပြန်ပြင်ပေါ့...
ဥပမာ Software တစ်ခုကို ၃ လ အချိန်ယူမယ်ဆိုပြီး စလိုက်တယ်...Scrum နဲ့ Run မယ်ဆိုရင် Product Owner က စပြီး Story တွေ ရေးရတယ်... Story ဆိုတာ တည်ဆောက်နေတဲ့ Product မှာ ပါတဲ့ Features တွေပဲ… အဲ့ Story တွေကို Product Owner တွေက Business Requirement ပေါ်မူတည်ပြီး အသေးစိတ် လိုက်ရေးပေးရတယ်.. ဥပမာ Login ဝင်တဲ့ စနစ်ဆိုရင် Customer က Website ကိုလာတယ်.. Login Button ကိုမြင်ရမယ်.. အဲ့ Login Button ကို နှိပ်လိုက်ရင် နောက်ထပ် Page တစ်ခုကို ရောက်သွားမယ်… အဲ့မှာ Username, Password ရိုက်ထည့်လို့ ရမယ်… ရိုက်ထည့်ပြီး Login ဆိုတဲ့ Button လေးကို နှိပ်လိုက်ရင် Customer ကို နောက်ထပ် Page တစ်ခုကို Redirect လုပ်ပေးသွားမယ်… လုပ်သွားတဲ့ Page မှာ Customer Login ဝင်သွားကြောင်း သိသာအောင် ပြရမယ်… Logout Button မြင်ရတယ်.. စသည်ဖြင့်ပေါ့လေ.. အသေးစိတ် တည်ဆောက်ပြီး ရေးပေးရတယ်…
အဲ့လို ရေးထားတဲ့ Story တွေ အများကြီး စုထားတာကို Backlog လို့ခေါ်တယ်.. အဲ့ Backlog ကို အလုပ်စလုပ်ဖို့အချိန် တစ်ခု သတ်မှတ်ရတယ်.. ၂ ပတ်ဖြင့် ၂ပတ်.. ၁ လဖြင့် ၁လပေါ့.. DSDM မှာတော့ Timebox လို့ခေါ်တယ်… Scrum ဘက်မှာတော့ Sprint လို့ခေါ်တယ်… အဲ့ Sprint တစ်ခုက အနည်းဆုံး ၂ ပတ်နဲ့ အများဆုံး ၃ ပတ်ကြာတယ်.. Company ပေါ်မူတည်တယ်.. ၃ လကြာမဲ့ Software တစ်ခုကို Development လုပ်မယ်ဆိုရင် ၂ ပတ် Run မဲ့ Sprint 6 ခုစာ အချိန်ယူမယ်ပေါ့.. အဲ့လို Story တွေကို ဘယ်ဟာကိုတော့ အရင်ဆုံးစပြီးလုပ်မလဲဆိုတာကို Product Owner, Developer, Tech Lead အားလုံး စုပြီး Meeting လုပ်ရတယ်.. Sprint Planning လို့ခေါ်တယ်.. အဲ့ Sprint Planning Meeting မှာ Story တစ်ခုချင်းစီကို Review လုပ်တယ်.. ဘာတွေ အရင်စပြီး လုပ်သင့်တယ်ဆိုတာပေါ်မူတည်ပြီး Story တွေကို အခုလုပ်မဲ့ Sprint မှာ ထည့်မယ်ဆိုပြီး Prioritize လုပ်ရတယ်… Prioritize List မှာပါတဲ့ ရွေးချယ်ထားတဲ့ Story တွေကို Review လုပ်တယ်… တကယ်လို့ Story တစ်ခုက အရမ်းကြီးနေတယ်လို့ Developer တွေက ခံစားရရင် Task တွေအဖြစ် ခွဲထုတ်ပေးရတယ်… သေးသေးလေးတွေ ခွဲပစ်တာပေါ့.. အဲ့မှာ Scrum Poker ဘာညာဆော့ပြီး ခွဲကြတာမျိုးလဲရှိတယ်.. ပျော်ဖို့ကောင်းပါတယ်… အဲ့မှာကျတော့ Scrum Master ပါလာပြီ.. သူက ဒါတွေအားလုံးကို စီစဉ်ပေးရတယ်… ဘယ်တော့ Sprint Planning လုပ်မယ်… ဘယ်အချိန်ပြီးမယ်… Story တွေကို ဦးဆောင်ပြီး Review လုပ်မယ် စသည်ဖြင့်ပေါ့
Scrum Software တွေကတော့ အစုံသုံးကြတယ်.. အတော်များများကတော့ Jira ပေါ့.. တချို့ကျတော့ Asana သုံးတယ်.. Story တွေကို Task တွေအဖြစ် Breakdown လုပ်အပြီးမှာ ၂ပတ်ကြာတဲ့ Sprint ကို စတယ်… Scrum Master က နေ့တိုင်း မနက်ပိုင်းမှာ Meeting တစ်ခုကို စီစဉ်ပေးရတယ်.. အဲ့ Meeting မှာ Developer တွေ Product Owner တွေက Sprint Backlog ထဲက ဘယ် Task တွေ စလုပ်ပါမယ်ဆိုတာ ပြောတယ်.. Scrum မှာ စကားကြီး ၃ ခွန်းရှိတယ်.. မနေ့က ဘာလုပ်ပါတယ်.. ဒီနေ့ ဘာလုပ်မှာပါ… လောလောဆယ် ဘာပြသနာ(Blocker) ရှိနေပါတယ်/Blocker မရှိပါဘူး.. စသည်ဖြင့် Team ကို သိအောင် အလှည့်ကျ ပြောပြရတယ်… အဲ့ဒါပြီးရင်တော့ ကိုယ်လုပ်ရမဲ့ Task ကို ဆက်လုပ်ပေါ့လေ..
ScrumMaster ရဲ့အလုပ်က Sprint မှာ ထည့်ထားတဲ့ Story/Task တွေက တကယ်တန်းကော Developer တွေ နိုင်ရဲ့လား.. ၂ ပတ်အတွင်းမှာ ပြီးနိုင်ရဲ့လားဆိုတဲ့ Workload ကို ချိန်ရတယ်.. သူ့မှာတော့ ဘာလုပ်ပါ ဘာလုပ်ရမယ်ဆိုတဲ့ Power တော့မရှိဘူး.. သူက Facilitator သက်သက်ပဲ… အဲ့ဒါတွေကို Senior Dev or Team Lead နဲ့ ညှိနှိုင်းရတယ်… ၂ ပတ်အတွင်း ပြီးနိုင်လောက်တဲ့ ပမာဏကို ချိန်ပြီး Story တွေကို Backlog Prioritize လုပ်တယ်.. ပြီးတော့ ဒီ Sprint မှာတော့ ဘာပြီးပါမယ်ဆိုတာကို Scrum Team တစ်ခုလုံးနဲ့ တိုင်ပင်ပြီး Sprint Goal အနေနဲ့ သတ်မှတ်တယ်…
၂ ပတ်ကြာတဲ့အချိန်မှာ Sprint ပြီးလို့ Task တွေက မပြီးသေးရင် နောက် Sprint ကို သယ်သွားလို့ ရတယ်.. ဒါပေမဲ့ Workload ကို သေချာ ချိန်ထားတာ ဖြစ်လို့ ပြီးကို ပြီးတယ်.. Task တစ်ခုချင်းစီကို ဘယ် Task ကတော့ ဘယ်လောက်ကြာပါ့မယ်ဆိုတာကို Developer က ခန့်မှန်းအချိန်ပေးရတယ်… Record လုပ်ထားတာပေါ့လေ.. Agile Scrum ရဲ့ကောင်းကွက်က Sprint ပြီးတဲ့အချိန်မှာ လူတယောက် ဘာတွေလုပ်ခဲ့လဲဆိုတဲ့ performance ပါ ထွက်တဲ့အပြင် Software Project တစ်ခုလုံးရဲ့ ကုန်ကျစရိတ်ပါ တခါထဲ တွက်ချက်နိုင်တယ်.. Man Power, Time invested စတာတွေကို မူတည်ပြီး ဒီ Software ကတော့ ဘယ်လောက် တန်နေပြီဆိုပြီး တွက်နိုင်တယ်
Sprint တစ်ခု ပြီးတိုင်းမှာ Sprint Retrospective ဆိုတာ အမြဲတန်း Scrum Master က စီစဉ်ပေးရတယ်.. အဲ့မှာတော့ အရင် Sprint တုန်းက ဘာတွေလိုသွားတယ်.. ဘယ်သူကတော့ ဘာတွေ လုပ်ပေးခဲ့တယ်.. Appreciate လုပ်ကြတယ်.. နောက်ထပ် ဘာတွေ လုပ်မလဲ တိုင်ပင်ကြတယ်.. Sprint က ထွက်လာတဲ့ Output ကို Product Owner က Customer နဲ့ ပြန်ပြပြီးတော့ လိုအပ်ချက် လိုချင်တာတွေ ပြင်စရာရှိလာတာတွေကို စုပြီး Backlog ထဲမှာ Bug/Enhancement အနေနဲ့ Story ထပ်ထည့်တယ်… လိုအပ်သလို Prioritize List ထဲ ထည့်ပြီး Sprint ထဲမှာ Run ကြတယ်… Scrum နဲ့ Run တဲ့အချိန်မှာ MVP လို့ခေါ်တဲ့ Minimum Viable Product ဘယ်အချိန်ထွက်မလဲဆိုတာ မှန်းလို့ ရတဲ့အပြင် Customer က Progress မြင်ရတာ ဖြစ်တဲ့အတွက်ကြောင့် အခု လိုချင်တာကို နောက်လာမဲ့ Sprint ရဲ့ Prioritize list ထဲထည့်ပြီး ဆက်လုပ်သွားလို့ ရတယ်… Incremental Release ထွက်တာက Scrum ရဲ့ သဘာဝပဲ.. မြန်မြန်ထုတ် မြန်မြန်ပြင်ပေါ့…
အဲ့မှာ Burndown Chart တွေ ၊ Reporting တွေ ၊ အသေးစိတ် Agile Scrum ရဲ့ နည်းစနစ်တွေရှိပါသေးတယ်… Project Management ရဲ့ အစိတ်အပိုင်း တစ်ခုဖြစ်ပေမဲ့ Agile Methodology က Software Development မှာပဲ အသုံးချတာ များတယ်.. ပုံမှန် Water Fall Methodology ထက်စာရင် ပိုပြီး ထိရောက်တယ်.. Project Fail တာ နည်းပြီး Developer တွေလဲ Stress ကင်းကင်းနဲ့ အလုပ်လုပ်နိုင်ပြီး Product Owner တွေပါ ပါလာတဲ့အတွက် ပိုကောင်းတဲ့ Product တွေ ထွက်တယ်.. Customer လိုချင်တဲ့ Software လဲ ရတာမို့လို့ Customer လဲ ကျေနပ်တယ်…
ဒါပေမယ့်လို့ One Time Project တွေ ဆိုရင်တော့ Water Fall Methodology ပဲ သုံးကြတာ များပါတယ်…
Keep Reading