Без код-фриза были в стрессе и быстро выгорали: как мы внедрили замораживание кода и что оно дает

Замораживание кода или код-фриз (code freeze) может показаться рудиментом в мире, где активно используются agile-методы и принцип непрерывной разработки. Ведь этот подход предлагает сделать паузу для того, чтобы выделить время исключительно на тестирование. Как замораживание кода может помочь командам сегодня? Поделимся собственным опытом.

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

Какой была наша проблема до код-фриза

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

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

Но разработка без код-фриза создавала лишний стресс, из-за которого увеличивалось количество ошибок и быстро наступало выгорание.

Как мы вводили код-фриз

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

Перестать вносить изменения хотя бы на несколько дней

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

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

Планировать спринты с учетом времени на заморозку кода

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

На разработку нового функционала выделили 1,5 недели, а остальную часть — исключительно на код-фриз.

Понять, готовы ли заливать обновления

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

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

Что нам дал код-фриз?

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

Недостатки код-фриза

В общем, это универсальный инструмент, ведь это о планировании времени, а не о тонкостях написания кода.

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

Тем не менее, когда нам нужно внедрить ключевые обновления, которые влияют на поведение всего продукта, мы «замораживаем» код и много-много тестируем.

Также вначале может быть тяжело принять то, что теперь вы ставите меньшее количество задач на спринт. Представьте ситуацию, когда вы договорились встретиться с товарищем, он приходит раньше и спрашивает, через сколько вы будете. Допустим вам реально идти 12-15 минут. Если вы скажете «через 10 минут» — это то, как мы работали раньше. Нужно чтобы или все пошло идеально, или очень спешить. Теперь же мы отвечаем «20 минут» и точно укладываемся в установленный срок без спешки.

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