ترتيب أولويات التقني في Salesforce: ماذا نصلح أولاً ولماذا؟

الإجابة المختصرة

إن الدين التقني لا يُقاس بجودة الكود، بل بالتكلفة التي يفرضها على أي تغيير مستقبلي. لذلك، لا يتعلق تحديد الأولويات بـ "ما هو الأكثر قبحًا" بل بما يزيد تكلفة العمل التالي.

القاعدة التي تصنف بسرعة: البند الذي يجعل كل تغيير في منطقته يتطلب فحص انحدار واسع النطاق - يأتي أولاً. إنه يضاعف تكلفة كل نشاط آخر في الخطة.

التسجيل بأربعة أبعاد

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

ثلاثة أنواع من الديون التي تتجاوز الدور

بغض النظر عن التسجيل، هناك ثلاثة أنواع تأتي أولاً:

1. دين يعيق الاختبار - عدم وجود بيئة Sandbox سليمة أو بيانات اختبار. كل إصلاح آخر يتم بدونه يتم في الظلام.
2. دين في الصلاحيات - نموذج رؤية فقد منطقه هو تعرض تنظيمي نشط، وليس مجرد إزعاج.
3. دين يتركز في شخص واحد - عندما يكون شخص واحد فقط يفهم مكونًا، فإن المخاطرة ليست تقنية بل تنظيمية.

كيفية عرض الدين للحصول على ميزانية

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

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

حصة ثابتة، وليس عرضًا لمرة واحدة

النمط الفاشل: مشروع تنظيف كبير مرة كل سنتين. النمط الناجح: حصة ثابتة من 15%-20% من كل موجة مخصصة للدين، يتم تحديدها مسبقًا ولا تخضع للتفاوض في كل Sprint.

بالإضافة إلى الحصة، يلزم وجود قاعدة وقائية واحدة على الأقل - على سبيل المثال، حظر إضافة أتمتة جديدة إلى كائن يحتوي بالفعل على عدة أتمتات، قبل توحيدها. بدون وقاية، يتجاوز معدل تراكم الدين معدل التنظيف. تفاصيل العلاقة بالبنية التحتية للتطوير في استراتيجية بيئات Sandboxes وعمليات DevOps.

ملخص

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