المقياس الصحيح لقياس التقدّم في صناعة البرمجيّات، هو البرمجيات الصالحة للاستعمال أو بعبارة أخرى نقول: الحصول على برمجيات صالحة قابلة للاستخدام، وهذا على عكس الشائع المتعارف عليه وهو اعتماد مقدار الإنجاز، كمعيار لقياس نسبة التقدم في تطوير البرمجيات.
وقد أكّدت الإدارة الرشيقة في المبدأ السابع من مبادئ أجايل على ذلك؛ حيث جاء فيه:
Working software is the primary measure of progress
البرمجيات الصالحة للاستعمال هي المقياس الرئيس للتقدم
نتعرف في هذه المادة من دليل أجايل ، على المبدأ السابع من مبادئ الأجايل الاثني عشر، ضمن سلسلة مقالات مبادئ أجايل (الإدارة الرشيقة).
ما هو المبدأ السابع من إعلان اجايل؟
يتبلور مفهوم المبدأ السابع من مبادئ اجايل عبر محورين رئيسين، هما:
1- البرمجيات الصالحة للاستعمال | مقياس بديل عن نسبة الإكمال
تكمن أهمية البرمجيات الصالحة للاستعمال في كونها معيار النجاح الفعلي للمشروع، وهي – في الغالب – ليست انعكاساً لما تم التخطيط لإنجازه.
ولأنَّ المتطلبات متغيرة ومتطورة مع تقدم العمل في كل مشروع، من غير الملائم أن نقيس تقدّم المشروع عبر طريقة تقليدية مثل مقارنة ما تم إنجازه مع ما هو مخطط.
مثال لتقريب الصورة:
في مصنع ما حيث يكون العمل تقليدياً صرفاً:
يجري قياس التقدم في المشروع من خلال مقارنة عدد المنتجات التي تم إنجازها خلال فترة ولنفرض أنها كانت 50 قطعة.
مع عدد المنتجات المخطط إنجازها في يوم واحد وليكن عند 100 قطعة مثلاً.
عندها نستطيع القول بكل ثقة إننا قد أنجزنا 50% من العمل المطلوب.
بينما في مشروع تطوير البرمجيات ستكون الخطة متبدلة ومتغيرة بشكل ديناميكي، وبالتالي:
لا يمكن قياس نجاح المشروع بناء على مطابقة ما تم إنجازه مع ما هو مخطط.
لذا سنحتاج إلى مؤشرات من نوع آخر..
2- دقّة المؤشرات التجريبيّة والمتوقّعة
تقسّم المشاريع بحسب درجة عدم التيقن، ويقاس أداؤها عن طريق نوعين رئيسين من المؤشرات، هما:
قياس نسبة الإنجاز للمشاريع المتوقّعة (Predictive Measurements)
نقيسها من خلال المؤشرات المتوقعة والمخطط لها؛ وتنقسم هذه المؤشرات إلى عدّة أنواع، منها:
- مؤشر نسبة الإنجاز: وهي نسبة العمل المنجز إلى العمل المخطط له Percentage of completion مثل حالة المصنع التي ذكرناها بالمثال السابق. حيث ينتج عدداً من القطع كل يوم. وهذا المؤشر يوضح بدقة مقدار العمل المنجز ومقدار العمل غير المنجز.
- RAG status: هو اختصار يتضح من خلال 3 ألوان لمعرفة درجات الإنجاز. فاللون الأخضر يشير إلى أنَّ المشروع يقع ضمن الحالة المتوقّعة. والأصفر يعني الاقتراب من دخولها بنسبة 10%. بينما الأحمر يدلّ على اقترابه من دخوله إليها بنسبة 15%.
يستطيع مدير المشروع أن يغير في المجالات الرقمية لهذه المؤشرات بنفسه، وذلك بحسب طبيعة المشروع.
إذ ربما تشي نسبة 10% كانزياح عن الخطة، بأمر خطير جداً لمشروع ما!
تتميّز هذه المؤشرات بدقّتها العاليّة في قياس نسبة تقدم الإنجاز في العمل، وذلك في حال كان المشروع ضمن الحالة المتوقعة (Predictive)، وجرى إنجازه مرات عديدة؛ مع عدم التعرّض لأي تغيرات مفاجئة تعيق تقدم المشروع.
مؤشرات التجارب (Empirical Measurements)
واحد من أهم هذه المؤشرات هو:
عدد الميزات التي أُنجزت بشكل مكتمل 100%
هذا المؤشر لا يقارن بين الميزات المنتهية والميزات التي ذكرت بالخطة.
لأن الخطة كما أسلفنا متغيرة ولا يمكن الاعتماد عليها كمعيار للتقدم.
نلاحظ أيضاً أنّ هذا المعيار يركز على القيمة المقدَّمة للزبون، أكثر من المسجّل ضمن الخطة فحسب! فربما يكون تسليم 3 ميزات (A, C, F) أفضل من تسليم الميزات (A, B, C, D) المسجلة بالخطة الأصلية!
- لاحظ أنه خلال العمل تم إغفال أو تأجيل تنفيذ الميزتين (B, D)
- وتم إنجاز ميزة أخرى غير مخطط لها لكنها أكثر أهمية في هذه المرحلة، وهي (F) عوضاً عنهما، هذا هو المقصد وبيت القصيد من هذا المؤشر.
وفي هذا الصدد يجدر التذكير بأنه لا جدوى أبداً من تضمين الميزات التي شارفت على الاكتمال، طالما أنها ميزات غير منجزة بالكامل، إذ ليس ثمة قيمة مقدمة للزبون عند تسليمها..
لذا نعود ونؤكد على أن الميزة التي تم إنجاز 90% منها، لا تمثّل شيئاً في مقياس تقدم المشروع، فهي غير منتهية؛ لاسيّما أنّ نسبة 10% المتبقية قد تحوي مفاجآت تقنية، وتستهلك وقتاً يعادل الوقت الذي استغرقته الـ 90% الأولى.
معايير تطبيق المبدأ السابع
يجري تطبيق هذا المبدأ من خلال مؤشرات رشيقة متعددة (Agile metrics) يجري من خلالها تقييم حالة المشروع الرقمي، منها:
Burndown Chart Sprint
يراقب هذا المعيار كمية العمل المُنجز يومياً أثناء دورة العمل، ويعكس مدى تطابق إنجاز الفريق الفعلي مع الخطة المعتمدة في بداية الدورة، ويوضّح إن كان الهدف منهاSprint goal قابلاً للتحقيق أم لا.
يُقاس هذا المعيار بالساعات أو بالـ Story Point وتعدّ
وتعد الطريقة الثانية أي التقييم النسبي (story points) أكثر دقة من سابقتها. ويُستخدم هذا المعيار من قبل المنهجيّات التي تعتمد دورة عمل زمنيّة محددة، ومن أشهرها منهجيّة سكرم scrum.
Team Velocity
سرعة الفريق هي حجم العمل الذي يستطيع أن ينجزه فريق التطوير خلال دورة عمل واحدة، ويقاس عادةً بالـ Story Pointوتكمن فائدة هذا المعيار في معرفة قدرة الفريق الفعليّة على إنجاز العمل خلال دورته المحددة، وبذلك يتم توقّع المدة الزمنية اللازمة لإنجاز ما تبقى من المشروع.
Escaped Defects (bugs in production)
يقصد بها عدد العثرات والأخطاء – التي لم تكتشف في مرحلة الاختبار – قبل ظهورها للمستخدمين النهائيين، إذ كلّما قلّ وجودها تحققت الاستفادة من البرمجيّات الصالحة للاستخدام بجودة عالية.
Code Coverage
هي إحدى المعايير الرئيسة التي تؤكد قابلية استعمال البرمجيات من عدمها، وفيها تجري كتابة كود لاختبار الكود، فمثلاً لديك كود 100 قطعة، وقمت بكتابة كود آخر لاختبار 50% منها، فالقطع المتبقية تحتاج إلى اختبار يدوي لعدم وجود تغطية لها في الاختبار المؤتمت السابق.
ثمّة عدّة آليات لكتابة الكود، أفضلها Test Driven Development (TDD)، وهي كتابة المطور لكود الاختبار جنباً إلى جنب مع الكود البرمجي الذي ينبغي تنفيذه، وهذا يعني أنّ الاختبار مسؤولية جميع أفراد الفريق، وليس قسم الجودة فحسب.
الخلاصة
إذا شبهنا المشروع بإنسان يعاني من مشاكل في الرؤية، فلن يستطيع أن يرى بعدستي نظارة صديقه الذي يعاني من مشكلة مختلفة في الرؤية، ومن هنا جاءت الحاجة الماسة لاعتماد مؤشرات رشيقة تساعد الإدارة على معرفة التقدم الحقيقي في المشروع، وهذا هو فحوى مبدأ أجايل السابع الذي يقوم على تسليم برمجيات صالحة للاستعمال فهي المقياس الملائم لتحديد نسبة التقدم الصحيحة في قطاع صناعة البرمجيات.
تفضّل بمشاركتنا رأيك عن معيار البرمجيات الصالحة للاستعمال، أو اطرح استفساراتك وتواصل معنا الآن.