تقييم كفاءة العملية باستخدام خرائط تدفق القيمة
عند إنشاء مخطط تدفق قيمة أو VSM، فإنه يساعدك على تحليل عملية دورة الإصدار الحالية. الغرض من VSM هو إظهار مكان إنشاء الفريق لقيمة في العملية ومكان وجود إهدار. الهدف هو التوصل إلى عملية توفر أكبر قيمة للعميل بأقل قدر من إهدار الوقت. يمكن أن يساعدك VSM في تحديد تلك المناطق التي إما لا تساهم بأي قيمة أو التي تقلل بالفعل من قيمة المنتج.
دعونا نرى كيف يقيس Tailspin.
ستقوم مارا، الجديدة في الفريق، بإنشاء VSM لمساعدتها على فهم العملية الحالية. مع VSM، ستتعرف على المكان الذي يتناسب فيه الفريق مع نموذج نضج DevOps. كما اتضح، عادة ما يتم إصدار الفرق الأكثر نضجا بشكل أسرع، بثقة أكبر، وبأخطاء أقل من الفرق الأقل نضجا.
تعرف مارا أنها لا تفهم كل شيء حتى الآن، لذلك ستقوم بإنشاء VSM سريع على السبورة البيضاء في غرفة الاجتماعات. ستكون هناك بعض الثغرات والأسئلة التي لم تتم الإجابة عنها، ولكن هذا الأمر لا بأس به. إنها بداية. عندما تنجز أكبر قدر ممكن، ستشاركه مع الفريق. يمنح VSM الجميع نقطة بداية مشتركة لتحديد الخطوات الأولى نحو تحسين كيفية تطوير Tailspin لمواقع الويب الخاصة به وإصدارها.
دعونا نلقي نظرة على خريطة لها.
فهم العملية الحالية
تجمع مارا الفريق في غرفة الاجتماع لتقديم VSM الخاص بها.
مارا: يساعدنا جهاز VSM على قياس المكان الذي يكون فيه للعملية قيمة للعميل ومكان تناولها للوقت دون إنتاج أي قيمة. تبدأ خريطتنا في أعلى اليسار بمواصفات البرمجيات الوظيفية. دعونا نتبع ميزة واحدة فقط لمعرفة كيفية تحركها خلال دورة الإصدار الحالية.
بعض الناس يلفون أعينهم، لكن مارا تضغط على.
عمليات التطوير
يبدأ إنشاء ميزة جديدة حالياً بإنشاء تسمية في عنصر التحكم المصدر 
. لدينا شخص واحد يمكنه إنشاء تسميات، وهو أندي. نحن نطلب تسمية عن طريق البريد الإلكتروني. نحن نستخدم نظام مركزي للتحكم في الإصدار، لذلك ينتظر أندي حتى يتم إيداع جميع التعليمات البرمجية الموجودة واستقرارها قبل أن يقوم بإنشاء التسمية. بعد إنشاء التسمية، نحصل على رسالة بريد إلكتروني تفيد بأنه يمكننا بدء العمل. تستغرق هذه العملية ما يصل إلى ثلاثة أيام وليس لها قيمة للعميل. يجب أن تستغرق الأشياء التي لا قيمة لها للعميل أقل وقت ممكن.
يستغرق ترميز ميزة حوالي أربعة أيام لشخص واحد بمجرد أن نحصل على حق الوصول إلى جميع الملفات التي نحتاجها 
. يجب أن نكون على شبكة الشركة من أجل الوصول إلى التحكم بالمصادر. هذه المرة لها قيمة للعميل. إنهم يريدون هذه الميزة.
عمليات الاختبار
بعد أن نقرر أن لدينا تحديث إصدار مستقراً، نقوم بتحديث جدول بيانات لإخبار Amita أن هناك تحديث إصدار جاهزاً للاختبار وأين يمكن العثور عليه 
. يستغرق الأمر يومين لإعلامها.
تقوم Amita باختبار تحديث الإصدار يدوياً 
. تستغرق هذه العملية وقتا أطول مع نمو قاعدة التعليمات البرمجية. في الوقت الراهن، لنفترض ثلاثة أيام. ثم ترسل بريدا إلكترونيا إلى أندي مع تقارير الأخطاء. الاختبار لا يضيف قيمة، ولكنه ضروري.
ثم يجب أن يستغرق Andy بعض الوقت لفرز الأخطاء وتعيين العمل . قد يستغرق أندي ثلاثة أيام أخرى لفهم المشكلات والحصول عليها إلى المطورين المناسبين.
أنشطة العمليات
عندما توافق أميتا على بناء، فإنها تهديه إلى تيم. يحتاج تيم إلى نشر هذا الإصدار إلى خوادم ما قبل الإنتاج لمزيد من الاختبار. غالبا ما تكون خوادم ما قبل الإنتاج غير متزامنة مع أحدث التصحيحات والتحديثات اللازمة لتشغيل موقع الويب. يستغرق تيم حوالي يومين للنشر قبل الإنتاج وتشغيل بعض الاختبارات. مرة أخرى، في حين أن النشر إلى ما قبل الإنتاج لا يضيف قيمة، فمن الضروري 
.
بعد أن يصبح البناء جاهزا للإنتاج، تحتاج القيادة إلى الموافقة على الإصدار قبل أن يمكن نشره. تتم الموافقة في اجتماع. يستغرق الأمر أربعة أيام للحصول على القيادة للاجتماع ومراجعة الإصدار.
في نهاية المطاف، يوزع تيم الميزة وتضع الميزة العملاء هنا على الجانب العلوي الأيمن من خريطة تدفق القيمة. إذا انجرف تكوين خادم الإنتاج بحيث يكون غير متزامن مع ما قبل الإنتاج، يحتاج تيم أولا إلى تحديثه، والذي يستغرق يوما 
واحدا.
حساب مقاييس قيمة العميل
الآن يمكننا أن ننظر إلى مقاييس الأداء الرئيسية ونرى كيف نقيس.
إجمالي وقت العميل المتوقع هو الوقت الذي تستغرقه الميزة لجعله للعميل. هنا، إجمالي الوقت هو 22 يوما. وقت العملية هو الوقت المستغرق في ميزة لها قيمة للعميل. هنا، يتضمن وقت العملية أربعة أيام للترميز بالإضافة إلى يوم واحد لنشر الميزة، ما يعطي ما مجموعه خمسة أيام.
نسبة النشاط هي وقت العملية مقسوما على إجمالي وقت العميل المتوقع:
$${Activity\ ratio\ =\ }{\dfrac{Process\ time}{Total\ lead\ time}}$$
هذه هي كفاءتنا. ضرب الكفاءة في 100 للحصول على نسبة مئوية. تكون النتيجة أكبر من 0٪ وعادة أقل من 100٪. تشير النسبة المئوية الأعلى إلى كفاءة أكبر.
استبدل أرقامنا ونحصل على:
$${Activity\ ratio\ =\ }{\dfrac{5\ days}{22\ days}}{\ =\ .23}$$
ضرب النتيجة في 100 وتحصل على 23٪.
كما ترون، لدينا الكثير من المجال للتحسين. يستغرق 22 يوما لتطوير ميزة طويلة جدا.
تيم: كيف يساعدنا ذلك؟
أين نذهب من هنا؟
مارا: من المفيد أن نرى أين نحن الآن حتى نتمكن من تحديد المناطق التي توجد بها نفايات. نريد تقليل الوقت الذي نقضيه ليس له قيمة للعميل. أعتقد أنه يمكننا تحسين كفاءتنا حقا من خلال اعتماد نهج DevOps. لشيء واحد، يمكننا أتمتة العديد من هذه الخطوات، والتي قطعا قطعا في الوقت المحدد.
أنا لا أقترح أن نسقط عملياتنا الحالية، ولكن أعتقد أنه يمكننا العمل نحو عملية أكثر كفاءة بزيادات صغيرة دون تعطيل ما لدينا حاليا.
لنلق نظرة على بعض المجالات التي يمكننا تحسينها.
أندي: قد نبدأ أيضا من البداية. يستغرق مني وقتا طويلا للحصول على تسمية على التعليمات البرمجية حتى نتمكن من بدء الميزة الجديدة. يجب أن أتجول للمطورين وأطلب منهم التحقق مما لديهم حتى نتمكن من البناء والاختبار. إذا كنت تستطيع معرفة كيفية تسريع ذلك، سيكون لديك انتباهي.
كما لاحظت أنه ليس لديك وقت للبناء نفسه. هذا يستغرق نصف يوم الآن سيكون من الجيد أن نرى أن الوقت يتحسن.
أميتا: لا تقوم Dev دائما بتحديث جدول البيانات لإعلامي بوجود إصدار جديد يحتاج إلى اختبار. من شأنه أن يوفر الوقت إذا كانت هناك طريقة للتأكد من إنجاز هذا الجزء.
مارا: رائع! أعتقد أن DevOps يمكن أن يساعدنا في كل هذه المخاوف.
أندي: ليس لدينا الوقت لتغيير العملية الآن. لقد سمعت إروين نحن في وضع الأزمات هنا!
مارا: أفهم ذلك. في الوقت الحالي، لنفعل ما نفعله دائما. ولكن يمكننا جميعا أن نفكر في دورنا في العملية وكيف يمكننا أن نتحسن. يمكننا البدء في إجراء تغييرات صغيرة بالتوازي مع عملياتنا الحالية. يمكننا بعد ذلك معرفة ما إذا كان DevOps يساعدنا دون تعطيل ما لدينا. سأحتفظ بهذه الخريطة ومقاييس الأداء. إذا انتهى الأمر إلى اعتماد ممارسات Azure DevOps، فيمكننا إعادة النظر في الأرقام. ربما يمكننا تحديث VSM في مرحلة ما.