Джефф Паттон - Пользовательские истории. Искусство гибкой разработки ПО

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

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

1. Сначала определяются высокоуровневые последовательности шагов по использованию продукта.

2. Затем последовательности шагов разбиваются на более четкие операции согласно пользовательским ролям.

3. Из пользовательских ролей выделяются конкретные пользовательские истории в формате «как < роль >, я хочу < функциональность >, что даст мне < выгоду >». Эти пользовательские истории включаются в первый вариант продуктового бэклога.

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

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

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

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

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

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

2. Масштабирование карт пользовательских историй

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

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