ប្រសិនបើអ្នកមិនយល់ថា DevOps ជាអ្វីទេ នេះជាសន្លឹកបន្លំរហ័ស។ DevOps គឺជាសំណុំនៃការអនុវត្តដែល កាត់បន្ថយការភ័យខ្លាចរបស់វិស្វករ និងកាត់បន្ថយចំនួននៃការបរាជ័យក្នុងការផលិតកម្មវិធី។ តាមក្បួនមួយពួកគេគឺដូចគ្នា។ កាត់បន្ថយពេលវេលាសម្រាប់ទីផ្សារ - រយៈពេលពីគំនិតរហូតដល់ការចែកចាយផលិតផលចុងក្រោយដល់អតិថិជន ដែលអនុញ្ញាតឱ្យអ្នកអនុវត្តបានយ៉ាងឆាប់រហ័ស ការពិសោធន៍អាជីវកម្ម.
តើធ្វើដូចម្តេចដើម្បីចាប់ផ្តើមការផ្លាស់ប្តូរ DevOps? សរុបមក៖ យើងជ្រើសរើសសេវាកម្មដែលត្រូវចាប់ផ្តើមដំណើរការ កំណត់អត្តសញ្ញាណអ្នកដែលទាក់ទងនឹងសេវាកម្ម បង្កើតផែនទីស្ទ្រីមតម្លៃ បង្កើតក្រុមបណ្ដោះអាសន្នដែលនឹងដោះស្រាយការបំប្លែងជាលើកដំបូង និងកំណត់ភារកិច្ចសម្រាប់វា។ យើងធ្វើវដ្តម្តងទៀតនូវចំនួនដងដែលត្រូវការ។
ផែនការផ្លាស់ប្តូរ DevOps លម្អិតជាមួយនឹងឧទាហរណ៍ និងការណែនាំនៅក្រោមការកាត់ - នៅក្នុងប្រតិចារិក Andrey Alexandrov - វិស្វករនៅ Express42 ដែលផ្តល់យោបល់លើដំណុះ DevOps បង្កើនល្បឿនដំណើរការនេះ ព្រោះនាងបានបង្កើតផែនទីតុងរួចហើយ។ ប្រសិនបើវាហាក់ដូចជាអ្នកថាអ្នកមិនត្រូវការការផ្លាស់ប្តូរ ឬជាក់លាក់របស់អ្នកដូចជាការអនុវត្ត DevOps មិនសមរម្យ សូមប្រើរបាយការណ៍ជាការណែនាំសម្រាប់ការស្វែងរក និងលុបបំបាត់ដែនកំណត់។
ប្រសិនបើអ្នកមានការព្រួយបារម្ភអំពីបញ្ហានៃការផ្លាស់ប្តូរ DevOps នោះអ្នកមានក្រុមហ៊ុនធំមួយ ហើយអ្នកត្រូវធ្វើមាត្រដ្ឋានដំណើរការនេះបន្តិចម្តងៗនៅទូទាំងរចនាសម្ព័ន្ធទាំងមូល។ ដរាបណាមានតម្រូវការបំប្លែងពាក្យបញ្ជា ឬលុបបំបាត់ដែនកំណត់មួយចំនួន នោះក្បួនដោះស្រាយខាងក្រោមអាចធ្វើម្តងទៀតបាន។
ការជ្រើសរើសសេវាកម្ម
យើងបានគូសបញ្ជាក់ផែនការមួយ សូមចាប់ផ្តើមជាមួយជំហានដំបូង - ការជ្រើសរើសសេវាកម្ម។ លក្ខណៈវិនិច្ឆ័យដំបូងគឺពេញមួយជីវិត៖ មានសេវាកម្មចាស់ - កេរ្តិ៍ដំណែល និងសេវាកម្មថ្មី។ អ្នកអាចចាប់ផ្តើមជាមួយទាំងពីរ។
វាសមហេតុផលក្នុងការជ្រើសរើសសេវាកម្មវ័យក្មេង. វាស្រស់ មិនទាន់មានដំណើរការដែលបានបង្កើតឡើងសម្រាប់ធ្វើការនៅក្នុងក្រុមដែលដោះស្រាយជាមួយវានៅឡើយ។ មិនមានភ្នំនៃបំណុលបច្ចេកទេសនៅជុំវិញវា អ្នកមិនចាំបាច់ជួសជុលវាគ្រប់ពេលនោះទេ។ យើងអាចធ្វើអ្វីដែលយើងចង់បានជាមួយវា។
នៅក្នុងករណីនៃសេវាចាស់មានបញ្ហាទាក់ទងនឹងការពិតដែលថា ការផ្លាស់ប្តូរគឺតែងតែពិបាក. មានការរឹតបន្តឹងធ្ងន់ធ្ងរមួយចំនួនរួចហើយ ប៉ុន្តែប្រហែលជាពួកគេកំពុងត្រូវបានដោះស្រាយដោយមនុស្សដែលត្រៀមខ្លួនរួចជាស្រេចដើម្បីរុះរើអ្វីគ្រប់យ៉ាង - ពួកគេហត់នឿយ ហើយចង់ធ្វើអ្វីផ្សេងដោយសារតែពួកគេឈឺចាប់។
ការធ្វើការជាមួយសេវាកម្មចាស់កំណត់គំរូដ៏មានឥទ្ធិពល នៅក្នុងក្រុមហ៊ុនរបស់អ្នក - អ្នកអាចផ្លាស់ប្តូរអ្វីមួយ។ ប្រសិនបើអ្នកផ្លាស់ប្តូរសេវាកម្មថ្មី វានឹងធ្លាក់ចុះ 100 ដងក្នុងមួយម៉ោង ហើយអ្វីៗគឺល្អ នោះមនុស្សនៅក្នុងក្រុមហ៊ុនរបស់អ្នកអាចនិយាយថា៖
- នេះជាសេវាកម្មថ្មី! អ្វីគ្រប់យ៉ាងគឺសាមញ្ញនៅទីនោះ ព្យាយាមធ្វើអ្វីមួយជាមួយនឹងការខូចខាតរបស់យើង។
វាសមហេតុផលក្នុងការប្រើសេវាកម្មកេរ្តិ៍ដំណែលសម្រាប់ការផ្លាស់ប្តូរ នៅពេលអ្នកធ្វើវាជាមួយនរណាម្នាក់ ឧទាហរណ៍ ប្រសិនបើអ្នកបានអញ្ជើញអ្នកប្រឹក្សាខាងក្រៅ។ ចូរនិយាយដោយស្មោះត្រង់ ការផ្លាស់ប្តូរនឹងអង្រួនអ្វីគ្រប់យ៉ាងដែលអាចធ្វើទៅបាន. អ្នកកំពុងពិសោធ ហើយមិនដឹងថាអ្នកនឹងបញ្ចប់នៅទីណា បច្ចេកវិទ្យាអ្វីដែលអ្នកនឹងប្រើ ហើយហេតុអ្វី កន្លែងណា និងបញ្ហាអ្វីខ្លះដែលនឹងកើតឡើងនៅក្នុងដំណើរការ។ ដូច្នេះវាកាន់តែងាយស្រួលក្នុងការផ្លាស់ប្តូរថ្មី។
ប្រសិនបើអ្នកធ្វើអ្វីៗគ្រប់យ៉ាងដោយខ្លួនឯង ហើយក្រុមហ៊ុនមិនមានសមត្ថកិច្ចធ្ងន់ធ្ងរទេ យើងទទួលយកសេវាកម្មថ្មី។ ប្រសិនបើអ្នកស្គាល់អ្នកប្រឹក្សាខាងក្រៅ និងមានមូលនិធិ សូមជ្រើសរើសអ្នកចាស់។
មានសេវាកម្មដែលគ្រាន់តែជាចំណុចប្រទាក់សម្រាប់អ្នកប្រើប្រាស់ ឧទាហរណ៍ គេហទំព័រសាមញ្ញ ឬកម្មវិធីទូរស័ព្ទ។ ប៉ុន្តែមានរឿងធ្ងន់ធ្ងរនៅក្នុងស្មារតីនៃការចេញវិក្កយបត្រ។ ប្រសិនបើមានអ្វីខុសជាមួយការចេញវិក្កយបត្រ វានឹងពិបាកក្នុងការដោះស្រាយ។ នៅទីនេះយើងក៏មានជម្រើសផងដែរ។
យើងក៏ធ្វើការដែរ។ ជាមួយនឹងសេវាកម្មសំខាន់ប៉ុន្តែយើងរងទុក្ខដោយសារតែវា វាបង្កើតការរឹតបន្តឹង ឬយើងធ្វើការ ជាមួយចំណុចប្រទាក់. នេះគឺជាលក្ខខណ្ឌជ្រើសរើសទីពីរ។ ដូចគ្នានេះដែរវាអាចទៅរួចដើម្បីទាក់ទាញអ្នកពិគ្រោះយោបល់ដែលមានបទពិសោធន៍ - យើងធ្វើការជាមួយជម្រើសពិបាក។
ប៉ុន្តែទោះបីជាក្នុងករណីនេះក៏ដោយ ខ្ញុំមិនណែនាំឱ្យធ្វើបែបនេះទេ ព្រោះទាល់តែមានការយល់ដឹងអំពីអ្វីដែលត្រូវធ្វើការជាមួយ និងក្នុងទិសដៅណាដែលត្រូវផ្លាស់ប្តូរ ការទទួលយករឿងសំខាន់ ហើយរង្គោះរង្គើវាមិនមែនជាគំនិតល្អទេ។ ដូច្នេះ ក្នុងករណីនេះ យើងចូលចិត្តធ្វើការជាមួយចំណុចប្រទាក់ដែលការបរាជ័យមិនសំខាន់។
តោះមើលបន្ថែមទៀត ក្រុមសេវាកម្ម. យើងនឹងត្រូវធ្វើការឥតឈប់ឈរ និងមានទំនាក់ទំនងយ៉ាងជិតស្និទ្ធជាមួយអ្នកដែលផ្តល់សេវាកម្មនេះ។
មនុស្សនៅក្នុងក្រុមត្រូវបានបែងចែកជាពីរប្រភេទ៖ អ្នកអភិរក្ស — រស់នៅក្នុងពិភពលោកចាស់ ឬគ្រាន់តែមិនដឹងអ្វីទាំងអស់អំពី DevOps និង អ្នកច្នៃប្រឌិតដែលទាញការអនុវត្តម៉ូតទាំងអស់។ ក្រោយមកទៀតមិនតែងតែយល់ពីប្រធានបទនោះទេប៉ុន្តែយ៉ាងហោចណាស់ពួកគេត្រៀមខ្លួនសម្រាប់វា។
ម៉្យាងវិញទៀត អ្នកអភិរក្សគឺជាមនុស្សដែលមានបទពិសោធន៍៖ ពួកគេនៅក្នុងក្រុមហ៊ុនយូរមកហើយ ពួកគេយល់ពីវាទាំងខាងក្នុង និងខាងក្រៅ ប៉ុន្តែពួកគេមិនដឹងច្បាស់អំពីការអនុវត្តនោះទេ។ ម្យ៉ាងវិញទៀត មានអ្នកច្នៃប្រឌិតដែលបានឮអ្វីមួយ ប៉ុន្តែភាគច្រើនទំនងជាមិនបានធ្វើការនៅក្នុងក្រុមហ៊ុននេះយូរណាស់មកហើយ។ តើមួយណាល្អជាងដើម្បីធ្វើការជាមួយ?
អ្នកនឹងត្រូវធ្វើអន្តរកម្មជាមួយអ្នកអភិរក្សក្នុងករណីណាក៏ដោយ ព្រោះនេះជាសេវាកម្មរបស់ពួកគេ។ អ្នកនឹងត្រូវប្រាស្រ័យទាក់ទងជាមួយពួកគេ ស្វែងយល់ពីភាពជាក់លាក់នៃសេវាកម្ម អ្វីដែលអាចធ្វើបានតាមវិធីនេះ និងអ្វីផ្សេងទៀត។ យើងពឹងផ្អែកលើដំបូន្មានរបស់ពួកគេ។ អ្នកប្រហែលជាត្រូវប្រគល់ឱ្យពួកគេនូវអ្វីមួយ ពីព្រោះពួកគេដឹងពីសេវាកម្មរបស់ពួកគេប្រសើរជាង។ ដូច្នេះ វាសំខាន់ណាស់ថាតើក្រុមណាដែលយើងបញ្ចប់ទំនាក់ទំនង។
វាជាការសមហេតុផលក្នុងការជ្រើសរើសអ្នកច្នៃប្រឌិតសម្រាប់ក្រុម ពីព្រោះអ្នកអភិរក្សអាចដាក់ជ្រូកនៅក្នុងវា។
នៅក្នុងការអនុវត្ត វាជារឿយៗកើតឡើងដែលមនុស្សអភិរក្សមានបទពិសោធន៍សំខាន់ៗ ប៉ុន្តែមិនមានការយល់ដឹងអំពីរបៀបរស់នៅបន្តទៀត។ ពួកគេគ្រាន់តែភ័យខ្លាចថា បន្ទាប់ពីការផ្លាស់ប្តូរ និងការរៀបចំឡើងវិញនៃសេវាកម្មនេះ ពួកគេនឹងត្រូវបានបណ្តេញចេញពីការងារដោយមិនចាំបាច់។ ពេលខ្លះ ដោយសារតែពួកគេមិនយល់ថាមានអ្វីកើតឡើង ពួកគេបំផ្លាញការងារ។
ខ្ញុំមានករណីដែលបុរសម្នាក់មកពីក្រុមបានជួសជុលអ្វីគ្រប់យ៉ាងព្រោះវាជាការរិះគន់ខ្លាំងជាងអ្វីដែលយើងកំពុងធ្វើឥឡូវនេះ។ យើងបានកំណត់ភារកិច្ច: ដើម្បីអនុវត្តបំណែកនេះនៅថ្ងៃនេះ - ទេមានភ្លើងនៅផ្នែកម្ខាងទៀតនៃពិភពលោកយើងនឹងជួសជុលវា។ វាពិបាកក្នុងការធ្វើការជាមួយមនុស្សបែបនេះ។
មនុស្សមកពីក្រុមអភិរក្សតែងតែភ្លេចអំពីកិច្ចការ ឬដាក់ពួកគេរហូតដល់នាទីចុងក្រោយ។ ហើយប្រសិនបើ John Willis ហាមឃាត់ អ្នកបានធ្វើខុស ហើយបានកំណត់ KPI ដល់ពួកគេសម្រាប់ចំនួនកិច្ចការដែលបានបញ្ចប់ ហើយសម្រាប់ហេតុផលខ្លះផ្នែកខ្លះមិនត្រូវបានបញ្ចូលក្នុង KPI នោះពួកគេនឹងមិនធ្វើអ្វីទាំងអស់។ ជាទូទៅពួកគេនឹងត្រឹមត្រូវព្រោះបន្ទាប់មកពួកគេបាត់បង់ប្រាក់រង្វាន់។
វាកាន់តែងាយស្រួលជាមួយអ្នកច្នៃប្រឌិត - ពួកគេស្មោះត្រង់ជាង. គេបានឮរឿងមួយរួចហើយចង់ទៅកន្លែងណាក៏គេជួយ។ យើងត្រូវការមនុស្សដែលត្រៀមខ្លួនទទួលរងទុក្ខជាលើកដំបូង៖ ប្រសិនបើសេវាកម្មផ្លាស់ប្តូរ នោះអ្នកបង្កើតថ្មីនឹងចាប់ដៃគូទាំងអស់ជាអ្នកត្រួសត្រាយ។ អ្នកច្នៃប្រឌិតចង់បានអ្វីគ្រប់យ៉ាងថ្មី និងទាន់សម័យ ហើយរងទុក្ខ។
អ្នកអភិរក្សអាចផ្លាស់ប្តូរនៅពេលក្រោយ។ នៅពេលអ្នកបង្ហាញថាអ្នកបានផ្លាស់ប្តូរមួយដុំ ហើយអ្វីៗដំណើរការល្អ ពួកគេទំនងជានឹងចង់សាកល្បងវាផងដែរ ហើយនឹងទទួលយកសាសនា DevOps ថ្មី។
ចូរយើងសង្ខេប។ ប្រសិនបើយើងធ្វើការផ្លាស់ប្តូរទាំងស្រុងនៅក្នុងក្រុមហ៊ុនរបស់យើងដោយខ្លួនឯង នោះយើងជ្រើសរើស៖ សេវាកម្មថ្មី និយមប្រើចំណុចប្រទាក់សាមញ្ញ ដើម្បីកុំឱ្យរងទុក្ខច្រើនពេកពីការបែកបាក់របស់វា និងក្រុមអ្នកច្នៃប្រឌិត។
បើអាចហៅអ្នកប្រឹក្សាខាងក្រៅមក ជំនួសឲ្យអ្នកថ្មីយកសេវាចាស់ ព្រោះយើងរងទុក្ខហើយ។ មនុស្សដែលបានចូលរួមក្នុងការផ្លាស់ប្តូរអស់រយៈពេលជាយូរនៅក្នុងក្រុមហ៊ុនផ្សេងៗគ្នាបានមើលឃើញករណីផ្សេងៗគ្នាហើយយល់រួចហើយពីរបៀបធ្វើវាឱ្យត្រឹមត្រូវហើយទិសដៅដែលត្រូវទៅជាទូទៅ។
តើអ្នកណាពាក់ព័ន្ធ?
យើងត្រូវស្វែងរកអ្នកគ្រប់គ្នាដែលមានទំនាក់ទំនងយ៉ាងតិចជាមួយសេវាកម្មនេះ៖ អ្នកអភិវឌ្ឍន៍ អ្នកសាកល្បង អ្នកគ្រប់គ្រង អ្នកឯកទេសសុវត្ថិភាព អ្នកគ្រប់គ្រង និងប្រហែលជា ម្ចាស់ផលិតផល។ ទោះបីជាការពិតដែលថាម្ចាស់ផលិតផលមិនមែនជាអ្នកឯកទេសបច្ចេកទេសក៏ដោយក៏ពួកគេទាក់ទងនឹងសេវាកម្ម: ពួកគេធ្វើការសម្រេចចិត្តកំណត់ភារកិច្ច។
មនុស្សគ្រប់រូបដែលធ្វើការសម្រេចចិត្តយ៉ាងហោចណាស់ខ្លះ និងមានឥទ្ធិពលលើអ្វីដែលកើតឡើងជាមួយសេវាកម្ម ចាំបាច់ត្រូវស្វែងរក ជួប និងទំនាក់ទំនង។
តើយើងត្រូវការពួកគេសម្រាប់អ្វី? ដើម្បីដឹងថាត្រូវចរចាជាមួយអ្នកណា. ក្នុងអំឡុងពេលនៃការផ្លាស់ប្តូរ នៅពេលដែលគោលការណ៍ធម្មតានៃការធ្វើការជាមួយសេវាកម្មផ្លាស់ប្តូរ វានឹងនៅតែញ័រ។ វានឹងមានកំហុសមួយរយៈខណៈពេលដែលយើងសាកល្បងវិធីសាស្រ្តថ្មី។ មនុស្សត្រូវតែត្រៀមខ្លួនសម្រាប់រឿងនេះ ហើយយល់ព្រមជាមួយវា។
បន្ទាប់មកទៀត អ្នកនឹងត្រូវបង្កើត Value Stream Map ហើយបើគ្មានមនុស្សទាំងនេះទេ អ្នកនឹងមិនអាចបង្កើតវាបានទេ ព្រោះមានតែពួកគេទាំងអស់គ្នាប៉ុណ្ណោះដែលដឹងពីរូបភាពពេញលេញនៃអ្វីដែលកំពុងកើតឡើង។ មនុស្សម្នាក់មិនដែលដឹងពីអ្វីគ្រប់យ៉ាងដែលកើតឡើងជាមួយសេវាកម្មនោះទេ។
ពួកគេនឹងណែនាំមនុស្សសម្រាប់ក្រុម។ ពេលក្រោយ យើងនឹងពិភាក្សាអំពីមូលហេតុដែលក្រុមដាច់ដោយឡែកមួយត្រូវការ។ វានឹងត្រូវយកមនុស្សពីនាយកដ្ឋានដែលមានស្រាប់។ អ្នកដែលចូលរួមក្នុងសេវាកម្មនឹងអាចណែនាំសហការីដែលគិតក្នុងទិសដៅរបស់យើង ដែលអាចជួយយើង និងមានសមត្ថភាពក្នុងអ្វីដែលយើងត្រូវការ។
បន្ទាប់មក យើងប្រមូលផ្តុំមនុស្សទាំងអស់នេះមកពីនាយកដ្ឋានផ្សេងៗគ្នា ចូលទៅក្នុងបន្ទប់តែមួយ ហើយចាប់ផ្តើមបង្កើតផែនទីស្ទ្រីមតម្លៃ។
ការកសាងផែនទីស្ទ្រីមតម្លៃ
Value Stream Map គឺជាដ្យាក្រាម ឬផែនទីដែលបង្ហាញពីលំហូរនៃតម្លៃទៅកាន់អតិថិជន. នេះគឺជាដំណើរការទាំងមូលចាប់ពីគំនិតមួយដល់ការអនុវត្ត រួមទាំងដំណាក់កាលមធ្យមទាំងអស់ និងរបៀបដែលតម្លៃចុងក្រោយទទួលបានដល់អតិថិជនរបស់យើង។
ផែនទីស្ទ្រីមតម្លៃគឺចាំបាច់ដើម្បី ស្រមៃមើលគ្រប់ដំណាក់កាលនៃការអភិវឌ្ឍន៍ធ្វើមូលដ្ឋានីយកម្មបញ្ហាតាមរយៈការវាស់វែងដែលមាននៅក្នុងដំណើរការបច្ចុប្បន្ន ហើយចាប់ផ្តើមលុបបំបាត់បញ្ហាទាំងនេះ និង កំណត់គោលដៅដំបូង. នេះជាកន្លែងដែលយើងចាប់ផ្តើមធ្វើអ្វីមួយ។
ម៉ែត្រ
មានម៉ែត្រខុសគ្នាជាច្រើនដែលបានពិពណ៌នានៅក្នុងអក្សរសិល្ប៍ Value Stream Map ប៉ុន្តែគ្រាន់តែបីគឺគ្រប់គ្រាន់ដើម្បីឱ្យយើងចាប់ផ្ដើម។
ពេលវេលានាំមុខ - ពន្យារពេល / រង់ចាំ - ពេលវេលាដែលយើងកំពុងរង់ចាំអ្វីមួយ។ ឧទាហរណ៍ អ្នកសាកល្បងរង់ចាំរហូតដល់កន្លែងសាកល្បងទំនេរ ហើយក្នុងអំឡុងពេលនេះមិនអាចធ្វើអ្វីបានទេ។
ពេលវេលាបន្ថែមតម្លៃ - ពេលវេលាការងារមានប្រយោជន៍ - អ្វីដែលយើងបានចំណាយក្នុងដំណាក់កាលបែបនេះដើម្បីបង្កើតតម្លៃចុងក្រោយសម្រាប់អ្នកប្រើ។ ជាឧទាហរណ៍ អ្នកសាកល្បងបានចាប់ផ្ដើមការសាកល្បងរបស់គាត់ ហើយចាប់ផ្ដើមពិនិត្យមើលអ្វីមួយ។ នេះគឺជាពេលវេលានៃការងារដែលមានប្រយោជន៍ នៅពេលដែលយើងធ្វើអ្វីមួយសម្រាប់ផលិតផល។ នេះគឺជាអ្វីដែលអតិថិជនចំណាយសម្រាប់ - កម្មវិធីដែលមានគុណភាព។
%C/A គឺជាភាគរយនៃការងារដែលទទួលយក។ យើងមានដំណាក់កាលមួយ - ការអភិវឌ្ឍន៍ដំណាក់កាលទីពីរ - ការធ្វើតេស្ត។ តើចំនួនអ្នកសាកល្បងលក្ខណៈពិសេសប៉ុន្មានដែលទទួលយកពីអ្នកអភិវឌ្ឍន៍គឺជាភាគរយនេះ។
នេះគឺជាអ្វីដែលផែនទីរបស់យើងមើលទៅដូចនោះ។
វាអាចមើលទៅខុសគ្នាអាស្រ័យលើរចនាសម្ព័ន្ធរបស់អង្គការ ចំនួននាយកដ្ឋាន និងអ្វីដែលអ្នកធ្វើ។ ប៉ុន្តែជាទូទៅ វានឹងមានពីរដំណាក់កាលនៅលើផែនទី៖ គំនិតនេះ и ការវិភាគ. នៅដំណាក់កាលនេះ ទិន្នន័យត្រូវបានរំពឹងទុក ឧទាហរណ៍ ពេលវេលានាំមុខ 2 សប្តាហ៍ និងតម្លៃបន្ថែម 2 ថ្ងៃ។
យើងគ្របដណ្តប់គ្រប់ដំណាក់កាលទាំងអស់ជាមួយនឹងម៉ែត្រ។
Backlog - តើមានបញ្ហាប៉ុន្មានបន្ទាប់ពីអ្នកវិភាគចេញមក។
ការអភិវឌ្ឍន៍ - តើរយៈពេលប៉ុន្មានសប្តាហ៍ដែលអ្នកអភិវឌ្ឍន៍បានរង់ចាំការបំភ្លឺអំពីកិច្ចការ ជំហរ ឬឧបករណ៍ - វាមិនមានបញ្ហាអ្វីទេ ប៉ុន្តែពួកគេកំពុងរង់ចាំអ្វីមួយ។ ជាឧទាហរណ៍ វាត្រូវចំណាយពេល 4 ថ្ងៃដើម្បីអនុវត្តមុខងារមួយ។ នេះគឺជាកន្លែងដែលម៉ែត្រ %C/A ចូលមក។ អ្នកអភិវឌ្ឍន៍បានយកតែ 80% នៃកិច្ចការពី Backlog ប៉ុណ្ណោះ។ ពួកគេជឿថា 20% ដែលនៅសេសសល់មិនទាន់មានលក្ខណៈបច្ចេកទេសច្បាស់លាស់ទេ ហើយបានបញ្ជូនពួកគេទៅពិនិត្យ។
សាកល្បង. ដ្យាក្រាម LT ត្រូវបានកំណត់ទៅ 4 ថ្ងៃ។ ឧទាហរណ៍ អ្នកសាកល្បងកំពុងរង់ចាំកៅអីសាកល្បងដោយឥតគិតថ្លៃ VA ពួកគេពិតជាកំពុងសាកល្បងអ្វីមួយរយៈពេល 2 ថ្ងៃ ហើយ %C/A = 40% ។ - មានតែ 40% នៃកូដ ឬលក្ខណៈពិសេសដែលផ្ញើដោយអ្នកអភិវឌ្ឍន៍ត្រូវបានចាត់ទុកថាគ្រប់គ្រាន់ដោយអ្នកសាកល្បង។ ពួកគេមិនចូលចិត្តអ្វីផ្សេងទៀតសម្រាប់ហេតុផលមួយចំនួន។
ខ្ញុំនឹងមិនរស់នៅលម្អិតអំពីរបៀបអនុវត្តការវាស់វែងទាំងនេះទេ នៅចុងបញ្ចប់នៃអត្ថបទខ្ញុំនឹងណែនាំអក្សរសិល្ប៍ដែលអ្នកអាចរៀនអំពីពួកគេ។
រឿងតែមួយគត់ដែលខ្ញុំអាចណែនាំបាននោះគឺថាអ្នកមិនទុកចិត្តមនុស្សដែលនឹងចងក្រងផែនទីស្ទ្រីមតម្លៃជាមួយអ្នកទេ។ ពួកគេផ្តល់គំនិតអំពីរយៈពេលដែលដំណើរការផ្សេងៗគ្នាត្រូវចំណាយពេល ប៉ុន្តែការប៉ាន់ស្មានទាំងនេះមិនតែងតែត្រឹមត្រូវទេ ដូច្នេះវាជាការល្អបំផុតក្នុងការវាស់វែងខ្លួនឯង។
យើងមានករណីមួយនៅពេលដែលយើងមកនាយកដ្ឋានប្រតិបត្តិការ ហើយបានសួរថាតើវាត្រូវចំណាយពេលប៉ុន្មានដើម្បីផ្តល់មុខងារថ្មីដល់ផលិតកម្ម។ ពួកគេបានប្រាប់យើងថា វានឹងមានរយៈពេល 10 នាទី ហើយយើងគិតថា ហេតុអ្វីបានជាយើងមកក្រុមហ៊ុននេះ? វាប្រែថា 10 នាទីគឺជាពេលវេលាដំណើរការនៃស្គ្រីបដែលយកកូដហើយបញ្ជូនវាទៅម៉ាស៊ីនមេ។ ប៉ុន្តែមុននេះ ការចេញផ្សាយនេះស្ថិតនៅលើម៉ាស៊ីនមេរយៈពេល XNUMX ថ្ងៃ ហើយកំពុងប្រមូលធូលី - មានភារកិច្ចមួយនៅក្នុង Backlog ដែលត្រូវការដាក់ឱ្យប្រើប្រាស់។ វាប្រែថាមុនពេលដំណាក់កាលដាក់ពង្រាយមានដំណាក់កាលរង់ចាំនៅពេលដែលគម្រោងគ្រាន់តែអង្គុយនៅទីនោះ។ ប្រសិនបើយើងមិនបានទៅជាមួយ notepad មិនបានចាប់អារម្មណ៍លើកិច្ចការនៅក្នុង Jira ហើយចាប់ផ្តើមតាមដានវាមួយជំហានម្តងៗ នោះយើងនឹងគិតថាអ្វីគ្រប់យ៉ាងគឺអស្ចារ្យ ហើយគ្មានបញ្ហាអ្វីនោះទេ។
ដូច្នេះហើយ អ្នកនឹងនៅតែត្រូវធ្វើការវាស់វែងដោយខ្លួនឯង ដោយនិយមច្រើនជាងមួយដង ដើម្បីមានគំនិតជិតស្និទ្ធនឹងការពិត។ អាស្រ័យលើ Value Stream Map អ្នកនឹងសម្រេចចិត្តកន្លែងដែលត្រូវចាប់ផ្តើម និងអ្វីដែលត្រូវជួសជុលមុន។
ក្រុមបណ្តោះអាសន្ន
ក្រុមហ៊ុនជាច្រើនដែលសម្រេចចិត្តអនុវត្ត DevOps បង្កើតក្រុមមួយ ប៉ុន្តែមិនមែនជាបណ្ដោះអាសន្នទេ ប៉ុន្តែជាក្រុមមួយដែលមានរយៈពេលជាច្រើនឆ្នាំ។ ប្រសិនបើអ្នកចូលទៅកាន់សេវាកម្មសុំទោស DevOps ដែលពណ៌នាអំពីគំរូផ្សេងៗសម្រាប់ការកសាងរចនាសម្ព័ន្ធស្ថាប័ននៅក្នុង DevOps អ្នកនឹងយល់ថានេះគឺជាការប្រឆាំងនឹងគំរូ។
នៅពេលដែលក្រុម DevOps មានជាបន្តបន្ទាប់អស់រយៈពេលជាច្រើនឆ្នាំ នេះគឺជាកំហុសដ៏ធំមួយ ពីព្រោះ DevOps និយាយអំពីការទំនាក់ទំនងរវាងនាយកដ្ឋាន អំពីល្បឿន និងប្រសិទ្ធភាព។
ប្រសិនបើក្រុមមួយមានរវាងនាយកដ្ឋានដើម្បីធ្វើអ្វីផ្សេងដាច់ដោយឡែក ហើយមានរយៈពេលយូរ នោះវានឹងបង្កើតរបាំងដែលមិនចាំបាច់។ ឥឡូវនេះ អ្នកសរសេរកម្មវិធី ជំនួសឱ្យការទៅជួបអ្នកគ្រប់គ្រងភ្លាមៗ ដើម្បីដោះស្រាយបញ្ហា ត្រូវតែទាក់ទងទៅនាយកដ្ឋាន DevOps ជាមុនសិន ហើយគាត់នឹងបន្តទៅមុខទៀត។
ដូច្នេះ ដើម្បីចាប់ផ្តើម អ្នកត្រូវបង្កើតក្រុមបណ្តោះអាសន្ន. វានឹងមានលក្ខខណ្ឌសម្រាប់រយៈពេលប្រាំមួយខែ អតិបរមាក្នុងមួយឆ្នាំ អាស្រ័យលើកិច្ចការដែលមាននៅក្នុងដៃ ដើម្បីលុបបំបាត់ដែនកំណត់មួយដែលយើងបានជ្រើសរើស។ បន្ទាប់មកនាងនឹងស្លាប់។ ប្រសិនបើយើងជ្រើសរើសចំណុចបន្ទាប់ដែលយើងមានការឈឺចាប់ខ្លាំង ហើយដឹងថាយើងក៏ត្រូវការក្រុមដាច់ដោយឡែកសម្រាប់នោះ យើងនឹងបង្កើតវាម្តងទៀត។ ប៉ុន្តែក្រុមបែបនេះមិនគួរមាន "នៅលើមូលដ្ឋានអចិន្រ្តៃយ៍" ទេ - បន្ទាប់មកពួកគេគ្រាន់តែរំខានការទំនាក់ទំនង ហើយជាទូទៅធ្វើកិច្ចការដាច់ដោយឡែកពីគ្នាដើម្បីសម្រេចកិច្ចការអ្វីមួយ។ កិច្ចការទាំងនេះប្រហែលជាមិនទាក់ទងនឹង DevOps ឬការផ្លាស់ប្តូរទាល់តែសោះ។ ហេតុអ្វីបានជាយើងមិនផ្តល់ភារកិច្ចនេះដល់នាយកដ្ឋានដែលមានស្រាប់?
ហេតុអ្វីបានជាត្រូវការក្រុមបណ្តោះអាសន្ន?
ជម្លោះជាមួយដំណើរការបច្ចុប្បន្ន. ការបំប្លែង DevOps មិនមែនគ្រាន់តែជាការផ្លាស់ប្តូរនៅក្នុងបច្ចេកវិទ្យា និងឧបករណ៍ដែលយើងប្រើនោះទេ ប៉ុន្តែជាការផ្លាស់ប្តូរនៅក្នុងដំណើរការនៃការងារ ការគិត និងតម្លៃ។ ប្រសិនបើក្រុមធ្វើការតាមរបៀបដែលវាធ្លាប់ប្រើរួចហើយ វានឹងមិនអាចសាកល្បងវិធីផ្សេងទៀតបានទេ។
មនុស្សទាំងនេះត្រូវរស់នៅដោយច្បាប់ផ្សេងៗគ្នា៖ មិនអើពើ KPIs ទាំងអស់នៅក្នុងក្រុមហ៊ុនព្រោះពួកគេកំពុងព្យាយាមធ្វើការខុសគ្នា។ ក្រុមបណ្តោះអាសន្ននឹងមិនបំពេញពាក្យសុំដើម្បីទទួលបានម៉ាស៊ីនមេទេ ប៉ុន្តែនឹងទៅដោយផ្ទាល់ទៅកាន់នាយកដ្ឋានដែលគ្រប់គ្រងពួកគេ ដោយទាមទារឱ្យពួកគេផ្តល់អ្វីដែលពួកគេត្រូវការជាមុន ព្រោះវាជាអាទិភាព និងដោយសារតែពួកគេកំពុងព្យាយាមរស់នៅខុសគ្នា។ ក្រុមនេះមានជម្លោះពេញលេញជាមួយដំណើរការបច្ចុប្បន្នទាំងអស់។ ដើម្បីធានាថាការអនុវត្តការងារដែលមានស្រាប់មិនជ្រៀតជ្រែកជាមួយពួកគេឥឡូវនេះ ហើយពួកគេមិនជ្រៀតជ្រែកជាមួយអ្នកដទៃ យើងដាក់មនុស្សទាំងនេះឱ្យនៅដាច់ដោយឡែកជាក្រុមដាច់ដោយឡែកមួយ។
ជៀសវាងការិយាធិបតេយ្យក្នុងការពិសោធន៍. ក្រុមបណ្ដោះអាសន្នមិនមានការិយាធិបតេយ្យ ពួកគេមិនដាក់របាយការណ៍ពេលវេលា ពួកគេមិនរាយការណ៍ទៅអ្នកគ្រប់គ្រង។ នេះគឺជាពិភពដាច់ដោយឡែកទាំងស្រុងដែលមនុស្សរស់នៅ ហើយគិតខុសគ្នា និងធ្វើរឿងខុសគ្នាទាំងស្រុង។ មិនចាំបាច់រំខានពួកគេម្តងទៀតទេ។
ការងារមិនឈប់ឈរលើសេវាកម្ម. នៅក្នុងចំណុចទីមួយ យើងបានជ្រើសរើសអ្វីមួយដែលយើងនឹងពិសោធន៍។ ការពិសោធ និងស្វែងរកវិធីដើម្បីធ្វើការឱ្យកាន់តែប្រសើរឡើងគឺល្អ ប៉ុន្តែយើងក៏ចង់បង្កើតលក្ខណៈពិសេសផងដែរ។ ប្រសិនបើក្រុមទាំងមូលផ្តោតលើការបំប្លែងជាជាងមុខងារ នោះយើងនឹងចាប់ផ្តើមបាត់បង់ប្រាក់ចំណូល កំហុសនឹងនៅជាប់ក្នុងរយៈពេលយូរ - យើងមិនត្រូវការវាទេ។ ការបង្កើតក្រុមបណ្តោះអាសន្នអនុញ្ញាតឱ្យអ្នកធ្វើការពិសោធន៍ដោយមិនបញ្ឈប់ការងារលើផលិតផល។
កុំខ្ជះខ្ជាយពេលវេលាលើការងារ. វានិយាយអំពីផលិតផលម្តងទៀត។ វាត្រូវការពេលវេលាច្រើនសម្រាប់ក្រុមដើម្បីសាកល្បងឧបករណ៍ និងវត្ថុផ្សេងៗ។ វានឹងត្រូវចំណាយពេលយ៉ាងហោចណាស់ប្រាំមួយខែសម្រាប់មនុស្សដើម្បីធ្វើជាម្ចាស់ឧបករណ៍ ចាប់ផ្តើមអនុវត្តពួកវា និងប្រើប្រាស់ជាធម្មតា។ ប្រសិនបើពួកគេផ្តោតទៅលើផលិតផលផងដែរនោះ ប្រាំមួយខែនឹងលាតសន្ធឹងដោយលោហធាតុ។ ប្រសិនបើមនុស្សធ្វើការលើផលិតផល ពួកគេធ្វើការម្តងទៀតជាមួយនឹងដំណើរការចាស់ - យើងមិនត្រូវការវាទេ។
ដូច្នេះហើយ យើងចាត់តាំងមនុស្សមកពីនាយកដ្ឋានផ្សេងៗគ្នា ទៅជាក្រុមដាច់ដោយឡែកដែលនឹងផ្លាស់ប្តូរសេវាកម្ម។ ជាលទ្ធផល សេវាកម្មនេះដំណើរការ បន្តអភិវឌ្ឍ ហើយក្នុងពេលជាមួយគ្នានេះ យើងធ្វើការពិសោធន៍មួយចំនួនលើវា។
ក្រុមបណ្តោះអាសន្នត្រូវបានឧទ្ទិសដល់ការផ្លាស់ប្តូរ DevOps តែប៉ុណ្ណោះ - ការលុបបំបាត់ដែនកំណត់ដែលយើងបានរកឃើញ ហើយគ្មានអ្វីទៀតទេ។
ក្រុមនេះមានមនុស្សចម្រុះ. នេះមានន័យថាយើងមិនត្រឹមតែជួលអ្នកអភិវឌ្ឍន៍ប៉ុណ្ណោះទេ។ យើងមិនបានមកមជ្ឈមណ្ឌលសេវាកម្មទេ ហើយយកក្រុមពាក់កណ្តាលមកពីទីនោះ - ទេ យើងយក មនុស្សមកពីនាយកដ្ឋានផ្សេងៗ. ប៉ុន្មានចំណុចមុននេះ យើងបានរកឃើញនាយកដ្ឋានផ្សេងៗគ្នា និងបុគ្គលិកផ្សេងៗគ្នា ដែលពាក់ព័ន្ធនឹងសេវាកម្មដែលបានផ្លាស់ប្តូរ។ យើងកំពុងជ្រើសរើសក្រុមពីពួកគេព្រោះវាត្រូវតែជាសកល - យើងនឹងផ្លាស់ប្តូរដំណើរការសាកល្បង ដំណើរការអភិវឌ្ឍ និងដំណើរការថែទាំសេវាកម្ម។ សមត្ថភាពផ្សេងគ្នាគឺត្រូវការ។
ជាធម្មតាយើងយកអ្នកអភិវឌ្ឍន៍ អ្នកសាកល្បង និងវិស្វករម្នាក់ក្នុងពេលតែមួយ ហើយរួមគ្នាជាមួយពួកគេ យើងបង្កើតដំណោះស្រាយដែលអនុញ្ញាតឱ្យយើងរស់នៅខុសគ្នា។
វាជាការចង់បានដែលមនុស្សទាំងនេះមានសិទ្ធិអំណាចនៅក្នុងអង្គការ. អ្នកប្រហែលជាត្រូវយកការអភិរក្សមួយ ទោះបីជាអ្នកមិនចង់ក៏ដោយ។ ប្រសិនបើយើងមានក្រុមហ៊ុនធំមួយ មិនមែនគ្រប់គ្នានឹងជឿលើគំនិតរបស់យើងទេ ហើយអ្នកខ្លះអាចនឹងនិយាយនៅក្នុងកង់របស់យើង ឧទាហរណ៍ ដោយមិនផ្តល់ជំហរ។ នេះគឺជាកន្លែងដែលអ្នកនឹងត្រូវការ "សិទ្ធិអំណាច" - មនុស្សដែលគួរឱ្យគោរពដែលមានបទពិសោធន៍យ៉ាងទូលំទូលាយដែលបានទទួលអាកប្បកិរិយាល្អពីសហសេវិករបស់គាត់។ សិទ្ធិអំណាចរបស់និយោជិតក្នុងក្រុមនឹងសម្រួលដល់ការងារ និងការងាររបស់ក្រុមបណ្តោះអាសន្ន។ មនុស្សនឹងគិត៖
- មែនហើយ បុរសសង្ហាម្នាក់នេះ ដែលយើងទាំងអស់គ្នាស្គាល់ និងស្រលាញ់គឺសាកសមនឹងនៅទីនោះ - ជាក់ស្តែង មានអ្វីដែលត្រូវមើលនៅក្នុង DevOps!
ការកំណត់គោលដៅ
យើងប្រមូលមនុស្ស ជ្រើសរើសសេវាកម្ម ពិនិត្យមើលការរឹតបន្តឹង និងកំណត់ថាតើមនុស្សណាដែលយើងនឹងមានឥទ្ធិពល។ ឥឡូវអ្នកត្រូវកំណត់គោលដៅ ហើយវាគួរតែត្រង់ ដោយ SMART - អ្វីគ្រប់យ៉ាងដែលយើងស្រឡាញ់។
ជាក់លាក់ - ជាក់លាក់.
អាចវាស់វែងបាន - អាចវាស់វែងបាន។. នេះគឺជាចំណុច SMART សំខាន់ណាស់។ ប្រសិនបើអ្នកមិនអាចវាស់វែងអ្វីមួយបានទេ នោះអ្នកមិនអាចផ្លាស់ប្តូរវា ហើយយល់ពីអ្វី និងរបៀបដែលអ្នកបានធ្វើបានល្អ ឬអាក្រក់ជាងនេះ។
អាចសម្រេចបាន - អាចសម្រេចបាន។. ធ្វើការកែតម្រូវឱ្យសមនឹងតម្រូវការជាក់លាក់របស់អ្នក។ ប្រសិនបើអ្នកជាក្រុមហ៊ុនសហគ្រាសដែលមានប្រវត្តិយូរអង្វែង និងមានទំនួលខុសត្រូវច្រើន ដែលចេញកំណែផលិតផលម្តងក្នុងមួយឆ្នាំ នោះអ្នកនឹងមិនអាចសម្រេចបាននូវការចេញផ្សាយកំណែថ្មីនៃផលិតផលរៀងរាល់ម៉ោងក្នុងរយៈពេលប្រាំមួយខែនោះទេ។ វានឹងមិនដំណើរការដូចនោះទេ។ ដូច្នេះ ចូរកំណត់គោលដៅជាក់ស្តែងដែលអាចសម្រេចបានក្នុងពេលវេលាដែលអាចទទួលយកបាន។
ពាក់ព័ន្ធ - ពាក់ព័ន្ធ។ យើងដកចេញតែការរឹតបន្តឹងទាំងនោះដែលពិតជាបម្រើគោលដៅបច្ចុប្បន្នរបស់យើង។
ពេលវេលាកំណត់ - មានកំណត់ក្នុងពេលវេលា. ប្រសិនបើគ្មានថ្ងៃកំណត់ទេ ក្រុមការងារនឹងធ្វើអ្វីដែលពួកគេចង់បាន៖ សាកល្បងបច្ចេកវិទ្យា 15 ជំនួសឱ្យ 3 សរសេររបាយការណ៍ដ៏ធំ ធ្វើការស្រាវជ្រាវដែលគ្មានប្រយោជន៍ ពង្រឹងការអនុវត្តរបស់ពួកគេរហូតដល់វាភ្លឺនៅពេលដែលគោលដៅបានសម្រេចរួចហើយ។
យើងយកគោលដៅដោយប្រើផែនទីស្ទ្រីមតម្លៃ - យើងប្រមូលមនុស្សទាំងអស់ម្តងទៀតហើយគូរពួកគេ។ ប៉ុន្តែមានតែពេលនេះទេ ដោយផ្អែកលើផែនទីស្ទ្រីមតម្លៃពីមុន យើងគូរអ្វីដែលយើងចង់ទទួលបាន។
យើងគូសបញ្ជាក់ពីដែនកំណត់មួយដែលយើងនឹងលុបបំបាត់នៅពេលនេះ - នេះគឺជាអ្វីដែលក្រុមនឹងធ្វើ។ ជាឧទាហរណ៍ ខ្ញុំបានរង់ចាំពីការចេញផ្សាយដែលបានបញ្ចប់រហូតដល់ការដាក់ពង្រាយរបស់ខ្លួននៅក្នុងផលិតកម្ម - នេះគឺជាដែនកំណត់ទូទៅបំផុតដែលមនុស្សងាកទៅរកអ្នកប្រឹក្សាយោបល់។
ដោយផ្អែកលើចំណុចនេះ យើងកំណត់ភារកិច្ច៖ យើងចង់ឱ្យការរង់ចាំរវាងការចេញផ្សាយដែលបានបញ្ចប់ និងការចូលទៅក្នុងសមរភូមិអតិបរមាមួយម៉ោង។
ឧទាហរណ៍នៃភារកិច្ច។
- កាត់បន្ថយពេលវេលានាំមុខនៃការធ្វើតេស្តពី 4 ថ្ងៃទៅ 1 ម៉ោង។
- កាត់បន្ថយពេលវេលាបន្ថែមតម្លៃសម្រាប់ការធ្វើតេស្តពី 2 ថ្ងៃទៅ 3 ម៉ោង។
- កាត់បន្ថយពេលវេលានាំមុខនៃការដាក់ពង្រាយពី 5 ម៉ោងទៅ 10 នាទី។
- បង្កើន C/A ពី 50% ទៅ 95% ពោលគឺបង្កើនចំនួនមុខងារដែលអ្នកសាកល្បងទទួលយក ម្យ៉ាងវិញទៀត ធ្វើអោយប្រសើរឡើងនូវគុណភាពការងាររបស់អ្នកអភិវឌ្ឍន៍។
ឧទាហរណ៍នៃកិច្ចការមិនត្រូវបានយកចេញពីក្បាលរបស់យើងទេ - ពួកគេផ្អែកលើការវាស់វែងដែលយើងបានធ្វើនៅពេលបង្កើតផែនទីស្ទ្រីមតម្លៃ។
យើងកំណត់ភារកិច្ចស្រដៀងគ្នាសម្រាប់ក្រុមរបស់យើង និងពេលវេលាកំណត់។ អាស្រ័យលើរបៀបដែលក្រុមហ៊ុនរបស់អ្នកដំណើរការបានល្អ អ្នកកំណត់ពេលវេលាកំណត់ខុសៗគ្នា។ ជាមធ្យម វាត្រូវចំណាយពេលប្រាំមួយខែដើម្បីលុបបំបាត់ដែនកំណត់ ប្រសិនបើមនុស្សកំពុងធ្វើនេះជាលើកដំបូង ហើយមិនទាន់ដឹងជាមួយនឹងបច្ចេកវិទ្យាអ្វី និងថាតើពួកគេនឹងដោះស្រាយបញ្ហានេះដោយរបៀបណា។
ផែនការខ្លី
ដូច្នេះហើយ ក្រុមរបស់យើងត្រូវបានបង្កើតឡើង វាមានគោលដៅមនុស្សចាប់ផ្តើមធ្វើការ។ ចំណុចសំខាន់មួយគឺការរៀបចំផែនការការងារខ្លីៗ៖ រត់ពីមួយទៅពីរសប្តាហ៍និងមិនមានទៀតទេ, ការកែលម្អដែលអាចវាស់វែងបាន។ រៀងរាល់សប្តាហ៍ និង ការកែតម្រូវវគ្គសិក្សា.
ឧទាហរណ៍ជាញឹកញាប់យើងប្រើវិធីសាស្រ្ត ផ្លាស់ទី - ផ្លាស់ទីនៅពេលដែលក្រុមទាំងមូលប្រមូលផ្តុំគ្នានៅដើមសប្តាហ៍នីមួយៗ ពួកគេបានកត់ត្រាទុកក្នុងឯកសារនូវអ្វីដែលអ្នកគ្រប់គ្នានឹងធ្វើ។ បន្ទាប់ពីមួយសប្តាហ៍ យើងកត់សម្គាល់នូវអ្វីដែលបានធ្វើ និងអ្វីដែលមិនទាន់បានធ្វើ ប្រសិនបើមិនបាន នោះហេតុអ្វី ហើយយើងគិតអំពីអ្វីដែលត្រូវធ្វើបន្ទាប់ទៀត។
Sprints អនុញ្ញាតឱ្យអ្នកធ្វើការកែតម្រូវវគ្គសិក្សាទាន់ពេលវេលា។
មួយឬពីរសប្តាហ៍ដែលអ្នកបានសាកល្បងអ្វីមួយ៖ បច្ចេកវិទ្យា វិធីសាស្រ្ត របៀបធ្វើការ បន្ទាប់ពីនោះអ្នកវាស់វែងម្តងទៀតហើយមើល - តើវាប្រសើរជាងឬអាក្រក់ជាមួយវិធីសាស្រ្តនេះទេ? ប្រសិនបើវាកាន់តែអាក្រក់ វាមានន័យថាយើងទៅក្នុងទិសដៅខុស យើងត្រូវកែតម្រូវវគ្គសិក្សា៖ កំណត់កិច្ចការផ្សេង យកបច្ចេកវិទ្យាផ្សេង ឬធ្វើអ្វីផ្សេងទៀត។ ការរត់រយៈពេលខ្លី 1-2 សប្តាហ៍អនុញ្ញាតឱ្យអ្នកធ្វើចលនា និងជៀសវាងការសម្រេចចិត្តមិនល្អទាន់ពេល។
ការចែករំលែកជោគជ័យ
ក្រុមសម្រេចបានជោគជ័យខ្លះ មិនថាតូច ឬធំ វាមិនសំខាន់ទេ វាតែងតែមានលទ្ធផលខ្លះ។ អ្នកគ្រប់គ្នាគួរតែដឹងអំពីលទ្ធផលនេះ៖ ទាំងអ្នកពាក់ព័ន្ធនៅក្នុង DevOps និងនាយកដ្ឋានជិតខាង។ នៅក្នុងពិភពដ៏ល្អមួយ វានឹងជាការចង់បានសម្រាប់រឿងនេះដើម្បីមកដល់ទាំងអស់។ ដល់មនុស្សទាំងអស់នៅក្នុងក្រុមហ៊ុន.
ដើម្បីអ្វី? ប្រសិនបើយើងចង់ផ្លាស់ប្តូរមិនត្រឹមតែផ្នែកនៃក្រុមហ៊ុនទេ លុបបំបាត់មិនត្រឹមតែដែនកំណត់មួយប៉ុណ្ណោះទេ ប៉ុន្តែអ្វីៗជាទូទៅដើម្បីឱ្យក្រុមហ៊ុនមានភាពបត់បែន លេខកូដទៅដល់អតិថិជនយ៉ាងឆាប់រហ័ស ហើយគ្មានអ្វីខូចនោះទេ យើងត្រូវការអ្នកគ្រប់គ្នាស្មោះត្រង់នឹងគំនិត។ របស់ DevOps ។ អ្នកនឹងមិនអាចអនុវត្តវិធីសាស្រ្ដចំពោះសេវាកម្ម និងក្រុមដែលប្រឆាំងនឹងវាយ៉ាងអង់អាចបានទេ។
ដើម្បីភាពស្មោះត្រង់លេចឡើង យើងត្រូវតែប្រាប់អ្នកគ្រប់គ្នាថាយើងបានសាកល្បងនេះ យើងមានលទ្ធផល សូមសាកល្បងវាផងដែរ! នេះនឹងបង្កើនចំណាប់អារម្មណ៍ និងភាពស្មោះត្រង់ចំពោះអ្វីដែលយើងធ្វើ មនុស្សនឹងចាប់ផ្តើមព្យាយាមធ្វើអ្វីមួយឥឡូវនេះ។ ដូចដែលការអនុវត្តបង្ហាញ នៅពេលដែលយើងប្រាប់អ្នកពីអ្វីដែលយើងបានព្យាយាម និងអ្វីដែលយើងសម្រេចបាន ក្រុមផ្សេងទៀតចាប់ផ្តើមសួរពីរបៀប និងអ្វីដែលយើងបានធ្វើ។ ពួកគេមើលទៅលើការអនុវត្ត កូដ ឯកសារ មកជាមួយនឹងសំណួរ ហើយព្យាយាមផ្លាស់ប្តូរអ្វីមួយនៅក្នុងខ្លួនពួកគេ។
ការនិយាយអំពីអ្វីដែលអ្នកបានធ្វើគឺសំខាន់។ វិធីនេះអ្នកនឹងបញ្ចុះបញ្ចូលអ្នកអភិរក្សដែលចង់ធ្វើអ្វីគ្រប់យ៉ាងតាមរបៀបចាស់ ដើម្បីចូលរួមជំរុំរបស់អ្នក ហើយបំប្លែងពួកគេទៅជាអ្នកច្នៃប្រឌិត។
សរុប
ការជ្រើសរើសសេវាកម្មជាចំណុចចាប់ផ្តើម - កន្លែងដែលយើងនឹងចាប់ផ្តើមការផ្លាស់ប្តូរនៅក្នុងក្រុមហ៊ុន។ យើងកំណត់អត្តសញ្ញាណអ្នកគ្រប់គ្នាដែលមានអ្វីដែលត្រូវធ្វើជាមួយសេវាកម្ម និងជាមួយពួកគេ។ ការកសាងផែនទីស្ទ្រីមតម្លៃយើងវាស់វែង និងមើលកន្លែងណា និងកម្រិតណា។
ការបង្កើតក្រុមបណ្តោះអាសន្នថ្មី។ដែលនឹងដោះស្រាយបញ្ហា។ ផ្អែកលើការវាស់វែង និងផែនទីស្ទ្រីមតម្លៃ យើងគូរផែនទីថ្មីមួយ ដែលយើងគូសបញ្ជាក់ពីការកំណត់ដែលយើងនឹងដោះស្រាយ. ផ្អែកលើការកំណត់នេះ។ កំណត់កិច្ចការមួយ។ដែលក្រុមការងារនឹងដោះស្រាយ។ ភារកិច្ចគួរតែ SMART ចាំបាច់ - ជាក់លាក់ អាចវាស់វែងបាន ពាក់ព័ន្ធទៅនឹងកិច្ចការបច្ចុប្បន្ន និងកំណត់ក្នុងពេលវេលា។
ដំណើរការឡើងវិញរហូតទាល់តែយើងបំប្លែងសេវាកម្មរបស់យើងទាំងស្រុងទៅជាទម្រង់ដែលត្រូវការ និងលុបបំបាត់ការរឹតបន្តឹងទាំងអស់។
ប្រាក់រង្វាន់។ សម្ភារៈមានប្រយោជន៍
សម្រាប់អ្នកដែលសម្រេចចិត្តធ្វើ DevOps ដោយខ្លួនឯង។
គម្រោង "ទីក្រុង Phoenix"
ចំណងជើងដើមគឺ "គម្រោង Phoenix: ប្រលោមលោកអំពីវា, Devops និងជួយឱ្យអាជីវកម្មរបស់អ្នកឈ្នះ" ។ នេះគឺជារឿងប្រលោមលោកអំពី DevOps - រឿងរ៉ាវនៃរបៀបដែលបុគ្គលិកត្រូវបានតែងតាំងជាប្រធាននាយកដ្ឋានដែលតែងតែឆេះ។ ចៅហ្វាយថ្មីត្រូវបានប្រគល់ភារកិច្ច:
"អ្នកមានពេលពីរបីឆ្នាំក្នុងការទទួលបានអ្វីគ្រប់យ៉ាងត្រឹមត្រូវ ដូច្នេះទីបំផុតយើងអាចចែកចាយផលិតផលរបស់យើងដល់អតិថិជនរបស់យើងបានយ៉ាងឆាប់រហ័ស និងមានប្រសិទ្ធភាព"។
"គម្រោង Phoenix" ប្រលោមលោកអំពីរបៀបដែល DevOps ផ្លាស់ប្តូរជីវិតឱ្យកាន់តែប្រសើរឡើង” គឺជាសៀវភៅសម្រាប់អ្នកគ្រប់គ្រងទាំងអស់ ព្រោះទាំងនេះគឺជាមនុស្សដែលធ្វើការសម្រេចចិត្តអំពីអ្វីដែលកើតឡើងនៅក្នុងក្រុមហ៊ុន។ ប្រសិនបើអ្នកជាវិស្វករ ឬអ្នកសរសេរកម្មវិធី ហើយចង់ឱ្យចលនា និងការផ្លាស់ប្តូរចាប់ផ្តើមនៅក្នុងក្រុមហ៊ុនរបស់អ្នក សូមទិញសៀវភៅមួយក្បាល ហើយប្រគល់វាឱ្យអ្នកគ្រប់គ្រង។ ប្រលោមលោកនេះពន្យល់គ្រប់យ៉ាង ហើយជាការអានរហ័ស និងងាយស្រួល។
មគ្គុទ្ទេសក៍ DevOps
សៀវភៅកាន់តែស្មុគស្មាញ។ វាត្រូវបានបោះពុម្ពកាលពីប៉ុន្មានឆ្នាំមុនជាភាសាអង់គ្លេសក្រោមចំណងជើងថា "សៀវភៅណែនាំ DevOps របៀបបង្កើតភាពរហ័សរហួន ភាពជឿជាក់ និងសុវត្ថិភាពលំដាប់ពិភពលោកនៅក្នុងអង្គការបច្ចេកវិទ្យា" ប៉ុន្តែឥឡូវនេះវាមានជាភាសារុស្សីរួចហើយ។ នេះគឺជាការពិត សៀវភៅណែនាំ - ការណែនាំជាក់ស្តែង៖ របៀបអនុវត្តការវាស់វែង ផែនទីស្ទ្រីមតម្លៃជាអ្វី និងហេតុអ្វីបានជាវាត្រូវការ កន្លែងដែលត្រូវទៅ តាមលំដាប់លំដោយ។ សៀវភៅនេះគឺសម្រាប់តែអ្នកដែលចង់ធ្វើអ្វីគ្រប់យ៉ាងដោយខ្លួនឯងប៉ុណ្ណោះ។ សំខាន់បំផុត វាមានឧទាហរណ៍នៃបទពិសោធន៍របស់ក្រុមហ៊ុនផ្សេងៗ។
ជាឧទាហរណ៍ វាប្រាប់ពីរបៀបដែលក្រុមហ៊ុនមួយបង្កើត Value Stream Map ហើយដឹងថាដែនកំណត់របស់វាមិនមាននៅក្នុងផលិតផលនោះទេ ប៉ុន្តែនៅក្នុងការពិតដែលអ្នកគិតលុយបានដើរពីហាងទៅការិយាល័យបន្ទាប់ដើម្បីប្រើផលិតផលនេះ។ ជំនួសឱ្យការដោះស្រាយបញ្ហាជាមួយកម្មវិធី ពួកគេគ្រាន់តែទិញថេប្លេតសម្រាប់អ្នកលក់របស់ពួកគេ ហើយឥឡូវនេះគ្មាននរណាម្នាក់ទៅណាទេ ហើយសកម្មភាពទាំងអស់ត្រូវបានអនុវត្តនៅកន្លែងធ្វើការរបស់ពួកគេ។ សេចក្តីសន្និដ្ឋាន៖ ផែនទីស្ទ្រីមតម្លៃអាចត្រូវបានពង្រីកមិនត្រឹមតែទៅលើកម្មវិធីប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងដំណើរការទាំងអស់នៅក្នុងស្ថាប័នផងដែរ។
បង្កើនល្បឿន
ចំណងជើងពេញ៖ “បង្កើនល្បឿន៖ វិទ្យាសាស្ត្រនៃកម្មវិធី Lean និង DevOps៖ ការកសាង និងពង្រីកអង្គការបច្ចេកវិទ្យាដែលដំណើរការខ្ពស់”។ នេះគឺជាកម្រិតបន្ទាប់ - រឹងរូស។ សៀវភៅនេះត្រូវបានបោះពុម្ពកាលពីឆ្នាំមុន រហូតមកដល់ពេលនេះមានតែភាសាអង់គ្លេសប៉ុណ្ណោះ ហើយវាគឺជាការស្រាវជ្រាវ។ អ្នកនិពន្ធ-Nicole Forsgren, Jez Humble, និង Gene Kim-បានប្រើការអនុវត្តផ្សេងៗគ្នានៅក្រុមហ៊ុនផ្សេងៗគ្នាអស់រយៈពេលជាច្រើនឆ្នាំ ហើយស្រាវជ្រាវថាតើការអនុវត្តណាមួយប៉ះពាល់ដល់អ្វី និងរបៀប។
ជំពូកទីពីរ ស្តីពីការវាស់វែង និយាយអំពីផែនទីស្ទ្រីមតម្លៃ រង្វាស់ដែលខ្ញុំបានលើកឡើង និងផ្សេងទៀតជាច្រើន ព្រមទាំងពិពណ៌នាអំពីដំណើរការវាស់វែងយ៉ាងលម្អិតផងដែរ។ អ្នកនិពន្ធវាស់វែងដោយប្រើកម្រងសំណួរ និងកិច្ចការតាមដានដោយខ្លួនឯង។ វាពិពណ៌នាយ៉ាងលម្អិតថាតើម៉ែត្រមួយណាត្រឹមត្រូវក្នុងការវាស់វែង មួយណាមិនគួរវាស់វែង និងកំហុសរបស់មនុស្សក្នុងការវាស់វែង។ ប្រសិនបើអ្នកមានការលំបាកជាមួយនឹងការវាស់វែងសូមមើលជំពូកទីពីរនៃសៀវភៅ "បង្កើនល្បឿន" ។ ប្រសិនបើក្រុមរបស់អ្នកមានការអនុវត្តច្រើន ប៉ុន្តែវាមិនច្បាស់ថាការអនុវត្តមួយណាត្រូវអនុវត្តឥឡូវនេះ មួយណានៅពេលក្រោយ មួយណាពិតជាដំណើរការ ហើយមួយណាមិនដំណើរការ - អានសៀវភៅពន្យល់គ្រប់យ៉ាង។
ការផ្លាស់ប្តូរគឺជាបញ្ហានៅចំនុចប្រសព្វនៃ DevOps និងការគ្រប់គ្រង។ កន្លែងណាមួយនៅក្នុងតំបន់ដូចគ្នានៃប្រសព្វនៃការអភិវឌ្ឍន៍ ប្រតិបត្តិការ និងការធ្វើតេស្តគឺជាប្រធានបទដែលយើងព្យាយាមពិភាក្សានៅ ការធ្វើសមាហរណកម្មដូចគ្នាគឺចាំបាច់ដើម្បីបង្កើតផលិតផលដែលមានគុណភាព - ប្រធានបទសំខាន់ . ការគ្រប់គ្រងពិធីបុណ្យ បានបង្ហាញ - នោះមានន័យថាមនុស្សគ្រប់គ្នានៅទីនោះសម្រាប់គំនិតសម្រាប់ការផ្លាស់ប្តូរ។ ចូលរួមជាមួយពួកយើងនៅថ្ងៃទី 27 និង 28 ឧសភា យើងនឹងធ្វើសមាហរណកម្ម និងផ្លាស់ប្តូរ។
ប្រភព: www.habr.com
