الانتقال من نهج مشروع إلى نهج موجه نحو المنتج يتطلب مزيجًا معقدًا من التخطيط الاستراتيجي، والتواصل الواضح، وإدارة المهام بكفاءة.
في قلب هذا التحول يكمن مكون أساسي من منهجية Scrum: Product Backlog. هذه القائمة الديناميكية المرتبة لكل ما هو مطلوب للمنتج تعتبر قلب أي مشروع Scrum.
توفر رؤية واضحة لما يجب القيام به، مما يسهل تحديد الأولويات وتركيز جهود الفريق.
بينما نغمر في عالم "Scrum Product Backlog"، سنتناول أهميتها، وهيكلها، وتأثيرها على تبسيط التحول من المشروع إلى المنتج. سيكون هذا دليلًا، لضمان أن يكون رحلة التحول الخاصة بك سلسة، فعالة، وقبل كل شيء، ناجحة.
"ADAPT Methodology®" هو إطار فريد لتطوير المنتج الرقمي لتغيير الشركات التقليدية الموجهة نحو المشروع إلى شركات تقودها المنتجات!
تغيرت المجتمع ويحتاج القادة إلى دعم في الطريقة التي يقودون بها ويصممون منظمات المنتج الرقمي الخاصة بهم، ولهذا السبب تم إنشاء "ADAPT Methodology®"، ولكن الآن دعونا نغمر في عوالم "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" خصائص معينة تميزه عن قائمة المهام البسيطة:
User stories هي الطريقة الرئيسية لفرق Scrum للتعبير عن الميزات في product backlog. القصص هي وصف قصير وبسيط للوظيفة المطلوبة من منظور المستخدم. على سبيل المثال، كمتسوق، يمكنني مراجعة العناصر في عربة التسوق الخاصة بي لرؤية ما اخترته بالفعل قبل الذهاب إلى الدفع.
الأخطاء والميزات الجديدة تصف شيئًا مختلفًا يريده المستخدم. نظرًا لعدم وجود فرق حقيقي بين الاثنين، فإن الأخطاء هي أيضًا جزء من product backlog.
أنشطة العمل التقني واكتساب المعرفة تنتمي أيضًا إلى "agile backlog". مثال على العمل التقني قد يكون تعليمات مثل: "ترقية محطات عمل جميع المطورين إلى Windows 7".
مثال على اكتساب المعرفة قد يكون عنصرًا في الـ backlog حول البحث في مكتبات JavaScript المختلفة، ثم اختيار مكتبة.
يحتاج الـ backlog إلى اهتمام ورعاية منتظمة؛ يجب إدارته بعناية. في البداية، يبدأ "Scrum Team" و"Scrum Product Owner" المشروع من خلال التفكير وكتابة كل ما يتبادر إلى أذهانهم. يجب أن تكون العناصر التي يأتي بها المالك والفريق أكثر من كافية لـ sprint أول.
"Scrum Product Backlogs" هو عملية مستمرة تتضمن الخطوات التالية:
بينما هذه عملية تعاونية، Product Owner مسؤول عن التأكد من أن "Scrum Product Backlog" في حالة جيدة وتعمل. عند استخدام إطار العمل Scrum، يجب حجز حوالي 10% من الوقت الإجمالي لـ "Scrum Team" للحفاظ على "Scrum Product Backlog".
الصيانة التعاونية لـ "Scrum Product Backlog" تساعد في توضيح المتطلبات وإنشاء الشراء من "Scrum Team".
العمل مع "product backlog" قد يكون تحديًا؛ العديد من "Scrum Product Owners" يكافحون مع backlogs طويلة ومفصلة. يمكن أن تساعدك النصائح التالية في العمل مع "product backlog" بفعالية:
استخدم خريطة الطريق لرسم الرحلة العامة التي ترغب في اتخاذها لمنتجك. حدد الإصدارات الرئيسية القادمة مع أهدافها أو فوائدها، ثم قم بتصميم "product backlog" من خريطة الطريق. استخدم الأهداف لاكتشاف العناصر الصحيحة للـ backlog لضمان التوافق مع استراتيجية المنتج. يساعدك ذلك في تحديد العناصر التي يجب إضافتها إلى "product backlog" والتي لا يجب إضافتها.
استخدم "product backlog" كأداة تكتيكية تحدد التفاصيل المنتج - بما في ذلك الـ epics و user stories - التي يجب تنفيذها للإصدار الرئيسي التالي. يساعد ذلك في إنشاء backlog مختصر يسهل تحديثه وتغييره.
عند إنشاء منتج أو ميزة جديدة، احتفظ بالعناصر ذات الأولوية المنخفضة بشكل خشن. استخدم ردود فعل العملاء والمستخدمين لتحديد الميزات التي يجب تنفيذها لتطوير وتحسين عناصر الـ backlog.
شمل أعضاء الفريق في عمل "product backlog". ستستفيد من معرفتهم وإبداعهم أثناء اكتشاف المخاطر التقنية والتبعيات. كما يزيد من فهم ومشاركة أعضاء الفريق، مما يؤدي إلى متطلبات أفضل وأكثر وضوحًا.
رفض الأفكار والمتطلبات التي لا تساعدك في تحقيق أهداف الإصدار أو تقريبك من رؤية المنتج. يضمن ذلك أن يكون لمنتجك عرض قيمة واضح بينما يمنعه من أن يصبح منتفخًا.
بينما تعد "user stories" والمتطلبات الوظيفية مهمة، فإنها عادةً ما تكون غير كافية. يجب أن تنظر أيضًا في تفاعلات المستخدم، والخصائص غير الوظيفية لمنتجك، وواجهة المستخدم عند إنشاء "backlog" الخاص بك.
استخدم الغموض والمخاطر لتحديد مدى سرعة تنفيذ العنصر. معالجة العناصر غير المؤكدة في وقت مبكر تتيح لك اختبار أفكارك. يمكنك التعلم من الأخطاء أثناء متابعة "backlog" الخاص بك.
قم بتهذيب وتحسين العناصر بانتظام مع فريق التطوير. قم بتحليل الردود والبيانات المجمعة من تعريض آخر زيادة في المنتج للمستخدمين، ثم طبق الرؤى الجديدة في الـ "backlog". قم بإزالة أو تحديث العناصر القديمة الموجودة مع إضافة عناصر جديدة. يقوي ذلك فرصك في بناء منتج يرغب المستخدمون حقًا فيه. كما يحافظ على تحديث "product backlog" وجعله مختصرًا.
قم بتقسيم العناصر الكبيرة إلى عناصر أصغر باستفادة من الرؤى المكتسبة من تعريض زيادات المنتج للمستخدمين. تأكد من أن العناصر ذات الأولوية العالية واضحة وممكنة وقابلة للاختبار حتى تكون جاهزة لتخطيط الـ "sprint".
جرب وضع "backlog" مبني على الورق على الجدار. لهذا النوع من "backlog" العديد من الفوائد:
نمكّن القادة من أن يصبحوا ذوي قيمة عالية ومعترف بهم من خلال تكييف شركتهم المركزة على المشروع إلى شركة موجهة نحو المنتج، تغيرت المجتمع ويحتاج القادة إلى دعم لتكييف شركاتهم للعصر الرقمي، هذا هو السبب في خلق ADAPT Methodology®!
إذا كنت مهتمًا في معرفة ما إذا كانت شركتك مركزة على المشروع أو شركة موجهة للمنتج ببساطة خذ اختبارنا للمنتج إلى منتج.
إذا كنت تريد معرفة كيف يمكننا مساعدتك في بدء التحول الخاص بك، يرجى مراجعة: تدريب المشروع إلى المشروع.
إذا كنت مهتمًا في إجراء تحول في شركتك، يرجى مراجعة: الاستشارات من المشروع إلى المنتج.