كيف تكتب قصص المستخدم: دليل كامل

تعد قصص المستخدمين جزءًا حيويًا من التطوير المناسب للبرامج الرشيقة: فلنلقِ نظرة على دورهم ونتعلم كيفية كتابة قصص المستخدمين.

تعد الأطر الرشيقة طريقة شائعة وفعالة لبناء تطوير البرامج وتفويض المهام. كتابة قصص المستخدم (يجب عدم الخلط بينه وبين كيفية كتابة الشهادة) هي أداة في التطوير السريع الذي يسمح للمطورين بفهم ما يجب القيام به وكيفية تلبية المتطلبات. هذا يجعلها نقطة انطلاق مهمة للغاية - ولكن هذا يعني أيضًا أنه يجب بناؤها بعناية. إليك ما يجب أن تعرفه.

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

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

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

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

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

الخطوة 1. الحصول على المدخلات

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

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

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

الخطوة 3. تحديد وتعريف وتعريف

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

الخطوة 4. اكتب القصة

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

الخطوة 5. قسّم على خطوات أخرى

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

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

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

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

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

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

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

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

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

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

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

دعنا ننتقل إلى تقنيتي تنسيق مفيدتين للغاية عند إنشاء جمل قصة للمستخدم. الأول بسيط للغاية: "من وماذا ولماذا؟" في قالب الجملة ، يمكن وصف ذلك على النحو التالي:

بصفتي [من هو المستخدم] ، أريد [ما يريده المستخدم] (بحيث [لماذا يريده المستخدم]).

يمكن أيضًا تأطير هذا النموذج على النحو التالي: "بصفتي [دورًا] ، أريد [إجراء] ، (حتى تكون [الفائدة]) ،" للمصطلحات المبسطة. يعد اتباع هذا التنسيق الأساسي كافيًا لإنشاء غالبية قصص المستخدمين. عادة ما يكون كل ما تحتاجه ويمكن أن يساعد في توفير الكثير من الوقت عند استخدامه لكل قصة مستخدم.

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

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

أسئلة وأجوبة حول كيفية كتابة قصص المستخدم

قد تكون مهتمًا أيضًا بدليلنا حول كيفية كتابة مراجعة اللعبة.