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
Пихлер, Роман
П36 Управление продуктом в Scrum. Agile-методы для вашего бизне-
са / Роман Пихлер ; пер. с англ. Александра Коробейникова. —
М. : Манн, Иванов и Фербер, 2017. — 240 с.
ISBN 978-5-00100-354-0
УДК 658.5.012.1
ББК 65.291.217
Все права защищены. Никакая часть данной
книги не может быть воспроизведена
в какой бы то ни было форме без письменного
разрешения владельцев авторских прав.
Предисловие Джеффа Сазерленда . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Предисловие Бретта Квинера . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Предисловие . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Чем отличается agile‑управление продуктом . . . . . . . . . . . . 23
Что предлагает эта книга и кто должен
ее прочесть . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Работа с командой . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Взаимодействие со scrum‑мастером . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Работа с клиентами, пользователями
и другими заинтересованными лицами . . . . . . . . . . . . . . . . . . . . . 41
Моделирование роли владельца продукта . . . . . . . . . . . . . . . . . 45
Главный владелец продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Иерархия владельцев продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Как правильно выбрать владельцев
продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Распространенные ошибки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Владелец продукта с недостаточными
полномочиями . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Перегруженность владельца продукта . . . . . . . . . . . . . . . 53
Частичный владелец продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Удаленный владелец продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Заместитель владельца продукта . . . . . . . . . . . . . . . . . . . . . . . . . 57
Комитет владельцев продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Вопросы для самоконтроля . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Минимально функциональный продукт . . . . . . . . . . . . . . . . . . . . 68
Простота . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Бритва Оккама . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Чем меньше, тем лучше . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Простые пользовательские интерфейсы . . . . . . . . . . . . . 76
Потребности покупателя и свойства продукта . . . . . . . . . 78
Рождение видения продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Любимые проекты . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Использование Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Техники формирования видения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Прототипирование и макетирование . . . . . . . . . . . . . . . . . 84
Персоны и сценарии . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Визуализация и обзор в отраслевом журнале . . . . 88
Модель Кано . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Формирование видения и дорожная карта
продукта . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Минимальные продукты и варианты продукта . . . . . . . . 92
Распространенные ошибки . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Отсутствие видения . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Пророческое видение . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Аналитический паралич . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
«Мы-лучше-знаем-что-нужно-клиентам» . . . . . . . . . . . 97
«Большое — значит хорошее» . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Вопросы для самоконтроля . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
10 Содержание
Библиография . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Благодарности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Об авторе . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Посвящается Мелиссе
Предисловие
Джеффа Сазерленда
Чем отличается
agile‑управление продуктом
Agile, или гибкое управление продуктом, основанное
на Scrum, отличается от традиционных подходов во мно-
гих отношениях. В таблице 1 приведено резюме наиболее
важных различий.
24 Управление продуктом в Scrum
Характеристики правильного
владельца продукта
Выбор правильного владельца продукта необходим
в любом scrum-проекте. Успешные владельцы продук-
та, с которыми я работал, обладали некоторыми общи-
ми чертами. Поскольку владелец продукта — это новая
роль, людям часто требуются время и поддержка, чтобы
приспособиться к ней и приобрести необходимые навы-
ки. Основная проблема — найти сотрудников с прием-
лемым уровнем знаний и опыта, которые смогут хорошо
выполнить задачу. (Переход к роли владельца продукта
и самосовершенствование в этой должности описаны
в главе 6.)
Команда предпринимателей
Порой мы излишне концентрируемся на знаменитых
предпринимателях и лидерах — Билле Гейтсе, Стиве
Джобсе и других. На самом деле лишь немногие ин-
новации — это действительно результат гениальности
34 Управление продуктом в Scrum
Пропагандист и переговорщик
Наделенный полномочиями
и преданный делу
Доступный и квалифицированный
Работа с командой
Взаимодействие
со scrum‑мастером
Чтобы постоянно играть на высшем уровне, спортивной
команде необходим тренер, а scrum-команде — scrum-
мастер*. Он оказывает поддержку владельцу продукта
и команде, защищает ее и процесс работы и при необхо-
димости вмешивается, чтобы удостовериться, справляет-
ся ли команда с задачей, сохраняет ли здоровую атмосфе-
ру и мотивацию и не создает ли технического долга**.
Роли владельца продукта и scrum-мастера дополняют
друг друга. Владелец продукта в первую очередь отвечает
за создание нужного продукта. Scrum-мастер в основном
несет ответственность за то, «как» правильно использо-
вать практики Scrum. Эти два аспекта проиллюстриро-
ваны на рисунке 1.1. Долгосрочный успех достигается,
когда правильный продукт создается правильными ме-
тодами.
Неправильно Правильно
Работа с клиентами,
пользователями и другими
заинтересованными лицами
Клиент — это тот, кто приобретает продукт, а пользо-
ватель — человек, применяющий продукт. Они опреде-
ляют его успех или неудачу. Продукт будет востребован
42 Управление продуктом в Scrum
Менеджеры по продуктовому
маркетингу и менеджеры продукта
Некоторые компании разграничивают стратегиче
ский и тактический продакт-менеджмент и выделяют
отдельные должности для каждого из них: менеджер
по продуктовому маркетингу и (технический) менед-
жер продукта. Деятельность менеджеров по продук-
товому маркетингу обычно направлена вовне: в их
обязанности входит понимать рынок, управлять пла-
ном развития продукта и следить за общими дохода-
ми после релизов. А менеджеры продукта смотрят
внутрь: их задача — подробное описание функций,
расстановка приоритетов и сотрудничество с коман
дой разработчиков. В Scrum владелец продукта
совмещает все эти обязанности. По стратегическим
вопросам управления продуктом владелец продукта
44 Управление продуктом в Scrum
Моделирование роли
владельца продукта
Прежде чем рассказать о методах работы владельца про-
дукта в крупных scrum-проектах, хочу дать совет: избе-
гайте больших проектов! Начинайте с малого и быстро
разрабатывайте продукт с минимальной функциональ-
ностью. Об этом пойдет речь в главе 2. Если приходится
заниматься крупным проектом, увеличивайте объемы
медленно. Пусть он растет естественным образом, при-
бавляя по одной команде за раз. Если работу начинает
слишком большое число людей, то проект может стать
чересчур сложным, так что последующие обновления по
требуют массу времени и денег*.
Владелец Владелец
продукта продукта
«МР3-плеер» «Игры»
Владелец Владелец
продукта продукта
«Тетрис» «Шахматы»
Распространенные ошибки
Введение роли владельца продукта для многих организа-
ций означает вход на новую для них территорию. И путь
к эффективному использованию этой должности полон
опасностей и ловушек. Данный раздел поможет избежать
некоторых наиболее распространенных ошибок.
Видение продукта
— Скажите, пожалуйста, куда мне отсюда идти?
— Это во многом зависит от того, куда ты хочешь
прийти, — ответил Кот.
— Да мне почти все равно, — начала Алиса.
— Тогда все равно, куда идти, — сказал Кот.
Льюис Кэрролл, «Алиса в Стране чудес»*
Общее и объединяющее
Широкое и мотивирующее
Краткое и приятное
Минимально
функциональный продукт
Чтобы создать видение продукта, scrum-команда долж-
на заглянуть в будущее и сформулировать то, как, по ее
мнению, будет выглядеть и работать будущий продукт.
Конечно, для любого человека, не наделенного даром яс-
новидения, верное предсказание будущего — дело чрез-
вычайно сложное. В конце концов, единственное, что мы
точно знаем о будущем, — это то, что оно неопределенное.
Не существует методики исследования рынка, способной
2. Планирование концепции продукта 69
* “So Much Fanfare, So Few Hits”, BusinessWeek.com, July 10, 2006. По-
добный же подход отражен в знаменитом изречении Арта Фрая
из 3М: «Чтобы найти принца, придется перецеловать много лягу-
шек». Заметьте, что прекрасный принц заплатит за всех этих ля-
гушек. (Имеется в виду сказка братьев Гримм «Принц-лягушка».
Прим. ред.)
74 Управление продуктом в Scrum
Простота
Простота облегчает создание удобного в использовании
продукта с минимальной функциональностью. Не сто-
ит путать простоту с упрощенностью. Еще Леонардо
да Винчи говорил: «Простота — это высшая степень слож
ности».
Бритва Оккама
Потребности покупателя
и свойства продукта
Потребности покупателя и свойства продукта лежат
в основе любой концепции и заслуживают самого при-
стального внимания. От выбора важнейших потребнос-
тей покупателя зависит то, к какому рынку или его сег-
менту мы собираемся обращаться. Сосредоточившись
на пот ребностях, мы рассматриваем продукт как средс-
тво достижения цели — удовлетворения нужд клиента
или пользователя. В то же время свойства продукта —
критически важные параметры, которыми должен об-
ладать продукт для удовлетворения этих потребностей.
Например, сенсорный экран — это свойство продукта.
Вероятно, потребность, обусловившая это свойство, —
простота в использовании. Свойства могут быть как
функциональными, так и нефункциональными. Функци-
ональные свойства — это конкретные функции или черты
продукта, например способность совершать и принимать
звонки. Нефункциональные свойства — это производи-
тельность, выносливость, стиль, дизайн и удобство в ис-
пользовании. Нефункциональные атрибуты могут стать
важным дифференцирующим фактором — воздейство-
вать на пользовательский опыт, а также на расширяе-
мость продукта и удобство его эксплуатации, которые,
2. Планирование концепции продукта 79
Любимые проекты
Использование Scrum
Прототипирование и макетирование
Планирование, выполнение,
проверка и воздействие
Организованный эксперимент проходит по четырех-
шаговой модели, известной также как цикл Деминга.
Сначала мы вырабатываем гипотезу (планирование).
Затем воплощаем ее (выполнение) и анализируем
результаты (проверка). Если эксперимент оказал-
ся неудачным, мы вносим в гипотезу изменения, где
необходимо, и проводим следующий эксперимент —
либо для достижения лучшего результата, либо что-
бы попробовать другой подход (воздействие). Томас
Эдисон, создатель первой коммерчески успешной
электрической лампочки, знал о неизбежности проб
и ошибок — необходимости многократно ошибиться,
чтобы воплотить в жизнь полноценный продукт. Хо-
рошо известна его фраза:
«Если я обнаружил десять тысяч методов, кото-
рые не работают, это не ошибка. Я не обескуражен,
потому что исключение каждого неверного метода —
это шаг вперед».
2. Планирование концепции продукта 87
Персоны и сценарии
Визуализация и обзор
в отраслевом журнале
Модель Кано
Формирование видения
и дорожная карта продукта
До сих пор в этой главе рассматривались вопросы со-
здания видения нового продукта, что особенно сложно.
По мере «взросления» продукта и выхода пошаговых об-
новлений визионерская деятельность обычно сокраща-
ется. Но новым версиям продукта все еще нужны цели.
План развития продукта позволяет scrum-команде сфор-
мулировать цели будущих версий продукта. Пока виде-
ние заключается в создании и корректировке дорожной
карты продукта.
Дорожная карта продукта — это тип плана, который
показывает, как продукт должен развиваться в своих вер-
сиях, и облегчает диалог между scrum-командой и заин-
тересованными лицами. Дорожная карта продукта позво-
ляет организациям координировать разработку и запуск
смежных продуктов — например, линейки продуктов или
продуктового портфеля. Рекомендуется не усложнять
план развития продукта, а сосредоточиться на самой
сути. План развития продукта должен содержать пример-
ную дату выхода следующей версии, указание целевых
потребителей и их нужд и три-пять основных функций.
Не беспокойтесь о деталях. Они появятся и будут отра-
жены в бэклоге продукта. Заметьте, что дорожная карта
92 Управление продуктом в Scrum
Минимальные продукты
и варианты продукта
В процессе взросления продукт начинает отвечать все
большему числу потребностей покупателей: обслуживает
потребителей в разных сегментах и регионах. Поскольку
2. Планирование концепции продукта 93
Распространенные ошибки
Выработка продуктового видения — это необходимый
шаг в подготовке его к запуску. Берегитесь следующих
Отсутствие видения
Пророческое видение
Аналитический паралич
«Мы-лучше-знаем-что-нужно-клиентам»
истории
Низкий
Оценка
Развитие
Приоритетность
Выявление и описание
элементов
Выявление и описание элементов бэклога продукта —
это постоянный процесс. Если вы привыкли составлять
полные и подробные спецификации, смиритесь с тем, что
Scrum поддерживает совершенно иной подход. Требова-
ния больше не замораживаются на ранней стадии — они
выявляются и детализируются в течение всего проекта.
По мере того как улучшается наше понимание потребнос-
тей покупателя и того, как оптимально их удовлетворить,
108 Управление продуктом в Scrum
Выявление элементов
Описание элементов
Расстановка приоритетов
в бэклоге продукта
Никогда не забуду тот день, когда я предложил менеджеру
продукта в области здравоохранения расставить приори-
теты в отношении лежащих перед ней вариантов исполь-
зования. Она посмотрела на меня с удивлением и ответи-
ла: «Я не могу. Они все очень важные».
Расстановка приоритетов требует решить, насколько
значим тот или иной элемент. Если у всех высокий при-
оритет, значит, все одинаково важны. На самом деле это
значит, что приоритета нет вообще и шансы создать то,
что действительно нужно покупателю, очень невели-
ки. Расстановка приоритетов в бэклоге продукта входит
в сферу ответственности владельца продукта. Однако, как
и при любой работе с бэклогом, лучше всего расставлять
приоритеты всей scrum-командой. В этом случае исполь-
зуется коллективный опыт команды и поддерживается
мотивация.
114 Управление продуктом в Scrum
Ценность
Возможность выпуска
Взаимозависимости
Подготовка к планированию
спринта
Перед каждым совещанием по планированию спринта
нужно подготовить элементы бэклога продукта, которые,
по всей вероятности, будут реализованы в ходе ближай-
шего спринта. Начинать следует с выбора цели спринта.
Размер
Большие
необра-
Большой ботанные
элементы
Декомпозиция элементов
Определение масштабов
элементов
Оценка элементов бэклога продукта позволяет нам при-
мерно понять их сложность и трудоемкость. Это полезно
по двум причинам — облегчает расстановку приорите-
тов и позволяет отслеживать и прогнозировать ход про-
екта. В Scrum используются два различных типа оценок:
приблизительные — в бэклоге продукта, указывающие
на примерный масштаб элемента, — и более точные оцен-
ки в спринт-бэклоге, сообщающие размер задач, на кото-
рые разбит элемент бэклога, обычно выраженный в рабо-
чих часах. В этом разделе рассказывается об определении
масштабов элементов бэклога продукта. Они оценивают-
ся, если выявляются новые или модифицируются старые
элементы либо изменяется командное понимание разме-
ров элемента. Поэтому необходимо средство измерения,
130 Управление продуктом в Scrum
Очки историй
Покерное планирование
Оценка нефункциональных
требований
Нефункциональные требования, которые приме-
няются ко всем функциональным, например произ-
водительность или пользовательские требования,
обычно не оцениваются самостоятельно, а вклю-
чаются в командные критерии готовности. Однако
если для внедрения нефункционального требова-
ния необходима дополнительная работа — исследо-
вание альтернативного дизайна пользовательского
134 Управление продуктом в Scrum
Экспресс-оценка
Если команда слишком ограничена во времени для
покерного планирования, можно использовать сле-
дующий метод оценки. Разделите одну стену кон-
ференц-зала на несколько частей, каждая из кото-
рых будет отражать одно из значений спектра очков
за пользовательскую историю. Распечатайте на бу-
мажных карточках элементы бэклога продукта и по-
ложите их на стол. Пусть все члены команды возьмут
по карточке, примут решение об оценке и прикрепят
карточку на ту часть стены, которая соответствует
избранному ими значению. При этом элемент должен
соответствовать по размеру другим элементам той же
группы. Если кто-то видит неподходящую карточку,
он сразу перемещает ее в нужную группу. Этот про-
цесс дает возможность очень быстро и с минималь-
ными усилиями оценить многие элементы. Основной
недостаток состоит в том, что команда не обсуждает
размер элементов. Поэтому качество оценки обычно
ниже по сравнению с результатами покерного плани-
рования.
Работа с нефункциональными
требованиями
Нефункциональные требования, также именуемые опе-
рационными, свойствами системы и ограничителя-
ми, — это настоящие гадкие утята разработки ПО. Ими
136 Управление продуктом в Scrum
Описание нефункциональных
требований
Управление нефункциональными
требованиями
Бэклог продукта
при масштабировании
Большие проекты, в которых принимает участие мно-
го команд, приносят новые проблемы. Одна из них —
что делать с бэклогом продукта при масштабировании.
3. Работа с бэклогом продукта 139
Распространенные ошибки
Хотя бэклог продукта — это очень простой инструмент,
использовать его правильно не всегда просто. Избегайте
таких распространенных ошибок, как спецификация под
видом бэклога продукта, письмо с просьбами к Санта-
Клаусу, навязывание требований команде, пренебреже-
ние работой по грумингу бэклога и создание нескольких
бэклогов для одной команды.
Замаскированная спецификация
Навязывание требований
Пренебрежение грумингом
Время, затраты
и функциональность
Планирование релиза начинается с принятия решения
о том, какая из составляющих проекта — время, затра-
ты или функциональность — должна остаться неизмен-
ной для запуска успешного продукта. Необходим ли за-
пуск именно в указанную дату? Жестко ли задан бюджет
на разработку? Нужно ли реализовать все требования,
отраженные в бэклоге продукта? Одновременная фикса-
ция времени, бюджета и функциональности невозможна.
По крайней мере одна из составляющих должна играть
роль высвобождающего клапана. Самое удачное реше-
ние — ограничить время и делать гибкой функциональ-
ность.
Фиксирование функциональности — плохой вари-
ант. Даже при наличии видения продукта его точные
свойства, функциональность и особенности не известны
сразу. Они открываются постепенно, на основе отзывов
клиентов и пользователей. Появляются новые требо-
вания, бэклог продукта развивается по мере того, как
4. Планирование релиза 149
Стабильность качества
Как мы убедились, функциональность продукта разви-
вается. Его точность тоже может возрастать в ходе про-
екта: улучшаются внешний вид, ощущения и опыт ис-
пользования. Но качество продукта в Scrum стабильно.
Критерии качества зафиксированы в критериях готов-
ности. Такое определение обычно подразумевает, что
результат каждого спринта должен быть (потенциаль-
но) готов к постановке инкремента продукта: это бу-
дет исполняемая программа, проверенная, задокумен-
тированная и готовая к релизу. Обеспечение качества
и меры контроля образуют неотъемлемую часть любо-
го спринта. Они не проводятся в конце проекта задним
числом.
Необходимо убедиться, что в ходе спринтов дей
ствительно создаются обновления нужного качества.
Владелец продукта не должен поощрять компромиссы
в качестве программ: не следует принимать результа-
ты работы, не соответствующие заданным критериям.
Ненадлежащее качество ведет к дефектным обновле-
ниям продукта, поэтому не получается четко отслежи-
вать прогресс и выпускать частые и быстрые релизы.
Более того, компромиссный подход к качеству имеет
долгосрочный отрицательный эффект. Вырабатывается
154 Управление продуктом в Scrum
Квартальные циклы
В Scrum не существует правил, которые предписывали
бы конкретную длительность проекта. Однако agile-
проекты обычно длятся от трех до шести месяцев. Если
для вывода продукта на рынок требуется более трех-четы-
рех месяцев, используйте квартальные циклы, выпуская
ежеквартально как минимум одну версию работающей,
протестированной и задокументированной программы
(Beck and Andres, 2005; 47–48). Google пользовалась этой
методикой в течение тех двух лет, которые ушли на разра-
ботку первой версии браузера Chrome. Дэрин Фишер так
описывает процесс: «Мы ориентировались на кварталь-
ные циклы, так что живой документ [бэклог продукта]
158 Управление продуктом в Scrum
Скорость
Скорость — индикатор того, какой объем работы может
выполнить команда в течение одного спринта. Она позво-
ляет отследить и предсказать ход проекта. Точнее говоря,
* Бек и Фаулер (Beck and Fowler, 2000) называют это свойство вче-
рашней погодой. Отметим, что приблизительный прогноз вполне
приемлем, если ход работ проверяется каждые несколько недель
в процессе обзорных совещаний на спринтах, что дает возмож-
ность обновить график и изменить прогноз.
162 Управление продуктом в Scrum
200
150
100
50
Спринты
1 2 3 4 5 6 7 8 9 10
200
150
100
50
0
1 2 3 4 5 6 7 8 9 10 Спринты
–50
План релиза
«Планы — ничто, планирование — все», — заметил как-то
Дуайт Эйзенхауэр*. Эта идея особенно подходит для пла-
на релиза. Хотя в Scrum от команд в обязательном порядке
не требуется план релиза, планировать его все-таки необ-
ходимо. Многим командам Scrum достаточно использо-
вать диаграмму сгорания работ и группировать элементы
бэклога продукта по категориям, чтобы понимать, какие
функции и в каком релизе внедрять**. Однако большие
scrum-проекты и те, которые требуют координации с дру-
гими проектами, партнерами или поставщиками, все же
должны разрабатывать формальный план релиза.
План релиза — это своего рода карта, обозначающая
нам направление. Он показывает, насколько мы прибли-
зились к выпуску продукта и когда он состоится. Мож-
но сказать, что план релиза — это расширенная версия
Спринт 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
текс- звонки,
товые сооб-
сооб- щения
щения с кар-
тинками
Текущий
спринт
Прогнозирование скорости
Планирование релизов
в больших проектах
Для планирования релизов в больших проектах требуют-
ся дополнительные методы работы. К ним относятся уста-
новление общих ориентиров для оценок, перспективное
планирование и, при необходимости, организация кон-
вейерной работы.
174 Управление продуктом в Scrum
Перспективное планирование
Конвейерная работа
Распространенные ошибки
При планировании релиза в scrum-проекте избегайте
следующих ошибок: отсутствие диаграммы сгорания
178 Управление продуктом в Scrum
Взрывной релиз
Планирование спринта
Совещание по планированию спринта позволяет коман-
де запланировать свою работу на спринт и сформулиро-
вать цель спринта, тем самым закладывается основание
для самоорганизации работы. Обязанность владельца
продукта — убедиться в том, что бэклог продукта хоро-
шо проработан, приоритеты в списке элементов расстав-
лены, а самые приоритетные из них детально описаны
до совещания по планированию спринта. Кроме того,
на совещании по планированию спринта нужно про-
яснить требования и ответить на возможные вопросы
команды.
Роль владельца продукта во время планирования
спринта состоит в том, чтобы помочь команде осознать,
что должно быть сделано. Команда же прикидывает, ка-
ков объем работы и как ее можно сделать. Вы не должны
указывать команде, сколько работы нужно выполнить
за спринт, или определять состав задачи от имени коман-
ды, не посоветовавшись с ней. Это прерогатива команды.
5. Совместная работа на совещаниях по спринту 185
Критерии готовности
Как команда понимает, что работа действительно сдела-
на? И как владельцу продукта определить, что какой-то
участок работы был успешно внедрен? Для этого необхо-
димо заранее выработать критерии готовности, то есть
описание требований, которым должно соответствовать
каждое обновление. Эти критерии обычно требуют пре-
вращения элементов бэклога продукта в работающие
программы, тщательно протестированные и задокумен-
тированные. Требования должны быть соответствующим
образом внедрены, протестированы и задокументирова-
ны в ходе одного спринта. Исключение — концептуаль-
ные спринты, цель которых — не выдать готовый про-
дукт, а получить необходимые для создания концепции
продукта знания. У этих спринтов есть собственные кри-
терии готовности.
Перед первым спринтом владелец продукта должен
встретиться со scrum-мастером и командой и выработать
критерии готовности. В некоторых проектах в критерии
5. Совместная работа на совещаниях по спринту 187
Ежедневный scrum-митинг
Такой вид scrum-собрания позволяет команде управ-
лять своей работой изо дня в день и выявлять препят
ствия и проблемы. Владелец продукта должен постоян-
но посещать их. Это отличная возможность понять, как
идет работа, и выяснить, не нужна ли команде помощь
(например, нужно быть готовым отвечать на вопросы,
анализировать результаты работы или помогать устра-
нять препятствия). Можно также сообщить информацию
и рассказать команде, над чем вы работаете сейчас и что
планируете делать дальше. Часто работа владельца про-
дукта предоставляет важную информацию о действиях
на уровне релиза и на периферии проекта.
Во время ежедневных scrum-митингов желательно
не вмешиваться в самоорганизацию команды, форму-
лировать и назначать задания, комментировать про-
гресс отдельных сотрудников. Если вас беспокоит ход
работы, делитесь своим мнением конструктивно —
188 Управление продуктом в Scrum
Препятствия
Нерешенные проблемы размножаются как грибы
после дождя. Вот почему Scrum уделяет особое
внимание борьбе с препятствиями — выявлению
и устранению проблем, которые мешают работе
и причиняют вред проекту. Члены команды расска-
зывают о препятствиях и проблемах на ежедневном
scrum-митинге, и scrum-мастер отвечает за то, что-
бы они были устранены как можно быстрее. Даже
если работа над проблемами кажется замедлением
хода проекта, она препятствует возникновению бо-
лее серьезных трудностей и долгих отсрочек. «Про-
блемы — это сокровища, — пишет эксперт по бе-
режливому управлению Паскаль Деннис. — Они
дают возможность учиться и совершенствоваться»
(Dennis, 2006; 19).
Спринт-бэклог и диаграмма
сгорания работ для спринта
Спринт-бэклог включает в себя все действия, необхо-
димые для достижения цели спринта. Команда создает
спринт-бэклог на совещании по планированию спринта
и регулярно его обновляет — как минимум раз в день.
Во время этих обновлений команда может добавлять
новые элементы или исключать те, которые становятся
неактуальными, она также фиксирует количество очков
историй, оставшееся на каждую задачу. Очень удобно ра-
ботать с доской задач, размещенной в рабочем помещении
и доступной каждому сотруднику. Диаграмма сгорания
работ позволяет команде понять, как она идет по дистан-
ции и насколько вероятно достижение цели спринта. Пос-
ле этого команда может внести соответствующие измене-
ния в рабочий процесс.
Спринт-бэклог и диаграмма сгорания работ для
спринта в основном обслуживают команду, поскольку
они облегчают самоорганизацию. Однако они также при-
носят пользу и владельцу продукта. С их помощью можно
понять, насколько вероятно выполнение поставленной
задачи. Однако все это не является средством отчетнос-
ти перед заинтересованными лицами. Если, например,
клиенты и руководство хотят узнать о ходе работ в те-
чение спринта, их можно пригласить на ежедневный
190 Управление продуктом в Scrum
Своевременные обзоры
Владельцу продукта необязательно ждать обзора
итогов спринта, чтобы дать отзыв о результатах ра-
боты. Полезно проводить своевременные обзоры
сразу после появления результатов спринта. Это
дает команде возможность что-то исправить уже
в ходе спринта. Своевременные обзоры особенно
важны, если элементы бэклога продукта, внедря
емые в ходе спринта, достаточно мелкие, чтобы
команда могла закончить работу над ними за не-
сколько дней.
Ретроспективный анализ
спринта
Ретроспективные анализы спринта помогают scrum-
команде проверить, насколько хорошо выполнена ра-
бота, выявить проблемы и их причины и понять, какие
меры нужно принять, чтобы работа была эффективной.
Немецкая пословица «Самопознание — первый шаг к со-
вершенствованию» отлично резюмирует главную идею
ретроспективных анализов.
194 Управление продуктом в Scrum
Совещания по спринтам
в крупных проектах
Хотя крупные проекты следуют тому же расписанию со-
вещаний, что и другие проекты Scrum, сами совещания
видоизменяются. В этом разделе мы расскажем, как это
происходит.
Scrum-совещание по Scrum
Распространенные ошибки
Владелец продукта должен поддерживать тесное сотруд-
ничество с командой и scrum-мастером, избегая распро-
страненных ошибок, к которым относятся «скачущий»
5. Совместная работа на совещаниях по спринту 199
Нежизнеспособный темп
Познайте себя
Развитие и рост
Найдите наставника
Убедитесь в поддержке
на нужном уровне
Вы еще не готовы
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.
220 Управление продуктом в Scrum
Заходите в гости:
http://www.mann-ivanov-ferber.ru/
Наш блог:
http://blog.mann-ivanov-ferber.ru/
Мы в Facebook:
http://www.facebook.com/mifbooks
Мы ВКонтакте:
http://vk.com/mifbooks
Роман Пихлер
Управление продуктом в Scrum
Agile-методы для вашего бизнеса