Задача «сделать оформление заказа» слишком велика для предметного обсуждения поставки. Если разделить её на «создать базу данных», «сделать экран» и «протестировать оплату», части станут меньше, но ни одна из них сама по себе не позволит покупателю совершить покупку.
Полезнее выделить узкий сценарий покупки, который работает от начала до конца. На общей Scrum-доске можно сравнить такие части, примеры приёмки и возможности, оставленные на будущее. Результат для покупателя должен оставаться видимым и при обсуждении технических задач.
Это небольшая история или техническая задача?
Согласно определению разделения историй Agile Alliance, каждая полученная история должна сохранять бизнес-ценность. Это не означает, что она обязана стать отдельным коммерческим запуском. Но её результат должен показывать полезное изменение поведения системы, а не только готовность одного технического слоя.
Пользователь может совершить покупку, открыть сохранённый заказ или применить подходящую скидку. Однако он не может осмысленно «воспользоваться таблицей базы данных» без соответствующих функций. Изменения базы, интерфейса и тестов необходимы; оформите их как задачи внутри истории.
Вертикальное разделение означает выделение узкого сквозного сценария, проходящего через необходимые части системы. Оно не требует рисовать каждую историю вертикальным столбцом. В руководстве Humanizing Work объясняется этот подход и предлагаются способы сокращать объём, сохраняя полезное поведение.
Задайте границы примера с оформлением заказа
Представим магазин, в котором покупатели уже могут просматривать доступные товары и добавлять их в корзину. Теперь требуется оформление заказа. В исходном запросе есть несколько способов оплаты, разные регионы доставки, промокоды, сохранённые адреса и гостевые покупки. Всё это не обязательно нужно для проверки первого рабочего сценария.
В условном первом выпуске команда выбирает зарегистрированных покупателей, доступные товары и доставку в пределах одного поддерживаемого региона. Она оставляет один способ оплаты и существующий стандартный вариант доставки. Промокоды, сохранение новых адресов и международная доставка пока исключены.
Первая история звучит так: «Зарегистрированный покупатель может оплатить доступные товары из корзины поддерживаемым способом и получить подтверждение заказа». Объём ограничен, но покупка всё же проходит от начала до конца.
Сравните два способа разделить работу
| Разделение по компонентам | Чего не хватает | Часть с результатом для покупателя |
|---|---|---|
| Создать базу данных заказов. | Покупателю негде оформить заказ. | Совершить стандартную покупку и сохранить заказ. |
| Сделать экран оплаты. | Без обработки платежа и заказа экран не подтверждает покупку. | Оплатить первым поддерживаемым способом и получить ясный результат принятия или отклонения платежа. |
| Добавить расчёт скидки. | Сам расчёт ещё не даёт законченного сценария покупки со скидкой. | Применить одно согласованное правило скидки в уже работающем оформлении заказа. |
| Создать таблицу адресов. | Хранение адреса не показывает, что покупатель может выбрать его и заполнить сведения о доставке. | Выбрать сохранённый адрес при уже работающем оформлении покупки. |
Варианты в правом столбце не означают обязательство сделать четыре отдельных выпуска. Первые две строки могут входить в одну начальную историю: успешная покупка включает обработку оплаты. Не разделяйте их только ради большего числа карточек.
Сделайте первую историю проверяемой
Запишите примеры приёмки, прежде чем признать историю достаточно маленькой. Одна фраза об успешной покупке может скрывать работу, необходимую для нормального использования.
| Ситуация | Ожидаемое поведение | Решение об объёме |
|---|---|---|
| Товары доступны, покупатель указал корректные данные поддерживаемого способа оплаты. | Заказ сохранён, покупатель видит подтверждение, а номер заказа позволяет определить эту покупку. | Входит в первую историю. |
| Платёж отклонён. | Покупатель понимает, что покупка не подтверждена, и может исправить данные для повторной попытки. | Входит: обработка ошибки — часть сценария покупки. |
| Покупатель повторно отправляет запрос, пока результат первой попытки неясен. | Сам по себе повтор действия не создаёт вторую покупку. | Нужно согласовать требуемое поведение с разработчиками до приёмки истории. |
| Товар стал недоступен к моменту оформления заказа. | Покупатель узнаёт, какой товар мешает завершить заказ, вместо ложного сообщения об успехе. | Входит: доступность проверяется в нужный момент. |
| Покупателю нужен неподдерживаемый способ оплаты или регион доставки. | Доступные варианты обозначены ясно; недоступный вариант не выглядит работающим. | Дополнительные способы и регионы остаются на будущее. |
Примеры описывают желаемое поведение, а не техническую спецификацию платёжной системы. Действующие требования безопасности, доступности, конфиденциальности и выпуска сохраняются. Удаление необходимых защитных мер или обработки ошибок не является сокращением бизнес-объёма.
Выберите следующую часть по потребности и неопределённости
После появления стандартной покупки команда может добавить другой способ оплаты, правило скидки или сохранённые адреса. Новый способ оплаты расширяет круг покупателей. Скидка меняет расчёт цены и её объяснение. Адреса избавляют постоянного покупателя от повторного ввода. Это разные потребности, и ни одна не обязана автоматически стать следующей.
Выясните, какая группа покупателей не может завершить покупку и чем это подтверждается. Если выбранный регион охватывает пилотную аудиторию, международная доставка может быть менее срочной, чем исправление непонятного подтверждения. Если же способ оплаты не подходит этой аудитории, возможно, неверно выбрана сама первая история.
Отделяйте исследование от поставки. Короткое изучение незнакомого платёжного провайдера может снизить техническую неопределённость, но само по себе не даёт законченного сценария покупки. Укажите вопрос и ожидаемые данные, не превращая исследование в пользовательскую ценность одной только фразой «Как пользователь».
Обсудите разделение историй в Boardmix
Поместите исходный большой запрос в верхней части доски Boardmix. Ниже создайте области для первой полезной истории, последующих вариантов и открытых вопросов. Технические задачи размещайте под историей, которую они обеспечивают.
Рядом с первой историей добавьте примеры приёмки. Вопрос о повторной отправке заказа оставьте в области вопросов до согласования поведения. Соедините его с соответствующей историей, чтобы неопределённость не потерялась при обсуждении.
Карта пользовательских историй поможет поместить оформление заказа в общий путь покупателя. Доска для разделения историй отвечает на более узкий вопрос: какое небольшое полезное изменение можно сделать в этой части пути?
Прежде чем переносить историю в систему управления разработкой, прочитайте вместе её результат и примеры приёмки. Если показать можно только готовность технического слоя, продолжайте искать меньший сквозной сценарий. Откройте Boardmix, чтобы разложить варианты и сравнить их с командой.
