Что такое User Story и как её создать

User Story, или пользовательская история, помогает увидеть функции продукта глазами конечного потребителя. Основную часть User Story пишут кратко, без технических деталей и лишних подробностей. Главное — сделать фокус на целях и потребностях людей.

В основной части User Story обычно указывают:

● категорию, к которой относится пользователь;
● действие, которое он или она хотели бы совершить;
● результат, который ожидает получить пользователь после действия.

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

Например, сотрудники компании «Лапки Солюшнз» разрабатывают приложение для хозяев домашних животных. Пользовательская история для будущего приложения может выглядеть так: «Из-за работы я постоянно в разъездах. Как хозяин кота, я хочу иметь приложение, которое позволит видеть моего питомца, чтобы я мог убедиться, что он выглядит счастливым и здоровым».

Пользовательские истории помогают увидеть ценность функций продукта и решить несколько задач:

1. Разложить требования на понятные и выполнимые элементы
Пользовательские истории обычно описывают не продукт целиком, а отдельные его функции. Так проще подойти к решению большой задачи. Например, разработка приложения для людей с питомцами может состоять из нескольких задач:

● Разработать безопасные и удобные регистрацию и вход в приложение.
● Спроектировать опцию создания профиля, в котором можно указать породу питомца, кличку, возраст и прививки.
● Придумать, как отслеживать активность домашнего животного.

Так работает декомпозиция: сложное задание легче выполнить, если разделить его на задачи попроще. Каждую из них потом можно описать в формате User Story.

2. Упростить оценку ресурсов для разработки
Когда требования в виде критериев приёмки описаны по одной структуре, задачи легче сравнивать между собой. Так можно оценить, насколько они сложные и сколько времени могут занять.

3. Добавить ясности всей команде
С помощью пользовательских историй коллеги могут обсудить, как будет выглядеть продукт, для кого его разрабатывают и зачем. Основную часть User Story пишут простым языком, поэтому её поймут и разработчики, и менее технически подкованные участники команды.

При работе с классическим шаблоном важно придерживаться двух правил:

1. Определить, кто будет использовать продукт и с какой целью. Целью может быть конкретная проблема или задача, которую пользователи хотят решить, или информация, к которой хотят получить доступ. Например, сотрудники «Лапки Солюшнз» провели исследование и выяснили, что хозяевам питомцев важно знать, что их любимцы каждый день съедают необходимое количество корма и пьют достаточно воды.

2. Описывая действие, которое хотел бы совершить пользователь, важно не переборщить с подробностями. Не стоит писать: «Я, как владелец животного, хотел бы получать регулярные пуш-уведомления, в которых будет информация о том, когда я последний раз кормил питомца, и напоминание, что скоро нужно покормить его снова». Обилие деталей мешает увидеть альтернативное решение. Лучше вообще избегать названий элементов интерфейса в истории.

● Independent (с англ. «независимый»). В пользовательской истории лучше описывать одну или несколько независимых функций. Они должны решить проблему пользователя без помощи других инструментов. Например: «Как хозяин домашнего животного, я хочу иметь возможность записывать визиты к ветеринару, чтобы следить за здоровьем питомца и не пропускать приёмы». В этой истории описан минимум функций, которые нужны пользователю: приложение должно уметь создавать встречи с ветеринаром и напоминать о них. Эти функции не зависят от других опций и свойств приложения, поэтому их можно разработать и протестировать самостоятельно.

● Negotiable (с англ. «подлежащий обсуждению»). User Story обязательно нужно обсудить в команде и внести изменения, если потребуется. Без обсуждения есть риск, что команда разработки получит неполное представление о задаче.

● Valuable (с англ. «ценный»). В функции, которую описывает User Story, должна быть реальная ценность для пользователя. Например, возможность следить за здоровьем питомца и планировать посещение ветеринара.

● Estimable (с англ. «поддающийся оценке»). Хорошую User Story можно оценить — понять, сколько времени, ресурсов и денег займёт разработка функции.

● Small (с англ. «маленький»). История должна быть краткой и ёмкой. Объёмные истории сложнее оценить, и они могут потребовать больше ресурсов на разработку.

● Testable (с англ. «поддающийся тестированию»). С критериями приёмки команде разработки будет проще создать нужную функцию. Тестировать историю лучше за один раз — это ещё одна причина, почему в истории не должно быть много деталей.

Критерии приёмки добавляют независимо от формата User Story — это условия, которые должны быть выполнены, чтобы история считалась завершённой. Критерии приёмки в User Story — это требования к системе, которые помогают разработчикам создавать нужные функции.

Сотрудники «Лапки Солюшнз» поняли, что пользователи хотят следить за питанием своих животных. Для этой пользовательской истории возможно несколько критериев приёмки:

● Пользователь может добавлять информацию о питании своего питомца, включая тип корма, его количество и время суток.
● Приложение показывает, сколько корма питомец съел за день.
● Приложение позволяет устанавливать и отслеживать цели по питанию, включая ежедневные и еженедельные показатели.

Так выглядит общая формулировка критериев приёмки для User Story. Существуют разные способы их описания — глубина и подробность зависят от потребностей команды.

Ограничения показывают, как и в чём ограничены возможности продукта или функции. Они определяют, что невозможно, не разрешено или не может быть сделано в рамках конкретной истории.

Например, у функции для управления питанием животных могут быть такие ограничения:

● Приложение не позволяет загружать фото корма.
● Приложение не может автоматически корректировать рекомендации по приёму пищи на основе изменений веса или уровня активности питомца.