كيفية بدء التحول DevOps

إذا كنت لا تفهم ماهية DevOps ، فإليك ورقة غش قصيرة. DevOps هي مجموعة من الممارسات التي تقلل من مخاوف المهندسين وتقلل من عدد حالات الفشل في إنتاج البرمجيات. كقاعدة عامة ، فإنها تقلل أيضًا من الوقت اللازم للتسويق - الفترة من الفكرة إلى تسليم المنتج النهائي للعملاء ، مما يتيح لك إجراء تجارب تجارية بسرعة.

كيف تبدأ تحول DevOps؟ باختصار: نختار الخدمة التي سنبدأ العملية منها ، ونحدد من لهم صلة بالخدمة ، وننشئ خريطة دفق القيمة ، وننشئ فريقًا مؤقتًا يتعامل مع التحول لأول مرة ونضعها في مهمة. نكرر الدورة عدة مرات حسب الضرورة.


توجد خطة تحويل تفصيلية لـ DevOps مع أمثلة وتعليمات تحت الخفض ، وهي في فك شفرة تقرير Andrei Alexandrov ، وهو مهندس في Express42 ، يقدم المشورة بشأن إنبات DevOps ، مما يسرع هذه العملية ، لأنه قام بالفعل ببناء خريطة أشعل النار. إذا بدا لك أنك لست بحاجة إلى هذا التحول ، أو إذا كان لديك بعض التفاصيل التي لا تناسبها ممارسات DevOps ، فاستخدم التقرير كتعليمات للعثور على القيود وإزالتها.

إذا كنت مهتمًا بمسألة تحول DevOps ، فأنت لديك شركة كبيرة وتحتاج إلى توسيع نطاق هذه العملية تدريجياً إلى الهيكل بأكمله. طالما كانت هناك حاجة لتحويل الفريق أو إزالة نوع من القيود ، يمكن تكرار الخوارزمية أدناه.

اختيار الخدمة

لقد حددنا خطة ، نبدأ بالخطوة الأولى - اختيار الخدمة. المعيار الأول هو العمر : هناك خدمات قديمة - إرث ، وخدمات جديدة. يمكنك أن تبدأ مع هؤلاء وغيرهم.

من المنطقي اختيار خدمة شابة . إنه جديد ، لا توجد عملية راسخة للعمل في فريق يتعامل معها. من حوله لا يوجد جبل من الديون الفنية ، لا حاجة لإصلاحه طوال الوقت. يمكننا أن نفعل ما نريد معه.

في حالة الخدمة القديمة ، هناك مشاكل مرتبطة بحقيقة أنه من الصعب دائمًا التغيير . هناك بالفعل مجموعة من بعض القيود الخطيرة ، ولكن ربما يكون الأشخاص المستعدين لدفع كل شيء يفعلون ذلك - إنهم متعبون ويريدون القيام بشيء مختلف ، لأنه مؤلم.

العمل مع الخدمة القديمة يخلق سابقة قوية في شركتك - يمكنك تغيير شيء ما. إذا غيرت خدمة جديدة ، فستتحول إلى 100 مرة في الساعة ، وكل شيء على ما يرام ، عندها يمكن للأشخاص في شركتك أن يقولوا:

- هذه خدمة جديدة! كان كل شيء بسيطًا هناك ، حاول أن تفعل شيئًا من خلال أشياءنا المبهمة.

من المنطقي تحويل خدمة Legacy إلى تحويل عندما تقوم بذلك مع شخص ما ، على سبيل المثال ، إذا قمت بدعوة مستشار خارجي. لنكن صادقين ، سيحول هذا التحول إلى كل شيء ممكن . أنت تقوم بالتجربة ولا تعرف من أين ستأتي ، وما هي التقنيات ولماذا ستستخدمها ، وأين وما هي المخاطر التي ستنشأ في العمليات. لذلك ، التغيير الجديد أسهل.

إذا كنت تفعل كل شيء بنفسك ، لكن الشركة ليس لديها كفاءة جدية ، فإننا نأخذ خدمة جديدة. إذا كنت تعرف مستشارًا خارجيًا وهناك أموال - فاختر المستشار القديم.

هناك خدمات ليست سوى واجهة للمستخدمين ، على سبيل المثال ، موقع ويب بسيط أو تطبيق محمول. ولكن هناك أشياء خطيرة في روح الفواتير. إذا حدث خطأ ما في الفوترة ، فسيكون من الصعب فهمها. هنا لدينا أيضا خيار.

نحن نعمل إما مع خدمة حرجة ، لكننا نعاني بالفعل بسببها ، فهي تخلق قيودًا ، أو نعمل مع الواجهة . هذا هو معيار الاختيار الثاني. وبالمثل ، من الممكن جذب خبير استشاري ذي خبرة - نحن نعمل مع خيار صعب.

لكن حتى في هذه الحالة ، فإنني لا أنصح بذلك ، لأنه بينما لا يوجد فهم لما يجب العمل به وكيفية التحويل ، فإن اتخاذ شيء حرج وتهزذه ليس فكرة جيدة. لذلك ، في هذه الحالة ، نفضل العمل مع واجهة ليس فشلها حرجًا.

بعد ذلك ، فكر في أمر الخدمة . مع أولئك الذين يشاركون في هذه الخدمة ، سيتعين علينا العمل باستمرار والتفاعل في اتصال وثيق للغاية.

ينقسم الأشخاص في الفريق إلى فئتين مشروطين: المحافظون - يعيشون في العالم القديم ، أو ببساطة لا يعرفون أي شيء عن DevOps ، والمبتكرين الذين يمارسون جميع الممارسات العصرية. هذا الأخير لا يفهم دائمًا الموضوع ، لكنه على الأقل جاهز له.

من ناحية ، المحافظون هم أشخاص ذوو خبرة: لقد ظلوا مع الشركة لفترة طويلة ، فهمهم تمامًا ، لكنهم لا يعرفون تمامًا عن الممارسات. من ناحية أخرى ، هناك مبدعون سمعوا شيئًا ، لكن على الأرجح كانوا يعملون في الشركة منذ وقت ليس ببعيد. أي منهم أفضل للعمل مع؟

في أي حال ، سوف تضطر إلى التفاعل مع المحافظين ، لأن هذه هي خدمتهم. سيتعين علينا التواصل معهم ومعرفة تفاصيل الخدمة وما الذي يمكن عمله بهذه الطريقة وما هو مختلف. نحن نعتمد على نصائحهم. بالتأكيد سيتعين عليهم تكليف شيء ما ، لأنهم يعرفون خدمتهم بشكل أفضل. لذلك ، من المهم الفريق الذي سنتواصل معه في النهاية.

من المنطقي اختيار فريق مبتكر ، لأن المحافظين يمكنهم وضع خنزير.

في الممارسة العملية ، يحدث غالبًا أن يكون لدى المحافظين خبرة كبيرة ، لكن لا يوجد فهم لكيفية العيش. إنهم يخشون ببساطة أنه بعد تحول الخدمة وتعديلها ، سيتم رفضهم باعتبارهم غير ضروريين. في بعض الأحيان ، ببساطة بسبب عدم فهم ما يحدث ، فإنهم يخربون العمل.

كانت لدي قضية عندما قام شخص من فريق بإصلاح أي شيء ، لأنه من المفترض أن يكون أكثر أهمية مما نفعله الآن. لقد حددنا المهمة: لتحقيق هذه القطعة اليوم - لا ، هناك حريق على الجانب الآخر من العالم ، ونحن بصدد إصلاحه. من الصعب العمل مع هؤلاء الناس.

غالبًا ما يسد الأشخاص من الفريق المحافظ المهام ، أو يؤجلونها حتى آخرها. وإذا أنقذك جون ويليس ، فقد ارتكبت خطأً وعلقته مع KPI لعدد المهام المنجزة ، ولسبب ما لم يتم تضمين بعضها في KPI ، فلن يفعلوا شيئًا على الإطلاق. بشكل عام ، سيكونون على حق ، لأنهم يفقدون المكافأة.

الأمر أسهل مع المبدعين - فهم أكثر ولاءً . لقد سمعوا بالفعل شيئًا ما ، يريدون الذهاب إلى مكان ما ، لذلك سيساعدون. نحتاج إلى أشخاص مستعدين للمعاناة في المرة الأولى: إذا تغيرت الخدمة ، فسيتم ابتكار جميع المخاريط والحطام من قبل المبتكرين كرائد. يريد المبتكرون الأحدث والأكثر عصرية ، ويعانون.

يمكن تحويل المحافظين فيما بعد. عندما تُظهر أنك قد غيرت قطعة ما وأن كل شيء يعمل بشكل جيد ، فمن المرجح أنها ستحاول أيضًا تبني دين DevOps الجديد.

لتلخيص. إذا قمنا بكل التحولات في شركتنا بأنفسنا ، فسنختار: خدمة جديدة ، ويفضل أن تكون واجهة بسيطة ، حتى لا نعاني كثيرًا من انهيارها ، وفريق من المبتكرين.

إذا كان من الممكن الاتصال بمستشار خارجي ، بدلاً من مستشار جديد ، فإننا نأخذ الخدمة القديمة ، التي نعاني بسببها بالفعل. لقد شهد الأشخاص الذين شاركوا في عملية التحول لبعض الوقت في شركات مختلفة حالات مختلفة وفهموا بالفعل كيفية القيام بذلك بشكل صحيح وأي طريقة يمكن القيام بها بشكل عام.

من يشارك؟

نحتاج إلى العثور بشكل عام على كل شخص له علاقة على الأقل بالخدمة: المطورين ، والمختبرين ، والمدراء ، وحراس الأمن ، والمديرين ، وربما أصحاب المنتجات. على الرغم من حقيقة أن مالكي المنتجات ليسوا تقنيين ، إلا أنهم مرتبطون بالخدمة: اتخاذ قرار وتحديد مهمة.

كل شخص يتخذ على الأقل بعض القرارات ويؤثر على ما يحدث مع الخدمة يحتاج إلى البحث والالتقاء والدردشة.

ما هم بالنسبة لنا؟ لمعرفة من تتفاوض معه . أثناء التحول ، عندما يتغير المبدأ المعتاد للعمل مع الخدمة ، سوف يهتز على أي حال. سيكون هناك خلل لفترة من الوقت بينما نحن اختبار أساليب جديدة. يجب أن يكون الناس مستعدين لهذا ويوافقون عليه.

بعد ذلك ، يجب عليك إنشاء "خريطة دفق القيمة" وبدون هؤلاء الأشخاص ، لا يمكنك إنشاؤها ، لأنهم جميعًا فقط يعرفون الصورة الكاملة لما يحدث. شخص واحد لا يعرف أبدًا كل ما يحدث مع الخدمة.

سيقدمون النصيحة للناس في الفريق ، وسنناقش لاحقًا سبب الحاجة إلى فريق منفصل. سيتعين عليها اصطحاب أشخاص من الأقسام الموجودة. سيتمكن أولئك الذين لهم صلة بالخدمة من التوصية بزملائهم الذين يفكرون في اتجاهنا ، والذين يمكنهم مساعدتنا ولديهم الكفاءة فيما نحتاج إليه.

ثم نجمع كل هؤلاء الأشخاص من أقسام مختلفة في غرفة واحدة ونبدأ في إنشاء خريطة لقيمة التدفق.

بناء خريطة تيار القيمة

Value Stream Map عبارة عن مخطط أو خريطة توضح تدفق القيم إلى العميل . هذه هي العملية برمتها من ابتكار فكرة إلى تنفيذها ، بما في ذلك جميع المراحل المتوسطة وكيف تصل القيمة في النهاية إلى عملائنا.

هناك حاجة إلى خريطة دفق القيمة لتصور جميع مراحل التطوير ، ولإضفاء الطابع المحلي على المشكلات من خلال القياسات التي تجري في العملية الحالية ، والبدء في التخلص من هذه المشكلات وتحديد هدف مبدئي . هذا هو المكان الذي سنبدأ فيه فعل شيء ما.

المقاييس

هناك العديد من المقاييس المختلفة الموضحة في مؤلفات Value Stream Map ، ولكن بالنسبة للمبتدئين ، نحتاج إلى ثلاثة فقط.

يؤدي الوقت - تأخير / الانتظار - الوقت عندما ننتظر شيئا. على سبيل المثال ، ينتظر المختبر حتى يتم تحرير حامل الاختبار ولا يمكنه فعل أي شيء في هذا الوقت.

وقت القيمة المضافة - وقت العمل المفيد - الوقت الذي قضينا فيه في مثل هذه ومرحلة إنشاء القيمة النهائية للمستخدم. على سبيل المثال ، أجرى اختبار له اختبار وبدأ اختبار شيء. هذا هو وقت العمل المفيد عندما نفعل شيئًا ما للمنتج. هذا هو ما يدفعه العملاء مقابل البرامج عالية الجودة.

٪ C / A - نسبة العمل المقبول. لدينا مرحلة واحدة - التطوير ، المرحلة الثانية - الاختبار. كم عدد ميزات اخذت من اختبار للمطورين ، وهناك هذه النسبة.

هذا هو ما تبدو خريطتنا.



قد يبدو مختلفًا حسب هيكل المنظمة وعدد الإدارات وما تفعله. لكن في الحالة العامة ، ستحتوي الخريطة على مرحلتين: فكرة وتحليلات . في هذه المرحلة ، من المتوقع أن البيانات ، على سبيل المثال ، المهلة الزمنية 2 أسابيع والقيمة المضافة الوقت 2 أيام.

تغطي المقاييس تماما جميع المراحل.

الأعمال المتراكمة - عدد المهام التي تكمن بعد وصول المحللين إليها.

التطوير - كم هو عدد أسابيع المطورين الذين ينتظرون الحصول على توضيحات بشأن المهام أو المدرجات أو المعدات - لا يهم ، لكنهم ينتظرون شيئًا ما. على سبيل المثال ، يتم تطبيق ميزة لمدة 4 أيام. يظهر٪ C / A المتري هنا. أخذ المطورون 80٪ فقط من المهام من Backlog. إنهم يعتقدون أن نسبة الـ 20٪ المتبقية ليس لديهم معارف تقليدية واضحة ، وأرسلوها للمراجعة.

اختبار . على مخطط LT ، يتم تعيين 4 أيام. على سبيل المثال ، كان المختبرون في انتظار إصدار اختبار مقاعد البدلاء ، و VA لمدة يومين يقومون بالفعل باختبار شيء ما ، و٪ C / A = 40٪. - اعتبر 40٪ فقط من الشفرة أو الميزات التي أرسلها المطورون أنها كافية. لم يعجبهم الباقون لسبب ما.

لن أتطرق إلى كيفية إجراء هذه القياسات ، في نهاية المقال ، سأوصي بأدبيات يمكنك التعرف عليها.

الشيء الوحيد الذي أنصح به هو عدم تصديق الأشخاص الذين سيقومون بتكوين خريطة تدفق القيمة معك. إنها تمثل مقدار الوقت الذي تستغرقه العمليات المختلفة ، لكن هذه التقديرات ليست صحيحة دائمًا ، لذلك من الأفضل أن تقيس نفسك.

كانت لدينا قضية عندما وصلنا إلى قسم العمليات وسألنا عن الوقت الذي يستغرقه تقديم ميزة جديدة للإنتاج. أجابوا ذلك 10 دقائق ، وفكرنا ، لماذا أتينا إلى هذه الشركة؟ اتضح أن 10 دقائق هي وقت تشغيل البرنامج النصي ، الذي يأخذ الرمز ويوصله إلى الخادم. ولكن قبل ذلك ، يقع الإصدار على الخادم لمدة ثلاثة أيام ويقوم بتجميع الغبار فقط - في Backlog تكمن المهمة التي يجب نشرها. اتضح أنه قبل مرحلة النشر هناك مرحلة انتظار عندما يكمن المشروع ببساطة. لو أننا لم نذهب مع جهاز كمبيوتر محمول ، ولم نغض النظر عن مهمة في جيرا ، ولم نبدأ بتتبعها على مراحل ، لكنا ظننا أن كل شيء كان رائعًا ولم تكن هناك مشكلة.

لذلك ، لا يزال يتعين إجراء القياسات بنفسك ، ويفضل أن يكون ذلك أكثر من مرة ، حتى يكون هناك تمثيل قريب من الواقع. وفقًا لخريطة دفق القيمة ، ستقرر أين تبدأ وما يجب إصلاحه أولاً.

فريق مؤقت

تقوم العديد من الشركات التي قررت تقديم DevOps بإنشاء فريق ، ليس فقط مؤقتًا ، ولكن موجودًا لعدة سنوات. إذا ذهبت إلى خدمة اعتذار DevOps ، التي تصف الأنماط المختلفة لبناء هيكل تنظيمي في DevOps ، فسوف تفهم أن هذا مضاد للتظاهر.

عندما يكون فريق DevOps مستمرًا لعدة سنوات ، فهذا خطأ كبير ، لأن DevOps يتعلق بالتواصل بين الإدارات ، حول السرعة والكفاءة.

إذا كان هناك فريق بين الإدارات ، لفعل شيء آخر منفصل ، وكان موجودًا لفترة طويلة ، فسيخلق ذلك عائقًا إضافيًا. الآن ، بدلاً من الانتقال مباشرة إلى المسؤول ، يحتاج المبرمج إلى الاتصال أولاً بقسم DevOps ، وسوف يذهب أبعد من ذلك.

لذلك ، للبدء ، تحتاج إلى إنشاء فريق مؤقت . ستكون موجودة لمدة ستة أشهر مع وقف التنفيذ ، بحد أقصى عام ، اعتمادًا على المهمة ، فقط لإزالة أحد القيود التي اخترناها. ثم سوف تموت. إذا اخترنا النقطة التالية حيث يؤلمها كثيرًا ونفهم أننا نحتاج أيضًا إلى فريق منفصل لها ، فسنقوم بإنشائها مرة أخرى. لكن لا ينبغي أن توجد مثل هذه الفرق على "أساس دائم" - ثم تقاطع التواصل وتتولى مهام منفصلة بشكل عام فقط لفعل شيء ما. قد لا تكون هذه المهام متعلقة بـ DevOps أو التحول على الإطلاق. لماذا لا نعطي هذه المهمة للإدارات القائمة؟

لماذا تحتاج إلى فريق مؤقت

الصراع مع العمليات الحالية . تحول DevOps هو تغيير ليس فقط في التقنيات والأدوات التي نستخدمها ، ولكن التغيير في عملية العمل والتفكير والقيم. إذا كان الفريق يعمل بالطريقة المعتادة ، فلن تتمكن من تجربة طرق أخرى.

يجب أن يعيش هؤلاء الأشخاص وفقًا لقواعد مختلفة: تجاهل جميع مؤشرات الأداء الرئيسية في الشركة ، لأنهم يحاولون العمل بشكل مختلف. لن تقوم الفرق المؤقتة بملء الطلبات للحصول على خادم ، بل ستذهب مباشرة إلى القسم الذي يديرها ، مطالبين بأن تكون أول من يقدم ما يحتاجون إليه ، لأن هذه مهمة ذات أولوية ولأنهم يحاولون العيش بشكل مختلف. الفريق لديه تعارض كامل مع جميع العمليات الحالية. حتى لا تتداخل أساليب العمل الحالية معها ، ولا تتداخل مع الآخرين ، فإننا نعزل هؤلاء الأشخاص عن طريق الاستعانة بهم كفريق منفصل.

تجنب البيروقراطية في التجارب . لا توجد بيروقراطية في فرق مؤقتة ؛ فهي لا تملأ تقارير عن ساعات العمل ؛ ولا تقدم تقارير إلى المديرين. هذا عالم منفصل تمامًا يعيش فيه الناس ويفكرون بطريقة مختلفة ، ويفعلون أشياء مختلفة تمامًا. لا تزعجهم مرة أخرى.

العمل بدون توقف على الخدمة . في الفقرة الأولى ، اخترنا شيئًا للتجربة. يعد التجريب والبحث عن طرق للعمل بشكل أفضل أمرًا جيدًا ، لكننا نريد أيضًا القيام بالميزات. إذا انخرط الفريق بأكمله في عملية التحول بدلاً من الميزات ، فسنبدأ في خسارة إيراداتنا ، وسوف تتعطل الأخطاء لفترة طويلة - لسنا بحاجة إلى ذلك. يتيح لك إنشاء فريق مؤقت إجراء التجربة دون إيقاف العمل على المنتج.

لا تضيع الوقت في مهام العمل . هذا مرة أخرى عن المنتج. يستغرق الفريق الكثير من الوقت لتجربة الأدوات والأشياء الأخرى. لكي يتمكن الأشخاص من إتقان الأدوات ، والبدء في تنفيذها واستخدامها بشكل طبيعي ، سيستغرق الأمر ستة أشهر على الأقل. إذا كانوا سيتعاملون أيضًا مع المنتج - تمتد ستة أشهر كونيًا. إذا شارك الناس في منتج ما ، فإنهم يعملون مرة أخرى مع العمليات القديمة - لسنا بحاجة إلى ذلك.

لذلك ، نقوم بفصل الأشخاص من الإدارات المختلفة إلى فريق منفصل يتعامل مع تحويل الخدمة. نتيجة لذلك ، تعمل الخدمة ، وتستمر في التطوير ، وفي الوقت نفسه ، نجري بعض التجارب عليها.

يشارك الفريق المؤقت فقط في تحول DevOps - مما يلغي القيود التي وجدناها ، ولا شيء أكثر من ذلك.

يتكون الفريق من أشخاص عالميين . هذا يعني أننا أخذنا ليس فقط المطورين. لم نأت إلى الخدمة ولم نأخذ فريقًا نصفًا من هناك - لا ، لقد أخذنا أشخاصًا من أقسام مختلفة . قبل بضع نقاط ، وجدنا أقسامًا مختلفة وموظفين مختلفين مرتبطين بخدمة التحويل. من بين هؤلاء ، نقوم بتعيين فريق ، لأنه يجب أن يكون عالميًا - سنقوم بتغيير عملية الاختبار ، وعملية التطوير ، وعملية تقديم الخدمة. هناك حاجة إلى كفاءات مختلفة.

عادةً ما نأخذ مطورًا واختبارًا ومهندسًا مشروطًا - كل واحدًا تلو الآخر ، ومعنا نتوصل إلى حل يتيح لك العيش بشكل مختلف.

من المرغوب فيه أن يكون لهؤلاء الأشخاص سلطة في المنظمة . قد تضطر إلى اتخاذ أحد المحافظين ، على الرغم من أنك لا تريد ذلك. إذا كان لدينا شركة كبيرة ، فلن يؤمن الجميع بمشروعنا ، ويمكن لأي شخص وضع العصي في العجلات ، على سبيل المثال ، عدم إبراز موقف. ستحتاج هنا إلى "سلطة" - شخص محترم يتمتع بخبرة واسعة ، ويستحق موقفًا جيدًا من الزملاء. سوف تبسط سلطة الموظف في الفريق مهمة وعمل الفريق المؤقت. سوف يفكر الناس:

- نعم ، هذا المتأنق اللطيف الذي نعرفه جميعًا ونحبّه ، يتلاءم مع ذلك - على ما يبدو ، لدى DevOps شيء يستحق النظر إليه!

وضعنا هدفا

لقد جمعنا الأشخاص ، واخترنا الخدمة ، ونظرنا في القيود ، وحددنا الأشخاص الذين سنؤثر عليهم. أنت الآن بحاجة إلى تحديد هدف ويجب أن يكون على SMART - هذا كل ما نحبه.

محددة - محددة .

قابلة للقياس - قابلة للقياس . هذه هي نقطة مهمة جدا من سمارت. إذا لم تتمكن من قياس شيء ما ، فلا يمكنك تغييره وفهم ماذا وكيف قمت بعمل أفضل أو أسوأ.

يمكن تحقيقه . ضبط للحصول على التفاصيل الخاصة بك. إذا كنت شركة مؤسسة لها تاريخ طويل وعبء كبير من المسؤوليات ، والتي تصدر إصدار منتج مرة واحدة في السنة ، فلن تكون قادرًا على تحقيق إصدار إصدارات منتج جديد كل ساعة في غضون ستة أشهر. إنها لن تنجح بهذه الطريقة. لذلك ، حدد هدفًا حقيقيًا يمكن تحقيقه في فترة مقبولة.

ذات الصلة - ذات الصلة. نحن فقط القضاء على القيود التي تسعى حقا أهدافنا الحالية.

الوقت محدود - الوقت محدود . إذا لم يكن هناك موعد نهائي ، فسوف يقوم الفريق بأي شيء: جرّب 15 تقنية بدلاً من 3 ، واكتب تقارير ضخمة ، وأجرت أبحاثًا عديمة الجدوى ، وقم بتطبيقها حتى يلمع عندما يتحقق الهدف بالفعل.

نحن نأخذ الهدف بمساعدة خريطة تدفق القيمة - مرة أخرى نجمع كل الأشخاص ونرسم. لكن الآن فقط ، استنادًا إلى خريطة القيمة السابقة ، نرسم ما نريد الحصول عليه.



لقد حددنا حداً واحداً من القيود التي سنقوم بإزالتها الآن - وهذا ما سيفعله الفريق. على سبيل المثال ، أخذت التوقع من الإصدار النهائي إلى نشره في الإنتاج - وهذا هو القيد الأكثر شيوعًا الذي يلجأ إليه الأشخاص إلى الاستشاريين.

بناءً على ذلك ، قمنا بتعيين المهمة: نريد أن يكون الانتظار بين إصدار جاهز والبدء في العمل ساعة بحد أقصى.

أمثلة من المهام.

• تقليل وقت اختبار الرصاص من 4 أيام إلى 1 ساعة.
• تقليل وقت القيمة المضافة للاختبار من 2 إلى 3 ساعات.
• تقليل نشر المهلة الزمنية من 5 ساعات إلى 10 دقائق.
• قم بزيادة نسبة C / A من 50٪ إلى 95٪ ، أي زيادة عدد الميزات التي يقبلها المختبرون ، بمعنى آخر ، تحسين جودة المطورين.

لا يتم أخذ أمثلة من المهام من الرأس - فهي تستند إلى القياسات التي قمنا بها عند تطوير خريطة دفق القيمة.

وضعنا مهمة مماثلة لفريقنا ومهلة زمنية. , , . , , , .

, , , . — : - , , .

, moving-moving , , , . : , , , , , .

.

- : , , , — ? , , : , - . 1-2 .

- , — , - . : , DevOps, . , .

لماذا؟ , , , , , , , DevOps. , .

, , — , ! , , - . , , , , . , , , - .

, — . , - .

, — , . , - Value Stream Map , , .

, . Value Stream Map , , . , . SMART — , , .

, .

.

, DevOps .

«»

— «The Phoenix Project: A Novel about It, Devops, and Helping Your Business Win». DevOps — , , . :

— , , .

« “”. , DevOps » — , , . , — . , .

DevOps

. «The DevOps Handbook How to create world‑class agility, reliability, and security in Technology organizations», . handbook — : , Value Stream Map , , . , . , .

, , Value Stream Map , , , , . , , , , . : Value Stream Map , .

Accelerate

: «Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations». — . , . — Nicole Forsgren, Jez Humble Gene Kim — , , .

, , Value Stream Map, , , , . . , , , . , «Accelerate». , , , , , — , .

— DevOps . - , , DevOpsConf , – QaulityConf . ++ Whale Rider — . 27 28 , .