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

اكتمال التخطيط ويمكن رؤية النتائج أعلاه. أخذوا 3 قصص المستخدم بقيمة 16 و 20 و 37 نقطة قصة ، على التوالي. المجموع - 73.
علاوة على ذلك ، مثل أي فريق تطوير يحترم نفسه ويعشق كل مسرات العمل على Scrum ، نضيف هذه التصنيفات إلى Jira. في الوقت نفسه ، نقدم فقط تقديرات عامة (أو متوسطة - أسوأ!) لكل قصة.
أسبوعين من العمل دون إزالة يديك من لوحة المفاتيح وبدون الاستيقاظ من كرسي المكتب المحبوب منذ سنوات ، يمكنك التفكير في الوظائف التي تم تصنيعها حديثًا.
ولكن ما الأمر؟ انتهى السباق ونرى أن الجبهة فعلت كل شيء كما هو مخطط لها ولن يكون لديها وقت للقيام بضربة مفاتيح واحدة ، وقد تجاوز الظهر السباق وقام بمهام أكثر من المخطط.
ثم انتهى سكروم وإكس بي من Trenches PM للتو من القراءة ويبدو: "كل شيء واضح !!! سيتعين علينا أن نأخذ المزيد من نقاط البناء إلى سباق العدو التالي ، وبعد ذلك سيكون كل شيء على ما يرام ولن يهرب أي دعم مني بعد الآن ، مع أخذهم في حصدهم! "
نحن نخطط لسباق جديد ....

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

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

ثم يأتي الحل في حد ذاته. من أجل تنظيم حمل الفريق بنجاح ، من الضروري الاحتفاظ ليس فقط بسجل عام في نقاط السجل ، ولكن أيضًا بسجل منفصل في سياق التحميل على المقدمة والخلف. سيتيح لك ذلك معرفة مقدار العمل الأمثل لكل منطقة والاعتماد عليها لملء الأعمال المتراكمة. حتى الآن ، لا يمكن تنفيذ هذا النهج في جيرا بدون ملاحظات منفصلة في MS Excel ، لكن هذا لا يعني أنه لا ينبغي استخدامه.
أنا متأكد من أن مطوري أتلاسيان سوف يتوصلون إلى حل لهذه المشكلة ، لكن في الوقت الحالي ، لا تكرروا أخطائنا!
ملاحظة: تنطبق هذه الاستنتاجات فقط على تطوير تطبيقات خادم العميل ، حيث يوجد فصل واضح للعمل في المقدمة والخلفية. لا ينبغي أن تنشأ مثل هذه المشكلة في فريق مطوري Full-Stack ، الذين يقومون على الفور بتقييم العمل في اتجاهين.