قصص المستخدم ومعايير القبول: الجسر بين احتياجات العمل ومهام التطوير

تذكرة تقول \"أضف فلتراً\" تترك المطوّر يخمّن بالضبط ما تعنيه كلمة \"منجز\". قصة مستخدم بمعايير قبول حقيقية تُزيل التخمين كلياً.

متطلب يُسلَّم لمطوّر كسطر واحد غامض — "أضف فلتر بحث" — يُبنى، ثم يُرفض، لأن ما تخيّله المطوّر وما احتاجه العمل فعلياً كانا شيئين مختلفين لم يُجعلا يلتقيان على ورق أولاً.

صيغة قصة المستخدم تفرض السؤال الصحيح

"بصفتي [نوع مستخدم]، أريد [هدفاً]، لكي [سبباً]" تبدو بسيطة، لكن الجملة الثالثة — السبب — هي ما يهم فعلياً. فلتر يُطلب "لكي أجد فواتير الشهر الماضي غير المدفوعة بسرعة" يُبنى بشكل مختلف تماماً عن الفلتر نفسه مطلوباً لسبب أساسي مختلف، حتى لو بدا عنوان التذكرة متطابقاً.

معايير القبول تحوّل النية إلى قائمة تحقق

• محدد وقابل للاختبار: "الفلتر يعمل جيداً" ليس معياراً؛ "تُحدَّث النتائج خلال ثانية واحدة من اختيار خيار فلتر" هو كذلك.
• يغطي الحالات الحدّية أيضاً: ماذا يُظهر الفلتر حين لا تتطابق أي نتيجة؟ هذه ليست فكرة لاحقة — بل معيار على أحدهم أن يقرره فعلاً.
• متفق عليه قبل بدء التطوير: معايير تُكتب بعد الحقيقة تصبح مجرد عذر لاحق لأياً كان ما بُني.

هذا حوار لا مجرد صيغة مستند

القيمة الحقيقية ليست قالب القصة — بل الحوار الذي تفرضه بين من يريد الميزة ومن سيبنيها، ليكشف الافتراضات التي كان كل طرف يضمرها بصمت قبل أن يكتب أي منهما سطر كود أو سطر توثيق.

الخلاصة

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