التقدير في تطوير البرمجيات الرشيقة هو أحد أكثر المواضيع التي نوقشت ونوقشت، لكنه لا يزال يربك الكثير من الناس. لطالما أردنا معرفة المزيد والمزيد عن التقدير والتخطيط. طرح مجموعة من الأشخاص السؤال التالي خلال حديثي الأخير ثم طلب أحدهم إجابة على Quora أيضًا. لذا فكرت، لماذا لا أكتب شرحاً مفصلاً هنا؟
5 الأسئلة الأكثر شيوعًا المتعلقة بالتقدير.
أردنا أن نعرف كم من الوقت سيستغرق الحصول على البرنامج المطلوب وكم من المال يجب أن يدفعه شخص ما مقابل ذلك. فهل هناك طريقة للإجابة على هذا السؤال أثناء ممارسة سكروم؟ لأن سكروم هو لتطوير البرمجيات المعقدة.
لماذا تطوير البرمجيات معقد؟ لأن المتطلبات إما أن تكون غير متسقة، أو أن التقنيات تتغير باستمرار، أو كليهما. إذا كان هناك شيء معقد، فإن تقدير المدة والتكلفة لن يكون سهلاً، لكن راعينا يريد تقديرًا.
التقدير يعني التقدير التقريبي، لذلك لا يمكن أن يكون هناك تقدير دقيق لأن التقدير الدقيق هو تناقض بين التقدير والدقة. تساعد التقديرات في تخطيط الإصدارات وتمويل جهود التطوير وتخفيف المخاطر.
انضم إلى تدريب مالك المنتج PSPO الخاص بنا للحصول على تعليمات من الدرجة الأولى من نافين وسوميت. مع سجل نجاح بنسبة 100%، فإن نجاحك في التدريب مضمون، احجز مقعدك!
أي طريقة مقبولة طالما يدرك الجميع أن هذا مجرد تقدير وليس عقدًا. يمكنك استخدام نقطة قصة مستخدم، أو نقطة وظيفية، أو نقطة حالة استخدام، أو نقطة تعقيد، أو عدد الأيام أو الساعات، إلخ. لكننا نتحدث عن برمجيات معقدة يقدمها فريق وليس فرد، لذا من الأفضل استخدام تقنيات مقبولة للجميع.
في مرحلة مبكرة من مسيرتي المهنية في هندسة البرمجيات، قدم مديري التقدير القائم على التعقيد، وكان مفيداً. كنا نستخدم خمسة مقاييس – منخفضة جدًا ومنخفضة ومتوسطة وعالية وعالية جدًا.
منخفضة جدًا تعني يوم واحد تقريبًا، ومنخفضة تعني 1-3 أيام، ومتوسطة تعني 3-5 أيام، ومرتفعة تعني 4-8 أيام، ومرتفعة جدًا تعني 7-12 يومًا. غيرناها لاحقًا إلى حجم القميص، لكنها كانت متشابهة. عندما استخدمنا نقاط القصة، أصبح الأمر مربكًا لأن النقاط كانت مرقمة أيضًا. حاول الكثيرون تحويل النقاط مباشرة إلى أيام بدلاً من استخدامها كمقياس. على الرغم من أن نقاط القصة أصبحت أكثر شيوعًا في الوقت الحاضر ويمكنك تجربة نفس الشيء كن حذرًا.
إذا كنا نعرف مقدار الوقت الذي سيستغرقه حل المشكلة، فلا ضير من التقدير بالأيام أو الساعات. لكننا نتحدث عن مجال معقد وفريق عمل معقد للتقدير، لذلك سيكون من الصعب التقدير بالأيام والساعات.
صعب ولكنه ممكن إذا فهم الجميع الغرض من التقدير. إذا كان الهدف هو التنبؤ بالإصدارات، وتخصيص ميزانية أولية، وتتبع التقدم نحو الإصدارات، فلا ضير في تقدير الأيام المثالية.
أما إذا كان الهدف هو محاسبة الفرد أو الفريق أو المنظمة على ذلك، فإن ذلك يتعارض مع الغرض من التقدير، وعندها يتحول الأمر إلى لعبة تعاقدية. في مثل هذه الحالات، يستخدم الناس علم النفس بدلاً من الرياضيات لمعرفة الرقم الذي سيفوز بالعقد. تساعد نقاط القصة أو أي تقدير نسبي في تجنب لعبة العقود.
تتعلق التقديرات النسبية بتحديد حجم المشكلة بناءً على بعض العوامل مثل حجم المشكلة ووضوح المتطلبات وتعقيدات التكنولوجيا وما إلى ذلك. نظرًا لأن الفريق يفضل كتابة PBI (عنصر تراكم المنتج) في قصة المستخدم، لذلك تصبح نقطة القصة الخيار الأمثل. يمكنك حتى التفكير في نقطة التعقيد أو نقطة حالة الاستخدام إذا كنت تستخدم تنسيقًا آخر لكتابة PBIs PBIs.
إذا كان هناك بالفعل PBI مقدر بالفعل، فإننا نقدر الباقي مقارنةً به، ولكن ماذا لو لم يكن لدينا أي PBI مقدر موجود؟ علينا اختيار واحد من PBI مع تعقيد معتدل (على سبيل المثال – اتفق الجميع على أن PBI معقد متوسط لأن هناك 3-4 عمليات تحقق من الصحة و2-3 عمليات سير عمل، والمتطلب مفهوم جيدًا، والتكنولوجيا ليست جديدة).
نظرًا لأن لدينا واحدًا الآن، يمكن تقدير 2 PBIs PBIs الثانية مقارنةً بـ PBIs الأولى. وبالمثل، يمكن تقدير 3 PBIs 3 بالمقارنة مع PBIs 1 و2. يمكننا استخدام سلسلة فيبوناتشي لتقدير وتحديد المقياس: –
1 – صغير جدًا، 2 – صغير جدًا، 3 – متوسط، 5 – كبير، 8 – كبير جدًا، 13 – كبير جدًا
يمكن للفريق استخدام ألعاب التخطيط للتقدير. تعتبر لعبة البوكر التخطيطية وجدران التقدير من التقنيات الشائعة بين فرق العمل الرشيقة. سأكتب عن كليهما في مدونتي القادمة. التقديرات المقدمة بالنقاط لا تجيب على أسئلتنا الأولية. متى سيكتمل المنتج وكم سيكلف؟
أراد الراعي/العميل/الشركة معرفة متى سيحصلون على المنتج كاملاً حتى قبل أن يبدأ الفريق العمل على أول PBI، فماذا نفعل؟
حاول أن تفهم الغرض من ذلك قبل تقديم أي رقم. عادةً ما يكون ذلك لمنح عقد للبائع أو تأمين الميزانية الأولية.
لا يُنصح بمنح عقد بناءً على عرض أسعار مالي فقط، ولم تعد العديد من الشركات تتبع ذلك بعد الآن. ومع ذلك، لا تزال هناك حاجة إلى عروض الأسعار المالية لصياغة عقد مبدئي.
وتتبع بعض الشركات التقديرات التناظرية، والقليل منها يتبع تقديرات بيرت، والعديد منها يتبع التقديرات القائمة على السعة.
التقدير التناظري: يعتمد على البيانات التاريخية. ننظر إلى إجمالي النقاط التي حددها الفريق ونقارنها بالمشاريع السابقة ونقتبس بعض الأرقام. كما يعتمد أيضًا على من يملك المخاطر الناجمة عن تغيرات المتطلبات.
اكتشف أهمية أجيليتي الفريق والرشاقة التقنية في توسيع نطاق ممارسات أجايل. تعرف على كيفية تعزيز القدرة على التكيف والتعاون والجودة والابتكار في مؤسستك لتقديم القيمة للعملاء بشكل أسرع وأكثر موثوقية وبجودة أعلى، ابدأ الآن!
يمكن لفريق Scrum تقدير التقديرات إما أثناء تنقيح الأعمال المتراكمة للمنتج أو أثناء أحداث تخطيط سباقات السرعة. أنا شخصياً أفضّل التقدير أثناء تنقيح الأعمال المتراكمة للمنتج. تتبع بعض الشركات أيضًا أسلوب تخطيط الإصدار، ولكن من الناحية الفنية هو تقاعد المنتج المتراكم الذي يحدث قبل السباق الأول.
أقوم بالتدريس في دروسي “محترف سكروم ماستر” و”محترف مالك منتج سكروم”. يمكنك الانضمام إلى جلساتنا التوجيهية القادمة أيضًا. أقترح استكشاف موقع SPOTO الإلكتروني.
نافين مدرب رشيق محترف ويعمل بشكل مستقل منذ فترة طويلة في منطقة آسيا والمحيط الهادئ. وهو يعمل مع فريق تطوير البرمجيات وفريق المنتج لتطوير منتجات رائعة بناءً على عمليات تجريبية.
