مستند المتطلبات معتمد، لكن فرق التنفيذ تعمل بـ stories لا بفقرات متطلبات — والفجوة بين الاثنين هي حيث ينحرف النطاق بصمت. متطلب واحد يُقسَّم إلى ثلاث stories وتُفقد النية الأصلية في واحدة منها؛ أو يضيف مطوّر story من نوع «سيكون جميلًا لو» لا تعود لأي شيء. هذا النظام يحوّل المتطلبات إلى backlog حيث تحمل كل epic و story رابطًا ظاهرًا لمتطلبها المصدر، بحيث يستطيع أي مراجع دائمًا الإجابة عن «لماذا توجد هذه الـ story؟» باسم وسطر من مستند المتطلبات، لا بهزّة كتف.
- مستند المتطلبات المعتمد (من اكتب مستند المتطلبات) — هذا هو المصدر الوحيد الذي يجب أن تعود إليه الـ stories.
- خريطة أصحاب المصلحة، إن وُجدت، لتعرف صاحب المصلحة المُسمّى الذي يخدمه كل متطلب.
- أي backlog أو تنسيق تذاكر يستخدمه فريق التنفيذ فعلًا، بحيث يُدرَج المُخرَج في أداتهم دون إعادة تنسيق.
-
جمّع المتطلبات في epics
افتح مستند المتطلبات في Claude Desktop واطلب تصنيفًا أوليًا، لا كتابة stories بعد. ضبط حدود الـ epics أولًا يمنع تشتت الـ stories لاحقًا عبر تصنيفات خاطئة.
أنت تطلباقرأ requirements-doc.md. جمّع المتطلبات الوظيفية في epics — كتل منطقية من القدرات المترابطة يمكن لفريق التنفيذ تخطيطها وتقديرها معًا. لكل epic، اذكر أرقام المتطلبات التي تغطيها وأعطها اسمًا واضحًا بلغة بسيطة. ضع علامة على أي متطلب لا يندرج بوضوح ضمن epic بمفرده.ما تحصل عليه تصنيف مقترح للـ epics مع أرقام المتطلبات المرتبطة تحت كل واحدة — مثل «Epic: توجيه اعتماد الفواتير ← يغطي R3، R4، R7» — مع علامة على أي متطلب يتيم يحتاج epic خاصة به أو مكانًا ضمن واحدة قائمة.
راجع التصنيف بنفسك قبل المتابعة — قد يجمّع Claude متطلبات تبدو متشابهة لكنها تخدم أصحاب مصلحة مختلفين. أنت تعرف المؤسسة؛ اكتشف ذلك قبل أن يتحول إلى عشر stories.
-
صِغ user stories تحت كل epic
قسّم كل epic الآن إلى stories، بالصيغة المعيارية، مع رابط التتبّع مبنيًا داخل الـ story نفسها لا ضمنيًا فقط.
أنت تطلبلـ epic '[اسم الـ epic]'، صِغ user stories بصيغة 'بصفتي [الدور]، أريد [القدرة]، حتى [السبب]'. لكل story، أضِف سطر: 'يعود إلى: [رقم المتطلب] — حاجة [اسم صاحب المصلحة]'. اجعل كل story صغيرة بما يكفي لبنائها واختبارها باستقلالية. لا تخترع قدرة غير موجودة في المتطلب.ما تحصل عليه مجموعة من الـ stories، كل واحدة بالصيغة المعيارية مع سطر تتبّع ظاهر يُسمّي كلًا من رقم المتطلب وصاحب المصلحة — بحيث لا تُترك أي story معلّقة بلا حاجة موثّقة.
-
اكتب معايير قبول قابلة للاختبار فعلًا
الـ story بلا معايير قبول قابلة للاختبار تفتح الباب لجدالات حول النطاق وقت المراجعة. اطلب معايير مصاغة بحيث يستطيع المختبِر التحقق منها دون سؤال إضافي عن معنى «مكتمل».
أنت تطلبلكل story أعلاه، اكتب 3-5 معايير قبول بصيغة Given/When/Then. اجعل كل معيار محددًا بما يكفي ليتحقق منه مختبِر دون سؤال متابعة. أضِف معيارًا واحدًا على الأقل يغطي حالة استثنائية أو مسار فشل، لا المسار الطبيعي فقط.ما تحصل عليه معايير Given/When/Then لكل story، تشمل حالة استثنائية واحدة على الأقل — مثل «بافتراض فاتورة تتجاوز سقف الاعتماد، عندما تُقدَّم، فإنها تُوجَّه إلى المعتمِد المُسمّى، لا إلى القائمة الافتراضية» — محددة بما يكفي لبناء اختبار منها مباشرة.
-
شغّل تدقيق التتبّع في الاتجاهين
دقّق الـ backlog مقابل مستند المتطلبات في اتجاهين: كل story تعود لمتطلب حقيقي، وكل متطلب لديه story واحدة على الأقل تغطيه. هذه الخطوة تكشف انحراف النطاق الصامت.
أنت تطلبدقّق هذا الـ backlog مقابل requirements-doc.md في الاتجاهين: (1) اذكر أي story يشير سطر 'يعود إلى' فيها إلى متطلب لا يطابق فعلًا ما يقوله ذلك المتطلب، و(2) اذكر أي متطلب من المستند لا تغطيه أي story. لا تُصلح شيئًا الآن — فقط أبلغ عن الفجوات.ما تحصل عليه تقرير فجوات بجانبين — روابط غير مطابقة ومتطلبات غير مغطاة — بحيث تُغلق نوعَي الانحراف قبل أن يذهب الـ backlog للتخطيط، لا أن تُكتشف في منتصف السبرنت.
المتطلب غير المُغطى غالبًا الفجوة الأخطر — فهو يعني أن حاجة معتمدة لصاحب مصلحة لا تُبنى فعليًا، بصمت.
-
رتّب حسب الأولوية مع إبقاء الرابط ظاهرًا، وجهّزه للتنفيذ
أضِف تمريرة أولويات ونسّق الـ backlog للأداة التي يستخدمها فريق التنفيذ فعلًا، مع الإبقاء على سطر التتبّع سليمًا عبر التصدير.
أنت تطلبأضِف أولوية مقترحة (Must/Should/Could) لكل story بناءً على حاجة صاحب المصلحة التي تخدمها وأي اعتماد بين الـ stories. ثم نسّق الـ backlog الكامل كـ [ملف CSV قابل للاستيراد إلى Jira / جدول Markdown / قائمة مرقّمة عادية — حدّد أيها]، مع إبقاء حقل 'يعود إلى' كعمود مستقل ليبقى موجودًا في أداة التنفيذ.ما تحصل عليه backlog مرتّب حسب الأولوية وجاهز للأداة مع عمود التتبّع سليمًا، جاهز لتسليمه للتنفيذ — كل story ما زالت تجيب عن «لماذا توجد» بعد التسليم.
- تغيّر المتطلب أثناء التنفيذ: أعِد تشغيل تدقيق التتبّع (الخطوة 4) كلما طرأ تغيير معتمد على مستند المتطلبات — سيكشف بالضبط أي stories تحتاج تحديثًا أو إيقافًا، بدل بحث يدوي في الـ backlog.
- برنامج كبير بعدة epics: شغّل الخطوتين 2-3 لكل epic في محادثات منفصلة بعد الاتفاق على التصنيف (الخطوة 1)، بحيث تحصل كل epic على اهتمام مركّز بدل كومة stories واحدة ضخمة.
- متطلبات غير وظيفية: إذا كان مستند المتطلبات يحتوي متطلبات غير وظيفية (أداء، أمان، صلاحيات وصول)، اطلب من Claude تحويلها إلى معايير قبول مرتبطة بالـ stories ذات الصلة بدل stories يتيمة بلا إطار «بصفتي مستخدم» واضح.
- تُغذّي حالة العمل: backlog بـ epics واضحة يسهّل كثيرًا جانب التكلفة في ابنِ حالة العمل — وجّه خطوة التكلفة في تلك الـ playbook نحو تصنيفات epics هذه.
- الـ story بلا سطر 'يعود إلى' لا تُشحَن. إذا صاغ Claude story لا يمكنك ربطها بمتطلب محدد وصاحب مصلحة، فذلك نطاق مُخترَع — احذفها أو اطلب تعديل مستند المتطلبات أولًا، ولا تدعها تمرّ صامتة إلى التخطيط.
- سيجمّع Claude بسعادة متطلبات تبدو متشابهة لكنها تأتي من أصحاب مصلحة مختلفين بإلحاح مختلف. راجع تصنيف الـ epics بنفسك في الخطوة 1 — تلك هي المراجعة التي تكشفها، لا تدقيق التتبّع لاحقًا.
- معايير القبول التي تغطي المسار الطبيعي فقط تبدو مكتملة وليست كذلك. أصرّ على معيار واحد على الأقل لحالة استثنائية أو مسار فشل لكل story — عادةً هناك يظهر الخلاف الحقيقي حول معنى «مكتمل».
- تدقيق التتبّع (الخطوة 4) ليس تنظيفًا اختياريًا — إنه الضمانة. تخطّيه هو بالضبط كيف يتوقف الـ backlog بصمت عن مطابقة مستند المتطلبات المعتمد الذي من المفترض أن يُنفّذه.
ستحصل في النهاية على backlog مرتّب حسب الأولوية وجاهز للتنفيذ، حيث تحمل كل epic و story سطرًا ظاهرًا يعود لمتطلبها المصدر وصاحب المصلحة، مع تدقيق تتبّع مكتمل في الاتجاهين يؤكد أنه لم يُخترَع شيء ولم يُفقَد شيء.
أسئلة يطرحها الناس
- ماذا يعني سطر 'يعود إلى' فعليًا في الـ story؟
- هو سطر في كل story يُسمّي رقم المتطلب الدقيق من مستند المتطلبات وصاحب المصلحة الذي تخدمه حاجته — مثل «يعود إلى: R4 — حاجة قسم المالية لتوجيه الفواتير عالية القيمة تلقائيًا». هذا ما يتيح لأي مراجع للـ backlog الإجابة عن «لماذا توجد» دون سؤال أحد.
- ماذا لو لم يتطابق متطلب ما مع أي story بوضوح؟
- هذا بالضبط ما يكشفه تدقيق التتبّع في الخطوة 4 — فهو يسرد كل متطلب بلا stories تغطيه. عامل ذلك كفجوة يجب إغلاقها قبل التخطيط، لا تفصيلًا يُصلَح لاحقًا؛ المتطلب غير المغطى عادةً يعني أن حاجة صاحب مصلحة لا تُبنى بصمت.
- هل يمكنني استخدام هذا دون مستند متطلبات رسمي؟
- يمكنك، لكن ضمانة التتبّع تكون أضعف بدونه — ستربط الـ stories بملاحظات غير رسمية بدل مصدر معتمد. يستحق الأمر تشغيل *اكتب مستند المتطلبات* أولًا، ولو بإيجاز، بحيث يكون للـ backlog شيء صلب يعود إليه.
- كيف أُبقي الـ backlog متزامنًا عند تغيّر المتطلبات؟
- أعِد تشغيل تدقيق التتبّع ثنائي الاتجاه (الخطوة 4) كلما طرأ تغيير معتمد على مستند المتطلبات. يكشف بالضبط أي stories موجودة أصبحت لا تطابق مصدرها الآن وأي متطلبات جديدة لا تملك story بعد، بدل الاعتماد على أن يتذكر أحد تحديث الـ backlog يدويًا.