قوالب قصة المستخدم + أمثلة لتحسين العملية الخاصة بك
بالنسبة لمطوري البرامج، من السهل التركيز على ما تقوم بإنشائه ونسيان من تقوم بتصميم البرامج من أجله.
بينما تؤكد منهجية Agile على أهمية متطلبات الميزات، يجب أن يكون المستخدم النهائي في مقدمة اهتماماته طوال عملية تطوير البرامج بأكملها. لحسن الحظ، يمكنك صياغة هذه المتطلبات في وصف قصير وبسيط.
نحن نسمي هذه القوالب قصة المستخدم.
يساعد إنشاء قصص المستخدم المطورين على فهم المشكلات التي يحلونها للمستخدمين وكيفية تسهيل مهامهم. باستخدام لغة بسيطة وغير تقنية، يمكنك تحديد القيمة الكامنة وراء أي برنامج.
لن يساعد هذا الفرق على فهم ما يقومون به فحسب، بل سيساعد أيضًا على فهم سبب أهميته.
أدناه، سنقوم بتفصيل عناصر قصة المستخدم الجيدة ونوفر لك نماذج مجانية لتحسين عملية قصة المستخدم الخاصة بك.
ما هي قصة المستخدم؟
تصف قصة المستخدم ميزات المنتج من وجهة نظر المستخدم النهائي. يقوم مديرو المنتجات ومصممو المنتجات بكتابة هذه القصص الموجزة لتوضيح سبب احتياج المستخدمين أو رغبتهم في وظائف معينة.
ضمن نطاق ممارسات فريق Agile ، تعد قصص المستخدمين أصغر وحدة عمل، لذا فهي مخصصة لتكون محددة.
هناك ثلاثة عناصر تدخل في إنشاء قصص المستخدم، والمعروفة باسم العناصر الثلاثة:
- البطاقة: هذا هو المكان الفعلي الذي تكتب فيه قصة المستخدم. يساعد وضع القصة على بطاقة فعلية على ترسيخ المعايير ومشكلة المستخدم التي تحلها لأعضاء الفريق.
- المحادثة: قصص المستخدمين تلهم مناقشات الفريق حول كيفية تلبية متطلبات المستخدم. يمكن لفريقك ابتكار حلول جديدة من خلال طرح الأسئلة والتوصل إلى تفاهم مشترك.
- التأكيد: يحتاج مديرو المنتجات والمصممون إلى وضع معايير القبول التي تلبي متطلبات المستخدم. بمجرد أن يرغب فريقك في المضي قدمًا في الحل، يمضي المطورون قدمًا في هذا التأكيد.
ملحوظة: تضيف بعض الفرق حرف “C” رابعًا لـ “السياق” في القصص الأكثر تعقيدًا.
تنسيق قصة المستخدم
تتكون قصص المستخدم من جملة أو جملتين. في هذا المجال، يصفون المستخدمين النهائيين الذين يكتسبون قيمة من خلال منتجك. يقرأ تنسيق قصة المستخدم: “باعتباري [مستخدمًا] أريد [الهدف] حتى [أستفيد].”
دعنا نستكشف هذا التنسيق بمزيد من التفاصيل:
- باعتبارك [مستخدمًا]: اشرح لمن تقوم بتصميم هذا المنتج من أجله. تجاوز المسميات الوظيفية والكليشيهات، واستحوذ على الإحساس الداخلي للمستخدم بالقيمة. إذا كانت مؤسستك تستخدم شخصيات المشتري، فيمكنك تطبيق شخصية محددة هنا.
- أريد [الهدف]: وصف نوايا المستخدم بدلاً من كيفية وصوله إلى هناك. الهدف أهم من التنفيذ.
- بحيث [الفائدة]: قسّم كيف يفيد تحقيق الهدف المستخدم. تذكر أن تنظر إلى الصورة الأكبر أو الرغبة الأعمق لدى المستخدمين.
ضع في اعتبارك أنه يمكن للفرق استخدام تنسيقات قصص المستخدم الأخرى. تشمل بعض الخيارات الشائعة ما يلي:
- من أجل [تلقي المنفعة] كـ [دور]، أستطيع [الهدف/الرغبة].
- بوصفي [من] [متى] [أين]، أنا [أريد] بسبب [لماذا].
أنواع قصص المستخدم
اعتمادًا على مدى تعقيد قصص المستخدم الخاصة بك، قد تتناسب مع فئات مختلفة. في بعض الأحيان، يمكنك أيضًا دمج قصص المستخدمين في قصة أكبر. فيما يلي الأنواع الأربعة الرئيسية لقصص المستخدم:
- بسيطة: هذه قصص مستخدمين فردية أو مستقلة تركز على مستخدم معين أو نوع معين من المنتج.
- ملحمة: مجموعات من قصص المستخدمين ذات الصلة تجتمع معًا لتشكل ملاحم. وقد تتضمن عدة مستخدمين يعملون معًا أو بشكل مستقل أو احتياجات متعددة لنوع واحد من المستخدمين لتحقيق هدف أو فائدة معينة.
- الموضوع: هذه هي الاستثمارات والاستراتيجيات الرئيسية التي تجمع الملاحم معًا. تسلط قصص المستخدم المواضيعية الضوء على كيفية تحقيق الشركة لأهداف أوسع.
- Scaled Agile Framework (SAFe): تضيف قصص المستخدمين هذه تفاصيل إضافية مثل فرضية الفائدة أو تكلفة التأخير أو المتطلبات غير الوظيفية.
لماذا تعتبر قصص المستخدم مهمة؟
تساعد قصص المستخدم المطورين على التركيز على المستخدم النهائي. بدلاً من التفكير في منتجهم من فراغ، تلتقط قصص المستخدمين الوظائف من منظور خارجي.
لذلك بدلاً من التفكير فيما تفعله الأداة، يفكر المطورون في كيفية مساعدة المستخدمين.
تلعب قصص المستخدم أيضًا دورًا رئيسيًا في تطوير Agile من خلال:
- توفير الشعور بالهيكل
- تسليط الضوء على احتياجات المستخدم وأولوياته للمطورين
- الإشارة إلى القيمة الفعلية الموجودة في المنتج
- استكشاف “من” و”ماذا” و”لماذا” في عملية التطوير لإعطاء المطورين سياقًا أساسيًا
قصص المستخدم مقابل متطلبات المنتج
من مسافة بعيدة، يمكن أن تبدو قصص المستخدم مثل متطلبات المنتج. في حين أن كلا الوصفين يساعدان في شرح المنتج، إلا أنهما يتعاملان معه بشكل مختلف:
- تركز قصص المستخدمين على كيفية تلبية منتجك لنوايا المستخدمين وقيمهم الأساسية.
- تحدد متطلبات المنتج الوظائف التي يؤديها المنتج في حد ذاته. تحدد بعض الفرق متطلبات المنتج ضمن معايير القبول الخاصة بها. ونتيجة لذلك، يستخدم بعض المطورين المصطلحات بالتبادل.
تكتب الفرق عمومًا قصص المستخدمين في وقت مبكر من التطوير. وبهذه الطريقة، يمكنهم تحديد كيفية تلبية أدواتهم لاحتياجاتهم الأساسية والعمل بشكل عكسي.
على النقيض من ذلك، تكتب الفرق متطلبات المنتج لاحقًا في الإنتاج. تركز هذه المتطلبات بشكل أقل على المستخدم وأكثر على كيفية عمل المنتج بشكل منفصل.
نهج الاستثمار في قصص المستخدم في Agile
ابتكر بيل ويك منهج INVEST لوصف الصفات التي تشكل قصة مستخدم جيدة. وعلى وجه التحديد، قام بصياغة معاييره لمساعدة فرق تطوير Agile. فيما يلي الصفات التي تشكل قصة مستخدم جيدة:
- مستقلة: يجب أن تقف قصة كل مستخدم بمفردها. لا ينبغي أن يعتمد سير عملك على التنقل عبر قصص المستخدمين بترتيب معين.
- قابل للتفاوض: يجب أن تتعاون الفرق لتحديد أولويات العملاء. تعتمد قصة المستخدم النهائية الخاصة بك على مناقشات ومراجعات متعمقة.
- قيمة: تشير قصص المستخدمين إلى المكان الذي يمكنك إضافة قيمة فيه إلى منتجك. إذا كانت قصة المستخدم الخاصة بك لا تضيف قيمة كافية، فهذه إشارة إلى أنه يجب عليك العودة إلى لوحة الرسم. كما أن القصص ذات القيمة الأعلى لها الأسبقية على القصص ذات القيمة المنخفضة.
- قابلة للتقدير: يجب عليك تقدير الحجم والإطار الزمني لكل قصة مستخدم. وهذا يساعد على إعطاء الأولوية لقصة على أخرى. إذا لم تتمكن من تقييم ما إذا كانت القصة تتطلب جهدًا عاليًا أم منخفضًا، فأعد تقييم كيفية تقسيم قصص مستخدم Agile .
- صغيرة: قصص المستخدم تلتقط جوهر احتياجات المستخدم. بدلاً من حصر الحقائق الفنية ونقاط الضعف، تعامل معها كهدف للتعاون من أجل تقييم التفاصيل الدقيقة ولكن ذات مغزى.
- قابلة للاختبار: تريد متطلبات قابلة للاختبار لقصص المستخدم. إذا كانت قصتك لا تتضمن معايير قبول قابلة للاختبار، فلن تساعدك.
كيفية كتابة قصص المستخدم
على الرغم من فائدتها، يحتاج بعض المطورين إلى المساعدة في العثور على موطئ قدم لهم من خلال قصص المستخدمين. ولحسن الحظ، يمكنك كتابة واحدة في أربع خطوات فقط:
1. تحديد المستخدم النهائي
قبل أي شيء آخر، اسأل من هو منتجك؟ بعد ذلك، يمكنك تحديد المستخدم النهائي المثالي الخاص بك عن طريق كتابة شخصية المستخدم.
قد لا تمثل هذه الشخصيات جميع المستخدمين لديك، ولكن يجب أن تحتوي على صفات موجودة في معظم المستخدمين. لتحديد المستخدم النهائي، اسأل:
- ما هي المواقف والسلوكيات التي سيكون لدى المستخدم النهائي؟
- ما هي وظيفة أو مجال المستخدم النهائي الخاص بك؟
- ما هي مسؤولياتهم الأساسية في عملهم؟
- هل لديهم سمات تؤثر على كيفية استخدامهم للمنتج؟
- ما هي قرارات المستخدم التي سيؤثر عليها منتجك؟
2. اشرح ما يريده المستخدم النهائي
بمجرد أن تعرف من هو المستخدم، عليك أن تعرف ما يريده أو يتوقعه أو يحتاجه. علاوة على ذلك، فكر في كيفية مساعدة منتجك لهم على تحقيق أهدافهم. لتحليل ما يريده المستخدمون، حاول:
- مراجعة آراء العملاء حول منتجاتك والمنتجات المماثلة
- إجراء أبحاث السوق في مجال عملك
- التحدث إلى عملائك أو الأشخاص الذين يتوافقون مع المستخدم النهائي الخاص بك
- تحديد المشاكل التي يمكن لمنتجك إصلاحها
- سؤال أعضاء الفريق عن كيفية استخدام منتجك
3. قم بصياغة قصة المستخدم
الآن بعد أن فهمت مستخدمك وما يريده، يمكنك كتابة الجزء الثالث من قصة المستخدم.
على وجه التحديد، خذ ما تعرفه عن المستخدم ووصف كيف يساعد حل احتياجات هذا المستخدم في منتجك العملاء على تحقيق أهدافهم. أنت تريد أيضًا التركيز على كيفية إنشاء هذه العملية لقيمة لمستخدميك وسبب أهمية هذه الفائدة لهم.
عند كتابة قصة مستخدم، تأكد مما يلي:
- إعطاء الأولوية لاحتياجات المستخدم التي من شأنها أن توفر أكبر قيمة.
- استخدم قالب قصة المستخدم المناسب.
- ركز على ما يفعله منتجك للمستخدمين وليس على كيفية تحقيق ذلك. إن التركيز بشكل أقل على كيفية عمله سيمنح المطورين لديك الحرية في العثور على أفضل الحلول.
- اجعل القصة محددة ولكن موجزة.
4. تضمين معايير القبول
ضمن منهجية Agile، تشير معايير القبول إلى الشروط التي تحل قصة المستخدم. يشير بعض المطورين إلى هذه الشروط على أنها متطلبات المنتج أو “تعريف ما تم إنجازه”.
على سبيل المثال، إذا كان منتجك يلبي جميع الوظائف التي يحتاجها المستخدم لتحقيق أهدافه، فهو يفي بالمعايير. قد تتضمن قصتك أيضًا أكثر من معيار قبول واحد.
عادة ما تتم كتابة معايير القبول بهذا التنسيق:
- بالنظر إلى أنه [كيف يبدأ السيناريو]، عندما [يتخذ المستخدم إجراءً]، فإن [تأثير الإجراء الخاص به].
تأكد من معايير القبول الخاصة بك:
- تلبية المتطلبات قبل شحن المنتج الخاص بك
- قابلة للقياس والاختبار
- تتناسب مع احتياجات المستخدم الأعمق بدلاً من سلسلة من المربعات التي يجب التحقق منها
- تتناسب مع وجهة نظر المستخدم، وليس وجهة نظرك
العوائق عند إنشاء قصص المستخدم
بفضل بساطتها وفائدتها، لا توجد أي جوانب سلبية حقيقية لإنشاء قصص المستخدم. ومع ذلك، فإن بعض المطورين يقعون في مخاطر من خلال التركيز على التفاصيل الخاطئة. فيما يلي بعض العوائق المحتملة التي يجب وضعها في الاعتبار:
- إنشاء قائمة مرجعية: قصص المستخدم ليست قائمة مهام. تعامل مع قصتك وكأنها قصة قصيرة وليست سلسلة من التعليمات.
- تجاهل التفاصيل الصغيرة: أهداف المستخدمين والفوائد المرجوة تكمن في التفاصيل. لا تتعامل مع قصة المستخدم وكأنها نظرة عامة واسعة النطاق، بل استخدمها للانطلاق إلى منظوره التفصيلي.
- التخلي عن القصة: في كثير من الأحيان، يكتب المطورون قصة مستخدم رائعة يتم تهميشها. طوال فترة التطوير، ضع قصة المستخدم في الاعتبار. يساعد التركيز على إحساس المستخدم بالقيمة على التركيز على أفضل ميزات المنتج وإضافاته.
أمثلة على قصة المستخدم مع معايير القبول
ولمساعدتك على كتابة قصص مستخدم أفضل، سنقدم بعض الأمثلة. في كل حالة، سنشرح بنية القصة، ومعايير القبول، وبعض الوجبات السريعة.
بصفتي [معلمًا] أريد [تسجيل جميع درجات الاختبارات وترتيبها] حتى [أتعرف على من يحتاج إلى أكبر قدر من المساعدة]
السيناريو: يشرح هذا السيناريو الأساسي من هو المستخدم وماذا يريد ولماذا. في هذه الحالة، يريد المعلم تنظيم درجات الاختبار أثناء تسجيلها.
معايير القبول: نظرًا لأن المعلم يريد ترتيب الدرجات، عندما يقوم البرنامج تلقائيًا بتصنيف جميع الدرجات، فيمكن للمعلم تحديد الطلاب الحاصلين على أقل الدرجات.
الوجبات السريعة: الأهداف والفوائد لا توجد بمعزل عن غيرها. كلاهما مرتبطان بالمستخدم ولديهما علاقة تعاونية تقريبًا. فالهدف يحقق المنفعة وليس العكس.
من أجل [تلقي الإشادة] كـ [مؤلف]، يمكنني [الترويج لكتابي الجديد عبر الإنترنت]
السيناريو: تتصدر هذه القصة رغبات المستخدم الأعمق قبل الأهداف الملموسة التي ستوصله إلى هناك.
معايير القبول: نظرًا لأن المؤلف يريد الإشادة، فعندما يروج لكتابه بنجاح، يمكنه تعزيز شعبيته.
الوجبات السريعة: تسلط قصة المستخدم هذه الضوء على كيف تأتي فوائد المستخدم وأهدافه قبل الوظيفة. لا تفقد نفسك في آليات كيفية نشر البرنامج للكلمة عبر الإنترنت. بدلًا من ذلك، فكر في الأمر في سياق الهدف النهائي.
باعتباري [مندوب مبيعات] [في سوق ضعيف الأداء] [في مدينة باهظة الثمن]، أريد [المزيد من العملاء المحتملين ذوي الجودة العالية] لأنني [أريد تحقيق أهداف معدل التحويل]
السيناريو: يستخدم هذا السيناريو صيغة الأسئلة الخمسة “W”: من وماذا ومتى وأين ولماذا.
معايير القبول: نظرًا لأن مندوب المبيعات يعمل في سوق صعب، فعندما يجد عملاء محتملين أفضل، تكون لديه فرصة أفضل لتحقيق المبيعات.
الوجبات السريعة: في بعض الأحيان لا تكون معرفة المستخدم الخاص بك كافية. إن الكتابة عن مندوب مبيعات شيء واحد؛ إنه أمر آخر أن تكتب عن واحد في مجال صعب.
يساعد السياق الإضافي في شرح كيف يمكن لأدوات التطوير مساعدة المستخدمين النهائيين في تحقيق أهدافهم.
4 قوالب قصة المستخدم
لمساعدتك في كتابة قصص المستخدم الخاصة بك، سنستكشف القوالب المختلفة وما تقدمه.
قالب قصة مستخدم بسيط
تركز قصص المستخدم البسيطة على سيناريو واحد في كل مرة. ويتيح لك ذلك التركيز على مشكلات مستخدم واحد وتحديد معايير قبول واضحة. تضيف بعض الفرق أولوية وتقديرًا للقصة:
- الأولوية: تشير إلى القيمة المرتبطة بقصص المستخدمين. عادةً ما تتعامل فرق Agile مع القصص ذات الأولوية الأكبر أولاً.
- التقدير: يشير هذا إلى الجهد الإجمالي اللازم لإكمال الوظيفة أو المنتج.
قالب قصة المستخدم الملحمي
الملاحم عبارة عن مجموعات من قصص المستخدمين ذات الصلة والتي ترتبط بروايات أكبر. على سبيل المثال، قد تتبع البرامج الملحمية موظفين مختلفين في نفس الشركة أو مستخدمين يطبقون برنامجًا لاستخدامات مختلفة.
تساعد الملاحم في تتبع فئات المستخدمين بدلاً من الأفراد.
قالب قصة المستخدم المواضيعية
تتجاوز قصص المستخدم المواضيعية الملاحم لتتبع مبادرات الأعمال الأكبر حجمًا. تضع القوالب الموضوعية إستراتيجيات مؤسستك في المقدمة.
ولتحقيق هذه الغاية، على عكس الملاحم، يأخذون في الاعتبار عوامل مثل الأولوية والتقدير والإصدار. هنا، يشير الإصدار إلى الوظائف التي تريد تقديمها للمستخدمين في وقت واحد.
قالب قصة المستخدم الآمن
يرغب بعض مطوري Agile في تضمين تفاصيل إضافية في قصص المستخدمين الخاصة بهم. تساعدك هذه النقاط الإضافية على فهم Agile على مستوى أعمق. تتضمن قصص المستخدم الآمنة عوامل مثل:
- فرضية المنفعة: البيانات التي يمكنك التحقق من صحتها بشأن فوائد الميزة
- المتطلبات غير الوظيفية: صفات النظام التي لا تتعلق بشكل مباشر بوظائفها
- قيمة أعمال المستخدم: أهمية المهمة بالنسبة للمستخدم ودخل عملك
- تكلفة التأخير: القيمة المفقودة من إصدار المنتج لاحقًا
- أهمية الوقت: أهمية إنهاء المهمة في أسرع وقت ممكن
- حجم الوظيفة: عدد الموظفين والموارد اللازمة لإنهاء المهمة
- قيمة تقليل المخاطر/تمكين الفرص: القيم التي تشير إلى قدرة الوظيفة على تخفيف المخاطر أو خلق المزيد من فرص العمل لاحقًا
- أقصر مهمة مرجحة أولاً (WSJF): خوارزمية تحديد أولويات المهمة بناءً على تكلفة التأخير مقسومة على مدة المهمة
قم بتنزيل قوالب قصة المستخدم
هل أنت مستعد لاستخدام قوالب قصة المستخدم هذه بنفسك؟ قم بتنزيل النموذج أدناه لإنشاء قصص مستخدم مخصصة بناءً على منتجاتك واحتياجات عملائك.
أفضل الممارسات لإنشاء قصص المستخدم
تتضمن بعض أفضل الممارسات لتجميع قصص المستخدمين معًا ما يلي:
- التعاون عبر الفرق: كلما زاد عدد أعضاء الفريق المشاركين في قصتك، أصبحوا أكثر ثراءً. يمكن لوجهات النظر المختلفة أن تشكل كيفية تأطير أهداف المستخدم ونقاط الألم.
- تعاطف مع المستخدمين: عند إنشاء قصة مستخدم، امنح المستخدمين اسمًا وسمات داخلية. أنت لا تخلق فكرة مجردة، لذا اجعلهم يشعرون وكأنهم أشخاص حقيقيون تعرفهم. اعتمد على العملاء الحقيقيين الذين تحدثت إليهم.
- ركز على ما يريده المستخدمون، وليس التنفيذ: حدد احتياجات المستخدم، وليس كيفية تلبيتها. لا يمكنك تقليل قصص المستخدم إلى سلسلة من المربعات التي تحددها.
- اجعل قصصك بسيطة: تريد أن تكون قصة كل مستخدم موجزة وواضحة وسهلة الفهم. تجنب الغموض والتعقيد للتركيز على جوهر احتياجات المستخدم.
- استخدم خرائط التأثير: تربط خرائط التأثير قصص المستخدمين بالأهداف والجهات الفاعلة والتأثيرات والتسليمات. تجيب هذه الفئات على لماذا ومن وكيف وما هي الأسئلة المتعلقة بقصصك.
المصدر: pluralsight
شاهد المزيد:
