مررنا بمثال عملي مفصل عن أفضل ممارسات تقدير الوقت في المنتجات الرقمية، وفي هذا المقال نتناول موضوعاً لا يقل أهمية وهو كيفية قياس سرعة الفريق في التقدير الرشيق Team Velocity.
فبعد أن حددنا وحدة لقياس حجم العمل في المشاريع الرقمية، عبر نقاط القصةStory Points، سنتعرف اليوم كيف ينعكس تقدير الحجم على سرعة الفريق، وبالتالي على تقدير زمن التسليم للمنتجات الرقمية، بناء على قصص المستخدم User Stories، ومقارنتها بمثيلاتها ضمن مشروع واحد.
ما هي سرعة الفريق Team Velocity في التقدير الرشيق ؟
حتى نبقى في السياق ذاته، سنتابع مثالنا العملي الذي بدأناه في المقال السابق عن التقدير الرشيق، وكنا قد وصلنا فيه إلى تقسيم قصة المستخدم الكبرى، إلى قصص أصغر، وصوّت فريق العمل على كل قصة منها على حدة لتقدير حجمها.
وخلاصة جولات التصويت الجديدة هذه، أن الفريق قد احتسب مع مالك المنتج Product Owner ما مجموعه تقريباً 110 نقاط story point يفترض أن يجري تنفيذها خلال دورة العمل الأولى sprint.
شرع الفريق بالعمل، وفي نهاية دورة العمل الأولى الـ sprint، اتضح أنّ ما تم إنجازه على أرض الواقع هو مئة نقطة story point فقط، وقد استغرقت هذه الدورة مدة أسبوعين.
وهذا معناه أن الفريق قد نجح بإنجاز 100 نقطة story point، خلال دورة عمل واحدة.
الحقيقة أن هذا لا يعدّ مؤشّراً دقيقاً ولا كافياً لاستنتاج مدّة انتهاء عمل الفريق على المشروع كاملاً، لأنّه من الممكن حصول تذبذب في حجم الإنجاز، فقد ينهي الفريق في دورة العمل القادمة (السبرنت) حوالي 120 نقطة story point، ومن الممكن أن ينهي 180 نقطة، لا يوجد ضمان حتمي بذلك.
لكن على الأقل أصبح لدينا الآن تقدير مبدئي لسرعة الفريق.
آيس كريم دورات العمل
ما سبق يسمّى عادة: Cone of Uncertainty أو مخروط عدم التيقن في دورات العمل!
ويعني باختصار: المخروط الذي تكون بدايته واسعة ويضيق في نهايته مع تقدّم المشروع، أي أنّه كلّما تقدمنا في المشروع أكثر، غدونا قادرين على احتساب سرعة الفريق بدقة أكثر.
وضمن هذا المخروط الذي يضيق كلما مضينا قدماً في إنجاز دورات عمل أكثر في المشروع؛ يمكن أن تتراوح درجة عدم التيقن من سرعة الفريق ضمن نطاق محدود، يقل التذبذب فيه كلما تم إنهاء دورة عمل جديدة في المشروع، أي نصبح أكثر تيقناً من دقة تقديرنا لسرعة الفريق بحسب دورات العمل المنجزة كما يلي:
بعد دورة العمل الأولى first sprint بين 0.6 و 1.6
بعد دورة العمل الثانية second sprint بين 0.8 و 1.25
بعد دورة العمل الثالثة third sprint بين 0.85 و 1.15
وفي هذا المثال، لدينا فريق بلغت سرعته المبدئية 100 نقطة/ السبرنت، وذلك بعد مقارنة حجم الـ story points ضمن المشروع ذاته فقط.
هل تصحّ العمليات الرياضية لقياس سرعة الفريق؟
مالك المنتج (Product Owner) لا زال يعمل مع الزبون يوميّاً، من خلال اجتماعات دورات العمل المتتالية (الـ sprints)، ولا يزال يجمع user stories أكثر، ولا زال يعود للفريق بشكل متكرر لعقد جلسات التصويت الدوريّة.
وفي مرحلة معينة، وصل عدد المهام المعلقة المتفق عليها ضمن قائمة عمل المنتج Product Backlog إلى 700 نقطة؛ وبفرض أنّ سرعة الفريق ضمن دورة العمل الواحدة 1sprint تساوي = 100 نقطة، فبوسعنا الآن إجراء عمليّة قسمة بسيطة: 700 ÷ 100 والنتيجة ستكون 7 دورات عمل، لإنهاء المطلوب كاملاً ضمن Product Backlog. لكن هل هذا الكلام دقيق تماماً؟
عوامل تؤثر في دقة القياس لسرعة الفريق
إن قياس سرعة الفريق تعتمد على تفاصيل كثيرة:
- أوّلها – أن يقوم الفريق بممارسة آليات التقدير بشكل صحيح.
- ثانياً – ألَّا يتم اعتماد سرعة الفريق بأنّها 100 نقطة/ السبرنت مثلاً، إلّا بعد إكمال أكثر من دورة عمل أو أكثر من sprint واحد.
كفاءة الفرد قبالة سرعة الفريق
نصيحة خاصة لك عزيزي المطور: عند تقييمك لقصة مستخدم User Story، لا تفترض وجود قيمة زمنية مثل 10 ساعات للنقطة الواحدة Story Point هذا خطأ!
بل ينبغي لك أن تأخذ بالحسبان فهمك لقصة user story وحجمها، بالمقارنة مع قصة user story أخرى ضمن المشروع نفسه..
إن ربط الوقت بوحدة القياس النسبية (Story Point) يتم بأثر رجعي، بناء على معرفة سرعة الفريق بدقة، عندها يمكننا القول: إنّ 100 نقطة story point تنتهي خلال أسبوعين، وهي دورة العمل.
الـ Story point ليس لها علاقة بقدرات الفرد الواحد مطلقاً، رابطها مع الفريق ككل، فهي تقدير لحجم عمل ينفذه الفريق بشكل متكامل.
فراس طالب
لذا، لا يمكن معرفة كفاءة الشخص وإنتاجيته من عدد الـ story point التي قام بها وحده.
في المقال القادم سنتناول حالات سلبية تؤثر على التقدير الزمني الرشيق؛ فانتظرونا.