قصص المستخدم ومعايير القبول

قصص المستخدم ومعايير القبول

قد تمتد حالة الاستخدام التقليدية على أربع صفحات، وقد تطمر قائمة المتطلبات المُرقَّمة الاحتياجَ الفعلي تحت طبقات من المصطلحات التقنية. اختُرعت قصص المستخدم لمعالجة هاتين المشكلتين معاً: إبقاء النقاش مرتبطاً بأشخاص حقيقيين لديهم أهداف حقيقية، مع الحرص على أن تظل القصة قصيرة بما يكفي لتُكتب على بطاقة. ستتعلم في هذا الدرس كيف تكتب قصصاً مفيدة فعلاً، وتقيّمها باستخدام معيار INVEST، وتُحدد معنى "الإنجاز" بدقة من خلال معايير القبول بصيغة Given-When-Then.

صيغة قصة المستخدم الثلاثية

الصيغة الكلاسيكية بسيطة ظاهرياً:

كل جزء يؤدي دوراً محدداً. الدور يُسمّي الشخص الذي سيتغير واقعه — ليس "النظام" أو "مستخدم"، بل شخصية محددة: موظف الاستقبال، مشرف المستودع، عميل عائد. الهدف يصف فعلاً من منظور المستخدم. أما عبارة حتى فتُعلن السبب — النتيجة التي يهتم بها المستخدم. هذا الجزء الثالث هو الذي تحذفه الفرق في أغلب الأحيان، وهو في الوقت نفسه الأكثر قيمة: يُخبر الفريق كيف تبدو النتيجة الناجحة ويمنع المبالغة في الهندسة.

ثلاثة أمثلة من مجالات مختلفة:

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

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

INVEST: ستة معايير لقصة صحية

يمنح اختصار INVEST الذي صاغه Bill Wake المحللين وأصحاب المنتج فحصاً سريعاً لجودة كل قصة قبل إدراجها في السبرنت. القصة التي ترسب في معيار واحد ستُسبب مشكلات في التسليم بشبه يقين.

من أكثر حالات الفشل في INVEST شيوعاً القصة غير المستقلة — كأن تُدرج قصة "بوصفي مريضاً، أريد تسجيل الدخول" كاشتراط صارم قبل كل قصة أخرى. الحل هو معالجة تسجيل الدخول كمتطلب تمكيني في أول سبرنت بنيوي، لا كقصة رسمية تُعرقل بقية المتراكم. أما الفشل الشائع الآخر فهو القصة الضخمة التي تُسمى ملحمة (Epic): "بوصفي عميلاً، أريد إدارة حسابي" ليست قصة — إنها موضوع يتفرع إلى عشرات القصص تشمل التسجيل وتسجيل الدخول وتعديل الملف والطلبات السابقة وغيرها.

معايير القبول: Given-When-Then

القصة تصف الرغبة؛ معايير القبول تصف العقد. إنها تُجيب على: كيف نعرف، بلا غموض، أن هذه القصة تحققت؟ أكثر الصيغ استخداماً هي Given-When-Then (GWT) المنبثقة من تطوير موجه بالسلوك (BDD):

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

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

معايير القبول:

1. المسار السعيد — إلغاء ناجح:
   Given أنني مسجّل الدخول ولديّ موعد محجوز في تاريخ مستقبلي،
   When أضغط "إلغاء الموعد" وأؤكد الإجراء،
   Then يتغير حالة الموعد إلى "ملغى"، يصبح الوقت متاحاً للمرضى الآخرين، وأتلقى رسالة SMS خلال دقيقتين.
2. قيد نافذة الإلغاء:
   Given لديّ موعد خلال الساعتين القادمتين،
   When أحاول إلغاءه،
   Then يعرض التطبيق رسالة "لا يمكن إلغاء المواعيد خلال ساعتين من وقتها المحدد. يُرجى الاتصال بالعيادة."
3. موعد ملغى مسبقاً:
   Given لديّ موعد في حالة "ملغى" بالفعل،
   When أنتقل إلى تفاصيل ذلك الموعد،
   Then يكون زر "إلغاء الموعد" مخفياً وتظهر علامة الحالة "ملغى".

الأخطاء الشائعة وكيفية تجنبها

حتى المحللون المتمرسون يقعون في الأخطاء التالية:

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

من القصص إلى عناصر المتراكم الجاهزة للسبرنت

عملياً، يكتب المحلل وصاحب المنتج القصص ويُرفقان معايير القبول بصيغة GWT، ثم يستعرض فريق التطوير كل قصة في جلسة تحسين المتراكم. يتحقق الفريق من اجتياز القصة لمعيار INVEST، ويقدّرها (نقاط قصة أو ساعات)، ويُشير إلى أي معايير ناقصة. بعد هذا النقاش فقط تُعتبر القصة جاهزة للسبرنت. ثم تُشكّل معايير القبول المرجع لإنشاء حالات الاختبار: كل معيار GWT يُقابله اختبار آلي أو يدوي على الأقل، مما يُنشئ خيطاً حياً من الحاجة العمل وصولاً إلى الاختبارات الناجحة في CI/CD.

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