قصة المستخدم

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

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

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

أمثلة

كممثل للعميل، أريد البحث عن عملائي بأسمائهم الأولى والأخيرة.
كمستخدم غير إداري، أريد تعديل مواعيد أعمالي لكن ليس مواعيد أعمال مستخدمين آخرين.
كمختبر تطبيق جهاز محمول، أريد اختبار حالات الاختبار الخاصة بي وكتابة تقرير بالنتائج لإدارتي.
بداية التطبيق
يبدأ التطبيق من خلال جلب المستند الأخير الذي كان يتعامل معه المستخدم.
بينما يغلق المستخدم التطبيق، أريد تنبيهي بالحفظ إذا غيرت شيءًا من بياناتي منذ آخر عملية حفظ.
غلق التطبيق
عند غلق التطبيق، يُطلب من المستخدم الحفظ (إذا تم تغيير أي شيء في البيانات منذ آخر عملية حفظ!).
سوف يقوم الاستشاري بإدخال المصاريف على استمارة مصاريف. وسيقوم الاستشاري
بإدخال بنود على الاستمارة مثل نوع المصاريف، والوصف، والمبلغ، وأي تعليقات بشأن المصاريف.
(1) بعد إكمال هذا، سوف يقوم الاستشاري " بالتقديم". فإذا كانت المصاريف اقل من (<50)،
فسوف تذهب المصاريف إلي النظام مباشرة من أجل العمليات.
(2) في حالة ما إذا لم ينه الاستشاري من إدخال المصاريف، فربما يريد الاستشاري " الحفظ لاحقًا".
وهذه الخطوة ينبغي أن يتم عرضها على قائمة (صف انتظار) للاستشاري مع حالة "عدم الاكتمال".
(3) في حالة ما إذا قرر الاستشاري مسح البيانات وغلق الاستمارة، فسوف "يلغي ويخرج " الاستشاري.
ولن يتم حفظ هذا الطلب في أي مكان.

الاستخدام

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