Цитаты из книги «Управление продуктом в Scrum. Agile-методы для вашего бизнеса»

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

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

«Риск — сущностная характеристика инновационного продукта. Каждое решение, касающееся проекта (принимается оно явно или по умолчанию), связано с рисками», — пишут Смит и Мерритт (Smith and Merritt, 2002; 4).

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

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

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

Этой информации достаточно, чтобы понять, что нужно для производства продукта, при этом содержание бэклога не замусоривается лишними деталями. Темы создают иерархию в бэклоге, который теперь помимо индивидуальных элементов содержит и их группы. Вдобавок полезно провести дальнейшее разграничение между обобщенными требованиями, например эпиками, и детализированными элементами, например историями. Пример такого бэклога частично приведен в таблице 3.1. Таблица 3.1. Образец бэклога продукта Тема Обобщенный элемент Детализированный элемент Усилия Электронная почта Создать электронное письмо Как корпоративный пользователь, я хочу создавать тему письма 1

Темы — это будущая функ­циональность продукта. Они структурируют бэклог, помогают расставить приоритеты, делают удобным доступ к информации

Рекомендуется использовать артефакты, только если они дей­ствительно помогают scrum-команде создать работающий продукт.

Как можно догадаться по названию, это история о том, как клиент или пользователь работают с продуктом. Она содержит имя, краткую информацию и критерии приемки — условия, которые позволяют понять, реализована история или нет. История может быть обобщенной или подробной. Обобщенные истории называются эпиками.