Agile Samurai

Agile Samurai

လိုင္ဘရီမွာ စာအုပ္ေကာင္းေလးေတြရခဲတတ္ပါတယ္။ လုငွားေနလို႕ပါ။

ဒီတစ္ခါေတာ႔ အရင္က Funan စာအုပ္ဆိုင္မွာျမည္းခဲ႔တဲ႔ Agile Samurai စာအုပ္ရလာပါတယ္။

Software Engineering ဟာ တခါတေလၾကရင္ ခန္႕မွန္းလုိ႕မရတာေတြကို ခန္႕မွန္းၾကရတာပဲ။

တစ္မိနစ္မွာ မုန္႕ ႏွစ္ခုစားႏိုင္ရင္ ႏွစ္မိနစ္မွာ မုန္႕ ေလးခု ေပါ႔။

ဒါေပမယ္႔ ၂၄ နာရီဆိုရင္ေရာ ဘယ္လိုေျဖမလဲ။ ဆတိုးက အျမဲမမွန္ပါဘူး။

ဆယ္တန္းေျဖျပီးစတုန္းက အဂၤလိပ္တစ္ေယာက္က ကြ်န္ေတာ္တို႕ကို အခ်ိန္ပိုင္း အဂၤလိပ္စာသင္ေတာ႔။ တစ္ခုေမးတယ္။ မင္းတုိ႕ႏိုင္ငံမွာ ဆိုက္ကားခနဲ႕ ကားခ ဘယ္ဟာေစ်းေပါလဲဆိုေတာ႔၊ ၀မ္းသာအားရ ဆုိက္ကားက ေပါတာေပါ႔ကြ လို႕ေျဖလုိက္တယ္။ သူက ေမးတယ္။ ပဲခူးအထိသြားရင္ ဆုိက္ကားခ ဘယ္ေလာက္က်မလဲတဲ႔။

အဲဒါကို ငယ္ကတည္းက စြဲျမဲေနေအာင္မွတ္မိတယ္။ ေမးခြန္းရဲ႕ ဆန္႕ထြက္သြားတတ္တဲ႔သေဘာကိုသိရင္ project timeline ရဲ႕ unexpected result ေတြကိုလည္း နားလည္ႏိုင္ပါတယ္။ real world မွာ black and white သဲကြဲတာမရိွပါဘူး။ ဒီလိုပဲ မီးစင္ၾကည္႕ကရတာပါပဲ။

အလြယ္ဆံုး mandays တြက္နည္းက ကိုယ္တစ္ရက္ လုပ္ႏုိင္မယ္ထင္ရင္ 1.33 နဲ႕ေျမွာက္။ ၃၃ % ကို buffer လုပ္ထား။ အဲဒါဆိုရင္ ၁ ရက္ခြဲေလာက္လုိ႕ ေျပာလုိ႕ရတယ္။ ဒါကလည္း အျမဲမွန္မွာေတာ႔မဟုတ္ဘူး။ General ေျပာၾက၊ တြက္ၾကရတာပါ။

ဒီစာအုပ္ကိုေတာ႔ recommend လုပ္ပါတယ္။ Agile ၀ါသနာပါရင္ ေလ႔လာသင္႔ပါတယ္။

Agile အေၾကာင္း သိပ္မေျပာျဖစ္ေပမယ္႔ သေဘာအက်ဆံုး development architecture ျဖစ္ပါတယ္။ အဓိက သံုးမ်ိဳးခြဲျပီးေျပာေလ႔ရိွပါတယ္။ Traditional, Agile and Extreme ပါ။

Traditional ေတြကေတာ႔ ေက်ာင္းမွာအေတာ္ေလးသင္ျပီးပါျပီ။ မွတ္မိမလားေတာ႔မသိပါဘူး။ sequential ေတြ၊ spiral ေတြ waterfall ေတြေလ။ အဲဒါေတြရဲ႕အားနည္းခ်က္က requirement gathering phase ျပီးရင္ users ကို ေတြ႕ခ်င္ေတာ႔ဘူး။ေတြ႕ခ်င္ေတာ႔ဘူး ျငင္းတာပါ။ အဲဒါက အဓိက က်ဆံုးခန္းပါပဲ။

Customers လိုခ်င္တာ ကြ်န္ေတာ္တို႕ software သမားေတြ တကယ္သိတာ ရွားပါတယ္။ သိတယ္လို႕ထင္တာနဲ႕ သိခ်င္ေယာင္ေဆာင္တာပဲမ်ားပါတယ္။ တကယ္သိဖို႕ဆိုတာ အခ်ိန္အမ်ားၾကီးေပးရပါတယ္။ Business logic ေတြအရ ကြ်န္ေတာ္တုိ႕ မထင္တာေတြ အမ်ားၾကီးရိွတတ္ပါတယ္။ အဲဒါကို တခါတည္းေမးျပီး တခါတည္းသေဘာအေပါက္ၾကီးေပါက္သြားတယ္ဆိုတာ စိတ္ကူးယဥ္တာပါ။ အထူးသျဖင္႔ စင္ကာပူမွာ စိတ္ကူးယဥ္ေတြ သိပ္မ်ားပါတယ္။

System တစ္ခုကို အထိေရာက္ဆံုးျဖစ္ဖုိ႕ Development Phase ေတြမွာ Users ေတြကို အဆင္႔တုိင္း ပါ၀င္ေစတာဟာ အေကာင္းဆံုးပါပဲ။ ဒါကို မင္းလိုခ်င္တာ ဒီအတုိင္းလားဆိုျပီး အပတ္တုိင္းေမးေနရင္၊ Project ျပီးသြားမွ တလြဲၾကီးျဖစ္ရတာတို႕ မလိုအပ္ပဲ CR(Change Request) လုပ္ရတာနည္းသြားပါတယ္။ အဆင္႔တုိင္းမွာ business flow အားျဖင္႔လည္း စိတ္တုိင္းက် ျဖစ္သြားေစပါတယ္။ ပိုေကာင္းတာတစ္ခုက Users ေတြရဲ႕ ယံုၾကည္မႈကိုတည္ေဆာက္ႏိုင္တာျဖစ္ပါတယ္။ အခက္အခဲကေတာ႔ စနစ္က်ျပီး ညီညြတ္တဲ႔ team လိုအပ္တာပါ။ အဲဒါေတြက Agile သေဘာတရား တစ္ခ်ိဳ႕ပါပဲ။ အရွင္းဆံုးေျပာရရင္ Users နဲ႕ေပါင္းျပီး testing ကို phase တိုင္းမွာ ထည္႕သြားတာပါပဲ။ အဲဒီလို architecture မ်ိဳးကို Agile လို႕ေခၚတြင္ေလသတည္းေပါ႔ဗ်ာ။

Notes:

Thank you my office for letting me read @ ()ffice(-)ours :P