В идеальном мире каждый раз, когда мы выкатывали код в конце спринта, он отлично работал бы в производстве. Там никогда не будет ошибок, и никогда не будет проблем, которые заставят нас откатить уже развернутый код.
Конечно, мы не живем в идеальном мире. Это одна из причин, по которой у нас гибкость в первую очередь. Agile не претендует на то, что ваш мир совершенен. Речь идет об адаптации к реальности и итерации для улучшения ваших процессов и гибкости, чтобы при возникновении проблем вы могли с ними справляться.
Одной из проблем, которая часто возникает у команд, является обнаружение новой ошибки в работе прямо в середине спринта. Ваша команда завершила развертывание, все тесты пройдены, и все было отправлено в производство, чтобы клиенты могли начать использовать его.
Но, может быть, подходит крайний случай, который не рассматривался. Возможно, какой-то аспект кода, который не был полностью протестирован, выходит на поверхность и начинает создавать проблемы для пользователей. Как ваша гибкая команда должна реагировать на это?
Есть много разных подходов к устранению ошибок в производстве, которые возникают во время спринта. Выбор того, который лучше всего подходит для вашей команды, зависит от того, как устроена ваша компания, насколько серьезна ошибка и что наиболее важно для владельца вашего продукта и вашего клиента.
Вариант минимального воздействия
Если ошибка в работе является результатом работы предыдущего спринта, и она оказывает негативное влияние на пользователей, проще всего по возможности откатить рабочий сервер до состояния, в котором он находился до его обновления после обновления. последний спринт По крайней мере, это минимизирует влияние ошибки на новых пользователей.
Для этого требуется настройка системы развертывания производства, которая поддерживает чистые откаты. Гибкая команда, способная внедрять код в производство, в идеале должна работать в среде, поддерживающей непрерывное развертывание, или по крайней мере с тегами развертывания, которые позволяют вам откатить рабочие серверы до прежнего состояния. В такие времена вы по-настоящему цените наличие в команде сильных разработчиков или разработчиков.
Если возможно решить проблему просто, владелец продукта может написать историю ошибок, над которой нужно поработать в следующем спринте. Это предотвратит прерывание текущего спринта и уменьшит влияние на скорость команды. Подобная обработка ошибок также позволяет команде более тщательно рассмотреть потенциальное влияние ошибки и наилучший способ ее устранения.
Вариант глубокого исследования
Иногда исправление ошибки в производстве не так просто, как кажется. Например, ошибка могла повлиять на данные, вводимые в приложение, или эта ошибка может фактически существовать на уровне данных. В этом случае может потребоваться восстановление базы данных, что создает целый ряд других трудностей.
Признание потенциального объема ошибки является обязанностью владельца продукта совместно с командой инженеров. При обнаружении ошибки владельцу продукта может потребоваться пригласить одного или нескольких инженеров на совещания, чтобы обсудить глубину воздействия и составить план действий. Конечно, скорость команды в спринте, вероятно, будет уменьшена только из-за необходимости оценить степень ущерба и предложить жизнеспособное решение.
Если ошибка достаточно срочная и прогноз неопределенный, возможно, потребуется ввести новый всплеск в текущем спринте, и кто-то из команды инженеров начнет смотреть в будущее, что будет необходимо для исправления ошибки в следующем спринте. , Ошибки могут быть трудными для оценки из-за их неизвестной природы, и обычно хорошей идеей является не назначать точки ошибке по этой причине. Тем не менее, если один инженер отнимает немного усилий у текущего спринта, это может в конечном итоге окупиться, не сдерживая всю команду.
Вариант срочных усилий
Не всегда возможно отложить исправление ошибки до следующего спринта. Иногда ошибка настолько критична и влияет на такой важный аспект продукта, что необходимо внедрить исправление во время текущего спринта. В идеале эти усилия не потребуют всей команды разработчиков. Владелец продукта обязан оценить масштаб ущерба и решить, стоит ли вводить новую историю в середине спринта для устранения критической ошибки.
Представление новых историй в середине спринта никогда не было хорошей идеей. Хороший мастер Scrum должен работать с владельцем продукта, чтобы попытаться ограничить изменения в спринте, который находится в процессе. Но это не значит, что в этом нет необходимости, и хороший мастер схваток также должен иметь возможность четко сообщать команде, когда и почему важно корректировать отставание, если это лучший вариант.
Цель в этом случае — оказать как можно меньшее влияние на спринт. Возможно, разработчики, которые работали над разделом кода, который вызывает проблемы, могут быть извлечены из историй, над которыми они работают, и временно назначены для исправления ошибки. Конечно, пострадают любые истории, над которыми они работают, и в спринте не будет заработано ни одного очка за работу над ошибкой из предыдущего спринта.
Ядерный вариант
Если в производственном коде обнаружена критическая ошибка, наличие ошибки вызывает серьезные проблемы, и более половины команды разработчиков необходимо работать сообща, чтобы исправить ее, иногда единственное, что нужно сделать, это остановить спринт и начать новый.
Это всегда должно быть последним средством для владельца продукта. Хотя у владельца продукта всегда есть возможность остановить спринт, следует понимать, что непрерывность любой незавершенной работы будет потеряна, и вычисления скорости, связанные с этим спринтом, также будут потеряны. Для целей планирования вся работа, уже выполненная в рамках этого спринта, должна считаться утраченной.
Конечно, это не значит, что работа на самом деле отбрасывается. Но с инженерной точки зрения прекращение работы над историей и последующее ее возобновление может оказать такое негативное влияние на концентрацию и концентрацию, необходимые для команды инженеров, что этот вариант следует использовать только в самых крайних случаях.
Если ваша команда выберет этот вариант, не делайте ошибку, пытаясь создать мини-спринт с ошибками, который короче обычного спринта. Если вы считаете, что ошибка может быть исправлена менее чем за время, необходимое для выполнения одного спринта, сохраните отставание от предыдущего спринта и позвольте инженерам снова начать работать над этими историями после исправления ошибки. Ваша общая скорость должна учитывать усилия, необходимые для исправления ошибок, созданных вашей командой, а не делать вид, что ее не существует. Создание спринтов разной длины — серьезный анти-паттерн схватки, который разрушит вашу способность отслеживать реальную скорость вашей команды.
Унция профилактики
В зависимости от типа кода, который развертывает ваша компания, и размера вашей пользовательской базы, часто рекомендуется использовать канареечные серверы для проверки влияния любых изменений в работе на подмножество ваших пользователей. Это позволяет быстро выявлять возможные крайние случаи и ограничивать влияние на общую клиентскую базу.
Даже если канарские серверы не подходят, всегда полезно разработать код с переключателями, которые позволят вам включать или отключать новые функции, которые были добавлены в продукт по желанию. Scrum — это разработка и развертывание полных функций сверху вниз для каждого спринта. Если новая функция добавляется таким образом, и оказывается, что в ней есть ошибка, которая не имеет более широких последствий, то ее отключение в производственной среде может позволить команде продолжать двигаться вперед, сводя к минимуму влияние на пользователей.
Не забудьте ретроспективу
Конечно, такие вопросы всегда следует обсуждать на ретроспективе, чтобы убедиться, что все на одной странице рассказывают о том, что произошло, и о том, как предотвратить это или более эффективно решать его в будущем.
В конечном итоге владелец продукта несет ответственность за совершение этих звонков. Гибкая команда инженеров должна работать так, чтобы обеспечить наиболее продуктивный и эффективный ответ в случае ошибки в работе.