толпа и [закрытый] рефакторинг
5 ответов
Я не думаю, что это имеет такое же отношение к Scrum, как и к философии управления проектами.
Независимо от того, использует ли проект Scrum или нет, многие менеджеры проектов не любят, чтобы разработчики тратили время на «ненужные» вещи, такие как рефакторинг или реструктуризация кода, которые напрямую не продвигают одно из выдающихся функциональных требований. Это не «работа, которая приносит результат», как нормальная разработка, это «работа, которая предотвращает отсрочку результатов позже». Учитывая обычно короткие сроки, используемые для спринтов, выгоду часто трудно увидеть и почти невозможно измерить количественно.
Поддержание кода в сопровождении должно быть пунктом в вашем списке выгорания (если вы используете Scrum). Это так же важно, как и новая разработка. Хотя это может показаться чем-то «невидимым для пользователя», игнорирование этого увеличивает ваш технический долг. В будущем, когда технический долг накапливается настолько, что отсутствие ремонтопригодности вашего кода замедляет разработку, задержки в разработке новых функций будут видны клиентам.
Это все вопрос менеджмента / философии.Вместо того чтобы рассматривать рефакторинг и улучшения ремонтопригодности как «дополнительную» работу, не влияющую на клиентов, ее следует рассматривать как вложение времени для предотвращения видимых для клиентов задержек (и, возможно, также ошибок) в будущем. Иногда разработчики видят эти преимущества более ясно, чем менеджеры; если ваш менеджер не понимает недостатков пренебрежения ремонтопригодностью, вы можете пригласить нескольких других разработчиков и поговорить со своим менеджером.
Я думаю, что есть веские основания для рефакторинга технического долга, когда затраты усилий / затрат на поддержание кода достигают или даже больше, чем стоимость его рефакторинга для улучшения качества или работы лучше / должным образом - в частности, чтобы обеспечить более высокую степень ремонтопригодности.
например: если программное обеспечение настолько проблематично, что вы теряете клиентов или деньги, вы должны действовать быстро, чтобы исправить это. Некоторые могут возразить, что это собственное бизнес-требование, но оно часто не ставится во главу угла. малые и средние проекты разработки, которые вместо этого сосредоточены на технических деталях создания приложений, а не на влиянии качества приложения на чистую прибыль.
Если все в Scrum связано с функциональными вещами, которые видит пользователь (...)
Любой проект и методология должны быть о генерируя ценность для бизнеса , вы редко делаете что-то просто для развлечения в деловой среде. При этом я вижу качество в Scrum (и других методах Agile) как способ не убивать вашу скорость в долгосрочной перспективе и, в конечном итоге, достичь гиперпродуктивности. Таким образом, я считаю, что типичное «Определение готовности» должно включать что-то вроде «без увеличения технического долга» (укажите здесь свои стандарты качества). Если вы думаете, что новая функция повлияет на существующий код, который необходимо отремонтировать, включите эту стоимость в оценку (или создайте элемент рефакторинга в своем бэклоге продукта) и объясните вещи своему владельцу продукта. Потому что, в конце концов, владелец продукта должен определить приоритеты элементов и решить, можно ли временно пожертвовать качеством (если ваш бизнес умирает из-за того, что вы не выпускаете функцию, какой смысл рефакторинга существующего кода?). Но он должен знать, что это не может быть долгосрочной стратегией, иначе он убьет скорость команды.
Я думаю, вы, вероятно, говорите о крупномасштабном рефакторинге, а не о непрерывном рефакторинге, который вы бы выполняли во время всего цикла рефакторинга красный-зеленый.
Мой подход был бы примерно таким: если реафакторинг старой функции упрощает добавление новой функции, тогда вперед и сделайте это. Но в некотором смысле вы правы, если на конкретный модуль не требуется изменений (т.е. он полностью закончен, никогда не изменится снова и никогда не повлияет на другие модули), тогда нет практической необходимости в рефакторинге. Однако я редко нахожу настолько доработанный модуль.
Если вы можете оправдать это как часть процесса выполнения других задач, выявляя проблемы / риски с помощью текущих наборов кода, и это лучший конечный результат , Действуй. Но не переусердствуйте и не портите сроки / бюджет.