Команда получила пользовательскую историю с действиями двух ролей. Какой признак показывает, что её следует разделить?
Пользовательскую историю следует разделить, если действия ролей приводят к разным самостоятельным пользовательским результатам, которые можно отдельно согласовать, принять и поставить в работу. Простого наличия двух ролей недостаточно: если они участвуют в одном сквозном результате, история может оставаться единой.
User stories появились как способ описывать требования через ценность для пользователя, а не через внутреннюю структуру системы. Такой подход помогает обсуждать ожидаемый результат с заказчиком и постепенно поставлять работающие части продукта.
Проблема крупных историй состоит в том, что они скрывают несколько целей, затрудняют оценку, планирование и проверку результата. Поэтому в гибких подходах применяют декомпозицию на небольшие вертикальные срезы, каждый из которых имеет понятную пользовательскую ценность.
История с несколькими ролями может выглядеть компактной, но фактически содержать разные требования, правила доступа и критерии приёмки. В результате команда спорит о размере задачи, часть поведения остаётся неописанной, а отказ одной роли блокирует выпуск результата другой.
Неверная декомпозиция тоже опасна. Разделение по техническим слоям, например на интерфейс, базу данных и сервис, создаёт задачи без самостоятельной пользовательской ценности и не позволяет проверить готовый результат по отдельности.
Главный признак для разделения — независимый пользовательский результат. Если оператор получает один полезный результат, а администратор — другой, для каждого результата обычно нужны собственная цель, правила доступа и критерии приёмки.
Дополнительные признаки разделения:
Формулировать новые истории лучше вертикально: каждая должна описывать путь от действия роли до проверяемого бизнес-результата. Например, вместо разделения на «сделать экран» и «добавить обработку» выделяют истории «оператор регистрирует заявку» и «администратор утверждает заявку», если это действительно разные ценности.
Разделение не означает механическое создание истории на каждую роль. Если одна роль только выполняет обязательный шаг общего сценария, а самостоятельная ценность возникает лишь после завершения всего процесса, преждевременное разделение может ухудшить понимание зависимости.
Компромисс состоит в выборе размера. Слишком крупная история плохо оценивается и долго проверяется, а слишком мелкая перегружает планирование и теряет бизнес-контекст. Практический критерий — возможность отдельно обсудить, реализовать, принять и при необходимости изменить историю без искусственного ожидания несвязанных частей.
В системе закупок одна история описывала действия закупщика по созданию заявки и действия руководителя по её утверждению. У этих действий были разные правила: закупщик мог редактировать состав заявки, а руководитель — только утверждать или отклонять её с обязательным комментарием.
Команда рассмотрела три варианта. Оставить историю целиком было проще для описания сквозного процесса, но затрудняло оценку и откладывало ценность до готовности обеих ролей. Разделить её по техническим слоям означало бы получить задачи без самостоятельно проверяемого бизнес-результата. Разделить по ролям и исходам процесса давало независимые критерии приёмки, но требовало явно описать состояние заявки и зависимость утверждения от её создания.
Выбрали третий вариант: выделили истории создания заявки закупщиком и принятия решения руководителем. Между ними зафиксировали бизнес-зависимость через состояние «ожидает утверждения», а критерии приёмки описали отдельно. В результате первую часть можно было принять и показать заказчику раньше, а правила утверждения не смешивались с правилами редактирования.
1. Достаточно ли разных ролей, чтобы всегда разделить пользовательскую историю?
Нет. Разные роли сами по себе не доказывают наличие разных историй. Нужно проверить, существуют ли самостоятельные результаты и может ли каждый из них быть отдельно принят пользователем.
Например, сотрудник создаёт обращение, а система автоматически уведомляет контролёра. Уведомление может быть частью одной истории создания обращения, если отдельной ценности для планирования и приёмки оно не имеет. Но если контролёр самостоятельно управляет уведомлениями и получает отдельный бизнес-результат, это может стать отдельной историей.
2. Можно ли разделять историю по техническим компонентам, если это упрощает разработку?
Для пользовательских историй это обычно неверный основной принцип. Задачи технической реализации можно декомпозировать по компонентам внутри истории, но сама история должна сохранять сквозной пользовательский результат.
Иначе команда может принять отдельно интерфейс или внутреннее хранилище, хотя пользователь ещё не способен выполнить полезное действие. Техническое разделение допустимо как план работ, но не должно подменять продуктовую декомпозицию требований.
3. Как поступить, если две части нельзя выпустить независимо из-за зависимости между ними?
Нужно различать независимость выпуска и независимость смысла. Истории могут иметь зависимость по порядку реализации, но при этом оставаться отдельными, если у них разные результаты, правила и критерии приёмки.
В таком случае зависимость фиксируют явно: например, утверждение возможно только для ранее созданной заявки. Если же отдельная часть не имеет самостоятельной ценности даже после реализации и служит лишь внутренним шагом, её лучше оставить критерием или задачей внутри исходной истории, а не искусственно превращать в отдельную пользовательскую историю.