كتبت قبل بضع سنوات عن المراجعات التقنية المستقلة التي يجب أن يمر بها أي مشروع برمجي بشكل منتظم للتأكد من أنَّ كل شيء تحت السيطرة. ونوّهت مؤخرًا أنه لا يوجد عذر لعدم القيام بها. بالإضافة إلى ذلك، كلما زادت ثقتنا بالمبرمجين، زادت حاجتنا إلى مراجعة مشاريعهم بانتظام. فيما يلي ملخص بسيط لما يجب أن يتضمنه تقرير المراجع.
حاولت أن أتطرق إلى هذا الموضوع في بضعة محادثات مؤخرًا مثل: اجعل العملاء يثقون بك في BDMSummit 2017، كيف تكون صادقًا وتحافظ على العميل في PMCon Kharkiv 2017، كيفية تجنب كارثة الاستعانة بمصادر خارجية في Kyiv Outsourcing Forum 2017. وأيضًا، هناك عدد من منشورات المدونة على نفس المنوال، بما في ذلك الأخطاء السبع القاتلة لمشروع برمجيات، وكيفية تجنب كارثة الاستعانة بمصادر خارجية للبرامج، وكيف تنجو من الاستعانة بمصادر خارجية للبرامج. أخيرًا، فيما يلي قائمة كاملة تقريبًا من الأشياء التي يجب أن يتضمنها التقرير الجيد.
بشكل أساسي هي قائمة بالأسئلة التي يجب على المُراجع الإجابة عليها. عندما يتم جمع كل الإجابات، يكون التقرير جاهزًا. أهم الأسئلة تمَّ طرحها أوّلاً:
- هل إجراء الإصدار موثَّق، وآلي، وهل يعمل؟
- هل الإصدارات تتجدد بشكل منتظم، على الأقل مرة أسبوعيًا؟
- ما حجم الديون التقنية (الأشياء التي يجب إصلاحها "لاحقًا")؟
- هل خط التسليم موثوقًا بما يكفي لاستبعاد الأخطاء؟
- هل الشيفرة نظيفة؟ كم عدد النماذج المضادّة التي تظهر؟
- هل تمَّ تسجيل جميع الأخطاء والميزات كملاحظات؟
- هل تم تغطية الشيفرة الأساسية بوحدات اختبار، وهل التغطية مرئية؟
- هل تم توقيع اتفاقيات "العمل من أجل التوظيف" مع جميع المطورين؟
- هل تم توثيق القرارات التقنية الهيكلية الرئيسية؟
- هل التحليل الثابت موضع التنفيذ ومُلزَم لإجراء تغييرات جديدة؟
- هل التكاملات المستمرة موضع التنفيذ، وهل تؤخذ تقاريرها في الحسبان؟
- هل الفرع الرئيسي (master branch) للقراءة فقط؟
- هل يتم جمع المقاييس البرمجية ومراجعتها بانتظام؟
- هل مستودع الشيفرة المصدرية يخضع لملكية العميل؟
- هل متطلبات التوثيق قصيرة ومحدَّثة؟
- هل تحتوي الفئات والطرق والتوابع الرئيسية على توثيق مضمَّن في الشيفرة؟
- هل مخلفات مستودع الشيفرة المصدرية مجانية؟
- هل تم توثيق واجهات UI/UX؟
- هل سجلات الإنتاج مرئية وتتم مراجعتها بانتظام؟
- ما مدى استجابة الفريق للملاحظات؟
- هل لدى Git تاريخ واضح للتغيرات الموثَّقة؟
بشكلٍ أساسي، هذا تجميع قصير جدًا لأهم الأشياء التي يمكنك العثور عليها في CMMI. إنها تتطلب كل هذا، بالإضافة لقائمة كبيرة من الأشياء الأخرى موجودة في الأعلى. لكن المشروع الصغير لا يحتاج إلى جميع الأسئلة المذكورة. قائمتي أقصر، وأنا متأكد من أنها ستكون كافية لمعظم القرَّاء.
بكل الأحوال، يمكنك مشاهدة التقارير التي يقوم المتطوعون بإنشائها للمشاركين في جائزة جودة البرمجيات، إذ يقومون بتحليل المشاريع مفتوحة المصدر والإبلاغ بشكلٍ مختصر عن المشكلات التي يجدونها. أعتقد أنهم يحاولون الإجابة عن نفس مجموعة الأسئلة السابقة تمامًا.
ترجمة -وبتصرف- للمقال Software Project Review Checklist لصاحبه Yegor Bugayenko
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.