Методология User Story

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

Подход помогает командам сосредоточиться на потребностях пользователей и создавать более ценные и удобные продукты.

Также повышается прозрачность передачи информации от заказчика вперёд по цепочке производства вплоть до доставки функциональности на прод.

Проблемы ТЗ для продуктовой разработки

1. Потеря ценности
• При передаче бизнес требований от одного человека к другому низкоописанные требования будут заполнены фантазиями и галюцинациями исполнителя.
2. Трата времени
• Для повышения понимания поставленной задачи исполнителям нужно будет больше коммуницировать с заказчиком.
3. Потеря качества
• Невозможно низкодекомпозированную задачу реализовать без потери всех аспектов.

Основные компоненты User Story

Пользовательская история обычно включает следующие элементы:

1. Роль пользователя
• Кто является конечным пользователем (например: покупатель, продавец-консультант).
2. Действие
• Что пользователь хочет сделать (например: купить товар со скидкой 11.11, повысить продажи во время акции 11.11).
3. Цель
• Зачем это нужно пользователю (например: закрыть потребность меньшими затратами, обеспечить уровень продаж в низкий сезон).

Дополнительно, каждая история должна содержать критерии приемки, которые определяют условия, при которых задача считается выполненной.

Принципы написания User Story

Для создания эффективных пользовательских историй часто используется акроним INVEST:

• Independent (Независимость)
• Истории должны быть независимыми друг от друга.
• Negotiable (Обсуждаемость)
• Истории должны быть гибкими и поддаваться изменениям.
• Valuable (Ценность)
• Каждая история должна приносить реальную/оцениваемую ценность пользователю.
• Estimable (Оценимость)
• Команды должны быть в состоянии оценить время и усилия для реализации без доп консультаций во время реализации.
• Small (Маленькие)
• Истории должны быть небольшими и реализуемыми в рамках одной итерации/спринта.
• Testable (Тестируемость)
• Наличие четких критериев приемки для проверки успешности выполнения.

Процесс создания User Story

1. Определение целевой аудитории
• Понимание, для кого создается продукт.
2. Выявление потребностей пользователей
• Сбор информации через интервью и опросы.
3. Создание списка User Stories
• Формулирование кратких описаний функциональности.
4. Приоритизация историй
• Определение наиболее важных задач для пользователей и бизнеса.
• Приоритизация должны строиться на основании одного из методов, исключая субъективизм.
• Список методов можно почитать тут
5. Детализация описаний
• Добавление конкретных неделимых шагов и условий для каждой истории.

Преимущества использования User Story

1. Улучшение коммуникации
• User Stories способствуют лучшему пониманию требований между командами разработки и заинтересованными сторонами.
2. Итеративная разработка
• Истории помогают разбить проект на управляемые части, что упрощает процесс разработки в рамках Agile-методологий.
3. Фокус на пользователе
• Этот подход позволяет командам лучше понимать ожидания клиентов и адаптировать продукт под их нужды.

Хорошие пользовательские истории

1. Я, как пользователь сайта, хочу иметь возможность детально принимать результат рассчёта скидок по акции 11.11
2. Я, как пользователь, хочу иметь возможность добавлять товар в список избранных, для того чтобы в дальнейшем быстро находить его.
3. Я, как пользователь панели с правами супер-админа, хочу иметь возможность посмотреть список администраторов системы, для того чтобы наглядно видеть тех, кто имеет к ней доступ.

Плохие пользовательские истории

1. Создать страницу товара.
2. Добавить функциональность поиска.
3. Как пользователь, я хочу, чтобы продукт был лучше.
4. Я, как администратор системы, хочу иметь возможность добавлять, редактировать и удалять категории товаров, фильтровать и сортировать их. Я также хочу настраивать права доступа к этим функциям для разных ролей.

Визуализация User Story

Для этого существуют несколько подходов, один из самых простых - User Story Mapping (Карта Пользовательских Историй).

USM - это метод визуализации, основанный на User Stories.

Какие действия необходимо выполнить:

1. В любом удобном инструменте (Google Sheets, MS Excel, либо специализированных, подготовить шаблон, вот тут можно забрать пример);
2. Перенести в строку Users ранее выявленные пользовательские роли;
3. Перенести в строку Actions ранее выявленные действия: для каждой роли реализуемых действий может быть несколько;
4. Для каждого действия заполнить историю;
5. Декомпозировать реализацию истории на цепочку понятных неделимых действий;
6. Разбить реализацию таким образом, чтобы действия умещались в возможности команды в рамках релизного цикла.

В результате получается понятный, хорошо декомпозированный план, который можно передать в команду производства для реализации без риска столкнуться с неоднозначным прочтением требований