مثال عملي لتطبيق التقدير الرشيق

التقدير الرشيق لزمن التسليم في المنتجات الرقمية هو موضوع مقالنا هذا، وكنا – ضمن مقالاتنا السابقة – قد استعرضنا بالتفصيل طرقاً متعددة للتقدير الزمني..

فعرفنا سُبُل الاستفادة من كلّ واحد منها، بدءاً بمحاكمة الخبراء، فالتقدير الجماعي، والتقدير النسبي، والتقدير بالمقارنة..

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

لماذا يصعبُ تقدير زمن دقيق للتسليم في المنتجات الرقمية ؟

بعد كل ما سبق، نرجع اليوم للسؤال الأول: لمَ يصعب الحصول على تقدير زمني دقيق قبيل تنفيذ مشاريع المنتجات الرقميّة؟

بدهيات قبل الدخول في التقدير الرشيق!

في موضوع تقدير زمن تسليم المنتجات الرقمية، لنتفق على ما يلي بدايةً:

• طبيعة المشاريع الرقميّة أشبه بإجراء بحث علمي جديد كل مرة!
• عملية تطوير البرمجيات تنطوي على درجة كبرى من عدم اليقين.
• التغيّرات كثيرة في مراحل تنفيذ المنتج الرقمي.

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

فراس طالب

المشكلة الشريرة عند محاولة تقدير الوقت في المنتجات الرقمية

كلّما كتبنا شيفرة برمجيّة جديدة، فهذا يعني بالضرورة أنّنا نكتبها للمرّة الأولى، لذا فهي أشبه بالبحث العلمي الذي يَنشد الوصول إلى نتيجة جديدة.

ولذلك أيضاً من المستحيل الوصول إلى تقدير زمن دقيق، لاسيما في مراحل البدايات..

يطلق عادة على هذا النوع من التحديات المشكلة الشريرة (Wicked Problem) وهي مشكلة لايمكن معرفة حلّها قبل القيام بمحاولة حلّها فعلياً

وكذلك الأمر في عملية تطوير البرمجيات؛ لا يمكن التنبؤ بالزمن اللازم لإنجاز مشروع ما، قبل البدء بتنفيذه فعلياً!

من جديد إذن.. ما هو أسلوب التقدير الصالح للمنتجات الرقمية ؟؟؟

• هل يعني ما سبق أنّ الوسيلة الوحيدة للتقدير الزمني في بداية أي مشروع رقمي هي تقييم الخبراء التقريبي؟
• هل يعني ذلك أنّ تِلْكُم هي طبيعة المشاريع الرقمية، ويجب علينا أن نقلع عن محاولة التقدير الدقيق للوقت، لاستحالته أصلاً؟

الجواب بالطبع: لا..

فأسلوب التقدير الذي نحتاجه يجب أن يتسلسل كالتالي:

1. سنبدأ بتطوير جزء من المنتج الرقمي خلال وقت محدد هو دورة العمل، وتسمى اصطلاحاً: سبرنت Sprint.
2. سيتم اعتماد هذا الجزء كنقطة بداية Baseline لكي يقارن أفراد الفريق -بشكل جماعي- حجم المهمات التي تمّ إنجازها، مع مهامَّ جديدة لم يبدأ بها الفريق بعد..
3. وفي هذه المرحلة، سيكون للأفراد الخبراء ضمن الفريق، دور جوهريّ في ضمان دقّة المقارنة، حيث سيقوم أفراد الفريق بتقييم حجم العمل بشكل نسبي وباستخدام وحدة قياس نسبية هي Story Point.

مثال عمليّ على التقدير الرشيق

نحن أمام مشروع رقمي جديد، وقد شرع مالك المنتج (Product Owner) بكتابة ما يتوقع أن يواجهه أو يحتاجه المستخدم، أو ما يسمى اصطلاحاً بـ: قصص المستخدم User stories يفيدنا بها مالك المنتج Product Owner بكل ما يمتلكه من وضوح في الرؤية خلال تلك اللحظة.

مالك المنتج يحكي لنا قصة المستخدم الودود!

لنبدأ بأول سيناريو متوقع من سيناريوهات المستخدم وقصصه؛ يعني الـ User stories التقليديّة الشهيرة:

أنا مستخدم ، وأودّ تسجيل الدخول إلى التطبيق أو النظام

As a user, I want to login to the system

جلسة التقدير الرشيق | اجتماع مهم!

سيعقد أفراد الفريق اجتماعاً طارئاً على مستوى القمة، أو ما يعرف بمسمى: جلسة تقدير جماعي؛ يهدفون من خلالها أولاً إلى تقدير حجم العمل المطلوب، وليس مدة تسليمه.

1. بداية يجب على الأشخاص ألّا يقوموا بالتصويت تِباعاً، وإنما يحقّ لكل شخص أن يسأل مالك المنتج Product Owner أسئلة معيّنة حول قصّة المستخدم المقدّمة أعلاه؛ بهدف الاستيضاح أكثر.
2. مالك المنتج Product Owner سيقدم إجابات على جميع الاستفسارات الواردة، وعندما تصل الأمور إلى الدرجة المطلوبة من الوضوح، سيصوّت أعضاء الفريق بشكل سرّي على حجم العمل المتوقع.
3. كل شخص سيضمر التقدير الخاص به لحجم العمل المطلوب، ولن يعلنه لأيّ طرف آخر، وبعد انتهاء التصويت، سيقوم مدير الجلسة بإظهار التقييمات المختلفة دفعة واحدة أمام الجميع

التقدير الرشيق مبني على الحوار

نحن الآن إزاء كشف المستور، ومعرفة آراء أفراد الفريق المتباينة، فكل فرد منهم قد افترض تقييماً مختلفاً عن الآخر:

• الشخص الأوّل وضع إشارة استفهام وتعني أنّه لم يستطع تقييم حجم العمل المطلوب لإنجاز قصة المستخدم User Story.
• الشخص الثاني وضع رقم 1 وهو -للتأكيد- حجم العمل وليس الزمن اللازم لإنجاز قصة المستخدم User Story هذه.
• الثالث وضع 5، وأوضح بشكل منطقي لمَ وضع هذا التقييم الكبير بالمقارنة مع تقييم زميله السابق (قليل الخبرة نسبياً) الذي وضع 1، حيث شرع صاحب
• الـ 5 بسرد أسبابٍ منطقية تضيء للحاضرين على جوانب مهمة لم يأخذوها في الحسبان عند تقييم حجم هذه القصة User Story.
• أفراد آخرون من الفريق، متفاوتو الخبرة والوظائف، وينظرون للأمر من زوايا ووجهات نظر متعددة، وضعوا أرقاماً مختلفة لتقدير حجم العمل اللازم لقصة المستخدم User Story هذه.
• لكن أحد المخضرمين وضع فنجاناً من القهوة، دلالة على أنّه متعب من هذه الجلسة التي استغرقت مدة نصف ساعة أو ربما أكثر من ساعة، ويطلب أخذ استراحة للرّاحة

يُفضّل ألّا تكون جلسة التقدير طويلة، ويُفضّل أن يجري عقد جلسات متعددة لجميع أفراد الفريق بإدارة مالك المنتج

• ربما تجد شخصاً ألمعياً قد وضع علامة صفر، ويقصد بها أنّ قصة المستخدم هذه شبه مُنجزة وجاهزة؛ لكننا سنستبعد هذه القيمة لأنّنا نتكلم عن مشروع جديد افتراضاً، ويقوم به الفريق لأول مرة. علماً أن قيمة الصفر قد تعني منطقياً أن حجم العمل صغير جداً لدرجة أنه أقل من 1.

حوار يبدأ مع صاحبي أعلى وأدنى تقييم

الآن أمامنا قيم مختلفة، ومدير الجلسة سيسأل صاحب أقل قيمة وصاحب أعلى قيمة، لأنّ القيم إذا كانت متباينة إلى هذا الحد، فذلك مؤشر على أنّ الأشخاص لا يتحدثون عن الأمر نفسه، أو أنّه ليس كل الأشخاص لديهم الفهم العميق بالدرجة ذاتها لهذه المشكلة!

– وبالتالي سيُسأل الشخص الذي أجاب بـ 1 عن تفسير لوجهة نظره: لِمَ وضعت نقطة واحدة؟

– سيجيبنا ببساطة: إنّ الأمر بسيط تقنياً، يجري تقسيمه بيني وبين زملائي وانتهى الأمر.

– حسناً شكراً لك.

– بالنسبة للشخص الذي أجاب بـ 20 سنسأله: لماذا قمت بوضع هذا التقييم؟

يبدو أنّه يمتلك خبرة جيدة، لذا وبناء على فهمه العميق للمشروع، فقد وضع العلامة 20، ثمّ أجاب بأنّه توقّع أن قصة المستخدم هذه التي يجري التصويت عليها، تحوي تفاصيل كثيرة ربما لم تخطر على بال مالك المنتج Product Owner؛ وبعد شرح تصوّره لكافة جوانبها، أقره مالك المنتج على رأيه بالفعل.

وكنتيجة حتمية لذلك، فقد أعاد مالك المنتجProduct Owner بصياغة قصة المستخدم الـuser story بشكل أوضح لفريق المطورين، وكرّر عمليّة التصويت بالطريقة التي ذكرناها، فظهرت القيم متقاربة أكثر حول الرقم 20..

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

التقسيم هو الحل!

شخص من المصوّتين وضع علامة اللانهاية، وتدل هذه العلامة على أنّ حجم قصة المستخدم الـ user story كبير جدّاً..

وبالنقاش مع مالك المنتج صاحب الخبرة الكبيرة في إعادة صياغة المتطلبات (Refinement & Grooming)، أيّد الإجابة السابقة، وتوافق مع أفراد الفريق على تقسيم قصة المستخدم الكبيرة ذات الـ 20 نقطة..

وبالفعل، تمّ تقسيم قصة المستخدم الكبرى إلى قصص أصغر، وأصبح لدينا:

• as a user, I want to login using my gmail account
• as a user, I want to login using my Facebook account
• as a user, I want to login using my Twitter account
• as a user, I want to login using my Email account

تصويت جديد | فيسبوك في مواجهة جيميل!

بدأ الفريق عمليّة تصويت جديدة على هذه القصص الصغيرة أعلاه، وتبين لهم أنّ برمجة عملية تسجيل الدخول باستخدام حساب فيسبوك، أصعب بـ 3 مرات من برمجة عملية تسجيل الدخول باستخدام حساب بريد إلكتروني على جيميل.

أيه أنهم قارنوا بين قصة المستخدم الأولى على جيميل، وقصة المستخدم الثانية على فيسبوك، لذلك قدّروا رقماً أكبر لقصة الفيسبوك، وهذه هي الفكرة من الـ story point.

حجم العمل نسبي، والرقم 3 لوحده ليس له معنى أبداً، ولا يكتسب معناه إلاّ بالمقارنة بين قصص المستخدم المختلفة user stories ضمن المشروع نفسه

وحدة قياس جديدة في التقدير الرشيق

وجد الفريق هنا أنّ قصة تسجيل الدخول Login باستخدام حساب البريد الإلكتروني صارت قيمتها تساوي = 1 نقطة واحدة، وسنسمي هذه النقطة ستوري بوينت.

وبالمقارنة بهذه القصة الصغرى، فقد جرى قياس حجم بقية قصص المستخدم، بناء على هذه القيمة النسبية، فصارت قصة الفيسبوك كما أسلفنا تساوي = 3 ستوري بوينت.

وبالنهاية عند جمع نقاط جميع قصص المستخدم الصغيرة هذه، أصبح المجموع 12 نقطة فقط.

بينما في قصة المستخدم الكبيرة الخاصة بعملية [تسجيل الدخول إلى النظام] فقد كان التقدير لأغلب أعضاء الفريق بعد الجلسة الثانية = 20 نقطة.

إذن فقد وجد الفريق ومالك المنتج Product Owner أن هذا التقييم الجديد أكثر رشاقة، وكلما كان لدينا عدد أكبر من قصص المستخدم user stories موصوفة وفق تفاصيل مهمة، وذات حجم أصغر، وتخدم هدفاً واحداً، سنحصل على تقييم أكثر دقة باستخدام النقاط Story Point.

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

وهنا لا بدّ من التأكيد مجدّداً على أهمية الحوار الذي أدى إلى دقة ونضوج فهم المتطلبات لكل أفراد الفريق

فراس طالب

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

في المقال القادم سنتناول سرعة الفريق Team Velocity وتأثير كفاءة الفرد عليها؛ فترقبونا.