في هذا الدرس، ستتعلم عن جزء مهم من نهج أجايل في تطوير البرمجيات: قصص المستخدمين.

سأشرح لك ما هي قصص المستخدمين، والأخطاء الشائعة التي رأيتها عند إنشاء قصص المستخدمين، والأطر الموجودة للتحقق مما إذا كانت قصة المستخدم الخاصة بك “جيدة”.

إليك ما سنغطيه:

بدايات الأجايل

من المحتمل أنك سمعت عن تطوير الأجايل وقصص المستخدم. ولكن إذا لم تكن قد سمعت، دعنا نقدم درسًا تاريخيًا موجزًا:

قصص المستخدم هي جزء من مفهوم أوسع يسمى منهجيات الأجايل.

توجد منهجيات الأجايل منذ عام 2001 عندما اجتمع 17 مهندس برمجيات محترم في منتجع تزلج في يوتا وأنشأوا ما يعرف الآن بـ بيان الأجايل.

إذا كانت أسماء مثل روبرت مارتن، مارتن فاولر وكينت بيك لا تعني لك شيئًا، فعندما تنتهي من قراءة هذا المقال، اذهب وابحث عنهم. لديهم ثروة من المعرفة وقدموا للعالم البرمجي طريقة أكثر سلاسة في تسليم المشاريع، تُعرف بالأجايل.

ما هو الأجايل؟

الأجايل هو أكثر من طريقة تفكير من كونه طريقة موصوفة. هناك طرق موصوفة، مثل سكرم وكانبان، لكن الأجايل هو مفهوم.

يُعزز الأجايل التعاون، والتغذية الراجعة السريعة، وتقديم القيمة بشكل متكرر للمستخدم.

تشجع طريقة التفكير الأجايلية على المرونة في تخطيط المشاريع، وهو ما يتعارض تمامًا مع منافسه في ذلك الوقت، تخطيط المشاريع بطريقة الشلال، الذي كان صارمًا للغاية فيما يتعلق بما يتم تسليمه ومتى.

تعزز منهجيات أجايل القيام بـ “البحث الكافي” في البداية لبدء المشروع، ثم التعلم والتكرار وتغيير التصميم والنتائج حسب الحاجة طوال المشروع حتى يتم تسليم الكود النهائي. تُسمى هذه المقاربة “التخطيط التكيفي”.

تروج أجايل لتقديم شيء ذو قيمة بسرعة وبشكل متكرر، عادة في شكل تسليم الكود للإنتاج في نهاية كل “سباق” مدته أسبوعين. وهذا، مرة أخرى، مختلف تمامًا عن التخطيط التقليدي على غرار الشلال الذي غالبًا ما يتطلب شهورًا من التطوير قبل أن يمكن تسليم أي تغيير مرئي للمستخدم إلى الإنتاج.

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

الآن بعد أن تعرفت على كيفية عمل أجايل، دعنا نتعمق أكثر في كيفية التحقق من القيمة للمستخدم.

لنبدأ بقصة المستخدم.

ما هي قصة المستخدم؟

قصة المستخدم هي وسيلة بلغة بسيطة لربط المهندس بالهدف النهائي للبرنامج.

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

هيكل قصة المستخدم

كـ [نوع المستخدم]، عندما [أقوم بفعل ما]، [النتيجة المتوقعة]

هذا هو الأمر في أبسط صوره.

أنت تركز على المستخدم النهائي و”القيمة” التي ستقدمها.

دعنا نغوص في المدخلات:

  • نوع المستخدم: لا يوجد “مستخدم” يناسب الجميع. لديك “مستخدمين إداريين”، لديك “مستخدمين مسجلين دخول”، لديك “مستخدمين لديهم إذن X” أو “مستخدمين في الدور Y”. هذا يحدد بوضوح من يقوم بالعملية

  • أداء العملية: ماذا يفعل المستخدم؟ هل ينقر على زر “تسجيل الدخول”؟ هل يحذف سجلاً؟ هل يقدم نموذجًا؟

  • النتيجة المتوقعة: بمجرد أن يقوم المستخدم بتنفيذ العملية، ماذا يجب أن يحدث؟ إذا نقروا على “تسجيل الدخول” باستخدام عنوان البريد الإلكتروني وكلمة المرور الصحيحة، إلى أين يجب أن يتوجهوا؟ إذا نقروا على “تسجيل الدخول” باستخدام عنوان بريد إلكتروني وكلمة مرور غير صحيحة، ماذا يجب أن يحدث؟

مثال على قصص المستخدمين:

دعونا نلقي نظرة على أمثلة قصص المستخدمين لصفحة تسجيل الدخول.

لا يوجد شيء أفضل من الأمثلة.

لنحدد المشهد. لديك صفحة تسجيل دخول بها مربع نص لإدخال عنوان البريد الإلكتروني ومربع نص لإدخال كلمة المرور. لديك زر إرسال. هذا كل شيء.

ما هي التركيبات المختلفة التي يمكن أن تحدث على هذه الصفحة من منظور المستخدم؟

كمستخدم مسجل الدخول، عندما يتم تحميل الصفحة، يتم توجيهي إلى الصفحة الرئيسية للمستخدم المسجل الدخول.

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

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

أنا مستخدم لم أسجل الدخول بعد، وقد أدخلت تفاصيل غير صحيحة. يجب ألا أكون مسجلاً للدخول.

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

مرة أخرى. أنا لست مستخدمًا مسجلاً للدخول. لقد أدخلت تفاصيل غير صحيحة، يجب ألا أكون مسجلاً للدخول.

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

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

هل ترى كيف أن كل هذه تركز على المستخدم؟

قد تلاحظ أن بعض “السلوك المتوقع” في الأعلى غير محدد بالكامل. سنعالج ذلك لاحقًا في معايير القبول.

كيفية كتابة قصص مستخدم جيدة

هناك نموذج جيد يسمى نموذج INVEST يوضح ببساطة كيف تعرف إذا كانت قصص المستخدم الخاصة بك جيدة.

نموذج INVEST:

  • مستقلة: يمكن تطويرها بشكل منفصل.

  • قابلة للتفاوض: مفتوحة للنقاش والتغيير.

  • قيمة: تضيف قيمة للمستخدم.

  • قابلة للتقدير: يمكن تقدير الجهد المطلوب لها.

  • صغيرة: تتناسب مع فترة السبرينت.

  • قابلة للاختبار: تحتوي على معايير قبول واضحة.

دعونا نطبق هذا النموذج INVEST على أحد أمثلة قصص المستخدم من أعلاه:

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

(سأقوم بعمل بعض الافتراضات هنا، حيث أن هذا أساس رمز نظري ومشروع نظري)

هل هذه القصة مستقلة؟ أود أن أقول نعم. إنها قصة صغيرة تشمل فقط عددًا قليلاً من المكونات التي ربما توجد بالفعل. إذا لم يتم إنشاء قاعدة البيانات بعد للمشروع، فهذا سيعطينا اعتمادًا. لن تكون هذه مستقلة بعد الآن.

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

هذه القصة بالتأكيد قيمة. بمجرد تنفيذها، يمكن للمستخدم تسجيل الدخول. إذا كانت القصة كالتالي:

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

لن تكون هذه قيمة. لن يحصل المستخدم على أي شيء من هذا.

هل القصة قابلة للتقدير؟ مرة أخرى، علينا أن نفترض بعض الافتراضات في هذا السيناريو المختلق، لكني آمل بالتأكيد أن يكون من السهل تقدير ذلك. إنها قصة موجزة، تتضمن عددًا قليلاً من المكونات، في مجال يعرفه الجميع ولديه معايير قبول واضحة.

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

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

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

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

يبدو أننا أنشأنا قصة مستخدم جيدة!

إذا استخدمت الهيكل الذي حددته أعلاه، واستوفت القصة معايير نموذج INVEST، فمن المحتمل أن تكون قصة جيدة.

المزالق الشائعة في إنشاء قصة المستخدم

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

التركيز على الجوانب التقنية

كما تظهر أمثلتي أعلاه، فإن قصة المستخدم غير تقنية.

لا ينبغي أن يكون هناك أي إشارة إلى اسم خدمة، أو اسم قاعدة بيانات، أو تحقق بناءً على أي شيء لا يستطيع المستخدم رؤيته.

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

ركز على ما سيقوم به المستخدم، وما سيراه المستخدم.

دعونا ننظر إلى مثال لقصة تركز على الجانب التقني:

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

لا يمكن للمستخدم التحقق من هذه القصة وقد لا يفهم المستخدمون غير التقنيين ما تعنيه.

دعونا نصلحها:

بصفتي مستخدمًا غير مسجل الدخول، عندما أنقر على رابط “نسيت كلمة المرور” مع عنوان بريد إلكتروني صحيح، يتم إرسال بريد إلكتروني إلى عنوان البريد الإلكتروني المقدم مع رابط إعادة تعيين كلمة المرور المنسي.

يمكن للمستخدمين غير التقنيين فهم هذا ويضع التركيز على المستخدم، وليس المنتج.

تعاون أصحاب المصلحة

العمل الجماعي هو جوهر الأسلوب السريع.

تحتاج قصص المستخدمين إلى مساهمة من الإنتاج، ومحللي الأعمال، ومهندسي الجودة، والمهندسين، والأهم من ذلك، المستخدمين.

هكذا ستضمن تقديم ما يريده المستخدم. العمل الجماعي يسهل العمل.

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

كمستخدم مسجل الدخول، عندما يتم تحميل الصفحة، يتم توجيهي إلى صفحة البداية للمستخدم المسجل الدخول

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

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

وهذا رائع. لكن دعونا الآن نشمل مهندسي الجودة، الذين يأتون بتجربة مختلفة حيث لديهم تجارب مختلفة مع البرمجيات:

كمستخدم غير مسجل الدخول، عند إدخال عنوان بريد إلكتروني صحيح بالعبرية وكلمة مرور صحيحة، يتم توجيهي إلى الصفحة الرئيسية

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

رائع. نحن نحصل الآن على مجموعة أكثر اكتمالًا من قصص المستخدمين التي تغطي المزيد من الحالات. لكن ماذا يحدث إذا شملنا الإنتاج؟

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

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

قصص مستخدم غامضة

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

إذا كتبت قصة مستخدم يمكن تفسيرها بـ 10 طرق مختلفة من قبل 10 أشخاص مختلفين، فقد تم الخطأ قليلاً.

لقد ذكرت أعلاه أنني سأتطرق إلى معايير القبول، والآن حان الوقت للقيام بذلك.

دعونا نعيد النظر في القصة التالية للمستخدم:

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

هناك غموض في هذا.

ما هي الرسالة التي يجب أن تظهر؟ عند إعادة تحميل الصفحة بعد محاولة تسجيل دخول غير صحيحة، هل يجب أن يتم ضبط مربع النص لاسم المستخدم إلى فارغ، أم معبأ بالقيمة التي تم إدخالها مسبقًا؟ ماذا يعني “عنوان بريد إلكتروني غير صحيح”؟ هل يعني عنوان بريد إلكتروني لم يُر من قبل، أو عنوان بريد إلكتروني غير صالح في الوقت الحالي (لم يتم دفع الاشتراك، تم إلغاء الاشتراك إلخ)

لذلك كما ترى، التفاصيل تهم.

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

لنصلح المشكلة:

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

تم إزالة الأسئلة حول إجراء المستخدم ولكن لم يتم حل المشكلة المتعلقة برسالة الخطأ المتوقعة.

أدخل معايير القبول.

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

أمور مثل:

  • رسالة الخطأ: “عنوان بريد إلكتروني غير صالح أو كلمة مرور غير صالحة”

  • صندوق نص عنوان البريد الإلكتروني وكلمة المرور يُعاد تعيينهما إلى فارغ عند إعادة التحميل

  • المستخدم غير قادر على الوصول إلى الصفحات التي تتطلب تسجيل الدخول

  • يتم تقديم خيار “نسيت كلمة المرور” للمستخدم

تحدد معايير القبول ما هو متوقع من التنفيذ.

كيفية البدء مع قصص المستخدم

ابدأ بشيء صغير.

لن تكون مثالية في تحسين وإنشاء قصص المستخدم في البداية.

إن إنشاء قصص المستخدم فن وعلم في نفس الوقت. العمل المتكرر يجعل الأمور أفضل.

يجب أن يتم إنشاء قصص المستخدم كمجموعة. في كثير من الأحيان، يتم ذلك باستخدام نهج “3 أصدقاء”، حيث يجتمع مهندس وشخص منتج ومسؤول ضمان الجودة معًا ويقومون بتفكير مشترك في مختلف الاحتمالات التي يجب دعمها.

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

الخاتمة

الأسلوب المرن يعتمد على التعاون. سكراوم يعتمد على التعاون. إنشاء قصص المستخدمين هو عمل تعاوني. تذكر ذلك.

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

المستخدم هو محور التركيز. إذا كنت تتضمن مصطلحات لا يفهمها المستخدم، فكر مجددًا في قصة المستخدم.

لن تكون مثاليًا في هذا من البداية، لكن كلما فعلت المزيد، أصبحت أسرع وأكثر فاعلية. خذ ذلك من شخص يمارس هذا العمل منذ أكثر من 10 سنوات. الفرق في السرعة والجودة في إنشاء قصص المستخدم اليوم مقارنةً قبل 10 سنوات هو فرق شاسع.

تحقق من منشورات مدونتي على موقعي، Just Another Tech Lead، أو اشترك في نشرتي الإخبارية الأسبوعية عبر البريد الإلكتروني هنا.