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

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

  • определенными проблемами с time to market доставки бизнес feature на продакшен — готовым задачам приходилось ждать пока релиз будет готов целиком
  • некоторым дисбалансом нагрузки команд разработки этих приложений — в начале релизного цикла можно было работать планово, а под конец всегда наступал аврал

Учитывая эти проблемы бизнес зачастую приходил к ИТ с двумя задачами:

  • научиться релизить часто — раз в 2 недели вместо раза в квартал
  • научиться работать отдельными фичевыми командами, у которых есть четко определенный закачик и поток бизнесовых задач

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

Процесс с крупными редкими релизами

В данном процессе система как бы переходит от одного крупного состояния к другому, например, от версии 2.5 к версии 3.0. Представим, что версия 2.5 является вашей текущей версией. А версия 3.0 вы хотите выпустить через квартал. В этом случае у вас обычно есть полное описание функциональности текущей версии в виде Технического Задания (ТЗ), а описание новой версии сделано методом copy-paste и изменением тех мест, которые теперь должны работать по другому.

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

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

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

Рис.1 “Работа с требованиями при крупных и редких релизах”

У данного подхода есть целый набор положительных качеств:

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

Но этот процесс плохо дружит с независимой разработкой в feature-командах и с частыми релизами, которых так желает бизнес.

Процесс с частыми релизами

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

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

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

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

Второй способ — разделить источники истины на несколько, ориентированных на разные категории потребителей:

  • поддерживать наборы тест-кейсов для того, чтобы проверять, что решение работает правильно (этот набор тест-кейсов должен пополняться тест-кейсами тех задач, что были слиты в стабильную ветку)
  • поддерживать наборы скриншотов, чтобы контролировать верность визуального отображения — правда, тут скриншоты экранов целиком могут быть слишком крупной единицей атомарности
  • поддерживать концептуальные схемы работы компонентов, например, те же самые uml диаграммы, что я упоминал в самом начале статьи
  • и любые другие способы, которые покажутся удобными

Я для себя визуализировал этот процесс на рисунке 2, где

  • вертикальными цветными линиями показаны релизы, которых четыре (зеленый 3.25, оранжевый 3.26, синий 3.27 и фиолетовый 3.28)
  • черные горизонтальные линии разделяют общие компоненты
  • а горизонтальные цветные стрелки показывают задачи, причем задачи окрашены цветами того релиза, в который они входят (это определяется по тому, когда задача будет готова)
Рис.2 “Работа с требования при частых релизах”

Положительных качеств в этом процессе достаточно много:

  • гибкость в развитии продукта
  • быстрый time to market
  • отдельные стримы изменений в виде работы feature-команд
  • параллельная работа над задачами

И все они относятся к тому, что запрашивает бизнес, но … как обычно есть некоторое “но”. Кажется, что в этом процессе сложнее синхронизировать потоки разных хотелок бизнеса … и это правда. Но мы можем комбинировать первый и второй подходы, используя более тяжеловесное описание для принципиально новых фич, а небольшие задачи реализуя в виде потока фич.

Переход между двумя процессами

Самую интересную часть, а именно переход от первого процесса ко второму, я расскажу в одной из следующих статей:)

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.