#camecenter

قصص المستخدمين .......

داخل مشاريع سكروم وبعد تحديد رؤية المشروع من قبل مالك المنتج Product Owner يتم تحديد سكروم ماستر المشروع Scrum Master + فريق عمل المشروع Developers Scrum Team وكذلك المعنيين بالمشروع Stakeholders بعدها يتم وضع ال Epics.

فما هي ال Epics؟ هو وصف عالي المستوى لما يريده العميل من متطلبات

مثال على Epic: يريد العميل إنشا منصة الكترونية ليقدم من خلالها كورسات تدريب وخدمات استشارية وخدمات أونلاين.

وبالتالي يتم تقسيم ال Epic إلى أجزاء أصغر تسمى سجل أعمال المنتج Product Backlog ليصبح لدينا قائمة بالمنتجات ذات الأولوية Prioritized Backlogs وتحتوي Backlogs على مجموعة من ال Sprints وكل Sprints تتكون من عدة مهام Tasks ويتم تنفيذ كل Sprint في مدة من خلال أسبوع إلى أربع أسابيع بينما الإتجاه الحالي في إدارة مشاريع سكروم هو تنفيذ ال Sprint كل أسبوعين.

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

نستخدم قصص المستخدمين User Stories لتحديد متطلبات العميل ويتم صياغة قصص المستخدمين من خلال ورش عمل لفهم متطلبات العميل وصياغتها بشكل قابل للتطبيق وسنتحدث هنا بأمثلة عملية حول صياغة قصص المستخدمين.

تعريف قصص المستخدمين User Story حسب شركة أكسيلوس: أداة تستخدم لكتابة مطلب في شكل (من وماذا ولماذا).

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

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

مثال رقم (1) لقصة مستخدم:

كعميل للخدمات المصرفية عبر الإنترنت (من)

أريد أن أرى رصيدًا متجددًا لحساباتي اليومية (ماذا) ...... يتم تحويلها إلى مهام

حتى أعرف رصيد حسابي بعد تطبيق كل معاملة (لماذا)

مثال رقم (2) : كأدمن أريد إنشاء أدمنز آخرين حتى أتمكن من تفويض المهام.

مثال رقم (3): كمسوق أريد إنشاء حملات بريد إلكتروني آلية حتى أتمكن من الحفاظ على مشاركة العملاء.

مثال رقم (1) لقصة مستخدم مع معايير قبول:

بصفتي أحد الحضور في المؤتمر ، أريد أن أكون قادرًا على التسجيل عبر الإنترنت ، بحيث يكون التسجيل بسيطًا وخالٍ من الأوراق

معايير القبول:

- لا يمكن للمستخدم تقديم نموذج دون ملء جميع الحقول الإلزامية - يتم تخزين المعلومات من النموذج في قاعدة بيانات التسجيلات

- تعمل الحماية ضد البريد العشوائي

- يمكن السداد عن طريق PayPal و Debit و Credit Card

- يتم إرسال رسالة تأكيد بالبريد الإلكتروني إلى الحاضر بعد إرسال النموذج

مثال رقم (2) لقصة مستخدم مع معايير قبول:

كعميل للخدمات المصرفية عبر الإنترنت ، أريد كلمة مرور قوية ، بحيث تكون معلومات بطاقتي الائتمانية آمنة

معايير القبول:

- يجب ألا تقل كلمة المرور عن 8 أحرف

- يجب أن تحتوي كلمة المرور على حرف واحد على الأقل من كل مجموعة من المجموعات التالية: الأبجدية الصغيرة ، الأبجدية الكبيرة ، الأرقام ، الأحرف الخاصة (! ، @ ، # ، $ ،٪ ، ^ ، & ، *)

مثال رقم (3) لقصة مستخدم مع معايير قبول:

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

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

معايير القبول:

- قم بتضمين الطلب والسعة المتوقعة حسب الموقع

- تضمين تصور الفجوات القدرات حسب الموقع

- تضمين القدرة على إعادة مواءمة الطلب مع المرافق ذات السعة المتاحة

- تضمين القدرة على إنشاء طلبات للتعاقد من الباطن / مصادر الموردين البديلة

مثال رقم (4) لقصة مستخدم مع معايير قبول:

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

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

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

معايير القبول:

- قم بتضمين الطلب والسعة على المدى الطويل حسب الموقع

- تضمين المشاريع الحالية المعتمدة حسب الموقع

- قم بتضمين قائمة مفصلة بطلبات المشروع مع التكلفة حسب السنة التقويمية

- تضمين الميزانية المالية المعتمدة لمشاريع السعة حسب الموقع حسب السنة التقويمية

- تضمين القدرة على مراجعة طلبات المشروع الفردية والموافقة عليها ورفضها وطلب الملاحظات

مثال رقم (5) لقصة مستخدم مع معايير قبول:

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

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

معايير القبول:

- تضمين الطلب المتوقع وميزانية المبيعات

- تضمين الفروق المتوقعة

- تضمين القدرة على إعادة تنظيم المبيعات للتنبؤ

- تضمين القدرة على طلب تسريع المبيعات

- قم بتضمين القدرة على المراجعة والموافقة والرفض وطلب التعليقات على التغييرات في ميزانية المبيعات

يتم تحديد الأولوية لكل قصة مستخدم من خلال تصنيف الأولوية إلى: ( Must – Should – Could يجب – ينبغي – يمكن)

مرفق في أول تعليق لنك يحتوي على 3 مشاريع سكروم منهم مشروع يتضمن المئات من قصص المستخدمين وموقفها من التنفيذ حتى ال Release بينما المشروع الأخر يتضمن توزيع قصص المستخدمين على أكثر من Epics والمشروع الأخير يتضمن أكثر من 160 قصة مستخدم.

وأنهي المقال بسؤال متوقع وهو هل يمكن استخدام أداة قصص المستخدمين في مشاريع الكونستركشن؟

box technique. The product box is a facilitated workshop where a blank white

cardboard box is given to the customer to design, using coloring markers, stickers,

etc. in order to present their vision for their future product. This tool helps you

identify what matters most to your customer regarding the product features. This

workshop can also involve potential end-users who can reveal some useful insights