Pair Programming

Pair programming ဆိုတာ နှစ်ယောက်တတွဲစီ ကုဒ်ရေးတာကိုပြောတာဖြစ်တယ်။ ​ တစ်ယောက်မသိတာကို တစ်ယောက်က ရှင်းပြပေးမယ်၊ တစ်ခြားကိုယ်မသိတဲ့ ရှုထောင့်တွေကိုလည်း ဖလှယ်ကြမယ်။ နှစ်ယောက်သား တိုင်ပင်ကြမယ်၊ နည်းလမ်းတွေစဥ်းစားကြမယ်၊​ ပြီးရင် ကုဒ်တူတူရေးကြမယ်ပေါ့။

Pair programming နည်းလမ်းတွေကတော့ အများကြီးရှိတယ်။ ကျွန်တော့် အလုပ်ထဲမှာတော့ Driver-Navigator နဲ့ Ping Pong ကိုပဲ လုပ်ဖြစ်တယ်။

Driver-Navigator

Driver-Navigator ဆိုတာ ကားမောင်းတဲ့အချိန် တစ်ယောက်က မောင်း၊ တစ်ယောက်က လမ်းညွှန်ပေးဖို့တာဝန်ယူသလိုပဲ Programming မှာကျ တစ်ယောက်က ကုဒ်ရေးတဲ့အလုပ်ကို တာဝန်ယူသလို တစ်ယောက်က ပန်းတိုင်ရောက်အောင် အကောင်းဆုံး ဘယ်လိုလုပ်ကြမလဲဆိုတာကို စဥ်းစားလမ်းညွှန်ပေးရတယ်။ အသေးစိတ်ပြောရမယ်ဆိုရင်

• Driver ရဲ့ တာဝန်က ကုဒ်ရေးဖို့ကို အဓိကတာဝန်ယူရတယ်။ သူအနေနဲ့  အခုမျက်စိရှေ့မှာ ရှိနေဲ့ ကုဒ်တစ်ပိုင်းလေးကိုပဲ​ အသေးစိတ်စဥ်းစားရေးရမယ်။ ရေးနေတုန်းမှာပဲ သူက ဘာဖြစ်လို့ ဒီလိုရေးတာ၊ ဘာကိုသုံးမယ်အစရှိသဖြင့် သူလုပ်နေတာကို တစ်ဖက်လူနားလည်အောင် ရှင်းပြနေရမယ်။
• Navigator ကကျတော့ သူက Full picture ကိုစဉ်းစားရမယ်။ ။ သူစဥ်းစားထားတဲ့ ရုပ်ပုံတစ်ခုလုံးကို နားလည်အောင် Driver ကို ရှင်းပြရမယ်။ Driver ကို ဘာပြီးရင်တော့ ဘာလုပ်ကြမယ်ဆိုတာကို ပြောပေးရမယ်။ တစ်ခုသိရမှာ အသေးစိတ် "Right click နှိပ်၊ ဒါလေးကို နှိပ်" အစရှိသဖြင့် micromanagement လုပ်တာမဟုတ်ပဲ system design, code design ပိုင်းကို အဓီကထားပြီး လမ်းညွှန်ပေးရမှာဖြစ်တယ်။

ပုံမှန် လုပ်ငန်းစဥ်ကတော့ အရင်ဆုံး card ကိုစကိုင်မယ်ဆိုရင် နှစ်ယောက်လုံး ဘာပြီး ဘာလုပ်မယ်ဆိုတာကို တိုင်ပင်ကြမယ်။ ပြီးရင် လုပ်မဲ့အလုပ်ကို task သေးသေးလေးတွေ ခွဲ၊ တစ်ခုပြီးသွားတိုင်း တစ်ခါ နေရာချင်းလဲတယ်။ အကြာကြီး တစ်နေရာထဲက လုပ်ရရင် ပျင်းသွားမယ်။ ကျွန်တော်တို့မှာတော့ တစ်ခါ commit ပြီးတိုင်း တစ်ခါ နေရာလဲတယ်။

ဒီနည်းက ဘယ်မှာကောင်းလဲဆိုရင်  တစ်ယောက်က high level အတွေးအမြင်ရှိတဲ့အချိန်မှာ နောက်တစ်ယောက်က အသေးစိတ်စဥ်းစားနေတယ်။ တစ်ယောက်တည်းရေးမယ်ဆို အသေးစိတ်စဥ်းစားနေရင် high level အတွေးတွေလွတ်သွားမယ်။ တကယ်လို့ အားလုံးကို ခြုံငုံတွေးနေတယ်ဆိုရင် အသေးစိတ်တွေလွတ်သွားမယ်။ Driver-Navigator မှာတော့ ရှုထောင့်ပေါင်းဆုံက စဥ်းစားတွေးခေါ်ထားတာဖြစ်လို့ လစ်ဟာသွားဖို့ခက်သွားမယ်။

ဒါ့အပြင် တစ်ယောက်က ကျွမ်းကျင်ပြီး နောက်တစ်ယောက်က မကျွမ်းကျင်တဲ့ အရာဆိုရင် နှစ်ယောက်ကို pair လိုက်ချင်းအားဖြင့် မသိတဲ့လူကို ဆွဲခေါ်ရတာ အဆင်ပြေတယ်။ သိတဲ့လူက Navigator နေရာကနေ ရှင်းပြပေးလို့ရတယ်။​ ဒါကြောင့်မလို့ ခုမှစဝင်တဲ့ လူသစ်ဆိုရင် ဒီနည်းနဲ့ တွဲခေါ်လို့ရတယ်။  ကျွန်တော်တုန်းကဆိုလည်း React Native နဲ့ JavaScript တစ်ခါမှမလုပ်ဘူးပေးမဲ့ ဒီနည်းနဲ့ လေ့လာတာ တစ်ပတ်၊ နှစ်ပတ်လောက်နဲ့ ရေးတတ်လာတယ်။

Ping Pong

Ping Pong က Test Driven Development TDD လုပ်နေရင် သုံးသင့်တဲ့နည်းဖြစ်တယ်။  သူကဘယ်လိုလဲဆိုတော့

• တစ်ယောက်က Test တစ်ခုရေးမယ်။ ဒါကို Ping လို့ခေါ်တယ်။
• နောက်တစ်ယောက်က Test ကို Pass သွားအောင် production code ကိုရေးမယ်။ ဒါကို Pong လို့ခေါ်တယ်။
• ပြီးရင် အဲ့တစ်ယောက်ကပဲ နောက်ထပ် Test တစ်ခုထပ်ရေးရမယ်။ Ping
• ပထမတစ်ယောက်က ပြန် Pass အောင်ရေး။ Pong။ ပြီးရင် Test ရေး.... အစရှိသဖြင့် နေရာဖလယ်ကြမယ်။

ဒီနည်းက ကိုယ့်ကုဒ်မှာ Test သေချာရှိစေတယ်။ နှစ်ယောက်လုံးကလည်း ကုဒ်သေးချာရေးရတော့ သိပ်မပျင်းရဘူး။​ ကျွန်တော့် Team မှာတော့ နှစ်ယောက်လုံး သိတဲ့အပိုင်းဆိုရင် Ping Pong နည်းနဲ့ရေးတယ်။

Pair Development

Pair နဲ့လုပ်တယ်ဆိုတာ Programming တစ်ခုတည်းမဟုတ်ပဲ Development တစ်ခုလုံးမှပါတဲ့ အဆင့်တိုင်းအတွက် လုပ်လို့ရတယ်။ ကျွန်တော်ဆိုရင် Spike တို့၊ Card လုပ်ရင်တို့၊​ Tech Analysis လုပ်ရင်တို့ လိုအပ်ရင် လိုအပ်သလို Pair လုပ်လေ့ရှိတယ်။ Tech Analysis နဲ့ Spike လိုမျိုးကျတော့ သူက Pair Programming နဲ့မတူတာက နှစ်ယောက်တူတူ ထိုင်လုပ်တာမဟုတ်ပဲနဲ့ ငါတို့လိုချင်တဲ့ အဖြေက ဘာလဲ၊ ဘယ်သူက ကဘယ်အပိုင်းကို​ရှာမလဲ၊​ တိုင်ပင်ပြီးရင် အချိန်တစ်ခုသတ်မှတ်ကြမယ်။​ အချိန်ပြည့်ရင် ပြန်တွေ့ကြပြီး တစ်ယောက်နဲ့ တစ်ယောက် ဖလှယ်တယ်၊​ လိုအပ်ရင်ထပ်အချိန်ယူမယ်ပေါ့။

Pair Rotation

Pair Programming ကတစ်ယောက်တည်းနဲ့ပဲ တစ်ချိန်လုံးတူတူလုပ်ရတာမဟုတ်ပဲ Team ထဲက လူတိုင်းနဲ့  တူတူလုပ်ရတာဖြစ်တယ်။ ဒီတော့ အချိန်တစ်ခုရောက်တိုင်း ကိုယ်နဲ့တွဲတဲ့လူကိုလဲရတယ်။ ကိုယ်လုပ်နေတဲ့ feature /card က မပြီးသေးဘူးဆိုရင် တစ်ယောက်က အဲ့ card မှာ နေခဲ့ရမယ်။ တစ်ယောက်တည်းကလည်း ဒီ feature တစ်ခုတည်းမှာပဲ အမြဲနေခဲ့လို့လည်းမရဘူးဆိုတာသိရမယ်။ နောက်တစ်ကြိမ် လူလဲမယ်ဆို အရင်တစ်ခေါက်နေခဲ့တဲ့လူက မနေခဲ့ပဲ feature ကနေထွက်သွားပေးတာမျိုးလုပ်ရမယ်။ ဒီလို လူလဲတဲ့ လုပ်ငန်းစဥ်ကို Pair Rotation လို့ခေါ်တယ်။ တစ်ခုက လူခဏခဏလဲနေရင် အဆင်မပြေသလို အကြာကြီးနေမှ  လဲရင်လည်းအဆင်မပြေဘူး။ ခဏခဏလဲ နေမယ်ဆိုရင် လူတစ်ခါလဲတိုင်း ဘယ်ရောက်နေပြီဆိုတာ တစ်ခါရှင်းပြနေရတာနဲ့ အလုပ်မတွင်တော့ဘူး။ အကြာကြီးနေမှလဲမယ်ဆိုရင်လည်း ကိုယ့် team ထဲမှာ အကြောင်းအရာတစ်ခုကိုပဲ သိတဲ့သူတွေများလာပြီး Knowledge transfer လိုသလောက် မရှိတော့ဘူး။ ဒီတော့ ကိုယ့် team နဲ့ကိုက်တဲ့ ဟာကိုရွေးဖို့လိုတယ်။ ကျွန်တော်တို့မှာတော့ တစ်ပတ်တစ်ခါ လဲတဲ့ team ရှိသလို၊ သုံးရက် တစ်ခါ၊ တစ်ရက်တစ်ခါ တွေလဲရှိတယ်၊။ တစ်ခုက သတ်မှတ်ထားတဲ့အချိန်တိုင်း မဖြစ်မနေ လဲရမှမဟုတ်ဘူး။ လိုအပ်ရင်လိုအပ်သလို အထိုက်အလျှောက် လုပ်ဖို့လဲလိုတယ်။ ဥပမာ တစ်ပတ်လုံး ရုံးပိတ်ရက်တွေ များနေမယ်ဆိုရင်တော့ အဲ့တစ်ပတ်အဖို့ လူမလဲတော့တာမျိုးလုပ်လို့ရတယ်။

ဘာလို့ Pair သင့်လဲ

Pairing လုပ်တာက နှစ်ယောက်တူတူလုပ်တော့ တစ်ချို့တွေက လူတစ်ယောက်အလုပ်ကို နှစ်ယောက်လုပ်ရတာ မလိုအပ်ပဲ အချိန်ပိုကြာတယ်၊ နှစ်ခုကို တစ်ယောက်တစ်ခုစီ လုပ်ရင် ပိုမြန်မြန်ပြီးတယ်ဆိုပြီး ထင်ကြတယ်။​ ဒီအကြောင်းကို ခဏလေးမေ့ထားပြီး ရတဲ့ အကျိုးကျေးဇူးတွေအရင်ပြောပြမယ်။

• တစ်ယောက်နဲ့တစ်ယောက် ထိန်းဖြစ်တယ်။ ဥပမာ ကျွန်တော်က ပျင်းပြီး Test လေးတော့မရေးတော့ပါဘူး လုပ်လို့မရဘူး။​ ကျွန်တော့်ကို သတိပေးမဲ့သူရှိတယ်။​ နောက်တစ်ခုက အသေးစိတ်စဥ်းစားပြီးရေးနေတဲ့သူနဲ့ နောက်ကနေ high level စဥ်စားပေးနေတဲ့လူရှိတော့ Code design ပိုင်း Code quality ပိုင်းမှာတော်တော် ကောင်းလာတယ်။
• တစ်ယောက်နဲ့ တစ်ယောက်ကြားမှာ empathy လို့ခေါ်တဲ့ စာနာစိတ်ပိုများစေတယ်။ အချင်းချင်း ယုံကြည်မှုလည်း ပိုစေတယ်။​ ယုံကြည်မှုပိုလာတဲ့အခါ "Collective Code Ownership" လို့ခေါ်တဲ့ ဘာဖြစ်ဖြစ် ညီတူမျှတူ တစ်ဖွဲ့လုံးတာဝန်ယူတတ်တဲ့စိတ်ကို အခြေခံတဲ့ culture တစ်ခု တည်ဆောက်ရလွယ်တယ်။
• Pairing က တစ်ယောက်က ကုဒ်ရေး၊ တစ်ယောက်က လိုက်ကြည့်ပေးနေရတာမလို့​ တစ်ခါတည်း review ပြီးသားဖြစ်တယ်။ Pull Request တွေမလိုတော့ဘူး။ Trunk Based Development သွားမယ်ဆို ဒါကတော်တော်အဆင်ပြေတယ်။ PR ကိုဖတ်လို့ ကုဒ်ကိုနားလည်တာ နဲ့ တူတူလုပ်လို့သိရတဲ့ နည်းလည်မှုက ကွာတယ်။​ တူတူလုပ်ရတာက ပိုနက်နက်နဲနဲ နားလည်စေတယ်။
• Knowledge Transfer လို့ခေါ်တဲ့ တစ်ယောက်နဲ့တစ်ယောက် သိထားတွေကို ဖလှယ်တာကို တစ်ခါတည်း ကုဒ်ရေးရင်းနဲ့ လုပ်လို့ရတယ်။ အပေါ်မှာပြောခဲ့သလို အပိုင်းတစ်ခုကို ကျွမ်းကျင်တဲ့လူက ရှင်းပြရင်း Onboarding လုပ်လို့ရတဲ့အထိ ဖလှယ်လို့ရတယ်။ ဒီလို ဖလှယ်ထားတော့ တစ်ယောက်က မအားတာတို့ နေမကောင်းဖြစ်လို့ ခွင့်ယူရမယ်တို့ ဆိုရင်လည်း နောက်တစ်ယောက်က သူမပါပဲ ဆက်လုပ်သွားလို့ရတယ်။အလုပ်ထွက်မယ်ဆိုရင်လည်း ကိုယ်က သပ်သပ်ကြီး အချိန်ပေးပြီး handover လုပ်စရာမလိုတော့ဘူး။

ဒီတော့ နှစ်ယောက်တူတူလုပ်တာက အချိန်ပိုကုန်တယ်ဆိုရင် ပြန်မေးရမှာက တကယ်လို့ bug တွေ့ခဲ့လို့ ပြန်ပြင်ရတဲ့အချိန်တွေက ဘယ်လောက်ကြမလဲ။ code quality ကအခြေအနေဆိုးလာပြီး နောက်တစ်နှစ်လောက်ကြာတော့ refactor အကြီးအကျယ်ပြန်လုပ်ရတဲ့ အချိန်တွေကကော၊​  ကုမ္မဏ္ဏီက လူတစ်ယောက်ထွက်သွားတဲ့အချိန် နောက်တစ်ယောက် ပြန်ဝင်လာတဲ့အချိန်မှာ အစကနေပြန်ရှင်းပြရတဲ့ အချိန်တွေကော ဘယ်လောက်ရှိမလဲ။​ ဒါတွေကို ထည့်တွက်တဲ့အခါ ရေရှည်မှာ အချိန်ကုန် သက်သာတာကို တွေ့ရမယ်။

အခက်အခဲတွေ

Pair programming က တစ်ခါတစ်ရံ တော်တော်စိတ်ပင်ပန်းစေတယ်။ Introvert တွေအတွက်ဆို ပိုဆိုးတယ်​။​​ ကျွန်တော်ဆိုလည်း စစက တစ်ချို့နေ့တွေဆို တစ်နေကုန် စကားပြောထားရတော့ ညဘက်မှာ ဘာမှမပြောနိုင်တဲ့ နေ့တွေရှိတယ်။ ဒီလိုမဖြစ်ရအောင် ကြားထဲမှာ နားချိန်လေးတွေယူဖို့လိုတယ်။ ကျွန်တော်ကတော့ pomodoro  နည်းကိုသုံးတယ်။ ၂၅ မိနစ်ပြည့်တိုင်း ၅ မိနစ်နား၊ လေးခါပြည့်ရင် မိနစ် ၂၀ လောက်နားတယ်။ တစ်ချို့ကျတော့ commit ပြီးတိုင်း၊  ဒါမှမဟုတ် task တစ်ခုပြီးတိုင်း နားတယ်။ ဒါတွေက Pair  စလုပ်တာနဲ့ ကိုယ် Pair နဲ့ နှစ်ယောက်လုံးအဆင်ပြေအောင် ညှိယူရမယ်။ တစ်ခုရှိတာက နားတယ်ဆိုတဲ့ အဓိပ္ပာယ်က email တွေ ဖတ်၊ စာပြန်တာတွေလုပ်နေရတာမျိုးမဟုတ်ပဲ​ လုံးဝ အပြည့်အဝ နားဖို့လိုအပ်တယ်။​ ဒီလို "office chore" တွေလုပ်ဖို့တွက်ကတော့ သက်သက် အချိန်ထပ်ပေးရတယ်။​ ဒီတော့ တစ်နေ့လုံးရဲ့ ၈၀ ရာခိုင်နှုန်းလောက်ကိုပဲ Pair​ ရင်လုံလောက်တယ်။ တစ်ချို့ ကုမ္မဏ္ဏီတွေမှာတော့ Pair ကို Knowledge transfer လုပ်ပေးဖို့လောက်ပဲသုံးကြတယ်။

အချိန်အကြောင်းပြောရင်း နောက်တစ်ခုကျွန်တော်တို့ Team မှာကြုံရတာက Timezone အခက်အခဲ။ ကျွန်တော်တို့ Team က Cross-regional team ဖြစ်တယ်။ တစ်ခါတစ်လေ ကျွန်တော်နဲ့ Pair တဲ့လူက ၄ နာရီလောက်အချိန်ကွာတယ်။ တစ်ရက် ၄ နာရီလောက်က မ Pair ပဲ တစ်ယောက်တည်းလုပ်ရတော့ သူမနက်မိုးလင်းကြည့်ဖို့ ညနေကျ PR တင်၊ သေချာ စာရေးပြီး ဘာလုပ်ထားတယ်ဆိုတာရှင်းပြတာမျိုးလုပ်ရတယ်။ အခုတော့ Region အလိုက် Team သေးသေးလေးတွေ ထပ်ခွဲလိုက်တော့ အဆင်ပြေသွားပြီ။ အဲလိုမလုပ်ခင်ကတော့ ကျွန်တော်တို့တတ်နိုင်သလောက် Region တူတဲ့သူအချင်းချင်း Pair ကြတယ်။ Cross-region လုပ်ရတော့မယ်ဆိုရင် အရမ်းမရှုပ်တဲ့ card မျိုးကိုလုပ်ကြတယ်။ အဲခါကျ PR တင် စာအရှည်ကြီးရှင်းပြစရာ မလိုတော့ပဲ ပြန်ရှင်းပြရလွယ်တယ်။ ပြီးရင် အားလုံးလက်ခံထားတဲ့ Meeting time ရှိဖို့လဲလိုတယ်။ ဒါတွေကတော့ Cross regional team လုပ်တဲ့ပုံအကြောင်း နောက်မှထပ်ရေးပါဦးမယ်။

Remote Working

ရုံးမှာ တူတူထိုင်လုပ်ရတာကျတော့ ထွေထွေထူးထူးပြောစရာမရှိဘူး။ Bring your own Keyboard ကိုယ်အသုံးကျနေတဲ့ ကီးဘုဒ်ကို သယ်လာဖို့၊ ရုံးကလည်း တူတူလုပ်ဖို့ Monitor တွေထားပေးထားဖို့၊ Keyboard ကို အကြာကြီး ကိုယ်ပဲရိုက်နေတာမျိုးမဖြစ်ဖို့ လောက်ပဲပြောစရာရှိတယ်။ Remote Working မှာကျတော့ Pair ရတာ တစ်ခါတစ်လေလက်ဝင်တယ်။ Software အနေနဲ့ကတော့

• Zoom သုံးတယ်ဆိုရင် Zoom မှာ Remote Control ပေးလို့ရတယ်၊ ပြီးရင် Annotate လုပ်တဲ့နည်းတို့ ကို သိထားဖို့လိုတယ်။ Interview တွေဖြေဖူးရင်တော့ ဒါကမခက်ပါဘူး။
• VSCode သမားဆိုရင် Live Share ကိုသုံးလို့ရတယ်။ အလားတူ IntelliJ မှာလည်း Code with me ဆိုတာရှိတယ်။ ကျွန်တော့်အတွေ့အကြုံမှာတော့ နှစ်ခုလုံးက latency တွေရှိတယ်။ တူတူပြိုင်ရေးရင် တိုင်ပတ်ကုန်တာမျိုးတွေ ရှိတယ်။ ဒီတော့ "ငါလုပ်မယ်နော်၊ မရေးနဲ့ဦးနော်" လို့ပြောပြီးမှ ကိုယ်ကရေးရတာတွေရှိတယ်။
• ကုမ္မဏ္ဏီက တစ်ချို့ team တွေကတော့ Tuple သုံးတယ်။ အဆင်ပိုပြေတယ်လို့ဆိုပေမဲ့ ကိုယ်တိုင်မသုံးကြည့်ဘူးတော့ မပြောတတ်ဘူး။

နောက်တစ်ခုက Remote Pair မယ်ဆို အသံသိပ်မဆူတဲ့နေရာမှ အဆင်ပြေမယ်။ အနည်းဆုံး Mic မတတ်နိုင်ရင်တော့ နားကြပ်လေးတော့ ဝယ်ထားသင့်တယ်။ ပြီးရင် IDE Theme တွေကို တစ်ရောက်တစ်မျိုးလျှောက်မလုပ်ပဲ Team တစ်ခုလုံး ညှိပြီးထားတာ Screen share တဲ့အခါကျ တစ်ဖက်လူအတွက် လိုက်ကြည့်ရတာ ပိုလွယ်ကူစေတယ်။

Pair Programming အကြောင်းပြောမယ်ဆို ဒီထက်အများကြီးတော့ ပြောစရာတွေရှိသေးတယ်။ Martin Fowler ရေးထားတာက ပိုပြီးတော့ပြည့်စုံမယ်။​ ကျွန်တော်က ကိုယ်ပိုင်အတွေ့အကြုံကို ပဲအဓိကထားရေးထားတာဆိုတော့ သူလို့တော့ မစုံဘူးပေါ့။ ဘယ်လိုဖြစ်ဖြစ် ဒါလေးဖတ်လိုက်ရလို့ အနည်းဆုံး Pairing အကြောင်းတော့ သိသွားမယ်လို့ထင်ပါတယ်။ Pairing အကြောင်းသိချင်သေးရင် email ပို့ပြီး မေးလို့လည်းရပါတယ်။ ကျွန်တော်တတ်နိုင်သလောက်ဖြေပေးပါမယ်ဗျာ။