كيف تقيس وتحسّن الصحة التقنية للفريق وقاعدة الأكواد؟

Question

Accepted Answer

**الصحة التقنية** هي مدى استدامة قدرة الفريق على التسليم، وجودة الكود، وموثوقية النظام، وسرعة التسليم معاً. لا يمكنك تحسين ما لا تقيسه، لكن الهدف هو *الحصول على رؤى تدفع التحسن*، وليس رقماً يجب الوصول إليه. المقاييس هي مصباح يدوي، وليست لوحة نتائج.

## ما الذي يجب قياسه

```text
DELIVERY (DORA metrics — well-researched, balanced):
  - Deployment frequency        - Lead time for changes
  - Change failure rate         - Time to restore service

QUALITY / RELIABILITY:
  - Production incident rate & severity
  - Test coverage trend (direction, not a vanity %)
  - Escaped-bug rate

TEAM / FLOW:
  - Cycle time, time-in-review (slow review = hidden bottleneck)
  - Recurring pain points (survey the team — they know)
```

## استخدم DORA بشكل متوازن

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

## مثال عملي

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

## المزلة الكبرى: التأثير السلبي

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

## لماذا يهم هذا

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

القياس الجيد يجعل غير المرئي مرئياً، بحيث يمكنك الاستثمار حيث يهم، وإثبات التأثير عند القيام بذلك.