Как измерить потенциальную ценность рефакторинга

На старом большом проекте с техническим долгом, как вы можете надежно оценить или измерить выгоду от рефакторинга кода?

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

Разработчики предполагают, что замена существующих компонентов старого языка новой версией была бы «хорошей вещью». Однако никакие дополнительные функции не будут добавлены в эту работу, и это будет стоить x дней разработки.

Продавец предлагает добавить «отличную новую функцию». Компания измеряет ценность его предложения, используя формулу. то есть. Это принесет компании F миллионов фунтов стерлингов в течение t лет, затратив на это x дней работы.

Как может компания осмысленно оценить предложение по рефакторингу? и при каких обстоятельствах это может быть наиболее выгодным вариантом для компании?

Это принесет компании F миллионов фунтов стерлингов в течение t лет, затратив на это x дней работы.

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

Но что угодно; Ваш вопрос достаточно ясен о том, что вы ищете:

Как я могу сделать экономическое обоснование для рефакторинга?

Главное понять, что время равняется деньгам. Вы можете перейти прямо к «5 разработчиков 2 недели = 80 часов * 5 разработчиков * $ 50 / час -> $ 20000», и это имеет смысл для деловых людей. Умные бизнесмены заметят, что этим 5 разработчикам платят в любом случае, и вы возражаете, что они не тратят / экономят 20 000 долларов - они используют 20 000 долларов самым прибыльным способом. В любом случае, со списком.

• Эффективность. Предположительно, вы можете сделать больше вещей с помощью C #, чем VB6. Лучшее оснащение, лучшие библиотеки, что угодно. Новые технологии, как правило, лучше, чем старые. Если вы можете делать вещи за меньшее время, это означает, что вы экономите деньги компании.
• Накладные расходы - кодирование - не единственная стоимость программного обеспечения. Посмотрите, что произойдет, когда выйдет Windows 2020. Сколько времени и усилий вы потратите на то, чтобы приложение VB6 работало над ним? Сколько это больше времени и усилий, чем приложение на C #? Это экономит деньги вашей компании.
• Качество - по-видимому, вы можете делать вещи с более высоким качеством в C #, чем в VB6 (или с более чистой архитектурой, или чем-то еще, что является вашей целью рефакторинга). Более высокое качество означает меньше ошибок. Меньшее количество ошибок означает меньшие затраты на их устранение, меньшие затраты на поддержку клиентов для решения этих проблем, меньшие потери клиентов из-за проблем с качеством, увеличение продаж из-за репутации качества ... все доллары для вашей компании.
• Экономия на людях - давайте посмотрим правде в глаза: никто не хочет работать с этим дерьмовым приложением VB6. Это означает, что все больше людей покидают компанию, что приводит к потере времени и денег на их замену. Это означает, что для найма новых сотрудников требуется больше времени и денег. Хуже всего то, что с этим приложением VB6 у вас будут разработчики, которые совершают карьерные самоубийства. Эти разработчики, в свою очередь, ускоряют гибель проблем качества. Сокращение оборота и найма экономит деньги вашей компании. Сохраняя самодовольство, дурацкие разработчики подальше спасают вашу компанию.
• Мораль - Точно так же программисты, которые уже там, ненавидят работать в VB6. Они сделают это, и они могут даже сделать это хорошо. Но это отстой. Может быть, не для всех, но, безусловно, для некоторых. Это означает, что больше времени уходит на просмотр веб-страниц, чтобы восстановить мотивацию. Это означает более длинные обеды. Это означает, что нужно меньше выполнять работу, в то время как вашим программистам требуется больше времени, чтобы оправиться от неудачной работы.
• Возможности. Это менее применимо к технологическим рефакторам, но относится к архитектурным рефакторам. Некоторые проблемы с кодом активно мешают вам предоставлять классную функцию X, чтобы заработать кучу денег. Может быть, вы не можете масштабировать. Может быть, вы не можете получить данные, чтобы сделать классную информатику. Может быть, код - это такое крысиное гнездо, что на самом деле непросто сделать эту работу. Без разницы. Иногда вы находитесь в этой точке, иногда вы едете прямо к этой точке. Трудно перевести на деловую речь, но если вы можете, «эта проблема не дает нам воспользоваться возможностями X, Y и Z», может быть очень мощной.

В общем, все сводится к тому, что «это поможет нам лучше выполнять свою работу; если мы будем выполнять свою работу лучше, мы сможем заработать / сэкономить больше денег».

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

Согласно моему опыту, продавцы обычно не делают оценок, а догадываются о том, сколько это слишком много для руководства или клиента: если руководство готово заплатить 50 человеко-недель работы, но абсолютно отвергнет 75 человеко-недель, давайте скажем что эта функция займет 70 человеко-недель, а готовность к пересмотру (что не может быть реальным для реальной оценки) - до 55 человеко-недель.

• С одной стороны, у вас есть оценки, сделанные ИТ-экспертами, которые говорят что-то вроде:

  Согласно этому конкретному аудиту, мы тратим 8 000 долларов в день, используя устаревшую технологию, по сравнению с аналогичными проектами аналогичного размера, в которых используются более новые технологии. Также представляется, что для переноса всей кодовой базы потребуется от 50 до 80 человеко-недель; в течение этого времени не будет выпущено никаких новых функций. Существует также 10% риск того, что миграция определенного компонента может привести к 20-30 дополнительным трудоемким периодам работы.

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

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

Обратите внимание, что если в прошлом ваши оценки были достаточно точными, вы приобретаете репутацию и влияние. Если ваши оценки всегда были неправильными, руководство, вероятно, проигнорирует ваши предложения.

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

• Вы действительно знаете, насколько умела ваша команда в C # по сравнению с VB6? Это основано на реальных измерениях или только догадках?

• Разработала ли эта команда большие проекты на C #? Знают ли они инструменты, которые должны использовать (IDE, отладчики, профилировщики и т. Д.)? Вам нужны дополнительные лицензии (что в мире Microsoft означает тысячи долларов за машину)?

• Является ли текущий проект полностью понятным, и вы можете гарантировать, что при миграции не будет сюрпризов? Это просто переписать все , каждую функцию, или будут сюрпризы?

• У вас есть инфраструктура, которая поддерживает C #? Как насчет непрерывной интеграции? А как насчет вашего сервера сборки? Руководства по стилю? Статические шашки?

• В рабочем состоянии, могут ли серверы (если это веб-приложение) или компьютеры клиентов (если это приложение для настольных компьютеров) запускать версию .NET Framework, которую вы ожидаете использовать?

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

Как только вы докажете, что вы тратите, скажем, 8 000 долларов в день из-за VB6 (что означает, что вы будете экономить 8 000 долларов в день после перехода на C #), как вы объясните преимущества проведения каждой новой разработки функций и сосредоточиться на полной переписать? В чем выгода по сравнению с прогрессивной перезаписью, когда вы переносите свои компоненты небольшими порциями один за другим, предлагая новые функции?

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

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

Во-вторых, вам нужна оценка стоимости не рефакторинга. Если бы вы делали оценки для меня, я бы ожидал некоторый уровень метрик. Например, разница между средней стоимостью разработки для кода VB и кода C # за четверть. Или некоторые такие. Очевидно, будет зависеть от того, насколько точно вы отследите это.

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

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

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

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

Ценность рефакторинга проявляется несколькими способами.

Это поможет вам внести другие изменения позже, поэтому для завершения X дней, которые потребовалась бы эта функция, теперь потребуется 2/3 дня. Использование гибкой терминологии увеличивает скорость.

Перечисленные явные изменения со временем помогут, поскольку вам больше не нужно будет поддерживать разработчиков с опытом работы с VB6, а только тех, кто имеет опыт работы с C #.

Это также помогает другими менее ощутимыми способами, такими как удержание персонала и набор персонала. Будет ли работа, выполняемая на C # и VB6, более или менее привлекательной, чем работа на C #? Будете ли вы с большей или меньшей вероятностью устроиться на работу или остаться на работе, работая над хорошей кодовой базой или паршивой?

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

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

• Если мы продолжаем делать то, что делаем, мы что-то упускаем? Существует ли какой-то старый, жестокий дизайн, который удерживает нас от осознания ценности? Например, если мы хотим добавить функцию, это настолько сложно, что для ее реализации может потребоваться, например, 100 часов, против 50 часов на рефакторинг и 25 часов на реализацию нового проекта?

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

• Является ли стоимость рефакторинга равной или меньшей стоимости не рефакторинга?

• Можно ли амортизировать стоимость, если небольшая команда рок-звезд реорганизует код, вызывающий наибольшее количество проблем? Можем ли мы распространить рефакторинг по релизам? Повсюду есть небольшая неэффективность: можем ли мы «восполнить пробелы», если можно так выразиться, этой дополнительной работой?

Преимущества наличия рефакторированной системы

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

Ключевые пункты бюджета, затронутые рефакторингом:

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

• Стоимость добавления новых функций - опять же, если текущая конструкция и структура системы делает неоправданно трудоемким процесс написания новых функций, то перезапись может обеспечить экономию. Взгляните на запланированный бюджет для новых функций, но будьте реалистичны - если вы утверждаете, что вы увидите улучшение на 50%, тогда ожидайте, что на самом деле вы разработаете функции за x человеко-месяцев, для реализации которых раньше потребовалось 2 * x человеко-месяца; такие обещания могут быть трудно сдержать.

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

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

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

Ценность рефакторинга можно измерить следующим образом: в настоящее время новая функция x будет стоить 5 устройств 2 недели. Если мы проведем рефакторинг старого компонента, стоимость новых функций будет снижена примерно на 20%. Таким образом, новая функция x будет стоить 4 разработчика в течение 2 недель.

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