10 советов для написания хороших пользовательских историй

Резюме

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

1 пользователи на первом месте

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

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

2 Используйте персонажи, чтобы узнать правильные истории

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

Вы можете скачать удобный шаблон для описания ваших персонажей с romanpichler.com/tools/persona-template .

3 Пишите истории совместно

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

4 Сохраняйте свои истории простыми и краткими

Напишите свои истории, чтобы их было легко понять. Держите их простыми и краткими. Избегайте запутанных и неоднозначных терминов и используйте активный голос. Сосредоточьтесь на том, что важно, и опустите ненужную информацию. Шаблон помещает пользователя или клиента, смоделированного как личность, в историю и дает явное преимущество. (Он основан на популярном шаблоне Рэйчел Дэвис, но я заменил роль пользователя именем персоны, чтобы связать историю с соответствующей персоной.)

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

5 Начните с эпосов

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

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

6 уточняйте истории, пока они не будут готовы

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

7 Добавить критерии приемки

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

8 Используйте бумажные карты

Пользовательские истории появились в Extreme Programming (XP), и в ранней литературе по XP говорится о картах историй, а не о пользовательских историях . Причина проста: люди писали истории на бумажных карточках. Такой подход дает три преимущества: во-первых, бумажные карты дешевы и просты в использовании. Во-вторых, они облегчают сотрудничество: каждый может взять открытку и записать идею. В-третьих, карты можно легко сгруппировать на столе или на стене, чтобы проверить их согласованность и полноту и визуализировать зависимости. Даже если ваши истории хранятся в электронном виде, при написании новых историй стоит использовать бумажные карточки.

9 Делайте свои истории видимыми и доступными

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

10 Не полагайтесь исключительно на истории пользователей

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

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

Учить больше

Узнайте, как писать эффективные пользовательские истории и улучшить свою практику написания пользовательских историй, посетив мой семинар «Написание замечательных пользовательских историй» .