قصص المستخدم (User stories)
صف ما سيُبنى في صورة حاجات صغيرة قابلة للاختبار مكتوبة من جهة المستخدم، ليبني الفريق الشيء الصحيح ويعرف متى ينتهي منه.
- الوقت
- 45 دقيقة
- الأشخاص
- 3–6
- نوع العمل
- التخطيط
باختصار
قصة المستخدم عبارة قصيرة تصف شيئاً واحداً يحتاجه المستخدم من الخدمة، بصيغة «بصفتي [المستخدم]، أحتاج إلى [شيء]، لكي [السبب]»، ومعها معايير قبول تحدد متى تكتمل. لكتابتها ابدأ من البحث، واجمع القصص المترابطة في ملحمات، وقسّم القصص الكبيرة، واتفق على المعايير مع من سيبنونها ويختبرونها.
ما هو
قصة المستخدم تصف جزءاً من العمل من وجهة نظر الشخص الذي سيستخدمه، لا بوصفه مهمة تقنية. ولها ثلاثة أجزاء: من المستخدم، وما الذي يحتاجه، ولماذا يحتاجه. والجزء الأخير «لكي» هو الأهم، لأنه يخبر الفريق بالمشكلة التي يحلها العمل، ويتيح له أن يقترح طريقة أفضل لحلها. وتصحب كل قصة معايير قبول، وهي قائمة قصيرة من الشروط التي يجب أن تتحقق لتُعدّ القصة مكتملة.
نشأت قصص المستخدم في ممارسات تطوير البرمجيات الرشيقة، واستُخدمت أول مرة في منهجية البرمجة القصوى (Extreme Programming) أواخر تسعينيات القرن العشرين. وهي اليوم معيار في فرق الخدمات الرقمية، ومنها الفرق الحكومية. ويستخدم دليل خدمات GOV.UK عبارة «أحتاج إلى» بدلاً من «أريد» ليبقى التركيز على الحاجات الحقيقية. وتسمى القصص الكبيرة التي تغطي هدفاً كاملاً «ملحمات» (Epics)، وتُقسَّم إلى قصص أصغر يمكن بناؤها واختبارها في وقت قصير. وفي ورقة العمل تدوّن: المستخدم، والحاجة، والسبب، ومعايير القبول، والملحمة التي تنتمي إليها القصة، والدليل الذي تستند إليه.
متى تستخدمه
استخدمه حين
- أنهيت البحث والتصميم وتحتاج إلى تحويلهما إلى قائمة أعمال يستطيع فريق التنفيذ بناءها.
- وثيقة المتطلبات طويلة وتقنية، ولا يستطيع أحد أن يحدد أي أجزائها أهم للمستخدمين.
- تخطط للإصدار الأول من خدمة جديدة وتحتاج إلى الاتفاق على ما يدخل فيه وما يمكن تأجيله.
- تصف فرق الأعمال والسياسات والتقنية الخدمة نفسها بكلمات مختلفة، ويتكرر سوء الفهم بينها.
- تحتاج إلى شروط واضحة للاختبار، ليتفق الجميع على متى تكتمل الميزة.
تجنّبه حين
- لا تعرف بعد من مستخدموك أو ما الذي يحتاجونه؛ ابدأ بالبحث وإلا وصفت القصص تخمينات.
- العمل تقني بحت لا يغيّر شيئاً يراه المستخدم، كترقية قاعدة بيانات؛ وصف المهمة المباشر أوضح.
- ما زلت تستكشف أفكاراً متباعدة جداً؛ فالقصص تثبّت التفاصيل مبكراً، فابدأ بلوحة القصة المصورة أو النموذج الأولي.
ما تحتاج إليه
- الوقت
- قرابة 45 دقيقة لصياغة قصص ملحمة واحدة ومراجعتها، وأكثر لخدمة كاملة.
- الأشخاص
- من 3 إلى 6 أشخاص: مالك المنتج أو الخدمة، وشخص من فريق البحث، وشخص على الأقل ممن سيبنون وآخر ممن سيختبرون.
- الأدوات
- نتائج البحث أو خريطة الرحلة، وبطاقات أو لوحة مشتركة، وقالب بسيط بخانات ورقة العمل الست.
كيف تديره
الخطوة 1: ابدأ من هدف المستخدم
اكتبوا في أعلى اللوحة الهدف العام لمجموعة واحدة من المستخدمين، مثل «مشترك يتقدم بطلب معاش تقاعدي». هذا هو الملحمة. وثبّتوا بجانبه ما يتصل به من البحث، كالاقتباسات أو خريطة الرحلة أو عبارة وجهة النظر، لتبقى القصص مرتبطة بالأدلة.
الخطوة 2: سمِّ المستخدمين بدقة
دوّنوا أنواع المستخدمين المعنيين بالهدف بلغة بسيطة: «مشترك يتقاعد هذا العام»، «جهة عمل المشترك»، «موظف المعاشات». وتجنبوا «بصفتي مستخدماً» و«بصفتي النظام»، فهما تخفيان صاحب الحاجة. والموظفون مستخدمون أيضاً ولهم قصصهم.
الخطوة 3: اكتبوا مسودات القصص
ليكتب كل مشارك قصصاً على بطاقات منفصلة بصيغة «بصفتي…، أحتاج إلى…، لكي…». اكتبوا الحاجة بلغة المستخدم لا على هيئة شاشة أو زر: «أحتاج إلى معرفة المستندات المطلوبة» لا «أحتاج إلى صفحة لرفع المستندات». واجعلوا لكل بطاقة حاجة واحدة.
الخطوة 4: افحص جزء «لكي»
اقرؤوا كل بطاقة بصوت مسموع واسألوا: هل السبب حقيقي ومحدد؟ فعبارة «لكي أتقدم بالطلب» لا تضيف شيئاً، أما «لكي لا تتأخر أول دفعة من معاشي» فتخبر الفريق كيف يبدو النجاح. وإن لم يستطع أحد أن يقول لماذا يحتاجها المستخدم فاستبعدوا البطاقة أو علّموها افتراضاً يحتاج إلى تحقق.
الخطوة 5: قسّم القصص الكبيرة
إذا كانت القصة ستأخذ من الفريق أكثر من بضعة أيام لبنائها واختبارها فقسّموها. ومن طرق التقسيم الجيدة: حسب نوع المستخدم، أو حسب الخطوة في الرحلة، أو الحالات البسيطة قبل المعقدة، أو المسار الرئيسي أولاً والاستثناءات لاحقاً. وأبقوا القصص المقسمة تحت الملحمة نفسها.
الخطوة 6: اكتب معايير القبول
اتفقوا لكل قصة على ثلاثة إلى ستة شروط يجب أن تتحقق عند اكتمالها، مكتوبة بحيث يستطيع المختبر التحقق منها. ومن الصيغ المفيدة: «إذا كان [الموقف]، وعندما [الفعل]، فإن [النتيجة]». واشملوا المسارات غير السعيدة، كمستند ناقص أو رقم خاطئ، لا المسار الرئيسي وحده.
الخطوة 7: رتّب ودوّن
رتّبوا القصص تحت الملحمة بالترتيب الذي يمر به المستخدمون، ثم علّموا ما يلزم منها للإصدار الأول. وسجّلوا كل قصة مع دليلها ومعاييرها في قائمة أعمال الفريق، واتفقوا على من سيراجع القصص مع فريق البحث قبل بدء البناء.
مثال تطبيقي
كان صندوق تقاعد حكومي يستقبل نحو 3,400 طلب تقاعد شهرياً، كلها تقريباً ورقية. وكانت معالجة الطلب تستغرق 47 يوماً في المتوسط، ويُعاد 38% من الطلبات إلى المشترك مرة على الأقل لنقص المعلومات أو خطئها. وخطط الصندوق لخدمة إلكترونية، وكانت لديه وثيقة متطلبات من 400 صفحة وجدها فريق التنفيذ صعبة الاستخدام.
اجتمع خمسة أشخاص لخمس وأربعين دقيقة: مالكة الخدمة، وباحث تجربة المستخدم، وموظف معاشات، ومطوّرة، ومختبر. وأخذوا ملحمة «مشترك يتقدم بطلب معاش تقاعدي» ووضعوا بجانبها اقتباسات المقابلات وخريطة الرحلة.
حددوا أربعة مستخدمين: مشتركاً يتقاعد هذا العام، وجهة عمل المشترك، وموظف المعاشات، وقريباً مفوَّضاً عن المشترك. وأنتجت المسودة الأولى 26 بطاقة.
أدى فحص «لكي» إلى استبعاد أربع بطاقات لم تكن إلا إعادة للخطوة. وحوّل كذلك «بصفتي مشتركاً، أحتاج إلى رفع شهادة الخدمة» إلى «بصفتي مشتركاً يتقاعد هذا العام، أحتاج إلى أن أعرف أن جهة عملي أكدت تواريخ خدمتي، لكي لا أضطر إلى جمع الشهادة بنفسي».
كانت قصة حساب المعاش كبيرة جداً، فقسّمها الفريق إلى ثلاث: مشتركون لهم جهة عمل واحدة، ومشتركون عملوا لدى عدة جهات، ومشتركون في اشتراكاتهم انقطاعات. ولم يعلّموا للإصدار الأول إلا الأولى.
شملت معايير قبول قصة تواريخ الخدمة: «إذا كانت جهة العمل قد أكدت التواريخ، وعندما يسجل المشترك دخوله، فإن التواريخ تظهر له ويستطيع قبولها»، و«إذا كانت التواريخ غير موجودة، وعندما يسجل المشترك دخوله، فإنه يرى الجهة التي يتواصل معها ويُحال الطلب إلى موظف».
ضمت قائمة الأعمال النهائية للملحمة 18 قصة، منها 11 للإصدار الأول. وحجز الفريق جلسة مراجعة مع الباحث قبل أول دورة عمل.
للتوضيحنصائح وأخطاء شائعة
نصائح
- اكتب الحاجة شيئاً يريد المستخدم تحقيقه لا ميزة تقنية؛ فهذا يترك للفريق مجالاً لإيجاد حل أبسط.
- أبقِ القصص صغيرة بما يكفي لبنائها واختبارها في دورة عمل واحدة أو أسبوع؛ فالقصص الكبيرة تخفي المخاطر.
- اكتب قصصاً للموظفين أيضاً؛ فلمن يعالجون الطلبات حاجات تشكّل الخدمة كلها.
- اربط كل قصة بالدليل الذي تستند إليه، ليستطيع أي شخص أن يعرف من أين جاءت الحاجة.
أخطاء شائعة
- كتابة «بصفتي مستخدماً» في كل شيء، فتختفي الحاجات المختلفة لأشخاص مختلفين.
- تحويل مهمة تقنية إلى قصة بإضافة «بصفتي النظام»، فيضيع الغرض من الصيغة.
- إهمال معايير القبول، فيقرر الفريق والمختبرون كلٌّ على حدة معنى الاكتمال.
- كتابة قائمة الأعمال كاملة على مكتب منفرد وتسليمها، بدلاً من صياغتها ومراجعتها مع الفريق.
ما تخرج به
تخرجون بملحمة مقسمة إلى قصص مستخدم صغيرة، تسمّي كل منها المستخدم والحاجة والسبب، ومعها معايير قبول ورابط للدليل وعلامة للإصدار الأول. وتدخل القصص مباشرة في قائمة أعمال فريق التنفيذ. وتساعد خارطة الطريق على ترتيب الملحمات عبر الزمن، ويمكن للوحة القصة المصورة أن تُظهر كيف تجتمع القصص في تجربة واحدة.
أسئلة شائعة
لماذا يستخدم GOV.UK عبارة «أحتاج إلى» بدلاً من «أريد» في قصص المستخدم؟
عبارة «أحتاج إلى» تُبقي التركيز على ما يجب أن يستطيع المستخدم فعله لبلوغ النتيجة، لا على التفضيلات، وتدفع الفرق إلى طلب الدليل على أن الحاجة حقيقية. وكثير من الفرق خارج القطاع الحكومي تستخدم «أريد»، وبنية القصة واحدة في الحالتين.
ما الفرق بين الملحمة وقصة المستخدم؟
الملحمة هدف كبير للمستخدم، كالتقدم بطلب معاش، أكبر من أن يُبنى دفعة واحدة. أما قصة المستخدم فجزء صغير من ذلك الهدف يستطيع الفريق بناءه واختباره في أيام قليلة. وتضم الملحمة عادة عدة قصص، وأحياناً عشرات.
كم معيار قبول ينبغي أن تحمل قصة المستخدم؟
من ثلاثة إلى ستة عادة. فإن قلّت فقد تكون القصة مبهمة أو أُهملت المسارات غير السعيدة، وإن زادت كثيراً فالقصة غالباً كبيرة وينبغي تقسيمها.
بطاقة الأداة
ورقة العمل التي يملؤها فريقك، خانة لكل حقل.
- المستخدم
- الحاجة
- لكي
- معايير القبول
- الملحمة
- الدليل