17 مقياسًا لهندسة البرمجيات وكيفية تتبعها

لتوجيه فرق هندسة البرمجيات في الاتجاه الصحيح، من الضروري أن يكون لديك المقاييس الصحيحة التي توضح لك أين كنت، وأين أنت اليوم، وأين تريد أن تكون غدًا.

من المحتمل أن فريقك التنفيذي لا يتحدث في سطور من التعليمات البرمجية أو نقاط القصة. وبدلاً من ذلك، يريدون بيانات تحكي قصة.

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

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

ما هي مقاييس هندسة البرمجيات؟

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

في حين أن الفرق قد تحاول “التلاعب” بالمقاييس في مؤسستهم، فإن هذا سيؤدي في النهاية إلى الإضرار بفريقك على المدى الطويل. يجب استخدام مقاييس هندسة البرمجيات كإشارات موضوعية لتحقيق نتائج أفضل لمؤسستك.

من المهم ملاحظة الفرق بين مقاييس هندسة البرمجيات ومقاييس مراقبة التطبيقات والأداء (APM). تعمل مقاييس APM (مثل مدة تشغيل موقع الويب) على تتبع الأداء الفعلي لأحد البرامج أو التطبيقات.

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

لماذا المقاييس التي نراها في جيرا ليست كافية؟

على الرغم من أن مقاييس Jira توفر أساسًا متينًا لتتبع مقاييس Agile الأساسية، إلا أنها لا تشمل جميع جوانب دورة حياة تطوير البرامج.

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

تقوم أدوات مثل Pluralsight Flow بدمج مقاييس هندسة البرمجيات المختلفة لتوفر لك نظرة عميقة على الاتجاهات التاريخية وصحة الفريق والتعاون لمساعدتك في تحديد الاختناقات في عمليتك.

أنواع مقاييس هندسة البرمجيات

هناك عدد من أنواع مقاييس هندسة البرمجيات التي يجب التركيز عليها كفريق واحد. في قلب هذه المقاييس، تريد إلقاء نظرة على مدى نجاح فريقك في تحقيق الأهداف وتطوير التعليمات البرمجية الإنتاجية.

تقع مقاييس هندسة البرمجيات ضمن مجموعات قليلة مميزة وتحدد جوانب معينة من دورة حياة تطوير البرمجيات:

القدرة على التنبؤ: المقاييس الموجودة ضمن هذه الفئة تجيب على الأسئلة “هل نتحرك بسرعة كافية؟” و”هل لدينا وتيرة ثابتة وفعالة؟” إن فهم هذه المقاييس يمكّن القادة من تقدير النتائج والجداول الزمنية وعائد الاستثمار بشكل أكثر توقعًا.
النشاط: يمكن لهذه المقاييس – عند استخدامها بشكل صحيح – أن توضح كيف أن أوجه القصور التنظيمية تعيق إنجاز العمل.
الثقافة: تجيب مقاييس الثقافة على السؤال التالي: “هل نقوم بغرس ثقافة تعاونية في عملية تطوير البرمجيات لدينا؟” تعد مقاييس طلب السحب أمرًا أساسيًا لمعرفة مدى تعاون فريقك أثناء عملية مراجعة التعليمات البرمجية.
الكفاءة: تعمل هذه المقاييس على تقييم مدى كفاءة فريقك، وما إذا كانت هناك عمليات أو حواجز تضر بفريقك، وما إذا كان المطورون يأخذون تعليقات من طلبات السحب الخاصة بهم ويكررونها.
الموثوقية: تعمل مقاييس الموثوقية كنوع من متغيرات التحكم لمساعدة الفرق على فهم ما إذا كانوا يضحون بالجودة من أجل السرعة.

مقاييس الترميز

تسمح مقاييس الترميز للمطورين بتتبع وقياس جودة التعليمات البرمجية التي يقومون بإنشائها. يوفر تتبع هذه البيانات التاريخية الرؤى التي تحتاجها الفرق لتحسين موثوقية التعليمات البرمجية وإمكانية صيانتها.

1. المهلة الزمنية للتغييرات

يقيس المهلة الزمنية للتغييرات الوقت الذي يستغرقه الالتزام بالتعليمات البرمجية عند نشرها. يقيس هذا المقياس المدة التي يستغرقها إنشاء القيمة وتقديمها للمستخدم.

يمكن أن تشير المهلة الزمنية العالية لإجراء التغييرات إلى وجود اختناقات في عملية تطوير البرامج لديك.

تُظهر المهلة الزمنية المنخفضة للتغييرات أن فريقك يتسم بالكفاءة في الاستجابة للتغييرات، سواء كان ذلك من خلال الاستجابة للملاحظات، أو إصلاح خطأ ما، أو تطوير ميزة جديدة، أو الحفاظ على قاعدة التعليمات البرمجية الخاصة بك.

2. تردد النشر

يقيس تكرار النشر عدد مرات نشر التعليمات البرمجية بنجاح في الإنتاج. يقيس هذا المقياس سرعة الفريق وخفة حركته.

تشير الفرق التي يتم نشرها بشكل متكرر (على سبيل المثال عدة مرات في اليوم أو مرة واحدة في الأسبوع) إلى فرق النخبة أو الفرق ذات الأداء القوي.

إذا كان فريقك يقوم بالنشر بشكل أقل تكرارًا (مثلاً مرة واحدة كل بضعة أسابيع)، فقد تكون هذه إشارة لتقليل حجم النشر الخاص بك بحيث يكون من الأسهل المراجعة والاختبار والنشر.

3. إعادة العمل

إعادة العمل هي التعليمات البرمجية التي تتم إعادة كتابتها أو حذفها خلال ثلاثة أسابيع من إنشائها.

في حين أنه من المتوقع إجراء بعض عمليات إعادة العمل، إلا أن الزيادة في عمليات إعادة العمل يمكن أن تشير إلى أن المهندس يواجه صعوبة في المشروع أو أن متطلبات المشروع غير واضحة.

بالنسبة للمهندسين الكبار، يتراوح معدل إعادة العمل النموذجي بين 20 إلى 30%.

4. التأثير

يقيس التأثير حجم التغييرات في قاعدة التعليمات البرمجية. يعد هذا المقياس مقياسًا تقريبيًا للحمل المعرفي الذي يحمله المهندس عند تنفيذ تغييرات التعليمات البرمجية.

يعد التأثير مقياسًا توضيحيًا جيدًا – إذا انخفضت الكفاءة أو أيام البرمجة، فهل كان ذلك بسبب العمل بدرجة تعقيد أعلى من المتوسط؟

يأخذ التأثير في الاعتبار:

مقدار الكود في التغيير
ما هي النسبة المئوية للعمل الذي يعد تعديلات على الكود القديم
عدد مواقع التحرير
عدد الملفات المتأثرة
مدى خطورة التغييرات عند تعديل الكود القديم
كيف يقارن هذا التغيير بالتغييرات الأخرى من تاريخ المشروع

5. إعادة البناء القديمة

يقوم عامل إعادة البناء القديم بقياس التحديثات والتعديلات على التعليمات البرمجية التي مضى عليها أكثر من ثلاثة أسابيع. يساعدك تتبع هذا المقياس على فهم مقدار الوقت الذي تقضيه في سداد الديون الفنية بشكل أفضل.

6. عمل جديد

العمل الجديد هو رمز جديد تمامًا لا يحل محل أو يصلح رمزًا آخر. يعرض هذا المقياس مقدار التعليمات البرمجية التي يكتبها الفريق أو الفرد للمنتجات والميزات الجديدة.

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

7. ارتكاب التعقيد

يقيس تعقيد الالتزام مدى احتمالية أن يتسبب التزام معين في حدوث مشكلات. يتضمن هذا الحساب المتري مدى حجم الالتزام، وعدد الملفات التي تمسها، ومدى تركيز التعديلات. ينظر تعقيد الالتزام بشكل أساسي إلى المخاطر المرتبطة بالالتزام.

يعد تعقيد الالتزام مقياسًا مهمًا يجب تتبعه لأنه يمكن أن يساعد الفرق على تحديد أولويات الالتزامات التي يجب مراجعتها أولاً – وأي الالتزامات ستتطلب وقتًا واهتمامًا إضافيين.

المقاييس التعاونية

تمنح مقاييس تعاون الفريق المديرين معلومات مهمة حول كيفية استجابة الفرق لعملية مراجعة التعليمات البرمجية.

توفر هذه المقاييس نظرة ثاقبة للتعاون الشامل وثقافة الفريق، بالإضافة إلى الاختناقات التي تؤثر على النشر.

8. الاستجابة

الاستجابة هي مقياس للمدة التي يستغرقها المرسل للرد على تعليق على طلب السحب الخاص به بتعليق آخر أو مراجعة التعليمات البرمجية.

يمنح هذا المقياس الفرق نظرة ثاقبة حول ما إذا كان أعضاء الفريق يستجيبون لملاحظات مراجعة التعليمات البرمجية في الوقت المناسب.

ويضمن خفض هذا المقياس مراجعة طلبات السحب ودمجها في إطار زمني مناسب. بالنسبة للسياق، فإن معيار الصناعة للمساهمين الرئيسيين هو 1.5 ساعة وست ساعات للمساهمين النموذجيين.

9. العلاقات العامة غير المراجعة

إن العلاقات العامة التي لم تتم مراجعتها هي النسبة المئوية لطلبات السحب دون تعليقات أو موافقات. يوضح لك هذا المقياس عدد طلبات السحب التي تم دمجها دون مراجعتها.

عادة ما يكون للمساهمين الرئيسيين 5% من العلاقات العامة غير المراجعة، والمساهمون النموذجيون لديهم 20% من العلاقات العامة غير المراجعة.

10. وقت تكرار العلاقات العامة

وقت تكرار العلاقات العامة هو متوسط الوقت بالساعات بين التعليق الأول والأخير على طلب السحب. يمنحك هذا المقياس نظرة ثاقبة حول المدة التي يستغرقها تنفيذ التغييرات المطلوبة على العلاقات العامة.

يمكن أن يشير وقت التكرار المرتفع إلى أن طلب السحب الأولي كان به متطلبات سيئة أو غير محاذية أو أن التغييرات التي طلبها المراجع كانت تستغرق وقتًا طويلاً وخارج النطاق.

11. العلاقات العامة المتكررة

تمثل PRs المتكررة النسبة المئوية لطلبات السحب مع التزام متابعة واحد على الأقل. يتيح لك هذا المقياس البسيط معرفة عدد طلبات السحب التي تتطلب عملاً إضافيًا قبل دمجها.

12. وقت رد الفعل

وقت رد الفعل هو الوقت الذي يستغرقه المراجع لمراجعة طلب السحب والرد على التعليق. يساعد هذا المقياس في الإجابة على السؤال: هل يستجيب المراجعون لطلبات السحب في الوقت المناسب؟

الهدف هو خفض هذا الرقم، حيث يشير وقت رد الفعل الأقل إلى تعاون أفضل بين المرسل والمراجع. وقت رد الفعل النموذجي للمساهم الرئيسي هو ست ساعات، و18 ساعة للمساهم النموذجي.

13. تمت مراجعة العلاقات العامة بدقة

إن PRS التي تمت مراجعتها بدقة هي النسبة المئوية لطلبات السحب المدمجة مع تعليق منتظم أو قوي واحد على الأقل. يهدف هذا المقياس إلى ضمان مراجعة طلبات السحب بدقة.

يمكن أن يكون عدد كبير جدًا من طلبات السحب دون مراجعات شاملة علامة على الختم المطاطي أثناء عملية مراجعة التعليمات البرمجية.

على الجانب الآخر، تشير النسبة المئوية العالية للعلاقات العامة التي تمت مراجعتها بدقة إلى جودة مراجعة الكود القوية والتعاون الصحي بين الفريق.

14. حان الوقت للاندماج

الوقت اللازم للدمج هو متوسط الوقت بالساعات منذ إنشاء طلبات السحب وحتى وقت دمجها. يخبرك هذا المقياس بالمدة التي تستغرقها طلبات السحب قيد المراجعة.

يمكن أن تكون طلبات السحب طويلة الأمد مكلفة لشركتك وتؤدي إلى تأخير الإصدارات.

15. حان الوقت للتعليق الأول

الوقت اللازم للتعليق الأول هو متوسط الوقت بالساعات منذ إنشاء طلبات السحب حتى تلقي أول تعليق لها. يساعد تقليل هذا المقياس على تقليل الهدر ووقت الدورة وتبديل السياق.

16. التزامات المتابعة

تقيس عمليات المتابعة عدد مراجعات التعليمات البرمجية المضافة إلى طلب السحب بعد فتحه للمراجعة. يمنحك تتبع هذا المقياس نظرة ثاقبة على جودة عملية مراجعة التعليمات البرمجية الخاصة بك.

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

17. فهرس المشاركة

يقيس فهرس المشاركة كيفية مشاركة المعلومات عبر الفريق من خلال النظر فيمن يقوم بمراجعة طلبات السحب الخاصة به.

يمكن أن يساعدك تتبع فهرس المشاركة في فهم عدد الأشخاص المشاركين بانتظام في مراجعات التعليمات البرمجية.

يعد هذا المقياس طريقة رائعة لقياس مدى مشاركة كبار الأعضاء للمعرفة مع المزيد من المطورين المبتدئين وتحديد المواقف التي تحدث فيها صوامع المعرفة.

فوائد تتبع مقاييس هندسة البرمجيات

يجب أن يكون الهدف من تتبع هذه المقاييس هو تحسين العمليات والجودة والتعاون عبر فريقك. تشمل فوائد تتبع مقاييس هندسة البرمجيات ما يلي:

زيادة فهم كيفية إنجاز العمل
تحديد المشاكل/الاختناقات
إدارة أعباء العمل والموارد
استخلاص استنتاجات موضوعية للمساعدة في اتخاذ القرار وتحديد الأهداف

بالطبع، لا يكفي مجرد تتبع مقاييس هندسة البرمجيات. يجب عليك أيضًا أن تعتاد على الإبلاغ عن هذه المقاييس ومراجعتها بشكل منتظم لتتبع النمو بمرور الوقت.

كيفية مواءمة مقاييس هندسة البرمجيات مع أهدافك التنظيمية

مع وجود العديد من المقاييس التي يجب تتبعها، قد يكون من المفيد الرجوع خطوة إلى الوراء والنظر في أهدافك التنظيمية أثناء تحديد المقاييس التي تريد تحديد أولوياتها.

إحدى الطرق للقيام بذلك هي باستخدام طريقة الهدف/السؤال/المقياس. وتنقسم هذه الطريقة إلى ثلاثة مستويات:

الأهداف (المستوى المفاهيمي): ابدأ بتحديد الأهداف التي تحاول تحقيقها.
الأسئلة (المستوى التشغيلي): اطرح أسئلة توضيحية تحاول الإجابة عليها باستخدام البيانات التي تجمعها.
المقاييس (المستوى الكمي): قم بتعيين مجموعة من المقاييس لكل سؤال للإجابة عليه بطريقة قابلة للقياس.

يمكن استخدام الهدف/السؤال/المقياس لمجموعة متنوعة من النتائج. قد ترغب في استخدام الطريقة لتحسين الجودة الفنية أو جودة المنتج أو صحة فريق التسليم.

سيساعدك استخدام الهدف/السؤال/المقياس في النهاية على تحديد أهداف عملك وتوضيحها، وإنشاء مقاييس تساعدك على تتبع وقياس التقدم نحو هذه الأهداف.