В официальном Руководстве по Scrum (Scrum Guide 2020) нет термина “User Story”. Там используется понятие Product Backlog Item (Элемент Бэклога Продукта). Однако 95% Agile-команд в мире используют именно формат Пользовательских Историй. Почему? Потому что это лучший способ переключить внимание с написания требований на обсуждение сути.
User Story — это короткое, простое описание функции с точки зрения человека, которому она нужна. Это не техническое задание (ТЗ). Это приглашение к диалогу.
Формула успеха: Кто, Что и Зачем
Классический шаблон, предложенный Майком Коном, выглядит так:
Как <роль пользователя>, я хочу <действие/функция>, чтобы <ценность/выгода>.
Разберем, почему важна каждая часть:
- Роль (Кто): Мы не делаем продукт для абстрактного “пользователя”. Мы делаем его для “Администратора”, “Нового клиента” или “Забывчивого покупателя”. Это дает контекст.
- Действие (Что): Что человек пытается сделать в системе.
- Ценность (Зачем): Самая важная часть. Если вы не можете объяснить “чтобы что”, задачу, скорее всего, делать не нужно. Это фильтр от бесполезной работы.
| Плохая история (Техническая задача) | Хорошая User Story (Фокус на ценности) | Почему это лучше |
| “Сделать кнопку синей на странице входа.” | “Как пользователь с плохим зрением, я хочу, чтобы кнопка входа была контрастной, чтобы я мог легко найти её и войти в систему.” | Разработчик понимает проблему. Он может предложить не просто синий цвет, а увеличить шрифт или добавить обводку. |
| “Рефакторинг базы данных поиска.” | “Как покупатель, я хочу получать результаты поиска менее чем за 1 секунду, чтобы не тратить время на ожидание.” | Мы продаем не “рефакторинг” (процесс), а скорость (результат). Это позволяет Владельцу Продукта понять ценность инвестиции. |
| “Создать таблицу users с полями login/pass.” | “Как новый клиент, я хочу зарегистрироваться в приложении, чтобы сохранить свои настройки.” | Фокус на цели клиента, а не на структуре БД. Это дает свободу в выборе технической реализации. |
Глубокое погружение: Модель 3C и критерии INVEST
Чтобы история была действительно качественной, недостаточно просто написать одно предложение. Профессионалы используют две модели.
1. Модель 3C (Рон Джеффрис)
User Story — это не документ, а процесс:
- Card (Карточка): Физический или цифровой стикер с заголовком истории. Напоминание о том, что нужно что-то сделать.
- Conversation (Разговор): Обсуждение между Владельцем Продукта и Разработчиками. Именно здесь рождаются детали, уточнения и понимание.
- Confirmation (Подтверждение): Критерии приемки (Acceptance Criteria). Как мы поймем, что история готова? Это те самые тесты, которые должны пройти успешно.
Критерии качества INVEST (Билл Уэйк)
Хорошая история должна соответствовать шести критериям. Если хоть один выпадает — у вас будут проблемы в Спринте.
- I — Independent (Независимая): Историю можно сделать отдельно от других. Если для задачи А нужно сначала сделать задачу Б — это плохая архитектура бэклога.
- N — Negotiable (Обсуждаемая): Это не жесткий приказ. Это тема для переговоров. Разработчики могут предложить более дешевое или быстрое решение той же проблемы.
- V — Valuable (Ценная): Она приносит пользу клиенту или бизнесу. Технические задачи “ради техники” не проходят этот фильтр.
- E — Estimable (Оценимая): Команда должна понимать задачу достаточно хорошо, чтобы дать ей оценку (в Story Points или часах). Если оценить нельзя — нужен Spike (исследование).
- S — Small (Маленькая): История должна помещаться в один Спринт. А лучше — занимать не более 2-3 дней работы. Большие истории нужно декомпозировать (дробить).
- T — Testable (Проверяемая): Должны быть понятные критерии, по которым мы скажем “Сделано”. Если нельзя написать тест-кейс, задача не готова.
Резюме: Сдвиг мышления
User Story — это инструмент эмпатии. Когда вы пишете задачу в формате “сделать таблицу”, вы относитесь к разработчикам как к кодерам. Когда вы пишете “Как покупатель, я хочу…”, вы превращаете их в инженеров, решающих проблемы бизнеса.
Ключевой вывод: User Story считается готовой к разработке (Ready) не тогда, когда она красиво написана, а когда вся команда одинаково понимает, что нужно сделать, зачем это нужно и как мы это проверим.
Часто задаваемые вопросы (FAQ)
Нет. Scrum не обязывает использовать именно этот шаблон. Вы можете описывать задачи как угодно, если это понятно команде и несет ценность. Но формат User Story стал стандартом де-факто, потому что он лучше всего держит фокус на пользователе.
Ответственность за Бэклог несет Владелец Продукта (Product Owner). Однако писать истории может любой член команды. Лучшие истории рождаются в совместном обсуждении (например, на Refinement).
Есть два пути. Первый: попытаться переформулировать их через ценность (как в таблице выше). Второй: использовать “Технические истории” (Tech Stories) или Spikes. Но их количество в Спринте должно быть разумным, чтобы не потерять фокус на бизнес-ценности.
Нет. User Story это элемент Бэклога Продукта (ценность). А Task это технические шаги, которые пишут сами разработчики в Бэклоге Спринта, чтобы реализовать эту историю (например: “создать API”, “верстка макета”, “написание тестов”).
Эпик — это просто очень большая Пользовательская История, которую невозможно выполнить за один Спринт. Эпики используются для обозначения крупных целей или блоков функционала. Чтобы команда могла взять работу в Спринт, Эпик обязательно нужно декомпозировать (разбить) на несколько мелких User Stories, которые соответствуют критерию Small из модели INVEST.