إن تسريع إنتاج الكود دون تغيير بقية العملية لا يُسرّع عملية التسليم، بل يُسرّع ظهور المشاكل في بيئة الإنتاج. لا تُقاس سرعة فريق التطوير بمدى سرعة كتابة الكود، بل بمدى سرعة قدرتهم على إجراء التغييرات بأمان، وقد ازداد انفصال هذين الأمرين خلال العامين الماضيين.
إنها ظاهرة مدروسة، وليست مجرد شك.
وجد تقرير DORA لعام 2024 الصادر عن Google Cloud، والذي شمل استطلاعًا لآراء حوالي 39000 متخصص، أن زيادة بنسبة 251% في تبني الذكاء الاصطناعي ارتبطت بانخفاض في 1.5% في إنتاجية التسليم ومن 7.2% في الاستقرار. التفسير الذي قدمه المؤلفون أنفسهم ليس أن الكود أسوأ، ولكن حجم دفعات التغيير يتزايد: يتم إرسال المزيد دفعة واحدة، ويتم مراجعته بشكل أقل دقة، ويتم نشره بمخاطر أكبر.
أضافت دراسة METR التي أُجريت في يوليو 2025 بُعدًا آخر للدراسة. ففي تجربة مضبوطة شملت 16 مطورًا خبيرًا في 246 مهمة واقعية، استغرق المشاركون وقتًا أطول بمقدار 191 وحدة زمنية (TP3T) عند استخدامهم للذكاء الاصطناعي، على الرغم من توقعهم إنجاز المهام أسرع بمقدار 241 وحدة زمنية، وبعد الاختبار، ظلوا يعتقدون أنهم أنجزوها أسرع بمقدار 201 وحدة زمنية. تجدر الإشارة إلى أن METR نفسها راجعت تصميم الدراسة في عام 2026 للتحقق من احتمال وجود تحيز في اختيار العينة، وأظهرت مجموعة أكبر من المشاركين فرقًا أقل بكثير: ولا تزال النتيجة الدقيقة محل نقاش.
ما لا خلاف عليه هو النتيجة الثانوية، وهي النتيجة المهمة لأي اتجاه: إن الإحساس بالسرعة والسرعة الفعلية أمران منفصلان.. قد يشعر الفريق بأنه يتحرك بشكل أسرع بكثير، على الرغم من أن النظام يستغرق وقتاً أطول للوصول إلى مرحلة الإنتاج.
يُعدّ حجم التغيير العامل الخفي وراء معظم مشاكل التسليم. فالتغيير الصغير يُراجع بدقة، ويُختبر بالكامل، ويُطبّق بسرعة، وإذا فشل، يُمكن تحديد السبب في غضون دقائق. أما التغيير الكبير فلا يسمح بأي من ذلك.
عامل | فكة صغيرة | تغيير كبير |
|---|---|---|
جودة المراجعة | هذا مفهوم تماماً | «"يبدو ذلك معقولاً"» |
تغطية الاختبار | قابل للتحقق | جزئي في الممارسة |
وقت التشخيص في حالة الفشل | دقائق | ساعات أو أيام |
تكلفة عكس العملية | قليل | توقف: إنه يعيق أشياء أخرى. |
مخاطر النشر | محدود | متراكم |
حتى وقت قريب، كان جهد كتابة الكود بمثابة حد طبيعي لحجم الدفعة. ومع زوال هذا الحد، يزداد حجم الدفعة ما لم يقرر أحدهم تقييده صراحةً. ولعل هذا القرار - أي تقييد حجم التغييرات - هو التدخل الأكثر فعالية من حيث التكلفة المتاح لفريق التطوير اليوم.
إن قياس عدد أسطر البرمجة، أو المهام المنجزة، أو "إنتاجية كل مطور" يزيد الوضع سوءًا لأنه يكافئ السلوك الذي يُسبب المشكلة. وتبقى مقاييس DORA الأربعة هي المعيار الأمثل.
معدل النشر. كم مرة يتم إدخال منتج ما في عملية الإنتاج؟ يشير التكرار العالي إلى دفعات صغيرة.
وقت التسليم للتغيير. منذ لحظة كتابتها وحتى إنتاجها. فهي تقيس العملية برمتها، وليس الكتابة نفسها فقط.
تغيير معدل الفشل. ما هي نسبة عمليات النشر التي تؤدي إلى وقوع حادث؟ هذا هو العامل الموازن للسرعة.
وقت استعادة الخدمة. كم من الوقت يستغرق التعافي؟ إنه يقيس القدرة الفعلية على التشغيل.
يقيس المعياران الأولان السرعة، بينما يقيس المعياران الأخيران الاستقرار، ويجب النظر إليهما معًا. الفريق الذي يُحسّن المعيارين الأولين ولكنه يُضعف المعيارين الأخيرين لم يُحسّن أداءه، بل نقل العمل ببساطة إلى المستقبل وإلى فريق الدعم.
قلل حجم التغييرات. أبسط الإجراءات وأكثرها فعالية. فهو يجبر على تقسيم العمل إلى وحدات مفهومة ويعيد الجودة إلى المراجعة.
استثمر في الاختبارات قبل التركيز على السرعة. مع ازدياد حجم الشيفرة البرمجية، تزداد أهمية شبكة الأمان، لا العكس. فبدون اختبار موثوق، يصبح تقييد الأداء مخاطرة متكررة.
أتمتة النشر والتراجع. إذا كانت عملية النشر مكلفة، فسوف يقوم الفريق بتجميع التغييرات حتى تصبح مجدية، وستعود الدفعة الكبيرة.
قم بقياس الثبات بنفس مستوى وضوح قياس السرعة. إذا كانت لوحة معلومات اللجنة تعرض عمليات التسليم فقط، فسيعمل الفريق على تحسين عمليات التسليم.
لا تكافئ السرعة المنفردة. تُحفز الحوافز السلوك. فإذا تم الاحتفاء بما يُرسل بدلاً من تحمله، سيزداد الإرسال ويقل التحمل.
تتوقع العديد من اللجان أن تُترجم مساعدة الذكاء الاصطناعي إلى تقديم ضعف الكمية المطلوبة خلال نفس الفترة الزمنية. هذا التوقع هو ما يُولّد الضغط الذي يُقوّض الاستقرار.
يتألف الحوار الصريح من جزأين. أولاً: لقد تسارع توليد الكود بالفعل بشكل ملموس وقابل للقياس. ثانياً: عملية التسليم عملية أشمل - تشمل الفهم والمراجعة والاختبار والتكامل والنشر والتشغيل - ولا تتسارع إلا عند معالجة الحزمة بأكملها.
ترجمة إلى جملة مناسبة للاستخدام في المجلس: لقد خفضنا تكلفة جزء واحد من العملية، وليس العملية بأكملها.. إن الاستفادة من هذا التحسن تتطلب الاستثمار في الباقي، وليس المطالبة بضعف الشيء نفسه.
هذا هو نفس الاستنتاج الذي تم التوصل إليه من منظور معماري، ولهذا السبب عاد النقاش إلى التصميم بدلاً من التنفيذ، كما ناقشنا في تكمن المشكلة مرة أخرى في الهندسة المعمارية
يُسرّع ذلك من عملية توليد التعليمات البرمجية، ولكن ليس بالضرورة من عملية التسليم. وقد وجد تقرير DORA لعام 2024 أن زيادة بنسبة 25% في تبني الذكاء الاصطناعي ارتبطت بانخفاض بنسبة 1.5% في الإنتاجية وانخفاض بنسبة 7.2% في الاستقرار، ويعزى ذلك إلى نمو أحجام دفعات التغيير.
لأنها تحدد جودة المراجعة، والتغطية الفعلية للاختبارات، والوقت اللازم لتشخيص الأعطال، وتكلفة التراجع عنها. كان جهد كتابة الكود بمثابة حد طبيعي لحجمه؛ ومع زوال هذا الحد، يجب تقييده بشكل صريح.
تتضمن مقاييس DORA الأربعة ما يلي: معدل النشر، ووقت تسليم التغيير، ومعدل فشل التغيير، ووقت استعادة الخدمة. يقيس المقياسان الأولان السرعة، بينما يقيس المقياسان الأخيران الاستقرار؛ ويجب قراءتها معًا.
أظهرت تجربة METR التي أُجريت عام 2025 تأخيرًا قدره 19% لدى مطورين ذوي خبرة كانوا يتوقعون تسريعًا قدره 24%. وقد راجعت METR نفسها لاحقًا تصميم الدراسة بحثًا عن أي تحيزات محتملة، وأظهرت مجموعة أكبر من المشاركين فرقًا أقل. والنتيجة الثابتة هي أن السرعة المُتصوَّرة تختلف عن السرعة الفعلية.
اختبار آلي موثوق، ونشر آلي، وإمكانية التراجع، وحد أقصى واضح لحجم التغييرات. مع ازدياد حجم التغييرات، تزداد أهمية شبكة الأمان والقدرة على التراجع، لا العكس.
لأنها تكافئ السلوك الذي يُسبب المشكلة: إنتاج كميات أكبر دون ضمان وصولها إلى خط الإنتاج بشكل موثوق. الحافز هو ما يُحدد السلوك، وقياس الإنتاج بدلاً من النتائج يُحوّل التكلفة إلى الدعم والاحتياجات المستقبلية.
هل يُنجز فريقك العمل بشكل أسرع أم أنه ينتج المزيد فقط؟ نقوم بتحليل عملية التسليم بأكملها - المراجعة والاختبار والنشر والتشغيل - ونخبرك أين تكمن المشكلة الحقيقية. لنتحدث →
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
