Scrum: العناصر الفنية في تراكم تديرها PO غير التقنية؟ [مغلق

Question

إذا كانت العناصر الفنية مثل "ترقية SPER من V1 إلى V2" أو "زيادة أداء بدء التشغيل" أو "وحدة تسجيل الدخول إلى Refactor لتقليل تعقيد الكود" ، انتقل إلى تراكم المنتج وإذا كان الأمر كذلك ، فكيف ينبغي لمالك المنتج غير التقني أن يكون قادرًا على تحديد أولوياتها مقابل عناصر تراكم أخرى أكثر وظيفية؟

هل يجب أن يكون هناك تراكم منفصل للأشياء الفنية؟ هل يجب أن يكون لدينا دور PO مشترك مع شخصين يمكن أن يعطي الأولوية لأشياء وظيفية وفنية على تراكم المنتج؟

Answer 1

لقد نجحت مع نهج التراكم المزدوج:

1. تراكم المنتج مملوكة لمالك المنتج. أنه يحتوي على عناصر على مستوى القصة (الميزات) التي يتم تقديرها من قبل الفريق ثم يحددها من قبل مالك المنتج. تقسيم عملية التقدير هذه القصص في المهام الأصغر.

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

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

Answer 2

عادة في "الفانيليا" ، لن تذهب المهام الفنية التي ذكرتها كقصص منفصلة.

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

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

أود أن أقترح القيام بقصص "الترقية" كارتفاع مع "تحسين الأداء" و "إعادة العامل" كونها مهام قصة عمل ذات صلة.

ملاحظة: قد تجد مناقشة جيدة حول هذا الموضوع (معظمها في الجزء 3 منه) في كتاب ممتاز من قبل مايك كوهن "يسمى"تطبق قصص المستخدم: لتطوير البرمجيات الرشيقة".

Answer 3

وأنا أتفق مع وجهة نظر النظر إلى الفائدة التجارية لأي قصة تقنية وتتبعها على تراكم المنتج الرئيسي

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

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