تكامل قواعد العمل في قصص المستخدم

Question

لديّ مجموعة من قصص المستخدم ولدي مجموعة من قواعد العمل (في المقام الأول القوانين التي تربط متطلباتي ليكون متوافقًا). في Agile SDLC ، لست متأكدًا من المكان الذي ترتبط فيه هذه "القواعد" بقصص المستخدم الخاصة بي.

على سبيل المثال ، قصة مستخدم مثل:

كطبيب أريد إضافة معلومات المريض من أجل إنشاء ملف مريض جديد.

وقاعدة مثل:

يجب إدخال المعلومات التالية في سجل كل مريض: (أ) المريض: (1) الاسم والاسم المعطى ؛ (2) العنوان ؛ (3) تاريخ الميلاد ؛ و (4) الجنس ؛

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

Answer 1

هناك بعض الطرق المختلفة التي رأيتها في التعامل معها:

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

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

3. لا يوجد رابط صريح ، ولكن القاعدة هي شيء بالنسبة لـ QA أو BA لتشغيل المستخدم للتحقق من أن النموذج يفرض هذه القاعدة. هذا مشابه للأساس ولكن السؤال هو ما هي مسؤولية المطور في هذا. في هذه الحالة ، من الذي يمكن أن يتتبعه ضمان الجودة بدلاً من المطورين.

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

---

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

Answer 2

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