يعرف الأشخاص الذين يعملون في بيئة Agile أهمية قصص المستخدم. تضع منهجيات Agile الأشخاص فوق العمليات وتدفع مشاريعهم إلى الأمام بطريقة تجعل أي شخص مرتبط بها يفهمها بشكل كامل. ولهذا السبب يتم التأكيد على كتابة قصص المستخدم في ظل Agile.
تقع على عاتقنا مسؤولية إنشاء قصص المستخدمين بكفاءة عالية بحيث يتمكن حتى الشخص الأقل خبرة من فهم الفكرة بالكامل بمجرد قراءتها. تقدم هذه القصص نظرة عامة على ميزات كل منتج وتخبر بالتفاصيل وراء كل جزء من المشروع. إنها عملية خطوة بخطوة حيث يتم جمع المتطلبات على بطاقات، وإحضارها للمناقشة من خلال المحادثة، والانتقال إلى مرحلة التأكيد بمجرد ترتيب كل شيء.
دعونا نبحث بشكل أعمق ونناقش قصص المستخدم والـ 3Cs الخاصة بقصص المستخدم بالتفصيل.
ما هي قصة المستخدم؟
ببساطة، قصة المستخدم هي وثيقة غير رسمية تشرح بإيجاز نظام البرمجيات. تستخدم منظور المستخدم النهائي لكتابة هذه الوثيقة، مع التأكد من أن جميع المتطلبات والتوقعات من المنتج واضحة لكل من يرتبط بها. في قصص المستخدم، يوجد شرح قصير وواضح لكل ميزة أو وظيفة لمنتج برمجي. يمكن لأي شخص يشارك في المشروع بأي طريقة في أي نقطة من العملية الرجوع إلى قصة المستخدم والحصول على فكرة كاملة عن المنتج بالكامل. من المهم ملاحظة هنا أن قصص المستخدم تختلف باختلاف حالات الاستخدام. وهي تهدف إلى معالجة الأولويات وفهم الحالة الحالية للمنتج.
كيف تقوم بتعريف قصة المستخدم؟
قصة المستخدم هي شرح عام غير رسمي لخاصية برمجية مكتوبة من منظور المستخدم النهائي. والغرض منها هو توضيح كيفية تقديم ميزة برمجية قيمة للعميل – Atlassian
قد تكون متطلبات الكتابة سهلة بالنسبة لأولئك الذين يقومون بتطوير المشروع. ولكن ماذا عن العملاء، الذين قد لا يفهمون دائمًا المصطلحات الفنية؟ يعمل Scrum، مع التركيز على تعاون العملاء، على حل هذه المشكلة بمساعدة قصص المستخدم.
يتضمن Scrum تقسيم مشروع معقد إلى أجزاء أصغر. يتم تقسيم كل جزء، والذي يُسمى ملحمة، إلى وحدات أصغر تسمى قصص المستخدم. وبالتالي، فإن قصة المستخدم هي أصغر وحدة عمل في مشروع رشيق. وهي تصف الهدف النهائي المراد تحقيقه ويتم سردها دائمًا من منظور المستخدم. بعبارة أخرى، تعتبر قصص المستخدم الأساس أو اللبنات الأساسية لوحدات أكبر داخل المشروع – مثل الملاحم والمبادرات. دعنا نفهم عملية تحليل السبب الجذري لـ 5 لماذا هنا لتحديد السبب الرئيسي للمشكلة.
نظرًا لأنه يُروى من منظور المستخدم، فهو مكتوب بصيغة يسهل على المستخدم فهمها. وهذا يعني أنه مكتوب بطريقة بسيطة وغير رسمية ويشرح ما يفترض أن تحققه ميزة البرنامج التي يمثلها. إنه ليس تفصيليًا، بل هو قصير ولا يزيد طوله عن بضع جمل. إذا لزم الأمر، يمكن إضافة المتطلبات إلى قصة المستخدم مع وضع المزيد من المتطلبات أثناء تطوير الميزة في العدو السريع.
بعبارة أخرى، تصف قصة المستخدم احتياجًا أو متطلبًا محددًا للمستخدم. ويمكن أيضًا تسميتها بالسيناريو. ويمكن كتابة قصص الاستخدام على بطاقات الفهرس أو مستندات Word أو حتى جداول بيانات Excel.
تعتبر قصص المستخدم مفيدة أيضًا لتقدير العمل الذي يتعين القيام به أو العمل المتبقي للقيام به. يعد تقدير كمية العمل الذي يتعين القيام به أو الجهد المطلوب لإكمال العمل ضروريًا لأن هذا سيساعد في تحديد الجدول الزمني والتكاليف والموارد المطلوبة لتلبية المتطلبات. بصفتك مديرًا، فإن أخذ دورة شهادة PMP سيمنحك الفرصة لإتقان قصص المستخدم أثناء العمل.
تتضمن بعض طرق التقدير باستخدام قصص المستخدم ما يلي:
- تخطيط البوكر
- مقاسات التي شيرت
- نظام الدلو
- رسم الخرائط التقاربية
- طريقة الطلب و المزيد
متى نشأت قصص المستخدم؟
قصص المستخدم هي أجزاء من السلوك المرغوب فيه لنظام برمجي. وهي تستخدم على نطاق واسع في مناهج البرمجيات الرشيقة لتقسيم كمية كبيرة من الوظائف إلى أجزاء أصغر لأغراض التخطيط–– مارتن فاولر
لذا، فإن السؤال هنا هو، متى بدأنا فعليًا في استخدام قصص المستخدم لأول مرة؟ وفقًا لـ Agile Alliance®، نشأت قصص المستخدم لأول مرة في عام 1989 في البرمجة المتطرفة، وهو إطار عمل لتطوير البرامج الرشيقة مثل Scrum. وفي حين كانت في الأصل، في وقت تقديمها، مشابهة جدًا لحالات الاستخدام، إلا أن تفاصيلها ونطاقها تغيرا بمرور الوقت.
قد تبدو قصص المستخدم وحالات الاستخدام متشابهة للغاية، ولكن هناك اختلافات دقيقة بينهما. تتعلق قصة المستخدم أكثر باحتياجات المستخدم أو متطلباته، بينما تصف حالة الاستخدام الميزة التي نبنيها لتناسب الاحتياجات التي يصفها العميل. إنها أكثر تقنية بعض الشيء وتحدد تفاعل الميزة التي يتم بناؤها مع بقية النظام أو البرنامج أو العملية. من ناحية أخرى، تكون قصص المستخدم أسهل في القراءة والفهم.
وفقًا لرون جيفريس، الذي اقترح نموذج المحادثة والتأكيد للبطاقات لقصص المستخدم، فإن حالات الاستخدام عبارة عن ممارسات متطلبات توثيقية بينما قصص المستخدم عبارة عن ممارسات متطلبات اجتماعية.
ثلاثة عناصر أساسية في قصص المستخدم – شرح جيد
“البطاقة، المحادثة، التأكيد”؛ هذه الصيغة (من رون جيفريز) تلتقط مكونات قصة المستخدم – Agile Alliance
في عام 2001، اقترح رون جيفريس نموذج البطاقة والمحادثة والتأكيد لقصص المستخدم للبرمجة المتطرفة، حيث ذكر أن قصص المستخدم هي عناصر أساسية في “دائرة الحياة” لنظام XP. دعونا نلقي نظرة على الجوانب الثلاثة لقصص المستخدم.
- بطاقة
أين تُكتب قصص المستخدم؟ على البطاقات. تُكتب يدويًا على بطاقات الفهرس، ويساعد هذا التمرين في الحفاظ على إيجاز قصص المستخدم. لن تحتوي البطاقة على كل المعلومات أو الكثير منها حول المتطلب. بدلاً من ذلك، ستحتوي البطاقة فقط على معلومات كافية لتحديد المتطلب ومساعدة الجميع على فهم ماهية القصة.
تمثل البطاقة المتطلبات وهي أداة رائعة للتخطيط. ويمكن استخدامها أيضًا لتدوين بعض الملاحظات الإضافية مثل الأولوية أو القصة والتكلفة المترتبة على ذلك. بعد الانتهاء من قصة المستخدم التي سيتم اختيارها للسباق المحدد، يقوم مالك المنتج بتسليم بطاقة قصة المستخدم إلى المطورين.
الشكل القياسي المستخدم لكتابة قصة المستخدم على البطاقة هو كما يلي:
باعتباري [نوع المستخدم]، أريد/أحتاج إلى [الهدف] حتى أتمكن من تحقيق [التبرير/القيمة التجارية]. - المحادثة
البطاقة هي الخطوة الأولى نحو صياغة قصة المستخدم، ولكن يجب مناقشة المتطلبات بشكل أكبر وصقلها وإبلاغها للمطورين. يتم ذلك من خلال المحادثة. كما تعمل المحادثة بين المطورين وأصحاب المنتجات ومدير سكروم وأصحاب المصلحة على تعزيز التعاون بين الجميع، وبالتالي المساعدة في الحصول على فهم مشترك للمتطلب مما يؤدي إلى تطوير المنتج.
يتم تبادل الأفكار والآراء من خلال المحادثة بشكل تدريجي بمرور الوقت، بدءًا من تقدير القصة الذي يتم إجراؤه أثناء التخطيط للإصدار ثم أثناء اجتماع التخطيط للسباق عندما يتم اختيار القصة للتنفيذ. وبينما تكون المحادثات لفظية في الغالب، يمكن استخدام المستندات للدعم. - التأكيد
حتى في أكثر المحادثات تعمقًا، هناك دائمًا عنصر من الشك حول المتطلب الذي يجب إنشاؤه. كيف نتعامل مع قصة المستخدم ونضمن أن هذا هو ما ينص عليه المتطلب؟
يتم ذلك من خلال الجزء الثالث من قصة المستخدم وهو “التأكيد”. يأتي التأكيد في شكل اختبارات القبول. والتأكيد هو معيار القبول الذي يلتقط المتطلبات الأساسية ويساعدنا في اختبار المنتج الذي تم إنشاؤه للتأكد من أنه يلبي المعايير المحددة.
يتم إنشاء معايير القبول بشكل عام بواسطة مالك المنتج ثم يتم تحسينها وتوسيعها في تحسين المتراكم. يقوم المطورون بتنفيذ معايير القبول أو اختبارات القبول. يجب أن تلبي الزيادة التي تم إنشاؤها بناءً على قصة المستخدم اختبارات القبول، والتي تؤكد أن الميزة تم تنفيذها بشكل صحيح. في نهاية التكرار، يوضح المطورون اكتمال القصة من خلال اجتياز معايير القبول. هذا هو التأكيد المكتمل.
عندما تكتمل هذه العناصر الثلاثة لقصص المستخدم ويتم الوفاء بها، تصبح الميزة التي تم إنشاؤها مكتملة ويمكن إصدارها.
أفضل المدن التي تقدم فيها SPOTO دورة تدريبية للحصول على شهادة إدارة المشاريع عبر الإنترنت
قالب قصة المستخدم: الدور والإجراء والفائدة
أطلق العنان لإمكاناتك مع Agile Management! احصل على شهادة Agile عبر الإنترنت وقم بتوجيه فريقك نحو النجاح باستخدام استراتيجيات قابلة للتكيف وفعالة.
يحدد قالب قصة المستخدم التنسيق المستخدم أثناء كتابة قصص المستخدم. وفقًا لـ Agile Alliance، يستخدم القالب الأكثر شيوعًا التنسيق “بصفتي… أريد أن… حتى…”
- كشخص (يريد إنجاز شيء ما)
- أريد أن (ما يريدون تحقيقه)
- لذلك (لماذا يريدون إنجاز هذا الشيء)
تتم كتابة قصة المستخدم من وجهة نظر المستخدم نفسه. فهي تصف دور المستخدم أو الإجراء أو ما يحتاجه المستخدم والسبب وراء القصة أو الفائدة التي تقدمها.
دعونا نلقي نظرة على كل من هذه المكونات بالتفصيل: - الدور: يشير الدور إلى المستخدم الذي يستخدم النظام أو الذي يتم بناء الميزة من أجله. المطورون ليسوا مستخدمي الميزة.
- الفعل: يشير جزء “ماذا” من القصة إلى الفعل أو سلوك النظام. كل قصة لها فعل فريد.
- الفائدة: هي نتيجة الفعل، وهو ما يحتاج المستخدم إلى حدوثه.
أمثلة:
باعتباري <مستخدم>، أريد أن أتمكن من <البحث> حتى أتمكن من <الحصول على المنتجات التي أريدها>
باعتباري <مستخدم>، أريد أن أتمكن من <إضافة عناصر إلى عربة التسوق> حتى أتمكن من <الاطلاع على العناصر>
تعرف على دورات إدارة المشاريع الأكثر شهرة في SPOTO
كيفية كتابة قصة مستخدم جيدة مع INVEST
INVEST هو اختصار لـ: - مستقل
- قابلة للتفاوض
- قيّم
- قابلة للتقدير
- صغير
- قابلة للاختبار
يجب أن تشتمل قصة المستخدم الجيدة على كل هذه الخصائص. دعنا نفحص كلًا من هذه الخصائص: - مستقلة: يساعد الحفاظ على استقلال القصص عن بعضها البعض في تحديد أولويات القصص الموجودة في قائمة الانتظار. إذا كانت القصة تعتمد على قصص أخرى، فلا يمكن تناولها حتى اكتمال القصص الأخرى، حتى لو كانت ذات أولوية أعلى.
- قابلة للتفاوض: القصة قابلة للتفاوض، مما يعني أنه يمكن تغييرها بناءً على المحادثة التي تجري بين المطورين وأصحاب المنتجات والمستهلكين. يعد الحوار التعاوني بين المطورين والمستخدمين الذين يتم تطوير الميزة من أجلهم، أو وكيل المستخدم، أي مالك المنتج، أمرًا ضروريًا. يجب أن تتوصل جميع الأطراف إلى رؤية مشتركة ثم يبدأ التطوير.
- قيمة: يجب أن تكون قصة المستخدم قابلة للقياس، مما يعني أنها يجب أن تضيف قيمة إلى المشروع الإجمالي. لذا، يجب أن تضيف قصة المستخدم قيمة ليس فقط للمستخدم الذي يتم تطويرها من أجله، بل يجب أن تلبي أيضًا المتطلبات غير الوظيفية.
- قابلة للتقدير: يجب أن تكون قصة المستخدم قابلة للتقدير حتى يمكن قياس قيمتها وأولويتها اللاحقة. وهذا يساعد مالك المنتج في تحديد أولويته في سجل المنتج.
- صغيرة: تمثل قصص المستخدم أصغر وحدة عمل في مشاريع Scrum وتمثل وظيفة صغيرة يقدمها المنتج. إذا كانت قصص المستخدم كبيرة، فيجب تقسيمها إلى وحدات أصغر لأن وحدات المستخدم الأصغر تساعد في تقديم الميزات بشكل أسرع.
- قابلة للاختبار: يجب أن تكون كل قصة مستخدم قابلة للاختبار للتأكد من أنها تعمل كما ينبغي وتقدم قيمة للعميل. تتم كتابة معايير القبول لهذا الغرض. عندما تجتاز قصة المستخدم معايير القبول، تكون مكتملة وجاهزة للشحن.
نصائح لإنشاء قصص مستخدم رائعة
توصل رومان بيتشلر إلى هذه النصائح التي ستساعد في إنشاء قصص مستخدم آمنة: - اكتب قصة المستخدم من وجهة نظر المستخدم
- استخدم الشخصيات لإنشاء أفضل سيناريو لقصة المستخدم
- ضمان التعاون أثناء إنشاء قصة المستخدم
- حافظ على القصص بسيطة
- ابدأ بالملاحم
- استمر في تحسين القصص حتى تصبح جاهزة
- إضافة معايير القبول
- استخدم الورق/البطاقات الفهرسية لتدوين قصص المستخدم
- تأكد من أن قصصك مرئية ويمكن الوصول إليها
خاتمة
تُعد قصص المستخدم تقنية مهمة في منهجية Agile التي توفر السياق للمطورين قبل بدء المشروع. تُجبر هذه الوثيقة الفريق على التفكير النقدي ومعالجة المشكلات التي قد يواجهها العميل. يُعد كتابة قصة المستخدم جزءًا مهمًا، لذا من الأهمية بمكان أن يتم إنجاز كل شيء بطريقة منظمة. تساعد في تحديد أولوية كل مهمة من خلال شرح متطلبات المستخدم المؤكدة وإفساح المجال لفريق التطوير.
لذا، يجب أن يكون لدى فريق التطوير أو أي شخص يكتب قصص المستخدم معلومات واضحة حول العناصر الثلاثة لقصص المستخدم وكيفية كتابة قصة مستخدم فعّالة. هناك شهادات Agile يمكن للمرء إكمالها لتعلم منهجيات مختلفة إلى جانب تعلم كيفية كتابة قصص المستخدم. افهم أنه كلما كانت قصص المستخدم الخاصة بك أكثر كفاءة ووضوحًا، كان تسليم المنتج أفضل.
الأسئلة الشائعة
- ما هي الـ 3C في Agile؟
العناصر الثلاثة للـ Agile هي:
- بطاقات
- محادثة
- تأكيد.
- هذه هي الخطوات الأساسية الثلاثة لكتابة قصة المستخدم.
بطاقات
وهنا يتم كتابة قصة المستخدم يدويًا. تحتوي البطاقات على معلومات دقيقة حول متطلبات المستخدم أو أي معلومات مباشرة شاركها المستخدم النهائي. تعد البطاقات أداة للتخطيط لأنها تخبر الجميع بالقصة الحقيقية.
محادثة
المعلومات التي يتم جمعها على البطاقات هي معلومات أولية وليست نهائية. لذا، تشكل المحادثة الخطوة الأولى نحو صياغة قصة المستخدم. تعد المحادثة أمرًا بالغ الأهمية لمناقشة المتطلبات مع المستخدمين النهائيين والجدوى مع فريق التطوير.
تأكيد
قد يتسبب التواصل اللفظي في حدوث فوضى. لذا، فإن الخطوة الأخيرة في العملية هي كتابة تأكيد. ويمكن لكل عضو مشارك الرجوع إليه وتجربته لإنشاء قصة المستخدم النهائية.
- لماذا من المهم كتابة قصة المستخدم على البطاقة؟
إن التواصل اللفظي مربك ويترك مجالاً لسوء الفهم. لذا، من الضروري تدوين كل شيء، ويمكنك القيام بذلك على بطاقات الفهرس. وعلاوة على ذلك، عندما تدون كل شيء على البطاقات، فإنك ستتخطى المعلومات غير الضرورية وتحتفظ فقط بالبيانات الدقيقة عليها. تشكل هذه البطاقات نقطة مرجعية للخطوة التالية، وهي المحادثة. يمكن لكل من يشارك في المحادثة استخدام بطاقات الفهرس لمعرفة ما يجب مناقشته للمضي قدمًا نحو إنشاء قصة المستخدم النهائية. - ما هي بعض التحديات الشائعة التي تواجهها الفرق في تطبيق الـ 3Cs بشكل فعال؟
من المهم كتابة قصص المستخدم بأسلوب Agile لأنها تساعد في الحفاظ على سلاسة العملية ووضوحها. ومع ذلك، هناك تحديات قد يواجهها المستخدمون أثناء تنفيذ 3Cs بفعالية في كتابة قصص المستخدم. بعض هذه المشكلات هي:
- كتابة معلومات غير ضرورية على بطاقات الفهرس هي المشكلة الأكثر شيوعًا، مما يؤدي إلى تفويت أشياء مهمة.
- عدم مناقشة المتطلبات بالتفصيل يترك مجالا للارتباك والأخطاء.
- سوء تحديد أدوار كل فريق فيما يتعلق بتنفيذ المشروع. وهذا يبقي الجميع في حالة من الفوضى، ولن ترى أي تقدم أو ملكية بين الفرق.
