Декомпозиция требований? Самая техническая сторона проджекта

Всем привет. Сегодня предлагаю поговорить про декомпозицию требований и как это делается в Agile.

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

И начнем мы… с конца. С ответа на вопрос зачем нам это делать?

В разработке проектов / продуктов перед реализацией того или иного функционала, проджект / продакт менеджеру необходимо держать в голове вопрос: “Какой самый быстрый недорогой способ реализации фичи для конечного пользователя?”. Если правильно перефразировать, то этот вопрос, в том контексте, который рассматриваем мы, должен больше звучать как: “Какие есть варианты наискорейшей доставки ценности конечному пользователю?”. Вроде бы похожие вопросы, но, если перевести их на менеджерский язык, то получаем некие различия. Первый вопрос — больше про реализацию того или иного целостного большого функционала.

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

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

Что такое слайсинг?

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

Вот как выглядит любая декомпозиция:

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

Процес декомпозиции и его результат имеет ряд преимуществ, среди которых:

Возможность быстро получать фидбек (аминь!). Разбив стори на логически завершенные кусочки функционала, мы можем смело бежать к клиенту и показывать, чего накодили для наискорейшего приема правок. Так дешевле.
Быстрое тестирование и багфикс. Имея маленький функционал, который станет частью большого функционала, у нас есть возможность быстрее найти баги и пофиксить их. Пример: разработка формы заказа еды, отдельно от разработки витрины онлайн магазина. Если мы потестим форму заказа быстренько, то успеем допилить и валидацию правильную и верные ответы сервера на запрос. А возможно, после ревю юристов, нам потребуется еще допилить GDPR позиции (мало ли).
Определение важной и менее важной работы. Когда мы декомпозируем большую задачу, мы сразу же видим, что будет важнее всего и пойдет в работу в первую очередь, а что будет менее важно и будет реализовано позже или не реализовано вовсе.
Лучшая прогнозируемость результатов спринта. Если например, у нас есть скорость работы команды17 сторипоинтов, а она работает над сторями 8, 13 сторипоинтов, то есть вероятность, что мы что-то не успеем. Но что? Гораздо легче ответить на этот вопрос, когда работаем над сторями по 3 сторипоинта.
Больше доверия и веры в себя. Выплывает из предыдущего — когда мы можем спрогнозировать конец спринта, к команде повышается доверие со стороны бизнеса. То же касается и веры в себя. Конечно, приятнее закрыть 10 сторис, чем 3, просто чисто на психологическом уровне. Последнее утверждение достаточно спорное, потому что важно остлеживать осознание того, что 10 сторис были частью великого — не всем доставляет удовольствие пофиксить 15 своих же багов и гордиться собой:)
Экономия времени на оценку. Гораздо легче оценивать мелкие сторисы, описанные с разных сторон разработки, чем продумывать логику взаимодействия в большой задаче.
Смягчение рисков. Декомпозируя задачи, нам легче выделить риски, влияющие на ту или иную реализацию. Например, подумали, что форму нужно сделать на какой-то новой технологии. Уже вырисовался риск того, что продажи в интернет-магазине можем не успеть запустить вовремя потому что технология для нас новая или не успеем покрыть юнит-тестами или еще что-то. В общем, мы можем прогнозировать раньше, чем наступит капец.
Лучшее распределение работы в рамках спринта.Декомпозиция на мелкие задачи позволит многие вещи запаралелить и избежать оверзагруженности в конце спринта + лучше прозрачность отслеживания своего вклада в разработку фичи.

Когда делать декомпозицию?

Итак, как же понять, на каком этапе нам в работе нужна декомпозиция?

Разработка приложений и веб-продуктов достаточно непредсказуемый процес, в котором сложно оценивать большие куски работ и понять, в каком месте пойдет медленнее. Если в рамках спринта мы работаем над недекомпозированными задачами, то невыполнение 1–2 стори = 50% результата невыполнения спринта (образно). Декомпозицию лучше делать без привязки к конкретному спринту, и не делать ее непосредственно на планировании спринта. Самый оптимальный вариант — приходить на планирование спринта с уже декомпозированными задачами для получения более точной точечной оценки.

Как декомпозровать?

Существует два основных подхода к декомпозиции задач: горизонтальный и вертикальный. Давайте рассмотрим каждый из них.

Горизонтальная декомпозиция задач подразумевает декомпозицию задач по типу проводимых работ, по компонентам, задействованным в работе, по специалистам. Например, возможны разбивки: База данных — Сервер — Клиентское приложение; бекенд разработчики делают свою часть работ, фронтенд свою, тестиврощики свою. В итоге, при завершении работ по каждому компоненту или каждый специалистом, мы не можем оценить конечный результат, поскольку его еще нужно “собрать” в кучу, интегрировать. Горизонтальную декомпозицию лучше всего проводить на начальном этапе проекта, когда необходимо выделить логически завершенные большие куски проекта (фичи), которые в дальнейшем будут разрабатываться.

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

Нагляднее о горизонтальном и вертикальном слайсинге можно посмотреть на картинке:

Если переводить на язык практического проектного менеджмента, то, в моей практике, горизонтальный слайсинг — это выделение эпиков, над которыми мы будем работать (например, “Мобильный API”), а вертикальный — создание юзер сторис (например, “Передавать 5 последних опубликованных новостей в мобильное приложение”). У вас может быть по-другому. Например, горизонтальный слайсинг это — “Создание редактируемой странички блога”, а вертикальный уже: “верстка страницы поста, создание админ-панели для редактирования страницы поста, тестирование работоспособности, нагрузочное тестирование и т.д.”

Какие техники использовать для декомпозиции?

Существует 4 основные техники декомпозиции задач: Vague Terms, Conjunctions, Acceptance Criteria, and Workflow Steps. Рассмотрим их ближе.

Vague Terms — используется в условиях сильной неопределенности. Часто, при описании фичи, мы используем неопределенности. Например:

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

В данном случае, словосочетание “несколькими способами” несет в себя некую неопределенность — что такое “несколькими”, “какими именно способами”, “сколько их должно быть”. Точно такая же история и со словосочетанием “на протяжении нескольких дней” — сколько дней? Что такое “день” и т.д. Использовав слайсинг, мы приходим к уточнению вышеописанной стори таким образом:

Создать страницу оплаты, где отобразить корзину с выбранными товарами, форму для заполнения персональной информации, выбор способов оплаты.
Добавить функционал оплаты через: банковский терминал, LiqPay, PayPal, расчетный счет, наличными при получении.
Добавить сохранение введенной информации на протяжении 48 часов с момента клика на кнопку “Сохранить”.

Таким образом, мы видим, что уже +/- ориентируемся в том, какой объем работ нам нужно сделать и какие требования к этим работам выдвигаются.

Conjunctions — (с англ. — “союз) — если говорить простыми словами, то это те юзер стори, где мы выражаем мысли с помощью союзов “и, при условии, или, когда” и т.д.

Например:

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

В данном случае применяем декомпозицию и получаем:

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

Acceptance Criteria — декомпозиция задач на основании возможности применить к ним критериев приемки.

Например:

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

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

Разбиваем:

Создать UI элементы на странице, где будем спрашивать пользователя разрешение определять его геолокацию.
Создать UI элементы на странице, где пользователь сможет разрешить / запретить определение своей геолокации.
Определять геолокацию пользователя — страну и город.
Автоматически подставлять страну и город проживания пользователя в поля “Страна”, “Город” на странице оформления заказа.
Дать возможность изменить геолокацию на странице оформления покупки вручную пользователем предоставив ему список стран и городов в них.

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

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

Например:

Как пользователь я хочу иметь возможность создать wish-лист с товарами магазина и иметь возможность совершить покупку из него.

Разбиваем по воркфлоу, получаем:

Пользователь просматривает все товары, доступные для добавления в wish-лист.
Пользователь формируем свой wish-лист из доступных товаров путем добавления выбранных товаров в wish-корзину.
Пользователь сохраняет wish-лист в своем профиле.
Пользователь переходит в свой wish-лист из личного кабинета.
Пользователь имеет возможность купить все товары из wish-листа вместе для чего добавлен чекбокс “Купить все товары”.
Пользователь имеет возможность купить каждый товар из wish-листа отдельно, путем клика на соответствующий товар.
Пользователь переходит на страницу оформления заказа и заполняет персональные данные или использовать ранее сохраненные персональные данные путем клика на соответствующий чекбокс.
Пользователь выбирает способ оплаты.
Пользователь вводит платежные данные.
Пользователь оплачивает выбранную покупку.
Пользователь получает квитанцию об оплате в персональный кабинет и на email, указанный при регистрации.
Пользователь получает информацию о том, когда и где он может забрать свой товар.

Как видим, после того, как мы разбили пользовательский воркфлоу, у нас нарисовались и неопределенности (например п.8 — какие способы оплаты доступны и т.д.) и критерии приемки.

Вместо выводов.

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

Всем пазл!