Как писать пользовательские истории: полное руководство

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

Agile-фреймворки — это популярный и эффективный способ структурировать разработку программного обеспечения и делегировать задачи. Написание пользовательских историй (не путать с написанием отзыва) — это инструмент гибкой разработки, который позволяет разработчикам понять, что нужно сделать и как выполнить требование. Это делает их очень важной отправной точкой, но это также означает, что они должны быть тщательно сконструированы. Вот что вы должны знать.

Что такое пользовательская история?

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

Итак, что именно это означает? Каждая функция программного обеспечения имеет (или должна иметь) определенную цель, когда она добавляется в проект. Эта цель должна влиять на все его развитие и на то, как оно включено в общую структуру. Разработчики могут ссылаться на эту цель всякий раз, когда это необходимо для принятия решений, особенно о том, как разбить цели и расставить приоритеты. «История пользователя» — это просто способ описать назначение функции.

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

Как написать пользовательскую историю

Шаг 1. Получите информацию

Получите информацию от владельцев, потенциальных пользователей и руководителей проектов. Сильная пользовательская история требует большого количества входных данных, чтобы быть точной. Получите от этих групп четкие объяснения того, что они хотят делать. Помните, что это не должно напрямую транслироваться в пользовательскую историю, но предоставит необходимую информацию. Владелец может сказать: «Мне нужно, чтобы люди могли платить с помощью PayPal в моем приложении», что очень полезно, но не для самой пользовательской истории.

Шаг 2. Решите, как создаются пользовательские истории

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

Шаг 3. Определите, определите, определите

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

Шаг 4. Напишите историю

Начните писать свою пользовательскую историю, она должна состоять всего из одного-двух предложений, чтобы удерживать внимание читателя. Заманчиво быть точным и техническим здесь, но общие формулировки, такие как заявления о миссии, могут быть полезными. Сделайте историю ясной и убедитесь, что ее можно решить или завершить, чтобы вы могли оглянуться назад и подтвердить: «Да, теперь пользователи могут это делать!».

Шаг 5. Разделите на дальнейшие шаги

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

Если кажется, что они займут значительно больше времени, это признак того, что нужно пересмотреть и посмотреть, нужно ли еще больше разбить и реструктурировать пользовательский опыт. Если добавляются новые требования, их также необходимо разбить на пользовательские истории. Хотя эти несколько предложений являются ядром эффективных пользовательских историй, их также можно расширять по ходу разработки. Давайте посмотрим на это поближе.

Каковы 3 C в пользовательских историях?

Карточка . Этап карточки относится к написанию пользовательских историй для команды разработчиков в одном или двух предложениях. Это называется карточкой, потому что пользовательские истории изначально записывались на каталожных карточках, и многие команды до сих пор предпочитают делать это именно так. Карта является ядром конкретных требований к программному обеспечению и отправной точкой для всех дискуссий. Также легко проверить, не слишком ли длинна ваша пользовательская история — если она не помещается на каталожной карточке, которую может прочитать каждый, ее нужно сократить.

Разговор : После того, как предложения Карты были созданы, пришло время проработать детали. Обычно это начинается с серии вопросов между разработчиками, например: «Сколько времени это займет для реализации?» или «Как мы можем включить это действие?» или «Эта пользовательская история важна здесь?» И так далее.

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

Подтверждение : Подтверждение связано с приемочными тестами, также известными как критерии приемки. Как только изменение реализовано и разработчики сообщают, что оно готово — что пользовательская история удовлетворена — пришло время его протестировать.

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

4-й С? : Интересно, что некоторые утверждают, что существует существенный 4-й C: контекст. В этом случае пользовательская история просматривается вместе с другими пользовательскими историями в более широкой структуре проекта. Здесь разработчики спрашивают, плавно ли пользовательская история дополняет другие пользовательские истории или есть пробелы — вещи, которые пользователь должен сделать или понять, но которые были упущены между пользовательскими историями.

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

Какой хороший формат для пользовательской истории?

Давайте рассмотрим два метода форматирования, которые очень полезны при создании предложений пользовательской истории. Первый очень прост: «Кто, что и почему?» В шаблоне предложения это можно описать так:

Как [Кто такой пользователь] я хочу [Чего хочет пользователь] (чтобы [Почему пользователь этого хочет]).

Этот шаблон также может быть сформулирован так: «Как [роль], я хочу [действие], (чтобы [польза])», для упрощения терминологии. Следования этому базовому формату достаточно для создания большинства пользовательских историй. Обычно это все, что вам нужно, и это может помочь сэкономить много времени при использовании для каждой пользовательской истории.

Однако иногда пользовательские истории сложнее определить в более сложных проектах. В этом случае может быть полезен второй метод шаблона пользовательской истории. Это называется INVEST, аббревиатура, которая означает:

• Независимость : истории должны быть полностью независимы друг от друга, и в результате истории должны работать вне последовательности.
• Оговорочность : Истории должны быть разработаны так, чтобы их можно было изменить во время разговорной части процесса.
• Ценность : пользовательская история должна демонстрировать четкую ценность для проекта. Если это невозможно, это может быть пустой тратой ресурсов.
• Оценка : пользовательская история должна быть измерена по ценности и приоритетам, чтобы помочь решить, над чем работать в порядке важности.
• Небольшой : пользовательские истории должны быть наименьшей единицей функциональности и в противном случае должны быть разбиты на более мелкие части.
• Тестируемый : пользовательская история должна быть изложена в проверяемом виде в процессе подтверждения.

Часто задаваемые вопросы о том, как писать пользовательские истории

Вас также может заинтересовать наше руководство о том, как написать обзор игры.