Как наш заказчик менял релизный процесс
Руководитель направления функционального тестирования одного из наших банковских проектов, рассказала нам про процесс управления релизами, как на их проекте менялась технология поставки задач на продуктив и как все работает сейчас.
Как было?
Релизный процесс у нашего Заказчика, работающего в банковском секторе, представляет собой масштабную работу по обновлению и продуктовых систем, и приложений для работы сотрудников банка, и клиентских приложений. Разные части функционала разрабатываются в разных командах, с использованием различных стеков технологий. А над достижением конечной цели трудятся сотни сотрудников.
Во всей этой огромной машине время от времени случаются сбои. Например, к моменту релиза обнаруживается, что какие-то доработки никак не получается стабилизировать. Или прибегает менеджер с требованием довключить “сырой” функционал.
В чем проблема?
Все это растягивало релизный цикл и, в итоге, привело к следующим проблемам:
· из-за ожидания доделок одних задач, задерживалась поставка на продуктив других. Как следствие: заказчик не получал прибыль, которую рассчитывал получить за счет продажи новых продуктов и оптимизации процессов;
· овертаймы команды тестирования становились нормой жизни;
· несчастные пользователи: с каждым релизом мы поставляем на продуктив не только новый функционал, но и фиксы существующих в системе дефектов. Чем дольше мы задерживаем исправление ошибок, тем дольше клиентам банка, операторам в банковских офисах и контакт-центре приходится использовать приложения с этими ошибками и искать обходные пути для выполнения задач.
Было очевидно, что наш релизный процесс нуждается в реорганизации.
Что решили делать?
Итак, мы решили внедрить у себя модель непрерывных релизов, чтобы сократить срок доставки функционала на продуктив. За основу была взята методология SAFe. Такой процесс релиза в банке называется train (от англ. “поезд”). Что это значит?
Наш релиз как поезд, двигается по строгому расписанию. В конце года релиз-менеджеры составляют план релизов на весь следующий год, где фиксируют даты релизов с частотой каждые две недели. В момент составления плана мы не знаем какие доработки будут реализованы и не подстраиваем график под их выпуск. Важный момент такого планирования заключается в том, что даты релизов впоследствии не меняются. Если релиз запланирован на определенную дату, то именно в эту дату он и будет поставлен.
Как поезд, идущий по расписанию, ни минутой раньше ни минутой позже.
Этот план помогает определять сроки по исправлению ошибок программного обеспечения и сообщать их пользователям. А также помогает продуктовым командам планировать даты выпуска своих доработок на продуктив.
Чтобы быть включенной в релиз, задача должна подходить под четкие критерии. К моменту сбора дистрибутива по задаче должно быть завершено тестирование и оформлены протоколы тестирования, исправлены все дефекты, с которыми нельзя выходить на прод, весь код передан сопровождению для сборки, после сборки проведено приемочное тестирование на общей среде регресса, информация по задаче передана команде регресса для корректировки регрессионных тестов и покрытия автотестами.
Задачи, не подходящие под эти условия, не допускаются до посадки на поезд.
Если в процессе приемочного или регрессионного тестирования обнаруживаются критичные дефекты, которые не могут быть решены к зафиксированной дате релиза, то такую задачу мы вынуждены “вырезать” из релиза или, иными словами, высадить пассажира из поезда, а не ждать фиксов дефектов и переносить дату релиза.
Релизный процесс у нашего Заказчика, работающего в банковском секторе, представляет собой масштабную работу по обновлению и продуктовых систем, и приложений для работы сотрудников банка, и клиентских приложений. Разные части функционала разрабатываются в разных командах, с использованием различных стеков технологий. А над достижением конечной цели трудятся сотни сотрудников.
Во всей этой огромной машине время от времени случаются сбои. Например, к моменту релиза обнаруживается, что какие-то доработки никак не получается стабилизировать. Или прибегает менеджер с требованием довключить “сырой” функционал.
В чем проблема?
Все это растягивало релизный цикл и, в итоге, привело к следующим проблемам:
· из-за ожидания доделок одних задач, задерживалась поставка на продуктив других. Как следствие: заказчик не получал прибыль, которую рассчитывал получить за счет продажи новых продуктов и оптимизации процессов;
· овертаймы команды тестирования становились нормой жизни;
· несчастные пользователи: с каждым релизом мы поставляем на продуктив не только новый функционал, но и фиксы существующих в системе дефектов. Чем дольше мы задерживаем исправление ошибок, тем дольше клиентам банка, операторам в банковских офисах и контакт-центре приходится использовать приложения с этими ошибками и искать обходные пути для выполнения задач.
Было очевидно, что наш релизный процесс нуждается в реорганизации.
Что решили делать?
Итак, мы решили внедрить у себя модель непрерывных релизов, чтобы сократить срок доставки функционала на продуктив. За основу была взята методология SAFe. Такой процесс релиза в банке называется train (от англ. “поезд”). Что это значит?
Наш релиз как поезд, двигается по строгому расписанию. В конце года релиз-менеджеры составляют план релизов на весь следующий год, где фиксируют даты релизов с частотой каждые две недели. В момент составления плана мы не знаем какие доработки будут реализованы и не подстраиваем график под их выпуск. Важный момент такого планирования заключается в том, что даты релизов впоследствии не меняются. Если релиз запланирован на определенную дату, то именно в эту дату он и будет поставлен.
Как поезд, идущий по расписанию, ни минутой раньше ни минутой позже.
Этот план помогает определять сроки по исправлению ошибок программного обеспечения и сообщать их пользователям. А также помогает продуктовым командам планировать даты выпуска своих доработок на продуктив.
Чтобы быть включенной в релиз, задача должна подходить под четкие критерии. К моменту сбора дистрибутива по задаче должно быть завершено тестирование и оформлены протоколы тестирования, исправлены все дефекты, с которыми нельзя выходить на прод, весь код передан сопровождению для сборки, после сборки проведено приемочное тестирование на общей среде регресса, информация по задаче передана команде регресса для корректировки регрессионных тестов и покрытия автотестами.
Задачи, не подходящие под эти условия, не допускаются до посадки на поезд.
Если в процессе приемочного или регрессионного тестирования обнаруживаются критичные дефекты, которые не могут быть решены к зафиксированной дате релиза, то такую задачу мы вынуждены “вырезать” из релиза или, иными словами, высадить пассажира из поезда, а не ждать фиксов дефектов и переносить дату релиза.
Чтобы не доводить ситуацию до такого, команды, реализующие фичи, также работают по принципам SAFe и в разработке следуют следующим правилам:
2. в качестве подстраховки используем feature toggle. т.е. переключатель, на случай, если что-то пошло не так, мы можем “выключить” наши доработки;
3. после установки задачи на тестовую среду релиза проводим happy path.
Бывают ситуации, когда процесс разработки задачи завершен на день позже после фиксации скоупа релиза или даже на несколько часов. И как велик соблазн запрыгнуть в последний вагон уходящего поезда. Но нужно понимать, что включение такой задачи приводит к большим рискам. Поэтому такая задача не включается в текущий релиз и ждет следующий. Иными словами, если вы купили билет на поезд, но опоздали на него, поезд уезжает без вас, а вы остаетесь на перроне ждать следующий. Обидно? Очень.
Но в большинстве случаев, т.к. релизный цикл у нас короткий, то подождать 2 недели - не критично и даже более приемлемо, чем в спешке выпустить сырой функционал.
Конечно, в каждом правиле есть исключения. К сожалению, иногда возникают ситуации, когда на продуктиве “выстреливает” супер-критичная ошибка и ожидание следующего поезда сулит банку большими потерями. В таком случае мы либо включаем такой функционал в релиз, либо выпускаем внеплановый патч, на случай, если даже ожидание ближайшего релиза будет очень дорого нам стоить. Внеплановый патч устанавливается независимо от запланированного графика релизов и не влияет на текущий график, т.е. сдвигов не происходит, а запускается как бы дополнительный поезд только с этим исправлением. Но нужно отметить, что эта практика не есть норма и поступаем так только в критических ситуациях.
Что в итоге?
В рамках рабочего процесса нашего заказчика такой подход успешно функционирует уже несколько лет и показывает хороший результат. Мы выстроили процесс так, что график релизов соблюдается и процесс подготовки очередного релиза стал более контролируем, а также повысилось качество выпускаемого релиза.
- декомпозиция задач. Разбиваем задачу на мелкие кусочки, которыми проще управлять и можно поставлять на прод по частям;
2. в качестве подстраховки используем feature toggle. т.е. переключатель, на случай, если что-то пошло не так, мы можем “выключить” наши доработки;
3. после установки задачи на тестовую среду релиза проводим happy path.
Бывают ситуации, когда процесс разработки задачи завершен на день позже после фиксации скоупа релиза или даже на несколько часов. И как велик соблазн запрыгнуть в последний вагон уходящего поезда. Но нужно понимать, что включение такой задачи приводит к большим рискам. Поэтому такая задача не включается в текущий релиз и ждет следующий. Иными словами, если вы купили билет на поезд, но опоздали на него, поезд уезжает без вас, а вы остаетесь на перроне ждать следующий. Обидно? Очень.
Но в большинстве случаев, т.к. релизный цикл у нас короткий, то подождать 2 недели - не критично и даже более приемлемо, чем в спешке выпустить сырой функционал.
Конечно, в каждом правиле есть исключения. К сожалению, иногда возникают ситуации, когда на продуктиве “выстреливает” супер-критичная ошибка и ожидание следующего поезда сулит банку большими потерями. В таком случае мы либо включаем такой функционал в релиз, либо выпускаем внеплановый патч, на случай, если даже ожидание ближайшего релиза будет очень дорого нам стоить. Внеплановый патч устанавливается независимо от запланированного графика релизов и не влияет на текущий график, т.е. сдвигов не происходит, а запускается как бы дополнительный поезд только с этим исправлением. Но нужно отметить, что эта практика не есть норма и поступаем так только в критических ситуациях.
Что в итоге?
В рамках рабочего процесса нашего заказчика такой подход успешно функционирует уже несколько лет и показывает хороший результат. Мы выстроили процесс так, что график релизов соблюдается и процесс подготовки очередного релиза стал более контролируем, а также повысилось качество выпускаемого релиза.