# قصة المستخدم

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

## تكوين قصص المستخدم

عندما يحين وقت تكوين قصص المستخدم، يجتمع أحد المطورين مع ممثل العميل. ويكون العميل مسئولا عن صياغة قصص المستخدم. وربما يستخدم المطور سلسلة من الأسئلة للحصول على معلومات من العميل، مثل السؤال عن ما إذا كانت وظيفية معينة مرغوبة، لكن يجب الاحتراس من السيطرة على فكرة عملية التكوين.
وعندما يدرك العميل قصص المستخدم، فيجدها بطاقة ملاحظة مكتوبة (مثل 3×5 بوصة أو 8×14 سم) مع الاسم والوصف الذي صاغه العميل. فإذا وجد المطور أن قصة المستخدم ناقصة بطريقة ما (ضخمة للغاية أو معقدة أو غير دقيقة)، فتتم إعادة كتابتها حتى تكون مرضية. ويتم التأكيد في البرمجةالقصوى أن قصص المستخدم لا تكون محددة بعد أن تتم كتابتها. فالمتطلبات تميل إلي التغير أثناء فترة التطوير، والتي يتم التعامل معها على أنها ليست دائمة بل قابلة للتغيير.
وبوجه عام تتبع قصص المستخدم القالب الأتي:
إلا أنه في الغالب يتم استخدام الصيغة الأقصر أيضا:

## الاستخدام

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

## الفوائد

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

## الحدود

بعض الحدود في قصص المستخدم في وسائل أيجيل:
* قد يصعب قياسها بالنسبة للمشروعات الكبيرة.
* تعتبر مستهلات للمحادثات.

## قصص المستخدم وحالات الاستخدام

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

## انظر أيضا

* متطلب
* سكرم
* تطوير البرمجيات أجايل