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

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

  • определенными проблемами с 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.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store