Как вы оцениваете рентабельность инвестиций в погашение технического долга?

Ответ 1

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

Теперь, добавив цифру $"плохой технический долг", можно было бы включить в более позитивный оборот (при условии, что в вашем случае будет следующее: "если мы инвестируем в компонент переделки X, мы могли бы добавить функцию Y быстрее и, таким образом, получить Z больше клиентов".

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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)

Ответ 4

+1 для jldupont сосредоточиться на потерянных деловых возможностях.

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

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

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

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

Ответ 5

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

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

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

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

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

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

Ответ 6

Являясь главным разработчиком одиночной или небольшой команды, это не в моей области, но для меня отличное решение, чтобы узнать, где время потрачено впустую, очень, очень подробный хронометраж, например, с помощью удобного инструмента панели задач, такого как этот, который может даже отфильтровываться при переходе в loo и может экспортировать все в XML.

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

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

Ответ 7

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

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