يسمع كل قائد هندسي في النهاية الأسئلة نفسها من الأعمال. هل نسلّم بسرعة كافية؟ هل تتحسن الجودة؟ هل يؤتي الاستثمار في الأدوات والمنصات ثماره؟ الإجابة بالحكايات غير مرضية، والإجابة بأرقام خاطئة خطرة. فأسطر الكود وعدد الإيداعات ونقاط القصص والساعات المسجلة سهلة الجمع، لكنها تقيس النشاط لا النتائج، ويمكن التلاعب بها بطرق تجعل البرمجيات أسوأ.
وخلال العقد الماضي قدّمت الأبحاث إجابات أفضل. فبرنامج DevOps Research and Assessment، المعروف بـDORA، حدد مجموعة صغيرة من المقاييس تتنبأ بأداء تسليم البرمجيات والنتائج المؤسسية معًا. وجادل إطار SPACE الذي نشره عام 2021 باحثون من مايكروسوفت وGitHub وجامعة فيكتوريا بأن الإنتاجية متعددة الأبعاد ولا يمكن اختزالها في رقم واحد. وفي الآونة الأخيرة اتجه الاهتمام إلى تجربة المطور مؤشرًا استباقيًا للسرعة والجودة.
يشرح هذا المقال هذه الأفكار، ويبيّن كيفية جمع المقاييس وتفسيرها، ويصف المزالق التي تحوّل القياس إلى ضرر، ويعرض مثالًا تطبيقيًا لفريق يستخدم المقاييس لإيجاد عنق زجاجة وإزالته.
لماذا يصعب قياس تسليم البرمجيات
تطوير البرمجيات عمل معرفي. مخرجاته غير ملموسة، وجهده يصعب مقارنته بين المهام، وقيمته تعتمد على بناء الأشياء الصحيحة لا على كمية ما بُني فقط. قد يسهم مطور يحذف ألف سطر من كود متقادم أكثر ممن يضيف ألفًا.
ويلخص قانون غودهارت الخطر الأساسي: عندما يصبح المقياس هدفًا، يتوقف عن أن يكون مقياسًا جيدًا. فإذا كوفئت الفرق على إغلاق التذاكر قسّمتها إلى قطع صغيرة. وإذا حُكم عليها بنسب تغطية الاختبارات كتبت اختبارات تنفذ الكود دون أي تأكيد. وإذا رُتّب الأفراد بعدد الإيداعات أودعوا أكثر وتعاونوا أقل. والمقاييس السيئة الاختيار لا تفشل في المساعدة فحسب، بل تعيد توجيه الجهد نحو المقياس بعيدًا عن الهدف.
والحل ليس تجنب القياس ولا إيجاد مقياس مثالي، بل اختيار مقاييس تعكس النتائج، واستخدامها على المستوى الصحيح، والجمع بين عدة مقاييس يوازن بعضها بعضًا، وتطبيقها للتعلم لا للعقاب.
مقاييس DORA الأربعة الرئيسية
منذ عام 2014 استطلع فريق DORA عشرات الآلاف من المهنيين وحلل النتائج إحصائيًا في تقارير حالة DevOps السنوية وفي كتاب «Accelerate» لنيكول فورسغرين وجيز هامبل وجين كيم. ووجدوا أربعة مقاييس تميّز معًا المؤسسات عالية الأداء، اثنان للإنتاجية واثنان للاستقرار.
تواتر النشر يقيس عدد مرات الإطلاق الناجح إلى الإنتاج. يشر الأداء المتميز عند الطلب مرات عدة يوميًا، بينما ينشر ضعيف الأداء شهريًا أو أقل. ويعني النشر المتكرر دفعات صغيرة وأتمتة وثقة.
زمن التغيير الاستباقي يقيس الوقت من إيداع الكود إلى تشغيله في الإنتاج. الأزمنة القصيرة تعني تغذية راجعة سريعة وتسليمًا أسرع للقيمة وقدرة على الاستجابة للمشكلات بسرعة. يقيس الفريق المتميز ذلك بالساعات أو أقل، وضعيف الأداء بالأشهر.
معدل فشل التغيير يقيس نسبة عمليات النشر التي تسبب فشلًا في الإنتاج يتطلب معالجة، كتراجع أو إصلاح عاجل أو ترقيعة. وهو يعبّر عن جودة ما يُصدر.
زمن استعادة الخدمة، ويسمى أحيانًا متوسط زمن التعافي، يقيس الوقت اللازم للتعافي من فشل في الإنتاج. ولأن الأعطال حتمية، فإن القدرة على اكتشافها وإصلاحها بسرعة لا تقل أهمية عن منعها. وصقلت أبحاث DORA الأحدث هذا المقياس إلى زمن التعافي من النشر الفاشل، مركزة على الأعطال الناتجة عن التغييرات.
وأهم ما وجدته الأبحاث أن السرعة والاستقرار ليسا مقايضة. فالأداء العالي جيد في المقاييس الأربعة معًا، لأن الممارسات التي تمكّن التسليم السريع، كالتغييرات الصغيرة والاختبار الآلي والتطوير على الفرع الرئيسي، تحسن الجودة أيضًا. وهذا قلب الاعتقاد الشائع بأن السرعة تعني كسر المزيد.
وفي السنوات الأخيرة أكدت DORA أيضًا الموثوقية بعدًا خامسًا، واستخدمت تحليل العناقيد بدل العتبات الثابتة لوصف مستويات الأداء، لذا ينبغي للفرق التعامل مع المعايير المنشورة سياقًا تقريبيًا لا أهدافًا صارمة.
ما يحرّك المقاييس: القدرات
أعظم قيمة في DORA لا تكمن في المقاييس الأربعة بل في قائمة القدرات التي تتنبأ بها. وتشمل التكامل المستمر، والتطوير على الفرع الرئيسي، وأتمتة الاختبارات، وأتمتة النشر، والمعمارية ضعيفة الارتباط، والمراقبة وقابلية الرصد، والتحكم بالإصدارات لكل شيء، والعمل بدفعات صغيرة، وثقافة تنظيمية مولِّدة قائمة على الثقة وتدفق المعلومات. وعلى الفرق التي تريد تحسين المقاييس أن تستثمر في هذه القدرات بدلًا من التلاعب بالأرقام مباشرة.
ولهذا تُفهم المقاييس بأفضل شكل مؤشراتٍ تشخيصية. تخبرك أين تنظر، وتخبرك القدرات ما الذي يجب تغييره.
إطار SPACE
بينما تركز DORA على أداء التسليم، يعالج إطار SPACE السؤال الأوسع عن إنتاجية المطورين. وقد اقترح مؤلفوه خمسة أبعاد تعطي حروفها الأولى اسم الإطار.
الرضا والرفاهية يلتقط مدى شعور المطورين بالإنجاز تجاه عملهم وفريقهم وأدواتهم وثقافتهم، وهل هم معرضون للإرهاق. الأداء يلتقط مخرجات النظام أو العملية، كالجودة والموثوقية وأثر العملاء، بدل حجم الإنتاج. النشاط يعدّ كمية الأفعال أو المخرجات، كالإيداعات وطلبات الدمج والحوادث المعالجة؛ وهو مفيد سياقًا لكنه خطر وحده. التواصل والتعاون ينظر في كيفية عمل الأفراد والفرق معًا، ومنه جودة مراجعة الكود وسرعة الاستقبال وسهولة العثور على التوثيق. الكفاءة والتدفق يقيس القدرة على إنجاز العمل بأقل تأخير وانقطاع، بما في ذلك التسليم بين الفرق وأوقات الانتظار ووقت التركيز المتواصل.
ويقدم الإطار عدة قواعد عملية. التقط مقاييس عبر ثلاثة أبعاد على الأقل في آن واحد، حتى لا تخفي المكاسب في بُعد الخسائر في آخر. وأدرج قياسات إدراكية من الاستطلاعات بجانب بيانات النظام، فتجربة المطورين الخاصة تكشف مشكلات لا تكشفها القياسات الآلية. وتذكّر أن المقاييس على مستوى الفرد كثيرًا ما تضلل، لأن الإنتاجية تعتمد بقوة على الفريق والنظام. لا يحدد SPACE مقاييس بعينها، بل هو عدسة لتصميم مجموعة قياس تناسب سياقًا معينًا.
تجربة المطور مؤشرًا استباقيًا
امتداد طبيعي هو فكرة تجربة المطور (DevEx)، وتركز على شعور المطورين تجاه بيئة عملهم وتفاعلهم معها، وتدعمها أبحاث لأبي نودا ومارغريت-آن ستوري ونيكول فورسغرين وميشيلا غرايلر، الذين اقترحوا ثلاثة أبعاد: حلقات التغذية الراجعة والحمل المعرفي وحالة التدفق.
حلقات التغذية الراجعة هي سرعة وجودة الاستجابات التي يتلقاها المطورون من الأدوات والأشخاص: زمن البناء والاختبارات ومراجعة الكود، وسرعة الإجابة عن الأسئلة. الحمل المعرفي هو الجهد الذهني اللازم لإنجاز مهمة، ويزيده تعقيد قواعد الكود وغموض التوثيق وكثرة الأدوات. حالة التدفق هي القدرة على التركيز وإحراز تقدم بأقل مقاطعة، وتشكلها كثرة الاجتماعات وعبء المناوبة ووضوح الأهداف.
تهم تجربة المطور لأنها تسبق النتائج لا تتبعها. فالبناء البطيء والعمليات الغامضة تستنزف الوقت والمعنويات قبل أن تظهر في زمن التغيير أو إحصاءات ترك العمل. ويشمل قياسها عادةً استطلاعات قصيرة منتظمة تطلب تقييم جوانب مثل سهولة الإصدار وسرعة مراجعة الكود والثقة بالاختبارات والوقت الضائع في الأدوات، مع بيانات النظام مثل مدة التكامل المستمر ووقت الانتظار في الطابور. وتستخدم فرق هندسة المنصات هذه المقاييس بشكل متزايد لترتيب أولويات الاستثمار في منصات المطورين الداخلية.
جمع البيانات
يمكن جمع معظم بيانات DORA من الأنظمة التي يستخدمها الفريق أصلًا. يأتي تواتر النشر من خط النشر أو أداة الإصدار. ويمكن حساب زمن التغيير بربط الإيداعات في التحكم بالإصدارات بأحداث النشر. ويتطلب معدل فشل التغيير تعريفًا متسقًا للفشل، يُشتق عادةً من سجلات الحوادث أو التراجعات أو عمليات النشر العاجلة المرتبطة بالتغيير الأصلي. ويأتي زمن الاستعادة من نظام إدارة الحوادث، مقيسًا من الاكتشاف إلى الحل.
وتسهّل الأدوات المفتوحة والتجارية ذلك. Four Keys مشروع مفتوح المصدر من غوغل يبني لوحة من بيانات GitHub أو GitLab والحوادث. وتوفر منصات تجارية مثل LinearB وJellyfish وSwarmia وSleuth وDX رؤى مشابهة وأوسع، وتضيف منصات قابلية الرصد مقاييس التسليم بصورة متزايدة. وأيًا كانت الأداة، فأهم مهمة هي الاتفاق على التعريفات. ما الذي يُعد نشرًا؟ متى يبدأ زمن التغيير؟ ما الذي يعد فشلًا؟ ودون تعريفات واضحة مشتركة ستختلف الأرقام بين الفرق ويستحيل مقارنتها.
وتستحق جودة البيانات اهتمامًا. فتذاكر الحوادث التي تُنشأ متأخرة أو تُغلق بإهمال تشوه زمن الاستعادة. والإيداعات المدمجة والفروع طويلة العمر تحجب زمن التغيير. وينبغي أن تعامل الفرق خط القياس نفسه شيئًا يُراجع ويُحسَّن.
كيف تستخدم المقاييس بحكمة
تفصل عدة مبادئ بين الاستخدام المنتج والضار.
قِس على مستوى الفريق أو النظام لا الفرد. فالتسليم إنجاز جماعي، وترتيب الأفراد بالمقاييس يدمر التعاون ويشجع التلاعب. استخدم المقاييس لتسأل ما الذي يبطئ الفريق لا من البطيء.
ركّز على الاتجاهات لا القيم المطلقة. المقارنة بين فريقين مضللة لاختلاف السياقات: فريق يصون جهازًا طبيًا منظّمًا يعمل ضمن قيود مختلفة عن فريق يدير موقعًا استهلاكيًا. قارن الفريق بماضيه ونظر في الاتجاه والتباين.
زاوج المقاييس ليوازن بعضها بعضًا. زيادة تواتر النشر مع مراقبة معدل فشل التغيير تمنع التهور، وتقليل زمن التغيير مع مراقبة رضا المطورين يمنع الإرهاق.
استخدم المقاييس لبدء حوارات. الرقم دافع للتحقيق لا حكم. عندما يرتفع زمن التغيير يجب أن يسأل الاستعراض الاستيعادي لماذا، وستجد الإجابة غالبًا بالتحدث إلى المعنيين.
لا تربط المقاييس مباشرة بتقييمات الأداء الفردية أو التعويضات. فبمجرد استخدامها أهدافًا سيجري التلاعب بها وستنهار الثقة بالبيانات. وعلى القيادة أن تكون صريحة في هذا الالتزام.
واجمع بين الأدلة الكمية والنوعية. فالاستطلاعات والمقابلات والملاحظة تكشف لماذا تبدو الأرقام كما هي.
أنماط مضادة شائعة
تتكرر أخطاء معروفة. معاملة مقاييس المخرجات مثل السرعة كأهداف إنتاجية تقود إلى تضخيم التقديرات. واستخدام نقاط القصص لمقارنة الفرق لا معنى له لأن النقاط نسبية لكل فريق. وعدّ أسطر الكود يكافئ الإسهاب. وقياس الاستخدام أو ساعات العمل يكافئ الحضور لا التقدم ولا يترك مجالًا للتحسين أو الابتكار. ونشر لوحات ترتيب للمطورين يولد الاستياء. واعتماد أداة ولوحة دون تحديد القرارات التي ستُبنى عليها ينتج رسومًا لا يستخدمها أحد. وتحسين مقياس واحد بمعزل، كدفع تواتر النشر بنشر تغييرات فارغة أو تافهة، ينتج أرقامًا جيدة المظهر دون تسليم شيء.
مثال تطبيقي: إيجاد عنق الزجاجة
لنفترض فريق منتج من ثمانية مهندسين في شركة متوسطة. تريد القيادة أن تعرف هل يسلّم الفريق جيدًا، ويقرر قائد الفريق إنشاء خط أساس باستخدام مقاييس DORA واستطلاع قصير للمطورين.
يتفق الفريق أولًا على التعريفات. النشر هو إصدار الخدمة الرئيسية إلى الإنتاج. وزمن التغيير يمتد من أول إيداع في طلب الدمج إلى النشر الناجح. والفشل هو أي نشر يتبعه تراجع أو إصلاح عاجل أو حادث خلال 24 ساعة. ويسحبون البيانات من المستودع وخط النشر ومتتبع الحوادث للربع الماضي.
النتائج كالتالي. تواتر النشر مرة كل تسعة أيام تقريبًا. وسيط زمن التغيير أحد عشر يومًا. ومعدل فشل التغيير 8 بالمئة. ووسيط زمن الاستعادة 50 دقيقة. معدل الفشل وزمن التعافي مقبولان، لكن سرعة التسليم بطيئة. ويضيف الاستطلاع الذي أجراه المهندسون الثمانية جميعًا سياقًا: يقيّمون الثقة في الاختبارات بأنها عالية، لكنهم يقيّمون عملية الإصدار بأنها ضعيفة، وتذكر التعليقات الحرة انتظار الموافقات ومرحلة انحدار يدوية.
للعثور على السبب، يقسّم الفريق زمن التغيير إلى مراحل. وقت البرمجة، من أول إيداع إلى طلب الدمج، نحو يوم. ووقت المراجعة، من فتح الطلب إلى الموافقة، يومان. أما الوقت من الدمج إلى النشر فثمانية أيام، لأن الإصدارات تُجمَّع في قطار إصدار نصف شهري يتطلب موافقة يدوية من مجموعة جودة منفصلة واختبار انحدار يدويًا من أربع ساعات. فعنق الزجاجة ليس التطوير ولا المراجعة بل عملية الإصدار.
يصوغ الفريق فرضية: أتمتة فحوص الانحدار والانتقال إلى النشر عند الدمج، محميًا بأعلام الميزات وتحليل كناري آلي، سيخفض زمن التغيير دون رفع معدل الفشل. فيحولون أهم الفحوص اليدوية إلى اختبارات شاملة آلية خلال سباقين، ويضيفون طرحًا تدريجيًا مع تراجع آلي عند ارتفاع معدل الأخطاء، ويستبدلون الموافقة اليدوية بفحوص سياسات آلية ومراجعة التغييرات عالية المخاطر فقط.
بعد ثلاثة أشهر يعيدون القياس. يرتفع تواتر النشر إلى نحو يومي. وينخفض وسيط زمن التغيير إلى يومين. ويصبح معدل الفشل 6 بالمئة، أفضل قليلًا لأن التغييرات أصغر. ويتحسن زمن الاستعادة إلى 20 دقيقة بفضل التراجع الآلي. وفي الاستطلاع اللاحق يرتفع الرضا عن عملية الإصدار من ضعيف إلى جيد، ويذكر المهندسون مقاطعات أقل. ويراقب الفريق أيضًا الآثار غير المرغوبة: ارتفع زمن المراجعة قليلًا لأن طلبات الدمج تصل أكثر تكرارًا، فيتفقون على معيار المراجعة خلال أربع ساعات عمل.
والدروس المهمة واضحة. حددت المقاييس أين ننظر. وحدد تقسيم المراحل عنق الزجاجة. وأكد الاستطلاع الأثر البشري. وجاء التحسن من القدرات لا من الضغط لبلوغ رقم. وعرض الفريق نتائجه على القيادة قصةَ إزالة احتكاك لا بطاقة درجات.
كيف تبدأ
تستطيع المؤسسة البدء بتواضع. اختر فريقًا أو اثنين تجريبيين. اتفق على تعريفات DORA الأربعة وقِسها من الأنظمة القائمة. أجرِ استطلاعًا ربع سنويًا قصيرًا عن تجربة المطور بخمسة إلى عشرة أسئلة. راجع النتائج معًا في الاستعراضات، واختر تحسينًا واحدًا، وقس مجددًا. شارك النتائج بانفتاح بما فيها الانتكاسات، وقاوم إغراء إطلاق لوحات نتائج على مستوى الشركة. ومع نمو الثقة وسّع الممارسة، وأضف أبعادًا من SPACE كالتعاون والرفاهية، واربط البيانات بقرارات الاستثمار كأولويات المنصة وميزانيات الأدوات.
الخاتمة
يساعد القياس الجيد المؤسسات الهندسية على رؤية نفسها بوضوح. تقدم مقاييس DORA مجموعة صغيرة موثقة من المؤشرات لسرعة التسليم واستقراره. ويذكّرنا إطار SPACE بأن للإنتاجية أبعادًا كثيرة وأن تجربة الأشخاص تهم بقدر بيانات النظام. وتوفر تجربة المطور إنذارًا مبكرًا بالاحتكاك قبل أن يصبح نتيجة.
وإذا استُخدمت هذه الأدوات بعناية، فإنها تدعم حوارات صادقة واستثمارًا موجهًا وتحسينًا مستمرًا. وإذا استُخدمت بإهمال تحولت إلى أدوات مراقبة وتلاعب. والفرق في النية: قِس الأنظمة لا الأفراد، وراقب الاتجاهات لا الترتيب، وأوازن السرعة بالاستقرار والرفاهية، وتتبّع الأرقام دائمًا إلى الأشخاص والممارسات التي تنتجها.