Пихлер Р. - Управление Продуктом в Scrum. Agile-методы Для Вашего Бизнеса - 2017

Эту книгу хорошо дополняют:
Scrum. Революционный метод управления

проектами
Джефф Сазерленд
Deadline
Том Демарко
От хорошего к великому
Джим Коллинз
Roman Pichler
Agile Product
Management
with Scrum
Creating Products that Customers Love
Addison-Wesley
2010
Роман Пихлер
Управление
продуктом
в Scrum
Agile-методы для вашего бизнеса
Перевод с английского
Александра Коробейникова
Москва
«Манн, Иванов и Фербер»
2017
УДК 658.5.012.1
ББК 65.291.217
П36
Издано с разрешения Pearson (Addison-Wesley Professional)

На русском языке публикуется впервые
Книга рекомендована к изданию
Лианой Мартиросян и Наталией Юлдашевой
Благодарим за помощь в подготовке издания компанию ScrumTrek
в лице Алексея Пименова, Дарьи Рыжковой, Василия Савунова
и Александра Тупикова
Пихлер, Роман
П36 Управление продуктом в Scrum. Agile-методы для вашего бизне-
са / Роман Пихлер ; пер. с англ. Александра Коробейникова. —
М. : Манн, Иванов и Фербер, 2017. — 240 с.
ISBN 978-5-00100-354-0
Ядро каждой успешной команды agile-разработки — дальновидный,

мотивированный и наделенный большими полномочиями владелец про-
дукта, способный быть не просто менеджером, а членом scrum-команды,
готовым к тесному и постоянному сотрудничеству.
Роман Пихлер, один из ведущих экспертов по Scrum и agile-управле-
нию продуктом, в своей книге рассматривает все компоненты этой роли,
необходимые, чтобы привести компанию к великолепным результатам.
Его книга о том, в чем заключается роль владельца продукта, с какими
типичными сложностями и подводными камнями он сталкивается в своей
работе, как их преодолеть, а также чем agile-управление продуктом, осно-
ванное на Scrum, отличается от традиционных подходов и как эффективно
применять scrum-техники на практике.
УДК 658.5.012.1
ББК 65.291.217
Все права защищены. Никакая часть данной
книги не может быть воспроизведена
в какой бы то ни было форме без письменного
разрешения владельцев авторских прав.
Authorized translation from the English language

edition, entitled Agile product management with
Scrum: creating products that customers love,
1st edition, ISBN 978-0-321-60578-8; published
by Pearson, publishing as Addison-Wesley
Professional.
ISBN 978-5-00100-354-0 © Roman Pichler, 2010

© Перевод на русский язык, издание
на русском языке, оформление.
ООО «Манн, Иванов и Фербер», 2017
Содержание
Предисловие Джеффа Сазерленда . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Предисловие Бретта Квинера . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Предисловие . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Чем отличается agile‑управление продуктом . . . . . . . . . . . . 23
Что предлагает эта книга и кто должен
ее прочесть . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Кто такой владелец продукта? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Роль владельца продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Характеристики правильного владельца
продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Визионер и человек действия . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Лидер и командный игрок . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Пропагандист и переговорщик . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Наделенный полномочиями
и преданный делу . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Доступный и квалифицированный . . . . . . . . . . . . . . . . . . . . . 36
8 Содержание
Работа с командой . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Взаимодействие со scrum‑мастером . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Работа с клиентами, пользователями
и другими заинтересованными лицами . . . . . . . . . . . . . . . . . . . . . 41
Моделирование роли владельца продукта . . . . . . . . . . . . . . . . . 45
Главный владелец продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Иерархия владельцев продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Как правильно выбрать владельцев
продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Распространенные ошибки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Владелец продукта с недостаточными
полномочиями . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Перегруженность владельца продукта . . . . . . . . . . . . . . . 53
Частичный владелец продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Удаленный владелец продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Заместитель владельца продукта . . . . . . . . . . . . . . . . . . . . . . . . . 57
Комитет владельцев продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Вопросы для самоконтроля . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2. Планирование концепции продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Видение продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Желаемые качества видения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Общее и объединяющее . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Широкое и мотивирующее . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Краткое и приятное . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Содержание 9
Минимально функциональный продукт . . . . . . . . . . . . . . . . . . . . 68
Простота . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Бритва Оккама . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Чем меньше, тем лучше . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Простые пользовательские интерфейсы . . . . . . . . . . . . . 76
Потребности покупателя и свойства продукта . . . . . . . . . 78
Рождение видения продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Любимые проекты . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Использование Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Техники формирования видения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Прототипирование и макетирование . . . . . . . . . . . . . . . . . 84
Персоны и сценарии . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Визуализация и обзор в отраслевом журнале . . . . 88
Модель Кано . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Формирование видения и дорожная карта
продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Минимальные продукты и варианты продукта . . . . . . . . 92
Распространенные ошибки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Отсутствие видения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Пророческое видение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Аналитический паралич . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
«Мы-лучше-знаем-что-нужно-клиентам» . . . . . . . . . . . 97
«Большое — значит хорошее» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Вопросы для самоконтроля . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
3. Работа с бэклогом продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Глубинные свойства бэклога продукта . . . . . . . . . . . . . . . . . . . . . 102
Достаточная степень детализации . . . . . . . . . . . . . . . . . . . . . 102
Оценка . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Развитие . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Приоритетность . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Работа над бэклогом продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Выявление и описание элементов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Выявление элементов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Описание элементов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Структурирование бэклога продукта . . . . . . . . . . . . . . . . . 111
Расстановка приоритетов в бэклоге продукта . . . . . . . . . 113
Ценность . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Знания, неопределенность и риск . . . . . . . . . . . . . . . . . . . . . . . 116
Возможность выпуска . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Взаимозависимости . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Подготовка к планированию спринта . . . . . . . . . . . . . . . . . . . . . . . 120
Выбор цели спринта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Когда нужно и ровно столько,
сколько нужно . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Декомпозиция элементов . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Обеспечение четкости, проверяемости
и осуществимости . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Определение масштабов элементов . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Очки историй . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Покерное планирование . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Работа с нефункциональными требованиями . . . . . . . . . 135
Описание нефункциональных требований . . . . . . 136
Управление нефункциональными
требованиями . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Бэклог продукта при масштабировании . . . . . . . . . . . . . . . . . . . 138
Использование единого бэклога продукта . . . . . . . 139
Расширьте горизонт груминга . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Создайте различные видения
бэклога продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Распространенные ошибки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Замаскированная спецификация . . . . . . . . . . . . . . . . . . . . . . . . 141
Список просьб к Санта-Клаусу . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Навязывание требований . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Пренебрежение грумингом . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Конкурирующие бэклоги продуктов . . . . . . . . . . . . . . . . . 144
Вопросы для самоконтроля . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
4. Планирование релиза . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Время, затраты и функциональность . . . . . . . . . . . . . . . . . . . . . . . . 148
Стабильность качества . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Быстрые и частые релизы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Квартальные циклы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Скорость . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Диаграмма сгорания работ для релиза . . . . . . . . . . . . . . . . . . . . . 160

График сгорания работ для релиза . . . . . . . . . . . . . . . . . . . . . 161
Столбиковая диаграмма сгорания работ . . . . . . . . . . 164
План релиза . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Прогнозирование скорости . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Составление плана релиза . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Планирование релизов в больших проектах . . . . . . . . . . . 173
Общие ориентиры для оценок . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Перспективное планирование . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Конвейерная работа . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Отсутствие диаграммы сгорания работ
или плана релиза . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Владелец продукта в кресле пассажира . . . . . . . . . . . . 178
Взрывной релиз . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Работа в ущерб качеству . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
5. Совместная работа на совещаниях по спринту . . . . . . . . . . 182

Планирование спринта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Критерии готовности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Ежедневный scrum-митинг . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Спринт-бэклог и диаграмма сгорания работ
для спринта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Обзор итогов спринта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Ретроспективный анализ спринта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Совещания по спринтам в крупных
проектах . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
Совместное планирование спринта . . . . . . . . . . . . . . . . . . . 195
Scrum-совещание по Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Демонстрация результатов спринта . . . . . . . . . . . . . . . . . . 196
Совместная ретроспектива спринта . . . . . . . . . . . . . . . . . . 197
Владелец продукта — «чайка» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Незаинтересованный владелец
продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Нежизнеспособный темп . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Стремление создать иллюзию . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Включение в отчет диаграммы
сгорания задач спринта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
6. Превращение во владельца продукта . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Как стать отличным владельцем продукта . . . . . . . . . . . . . . 206
Познайте себя . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
Развитие и рост . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Найдите наставника . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Убедитесь в поддержке на нужном
уровне . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Вы еще не готовы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Как развивать владельцев продукта . . . . . . . . . . . . . . . . . . . . . . . . . . 211

Осознайте важность роли . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Выбирайте правильного владельца
продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Наделяйте владельцев продукта
полномочиями и поддерживайте их . . . . . . . . . . . . . . . . . . 213
Поддерживайте институт владельцев
продукта в компании . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Библиография . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Благодарности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Об авторе . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Посвящается Мелиссе
Предисловие
Джеффа Сазерленда
Владелец продукта — новая роль для большинства ком-

паний, и поэтому она нуждается в убедительной презен-
тации, которую и дает эта книга. Когда избирался пер-
вый владелец продукта, я был вице-президентом Object
Technology и отвечал за разработку первого продукта, со-
зданного по Scrum. Этот продукт должен был стать опреде-
ляющим для компании, и мне отводилось шесть месяцев,
чтобы создать инструмент разработки, который изменит
рынок. Помимо работы вместе с небольшой, тщательно
подобранной командой мне предстояло перестроить всю
компанию вокруг новой схемы деятельности. До поставки
продукта оставалось несколько месяцев, и было понятно,
что успех определит правильно сформированный набор
минимального функционала. Оказалось, мне не хватает
времени на разговоры с клиентами и тщательный анализ
действий конкурентов, что помогло бы точно расставить
Предисловие Джеффа Сазерленда 17
приоритеты и разложить функционал на небольшие эле-

менты для команды.
Я уже делегировал свои инженерные обязанности
первому scrum-мастеру, Джону Скамниоталесу, но мне
был необходим владелец продукта. У меня имелся до-
ступ к любым ресурсам компании, поэтому я избрал
на нужную мне роль Дона Реднера, лучшего специалис-
та из команды менеджеров продукта. Дону как первому
владельцу продукта предстояло вести его, сформировав
в уме видение перспектив, бизнес-плана и выручки, пла-
нов развития и выпуска, а главное — тщательно разрабо-
тав бэклог* продукта с расставленными для всей коман-
ды приоритетами.
Дон половину времени проводил с командой, а дру-
гую половину — с клиентами. В его задачи входило вы-
дать нужный продукт, в то время как я вместе со всей
компанией работал над неймингом и брендингом, марке-
тинговой стратегией и коммуникациями, планировани-
ем продаж и обучением, продолжая каждый день ходить
на scrum-митинги и устранять все препятствия на пути
* Бэклог (или журнал продукта) — список всех пожеланий к продук-

ту, составленный по принципу от наиболее к наименее важному.
При этом под важностью понимается совокупный показатель про-
гнозируемых трудозатрат на его реализацию. В бэклоге хранятся
элементы — это могут быть пользовательские истории, техниче
ский долг и т. д. Элементы бэклога декомпозируются на задачи
(элементарные действия, которые может сделать один человек).
Прим. науч. ред.
18 Управление продуктом в Scrum
команды. Роль Дона была гораздо серьезнее, чем обычно

у менеджера по маркетингу продукта. Внезапно он ока-
зался владельцем нового направления бизнеса. В то же
время ему приходилось глубоко вникать в работу инже-
неров, регулярно объясняя ситуацию и мотивируя со-
трудников. Полное погружение одновременно и в рынок,
и в команду — это уникальный опыт.
Степень концентрации и мера ответственности хоро-
шего владельца продукта подробно описаны в этой книге,
однако редко наблюдаются в реальных компаниях по про-
изводству продукта и IT-командах. Нам необходимо опи-
сание образцового владельца продукта, а также того, как
он исполняет эту роль. Такое руководство и подготовил
Роман Пихлер.
Джефф Сазерленд,
один из создателей Scrum
Бретта Квинера
Сегодня во всей индустрии ПО набирает силу Agile. По

следние двадцать лет многие клиенты, партнеры и со-
трудники были разочарованы тем, как мы разрабатываем
корпоративные технологические решения. Они, к сожа-
лению, часто оказывались низкокачественными, требо-
вали нескольких лет для вывода на рынок, в них нередко
отсутствовали инновации, необходимые для решения ре-
альных проблем бизнеса.
Salesforce.com стремится стать другой компанией,
ориентированной на успех клиентов и сотрудников. Мы
знали, что для организации нашего типа традиционные
методы разработки ПО неприменимы. Требовалось при-
думать иную модель и, смирив гордыню, найти лучший
вариант. Мы спросили себя: существует ли способ регу-
лярно и вовремя выдавать качественное ПО? Реально ли
часто и быстро создавать ценности для клиентов? Можно
ли внедрять инновации с такой же скоростью, с какой рас-

тет компании? Оказалось — да, можно.
Мне как главному владельцу продукта в Salesforce.com
нужно было найти максимально динамичный способ, при
помощи которого менеджеры продуктов сумеют донести
желания и потребности клиентов и бизнеса до команд
разработчиков, обеспечив к тому же обратную связь. Ис-
пользование Scrum позволяет возложить на менеджеров
продукта ответственность за создание ценности для кли-
ента. Что, в свою очередь, дает возможность направлять
команду к разработке в первую очередь наиболее важных
для бизнеса функций, чтобы как можно быстрее передать
продукт в руки покупателей. Scrum дает нужную гиб-
кость, чтобы быстро реагировать на меняющиеся условия
рынка и давление со стороны конкурентов или внедрять
новые идеи наших команд. Из этой книги вы узнаете,
чем владелец продукта отличается от традиционного ме-
неджера продукта и почему он наделен более высоким
уровнем ответственности за успех продукта. Здесь ярко
выявлен контраст между поведением специалиста в тра-
диционной и agile-моделях.
Многие пытались объяснить роль владельца продук-
та, но никому это не удалось так, как Роману Пихлеру.
Он убедительно рассказывает о теории и практике гиб-
кого управления продуктом, которые помогают владель-
цам продукта, членам scrum-команд и руководителям
Предисловие Бретта Квинера 21
внедрять инновации. Роман приводит множество приме-

ров из деятельности таких конкурентоспособных инно-
ваторов, как Salesforce.com, а также доходчиво объясняет,
как создать и обеспечить надежную работу минимальной
функциональности при инновациях. Он обращает внима-
ние и на часто встречающиеся ошибки владельцев про-
дукта.
В современной динамичной и конкурентной среде
требования клиентов высоки как никогда. Гибкий под-
ход, которого мы придерживаемся в Salesforce.com, де-
монстрирует отличные результаты, наши владельцы про-
дукта выдают все больше инноваций и создают ценности
для покупателей. Если вы хотите добиться такого же ре-
зультата, то эта книга для вас. Проверенные инструмен-
ты, методы, ценные советы — все это поможет на пути
к успеху — вашему и ваших клиентов.
Бретт Квинер,
старший вице-президент
по продукту Salesforce.com
По гибкой разработке ПО и управлению продуктом на-

писано много отличных книг. Однако до сих пор нет ис-
черпывающего описания того, как оно работает. Кажется,
что agile-адепты стараются ускользнуть от ответа на этот
вопрос, а специалисты по управлению продуктом до сих
пор силятся понять этот дивный agile-мир. Сейчас все
больше компаний берут на вооружение Scrum, и вопрос
о специфике управления продуктом в scrum-среде стано-
вится очень актуальным. В этой книге делается попытка
на него ответить.
В 1999 году я познакомился с agile- и деологией, и ме
ня поразило тесное сотрудничество между техническими
и бизнес-специалистами и технарями. Я всегда считал,
что разработка ПО — это то, что интересует гиков*,
* Гик — человек, чрезвычайно интересующийся чем-либо, фанат.

Первоначально так называли людей, увлеченных высокими техно-
логиями (обычно компьютерами и гаджетами). Прим. ред.
Предисловие 23
но не бизнесменов. Занимаясь коучингом своего первого

agile-проекта в 2001 году, я прежде всего старался помочь
менеджерам продукта перейти к миру гибких методоло-
гий. С тех пор владение продуктом всегда оставалось са-
мым большим вызовом для компании и определяло успех
всего предприятия. Так было во всех компаниях, которые
я консультировал, и это помогало не только разрабаты-
вать успешный продукт, но и применять Scrum по назна-
чению. Можно повторить слова Криса Фрая и Стива Грина
(Fry, 2007; 139), которые консультировали Salesforce.com
по переходу к Agile:
В начале нашей работы мы постоянно слышали

от многих экспертов, что роль владельца продукта —
ключевая для успеха перехода к Agile. Хотя интуи-
тивно это было понятно и нам, мы все же не до кон-
ца осознавали те значительные перемены, которые
ожидают владельцев продукта.
Чем отличается
agile‑управление продуктом
Agile, или гибкое управление продуктом, основанное
на Scrum, отличается от традиционных подходов во мно-
гих отношениях. В таблице 1 приведено резюме наиболее
важных различий.
Таблица 1. Управление продуктом по-старому и по-новому
Старые методы Новые методы
Несколько ролей — напри- Один человек, владелец продукта,

мер, маркетолог продук- отвечает за продукт и возглавляет
та, менеджер продукта проект. Более подробно об этой
и менеджер проекта. новой роли можно прочитать в гла-
Между ними делится от- вах 1 и 6
ветственность за создание
продукта
Менеджеры команды отде- Владелец продукта — член scrum-

лены от команды разра- команды, он постоянно и тесно
ботчиков: разные процеду- сотрудничает со scrum-мастером
ры, отделы и мощности и всей командой. Подробнее об этом
читайте в главах 1, 3 и 5
Обширное исследование Минимальная предварительная

рынка, планирование работа проводится в основном для
продукта и бизнес-анализ выработки общей идеологии и гру-
предшествуют разработке бых прикидок по функциональности
продукта. Это описывается в главе 2
Предварительное иссле- Исследование продукта — это посто-

дование и определение янный процесс, требования возни-
продукта: разрабатывают- кают как его следствие. Отсутствует
ся и окончательно уста- фаза определенности и четкое
навливаются подробные указание требований к рынку или
требования продукту. Бэклог продукта динами-
чен, и его содержание варьируется
в зависимости от отзывов клиентов
и пользователей. Более подробно
об этом говорится в главе 3
Отзывы пользователей Максимально быстрые и частые

получаются на позднем релизы вместе с краткосрочными
этапе, в ходе рыночного обзорными совещаниями порождают
тестирования и после ценную обратную связь от пользо-
запуска продукта вателей и клиентов, что позволяет
создать продукт, который полюбят
клиенты. Это описано в главах 4 и 5
Предисловие 25
Agile-методы, в том числе Scrum, придерживаются

старой как мир истины: постоянны только изменения.
«Если собственный анализ компании не делает продукт
устаревшим, это сделает чей-то еще анализ», — писал
Теодор Левитт в своей знаменитой статье «Близорукость
маркетинга», опубликованной в 1960 году. Кристенсен
добавляет, что прорывные технологии со временем про-
исходят в любой отрасли. Непонятно только, насколько
быстро и часто это случается. Компании, неспособные
к стремительной адаптации, сойдут с дистанции, даже
если в данный момент с их доходами все в порядке. К счас-
тью, эмпирическая природа Scrum отлично приспособила
эту методологию к внедрению разных новшеств и инно-
ваций, действий в сложных ситуациях, где преобладают
текучесть и непредсказуемость. Если ваш бизнес характе-
ризуется переменами, в Scrum вы, скорее всего, найдете
мощного союзника.
Что предлагает эта книга

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

нирование и отслеживание релиза продукта, использо-
вание scrum-собраний и переход к новой роли. Это прак-
тическое руководство позволит эффективно применить
scrum-техники управления продуктом. Особое внимание
уделяется продуктам, связанным с ПО, — от простого
приложения до мобильных телефонов.
Но это не учебник для начинающего менеджера про-
дукта и не пособие по Scrum для новичков. Тем более не-
льзя считать книгу руководством на все случаи жизни
в области управления продуктом. Многие аспекты управ-
ления продуктом здесь даже не рассматриваются. Наи
большее внимание уделяется идеям и методам управле-
ния продуктом, специфичным для Scrum.
Эта книга предполагает, что вы знакомы со Scrum
и обладаете актуальными познаниями в области управ-
ления продуктом.
Надеюсь, книга поможет вам создавать продукты,
которые полюбят потребители: они будут приносить по-
купателям пользу и разрабатываться разумно, с расчетом
на длительную перспективу.
1
Кто такой владелец
продукта?
Однажды я работал над продуктом в области здраво

охранения. Эта система должна была создавать больше
ценностей для потребителей и обеспечить существенное
преимущество над конкурентами. Через два с лишним
года новый продукт был наконец запущен, на него возла-
гались большие надежды, но все обернулось провалом.
Что же произошло? Где-то по дороге между идеей
и запуском концепция заблудилась. Маркетологи про-
вели исследование рынка, сформулировали концепцию
продукта и передали ее менеджеру продукта. Он написал
спецификацию и вручил менеджеру проекта, который пе-
редал ее в разработку. Не нашлось никого, кто бы отвечал
за создание успешного продукта, не существовало общего
видения продукта и его функциональности. У всех были
собственные подходы, своя концепция.
Как разрешить ситуацию? На всех этапах за продукт

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

В Scrum Guide Кен Швабер пишет о владельце продукта:
Владелец продукта — единственный человек, отве-

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

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

значение одного человека ответственным за релизы
обеспечивает их непрерывность и снижает количество
передаточных звеньев, а также поощряет долгосрочное
планирование. Исследование в SAP AG выявило и другие
преимущества: сотрудники, работающие владельцами
продукта, чувствовали себя уверенно, понимали степень
своего влияния и то, что они на виду, были наиболее орга-
низованными и мотивированными для новой роли.
Но владелец продукта — это прежде всего член scrum-
команды, он тесно сотрудничает с коллегами. Scrum-
мастер и команда помогают владельцу продукта, совмес-
тно работая над бэклогом продукта, а владелец продукта
отвечает за успех необходимых мероприятий.
Велик соблазн сравнить роль владельца продукта
с традиционными ролями — менеджером продукта или
руководителем проекта. Но любое сравнение будет не-
точным. Владелец продукта — это новая многогранная
роль, которая объединяет власть и ответственность, тра-
диционно распределявшиеся в руках разных людей, в том
числе клиента, спонсора, менеджера продукта и руково-
дителя проекта.
Конкретные задачи владельца продукта зависят
от контекста: в частности, от типа продукта, стадии его
жизненного цикла и размера проекта. Например, вла-
дельцу продукта, который состоит из программного
обеспечения, аппаратного обеспечения и механических

устройств, потребуются совершенно иные компетенции,
чем человеку, возглавляющему работу по созданию веб-
приложения. А владелец продукта, участвующий в боль-
шом scrum-проекте, должен иметь иные навыки, чем че-
ловек, сотрудничающий с одной-двумя командами.
В коммерческих проектах владелец продукта —
обычно представитель клиента: менеджер продукта
или маркетолог. Сам клиент принимает на себя эту
роль, если продукт разрабатывается для конкретной
организации. Например, это может быть внешний кли-
ент, которому необходимо новое решение для хранили-
ща данных, или внутренний клиент (в частности, отдел
маркетинга), запрашивающий обновление сайта. Мне
доводилось работать с клиентами, пользователями, ме-
неджерами бизнес-направлений, менеджерами продук-
тов, руководителями проектов, бизнес-аналитиками
и архитекторами, которые хорошо подходили на роль
владельца продукта в конкретных обстоятельствах.
Владельцем продукта может стать даже CEO*. Напри-
мер, Ript — визуальный планировщик, позволяющий
пользователям копировать и вставлять изображения
и тексты из одного приложения в другое, — это плод
* От Chief Executive Officer (англ.) — высшая исполнительная долж-

ность в компании. В принятой в России иерархии аналог генераль-
ного директора. Прим. ред.
усилий Джерри Лейборна, CEO компанииOxygen Media,

который взял на себя роль владельца продукта для пер-
вого релиза программы.
Характеристики правильного
владельца продукта
Выбор правильного владельца продукта необходим
в любом scrum-проекте. Успешные владельцы продук-
та, с которыми я работал, обладали некоторыми общи-
ми чертами. Поскольку владелец продукта — это новая
роль, людям часто требуются время и поддержка, чтобы
приспособиться к ней и приобрести необходимые навы-
ки. Основная проблема — найти сотрудников с прием-
лемым уровнем знаний и опыта, которые смогут хорошо
выполнить задачу. (Переход к роли владельца продукта
и самосовершенствование в этой должности описаны
в главе 6.)
Визионер* и человек действия
Писатель Джонатан Свифт заметил: «Ви`дение — это ис-

кусство видеть невидимое». Владелец продукта — это
* Визионер (от англ. vision — видение) — человек, обладающий стра-

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

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

руют концепцию, страстно ее отстаивают и неумолимо
ведут к завершению», — говорит Джек Уэлч, бывший
председатель совета директоров и CEO компании General
Electric. Владелец продукта — именно такой лидер. От-
вечая за успех продукта, он обеспечивает руководство
всеми, кто занят разработкой, и готов принимать слож-
ные решения. Например, укажет, отложить дату запуска
или ограничиться меньшей функциональностью. В то
же время владелец продукта — командный игрок, он
вступает в тесное сотрудничество с другими членами
scrum‑команды и не обладает формальной властью над

ними. Мы можем определить владельца продукта как
primus inter pares — первого среди равных в том, что ка-
сается продукта.
Двойственная природа владельца продукта (как лиде-
ра и командного игрока) накладывает свои ограничения.
Он ни в коем случае не должен быть диктатором, но в то
же время не может себе позволить нерешительности
и мягкотелости в управлении.
Владелец продукта — это своего рода пастырь инно-
вационного процесса, он направляет проект и стремится
к согласию с командой при принятии решений. Совмест
ное принятие решений обеспечивает общую вовлечен-
ность, задействует знания и творческий импульс коман-
ды и в итоге дает лучшие результаты. Подобный метод
работы требует терпения, поскольку члены команды по-
началу часто спорят и лишь затем из различных идей фор-
мируется новое решение. Кейнер приводит в своей рабо-
те полезные сведения о коллективном принятии решений
и связанных с ним методах координации (Kaner, 1996).
Команда предпринимателей
Порой мы излишне концентрируемся на знаменитых
предпринимателях и лидерах — Билле Гейтсе, Стиве
Джобсе и других. На самом деле лишь немногие ин-
новации — это действительно результат гениальности
одного человека. И даже если владелец продукта —

ходячая инновация, ему все равно требуется команда
для воплощения идеи в жизнь. Ни один даже самый
выдающийся предприниматель не сможет сам при-
нять все нужные решения. Нейробиологи доказали,
что даже сверхквалифицированный человек спосо-
бен ошибиться, пытаясь справиться со всем в одиноч-
ку. Поэтому рекомендуется использовать еще хотя бы
одного человека, чтобы было с кем проконсультиро-
ваться. Финкельштейн и его соавторы связывают это
с работой человеческого сознания (Finkelstein, 2009).
В команде множество партнеров, способных про-
верить ваши идеи и тем самым стимулировать приня-
тие верных решений. Эд Кэтмалл, президент Pixar,
утверждает:
…если дать хорошей команде посредственную
идею, она либо исправит ее, либо выбросит и приду-
мает взамен что-то получше.
Мудрость многих лучше, чем гений одного.
Пропагандист и переговорщик
Владелец продукта должен быть эффективным пропа-

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

теля и заполняет лакуну между «пиджаками» и «технаря-
ми». Иногда от него требуется сказать «нет», а иногда —
найти компромисс.
Наделенный полномочиями
и преданный делу
У владельца продукта должно быть достаточно полномо-

чий, чтобы возглавить разработку и объединить усилия
всех заинтересованных лиц. В mobile.de, самом большом
немецком онлайн-рынке автомобилей, высшее руковод
ство избирает владельцев продуктов, обеспечивает им
поддержку и выступает в роли старшего партнера. Столь
тесное сотрудничество позволяет руководителям лучше
следить за ходом выполнения конкретных проектов и от-
казываться от бесперспективных на раннем этапе*.
Достаточные полномочия владельца продукта необ-
ходимы для руководства разработкой продукта. Владелец
продукта должен обладать полнотой власти для приня-
тия решений, касающихся любых аспектов — подбора
подходящих членов команды, определения того, какая
функциональность будет входить в тот или иной релиз,
* Личное сообщение Филиппа Мисслера, CTO компании mobile.de,

18 июня 2009 года.
и т. д. Это человек, имеющий доступ к бюджету и спо-

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

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

Джефф Сазерленд, один из создателей Scrum
и бывший технический директор компании Patient-
Keeper, ведущего производителя интегрированных
информационных систем в области здравоохране-

ния, разъясняет необходимую квалификацию и пол-
номочия владельцев продукта в этой компании:
[Владелец продукта] должен быть экспертом
в своей отрасли, работать хотя бы пару дней в не-
делю как врач в одной из ведущих больниц Бос-
тона… техническим специалистом, уже написав-
шим несколько приложений… экспертом в анализе
пользовательских историй, сценариев использо-
вания и программных спецификаций, особенно
в области здравоохранения… уметь находить об-
щий язык с клиентами и отделом продаж, выяснять
требования и набирать специалистов-медиков
для тестирования прототипов с новой функцио-
нальностью… и при этом вести бизнес, заниматься
выручкой, отношениями с клиентами и специа-
листами по продажам в части, касающейся функ
ционала, создавать пользовательские истории
и все дополнительные спецификации продукта,
в том числе анализировать ожидания клиента.
[Наши владельцы продукта] получают помощь
только от разработчиков и членов своей команды.
Первые два назначенных специалиста с задачей
не справились. Но постоянное обучение, настав-
ничество и верно выбранный сотрудник дали нуж-
ные результаты*.
* Из письма Джеффа Сазерленда на рассылку scrum-тренеров Yahoo!

от 2 октября 2008 года и из личного сообщения Джеффа Сазерлен-
да от 16 декабря 2008 года.
Работа с командой
Владелец продукта — это такой же член scrum-команды,

как и все остальные, он должен полагаться на сотрудни-
чество с ней и со scrum-мастером. Команда представля-
ет собой многофункциональную, самоорганизующую-
ся и при этом небольшую группу специалистов. В ней
должны быть представлены все роли, необходимые для
создания продукта. Члены scrum-команды работают в ат-
мосфере доверия и сотрудничества, как равноправные
коллеги. Исключается разделение людей на «мы и они».
Должно присутствовать только понятие «мы».
Для создания атмосферы успешности в scrum-коман-
де сведите к минимуму изменения в ее составе в течение
релизов и между ними. Чтобы группа людей преврати-
лась в сплоченную команду, потребуется время. Необхо-
димо создать тесно спаянный коллектив, члены которого
доверяют друг другу, эффективно работают вместе. Если
изменить состав команды, процесс построения начина-
ется заново и в результате снижаются продуктивность
и самоорганизация. К тому же нужно установить долго-
срочное партнерство между scrum-командой и ее продук-
том. Каждый продукт должен разрабатываться одной или
несколькими преданными ему командами. Это не только
облегчает обучение, но и упрощает распределение людей
и ресурсов.
Поскольку владелец продукта, scrum-мастер и коман-

да должны постоянно и тесно сотрудничать, желательно
разместить всех членов scrum-команды в одном помеще-
нии. Рассмотрим пример mobile.de. То, что владельцы
продукта, scrum-мастер и команда находились в одном
помещении, повысило производительность и боевой на-
строй команды*. Если владелец продукта не имеет воз-
можности постоянно находиться вместе с командой, он
должен регулярно встречаться с ее членами. Владельцы
продукта, работающие удаленно, могут приходить в офис
и оставаться вместе с командой на протяжении несколь-
ких дней при каждом спринте. Если владельцы находятся
в том же комплексе, но располагаются далеко от коман-
ды, я рекомендую им выполнять «правило одного часа»:
проводить как минимум час в день в помещении, где тру-
дится команда.
Атмосфера в помещении, где работает команда, долж-
на стимулировать творческий процесс, который включа-
ет взаимодействие и ощущение радости от работы, со-
держит ключевые маркеры информации (формулировку
концепции, наиболее приоритетные элементы бэклога
продукта, диаграмму архитектуры ПО, задания текуще-
го спринта, график хода релиза и спринта). Лучшие рабо-
чие помещения — те, где созданы условия для сочетания
* Личное сообщение Филиппа Мисслера, CTO компании mobile.de,

22 июня 2009 года.
командной работы, личного пространства и деятельнос-

ти небольших групп в комнатах отдыха.
Взаимодействие
со scrum‑мастером
Чтобы постоянно играть на высшем уровне, спортивной
команде необходим тренер, а scrum-команде — scrum-
мастер*. Он оказывает поддержку владельцу продукта
и команде, защищает ее и процесс работы и при необхо-
димости вмешивается, чтобы удостовериться, справляет-
ся ли команда с задачей, сохраняет ли здоровую атмосфе-
ру и мотивацию и не создает ли технического долга**.
Роли владельца продукта и scrum-мастера дополняют
друг друга. Владелец продукта в первую очередь отвечает
за создание нужного продукта. Scrum-мастер в основном
несет ответственность за то, «как» правильно использо-
вать практики Scrum. Эти два аспекта проиллюстриро-
ваны на рисунке 1.1. Долгосрочный успех достигается,
когда правильный продукт создается правильными ме-
тодами.
* Например, у профессиональных регбистов есть несколько тре-

неров: по атакам, защите, схваткам, ударам, тренеры форвардов,
а также главный тренер.
** О техническом долге и оптимальном темпе работы подробно гово-
рится в главах 4 и 5.
Правильный Быстрые, Продол-

продукт но недолго- жительный
вечные успехи успех
Неправильный Медленный Быстрый

продукт провал провал
Неправильно Правильно
Рисунок 1.1. Создание правильного продукта

правильными методами
Поскольку роли владельца продукта и scrum-мастера

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

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

продукта должны привлекать и других заинтересован-
ных лиц — например, представителей служб маркетинга,
продаж и клиентского обслуживания. Их с самого нача-
ла следует приглашать на рабочие совещания во время
спринтов. Эти встречи позволят заинтересованным ли-
цам увидеть, как создается продукт, наладить контакт
со scrum-командой и обменяться мнениями. Брайсон
(Bryson, 2004) предлагает обзор методов выявления за-
интересованных лиц, анализа их требований и работы
с ними.
Менеджеры по продуктовому
маркетингу и менеджеры продукта
Некоторые компании разграничивают стратегиче
ский и тактический продакт-менеджмент и выделяют
отдельные должности для каждого из них: менеджер
по продуктовому маркетингу и (технический) менед-
жер продукта. Деятельность менеджеров по продук-
товому маркетингу обычно направлена вовне: в их
обязанности входит понимать рынок, управлять пла-
ном развития продукта и следить за общими дохода-
ми после релизов. А менеджеры продукта смотрят
внутрь: их задача — подробное описание функций,
расстановка приоритетов и сотрудничество с коман
дой разработчиков. В Scrum владелец продукта
совмещает все эти обязанности. По стратегическим
вопросам управления продуктом владелец продукта
может получить поддержку от управляющего порт

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

руководителя проекта в scrum-команде. Причи-
на в том, что обязанности по управлению проектом
больше не входят в компетенцию одного человека.
Они распределены между членами scrum-команды.
Например, владелец продукта отвечает за дату ре-
лиза, его объем, управление бюджетом, сообщения
о прогрессе и работу с заинтересованными лицами.
Команда определяет и оценивает задачи, а затем ра-
ботает над ними. Таким образом, роль руководителя
проекта становится избыточной. Это не значит, что
люди, которые работают в этой должности, больше
не нужны. Очень часто они становятся успешными
scrum-мастерами. Встречались мне и руководители
проекта, отлично выполнявшие роль владельца про-
дукта.
Моделирование роли
владельца продукта
Прежде чем рассказать о методах работы владельца про-
дукта в крупных scrum-проектах, хочу дать совет: избе-
гайте больших проектов! Начинайте с малого и быстро
разрабатывайте продукт с минимальной функциональ-
ностью. Об этом пойдет речь в главе 2. Если приходится
заниматься крупным проектом, увеличивайте объемы
медленно. Пусть он растет естественным образом, при-
бавляя по одной команде за раз. Если работу начинает
слишком большое число людей, то проект может стать
чересчур сложным, так что последующие обновления по
требуют массу времени и денег*.
Главный владелец продукта
В крупных scrum-проектах принимает участие несколь-

ко небольших команд. Каждой из них требуется владе-
лец продукта, но в одиночку он может заниматься лишь
ограниченным количеством команд. Сколько команд
* Эта идея излагается в законе Конвея (Conway, 1968). Он гласит, что

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

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

владельцем продукта. Швабер использует термин владелец обще-
го продукта (Schwaber, 2007); Ларман и Водде называют главного
владельца продукта просто владельцем продукта (Larman & Vodde,
2009).
слово, если компромисс не найден. Когда проект, начав-

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

продукта с главным владельцем до сложной структуры,
состоящей из нескольких уровней сотрудничающих вла-
дельцев продукта. Рассмотрим оба варианта, начав с наи
более простого.
Организация проекта, изображенная на рисунке 1.2,
состоит из трех команд и трех владельцев продукта. Каж-
дый владелец продукта отвечает за свою команду. В свою
очередь, владельцы продукта тоже формируют команду,
и владелец продукта В выступает в роли главного. Эта
иерарх ия считается горизонтальной, несмотря на нали-
чие главного владельца. Приведу пример, как можно при-
менить такую организацию проекта: клиент нанимает
команд у владельца продукта, отвечающую за веб-портал
и его приложения. Четыре владельца продукта и главный
владелец продукта тесно сотрудничают, при этом каждый
отвечает за конкретное предложение, а главный владелец
продукта — за весь продукт, включающий в себя все при-
ложения и портал.
Команда владельцев продукта
Владелец Главный владелец Владелец

продукта А продукта и владелец продукта В
продукта Б
Команда А Команда Б Команда В
Рисунок 1.2. Простая иерархия владельцев продукта
На рисунке 1.3 представлен другой вариант, подхо-

дящий для больших scrum-проектов и заимствованный
из книги Кена Швабера (Schwaber, 2007; 70–73).
Организация проекта, частично изображенная на ри-
сунке 1.3, состоит из четырех уровней и девяти владель-
цев продукта*. Каждый владелец продукта руководит
своими коллегами, располагающимися на более низком
иерархическом уровне, и помогает им. Владелец продук-
та верхнего уровня является главным владельцем про-
дукта. Он отвечает за всю разработку и успех продукта.
* Кен Швабер (Schwaber, 2007; 71) предлагает каждому владельцу

продукта стать частью интегрированной scrum-команды, в кото-
рую входят также scrum-мастер и команда. Каждая интегрирован-
ная scrum-команда поддерживает команды более низкого уровня.
Так, на рисунке 1.3 интегрированная scrum-команда «Игры» под-
держивает scrum-команды «Тетрис» и «Шахматы».
В данном случае владельцы продукта образуют непрос-

тую иерархию.
Главный владелец продукта

«Мобильный телефон»
Владелец про- Владелец про- Владелец про- Владелец

дукта «Развле- дукта «Комму- дукта «Фото продукта
чения» никации» и видео» «Органайзер»
Владелец Владелец
продукта продукта
«МР3-плеер» «Игры»
Владелец Владелец
продукта продукта
«Тетрис» «Шахматы»
Рисунок 1.3. Сложная иерархия владельцев продукта
Сложная иерархия владельцев продукта предпо-

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

работку, координируя свою деятельность с клиента-
ми и другими заинтересованными лицами. Владельцы
продукта более низкого уровня сосредоточены на сво-
их функциях или подсистемах и тесно сотруднича-
ют с командами разработчиков. Швабер (Schwaber,
2007; 72) отмечает:
Владелец продукта планирует, расписывает, рас-

пределяет и отслеживает работу со своего уровня
вниз… Чем выше его уровень, тем сложнее работа.
Объем ответственности владельца продукта вы-
сшего уровня обычно предполагает, что им стано-
вится должностное лицо не ниже вице-президента
или CEO.
Как правильно выбрать

владельцев продукта
Найти подходящего человека на роль владельца про-

дукта непросто, даже когда нужен только один такой
кандидат. По каким же критериям выбирать правиль-
ных владельцев продукта для больших проектов? Ответ
на этот вопрос дает понимание разных способов органи-
зации команд в большом проекте. Существует всего два
варианта: функциональные команды и компонентные
команды (Pichler, 2008; Larman and Vodde, 2009). Функ-

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

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

полномочиями
Проект, в котором владелец продукта не обладает доста-

точными полномочиями, похож на автомобиль с мало-
мощным двигателем: он, конечно, едет, но с увеличением

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

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

Симптомы перегрузки владельца продукта — это не-
достаточная работа над бэклогом продукта, пропуски
планирования спринтов или обзорных совещаний, не-
возможность задать им вопрос и слишком длительное
время, требующееся для ответов. Перегруженные вла-
дельцы продукта не соответствуют идее agile-манифеста
о постоянном темпе. «Agile-процессы подразумевают
равномерное развитие. Заказчики, разработчики и поль-
зователи должны постоянно поддерживать один и тот же
темп» (Beck et al., 2001).
Перегруженность владельца продукта наступает
вследствие двух основных причин: нехватки времени
на исполнение своих обязанностей и недостатка подде-
ржки со стороны команды. Доступность владельца про-
дукта оказывается под угрозой, если эта роль — лишь
одна из нескольких задач, которые он вынужден выпол-
нять, или если ему приходится следить за большим коли-
чеством продуктов и командами. Недостаток поддержки
со стороны команды — результат неправильного пони-
мания роли владельца продукта. Хотя он один, бо́льшая
часть его работы требует коллективного труда. Коман
да и scrum-мастер должны поддерживать владельца
продукта.
Чтобы не перегружать владельца продукта, по
пробуйте для начала освободить этого человека от всех
остальных обязанностей. Ведь он занимается постоян-

ной работой и может отвечать только за один продукт
и одну команду. Кроме того, убедитесь, что команда
в каждом спринте находит время для сотрудничества
с владельцем продукта. Scrum отводит для этого до 10%
действий команды (Schwaber, 2007). Такое сотрудни-
чество не только позволяет более равномерно распре-
делить бремя нагрузки, но и дает возможность исполь-
зовать коллективное мышление и творческий импульс
всей команды.
Частичный владелец продукта
Некоторые организации распределяют роль истинного

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

вильно ее использовать. За тактические и стратегические
вопросы управления продуктом должен отвечать один че-
ловек. Это может потребовать перемен в организации —
например, адаптации служебных обязанностей и путей
карьерного роста, увеличения спектра обязанностей от-
дельных сотрудников, о чем пойдет речь в главе 6.
Удаленный владелец продукта
Удаленный владелец продукта работает отдельно

от команды. Слово «удаленный», возможно, вызывает
представление, что владелец продукта находится на од-
ном континенте, а команда — на другом. На самом деле
удаленность имеет самые разные формы и степени. Так
называют и ситуации, когда владелец продукта работа-
ет с командой в одном здании, но в разных помещениях,
и случаи, когда они находятся на разных континентах
и в различных часовых поясах (Simons, 2004). Проблемы,
связанные с удаленными владельцами, повсюду одина-
ковы: недостаток доверия, недопонимание, отсутствие
единства и медленный темп работы. И причина понятна:
«Самый экономичный и эффективный способ передачи
информации команде разработчиков — это личная бесе-
да» (Beck et al., 2001).
Избегайте удаленных владельцев продукта, разме-

щайте всех членов scrum-команды рядом. Как уже гово-
рилось, компания mobile.de резко повысила производи-
тельность и боевой настрой, когда владелец продукта,
scrum-мастер и команда стали работать в одном помеще-
нии. Если это невозможно, то владелец продукта должен
проводить как можно больше времени в том же помеще-
нии, что и остальная scrum-команда. Удаленным владель-
цам продукта нужно присутствовать хотя бы при пла-
нировании спринтов, на обзорных и ретроспективных
совещаниях. Переход от удаленного к присутствующему
владельцу продукта нередко требует времени. Иногда
это связано с приемом на работу и обучением местного
владельца продукта. В некоторых случаях требуется даже
переосмысление стратегии продукта компании и измене-
ние места его производства.
Заместитель владельца продукта
Заместитель владельца продукта — это человек, кото-

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

ально подходил для этой работы, ему с трудом удавалось
проводить достаточно времени с командой. В результате
бизнес-аналитику команды пришлось выступать в роли
заместителя, когда настоящий владелец продукта не мог
присутствовать. Он делал бóльшую часть работы вла-
дельца, не имея соответствующих полномочий. Сам же
владелец продукта принимал окончательные решения
о приоритетах в бэклоге продукта, при планировании ре-
лизов, приеме результатов работы. В итоге увеличилось
количество конфликтов, решения принимались медлен-
нее, уменьшилась производительность и упал команд-
ный дух.
Использование заместителя владельца продукта —
это попытка искусственно вылечить системную пробле-
му. Вместо косметического ремонта организациям следу-
ет заняться причинами: например, освободить владельца
продукта от других обязанностей, объединить его в од-
ном помещении со scrum-мастером и командой или найти
нового владельца продукта.
Комитет владельцев продукта
Комитет владельцев продукта — это группа владель-

цев продукта, в которой никто персонально не отвечает
за общий продукт. Ни один из них не руководит этой

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

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

шей компании?
—К
то определяет и описывает потребности клиентов
и функциональность продукта?
—К
то руководит выработкой концепции продукта
и действиями по претворению ее в жизнь? Какую
роль играют командная работа и совместное при-
нятие решений?
—Ч
то потребуется для внедрения роли владельца
продукта в той форме, которая описана в данной
главе?
2
Планирование
концепции продукта
В начале 1990‑х телефонные конференции были насто

ящим испытанием. Участникам нередко приходилось от-
ворачиваться от стола и кричать в микрофон. Когда люди
говорили одновременно, их голосов не было слышно, так
что разговор напоминал какой-то гул. Компания Polycom
занималась телепрезентациями и решениями по пере
даче видеокартинки, голоса и контента. Там осознали,
что клиентам необходимы телефонные конференции, ко-
торые были бы больше похожи на личное общение, без ис-
кажений, эха и других помех. Поэтому Polycom заплани-
ровала концепцию продукта со следующими свойствами
(Lynn and Reilly, 2002; 63):
— Превосходное качество аудио, позволяющее гово-
рить нескольким людям одновременно без ущерба
для понимания.
— Простота в использовании, без загадочных кнопок

и проводов.
— Привлекательный внешний вид, подходящий для
использования в конференц-зале руководства.
В итоге появился продукт под названием SoundStation,
который был запущен в 1992 году. Концепция стала важ-
ным фактором его успеха. В этой главе рассказывается
о методах планирования концепции продукта. Начнем
с содержания и свойств эффективной концепции.
Видение продукта
— Скажите, пожалуйста, куда мне отсюда идти?
— Это во многом зависит от того, куда ты хочешь
прийти, — ответил Кот.
— Да мне почти все равно, — начала Алиса.
— Тогда все равно, куда идти, — сказал Кот.
Льюис Кэрролл, «Алиса в Стране чудес»*
Способность представить себе то, как должен выглядеть

новый продукт или его новая версия, необходима для
того, чтобы куда-то прийти. Представления о продукте
выливаются в видение — набросок будущего продукта**.
* Перевод Б. Заходера. Прим. перев.

** Хотя концепция продукта не входит в структуру Scrum, она упо-
минается у Швабера и Бидла (Schwaber and Beedle, 2002; 34). Кен
Швабер пишет: «Концепция описывает причины, по которым за-
пускается проект, и его желаемый результат» (Schwaber, 2004; 68).
2. Планирование концепции продукта 63
Видение служит объединяющей целью, которая придает

энергию и направляет работу людей. В этой цели смысл
существования продукта. Как и в примере с Polycom, ви-
дение описывает продукт в самом общем виде, указывает
суть — информацию, которая считается критичной для
разработки и запуска успешного продукта. Демонстрация
обновлений продукта клиентам и пользователям на об-
зорных совещаниях во время спринта и частые и быстрые
релизы ПО служат для подтверждения и уточнения кон-
цепции. Эффективное видение должно содержать ответы
на следующие вопросы:
— Кто будет покупать этот продукт? Кто его целевой
клиент? Кто будет использовать продукт? Кто его
целевые пользователи?
— Каким потребностям будет отвечать продукт? Ка-
кую ценность он создает?
— Какие свойства продукта жизненно необходимы
для удовлетворения избранных потребностей,
а следовательно, и для успеха продукта? Как
приблизительно продукт будет выглядеть и ра-
ботать? В каких аспектах он станет особенно
хорош?
— Как он будет выглядеть на фоне других продуктов,
выпущенных конкурентами или самой компани-
ей? Каковы уникальные коммерческие аргументы
продукта? Какой станет его цена?
— Как компания будет получать прибыль от прода-

жи продукта? Каковы источники выручки за него
и как выглядит бизнес-модель?
— Осуществимо ли производство продукта? Сможет
ли компания его разработать и продавать?
Если вы планируете использовать новый продукт
как трамплин для изменения бизнес-модели, то эта
информация должна быть отражена в концепции про
дукта.
Возьмем в качестве примера iPod и iTunes компа-
нии Apple. Apple проложила дорогу к доминированию
на цифровом музыкальном рынке, создав хороший про-
дукт, iPod, и упаковав его в отличную бизнес-модель.
Тесная интеграция iPod и iTunes, музыкального онлайн-
магазина компании, не только сделала удобной процесс
покупки музыки онлайн, но и замкнула покупателей
в пространстве своих продуктов. Это позволило Apple
изменить правила игры — продавать музыку онлайн
по сравнительно низким ценам. Доход компании от му-
зыки невелик, в отличие от огромной прибыли от прода-
жи MP3‑плееров.
Видение iPod должно было обязательно предусмат-
ривать безболезненную интеграцию с iTunes, а видение
iTunes — обращаться к бизнес-модели и дополнительной
выручке от продажи iPod.
Желаемые качества видения

Видение должно кратко сообщать о сути будущего про-
дукта и описывать общую цель, которая дает направле-
ние для работы, но достаточно неопределенно, чтобы спо-
собствовать творчеству.
Общее и объединяющее
Все люди, связанные с разработкой продукта, должны

разделять его видение: scrum-команда, руководство,
клиенты, пользователи и другие заинтересованные
лица. Питер Сенге формулирует это так: «Концепция
действительно является общей, когда у нас с вами возни-
кает схожая картина и мы оба хотим, чтобы эта картина
возникала у нас обоих, а не у каждого индивидуально»
(Senge, 2006; 192). Общее видение порождает единение
и заряжает энергией всех, кто вовлечен в процесс раз-
работки. Оно способствует эффективной командной
работе и облегчает обучение команды. «Когда люди дей
ствительно разделяют одно видение, они связаны друг
с другом общими надеждами» (Senge, 2006; 192). Если
же у членов команды видение не совпадает, они будут
двигаться в разных направлениях, а не к общей цели.
Отличный способ добиться общего видения — привлечь
к его разработке членов scrum-команды и заинтересо-

ванных лиц.
Широкое и мотивирующее
Видение продукта должно в общих чертах описывать

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

тельно очень заинтересованы в предмете. Считаю
полезным, что мы по-прежнему отказываемся от де-
тальных спецификаций продукта. Если вы пишете
документ объемом 70 страниц, в котором подроб-
но рассказывается, какой продукт вы должны сде-
лать, — вы убиваете творчество. А так, например,
инженер приходит и говорит: знаете, вы тут забыли
функцию, а я хочу ее добавить. Нельзя изгонять твор-
ческое начало из работы. Консенсусный подход, при
котором команда сообща вырабатывает концепцию
того, что они делают, и оставляет достаточно про-
странства для творчества каждому члену команды,
действительно способен вдохновлять и нередко

приводит к наилучшим результатам*.
Нужно противостоять искушению перегружать про-

дукт деталями или спецификациями. Дополнительная
функциональность будет обнаружена и отражена в бэк-
логе продукта в ходе проекта.
Краткое и приятное
Если говорить о видении продукта, то оно должно быть

кратким и сжатым, содержать только информацию, не-
обходимую для его успеха. Например, продукты-блок-
бастеры, как показало десятилетнее исследование Линна
и Рейли, обладали всего шестью атрибутами (Lynn and
Reilly, 2002). Таким образом, видение продукта — это
не список функций и оно не должно содержать избы-
точные подробности. Специалист по agile-управлению
проектами Джим Хайсмит поясняет: «Как оказалось,
описание пятнадцати-двадцати признаков или функ-
ций продукта — задача довольно легкая. А вот выбор
трех-четырех из них, которые побудили бы человека этот
* “Inside Google’s New-Product Process”, BusinessWeek.com, June 30,

2006.
продукт купить, — дело сложное» (Highsmith, 2009; 97).

Специалист по разработке продуктов Дональд Райнерт-
сен соглашается: «У большинства успешных продуктов
есть четкое и простое ценностное предложение. Поку-
патели обычно выбирают между конкурирующими про-
дуктами на основе трех-четырех ключевых факторов»
(Reinertsen, 1997; 174–175).
Видение продукта обычно считается сжатым, если
может пройти лифтовый тест Мура. «Можете вы объяс
нить, в чем идея вашего продукта, за то время, пока
едете в лифте?» (Moore, 2006; 152). Если ответ отрица-
тельный, то видение, вероятно, слишком сложное или
запутанное.
Минимально
функциональный продукт
Чтобы создать видение продукта, scrum-команда долж-
на заглянуть в будущее и сформулировать то, как, по ее
мнению, будет выглядеть и работать будущий продукт.
Конечно, для любого человека, не наделенного даром яс-
новидения, верное предсказание будущего — дело чрез-
вычайно сложное. В конце концов, единственное, что мы
точно знаем о будущем, — это то, что оно неопределенное.
Не существует методики исследования рынка, способной
выдавать абсолютно достоверные прогнозы. А полностью

безопасные инвестиции — это лишь иллюзия. Так, Купер
утверждает, что вероятность неудачи для новых продук-
тов колеблется от 25 до 45% (Cooper, 2001; 10). В некоторых
исследованиях приводятся еще более высокие проценты.
Рынки развиваются самым неожиданным образом, реак-
цию клиентов предсказать трудно, что и иллюстрирует
следующая история*.
Когда в 1999 году компания Expertcity выпустила ин-
терактивную систему технической поддержки, на нее
возлагались большие надежды. Исследования рынка по-
казали, что новый продукт будет иметь большой успех.
К сожалению, продукт не оправдал ожиданий. Expertcity,
однако, отметила, что пользователи стали широко при-
менять одну из функций продукта — возможность поде-
литься экраном — неожиданным образом. Они начали
с ее помощью управлять удаленными компьютерами.
Компания тут же внесла изменения в продукт, превратив
его в средство удаленного контроля. Модифицированный
продукт получил название GoToMyPC. Он стал настолько
* На точность предсказания реакции рынка влияет его динамика

и степень инновационности продукта. Для стабильных рынков
и продуктов, переживающих постоянные или пошаговые инно-
вации, реакция рынка может быть просчитана довольно хорошо.
Для других рынков и продуктов это сложно или даже невозмож-
но — например, в случае прорывных инноваций. Кристенсен
(Christensen, 1997; 143) отмечает: «Нельзя анализировать рынки,
которые еще не существуют».
успешен, что Citrix в 2003 году решила приобрести

Expertcity за 225 миллионов долларов. GoToMyPC сейчас
является частью пакета Citrix Online. Хотя исходное ви-
дение продукта Expertcity и оказалось неверным, способ-
ность компании к адаптации помогла ей превратить яв-
ный провал в неожиданный успех.
Поскольку наше умение предсказывать будущее ог-
раниченно, ориентируйтесь ради успеха на минималь-
но функциональный продукт, имеющий небольшое ко-
личество функций, которые призваны удовлетворить
избранные потребности клиентов*. Вспомните iPhone,
выпущенный в 2007 году. Уникальное восприятие теле-
фона пользователем полностью затмило конкурентов.
Так был установлен новый стандарт для смартфонов.
Одним из секретов успеха стал узкий набор потребнос-
тей клиента, которые были избраны Apple. Компания
избежала искушения попытаться разом удовлетворить
запросы многих потребителей, постаравшись скопиро-
вать все функции, которые предлагались конкурентами.
Вместо этого Apple решила по-новому взглянуть на то,
* Термин «минимально функциональный продукт» отсылает нас

к работе Марка Денна и Джейн Клиленд-Хуан. В их книге Software
by Numbers (2004) предложен термин «минимальная коммерче
ски ценная функциональность», который обозначает наименьшую
функциональность, способную все же создать ценность для поку-
пателя. Идея быстрого формирования небольшого набора функ-
ций и пошагового улучшения продукта восходит к методу эволю-
ционной разработки Тома Гилба (Gilb, 1988).
как должны выглядеть смартфоны, и сознательно отка-

залась от некоторых функций. Первый iPhone поступил
в продажу без множества функций, которые считались
к тому времени стандартом: копирования и вставки, воз-
можности отправлять текстовые сообщения нескольким
получателям и набора для разработки ПО. Однако эти ог-
раничения не сказались на общем успехе. Урезание функ-
циональности позволило Apple разработать и выпустить
продукт в конкурентоспособное время и дало компании
существенное преимущество над соперниками. Основы-
ваясь на успехе первой версии iPhone, Apple в 2008 году
запустила 3G-модель, расширив возможности телефо-
на как в программном, так и в аппаратном отношении.
Она вышла и на новый сегмент рынка, нацелившись
на бизнес-к лиентов.
Сравните успех iPhone с другим продуктом компа-
нии — Apple Newton, вышедшим на рынок в 1993 году
после пяти лет разработки. Помните объявления Apple,
которые обещали вам полноценный КПК, способный
делать самые невероятные вещи — например, распозна-
вать ваш почерк? Когда Newton наконец вышел на ры-
нок, оказалось, что он чересчур громоздкий. Более того:
самая важная его функция — распознавание почер-
ка — не работала должным образом. Продукт не оправ-
дал ожиданий, и в 1998 году его выпуск прекратился.
Сейчас можно сказать, что планы Apple на Newton были
чрезмерно амбициозными. Компания выпустила про-

дукт, который претендовал слишком на многое, и по-
терпела неудачу.
Создание минимального продукта дает ряд пре-
имуществ. Это отмечают Смит и Райнертсен (Smith and
Reinertsen, 1997) и Денн и Клиленд-Хуан (Denne and
Cleland-Huang, 2004)*. Продукт выходит быстрее, вре-
мя выхода на рынок сокращается, функциональность
добавляется более своевременно. Снижается стоимость
разработки продукта и увеличивается скорость возвра-
та инвестиций. Быстрее можно выручить деньги за то-
вар, что ускоряет движение наличности, убыстряются
и темпы обучения. Сократив время выхода на рынок,
мы имеем возможность чаще воспринимать реакцию
рынка и самостоятельно реагировать на нее, а не пы-
таться ее предугадать. Быстрый выпуск минимально
функционального продукта снижает риски. Если про-
дукт оказывается неудачным и его приходится сразу же
отзывать с рынка, мы теряем меньше денег. Это позво-
ляет внедрить в стратегию возможность ошибки, таким
подходом активно пользуется Google. Марисса Майер
из Google объясняет: «Мы понимаем, что многие про-
дукты придется просто выбросить, но помнить будут
* Смит и Райнертсен (Smith and Reinertsen, 1997) называют метод

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

пользовательским потенциалом»*.
Поскольку будущее неопределенно, концепция долж-
на распространяться только на следующую версию про-
дукта. Даже если долгосрочной мечтой Стива Джобса
было доминирование на рынке мобильных телефонов,
это определенно не являлось целью первого iPhone. Боль-
шие амбиции лучше всего реализовывать пошагово. «Ва-
жен только один шаг — следующий» (Gilb, 1988; 97). Как
только появляется концепция, она превращается в го-
товый продукт благодаря использованию пользователь-
ских и клиентских отзывов. Их собирают по результатам
демонстрации новых версий продукта на обзорных со-
вещаниях во время спринтов, а также быстрых и частых
релизов продукта. Подобный метод работы позволяет
scrum-команде сразу же определить, действительно ли
они производят нужный продукт. Если же нет, то виде-
ние, вероятно, сформировано неверно, так что следует
внести коррективы.
Заметьте, что видение продукта может воплощать-
ся более чем в одном релизе. Например, запуску первой
* “So Much Fanfare, So Few Hits”, BusinessWeek.com, July 10, 2006. По-
добный же подход отражен в знаменитом изречении Арта Фрая
из 3М: «Чтобы найти принца, придется перецеловать много лягу-
шек». Заметьте, что прекрасный принц заплатит за всех этих ля-
гушек. (Имеется в виду сказка братьев Гримм «Принц-лягушка».
Прим. ред.)
версии Google Chrome в декабре 2008 года предшество-

вало множество непубличных релизов и публичная бета-
версия в сентябре 2008 года. Более долгосрочный взгляд
на рост продукта можно воплотить в плане развития,
о котором говорится ниже.
Простота
Простота облегчает создание удобного в использовании
продукта с минимальной функциональностью. Не сто-
ит путать простоту с упрощенностью. Еще Леонардо
да Винчи говорил: «Простота — это высшая степень слож
ности».
Бритва Оккама
Простота как руководящий принцип — это давняя тради-

ция. Еще в XIV веке францисканский монах Уильям Ок-
кам, как считается, заявил, что при выборе между функ-
ционально эквивалентными решениями следует отдавать
предпочтение более простому (Lidwell, Holden, and Butler,
2003; 142). Эта идея известна как бритва Оккама.
Простота — это не только эстетика продукта. Это кон-
центрация на его сути, когда создается только действи-
тельно необходимое и есть возможность быстро и легко
изменять и расширять продукт. Простые, но адекватные

продукты удобны в использовании — например, Apple
или iPod. Основанный на колесе прокрутки и кнопках
на нем, iPod прост и минималистичен, но предлагает все
необходимые функции. Бек и Эндрес пишут: «Проекты,
тяготеющие к простоте, идут на пользу и человечеству,
и производительности» (Beck and Andres, 2005; 110).
Чем меньше, тем лучше
Здравый смысл предполагает: для выигрыша в конкурент

ной борьбе требуется создать лучший и более функцио
нальный продукт. Мы часто полагаем, что чем больше
функций у продукта, тем он лучше и привлекательнее для
покупателей. Вовсе нет, утверждает 37Signals (37Signals,
2006), создающая удобные в использовании веб-прило-
жения, удостоенные многочисленных призов. Компания
при разработке продуктов руководствуется принципом
простоты и сосредоточивается на их сути.
Чтобы опередить конкурентов, делайте меньше, чем

они… Возьмите свое видение продукта и уменьши-
те его наполовину… Начните с экономичного умного
приложения и дайте ему набрать обороты. На пост-
роенном таким образом надежном основании можно
делать что угодно.
Джон Маэда, специалист по простоте решений и про-

фессор Массачусетского технологического института, со-
гласен с этими положениями: «Легче всего достичь про-
стоты при помощи обдуманного исключения. Если вы
сомневаетесь в функции, исключите ее» (Maeda, 2006; 1).
Стиву Джобсу приписывают фразу: «Инновации — это
не значит всегда и всему говорить “да”. Это значит гово-
рить “нет” всему, кроме самых важных функций». Agile-
манифест разделяет эту точку зрения, называя простоту
одним из 12 принципов и определяя ее как «искусство
увеличения работы, которую вы не делаете» (Beck et al.,
2001). Каждый раз, когда у вас появляется идея новой
функции или вы обнаруживаете новое требование, задай-
те себе вопрос, насколько эта функциональность значима
для успеха продукта. Если она не критична — откажитесь
от идеи. В результате получается простой и лаконичный
продукт, который предлагает только те функции, кото-
рые действительно нужны клиенту или пользователю.
Простые пользовательские интерфейсы
Google — компания, которая открыто взяла на воору-

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

продукты, которые требуют большого количества функ-
ций и сложного дизайна, должны быть столь же просты,
сколь и эффективны… Мы стараемся не просто добав-
лять новые функции, но и развивать продукты в других
направлениях»*. Разработка простых пользовательских
интерфейсов, по утверждению Лидуэлла, Холдена и Бат-
лера, прекрасно оправдала себя в Google: «В то время
как другие интернет-поисковики стремились добавлять
на свои сайты рекламные сервисы и применимые для кон-
кретных случаев функции, Google придерживалась свое-
го простого и эффективного дизайна. Результат — самый
производительный и удобный в использовании поиско-
вик в сети» (Lidwell, Holden, and Butler, 2003; 143). А Бер-
нар Жирар, автор книги The Google Way (Girard, 2009; 34),
считает, что именно благодаря простоте AdWords — рек-
ламная программа Google — стала такой успешной.
Подобно интуитивному Macintosh GUI, благодаря

которому продукты Apple выглядят такими друже-
любными и удобными в использовании, дизайн и на-
правленность на пользователя интерфейса AdWords
от Google помогли ему победить. Любой рекламо-
датель сразу же понимает, как разместить объяв
ление…
* “Ten principles that contribute to a Google user experience”.

www.google.com/corporate/ux.html.
Потребности покупателя
и свойства продукта
Потребности покупателя и свойства продукта лежат
в основе любой концепции и заслуживают самого при-
стального внимания. От выбора важнейших потребнос-
тей покупателя зависит то, к какому рынку или его сег-
менту мы собираемся обращаться. Сосредоточившись
на пот ребностях, мы рассматриваем продукт как средс-
тво достижения цели — удовлетворения нужд клиента
или пользователя. В то же время свойства продукта —
критически важные параметры, которыми должен об-
ладать продукт для удовлетворения этих потребностей.
Например, сенсорный экран — это свойство продукта.
Вероятно, потребность, обусловившая это свойство, —
простота в использовании. Свойства могут быть как
функциональными, так и нефункциональными. Функци-
ональные свойства — это конкретные функции или черты
продукта, например способность совершать и принимать
звонки. Нефункциональные свойства — это производи-
тельность, выносливость, стиль, дизайн и удобство в ис-
пользовании. Нефункциональные атрибуты могут стать
важным дифференцирующим фактором — воздейство-
вать на пользовательский опыт, а также на расширяе-
мость продукта и удобство его эксплуатации, которые,
в свою очередь, влияют на общую стоимость владения

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

архитектурной сложности. Удобство в эксплуатации, на-
против, предполагает использование простой открытой
архитектуры. В результате появляется напряжение: вла-
делец продукта, scrum-мастер и команда вынуждены при-
лагать усилия, чтобы примирить непримиримое и найти
наилучшее решение для удовлетворения потребностей
покупателя. Алистер Кокберн (Cockburn, 2005; 147) пред-
лагает при расстановке приоритетов для свойств продук-
та руководствоваться следующими факторами:
— Пожертвовать остальными ради этого.
— Попытаться сохранить.
— Пожертвовать этим ради остального.
Так, чтобы поставить удобство в эксплуатации выше
сочетаемости с другим оборудованием, мы должны по-
жертвовать остальными свойствами ради удобства
в эксплуатации. В то же время мы должны попытаться
сохранить сочетаемость.
Полезное, простое и дешевое решение для записи по
требностей и свойств — это набор бумажных карточек.
Карточки способствуют командной работе, на них легко
писать и делать дополнения. Их можно группировать,
вешать на стенку и перемещать. Когда работа по форми-
рованию концепции закончена, мы можем наклеить кар-
точки на перекидную доску, повесить ее в рабочем поме-
щении и скопировать данные на вики-ресурс проекта.
Рождение видения продукта

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

ется тратить до 20% времени на «любимые проекты». Это
проекты, связанные с частными исследованиями, которые
приводят к новым идеям, реализуемым в прототипах. Ре-
зультаты оправдывают вложения Google: большая часть
всех продуктов, выпущенных за вторую половину 2005 го
да, начиналась как «любимый проект» (Mayer, 2006).
Разработчики, выдвинувшие исходную идею, продолжа-

ют работать над проектом претворения ее в жизнь, как
это было в случае с браузером Google Chrome. Бен Гуджер
и Дарин Фишер, два инженера, предложивших прототип,
сыграли важную роль в проекте разработки Chrome (Levy,
2008)*. Кен Швабер (Schwaber, 2007; 80) приводит такие ар-
гументы в пользу этого подхода к развитию новых идей:
Я рекомендую отвести часть времени каждого со-

трудника на деятельность, не имеющую отношения
к scrum-командам, в которых он состоит на данный
момент, но идущую на благо предприятия. Я советую
использовать на это примерно 20% их времени. Пусть
они соединяются в группы по интересам и работают
вместе. Какое-то время займет работа с коллегами
по поддержанию и расширению функциональных
знаний, а какое-то — поиск и разработка прототипов
новых идей. Так были разработаны желтые клейкие
стикеры в 3M и почта Gmail в Google.
Использование Scrum
Если для разработки концепции необходимы более серь-

езные усилия, используйте для этого Scrum. Попросите
владельца продукта, scrum-мастера и команду провести
* Проект браузера Google возглавлял менеджер продукта Брайан

Раковски(Levy, 2008).
мероприятия по выработке продуктового видения, воз-

главлять которые должен владелец продукта. Сначала
в бэклоге продукта будет фигурировать самое общее ви-
дение итогового продукта — например, «Доступны прото-
типы, исследующие варианты дизайна пользовательского
интерфейса» или «Проводятся собеседования с клиента-
ми». В процессе работы в бэклоге продукта появляются
высокоуровневые свойства, описывающие будущий про-
дукт в соответствии с продуктовым видением. Каждый
визионерский спринт будет порождать обновление — шаг
навстречу видению продукта, что в итоге вырастет в ито-
говый продукт. (Если понадобится только один визио-
нерский спринт, то концепция продукта создается по его
результатам.) Например, Supermassive Games — британс-
кая студия по разработке компьютерных игр — исполь-
зует визионерские спринты для организации работы
на раннем этапе, который часто именуется «предпроиз-
водством». Команда создает наброски и прототипы для
дальнейших итераций на пути к общей концепции ком-
пьютерной игры. Прототипы могут быть как моделями
Lego и набросками на бумаге, так и действующими про-
граммами*.
Scrum-команда, вырабатывавшая видение продук-
та, должна в том же составе, за некоторыми ощутимыми
* Личные сообщения Харви Уитона, CEO Supermassive Games, 21 ок-

тября и 2 ноября 2009 года.
исключениями, проводить и разработку. В некоторых слу-

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

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

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

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

строила прототип, состоящий из макета устройства и од-
норазовой реализации самых важных элементов пользо-
вательского интерфейса на Flash. Клиентов пригласили
протестировать прототип, и их отзывы сильно повлияли
на итоговый дизайн. В результате получился новый про-
дукт с прекрасным клиентским интерфейсом.
Планирование, выполнение,
проверка и воздействие
Организованный эксперимент проходит по четырех-
шаговой модели, известной также как цикл Деминга.
Сначала мы вырабатываем гипотезу (планирование).
Затем воплощаем ее (выполнение) и анализируем
результаты (проверка). Если эксперимент оказал-
ся неудачным, мы вносим в гипотезу изменения, где
необходимо, и проводим следующий эксперимент —
либо для достижения лучшего результата, либо что-
бы попробовать другой подход (воздействие). Томас
Эдисон, создатель первой коммерчески успешной
электрической лампочки, знал о неизбежности проб
и ошибок — необходимости многократно ошибиться,
чтобы воплотить в жизнь полноценный продукт. Хо-
рошо известна его фраза:
«Если я обнаружил десять тысяч методов, кото-
рые не работают, это не ошибка. Я не обескуражен,
потому что исключение каждого неверного метода —
это шаг вперед».
Персоны и сценарии
Персоны помогают нам выбрать целевых потребителей.

Сценарии позволяют понять, как продукт изменяет их
жизнь (Cooper, 1999). Персона — это «гипотетический архе-
тип», представляющий целевого клиента или пользовате
ля. Можно считать персону частным случаем носителя
пользовательского сценария или пользовательской роли.
В их описания включается информация, важная для ис-
пользования продукта потребителями: например, долж-
ностные обязанности, навыки или интересы пользователя.
Сформировав корректно персоны, мы можем иссле-
довать то, как продукт, который мы собираемся разра-
батывать, будет влиять на их жизнь. Для этого создаем
сценарии, которые описывают, как персона достигает
своих целей без продукта и с ним. Формальный способ со-
здания таких сценариев — составление карты потребле-
ния: одна ее часть описывает деятельность, необходимую
для достижения конкретной цели без нашего продукта,
другая — деятельность, которая потребуется в будущем,
когда продукт будет доступен (Womack and Jones, 2005).
Использование сценариев и карт потребления позволяет
установить ценностное предложение продукта: необхо-
димы ли выбранные свойства? Создают ли они преиму-
щества для всех персон? Можно ли определить более важ-
ные свойства продукта?
Визуализация и обзор
в отраслевом журнале
Два эффективных метода определения ценностных

и коммерческих аргументов продукта — это его визу-
ализация и обзор в отраслевом журнале. Визуализа-
ция — это макет упаковки, в которой может поставлять-
ся продукт. Для создания визуализации scrum-команда
придумывает название продукта, его графическое отоб-
ражение и три важнейших коммерческих аргумента,
при помощи которых продукт будет продаваться. Ин-
формация размещается на передней части упаковки.
На оборотной части можно указать дополнительные
подробности (Highsmith, 2009; 96–97). Чтобы написать
обзор в отраслевом журнале, члены scrum-команды вы-
ясняют, что бы они хотели прочитать о продукте после
его запуска (Cohn, 2009; 232). Это упражнение сделать
быстро и легко. Его также можно использовать для про-
верки того, все ли одинаково понимают и разделяют
концепцию продукта.
Модель Кано
Модель Кано помогает выбрать нужную функцио-

нальность для создания привлекательного продукта
(Kano, 1984). Она рассказывает, насколько может быть
удовлетворен покупатель при внедрении определенно-

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

летворять скрытые потребности клиентов, о которых те
могли и не догадываться. Именно эти функции продук-
та создают конкурентное преимущество и уникальное
коммерческое предложение.
Проблема в том, что нужно сочетать основные, про-
изводительные и привлекательные функции таким
образом, чтобы желаемые преимущества были макси-
мальными. Полезно бывает применить модель Кано
к продуктовому видению или бэклогу продукта. Как
и в случае видения продукта SoundStation, с которого
мы начали эту главу, продуктовое видение часто сосре-
доточивается на производительных и привлекательных
функциях и редко включает основные, которые можно
найти в бэклоге продукта. Заметьте, что модель Кано
способна делать интересное предсказание: со временем
привлекательные функции превращаются в производи-
тельные, а производительные становятся основными.
Когда конкуренты начинают поставлять схожие продук-
ты, ваши продукты теряют свои преимущества. Чтобы
остаться лидерами, компаниям нужно регулярно обнов-
лять свой продукт, предлагая новые привлекательные
функции. Эта корреляция — еще одна причина того,
чтобы быстро запустить исходный продукт и затем регу-
лярно его обновлять.
Формирование видения
и дорожная карта продукта
До сих пор в этой главе рассматривались вопросы со-
здания видения нового продукта, что особенно сложно.
По мере «взросления» продукта и выхода пошаговых об-
новлений визионерская деятельность обычно сокраща-
ется. Но новым версиям продукта все еще нужны цели.
План развития продукта позволяет scrum-команде сфор-
мулировать цели будущих версий продукта. Пока виде-
ние заключается в создании и корректировке дорожной
карты продукта.
Дорожная карта продукта — это тип плана, который
показывает, как продукт должен развиваться в своих вер-
сиях, и облегчает диалог между scrum-командой и заин-
тересованными лицами. Дорожная карта продукта позво-
ляет организациям координировать разработку и запуск
смежных продуктов — например, линейки продуктов или
продуктового портфеля. Рекомендуется не усложнять
план развития продукта, а сосредоточиться на самой
сути. План развития продукта должен содержать пример-
ную дату выхода следующей версии, указание целевых
потребителей и их нужд и три-пять основных функций.
Не беспокойтесь о деталях. Они появятся и будут отра-
жены в бэклоге продукта. Заметьте, что дорожная карта
продукта никогда не заменит тщательного анализа реак-

ции рынка и соответствующей корректировки продукта.
Он просто утверждает, как, по нашему мнению, продукт
должен развиваться на основе текущего понимания рын-
ка. Дорожные карты продукта — это живые документы,
они эволюционируют.
Составьте дорожную карту сразу после того, как про-
дукт был успешно представлен на рынке. (Появление
пятилетнего плана прежде, чем вышел релиз продукта,
имеет мало смысла. Такой план скорее отражает мечту,
чем предсказывает реальность.) В составлении долж-
ны принимать участие все важные для продукта лица.
К ним относятся scrum-команда, ответственный за про-
дуктовый портфель, представители команд разработки
других продуктов и заинтересованные лица. Убедитесь,
что дорожная карта продукта имеет реалистичные сроки.
В зависимости от рынка и стадии жизненного цикла про-
дукта ограничьтесь 6–12 месяцами и не пытайтесь делать
прогнозы на следующие два-три года.
Минимальные продукты
и варианты продукта
В процессе взросления продукт начинает отвечать все
большему числу потребностей покупателей: обслуживает
потребителей в разных сегментах и регионах. Поскольку
запросы становятся многочисленнее и разнообразнее,

усложн яется выпуск обновлений продукта с минималь-
ной функциональностью. Требуется все больше функций
для поддержки постоянно растущего количества клиентов
и пользователей. Чтобы решить проблему, мы применяем
варианты продукта. Каждый вариант адресован конкрет-
ной группе пользователей и сегменту рынка. Приведем
в качестве примера популярную программу Visio для со-
здания диаграмм. Версия 2007 года доступна в двух вари-
антах: Office Visio Standard 2007 и Office Visio Professional
2007. Первый позиционируется как «базовое средство
визуализации», а профессиональная версия является рас-
ширением Visio Standard 2007 и призвана «помочь биз-
нес- и IT-пользователям визуализировать, анализировать
и представлять комплексную информацию, сложные сис-
темы и процессы». Эти два варианта обслуживают различ-
ные сегменты рынка — домашних и коммерческих поль-
зователей с ограниченной потребностью в диаграммах
и профессиональных пользователей, нуждающихся в до-
полнительной диаграммной функциональности.
Хотя варианты продукта могут стать могущественны-
ми союзниками, слишком большое их количество ведет
к разбуханию продуктового портфеля, высокой стоимос-
ти поддержки и перегруженности клиентов. Представьте
себе, что было бы, если бы Microsoft предлагала четыре
версии Office Visio 2007: Essentials, Standard, Professional
и Deluxe. Потребители затруднились бы с выбором, и им

было бы непросто принять решение о покупке*.
Есть и еще один недостаток: варианты продукта опас-
ны тем, что функциональность придется внедрять снова
и снова, что приведет к высоким издержкам на разработ-
ку и техническую поддержку. Решить эту проблему мо-
жет создание набора шаблонов, общих для всех вариан-
тов. Эти шаблоны называются платформой. Например,
Apple использует общие компоненты для iPhone и iPod
touch. Однако, осознав необходимость введения общих
компонентов, не следует попадаться в ловушку — наде-
яться на создание идеальной мегаплатформы. Начинайте
с малого. Платформа должна расти естественным путем
по мере увеличения необходимости в вариантах продук-
та. Тщательно сохраняйте ее функциональность. Этот
подход, возможно, приведет к рефакторингу архитекту-
ры, но он исключает опасность чрезмерного усложнения
платформы.
Выработка продуктового видения — это необходимый
шаг в подготовке его к запуску. Берегитесь следующих
* Кстати, Microsoft в конце 1990‑х годов предлагала три варианта

Visio — Standard, Pro и Tech. Затем компания решила упростить
свой портфель.
распространенных ошибок: отсутствия видения, про-

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

разработку продукта без какого-либо видения. Это чаще
всего бывает, когда клиенты требуют внедрения в продукт
отдельных функций, не понимая необходимости связи
между ними. Получающийся при этом продукт носит на-
звание функциональной сборной солянки (DeMarco et al.,
2008; 143–145). Избегайте этого: убедитесь, что вы име-
ете концепцию, четко указывающую на клиента, его из-
бранные потребности и важнейшие свойства продукта.
Эта концепция затем позволит определить, какие функ-
ции следует внедрить, и поможет создать полезный и цен-
ный продукт.
Пророческое видение
Несмотря на то что продуктовое видение рисует карти-

ну будущего продукта, это предсказанное будущее мо-
жет никогда не наступить. Переработка видения в про-
дукт — это предпринимательская деятельность, которая
подразумевает риск. Как вы помните, видение Expertcity

вылилось в продукт, который не оправдал ожиданий.
То есть даже видение не страхует от неудачи. Однако, как
и в случае с Expertcity, провал может стать первым шагом
к успеху. Например, программа GoToMyPC стала результа-
том неудачного первого релиза. Чтобы свести к миниму-
му любые потенциальные убытки или ущерб от неточного
прогноза, выбирайте узкий набор потребностей клиента
и почаще выпускайте обновления. Затем анализируйте
и вносите изменения.
Аналитический паралич
Как уже говорилось, не стоит увлекаться предваритель-

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

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

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

кая ПО.
«Большое — значит хорошее»
Создание продуктов с огромным количеством функций

может, как отмечают Престон Смит и Дональд Райнерт-
сен, создать большую шумиху вокруг вашей компании
(Smith and Reinertsen, 1998; 67):
Всем нам нравятся истории успеха разработки,

достигнутого героическими стараниями. Команда
разработчиков берется за, казалось бы, невоз-
можный проект и прилагает сверхчеловеческие
усилия… Эти проекты похожи на длинные пере-
дачи, приводящие к тачдауну* и сводящие с ума
болельщиков. Они гораздо интереснее, чем обыч-
ная игра, в которой за один раз не проходишь
и 10 метров.
Но какими бы увлекательными ни были огромные

проекты, есть у них и недостатки: на них уходит мас-
са денег и времени, при этом очень велик риск провала.
* Тачдаун — один из способов набрать очки в американском и ка-

надском футболе. Прим. ред.
«Компании часто совершают ошибку — пытаются найти

идеальное решение, которое с первого же дня всех устро-
ит. Часто это выливается в создание слишком сложных
дорогих продуктов, которые не очень хорошо функцио-
нируют» (Anthony et al., 2008; 125). При этом в больших
проектах очень сложно развивать продукт на основании
отзывов клиентов и пользователей, поскольку многие
функции предопределены.
Этой ошибки можно избежать, начав с работы над
продуктом, призванным удовлетворить узкий набор кли-
ентских требований и предлагающим минимальную,
но достаточную функциональность. Быстро запустите
его, изучите реакцию рынка и внесите соответствующие
изменения.

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

для концепции, обсуждавшиеся в этой главе.
— Преследуют ли ваши продукты общие цели?

— Как вырабатываются цели и кто их формулирует?
— Как выработать концепцию, обладающую описан-
ными в этой главе качествами?
—К
ак такая концепция обогатит вашу инновационную
деятельность?
3
Работа с бэклогом
продукта
Немногие элементы Scrum могут похвастаться такой по-

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

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

продукта
Элементы бэклога продукта обладают четырьмя свой
ствами: имеют достаточную степень детализации, оце-
нены, независимы и приоритизированы — в английском
языке получается удобная аббревиатура DEEP (от detailed,
estimated, emergent, prioritized) — глубинный*. Рассмот-
рим эти свойства подробнее.
Достаточная степень детализации
Элементы бэклога продукта имеют достаточную степень

детализации, это показано на рисунке 3.1. Элементы с бо-
лее высоким приоритетом описаны подробнее, чем ме-
нее важные. «Чем ниже приоритет, тем меньше деталей,
* Аббревиатуру DEEP придумал Майк Кон.

3. Работа с бэклогом продукта 103
вплоть до полного минимума», — пишут Швабер и Бидл

(Schwaber and Beedle, 2002; 33). Следуя этому правилу,
вы сохраняете бэклог продукта минималистичным, а его
элементы — реализуемыми в течение спринта. В резуль-
тате требования выявляются, декомпозируются и дета-
лизируются в течение всего проекта.
Очень подробно прописанные

Высокий Бэклог продукта элементы, готовые к внесению
в следующую итерацию, — например,
краткие пользовательские истории
Элементы со средней детализацией —
например, длинные пользовательские
Приоритет
истории
Обобщенные элементы, например

эпики
Низкий
Рисунок 3.1. Степень приоритетности элемента бэклога

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

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

ются в спринт-бэклоге.
Развитие
Развитие бэклога продукта имеет естественный харак-

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

тетности. Самые важные внедряются в первую очередь.
Они находятся в верхней части бэклога продукта, как по-
казано на рисунке 3.1. После завершения работы над эле-
ментом он удаляется из бэклога.
Работа над бэклогом продукта

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

ние, с ним рекомендуется постоянно работать. Работа
над ним — это непрерывный процесс, состоящий из ука-
занных ниже шагов. Правда, они не всегда выполняются
именно в таком порядке.
— Выявляются и описываются новые элементы, а су-
ществующие при необходимости изменяются или
удаляются.
— Происходит расстановка приоритетов. Самые важ-
ные задачи помещаются в верхнюю часть.
— Высокоприоритетные элементы подготавлива-
ются к ближайшему совещанию по планирова-
нию спринта. Они декомпозируются и детализи
руются.
— Команда определяет масштаб элементов бэклога
продукта. Это необходимо ввиду внесения в него
новых элементов, изменения существующих и ис-
правления оценок.
Хотя владелец продукта отвечает за хорошее состоя-
ние бэклога продукта, работа над ним — это командный
процесс. Выявляются и описываются элементы, они вы-
страиваются по приоритету, декомпозируются и детали-
зируются всей scrum-командой. В Scrum выделяется на эту
деятельность до 10% командного времени (Schwaber,
2007). При необходимости в процесс вовлекаются и за-
интересованные лица. Требования больше не спускаются
команде сверху, в их формулировании принимают учас-

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

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

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

создания. Лучше всего это делается совместными усили-
ями: члены scrum-команды и при необходимости заин-
тересованные лица в ходе мозгового штурма выявляют
элементы, нужные для создания продукта, используя в ка-
честве точки отсчета его идею, его видение или дорожную
карту. При этом не пытайтесь думать обо всех элементах
сразу. Каждый раз, когда вы работаете с бэклогом, сосре-
доточивайтесь на минимальной функциональности, необ-
ходимой для выхода продукта на рынок, и придерживай-
тесь принципа простоты, который обсуждался в главе 2.
В ходе проекта появятся новые идеи, и бэклог продукта
будет развиваться в соответствии с отзывами клиентов
и пользователей. Если в самом начале бэклог продукта
станет слишком длинным и сложным, будет трудно сосре-
доточиться и правильно расставить приоритеты. Исполь-

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

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

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

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

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

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

элемент элемент
Электронная Создать элект- Как корпоративный 1
почта ронное письмо пользователь, я хочу
создавать тему письма
Темы в таблице 3.1 содержат обобщенные элементы.

Со временем они декомпозируются на более детально
описанные элементы. После оценки элемента коман-
дой фиксируется общий размер бэклога. Структуру
из таблицы 3.1 можно применять вне зависимости

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

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

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

принять, также называется самым поздним ответственным реше-
нием (Poppendieck, 2003)
реализовать самые ценные элементы бэклога продукта.

Но что делает элемент бэклога ценным? Ответ прост —
его важность для выхода продукта. Если это не так, то
элемент не имеет значения и его можно исключить из те-
кущего релиза или версии продукта. Scrum-команда либо
лишает такой элемент приоритетности и помещает его
в самый низ бэклога, либо отказывается от него. Если
элемент важен для какой-то из будущих версий, то он по-
явится вновь.
Прежде чем включить элемент в релиз, нужно понять,
не будет ли продукт и без данного элемента приносить те
же преимущества. Это помогает создать простой продукт
с минимальной функциональностью, как описано в гла-
ве 2. Apple, например, выпускала iPhone первого и второ-
го поколения без возможности копирования и вставки,
что не повредило успеху гаджета. Если элемент действи-
тельно нужен, подумайте, нет ли альтернативы, которая
приносит те же выгоды, но требует меньше усилий, вре-
мени или денег. Команды, к сожалению, часто сдержива-
ют какие-то неявные ограничения, поэтому они не всегда
способны оценить все варианты.
Тщательно нужно проверять не только новые требо-
вания. Постоянно пересматривайте и уже существующие.
По мере того как scrum-команда осознает потребности
клиента, часто возникают более интересные альтернати-
вы и вырабатываются решения. Упрощайте, сокращайте
и стремитесь к порядку, как садовник, выпалывающий

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

продукта. Каждое решение, касающееся проекта (при-
нимается оно явно или по умолчанию), связано с риска-
ми», — пишут Смит и Мерритт (Smith and Merritt, 2002; 4).
Таким образом, риск — неотъемлемая часть разработки
ПО. Ни один продукт без риска просто не выпустить.

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

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

ваше ПО в продукт, любимый покупателями, о чем будет
говориться в главе 4.
Кроме того, это хороший способ уменьшить риски.
Если scrum-команда сомневается, стоит ли внедрять
функцию и как именно это делать, ранние релизы помо-
гут ответить на этот вопрос, как в упоминавшемся случае
с Google News.
Таким образом, возможность быстро и часто выпус-
кать обновления продукта должна оказывать влияние
на расстановку приоритетов в бэклоге продукта. Каждый
релиз должен предлагать такую функциональность, кото-
рая будет полезна клиентам и пользователям и породит
желаемые отзывы. При этом обычно полное внедрение

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

ный факт. Например, функциональные требования часто
зависят от других функциональных и даже нефункцио-
нальных. А если вместе работают несколько команд, то
взаимозависимости между ними могут влиять на рас-
становку приоритетов, о чем подробнее говорится в гла-
ве 4. Взаимозависимости ограничивают свободу выбора
приоритетов и сказываются на оценке усилий: элемент,
на который влияют другие, придется внедрять первым.
Поэтому следует по возможности решать вопрос с взаимо
зависимостями.
Объединение нескольких зависящих друг от дру-
га элементов бэклога продукта в один более крупный
и переформулирование для устранения зависимости —
вот два основных метода работы с взаимозависимыми
пользовательскими историями (Cohn, 2004; 17). Рассмот-
рим в качестве примера две истории: «Я как пользователь
хочу написать текстовое сообщение» и «Я как пользова-
тель хочу написать электронное письмо». Они зависят
друг от друга, поскольку обе связаны с обработкой текста.

Если сначала внедрить текстовые сообщения, это сокра-
тит усилия на работу с электронными письмами, и наобо-
рот. Первый вариант — соединить их в более крупную
пользовательскую историю — не очень подходит нам,
поскольку история получается слишком сложной. Второй
вариант — разбить требования по-иному. Если общая
функциональность выделяется в отдельную историю —
«Я как пользователь хочу вводить текст», то две исходные
истории больше не зависят друг от друга. Таким обра-
зом, их оценка больше не связана с порядком работы над
ними.
Подготовка к планированию
спринта
Перед каждым совещанием по планированию спринта
нужно подготовить элементы бэклога продукта, которые,
по всей вероятности, будут реализованы в ходе ближай-
шего спринта. Начинать следует с выбора цели спринта.
Выбор цели спринта
Цель спринта формулирует его желаемый резуль-

тат. Он должен подвести scrum-команду на шаг ближе
к запуску успешного продукта. Один владелец продукта

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

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

сколько нужно
Как только избрана цель спринта, нужно подготовить

ровно столько элементов для будущего спринта, сколь-
ко нужно и когда нужно*. (Крупные проекты, при ра-
боте над которыми необходимо заглядывать далеко
вперед, описаны ниже в этой же главе.) Работа с бэкло-
гом продукта во время первого спринта строится вок-
руг элементов для второго спринта, во время второго
спринта — вокруг элементов для третьего и т. д. У тако-
го подхода есть ряд преимуществ: сводятся к минимуму
траты времени и денег на описание элементов, а также
снижается количество элементов, нуждающихся в под-
робном описании. Избыточное количество информа-
ции — это пустая трата сил. Подробно описывая лишь
те элементы, которые, вероятнее всего, понадобятся для
* Термины «сколько нужно» и «когда нужно» впервые использованы

в работе Кона (Cohn, 2008) для описания работы над бэклогом про-
дукта.
следующего спринта, мы даем бэклогу продукта воз-

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

Малый необра- ществимые
ботанные и контролиру-
элементы емые элементы
Низкий Высокий Уровень детализации
Рисунок 3.2. Расширение и улучшение компонентов бэклога

продукта
Количество элементов, которые следует подготовить,

зависит от общей скорости работы команды и желаемой
проработанности элементов. Чем выше скорость коман-

ды, тем больше элементов нужно подготовить. Стоит
подготовить несколько дополнительных элементов, это
придаст команде гибкость. Кроме того, они будут под ру-
кой, если команда продвинется вперед быстрее, чем ожи-
далось. Полезно также работать с небольшими требова-
ниями, с которыми можно справиться за несколько дней
независимо от продолжительности спринта.
Это идет на пользу при отслеживании прогрес-
са команды в спринте, а следовательно, повышает
самоорганизацию: прогресс команды основывается
не только на оставшихся задачах, но и на том, сколько
внедряемых функций уже протестировано и задокумен-
тировано. Небольшие требования сводят к минимуму
и объем одновременной деятельности, и риск не до-
делать работу до конца или выполнить ее с ошибками
в конце спринта. К тому же небольшие элементы облег-
чают реалистичное выполнение задач. Большие могут
содержать так много заданий, что команда не сможет
их все выявить.
Декомпозиция элементов
Декомпозиция элементов бэклога продукта — это посте-

пенное их уменьшение до степени готовности для сприн-
та. Такой процесс, известный также как последовательная
декомпозиция элементов (Reinertsen, 1997), может зани-

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

Выбрать полу-
корпоративный
чателя: Я как
пользователь хочу
задать тему
выбрать одного
Задать полу- или нескольких
Создать электрон-
чателя: Я как получателей
ное письмо: Я как
корпоративный из своего списка
пользователь хочу контактов
задать одного
создать электрон-
или нескольких Ввести получате-
ное письмо
получателей ля: Я как корпора-
тивный пользова-
Задать важность:
тель хочу ввести
Я как корпора-
получателя
тивный пользова-
тель хочу задать
важность
Рисунок 3.3. Декомпозиция пользовательских историй
Как показано на рисунке 3.3, scrum-команда из-

начально вписала в бэклог продукта эпик «Создать
электронноеписьмо». Поскольку это слишком большая

и неопределенная задача для одного спринта, эпик раз-
делили на несколько недетализированных пользова-
тельских историй. История «Задать получателя» была
затем вновь разбита на две более подробные пользо-
вательские истории. Теперь они достаточно малы для
спринта. Эпик — это пример сложной истории, то есть
пользовательской истории, имеющей не одну цель
(Cohn, 2004; 24–25). Для декомпозиции подобной ис-
тории вводим отдельную историю для каждой цели.
Таким образом, «Создать электронное письмо» разде-
ляется на «Задать тему», «Задать получателя» и «Задать
важность».
Затем нужно подвергнуть декомпозиции и другие
пользовательские истории, в том числе сложные и име-
ющие слишком много критериев. Обычно сложная поль-
зовательская история слишком велика для разработки
за один спринт из-за внутренней неопределенности
или слишком большой функциональности (Cohn, 2004;
25–26). Если она чересчур туманна, мы вводим в бэклог
продукта один или несколько элементов, исследующих
эту неопределенность и порождающих соответству
ющие знания, например: «Исследовать JavaServer Faces
как технологию пользовательского интерфейса». Если
история описывает слишком много функций, то мы раз-
биваем ее на несколько, чтобы впоследствии пошагово
добавлять функциональность. Эта техника известна как

разрезание торта (Cohn, 2004; 76). Например, пользова-
тельскую историю «Проверка пользователя» можно раз-
ложить на «Проверку имени пользователя» и «Проверку
пароля».
Иногда кажется, что с историями все в порядке,
но только до определения критериев приемлемости.
Если их более десяти или если требования скрывают-
ся в самих критериях, то нужно переработать историю
и подвергнуть ее декомпозиции. Вот пример: «Я как
пользователь хочу удалить текстовое сообщение». Кри-
терии приемлемости таковы: «Я могу выбрать любое
текстовое сообщение. Я могу удалить текст сообщения.
Я могу сохранить измененное сообщение». Во-первых,
второе условие избыточно, а во-вторых, два других вво-
дят новые требования, а не указывают критерии прием-
лемости. Такую историю нужно разбить на три части —
историю об удалении текстовых сообщений, о правке
текстовых сообщений и о сохранении измененных сооб-
щений.
Обеспечение четкости, проверяемости

и осуществимости
Когда элемент доведен до достаточно малого разме-

ра, следует убедиться в его четкости, проверяемости
и осуществимости*. Требование считается четким,

если все члены scrum-команды одинаково понимают его
смысл. Совместное описание требований и выражение
элементов бэклога продукта в простой и сжатой форме
облегчают достижение четкости. Элемент называют про-
веряемым, если существует эффективный способ опреде-
лить удовлетворенность реализацией требования в тече-
ние спринта. У истории должны быть критерии приемки,
которые определяют ее проверяемость. Элемент являет-
ся осуществимым, если он может быть внедрен за один
спринт в соответствии с критериями приемки, приня-
тыми в команде. (О стандартах осуществления гово-
рится в главе 5.) Для обеспечения осуществимости мы
оцениваем зависимость от других элементов, в том чис-
ле функциональных и нефункциональных требований.
Если история ограничена, например, требованием поль-
зовательского интерфейса, то должно быть ясно, каким
будет получающееся обновление продукта. В противном
* Билл Уэйк предложил так называемые INVEST-критерии, имея

в виду, что истории должны быть независимыми (independent),
согласуемыми (negotiable), ценными (valuable), удобными
для оценки (estimatable), небольшими (small) и контролиру
емыми (testable) (Wake, 2003). Взаимозависимости и ценности
обсуждаются в разделе расстановки приоритетов, об оценке
говорится в этой главе. Под согласуемостью понимается воз-
можность изменения пользовательской истории. Как сказал Рон
Джеффрис, история — это обещание диалога, а не жесткое тре-
бование.
случае команда должна перед реализацией пользова-

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

историй*.
Очки историй
Очки за пользовательскую историю — это приблизи-

тельные, относительные единицы измерения сложнос-
ти и трудоемкости**. Элемент, который стоит одно очко
за пользовательскую историю, равен половине элемента,
стоящего два очка. Элемент, оценивающийся в три очка,
требует столько же усилий, как одноочковый и двухоч-
ковый, вместе взятые. Относительные измерения поль-
зуются тем фактом, что размер сам по себе относителен,
значения большого и малого зависят от точки отсчета.
Так, компьютерная мышь невелика по сравнению с ноут-
буком, но большая, если ее сравнить со слотом памяти.
Распространенный спектр очков за пользовательскую ис-
торию приведен в таблице 3.2.
Нелинейная последовательность из таблицы 3.2 уско-
ряет процесс принятия решений командой. Она предот
вращает продолжительные дискуссии об «истинной цен-
ности», которые могут возникнуть при использовании
линейных последовательностей.
* Более подробное и полное описание методов оценки см. в: Cohn,

2005.
** Время оценивается отдельно по соотношению усилий и скорости
работы, о чем пойдет речь в главе 4.
Таблица 3.2. Распространенный спектр очков

за пользовательскую историю
Очки Размер футболки

0 Подарок — элемент уже внедрен
1 XS Очень маленький
2 S Маленький
3 M Средний
5 L Большой
8 XL Очень большой
13 XXL Двойной очень большой
20 XXXL Огромный
Команда может продолжить спектр, представлен-

ный в таблице 3.2, добавив более крупные значения —
40 и 100, если сопоставление сравнительных оценок ос-
тается верным. Однако какой бы спектр значений ни был
бы избран, последовательность должна быть удобной для
команды и оставаться неизменной. Поскольку очки исто-
рий — критерий относительный и произвольный, нельзя
сравнивать их у разных команд, если только они не дого-
ворились об общем спектре очков с общей семантикой.
Покерное планирование
Очки историй — хороший, но недостаточный инстру-

мент. Нам нужен метод эффективной командной оцен-
ки, и он существует — это покерное планирование
(Cohn, 2005; 56–59). В покерном планировании каждому

члену команды выдается колода карточек, которая содер-
жит определенное количество очков. Если мы использу-
ем, например, спектр из таблицы 3.2, то в колоде будет
восемь карточек, каждая из которых имеет одно из зна-
чений спектра. Оценка начинается сразу после того, как
участникам будут розданы все карточки.
Если команда оценивает элементы бэклога продукта
впервые, то ей нужно решить, что для нее кроется за зна-
чениями спектра. Для этого многие команды выбирают
такой элемент бэклога, который, по общему мнению,
является наименьшим, и используют его в качестве эта-
лона оценки. Или команда может выбрать наименьший,
наибольший и среднего размера элементы и оценить их
по очереди. Если же команда уже знакома со спектром, то
она обычно начинает работу с элемента с самым высоким
приоритетом и двигается по списку вниз.
Перед оценкой владелец продукта объясняет элемент
членам команды, а те кратко обсуждают, какие шаги нуж-
но предпринять для разработки элемента в соответствии
с приемочными критериями. После обсуждения каждый
член команды независимо от других определяет значение
элемента, не делая каких-либо предположений по поводу
того, кто будет внедрять этот элемент, поскольку это ре-
шится только на ежедневном scrum-митинге. Каждый член
команды выбирает карточку с нужной оценкой и кладет ее
на стол лицевой стороной вниз. После того как все положи-

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

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

ра: команда должна понимать, что нужно для внедрения
элемента, ее члены — уметь выявлять взаимозависимости
этого элемента с другими, а критерии готовности долж-
ны быть доступными. Если команда не может оценить
элемент, необходимо добавить в бэклог продукта новый
элемент, который создаст требуемое знание, например:
«Создание прототипа или макета для исследования вари-
антов дизайна пользовательского интерфейса».
Только члены команды, занимающиеся реализаци-
ей инкремента продукта, должны оценивать элементы
бэклога. Владелец продукта и scrum-мастер не принима-
ют участия в оценке и не влияют на ее результаты (если
они не являются одновременно рядовыми сотрудниками
команды или если команда не обращается к ним за сове-
том). Однако владелец продукта должен присутствовать
на совещании. Многие элементы бэклога продукта будут
выглядеть довольно приблизительно, так что владельцу
продукта потребуется их объяснить и конкретизировать.
Экспресс-оценка
Если команда слишком ограничена во времени для
покерного планирования, можно использовать сле-
дующий метод оценки. Разделите одну стену кон-
ференц-зала на несколько частей, каждая из кото-
рых будет отражать одно из значений спектра очков
за пользовательскую историю. Распечатайте на бу-
мажных карточках элементы бэклога продукта и по-
ложите их на стол. Пусть все члены команды возьмут
по карточке, примут решение об оценке и прикрепят
карточку на ту часть стены, которая соответствует
избранному ими значению. При этом элемент должен
соответствовать по размеру другим элементам той же
группы. Если кто-то видит неподходящую карточку,
он сразу перемещает ее в нужную группу. Этот про-
цесс дает возможность очень быстро и с минималь-
ными усилиями оценить многие элементы. Основной
недостаток состоит в том, что команда не обсуждает
размер элементов. Поэтому качество оценки обычно
ниже по сравнению с результатами покерного плани-
рования.
Работа с нефункциональными
требованиями
Нефункциональные требования, также именуемые опе-
рационными, свойствами системы и ограничителя-
ми, — это настоящие гадкие утята разработки ПО. Ими
часто пренебрегают, хотя они описывают такие важные

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

как ограничители (Newkirk and Martin, 2001; 16–18). На-
пример, можно описать требование к производительнос-
ти, как показано на рисунке 3.4.
Ограничитель Критерий приемлемости

производительности — 10 000 транзакций чтения и записи
Система должна происходят одновременно
отвечать на любой — Каждая транзакция имеет
запрос менее чем размер 500 Кб
за одну секунду — Конфигурация системы —
«небольшое предприятие»
Рисунок 3.4. Нефункциональное требование,

сформулированное как ограничитель
Требования пользовательского интерфейса часто

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

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

Функциональные требования Нефункцио

Тема Приблизитель- Детализирован- Уси- нальные
ное требование ное требование лия требования
Элект- Создать элект- Я как корпора- 1 Продукт дол-

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

кальные нефункциональные требования относятся
только к конкретному функциональному требованию —
например, требованию к производительности по получе-
нию информации. Если нефункциональное требование
выражено как ограничитель, просто добавляем этот ог-
раничитель к истории (Newkirk and Martin, 2001) и (Cohn,
2004). Это можно сделать, аннотировав историю ограни-
чителем.
Бэклог продукта
при масштабировании
Большие проекты, в которых принимает участие мно-
го команд, приносят новые проблемы. Одна из них —
что делать с бэклогом продукта при масштабировании.
Для успехаиспользуйте один бэклог, прорабатывайте его

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

продукта
Для работы над каждым большим scrum-проектом нужен

один бэклог продукта, содержащий описание всего функ
ционала, необходимого для создания продукта. Избегай-
те отдельных журналов для каждой команды или ком-
понента, где требования к продукту трансформируются
в требования к подсистеме или компоненту. Это приво-
дит к лишнему объему работы, поскольку содержание
должно быть выделено из общего потока требований, ко-
торый должен прорабатываться, а при реализации надо
постоянно следить за синхронизацией. Постарайтесь
давать всем командам указания из общего бэклога про-
дукта, отдавая при этом предпочтение функциональным
командам, о чем говорилось в главе 1. Дэрин Фишер, один
из инженеров проекта браузера Chrome, так описывает
действия Google по работе с одним бэклогом продукта
в рамках большого проекта: «Когда дело дошло до требо-
ваний, многие процедуры свелись к совещаниям в фор-
мате мозгового штурма, где мы обсуждали функционал.
У нас в Google была открытая внутренняя рассылка, там
люди могли выразить свое мнение по поводу того, как

сделать лучше… Мы старались, чтобы элементы бэклога
продукта были конкретными и минималистичными. За-
тем мы предлагали этот список команде, и ее члены сами
выбирали, над чем хотят работать»*.
Расширьте горизонт груминга
Элементы бэклога продукта в больших scrum-проектах

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

бэклога продукта
Крупные agile-проекты, в которых участвует несколько

функциональных команд, могут выиграть от использо-
* Интервью Коллин Фрай с Дэрином Фишером на сайте

SearchSoftwareQuality.com, 1 октября 2008 года.
вания разных представлений о бэклоге продукта (Cohn,

2009; 330–331). Каждое представление соотносится с оп-
ределенным разделом. Если в течение следующих не-
скольких спринтов функциональная команда работает,
например, по теме «органайзер», то видение бэклога для
команды ограничивается соответствующим разделом.
Это может предотвратить конфликты между нескольки-
ми владельцами продукта и командами, использующими
один и тот же бэклог.
Хотя бэклог продукта — это очень простой инструмент,
использовать его правильно не всегда просто. Избегайте
таких распространенных ошибок, как спецификация под
видом бэклога продукта, письмо с просьбами к Санта-
Клаусу, навязывание требований команде, пренебреже-
ние работой по грумингу бэклога и создание нескольких
бэклогов для одной команды.
Замаскированная спецификация
Спецификация под видом бэклога продукта — это насто

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

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

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

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

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

ботать над проектом» (Beck et al., 2001).
Пренебрежение грумингом
Большинство совещаний по планированию спринтов

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

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

разочарованы, ведь проходит масса времени, прежде чем
что-то делается! Казалось бы, в одновременной работе
над несколькими продуктами нет ничего плохого: все за-
няты, над всеми требованиями трудятся… Но мгновенно
ничего не происходит. Напротив, у команды нет общей
цели спринта, а драгоценное время тратится на переклю-
чение между задачами. Если вашей команде приходится
работать с несколькими бэклогами, сделайте так, что-
бы каждый спринт был выстроен вокруг только одного
продукта. Лучше всего попросить команду работать над
единственным продуктом в течение нескольких сприн-
тов, чтобы она могла быстро выпустить новую версию.
Затем можно переходить к следующему. Этот подход тре-
бует расставить приоритеты для продуктов и назначить
процедуру для управления продуктовым портфелем.
В проблеме моего клиента в итоге оказался виноват CEO
компании, который хотел, чтобы все было сделано «еще
вчера», и не мог назначить приоритеты, которыми могли
бы руководствоваться владельцы продукта.

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

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

требования?
— Обладает ли ваш продукт DEEP-характеристиками?
Как ведется работа над грумингом бэклога вашего
продукта?
— Насколько сложно коллективно выявлять и описы-
вать требования при каждом спринте?
— Как вы работаете с нефункциональными требова-
ниями? Где и как они фиксируются?
4
Планирование релиза
«Планирование… — это поиск ценности», — пишет

Майк Кон (Cohn, 2005; 5), а планирование релиза подде-
рживает разработку и запуск успешного продукта. Оно
облегчает диалог между scrum-командой и заинтересо-
ванными лицами и отвечает на вопрос, какая функцио-
нальность будет включена в ближайший релиз продук-
та. Планирование релизов происходит в течение всего
проекта, поскольку команда прислушивается к отзывам
клиентов и пользователей и реагирует на них. Переход
от основанного на документах и отчетах планирования
к диалогу и беседам позволяет scrum-команде использо-
вать простые методы планирования, отчего планы ста-
новятся проще и прозрачнее. Несмотря на то что плани-
рование релиза — это совместный труд, ответственный
за принятие всех необходимых решений — владелец
продукта.
В этой главе рассказывается об основных идеях и ме-

тодах планирования релиза. Более подробно они описаны
в книге Agile Estimating and Planning (Cohn, 2005).
Время, затраты
и функциональность
Планирование релиза начинается с принятия решения
о том, какая из составляющих проекта — время, затра-
ты или функциональность — должна остаться неизмен-
ной для запуска успешного продукта. Необходим ли за-
пуск именно в указанную дату? Жестко ли задан бюджет
на разработку? Нужно ли реализовать все требования,
отраженные в бэклоге продукта? Одновременная фикса-
ция времени, бюджета и функциональности невозможна.
По крайней мере одна из составляющих должна играть
роль высвобождающего клапана. Самое удачное реше-
ние — ограничить время и делать гибкой функциональ-
ность.
Фиксирование функциональности — плохой вари-
ант. Даже при наличии видения продукта его точные
свойства, функциональность и особенности не известны
сразу. Они открываются постепенно, на основе отзывов
клиентов и пользователей. Появляются новые требо-
вания, бэклог продукта развивается по мере того, как
4. Планирование релиза 149
scrum-команда больше узнает о потребностях клиентов

и возможностях их удовлетворения. Попытка фиксиро-
вать функциональность вредит способностям команды
адаптировать продукт к отзывам пользователей. В ре-
зультате получится не тот продукт, который могут полю-
бить покупатели.
Определить дату запуска легче, если есть видение
продукта. Оно позволяет установить возможное окно —
временной интервал, когда продукт должен быть запущен
для получения желаемых выгод. Фиксация этого окна
защищает время как самый важный и труднодоступный
ресурс. Если пропустить нужную дату, то возможность
будет упущена и запуск продукта окажется бессмыслен-
ным. Выбор даты запуска на основании работы, записан-
ной в бэклоге продукта, — не лучшая идея, поскольку это
заставляет команду заморозить требования и часто при-
водит к плохой оценке. На деле реальный срок работы,
основанный на требованиях, может составлять 60–160%
от примерного. Так, проект, рассчитанный на 20 не-
дель, может занять от 12 до 32 недель (Cohn, 2005; 4).
Это хорошо известное соотношение называется «ворон-
ка неопределенности»*. Определение возможного окна
вместо попыток оценить вероятную дату запуска позво-
ляет избежать этих проблем.
* Термин «воронка неопределенности» впервые предложен Барри

Бемом.
Фиксация даты позволяет создать постоянный ритм

для инноваций. Это достигается выбором единого вре-
менного ограничения для всех релизов. Звучит неверо-
ятно? Но именно так поступили в Salesforce.com — ве-
дущем поставщике услуг по управлению связями с за-
казчиками по запросу. И преуспели. В 2006 году после
нескольких лет быстрого роста Salesforce.com оказалась
в неприятной ситуации. Способность компании выпус-
кать новые продукты сократилась до одного в год, резко
упала и производительность. Чтобы вернуть упущенное,
команда внедрила методологию Scrum. Крис Фрай, вице-
президент по разработке платформ Salesforce.com, пояс-
няет:
Решение перейти к agile-методам в Salesforce.com

выросло из желания быстрее выпускать более пред-
сказуемые релизы. Мы уже год не выпускали ни од-
ного крупного релиза и хотели перейти к более пред-
сказуемому расписанию выхода продуктов, которые
будут приносить ценность покупателям на постоян-
ной основе.
После внедрения Scrum Salesforce.com стала сле-

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

программного продукта, технические операции и внут-
ренние IT-системы», — заявляет Стив Грин, вице-прези-
дент по управлению программами и гибкой разработке
в Salesforce.com*. Результаты оказались поразительны-
ми. Salesforce.com стала вырабатывать на 97% больше
функций благодаря кратким устойчивым циклам рели-
зов. В то же время компании удалось сократить время
на разработку новой функциональности на 61%. Оценка
и планирование стали точнее и эффективнее. Клиенты
Salesforce.com могли твердо рассчитывать на следующий
релиз. В то же время вырос и моральный дух разработчи-
ков (Greene and Fry, 2008).
Фиксация даты и работа со стабильными scrum-
командами существенно упрощают выработку бюджета,
если считать оплату труда основным фактором издержек.
Когда проект приходится масштабировать, точное пред-
сказание бюджета оказывается сложным делом, особен-
но при разработке новых программных продуктов. Если
бюджет подвергается опасности или превышен, владель-
цу продукта придется сделать выбор — представить про-
дукт с меньшей функциональностью или повысить его
стоимость, подключив к проекту дополнительных со-
трудников (если эти новые члены смогут за оставшееся
* Личное сообщение Стива Грина, 16 апреля 2009 года.

время повысить производительность). Apple, например,

решила увеличить затраты и добавила сотрудников
к своему первому проекту iPhone, чтобы успеть к дате
релиза. При этом не стоит забывать о законе Брукса:
«Увеличение числа участников при подготовке опазды-
вающей программы только замедляет процесс» (Brooks,
1995; 25).
Как насчет контрактов

с фиксированной стоимостью?
Если есть выбор, избегайте проектов с фиксирован-
ным объемом работ и фиксированной стоимостью.
Если это невозможно, то попробуйте следующее: раз-
делите контракт с фиксированной ценой на две час-
ти и делайте два последовательных проекта. В ходе
первого проекта вырабатывается и частично внедря-
ется за два-три спринта видение продукта. В конце
проекта бэклог продукта подвергается изменениям
в соответствии с отзывами клиентов. Это позволяет
разработать реалистичный план релиза и примерный
бюджет на второй проект, где продолжается разра-
ботка продукта. Помните, что Scrum — это процесс
прорывных инноваций. Как и в случае с другими
прорывными инновациями, клиенты и покупатели,
возможно, не захотят иметь дело с этим процессом,
поскольку считают, что у них уже есть работающее
решение.
Стабильность качества
Как мы убедились, функциональность продукта разви-
вается. Его точность тоже может возрастать в ходе про-
екта: улучшаются внешний вид, ощущения и опыт ис-
пользования. Но качество продукта в Scrum стабильно.
Критерии качества зафиксированы в критериях готов-
ности. Такое определение обычно подразумевает, что
результат каждого спринта должен быть (потенциаль-
но) готов к постановке инкремента продукта: это бу-
дет исполняемая программа, проверенная, задокумен-
тированная и готовая к релизу. Обеспечение качества
и меры контроля образуют неотъемлемую часть любо-
го спринта. Они не проводятся в конце проекта задним
числом.
Необходимо убедиться, что в ходе спринтов дей
ствительно создаются обновления нужного качества.
Владелец продукта не должен поощрять компромиссы
в качестве программ: не следует принимать результа-
ты работы, не соответствующие заданным критериям.
Ненадлежащее качество ведет к дефектным обновле-
ниям продукта, поэтому не получается четко отслежи-
вать прогресс и выпускать частые и быстрые релизы.
Более того, компромиссный подход к качеству имеет
долгосрочный отрицательный эффект. Вырабатывается
технический долг — программы, которые трудно улуч-

шать и поддерживать (Cunningham, 1992). Это может
повредить репутации бренда и оставить потребителей
неудовлетворенными. Недостаточное качество про-
грамм — результат уступок в долговременном росте
в пользу краткосрочных выгод. Вы сами себя лишаете
успешного, яркого будущего.
Быстрые и частые релизы

«Наш приоритет — удовлетворить покупателя, часто
и постоянно выпуская ценные программы», — утвержда-
ется в agile-манифесте, а далее приводится рекомендация:
«Почаще выпускайте рабочие программы — с интерва-
лом от пары недель до пары месяцев, но предпочтительны
более короткие интервалы» (Beck et al., 2001). Быстрый
и частый выпуск инкремента продукта для целевых пот-
ребителей вместо разового выхода законченного продук-
та порождает ценные отзывы*.
Это дает продукту возможность изменяться на основе
отзывов пользователей и экономит scrum-команде время,
* Быстрые и частые релизы — не новая идея, они восходят к идее

эволюционной разработки Тома Гилба (Gilb, 1988). Экстремальное
программирование также придерживается идеи частых релизов,
именуя их короткими релизами (Beck, 2000) и поэтапным развер-
тыванием (Beck and Andres, 2005).
предотвращая внедрение лишних функций и выпуск про-

дукта с избыточной или недостаточной функциональнос-
тью. Создается именно то, что нужно.
Частые релизы эффективны, поскольку клиенты
и пользователи могут применить продукт на практике,
а не просто посмотреть демоверсию на обзорном сове-
щании по спринту. Более того, быстрые и частые релизы
позволяют команде Scrum охватить больше людей, сни-
жая риск неправильного выбора целевых потребителей.
Ранний выход программ имеет и другое преимущество:
в этом случае сразу обнаруживается ошибочность виде-
ния, так что появляется возможность либо пересмотреть
его, либо отказаться от продукта на ранней стадии.
Команда, разрабатывавшая браузер Chrome, сначала
планировала не использовать панель закладок. Но отзы-
вы пользователей показали, что некоторые любят пере-
ходить именно по этой панели. Поэтому команда высту-
пила с новым решением: если пользователь изначально
подбирал закладки в Internet Explorer или Firefox, Chrome
импортирует их. В ином случае у пользователей не будет
панели закладок, пока они не добавят ее. Не выпустив
первых версий браузера, команда не осознала бы важнос-
ти панели закладок, так что продукт в итоге получился
бы не оптимальным.
Частые релизы образуют строительные кирпичи-
ки для инновационных возможностей Google, отмечает
Бернар Жирар, автор книги The Google Way: «Быстро

выводя на рынок даже не до конца готовые продукты,
Google извлекает максимум из своих усилий и сводит
на нет потенциальную конкуренцию… Стратегия Google,
состоящая в быстрых и частых релизах, — это блестящая
и изобретательная маркетинговая стратегия: она устра-
няет потенциальных конкурентов, повышает стоимость
выхода на рынок и удерживает пользователей в сфере
влияния Google» (Girard, 2009; 86).
Но, как известно, бесплатный сыр бывает только в мы-
шеловке. Частые релизы имеют свою цену: программы
должны быть высокого качества и нужно иметь возмож-
ность легко получить и установить продукт. Совершенно
нормально, когда в ранних релизах лишь частично внед-
ряются некоторые функции. Приемлемо также предла-
гать функциональность, обеспечивающую клиенту или
пользователю лишь ограниченные преимущества. Одна-
ко качество программ, которое обозначено в критериях
готовности, должно быть высоким для всех инкрементов
продукта. Это позволяет команде быстро улучшать про-
дукт во время будущих спринтов и препятствует возник-
новению ошибок, которые могут навредить репутации
продукта. Такие методы, как разработка через тестиро-
вание и автоматизация тестов, рефакторинг и непрерыв-
ная интеграция, облегчают создание работающих обнов-
лений продукта. Командам понадобится время, чтобы
освоить эти техники, а их применение может потребо-

вать изменения инфраструктуры и среды.
Если получить и установить новые версии продукта
будет нелегко, то потребители откажутся от обновлений
или проигнорируют их. Хотя достичь этого непросто,
«любой большой проект можно разбить на серию более
мелких и с более ранними сроками поставки. Не сдавай-
тесь, даже если для этого потребуются новые технические
решения. Вас должны интересовать результаты, а не тех-
нологии» (Gilb, 1988; 336).
Квартальные циклы
В Scrum не существует правил, которые предписывали
бы конкретную длительность проекта. Однако agile-
проекты обычно длятся от трех до шести месяцев. Если
для вывода продукта на рынок требуется более трех-четы-
рех месяцев, используйте квартальные циклы, выпуская
ежеквартально как минимум одну версию работающей,
протестированной и задокументированной программы
(Beck and Andres, 2005; 47–48). Google пользовалась этой
методикой в течение тех двух лет, которые ушли на разра-
ботку первой версии браузера Chrome. Дэрин Фишер так
описывает процесс: «Мы ориентировались на кварталь-
ные циклы, так что живой документ [бэклог продукта]
пересматривался каждый квартал. Например, в этом

квартале мы работаем с таким набором функций, в сле-
дующем — с другим и т. д. Это было полезным средством
продвижения вперед, к тому же продукт мог применять-
ся кем угодно в Google на самых ранних стадиях, так что
мы непрерывно получали отзывы»*. Еще одна компа-
ния, систематически пользующаяся квартальными цик-
лами, — это PatientKeeper, выпускающая продукты для
сферы здравоохранения. Новая версия продукта выходит
у них каждые три месяца (Sutherland, 2005). Если учесть,
что продукты PatientKeeper имеют особые требования
по безопасности, нуждаются в одобрении регулятора
и применяются в больницах в самых разных условиях, то
это огромное достижение, дающее компании значитель-
ные конкурентные преимущества. Неудивительно, что
PatientKeeper утвердилась в качестве лидера среди произ-
водителей мобильных приложений в сфере здравоохра-
нения, опережая гораздо более мощных конкурентов.
Скорость
Скорость — индикатор того, какой объем работы может
выполнить команда в течение одного спринта. Она позво-
ляет отследить и предсказать ход проекта. Точнее говоря,
* Интервью Коллин Фрай с Дэрином Фишером на сайте

SearchSoftwareQuality.com, 1 октября 2008 года.
скорость — это сумма усилий, затраченных на достиже-

ние результата, принятого владельцем продукта в тече-
ние одного спринта. Рассмотрим пример. На совещании
по планированию спринта команда решает завершить
работу над шестью историями общей суммой в 12 очков
историй. В конце спринта владелец продукта тщательно
проверяет обновление и обнаруживает, что все требова-
ния выполнены в соответствии с приемочными критери-
ями, кроме одного: не окончена небольшая часть доку-
ментирования истории Г. Поскольку Г не закончена, очки
за нее не попадают в сумму командной скорости, как
указано в таблице 4.1. Сумма очков за принятые элемен-
ты бэклога продукта равна 10. Таким образом, скорость
команды в этом спринте равна 10.
Таблица 4.1. Определение скорости
Элемент бэклога Очки за пользователь- Результат приемки

продукта скую историю
А 1 Принято
Б 3 Принято
В 1 Принято
Г 2 Отказано
Д 2 Принято
Е 3 Принято
Как показывает этот пример, скорость лучше все-

го определять по способности команды превращать
элементы бэклога продукта в инкремент продукта. «Ра-

ботающие программы — это основная мера прогрес-
са», — сообщает по этому поводу agile-манифест (Beck
et al., 2001). Скорость может колебаться в зависимости
от многих факторов — например, динамики командной
работы, затруднений и доступности средств. Если не-
сколько членов команды уходят в отпуск, то скорость,
вероятнее всего, упадет. В случае новых команд или про-
ектов разработки новых продуктов может потребоваться
два-три спринта, прежде чем скорость стабилизируется
(Cohn, 2005; 179).
Скорость специфична для каждой команды, ее не сто-
ит сравнивать у разных команд, если только они не дого-
ворились об использовании очков за пользовательскую
историю с одинаковым значением. Когда команда, разра-
батывающая продукт А, имеет скорость 40, а создающая
продукт Б — скорость 20, это не значит, что первая коман-
да продуктивнее. Исходные данные могут быть разными,
оценки первой команды иногда просто ниже.
Диаграмма сгорания работ

для релиза
Диаграмма сгорания работ — это неотъемлемый инс-
трумент отслеживания и прогнозирования хода проекта
в Scrum. Она может выглядеть как график или как столби-

ковая диаграмма. Сначала рассмотрим график.
График сгорания работ для релиза
График сгорания работ позволяет отслеживать и прогно-

зировать ход проекта (Schwaber and Beedle, 2002; 83–88).
Он основан на скорости предыдущих спринтов и спосо-
бен предсказывать будущее, так что scrum-команда мо-
жет на основании этих прогнозов видоизменять продукт
и проект нужным ей образом*. Он базируется на двух
факторах: времени и оставшемся объеме работ из бэкло-
га продукта. График лучше всего составлять и обновлять
на обзорном совещании по спринту, когда результаты
спринта уже известны.
Составление графика — процесс несложный. Сначала
мы чертим систему координат и на оси х указываем ко-
личество спринтов. На оси у мы пишем очки за пользо-
вательскую историю (или другую, более привычную вам
единицу измерения усилий). Первая точка на графике —
это примерный объем работ на весь бэклог продукта еще
* Бек и Фаулер (Beck and Fowler, 2000) называют это свойство вче-
рашней погодой. Отметим, что приблизительный прогноз вполне
приемлем, если ход работ проверяется каждые несколько недель
в процессе обзорных совещаний на спринтах, что дает возмож-
ность обновить график и изменить прогноз.
до разработки. Для следующей точки нужно определить

оставшийся объем работ из бэклога продукта в конце
первого спринта. После этого мы проводим линию между
этими точками. Она называется сгоранием и показывает
скорость, с которой разрабатывается функционал из бэк
лога продукта. Если мы продлим линию выполнения
до оси х, то сможем предсказать, когда примерно проект
будет закончен (при условии, что скорость работы и уси-
лия останутся стабильными). Рассмотрим образец графи-
ка сгорания работ, показанный на рисунке 4.1.
На этом графике видны две линии. Сплошная ли-
ния — это действительное сгорание. Она соответствует
реальному прогрессу и оставшемуся объему работ. Вид-
но, что начало проекта получилось довольно медленным.
Это могло быть вызвано задержками, материализацией
рисков, проблемами при построении команды или тех-
нологическими сложностями. В третьем спринте коли-
чество оставшихся усилий даже увеличилось. Это может
быть связано с переоценкой командой элементов бэклога
продукта или выявлением новых требований, необходи-
мых для реализации видения. Четвертому спринту соот-
ветствует пологий спуск: проект быстро прогрессирует.
Если сейчас рассмотреть предыдущие спринты, то можно
отметить тенденцию сгорания, которой и соответствует
прерывистая линия на рисунке 4.1. Тенденция сгорания
предсказывает прогресс в ходе следующих спринтов.
Оказывается, что если работа по бэклогу продукта и тем-

пы сгорания задач останутся прежними, то проект не бу-
дет закончен за десять спринтов, то есть команда сбилась
с пути. Поняв проблемы, scrum-команда может выяснить,
в чем причины задержки — медленном прогрессе или
чрезмерном количестве работы. Когда команда приходит
к определенному выводу, она может принять верное ре-
шение. Если дата фиксирована, то можно либо снизить
количество функций, либо попросить добавить в состав
команды еще одного специалиста.
Очки за пользовательскую историю
200
150
100
50
Спринты
1 2 3 4 5 6 7 8 9 10
Рисунок 4.1. График хода сгорания работ
График хода сгорания работ можно использовать

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

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

столбиковый вариант (Cohn, 2005; 221–224). Столбиковая
диаграмма сгорания работ обладает всеми свойствами
соответствующего графика, но проводит границу между
переоценкой элементов и выполнением работы, с одной
стороны, и добавлением и исключением элементов бэк-
лога продукта — с другой. Если команда добивается про-
гресса или снижает оценки усилий, то верхушка столбика
движется вниз. А когда увеличивает оценки — верхушка
столбика движется вверх. Если в бэклог добавляются
новые элементы, то нижняя часть движется вниз. Когда

элементы удаляют из бэклога или их заменяют на требу-
ющие меньших усилий, нижняя часть движется вверх.
На рисунке 4.2 показан образец столбиковой диаграммы
сгорания работ.
Диаграмма на рисунке 4.2 — это те же самые данные,
что и в примере графика на рисунке 4.1. Разница в том,
что теперь мы лучше понимаем, что случилось во время
третьего и четвертого спринтов. Верхушка столбиков
пошла вниз, значит, команда добилась прогресса в ходе
обоих спринтов. То, что нижняя часть столбика пошла
вниз на третьем спринте, свидетельствует о появлении
в бэклоге продукта новых элементов. В ходе четвертого
спринта нижняя часть двинулась вверх, показывая, что
элементы были устранены. Самый первый столбик де-
монстрирует количество работы до первого спринта.
Очки за пользовательскую историю
200
150
100
50
0
1 2 3 4 5 6 7 8 9 10 Спринты
–50
Рисунок 4.2. Столбиковая диаграмма сгорания работ

На рисунке 4.2 видны две пунктирные линии, обозна-

чающие тенденции, — верхняя и нижняя. Верхняя пред-
ставляет тенденцию сгорания работ и наносится точно
так же, как и в случае с графиком. Нижняя отражает теку-
щую нулевую линию.
План релиза
«Планы — ничто, планирование — все», — заметил как-то
Дуайт Эйзенхауэр*. Эта идея особенно подходит для пла-
на релиза. Хотя в Scrum от команд в обязательном порядке
не требуется план релиза, планировать его все-таки необ-
ходимо. Многим командам Scrum достаточно использо-
вать диаграмму сгорания работ и группировать элементы
бэклога продукта по категориям, чтобы понимать, какие
функции и в каком релизе внедрять**. Однако большие
scrum-проекты и те, которые требуют координации с дру-
гими проектами, партнерами или поставщиками, все же
должны разрабатывать формальный план релиза.
План релиза — это своего рода карта, обозначающая
нам направление. Он показывает, насколько мы прибли-
зились к выпуску продукта и когда он состоится. Мож-
но сказать, что план релиза — это расширенная версия
* Дуайт Эйзенхауэр (1890–1969) — 34‑й президент США. Прим. ред.

** Эти категории также называют журналами релиза (Schwaber and
Beedle, 2002; 71–72).
диаграммы сгорания работ. Он не только содержит боль-

ше информации, но и более комплексный. План релиза
основывается на четырех факторах: элементах бэклога
продукта, оставшегося объема работ, скорости команды
и времени. План релиза не является фиксированным. Он
меняется вместе с развитием бэклога продукта, а также
нашего понимания оставшегося объема работ и скоро-
сти. Как и диаграмму сгорания работ, план релиза луч-
ше всего составлять и обновлять совместными усилиями
команды во время демонстрации результатов спринта.
Чтобы выжать из плана максимум, полезно представ-
лять функциональность, которая внедряется в ходе каж-
дого релиза, в виде тем или эпиков. Включение в план
релиза пользовательских историй обычно ведет к излиш-
ней детализации и усложнению (исключение из этого
правила — крупные проекты, их обсудим в этой же гла-
ве ниже). Полезно также включить в план релиза любую
информацию, необходимую для координации усилий
с другими проектами, партнерами, поставщиками, а так-
же зафиксировать все известные изменения, влияющие
на скорость, — например, изменения в составе команды
или организации проекта. Таблица 4.2 иллюстрирует об-
разец плана релиза.
В примере, представленном в таблице 4.2, проект на-
ходится на стадии четвертого спринта, а выход версии 1.0
должен состояться еще через четыре спринта.
Таблица 4.2. Образец плана релиза
Спринт 1 2 3 4 5 6 7 8
Про- Нет 12–32 18–28 21–28 11–18 16–23 21–28 21–
гноз 28
скоро-
сти
Акту- 20 25 28
альная
ско-
рость
Взаи- Биб-
моза- лио-
виси- тека
мости изоб-
раже-
ний
Релизы Альфа: Праз- Бета: Вер-
звонки, дники конфе- сия
базовые ренц- 1.0
текс- звонки,
товые сооб-
сооб- щения
щения с кар-
тинками
Текущий
спринт
Продолжительность каждого спринта — две недели.

Альфа-версия, включающая в себя две темы, поставля-
ется выбранным заказчикам после четвертого спринта.
Бета-версия с еще двумя темами выходит после шестого
спринта. Хотя эти релизы имеют приставки альфа и бета,
это обновления продукта, удовлетворяющие критериям
готовности. Версия 1.0 выходит на рынок после восьми

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

предпринимаем следующие шаги: если разрабатывается
новый продукт, команда никогда не работала вместе или
ее состав существенно изменился, нам нужно понаблю-
дать скорость работы команды по крайней мере по ито-
гам первого спринта, а лучше — после двух или трех. Как
уже упоминалось, чтобы скорость стабилизировалась,
может потребоваться несколько спринтов. После этого
мы можем использовать полученные данные по скорости
работы команды для прогнозирования в будущих сприн-
тах. В плане релиза из таблицы 4.2 для четвертого сприн-
та ожидается скорость работы команды от 20 до 28 очков
со средним значением 24 очка.
Кроме того, чтобы спрогнозировать будущую ско-
рость работы команды, можно использовать и таблицу 4.3
(Cohn, 2005; 180). Так и поступила scrum-команда в плане
релиза из таблицы 4.2.
Таблица 4.3. Множители скорости на основе завершенных

спринтов*
Завершенные Наименьший Наибольший множитель

спринты множитель
1 0,6 1,60
2 0,8 1,25
3 0,85 1,15
4 или более 0,9 1,10
Используя среднюю скорость трех первых спринтов

из таблицы 4.2, мы умножаем 24 на соответствующие на-
именьший и наибольший множитель из таблицы 4.3. По-
лучается диапазон значений скорости работы команды
от 21 до 28 очков.
После того как команда проделала пять и более
спринтов, можно составить точный прогноз (Cohn, 2009;
297–300). Допустим, мы завершили восьмой спринт
из таблицы 4.2 и хотим предсказать скорость команды
в следующем релизе. Скорости завершенных спринтов
имеют следующие значения: 20, 25, 28, 26, 16, 20, 26, 26.
Теперь исключаем из рассмотрения данные по тем сприн-
там, в которых произошли аномалии — например, по-
ловина команды заболела или сервер на несколько дней
стал недоступен. Затем сортируем список оставшихся
* Из книги Майка Кона Agile Estimating and Planning. Печатается

с разрешения.
значенийв порядке возрастания. Получается следующее:

16, 20, 20, 25, 26, 26, 26, 28. Теперь, пользуясь таблицей 4.4,
мы с 90%-ной уверенностью можем определить будущую
скорость работы команды.
Таблица 4.4. Использование n-ного наименьшего и n-ного

наибольшего наблюдения в отсортированном списке значений
скорости для нахождения 90%-ного интервала достоверности*
Количество наблюдений скорости n-ное наблюдение скорости

5 1
8 2
11 3
13 4
16 5
18 6
21 7
23 8
26 9
Поскольку мы прошли восемь спринтов, берем вто-

рое наблюдение скорости с начала и с конца последо-
вательности. Это дает диапазон значений скорости
от 20 до 26 со средней скоростью 23. Можно быть на 90%
уверенными, что реальное значение скорости работы
команды будет внутри этого диапазона.
* Из книги Майка Кона Succeeding with Agile: Software Development

Using Scrum. Печатается с разрешения.
Составление плана релиза
Предсказав скорость, делим оставшийся объем ра-

бот из бэклога продукта на среднюю скорость работы
команд ы или на диапазон скоростей, что дает пример-
ное количество спринтов, необходимых для реализа-
ции продукта. Теперь фиксируем выявленное число
спринтов в календаре и изучаем факты, которые могут
пов лиять на скорость, но при этом не учтены в прогно-
зе. Это могут быть выходные, отпуск, дни для обучения
и развития персонала, а также статистика заболева
емости и запланированные изменения в организации
проекта — например, изменение состава команды. В со-
ответствии с этими данными корректируем прогноз
скорости разработки для каждого будущего спринта
в плане релиза.
Вернемся к плану релиза из таблицы 4.2. Из него сле-
дует, что реальная скорость работы команды по итогам
первых трех спринтов составила 20, 25 и 28. Средняя
скорость спринта, таким образом, равняется 24 очкам.
Scrum-команда спрогнозировала скорость в диапазоне
от 21 до 28 очков для четвертого, седьмого и восьмого
спринтов, воспользовавшись множителями из табли-
цы 4.3.
План релиза также прогнозирует падение скорости
для пятого и шестого спринтов, поскольку в это время
несколько членов команды берут отпуск, после чего воз-

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

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

хода всего проекта, нужно приложить дополнительные
усилия. Прежде всего следует заглянуть на два-три сприн-
та вперед. Это даст возможность понять, над какими эле-
ментами бэклога продукта, вероятнее всего, будет про-
водиться работа (Cohn, 2005; 206. Pichler, 2008; 146). Это
требует более ранней декомпозиции и оценки элементов
бэклога продукта. Теперь в его верхней части будет боль-

ше детализированных элементов.
Следующий шаг — выявление взаимозависимости
между командами. Следует спросить себя, должны ли
команды совместно работать над какой-то функцией или
компонентом? Будет ли какая-либо команда выступать
поставщиком для другой команды? Если да, то возможно
ли за один спринт реализовать какую-то функцию или
компонент и сразу же его использовать? Чтобы ликви-
дировать проблемные зависимости, можно прибегнуть
к пересмотру приоритетов в бэклоге продукта. Напри-
мер, вместо того чтобы поручить двум командам во вре-
мя следующего спринта работать над одной и той же
подсистемой, можно отложить внедрение некоторых тре-
бований на следующий спринт и выдвинуть на передний
план другие элементы, поменяв приоритеты в бэклоге
продукта.
После того как все проблемы взаимозависимости ре-
шены, оцениваем объем работы для каждой команды.
Не будет ли команда перегружена во время следующего
спринта? А может быть, ее, напротив, используют недоста-
точно? В любом случае есть возможность вернуться и из-
менить расстановку приоритетов в бэклоге продукта.
Можно пройти указанные этапы несколько раз, пре-
жде чем будет достигнут оптимальный баланс меж-
ду пот ребностями индивидуальных команд и общими
нуждами проекта. Когда это сделано, добавляем в план

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

ит обращаться, только если все остальные возможности
исчерпаны. Конвейерная работа разделяет то, что должно
быть единым целым. Она распределяет работу над одним
элементом бэклога продукта по нескольким спринтам
(Larman, 2004; 251–253). Вот как это работает: допус-
тим, у нас есть две команды — А и Б. Команда А должна
поставить компонент для команды Б, а команда Б будет
с ним работать. В процессе перспективного планирова-
ния мы обнаруживаем, что обе части процесса нельзя вы-
полнить в ходе одного спринта. Сложно также сократить
объем работы посредством последующей декомпозиции
требований. Последний шанс — перейти на конвейерный

метод. Мы просим команду А внедрить нужный компо-
нент в ходе ближайшего спринта, а команду Б — исполь-
зовать его в ходе следующего.
Звучит замечательно, но сразу возникает пробле-
ма: что будет сделано, когда команда А завершит ра-
боту? И как убедиться в том, что компонент будет ра-
ботать нужным образом, когда команда Б начнет его
использовать? Поскольку за частично сделанную рабо-
ту не начисляется очков, то деятельность команды А
не будет отражена в диаграмме сгорания работ, что
затруднит отслеживание прогресса. Более того, может
потребоваться резерв времени, чтобы убедиться в том,
что команда А действительно сможет поставить нуж-
ный компонент (Cohn, 2005; 208). Буфер нужен в том
случае, если команда A столкнется с необходимостью
приложить больше усилий к работе над проектом, чем
ожидалось. Потребности в конвейерной работе можно
снизить, если задействовать функциональные, а не ком-
понентные команды.
При планировании релиза в scrum-проекте избегайте
следующих ошибок: отсутствие диаграммы сгорания
работ или плана релиза; пассивный владелец продукта,

не принимающий участия в процессе планирования ре-
лиза; взрывные релизы; предлагающие слишком много
функциональности сразу; работа в ущерб качеству.
Отсутствие диаграммы сгорания работ

или плана релиза
Мне встречались организации, которые, привыкнув

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

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

дукта, он должен руководить им с самого начала.
Взрывной релиз
Если выбрать главный совет этой главы, то вот он: де-

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

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

ментации… Проблема, однако, в том, что, жертвуя каче
ством, команды остаются с продуктом, который будет все
сложнее и дороже поддерживать и расширять. Да, кратко
срочная выгода очевидна. Но через несколько месяцев
начнутся проблемы. Кроме того, жертвуя качеством,
сотрудники вряд ли будут гордиться своей работой, так
как подрывают мастерство команды и применение пра-
вильных инженерных методов. У команд должны быть
критерии готовности — это требования, которым должен
удовлетворять продукт. Эти критерии владелец продукта
должен использовать при каждой демонстрации резуль-
тата спринта. Не следует принимать частично выполнен-
ную или выполненную с ошибками работу. Упрощайте
планирование релиза, назначая временны́е рамки для
проектов, и установите равномерную частоту выпуска
обновлений.

Зачем ждать официального запуска продукта, чтобы
узнать реакцию рынка? Выпускайте релизы быстро
и часто, но ПО должно быть качественным. Учитесь
на первичных отзывах заказчиков и пользователей,
включайте их замечания в следующие улучшения про-
граммы.
Выпустите обновления, а затем снова улучшайте

проект.
— Каковы будут последствия, если зафиксировать

время, качество или гибкость функциональности?
— Каковы выгоды от частых и быстрых релизов? И как
на них перейти? Что нужно сделать, чтобы органи-
зовать выпуск проекта квартальными циклами? Ка-
кова скорость работы вашей команды?
—Ч
то вы используете: диаграмму сгорания работ или
план? Кто составляет и обновляет их?
5
Совместная работа
на совещаниях
по спринту
Существует миф, что художники только и ждут, когда

их поразит гениальная идея, и затем без особых усилий
претворяют ее в шедевр. Все это сказки. На самом деле
инновация требует преданности делу, кропотливого
труда и дисциплины. Возьмем, например, американско-
го художника и фотографа Чака Клоуза. Его фирменная
техника — писать картины по фотографиям. При этом он
делит холст на мельчайшие квадраты и заполняет их за-
витушками — своеобразными аналогами пикселей. Если
смотреть вблизи, то видны эти отдельные формы, но при
отдалении картина складывается в портрет. Вот как Кло-
уз описывает процесс работы над картиной (Oberkirch,
2008):
5. Совместная работа на совещаниях по спринту 183
Мои картины создаются поэтапно, по одному квадра-

тику за раз, что напоминает работу писателя… Сре-
ди преимуществ поэтапной работы могу назвать то,
что у меня нет необходимости ежедневно изобретать
колесо. Сколько я сегодня сделал, столько и сделал,
нравится вам это или нет. Мне не нужно ждать вдох-
новения. Для меня не существует удачных и неудач-
ных дней. Каждый день — это продолжение той рабо-
ты, которую я делал накануне.
К счастью, Scrum дает возможность работать поэтапно,

шаг за шагом претворяя в жизнь продукт, так что результат
каждого нового спринта базируется на результатах пред-
шествующих спринтов. Состав спринта вырабатывается
и корректируется на нескольких обязательных встречах
команды. Встреча для планирования спринта происходит
вначале, демонстрация результатов спринта и ретроспек-
тивное совещание замыкают цикл. Совместные встречи —
ценная возможность для взаимодействия и общения, об-
мена информацией и сотрудничества. Джерри Лэйборн,
владелец продукта Ript — программы визуального плани-
рования, — согласен с этим (Judy, 2007):
За тот год, когда мы создавали [Ript], я пропустил толь-

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

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

которые действительно может выполнить. Ограничение
объема работы на спринт определяется скоростью рабо-
ты команды и ее размерами, что в итоге создает опти-
мальный темп разработки: «Заказчики, разработчики
и пользователи должны уметь до бесконечности выдер-
живать постоянный темп разработки» (Beck et al., 2001).
Бесполезно пытаться добиваться слишком амбициозной
цели в течение одного спринта, только чтобы полно-
стью истощить свои силы к следующему. Scrum отдает
предпочтение равномерному, устойчивому потоку задач
из бэклога продукта в спринты. Надежность важнее лож-
ных амбиций, это необходимое условие для составления
реалистичных прогнозов. А излишнее давление убивает
творчество.
Помните, что решение команды — это не гарантия.
Новая команда может лишь через два-три спринта по-
нять, как принимать решения, которые она сможет воп-
лотить. Кроме того, в разработке ПО слишком много
неизвестных слагаемых: неопределенность и риск идут
рука об руку с инновациями. Закон Мерфи гласит: «Все,
что может пойти не так, обязательно пойдет не так».
Риски могут проявиться в любой момент, а проблемы
не всегда будут быстро решаться. Случается, что цель
спринта не достигнута, — но это должно быть исклю-
чением, а не правилом. Если это все-таки произошло,
используйте ретроспективный анализ спринта, чтобы

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

тестирование единиц ПО. После выработки критериев
они должны быть записаны и доступны в течение всего
проекта.
Ежедневный scrum-митинг
Такой вид scrum-собрания позволяет команде управ-
лять своей работой изо дня в день и выявлять препят
ствия и проблемы. Владелец продукта должен постоян-
но посещать их. Это отличная возможность понять, как
идет работа, и выяснить, не нужна ли команде помощь
(например, нужно быть готовым отвечать на вопросы,
анализировать результаты работы или помогать устра-
нять препятствия). Можно также сообщить информацию
и рассказать команде, над чем вы работаете сейчас и что
планируете делать дальше. Часто работа владельца про-
дукта предоставляет важную информацию о действиях
на уровне релиза и на периферии проекта.
Во время ежедневных scrum-митингов желательно
не вмешиваться в самоорганизацию команды, форму-
лировать и назначать задания, комментировать про-
гресс отдельных сотрудников. Если вас беспокоит ход
работы, делитесь своим мнением конструктивно —
например, задавая вопросы*. Чтобы прояснить ситу-

ацию с достижением цели спринта, можно сказать:
«Я заметил: диаграмма сгорания задач для спринта по-
казывает, что осталось еще много работы до заверше-
ния спринта. Вас это беспокоит?» Задавая вопросы, вы
привлекаете внимание команды, но оставляете выбор
действий за ней.
Препятствия
Нерешенные проблемы размножаются как грибы
после дождя. Вот почему Scrum уделяет особое
внимание борьбе с препятствиями — выявлению
и устранению проблем, которые мешают работе
и причиняют вред проекту. Члены команды расска-
зывают о препятствиях и проблемах на ежедневном
scrum-митинге, и scrum-мастер отвечает за то, что-
бы они были устранены как можно быстрее. Даже
если работа над проблемами кажется замедлением
хода проекта, она препятствует возникновению бо-
лее серьезных трудностей и долгих отсрочек. «Про-
блемы — это сокровища, — пишет эксперт по бе-
режливому управлению Паскаль Деннис. — Они
дают возможность учиться и совершенствоваться»
(Dennis, 2006; 19).
* Этот метод — задавать вопросы для сообщения информации — из-

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

спринта — как активных участников.
Обзор итогов спринта
Обзор итогов спринта способствует созданию успешного

продукта. Он дает scrum-команде возможность взаимо-
действовать с заинтересованными лицами, рассмотреть
ход разработки продукта на данное время и принять ре-
шение относительно дальнейших действий. Это лучше,
чем просто верить, что все идет по плану. Среди заинте-
ресованных лиц могут быть представители маркетин-
га, продаж и сервиса, а также клиенты и пользователи.
Например, один клиент Primavera Systems — поставщи-
ка программных решений для управления проектами,
программами и портфелями — посещал обзоры итогов
спринта компании, считал их чрезвычайно полезными,
ценил прозрачность и возможность повлиять на разра-
ботку продукта. Отметим, что подготовка к обзору должна
быть сведена к минимуму. Обзор — это рабочая процеду-
ра, а не шоу. Командам стоит воздержаться от формаль-
ных презентаций и не использовать слайды. Цель обзо-
ра — не произвести впечатление или вызвать ажиотаж,
а обеспечить прозрачность, проанализировать продукт
и выработать меры по его улучшению.
Задача владельца продукта — открыть совещание,

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

двигаться вперед*.
После определения степени прогресса заинтересо-
ванные лица должны выступить с отзывами на обнов-
ление продукта. Нравится ли им то, что они видят? Ка-
кие изменения нужно внести, чтобы продукт стал более
успешным? Продолжает ли действовать концепция? Что
с функциональностью: не слишком ли ее мало или мно-
го? Не внедрена ли какая-то функция некорректно? Мо-
жет быть, стоит изменить внешний вид продукта и то, как
он воспринимается? Если это нужно, то почему? На этом
этапе нередко обнаруживаются новые требования или
выясняется неактуальность старых. Заметим, что отзы-
вы заинтересованных лиц позволяют владельцу продукта
и команде увидеть обновление их глазами, что устраняет
опасность шаблонного мышления. Чтобы получить полез-
ные отзывы, поработайте с ожиданиями заинтересован-
ных лиц. Объясните, что обновление продукта на раннем
этапе может напоминать конечный продукт лишь отчас-
ти, а новые идеи и требования должны поддерживать кон-
цепцию. Поэтому заинтересованным лицам, возможно,
придется подождать еще в течение одного-двух спринтов,
* Уважение в Scrum настолько важно, что входит в число пяти ба-

зовых ценностей (Schwaber and Beedle, 2002; 147–154). Остальные
четыре — это преданность делу, сфокусированность, открытость
и смелость.
прежде чем можно будет внедрить новые идеи, в зависи-

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

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

ствования — например, покупка и установка ново-
го сборочного сервера, — они фиксируются в бэклоге
продукта.
Совещания по спринтам
в крупных проектах
Хотя крупные проекты следуют тому же расписанию со-
вещаний, что и другие проекты Scrum, сами совещания
видоизменяются. В этом разделе мы расскажем, как это
происходит.
Совместное планирование спринта
Чтобы провести совещание по планированию спринта

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

должны быть реализованы в ходе спринта.
Scrum-совещание по Scrum
Scrum-совещание по Scrum позволяет нескольким коман

дам ежедневно координировать свои действия в ходе
спринта. Представители команд после этого приходят
на ежедневные scrum-митинги своих команд, чтобы об-
судить положение дел, запланированную работу и взаи-
модействие между командами (Schwaber, 2007; 72). Это
совещание — тактическое и не может служить компенса-
цией за недостаточную подготовку к спринту — напри-
мер, отсутствие стратегического планирования.
Демонстрация результатов спринта
Организация эффективной встречи для одной-двух

команди клиентов, руководства и других заинтересован-
ных лиц для демонстрации результатов спринта — не-
простая задача. Если же команд пять, десять или больше,
то обеспечить общее понимание прогресса и выработать
пути продвижения вперед еще сложнее. В компании
Primavera нашли отличный способ организовать свои де-
монстрации, в которых нередко принимало участие сразу
15 команд. Боб Шатц, бывший вице-президент Primavera

по разработке, поясняет: «Наши демо больше всего на-
поминали выставки в школе. Каждая команда собирала
стенд, на котором демонстрировала то, над чем работает.
Конечные пользователи, заинтересованные лица и еще не-
сколько человек из нашей компании объединялись в не-
большие группы. Каждая такая группа начинала со свое-
го стенда. На анализ отводилось пятнадцать минут, после
чего обозреватели переходили к следующим стендам. Все
это проходило в атмосфере, полной энергии, вдохновения
и радости» (Schatz, 2009)*. Совместная встреча заинте-
ресованных лиц в одном помещении — отличный способ
дать им всем возможность для взаимодействия и обмена
мнениями. Если в офисе компании это невозможно, за-
казывайте конференц-зал хотя бы для каждой второй де-
монстрации результатов спринта.
Совместная ретроспектива спринта
Изменения и улучшения, которые каждая scrum-команда

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

вателям результаты работы команды.
общие пути совершенствования и поделиться друг с дру-

гом найденными идеями. Это позволяет делать совмест
ная ретроспектива спринта. Эффективный метод ее про-
ведения — привлечение представителей команд, что
способствует перекрестному обмену идеями. Но при этом
творческий импульс и знания всех участников команд
не используются. Альтернатива — совместная ретроспек
тива всеми участниками команд. Это затратное дело:
можетзанять полдня или больше, но так полнее использу-
ется накопленный опыт команд, а все их члены могут вза-
имодействовать друг с другом, укрепляя межкомандные
взаимоотношения. Отличный способ организации ретро
спективного анализа спринта — Open Space Technology
(Owen, 1997), когда участники проекта самоорганизуют-
ся вокруг проблемных областей и определяют пути улуч-
шения. Отметим, что оба варианта хорошо сочетаются.
Например, организация может регулярно проводить рет-
роспективы с представителями команд и после каждого
третьего спринта назначать общую ретроспективу, на ко-
торой будут присутствовать все члены команд.
Владелец продукта должен поддерживать тесное сотруд-
ничество с командой и scrum-мастером, избегая распро-
страненных ошибок, к которым относятся «скачущий»
владелец продукта, или «чайка», незаинтересованный

владелец продукта, нежизнеспособный темп, стремление
пустить пыль в глаза, включение в отчет диаграммы сго-
рания задач спринта.
Владелец продукта — «чайка»
Такой владелец продукта появляется на планировании

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

дукта, scrum-мастер, команда, пользователи и несколько
менеджеров среднего звена смотрели на монитор ком-

пьютера. Тестировщик, сидящий перед ним, изо всех сил
старался объяснить функциональность, которую пред-
ставлял. Владельцу продукта было не по себе, и он очень
медленно отворачивался от монитора. Периодически он
согласно кивал. Через десять минут демонстрация закон-
чилась. Scrum-мастер посмотрел на владельца продукта
и спросил: «Вам нравится то, что вы увидели?» Владелец
продукта еще раз кивнул и сказал: «Хорошая работа».
После этого он встал и вышел из комнаты. Другие члены
scrum-команды молча смотрели друг на друга. «Пора на-
чинать ретроспективу», — сказал scrum-мастер.
Если бы я придумал этот рассказик или хотя бы на-
блюдал все это лишь однажды! К сожалению, очень часто
на демонстрации результатов спринта владельцы про-
дукта ведут себя как посторонние. Но демо — это не шоу,
которое вы смотрите из зала. Его цель — выяснить, что
должно быть сделано для увеличения шансов на создание
успешного продукта. И владелец продукта должен актив-
но вносить свой вклад в совещание, чтобы гарантировать
правильное развитие продукта.
Нежизнеспособный темп
«Перерыва между спринтами не будет. Новый спринт на-

чнется на следующий рабочий день», — говорю я. Одна
из присутствующих поднимает руку и спрашивает:

«Но как команда сможет восстановиться?» «Она и не долж-
на», — отвечаю я. Я смотрю на поникших коллег, кто-то
качает головой. Я продолжаю: «Нужно убедиться, что
команда способна выполнить нужный объем работы —
ровно столько элементов бэклога продукта, сколько она
способна действительно воплотить в продуктовом инкре-
менте, не перерабатывая и не чувствуя истощения».
Разработка продукта похожа на марафон. Если вы хо-
тите финишировать, нужно подобрать оптимальный темп.
Многие владельцы продукта совершают ошибку, оказывая
на команду давление, чтобы она работала активнее. Так
достигается краткосрочный выигрыш в скорости, но сам
темп нежизнеспособен. Более того, он вообще контрпро-
дуктивен. Спринты превращаются чуть ли не в гонку
на выживание — люди быстро перегорают, заболевают
или уходят. Владелец продукта должен уважать силы сво-
ей команды независимо от того, как выглядит диаграмма
сгорания задач. Если дело движется медленно, соберите
совещание, чтобы найти подходящее решение. Но не тре-
буйте от сотрудников, чтобы они работали больше.
Стремление создать иллюзию
Одно из моих любимых воспоминаний детства — это

визит на местную ярмарку с бегами и аттракционами.
Один из них особенно впечатлял: это был магический

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

задач спринта
Некоторые компании используют диаграмму сгорания

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

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

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

та поддерживать команду без ущерба для ее само
организации?
— Какой вклад вы можете внести в ежедневные scrum-

митинги?
—К
ак вы будете сотрудничать с командой, предостав-
ляя первые отзывы по результатам работы?
—К
ак сделать демонстрации результатов спринта
еще эффективнее и интереснее?
—П
осещаете ли вы ретроспективы спринта? Если
нет, то как начать это делать? В чем преимущества
этого?
6
Превращение
во владельца
продукта
Когда я познакомился с Полом, в первый раз выполняв-

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

неджерам, руководящим переходом к Scrum. Более по
дробнее о методах перехода к Scrum читайте в (Schwaber,
2007) и (Cohn, 2009).
Как стать отличным

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

продукта, — это понять, каков вы на самом деле и как со-
бираетесь развиваться в профессиональном плане. Срав-
ните свои умения и навыки с обязанностями владельца
продукта, определите те аспекты этой роли, которые ка-
жутся вам сложными и могут вызвать проблемы.
Как уже упоминалось в главе 1, роль владельца про-
дукта многогранна. Практически невозможно найти
начинающих владельцев продукта, которые обладают
всеми необходимыми навыками. Поэтому вполне веро-
ятно, что вы найдете пробелы в собственных знаниях
6. Превращение во владельца продукта 207
и навыках. Джон, например, обладает большим опытом

взаимодействия с клиентами и создания стратегических
планов развития продукта, но не очень успешно пишет
пользовательские истории и план релиза. Джейн, на-
оборот, отлично составляет пользовательские истории
и знакома с планированием релиза, однако ей не хватает
умения выстроить концепцию развития продукта. Обоим
нужно активно проявить свои сильные стороны и улуч-
шить навыки. Лисса Адкинс, автор книги Coaching Agile
Teams, дает начинающим владельцам продукта следу
ющие советы (таблица 6.1):*
Таблица 6.1. Что нужно и чего не нужно делать владельцу

продукта
Что делать Чего не делать

Говорить, что нужно сделать Говорить, как это сделать и сколько
времени это займет
Бросать вызов команде Заставлять команду работать угро-
зами
Заниматься созданием высоко Концентрироваться только
производительной команды на краткосрочной выгоде
Мыслить категориями возмож- Придерживаться исходных мнений
ностей для бизнеса и подхода «во что бы то ни стало»
Защищать команду от внешне- Заранее беспокоить команду, рас-
го шума сказывая о возможных изменениях,
пока они еще не стали реальностью
Внедрять изменения между Позволять изменениям «проникать»
спринтами в спринты
* Личное сообщение Лиссы Адкинс, 29 июня 2009 года.

Развитие и рост
Понимание вашего основного потенциала для развития

поможет принять самые эффективные меры. Будущим
владельцам продукта полезно посещать курсы Scrum
для владельцев продукта, чтобы быстро получить необ-
ходимые знания. Но дело не только в теории. Будущему
владельцу продукта нужно осознать основные принципы
гибкого управления и начать жить в соответствии с цен-
ностями Scrum.
Будьте преданны продукту и команде, сосредоточи-
вайтесь на задачах владельца продукта, проявляйте от-
крытость и поощряйте прозрачность, уважайте людей,
с которым работаете, и имейте мужество вести себя пра-
вильно (Schwaber and Beedle, 2002, 147–154). Будьте ко-
мандным игроком и доверяйте своим коллегам по scrum-
команде.
Дайте себе время раскрыться в новой роли. Не надей-
тесь, что сразу же будете выдавать идеальный результат.
Ошибки — это часть процесса обучения. Будьте терпе-
ливы, но не допускайте самоуспокоенности. Начав рабо-
тать владельцем продукта, вы яснее увидите свои слабые
и сильные стороны.
Во время ретроспективы узнайте у scrum-мастера
и команды мнение о вашей работе и внесите соответству-
ющие изменения.
Найдите наставника
Помимо посещения тренингов и чтения книг начина

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

решила пригласить в качестве помощника одного из сво-
их подчиненных, Тома. Это дало ему время освоиться.
После успешного первого релиза Саре удалось постепен-
но передать роль владельца продукта Тому.
Убедитесь в поддержке
на нужном уровне
Чтобы эффективно выполнять функции владельца про-

дукта, нужно быть уверенным в постоянной поддержке
и доверии руководства. В зависимости от организации
и ситуации нужным уровнем может оказаться вице-
президент по управлению продуктом, глава бизнес-
отдела, вся команда руководителей или CEO. Чтобы до-
биться необходимого внимания от руководства, нужно
объяснить им важность вашей роли и границы ваших
полномочий и ответственности. Без поддержки на нуж-
ном уровне вам, вероятнее всего, не будет хватать пол-
номочий, что повлечет за собой серьезные проблемы
в работе.
Вы еще не готовы
Проработав несколько месяцев в новой роли и устранив

первые барьеры, вы будете чувствовать себя комфортнее.
Дойти до этого этапа — уже большое достижение. Но не-

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

продукта
Хотя каждый конкретный владелец продукта должен сам

отвечать за свою работу, менеджеры, руководящие пе-
реходом к Scrum, все же могут предпринять некоторые
меры по созданию среды, в которой владельцам продукта
будет максимально комфортно. В этом разделе описыва-
ется, что руководитель или менеджер должны для этого
сделать.
* Кон (Cohn, 2009; 70–79) подробно рассказывает о сообществах

по совершенствованию как о варианте освоения Scrum.
Осознайте важность роли
Высшее руководство должно осознать полномочия и от-

ветственность, сопряженные с ролью владельца продук-
та, и как эта роль влияет на организацию. Это не только
жизненно важно для успешного функционирования гиб-
кого управления продуктом, но и является ключевым
фактором успеха в переходе на Scrum в целом. Согласен
с этим и Кен Швабер (Schwaber, 2007; 85).
До недавнего времени я рассматривал эти отноше-

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

продукта
Владельцев продукта надо выбирать тщательно. Вы как

руководитель должны принимать во внимание не толь-
ко желаемые характеристики кандидата на должность
(описанные в главе 1), но и другие факторы, в том числе
продукт, его размер и отрасль. Идеальный владелец для

одного продукта может плохо подходить для другого.
К тому же у каждой компании должен быть собственный
подход к выбору кандидатов. Например, в Salesforce.com
менеджеры продуктов работают и владельцами продук-
та, при этом они относятся к одному и тому же подраз-
делению. В mobile.de функции владельца продукта ис-
полняются членами бизнес-подразделений. И каждое
подразделение следит за своим набором продуктов или
функций продукта*. Как и в целом в Scrum, все зависит
от результата. Когда организация воплотит несколько
scrum-проектов, обычно начинает вырабатываться общее
представление о том, кто должен выполнять роль вла-
дельца продукта.
Наделяйте владельцев продукта

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

в новой роли, нужны время, доверие и поддержка. Есть
вероятность того, что новый владелец продукта будет де-
лать ошибки, начиная игнорированием заинтересован-
ных лиц и заканчивая прерыванием спринта. Нередко
* Личные сообщения Бретта Квинера, старшего вице-президента

по продуктам в Salesforce.com (9 июня 2009 года), и Филипа Мис-
слера, технического директора mobile.de (18 июня 2009 года).
ошибки — это неотъемлемая часть процесса обучения.

Вы как представитель высшего руководства можете по-
мочь ему, приняв меры по его обучению и наставничес-
тву. «Раннее погружение владельцев продукта в agile-
принципы и их обучение, создание бэклога продукта
и пользовательских историй, оценка и планирование —
вот ключи к успеху любой agile-команды. Кроме того, по-
мимо начальной фазы обучения, для укоренения нового
процесса в культуре компании необходимо постоянное
наставничество владельца продукта в течение всего пе-
риода его работы», — делятся Фрай и Грин, описывая
свой опыт работы в Salesforce.com. Также они советуют
компаниям «обращаться за профессиональной помо-
щью. Внешние наставники уже обладают необходимым
опытом и способны раньше вас распознать препятствия.
Они помогут учиться на примере других организаций,
где подобный переход уже завершился» (Fry and Greene,
2007; 139).
Помимо обучения вы можете помочь владельцам
продукта, наделив их полномочиями и дав достаточно
времени на качественное выполнение работы. Владе-
лец продукта, у которого недостаточно полномочий для
принятия решения о том, будет ли функция внедрена
в ближайшем релизе, быстро утрачивает доверие членов
scrum-командыи заинтересованных лиц. Следует понять,
что деятельность в качестве владельца продукта обычно
отнимает все рабочее время. Если человек, занимаю-

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

продукта в компании
Поддержка института владельцев продукта в компании

требует совершенствования в организации необходимых
возможностей для роста и развития исполняющих эту
роль. Речь идет не только о привнесении первоначальных
знаний в организацию. Требуется создать полноценную
программу развития и сообщество владельцев продукта.
Отличный способ для создания программы развития —
использовать коллективный разум владельцев продукта,
активно вовлекая их в ее разработку. Например, можно
проводить регулярные мастер-классы для владельцев
продукта, чтобы выявить наилучшие методики и пути со-
вершенствования.
Иногда, чтобы окончательно укоренить роль владель-
ца продукта в корпоративной культуре, необходимы орга-
низационные изменения. Вот пример CSG Systems — ком-
пании по управлению взаимодействием с покупателями,
предлагающей программные решения. Маурисио Замора,
исполнительный директор CSG, так объясняет подход

компании (Leffingwell, 2009):
Сначала мы объяснили каждому различия между ро-

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

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

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

ца продукта.
— Какие аспекты этой роли кажутся вам трудными?

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

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

на компанию?
— Что имеет наибольшее значение для успешных вла-
дельцев продукта?
—К
ак вы можете помочь владельцам продукта в их
работе?
—К
ак может организация эффективно поддерживать
существование роли владельца продукта?
Библиография
37Signals. 2006. Getting Real: The Smarter, Faster, Easier Way

to Build a Successful Web Application. https://gettingreal.
37signals.com/.
Anthony, Scott, Johnson, Mark, Sinfield, Joseph and Altman,
Elizabeth. 2008. The Innovator’s Guide to Growth: Putting
Disruptive Innovations to Work. Harvard Business School
Press. Издание на русском языке: Руководство иннова-
тора: Как выйти на новых потребителей за счет упроще-
ния и удешевления продукта / М. Джонсон, С. Олтман,
Дж. Синфилд, С. Энтони. М.: Альпина Паблишер, 2011.
Beck, Kent. 2000. Extreme Programming Explained: Embrace
Change. Addison-Wesley.
Beck, Kent, and Cynthia Andres. 2005. Extreme Programming
Explained: Embrace Change, 2nd edition. Addison-Wesley.
Beck, Kent, and Martin Fowler. 2000. Planning Extreme
Programming. Addison-Wesley.
Библиография 219
Beck, Kent, et al. 2001. The Manifesto for Agile Software Deve
lopment, http://agilemanifesto.org/, http://agilemani-festo.org/
principles.html.
Brooks, Frederick P. 1995. The Mythical Man-Month: Essays
on Software Engineering, 2nd edition. Addison-Wesley. Из-
дание на русском языке: Брукс Ф. Мифический человеко-
месяц, или Как создаются программные системы. СПб.:
Символ-Плюс, 2010.
Bryson, John M. 2004. “What to Do When Stakeholders
Matter: Stakeholder Identification and Analysis Techniques.”
Public Management Review 6, no. 1, 21–53.
Carroll, Lewis. 1998. Alice’s Adventures in Wonderland and
Through the Looking-Glass. Penguin Classics. Издание на
русском языке: Кэрролл Л. Алиса в Стране чудес и Зазер-
калье. М.: Эксмо, 2016.
Catmull, Ed. 2008. “How Pixar Fosters Collective Creativity.”
Harvard Business Review, September, 64–72.
Christensen, Clayton M. 1997. The Innovator’s Dilemma: When
Technologies Cause Great Firms to Fail. Harvard Business
School Press. Издание на русском языке: Кристенсен К. Ди-
лемма инноватора: Как из-за новых технологий погибают
сильные компании. М.: Альпина Паблишер, 2016.
Cockburn, Alistair. 2005. Crystal Clear: A Human-Powered
Methodology for Small Teams. Addison-Wesley.
Cohn, Mike. 2004. User Stories Applied: For Agile Software

Development. Addison-Wesley.
-----------. 2005. Agile Estimating and Planning. Prentice Hall.
-----------. 2008. “Writing the Product Backlog Just Enough
and Just in Time.” Scrum Alliance Weekly Column, February
12. www.scrumalliance.org/articles/87-writing-the-product-
back-log-just-enough-and-just-in-time.
-----------2009. Succeeding with Agile: Software Development
Using Scrum. Addison-Wesley. Издание на русском языке:
Кон М. Scrum. Гибкая разработка ПО. М.: Вильямс, 2015.
Conway, Melvin E. 1968. «How Do Committees Invent?”
Datamation, April, 28–31.
Cooper, Alan. 1999. The Inmates Are Running the Asylum:
Why High-Tech Products Drive Us Crazy and How to Restore
Sanity. Sams Publishing.
Cooper, Robert G. 2001. Winning at New Products: Accelerating
the Process from Idea to Launch, 3rd edition. Perseus.
Cunningham, Ward. 1992. “The WyCash Portfolio Management
System.” OOPSLA 1992 Experience Report. http://c2.com/
doc/oopsla92.html.
DeMarco, Tom, Peter Hruschka, Tim Lister, Suzanne Robertson,
James Robertson, and Steve McMenamin. 2008. Adrenaline
Junkies and Template Zombies: Understanding Patterns of
Project Behavior. Dorset House. Издание на русском языке:
Балдеющие от адреналина и зомбированные шаблона-

ми. Паттерны поведения проектных команд / Т. Демарко,
Т. Листер, С. Макменамин и др. СПб.: Символ Плюс, 2010.
Denne, Mark, and Jane Cleland-Huang. 2004. Software
by Numbers: Low-Risk, High-Return Development. Sun
Microsystems Press.
Dennis, Pascal. 2006. Getting the Right Things Done: A Lead-
er’s Guide to Planning and Execution. Lean Enterprise Insti-
tute.
Finkelstein, Sydney, Andrew Campbell, and Jo Whitehead.
2009. Think Again: Why Good Leaders Make Bad Decisions
and How to Keep It from Happening to You. Harvard Business
School Press.
Fry, Chris, and Steve Greene. 2007. “Large Scale Agile
Transformation in an On-Demand World.” Paper presented at
Agile 2007, August 13–17, IEEE, 136–42.
Gilb, Tom. 1988. Principles of Software Engineering Manage-
ment. Addison-Wesley.
Girard, Bernard. 2009. The Google Way: How One Company Is
Revolutionizing Management as We Know It. No Starch Press.
Greene, Steve, and Chris Fry. 2008. “Year of Living Dangerously:
How Salesforce.com Delivered Extraordinary Results through
a ’Big-Bang’ Enterprise Agile Revolution.” Presentation at the
Scrum Gathering, Chicago, April.
Highsmith, Jim. 2009. Agile Project Management: Creating

Innovative Products, 2nd edition. Addison-Wesley.
Judy, Ken H. 2007. “CEO and Team: Collective Product
Ownership at Oxygen Media.” Presentation at the Scrum
Gathering, London, November.
Kaner, Sam, Lenny Lind, Catherine Toldi, Sarah Fisk, and
Duane Berger. 1996. Facilitator’s Guide to Participatory
Decision-Making. New Society Publishers. Издание на рус-
ском языке: Руководство фасилитатора. Как привести
группу к принятию совместного решения / С. Кейнер,
Л. Линд, К. Толди и др. М.: Издательство Дмитрия Лаза-
рева, 2016.
Kano, Noriaki. 1984. “Attractive Quality and Must-Be Quality.”
Journal of the Japanese Society for Quality Control, April, 39–
48.
Larman, Craig. 2004. Agile and Iterative Development:
A Manager’s Guide. Addison-Wesley.
Larman, Craig, and Bas Vodde. 2009. Scaling Lean and Agile
Development: Thinking and Organizational Tools for Large-
Scale Scrum. Addison-Wesley.
Leffingwell, Dean. 2009. “The Product Owner in the Agile
Enterprise.” Agile Journal, April 6.
Levitt, Theodore. 1960. “Marketing Myopia.” Harvard Business
Review 38, no. 4, 45–56.
Levy, Steven. 2008. “Inside Chrome: The Secret Project to

Crush IE and Remake the Web.” Wired, no. 16 (October), www.
wired.com/techbiz/it/magazine/16–10/mf_chrome.
Lidwell, William, Kritina Holden, and Jill Butler. 2003.
Universal Principles of Design. Rockport Publishers.
Lynn, Gary S., and Richard R. Reilly. 2002. Blockbusters:
The Five Keys to Developing Great New Products. Harper-
Collins.
Maeda, John. 2006. The Laws of Simplicity. MIT Press. Изда-
ние на русском языке: Маэда Дж. Законы простоты. Ди-
зайн. Технологии. Бизнес. Жизнь. М.: Альпина Паблишер,
2008.
Mayer, Marissa. 2006. “Nine Lessons Learned about Creativity
at Google.” Presentation at Stanford University, May.
Moore, Geoffrey A. 2006. Crossing the Chasm. Marketing and
Selling Disruptive Products to Mainstream Customers, revised
edition. Collins Business Essentials. Издание на русском язы-
ке: Мур Дж. Преодоление пропасти. Как вывести техноло-
гический продукт на массовый рынок. М.: Манн, Иванов
и Фербер, 2012.
Newkirk, James, and Robert C. Martin. 2001. Extreme
Programming in Practice. Addison-Wesley.
Oberkirch, Brian. 2008. “Working in Close.” 43 Folders,
November. www.43folders.com/2008/01/11/working-close.
Owen, Harrison. 1997. Open Space Technology: A User’s Guide,

2nd edition. Berrett-Koehler Publishers.
Pichler, Roman. 2008. Scrum — Agiles Projektmanagement
erfolgreich einsetzen. dpunkt.verlag.
Poppendieck, Mary and Tom. 2003. Lean Software Develop-
ment: An Agile Toolkit for Software Development Managers.
Addison-Wesley. Издание на русском языке: Поппендик М.
и Т. Бережливое производство программного обеспече-
ния. От идеи до прибыли. М.: Вильямс, 2010.
Reinertsen, Donald G. 1997. Managing the Design Factory:
A Product Developer’s Toolkit. Free Press.
Schmidkonz, Christian. 2008. “Product Owner at SAP —
A New Job Title Developed.” Presentation at ObjektForum,
Stuttgart, September.
Schatz, Bob. 2009. “The Sprint Review: Mastering the Art of
Feedback.” www.scrumalliance.org/articles/124-the-sprint-
review-mastering-the-art-of-feedback.
Schwaber, Ken. 2004. Agile Project Management with Scrum.
Microsoft Press.
-----------. 2007. The Enterprise and Scrum. Microsoft Press.
-----------. 2009. “Scrum Guide.” Scrum Alliance, May.
Schwaber, Ken, and Mike Beedle. 2002. Agile Software
Development with SCRUM. Prentice Hall.
Senge, Peter M. 2006. The Fifth Discipline: The Art and

Practice of the Learning Organization, revised and updated
edition. Random House.
Simons, Matthew. 2004. “Distributed Agile Development and
the Death of Distance.” Cutter Consortium Executive Report,
Sourcing and Vendor Relationships 5, no. 4.
Smith, Preston G., and Guy M. Merritt. 2002. Proactive Risk
Management: Controlling Uncertainty in Product Develop-
ment. Productivity Press.
Smith, Preston G., and Donald G. Reinertsen. 1998. Developing
Products in Half the Time: New Rules, New Tools. John Wiley
and Sons.
Sutherland, Jeff. 2005. “Future of Scrum: Parallel Pipelining
of Sprints in Complex Projects.” Proceedings of the Agile
Development Conference, 90–102.
Wake, Bill. 2003. “INVEST in Good Stories, and SMART Tasks.”
www.xpl23.com/xplor/xp0308/index.shtml. August.
Womack, James P., and Daniel T. Jones. 2005. Lean Solutions:
How Companies and Customers Can Create Value and Wealth
Together. Simon and Schuster. Издание на русском языке:
Вумек Дж., Джонс Д. Бережливое производство. Как изба-
виться от потерь и добиться процветания вашей компа-
нии. М.: Альпина Паблишер, 2016.
Благодарности
Эта книга появилась на свет благодаря помощи многих

людей. Хотел бы от всего сердца поблагодарить всех, кто
рецензировал ее, делился своими историями и давал со-
веты:
Лиссу Адкинс, Гейра Амше, Маркуса Андрезака, Габ-
риэля Бенефилда, Роберта Богетти, Томке Буля, Кауста-
ба Деббармана, Пита Димера, Криса Фрая, Стива Грина,
Роланда Хэнбери, Кевлина Хенни, Бена Хогана, Клинтона
Кита, Андреаса Клингера, Ханса-Петера Корна, Йохена
Кребса, Крэга Лармана, Билла Ли, Лоуэлла Линдстрема,
Кэтрин Луис, Родриго Луна, Артема Марченко, Джейсо-
на Мартинеса, Ралфа Мярку, Филиппа Мисслера, Бента
Мюллерупа, Джеффа Паттона, Тобиаса Пихлера, Бретта
Квинера, Сезарио Рамоса, Дэна Росторна, Саймона Ро-
бертса, Стефана Рука, Рене Розендаля, Джоанну Ротман,
Кеннета Рубина, Мартина Руснака, Ханса-Петера Самио-
са, Боба Шатца, Андреаса Шлипа, Кена Швабера, Кристу
Шваннингер, Карла Скотланда, Мартина Шоу, Лизу Шуп,
Благодарности 227
Джеймса Сиддла, Мишель Слайгер, Престона Смита, Ди-

тера Стефановича, Джеффа Сазерленда, Мадса Трельс-
Хансена, Баса Водде, Джеффа Уоттса, Харви Уитона, Рий-
дигера Вольфа, Элизабет Вудворд и Лу И.
Особенно благодарю Майка Кона. Его терпение, по-
мощь и отзывчивость бесценны. Большое спасибо, Майк!
Благодарю также Джеффа Сазерленда и Бретта Квинера
за замечательные предисловия. И спасибо Кену Шваберу
за то, что научил меня Scrum.
Я бесконечно признателен своей семье. Моя жена, Ме-
лисса Пихлер, дала мне возможность не беспокоиться ни
о чем постороннем и полностью посвятить себя написа-
нию книги. Она терпеливо выслушивала мои идеи, редак-
тировала текст и помогала с дизайном обложки. Спасибо,
любимая! Я благодарен также сыну Лео и дочке Ясмин,
которые самоотверженно старались ходить на цыпочках,
пока папа пишет. Особая признательность пятилетнему
Лео за его честность. Прочитав несколько предложений,
он сказал: «Папа, это немного странно».
Также я хотел бы поблагодарить Ребекку Трегер за пре-
красную редакторскую работу и команду издательства
Pearson — Криса Гузиковски, Райну Хробак, Шери Кейн,
Анну Попик и Барбару Вуд — за помощь и трудолюбие.
Об авторе
Роман Пихлер — один из ведущих экспертов по Scrum

и agile-управлению продуктом. Он опытный наставник
и помог многим компаниям в применении эффективных
методов управления продуктом. Роман часто выступает
на международных конференциях. Он сертифицирован-
ный тренер по Scrum и возглавлял Scrum Alliance в про-
цессе выработки курса обучения владельцев продукта.
Максимально
полезные книги
Заходите в гости:
http://www.mann-ivanov-ferber.ru/
Наш блог:
http://blog.mann-ivanov-ferber.ru/
Мы в Facebook:
http://www.facebook.com/mifbooks
Мы ВКонтакте:
http://vk.com/mifbooks
Предложите нам книгу:

http://www.mann-ivanov-ferber.ru/about/predlojite-nam-knigu/
Ищем правильных коллег:

http://www.mann-ivanov-ferber.ru/about/job/
Научно-популярное издание
Роман Пихлер
Управление продуктом в Scrum
Agile-методы для вашего бизнеса
Главный редактор Артем Степанов

Ответственный редактор Татьяна Рапопорт
Литературный редактор Игорь Лейко
Арт-директор Алексей Богомолов
Дизайн Сергей Хозин
Верстка Екатерина Матусовская
Корректоры Надежда Болотина, Юлия Молокова

Пихлер Р. - Управление Продуктом в Scrum. Agile-методы Для Вашего Бизнеса - 2017

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Пихлер Р. - Управление Продуктом в Scrum. Agile-методы Для Вашего Бизнеса - 2017

Загружено:

Авторское право:

Доступные форматы

Эту книгу хорошо дополняют:

Scrum. Революционный метод управления

Издано с разрешения Pearson (Addison-Wesley Professional)

Ядро каждой успешной команды agile-разработки — дальновидный,

Authorized translation from the English language

ISBN 978-5-00100-354-0 © Roman Pichler, 2010

1. Кто такой владелец продукта? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2. Планирование концепции продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3. Работа с бэклогом продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Очки историй . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

4. Планирование релиза . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Диаграмма сгорания работ для релиза . . . . . . . . . . . . . . . . . . . . . 160

5. Совместная работа на совещаниях по спринту . . . . . . . . . . 182

Ретроспективный анализ спринта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

6. Превращение во владельца продукта . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Как развивать владельцев продукта . . . . . . . . . . . . . . . . . . . . . . . . . . 211

Владелец продукта — новая роль для большинства ком-

приоритеты и разложить функционал на небольшие эле-

* Бэклог (или журнал продукта) — список всех пожеланий к продук-

команды. Роль Дона была гораздо серьезнее, чем обычно

Сегодня во всей индустрии ПО набирает силу Agile. По­

ли внедрять инновации с такой же скоростью, с какой рас-

внедрять­ инновации. Роман приводит множество приме-

По гибкой разработке ПО и управлению продуктом на-

* Гик — человек, чрезвычайно интересующийся чем-либо, фанат.

но не бизнесменов­. Занимаясь коучингом своего первого

В начале нашей работы мы постоянно слышали

Таблица 1. Управление продуктом по-старому и по-новому

Старые методы Новые методы

Несколько ролей — напри- Один человек, владелец продукта,

Менеджеры команды отде- Владелец продукта — член scrum-

Обширное исследование Минимальная предварительная

Предварительное иссле- Исследование продукта — это посто-

Отзывы пользователей Максимально быстрые и частые

Agile-методы, в том числе Scrum, придерживаются

Что предлагает эта книга

разработка и совершенствование бэклога продукта, пла-

Однажды я работал над продуктом в области здраво­

Как разрешить ситуацию? На всех этапах за продукт

Роль владельца продукта

Владелец продукта — единственный человек, отве-

Определение звучит вполне безобидно, пока мы не на-

но и в поддержании­ жизненного цикла продукта. На-

обеспечения­, аппаратного обеспечения и механических

* От Chief Executive Officer (англ.) — высшая исполнительная долж-

усилий Джерри Лейборна, CEO компании­Oxygen Media,

Визионер* и человек действия

Писатель Джонатан Свифт заметил: «Ви`­де­ние — это ис-

* Визионер (от англ. vision — видение) — человек, обладающий стра-

визионер­, который может представить себе конечный про-

Лидер и командный игрок

«Хорошие бизнес-лидеры создают концепцию, формули-

scrum‑команды­ и не обладает формальной властью над

одного человека. И даже если владелец продукта —

Владелец продукта должен быть эффективным пропа-

который доносит до исполнителей требования потреби-

У владельца продукта должно быть достаточно полномо-

* Личное сообщение Филиппа Мисслера, CTO компании mobile.de,

и т. д. Это человек, имеющий доступ к бюджету и спо-

Владелец продукта должен быть доступным и иметь нуж-

Владелец продукта в PatientKeeper

информационных­ систем в области здравоохране-

* Из письма Джеффа Сазерленда на рассылку scrum-тренеров Yahoo!

Владелец продукта — это такой же член scrum-команды,

Сегодня во всей индустрии ПО набирает силу Agile. По

внедрять инновации. Роман приводит множество приме-

но не бизнесменов. Занимаясь коучингом своего первого

Однажды я работал над продуктом в области здраво

но и в поддержании жизненного цикла продукта. На-

обеспечения, аппаратного обеспечения и механических

усилий Джерри Лейборна, CEO компанииOxygen Media,

Писатель Джонатан Свифт заметил: «Ви`дение — это ис-

визионер, который может представить себе конечный про-

scrum‑команды и не обладает формальной властью над

информационных систем в области здравоохране-

командной работы, личного пространства и деятельнос-

на рынке, только если достаточное количество клиентов

может получить поддержку от управляющего порт

может быть доверено одному владельцу продукта без

В данном случае владельцы продукта образуют непрос-

Главный владелец продукта возглавляет общую раз-

команды, а компонентные привлекают только при необ-

продукта, критичного для развития бизнеса. Хотя он иде-

за общий продукт. Ни один из них не руководит этой

— Кто представляет клиентов и пользователей в ва-

В начале 1990‑х телефонные конференции были насто

действительно способен вдохновлять и нередко