كتب user story

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

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

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

وبوجه عام تتبع قصص المستخدم القالب الأتي:

" بما أني <دور>، أريد <هدف/رغبة> من أجل <منفعة>

إلا أنه في الغالب يتم استخدام الصيغة الأقصر أيضا:

" بما أني <دور>، أريد <هدف/رغبة>"

أمثلة

كممثل للعميل، أريد البحث عن عملائي بأسمائهم الأولى والأخيرة.

كمستخدم غير إداري، أريد تعديل مواعيد أعمالي لكن ليس مواعيد أعمال مستخدمين آخرين.

كمختبر تطبيق جهاز محمول، أريد اختبار حالات الاختبار الخاصة بي وكتابة تقرير بالنتائج لإدارتي.

بداية التطبيق يبدأ التطبيق من خلال جلب المستند الأخير الذي كان يتعامل معه المستخدم.

بينما يغلق المستخدم التطبيق، أريد تنبيهي بالحفظ إذا غيرت شيءًا من بياناتي منذ آخر عملية حفظ.

غلق التطبيق عند غلق التطبيق، يُطلب من المستخدم الحفظ (إذا تم تغيير أي شيء في البيانات منذ آخر عملية حفظ!).

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

الاستخدام

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

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

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

الفوائد

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

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

الحدود

بعض الحدود في قصص المستخدم في وسائل أيجيل:

• قد يصعب قياسها بالنسبة للمشروعات الكبيرة.
• تعتبر مستهلات للمحادثات.

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

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