تنفيذ قصص المستخدم بطريقة رشيقة [مغلقة

Question

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

على سبيل المثال ، دعنا نفترض أن لدي أقل من قصتين من المستخدمين لتبدأ بنظام إدارة المحتوى الافتراضي:

القصة 1:
ك مؤلف المحتوى
أنا بحاجة لــ تكون قادرًا على إنشاء مقالات إخبارية
لهذا السبب. يمكن استخدامها لجذب المستخدمين إلى موقع الويب

القصة 2:
ك محرر
أنا بحاجة لــ تكون قادرًا على عرض المقالات الحالية
لهذا السبب. يمكنني مراجعتهم لتحسين الجودة

الطريقة التي سأقترب بها من هذا ،

• أود الحصول على إحدى قصص المستخدم هذه
• كسر أنا بحاجة لــ جزء من قصة المستخدم إلى قطع أصغر من المهام
• احصل على هذه المهام واحدة تلو الأخرى وتوصل إلى اختبارات لتغطية المهمة المحددة
• تنفيذ المهام طريقة TDD

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

لذا فإن سؤالي هو ما إذا كان ينبغي عليّ أن يكون لدي أي مهام/اختبارات تتحكم في المصادقة/التفويض للنظام لإكمال قصص المستخدم هذه
أو
هل يجب أن أركز فقط على أنا بحاجة لــ جزء من قصص المستخدم في محاولة لتنفيذ الوظيفة ، وانتظار أي قصص مستخدمية تذكر على وجه التحديد المصادقة ، التفويض المتطلبات ذات الصلة؟

جميع مدخلاتك موضع تقدير كبير.

هتافات.

Answer 1

يجب أن تركز بالتأكيد على أنا بحاجة لــ جزء والنظر في ك و لهذا السبب. كنوع من السياق.

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

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

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

يجب أن تلقي نظرة على الكتاب الممتاز Scrum و XP من الخنادق وانظر كيف يفعلون ذلك.

Answer 2

لا تقلق بشأن الآثار المترتبة في هذه المرحلة.

يجب أن تكون قصة المستخدم:

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

[المصدر ، ويكيبيديا]

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

Answer 3

الجملة

"ك مؤلف المحتوى أنا بحاجة لــ تكون قادرًا على إنشاء مقالات إخبارية لهذا السبب. يمكن استخدامها لجذب المستخدمين إلى موقع الويب "

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

تحدث إلى المستخدم أو ممثل المستخدم في فريقك لمعرفة معنى ذلك حقًا.

Answer 4

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

• كزائر جديد ...
• كزائر عائد ...

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

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

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

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

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

Answer 5

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

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

Answer 6

على الأقل كنت أفرخ القصص:

1. مصادقة المستخدم
2. مؤلف / محرر الاشتراك ... أو مستخدم تسجيل ، تعيين أذونات

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

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

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

مهما فعلت ، اجعل الأمر بسيطًا.

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