'/%3e%3cpath%20d='M83.8172%20112C100.688%20112%20111.886%2098.2694%20112%2083.8882H44.0245C25.8409%2083.8882%2016.001%2094.3169%2016.001%20112H83.8172Z'%20fill='url(%23paint1_linear_101_577)'/%3e%3cpath%20d='M44.1725%2044.1138H16.0008C15.9465%2051.0963%2018.504%2058.2306%2024.2977%2064.0225L44.1706%2083.8881L52.8986%2075.3569L61.7636%2066.7019C63.2767%2065.2244%2063.2786%2062.7888%2061.7636%2061.3094L44.1725%2044.1138Z'%20fill='%233A5FFF'/%3e%3cpath%20d='M83.8248%2083.8862H111.996C112.051%2076.9037%20109.493%2069.7693%20103.7%2063.9774L83.8267%2044.1118L75.0986%2052.6431L66.2337%2061.2981C64.7206%2062.7756%2064.7187%2065.2112%2066.2337%2066.6906L83.8248%2083.8862Z'%20fill='%233A5FFF'/%3e%3cdefs%3e%3clinearGradient%20id='paint0_linear_101_577'%20x1='16.001'%20y1='30.055'%20x2='111.998'%20y2='30.055'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%2370ADFE'/%3e%3cstop%20offset='0.62'%20stop-color='%233A5FFF'/%3e%3c/linearGradient%3e%3clinearGradient%20id='paint1_linear_101_577'%20x1='111.998'%20y1='97.9451'%20x2='16.001'%20y2='97.9451'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%2370ADFE'/%3e%3cstop%20offset='0.62'%20stop-color='%233A5FFF'/%3e%3c/linearGradient%3e%3c/defs%3e%3c/svg%3e)
Пользовательская история
User Story — формат описания требований, придуманный в XP (Extreme Programming) и взятый Scrum'ом. Классическая формула:
Как [роль пользователя],
я хочу [возможность],
чтобы [получить пользу].
Пример: «Как новый пользователь, я хочу видеть видео-туториал на главной, чтобы быстро разобраться с продуктом».
У хорошей User Story есть три качества (мнемоника INVEST):
- Independent — независима от других историй
- Negotiable — детали можно обсуждать
- Valuable — даёт ценность пользователю
- Estimable — можно оценить трудоёмкость
- Small — помещается в один спринт
- Testable — можно проверить готовность
К каждой User Story прилагаются Acceptance Criteria — критерии, по которым команда понимает, что история выполнена.
Когда применять и когда нет
Применять
- Работаете в Scrum или Kanban
- Хотите ставить требования с фокусом на пользу для пользователя
- Нужна гибкость в обсуждении деталей реализации
Не применять
- Чисто технические задачи (рефакторинг, миграция БД) — лучше использовать формат Task
- Зарегламентированные процессы со строгими ТЗ
Примеры применения
«Как менеджер по продажам, я хочу видеть стадию каждой сделки на канбан-доске, чтобы быстро понимать, какие сделки требуют внимания.»
Acceptance Criteria:
• На странице «Сделки» отображается канбан-доска с колонками по стадиям воронки.
• Сделки можно перетаскивать между колонками.
• При перетаскивании отправляется событие в аналитику.
Часто задаваемые вопросы
ТЗ описывает как сделать (детали реализации), User Story — зачем (польза для пользователя). Детали реализации обсуждаются командой при работе над историей, а не фиксируются заранее.
Конкретные проверяемые условия: «при клике на X происходит Y», «поле Z обязательно для заполнения», «ошибка отображается красным». Это чек-лист для приёмки.
Чаще всего — в Story Points (по шкале Фибоначчи: 1, 2, 3, 5, 8, 13). Если история больше 13 — её надо разбить на меньшие.