مشكلات Scrum Burndown [مغلق]
https://stackoverflow.com/questions/91257
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
نحن نستخدم Scrum منذ حوالي 9 أشهر وقد نجح إلى حد كبير.ومع ذلك، نادرًا ما تبدو مخططاتنا المتوقفة مثل المخططات "النموذجية"، بل تشبه بدلاً من ذلك رحلة أفعوانية مرعبة مع بعض الصعود والهبوط المسبب للقيء.
لمحاولة التغلب على هذا الأمر، فإننا نقضي وقتًا أطول قبل بدء السباق في وضع النماذج الأولية والتصميم، لكن يبدو أننا ما زلنا نكتشف المزيد من العمل خلال السباق أكثر مما كنا نعتقد في البداية.ملحوظة:أعني بهذا أن العمل المطلوب لتلبية الأعمال المتراكمة هو أكثر تعقيدًا مما كنا نعتقد في البداية بدلاً من تحديد عناصر جديدة للعمل المتراكم.
هل هذه مشكلة شائعة في Scrum وهل لدى أي شخص أي نصائح للمساعدة في تسهيل الرحلة؟
يجب أن أشير إلى أن معظم أعمال التطوير لدينا ليست مجالات جديدة، لذلك نحن نحافظ على الوظائف في تطبيق كبير ومعقد موجود.هل سكروم أقل ملاءمة لهذا النوع من التطوير لمجرد أنك لا تعرف ما هي المشاكل التي سيطرحها الكود الحالي؟
ما هو الوقت الذي يجب أن نقضيه قبل أن يبدأ السباق في تحديد تفاصيل التطوير؟
تحديث:لقد حققنا المزيد من النجاح ورحلة أكثر سلاسة الآن.ويرجع ذلك إلى حد كبير إلى أننا اتخذنا وجهة نظر أكثر تشاؤمًا عند التقدير مما يمنحنا مساحة أكبر للتنفس للتعامل مع الأشياء عندما لا تسير كما هو مخطط لها.يمكنك القول إنها تسمح لنا بأن نكون أكثر "رشاقة".نحن نحاول أيضًا تغيير التصور القائل بأن المخطط المحترق هو نوع من الجدول الزمني وليس إشارة إلى موارد النطاق.
المحلول
بعض النصائح حول تجانس الأمور.
1) كما قال الآخرون - حاول تقسيم المهام إلى أجزاء أصغر.الطريقة الأكثر وضوحًا للقيام بذلك هي محاولة تقسيم المهام الفنية بمزيد من التفصيل.حيثما أمكن، أشجعك على التحدث إلى مالك المنتج ومعرفة ما إذا كان بإمكانك تقليل النطاق أو "تخفيف" القصة بدلاً من ذلك.أجد الأخير أكثر فعالية.يكون التوفيق بين الأولويات والتقديرات أسهل إذا فهم كل من الفريق ومالك المنتج ما تتم مناقشته.
قاعدتي العامة هي أن أي تقدير أكبر من نصف يوم مثالي ربما يكون خاطئًا :-)
2) حاول القيام بسباقات السرعة القصيرة.إذا كنت تقوم بسباقات السرعة لمدة شهر واحد - فجرب لمدة أسبوعين.إذا كنت ستقضي أسبوعين - فجرّب واحدًا.
- إنه يعمل على تحديد حجم القصة - مما يشجع مالك المنتج والفريق على العمل على قصص أصغر يسهل تقديرها بدقة
- تحصل على تعليقات في كثير من الأحيان حول تقديراتك - ومن الأسهل رؤية الروابط بين القرارات التي اتخذتها في بداية السباق وما حدث بالفعل
- كل شيء يصبح أفضل مع الممارسة :-)
3) استخدم المواقف والأحداث الاسترجاعية لإلقاء نظرة أكثر قليلاً على أسباب الصعود والهبوط.هل هو عندما تقضي وقتًا في مناطق معينة من قاعدة التعليمات البرمجية؟وهل السبب هو سوء فهم شعبي لصاحب المنتج؟حالات الطوارئ العشوائية التي تأخذ وقت التطوير بعيدًا عن الفريق؟بمجرد أن يكون لديك فهم أكبر لمصادر الصعود والهبوط، يمكنك غالبًا معالجة هذه المشكلات على وجه التحديد.مرة أخرى - يمكن لسباقات السرعة الأقصر أن تساعد في جعل هذا الأمر أكثر وضوحًا.
4) صدق تاريخك.ربما تعرف هذا...لكنني سأقولها على أي حال :-) إذا استغرق العبث بحزمة Foo القديمة المروعة 3 مرات أطول مما كنت تعتقد أنها ستستمر في السباق - فسوف يستغرق الأمر أيضًا 3 مرات طالما كنت تعتقد أن السباق التالي.بغض النظر عن مدى الفعالية التي تعتقد أنك ستكون عليها هذه المرة؛-) ثق بالتاريخ واستخدم أشياء مثل طقس الأمس لتوجيه تقديراتك في الربيع المقبل.
أتمنى أن يساعدك هذا!
نصائح أخرى
يسعدني أن أسمع أن سكروم كان ناجحًا إلى حد كبير بالنسبة لك - وهذا أكثر أهمية من أن يبدو مخطط التخفيض السريع مثاليًا.إن توقف الركض السريع هو مجرد أداة للفريق لمساعدته في معرفة ما إذا كان يسير على الطريق الصحيح لتحقيق أهداف الركض السريع.إذا كان الفريق يحقق أهداف العدو السريع، فلن أقلق كثيرًا من أن الرسم البياني يبدو وكأنه أفعوانية.بعض الاقتراحات
- خلال معرض العدو السريع، اسأل الفريق من أين يأتي العمل الإضافي
- يمكن أن يأتي العمل الإضافي من عدم إجراء اختبارات قبول جيدة في وقت مبكر من السباق
- يمكن أن يأتي العمل الإضافي من عدم وجود تراكم جيد الإعداد.القاعدة الأساسية الجيدة هي قضاء ما لا يقل عن 5% من وقت الفريق في التفكير في قصص السباق التالي مسبقًا.
- مراقبة تقدم العمل - هل يقوم الفريق بعمل الكثير بالتوازي؟
- أثناء التخطيط للسباق السريع - كيف يشعر الفريق تجاه تقسيم المهام التي تشكل القصص؟
إذا لم تكن قد حققت أهداف العدو السريع - استخدم سرعة الفريق المحددة لتحمل مسؤولية أقل خلال السباق التالي.عليك أن تتقن المشي قبل أن تتمكن من الركض.
من خلال تجربتي، فإن Scrum بالتأكيد موجه نحو التطوير الجديد أكثر من اهتمامه بالصيانة.التطوير الجديد أكثر قابلية للتنبؤ به من الحفاظ على قاعدة تعليمات برمجية قديمة وكبيرة.
مع ذلك، إحدى المشاكل المحتملة هي أنك لا تقوم بتقسيم المهام إلى أجزاء صغيرة بما فيه الكفاية.إحدى المشاكل الشائعة التي يواجهها الأشخاص في تخطيط البرامج بشكل عام هي أنهم يعتقدون "أوه، هذه المهمة يجب أن تستغرق يومين" دون التفكير حقًا في ما يحدث للقيام بهذه المهمة.في كثير من الأحيان، ستجد أنه إذا جلست وفكرت في الأمر، فإن المهمة تتكون من القيام بـ A وB وC وD وينتهي الأمر بأكثر من يومين من العمل.
كما قال الآخرون، أتوقع أن يكون الاحتراق صعودا وهبوطا.يحدث الاشياء!يجب عليك استخدام البتات "لأعلى ولأسفل" كعلف لاستعراضاتك الاسترجاعية.
تأكد من أن الجميع على دراية بما يعنيه "يتم إنجازه"، واستخدم هذا الفهم المشترك للمساعدة في دفع جلسات التخطيط الخاصة بك.غالبًا ما يؤدي وجود قائمة بما تم إنجازه إلى (أ) مساعدتك على تذكر الأشياء التي قد تنساها و (ب) من المحتمل أن يؤدي إلى المزيد من الأفكار للمهام التي قد تظهر لاحقًا.
هناك نقطة أخرى يجب التفكير فيها - إذا كنت تعمل شهريًا باستخدام قاعدة تعليمات برمجية غير متوقعة، فما زلت أتوقع أن تعود سرعتك إلى معدل ثابت إلى حد معقول.ما عليك سوى تتبع نجاحك مقابل عملك المخطط له واستخدام العناصر المكتملة فقط كحد أقصى عند التخطيط.ثم ركز على مهامك غير المخطط لها ولاحظ ما إذا كانت هناك أي أنماط تشير إلى أن هناك أشياء يمكنك القيام بها بشكل مختلف لتضمين تلك الأشياء في العمل المخطط له.
لقد واجهت مشاكل مماثلة.كان فريقي السابق (الذي كان يعمل فيه لأكثر من عام) كبيرًا وحافظنا على قاعدة بيانات كبيرة جدًا وسريعة التغير لسلسلة من عمليات إطلاق المنتجات الأولية.كانت عمليات الاحتراق التي قمنا بها تبدو مخجلة، لكنها كانت أفضل ما يمكننا القيام به على الإطلاق.
الشيء الوحيد الذي قد يساعد (يجعل الرسم البياني الخاص بك يبدو أفضل) هو الالتزام بعدد الساعات/النقاط الملتزمة بالثبات.إذا قللت من أهمية مهمة ما، واضطررت إلى مضاعفة ساعات العمل، فاستخرج شيئًا ما من سباق السرعة.إذا قمت بمهمة جديدة، فمن الواضح أنها ذات أولوية أعلى من شيء التزم به فريقك، لذا قم بسحب ذلك الشيء الآخر.
لقد حاولنا تقسيم المهمة إلى عدة مهام أثناء التخطيط وقبله، ويبدو أن ذلك لم يساعد أبدًا.في الواقع، لقد أعطانا المزيد من التذاكر اللعينة لتتبعها أثناء السباق.بدأت المتطلبات في الانتقال إلى التذاكر و(ليس من المستغرب) أن تضيع في كل هذه المراوغة.
في فريقي الجديد ، اتبعنا نهجًا جذريًا للغاية وبدأنا في إنشاء تذاكر كبيرة (بعضها أكثر من أسبوع) يقولون أشياء مثل "تنفيذ ميزات V1.2 في ProjectX." يتم الاحتفاظ بمتطلبات/قوائم الميزات الخاصة بـ ProjectX (الإصدار 1.2 المضمن) على الويكي ، لذا فإن التذكرة نظيفة للغاية وتتبع العمل الذي تم تنفيذه فقط.لقد ساعدنا هذا كثيرًا - لقد ساعدنا ذلك طريق عدد أقل من التذاكر لتتبعها، وتمكنا من إنهاء جميع سباقات السرعة لدينا على الرغم من استمرارنا في إنجاز مهام العدو لمساعدة الفرق الأخرى أو إخماد الحرائق.
نستمر في دفع العناصر خارج السباق إذا (وفقط إذا) أجبرنا (من قبل الرجل) على جلب عناصر جديدة.
نصيحة بسيطة أخرى ساعدتنا:أضف "إجمالي ساعات العدو" إلى قائمة الإيقاف الخاصة بك.وينبغي أن يكون هذا مجموع كل التقديرات.إن العمل على إبقاء هذا الخط ثابتًا قد يساعد، ويزيد من وضوح المشكلات التي قد يواجهها فريقك (بافتراض أن ذلك لن يؤدي إلى تخفيض رتبتك...)
-أب
لقد واجهت مشاكل مماثلة في عملية الاحتراق الخاصة بي أيضًا.لقد قمت "بإصلاحها" من خلال تحسين ما تم تضمينه في عملية الإيقاف.
علق SiKeep:
تقدمه ضد التراكم المحدد لهذا العدو ، والذي قد ينتهي أو لا ينتهي بمثابة إصدار.
نظرًا لأنك حددت أشياء معينة للسباق السريع وهذا ما هو موجود في القائمة المنسدلة، فلا أعلم أن كل "العمل الجديد" يجب أن يظهر في القائمة المنسدلة.سأرى ذلك يستمر في الأعمال المتراكمة (لا يؤثر على الإرهاق)، إلا إذا كان من المهم بما يكفي للانتقال إلى السباق الحالي (والذي سيظهر بعد ذلك كاتجاه تصاعدي في الإرهاق).
هكذا قال، الارتفاعات والانخفاضات الطفيفة طبيعية, ، إذا كان خط الاتجاه يتبع بشكل أساسي السرعة المتوقعة.سأكون قلقًا بشأن اتجاه السفينة الدوارة الذي ذكرته.ومع ذلك، فإن فكرة عزل الإرهاق عن طريق إضافة عناصر ذات أولوية عالية فقط إلى السباق الحالي قد تساعد في تخفيف هذه الارتفاعات والانخفاضات في الإرهاق الخاص بك.
وكما قال الآخرون، فإن التخطيط قبل بدء السباق يجب أن يكون قصيرًا...(لا يزيد عن 4 ساعات).
نحن نستخدم مهمة "محددة زمنيًا" للمهام غير المخطط لها.عندما يأتي عمل ذو أولوية عالية، أو تظهر أخطاء مفاجئة، يمكننا استخدام وقت المربع الزمني (لكن، لا يمكننا أبدًا النزول إلى ما دون الصفر).تتمتع هذه الطريقة بميزة إضافية تتمثل في أنه يمكننا بسهولة تتبع المهام غير المتوقعة، ووضع هذه الأشياء في الاعتبار أثناء التخطيط التالي للسباق.
يمكنك دمج العمل الجديد في تاريخ بدء السباق للحصول على مخطط تنازلي رائع المظهر.
يمكنك وضع علامة على العمل الإضافي باستخدام علامة محددة وتقييم في نهاية السباق لماذا لم تتمكن من تحديد تلك المهام من قبل.
نحن نستخدم الآن مخطط حرق.بدلاً من مجرد رسم مخطط لكمية العمل المتبقي، نقوم برسم شيئين:مقدار العمل المنجز والمبلغ الإجمالي للعمل (أي.مكتمل + متميز).
يمنحك هذا سطرين على الرسم البياني يجب أن يلتقيا عند الانتهاء من كل العمل.كما أن لديها ميزة كبيرة تتمثل في أنها تظهر بوضوح عندما يكون التقدم بطيئًا بسبب إضافة المزيد من العمل.
إذا أردت، "يمتلك" أمر الشراء سطرًا واحدًا (إجمالي العمل) و"يمتلك" المطورون/المختبرون السطر الآخر (تم إنجاز العمل).
سوف يتحرك خط أمر الشراء لأعلى ولأسفل عند إضافة/إزالة العمل.
لن يرتفع خط التطوير/الاختبار إلا بعد إكمال العمل.
شرط هل هو الرسم البياني المحترق الخاص بك؟ يشرح ما تعنيه الحالة المحددة في المخطط المحترق.كما يقدم اقتراحات ما يجب القيام به مع ذلك.
بعض الأمثلة الموضحة في المقالة:
هذا هو ما ينبغي أن يكون.إذا كان المخطط التفصيلي الخاص بك يشبه المخطط النموذجي، فأنت في مشكلة.سيساعدك الرسم البياني في معرفة ما إذا كان بإمكانك الالتزام وإنهاء جميع القصص.
اكتشاف القصص أثناء السباق سيحدث دائمًا.من الناحية المثالية، ستكون قادرًا على تصميم المهام واكتشافها مقدمًا، ولكن إذا نجحت، فلماذا لن ينجح التصميم المسبق الكبير؟للإجابة على سؤالك الأخير، يجب أن يستغرق التخطيط للعدو أربع ساعات على الأكثر.
