Цитаты из книги «Пользовательские истории. Искусство гибкой разработки ПО»

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

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

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

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

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

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

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

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

максимальный реальный результат.

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