Заплатить технический долг в [закрытом] Гибком

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

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

Обратите внимание, что когда вы говорите об окупаемости, от вас могут ожидать конкретных цифр. Недостаточно сказать «будет намного легче исправлять ошибки». Вместо этого вы должны быть готовы сказать что-то вроде: «Мы увидим как минимум 30% улучшение времени выполнения исправлений ошибок» или «У нас будет на 40% меньше регрессий». Вы также должны быть готовы к переговорам с руководством и / или клиентами, чтобы вы все согласились с тем, что у вас есть измерения, которые имеют для них значение, и чтобы предоставить измерения до и после рефакторинга.

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

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

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

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

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

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

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

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

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

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

Как только мы начинаем использовать практики, мы начинаем определять технический долг. Как только технический долг был выявлен, владелец продукта написал карточки технических историй и поместил их в список невыполненных работ. Разработчик и тестировщики оценили всю работу с использованием инженерных практик XP (TDD, автоматическое тестирование, парное программирование и т. Д.). Эти методы выявили хрупкость кода с помощью TDD, автоматизированных функциональных тестов и тестов производительности. В частности, с помощью автоматического тестирования производительности и профилирования была выявлена ​​значительная проблема производительности. Задолженность была настолько велика, что, по нашим оценкам, исправление потребовало 6 итераций. мы проинформировали владельца продукта, что, если будут разработаны новые функции, они не смогут использоваться базой пользователей из-за низкой производительности приложения. Учитывая, что нам пришлось масштабировать приложение с нескольких сотен пользователей до десятков тысяч пользователей, владелец продукта очень высоко оценил технический долг по производительности, и мы завершили технические карты в оцененных итерациях.

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

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