Backlog Refinement وAI: ما الذي يتغير فعلاً

تحليل عملي لكيفية تغيير AI لعملية Backlog Refinement: ما الذي يتسارع، وأين تظهر المخاطر، وكيف يُعاد توزيع وقت الفريق، وما الذي يجب التحقق منه يدوياً.

26 Mar 2026 · 06:54 UTC21 دقائق للقراءة

Telegram الأصل

هذه هي المقالة الأولى في سلسلة حول كيفية تغيير AI للاجتماعات الكلاسيكية لفريق التطوير متعدد الوظائف. أدناه سأبدأ بـ Backlog Refinement, وفي المواد التالية سأفرد بالتحليل Planning, وDaily وReview وRetrospective، ثم سأجمع كل شيء في مقالة مراجعة ختامية.

سأوضح الإطار فوراً: أدناه أتحدث عن refinement كجلسة فريق منتظمة وممارسة لتوضيح backlog items، وليس بالضرورة كحدث Scrum رسمي مستقل. هذا مهم لدقة المصطلحات: في Scrum Guide 2020 (RU PDF) ، يُوصف refinement كنشاط مستمر (ongoing activity) وليس كحدث (event) مستقل. في النسخة الروسية من Scrum Guide 2020 صيغت هذه الفكرة بوضوح: توضيح Product Backlog هو نشاط دائم لإضافة التفاصيل والترتيب والحجم.

Backlog Refinement هو أحد أول المواضع التي يبدأ فيها AI بجلب فائدة ملموسة تماماً للفريق. فهو يساعد على جمع السياق بسرعة، وإعداد مسودة للصياغة، وتوليد مسودة سريعة لمعايير القبول، وإيجاد حالات مشابهة، وصياغة قائمة بالأسئلة المفتوحة. هذا الطرح تدعمه أيضاً أعمال أكثر تطبيقية: على سبيل المثال، في LLM-Assisted Requirements Engineering in Agile MDD تم التحقق بشكل منفصل من توليد معايير القبول، وفي الحالة الصناعية Acceptance Test Generation with Large Language Models لاحظ المستخدمون أن سيناريوهات AI ساعدتهم على ملاحظة حالات كانت قد فاتتهم سابقاً. ولكن لهذا السبب بالتحديد يسهل هنا الوقوع في الفخ: الخلط بين مسودة جيدة الإعداد ومهمة مفهومة فعلاً.

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

"AI يسرّع ليس الاتفاق الجماعي نفسه، بل إعداد المادة له"

لماذا تُلاحظ التغييرات أولاً في Backlog Refinement تحديداً

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

في هذه الطبقة تحديداً يقع AI بشكل جيد للغاية. وهذا يتوافق جيداً أيضاً مع كيفية مناقشة تطبيق LLM في requirements engineering اليوم: النماذج قوية في التلخيص والهيكلة الأولية للمتطلبات وتوليد المسودات ودعم الإعداد التحليلي، لكنها أضعف حيث تكون هناك حاجة إلى الدقة في مجال العمل والتتبع والمسؤولية عن القرارات النهائية. بهذا المعنى، يصبح refinement فعلاً أحد أول العمليات التي تُلاحظ فيها فائدة AI بسرعة، وحدود موثوقيته — على الفور تقريباً. يُكتب عن هذا جيداً في مراجعة Challenges in applying large language models to requirements engineering tasks, وفي المراجعة المنهجية الحديثة Large Language Models (LLMs) for Requirements Engineering (RE): A Systematic Literature Review, وفي العمل الأكثر تطبيقية LLM-Assisted Requirements Engineering in Agile MDD.

الفريق يحلل backlog item بمساعدة AI ومخرجات Agile — AI يسرّع الإعداد لـ refinement جيداً، لكنه لا يستبدل التحقق الجماعي من المعنى.

كيف كان refinement يبدو قبل AI

بالتبسيط، كان refinement قبل AI في كثير من الأحيان عملية تجميع يدوي للفهم. لم تكن المهمة الجاهزة هي ما يدخل إلى backlog، بل بالأحرى نية عمل: تحسين onboarding، إضافة تذكيرات، منح المدير تقريراً جديداً، تقليل عدد الطلبات المتأخرة. بعد ذلك كان مالك المنتج أو المحلل أو أحد القادة يبدأ في جمع السياق يدوياً: تُرفع طلبات العملاء القديمة، والميزات المشابهة، وقيود البنية الحالية، والحالات السارية، والإشعارات الموجودة، وأنماط UI، وكل ما قد يطفو فجأة أثناء النقاش.

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

الحالة نفسها: بدون AI ومع AI

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

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

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

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

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

هنا عادةً يظهر سؤال طبيعي: وماذا لو أغفل AI شيئًا؟ إلى أي مدى يمكن الوثوق بمثل هذا الملخص الموجز أصلًا، خصوصًا عندما تكون قاعدة المصادر كبيرة؟ تعطي الأبحاث والحالات العملية هنا صورة واقعية إلى حد ما: يمكن لنماذج LLM بالفعل تسريع توليد قصص المستخدم ومسودات معايير القبول والمواصفات الأولية، لكن جودة النتيجة تعتمد بشدة على السياق المدخل والمجال والمراجعة البشرية اللاحقة. لذلك من المفيد أن نضع في الاعتبار أيضًا أعمالًا أكثر تطبيقية مثل AI-Generated User Stories: Are They Good Enough? و LLM-Assisted Requirements Engineering in Agile MDD: فهي تُظهر جيدًا أن توليد مسودة قوية والجاهزية للتطوير ليسا الشيء نفسه.

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

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

«كلما كبرت قاعدة المصادر وكان الملخص المختصر أكثر إقناعًا، ارتفع خطر الخلط بين الإعداد القوي والفهم المُتحقَّق منه بالفعل»

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

في ماذا يتمثل تقدم الفريق؟

عندما يبدأ الفريق للتو في استخدام الذكاء الاصطناعي، فإنه يعمل أساسًا كمولّد سريع للمسودة الأولى. لكن مع نضج الفريق، فإن الخطوة المنطقية التالية هي التوقف عن العمل مع النموذج العام فقط والبدء تدريجيًا في نقل ما كان يعيش سابقًا في ذاكرة الناس فقط إلى سياق الفريق المُدار. قد تكون هذه مبادئ المنتج، وقوالب معايير القبول، والأسباب الشائعة لرفض المهمة في refinement، والحالات الحدية النموذجية، والقيود المعمارية، ومجموعة الأسئلة التوضيحية النموذجية، واللوائح الداخلية للمؤسسة، وDefinition of Ready وDefinition of Done على مستوى المؤسسة والفريق، وأمثلة الحلول الجيدة لحالات مشابهة.

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

ما الذي يتغير حسب الأدوار

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

الدور	بدون ذكاء اصطناعي	مع ذكاء اصطناعي
مالك المنتج	يرفع سياق العميل يدويًا، ويجمع طلبات فريق دعم العملاء، ويعيد شرح مشكلة العمل في الاجتماع.	يُعدّ مدخلًا مجهول الهوية، ويطلب من الذكاء الاصطناعي تجميع آلام العملاء، ويأتي إلى الاجتماع بمسودة صياغة المشكلة وقائمة قرارات المنتج الخلافية.
محلل أعمال	يبحث عن حالات مشابهة، ويجمع يدويًا الحالات والقيود والتبعيات ثم يعيد كتابة كل شيء في المسودة الأولى للمواصفة.	ينظم طلبًا إلى الذكاء الاصطناعي حسب المصادر، ويطابق الملخص المختصر مع المصادر، ويحرر معايير القبول، ويسجل الأسئلة المفتوحة وما قد يكون النموذج أغفله.
مطور خلفية	غالبًا ما يتعمق في المشكلة لأول مرة في refinement، ويطرح قيود خدمة الإشعارات ومخاطر التكرار أثناء النقاش مباشرة.	قبل الاجتماع يحصل على مسودة أولى للخيارات التقنية، ويتحقق مسبقًا من إزالة التكرار ومهام المجدول وaudit trail وحدود الإصدار الأول.
مطور واجهة أمامية	في الاجتماع يحاول مع المصمم فهم ما إذا كانت هناك حاجة لشاشة منفصلة، وأين تعيش الإعدادات، وما الذي يدخل فعليًا في الحد الأدنى من واجهة المستخدم.	قبل الاجتماع يطلع على مسودة الذكاء الاصطناعي لدمج الواجهة، ويحدد مسبقًا النقاط الخلافية حول الإعدادات والحالات وقيود الواجهة.
مهندس جودة / QA	ينضم أساسًا في الاجتماع، ويستخرج السيناريوهات السلبية وتعارضات الحالات والمخاطر الزمنية في الحوار العام.	قبل الاجتماع يحصل على قائمة أولية بالحالات الحدية، ويتحقق من أن الذكاء الاصطناعي لم يغفل التكرارات والمناطق الزمنية وسيناريوهات fallback اللغوية والاستثناءات المتعلقة بحالات المستخدمين.
مصمم UX/UI	يفهم المهمة أثناء النقاش ويقدّر في المكان ما إذا كانت هناك حاجة لشاشة جديدة أو كتلة إعدادات أو سجل إرسال.	يختبر بسرعة مع الواجهة الأمامية عدة خيارات لنهج واجهة المستخدم ويأتي باقتراح مدروس بدلاً من البدء من الصفر.
سكروم ماستر	يجمع المشاركين، ويحافظ على التوقيت، ويساعد على عدم الضياع في رفع السياق الفوضوي، ويعيد الفريق إلى الجوهر عندما يتشعب النقاش.	يقضي وقتاً أقل على الميكانيكا التنظيمية ومواءمة السياق الأساسي، ووقتاً أكثر على تيسير القرارات الخلافية وتوثيق الأسئلة المفتوحة ومراقبة جودة النقاش.

الإيجابيات والمخاطر والوقت المتحرر

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

من المفيد هنا تسمية الأشياء بأسمائها. أولاً، هذا تحيز الأتمتة والاعتماد المفرط — الميل إلى قبول توصية النظام بسهولة مفرطة والانتقال من التحقق النشط إلى المراقبة الأكثر سلبية. في ملف NIST للذكاء الاصطناعي التوليدي يُوصف هذا صراحةً كثقة مفرطة في أنظمة الذكاء الاصطناعي، وفي الدراسة التجريبية Automation Bias in AI-Decision Support: Results from an Empirical Study يُظهر أن الفائدة المتصورة العالية للنظام قد تزيد من الموافقة الخاطئة على أخطائه، بينما تقلل جودة تدريب المستخدمين من احتمال هذا التأثير. ثانياً، هذا هلوسة النموذج — استنتاج معقول لكنه غير مدعوم بالمصادر. وهذا أمر بالغ الأهمية في التنقيح تحديداً، لأن الذكاء الاصطناعي يعمل دائماً تقريباً عبر تلخيص المستندات والتذاكر والمراسلات، ما يعني أن الخطر لا يقتصر على "مسودة معايير قبول جميلة لكنها مختلقة"، بل يشمل أيضاً التشويه الصامت للسياق الأصلي. ولهذا السبب بالذات يخطئ الذكاء الاصطناعي في التنقيح غالباً ليس في أسلوب النص، بل في وقائع السياق — وهذا الخطر موصوف جيداً في عمل On Faithfulness and Factuality in Abstractive Summarization. والترياق العملي هنا بسيط إلى حد ما: أن يُطلب من النموذج فصل الوقائع عن الفرضيات، والمطالبة بمراجع للمصادر، وبناء ملخص موجز بحيث يمكن تفكيكه بسرعة إلى المستندات والتذاكر وقرارات الفريق.

وهناك طبقة أخرى من المخاطر — البيانات. في الحالة أعلاه يعمل الذكاء الاصطناعي مع استفسارات العملاء والأوصاف الداخلية للنظام وإشارات المستخدمين. لذلك من المهم أن يتفق الفريق مسبقاً على ما يمكن تمريره إلى النموذج وما لا يمكن. بالنسبة للذكاء الاصطناعي التوليدي، لا يقتصر الخطر على الـ prompt فقط: فقد تظهر البيانات الشخصية في المدخلات والمخرجات وحتى عبر memorization/regurgitation للنموذج. لذلك، إذا كانت البيانات الشخصية أو سياق العملاء الحساس حاضراً في العمل، فيجب أن تكون مبادئ نظافة البيانات الأساسية إلزامية: تقليل حجم البيانات في الـ prompts، وإخفاء الهوية للمدخلات حيثما أمكن، وعدم جلب تصدير خام إلى النموذج دون تصفية، وفهم هدف المعالجة بوضوح، وعدم قبول تصريحات المزود مثل "نحن لا نعالج البيانات الشخصية" أو "النموذج مجهول" دون ضوابط تنظيمية وتقنية قابلة للتحقق. ومن المفيد أيضاً تثبيت الأساس القانوني للمعالجة مسبقاً، والحد الأدنى الضروري من الحقول، والأدوار والمسؤوليات داخل العملية، وحيثما ينطبق، متطلبات إبلاغ أصحاب البيانات. وإذا كان السيناريو يتضمن بيانات شخصية وكان النطاق أو المخاطر ملحوظاً، فمن المنطقي تقييم مسبقاً ما إذا كانت DPIA مطلوبة، وتثبيت هذا القرار بشكل منفصل. في السياق الأوروبي، يتوافق هذا جيداً مع مبادئ GDPR Article 5, ومع التوصيات العملية لـ CNIL بشأن تطوير أنظمة الذكاء الاصطناعي, وكذلك مع EDPS guidance on Generative AI و EDPB Opinion 28/2024.

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

تكاليف خفية جديدة لا يمكن تجاهلها

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

تقييم سيناريوي للجهد المبذول في جلسة Backlog Refinement واحدة (سيناريو)

فيما يلي ليس "متوسط حرارة السوق"، بل نموذج سيناريوي لنفس جلسة Backlog Refinement لنفس الفريق المكوّن من سبعة أشخاص: PO وBA ومطوّر خلفية ومطوّر واجهة وQA ومصمم وScrum Master. هذا تقييم لعنصر backlog واحد كبير أو غير محدد بوضوح، وليس لقصة صغيرة مفهومة جيدًا. قيمة هذه الأرقام ليست في دقتها حتى الدقيقة، بل في مقارنة بنية التكاليف: أين كان الوقت يُصرف سابقًا وأين يُصرف الآن.

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

ملاحظة على حساب الجهد: تاريخيًا في Scrum Guide 2017 (RU PDF) كان refinement يُوصف أيضًا كعملية مستمرة، وكان هناك توجيه بأنه عادةً لا يستغرق أكثر من 10% من السعة المتاحة لفريق التطوير. في Scrum Guide 2020 (RU PDF) لم يعد هذا التوجيه موجودًا، لذا يُفضّل قراءة الجدول أدناه ليس كمعيار، بل كنموذج سيناريوي لمقارنة نمطي عمل.

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

لكي يكون هذا التقييم قابلًا للتكرار، من المناسب حسابه وفق مخطط بسيط: T_AI = T_base × ((1 − p) + p × s) + o, حيث T_base — الوقت بدون AI، p — نسبة العمل القابل للتسريع، s — معامل التسريع في هذا الجزء، و o — العمل الجديد لتحضير البيانات والاستعلامات التوضيحية والتحقق من النتيجة.

فيما يلي مثال معاير خصيصًا لهذا السيناريو الأساسي. مهمته ليست إثبات معيار عالمي، بل إظهار كيف يمكن للنموذج نفسه أن يعيد إنتاج الأرقام من الجدول لحالة واحدة محددة. في فريق حقيقي، يُفضّل معايرة هذه المعاملات وفق آخر 3–5 جلسات Backlog Refinement ثم الحصول على نطاقك الخاص.

# Calibrated to reproduce the table (base scenario)
# T_ai = T_base * ((1 - p) + p * s) + o
roles = {
    "PO": {"T_base": 4.5, "p": 0.75, "s": 0.20, "o": 0.7},
    "BA": {"T_base": 10.0, "p": 0.70, "s": 0.20, "o": 0.6},
    "BE": {"T_base": 3.5, "p": 0.75, "s": 0.20, "o": 0.6},
    "FE": {"T_base": 3.0, "p": 0.75, "s": 0.20, "o": 0.3},
    "QA": {"T_base": 3.0, "p": 0.50, "s": 0.20, "o": 0.2},
    "UX": {"T_base": 3.0, "p": 0.50, "s": 0.20, "o": 0.2},
    "SM": {"T_base": 2.5, "p": 0.50, "s": 0.20, "o": 0.0},
}

def t_ai(x):
    return x["T_base"] * ((1 - x["p"]) + x["p"] * x["s"]) + x["o"]

total_base = sum(r["T_base"] for r in roles.values())
total_ai = sum(t_ai(r) for r in roles.values())

print("Total base:", round(total_base, 1))
print("Total AI:", round(total_ai, 1))
print("Gain:", round(total_base - total_ai, 1))

for role, x in roles.items():
    print(role, round(t_ai(x), 1))

الدور	بدون AI	مع AI (مع احتساب العمل الجديد)	ما الذي يتغير
مالك المنتج	4.5 ساعة	2.5 ساعة	يجمع سياق العميل بشكل أسرع، لكنه يخصص جزءًا من الوقت لتحضير المدخلات والاستعلامات التوضيحية
محلل أعمال	10 ساعات	5 ساعات	بحث وإعادة كتابة يدوية أقل، وتحقق وتحرير وفحص أكثر لما قد يفوته AI
مطوّر خلفية	3.5 ساعة	2 ساعة	يحصل على أول تحليل تقني بشكل أسرع، لكنه يتحقق بشكل منفصل من قيود البنية ومخاطر التكرار
مطوّر واجهة	3 ساعات	1.5 ساعة	يقيّم دمج الواجهة والإعدادات بشكل أسرع، وينخرط مبكرًا في التحقق من النقاط الخلافية
مهندس جودة / QA	3 ساعات	2 ساعة	يحصل على الحالات الحدية والمخاطر الزمنية مبكرًا، لكنه ينخرط أكثر في التحقق من الثغرات والسيناريوهات السلبية
مصمم UX/UI	3 ساعات	2 ساعة	يجمع أول نسخة من نهج الواجهة بشكل أسرع ويستبعد مسبقًا الخيارات الزائدة
Scrum Master	2.5 ساعة	1.5 ساعة	وقت أقل لمواءمة السياق التنظيمي، ووقت أكثر لتيسير القرارات وتوثيق الأسئلة المفتوحة
الإجمالي	29.5 ساعة	16.5 ساعة	الفائدة السيناريوية — نحو 13 ساعة عمل بشري في جلسة Backlog Refinement واحدة كهذه بعد احتساب العمل الجديد الأساسي

نطاق السيناريو: كيف يمكن أن تتغير الفائدة

السيناريو	بدون AI	مع AI	الفائدة الصافية	متى يحدث ذلك
حذر	24–28 ساعة	18–21 ساعة	4–10 ساعات	المصادر غير مكتملة، والتحقق اليدوي كثير، والفريق ما زال يبني قوالب العمل مع AI.
أساسي	28–32 ساعة	15–18 ساعة	10–15 ساعة	هكذا تقريبًا تبدو الحالة النموذجية: AI يسرّع التحضير جيدًا، لكن العمل الجديد على التحقق محتسب بالفعل.
قوي	30–36 ساعة	14–17 ساعة	13–19 ساعة	لدى الفريق مصادر جيدة وقوالب متكررة وقواعد واضحة لنظافة البيانات والتحقق اليدوي.

ما العمل الجديد المحتسب بالفعل في سيناريو AI

الجدول أدناه لا يلغي الفائدة النهائية من الجدول الأول. إنه فقط يوضح عبر أي إجراءات جديدة يعود جزء من الوقت الموفَّر إلى العملية — ولماذا يبقى الأثر الصافي ملحوظًا حتى بعد ذلك.

مجال العمل الجديد	ما يظهر مع AI	لماذا هذا ضروري
تحضير البيانات المدخلة	التنظيف وإخفاء الهوية واستخلاص السياق المطلوب	لكي لا نُثقل النموذج بالضوضاء ونجرّ بيانات زائدة
الاستعلامات التوضيحية	جولات متكررة، توضيح إطار الإجابة، طلب فصل الحقائق عن الافتراضات	لكي لا نأخذ أول إجابة جميلة كفهم نهائي
إعداد القوالب	المطالبات (prompts)، وقوالب الصياغات، وقواعد تنسيق النتيجة	لكي يُخرج AI مسودة مفيدة وقابلة للتكرار، لا نصًا عشوائيًا
التحقق من الحقائق	التحقق من مراجع المصادر والمصطلحات والحالات والقيود	لالتقاط هلوسات النموذج والوضوح الزائف قبل الاجتماع
توثيق الثقة	توثيق ما تم التحقق منه يدويًا ولماذا يمكن الوثوق بالنتيجة	حتى لا تستبدل الفرقة المسؤولية بمسودة أنيقة

الفروقات حسب المراحل

المرحلة	بدون AI	مع AI
جمع السياق قبل الاجتماع	بحث يدوي طويل في المستندات والتذاكر وذاكرة الأشخاص	المرور الأول على المصادر والملخص القصير يتمان بشكل أسرع بكثير
مسودة الصياغة	تُكتب يدويًا وغالبًا تبقى خامًا	توجد مسودة قوية يمكن للفرقة نقدها وتوضيحها
جلسة Backlog Refinement نفسها	يُستهلك الكثير من الوقت في مواءمة الفهم	ينتقل التركيز إلى القرارات الخلافية والتبعيات وحدود النسخة الأولى
التحسين بعد الاجتماع	غالبًا ما يُضطر إلى إعادة كتابة الصياغة من الصفر تقريبًا	النتائج معبأة جيدًا وتتطلب جهدًا يدويًا أقل

قائمة تحقق جودة التحضير بالذكاء الاصطناعي لـ refinement

مهم: هذا Definition of Ready هو ممارسة داخلية للفرقة وليس جزءًا من Scrum Guide. وهو مطلوب هنا كحماية من الوضوح الزائف والثغرات والمسؤولية الغامضة في التحضير بالذكاء الاصطناعي.

Definition of Ready للمسودة بالذكاء الاصطناعي

فُصلت الحقائق عن الافتراضات: تفهم الفرقة ما أُخذ من المصادر وما اقترحه النموذج.

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

الأسئلة المفتوحة ليست مخفية تحت نص أنيق، بل مذكورة صراحة.

تم التحقق من المصطلحات المجالية والحالات والقيود والأدوار والتبعيات.

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

تم التحقق بشكل منفصل من الحالات الحدية والسيناريوهات السلبية والمخاطر الزمنية.

من الواضح ما هي البيانات التي لم يكن مسموحًا تمريرها للنموذج وما إجراءات نظافة البيانات المطبقة.

تم تعيين مالكي التحقق حسب أنواع الادعاءات: منطق الأعمال، والجدوى المعمارية، وقابلية الاختبار، والتعامل مع البيانات.

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

لكي لا تبقى قائمة التحقق هذه مجردة جدًا، هكذا كانت ستبدو في حالتنا مع تذكيرات البريد الإلكتروني:

يقترح AI تضمين الحالات not_started, in_progress و expired — وتشير الفرقة صراحة إلى أن expired يبقى حتى الآن فرضية وليس قاعدة مؤكدة للنسخة الأولى.
يُذكر في الملخص القصير أنه يجب إرسال الإشعارات حسب المنطقة الزمنية للمستخدم — يتحقق الباك إند من ذلك مقابل المصادر ويؤكد أن المنطقة الزمنية في النظام الحالي مخزنة فقط على مستوى العميل، وأن الانتقالات بين المناطق الزمنية والتوقيت الصيفي يجب التحقق منها بشكل منفصل.
أضاف AI سجل الإرسالات كجزء "بديهي" من الحل — ويقرر مالك المنتج وBA بشكل منفصل ما إذا كان هذا جزءًا إلزاميًا من النسخة الأولى أم تحسينًا للإصدار التالي، لأن هنا أيضًا مسألة التدقيق والحمل على الدعم.
يحصل QA ليس على قائمة حالات حدية فقط، بل على مهمة محددة للتحقق من التكرارات عند إعادة تشغيل مهام المجدول، وسيناريوهات اللغة الاحتياطية، والاستثناءات للمستخدمين المؤرشفين والمعطلين، والسيناريوهات السلبية حول المواعيد النهائية.
يتحقق الباك إند بشكل منفصل من حدود المعدل وتقييد الطلبات وقابلية التسليم وكيف سيتصرف النظام عند الإرسالات المتكررة وأخطاء المزود.
يتحقق PO وBA إضافيًا من سياسة الإشعارات: من يجوز إرسال التذكيرات له، وأين يلزم opt-out أو استثناءات العملاء، وما يُعد سلوكًا مقبولًا للدورات الإلزامية.

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

من يتحقق من ماذا يدويًا

ما نتحقق منه	من المالك	مثال في حالة LMS
الهدف والسياسة المنتجية	PO وBA	من ومتى تُرسل التذكيرات، وما الاستثناءات المسموحة، وأين تقع حدود النسخة الأولى.
صحة القواعد والحالات	BA	أي الحالات تُعد "لم يكمل"، وما يُفعل بـ `expired` وأين تم تأكيد ذلك من المصادر.
القيود المعمارية	مطور الباك إند	إزالة التكرار، ومهام المجدول، والتماثل، وسجل التدقيق، وحدود المعدل، والسلوك عند الإرسالات المتكررة.
حدود واجهة المستخدم للنسخة الأولى	مطور الواجهة الأمامية ومصمم UX/UI	أين توجد الإعدادات، وهل يلزم شاشة منفصلة للسجل، وأي سيناريوهات الواجهة تدخل فعليًا في النسخة الأولى.
السيناريوهات السلبية والزمنية	مهندس الجودة / مهندس QA	التوقيت الصيفي، والمناطق الزمنية، وسيناريوهات اللغة الاحتياطية، واستثناءات المستخدمين المؤرشفين والمعطلين، وكذلك التكرارات عند إعادة تشغيل مهام المجدول.
تيسير القرارات والأسئلة المفتوحة	سكروم ماستر	ما تم حسمه، وما يبقى خلافيًا، وأين يجب على الفرقة قبول حل وسط واعٍ.
نظافة البيانات ومسموحيتها	PO/BA وإن وُجد، الأمن أو DPO	ما يمكن تمريره للنموذج، وما يجب إخفاء هويته، وما الفحوصات الإلزامية قبل تشغيل التحضير بالذكاء الاصطناعي.

ما كنت سأوصي به الفرقة

ألا تُعد المسودة بالذكاء الاصطناعي مهمة جاهزة لمجرد أنها تبدو جيدة.
الاتفاق صراحةً على أي أجزاء من السياق يجب أن تتحقق منها الفرقة يدويًا قبل الاجتماع، وأيها يتم التحقق منها في الاجتماع نفسه.
نقل الأنماط المنتجية والعملية الخاصة بالفريق تدريجيًا إلى طبقة الذكاء الاصطناعي الجماعية، بدلًا من استخدام الدردشة العامة "كما هي" فقط.
عدم تقليص جلسة التنقيح (refinement) آليًا لمجرد أن التحضير أصبح أسرع.
اتخاذ قرار واعٍ بشأن وجهة الوقت المُحرَّر: الجودة، أو التدريب، أو التوثيق، أو الدين التقني، أو استعادة انتباه الفريق.

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

الخلاصة

باختصار شديد، سأصوغ الأثر الرئيسي للذكاء الاصطناعي على التنقيح (refinement) هكذا: الذكاء الاصطناعي لا يسرّع اتفاق الفريق نفسه، بل يسرّع تحضير المادة له. ولهذا يصبح التنقيح أسرع عند المدخل: يُجمَّع السياق أسرع، ويظهر المسودة أسرع، وتُكشف الأسئلة الأساسية والمخاطر أسرع، وتُغلَّف النتائج أسرع.

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

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

المصادر والمراجع

← كل المقالات