كيف تكتب قصص المستخدم (مع أمثلة ومعايير قبول)

قصة المستخدم وصف قصير لميزة من وجهة نظر المستخدم: «بصفتي [نوع المستخدم]، أريد [هدف] حتى [سبب].» وتحتها تكتب معايير القبول، وهي بضعة شروط محددة يجب أن تتحقق حتى تُعد القصة مكتملة. اجعل كل قصة صغيرة بما يكفي لبنائها واختبارها دفعة واحدة، واكتب المعايير بحيث يستطيع أي شخص التحقق منها.

انتشرت قصص المستخدم بفضل فرق البرمجيات الرشيقة (Agile)، لكنها مفيدة بالقدر نفسه عندما تبني بمفردك باستخدام أداة بناء تطبيقات بالذكاء الاصطناعي. القصة الجيدة برومبت جيد.

الصيغة

لقصة المستخدم ثلاثة أجزاء:

بصفتي [من]، أريد [ماذا] حتى [لماذا].

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

مثال:

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

السبب يخبرك بشيئين لم يخبرك بهما «ماذا»: يجب أن تعمل الميزة على الهاتف، وقائمة الانتظار وقواعد الرسوم متضمنة فيها.

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

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

طريقة شائعة لكتابتها هي Given / When / Then:

• Given وضع بداية معين
• When يقوم المستخدم بشيء ما
• Then هذه هي النتيجة

لقصة حجز صالة الرياضة:

1. Given لدي حجز بعد أكثر من 12 ساعة، when أنقر على إلغاء وأؤكد، then يُحذف الحجز وأرى رسالة «تم إلغاء الحجز».
2. Given ألغيت حجزاً والحصة لها قائمة انتظار، when يُحفظ الإلغاء، then يحصل أول شخص في قائمة الانتظار على المكان ورسالة بريد إلكتروني.
3. Given حجز أقل من 12 ساعة، when أنقر على إلغاء، then أرى أن رسوم الإلغاء المتأخر تُطبَّق قبل أن أؤكد.
4. Given أنا على شاشة بعرض الهاتف، then زر الإلغاء مرئي دون التمرير أفقياً.

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

خطوة بخطوة: كتابة قصة جيدة

الخطوة 1: ابدأ من مستخدم حقيقي ومشكلة حقيقية

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

الخطوة 2: اكتب القصة في سطر واحد

املأ القالب. إذا لم تستطع كتابة «حتى» مقنعة، فاسأل نفسك هل الميزة مطلوبة أصلاً.

الخطوة 3: أضف من ثلاثة إلى ستة معايير قبول

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

الخطوة 4: دوّن ما هو خارج النطاق

سطر واحد يوفر كثيراً من الأخذ والرد: «خارج النطاق: استرداد أموال الحصص المدفوعة؛ والمديرون الذين يلغون عن الأعضاء.» يمنع القصة من النمو أثناء البناء.

الخطوة 5: تحقق منها وفق INVEST

INVEST قائمة تحقق شائعة للقصص الجيدة. يجب أن تكون القصة:

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

أمثلة جيدة وسيئة

كيف تقسّم قصة كبيرة؟

القصص الكبيرة هي ما يوقف المشاريع. طرق شائعة للتقسيم:

• حسب دور المستخدم. يلغي الأعضاء حجوزاتهم؛ ويلغي الموظفون أي حجز.
• حسب خطوة في التدفق. تصفح الحصص؛ واحجز حصة؛ واستلم تذكيراً.
• الحالة البسيطة أولاً. ألغِ حصة مجانية الآن؛ وعالج الرسوم والاسترداد في قصة لاحقة.
• حسب تنوع البيانات. ادعم موقعاً واحداً أولاً، ثم عدة مواقع لاحقاً.
• المسار السعيد ثم الأخطاء. ابنِ الميزة تعمل أولاً، ثم أضف المعالجة للحصص المكتملة والاشتراكات المنتهية وما شابه.

يجب أن تظل كل قطعة شيئاً يستطيع المستخدم استخدامه وملاحظته.

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

قصة المستخدم مع معايير القبول قريبة جداً من برومبت جيد لأداة بناء تطبيقات بالذكاء الاصطناعي. فهي تعطي الذكاء الاصطناعي الـ«من» و«ماذا» و«لماذا» وتعريفاً لاكتمال المهمة. أرسل قصة واحدة في كل رسالة:

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

1. زر الإلغاء موجود على كل حجز في «حجوزاتي»، مع خطوة تأكيد.
2. الإلغاء قبل أكثر من 12 ساعة من الحصة يزيل الحجز فقط.
3. أقل من 12 ساعة قبل الموعد، اعرض «تُطبَّق رسوم إلغاء متأخر قدرها 5 دولارات» قبل التأكيد، وسجّل الرسوم على الحجز.
4. إذا كانت للحصة قائمة انتظار، يحصل أول شخص فيها على المكان ورسالة بريد إلكتروني.
5. تعمل على شاشة بعرض الهاتف. خارج النطاق: الاسترداد، وقيام الموظفين بالإلغاء نيابة عن الأعضاء. ابنِ هذا، ثم تحقق من كل معيار في المعاينة وأخبرني أيها ينجح.

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

هذه فكرة تطبيقي: [جملتان أو ثلاث]. اكتب قصص المستخدم للنسخة الأولى، مجمّعة حسب نوع المستخدم، وكل قصة مع 3 إلى 5 معايير قبول بصيغة Given/When/Then. حدد أيها أساسي للإطلاق وأيها يمكن أن ينتظر.

اقرأ النتيجة وعدّلها دائماً. الذكاء الاصطناعي لا يعرف مستخدميك؛ أنت تعرفهم.

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

مكان قصص المستخدم بين الوثائق الأخرى

• وثيقة متطلبات المنتج تصف المنتج كله: المشكلة، والمستخدمين، والنطاق. قصص المستخدم هي القطع التفصيلية داخلها. راجع كيف تكتب PRD بالذكاء الاصطناعي.
• تقرير الخلل يصف شيئاً معطلاً مقارنةً بقصة سبق بناؤها. راجع كيف تكتب تقرير خلل جيداً.
• الحد الأدنى من المنتج القابل للتطبيق (MVP) هو أصغر مجموعة من القصص تقدم القيمة الأساسية. راجع ما هو MVP.

أخطاء شائعة

• «بصفتي مستخدماً…» عامة جداً. سمِّ النوع الفعلي للمستخدم.
• تخطي «حتى». بدون السبب لا يمكنك اتخاذ مفاضلات معقولة.
• كتابة الحل بدلاً من الحاجة. «أريد قائمة منسدلة» تثبّت تصميماً قبل أن يفكر أحد فيه.
• معايير لا يمكن اختبارها. «سهل» و«سريع» و«بديهي» أمنيات لا معايير.
• قصص هي في الحقيقة ملاحم (Epics). «إدارة حسابي» هي عشر قصص.
• كتابة كل القصص مقدماً. اكتب القصص القادمة القليلة بالتفصيل، واترك الباقي كأسطر قصيرة حتى تصل إليها.

القصص في Mythex

في Mythex، وضع Plan مكان مناسب لتحويل فكرة إلى قصص: يناقش الوكيل النهج قبل أن يعدّل أي شيء. عندما تصبح القصة جاهزة، انتقل إلى Build والصقها، قصة واحدة في كل رسالة. بعد كل واحدة، يمكن لـ/test أن ينقر عبر المعاينة ويتحقق من التدفق، ويمكنك التراجع عن أي رد بـRevert to this point إذا سار في الاتجاه الخاطئ. راجع البرومبتات الفعالة في الوثائق، ودليلنا عن كتابة البرومبتات لأدوات بناء التطبيقات بالذكاء الاصطناعي.

قائمة تحقق لقصص المستخدم

• تسمي نوعاً محدداً من المستخدمين
• تصف حاجة، لا تصميماً
• تتضمن سبب «حتى» حقيقياً
• لديها من ثلاثة إلى ستة معايير قبول قابلة للاختبار
• تغطي حالة استثنائية واحدة على الأقل أو خطأ
• تحدد ما هو خارج النطاق
• صغيرة بما يكفي لبنائها واختبارها دفعة واحدة
• تُفحص المعايير بعد البناء، واحداً تلو الآخر

الأسئلة