Привет, хабровчане. Для будущих студентов курса «Системный аналитик. Advanced» подготовили перевод статьи.

Также приглашаем всех желающих участвовать в открытом вебинаре на тему «Как спроектировать REST API и не умереть?». Участники вместе с экспертом на занятии рассмотрят следующие моменты:

• Основные плюсы и фичи REST API;
• Правильное разделение ресурсов в REST API;
• Наследование ресурсов и абстрактные ресурсы.

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

Аудиоверсия статьи здесь.

Скачать аудиоверсию можно здесь.

1. Пользователи прежде всего 

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

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

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

Отличный способ получить представление о пользователях и клиентах — это работа с персонажами (или персонами — persona). Это вымышленные персонажи, основанные на первичных сведениях о потенциальных клиентах. Обычно они состоят из имени и изображения; соответствующих характеристик, поведения и отношений; и цели. Цель — это выгода, которую хочет достичь персонаж, или проблема, которую персонаж хочет видеть решенной с помощью вашего продукта. 

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

3. Совместное создание историй 

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

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

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

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

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

Как <персонаж> 

я хочу <что?>,

чтобы <почему?>. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для создания хорошего пользовательского опыта (user experience, UX) требуется нечто большее, чем пользовательские истории. Пользовательские истории полезны для отражения функциональности продукта, но они не подходят для описания пользовательского пути и визуального дизайна. Поэтому дополняйте пользовательские истории другими методами, такими как карты историй (story maps), диаграммы рабочих процессов, сториборды (storyboards), скетчи и макеты. 

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

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

Узнать подробнее о курсе «Системный аналитик. Advanced».

Смотреть открытый вебинар на тему «Как спроектировать REST API и не умереть?».