10 Советов По Написанию Хороших Пользовательских Историй

Здравствуйте, хабровчане.
Для будущих студентов курса «Системный аналитик.
Продвинутый уровень» подготовил перевод статьи.
Также приглашаем всех принять участие в открытом вебинаре по теме «Как разработать REST API и не умеретьЭ» .
В ходе занятия участники вместе с экспертом рассмотрят следующие моменты: • Основные преимущества и особенности REST API; • Правильное разделение ресурсов в REST API; • Наследование ресурсов и абстрактные ресурсы.

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

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

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

Отличный способ получить представление о пользователях и клиентах — работать с персонами (или персонами).
Это вымышленные персонажи, основанные на первичной информации о потенциальных клиентах.
Обычно они состоят из имени и изображения; соответствующие характеристики, поведение и отношения; и цели.
Цель — это выгода, которую персонаж хочет достичь, или проблема, которую персонаж хочет решить с помощью вашего продукта.
Но это еще не все: цели персонажа помогают определить правильный истории: спросите себя, какой функционал должен обеспечивать продукт для достижения целей персонажей (я объясняю это в своей статье ") От персонажей к пользовательским историям» .
Удобный шаблон для описания ваших персонажей вы можете скачать на сайте romanpichler.com/tools/persona-template .

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

4. Делайте свои истории простыми и краткими.

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

Нравиться Я хочу , к .

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

5. Начните с эпиков
Эpeak (Epic) – это большая, схематичная, масштабная история.
Обычно он разбивается на несколько пользовательских историй с течением времени на основе отзывов пользователей о ранних прототипах и новых продуктах.
Вы можете думать об этом как о преамбуле и временной задержке до тех пор, пока не будут рассказаны более подробные истории.
Начав с эпопеи, вы сможете обрисовать функциональность продукта, не вдаваясь в детали.
Это особенно полезно для описания новых продуктов и функций: это позволяет охватить приблизительный объем и дает время узнать больше о том, как лучше всего удовлетворить потребности пользователей.
Это также сокращает время и усилия, необходимые для интеграции новых идей.
Если в вашем бэклоге продукта много подробных историй, то связывание отзывов с соответствующими элементами зачастую является сложным, трудоемким процессом и сопряжено с риском возникновения несогласованностей.

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

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

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

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

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

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

10. Не полагайтесь исключительно на пользовательские истории
Создание хорошего пользовательского опыта (UX) требует больше, чем пользовательские истории .
Пользовательские истории полезны для передачи функциональности продукта, но не подходят для описания.
путь пользователя И визуальный дизайн .
Поэтому дополняйте пользовательские истории другими методами, такими как карты-истории, диаграммы рабочих процессов, раскадровки, эскизы и макеты.
Кроме того, пользовательские истории плохо отражают технические требования.
Если вам нужно передать, что должен делать архитектурный элемент, такой как компонент или сервис, напишите технические истории или — что я предпочитаю — использовать какой-нибудь язык моделирования, например UML. Наконец, написание пользовательских историй имеет смысл при разработке программного обеспечения, которое, скорее всего, будет использоваться повторно.
Но если вы хотите быстро создать уникальный прототип или макет для проверки идеи, писать истории может и не понадобится.
Помните: пользовательские истории не связаны с документированием требований; их цель — дать вам возможность действовать быстро и разрабатывать программное обеспечение как можно быстрее, не создавая при этом каких-либо значительных накладных расходов.

Узнайте больше о курсе «Системный аналитик.
Продвинутый уровень» .
Посмотрите открытый вебинар по теме «Как разработать REST API и не умеретьЭ» .