Разрешается ли случайный рефакторинг кода в Scrum

Задний план

• Моя команда использует схватки
• В настоящее время у меня нет задачи
• Больше нет отложенных задач в отставании
• Сегодня День Труда для моего клиента.

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

Разве это нормально в Scrum, если я начинаю случайный рефакторинг кода, который у меня есть, а я не написал, который всегда беспокоит меня, но у меня нет времени, чтобы исправить его из-за назначений других дней?

Как насчет других дней, когда у меня есть свободное время между спринтами?

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

Я действительно не хочу атаковать другие ответы, но никто больше не пишет здесь автоматические тесты? Вот интересное чтение от Мартина Фаулера для любого, кто занимается Scrum без надлежащей практики разработки программного обеспечения. Роберт С. Мартин также много говорит об этом здесь .

Итак, к моему ответу ... Короче, это выглядит так:

Да, в Scrum разрешен «случайный» рефакторинг кода , если команда решит, что это нужно сделать. (Ведь это самоорганизация)

А теперь для длинного ответа:

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

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

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

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

Scrum ничего не говорит о рефакторинге.

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

Я бы сказал нет, это не так. Это независимо от типа работы (рефакторинг и т. Д.).

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

Что касается рефакторинга работы сам по себе, я могу пойти на тираду по этому поводу, но я не буду, так как не думаю, что это основной вопрос, на который вы пытаетесь ответить.

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

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

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

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

Если есть сомнения, спросите своего менеджера.

РЕДАКТИРОВАТЬ: Я также хочу упомянуть, что определенный кусок кода, который вам не нравится, может иметь определенный целевой показатель производительности, связанный с ним. Возможно, вам это не понравится, но это может быть быстрее, чем все, что вы могли бы построить, что соответствует тому, как вы хотите его использовать. Еще одна причина, по которой функциональный ре-факторинг всегда должен быть управляемым процессом.

Scrum ничего не говорит о рефакторинге (см. Лекцию Роберта К. Мартина «Земля, которую забыли схватки»).

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

Scrum - это статистическое управление проектами. Чтобы получить значимые показатели «сколько времени это займет», вы должны знать производительность (выход за спринт). Вы сравниваете оценку и реальную продолжительность для функции, по крайней мере, для более чем 1 спринта, чтобы попасть в статистику. Я рекомендую 5 спринтов. Но это зависит от вашей команды.

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

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

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

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

Последнее замечание: если вы выполняете рефакторинг, убедитесь, что у вас тестируется компонент, который вы рефакторингу. Ооо, у тебя нет тестов? Сделать задание на написание тестов. Ваш клиент будет рад узнать, что используемое им программное обеспечение не имеет достаточного покрытия для тестирования ...

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

Вот один из подходов: делай оба!

Рефакторинг часто подвержен ошибкам или занимает больше времени, что первоначально оценивается как @misterbiscuit.

Так что рассмотрим попытку сделать это черновиком или шипом. Вы не должны искать одобрения или рекламы, если на этом этапе.

Затем включите его через один из двух каналов:

• существующий билет, который затрагивает тот же код / ​​функциональность, где вы можете разумно обернуть его. Разумно, как согласовано с другими членами команды.
• весь билет для просмотра на следующем груминге (или еженедельной встрече и т. д. при водопаде). В то время вы можете обосновать это.

Как только вы получите реальный бай-ин, вы можете посмотреть, как применить или повторить всплеск, и фактический код будет объединен с основной веткой (основной и т. Д.).

Это будет иметь несколько преимуществ:

• Весь ваш код кодируется через один и тот же процесс, проходит тестирование, проверку качества, в конвейере выпуска и т. Д.
• Вы получаете официальный бай-ин, в том числе от менеджера по продукту, что рефакторинг является частью ремесла, а не тем, что нужно «пробраться» на выходных. Спросите себя, почему вы не «крадетесь», фактическая функция может помочь в перспективе.
• Вы можете запросить сопряжение, проверку кода, qa, devops и другую поддержку, которая может понадобиться для изменения кода факторинга. Все это будет официально, в соответствии с Политикой и Процедурой и вышеупомянутым правлением.
• Если вы являетесь публичной компанией с SOX-совместимостью, вы, вероятно, захотите / должны будете выполнить этот формальный процесс (т.е. задокументировать его и затем следовать ему).
• Вы получаете лучшую репутацию как с менеджером по продукту (изменение было сделано быстро), так и с командой разработчиков (кодовая база была улучшена).
• Организация стремится заботиться о качестве кода, которое хорошо для производительности, морального состояния, удержания сотрудников и многих других причин.
• Влияние на скорость проекта легче отследить, когда все работы включены. Может быть нормально не назначать какие-либо точки, так как само присутствие может использоваться для влияния на скорость.
• Разработчики, скорее всего, увидят инструменты, способствующие более легкому обзору кода, такие как Fisheye, Github и т. Д.
• Разработчики с большей вероятностью увидят некоторые базовые стандарты (иногда документированные, иногда нет), которые упрощают совместное использование кода и, следовательно, упрощают рефакторинг. Иногда большая часть рефакторинга выбирает стиль, а затем широко применяет его (заменяя смесь подходов одним).

Последний комментарий: избегайте, чтобы менеджер по продукции слышал слово «случайный». Они могут отреагировать более благоприятно с помощью «целевого, стратегического, повышающего производительность» обновления кода. Или пакет обновления приложения. Или на любом другом языке.

Случайный рефакторинг не имеет смысла. Что имеет смысл, так это рефакторинг кода, который принесет большинство преимуществ. Это означает :

• устранение проблемы дизайна или архитектуры
• улучшение реализации

Разве это нормально в Scrum, если я начинаю случайный рефакторинг кода, который у меня есть, а я не написал, который всегда беспокоит меня, но у меня нет времени, чтобы исправить его из-за назначений других дней?

Из этого ответа :

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

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