Scrum Product Backlog - الدليل النهائي المبسط

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

في قلب هذا التحول يكمن مكون أساسي من منهجية Scrum: Product Backlog. هذه القائمة الديناميكية المرتبة لكل ما هو مطلوب للمنتج تعتبر قلب أي مشروع Scrum.

توفر رؤية واضحة لما يجب القيام به، مما يسهل تحديد الأولويات وتركيز جهود الفريق.

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

"ADAPT Methodology®" هو إطار فريد لتطوير المنتج الرقمي لتغيير الشركات التقليدية الموجهة نحو المشروع إلى شركات تقودها المنتجات!

تغيرت المجتمع ويحتاج القادة إلى دعم في الطريقة التي يقودون بها ويصممون منظمات المنتج الرقمي الخاصة بهم، ولهذا السبب تم إنشاء "ADAPT Methodology®"، ولكن الآن دعونا نغمر في عوالم "Scrum Product Backlog".

Scrum Product Backlog

بينما كنت أقوم بتدريب بعض عملائي خلال الأسابيع القليلة الماضية، تم طرح أسئلة مستمرة حول "scrum product backlog". للرد على أسئلتكم المستمرة، قررت أن أبحث في هذا الموضوع بشكل أكثر دقة وأكتب هذا المقال.

أبسط تعريف لـ "Scrum Product Backlog" هو: 'هو قائمة بجميع الأعمال التي يجب إنجازها ضمن المشروع'. يحلون محل المتطلبات التقليدية للمواصفات. يتم تصميم الـ backlogs على شكل قصص المستخدمين ويمكن أن يكونوا فنيين بطبيعتهم أو موجهين نحو المستخدم.

"Scrum Product Owner" يمتلك "Scrum Product Backlog". "Scrum Master"، و"Scrum Team"، والأطراف المعنية الأخرى جميعهم مساهمون. لديهم قائمة مهام واسعة وكاملة لإكمال الـ backlog.

يتكون الـ backlog التقليدي في Scrum من العناصر التالية:

• الميزات
• الأخطاء
• العمل التقني
• اكتساب المعرفة

يستخدم "Scrum Product Owner" "Scrum Product Backlog" خلال اجتماع تخطيط الـ Sprint لوصف أعلى الإدخالات للفريق. ثم يحدد فريق Scrum العناصر التي يمكن إكمالها خلال الـ sprint القادم.

لكل "Scrum Product Backlog" خصائص معينة تميزه عن قائمة المهام البسيطة:

• إدخال في "Scrum Product Backlog" يضيف دائمًا قيمة للعميل.
• الإدخالات في "Scrum Product Backlog" مُقدرة بأولوية ومُرتبة وفقًا لذلك.
• مستوى التفصيل للإدخال يعتمد على موقعه في السجل - يتم تقدير جميع الإدخالات.
• هو وثيقة حية.
• لا توجد عناصر إجراء أو مهام منخفضة المستوى.

User stories هي الطريقة الرئيسية لفرق Scrum للتعبير عن الميزات في product backlog. القصص هي وصف قصير وبسيط للوظيفة المطلوبة من منظور المستخدم. على سبيل المثال، كمتسوق، يمكنني مراجعة العناصر في عربة التسوق الخاصة بي لرؤية ما اخترته بالفعل قبل الذهاب إلى الدفع.

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

أنشطة العمل التقني واكتساب المعرفة تنتمي أيضًا إلى "agile backlog". مثال على العمل التقني قد يكون تعليمات مثل: "ترقية محطات عمل جميع المطورين إلى Windows 7".

مثال على اكتساب المعرفة قد يكون عنصرًا في الـ backlog حول البحث في مكتبات JavaScript المختلفة، ثم اختيار مكتبة.

العمل مع Scrum Product Backlog

يحتاج الـ backlog إلى اهتمام ورعاية منتظمة؛ يجب إدارته بعناية. في البداية، يبدأ "Scrum Team" و"Scrum Product Owner" المشروع من خلال التفكير وكتابة كل ما يتبادر إلى أذهانهم. يجب أن تكون العناصر التي يأتي بها المالك والفريق أكثر من كافية لـ sprint أول.

"Scrum Product Backlogs" هو عملية مستمرة تتضمن الخطوات التالية:

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

بينما هذه عملية تعاونية، Product Owner مسؤول عن التأكد من أن "Scrum Product Backlog" في حالة جيدة وتعمل. عند استخدام إطار العمل Scrum، يجب حجز حوالي 10% من الوقت الإجمالي لـ "Scrum Team" للحفاظ على "Scrum Product Backlog".

الصيانة التعاونية لـ "Scrum Product Backlog" تساعد في توضيح المتطلبات وإنشاء الشراء من "Scrum Team".

أخطاء شائعة - مأخوذة من Scrum Alliance

• غالبًا ما يتم الخلط بين الـ backlog ووثيقة المتطلبات.
• لا يوجد تنسيق مفروض لتمثيل الـ backlog: يمكن أن يكون مستند Excel، أو ملف نصي، أو قاعدة بيانات، أو مجموعة من البطاقات المؤشرة، أو الأكثر شيوعًا، ملاحظات Post-It.
• إنشاء نموذج فعلي للـ backlog يزيد من خطر إنشاء نسخ متعددة ومتضاربة؛ هذا خطأ فادح لأن الـ backlog هو مصدر موثوق واحد للعمل الذي يجب القيام به.
• العناصر في الـ backlog هي ذرية بدلاً من الوثائق السردية، مما يعني أن جملة واحدة قد تحتوي على عدة متطلبات متميزة، أو بالعكس تصف متطلبًا واحدًا على مدى عدة فقرات مفصلة. الشكل الفعلي يشجع على هذه "الذرية".
• يجب ألا يصف الـ backlog كل عنصر بنفس مستوى التفصيل، أو "الحبوب". يجب تقسيم الميزات والمهام المخطط لها في المستقبل القريب إلى عناصر دقيقة ومصاحبة بتفاصيل أخرى مثل اختبارات القبول، رسومات واجهة المستخدم، وما إلى ذلك. يمكن وصف العناصر المخطط لها في المستقبل البعيد على مستوى أكثر شمولية.

10 نصائح لـ "Product Backlogs" - مأخوذة من Roman Pichler

العمل مع "product backlog" قد يكون تحديًا؛ العديد من "Scrum Product Owners" يكافحون مع backlogs طويلة ومفصلة. يمكن أن تساعدك النصائح التالية في العمل مع "product backlog" بفعالية:

نصيحة #1: استكمل "Product Backlog" بـ "Product Roadmap"

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

نصيحة #2: ركز "Backlog" الخاص بك على الإصدار الرئيسي التالي

استخدم "product backlog" كأداة تكتيكية تحدد التفاصيل المنتج - بما في ذلك الـ epics و user stories - التي يجب تنفيذها للإصدار الرئيسي التالي. يساعد ذلك في إنشاء backlog مختصر يسهل تحديثه وتغييره.

نصيحة #3: ابدأ بـ "Product Backlog" قصير ومُخطط

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

نصيحة #4: تعاون مع فريق التطوير

شمل أعضاء الفريق في عمل "product backlog". ستستفيد من معرفتهم وإبداعهم أثناء اكتشاف المخاطر التقنية والتبعيات. كما يزيد من فهم ومشاركة أعضاء الفريق، مما يؤدي إلى متطلبات أفضل وأكثر وضوحًا.

نصيحة #5: قل لا

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

نصيحة #6: انظر وراء "User Stories"

بينما تعد "user stories" والمتطلبات الوظيفية مهمة، فإنها عادةً ما تكون غير كافية. يجب أن تنظر أيضًا في تفاعلات المستخدم، والخصائص غير الوظيفية لمنتجك، وواجهة المستخدم عند إنشاء "backlog" الخاص بك.

نصيحة #7: أعطِ الأولوية لـ "Backlog" الخاص بك

استخدم الغموض والمخاطر لتحديد مدى سرعة تنفيذ العنصر. معالجة العناصر غير المؤكدة في وقت مبكر تتيح لك اختبار أفكارك. يمكنك التعلم من الأخطاء أثناء متابعة "backlog" الخاص بك.

نصيحة #8: قم بإدارة "Product Backlog" الخاص بك بشكل استباقي

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

نصيحة #9: جهز "Backlog" الخاص بك

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

نصيحة #10: اجعل "Product Backlog" الخاص بك مرئيًا وسهل الوصول إليه

جرب وضع "backlog" مبني على الورق على الجدار. لهذا النوع من "backlog" العديد من الفوائد:

• يكون واضحًا ويخلق الشفافية (عند وضعه على جدار غرفة الفريق وعندما يكون الأشخاص في نفس المكان).
• يمكنك أن ترى عندما يصبح "backlog" الخاص بك كبيرًا جدًا لأنك تنفد من مساحة الجدار.

هل أعجبك هذا المقال؟

نمكّن القادة من أن يصبحوا ذوي قيمة عالية ومعترف بهم من خلال تكييف شركتهم المركزة على المشروع إلى شركة موجهة نحو المنتج، تغيرت المجتمع ويحتاج القادة إلى دعم لتكييف شركاتهم للعصر الرقمي، هذا هو السبب في خلق ADAPT Methodology®!

إذا كنت مهتمًا في معرفة ما إذا كانت شركتك مركزة على المشروع أو شركة موجهة للمنتج ببساطة خذ اختبارنا للمنتج إلى منتج.

إذا كنت تريد معرفة كيف يمكننا مساعدتك في بدء التحول الخاص بك، يرجى مراجعة: تدريب المشروع إلى المشروع.

إذا كنت مهتمًا في إجراء تحول في شركتك، يرجى مراجعة: الاستشارات من المشروع إلى المنتج.