كيف يمكننا *تحديد* المواعيد النهائية للسماح لنا بالعمل عليها بفعالية وبطريقة سريعة؟[مغلق]

Question

مغلق. هذا السؤال هو خارج الموضوع.لا يقبل حاليا الإجابات.

---

هل ترغب في تحسين هذا السؤال؟ تحديث السؤال إذن كذلك عن الموضوع لتجاوز سعة المكدس.

مغلق منذ عامين.

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

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

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

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

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

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

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

Answer 1

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

Answer 2

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

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

Answer 3

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