Как писать качественные пользовательские истории

Анна Мининкова, менеджер мобильной аналитики в JetSmarter, написала колонку специально для Нетологии о том, как использовать пользовательские истории для разработки требований продукта.

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

Как роль/персона юзера я что-то хочу получить с такой-то целью.

Часто команды задаются вопросом: зачем работать над документацией вообще, если можно просто создать задачи в трекере и сразу начать внедрять новый функционал?

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

И если формат традиционной нарративной функциональной спецификации позволяет легко потерять ценность за событие «по нажатию на кнопку X должно происходить событие Y», то формат пользовательской истории: «Как роль/персона пользователь я что-то хочу получить с такой-то целью», позволяет команде задуматься над этой ценностью на самом раннем этапе.

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

История — это результат обсуждения команды разработки и бизнес-пользователей, который фиксируется в максимально ненагруженной форме.

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

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

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

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

    Текст истории должен объяснять действия пользователя, его потребность и результат, на который он надеется.

    Как роль/персона юзера я что-то хочу получить с такой-то целью.

    Чтобы понять, хорошей ли получилась пользовательская история очень удобно использовать следующий чек-лист:

    • Разработка этой истории относительно независима. Чем больше программных зависимостей и ограничений, тем сложнее будет спланировать разработку такой истории.
    • Ценность. Финальная часть конструкции «я хочу что-то получить с такой-то целью» должна содержать цель, которую вся команда признает важной и осмысленной.
    • История должна быть легко оцениваема. Если она слишком большая или слишком размытая, чтобы оценить, то ее стоит разбить на меньшие части.
    • Разработка не должна занимать больше недели. Иначе ее придется дробить на составляющие.
    • Критерии приемки должны быть довольно четкими, чтобы по ним можно было протестировать продукт.

    Распространенные ошибки в пользовательских историях

    История для пользователя

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

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

    У этих пользователей будут совершенно разные ожидания от системы. Ошибка этой истории — невнимание к роли пользователя в ней.

    История для разработчика

    Пример: «Как разработчик я хочу перейти на программную библиотеку Х, чтобы у меня была последняя версия библиотеки Х»

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

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

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

    Перепишите ее с пользовательской точки зрения: «Как рекламодатель я хочу, чтобы система позволяла создавать мне папки, чтобы я мог быстрее работать с большими списками объявлений»

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

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

    При этом к такой истории гораздо проще написать критерии приемки:

    • «Пользователь не должен видеть задержки после создания спецпредложения при нормальной скорости интернета».

    Никакой бизнес-ценности для пользователя

    Пример: «Как администратор системы я хочу чтобы у меня была возможность сортировать спецпредложения».

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

    Практические советы по написанию пользовательских историй

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

    Порочные практики

    • Формализм

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

    • Отсутствие обсуждений

    Без обсуждения истории с командой очень легко пропустить мелкие детали или создать неправильное представление о задаче. Лучше потратить время на старте, когда не написано ни строчки кода, чем спохватиться в середине проектирования.

    • Перевес в пользу технических историй

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

    Мнение автора и редакции может не совпадать. Хотите написать колонку для «Нетологии»? Читайте наши условия публикации.

    Комментирование и размещение ссылок запрещено.

    Комментарии закрыты.

    Translate »