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

Иногда владелец продукта пишет элементы бэклога продукта в одиночку и затем на совещании по планированию спринта вручает их команде. Такой подход укрепляет разделение на «мы» и «они»: владелец продукта здесь, а коман­да — там. Это отказ от знаний, опыта и творческого потенциала команды, который усложняет планирование спринта. Владелец продукта должен привлекать к грумингу бэклога продукта коллег по scrum-команде­.

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

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

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

Требование считается четким, если все члены scrum-команды одинаково понимают его смысл.

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

Объединение нескольких зависящих друг от друга элементов бэклога продукта в один более крупный и пере­формулирование для устранения зависимости — вот два основных метода работы с взаимозависимыми пользовательскими историями (

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

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

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