Пользовательская история начинается с человека
User story — короткое описание нужного человеку результата. Она помогает обсудить, кому и зачем нужна работа, прежде чем выбирать её техническую реализацию.
«Добавить кнопку» звучит конкретно, но не объясняет, какую проблему она решает. Кнопку можно сделать точно по макету и всё равно не помочь человеку. В пользовательской истории сначала появляется ситуация: посетитель выбирает мастер-класс и хочет убедиться, что успеет приехать к началу. Уже потом команда решает, достаточно ли расписания или нужен подбор времени.
Ниже — авторский учебный пример сайта мастерской. Это не описание функций Sinqly и не клиентский кейс. Мы пройдём путь от размытой просьбы до небольшой истории, которую можно обсудить, проверить и поставить в работу.
- Функция
Сделайте выпадающий список времени.
- Потребность
Посетитель должен выбрать подходящий сеанс и не записаться на занятое время.
Формула: роль, потребность, польза
Распространённый шаблон звучит так: «Как [роль], я хочу [возможность], чтобы [полезный результат]». Это опора для разговора, а не обязательная грамматика. Неестественную фразу лучше переписать обычным языком, сохранив три смысла.
Роль здесь не «пользователь вообще», а посетитель, выбирающий занятие. Возможность — увидеть доступные варианты. Польза — подобрать время. Слово «чтобы» проверяет причинную связь: «чтобы была возможность просмотра» лишь повторяет первую часть и ничего не объясняет.
Не обязательно создавать десятки ролей. Если новому и постоянному посетителю нужен один и тот же результат при одинаковых условиях, одна история может охватить обоих. Отдельная роль полезна, когда меняются действия, ограничения или нужный результат: например, организатор управляет вместимостью, а посетитель выбирает место.
Три формулировки, которые стоит исправить
| Черновик | Что мешает | Рабочая версия |
|---|---|---|
| Как пользователь, хочу удобный сайт | Непонятны ситуация и проверяемый результат | Как посетитель, хочу увидеть свободные сеансы на субботу, чтобы выбрать подходящий. |
| Как клиент, хочу кнопку «Ещё» | Заранее выбрана деталь интерфейса | Как посетитель, хочу посмотреть занятия на следующую неделю, чтобы найти свободное время. |
| Как менеджер, хочу базу PostgreSQL | Техническая работа выдана за пользовательскую | Отдельная техническая задача: подготовить хранение записей с оговорёнными требованиями. |
Технические задачи не нужно насильно превращать в истории. Обновить библиотеку или настроить резервное копирование — нормальная работа со своим обоснованием и проверками. Вымышленная роль «как сервер» обычно только скрывает, что именно предстоит сделать.
Если в истории уже указаны цвет, расположение поля и технология хранения, проверьте, действительно ли это ограничение. Иногда оно обосновано существующей системой или требованиями доступности. Тогда сохраните его отдельно, а не смешивайте с причиной, ради которой человек пользуется продуктом.
Добавляем границы и критерии приёмки
Одна фраза не заменяет договорённость о поведении. Для нашей истории команда отдельно фиксирует: показываем сеансы только выбранного дня; полностью занятые варианты недоступны для записи; выбор другого дня обновляет список; отсутствие свободных мест сопровождается понятным сообщением. Оплата, отмена и перенос записи пока вне этой истории.
- Открыт день с двумя свободными сеансами — посетитель видит оба времени и может выбрать одно.
- Открыт полностью занятый день — выбрать сеанс нельзя, показано отсутствие мест.
- После выбора дня посетитель меняет дату — старый выбор сбрасывается, доступны варианты новой даты.
- Место занял другой посетитель до подтверждения — система сообщает об изменении и не обещает несуществующее место.
Последний пункт выявляет важный пограничный случай. Если его обнаружили только при выпуске, спор будет выглядеть как «мы это не заказывали». Если обсудили заранее, можно отдельно оценить сложность и решить, входит ли защита от одновременной записи в ближайший результат.
Подробнее о критериях приёмки — с позитивными и негативными сценариями проверки.
Как разделить большую историю
Фраза «хочу управлять всеми занятиями» включает слишком разные действия. Попробуйте выделить завершённый путь, после которого человек уже получает пользу. Для первого небольшого выпуска это выбор одного сеанса и подтверждение записи; перенос и лист ожидания можно обсудить следующими историями.
- Первая история
Выбрать свободный сеанс и получить подтверждение.
- Следующая
Перенести существующую запись на другое доступное время.
- Позже
Встать в лист ожидания при отсутствии мест.
Разрез «сначала вся база, потом весь сервер, затем весь интерфейс» описывает этапы реализации. Он может быть нужен в техническом плане, но не даёт трёх самостоятельно полезных пользовательских историй. Внутри первой истории такие технические задачи допустимы; важно не перепутать два уровня.
Не делите ради количества карточек. Если две части невозможно осмысленно показать и проверить отдельно, вероятно, граница выбрана неудачно. А если история всё ещё скрывает неизвестную интеграцию, сначала запишите вопрос и короткую исследовательскую работу.
Разговор перед передачей в работу
Автор истории, исполнитель и человек, который будет проверять результат, могут вместе пройти один обычный и один неудобный сценарий. В нашем примере это свободная суббота и последний занятый сеанс. Полезно попросить каждого своими словами описать ожидаемый результат: расхождения обнаружатся быстрее, чем при молчаливом согласовании документа.
Предположим, разработчик понял «недоступный сеанс» как скрытый, а администратор хотел видеть его серым, чтобы объяснять расписание. Оба прочитали одну фразу, но представили разное. Уточните решение и причину прямо рядом с историей. Не оставляйте их в записи созвона, которую следующий участник может не открыть.
Где сохранить рабочий результат
В Sinqly можно создать задачу «Уточнить запись на мастер-класс» и добавить в описание формулировку истории, четыре сценария проверки и явные исключения; регистрация бесплатная.
Как применить шаблон к своей задаче
Возьмите одну реальную просьбу из рабочего чата. Сначала выпишите её дословно, затем отдельно ответьте: кто столкнулся с трудностью, что он пытается сделать и по какому признаку поймёт, что получилось. Только после этого составьте историю. Такой порядок снижает риск аккуратно оформить уже выбранную, но ненужную функцию.
Сохраните исходную просьбу рядом с новой формулировкой: это поможет объяснить, почему решение изменилось. После демонстрации спросите не только «всё ли по списку», но и «получился ли нужный результат». Успешная проверка требований ещё не доказывает, что первоначальная гипотеза о потребности была верной.
Что ещё стоит уточнить
User story — это техническое задание?
Нет. История кратко задаёт потребность и ценность. Требования к поведению, ограничения, макеты и технические решения могут дополнять её отдельными материалами.
Кто пишет пользовательские истории?
Тот, кто помогает сформулировать потребность: владелец продукта, аналитик или другой участник. Важнее совместное обсуждение, чем должность автора.
Нужна ли формула «Как… хочу… чтобы…» всегда?
Нет. Сохраняйте роль, действие и смысл, но не жертвуйте понятностью ради шаблона.
Помогло разобраться?
Оцените статью и расскажите, чего не хватило. Отзыв увидит редакция Sinqly — он не появится на сайте.
Источники и примечания
- Atlassian: user stories
- Предлагаемый порядок — редакционная практика, а не обещание одинакового результата для всех.
Критерии приёмки задачи: как написать и проверить, с примерами
Наблюдаемые условия вместо «сделать хорошо»: критерии приёмки формы, позитивные и негативные сценарии, границы задачи и разбор спорного результата.
Job story: формула, примеры и отличие от user story
Как описать ситуацию, мотивацию и желаемый результат в job story. Разбираем перенос записи, отличаем гипотезу от факта и не прыгаем сразу к функции.
User story mapping: как собрать карту пользовательских историй
Карта пользовательских историй на примере мастерской: путь посетителя, карточки действий, первый сквозной выпуск и ошибки нарезки релизов.