Как убедить менеджера позволять Вам платить наличными за технический долг? [закрытый]

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

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

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

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

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

Только на основе того, что Вы записали и то, что Ваш проект все еще разрабатывается, я предостерег бы Вас, чтобы помнить, что пословица "Лучше является врагом сделанных". (Я полагаю, что это было выдумано или по крайней мере популяризировано Michael Lopp.) Могло бы быть лучшее время в жизненном цикле Проекта для рефакторинга кода.

Основная статья из Вашей ссылки уже имеет идеальный ответ. Это описание технического долга очень хорошо:

Технический Долг является замечательной метафорой, разработанной Ward Cunningham, чтобы помочь нам думать об этой проблеме. В этой метафоре делая вещи быстрый и грязный путь настраивает нас с техническим долгом, который подобен финансовому долгу. Как финансовый долг, технический долг подвергается выплатам процентов, которые поступают в форме дополнительного усилия, которое мы должны сделать в будущей разработке из-за быстрого и грязного проектного решения. Мы можем принять решение продолжить выплачивать процент, или мы можем платить наличными за принципал путем рефакторинга быстрого и грязного дизайна в лучший дизайн. Хотя это стоит, чтобы платить наличными за принципал, мы получаем уменьшенными выплатами процентов в будущем.

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

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

Если бы управление сочувствует, но они передумали относительно предоставления Вам 2-3 недели, чтобы сделать полный пересмотр, то компромисс был бы, когда Вы исправляете ошибки в тех компонентах, запишите некоторые тесты и сделайте некоторый ограниченный рефакторинг и со временем улучшайте код.

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