Working with SCRUM

SCRUM ဆုုိတာ Agile Methodology ေတြကုုိ လုုိက္နာႏုုိင္ေအာင္ အေထာက္အကူျပဳေပးတဲ့ framework တစ္ခုုပါ။ Project တစ္ခုုလုုိမ်ိဳး deliver လုုပ္ျပီးရင္ သိပ္ျပင္ေလ့မရွိတဲ့ အေနအထားမ်ိဳးမွာ Waterfall လုုိ Methodlogies ေတြကုုိ သုုံးေလ့ရွိေပမယ့္ Continuous develop လုုပ္ေနရတဲ့ Product လိုုမ်ိဳးအေနအထားမွာ SCRUM ကုုိပုုိျပီးအသုုံးျပဳေလ့ရွိပါတယ္။ ခပ္ဆင္ဆင္တူတဲ့ Lean နဲ ့ Kanban လုုိမ်ိဳးကုုိ တျခားရုုံးေတြက သုုံးေကာင္းသုုံးေပမယ့္ က်ြန္ေတာ္ မသုုံးဖူးလုုိ ့ အတိအက်ေတာ့မသိပါဘူး။ ဒီပိုုစ္မွာေတာ့ က်ြန္ေတာ္တုုိ့ အလုုပ္ထဲမွာ လုုပ္ေနရတဲ့ SCRUM ကုုိပဲအဓိက ေျပာသြားမွာပါ။

အရင္ဆုုံး SCRUM ကုုိအသုုံးျပဳမယ္ဆုုိရင္ Project တစ္ခုုလုုံးကုုိ task list ေတြ ပုုိင္းပစ္ရပါတယ္။ ပိုုင္းရင္းနဲ့မွ တခ်ိဳ့အပုုိင္း ေတြဟာၾကီးေနေသးရင္ EPIC ဆုုိတဲ့ နာမည္တပ္ျပီး ထပ္ပုုိင္း ရပါတယ္။ EPIC ဆုုိတာကေတာ့ task list ေတြရဲ့ category လုုိမ်ိဳး သေဘာမ်ိဳးပါ။ ဥပမာ Blog တစ္ခုုကုုိ Project အေနနဲ ့ ဥပမာေပးတယ္ ဆုုိပါစုုိ ့ post တင္တဲ့ အပုုိင္းအတြက္ Create, Retrieve, Update, Delete (CRUD) ဆုုိျပီးေလးပိုုင္းရမယ္။ အဲဒီအတြက္ EPIC ဟာ Post ျဖစ္ျပီး CRUD တစ္ခုုခ်င္းစီက task list ပါ။ ဒီေနရာမွာ task list ေတြကုုိ အေသးႏုုိင္ဆုုံး ခြဲႏုုိင္ေလ ပုုိ အဆင္ေျပေလ ပါပဲ။ အထက္က ဥပမာ အရဆုုိရင္ CRUD ကုုိပဲ User Interface အတြက္ Frontend က တစ္ပုုိင္း ၊ Server side အတြက္ က တစ္ပုုိင္းပုုိင္းႏုုိင္ပါတယ္။ သုုိ ့ေသာ္ မ်ားမ်ားပုုိင္းေလ ေကာင္းေလ ဆုုိျပီးေတာ့ class တစ္ခုုစီ method တစ္ခုုဆီကုုိ ပုုိင္းရင္ေတာ့ အဆင္မေျပေတာ့ပါ။ SCRUM က ရည္စူးထားတာက One Bite at a time ဆုုိေတာ့ ကုုိယ္ႏုုိင္သေလာက္ပါ။

Sprint ကုုိခန့္မွန္းတဲ့ အေၾကာင္းမလာခင္ sprint ဆုုိတာ ဘာလဲလုုိ့ ရွင္းျပဖုုိ့ လုုိပါလိမ့္မယ္။ Sprint ဆုုိတာ အခ်ိန္သတ္မွတ္ခ်က္ တစ္ခုုပါ။ ဥပမာ ဘယ္သူက ဘယ္အခ်ိန္ ဘယ္ေလာက္ျပီးမလဲ ဆုုိတာ မွန္းဆဖုုိ့ အတြက္ အခ်ိန္သတ္မွတ္ခ်က္လုုိပါတယ္။ ေယဘူယ်အားျဖင့္ Sprint တစ္ခုုအတြက္ တစ္ပတ္ သုုိ ့မဟုုတ္ ႏွစ္ပတ္ အလ်ဥ္းသင့္သလုုိ သတ္မွတ္ေလ့ရွိပါတယ္။ အဲဒီ sprint ေပါ္မွာ မူတည္ျပီး quarter ေတြတြက္ယူရပါတယ္။ quarter ဆုုိတာက sprint တစ္ခုု ထဲမွာ ပါဝင္ အခ်ိန္အပုုိင္းအျခားေတြပါ။ ဥပမာ က်ြန္ေတာ္တုုိ ့ ရုုံးတက္ခ်ိန္ကုုိ ေလးပိုုင္းပုုိင္းျပီး တစ္ပုုိင္းကိုု quarter တစ္ခုု သတ္မွတ္မလား ၊ ဒါမွမဟုုတ္ တစ္နာရီကုုိ quarter တစ္ခုုအေနနဲ ့သတ္မွတ္မလား။ ဒီသတ္မွတ္ခ်က္ေတြဟာ Scrum Master ေပါ္မွာမူတည္ပါတယ္။ ဒီေနရာမွာ သမရုုိးက် Project Managment လုုပ္တဲ့သူအေနနဲ့ Scrum Master ဆုုိတဲ့ အသုုံးကိုု စိမ္းေကာင္းစိမ္းေနလိမ့္ပါမယ္။ SCRUM Master ဆုုိတာက Project မွာပါဝင္သူေတြ (Developer, Designer စသျဖင့္ စသျဖင့္) အလုုပ္ကိုု ပိုုမုုိျပီးေျမာက္ႏုုိင္ဖုုိ ့ အေထာက္အကူျပဳသူေတြပါ။ SCRUM မွာ Project Manager ဆုုိတဲ့ role မရွိပါဘူး။ Project Manager နဲ့ ခပ္ဆင္ဆင္ တူတဲ့ Product Owner ဆုုိတာေတာ့ရွိေသာ္လည္း အတိအက်ေတာ့ မတူပါဘူး။ Product Owner ဆုုိတာက Product အတြက္ လုုိအပ္တဲ့ Feature ေတြကုုိ သတ္မွတ္ေပးတဲ့သူပါ။ Project manager နဲ ့မတူတာက သူက decision maker ပါ။ အထက္ရဲ့အထက္ရဲ့ အထက္ဆုုိတာလုုိမ်ိဳး လုုိက္လံညွိႏႈိင္းရင္း အလုုပ္ရႈပ္ေထြးမွာကုိ ကာကြယ္တဲ့ အေနနဲ့ Product Owner ရဲ ့ decision ကုုိမူတည္ျပီး SCRUM master က ရွိတဲ့ developer ေတြနဲ ့ ညွိႏႈိင္းေဆာင္ရြက္ပါတယ္။ တနည္းအားျဖင့္ Scrum Master ဟာ ပါဝင္သူေတြနဲ ့ Product Owner ၾကားမွာ ညွိႏႈိင္းေဆာင္ရြက္သူပါ။

ေရွ့ဆက္ရရင္ ေပးထားတဲ့ အခ်ိန္ေပါ္မွာ မူတည္ျပီး SCRUM master က ရွိတဲ့ လူေတြနဲ ့ ဘယ္လုုိလုုပ္ရင္ ဘယ္အခ်ိန္ေလာက္ျပီးမလဲ ၊မွီမလား မမွွီဘူးလား ဆုုိတာ ခန္ ့မွန္းဆုုံးျဖတ္ရတာပါ။ ဥပမာ developer တစ္ေယာက္ နဲ့ designer တစ္ေယာက္ပဲ ပါတဲ့ product တစ္ခုု ၊ blog ပဲဆုုိပါစုုိ ့။ CRUD အတြက္ Frontend အတြက္ task ေလးခုု ၊ Server side အတြက္ task ေလးခုု ၊ Designer က Photoshop template ေလးခုု အတြက္ task က ၁၂ ခုုပါ။ အဲဒီအတြက္ အခ်ိန္ တစ္ပတ္ပဲရတယ္ ဆုုိပါစုုိ ့။ တစ္ပတ္မွာ ငါးရက္ရွိျပီး တစ္ရက္မွာ 4 quarter လုုိယူမယ္ ဆုုိရင္ တစ္ေယာက္ခ်င္းစီအတြက္ quarter က ၂၀ ျဖစ္ျပီးေတာ့ စုုစုုေပါင္း 40 quarters ပါ။ ျပီးရင္ေတာ့ developer နဲ ့ designer ကုုိ task တစ္ခုုအတြက္ quarter ဘယ္ႏွစ္ခုုလုုိမလဲ ဆုုိတာ ေမးရပါတယ္။ ဥပမာ Create အတြက္ ငါးခုု ၊ Edit က သုုံးခုု ၊ retrieve က ႏွစ္ခုု နဲ ့ delete က တစ္ခုုလုုိ ့ ဆုုိပါစိုု ့။ စုုစုုေပါင္း ၁၁ quarter ပါ။ design အတြက္ template တစ္ခုုကိုု 3 quarter စီ ဆုုိပါစိုု ့။ designer အတြက္ 12 quarter ပါ။ ဒီအတြက္ စုုစုုေပါင္း 12+10 = 22 quarter က်မွာျဖစ္ျပီး ရထားတဲ့ quarter က 40 ျဖစ္ေတာ့ ေလာက္တယ္လုုိ ့ အၾကမ္းျဖင္းယူဆလိုု ့ရပါျပီ။ ျပီးရင္ task ေတြကိုု priortise လုုပ္ရပါမယ္။ အခုု လက္ရွိကိစၥအတြက္ ဆုုိရင္ Front End က design ျပီးမွ လုုပ္လုုိ ့ရမွာပါ။ ဒီအတြက္ အျပိဳင္လုုပ္လုုိ ့ရမွာက Design နဲ ့ Server Side ပါ။ အဲဒီအတြက္ Epic ကုုိျပန္စီရပါတယ္။ ျပီးရင္ Epic တစ္ခုုခ်င္းစီက task list ကုုိ ထပ္စီရပါတယ္။ ဥပမာ CRUD မွာ ျပတာျဖစ္တဲ့ retrieve ကုုိအရင္လုုပ္မယ္။ data ကုုိေတာ့ database ထဲကေန seed လုုပ္ျပီး ျပမယ္ေပါ့။ ျပီးရင္ Create ကုုိလုုပ္မယ္။ သူနဲ ့ဆင္တဲ့ Update ကုုိလုုပ္မယ္။ ေနာက္ဆုုံးက်မွ update ကုုိ လုုပ္မယ္ ဆုုိျပီး ထပ္စီလုုိ ့ရပါတယ္။

Quarter သတ္မွတ္တဲ့ေနရာမွာ Product Owner က ဒါက ဒီေလာက္ဆုုိျပီး ဝင္သတ္မွတ္လိုု ့မရပါဘူး။ SCRUM အရဆုုိရင္ Product Owner မွာ အဲဒီလုုပ္ပုုိင္ခြင့္မရွိပါဘူး။ Quarter ကုုိ SCRUM master နဲ ့ developer နဲ ့ညွိႏႈိင္းျပီး သတ္မွတ္ရပါတယ္။ Quarter သတ္မွတ္ျပီးရင္ ေနာက္တစ္ဆင့္က Point ကုုိသတ္မွတ္ရပါတယ္။ Quarter ကုုိသတ္မွတ္တာက ျပီးေလာက္မယ့္ အခ်ိန္ကာလကုုိ မွန္းဆႏုုိင္ေအာင္ ရာထားတာျဖစ္ျပီး point ကေတာ့ အဲဒီလုုိမဟုုတ္ပါဘူး။ point က task တစ္ခုုရဲ ့ ခက္ခဲမႈအေပါ္ မူတည္ျပီး သတ္မွတ္ပါတယ္။ point ကုုိသတ္မွတ္တဲ့ factor ေတြကေတာ့ Complexity (ဘယ္ေလာက္ရႈပ္ေထြးသလဲ ?) ၊ effort ( ဘယ္ေလာက္ အားစုုိက္ရသလဲ ?) ၊ Uncertainty (ဘယ္ေလာက္ မေသခ်ာ သလဲ အေပါ္မွာ မူတည္ျပီး ခ်င့္ခ်ိိန္ပါတယ္။ ဒီေနရာမွာ ေရွ့ႏွစ္ခုုကုုိ ရွင္းေပမယ့္ ေနာက္တစ္ခုုကိုု နည္းနည္း အူေၾကာင္ေၾကာင္ ျဖစ္ႏုုိင္ေခ် ရွိတယ္။ ဘာကုုိ မေသခ်ာတာလဲ ဆုုိတာ။ ဒါကေတာ့ task အတြက္ေပးထားတဲ့ဟာကိုု နည္းပညာ A နဲ ့အသုုံးျပဳျပီး ေရးမယ္ ဆုုိပါစုုိ ့။ အဲဒီ နည္းပညာ A ကုုိ တကယ္တမ္း ေလ့လာလုုိက္မွ အဲဒီ နည္းပညာ A နဲ ့ အဲဒီ task ကိုုလုုပ္မရဘူး ဆုုိတာ ျဖစ္ႏုုိင္ပါတယ္။ အဲဒီအတြက္ကုုိ ထားထားတာပါ။ သတ္မွတ္တဲ့ ေနရာမွာလည္း SCRUM master က ေညး မင္းေတာ့ ဒီေလာက္ယူလုုိက္ကြာ ဆုုိျပီး သတ္မွတ္တာထက္ Planning Poker ကိုု အသုုံးျပဳျပီး သတ္မွတ္ေလ့ရွိပါတယ္။ (planning poker အေၾကာင္းကိုုေတာ့ ေနာက္မွ သတ္သတ္ ေရးပါမယ္။)

ျပီးရင္ေတာ့ Definition of Done (DoD) ကုုိသတ္မွတ္ရပါတယ္။ DoD ဆုုိတာက task တစ္ခုုျပီးေျမာက္တာကိုု ဘာနဲ ့သတ္မွတ္မလဲ။ က်ြန္ေတာ္ကေတာ့ Create အတြက္ task ကုုိေရးလုုိက္တာပဲ ၊ implmentation ၾကမွ error ေတြမွ ပုုံလုုိ ့ဆုုိတာမ်ိဳးဆိုုတာ မထူးဆန္းတဲ့ အေနအထားပါ။ အဲဒီအတြက္ DoD ကုုိ သတ္မွတ္ဖုုိ ့လုုိပါတယ္။ team တစ္ခုုနဲ ့တစ္ခုု DoD သတ္မွတ္တာမတူပါဘူး။ တခ်ိဳ ့ team ေတြအတြက္ ပုုံေလးေပါ္ စာေလးထည့္လိုု ့ရရင္ ေတာ္ပါျပီ ဆုုိတာ ျဖစ္ေကာင္းျဖစ္ႏုုိင္ေပမယ့္ တခ်ိဳ ့ team အတြက္ Unit test pass ျဖစ္ရမယ္ ၊ Jenken ေပါ္မွာ တျခား PHP version အစုုံနဲ ့ Device အစုုံေပါ္မွာ အလုုပ္လုုပ္ရမယ္ ၊စသျဖင့္ စသျဖင့္ ျဖစ္ႏုုိင္ပါတယ္။ ဒါေတြကိုု Sprint Planning မွာ တခါတည္း ေဆြးေႏြးရပါတယ္။

ျပီးလုုိ ့ Sprint ကုုိအတည္ျပဳ အလုုပ္ေတြခြဲေဝလုုပ္ရင္း sprint တစ္ခုုျပီးတုုိင္းျပီးတုုိင္း Sprint Review section ကုုိ team member ေတြနဲ ့ျပန္ထုုိင္ရပါတယ္။ အဲဒီမွာ အပုုိင္းႏွစ္ပုုိင္းပါပါတယ္။ ပထမတစ္ပုုိင္းကေတာ့ လက္ရွိ sprint ရဲ ့ အေျခအေန ၊ အလုုပ္ေတြ ျပီးမျပီးနဲ ့ ၊မျပီးရင္ က်န္ခဲ့တဲ့ task ေတြနဲ ့ အသစ္လာမယ့္ task ေတြကုုိ ေနာက္ sprint planning မွာ ထည့္သြင္းရမယ့္ အေၾကာင္းပါ။ ေနာက္တစ္ပုုိင္းက အခုု run ေနတဲ့ sprint process ၾကီးရဲ ့အေျခအေနပါ။ အထဲက developer ေတြ တစ္ေယာက္နဲ ့တစ္ေယာက္ အခ်ိဳးမေျပလုုိ ့ေပါက္ကရေတြ လုုပ္သလား ၊ ျကားထဲမွာ interrupt ေတြဘာရွိသလဲ ၊ စသျဖင့္ စသျဖင့္ပါ။ အၾကမ္းအားျဖင့္ေတာ့ သုုံးပုုိင္းပုုိင္းလုုိ ့ရပါတယ္။ Start ၊ Stop နဲ ့ Continue ပါ။ Start မွာက ေနာက္ sprint မွာ ဘာေတြစျပီး လုုပ္ေဆာင္သင့္တယ္ ဆိုုတာမ်ိဳး ၊ ဥပမာ Unit test မလုုပ္ျဖစ္ဘူး ၊အခုုလုုပ္မယ္။ Stop ကေတာ့ ဘာေတြကုုိ ရပ္သင့္သလဲဆုုိတာမ်ိဳး ၊ ဥပမာ အခုု workflow က အဆင္မေျပဘူး ဘယ္လုုိ ေျပာင္းသင့္တယ္ ဆုုိတာမ်ိဳး ၊ continue ကေတာ့ ေနာက္ sprint ေတြမွာပါ ဆက္လက္ ထိန္းသိမ္းသင့္တဲ့ အစဥ္အလာေကာင္းမ်ိဳးဟာမ်ိဳးေတြပါ။

မွတ္ခ်က္ ။ ။ အိပ္ခါနီး အခ်ိန္ရသေလာက္ လက္တန္းေရးလုုိက္တာမ်ိဳး လြန္တာရွိ ဝႏၵာမိပါ။ တကယ့္တကယ္ပုုံေတြ စာေတြနဲ ့ေဝဆာေနေအာင္ ေရးမွ ပုုိျပီး ဖတ္ရတာ အဆင္ေျပေပမယ့္လည္း ၊ ဘယ္သူေတြ ဘယ္ေလာက္ ဖတ္မလဲ ဆုုိတာ အတိအက် မသိလုုိ ့ အၾကမ္းေလာက္ပဲေရးလုုိက္ပါတယ္။ စိတ္ဝင္စားရင္ ဝင္မန္ ့သြားႏုုိင္ပါတယ္။

originally wrote it in facebook

Show your support

Clapping shows how much you appreciated Naing Lin Aung’s story.