အခန်း ၃ :: Agile Development
Waterfall လိုမျိုး ရှေးရိုးစွဲ နည်းလမ်းတွေ ရဲ့ အားနည်းချက်တွေက ပြုပြင်မလွယ်ဘူး။ အဆင့်တဆင့်ပြီးသွားရင် ပြန်ပြင်မရတော့ဘူး။ အရင်က အဆင်ပြေခဲ့ပေမယ့် နောက်ပိုင်းမှာ web development တွေ ခေတ်စားလာတာ နဲ့ အညီ web software တွေ အများကြီးဟာ 2000 ဝန်းကျင်မှာ ခေတ်စားလာတယ်။ တနည်းပြောရင် ရှေးရိုးဆွဲ distribution ပုံစံ မဟုတ်တော့ပဲ website ပေါ်မှာ deployment မြန်မြန် လုပ်လို့ရလာတယ်။ တနည်းပြောရင် သမာရိုးကျ နည်းလမ်းကနေ ပိုမိုမြန်ဆန်ပြီး user တွေ နဲ့ မြန်မြန် ဆန်ဆန် ထိတွေ့ ဆက်ဆံ သည့် နည်းလမ်း ပြောင်းလဲလာသည့် သဘောပဲ။ bugs တွေ ရှိတယ်။ user က တောင်းဆိုသည့် feature တွေ ရှိတယ်။ လိုလည်း လိုအပ်တယ်။ user ကလည်း တောင်းဆိုနေတယ်။ Software မှာ ချက်ခြင်း ထည့်မရဘူး။ ဘာဖြစ်လို့လည်း ဆိုတော့ waterfall process က requirement အဆင့် planning အဆင့်ပြီးသွားလို့ development လုပ်နေသည့် အဆင့်ဖြစ်တယ်။ ဒီ feature ကို ထပ်ဖြည့်မယ် ဆိုရင် အစ ကနေ ပြန်စရမယ်။ ဒီလို ပြဿနာ တွေ အများစုက ၂၀၀၀ ဝန်းကျ web 2.0 ခေတ်စားလာတာနဲ့ အညီ စပြီး ကြုံတွေ့ရသည့် ပြဿနာပဲ။
အခန်း ၁ မှာ ပြောခဲ့သလိုမျိုး ၂၀၀၁ ခုနှစ်မှာ Software Developer ၁၇ ဦးက Agile Manifesto ကို ထုတ်ပြန်ခဲ့ပြီး Software Development ပုံစံကို ပြောင်းလဲ စေခဲ့တယ်။ အဓိက တန်ဖိုး ၄ ခု နှင့် principles ၁၂ ခု ပါဝင်ပါတယ်။
၃.၁ The Four Values နှင့် Twelve Principles
တန်ဖိုးထားမှု ၄ ခု (The Four Values)
အခန်း ၁ တွင် ဖော်ပြခဲ့သည့်အတိုင်း Agile Manifesto ၏ တန်ဖိုးထားမှု ၄ ခုမှာ-
- ပုဂ္ဂိုလ်များနှင့် အပြန်အလှန်ဆက်ဆံရေးကို လုပ်ငန်းစဉ်များနှင့် ကိရိယာများထက် ပို၍တန်ဖိုးထားခြင်း
- အလုပ်လုပ်သော ဆော့ဖ်ဝဲလ်ကို ပြည့်စုံသော မှတ်တမ်းပြုစုခြင်းထက် ပို၍တန်ဖိုးထားခြင်း
- ဖောက်သည် ပူးပေါင်းဆောင်ရွက်မှုကို စာချုပ်ညှိနှိုင်းခြင်းထက် ပို၍တန်ဖိုးထားခြင်း
- အပြောင်းအလဲကို တုံ့ပြန်ခြင်းကို စီမံကိန်းအတိုင်း လုပ်ဆောင်ခြင်းထက် ပို၍တန်ဖိုးထားခြင်း
ဆိုလိုချက်ကတော့ ဘယ်အရာ ကို ပိုပြီး အလေးပေးသင့်သလဲ ဆိုတာကို ဖော်ပြထားတာပါ။
Principles ၁၂ ချက်
- Customer Satisfaction အဓိက ဥိးစားပေးမှာ Software များကို အချိန်မှီ deliver လုပ်ခြင်းဖြင့် customer ကို စိတ်ကျေနပ်မှု ရရှိစေရန်
- Welcome Change Requirement များ ပြောင်းလဲခြင်းကို ကြိုဆိုခြင်း။ Development လုပ်နေသည့် ကာလ ဖြစ်နေပါစေ အပြောင်းအလဲ ကို ကြိုဆိုသည်။
- Deliver Frequently တကယ်အလုပ်လုပ်လို့ ရသည့် Software များကို ရက်သတ္တပတ် အနည်းငယ် လအနည်းငယ် အတွင်း မကြာခဏ deliver လုပ်ပေးရန်။
- Work Together Business သမားများ နှင့် developer များ ကို product ဖန်တီးနေသည့် ကာလ အတွင်း အတူတကွ လုပ်ဆောင်ရန်
- Motivated Individuals တကယ် စိတ်အားထက်သန်သော လူများ ဖြင့် project ကို တည်ဆောက်ရန်
- Face-to-Face Conversation Development Team အတွင်း သတင်းအချက်အလက် များ ဖြန့်ဝေရန် အထိရောက်ဆုံး နှင့် အကောင်းဆုံးနည်းလမ်းမှာ မျက်နှာချင်းဆိုင် စကားပြောခြင်းဖြစ်သည်
- Working Software တကယ် အလုပ်လုပ်သော software ဖြင့်သာ တိုးတက်မှု ကို အဓိက တိုင်းသာ သည်။
- Sustainable Pace ရေရှည်တည်တံ့နိုင်သည့် development များကို အားပေးသည်။ developer များ user များသည် အမြဲတန်း ထိန်းသိမ်းထားသင့်သည်။
- Technical Excellence နည်းပညာဆိုင်ရာ ထူးချွန်မှု နှင့် design ကောင်းမွန်မှု အပေါ်အာရုံစိုက်ခြင်းက agility ကို မြှင့်တင်ပေးသည်
- Simplicity မလိုအပ်သော အလုပ်များကို ရှောင်ရှားပြီး ရိုးရှင်း မှု သည် အရေးကြီးသည်။
- Self-Organization Teams အကောင်းဆုံး architecture များ requirement များနှင့် ကိုယ့်ဘာသာ manage လုပ်နိုင်သည့် self organization team ထွက်ပေါ်လာရန် အရေးကြီးသည်။
- Regular Reflection Team သည် ပုံမှန် အချိန်ကာလ များ တွင် ပိုမို ထိရောက်အောင် မည်သို့ လုပ်ဆောင်နိုင်သည် ကို ပြန်လည် သုံးသပ်ပြီး လိုက်လျော်ညီထွေ ဖြစ်အောင် ညိုနိုင်းပြုပြင်ရန်
Agile Methodology အောက်မှာ project management အတွက် Scrum, Kanban တို့ဟာ လက်တွေ့ လူ အသုံးများဆုံးဖြစ်ပါတယ်။
၃.၂ Scrum Framework
Scrum သည် Agile ကို လက်တွေ့ အကောင်အထည်ဖော်ရန် နှင့် လူသုံးအများဆုံး framework တစ်ခု ဖြစ်သည်။ အခု နောက်ပိုင်း company တွေမှာ Scrum ကို project management အတွက် အသုံးပြုကြပါတယ်။ ဒါပေမယ့် သိထားဖို့ လိုတာက Scrum က framework ပါ။ ရိုးရှင်းပေမယ့် ကျွမ်းကျင် နားလည်စွာ အသုံးပြုနိုင်ဖို့ ခက်ခဲပါတယ်။ Team တစ်ခုလုံး ပူးပေါင်း ဆောင်ရွက်မှ Scrum က အောင်မြင်ပါလိမ့်မယ်။ Scrum ကို 3-5-3 ဟု ခေါ်ကြပါတယ်။ Role ၃ ခု , Events ၅ ခု နှင့် Artifacts ၃ ခု တို့ ပါဝင်ပါတယ်။
Scrum ၏ အဓိက သဘောတရားမှာ Empiricism (အတွေ့အကြုံပေါ် အခြေခံသော သီအိုရီ) ဖြစ်ပြီး၊ ဆုံးဖြတ်ချက်များကို အတွေ့အကြုံနှင့် လက်တွေ့ အချက်အလက်များပေါ်တွင် မူတည်၍ ချမှတ်ခြင်း ဖြစ်သည်။ Scrum ၏ အဓိက အချက် ၃ ခု မှာ
Transparency
ပွင့်လင်းမြင်သာမှု ရှိမှု သည် အရေးပါသည်။ လုပ်ငန်းစဥ်နှင့် ပတ်သက်သော အရေးကြီးသည့် အချက်အလက် များကို အဖွဲ့ဝင် အားလုံး နှင့် သက်ဆိုင်သူ (Stakeholders) အားလုံး မြင်နိုင်ရမည်။
Inspection
သတ်မှတ်ထားသည့် ရည်မှန်းချက်များ (Goals) နှင့် သွေဖည်မှု မရှိစေရန် Scrum Artifacts များ နှင့် လုပ်ငန်းတိုးတက် မှု များကို မကြခဏ စစ်ဆေးရမည်။
Adaptation
စစ်ဆေးမှု မှ ရလာသည့် အချက်အလက်များ အရ လုပ်ငန်းစဥ် နှင့် လက်ခံနိုင်သော အတိုင်းအတာထက် ကျော်လွန် နေပါက အမြန်ဆုံး ပြန်လည် ပြင်ဆင် ညှိနှိုင်း ရမည်။
Scrum Roles
Scrum Team တစ်ခု မှာ အဓိက role ၃ ခု ရှိပါသည်။
Product Owner (PO)
Product ၏ တန်ဖိုးကို အမြင့်ဆုံး ဖြစ်စေရန် တာဝန်ရှိသူ ဖြစ်သည်။ Product Backlog ကို စီမံခန့် ခွဲရသည်။ Stakeholder များ customer များ developer များ အကြား ကူးလူးဆက်သွယ်ပေးရသည့် ပေါင်းကူး တံတားဖြစ်သည်။ တနည်းပြောရင် project တစ်ခုလုံး ရဲ့ idea လုပ်ဆောင်ရမယ့် product တစ်ခုလုံး ဘယ်လို အလုပ်လုပ်နေလဲ ဆိုတာ ကို Product owner က ကောင်းမွန်စွာ သိနေဖို့ လိုပါတယ်။
Scrum Master (SM)
Scrum Framework ကို မှန်ကန်စွာ လိုက်နာကျင့်သုံးနိုင်ရန် ကူညီပေးသူ ဖြစ်သည်။ Team ၏ အတားအဆီးများ ကို ဖယ်ရှားပေးပြီး Scrum process ကို ချေမွေ့စွာ လည်ပတ်နိုင်ရန် ဆောင်ရွက်ပေးရသည်။ team ၏ servant-leader ဖြစ်သည်။
The Development Team
Product Increment ကို ဖန်တီးပေးရသော ကျွမ်းကျင်သူများ အဖွဲ့ဖြစ်သည်။ Team သည် cross-functional (backend, frontend, Full-Stack, QA, designer အားလုံးပါဝင်) ဖြစ်ပြီး self-organizing ဖြစ်ရမည်။
Scrum Framework မှာ Scrum Master က အရေးပါပါတယ်။ အများအားဖြင့် Scrum ကို အသုံးပြုသည့် အခါမှာ Developer များအနေနဲ့ Project Manager နဲ့ မှားတတ်သလို Scrum Master role မှာ မလိုအပ်ဘူး လို့ ထင်တတ်ပါတယ်။ Scrum Master ဟာ Team ကို Scrum ကို မှန်ကန်စွာ အသုံးပြုအောင် လမ်းပြရသလို အမြဲ ပြန်တည့်မတ် ပေးရပြီး Scrum Team တစ်ခု အောင်မြင်ဖို့ Scrum Master က အရေးပါ ပါတယ်။
Scrum Team က flat level ဖြစ်ပါတယ်။ product owner က ရာထူး ပိုကြီးတယ်။ Scrum Master က ရာထူး ပိုမြင့်တယ် မရှိပါဘူး။ အကုန် အတူတူပဲလို့ သတ်မှတ်ပါတယ်။
Scrum Events
Scrum Event များအားလုံးသည် အချိန် သတ်မှတ်ချက် (time boxed) ရှိပါသည်။ Scrum Events တွေ ဟာ ပုံမှန် လုပ်နေကျ အစည်းအဝေး များ ဖြစ်ပြီး Inspection နှင့် Adaption ပြုလုပ်ရန် အခွင့်အလမ်းများကို ဖန်တီးပေးပါတယ်။
The Sprint (Sprint)
Sprint ဆိုတာကတော့ အချိန်ကန့်သတ်ထားသည့် (time-boxed) ကာလ တစ်ခု ပါ။ ပုံမှန်အားဖြင့် အနည်းဆုံး ၁ ပတ် မှအများဆုံး ၄ ပတ် အတွင်း သတ်မှတ်ပါတယ်။ ထိုကာလ အတွင်း “Done” ဖြစ်သည့် အသုံးပြုနိုင်သည့် Increment တစ်ခု ကို တည်ဆောက်ရပါတယ်။ ပုံမှန် အားဖြင့် Sprint တစ်ခု ကို ၂ ပတ် ကြပါတယ်။ Defination Of Done ကို မဖြစ်မနေ သတ်မှတ် ဖို့ လိုပါတယ်။ “Done” ဖြစ်တယ် ဆိုတာ ဘာလဲ။ ဥပမာ Test တွေ အကုန်လုပ်ထားရမယ်။ Unit Testing ပါရမယ်။ တကယ်အလုပ်လုပ်သည့် feature ဖြစ်ဖို့ လိုပါတယ်။
Sprint တစ်ခု ပြီးဆုံးသည်နှင့် နောက် Sprint တစ်ခု ကို ချက်ချင်း ပြန်စဖို့ လိုအပ်ပါတယ်။
ကျန်ရှိသည့် Event ၄ ခု စလုံး ဟာ Sprint အတွင်းသာ ကျင်းပ ပါတယ်။
**
**
**
**
Sprint Planning
Sprint တစ်ခု အစ တွင် ပြုလုပ်ရပါသည်။ Scrum Team တစ်ခုလုံး စုဝေးပြီး “ဒီ Sprint မှာ ဘာတွေ လုပ်ကြမလဲ” နှင့် “အဲဒါတွေကို ဘယ်လိုလုပ်ရမလဲ” (What & How) ကို ဆွေးနွေး တိုင်ပင်ကြပါတယ်။ Product Owner က Product Backlog မှ ဦးစားပေး များကို ရှင်းပြပြီး Developer တွေက ထိုအလုပ်များထဲမှ မိမိ တို့ ပြီးစီးနိုင်မည်လို့ ယုံကြည်သည့် အလုပ်များကို ရွေးချယ်ကာ Sprint Backlog ကို တည်ဆောက်ပါတယ်။
Sprint Planning ကို ၁ လ စာ Sprint အတွက် အများဆုံး ၈ နာရီ အချိန် သတ်မှတ်ပါတယ်။
Daily Scrum
Daily Stand Up လို့လည်း ခေါ်ကြပါတယ်။ နေ့စဥ် သတ်မှတ်ထားသည့် အချိန် နှင့် နေရာမှာ ပြုလုပ်ပြီး ၁၅ မိနစ် ကြာ အစည်းအဝေး လုပ်ရပါတယ်။ Developer အဖွဲ့ အတွက်သာ ဖြစ်ပါတယ်။ Scrum Master က အဆင်ပြေအောင် ကူညီပေးနိုင်သော်လည်း Developer များ ၏ အစည်းအဝေး ဖြစ်ပါတယ်။ အဓိက ရည်ရွယ်ချက်မှာ Sprint Goal အတွက် ဖြစ်ပြီး လက်ရှိ တိုးတက်မှု အခြေအနေ နှင့် ဆက်ပြီး လုပ်ဆောင်ရန် အခြေအနေ များကို ဆွေးနွေးဖို့ပါ။ Daily Scrum ကို အချိန် နေရာ ကို မရွေ့ပဲ နေ့စဥ် ပုံမှန် လုပ်ဖို့ အရေးကြီးပါတယ်။
Sprint Review
Sprint ပြီးဆုံး ချိန်မှာ ပြုလုပ်ပါသည်။ Scrum Team အနေနဲ့ တည်ဆောက် ပြီးစီး ခဲ့သည့် Increment ကို သက်ဆိုင်သူ Stakeholders ကို demo ပြရပါတယ်။ ဒါကြောင့် Increment ဆိုတာ တကယ် အလုပ်လုပ်သည့် အစိတ်အပိုင်း ဖြစ်နေဖို့ လိုအပ်တာပါ။ Stakeholder တွေက product ကို စစ်ဆေးပြီး Feedback များ ပေးပါတယ်။ ရလာသည့် Feedback တွေကို product backlog မှာ ပြန်ထည့်ပြီး ပြန်လည် ညှိနှိုင်းပါသည်။
Sprint Retrospective
Sprint တစ်ခု ၏ နောက်ဆုံး ပြုလုပ်သည့် Event ဖြစ်ပါသည်။ Sprint Review ပြီး နောက် နှင့် နောက် ထပ် Sprint အသစ် မစခင် မှာ လုပ်သည့် Event ပါ။ Scrum Team တစ်ခုလုံး (Product Owner, Scrum Master, Developers) ပါဝင် ပြီး ပြီးခဲ့သည့် Sprint ကို ပြန်လည် သုံးသပ်ပါတယ်။ ဘာတွေ အဆင်ပြေခဲ့လဲ။ ဘာတွေ အဆင်မပြေဘူးလဲ။ ဘာပြဿနာတွေ ရှိခဲ့လဲ။ နောက် Sprint မှာ ဘာတွေ ပို ကောင်းအောင် လုပ်မလဲ ဆိုတာ ကို ဆွေးနွေးပြီး နောက် Sprint မှာ ပိုကောင်းအောင် လုပ်ဖို့ အစီအစဥ် များကို ချမှတ် လုပ်ဆောင်ပါတယ်။
Scrum Artifacts
Product Backlog
Product အတွက် လိုအပ်သော feature များ function များ ပြင်ဆင်ရန် လိုအပ်ချက်များ bugs များ အားလုံး ကီု ဦးစာပေး အလိုက် စီထားသော စာရင်း ဖြစ်သည်။ Product Owner က စာရင်း ကို တာဝန်ယူပြီး အမြဲတမ်း ပြောင်းလဲ နိုင်သော dynamic artifact တစ်ခု ဖြစ်သည်။
Sprint Backlog
Sprint တစ်ခု အတွင်း ပြီးမြောက်အောင် လုပ်ဆောင်ရန် အတွက် Developer များက Product Backlog မှာ ရွေးထားသော item များ စာရင်း ဖြစ်သည်။ တနည်းဆိုရလျှင် လက်ရှိ Sprint တွင် လုပ်ဆောင်မည့် tasks များ ဖြစ်ပါသည်။ ဒီ Sprint Backlog ကို Developer များက manage လုပ်ပြီး Track လုပ်ရန် အသုံးပြုပါသည်။
Increment
Sprint တစ်ခု အတွင်း ပြီးစီးသည်ဟု သတ်မှတ်ထားသည့် Product Backlog items အားလုံး၏ စုစုပေါင်း ရလဒ် ဖြစ်ပါတယ်။ ဒီနေရမှာ Task တစ်ခု က increment တစ်ခု မဟုတ်ပါဘူး။ Task ၃ ခု ပြီးမှ တကယ်အလုပ်လုပ်သည့် Increment တစ်ခု ရတာလည်း ဖြစ်နိုင်ပါတယ်။ Increment က တကယ် အလုပ်လုပ်သည့် feature ဖြစ်ဖို့ လိုပါတယ်။
ဥပမာ ဘီး ဖန်တီးတာက Task 1 , ကား အတွင်း ပိုင်း ဖန်တီးတာက Task 2 , ကားကိုယ်ထည် ဖန်တီး တာ က Task 3 ဖြစ်ပြီး အကုန်ပေါင်းလိုက်မှ ကား တစ်စီး , increment တစ်ခု ရလာတာကို ဆိုလို တာပါ။
Time-box
| Scrum Event | Maximum Time-Box | မှတ်ချက် |
| The Sprint | အများဆုံး ၁ လ ၊ ပုံမှန် ၂ ပတ် | Event များအားလုံး ပါဝင်သည်။ |
| Sprint Planning | အများဆုံး ၈ နာရီ ( ၁ လ စာ Sprint အတွက်) | Sprint အတွင်း ဘာလုပ်မည် ဘယ်လိုလုပ်မည် ကို အစီအစဥ် ဆွဲသည် |
| Daily Scrum | အများဆုံး ၁၅ မိနစ် | နေ့စဥ် တိုးတက်မှု ကို စစ်ဆေးပြီး လုပ်ဆောင်ရန် များကို ညှိနှိုင်းရန် |
| Sprint Review | အများဆုံး ၄ နာရီ ( ၁ လစာ Sprint အတွက်) | ပြီးခဲ့သည့် Increment ကို ပြပြီး Feedback ရယူ |
| Sprint Retrospective | အများဆုံး ၃ နာရီ (၁ လ Sprint အတွက်) | ပြီးခဲ့သည့် Sprint လုပ်ငန်းစဥ် ကို ပြန်လည် ဆင်ခြင် သုံးသပ်ရန် |
Life Cycle
၃.၃ Kanban (Development)
Kanban (看板) ဆိုတာ ဂျပန် စကားလုံး ဖြစ်ပြီး ဆိုင်းဘုတ် လို့ အဓိပ္ပာယ် ရပါတယ်။ Software Development မှာ သုံးသည့် Kanban ကတော့ အလုပ်တွေ ကို စီမံခန့် ခွဲပြီး လုပ်ငန်းစဥ် တွေ ကို တိုးတက်အောင် လုပ်ဖို့ အသုံးပြုသည့် Lean နည်းလမ်း တစ်ခု ဖြစ်ပါတယ်။
ဒီနည်းလမ်းကို မူလ Toyota compapny ရဲ့ Toyota Production System (TPS) မှာ ထုတ်ကုန် လုပ်ငန်းစဥ် တွေကို အလေအလွင့် မရှိစေပဲ အကောင်းဆုံး ဖြစ်အောင် စီမံဖို့ တီထွင်ခဲ့တာပါ။ နောက်ပိုင်း ဒီ အယူအဆ ကို Software Development အပါအဝင် လုပ်ငန်း အတော်အတော်များများ မှာ ပြန်လည် အသုံးချလာကြပါတယ်။
Kanban Board
Kanban ရဲ့ အဓိက အပိုင်းကတော့ Kanban Board ဖြစ်ပါတယ်။
Columns များမှာ Todo, Doing , Review , Done တို့ကို ပါဝင် ပြီး လက်ရှိ လုပ်ဆောင် ဖြတ်သန်းနေသည့် အဆင့် ကို ဖော်ပြထားပါတယ်။
Cards များ ကတော့ Task တစ်ခု စီ ကို ကိုယ်စား ပြုပါတယ်။
Kanban ရဲ့ Workflow ကတော့ Card တွေကို ဘယ် ဘက် ကနေ ညာဘက် Column ဆီ အလုပ်တစ်ခု ပြီးသွားတိုင်း ရွှေ့သွားရပါတယ်။
Kanban Core Principle
Kanban method မှာ အဓိက မူဝါဒ ၆ ချက်ရှိ ပါတယ်။
Visualize Work
အလုပ်အားလုံး ကို Kanban Board ပေါ်မှာ Card တွေ ဖြင့် ပြထားသည့်။ အတွက် ကြောင့် ဘယ်သူ ဘာလုပ်နေလဲ ဘယ်အဆင့် ရောက်နေပြီလဲ ဆိုတာကို ရှင်းရှင်း လင်းလင်း မြင်နိုင်ပါတယ်။
Limit Work in Progress (WIP)
ဒါဟာ Kanban ရဲ့ အရေးကြီး ဆုံး အချက်ဖြစ်ပါတယ်။ Doing / In Progress အဆင့်မှာ တချိန်တည်းမှာ ရှိနိုင်သည့် အလုပ် card အရေအတွက် ကို ကန့်သတ်ထားတာပါ။ In Progress အဆင့် မှာ WIP Limit ကို ၃ လို့ သတ်မှတ်ထားရင် developer တွေ က အလုပ် ၃ ခု အများဆုံး တစ်ပြိုင်တည်း လုပ်ဆောင်နိုင်ပေမယ့် နောက်ထပ် အလုပ်အသစ် တစ်ခု ထပ် စ ခွင့်မရှိသည့် သဘောပါ။ တနည်းပြောရင် အဖွဲ့ဝင် တွေ မှာ အလုပ်တွေ မပိ သွားစေဖို့ အတွက်ပါ။
Manage Flow
အလုပ်တွေ ဘုတ်ပေါ်မှာ ဘယ်လို ချောချောမွေ့မွေ့ စီးဆင်းနေသလဲ ဆိုတာကို စောင့်ကြည့်တိုင်းတာ ရပါတယ်။ Bottlenecks တွေကို ရှာဖွေပြီး ဖြေရှင်း ရပါတယ်။
Make Policies Explicit
အလုပ်တစ်ခု ပြီးစီး တယ် ဆိုတာ ဘယ် အချိန် မှာ သတ်မှတ်မလဲ။ တနည်းပြောရင် Definition of Done ကို သတ်မှတ်ခြင်းပါ။ WIP Limit ကို ဘယ်လောက် သတ်မှတ်မလဲ။ အရေးပေါ် အလုပ်ဝင်လာရင် ဘယ်လို ကိုင်တွယ် မလဲ စသည့် စည်းမျဥ်း စည်းကမ်း တွေကို လူတိုင်း နားလည်အောင် ရှင်းရှင်း လင်းလင်း သတ်မှတ် ထားရပါမယ်။
Implement Feedback Loops
လုပ်ငန်းစဥ် နဲ့ ပတ်သက်ပြီး အဖွဲ့လိုက် ပြန်လည်သုံးသပ်သည့် အစည်းအဝေးတွေ (Stand Up meeting, Review meeting) ကို ပုံမှန် လုပ်ဆောင်ရပါမယ်။
Improve Collaboratively
Kanban မှာ ပွင့်လင်းမြင်သာမှု ရှိပြီး လက်ရှိ လုပ်ငန်းစဥ်ကနေ စတင်ပြီး တဖြည်းဖြည်း စမ်းသပ် တိုးတက်အောင် လုပ်ဆောင်သွားရသည့် နည်းလမ်း ဖြစ်ပါတယ်။
၃.၄ Kanban နှင့် Scrum ကွာခြားချက်
Kaban ဟာ Continue Flow သွားပါတယ်။ Scrum ကတော့ iterative ပါ။ Scrum ရဲ့ လုပ်ငန်းစဥ် တွေ ဟာ ရှုပ်ထွေးပါတယ်။ Time boxing , Sprints စသည့် အပိုင်းအခြား တွေ ပါဝင်တယ်။ Kanban မှာတော့ WIP (Work In Progress) အရေအတွက် ကိုပဲ ကန့်သတ်ထားပါတယ်။ Scrum မှာ Roles တွေ ရှိပြီး Kanban မှာ Role တွေ မရှိပါဘူး။ Kanban က WIP limit မကျော်ရင် ကြိုက်သည့် tasks ကို ချက်ခြင်း ကောက်လုပ်လို့ ရပေမယ့် Scrum ကတော့ ကြိုတင်ပြင်ထားသည့် Sprint Backlog က tasks တွေကို ပဲ priority အရ လုပ်ဆောင်ရပါတယ်။
၃.၅ အသုံးချ Software များ
Scrum အတွက် အသုံးများသည့် Software တွေကတော့
စတာတွေ ရှိပါတယ်။ တကယ့် Scrum Framework အတိုင်း လိုက်နာထားတာ မဟုတ်ပဲ kanban လိုမျိုး Column style work flow နဲ့ တွဲ သုံးကြတာများပါတယ်။ တကယ်တန်း အသုံးများတာကတော့ Jira ပါ။ Software Engineering တစ်ယောက် အနေနဲ့ Jira ကို ကောင်းမွန်စွာ သုံးသပ်နိုင်ဖို့ လည်း လိုအပ်တယ် လို့ မြင်ပါတယ်။
Kanban အတွက်ကတော့
- Trello
- Asana
- Monday
- Github Project
စတာတွေ ရှိပါတယ်။ Trello ကတော့ အရိုးအရှင်း ဆုံး နဲ့ လွယ်လင့် တကူ အသုံးပြုနိုင်ပါတယ်။ Kanban ကို sticky note နဲ့လည်း physcially white board မှာ ဆွဲပြီး အလုပ်လုပ်ကြတာတွေလည်း ရှိပါတယ်။
Jira ဟာ စသုံးကာစ မှာ ရှုပ်ထွေးပေမယ့် Scrum ကို နားလည် သည့် အခါမှာ အသုံးပြုရတာ ပိုမို လွယ်ကူ တာ ကို တွေ့ရမှာပါ။ နောက်တစ်ချက်က SCRUM မှာ Epic , Milestone စတာတွေ မပါဝင်ပေမယ့် လက်တွေ့မှာ အသုံးပြုကြတာ များပါတယ်။ တနည်းပြောရင် increment (တကယ် အလုပ်လုပ်သည့် feature) တစ်ခု အနေနနဲ့ အသုံးပြုကြတာ ရှိသလို version အနေနဲ့လည်း အသုံးပြုကြတာ ရှိပါတယ်။