التقدير الرشيق في إدارة المنتجات الرقمية، شروطها غير يسيرة، وقد يعتري تطبيقها بعض الممارسات السلبية..
لكن إن نجحت الشركة التقنية بتجاوز سلبيات التنفيذ بين أفراد فرق العمل، وضحدت الافتراضات والتطبيقات الخاطئة غير العلمية، ووفرت بيئة ملائمة لازدهار هذه المنهجية؛ فستكون نتائجها باهرة يعمّ نفعها على جميع الأطراف إدارة وعملاء وفرق عمل.
في هذا المقال سنتعرف على بعض الحالات والإجراءات الخاطئة، التي تؤثّر سلباً على تبني التقدير الزمني الرشيق لدى شركات تطوير البرمجيات.
حالات تؤثّر سلباً على التقدير الزمني الرشيق
1- تمديد السبرنت
إذا تمّ تمديد السبرنت كيف ستحتسب سرعة الفريق؟ إنّ سرعة الفريق مبنيّة على ما ينجزه الفريق في وحدة قياس زمنيّة ثابتة ألا وهي السبرنت.
فإذا استغرق السبرنت في المرة الأولى أسبوعاً واحداً، وفي المرّة الثانية أسبوعين اثنين، فلن نستطيع حساب سرعة الفريق. ولن يتمكن الفريق من الوصول لتواتر ثابت ومستقر.
عند الضرورة، من الأفضل العودة إلى تقييم الزمن بالساعة، إذا افترضت أنّه لن يُحدث تقاطعاً مع مهمة أخرى. وعلى الرغم من عدم دقّة هذا الأسلوب مطلقاً، إلّا أنّه أفضل من تمديد السبرنت وتخريب آلية احتساب نقاط story point، فتمديد السبرنت خط أحمر يجب ألاّ يحدث مهما كانت الظروف.
زمن السبرنت يُحدّد من خلال عدّة شروط منها مدى تواصل الزبون معنا، لكن كلّما قلّ زمن السبرنت فذلك أفضل لتحقيق تقدير وتسارع أكثر رشاقة
فراس طالب
2- عدم استقرار الفريق
إنّ عدم استقرار الفريق سيؤثّر حتماً على الإنجاز، وسيحدث تذبذب في سرعة الفريق بين سبرنت وأخرى.
لكن يجب ألّا يؤثّر على التقدير. منطقيّاً، شخص حضر التقدير الجماعي، وكان يفترض أنه سيسهم بإنجاز user story معيّنة، لكن للأسف تمّ سحبه لمشروع آخر، وبالتالي هذه الـ user story لن تكتمل وسوف تتأخر، أما حجمها فسيظلّ ذاته.
لذلك واحدة من إيجابيات الانتقال إلى أسلوب التقدير الزمني الرشيق المعتمد على وحدة قياس نسبية (الـ story point) أنّك تقيّم حجم العمل بحدّ ذاته، من دون ربط تقدير هذا الحجم بشخص معيّن.
إنّ ارتباط التقييم بالفريق لأمر رائع، وهو أدقّ بكثير من ربط قصة مستخدم user story بشخص يقوم على إنجازها، أو الشخصين اللذين سينجزانها!
ما لم تكن التغيّرات شديدة؛ فإن عدم استقرار الفريق سيؤثّر على التقدير بنسبة بسيطة نوعاً ما، لكنّه يؤثّر على الإنجاز أكثر
فراس طالب
وعدم التفرّغ للمشروع، يؤثّر على الإنجاز، على الإنتاجيّة، وليس بالضرورة أن يؤثر بشكل كبير على تقدير حجم العمل.
3- حالة التقدير بالمناقصة | إصابة التقدير الزمني الرشيق في مقتل!
واحدة من الحالات الخاطئة، أن يستخدم الفريق story point ولكن بإجراء مناقصة يتم فيها انتقاء الشخص الذي يقدم التقدير الأقل، لترسو عليه مهمة تنفيذ user story معينة.
في هذه الحالة، الشخص المتباهي، أو الشخص الجريء، سيقدم تقديراً أقل ليحصل على الـ story point التي يريدها.
أما الشخص الذي لا يرغب بالعمل على هذه الـ user story، فليس عليه سوى أن يبالغ في التقدير لحجم الـ story point كي لا يتم اختياره للتنفيذ..
هذه الطريقة ليست طريقة جيدة وتثير تنافسية سلبية أقرب إلى النفاق، بدلاً من أن تحفز على التعاون، وجلسة التقدير الجماعي ينبغي ألّا يجري التعامل معها على أنّها مناقصة..
فضلاً عن أن قصة المستخدم سيعمل عليها عادة أكثر من فرد واحد.
ليست الغلبة للشخص الذي يعطي story point أقل، هذا السلوك قد يتوافق أحياناً مع مزاج بعض المدراء، لرغبتهم بإنجاز العمل بسرعة، حيث يجري التغافل عن تقدير حجم العمل الحقيقي، لصالح الحصول على تقدير زمني أقل وإن كان غير واقعي.
4- التقدير الرشيق ضرب من المثالية والخيال!
إذا كنت قد تابعت هذه السلسلة كاملة من مقالاتنا عن تقدير زمن التسليم في المنتجات الرقمية، فأنت أكثر شخص يدرك أن الادعاء السابق محض خرافة!
التقدير الرشيق، مطبّق بشكل صارم وناجح ضمن كبرى الشركات التقنية العالمية، لكنَّ شروطه صعبة وغير متيسرة لكل فريق؛ لذا نجد كثيراً من شركات تطوير البرمجيات في منطقتنا، قد أحجمت عن التقدير النسبي وعن استخدام الـstory point .
الخطأ بالممارسات التي تجري داخل الفريق، وقد ذكرنا عدداً من هذه الممارسات السلبية عند استعراض أساليب تقدير الوقت في المنتجات الرقمية.
التقدير الرشيق ليس أمراً نظرياً على الإطلاق، بل هو تقدير علمي
التقدير الرشيق ليس أمراً نظرياً على الإطلاق، بل هو تقدير علمي ومطبّق بنجاح في كثير من الشركات البرمجية الرائدة، لكن الشروط الملائمة لتطبيقه ينبغي أن تتوفّر، وبيئة العمل المناسبة لاحتضانه يجب أن تتوفّر
فراس طالب
نعم، شروط التقدير الرشيق ليست سهلة، لكنها ممكنة بوجود تعاون بين الأفراد، فإن لم يتوفر التعاون الحقيقي فيما بينهم، فستتحول جلسة التقدير الجماعي إلى مجرد جدال عقيم، أكثر من كونه اتفاقاً هدفه الوصول إلى تقدير صحيح لكل مهمة، عبر قيمة رقمية تمثل حجم العمل، ويجري التوافق عليها من قبل جميع أعضاء جلسة التقييم.
مشكلة تطوير البرمجيات مشكلة كبيرة وشريرة! لذا فهي تحتاج إلى وجود عقليّة صحيحة أوّلاً، ثمّ مهارات سليمة، وأخيراً أدوات صحيحة..
وكما لاحظتم لم نتطرّق إلى الأدوات كثيراً، فآلية التقدير عادةً لها برنامج سوفت وير بسيط وسهل، ومتاح لمعظم الفرق.
التقدير الرشيق ليس مجرد مبادئ نظرية؛ ثمّة عملاء يجري الاتفاق معهم كل يوم بطريقة أجايل Agile، وليس بطريقة تحديد الزمن اللازم بالساعات
فراس طالب
خلاصة القول..
التقدير يجب ألّا يكون فردياً، ولا جماعياً سلبياً، وربط النقاط بكفاءة الفرد أمر خاطئ وغير منطقي..
أما سرعة الفريق Velocity Team فينبغي قياسها بصبر وأناة بعد عدة دورات عمل، بناء على مقارنة قصص المستخدم ضمن المشروع ذاته؛ وبهذا يتحسن تقدير الزمن كلما قطعنا شوطاً في تنفيذ المشروع، بحسب مفهوم مخروط عدم اليقين (Cone of Uncertainty)