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

Ответ 1

Да, иногда один из них иногда не плох. Но если вы проворны, используя Scrum, то вы, по-видимому, пытаетесь следовать Test-Driven Development (TDD), и важно помнить, что последовательность красно-зеленая - рефакторинг, а не только красный зеленый. Плохой качественный код не является результатом гибкой разработки, но плохой гибкой разработки.

Ответ 2

У вас есть определение "сделано"?

Когда вы закончили кодирование и готовы к регистрации, вы должны были выполнить определение своей команды "done"

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

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

Здесь статья Scrum Alliance по определению вашего 'definition of done'

Ответ 3

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

Ответ 4

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

Я запускаю рефакторинговый спринт, как и любой другой спринт - строго 2 недели. Иногда мы даже запускаем только 1 неделю рефакторинга спринтов (когда происходит что-то срочное).

Примечание по рефакторингу спринтов: не слишком амбициозны:

• Поймите, что рефакторинг - это бесконечный цикл: вы всегда найдете лучший способ сделать что-то.
• Это нормально, если вы реорганизуете только 10% того, что нужно реорганизовать.
• Относитесь к рефакторингу, как и к любым другим историям, чтобы вы были вынуждены уделять приоритетное внимание тому, что нужно для рефакторинга и узнать, где в вашем коде больше всего нужна рефакторинг. Единственное различие заключается в том, что для рефакторинга рассказов я позволяю разработчикам устанавливать приоритеты.
• Частичный рефакторинг все равно оставит ваш код в лучшем состоянии, чем вообще не рефакторинг. Кроме того, он имеет тенденцию облегчать дальнейший рефакторинг.
• Рефакторинг происходит даже за пределами рефакторинговых спринтов при работе над историями, но только в том случае, если рефакторинг представляет собой низко висящий плод, который не мешает завершению истории.

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

Ответ 5

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

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