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