كيف تقدر عائد الاستثمار لمسح الدين الفني؟

Question

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

لقد حددت مجالات التطبيق في حالة سيئة ويمكنني تقدير تكلفة إصلاح تلك المناطق ، لكنني أواجه صعوبة في تقدير العائد على الاستثمار (ROI).

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

يبدو أن مكانًا جيدًا للبدء يعود إلى نظام تتبع الأخطاء لدينا وتقدير التكاليف بناءً على الأخطاء والميزات المتعلقة بهذه المناطق "السيئة". ولكن يبدو أن هذا مضيعة للوقت وقد لا يكون أفضل مؤشر للقيمة.

هل قام أي شخص بإجراء مثل هذا التحليل في الماضي ولديه أي نصيحة لي؟

Answer 1

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

بالنظر إلى مشكلتك ، يندرج اقتراحك في الفئة الثانية: سيتخلى هذا بلا شك عن الهدف رقم 1 (وبالتالي يتم إعطاؤه الأولوية حتى إذا كان هذا يمكن أن يوفر المال ... لأن توفير المال يدل إنفاق المال (معظم الوقت على الأقل ؛-)).

حاليا, ، يمكن تحويل شخصية $ على "الديون الفنية السيئة" إلى تدور أكثر إيجابية (على افتراض أن ما يلي ينطبق في حالتك): "إذا استثمرنا في إعادة صياغة المكون X ، فيمكننا تقديم ميزة y بشكل أسرع وبالتالي الحصول عليها Z المزيد من العملاء ".

بعبارات أخرى، تقييم تكلفة الدين التقني مقابل تكلفة فرص العمل المفقودة.

Answer 2

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

إليكم مقتطف خوارزمية:

Debt(in man days) =
    cost_to_fix_duplications +
    cost_to_fix_violations + 
    cost_to_comment_public_API +
    cost_to_fix_uncovered_complexity + 
    cost_to_bring_complexity_below_threshold


 Where :

 Duplications = cost_to_fix_one_block * duplicated_blocks

 Violations   = cost_to fix_one_violation * mandatory_violations

 Comments     = cost_to_comment_one_API * public_undocumented_api

 Coverage     = cost_to_cover_one_of_complexity * 
                         uncovered_complexity_by_tests (80% of
                         coverage is the objective)

 Complexity   = cost_to_split_a_method *
                         (function_complexity_distribution >=
                          8) + cost_to_split_a_class *
                         (class_complexity_distribution >= 60)

Answer 3

أعتقد أنك على المسار الصحيح.

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

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

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

يحتاج العائد على الاستثمار المناسب إلى حساب العائد الكامل ، لذلك بعض الأشياء التي يجب مراعاتها هي: - انخفاض تكلفة الصيانة (من الواضح) - تكلفة الفرصة البديلة لأعمال التوقف أو الميزات الجديدة التي لا يمكن إضافتها في الوقت المناسب للإصدار - قم بإنشاء خطوط إنتاج جديدة بسبب refactors

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

Answer 4

+1 لتركيز Jldupont على فرص العمل المفقودة.

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

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

تأكد أيضًا من فهم الأفق الذي تتم إدارة المنتج له. إذا لم تفكر الإدارة بعد عامين من الآن ، فلن يهتموا بالفوائد التي لن تظهر لمدة 18 شهرًا.

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

Answer 5

لا يمكنني التحدث إلا عن كيفية القيام بذلك تجريبياً في عملية تكرارية وتزايدية.

تحتاج إلى جمع المقاييس لتقدير أفضل التكلفة/نقطة القصة. من المفترض أن هذا يمثل نظامك بعد الانقطاع المعماري الأولي ، عندما يتم إجراء معظم التجارب والخطأ في التصميم ، لكن إنتروبيا كان لديه أقل وقت للتسبب في التحلل. ابحث عن النقطة في تاريخ المشروع عندما تكون السرعة/حجم الفريق هي الأعلى. استخدم هذا كـ COST/Point Baseline (صفر ديبتي).

بمرور الوقت ، مع تراكم الديون الفنية ، تبدأ السرعة/حجم الفريق في الانخفاض. يمكن ترجمة نسبة انخفاض هذا الرقم فيما يتعلق بخط الأساس الخاص بك إلى "الفائدة" التي يتم دفعها على كل نقطة قصة جديدة. (هذا هو الفائدة حقا المدفوعة على التقنية و ديون المعرفة)

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

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

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

Answer 6

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

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

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

Answer 7

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

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