Каждая история пользователя должна быть полезной как для пользователя, так и для продукта, а описания должны быть написаны таким образом, чтобы преимущества были более понятны. Таким образом, команда разработчиков поймет, почему это должно быть реализовано.
User Story — инструкция по применению
Как правильно формулировать истории пользователей? Третья часть серии уроков об инструментах, которые помогут вам улучшить ваши продукты и жизнь ваших клиентов.
→ Вы можете прослушать аудиоверсию этой статьи на канале Listen IT.
История пользователя — это краткое описание намерений пользователя и того, что он хочет, чтобы продукт сделал для него.
Для чего применяется User Story?
- Для описания элементов бэклога
- Для лучшего понимания пользователей
- Для описания требований к продукту на понятном для всех языке: пользователей, разработчиков другие заинтересованных лиц
- Для вовлечения в процесс разработки пользователей и заинтересованных лиц
- Для построения User Story Mapping
Пользовательская история — это ответ на 3 вопроса, изложенный в одном предложении:
- Что это за пользователь?
- Какое действие он хочет выполнить в продукте или какой результат от продукта хочет получить?
- Зачем это ему?
Еще 50 инструментов для владельца продукта
Описания продуктовых практик и подходов, сгруппированные в 7 тем, Дмитрий Кустов.
Темы: Анализ рынка, сегментация, описание и исследование клиентов, разработка решений, управление очередью, управление продуктом, метрики.
Примеры пользовательских историй
И еще несколько примеров:
Типа, я хочу,
Как, я хочу, я хочу.
Как видно из примеров, ценность инструмента User Story заключается в том, что он очень гибкий — вы можете использовать его для лучшего понимания пользователей в абсолютно любой области.
Для чего применяется User Story?
Пользовательские истории помогут вам сосредоточиться на потребностях пользователей: Как они будут использовать приложение? Что они ожидают от продукта? Как он поведет себя в той или иной ситуации? Ответы на эти вопросы помогут разработчикам продуктов решить реальные проблемы клиентов. Вот некоторые из наиболее важных задач, для решения которых следует использовать пользовательские истории:
- организовать работу. Когда проект разбит на части, связанные с пользовательскими историями, каждая из них представляет собой цельную и понятную задачу. Так разработчики могут фокусироваться на каждой из них и получать измеримый результат. Так, например, мы описывали пользовательские требования с помощью дискретных User Strories для разработки платформы для онлайн-обучения. Это помогло клиенту в условиях ограниченного бюджета гибко управлять приоритетами в разработке, добавляя или исключая User Story.
- сохранить фокус на пользователе. Конечно, разработка включает себя десятки сложных задач, связанных с техническими, финансовыми и другими вопросами. Однако юзер стори — это постоянное напоминание команде о тех, для кого этот продукт создается, и направляют их работу в нужное русло. Кто такой юзер вашего приложения и как вы можете быть ему полезны? Ответы на эти вопросы помогут вам составить качественную user story .
- сплотить команду. Несмотря на то, что у каждого есть свои задачи ( дизайн, тестирование, разработка ), каждый понимает конечную цель и видит себя частью целого. Только работая сообща, можно достичь нужного пользователю результата, и пользовательские истории дают четкое понимание этого аспекта работы.
- найти свежие решения. Команда старается придумать самый приятный и интересный способ решить задачу пользователя. Часто это приводит к появлению новых интересных идей и их воплощению. Результат — полезный и уникальный продукт.
Структура User Story
Ваша история пользователя будет уникальной, поэтому вы можете рассказать ее по-своему. Тем не менее, существуют стандартные элементы в создании истории пользователя, которые помогут вам лучше «прочитать» мысли пользователя и понять его образ мышления. Эти элементы включают:
После того как вы поняли основные поведенческие модели конечного пользователя, необходимо описать его действия более подробно. Как они будут заказывать еду в вашем приложении? Что они будут искать на сайте университета? Какими критериями они будут руководствоваться при поиске врача? Опирайтесь на то, что уже существует, и старайтесь как можно точнее воспроизвести поведение пользователей. Так выглядит диаграмма сценариев, которая показывает, как будет использоваться ваш продукт:
Сценарий: Заголовок
И еще немного контекста…
тогда результат
И еще один результат…
С помощью пользовательских историй вы можете начать разрабатывать свой продукт более продуманно. Формулировать функциональные требования становится проще, вы уже видите конечный результат, и с таким пониманием вам легче его достичь.
User Story: примеры
Представьте, что вы хотите разработать приложение для телемедицины, которое позволит врачам
- я как пациент хочу созваниваться с врачами по видеосвязи, чтобы иметь возможность обсудить вопросы здоровья;
- я как пациент хочу иметь собственную медкарту, чтобы хранить всю информацию о своем здоровье в одном месте;
- я как пациент хочу оплачивать консультации в приложении, чтобы не искать для этого сторонние сервисы и обезопасить свои средства.
Для команд разработчиков, только приступивших к agile-разработке, пользовательские истории кажутся ненужным шагом. Почему бы не разделить большой (эпический) проект на несколько этапов и не заняться ими? Но с помощью историй команда получает необходимый контекст и связь между задачами и ценностью, которая исходит от этих задач.
- я как врач хочу созваниваться с пациентами по видеосвязи, чтобы иметь возможность работать из дома;
- я как врач хочу управлять своим расписанием, чтобы равномерно распределять нагрузку;
- я как врач хочу получать от пациентов медиафайлы, чтобы изучать результаты исследований и более качественно лечить людей.
Пользовательские истории имеют несколько важных преимуществ.
Зачем нужны пользовательские истории?
Когда история написана, наступает время интегрировать ее в рабочий процесс. Как правило, владелец продукта, менеджер продукта или руководитель проектной группы пишет историю, а затем отправляет ее на рассмотрение.
Во время собрания по планированию спринта или итерации команда решает, какие истории должны быть завершены в этом спринте. На этом этапе команды обсуждают требования каждой истории пользователя и связанные с ней функции. Это возможность продемонстрировать свои навыки и творческие способности и оживить историю для своей команды. После достижения согласия требования включаются в сюжет.
- Истории удерживают акцент на пользователе. Список дел поможет команде сосредоточиться на актуальных задачах, в то время как с набором историй участники смогут направить усилия на решение проблем реальных пользователей.
- Истории создают условия для совместной работы. Когда определена конечная цель, команда может совместными усилиями найти лучшее решение для клиента и лучший способ достижения этой цели.
- Истории подталкивают к поиску нестандартных решений. Истории заставляют команду подходить критически и творчески к выбору наилучшего пути достижения конечной цели.
- Истории задают динамику. Выполнив очередную историю, команда разработчиков справляется с небольшой задачей и радуется промежуточному успеху, который помогает двигаться дальше.
Работа с пользовательскими историями
На встречах рассказы оцениваются по уровню сложности или по тому, сколько времени они заняли. Команды подсчитывают очки в размерах футболок, по последовательности Фибоначчи или с помощью покерного дизайна. Размер истории должен позволять завершить ее в течение спринта. Поэтому, оценивая каждую историю, команда следит за тем, чтобы истории, которые требуют слишком много времени или затрат, были разбиты на более мелкие части.
Помните о следующих моментах при написании пользовательских историй.
После того как вы сформулировали истории пользователей, убедитесь, что они доступны всей команде.
Как написать пользовательскую историю
- Критерии готовности работы. Как правило, история считается «выполненной», когда пользователь может сделать то, что было запрошено. Тем не менее, четко сформулируйте цель.
- Краткое описание задач и подзадач. Определите, какие конкретно этапы нужно пройти и кто несет ответственность за каждый из них.
- Типы клиентов. Для кого? При наличии нескольких типов конечных пользователей желательно написать несколько историй.
- Этапы как часть цепи. Напишите историю для каждого этапа, составляющего более масштабный процесс.
- Обратная связь. Поддерживайте связь с пользователями, чтобы увидеть проблему или потребность их глазами. Зачем гадать, если можно услышать историю из уст самих клиентов?
- Время. Время — очень щекотливая тема. Многие команды разработчиков боятся поднимать вопросы о времени совсем, полагаясь на свои оценки. Истории должны выполняться за один спринт, поэтому истории, которые могут занимать недели или месяцы, следует разбивать на несколько историй поменьше. Как вариант, считайте их самостоятельными эпиками.
