Agile Development - Estimation

Agile ဆိုတာကို အရင်က လူတွေဘာလို့ ကြိုက်ကြလဲသေချာနားမလည်ခဲ့ဘူး။ ကျွန်တော်အရင်လုပ်တဲ့ ကုမ္မဏ္ဏီတွေမှာက Agile လို့ ခေါင်းစဥ်တပ်ထားတဲ့ "Waterfall with sprint" လုပ်ရတယ်။ Agile ဆိုတာ စာတွေ့သာဖတ်ခဲ့ရပြီး သေချာနားမလည်ခဲ့ဘူး။ ကျွန်တော် Udacity ကပေးတဲ့ Agile nanodegree ကို တက်တုန်းကလည်း အတွေးအခေါ်ပိုင်းကိုသာ နားလည်ခဲ့ပြီး အခုလုပ်နေတဲ့ ပရောဂျက်ကျမှ Agile ကိုစတင်ထိတွေ့ခွင့်ရခဲ့တယ်။ ကျွန်တော်အခုလုပ်နေတဲ့ ၆ လအတွင်းမှာမှ သေချာနားလည် သိရှိလာတဲ့ Agile အကြောင်းလေး ပြန်မျှဝေချင်လို့ဒီ blog post ကိုရေးဖြစ်တယ်။ ပြောချင်တာတွေများတော့ အပိုင်းလေးတွေခွဲပြီးရေးဖြစ်တယ်။

ကျွန်တော်တို့ project တစ်ခုမစခင် sprint တစ်ခုမစခင်မှာဆိုရင် estimation လို့ခေါ်တဲ့ ခန့်မှန်းမှုတစ်ခုကိုလုပ်ရတယ်။ ကိုယ်တွေလုပ်ရမဲ့ feature လေးတွေကို အမှတ်ကလေးတွေ ပေးရတာမျိုးပေါ့။ ကျွန်တော်အရင်က estimation လုပ်ရင် အချိန်ဘယ်လောက်ကြာမယ်၊ လုပ်အားဘယ်လောက်လိုတယ် အစရှိတဲ့ "absolute value" ဆိုတာကို တွက်ပေးရတယ်။ Absolute value ဆိုတာ တကယ်က တိကျဖို့တော်တော်ခက်တယ်။ ကျွန်တော်တို့လုပ်ရမဲ့ feature တိုင်းအတွက် ခန့်မှန်းမယ်ဆို မှန်ဖို့တော်တော်လေးကိုခက်တယ်။ Agile မှာက "absolute value" တွေကို မခန့်မှန်းကြဘူး။ အဲဒီအစား ကျွန်တော်တို့ estimate ဘယ်လိုလုပ်ကြလဲ? အရင်ဆုံး ဒီပုံလေးကိုမြင်ကြည့်ရအောင်

ဒီပုံမှာကြည့်မယ်ဆို အဆောက်အဦး A ရဲ့ အမြင့်ကို ခင်ဗျားကို ခန့်မှန်းခိုင်းမယ်ဆို ခင်ဗျား ဘယ်လောက်တိတိကျကျမှန်းနိုင်မယ်ထင်လဲ။ သေချာပါတယ်၊ တော်တော့်ကိုလွဲနေမှာ။ ကျွန်တော်က ခင်ဗျားကို B ရဲ့အမြင့်က ၃ မီတာရှိမယ်လို့ပြောလိုက်ရင်တော့ အနည်းဆုံးတော့ ခင်ဗျား ကြည့်လိုက်တာ နှစ်ဆလောက်တော့ကွာမှာပဲ၊ ဒီတော့ A က ၆ မီတာတော့ရှိရောပေါ့ဆိုပြီး မတိကျပေမဲ့နီးစပ်တဲ့ အဖြေတစ်ခုတော့ ရနိုင်တယ်။

ပြောချင်တာက ကျွန်တော်တို့တွေက ခန့်မှန်းတဲ့အခါမှာ "Relative Estimation" လို့ခေါ်တဲ့ နှိုင်းယှဥ်ပြီးခန့်မှန်းခြင်းကို လုပ်ရတာပိုအဆင်ပြေကြတယ်။ မသေချာမရေရာဖြစ်နေတဲ့ အခြေအနေမှာ  ကျွန်တော်တို့တွေက နှိုင်းယှဥ်စရာတစ်ခုကို ရှာပြီးပြောတာ ပိုလွယ်တယ်၊ ပိုတိကျတယ်။  နောက်တစ်ခုက နှိုင်းစရာများလာလေ ပိုတိကျလာလေလေပဲ။  ဒါကြောင့်မလို့ ဘာ code မှတောင်စမရေးခင် ဘာမှ နှိုင်းယှဉ်စရာမရှိတဲ့အချိန်မှာ ခန့်မှန်းတာမှန်သမျှသည်လွဲမှာပါပဲ။

ဟုတ်ပြီ ကျွန်တော်တို့က နှိုင်းယှဉ်မယ်ဆိုတော့ ဘာကိုနှိုင်းယှဥ်ရမလဲ? အချိန်နဲ့ လူအင်အားဆိုတာသည် တစ်ခြားအချက်တွေပေါ်မူတည်ပြီး ပြောင်းလဲနိုင်တယ် (ဥပမာ နေမကောင်းတာဖြစ်တာ လုပ်နေကျလူတွေထွက်သွားတာ အစရှိသဖြင့်)။ ဒီတော့ အဲဒါတွေအစား ကျွန်တော်တို့က "complexity" ခက်ခဲနက်နဲမှုကို ခန့်မှန်းကျတယ်။ ဒီအတွက်ကို ကျွန်တော်တို့ သုံးမဲ့ စံနှုန်းတွေသတ်မှတ်တယ်။

စံနှုန်းတွေကတော့ အများကြီးပဲ။ တစ်ချို့တွေကအင်္ကျီအရွယ်အစား စံနဲ့တိုင်းတယ်။ အရိုးရှင်းဆုံးလုပ်ရတဲ့အရာတွေက XS ဆို သူ့ထက် နည်းနည်းခက်ခဲရင် S, အရမ်းခက်ရင် L, XL, XXL အစရှိသဖြင့် ခန့်မှန်းယူလို့ရတယ်။ ကျွန်တော်တို့ကတော့အခု Scrum Poker နည်းသုံးတယ်။ 1,3,5,8,13 အစရှိသဖြင့် တက်သွားမယ်။ အလွယ်ဆုံးက 1 လို့ပေးပေါ့။ တစ်ခြား Bucket Sizing တွေဘာတွေရှိသေးတယ်။ ကိုယ်နဲ့ကိုက်တဲ့ စံနှုန်းကိုရွေးဖို့ပဲလိုတယ်။

ဒီတော့မေးစရာက ဒါဆို Project Manager တွေက ဒီ estimate တွေမသုံးရတော့ဘူးလားပေါ့။ အဲလိုလည်းမဟုတ်ဘူး။ ကျွန်တော်တို့က estimate တွေကိုသုံးပြီး ကိုယ့် အဖွဲ့ရဲ့  အလျင် (velocity) ကိုတွက်လို့ရတယ်။ ကျွန်တော်တို့ပထမ sprint ၃ ၄ ခုလောက်ထိ velocity ကငြိမ်မှာမဟုတ်ဘူး။ sprint များလာလေလေ၊ နှိုင်းယှဥ်စရာတွေ များလာလေလေ၊ ပိုပြီးတိကျလာလေလေဖြစ်တယ်။ sprint နဲ့ တိကျမှုက တိုက်ရိုက်အချိုးကျမယ်၊။ တိကျလာရင် ကျွန်တော်တို့ စပြီး velocity တွက်လို့ရပြီ။ ဥပမာ Sprint ၄ ခု လောက်အပြီးမှာ velocity ပျှမ်းမျ ၃၀ လောက် ရတယ်ပဲထား။ ဒါဆို နောက် sprint တွေမှာတော့ ဘယ် feature တွေထိ ပြီးလောက် တယ်ဆိုတာ ကြိုခန့်မှန်းကြည့်လို့ရပြီ။  ဘယ်လိုပဲကြိုခန့်မှန်းတယ်ပြောပြော  Estimation ဆိုတာတွေက "ခန့်မှုန်းချက်"သာ ဖြစ်တယ်ဆိုတာကို Team မှာပါတဲသူအကုန်လုံးက လက်ခံထားရမယ်၊ Team လို့ပြောတဲ့အခါမှာ ရေးမဲ့ developer တွေကော၊ PM တွေကော၊  Product Owner (Client) ကော အကုန်ပါဝင်တယ်။

အရှိန် ဆိုလို့ agile မှာ ပိုမြန်မြန်လုပ်ဖို့မလိုဘူး၊ အရှိန်ကိုထိမ်းထာနိုင်ရင်ရပြီ၊ လျော့သွားတယ်ဆို ဘာလွဲနေလဲ retro မှာပြန်ကြည့်ရမယ်၊ ဒီလိုပဲ အရင်ကထက်များသွားရင် လဲဘာလွဲနေလဲကြည့်ရမယ်။ ကျွန်တော်အရင်က ထင်တာ ကိုယ်ထင်တာထက်စောပြီးနေရင် ဒါချီးကျူးစရာလို့ထင်ခဲ့တယ်။ အရင်တစ်ခေါက်က sprint တစ်ခုအပြီးမှာ feature တွေစောပြီးနေလို့  ကျွန်တော့် manager က ဘာလို့စောပြီးနေလဲ မေးခွန်းထုတ်တာခံရဘူးတယ်။ estimation က တစ်အားကြီးလွဲနေလို့လား၊ feature card (story card) မှာ ရေးထာတဲ့ "Definition of Done" က လွဲနေတာလားဆိုပြီး အဖြေရှာဘူးတယ်။ ဒီတော့ ပိုမြန်နေရင်လည်း တစ်ခုခုမှားနေပြီဆိုတာ သိရမယ်။

နောက်ဆုံးအနေနဲ့ မှားတတ်တာတွေက

• Team တွေကိုမနှိုင်းရဘူး။ "Team A က sprint တစ်ခု အမှတ် ၂၀ ပြီးတယ်၊ မင်းတို့က ၁၀ ပဲပြီးတယ်" ဆိုတာကမှားတယ်။ Estimation Point တွေဆိုတာ relative ဖြစ်လို့ Team တွေက ပေးတဲ့ relativity တူမှာမဟုတ်ဘူး။
• "ငါတို့ velocity အရှိန်ကတော့ sprint တစ်ခု ၂၀။ ဒီတော့ ဒီ sprint မှာ ၂၅ မှတ်လောက်ရအောင်လုပ်မယ်"  ဆိုတာမျိုးမလုပ်ရဘူး။ Sprint တစ်ခုရဲ့ Goal က ဘယ်တော့မှ ဘယ်လောက် အမှတ် ပြီးအောင်လုပ်မယ်ဆိုတာမဖြစ်ရဘူး။
• လူတွေကို ဘယ်လောက်လုပ်ဆိုပြီး တာဝန်ခွဲတာမျိုးမလုပ်ရဘူး။ ဥပမာ ဒီလူကတော့  ၅ မှတ်ပြီးအောင်လုပ်၊ ဟိုတစ်ယောက်ကို ၁၀ ပြီးရမယ် ဆိုတာတွေမလုပ်ရဘူး။ "Story Point" တွေက ဒါကို တကယ်ရေးမဲ့လူကပေးတာမဟုတ်ဘူး။ Team တစ်ခုလုံးက ပေးတာဖြစ်လို့ တစ်ယောက်တွက် ၁၀ မှတ် complexity က နောက်တစ်ယောက်အတွက် ၅ မှတ်  ဖြစ်နိုင်တာမျိုးလည်း ဖြစ်နိုင်တယ်။

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