Что такое User Story
User Story — краткое описание потребности или цели пользователя, которое помогает команде обсудить ожидаемый результат и определить условия его принятия. По-русски этот термин переводят как «пользовательская история», но в профессиональной работе часто используют английское название.
Короткая формулировка не должна самостоятельно отвечать на каждый вопрос о будущей функции. Она задаёт направление разговора: кто хочет получить результат, что ему нужно и зачем. Подробности появляются при обсуждении контекста, правил, ограничений, интерфейса и критериев приёмки.
Поэтому User Story не следует воспринимать как полную спецификацию или обязательный артефакт любого процесса разработки. Команда может использовать требования, Use Cases, сценарии или другие способы описания работы. Практическая ценность Story состоит в том, что она удерживает внимание на потребности пользователя и помогает не подменить её перечнем технических операций.
User Story и пользовательская потребность
Потребность обычно возникает раньше готовой формулировки. Например, руководителю нужно передавать работу конкретному сотруднику. Это ещё не описание интерфейса и не задача разработчику. Сначала необходимо понять роль, желаемый результат и ценность, а затем уточнить поведение.
User Story фиксирует суть этой потребности в компактной форме. Критерии приёмки выполняют другую функцию: описывают согласованные, наблюдаемые условия, по которым можно принять конкретную Story. Вместе с контекстом и правилами они превращают исходную идею в постановку, пригодную для обсуждения, реализации и проверки.
Из чего состоит User Story
Для первой формулировки удобно использовать распространённый шаблон:
Как [роль], я хочу [действие или результат], чтобы [получить ценность].
Например:
Как руководитель проекта, я хочу назначить исполнителя задачи, чтобы передать работу конкретному участнику команды.
Роль, действие и ценность
Роль показывает, с чьей точки зрения рассматривается потребность. Формального слова «пользователь» часто недостаточно. Если руководитель назначает работу, исполнитель выполняет её, а администратор управляет доступом, у этих ролей разные цели и ожидаемое поведение. При этом не нужно придумывать отдельную роль, если различие никак не влияет на потребность или функцию.
Действие или результат следует описывать на уровне пользовательской цели. Формулировка «вызвать метод обновления записи» говорит о реализации, но не объясняет, чего хочет человек. «Назначить исполнителя задачи» оставляет команде возможность обсудить решение и одновременно задаёт понятный результат.
Ценность отвечает на вопрос «зачем?». В примере назначение нужно не ради заполнения поля, а чтобы передать работу конкретному участнику. Если часть «чтобы» просто повторяет действие — например, «хочу назначить исполнителя, чтобы исполнитель был назначен», — она не добавляет смысла. Лучше уточнить реальную пользу или убрать искусственное продолжение.
Шаблон — это подсказка, а не определение Story
Форма Как… я хочу… чтобы… помогает не забыть роль, потребность и ценность. Но точное соблюдение синтаксиса не гарантирует хорошую Story, а другая ясная формулировка не становится неправильной только из-за отсутствия шаблона.
Не стоит помещать в одно предложение все поля, проверки, исключения и варианты поведения. Короткая Story должна оставаться понятной. Дополнительные сведения сохраняются рядом — в критериях приёмки, бизнес-правилах и связанных требованиях.
Как выбрать границы User Story
Границы определяются не количеством слов и не размером карточки в трекере. Полезно выделить один понятный пользовательский результат, который команда может содержательно обсудить и проверить. Если формулировка объединяет независимые цели, требует множества несвязанных правил или не позволяет увидеть законченный результат, стоит рассмотреть разделение.
Один понятный пользовательский результат
Сравним две версии примера:
Широкая Story: Как руководитель проекта, я хочу создать задачу и назначить исполнителя, чтобы передать работу конкретному участнику команды.
Узкая Story: Как руководитель проекта, я хочу назначить исполнителя задачи, чтобы передать работу конкретному участнику команды.
Во второй версии создание или существование задачи становится контекстом, а предметом обсуждения остаётся назначение исполнителя. Так проще отдельно выяснить, кого можно выбрать, обязательно ли назначение, можно ли его изменить и где отображается результат.
Широкая и узкая Story
Узкая формулировка не всегда автоматически лучше. Если для пользователя создание задачи без назначения не имеет самостоятельного результата, а команда действительно реализует и принимает весь сценарий как одно целое, широкая Story может быть оправдана. В другом проекте создание задачи и назначение сотрудника могут иметь разные правила, права и сроки реализации — тогда разделение делает работу яснее.
Два действия рассматриваются как один пользовательский результат.
Создание задачи остаётся контекстом, а назначение получает отдельные правила и критерии.
При выборе границ задайте несколько вопросов:
- содержит ли Story один различимый пользовательский результат;
- можно ли объяснить её ценность независимо от соседних функций;
- достаточно ли она компактна для обсуждения;
- можно ли сформулировать наблюдаемые критерии принятия;
- не скрываются ли внутри несколько разных ролей или целей.
Ответы не дают механического решения, но помогают увидеть, почему Story разрастается.
Как проверить границы Story: INVEST
INVEST можно использовать как дополнительный чек-лист для разговора о качестве и границах Story:
- Independent — насколько Story независима от других;
- Negotiable — остаётся ли предметом обсуждения, а не жёстким преждевременным решением;
- Valuable — выражает ли ценность для пользователя или заинтересованной стороны;
- Estimable — достаточно ли команда понимает работу, чтобы оценить её;
- Small — разумен ли объём для выбранного процесса;
- Testable — можно ли проверить ожидаемый результат.
Это не стандарт соответствия и не автоматический тест «хорошая или плохая Story». Для примера с исполнителем особенно полезны Valuable, Small и Testable: узкая Story сохраняет ценность передачи работы, ограничивает предмет обсуждения одним результатом и позволяет задать конкретные проверки. Independent помогает заметить зависимость от существования задачи, но не требует искусственно устранять любой контекст.
Типичные ошибки при написании User Story
Грамматически правильная фраза может оставаться бесполезной для команды. Чаще всего проблема возникает в одном из следующих мест.
Техническая задача вместо потребности
Формулировка «Как пользователь, я хочу добавить поле assignee_id в таблицу» описывает предполагаемую реализацию, а не пользовательский результат. Если способ хранения данных не является обязательным ограничением, Story лучше начать с потребности: назначить ответственного и передать ему работу.
Слишком общая роль тоже скрывает смысл. «Пользователь хочет назначить пользователя» не объясняет, кто имеет право выполнять действие и зачем оно ему. Но и чрезмерная детализация роли не нужна, если она не меняет поведение.
Несколько результатов и формальная ценность
В одной Story иногда объединяют создание задачи, назначение, уведомление, смену статуса и отчётность. Это может оказаться целым сценарием, состоящим из нескольких независимо обсуждаемых результатов. Длинный список условий внутри предложения делает ситуацию ещё сложнее.
Другой симптом — формальная ценность: «чтобы использовать функцию назначения». Она повторяет действие и не объясняет пользу. Полезнее назвать результат для человека или процесса.
Наконец, Story без критериев может звучать убедительно, но оставлять разные ожидания у заказчика, аналитика и разработчика. Правильный шаблон не заменяет обсуждение поведения и способа проверки.
Практическое продолжение этой темы — материал о том, почему User Story стоит начинать с потребности пользователя.
Что добавить к User Story для разработки
Короткая Story фиксирует роль, потребность или результат и ценность. Для разработки рядом с ней обычно нужны сведения, которые не стоит пытаться вместить в одно предложение.
Контекст, условия и бизнес-правила
Контекст описывает исходную ситуацию: задача уже существует или создаётся в текущем сценарии, кто открыл карточку и какое состояние у объекта. Условия и бизнес-правила отвечают на вопросы о доступности действий и допустимых значениях. Ограничения определяют границы решения, а исключения — ожидаемое поведение в особых случаях.
Для назначения исполнителя аналитик может выяснить:
- кого разрешено выбирать;
- обязательно ли указывать исполнителя;
- кто может изменить назначение;
- что происходит, если значение не выбрано;
- где после сохранения отображается ответственный;
- нужно ли дополнительно уведомлять назначенного сотрудника.
Ответы зависят от проектируемой системы. Само наличие поля в интерфейсе их не доказывает.
Что не нужно помещать в одно предложение
Не все условия являются критериями приёмки. Например, правило о допустимых ролях может храниться как самостоятельное требование, а критерий показывает, как согласованное правило наблюдается при проверке. Техническое ограничение интеграции тоже может быть существенным, но оно не обязано становиться частью фразы Как… я хочу… чтобы….
Хорошая структура сохраняет Story читаемой, а детали — доступными рядом. Команда видит потребность, может найти связанные правила и понимает, по каким критериям принимать результат.
Как сформулировать критерии приёмки User Story
Критерии приёмки описывают согласованные, наблюдаемые условия, по которым можно принять конкретную Story. Они превращают общее ожидание в проверяемое поведение: при каких условиях пользователь действует, что он делает и какой результат должен увидеть.
Наблюдаемый результат и значимые исключения
Начните с успешного пути, затем добавьте важные альтернативы и исключения. Не нужно перечислять любую теоретически возможную ситуацию. Критерии должны покрывать решения, существенные для ценности Story, границ функции и приёмки.
Для учебного примера список может выглядеть так:
- руководитель может выбрать исполнителя в карточке задачи;
- после сохранения выбранный исполнитель отображается в карточке;
- ранее выбранного исполнителя можно изменить, если такое изменение разрешено согласованными правилами;
- если назначение необязательно, задача сохраняется без исполнителя.
Это проектируемое поведение примера, а не утверждение о текущей реализации TaskForMe. Перед разработкой команда должна отдельно решить, кого можно выбирать, обязательно ли назначение и кому доступно изменение.
Фиксированного правильного количества критериев нет. Их должно быть достаточно для основного поведения и значимых исключений. Если список становится чрезмерно длинным или распадается на несколько независимых групп, полезно снова проверить границы Story.
Формулируйте ожидаемый результат так, чтобы его можно было наблюдать: значение показано в сохранённой карточке, действие недоступно, появилось понятное сообщение. Указание внутренней функции, таблицы базы данных или алгоритма требуется только тогда, когда технология действительно является частью ограничения.
Критерии в формате Given / When / Then
Given / When / Then — один из способов явно разделить исходный контекст, событие и ожидаемый результат:
Дано: руководитель редактирует задачу.
Когда: он выбирает исполнителя и сохраняет изменения.
Тогда: выбранный исполнитель отображается в сохранённой карточке.
В Gherkin Given задаёт известное начальное состояние, When описывает действие или событие, а Then — наблюдаемый результат. Такая структура помогает заметить пропущенное условие и не смешивать действие с результатом.
Однако критерии приёмки не обязаны быть записаны только в этом формате. Для простой Story ясный маркированный список может читаться лучше. Использование слов Given, When и Then также не превращает текст в автоматизированный тест: для исполняемого сценария потребуются соответствующие инструменты и реализация проверок.
От потребности к проверяемой User Story: пример TaskForMe
Рассмотрим на примере TaskForMe, как одна пользовательская потребность постепенно превращается в проверяемую постановку функции. Этот кейс демонстрирует метод; он не утверждает, что функция исторически проектировалась в Prototype Story Builder.
Потребность и роль
Исходная потребность звучит так:
Руководителю нужно передавать работу конкретному сотруднику.
Роль важна, потому что именно руководитель распределяет работу и отвечает за назначение. Ценность состоит не в заполнении поля, а в том, чтобы конкретный участник команды получил ответственность за задачу.
Выбор границ Story
Первая формулировка может объединять два действия:
Как руководитель проекта, я хочу создать задачу и назначить исполнителя, чтобы передать работу конкретному участнику команды.
Она допустима, если команда воспринимает создание и назначение как один законченный результат. Для учебного примера сузим границу, чтобы отдельно разобрать правила назначения:
Как руководитель проекта, я хочу назначить исполнителя задачи, чтобы передать работу конкретному участнику команды.
Теперь существование или создание задачи — исходный контекст, а назначение исполнителя — предмет Story.
Контекст интерфейса и аналитические вопросы
В карточке задачи предусмотрено поле выбора ответственного. Этот экран показывает, где пользователь взаимодействует с функцией, но сам по себе не отвечает на вопросы о поведении.
Аналитику необходимо выяснить:
- можно ли выбрать любого пользователя или только участника проекта;
- является ли назначение обязательным;
- кто может назначать и менять ответственного;
- что система показывает после сохранения;
- как ведёт себя задача без исполнителя;
- возникает ли уведомление или другое связанное действие.
Условия, правила и критерии приёмки
Для демонстрации примем несколько проектируемых условий: задача уже создана; руководитель может выбрать активного участника проекта; выбранное значение сохраняется и отображается в карточке. Эти решения нужны, чтобы показать ход анализа. Они не являются подтверждением фактического runtime-поведения TaskForMe.
В Prototype Story Builder сведения можно разнести по точным полям: Действие пользователя, Результат в системе, Условия, Как проверить. В области Текст US показывается собранное представление введённого сценария.
Критерии можно сформулировать наблюдаемым образом:
- Руководитель открывает карточку существующей задачи и выбирает исполнителя.
- После сохранения выбранный исполнитель отображается в карточке.
- При повторном редактировании руководитель видит сохранённое значение и может изменить его, если это разрешено правилами.
- Если назначение необязательно, карточка сохраняется без исполнителя; если обязательно — система не сохраняет её и сообщает, что нужно заполнить поле.
Последний пункт содержит альтернативы. До передачи в разработку команда должна выбрать одно согласованное поведение, а не оставлять обе версии как неопределённость.
Проверяемая постановка функции
В результате короткая Story остаётся читаемой и объясняет потребность. Рядом находятся интерфейсный контекст, принятые условия, правила и критерии. Разработчик понимает, какое поведение требуется, а участники приёмки знают, что наблюдать после выбора и сохранения.
Если нужно подробнее разобраться, как проверять экраны и поведение до фиксации требований, прочитайте материал о прототипировании программного обеспечения.
Как связать User Story с прототипом и техническим заданием
Story, критерии и интерфейс можно хранить в разных инструментах. В таком процессе команде необходимо отдельно поддерживать связи между ними, чтобы не потерять контекст изменений и согласования. Работа со связанным контекстом после изменения подробнее разобрана в материале об управлении требованиями. Другой вариант — сохранять описание поведения рядом с проектируемым элементом.
User Story в контексте элемента интерфейса
В Prototype Story Builder действие пользователя, результат в системе, условия и критерии сохраняются в контексте соответствующего экрана и элемента проекта. PSB собирает представление Story из заполненных пользователем полей, но не придумывает за аналитика потребность, правила или способ проверки.
Такая связь помогает увидеть, к какому полю или действию относится постановка. Она не означает автоматическую смысловую синхронизацию: если решение изменилось, содержание связанных описаний необходимо проверить и при необходимости обновить.
Переход к документации
User Stories и критерии из заполненного проекта могут войти в сохранённую версию документации. Её можно скачать в Markdown или Word .docx. Сохранённая версия фиксирует состояние данных на момент создания и не переписывается автоматически после последующих изменений проекта.
Подробнее о составе, подготовке и версиях документа читайте в материале о техническом задании на разработку ПО.
Частые вопросы о User Story и критериях приёмки
Что такое User Story?
Это краткое описание потребности или цели пользователя, которое помогает команде обсудить ожидаемый результат и условия его принятия. Story не обязана содержать всю спецификацию функции: контекст, правила и критерии можно хранить рядом.
Кто должен писать User Stories?
Единственной обязательной должности-автора нет. Потребность может исходить от пользователя, заказчика или владельца продукта; оформить Story может аналитик, Product Owner или другой участник. Важно уточнить её с людьми, которые понимают потребность, реализацию и способ проверки.
Как правильно написать User Story?
Назовите роль, потребность или желаемый результат и ценность. Выберите границу одного понятного пользовательского результата, затем отдельно зафиксируйте необходимый контекст, правила, ограничения и критерии приёмки. Проверьте, одинаково ли участники понимают формулировку.
Обязательно ли использовать шаблон «Как…, я хочу…, чтобы…»?
Нет. Это распространённая подсказка, помогающая назвать роль, действие или потребность и ценность. Качество Story определяется не точным соблюдением шаблона, а ясностью цели, разумными границами, контекстом и возможностью проверить результат.
Чем User Story отличается от требования, Use Case и задачи на разработку?
User Story фокусирует обсуждение на пользовательской потребности и ценности. Требование выражает конкретную потребность, условие или ограничение. Use Case обычно подробнее раскрывает взаимодействие и альтернативные сценарии. Задача на разработку описывает конкретную работу команды. Эти артефакты могут быть связаны, но не являются универсально взаимозаменяемыми.
Как понять, что User Story слишком большая?
Проверьте, не объединяет ли она несколько независимых результатов, ролей или групп правил. Другие признаки — сложность содержательного обсуждения, слишком большой набор несвязанных критериев и невозможность принять результат как единое целое. Это повод обсудить разделение, а не автоматический запрет на широкую Story.
Что такое критерии приёмки и сколько их должно быть?
Это наблюдаемые условия, по которым можно проверить согласованное поведение конкретной Story. Критериев должно быть достаточно для основного результата и значимых исключений; универсального количества нет. Чрезмерный список может быть сигналом, что границы Story стоит пересмотреть.
Чем критерии приёмки отличаются от Definition of Done?
Критерии относятся к ожидаемому поведению и условиям принятия конкретной Story. Definition of Done в Scrum задаёт общие условия качества завершённого Increment. Эти понятия дополняют, но не заменяют друг друга.
Обязательно ли писать критерии в формате Given / When / Then?
Нет. Формат помогает разделить начальное условие, действие и наблюдаемый результат, но ясный список тоже подходит. Слова Given, When и Then сами по себе не превращают критерий в автоматизированный тест.
Как Prototype Story Builder связывает User Story с прототипом и техническим заданием?
Для элемента прототипа можно описать действие пользователя, результат в системе, условия и критерии проверки. Эти сведения сохраняются в контексте соответствующего экрана и элемента и могут войти в сохранённую версию документации проекта в Markdown или Word .docx. Содержание формируется из заполненных пользователем данных: PSB не придумывает потребность, правила и критерии автоматически.