ما هي قصص المستخدم ولماذا هي مهمة؟

تستخدم جميع فرق Scrum التي عملت معها تقريبًا “قصص المستخدم”. ومع ذلك، فإن معظمهم غير مدركين لأصل “قصة المستخدم”، فجميعهم يعتقدون أن قصة المستخدم هي “مطلب”. قد يكون ذلك صحيحًا إلى حد ما، لكن قصة المستخدم ليست كذلك.
في أبسط العبارات، قصة المستخدم هي طريقة للتعبير عن المتطلبات. عندما يتم وصف متطلب/وظيفة ما من منظور مستخدم المنتج أو النظام أو البرنامج، يُطلق عليها اسم قصة المستخدم.
نشأت قصة المستخدم أو القصص فقط مع البرمجة القصوى. في كتابه “شرح البرمجة القصوى” يصف كينت بيك القصص كممارسة أساسية يستخدمها فريق XP. في إطار XP، تتم كتابة قصص المستخدم من قبل العملاء على أنها الوظائف أو الميزات التي يريدون أن يقوم بها النظام/البرنامج من أجلهم. وغالباً ما تكون في شكل ثلاث جمل يكتبها العميل. تركز قصة المستخدم دائمًا على احتياجات وفوائد المستخدم. يبقي التفاصيل مثل التكنولوجيا أو جوانب التنفيذ خارجها.
كما هو مذكور أعلاه، قصة المستخدم هي طريقة للتعبير عن أي متطلبات من منظور المستخدم. ويمكن أن تكون بسيطة مثل جملة واحدة: “يمكن للطالب التسجيل في المقرر الدراسي المطلوب.” هنا، على الرغم من عدم توفر التفاصيل. فهي ببساطة تقول طالب، ومقرر دراسي، وتسجيل.
ماذا يجب أن نفعل بها؟ وهذا يؤدي إلى مناقشة، وهي عملية إنشاء فهم مشترك مشترك حول ماهية هذا الشرط.
وعادةً ما تبلور هذه المحادثات تفاصيل قصة المستخدم، وغالبًا ما تساعد المطورين والأعمال على الاتفاق على متى يمكننا القول بأن قصة المستخدم قد اكتملت. ويصف رون جيفريز هذه الجوانب الثلاثة لقصص المستخدم بـ 3C. البطاقة والمحادثة والتأكيد.
البطاقة: في الأيام الخوالي كانت قصص المستخدم تُكتب على بطاقة (فهرس/ملاحظات لاصقة). لم يكن هذا يحتوي على جميع المعلومات التي تصف المتطلبات ولكن ما يكفي فقط لتحديد ماهية المتطلبات. وغالبًا ما يتم استخدامها كرمز للبدء. تؤدي هذه البطاقة بعد ذلك إلى الفئة الثانية ج – المحادثة.
المحادثة: تعمل الشركة والمطورون الآن معًا لتوضيح المتطلبات من خلال المحادثة. يحدث هذا عدة مرات حتى يكون لدى الجميع فهم مشترك مشترك حول ماهية المتطلبات. على الرغم من أن هذه المحادثة غالبًا ما تكون شفهية، إلا أنه يتم تدوين الملاحظات، ويتم وضع معايير لتحديد متى يتم استدعاء قصة المستخدم مكتملة. هذا المعيار المحدد هو المعيار الثالث C – التأكيد.
التأكيد: على الرغم من كل المحادثة والتوثيق، هناك دائمًا احتمال وجود شكوك وافتراضات. يشير التأكيد إلى الجانب الأخير الذي يحدد ما إذا كانت قصة المستخدم مكتملة أم لا، أي ما إذا كانت قصة المستخدم تؤدي الوظيفة المقصودة. يُشار إلى هذا التأكيد أيضًا باسم “معايير القبول”.
انطلق في برنامج سكروم ماستر التدريبي الشامل المصمم لتزويدك بالمهارات والمعرفة اللازمة لإتقان فن إنشاء قصص المستخدمين. تعلم التقنيات الفعالة وأفضل الممارسات لاستنباط متطلبات المستخدم وتحديدها وتحديد أولوياتها.سجل اليوم
في معظم الفرق التي عملت معها، قصص المستخدم ليست عبارة عن سطر واحد كما عبرت عنها أعلاه. لديهم صيغة محددة للغاية على النحو التالي: بصفتي دور (من يريد القيام بشيء ما) أريد أن أفعل (النشاط الذي يجب إنجازه) بحيث تكون تلك القيمة (الهدف الذي سيتم تحقيقه) مثال بصفتي عاشقاً للكتب أريد أن أقرأ مراجعات الكتب حتى أتمكن من اتخاذ قرار شراء كتاب تم اختراع هذا القالب في Connextra، وهي من أوائل من تبنى ممارسات XP (المصدر: قصص المستخدم التطبيقية، مايك كوهن).
عندما يتم وصف أي متطلب من منظور المستخدم للمتطلب، يطلق عليه اسم قصة المستخدم. تتبع قصة المستخدم 3C – البطاقة والمحادثة والتأكيد. بالإضافة إلى ذلك، غالبًا ما يكون من المفيد أن تكون هناك ست سمات محددة بالاختصار INVEST – مستقلة، وقابلة للتفاوض، وقيّمة، وقابلة للتقدير، وصغيرة، وقابلة للاختبار، لتكون جزءًا من قصة المستخدم.
أعمل كمدرب لين-أجايل متحمس مع أكثر من 19 عامًا من الخبرة المتنوعة، وأعمل مع المهنيين والفرق والمنظمات لمساعدتهم في سعيهم لتحقيق الرشاقة. كوني مدرب محترف في سكروم (Scrum.org)، ومدرب محترف في سكروم (Scrum.org)، ومدرب معتمد من ICAgile.