Как Вы оцениваете ROI для очистки технического долга?

Sonar имеет отличный плагин ( плагин технического долга ) для анализа исходного кода и поиска именно такой метрики. Хотя вы, возможно, не сможете использовать его специально для своей сборки, поскольку это инструмент 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)

Я думаю, вы на правильном пути.

Мне не приходилось рассчитывать это, но у меня было несколько разговоров с другом, который управляет крупной организацией по разработке программного обеспечения с много унаследованного кода.

Одна из вещей, которые мы обсуждали, - это создание некоторых приблизительных показателей трудозатрат на основе анализа коммитов VCS и их использование для распределения приблизительной оценки часов программиста. Это было вдохновлено Джоэлом Спольским Планированием на основе доказательств .

Выполнение такого анализа данных позволит вам также идентифицировать кластеризацию, когда код поддерживается, и сравнивать это с завершением ошибок в системе отслеживания (если вы не уже наделены тесной интеграцией между двумя и точными записями).

Для правильного расчета рентабельности инвестиций необходимо учитывать следующие моменты: - снижение стоимости обслуживания (очевидно) - альтернативные издержки для бизнеса из-за простоев или пропущенных новых функций, которые не могли быть добавлены вовремя для выпуска - возможность создавать новые продуктовые линейки за счет рефакторинга

Помните, если у вас есть правило для получения данных, у вас могут быть аргументы о том, как вычислять вещи, но, по крайней мере, у вас есть некоторые цифры в обсуждение!

+1 за внимание jldupont к упущенным возможностям для бизнеса.

Я предлагаю подумать об этих возможностях с точки зрения руководства. Что, по их мнению, влияет на рост доходов - новые функции, время выхода на рынок, качество продукции? Связь выплаты долга с этими факторами поможет руководству понять выгоды.

Сосредоточение внимания на восприятии руководства поможет вам избежать ошибочного исчисления. ROI - это оценка, и она не лучше, чем предположения, сделанные при ее оценке. Руководство будет подозревать только количественные аргументы, потому что они знают, что где-то есть качественные. Например, в краткосрочной перспективе реальная стоимость выплаты долга - это другая работа, которую программисты не выполняют, а не денежные затраты этих программистов, потому что я сомневаюсь в вас ». мы собираемся нанять и обучить новых сотрудников только для этого. Являются ли улучшения в будущем времени разработки или качества более важными, чем функции, которые в противном случае добавили бы эти программисты?

Также убедитесь, что вы понимаете горизонт, в течение которого осуществляется управление продуктом. Если руководство не думает о том, что произойдет через два года, они не будут заботиться о преимуществах, которые не появятся в течение 18 месяцев.

Наконец, подумайте о том, что восприятие руководства позволило этому продукту достичь этого состояния в первое место. Что изменилось, что сделало бы компанию более внимательной к техническому долгу? Если разница в том, что вы - вы лучший менеджер, чем ваши предшественники, - помните, что ваша управленческая команда не привыкла думать об этом. Вы должны найти для них аппетит, и сосредоточьтесь на тех элементах, которые принесут результаты, которые их волнуют. Если вы сделаете это, вы получите доверие, которое вы можете использовать, чтобы заставить их задуматься о дальнейших изменениях. Но признание прибылей может только возрасти.

Being a mostly lone or small-team developer this is out of my field, but to me a great solution to find out where time is wasted is very, very detailed timekeeping, for example with a handy task-bar tool like this one that can even filter out when you go to the loo, and can export everything to XML.

It may be cumbersome at first, and a challenge to introduce to a team, but if your team can log every fifteen minutes they spend due to a bug, mistake or misconception in the software, you accumulate a basis of impressive, real-life data on what technical debt is actually costing in wages every month.

The tool I linked to is my favourite because it is dead simple (doesn't even require a data base) and provides access to every project/item through a task bar icon. Also entering additional information on the work carried out can be done there, and timekeeping is literally activated in seconds. (I am not affiliated with the vendor.)

Я могу говорить только о том, как сделать это эмпирически в итеративном и инкрементном процессе.

Вам необходимо собрать метрики, чтобы оценить вашу продемонстрированную лучшую стоимость / сюжетную точку. Предположительно, это представляет вашу систему сразу после первоначального изменения архитектуры, когда большая часть проектных проб и ошибок была сделана, но у энтропии было меньше всего времени, чтобы вызвать распад. Найдите в истории проекта момент, когда скорость / размер команды самые высокие. Используйте это в качестве базового показателя затрат / пунктов (нулевой долг).

Со временем, по мере накопления технического долга, скорость / размер команды начинает уменьшаться. Процентное уменьшение этого числа по сравнению с базовым уровнем можно перевести в «проценты», выплачиваемые за каждый новый сюжетный пункт. (На самом деле это проценты, выплачиваемые по долгу технических и знаний)

Дисциплинированный рефакторинг и отжиг приводят к тому, что проценты по техническому долгу стабилизируются на некотором значении выше, чем ваш базовый уровень. Думайте об этом как об устойчивом проценте, который владелец продукта выплачивает по техническому долгу в системе. (Та же концепция применима к долгу знаний.)

Некоторые системы достигают точки, когда стоимость + процент на каждый новый сюжетный пункт превышает ценность разрабатываемого особого пункта. Это когда система обанкротилась, и пора ее переписать с нуля.

Я думаю, что можно использовать регрессионный анализ, чтобы отделить технический долг от долга знаний (но я не пробовал). Например, если вы предположите, что технический долг тесно коррелирует с некоторыми показателями кода, например, дублированием кода,

Возможно, будет проще оценить, сколько это стоило вам в прошлом . Как только вы это сделаете, вы сможете составить прогноз на будущее с диапазонами и логикой, понятными даже вашим начальникам.

При этом у меня нет большого опыта работы с такого рода просто потому, что я еще не видел менеджера, готового зайти так далеко в исправлении кода. Это всегда было чем-то, что мы исправляли, когда нам нужно было изменить плохой код, поэтому рефакторинг фактически является скрытой платой за все модификации и исправления ошибок.