Пользовательская история¶

Пользовательская история (от англ. user story) — это инструмент гибкой разработки программного обеспечения (Agile), описывающий одну функцию или требование к системе с точки зрения её конечного пользователя. Формулируется в виде короткого, неформального предложения на естественном языке, которое фиксирует, кто, что хочет получить и зачем. Пользовательские истории служат заменой традиционным техническим заданиям и используются для планирования итераций (спринтов) и оценки объёма работ.

¶История возникновения

Концепция пользовательских историй возникла в конце 1990-х годов в рамках методологии экстремального программирования (XP). Автором термина считается американский программист и методолог Кент Бек. В книге «Extreme Programming Explained» (1999) он описал пользовательские истории как один из ключевых приёмов XP, наряду с парным программированием и непрерывной интеграцией.

Идея заключалась в том, чтобы уйти от громоздких и формальных спецификаций требований, которые часто не отражали реальных потребностей пользователей и были сложны в поддержке. Вместо этого предлагалось фиксировать требования короткими фразами, записанными на карточках (индексных карточках), что позволяло быстро обсуждать их с заказчиком и разработчиками.

В 2000-х годах, с ростом популярности методологии Scrum, пользовательские истории стали стандартным элементом бэклога продукта (списка задач). В 2004 году Майк Кон (Mike Cohn) опубликовал книгу «User Stories Applied: For Agile Software Development», которая систематизировала практику и ввела понятия «INVEST» (критерии качества истории) и «Epic» (крупная история, требующая декомпозиции).

¶Структура и формат

Пользовательская история обычно записывается по шаблону, предложенному Крисом Мэттсом и Майком Коном:

Как <роль пользователя>, я хочу <действие или функция>, чтобы <цель или выгода>.

Примеры:

• «Как покупатель, я хочу добавить товар в корзину, чтобы оформить заказ позже».
• «Как администратор, я хочу видеть список зарегистрированных пользователей, чтобы управлять их правами доступа».

Допускаются и более свободные формулировки, но обязательными элементами являются:

• Роль (кто выполняет действие — пользователь, клиент, администратор, система).
• Действие (что именно должно быть реализовано — кнопка, форма, алгоритм).
• Цель (зачем это нужно — бизнес-ценность, решение проблемы).

¶Критерии приёмки (Acceptance Criteria)

Каждая пользовательская история должна сопровождаться набором условий, при выполнении которых она считается завершённой. Критерии приёмки записываются в виде чек-листа или сценариев в формате «Given-When-Then» (предпосылка — действие — результат). Например:

• Given пользователь авторизован, When он нажимает кнопку «Добавить в корзину», Then товар появляется в корзине, а счётчик обновляется.
• Given товар отсутствует на складе, When пользователь нажимает «Добавить в корзину», Then отображается сообщение «Товар временно недоступен».

¶Классификация и виды

Пользовательские истории различаются по размеру и детализации:

• Epic (Эпик) — крупная история, которая не может быть выполнена за одну итерацию (спринт). Требует разбивки на несколько более мелких историй. Пример: «Как пользователь, я хочу управлять своим профилем» — может включать редактирование имени, загрузку фото, смену пароля.
• Story (Собственно история) — история, выполняемая за один спринт (обычно 1–3 дня работы разработчика).
• Task (Задача) — техническая подзадача, не всегда имеющая прямую пользовательскую ценность, но необходимая для реализации истории. Например, «Настроить базу данных для хранения паролей».

Также выделяют технические истории (technical stories), которые описывают нефункциональные требования (производительность, безопасность, интеграция) и баги (дефекты), которые могут быть оформлены как истории, если требуют новой функциональности.

¶Принцип INVEST

Для оценки качества пользовательской истории используется мнемоническое правило INVEST, предложенное Биллом Уэйком:

• Independent (Независимая) — история должна быть самодостаточной и не зависеть от других историй для выполнения.
• Negotiable (Обсуждаемая) — история — это не контракт, а повод для обсуждения. Детали уточняются в процессе.
• Valuable (Ценная) — история должна приносить явную пользу пользователю или бизнесу.
• Estimable (Оцениваемая) — команда должна иметь возможность оценить трудоёмкость истории.
• Small (Маленькая) — история должна быть достаточно мала, чтобы её можно было выполнить за одну итерацию (обычно 1–3 дня работы).
• Testable (Тестируемая) — должны быть чёткие критерии приёмки, позволяющие проверить, что история выполнена.

¶Применение в Agile-процессах

Пользовательские истории являются основой бэклога продукта — упорядоченного списка всех задач, которые предстоит выполнить. В процессе планирования спринта команда (Scrum-команда) выбирает из бэклога истории, которые будут реализованы в ближайшую итерацию. Каждая история оценивается в стори-поинтах (story points) — условных единицах трудоёмкости, не привязанных к часам.

В ходе спринта разработчики уточняют детали истории в диалоге с владельцем продукта (Product Owner) и тестировщиками. После завершения истории проводится демонстрация (review) — показ работающей функциональности заказчику или стейкхолдерам.

¶Преимущества

• Ориентация на пользователя — истории формулируются с точки зрения того, кто будет использовать систему, что снижает риск создания «ненужных» функций.
• Гибкость — истории легко переставлять, менять приоритеты и добавлять новые по мере необходимости.
• Снижение бюрократии — вместо многостраничных спецификаций — короткие карточки, что ускоряет коммуникацию.
• Прозрачность — бэклог виден всей команде, что упрощает планирование и отслеживание прогресса.

¶Недостатки и критика

• Неполнота — короткие формулировки могут упускать важные детали, особенно в сложных системах. Требуется постоянное уточнение в диалоге.
• Сложность оценки — без чётких критериев приёмки трудно оценить реальный объём работы.
• Риск «распыления» — команда может сосредоточиться на отдельных историях, упуская из виду общую архитектуру и долгосрочные цели.
• Зависимость от коммуникации — если заказчик или владелец продукта недоступен, истории теряют смысл, так как детали не могут быть согласованы.

¶Примеры в реальной разработке

В российской практике пользовательские истории активно используются в IT-компаниях, работающих по Scrum или Kanban. Например, при разработке интернет-магазина:

• Epic: «Как покупатель, я хочу оплатить заказ онлайн».
• Story 1: «Как покупатель, я хочу выбрать способ оплаты (карта, электронный кошелёк), чтобы завершить покупку».
• Story 2: «Как покупатель, я хочу ввести данные карты, чтобы оплатить заказ».
• Story 3: «Как система, я хочу проверить платёж и отправить подтверждение, чтобы пользователь знал, что оплата прошла».

Каждая из этих историй имеет свои критерии приёмки и оценивается отдельно.

¶Инструменты для управления

Для ведения бэклога пользовательских историй используются специализированные системы управления проектами: Jira (Atlassian), Trello, Asana, Redmine, а также российские аналоги, такие как Yandex Tracker, Битрикс24 и Kaiten. В этих инструментах истории могут быть представлены в виде карточек с полями для описания, критериев приёмки, приоритета, оценки и статуса.

¶Источники

• Кент Бек. «Extreme Programming Explained: Embrace Change» (1999).
• Майк Кон. «User Stories Applied: For Agile Software Development» (2004).
• Билл Уэйк. «INVEST in Good Stories, and SMART Tasks» (2003).
• Scrum Guide (2020) — описание бэклога продукта и пользовательских историй.
• Статья «User Story» в Agile-методологии (сайт Scrum.org).