Spikes: Making Unknowns Known

Software Engineering အဖွဲ့တစ်ခုက​ ရှိသမျှ နည်းပညာ Technology တွေအကုန်လုံးကို မသိန်ိုင်ဘူး။​ (သိဖို့လည်းမလိုအပ်ပါဘူး။)​ မသိတာက ကိစ္စမဟုတ်ပေမဲ့ ကျွန်တော်တို့ မသိသေးတဲ့ အရာတွေကို စလုပ်ရတော့မယ်ဆိုတဲ့အချိန်မှာ ဒီအရာက ဘယ်လောက်ခက်မလဲ၊ ဘယ်လောက်ကြာမလဲ အစရှိတဲ့မေးခွန်းတွေကို ဖြေဖို့က အင်မတန်ခက်တယ်။ ဒီထက်ပိုပြဿနာရှိတာက သေချာမသိပဲလုပ်မယ်ဆိုရင် တစ်ဝက်လောက်ရောက်မှ ဆက်လုပ်ဖို့ အဆင်မပြေတာသော်လည်းကောင်း၊ သွားချင်တဲ့လမ်းကြောင်း မမှန်တာသော်လည်းကောင်းဆိုရင် လုပ်ထားသမျှ သဲထဲရေသွန်ဖြစ်မယ်။ ဒီတော့မသိသေးတဲ့အကြောင်းအရာ တစ်ခုကို နည်းနည်းပါးပါးလောက် နားလည်ဖို့လိုအပ်လာတဲ့အခါမှာ Agile လုပ်ထုံးတစ်ခုဖြစ်တဲ့ Spike တွေကို အသုံးချကြတယ်။

Spike ဆိုတာဘာလဲ?

Spike ဆိုတာ အချိန်တစ်ခုသတ်မှတ်ထားပြီး အဲ့အချိန်အတွင်းမှာ သိချင်တဲ့ အကြောင်းအရာတစ်ခုကို ရိပ်ဖမ်းသံဖမ်းလောက်နားလည်အောင်၊ Proof of Concept တစ်ခုလောက်ရအောင် စမ်းလုပ်ကြည့်တဲ့ လုပ်ထုံး လုပ်နည်း တစ်မျိုးဖြစ်တယ်။ သူ့ရဲ့ ရည်ရွယ်ချက်က အတွင်းကျကျသိအောင်လုပ်ဖို့မဟုတ်ပဲ ဘယ်လောက်လောက်တော့ ခက်ခဲမလဲဆိုတာကို အကြမ်းဖျင်းနားလည်အောင်လုပ်ပြီး ရှေ့ဆက်လုပ်မဲ့ လမ်းကြောင်းကို ရှာဖို့ပဲဖြစ်တယ်။ နည်းပညာသမားတွေအတွက်ကြတော့ Tech Spike လို့လည်းခေါ်ကြတယ်။ အဓိပ္ပာယ်ကတော့ တူတူပဲ။

ဥပမာ ကျွန်တော်က Amazon Web Service (AWS) လုပ်တတ်တဲ့သူဆိုပါတော့။ Project မှာ Google Cloud ကိုသုံးဖို့ဖြစ်လာပြီဆိုရင် စမလုပ်ခင်မှာ ကျွန်တော့်အနေနဲ့ AWS နဲ့ဘယ်နားတွေကွာသွားလဲ၊ Pricing Model တွေဘယ်လိုရှိလဲ အစရှိသဖြင့် သိဖို့လိုလာမယ်။ ဒီတော့ ကိုယ့် ရဲ့ Production မှာသုံးနေတဲ့ Service အစစ်နဲ့စမ်းကြည့်မဲ့အစား အရင်ဆုံး Demo Service သေးသေးလေးတစ်ခုကို host တာမျိုးနဲ့ စလို့ရတယ်။ ဒီလိုစမ်းသပ်တဲ့နည်းလမ်းကို Spike လုပ်ကြည့်တယ်လို့ခေါ်တယ်။

ဒီတော့ Spike တစ်ခုမစခင်မှာ အရင်ဆုံးလုပ်ရမှာက အကြောင်းအရာတစ်ခုနဲ့ ပတ်သက်ပြီး ဘာတွေသိချင်တာလဲဆိုတာကို အရင်သတ်မှတ်ရမယ်။​ ကိုယ်ဖြေရမဲ့ မေးခွန်းလေးတွေကို ချရေးထားပြီး​ဒါကတော့ Spike Goal ဖြစ်ပါတယ်ဆိုပြီး သတ်မှတ်ထားရမယ်။ နောက်တစ်ဆင့်အနေနဲ့ ဒီမေးခွန်းတွေကို ဖြေနိုင်ဖို့ ဘယ်လောက်လောက်အချိန်ပေးရမလဲသတ်မှတ်ရမယ်။ ကိုယ်သိပြီးသားအရာတစ်ခုနဲ့ ဆက်စပ်တဲ့ အကြောင်းအရာဆိုရင်တော့ များသောအားဖြင့် ၁ ရက်၊ ၂ရက်လောက် အချိန်ပေးရင်ရတယ်။​ ဒါပမဲ့ အပေါ်မှာပြောတဲ့ ဥပမာလို မသိသေးတဲ့ Service/Framework တစ်ခုလုံးကို စမ်းသုံးကြည့်ရမယ်ဆိုရင်တော့ ဒီထပ် အချိန်ပိုလိုမယ်။ ဒီလိုအချိန်သတ်မှတ်တာကို "Timebox" လုပ်တယ်လို့ခေါ်တယ်။ Spike လုပ်တော့မယ်ဆို Timebox တစ်ခုရှိနေဖို့က အရေးကြီးတယ်။ တစ်ခါတစ်ရံမှာကျွန်တော်တို့တွေက အကြောင်းအရာတစ်ခုကို ဖတ်ရင်းနဲ့ စိတ်ပါသွားပြီး ကိုယ်ပထမက လေ့လာမယ်ဆိုပြီး သတ်မှတ်ထားတဲ့ အကြောင်းအရာကနေ ချောထွက်ပြီး စပ်ဆက်တဲ့ တစ်ခြားသောအကြောင်းအရာတွေထဲမှာ မျောသွားတတ်တယ်။ (Rabbit Hole လို့လည်းခေါ်ကြတာပေါ့) အချိန်တစ်ခုသေချာသတ်မှတ်ခြင်းအားဖြင့် အဲလိုအာရုံပျံ့လွင့်တာမျိုးမဖြစ်စေပဲ သိချင်တာကိုပဲ အာရုံပိုစိုက်စေတယ်။ Timebox ပြီးတဲ့အချိန်မှာ ရတဲ့ ရလဒ်ပေါ်မူတည်ပြီး အချိန်ထပ်လိုလား မလိုလား ဆုံးဖြတ်လို့ရတယ်။

နောက်တစ်ခုက Spike ဆိုသည်မှာ Production အဆင့်ထိသွားဖို့မလိုတာမလို့ အချိန်ကုန်သက်သာမဲ့ ဖြတ်လမ်းတွေသုံးလို့ရတယ်။ လိုချင်တဲ့ Data တွေကို Mock လုပ်တာမျိုး၊ ပုံမှန် Test Driven Development နဲ့ရေးတာဆို စမ်းတဲ့အချိန်မှာတော့ Unit Test ကို ခဏမေ့ထားတာမျိုး အစရှိသဖြင့် အလွယ်နည်းတွေ သုံးခွင့်ရှိရမယ်။ တစ်ခါတစ်လေမှာ ရှိပြီးသား Code မှာ စမ်းသပ်ရအရမ်းခက်နေရင် Fresh Codebase တစ်ခုဖန်းတီးပြီးတော့လည်း စမ်းလို့ရတယ်။

Spike Playback

ဒီလို လေ့လာလို့ပြီးပြီဆိုရင် ရလာတဲ့ ရလဒ်ကို ကိုယ့် Team ကို ပြန်ပြောပြရမယ်။​ ဒီလို ရလဒ်ပြန်ပြောပြတဲ့အလုပ်ကို "Playback" လုပ်တယ်လို့ခေါ်တယ်။ ကျွန်တော်ကတော့ မတင်ပြခင်မှာ လေ့လာနေရင်း အချက်အလက်တွေစုဆောင်းဖို့ Request for Comments (RFC), Architecture Decision Record (ADR) လိုမျိုး Document တစ်ခုကို အရင်ရေးလေ့ရှိတယ်။

RFC & ADR

RFC ကော ADR ကောကတော့ ဖြေရှင်းချင်တဲ့ ပြဿနာကဘာ၊ ဘယ်လိုဖြေရှင်းမလဲ၊ ဘာ Risk တွေရှိလဲ၊ ဘာလို့ နည်းလမ်းတွေအများကြီးထဲက ဘာလို့ဒါကိုရွေးလဲ အစရှိသဖြင့် အကြောင်းအရာကိုရေးတာပါပဲ။ ဘာကွာလဲဆိုတော့ RFC ကများသောအားဖြင့် ရေရှည်စီမံကိန်း (Long term plan) အကြီးကြီးတစ်ခုကို စလုပ်ဖို့ နှိုးဆော်ချင်တဲ့အချိန်မှာ သုံးတယ်။ ဥပမာ Test Driven Development စလုပ်ဖို့၊ Tooling တစ်ခုကိုဝယ်သုံး/ဖန်တီးဖို့ အစရှိသဖြင့်ပေါ့။ ရေးပြီးပြီဆိုရင် Organization တစ်ခုလုံးကိုဖတ်ခိုင်းပြီး မှတ်ချက်တွေပေးဖို့ အချိန်တစ်ခုသတ်မှတ်ထားပေးတယ်။ ဒီလိုလုပ်ခြင်းအားဖြင့် ကိုယ်က စစဥ်းစားထားတာကတော့ Use Case တစ်ခုအတွက်ပဲ၊​ တစ်ခြား Team တွေကို မေးကြည့်တော့မှ တစ်ခြားသော Use Case တွေအတွက်တော့ ဘယ်လိုအခက်အခဲတွေရှိနိုင်မလဲဆိုတာကို မြင်လာမယ်။ ဒါပေမဲ့တစ်ခုရှိတာက အားလုံးနဲ့ အဆင်ပြေဖို့ထက် အများစုအတွက် အဆင်ပြေမဲ့ နည်းလမ်းကို ရဖို့ကို ပိုဦးစားပေးတယ်။ RFC တစ်ခုက Draft အနေနဲ့စမယ်၊ ပြီးရင် Collecting Feedback အဆင့်မှာ မှတ်ချက်တွေတောင်းမယ်၊ မှတ်ချက်တွေပေါ်မူတည်ပြီး လိုတာရှိတာတွေပြင်မယ်၊ အများစုလက်ခံတဲ့ အခြေအနေရောက်သွားပြီဆိုရင်တော့ Accepted ဖြစ်သတ်မှတ်ပြီး လူတိုင်းလိုက်နာရမဲ့ စံနှုံးတစ်ခုဖြစ်လာမယ်။​ အတိုက်အခံများတယ်၊ မဖြစ်နိုင်ဘူးဆိုရင်တော့ Rejected ဖြစ်သတ်မှတ်ကမယ်။ နောက်ပိုင်း​ ဒီစံနှုံးတစ်ခုက မလိုအပ်တော့ဘူးရင်တော့ Abandoned ဖြစ်သတ်မှတ်ပြီး ပယ်ဖျက်နိုင်တယ်။

ADR ကတော့ ချက်ချင်းနီးပါး ဆက်လုပ်တော့မဲ့ အစီအစဥ်တွေအတွက်အသုံးချတယ်။ RFC လို Cross Team အများကြီးနဲ့သက်ရောက်နိုင်မဲ့ ရေရှည်စီမံကိန်းတွေအတွက်မဟုတ်ပဲ မကြာခင်အကောင်အထည်ဖော်တော့မဲ့ အရာတစ်ခုကို နောင်တစ်ချိန်ပြန်ကြည့်တဲ့အခါမှာ ဘာလို့ဒီလိုလုပ်ခဲ့သလဲဆိုတာကို မှတ်မိလွယ်နေအောင် ရေးတာဖြစ်တယ်။ သူကလည်း RFC လိုပဲ Feedback တော့တောင်းရတယ်၊ ဒါပေမဲ့ သူ့ Feedback ကတော့ တကယ့်ကို တိုက်ရိုက်သက်ဆိုင်တဲ့ လူတွေလောက်ပဲ ခေါ်ပြီး ဆွေးနွေးတာမျိုးဖြစ်တယ်။ RFC မှာတော့ လူအများအတွက်အဆင်ပြေတဲ့ နည်းကိုရွေးတာများပေမဲ့ ADR တစ်ခု ရှေ့ဆက်ဖို့အတွက်ကျတော့ သက်ဆိုင်သူတွေအကုန်လုံးရဲ့ သဘောတူညီချက်ကိုလိုအပ်တယ်။ နောက်တစ်ခုက ADR ကသက်ဆိုင်တဲ့ Feature အပိုင်းရှိတဲ့ ကုဒ်နဲ့တူတူ တွဲလျှက်သိမ်းလေ့ရှိပြီး RFC က တော့ အကုန်လုံးမြင်လွယ်တဲ့ စံနှုန်းအဖြစ် သိမ်းလေ့ရှိတယ်။ မြင်အောင်ပြောရင် Confluence မှာ RFC ထားပြီး ADR ကိုတော့ Git Codebase မှာတင် တစ်ခါတည်း ကုဒ်နဲ့တွဲသိမ်းလေ့ရှိတယ်။ သူမှာလည်း Draft, In Review, Accepted, Rejected, Abandoned အဆင့်တွေရှိပေမဲ့ သူရဲ့ သက်တမ်းကတော့ တစ်ဆင့်နဲ့တစ်ဆင့်ရောက်ဖို့ မြန်ဆန်တယ်။

ကိုယ့်ကုမ္ပဏ္ဏီမှာ ဒီလို မှတ်တမ်းရေးတဲ့ အကျင့်မရှိသေးရင်တော့ ADR နဲ့စစမ်းကြည့်လို့ရတယ်။ အများကြီးမလိုဘူး၊ Github သုံးတယ်ဆိုရင် Github Wiki လို မျိုးသုံးလို့ရတယ်။​ ဒီထက်လွယ်ချင်ရင် Markdown File လေးတွေသုံးပြီး ကုဒ်နဲ့တွဲလျှက် သိမ်းလို့ရတယ်။ Markdown ဆိုလို့ကြုံတုန်းပြောရရင် Software Engineer တစ်ယောက်အလုပ်က ကုဒ်ရေးတတ်ရုံနဲ့မရဘူး၊​ ဒီလို Technical writing လို့ခေါ်တဲ့ နည်းပညာအလုပ်နဲ့ ဆိုင်တဲ့ စာတွေ၊ မှတ်စုတွေ ရေးတတ်ဖို့လည်းလိုအပ်တယ်။ Markdown File လောက်တော့ ကြွမ်းကြွမ်းကျင်ကျင်ရေးတတ်ရမယ်။​

Diagramming

Playback မှာ တစ်ခု သတိထားရမှာက သက်ဆိုင်သူ (Stakeholder) ပေါ်မူတည်ပြီး သူတို့လိုချင်တဲ့ အချက်အလက်က တူချင်မှတူမယ်။​ ဥပမာ Product Owner တစ်ယောက်အနေနဲ့ လိုချင်တဲ့ အဖြေက လက်ရှိ Teamရဲ့ အရည်အချင်းနဲ့ တကယ်လုပ်ဖို့ ဖြစ်နိုင်လား၊ လုပ်မယ်ဆိုရင် ဘယ်လောက်ကြာမလဲ အစရှိသဖြင့် ဖြစ်ပြီးတော့ Tech Lead တစ်ယောက်အနေနဲ့ကျတော့ ဒီနည်းလမ်း က Scalable ဖြစ်လား၊ Maintainable ဖြစ်လား အစရှိသဖြင့် စိတ်ဝင်စားမယ်။ ဒီတော့ ကိုယ်က သက်ဆိုင်ရာလူတစ်ယောက်ချင်းစီအတွက် ချိန်ညှိပြီး သူတို့လိုချင်တဲ့၊ စိတ်ဝင်စားမဲ့ အကြောင်းအရာကို ကျစ်ကျစ်လစ်လစ် ပြန်ပြောပြတတ်ရမယ်။ ဒီမှာ ပြဿနာက Team ထဲမှာ အကုန်လုံးက နည်းပညာနဲ့ ကျွမ်းကျင်တဲ့သူဟုတ်ချင်မှဟုတ်မယ်။ ဒီတော့ ကိုယ်နားလည်ထားတဲ့ နည်းပညာသဘောတရား Concept တစ်ခုကို နည်းပညာနဲ့ မရင်းနှီးတဲ့သူတွေကို ရှင်းပြတဲ့အခါမှာ ပုံ (Diagram) နဲ့ပြတာက ထိရောက်တဲ့ နည်းလမ်းတစ်ခုဖြစ်တယ်။

ကိုယ်ကလှလှပပ မဆွဲတတ်ဘူးဆိုရင်တောင် ပုံကြမ်းလောက်တော့ဆွဲတတ်ရမယ်။ တကယ်လက်တွေ့မှာလည်း လန်ပြန်နေအောင် ဆွဲတတ်စရာမလိုဘူး၊ အခြေခံလောက်သိရင်ကို အဆင်ပြေတယ်။ လေ့လာချင်တဲ့သူအတွက် Unfolding the Napkin​ နဲ့ The Back of the Napkin ဆိုတဲ့ စာအုပ်လေးဖတ်ကြည့်ပြီး အဲ့ထဲက လေ့ကျင့်ခန်းလေးတွေလိုက်လုပ်ကြည့်ဖို့ အကြံပေးချင်တယ်။ Tooling အနေနဲ့ကတော့ Excalidraw သုံးကြည့်ဖို့အကြံပေးချင်တယ်။ သပ်သပ်ရပ်ရပ် လှလှပပဆိုရင်တော့ Miro၊​ ဒါမှမဟုတ် Figjam က သုံးလို့တော်တော်ကောင်းတယ်။ အင်တာဗျူးဖြေဖို့လုပ်နေတယ်ဆိုရင်တော့ Zoom Whiteboard ကို ကျင့်ထားတာက ပိုအသုံးဝင်မယ်။

တစ်ခြားနောက်ဆုံးပိတ် Tips & Tricks မှာချင်တာကတော့

• Spike ထဲမှာ စမ်းရေးထားတဲ့ Code demo တွေရှိတယ်ဆိုရင် အဲဒီ Code Sample တွေပါထည့်ရေးပေး၊ ပြပေးတာမျိုးလုပ်ပါ။
• Frontend သမားတွေဆို Screen recording လေးတွေနဲ့ ဘယ်လိုရနိုင်တယ်ဆိုတာ မြင်အောင်ပြပေးနိုင်ရင်ပိုပြီး မြင်လွယ်တယ်။
• Code demo တွေကိုလည်း Git Repo တွေ သိမ်းထားတာလည်း နောင်တစ်ချိန်ပြန်ကြည့်ချင်ရင် အလွယ်တကူ မှတ်မိလွယ်စေပါတယ်။

ဒီလို နည်းပညာအကြောင်းတွေကို သဘောကျတယ်ဆိုရင် တစ်လ Baht 1၀၀ နဲ့ အားပေးလို့ရနေပြီနော်။ Supporter တွေအနေနဲ့ Comment မှာလည်း သိချင်တာတွေရှိရင်မေးလို့ရပါတယ်။ ကျွန်တော်အကုန်လုံးကို ဖြေပေးသွားပါမယ်။