قصة المستخدم
قصة المستخدم في برمجة الحاسوب جملة أو أكثر في اللغة اليومية أو لغة أعمال المستخدم النهائي والتي تستحوذ على ما يريد المستخدم تحقيقه. ويتم استخدام قصص المستخدم مع وسائل [أيجيل لتطوير البرامج] من أجل أساس ما يمكن تنفيذه من ميزات. وكل قصة مستخدم محدودة، وبالتالي تتناسب مع بطاقة ملاحظة صغيرة من أجل ضمان أنها لا تتضخم. وينبغي أن تكتب قصص المستخدم عن طريق العملاء من أجل مشروع برمجي وهي أداتهم الرئيسية في التأثير على تطوير البرنامج. ويمن كتابة قصص المستخدمين من خلال المطورين للتعبير عن المتطلبات غير الوظيفية.[1]
لا تُوفِّر هذه المقالة السياق المناسب لتناول معلومات غير مألوفة لغير المختصين. (فبراير 2011) |
هذه المقالة لا تحتوي إلّا على استشهادات عامة فقط. (يونيو 2009) |
وقصص المستخدم هي طريقة سريعة للتعامل مع متطلبات العميل بدون استخدام الكثير من مستندات المطالب الرسمية وبدون أداء المهام الإدارية المثقلة المرتبطة بالمحافظة عليها. والقصد من قصة المستخدم هي القدرة على التجاوب بشكل أسرع وبعبء أقل مع متطلبات العالم الحقيقي المتغيرة بسرعة كبيرة.
وقصة المستخدم هي بيان غير رسمي للمطلب طالما أن هناك افتقارًا إلي تطابق إجراءات اختبار قبول. وقبل تنفيذ قصة المستخدم، يجب كتابة إجراء قبول مناسب عن طريق العميل للتأكد عن طريق الاختبار أو تحديد ما إذا تم تحقيق أهداف قصة المستخدم. ويحدث في النهاية بعض الرسميات عندما يقبل المطور قصة المستخدم وإجراء القبول كطلب عمل محدد.
تكوين قصص المستخدم عدل
عندما يحين وقت تكوين قصص المستخدم، يجتمع أحد المطورين مع ممثل العميل. ويكون العميل مسئولا عن صياغة قصص المستخدم. وربما يستخدم المطور سلسلة من الأسئلة للحصول على معلومات من العميل، مثل السؤال عن ما إذا كانت وظيفية معينة مرغوبة، لكن يجب الاحتراس من السيطرة على فكرة عملية التكوين.
وعندما يدرك العميل قصص المستخدم، فيجدها بطاقة ملاحظة مكتوبة (مثل 3×5 بوصة أو 8×14 سم) مع الاسم والوصف الذي صاغه العميل. فإذا وجد المطور أن قصة المستخدم ناقصة بطريقة ما (ضخمة للغاية أو معقدة أو غير دقيقة)، فتتم إعادة كتابتها حتى تكون مرضية. ويتم التأكيد في البرمجةالقصوى أن قصص المستخدم لا تكون محددة بعد أن تتم كتابتها. فالمتطلبات تميل إلي التغير أثناء فترة التطوير، والتي يتم التعامل معها على أنها ليست دائمة بل قابلة للتغيير.
وبوجه عام تتبع قصص المستخدم القالب الأتي:
" بما أني <دور>، أريد <هدف/رغبة> من أجل <منفعة>
إلا أنه في الغالب يتم استخدام الصيغة الأقصر أيضا:
" بما أني <دور>، أريد <هدف/رغبة>"
أمثلة عدل
كممثل للعميل، أريد البحث عن عملائي بأسمائهم الأولى والأخيرة.
كمستخدم غير إداري، أريد تعديل مواعيد أعمالي لكن ليس مواعيد أعمال مستخدمين آخرين.
كمختبر تطبيق جهاز محمول، أريد اختبار حالات الاختبار الخاصة بي وكتابة تقرير بالنتائج لإدارتي.
بداية التطبيق يبدأ التطبيق من خلال جلب المستند الأخير الذي كان يتعامل معه المستخدم.
بينما يغلق المستخدم التطبيق، أريد تنبيهي بالحفظ إذا غيرت شيءًا من بياناتي منذ آخر عملية حفظ.
غلق التطبيق عند غلق التطبيق، يُطلب من المستخدم الحفظ (إذا تم تغيير أي شيء في البيانات منذ آخر عملية حفظ!).
سوف يقوم الاستشاري بإدخال المصاريف على استمارة مصاريف. وسيقوم الاستشاري بإدخال بنود على الاستمارة مثل نوع المصاريف، والوصف، والمبلغ، وأي تعليقات بشأن المصاريف. (1) بعد إكمال هذا، سوف يقوم الاستشاري " بالتقديم". فإذا كانت المصاريف اقل من (<50)، فسوف تذهب المصاريف إلي النظام مباشرة من أجل العمليات. (2) في حالة ما إذا لم ينه الاستشاري من إدخال المصاريف، فربما يريد الاستشاري " الحفظ لاحقًا". وهذه الخطوة ينبغي أن يتم عرضها على قائمة (صف انتظار) للاستشاري مع حالة "عدم الاكتمال". (3) في حالة ما إذا قرر الاستشاري مسح البيانات وغلق الاستمارة، فسوف "يلغي ويخرج " الاستشاري. ولن يتم حفظ هذا الطلب في أي مكان.
الاستخدام عدل
كجزء محوري من العديد من وسائل تطوير أيجيل، مثل [لعبة تخطيط البرمجة القصوى]، فقصص المستخدم تحدد ما سيتم بناؤه في المشروع البرمجي. وقصص المستخدم لها أولوية من جانب العميل لأنها توضح الشيء الأكثر أهمية بالنسبة للنظام وسوف يتم تقسيمها في المهام وتقييمها عن طريق المطورين.
وعندما تكون قصص المستخدم على وشك التنفيذ ينبغي على المطورين أن تكون لديهم إمكانية التحدث مع العميل عنها. والقصص القصيرة ربما تكون صعبة التفسير، وربما تتطلب خلفية معرفية أو ربما تغيرت المتطلبات منذ أن تمت كتابة القصة.
ويجب إن يكون مع كل قصة مستخدم في مرحلة ما اختبارات قبول مرفقة، والتي تسمح للمطورين بإجراء الاختبار عند الانتهاء من قصة المستخدم والسماح أيضا للعميل بالتحقق منها. وبدوم صياغة دقيقة للمتطلبات، فربما تنشأ أراء مطولة وغير بناءة عندما يحين تسليم المنتج.
الفوائد عدل
تفضل [البرمجة القصوى XP] ووسائل أيجيل التواصل المباشر عند التوثيق الشامل والتكييف السريع مع التغيير بدلا من التركيز على المشكلة. وتحقق قصص المستخدم هذا من خلال:
- كونها قصيرة جدا. فهي تمثل أجزاء صغيرة من قيمة العمل الذي يمكن تحقيقه في فترة أيام إلي أسابيع.
- تتيح للمطور وممثل العميل مناقشة المتطلبات طوال مدة المشروع.
- تحتاج إلي صيانة بسيطة
- يتم التفكير فيها فقط عند وقت الاستخدام
- تحافظ على اتصال وثيق مع العميل
- تسمح بتقسيم المشروعات إلي أجزاء صغيرة.
- مناسبة للمشروعات التي فيها متطلبات متغيرة وسريعة الزوال أو مفهومة بشكل سيء. فتكرار الاكتشاف يدفع عملية الصقل.
- تجعل من السهل تقييم جهود التطوير
- تتطلب اتصالا وثيقا مع العميل طوال المشروع لكي يمكن تنفيذ الأجزاء الأكثر قيمة للبرنامج.
الحدود عدل
بعض الحدود في قصص المستخدم في وسائل أيجيل:
- قد يصعب قياسها بالنسبة للمشروعات الكبيرة.
- تعتبر مستهلات للمحادثات.
قصص المستخدم وحالات الاستخدام عدل
بينما قصص المستخدم، وحالات الاستخدام وسيناريو الاستخدام كلها تخدم هدف الحصول على متطلبات محددة للمستخدم خاصة بالتفاعلات بين المستخدم والنظام، إلا أن هناك اختلافات رئيسية بينها.
| قصص المستخدم | حالات الاستخدام |
|---|---|
|
|
انظر أيضا عدل
المراجع عدل
- Daniel H. Steinberg and Daniel W. Palmer: Extreme Software Engineering, Pearson Education, Inc., ISBN 0-13-047381-2
- Mike Cohn, "User Stories Applied", 2004, Addison Wesley, ISBN 0-321-20568-5
- Mike Cohn: Agile Estimating and Planning, 2006, Prentice Hall, ISBN 0-13-147941-5
- ^ Davies، Rachel. "Non-Functional Requirements: Do User Stories Really Help?". مؤرشف من الأصل في 2019-02-02. اطلع عليه بتاريخ 2011-05-12.
- ^ Advantages of User Stories for Requirements نسخة محفوظة 18 أبريل 2012 على موقع واي باك مشين.
