အခန်း ၁၂ :: Project စတင်ခြင်း
Project တစ်ခု စပြီ ဆိုရင် ဘာတွေ လုပ်ရမလဲ။ ဘာတွေ ပြင်ရမလဲ ဆိုတာကို စလုပ်ခါစ Project Manager တွေ အတွက် ခေါင်းစားပါတယ်။ Project တစ်ခု စပြီဆိုရင် အရင်ဆုံး ကျွန်တော်တို့ လိုအပ်တာက overall system design ပါ။
- User Stories
- Use Case Diagram (System Flow)
- ERD
- Backlog
- Sprint
စတာတွေကို ပြင်ဖို့ လိုပါတယ်။ Scrum ကို အခြေခံထားပေမယ့် team တော်တော်များများဟာ Scurm အတိုင်း အပြည့်အဝ မ run နိုင်ပါဘူး။ အများအားဖြင့် ပြည်တွင်းမှာ Kaban board နဲ့ သွားကြတာ များပါတယ်။ ဒီစာအုပ်ဟာ Scrum စာအုပ် မဟုတ်သည့် အတွက်ကြောင့် အသေးစိတ်တော့ မရေးထားပါဘူး။ လုပ်ငန်းခွင်မှာ ဘယ်လို အလုပ်လုပ်နေကြတယ် ဆိုတာ သိလောက်အောင်ပဲ ဖြည့်စွက်ရေးထားပါတယ်။
+++
User Stories
Project စတော့မယ် ဆိုရင် အသုံးပြုမယ့်သူတွေ ဘယ်လို အသုံးပြုမလဲ။ ဘယ်လို အသုံးပြုရင် လွယ်မလဲ ဆိုတာကို စပြီး လေ့လာကြပါတယ်။ ဥပမာ Musica App ကို လုပ်ပြီ ဆိုပါဆို့။ ဘယ်အချက်တွေကို ကြည့်ပြီး user က သီချင်း နားထောင်မလဲ ? User တစ်ယောက် သီချင်း တစ်ပုဒ်ကို နားထောင်ဖို့ ဘယ်လို လမ်းကြောင်းတွေ ရှိပြီး ဘယ်လို လုပ်ရင် ရနိုင်မလဲ။
Payment အတွက်ကကော User stories ဘယ်လို ရှိမလဲ။ ဘယ်အချိန် ရောက်ရင် User က ငွေပေးမလဲ။ ငွေပေးဖို့ အဆင့်တွေကတော့ ဘယ်နှစ်ဆင့်လောက် ရှိလဲ။ ငွေပေးပြီးရင် ဘယ်လိုဖြစ်သွားမလဲ။
အချက်အလက်များစွာပေါ်မှာ မူတည်ပြီး User stories ကို တည်ဆောက်ပါတယ်။ Proposal မှာ လုပ်ထားသည့် အချက်အလက်တွေ နဲ့ ကွဲပြားနိုင်တယ်။ proposal wireframe က အပိုင်းနဲ့ မတူတာတွေကို Product owner နဲ့ ညှိဖို့ လိုတယ်။ ဘယ်အချက်တွေ က ပြောင်းသွားတယ်။ ဘယ်အချက်တွေ သဘောတူတယ် မတူဘူး ဆိုပြီး ပြန်ညှိရပါတယ်။
Use Case Diagram (System Flow)
Use Case Diagram ဟာ team ကို လက်ရှိ လုပ်မယ့် project အတွက် ရှင်းပြလို့ရသည့် အလွယ်ဆုံး diagram ပါပဲ။
Use Case Diagram ကို Computer Science နဲ့ ဘွဲ့ ရထားသည့် ကျောင်းသား တော်တော်များများ ဆွဲ တတ်ပါတယ်။ Unified Modeling Language (UML) သင်သည့် အထဲမှာ Use Case ကိုလည်း ထည့်သင်ပါတယ်။ Computer Science နဲ့ ဘွဲ့ ရထားခဲ့ပြီးရင် Class Diagram, Use Case Diagram, Flow Chart တွေ သိထားပြီးလို့ မှတ်ယူလို့ ရပါတယ်။ အကယ်၍ စာဖတ်သူဟာ Computer တက္ကသိုလ် တစ်ခုခုက ဘွဲ့ရထားခဲ့ပြီး အထက်ပါ diagram တွေ မဆွဲတတ်သေးရင်တော့ ပြန်လေ့လာဖို့ လိုအပ်ပါတယ်။
နောက်အရေးကြီးသည့် အချက်ဟာ document တွေကို သေချာ version ခွဲပြီး သိမ်းထားဖို့ လိုပါတယ်။ မြန်မာနိုင်ငံမှာ ရှိသည့် project manager တွေက လိုအပ်မှသာ email တွေ ထဲမှာ ပြန်ရှာတတ်ပါတယ်။ version အလိုက်ခွဲပြီး file တွေကို သိမ်းထားသည့် အကျင့်ကို လုပ်ထားဖို့ လိုပါတယ်။ ဒါမှသာ developer က flow များသွားရင် သူ့ version နဲ့ ကိုယ့် version မတူတာလား။ ကိုယ်ပြောဖို့ ကျန်ခဲ့တာလည်း စတာတွေကို စီစစ်နိုင်မှာပါ။
Entity Relationship Diagram (ERD)
ERD ကတော့ Project ကို lead လုပ်မယ့် lead developer တွေ ဆွဲကြတာ များပါတယ်။ database ကို ဘယ်လို design ထားသင့်တယ်။ ဘယ် table တွေ လိုအပ်တယ်။ အချို့ data တွေက table ခွဲထုတ်လို့ရပေမယ့် flat ထားသင့်အခါ ထားတာတွေ လည်း ရှိပါတယ်။ ERD diagram ကို ဆွဲလိုက်ခြင်းအားဖြင့် လက်ရှိ project မှာ ပါဝင်ရမယ့် model တွေ ကို ရှင်းလင်းစွာ မြင်စေပါတယ်။
Team အနေနဲ့လည်း ဘယ် class တွေကို ဖန်တီးသင့်တယ် API design ဘယ်လို ချရမလဲဆိုတာကို ERD ပေါ်မှာ မူတည်ပြီး ဆုံးဖြတ်နိုင်ပါလိမ့်မယ်။ နောက်တချက် သတိထားသင့်တာကတော့ ERD diagram က development လုပ်နေရင်း ပြောင်းလဲ သွားနိုင်ပါတယ်။ တကယ့် plan အတိုင်း မဟုတ်ပဲ sprint တစ်ခု မှာ changes ရှိခဲ့ရင် ပြောင်းလဲ မှုတွေ ဖြစ်နိုင်ပါတယ်။ ဖြစ်နိုင်ရင်တော့ diagram တွေကို version ခွဲပြီး သိမ်းထားရင် အကောင်းဆုံးပါပဲ။
Backlog
ဘာမှ မစခင်မှာ test တွေ အကုန်လုံးကို backlog ထဲကို ထည့်ထားပါ။ ပြီးမှ သက်ဆိုင်ရာ developer ကို assign ချဖို့ လိုပါတယ်။ Backlog မှာ တစ်ခါတည်း estimate task duration ပါ ထည့်ပြီး သတ်မှတ်ထားဖို့ လိုပါတယ်။
Sprint
Backlog တွေ ရရင် actual timeline ကို ရပါပြီ။ လူ ဘယ်နှစ်ယောက် တကယ် သုံးရမယ်။ အချိန် ဘယ်လောက် ကြာမလဲ ဆိုတာ ထွက်လာပါပြီ။ အဲဒီ အခါမှာ estimate လုပ်ပြီး project proposal timeline နဲ့ ကိုက်မကိုက် ကြည့်ရပါတယ်။ မကိုက်ခဲ့ရင် ပြန်ညှိတာတွေ လုပ်ဖို့ လိုတယ်။
နောက်တချက်က အခု project မှာ ပါသည့် developer တွေဟာ အကြောင်းကြောင်းကြောင့် sprint တစ်ခုမှ မပါသည့် အခါ မှာ timeline တွေနောက်ကျနိုင်တယ်။ အဲဒီ အတွက်ပါ ဘယ် လောက် နောက်ကျလို့ ရသည် အထိ ထည့်စဥ်းစားဖို့ လိုတယ်။
Sprint တွေကို ခွဲလိုက်ရင် စုစုပေါင်း ဘယ်နှစ်ပတ် အတွင်း ပြီးမယ် ဆိုတာ ထွက်လာပါမယ်။ ဒါဆိုရင်တော့ project စလို့ ရပါပြီ။ Sprint ခွဲသည့် အခါမှာ work done ကို acual test နဲ့ တွက်ရပါတယ်။ Sprint တစ်ခု ပြီးသွားတယ် ဘာမှ လုပ်မရသေးဘူး ဆိုရင် Sprint ခွဲတာ လွဲနေပါပြီ။ ဥပမာ Sprint 1 ပြီးသွားရင် user login ဝင်ပြီး home screen တွေ ကြည့်လို့ရပြီ။ backend မှာ user တွေ manage လုပ်လို့ရပြီ။ စသည် ဖြင့် acual sprint goal ထားဖို့ လိုပါတယ်။
Agile နှင့် timeline ပြဿနာ
Agile မှာ sprint ခွဲလိုက်ပေမယ့် sprint တစ်ခု ပြီးသွားဖို့ အတော့်ကို ခက်ပါတယ်။ Product owner က sprint ပြီးသည့် အခါမှာ ကြည့်ပြီး design ပြောင်းချင်တာ ပြင်ချင်တာ တွေ ရှိလာနိုင်ပါတယ်။ တစ်ခါတစ်လေ လုပ်ထားသည့် feature တစ်ခု လုံး ဖြုတ်ချပြီး feature နောက်တစ်ခု ထပ်ဖြည့်တာတွေ လုပ်တတ်ပါတယ်။ တစ်ခါတစ်လေ bug တွေ အများကြီး ထွက်လာတာ။ ပြောထားသည့် flow လွဲနေတာ စသည်ဖြင့် sprint တစ်ခု close မလုပ်နိုင်ပဲ အရမ်းကြာသွားနိုင်တာကို Scrum Master က သိဖို့ လိုအပ်ပြီး ဝင်ညှိနိုင်ဖို့ လိုအပ်ပါတယ်။ Scrum Master တွေဟာ feature တွေ လျော့ချပြီး sprint goal ရောက်အောင် product quality မကျအောင် ထိန်းရပါတယ်။ Feature တွေ ထပ်ဖြည့်လို့ product quality ကျသွားလို့ မဖြစ်ဘူး။ Timeline ပို ကြာသွားလို့ မဖြစ်ဘူး။ Project တစ်ခု မှာ Scrum Master ဟာ အရေးပါပါတယ်။
Project တစ်ခု စင်းလုံးချောပြီးဖို့ ဆိုတာ အတော့်ကို ခက်ပါတယ်။ ဒါကြောင့် အရင်စ ထားပေမယ့် Scrum Master, Product Owner ကြားက ညှိနှိုင်းမှု ၊ team ရဲ့ စွမ်းဆောင်ရည် တွေ ပေါ်မူတည်ပြီး project တစ်ခု အောင်မြင်မမြင် ရလဒ် ထွက်လာပါလိမ့်မယ်။