DevOps အသွင်ပြောင်းခြင်းကို စတင်နည်း

DevOps ဆိုသည်မှာ နားမလည်ပါက၊ ဤတွင် အမြန်လိမ်လည်မှုစာရွက်။ DevOps သည် ကျင့်ထုံးအစုတစ်ခုဖြစ်သည်။ အင်ဂျင်နီယာများ၏ ကြောက်ရွံ့မှုကို လျှော့ချပေးသည်။ ဆော့ဖ်ဝဲလ်ထုတ်လုပ်မှုတွင် ကျရှုံးမှုအရေအတွက်ကို လျှော့ချပါ။ စည်းကမ်းအရ၊ သူတို့က အတူတူပါပဲ။ စျေးကွက်အတွက်အချိန်ကိုလျှော့ချ - အကြံဥာဏ်မှ နောက်ဆုံးထုတ်ကုန်ကို ဖောက်သည်များထံ အရောက်ပို့ချိန်အထိ၊ သင်မြန်မြန်ဆန်ဆန်ဆောင်ရွက်နိုင်မည့် ကာလ စီးပွားရေးစမ်းသပ်မှုများ.

DevOps အသွင်ပြောင်းခြင်းကို မည်သို့စတင်ရမည်နည်း။ အတိုချုပ်အားဖြင့်- ကျွန်ုပ်တို့သည် လုပ်ငန်းစဉ်ကိုစတင်ရန်၊ ဝန်ဆောင်မှုနှင့်သက်ဆိုင်သူများကို ခွဲခြားသတ်မှတ်ရန်၊ Value Stream Map တစ်ခုတည်ဆောက်ရန်၊ အသွင်ပြောင်းခြင်းကို ပထမဆုံးအကြိမ်အဖြစ် ကိုင်တွယ်ဖြေရှင်းမည့် ယာယီအဖွဲ့ကို ဖန်တီးပြီး ၎င်းအတွက် အလုပ်တစ်ခုသတ်မှတ်ပေးမည့် ဝန်ဆောင်မှုကို ရွေးချယ်ပါ။ ကျွန်ုပ်တို့သည် လိုအပ်သောအကြိမ်အရေအတွက်အတိုင်း စက်ဝန်းကိုပြန်လုပ်ပါသည်။

ဖြတ်တောက်မှုအောက်တွင် နမူနာများနှင့် လမ်းညွှန်ချက်များပါရှိသော DevOps အသွင်ပြောင်းမှု အစီအစဉ်အသေးစိတ် - စာသားမှတ်တမ်း အစီရင်ခံစာ Andrey Alexandrov - DevOps အပင်ပေါက်ခြင်းကို အကြံပေးသည့် Express42 မှ အင်ဂျင်နီယာတစ်ဦး၊ သူမသည် ထွန်ခြစ်မြေပုံကို တည်ဆောက်ပြီးဖြစ်သောကြောင့် ဤလုပ်ငန်းစဉ်ကို အရှိန်မြှင့်လိုက်သည်။ သင်သည် အသွင်ပြောင်းရန် မလိုအပ်ဘဲ သို့မဟုတ် DevOps အလေ့အကျင့်များသည် မသင့်လျော်ဟု ထင်ပါက၊ ကန့်သတ်ချက်များကို ရှာဖွေရန်နှင့် ဖယ်ရှားရန်အတွက် ညွှန်ကြားချက်အဖြစ် အစီရင်ခံစာကို အသုံးပြုပါ။

DevOps အသွင်ပြောင်းခြင်းဆိုင်ရာ ပြဿနာကို သင်စိုးရိမ်နေပါက သင့်တွင် ကုမ္ပဏီကြီးတစ်ခုရှိပြီး၊ တည်ဆောက်မှုတစ်ခုလုံးတွင် ဤလုပ်ငန်းစဉ်ကို ဖြည်းဖြည်းချင်း ချဲ့ထွင်ရန် လိုအပ်ပါသည်။ အမိန့်ကို ပြောင်းလဲရန် သို့မဟုတ် ကန့်သတ်ချက်အချို့ကို ဖယ်ရှားရန် လိုအပ်သရွေ့၊ အောက်ပါ အယ်လဂိုရီသမ်ကို ထပ်ခါတလဲလဲ ပြုလုပ်နိုင်ပါသည်။

ဝန်ဆောင်မှုတစ်ခုရွေးချယ်ခြင်း။

ကျွန်ုပ်တို့သည် အစီအစဉ်တစ်ခုကို ရေးဆွဲထားပြီး၊ ဝန်ဆောင်မှုကို ရွေးချယ်ရာတွင် ပထမအဆင့်ဖြင့် စတင်ကြပါစို့။ ပထမစံသတ်မှတ်ချက်မှာ တစ်သက်တာဖြစ်သည်။: ဝန်ဆောင်မှုအဟောင်းများ - အမွေအနှစ်များ၊ နှင့် အသစ်များရှိပါသည်။ နှစ်မျိုးလုံးဖြင့် စတင်နိုင်ပါသည်။

လူငယ်ဝန်ဆောင်မှုကို ရွေးချယ်ခြင်းသည် ယုတ္တိတန်ပါသည်။. ၎င်းသည် ဆန်းသစ်သည်၊ ၎င်းနှင့် ပတ်သက်သည့် အဖွဲ့တွင် အလုပ်လုပ်ရန် တိကျသော လုပ်ငန်းစဉ် မရှိသေးပါ။ ၎င်းပတ်ပတ်လည်တွင် နည်းပညာဆိုင်ရာကြွေးမြီများ တောင်မရှိပါ၊ သင်သည် ၎င်းကို အချိန်တိုင်းပြုပြင်ရန် မလိုအပ်ပါ။ ငါတို့က အဲဒါနဲ့ ငါတို့လုပ်ချင်တာကို လုပ်နိုင်တယ်။

ဝန်ဆောင်မှုအဟောင်း၏အမှု၌, ထိုအချက်နှင့်ဆက်စပ်သောပြဿနာများရှိပါတယ်။ အပြောင်းအလဲက အမြဲတမ်းခက်ခဲတယ်။. ကြီးလေးသောကန့်သတ်ချက်အချို့ရှိနှင့်ပြီးသားဖြစ်သော်လည်း၊ အရာအားလုံးကို ဂေါ်ပြားလုပ်ရန်အဆင်သင့်ဖြစ်နေသောလူများက ၎င်းတို့ကို ကိုင်တွယ်ဖြေရှင်းနေခြင်းဖြစ်နိုင်သည် - ပင်ပန်းနွမ်းနယ်ပြီး နာကျင်ကိုက်ခဲနေသောကြောင့် တစ်ခုခုကို လုပ်ချင်နေသူများဖြစ်သည်။

ဝန်ဆောင်မှုဟောင်းတစ်ခုနှင့် လုပ်ဆောင်ခြင်းသည် အားကောင်းသော စံနမူနာတစ်ခုဖြစ်သည်။ သင့်ကုမ္ပဏီတွင် - သင်တစ်ခုခုကိုပြောင်းလဲနိုင်သည်။ ဝန်ဆောင်မှုအသစ်တစ်ခုပြောင်းပါက၊ ၎င်းသည် တစ်နာရီလျှင် အကြိမ် 100 ကျဆင်းသွားမည်ဖြစ်ပြီး အရာအားလုံး အဆင်ပြေသွားပါက သင့်ကုမ္ပဏီရှိလူများက ပြောနိုင်သည်-

- ဒါက ဝန်ဆောင်မှုအသစ်ပါ။ အဲဒီမှာ အရာအားလုံးက ရိုးရိုးရှင်းရှင်းပဲ၊ ငါတို့ရဲ့ အပျက်အစီးနဲ့ တစ်ခုခုလုပ်စမ်းပါ။

ဥပမာအားဖြင့် ပြင်ပအတိုင်ပင်ခံတစ်ဦးကို ဖိတ်ခေါ်ပါက တစ်စုံတစ်ဦးနှင့်ပြုလုပ်သောအခါ အသွင်ပြောင်းရန်အတွက် Legacy ဝန်ဆောင်မှုကို အသုံးပြုခြင်းသည် အဓိပ္ပာယ်ရှိစေသည်။ ရိုးရိုးသားသား ပြောရရင် အသွင်ကူးပြောင်းမှုဟာ ဖြစ်နိုင်သမျှ အရာအားလုံးကို တုန်လှုပ်သွားစေလိမ့်မယ်။. သင်သည် စမ်းသပ်နေပြီး မည်သည့်နေရာတွင် ကုန်ဆုံးမည်၊ မည်သည့်နည်းပညာများကို သင်အသုံးပြုမည်၊ မည်သည့်အတွက်ကြောင့်၊ လုပ်ငန်းစဉ်များတွင် မည်သည့်နေရာနှင့် မည်သို့သော ချို့ယွင်းချက်များ ဖြစ်ပေါ်လာမည်ကို သင်မသိပါ။ ထို့ကြောင့် အသစ်တစ်ခုပြောင်းရန် ပိုလွယ်သည်။

သင်ကိုယ်တိုင် အရာရာကို လုပ်ဆောင်ပြီး ကုမ္ပဏီတွင် လေးနက်သော အရည်အချင်းမရှိပါက၊ ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုအသစ်ကို ရယူပါသည်။ ပြင်ပအတိုင်ပင်ခံတစ်ဦးကို သိပြီး ရန်ပုံငွေရှိလျှင် အဟောင်းကို ရွေးချယ်ပါ။

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

ကျွန်တော်လည်း လုပ်တယ်။ အရေးပါသောဝန်ဆောင်မှုနှင့်အတူဒါပေမယ့် အဲဒါကြောင့် ငါတို့ ဒုက္ခရောက်တယ်၊ အဲဒါက ကန့်သတ်ချက်တွေ ဖန်တီးတယ်၊ ဒါမှမဟုတ် ငါတို့ အလုပ်လုပ်တယ်။ interface နှင့်အတူ. ဒါက ဒုတိယရွေးချယ်မှုစံနှုန်းပါ။ အလားတူပင်၊ အတွေ့အကြုံရှိသောအတိုင်ပင်ခံကိုဆွဲဆောင်ရန်ဖြစ်နိုင်သည် - ကျွန်ုပ်တို့သည်ခက်ခဲသောရွေးချယ်မှုဖြင့်အလုပ်လုပ်သည်။

သို့သော် ဤကိစ္စမျိုးတွင်ပင် ကျွန်ုပ်သည် မည်သည့်အရာနှင့် လုပ်ဆောင်ရမည်ကို နားလည်သဘောပေါက်ပြီး မည်သည့်ဦးတည်ချက်သို့ ပြောင်းလဲရမည်ကို နားလည်သည်အထိ၊ အရေးကြီးသောအရာကို ယူဆောင်ကာ တုန်လှုပ်ခြင်းသည် အလွန်ကောင်းသော အကြံအစည်မဟုတ်ပေ။ ထို့ကြောင့်၊ ဤကိစ္စတွင်၊ ကျွန်ုပ်တို့သည် မစိုးရိမ်ရသော ချို့ယွင်းချက်မရှိသော အင်တာဖေ့စ်တစ်ခုနှင့် အလုပ်လုပ်လိုပါသည်။

နောက်ထပ်ကြည့်ရအောင် ဝန်ဆောင်မှုအဖွဲ့. ကျွန်ုပ်တို့သည် ဤဝန်ဆောင်မှုကို ပံ့ပိုးပေးသူများနှင့် အဆက်မပြတ် လုပ်ဆောင်ပြီး အလွန်နီးကပ်စွာ ဆက်ဆံရမည်ဖြစ်ပါသည်။

အဖွဲ့ရှိလူများကို အမျိုးအစား နှစ်မျိုးခွဲထားသည်- ရှေးရိုးစွဲဝါဒီများ - ကမ္ဘာဟောင်းတွင်နေထိုင်ပါ၊ သို့မဟုတ် DevOps အကြောင်း ဘာမှမသိပါ၊ နှင့် ဆန်းသစ်တီထွင်သူများခေတ်ဆန်သော အလေ့အကျင့်အားလုံးကို ဆွဲယူပေးသော၊ နောက်တစ်ခုက အကြောင်းအရာကို အမြဲတမ်းနားမလည်ပေမယ့် အနည်းဆုံးတော့ အဲဒါအတွက် အဆင်သင့်ဖြစ်နေပါပြီ။

တစ်ဖက်တွင် ရှေးရိုးစွဲဝါဒီများသည် အတွေ့အကြုံရှိသူများဖြစ်သည်- ၎င်းတို့သည် ကုမ္ပဏီတွင် ကြာရှည်စွာရှိနေကြပြီး အတွင်းအပြင်ကို နားလည်ကြသော်လည်း အလေ့အကျင့်များအကြောင်းကို အတိအကျမသိကြပေ။ အခြားတစ်ဖက်တွင်၊ တစ်ခုခုကိုကြားသိဖူးသော တီထွင်သူရှိသော်လည်း အများစုမှာ ကုမ္ပဏီတွင် အလုပ်မလုပ်သည်မှာ ကြာပါပြီ။ ဘယ်ဟာနဲ့ တွဲလုပ်ရင် ပိုကောင်းမလဲ။

မည်သည့်ကိစ္စတွင်မဆို ရှေးရိုးစွဲဝါဒီများနှင့် ဆက်ဆံရမည်ဖြစ်ပြီး၊ ဤသည်မှာ ၎င်းတို့၏ဝန်ဆောင်မှုဖြစ်သောကြောင့် ဖြစ်သည်။ သင်သူတို့နှင့်ဆက်သွယ်ရန်၊ ဝန်ဆောင်မှု၏အသေးစိတ်အချက်အလက်များကိုရှာဖွေရန်၊ ဤနည်းဖြင့်လုပ်ဆောင်နိုင်သည်နှင့်အခြားအရာများကိုရှာဖွေရမည်ဖြစ်သည်။ ငါတို့က သူတို့ရဲ့ အကြံဉာဏ်ပေါ် မူတည်တယ်။ သူတို့က သူတို့ရဲ့ဝန်ဆောင်မှုကို ပိုသိတာကြောင့် သူတို့ကို တစ်ခုခုအပ်နှင်းဖို့ ဖြစ်နိုင်တယ်။ ဒါကြောင့် ဘယ်အသင်းနဲ့ အဆက်အသွယ်ရမလဲဆိုတာ အရေးကြီးတယ်။

ကွန်ဆာဗေးတစ်တွေက ဝက်တစ်ကောင်ကို ထည့်သွင်းနိုင်တာကြောင့် အဖွဲ့အတွက် ဆန်းသစ်တီထွင်သူတွေကို ရွေးချယ်ရတာ ယုတ္တိတန်ပါတယ်။

လက်တွေ့တွင် ရှေးရိုးစွဲလူများသည် သိသာထင်ရှားသော အတွေ့အကြုံများ ရှိသော်လည်း နောက်ထပ် မည်သို့နေထိုင်ရမည်ကို နားမလည်ဘဲ ဖြစ်နေတတ်သည်။ ဝန်ဆောင်မှုကို အသွင်ပြောင်းပြီး ဒီဇိုင်းပြန်ဆွဲပြီးနောက် မလိုအပ်ဘဲ အလုပ်ထုတ်ခံရမည်ကို ရိုးရှင်းစွာကြောက်ရွံ့ကြသည်။ တခါတရံမှာ သူတို့ဘာဖြစ်နေတယ်ဆိုတာကို နားမလည်တာကြောင့် အလုပ်တွေကို ဖျက်စီးပစ်တယ်။

အသင်းထဲက ကောင်လေးတစ်ယောက်ဟာ အရာအားလုံးကို ပြုပြင်ပေးခဲ့တဲ့ ကိစ္စတစ်ခုရှိခဲ့တယ်၊ ဘာကြောင့်လဲဆိုတော့ ဒါက ကျွန်တော်တို့ အခုလုပ်နေတဲ့အရာထက် ပိုအရေးကြီးတယ်လို့ ယူဆရလို့ပါပဲ။ ကျွန်ုပ်တို့သည် ဤအပိုင်းကို ယနေ့အကောင်အထည်ဖော်ရန် - မဟုတ်ဘူး၊ ကမ္ဘာကြီးရဲ့တစ်ဖက်ခြမ်းမှာ မီးရှိနေတယ်၊ ​​အဲဒါကိုပြင်မယ်။ ဒီလိုလူတွေနဲ့ တွဲလုပ်ရတာ ခက်တယ်။

ကွန်ဆာဗေးတစ်အဖွဲ့မှ လူများသည် အလုပ်များကို မေ့လျော့သွားတတ်သည် သို့မဟုတ် နောက်ဆုံးမိနစ်အထိ ၎င်းတို့ကို အလုပ်ဖြုတ်ပစ်လေ့ရှိသည်။ အကယ်၍ John Willis က တားမြစ်ခဲ့ပါက သင်သည် အမှားတစ်ခုပြုလုပ်ပြီး ပြီးမြောက်သည့် အလုပ်အရေအတွက်အတွက် KPI ကို သတ်မှတ်ပေးကာ အချို့သော အကြောင်းရင်းများကြောင့် KPI တွင် မပါဝင်ပါက ၎င်းတို့သည် မည်သည့်အရာကိုမျှ လုပ်ဆောင်မည်မဟုတ်ပါ။ ယေဘူယျအားဖြင့်၊ သူတို့သည် ဘောနပ်စ်ကို ဆုံးရှုံးသွားသောကြောင့် မှန်ပေလိမ့်မည်။

ဆန်းသစ်တီထွင်သူများနှင့် ပိုမိုလွယ်ကူသည် - ၎င်းတို့သည် ပိုမိုသစ္စာရှိကြသည်။. တစ်ခုခုတော့ ကြားပြီးပြီ၊ တစ်နေရာရာကို သွားချင်နေတော့ ကူညီမယ်။ ကျွန်ုပ်တို့သည် ပထမအကြိမ်တွင် ဒုက္ခခံရန် အဆင်သင့်ဖြစ်နေသူများကို လိုအပ်သည်- ဝန်ဆောင်မှုပြောင်းလဲပါက ဆန်းသစ်တီထွင်သူများသည် ရှေ့ဆောင်များအဖြစ် အဖုအထစ်များအားလုံးကို ဖမ်းဆုပ်နိုင်မည်ဖြစ်သည်။ ဆန်းသစ်တီထွင်သူများသည် အရာရာကို အသစ်အဆန်းနှင့် ခေတ်မီသော လိုချင်စိတ်ရှိပြီး ခံစားနေကြရသည်။

ကွန်ဆာဗေးတစ်တွေကို နောက်ပိုင်းမှာ ပြောင်းလဲလာနိုင်တယ်။ အပိုင်းတစ်ခုကို သင်ပြောင်းလဲလိုက်ပြီး အရာအားလုံး ကောင်းမွန်ကြောင်း သင်ပြသသောအခါ၊ ၎င်းတို့သည်လည်း ၎င်းကို စမ်းကြည့်ချင်ပြီး DevOps ဘာသာအသစ်ကို လက်ခံယုံကြည်လာမည်ဖြစ်သည်။

အကျဉ်းချုံးကြည့်ရအောင်။ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ကုမ္ပဏီတွင် အသွင်ကူးပြောင်းမှုတစ်ခုလုံးကို ကိုယ်တိုင်လုပ်ဆောင်ပါက၊ ဝန်ဆောင်မှုအသစ်တစ်ခု၊ ၎င်း၏ပျက်ပြားမှုဒဏ်ကို အလွန်အကျွံမခံရစေရန်နှင့် ဆန်းသစ်တီထွင်သူအဖွဲ့တစ်ဖွဲ့သည် ပိုကောင်းရိုးရှင်းသော ဝန်ဆောင်မှုအသစ်ကို ရွေးချယ်ပါ။

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

ဘယ်သူတွေ ပါဝင်နေလဲ။

ဝန်ဆောင်မှုနှင့် ပတ်သက်သည့် အနည်းဆုံး ဆက်စပ်သူတိုင်းကို ရှာဖွေရန် လိုအပ်သည်- ဆော့ဖ်ဝဲအင်ဂျင်နီယာများ၊ စမ်းသပ်သူများ၊ စီမံခန့်ခွဲသူများ၊ လုံခြုံရေး ကျွမ်းကျင်သူများ၊ မန်နေဂျာများနှင့် ထုတ်ကုန်ပိုင်ရှင်များ ဖြစ်နိုင်သည်။ ကုန်ပစ္စည်းပိုင်ရှင်များသည် နည်းပညာဆိုင်ရာကျွမ်းကျင်သူများမဟုတ်ကြသော်လည်း၊ ၎င်းတို့သည် ဝန်ဆောင်မှုနှင့် သက်ဆိုင်သည်- ၎င်းတို့သည် ဆုံးဖြတ်ချက်များချကြပြီး၊ အလုပ်များကို သတ်မှတ်ကြသည်။

ဝန်ဆောင်မှုနှင့် ပတ်သက်သည်များကို အနည်းဆုံး ဆုံးဖြတ်ချက်အချို့နှင့် လွှမ်းမိုးနိုင်သူတိုင်းကို ရှာဖွေတွေ့၊ တွေ့ဆုံပြီး ဆက်သွယ်ရန် လိုအပ်ပါသည်။

၎င်းတို့အတွက် ကျွန်ုပ်တို့ ဘာလိုအပ်သနည်း။ ဘယ်သူတွေနဲ့ ညှိနှိုင်းရမလဲဆိုတာ သိပါရစေ. အသွင်ပြောင်းစဉ်တွင်၊ ဝန်ဆောင်မှုနှင့် လုပ်ဆောင်ခြင်း၏ ပုံမှန်နိယာမသည် ပြောင်းလဲသွားသောအခါ၊ ၎င်းသည် တုန်လှုပ်နေဆဲဖြစ်သည်။ ချဉ်းကပ်မှုအသစ်များကို စမ်းသပ်စဉ်တွင် ခဏတာ လွဲချော်မှုများ ရှိလိမ့်မည်။ လူတွေက ဒါကို အဆင်သင့်ဖြစ်မှ သဘောတူရမယ်။

ထို့နောက်တွင် သင်သည် Value Stream Map ကိုတည်ဆောက်ရမည်ဖြစ်ပြီး၊ ဤလူများမရှိဘဲ သင်ဖြစ်ပျက်နေသောအရာအားလုံးကို အတူတကွသိရုံမျှဖြင့် ၎င်းကိုတည်ဆောက်နိုင်မည်မဟုတ်ပါ။ လူတစ်ဦးသည် ဝန်ဆောင်မှုနှင့် ဖြစ်ပျက်သမျှကို ဘယ်တော့မှ မသိပါ။

၎င်းတို့သည် အဖွဲ့အတွက် လူများကို အကြံပြုပါမည်။ နောက်ပိုင်းတွင် အဘယ်ကြောင့် သီးခြားအဖွဲ့ လိုအပ်ကြောင်း ဆွေးနွေးပါမည်။ တည်ဆဲဌာနများမှ လူများကို ခေါ်ယူရမည်ဖြစ်ပါသည်။ ဝန်ဆောင်မှုတွင်ပါဝင်သူများသည် ကျွန်ုပ်တို့၏ဦးတည်ချက်တွင်ထင်မြင်ယူဆသော လုပ်ဖော်ကိုင်ဖက်များကို အကြံပြုနိုင်မည်ဖြစ်ပြီး၊ ကျွန်ုပ်တို့ကို ကူညီပေးနိုင်ပြီး ကျွန်ုပ်တို့လိုအပ်သည်များကို အရည်အချင်းပြည့်မီသူဖြစ်ကြောင်း အကြံပြုနိုင်မည်ဖြစ်ပါသည်။

ထို့နောက်၊ ဌာနအသီးသီးမှ ဤလူအားလုံးကို အခန်းတစ်ခုထဲသို့ စုစည်းပြီး Value Stream Map တစ်ခုကို စတင်တည်ဆောက်ပါသည်။

Value Stream Map တည်ဆောက်ခြင်း။

Value Stream Map သည် သုံးစွဲသူထံသို့ တန်ဖိုးများ စီးဆင်းမှုကို ပြသသော ပုံ သို့မဟုတ် မြေပုံတစ်ခုဖြစ်သည်။. ဤသည်မှာ အလယ်အလတ်အဆင့်များအားလုံးနှင့် ကျွန်ုပ်တို့၏ဖောက်သည်များထံ မည်ကဲ့သို့ တန်ဖိုးများ နောက်ဆုံးတွင် မည်သို့ရောက်ရှိသွားခြင်းအပါအဝင် ၎င်း၏အကောင်အထည်ဖော်မှုအထိ စိတ်ကူးတစ်ခုရရှိလာချိန်မှ လုပ်ငန်းစဉ်တစ်ခုလုံးဖြစ်သည်။

Value Stream Map လုပ်ဖို့ လိုအပ်တယ်။ ဖွံ့ဖြိုးတိုးတက်မှု အဆင့်အားလုံးကို မြင်ယောင်ကြည့်ပါ။၊ လက်ရှိလုပ်ငန်းစဉ်တွင် တည်ရှိနေသော တိုင်းတာမှုများမှတဆင့် ပြဿနာများကို ဒေသအလိုက်သတ်မှတ်ပြီး အဆိုပါပြဿနာများကို ဖယ်ရှားပစ်ရန် စတင်ပါ။ ကနဦးရည်မှန်းချက်တစ်ခုချမှတ်ပါ။. ဤနေရာ၌ ကျွန်ုပ်တို့သည် အမှန်တကယ် တစ်ခုခုကို စတင်လုပ်ဆောင်နေပါသည်။

မက်ထရစ်များ

Value Stream Map စာပေတွင် ဖော်ပြထားသော မတူညီသော မက်ထရစ်များစွာရှိသည်၊ သို့သော် ကျွန်ုပ်တို့ကို စတင်ရန် လုံလောက်ပါသည်။

ပို့ဆောင်ချိန် - နှောင့်နှေး/စောင့်ပါ။ - တစ်ခုခုကို စောင့်မျှော်နေတဲ့အချိန်။ ဥပမာအားဖြင့်၊ စမ်းသပ်သူသည် စာမေးပွဲ ကင်းစင်သည်အထိ စောင့်ဆိုင်းနေပြီး ဤကာလအတွင်း မည်သည့်အရာကိုမျှ မလုပ်နိုင်ပါ။

Value Added Time - အသုံးဝင်သော အလုပ်ချိန် - သုံးစွဲသူအတွက် နောက်ဆုံးတန်ဖိုးကို ဖန်တီးရန် ဤကဲ့သို့သော အဆင့်တွင် ကျွန်ုပ်တို့ သုံးစွဲခဲ့သည့်အရာ။ ဥပမာအားဖြင့်၊ စမ်းသပ်သူတစ်ဦးသည် ၎င်း၏စမ်းသပ်မှုကို စတင်ပြီး တစ်ခုခုကို စတင်စစ်ဆေးသည်။ ကျွန်ုပ်တို့သည် ထုတ်ကုန်အတွက် အမှန်တကယ် တစ်ခုခုလုပ်သောအခါတွင် ဤအချိန်သည် အသုံးဝင်သော အလုပ်ဖြစ်သည်။ ဤသည်မှာ ဖောက်သည်များ ပေးချေသည် - အရည်အသွေး ဆော့ဖ်ဝဲ။

%C/A သည် လက်ခံအလုပ်၏ ရာခိုင်နှုန်းဖြစ်သည်။ ကျွန်ုပ်တို့တွင် အဆင့်တစ်ခုရှိသည် - ဖွံ့ဖြိုးတိုးတက်မှု၊ ဒုတိယအဆင့် - စမ်းသပ်ခြင်း။ ဤရာခိုင်နှုန်းသည် ဆော့ဖ်ဝဲအင်ဂျင်နီယာများထံမှ လက်ခံသည့် အင်္ဂါရပ်များ မည်မျှရှိသနည်း။

ဒါက အကြမ်းဖျင်းအားဖြင့် ငါတို့မြေပုံနဲ့တူတယ်။

အဖွဲ့အစည်းဖွဲ့စည်းပုံ၊ ဌာနအရေအတွက်နှင့် သင်လုပ်ဆောင်သည့်အရာပေါ်မူတည်၍ ၎င်းသည် ကွဲပြားနိုင်သည်။ သို့သော် ယေဘုယျအားဖြင့် မြေပုံပေါ်တွင် အဆင့်နှစ်ဆင့်ရှိလိမ့်မည်- စိတ်ကူး и analytics. ဤအဆင့်တွင်၊ ဥပမာ၊ ပို့ဆောင်ချိန် ၂ ပတ်နှင့် တန်ဖိုးထပ်ထည့်ချိန် ၂ ရက်၊ ဒေတာကို မျှော်လင့်ထားသည်။

ကျွန်ုပ်တို့သည် အဆင့်အားလုံးကို မက်ထရစ်များဖြင့် အကျုံးဝင်ပါသည်။

Backlog - လေ့လာသုံးသပ်သူတွေ ပေါ်လာပြီးနောက်မှာ ပြဿနာ ဘယ်လောက်ရှိလဲ။

ပုံစံ - အလုပ်များ၊ ရပ်တည်မှုများ သို့မဟုတ် စက်ပစ္စည်းဆိုင်ရာ ရှင်းလင်းချက်အတွက် developer များသည် သီတင်းမည်မျှစောင့်ဆိုင်းခဲ့သည် - အရေးမကြီးပါ၊ သို့သော် ၎င်းတို့သည် တစ်ခုခုကို စောင့်နေကြသည်။ ဥပမာအားဖြင့်၊ အင်္ဂါရပ်တစ်ခုကိုအကောင်အထည်ဖော်ရန် ၎င်းတို့သည် ၄ ​​ရက်ကြာသည်။ ဤနေရာတွင် %C/A မက်ထရစ်ဝင်လာသည်။ Developer များသည် Backlog မှ အလုပ်များ 4% ကိုသာ ရယူခဲ့သည်။ ကျန် 80% မှာ လုံလောက်တဲ့ နည်းပညာဆိုင်ရာ သတ်မှတ်ချက်မရှိဘူးလို့ ယုံကြည်ကြပြီး ပြန်လည်ပြင်ဆင်ဖို့အတွက် စေလွှတ်လိုက်ပါတယ်။

စမ်းသပ်ခြင်း. LT diagram ကို 4 ရက်သတ်မှတ်ထားသည်။ ဥပမာအားဖြင့်၊ စမ်းသပ်သူများသည် အလကားဖြစ်ရန် စောင့်ဆိုင်းနေကြသည်၊ VA သည် ၎င်းတို့ အမှန်တကယ် တစ်စုံတစ်ခုကို စမ်းသပ်နေသည်မှာ ၂ ရက်၊ နှင့် %C/A = 2% ဖြစ်သည်။ - developer များမှပေးပို့သော ကုဒ် သို့မဟုတ် အင်္ဂါရပ်များ ၏ 40% ကိုသာ စမ်းသပ်သူများသည် လုံလောက်သည်ဟု ယူဆပါသည်။ အကြောင်းတစ်ခုခုကြောင့် အခြားအရာအားလုံးကို မကြိုက်ခဲ့ကြပါ။

ဤအတိုင်းအတာများကို မည်သို့လုပ်ဆောင်ရမည်ကို အသေးစိတ်ကျုပ်မပြောပါ၊ ဆောင်းပါး၏အဆုံးတွင် ၎င်းတို့အကြောင်း သင်လေ့လာနိုင်သည့်စာပေများကို အကြံပြုပါမည်။

ကျွန်ုပ်အကြံပြုနိုင်သည့်တစ်ခုတည်းသောအချက်မှာ သင်နှင့်အတူ Value Stream Map ကို ပြုစုမည့်သူများကို သင်မယုံရန်ဖြစ်သည်။ ၎င်းတို့သည် မတူညီသော လုပ်ငန်းစဉ်များ မည်မျှကြာမည်ကို အကြံဥာဏ်ပေးသော်လည်း ဤခန့်မှန်းချက်များသည် အမြဲတမ်းမမှန်သောကြောင့် သင့်ကိုယ်သင် တိုင်းတာရန် အကောင်းဆုံးဖြစ်သည်။

လည်ပတ်မှုဌာနကို ရောက်လာပြီး ထုတ်လုပ်မှုအတွက် အင်္ဂါရပ်အသစ်ကို ပေးပို့ရန် အချိန်မည်မျှကြာကြောင်း မေးမြန်းသောအခါတွင် ကျွန်ုပ်တို့တွင် ကိစ္စတစ်ခုရှိသည်။ သူတို့က 10 မိနစ်လောက်ကြာမယ်လို့ ပြောတယ်၊ ငါတို့က ဘာလို့ ဒီကုမ္ပဏီကို လာတိုင်တာလဲလို့ တွေးမိတယ်။ 10 မိနစ်သည် ကုဒ်ကိုယူ၍ ဆာဗာသို့ ပို့ဆောင်ပေးသည့် script ၏ လည်ပတ်ချိန်ဖြစ်သည်။ သို့သော် ယင်းမတိုင်မီတွင်၊ ဖြန့်ချိမှုသည် ဆာဗာပေါ်တွင် သုံးရက်ကြာနေပြီး ဖုန်မှုန့်များကို ရိုးရှင်းစွာ စုဆောင်းနေသည် - အသုံးပြုရန် လိုအပ်သည့် Backlog တွင် အလုပ်တစ်ခုရှိသည်။ ဖြန့်ကျက်ခြင်းအဆင့် မရောက်မီ ပရောဂျက်သည် ထိုနေရာတွင် ထိုင်နေချိန်တွင် စောင့်ဆိုင်းရသည့် အဆင့်တစ်ခု ရှိနေပါသည်။ အကယ်၍ ကျွန်ုပ်တို့သည် notepad နှင့်မလိုက်ခဲ့ပါ၊ Jira တွင်လုပ်ဆောင်ရမည့်တာဝန်ကိုကျွန်ုပ်တို့မျက်စိမလည်ဘဲ တစ်ဆင့်ပြီးတစ်ဆင့် ခြေရာခံမိပါက၊ အရာအားလုံးသည် ကောင်းမွန်ပြီး ပြဿနာမရှိဟုကျွန်ုပ်တို့ထင်နေမည်ဖြစ်ပါသည်။

ထို့ကြောင့်၊ လက်တွေ့နှင့်နီးစပ်သော အကြံဥာဏ်တစ်ခုရရှိရန် သင်ကိုယ်တိုင် တိုင်းတာမှုများကို တစ်ကြိမ်ထက်ပို၍ လုပ်ဆောင်ရသေးသည်။ Value Stream Map ပေါ်မူတည်၍ မည်သည့်နေရာတွင် စတင်ရမည်နှင့် မည်သည့်အရာကို အရင်ပြင်ရမည်ကို သင်ဆုံးဖြတ်မည်ဖြစ်သည်။

ယာယီအဖွဲ့

DevOps ကို အကောင်အထည်ဖော်ရန် ဆုံးဖြတ်သော ကုမ္ပဏီများစွာသည် အဖွဲ့တစ်ခုကို ဖန်တီးသော်လည်း ယာယီတစ်ခုမဟုတ်ဘဲ နှစ်အတော်ကြာ တည်ရှိနေသည့် အဖွဲ့တစ်ခုဖြစ်သည်။ DevOps တွင် အဖွဲ့အစည်းဖွဲ့စည်းပုံတည်ဆောက်မှုအတွက် မတူညီသောပုံစံများကိုဖော်ပြသည့် DevOps တောင်းပန်ဝန်ဆောင်မှုသို့ သင်သွားပါက၊ ၎င်းသည် ဆန့်ကျင်သည့်ပုံစံတစ်ခုဖြစ်ကြောင်း သင်နားလည်ပါလိမ့်မည်။

DevOps အဖွဲ့သည် နှစ်အတော်ကြာ အဆက်မပြတ် တည်ရှိနေသောအခါ၊ DevOps သည် ဌာနများအကြား ဆက်သွယ်မှု၊ မြန်နှုန်းနှင့် ထိရောက်မှုတို့အကြောင်း၊

အဖွဲ့တစ်ဖွဲ့သည် အခြားအရာတစ်ခုကို သီးခြားလုပ်ဆောင်ရန်သာရှိပြီး အချိန်အကြာကြီးတည်ရှိနေပါက၊ ၎င်းသည် မလိုအပ်သော အတားအဆီးတစ်ခုကို ဖန်တီးပေးသည်။ ယခုအခါ ပရိုဂရမ်မာသည် ပြဿနာကိုဖြေရှင်းရန် စီမံခန့်ခွဲသူထံ ချက်ချင်းသွားမည့်အစား DevOps ဌာနကို ဦးစွာဆက်သွယ်ရမည်ဖြစ်ပြီး၊ သူသည် ဆက်လက်လုပ်ဆောင်မည်ဖြစ်သည်။

ထို့ကြောင့် စတင်ရန်၊ ယာယီအဖွဲ့တစ်ခု ဖန်တီးရန် လိုအပ်သည်။. ကျွန်ုပ်တို့ရွေးချယ်ထားသော ကန့်သတ်ချက်တစ်ခုအား ဖယ်ရှားရန်အတွက်သာ လက်ထဲတွင်ရှိသော အလုပ်ပေါ်မူတည်၍ ခြောက်လ၊ အများဆုံး တစ်နှစ်အထိ အခြေအနေအရ တည်ရှိနေမည်ဖြစ်ပါသည်။ ထိုအခါသူမသေလိမ့်မည်။ နာကျင်စရာတွေ အများကြီးရှိတဲ့ နောက်တနေရာကို ရွေးပြီး အဲဒီအတွက် သီးခြားအဖွဲ့တစ်ခု လိုအပ်တယ်ဆိုတာ သိထားရင် အဲဒါကို ထပ်ပြီး ဖန်တီးမယ်။ သို့သော် ထိုအဖွဲ့များသည် "အမြဲတမ်းအခြေခံ" တွင်မတည်ရှိသင့်ပါ - ထို့နောက် ၎င်းတို့သည် ဆက်သွယ်ရေးကို အနှောင့်အယှက်ပေးရုံသာမက တစ်စုံတစ်ခုပြီးမြောက်စေရန်အတွက် ယေဘုယျအားဖြင့် သီးခြားလုပ်ဆောင်စရာများကို လုပ်ဆောင်ကြသည်။ ဤလုပ်ဆောင်စရာများသည် DevOps သို့မဟုတ် အသွင်ပြောင်းခြင်းနှင့် လုံးဝသက်ဆိုင်မည်မဟုတ်ပါ။ လက်ရှိဌာနတွေကို ဘာကြောင့် ဒီတာဝန်ကို မပေးတာလဲ။

ယာယီအဖွဲ့ ဘာကြောင့် လိုအပ်တာလဲ။

လက်ရှိ လုပ်ငန်းစဉ်များနှင့် ကွဲလွဲနေပါသည်။. DevOps အသွင်ပြောင်းခြင်းသည် ကျွန်ုပ်တို့အသုံးပြုသည့် နည်းပညာများနှင့် ကိရိယာများတွင် ပြောင်းလဲခြင်းသာမက အလုပ်၊ တွေးခေါ်မှုနှင့် တန်ဖိုးများဆိုင်ရာ ပြောင်းလဲမှုတစ်ခုဖြစ်သည်။ အဖွဲ့သည် ၎င်းအသုံးပြုသည့်ပုံစံအတိုင်း လုပ်ဆောင်ပါက အခြားနည်းလမ်းများကို စမ်းသုံးနိုင်မည်မဟုတ်ပေ။

ဤလူများသည် မတူညီသော စည်းမျဉ်းများဖြင့် နေထိုင်ရပါမည်- ကွဲပြားစွာ အလုပ်လုပ်ရန် ကြိုးစားနေသောကြောင့် ကုမ္ပဏီရှိ KPI အားလုံးကို လျစ်လျူရှုပါ။ ယာယီအဖွဲ့များသည် ဆာဗာတစ်ခုရရှိရန် လျှောက်လွှာများကို ဖြည့်စွက်မည်မဟုတ်သော်လည်း ၎င်းတို့ကို စီမံခန့်ခွဲသည့်ဌာနထံ တိုက်ရိုက်သွားမည်ဖြစ်ပြီး ၎င်းတို့ကို ဦးစားပေးရမည့်အရာဖြစ်သောကြောင့် ၎င်းတို့သည် ဦးစားပေးဖြစ်ပြီး မတူညီသောနေထိုင်ရန်ကြိုးစားသောကြောင့် ၎င်းတို့ကို ဦးစားထားရန် တောင်းဆိုကာ ၎င်းတို့ကို စီမံခန့်ခွဲသည့်ဌာနထံ တိုက်ရိုက်သွားမည်ဖြစ်သည်။ အဖွဲ့သည် လက်ရှိ လုပ်ငန်းစဉ်အားလုံးနှင့် လုံးဝဆန့်ကျင်နေပါသည်။ လက်ရှိအလုပ်အလေ့အကျင့်များသည် ၎င်းတို့အား အနှောင့်အယှက်မဖြစ်စေရန်နှင့် အခြားသူများကို အနှောင့်အယှက်မပေးကြောင်း သေချာစေရန်၊ ဤလူများကို သီးခြားအဖွဲ့အဖြစ် ခွဲထုတ်ထားပါသည်။

စမ်းသပ်မှုများတွင် ဗျူရိုကရေစီကို ရှောင်ပါ။. ယာယီအဖွဲ့များသည် ဗျူရိုကရေစီမရှိ၊ အချိန်အစီရင်ခံချက်မတင်ကြ၊ မန်နေဂျာများထံ အစီရင်ခံခြင်းမပြုကြပါ။ ဤကမ္ဘာသည် လူတို့နေထိုင်ပြီး မတူညီသောတွေးခေါ်မှုများနှင့် လုံးဝကွဲပြားသည့်အရာများကို လုပ်ဆောင်သည့် လုံးဝ သီးခြားကမ္ဘာတစ်ခုဖြစ်သည်။ သူတို့ကို ထပ်ပြီး နှောင့်ယှက်စရာ မလိုဘူး။

ဝန်ဆောင်မှုတွင် မရပ်မနားလုပ်သည်။. ပထမအချက်တွင်၊ ကျွန်ုပ်တို့သည် စမ်းသပ်မည့်အရာတစ်ခုကို ရွေးချယ်ခဲ့သည်။ ပိုမိုကောင်းမွန်အောင် လုပ်ဆောင်ရန် နည်းလမ်းများကို စမ်းသပ်ခြင်းနှင့် ရှာဖွေခြင်းသည် ကောင်းမွန်သော်လည်း အင်္ဂါရပ်များကိုလည်း ပြုလုပ်လိုပါသည်။ အဖွဲ့တစ်ဖွဲ့လုံးသည် အင်္ဂါရပ်များအစား အသွင်ပြောင်းခြင်းကို အာရုံစိုက်ပါက၊ ကျွန်ုပ်တို့သည် ဝင်ငွေစတင်ဆုံးရှုံးမည်ဖြစ်ပြီး၊ ပိုးကောင်များသည် အချိန်အတော်ကြာအောင် တွဲနေလိမ့်မည် - ၎င်းကို ကျွန်ုပ်တို့ မလိုအပ်ပါ။ ယာယီအဖွဲ့တစ်ခုဖန်တီးခြင်းသည် သင့်အား ထုတ်ကုန်ပေါ်တွင် အလုပ်မရပ်ဘဲ စမ်းသပ်နိုင်စေပါသည်။

အလုပ်ကိစ္စများတွင် အချိန်မဖြုန်းပါနှင့်. အဲဒါက ထုတ်ကုန်နဲ့ ပတ်သက်ပြန်တယ်။ အဖွဲ့သည် အခြားကိရိယာများနှင့် ပစ္စည်းများကို စမ်းကြည့်ရန် အချိန်များစွာ လိုအပ်သည်။ လူများသည် ကိရိယာများကို ကျွမ်းကျင်ပိုင်နိုင်စေရန်၊ ၎င်းတို့ကို စတင်အကောင်အထည်ဖော်ရန်နှင့် ပုံမှန်အသုံးပြုရန် အနည်းဆုံး ခြောက်လကြာမည်ဖြစ်သည်။ သူတို့ ထုတ်ကုန်ကို အာရုံစိုက်ထားရင် ခြောက်လလောက် အာကာသထဲ တိုးသွားလိမ့်မယ်။ လူတွေက ထုတ်ကုန်မှာ အလုပ်လုပ်ရင်၊ သူတို့ဟာ လုပ်ငန်းစဉ်ဟောင်းတွေနဲ့ ပြန်အလုပ်လုပ်တယ် - အဲဒါကို မလိုအပ်ပါဘူး။

ထို့ကြောင့် ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုအသွင်ပြောင်းမည့် သီးခြားအဖွဲ့တစ်ဖွဲ့သို့ ဌာနအသီးသီးမှ လူများကို တာဝန်ပေးပါသည်။ ရလဒ်အနေဖြင့်၊ ဝန်ဆောင်မှုသည် အလုပ်လုပ်သည်၊ ဆက်လက်ဖွံ့ဖြိုးနေပြီး၊ တစ်ချိန်တည်းတွင် ကျွန်ုပ်တို့သည် ၎င်းနှင့်ပတ်သက်ပြီး အချို့သောစမ်းသပ်မှုများကို လုပ်ဆောင်ပါသည်။

ယာယီအဖွဲ့သည် DevOps အသွင်ပြောင်းခြင်းအတွက်သာ ရည်စူးထားသည် - ကျွန်ုပ်တို့တွေ့ရှိခဲ့သည့် ကန့်သတ်ချက်များကို ဖယ်ရှားကာ ဘာမှမပိုပါ။

အဖွဲ့တွင် စွယ်စုံရလူများ ပါဝင်သည်။. ဆိုလိုသည်မှာ ကျွန်ုပ်တို့သည် developer များကိုသာ ငှားရမ်းခြင်းမဟုတ်ပါ။ ကျွန်ုပ်တို့သည် ဝန်ဆောင်မှုစင်တာသို့ မရောက်ဘဲ ထိုနေရာမှ အဖွဲ့တစ်ဝက်ကို ခေါ်သွားသည် - မဟုတ်ပါ၊ ကျွန်ုပ်တို့ ယူလိုက်ပါသည်။ ဌာနအသီးသီးကလူတွေ. လွန်ခဲ့သည့်အချက်အနည်းငယ်က၊ အသွင်ပြောင်းဝန်ဆောင်မှုနှင့်ပတ်သက်သည့် မတူညီသောဌာနများနှင့် မတူညီသောဝန်ထမ်းများကို ကျွန်ုပ်တို့တွေ့ရှိခဲ့သည်။ ကျွန်ုပ်တို့သည် universal ဖြစ်ရမည်ဖြစ်သောကြောင့် ၎င်းတို့ထံမှ အဖွဲ့တစ်ဖွဲ့ကို စုဆောင်းနေသည် - စမ်းသပ်ခြင်းလုပ်ငန်းစဉ်၊ ဖွံ့ဖြိုးတိုးတက်မှုလုပ်ငန်းစဉ်နှင့် ဝန်ဆောင်မှုထိန်းသိမ်းခြင်းလုပ်ငန်းစဉ်တို့ကို ပြောင်းလဲပါမည်။ မတူညီတဲ့ အရည်အချင်းတွေ လိုအပ်တယ်။

အများအားဖြင့် ကျွန်ုပ်တို့သည် ဆော့ဖ်ဝဲအင်ဂျင်နီယာတစ်ဦး၊ စမ်းသပ်သူနှင့် အင်ဂျင်နီယာတစ်ဦးကို တစ်ကြိမ်လျှင် တစ်ဦးယူကာ မတူညီသော နေထိုင်နိုင်စေမည့် ဖြေရှင်းချက်တစ်ခုကို ၎င်းတို့နှင့်အတူ စုစည်းပေးပါသည်။

ဒီလူတွေဟာ အဖွဲ့အစည်းမှာ အခွင့်အာဏာရှိဖို့ လိုလားတယ်။. သင်မလုပ်ချင်သော်လည်း ရှေးရိုးစွဲဝါဒီတစ်ဦးကို သင်ယူရပေမည်။ ကျွန်ုပ်တို့တွင် ကုမ္ပဏီကြီးတစ်ခုရှိလျှင် လူတိုင်းသည် ကျွန်ုပ်တို့၏စိတ်ကူးကို ယုံလိမ့်မည်မဟုတ်ပေ၊ ဥပမာအားဖြင့် မတ်တပ်ရပ်မပေးခြင်းဖြင့် အချို့က ကျွန်ုပ်တို့၏ဘီးများတွင် စကားပြောဆိုနိုင်ပါသည်။ ဤနေရာတွင် သင်သည် သူ၏လုပ်ဖော်ကိုင်ဖက်များ၏ စိတ်သဘောထားကောင်းကို ရရှိထားသည့် ကျယ်ပြန့်သောအတွေ့အကြုံရှိသော လေးစားထိုက်သူ တစ်ဦးဖြစ်သည့် "အခွင့်အာဏာ" လိုအပ်ပါသည်။ အဖွဲ့ရှိ ဝန်ထမ်း၏ အခွင့်အာဏာသည် ယာယီအဖွဲ့၏ လုပ်ငန်းတာဝန်နှင့် အလုပ်များကို ရိုးရှင်းစေမည်ဖြစ်သည်။ လူတွေထင်လိမ့်မယ်-

- ဟုတ်တယ်၊ ငါတို့အားလုံးသိပြီး နှစ်သက်ကြတဲ့ ဒီ ခပ်မိုက်မိုက်ကောင်လေးဟာ အဲဒီနေရာမှာ အံဝင်ခွင်ကျပါပဲ - DevOps မှာ ကြည့်ရကျိုးနပ်တဲ့ အရာတစ်ခု ရှိနေပါတယ်။

ပန်းတိုင်တစ်ခုသတ်မှတ်ခြင်း။

ကျွန်ုပ်တို့သည် လူများကို စုဆောင်းကာ ဝန်ဆောင်မှုကို ရွေးချယ်ကာ ကန့်သတ်ချက်များကို ကြည့်ရှုကာ မည်သည့်လူများကို လွှမ်းမိုးမည်ကို ကျွန်ုပ်တို့ ဆုံးဖြတ်ခဲ့သည်။ အခု ပန်းတိုင်တစ်ခု ချမှတ်ဖို့လိုပြီး အဲဒါက ဖြောင့်သင့်တယ်။ SMART မှ - ငါတို့ချစ်သမျှ။

Specific - သီးခြား.

Measurable - တိုင်းတာနိုင်သော. ဤသည်မှာ အလွန်အရေးကြီးသော SMART အချက်ဖြစ်သည်။ တစ်စုံတစ်ရာကို မတိုင်းတာနိုင်ပါက ၎င်းကို ပြောင်းလဲ၍ သင် မည်သို့ကောင်းသည် သို့မဟုတ် ပိုဆိုးခဲ့သည်ကို နားလည်နိုင်မည်မဟုတ်ပေ။

Achievable - အောင်နိုင်သည်. သင်၏ သီးခြားလိုအပ်ချက်များနှင့် ကိုက်ညီစေရန် ပြုပြင်ပြောင်းလဲမှုများ ပြုလုပ်ပါ။ အကယ်၍ သင်သည် ရှည်လျားသောသမိုင်းကြောင်းနှင့် ကြီးမားသောတာဝန်ဝတ္တရားများရှိသော လုပ်ငန်းကုမ္ပဏီတစ်ခုဖြစ်ပါက၊ တစ်နှစ်လျှင်တစ်ကြိမ် ထုတ်ကုန်ဗားရှင်းတစ်ခုထုတ်လွှတ်ပါက၊ သင်သည် ခြောက်လအတွင်း ထုတ်ကုန်ဗားရှင်းအသစ်များကို တစ်နာရီလျှင်တစ်ကြိမ် ထုတ်ဝေနိုင်မည်မဟုတ်ပေ။ ဤနည်းဖြင့် အလုပ်မဖြစ်ပါ။ ထို့ကြောင့် လက်ခံနိုင်လောက်သော အချိန်အတိုင်းအတာတစ်ခုအတွင်း အောင်မြင်နိုင်သော လက်တွေ့ကျသောပန်းတိုင်ကို ချမှတ်ပါ။

သက်ဆိုင်ရာ - သက်ဆိုင်ရာ။ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏လက်ရှိပန်းတိုင်များကို အမှန်တကယ်ဆောင်ရွက်ပေးနိုင်သော အဆိုပါကန့်သတ်ချက်များကိုသာ ဖယ်ရှားပါသည်။

Time Limited - အချိန်ကန့်သတ်ချက်. နောက်ဆုံးရက်မရှိပါက၊ အဖွဲ့သည် ၎င်းတို့အလိုရှိသည့်အတိုင်း လုပ်ဆောင်နိုင်သည်- 15 အစား နည်းပညာ 3 ခုကို စမ်းကြည့်ပါ၊ ကြီးမားသောအစီရင်ခံစာများရေးပါ၊ အသုံးမကျသောသုတေသနပြုလုပ်ပါ၊ ပန်းတိုင်ရောက်ပြီးသောအခါတွင် တောက်ပလာသည်အထိ ၎င်းတို့၏အကောင်အထည်ဖော်မှုကို တောက်ပြောင်စေသည်။

ကျွန်ုပ်တို့သည် Value Stream Map ကိုအသုံးပြု၍ ပန်းတိုင်ကိုယူသည် - လူအားလုံးကို ထပ်မံစုဆောင်းပြီး ၎င်းတို့ကိုဆွဲပါ။ သို့သော်ယခင် Value Stream Map ကို အခြေခံ၍ ယခုမှသာ ကျွန်ုပ်တို့ ရယူလိုသောအရာကို ရေးဆွဲပါ။

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

ယင်းကိုအခြေခံ၍ ကျွန်ုပ်တို့သည် လုပ်ငန်းတာဝန်ကိုသတ်မှတ်ထားပါသည်- ကျွန်ုပ်တို့သည် ပြီးဆုံးသွားသော လွတ်မြောက်မှုနှင့် တိုက်ပွဲဝင်ခြင်းကြားတွင် စောင့်ဆိုင်းရမည့်အချိန်ကို အများဆုံး တစ်နာရီအထိ ဖြစ်စေလိုပါသည်။

အလုပ်များကို နမူနာများ။

• စမ်းသပ်ချိန်ကို 4 ရက်မှ 1 နာရီသို့လျှော့ချပါ။
• စမ်းသပ်ခြင်းအတွက် 2 ရက်မှ 3 နာရီအထိ တန်ဖိုးထပ်တိုးချိန်ကို လျှော့ချပါ။
• ပို့ဆောင်ချိန်ကို ၅ နာရီမှ ၁၀ မိနစ်အထိ လျှော့ချပါ။
• C/A ကို 50% မှ 95% အထိ တိုးလာသည်၊ ဆိုလိုသည်မှာ၊ စမ်းသပ်သူများ လက်ခံသည့် အင်္ဂါရပ်များ အရေအတွက်ကို တိုးစေသည်၊ တစ်နည်းအားဖြင့်၊ developer များ၏ အလုပ်အရည်အသွေးကို တိုးတက်စေသည်။

လုပ်ဆောင်စရာ နမူနာများကို ကျွန်ုပ်တို့၏ ဦးခေါင်းမှ ယူဆောင်ခြင်း မပြုပါ - ၎င်းတို့သည် Value Stream Map ကို ဖန်တီးရာတွင် ကျွန်ုပ်တို့ ပြုလုပ်ခဲ့သည့် တိုင်းတာမှုများအပေါ် အခြေခံပါသည်။

ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏အဖွဲ့အတွက် အလားတူလုပ်ဆောင်မှုတစ်ခုနှင့် အချိန်ကန့်သတ်ချက်တစ်ခု သတ်မှတ်ခဲ့သည်။ သင့်ကုမ္ပဏီ မည်မျှ ကောင်းစွာ လုပ်ဆောင်နေသည်အပေါ်မူတည်၍ သင်သည် မတူညီသော သတ်မှတ်ရက်များကို သတ်မှတ်သည်။ ပျမ်းမျှအားဖြင့်၊ လူများသည် ဤအရာကို ပထမဆုံးအကြိမ်ပြုလုပ်ပြီး မည်သည့်နည်းပညာနှင့် ပြဿနာကိုမည်ကဲ့သို့ တိတိကျကျဖြေရှင်းမည်ကို မသိသေးပါက ကန့်သတ်ချက်တစ်ခုကို ဖယ်ရှားရန် ပျမ်းမျှအားဖြင့် ခြောက်လကြာတတ်သည်။

အတိုချုံးစီစဉ်ခြင်း။

ဒါကြောင့် ကျွန်တော်တို့အဖွဲ့ကို ဖန်တီးထားပြီး၊ ရည်မှန်းချက်ရှိပြီး လူတွေက စတင်လုပ်ဆောင်နေပါတယ်။ အရေးကြီးသောအချက်မှာ အလုပ်၏အတိုချုံးအစီအစဉ်ဖြစ်သည်။ တစ်ပတ်မှ နှစ်ပတ်အထိ ပြေးသည်။မရှိတော့ဘူး၊ တိုင်းတာနိုင်သောတိုးတက်မှုများ အပတ်တိုင်းနှင့် သင်တန်းပြင်ဆင်ခြင်း။.

ဥပမာအားဖြင့်၊ ကျွန်ုပ်တို့သည် ချဉ်းကပ်မှုကို မကြာခဏအသုံးပြုသည်။ ရွေ့လျားခြင်း။အဖွဲ့တစ်ဖွဲ့လုံးသည် အပတ်တိုင်း၏အစတွင် စုရုံးသောအခါတွင် လူတိုင်းလုပ်မည့်အရာကို ဖိုင်တစ်ခုတွင် ရေးမှတ်ထားသည်။ တစ်ပတ်အကြာတွင် ကျွန်ုပ်တို့သည် ပြီးခဲ့သောအရာနှင့် မလုပ်ရသေးသော အရာများကို မှတ်သားထားပြီး နောက်ဘာလုပ်ရမည်ကို ကျွန်ုပ်တို့ စဉ်းစားကြသည်။

Sprints သည် သင့်အား အချိန်နှင့်တစ်ပြေးညီ သင်တန်းပြင်ဆင်မှုများကို ပြုလုပ်နိုင်စေပါသည်။

တစ်ပတ် သို့မဟုတ် နှစ်ပတ်ကြာအောင် သင် တစ်ခုခုကို ကြိုးစားခဲ့သည်- နည်းပညာများ၊ ချဉ်းကပ်မှုများ၊ လုပ်ဆောင်မှုနည်းလမ်းများ၊ ထို့နောက်တွင် သင်ထပ်မံတိုင်းတာပြီး ကြည့်ပါက- ဤချဉ်းကပ်မှုဖြင့် ၎င်းသည် ပိုကောင်းသလော သို့မဟုတ် ပိုဆိုးလာပါသလား။ ပိုဆိုးပါက၊ ကျွန်ုပ်တို့သည် လမ်းကြောင်းမှားသွားနေသည်ဟုဆိုလိုသည်၊ ကျွန်ုပ်တို့သည် သင်တန်းကို ပြုပြင်ရန် လိုအပ်သည်- မတူညီသောအလုပ်တစ်ခုကို သတ်မှတ်ရန်၊ မတူညီသောနည်းပညာတစ်ခုယူရန် သို့မဟုတ် အခြားတစ်ခုခုကို ပြုလုပ်ရန် လိုအပ်သည်။ 1-2 ပတ်ကြာ အတိုချုံးပြေးခြင်းသည် သင့်အား အချိန်မီ ထိန်းညှိနိုင်ပြီး ဆိုးရွားသော ဆုံးဖြတ်ချက်များကို ရှောင်ရှားနိုင်သည်။

အောင်မြင်မှုကို မျှဝေပါ။

အဖွဲ့သည် အောင်မြင်မှုအချို့၊ သေးငယ်သည်ဖြစ်စေ ကြီးသည်ဖြစ်စေ - အရေးမကြီးပါ၊ ရလဒ်အချို့အမြဲရှိသည်။ ဤရလဒ်အကြောင်း လူတိုင်းသိသင့်သည်- DevOps နှင့် အိမ်နီးနားချင်းဌာနများတွင် ပါဝင်ပတ်သက်သူများ။ စံပြကမ္ဘာတစ်ခုတွင် ဤအရာသည် အလုံးစုံရောက်ရှိရန် နှစ်လိုဖွယ်ကောင်းပေလိမ့်မည်။ ကုမ္ပဏီရှိလူအားလုံးကို.

ဘာအတွက်လဲ? ကျွန်ုပ်တို့သည် ကုမ္ပဏီ၏အစိတ်အပိုင်းတစ်ခုမျှသာမဟုတ်ဘဲ ကန့်သတ်ချက်တစ်ခုမျှသာမဟုတ်ဘဲ ယေဘုယျအားဖြင့် အရာအားလုံးကို ဖယ်ရှားပစ်လိုပါက ကုမ္ပဏီသည် လိုက်လျောညီထွေဖြစ်လာစေရန်၊ ကုဒ်သည် သုံးစွဲသူထံ မြန်မြန်ဆန်ဆန်ရောက်ရှိပြီး မည်သည့်အရာမှ မပျက်စီးစေဘဲ ကျွန်ုပ်တို့အားလုံးသည် အိုင်ဒီယာအပေါ် သစ္စာရှိရန် လိုအပ်ပါသည်။ DevOps ၏ ဝန်ဆောင်မှုများနှင့် ဆန့်ကျင်ဘက်အဖွဲ့များထံ ချဉ်းကပ်မှုကို သင် ကျင့်သုံးနိုင်မည် မဟုတ်ပါ။

သစ္စာရှိမှု ပေါ်လာစေရန်၊ ကျွန်ုပ်တို့ ဤအရာကို ကြိုးစားခဲ့ကြောင်း လူတိုင်းကို ပြောပြရပါမည် - ကျွန်ုပ်တို့တွင် ရလဒ်များ ရှိသည်၊ လည်း စမ်းကြည့်ပါ။ ၎င်းသည် ကျွန်ုပ်တို့လုပ်ဆောင်သည့်အရာအပေါ် စိတ်ဝင်စားမှုနှင့် သစ္စာရှိမှုကို တိုးစေမည်ဖြစ်ပြီး၊ လူများသည် ယခုအချိန်တွင် တစ်ခုခုလုပ်ဆောင်ရန် စတင်ကြိုးစားလာမည်ဖြစ်သည်။ အလေ့အကျင့်ပြသထားသည့်အတိုင်း၊ ကျွန်ုပ်တို့ကြိုးစားခဲ့ရာနှင့် ကျွန်ုပ်တို့အောင်မြင်ခဲ့ကြောင်း သင့်အားပြောပြသောအခါတွင် အခြားအဖွဲ့များက ကျွန်ုပ်တို့လုပ်ဆောင်ခဲ့ပုံနှင့် အဘယ်အရာတို့ကို စတင်မေးမြန်းကြသည်။ ၎င်းတို့သည် အကောင်အထည်ဖော်မှု၊ ကုဒ်၊ စာရွက်စာတမ်းများကို ကြည့်ရှုကာ မေးခွန်းများထုတ်ကာ ၎င်းတို့ကိုယ်တိုင် တစ်ခုခုကို ပြောင်းလဲရန် ကြိုးစားကြသည်။

မင်းလုပ်ခဲ့တာတွေကို ပြောပြဖို့ အရေးကြီးတယ်။ ဤနည်းဖြင့် သင့်စခန်းတွင် ပါဝင်ရန် နည်းလမ်းဟောင်းအားလုံးကို လုပ်ဆောင်လိုသော ရှေးရိုးစွဲဝါဒီများကို ဆွဲဆောင်နိုင်ပြီး ၎င်းတို့အား ဆန်းသစ်တီထွင်သူများအဖြစ် ပြောင်းလဲစေမည်ဖြစ်သည်။

စုစုပေါင်း

ဝန်ဆောင်မှုတစ်ခုရွေးချယ်ခြင်း။စမှတ်တစ်ခုအနေနဲ့ - ကုမ္ပဏီမှာ အပြောင်းအလဲတွေ စတင်မယ့်နေရာ။ ဝန်ဆောင်မှုနှင့် သက်ဆိုင်သူတိုင်းကို ကျွန်ုပ်တို့ ခွဲခြားသတ်မှတ်ပါသည်။ သူတို့နှင့်အတူ Value Stream Map တစ်ခုတည်ဆောက်ခြင်း။ကန့်သတ်ချက်တွေက ဘယ်နေရာမှာရှိသလဲဆိုတာကို တိုင်းတာပြီး ကြည့်ပါတယ်။

ယာယီအသင်းအသစ်တစ်ခုဖန်တီးခြင်း။ပြဿနာကို ဖြေရှင်းပေးမယ့်၊ တိုင်းတာမှုများနှင့် Value Stream Map ကို အခြေခံထားသည်။ ဖြေရှင်းရမယ့် ကန့်သတ်ချက်တွေကို မီးမောင်းထိုးပြတဲ့ မြေပုံအသစ်တစ်ခု ရေးဆွဲပါတယ်။. ဤကန့်သတ်ချက်အပေါ်အခြေခံသည်။ အလုပ်တစ်ခုသတ်မှတ်ပါ။ဘယ်အသင်းက ကိုင်တွယ်မလဲ။ တာဝန်ဖြစ်သင့်သည်။ သေချာပေါက် SMART - တိကျသော၊ တိုင်းတာနိုင်သော၊ လက်ရှိအလုပ်များနှင့် သက်ဆိုင်ပြီး အချိန်အကန့်အသတ်ရှိသည်။

လုပ်ငန်းစဉ်ကို ပြန်လုပ်ပါ။ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုအားလုံးကို လိုအပ်သောပုံစံသို့ ပြောင်းလဲပြီး ကန့်သတ်ချက်များအားလုံးကို ဖယ်ရှားသည်အထိ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ဝန်ဆောင်မှုအားလုံးကို လိုအပ်သောပုံစံသို့ ပြောင်းလဲမမှီပါ။

ဘောနပ်စ်။ အသုံးဝင်သောပစ္စည်းများ

DevOps ကို ကိုယ်တိုင်လုပ်ဖို့ ဆုံးဖြတ်ထားတဲ့သူတွေအတွက်ပါ။

ပရောဂျက် "ဖီးနစ်"

မူရင်းခေါင်းစဉ်မှာ "ဖီးနစ်ပရောဂျက်- ၎င်းနှင့်ပတ်သက်သည့် ဝတ္ထုတစ်ပုဒ်၊ Devops နှင့် သင့်လုပ်ငန်းကို အောင်မြင်အောင် ကူညီပေးခြင်း" ဖြစ်သည်။ ဤသည်မှာ DevOps အကြောင်းဝတ္ထုဖြစ်သည် - ဝန်ထမ်းတစ်ဦးသည် အမြဲတမ်းမီးလောင်နေသောဌာန၏အကြီးအကဲဖြစ်ပုံအကြောင်း ဝတ္ထုတစ်ပုဒ်ဖြစ်သည်။ သူဌေးအသစ်ကို တာဝန်ပေးထားသည်။

"အရာရာတိုင်းမှန်အောင်လုပ်ဖို့ မင်းမှာ နှစ်အနည်းငယ်ပဲရှိတော့ နောက်ဆုံးမှာ ငါတို့ရဲ့ထုတ်ကုန်တွေကို သုံးစွဲသူတွေဆီ မြန်မြန်ဆန်ဆန်နဲ့ ထိထိရောက်ရောက် အရောက်ပို့ပေးနိုင်မှာပါ"

"Project Phoenix" DevOps သည် ဘဝကိုပိုမိုကောင်းမွန်အောင်မည်သို့ပြောင်းလဲစေသည့်ဝတ္ထုတစ်ပုဒ်ဖြစ်သည်” ဟူသည့်ဝတ္ထုသည် မန်နေဂျာများအားလုံးအတွက် စာအုပ်တစ်အုပ်ဖြစ်သည်၊ အကြောင်းမှာ ဤသူများသည် ကုမ္ပဏီတွင်ဖြစ်ပျက်နေသည့်အရာများကို ဆုံးဖြတ်ချက်ချသူများဖြစ်သောကြောင့်ဖြစ်သည်။ အကယ်၍ သင်သည် အင်ဂျင်နီယာ သို့မဟုတ် ပရိုဂရမ်မာတစ်ဦးဖြစ်ပြီး သင့်ကုမ္ပဏီတွင် လှုပ်ရှားမှုနှင့် အသွင်ကူးပြောင်းမှုကို လိုချင်ပါက စာအုပ်တစ်အုပ်ဝယ်ပြီး စီမံခန့်ခွဲရေးထံ ပေးလိုက်ပါ။ ဤဝတ္ထုသည် အရာအားလုံးကို ရှင်းပြထားပြီး လွယ်ကူမြန်ဆန်စွာ ဖတ်နိုင်သည်။

DevOps လမ်းညွှန်

စာအုပ်က ပိုရှုပ်ထွေးတယ်။ ၎င်းကို နည်းပညာအဖွဲ့အစည်းများတွင် ကမ္ဘာ့အဆင့်မီ သွက်လက်မှု၊ ယုံကြည်စိတ်ချရမှုနှင့် လုံခြုံရေးကို ဖန်တီးနည်း" The DevOps Handbook ခေါင်းစဉ်အောက်တွင် အင်္ဂလိပ်ဘာသာဖြင့် ထုတ်ဝေခဲ့သည်မှာ နှစ်အတော်ကြာခဲ့ပြီဖြစ်သော်လည်း ယခုအခါ ရုရှားဘာသာဖြင့် ရရှိနေပြီဖြစ်သည်။ ဒါအမှန်ပဲ။ လက်စွဲစာအုပ် - လက်တွေ့လမ်းညွှန်: တိုင်းတာမှုများပြုလုပ်ပုံ၊ Value Stream Map ကဘာလဲ၊ ဘာကြောင့်လိုအပ်သလဲ၊ ဘယ်ကိုသွားရမလဲ၊ ဘယ်လိုပုံစံနဲ့လုပ်ဆောင်မလဲ။ စာအုပ်သည် အရာရာကို ကိုယ်တိုင်လုပ်လိုသူများအတွက်သာဖြစ်သည်။ အရေးအကြီးဆုံးကတော့ ၎င်းတွင် အခြားကုမ္ပဏီများ၏ အတွေ့အကြုံများ ဥပမာများပါရှိသည်။

ဥပမာအားဖြင့်၊ ကုမ္ပဏီတစ်ခုသည် Value Stream Map ကို မည်သို့တည်ဆောက်ခဲ့ပုံကို ပြောပြပြီး ၎င်း၏ကန့်သတ်ချက်မှာ ကုန်ပစ္စည်းတွင်မရှိသည်ကို နားလည်ထားသော်လည်း ငွေကိုင်သည် ဤထုတ်ကုန်ကိုအသုံးပြုရန် စတိုးဆိုင်မှ နောက်ရုံးတစ်ခုသို့ လျှောက်သွားခြင်းကြောင့်ဖြစ်သည်။ ပရိုဂရမ်ပြဿနာကို ဖြေရှင်းမည့်အစား ၎င်းတို့၏ အရောင်းဝန်ထမ်းများအတွက် တက်ဘလက်များကို ရိုးရှင်းစွာ ဝယ်ယူခဲ့ပြီး ယခုအခါ မည်သည့်နေရာမှ မသွားဘဲ လုပ်ဆောင်မှုများအားလုံးကို ၎င်းတို့၏ လုပ်ငန်းခွင်တွင် လုပ်ဆောင်လျက်ရှိသည်။ နိဂုံးချုပ်- Value Stream Map ကို ဆော့ဖ်ဝဲလ်တွင်သာမက အဖွဲ့အစည်းအတွင်းရှိ လုပ်ငန်းစဉ်အားလုံးကိုလည်း တိုးချဲ့နိုင်ပါသည်။

တိုး။ မြန်စေ

ခေါင်းစဉ်အပြည့်အစုံ- "အရှိန်မြှင့်- ပျော့ပျောင်းသောဆော့ဖ်ဝဲလ်နှင့် DevOps သိပ္ပံ- စွမ်းဆောင်ရည်မြင့်မားသော နည်းပညာအဖွဲ့အစည်းများကို တည်ဆောက်ခြင်းနှင့် ချဲ့ထွင်ခြင်း။" ဒါကနောက်ထပ်အဆင့် - hardcore ။ ဒီစာအုပ်ကို မနှစ်က ထုတ်ဝေခဲ့ပြီး အခုအချိန်အထိ အင်္ဂလိပ်ဘာသာနဲ့သာ သုတေသနပြုထားပါတယ်။ စာရေးဆရာများဖြစ်သည့် Nicole Forsgren၊ Jez Humble နှင့် Gene Kim တို့သည် မတူညီသောကုမ္ပဏီများတွင် မတူညီသောအလေ့အကျင့်များကို နှစ်ပေါင်းများစွာ အသုံးပြုခဲ့ကြပြီး မည်သည့်အလေ့အကျင့်များက မည်သို့အကျိုးသက်ရောက်သည်ကို သုတေသနပြုခဲ့ကြသည်။

ဒုတိယအခန်းတွင်၊ တိုင်းတာခြင်းတွင် Value Stream Map၊ ကျွန်ုပ်ဖော်ပြခဲ့သော မက်ထရစ်များနှင့် အခြားများစွာကို ဖော်ပြထားပြီး တိုင်းတာခြင်းလုပ်ငန်းစဉ်ကိုလည်း အသေးစိတ်ဖော်ပြထားသည်။ စာရေးဆရာများသည် မေးခွန်းပုံစံများနှင့် ကိုယ်တိုင်ခြေရာခံခြင်းလုပ်ငန်းများကို အသုံးပြု၍ တိုင်းတာသည်။ ၎င်းသည် မည်သည့်တိုင်းတာမှုမှန်ကန်ကြောင်း တိုင်းတာရန်၊ မည်သည့်အရာများကို တိုင်းတာသင့်သည်နှင့် တိုင်းတာမှုတွင် လူသားအမှားများကို အသေးစိတ်ဖော်ပြထားသည်။ သင့်တွင် တိုင်းတာမှုအခက်အခဲများရှိပါက "အရှိန်မြှင့်" စာအုပ်၏ ဒုတိယအခန်းကို ကိုးကားပါ။ သင့်အဖွဲ့တွင် အလေ့အကျင့်များစွာရှိသော်လည်း ယခုကျင့်သုံးရမည့်အလေ့အကျင့်များကို ရှင်းရှင်းလင်းလင်းမသိရသေးပါက မည်သည့်အလေ့အကျင့်သည် နောက်ပိုင်းတွင် မည်သည့်အရာက အမှန်တကယ် အလုပ်ဖြစ်ကာ မည်သည့်အရာက မဖတ်ပါက၊ စာအုပ်က အရာအားလုံးကို ရှင်းပြထားသည်။

အသွင်ပြောင်းခြင်းသည် DevOps နှင့် စီမံခန့်ခွဲမှု၏ ဆုံရပ်တွင် ပြဿနာတစ်ခုဖြစ်သည်။ လမ်းဆုံ၏ တူညီသော ဧရိယာတစ်နေရာတွင် ဖွံ့ဖြိုးတိုးတက်မှု၊ လည်ပတ်မှုနှင့် စမ်းသပ်မှုတို့သည် ကျွန်ုပ်တို့ ဆွေးနွေးရန် ကြိုးစားသည့် ခေါင်းစဉ်များ၊ DevOpsConfအရည်အသွေးရှိသော ထုတ်ကုန်တစ်ခုကို ဖန်တီးရန် တူညီသောပေါင်းစပ်မှုသည် လိုအပ်သည် - အဓိကအကြောင်းအရာဖြစ်သည်။ အရည်အသွေးသတ်မှတ်ချက်. ပွဲတော်စီမံခန့်ခွဲမှု RIT++ တင်သွင်းခဲ့သည်။ Whale Rider ဆိုလိုတာက အသွင်ပြောင်းဖို့ စိတ်ကူးစိတ်သန်းတွေ လူတိုင်းမှာ ရှိနေတယ်။ မေလ 27 နှင့် 28 ရက်နေ့တွင်ကျွန်ုပ်တို့နှင့်ပူးပေါင်းပါ၊ ပေါင်းစည်းပြီးအသွင်ပြောင်းပါမည်။

source: www.habr.com