دليل سكرم | 22. معايير قبول قصة المستخدم
نشرت: 2022-05-25User Story هي تقنية تسمح للشركات بتقديم المنتجات والخدمات التي تلبي احتياجات العملاء إلى أقصى حد. تعزز معايير قبول قصة المستخدم تقييم وظائف المنتج الجديدة من وجهة نظر المستخدم.
معايير قبول قصة المستخدم - جدول المحتويات:
- مقدمة
- كيف تصوغ معايير قبول قصة المستخدم؟
- معايير قبول قصة المستخدم مقابل تعريف تم
- ملخص
مقدمة
لقد غطينا قصة المستخدم والقضايا التي يجب معالجتها عند إنشائها في المقالات السابقة. ومع ذلك ، سنركز اليوم على معايير قبول "قصة المستخدم".
يجب أن تتبع معايير القبول هذه الإرشادات:
- وصف الوظيفة الجديدة والمحسّنة للمنتج من وجهة نظر المستخدم
- تكون فريدة لكل قصة مستخدم
لا يحدد دليل Scrum الرسمي قصة المستخدم ومعايير القبول الخاصة به. إنها اختيارية ، لكنها عناصر شائعة جدًا في عمل سكروم. ومع ذلك ، لتخفيف فضول قرائنا ، سنقوم بتصويرهم على النحو التالي: الشروط التي يجب أن يفي بها تحسين المنتج أثناء سباق معين للحصول على موافقة من المستخدم.
كيف تصوغ معايير قبول قصة المستخدم؟
تحتوي قصة المستخدم المكتوبة جيدًا على وصف واضح للسياق أو الموقف الذي يتعلق به ، وبالتالي تلبية معايير القبول. ومع ذلك ، فهي مجرد جملة قصيرة ، غامضة وغامضة للغاية بحيث لا يمكن تحديد الاعتبارات الضرورية بشكل مباشر.
وضوح معايير القبول وإمكانية الوصول إليها
لذلك ، لمنع الغموض ، قم بإجراء وتسجيل محادثة مفصلة مع العميل لتحديد الغرض من الحل المنفذ. تذكر أن الصياغة النهائية لمعايير القبول تعود إلى مالك المنتج.
قم بتدوينها مع معايير قصة المستخدم قبل تخطيط Sprint. يجب على كل عضو من أعضاء فريق Scrum قراءته والتأكد من فهمه لمعايير قبول قصة المستخدم والموافقة عليها. عادة ، تكون معايير القبول على الجانب الآخر من بطاقة قصة المستخدم.
تسمح معايير القبول المصاغة بشكل صحيح للمستخدم بالتحقق مما إذا كان اختبار قصة المستخدم يتبع وصفها. يمكن أن تأخذ المعايير شكل قائمة تحقق بنقاط نقطية لوضع علامة عليها عند الانتهاء أثناء اختبار المنتج في نهاية Sprint.
يكون الأمر بسيطًا إذا كانت عملية المنتج شفافة للمستخدم. ومع ذلك ، كلما زاد تعقيد المنتج ، زادت صعوبة اختباره. خذ برامج معقدة أو خدمات واسعة النطاق. لذلك ، في معظم الحالات ، من الأدوات المفيدة للتحقق من صحة قصة المستخدم إعداد اختبار قبول.
اختبار القبول
إذا قررت تطوير اختبار قبول ، فضعه على الجانب الآخر من البطاقة التي تحتوي على قصة المستخدم. لاحقًا ، يمكن لفريق Scrum أو فريق ضمان الجودة الخارجي تنفيذه.
يجب أن يحتوي الاختبار أولاً وقبل كل شيء على بيان واضح عما إذا كان المنتج قد فشل أو اجتاز الاختبار. لا يمكن أن تحتوي على بيانات النسبة المئوية أو تقييم وسيط.
إذا كانت قصة المستخدم تحتوي على أكثر من معيار قبول واحد ، فإن كل معيار يتطلب اختبارًا منفصلاً. بهذه الطريقة ، يكون من الأسهل كثيرًا تحديد وظيفة المنتج التي تحتاج إلى تحسين أو تنقيح وهي مهمة بشكل خاص إذا كانت الوظائف الجديدة المضمنة في قصة المستخدم متداخلة أو مستقلة عن بعضها البعض.
معايير قبول قصة المستخدم مقابل تعريف تم
يعد تعريف Done جزءًا لا يتجزأ من العمل في Scrum ، وهو المكافئ الفني لمعايير القبول. ومع ذلك ، يجب ألا تخلط بين هذين الأمرين لأنهما يشيران إلى التزامات مختلفة. ما هو تعريف تم ، وكيف ومتى يتم صياغته ، هل هذه مشكلة قمنا بتغطيتها في منشور منفصل؟
هنا ، سنذكر فقط أن تعريف تم هو وصف واضح وشفاف للحالة المتوقعة للمنتج بعد الانتهاء من الزيادة في Product Backlog. يصف التحسينات التي تم إجراؤها داخل الزيادة. يتناقض هذا مع معيار القبول المطابق لقصة المستخدم ، والذي يصف وظائف المنتج التي تم إنشاؤها خلال آخر سباق كما يراها العميل.
على سبيل المثال ، خذ قصة المستخدم هذه مع المحتوى:
بصفتي عميلاً مسجلاً الدخول لمتجر عبر الإنترنت ، أريد شراء عصا سحرية بنقرة واحدة.
قد يتضمن تعريف الإكمال لقصة المستخدم أعلاه ما يلي:
- إنشاء لوحة تسجيل دخول لعملاء المتجر
- تكامل نظام الدفع
- إضافة زر الدفع الفوري إلى قالب صفحة المنتج
من ناحية أخرى ، ميزة معايير قبول العميل:
- القدرة على تسجيل الدخول إلى المتجر
- إمكانية تحديد طريقة سداد افتراضية
- يعمل زر "اشتر الآن" لمنتج "العصا السحرية"
ملخص
معايير القبول هي مجموعة من الشروط التي تعمل كطريقة لتقييم تنفيذ قصة المستخدم. من خلال وصف أداء المنتج الجديد والمحسّن من وجهة نظر المستخدم ، تصبح هذه الطريقة أداة فعالة للعمل مع العميل. يعرض أداء فريق Scrum من وجهة نظر المستخدم.
تسمح لنا معايير القبول المصاغة جيدًا ، على سبيل المثال في شكل اختبار قبول ، بالتحقق خلال Sprint مما إذا كانت الوظيفة التي تم إنشاؤها تعزز تلبية متطلبات العميل.
تختلف معايير القبول عن تعريف "تم" بشكل أساسي في المنظور الذي تتخذه عند التعبير. لا تحتوي على وصف للمتطلبات الفنية التي يجب أن يفي بها الحل الجديد ، ولكن فقط الوظائف التي يجب أن يتميز بها المنتج بعد تفعيل قصة المستخدم الجديدة.
إذا أعجبك المحتوى الخاص بنا ، فقم بالانضمام إلى مجتمع النحل المشغول لدينا على Facebook و Twitter و LinkedIn و Instagram و YouTube و Pinterest.
المؤلف: كارولين بيكر
بصفتها مديرة المشروع ، تعد كارولين خبيرة في إيجاد طرق جديدة لتصميم أفضل تدفقات العمل وتحسين العمليات. مهاراتها التنظيمية وقدرتها على العمل تحت ضغط الوقت تجعلها أفضل شخص لتحويل المشاريع المعقدة إلى واقع.
دليل سكروم:
- مسرد للمصطلحات الأساسية والأدوار والمفاهيم
- ما هو سكرم؟
- قيم سكروم
- كيف تنفذ سكرم في شركتك؟
- فريق سكرم - ما هو وكيف يعمل؟
- من هو مالك المنتج؟
- أكثر أخطاء "مالك المنتج" شيوعًا
- من هو سيد سكرم؟
- خصائص سيد سكرم الجيد
- الأخطاء الأكثر شيوعًا في Scrum Master
- ما هي الإحصائيات والمقاييس التي يجب أن يتبعها Scrum Master؟
- التعاون بين مالك المنتج و Scrum Master
- فريق التطوير في سكرم
- أكثر أخطاء المطورين شيوعًا
- القطع الأثرية سكروم
- تحجيم سكروم
- سباق المتراكمة
- ما هو Product Backlog؟
- ما هي قصص المستخدم؟
- إنشاء أفضل قصة مستخدم مع INVEST
- أكثر أخطاء قصة المستخدم شيوعًا
- معايير قبول قصة المستخدم
- التقدير ونقاط القصة في سكرم
- التخطيط للبوكر
- لعبة تقدير الفريق
- تحديد الزيادة
- أحداث سكرم
- ما هو Sprint in Scrum؟
- التزامات فريق Scrum - هدف المنتج ، هدف Sprint وتعريف الإنجاز
- ما هو مخطط Burndown؟
- كيفية إنشاء وتفسير مخطط توقف؟
- مزايا وعيوب مخطط التوقف
- مجالس كانبان في سكرم وسكرومبان
- السرعة في سكرم - سرعة فريق التطوير
- ديلي سكرم
- Sprint Planning
- مراجعة Sprint
- ما هو معرض Sprint Retrospective؟
- الأخطاء الشائعة خلال Sprint Retrospective
- رعاية تراكم المنتج