Назовите действие и его смысл
В нашей ситуации читателю важно избежать напрасной поездки: книга должна ожидать его после подтверждённого бронирования. Кнопка является возможной частью интерфейса, но цель шире её появления. Формулировка истории должна помогать команде понять, кто действует, что ему нужно и зачем. Например, участник библиотеки хочет забронировать доступный экземпляр, чтобы забрать его позже в согласованный срок. Такая запись ещё не описывает все правила, зато задаёт предмет разговора. Если убрать объяснение пользы, команда может реализовать красивую кнопку, которая не предотвращает выдачу той же книги другому читателю.
Краткая карточка требует обсуждения
Что означает доступный экземпляр? Может ли человек бронировать несколько книг? Как долго действует бронь? Что происходит, если два читателя нажали кнопку почти одновременно? Эти вопросы не являются придирками к формулировке: ответы меняют ожидаемое поведение продукта. Полезно различать краткую запись, обсуждение и подтверждение результата. Участники уточняют правила с теми, кто понимает работу библиотеки, а существенные решения фиксируют. При этом не обязательно заранее подробно описывать все будущие истории. Ближайшая работа требует большей ясности, чем идея, к которой вернутся значительно позже.
Маленькая история сохраняет полезный результат
Большую задачу управления всеми бронированиями можно разделить. Сначала проверить создание одной брони доступного экземпляра для зарегистрированного читателя, затем отдельно обсуждать продление, отмену и очередь ожидания. Границы должны быть согласованы: в первой части всё равно нужно избежать двойного подтверждения одного экземпляра. Разделение только на базу данных, сервер и экран описывает технические работы. Они могут понадобиться, но сами по себе не показывают законченный результат для читателя. Команде полезно видеть, как эти задачи вместе обеспечивают небольшой рабочий сценарий. Размер истории определяется не числом строк в карточке.
Критерии показывают наблюдаемое поведение
Для учебной истории можно договориться: доступный экземпляр получает одну активную бронь; читатель видит подтверждение; если экземпляр уже занят, новая бронь не подтверждается. Отдельно проверяют, что повторное действие не создаёт лишний дубликат. Это конкретнее, чем требование сделать удобно и надёжно. Критерии не обязаны описывать внутреннюю архитектуру. Они уточняют, что система должна делать в согласованных условиях. Реализация может меняться, если сохраняется требуемое поведение. После демонстрации полезно проверить не только успешный путь, но и выбранные пограничные случаи, а новые вопросы вернуть в обсуждение.
Попробуйте на практике
Подготовьте одну пользовательскую историю для вымышленной библиотеки на бумаге, без разработки приложения.
- Определите конкретного читателя и пользу от бронирования. Запишите историю одним понятным предложением.
- Перечислите три вопроса к библиотеке, ответы на которые меняют поведение системы.
- Ограничьте первую версию одним доступным экземпляром и обозначьте, какие возможности обсуждаются отдельно.
- Сформулируйте три проверяемых критерия: успешная бронь, занятый экземпляр и повторное действие.
- Прочитайте запись глазами разработчика и проверяющего. Исправьте слова, которые допускают разные трактовки, не добавляя ненужных технических деталей.
Как проверить результат. История описывает пользу и законченный сценарий. Вопросы и критерии согласованы с её границами; появление кнопки не считается достаточным подтверждением результата.
Частые вопросы
Нужно ли всегда использовать один шаблон предложения?
Шаблон помогает не забыть роль и пользу, но сам по себе не делает историю хорошей. Важнее понятная потребность, обсуждённые границы и возможность проверить результат.
Критерии приёмки заменяют разговор с пользователем?
Нет. Они фиксируют часть договорённостей. Если правила или обстоятельства изменились, критерии уточняют вместе с пониманием потребности.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.