Скрам Гайде версии 2011 года присутствовал термин Grooming. Это неофициальная встреча Скрама, во время которой Команда Разработки вместе Владельцем Продукта старательно «причесывают» Беклог, готовя его к следующим Спринтам. В последней версии встреча не изменила своего назначения, просто сменила вывеску и теперь называется Product Backlog Refinement (PBR).
Зачем? Откройте английский жаргонный словарь, и вы сразу поймете, почему многие англичане раньше смущенно качали головой.
Тем не менее, давайте считать, что во время Product Backlog Refinement (PBR) Беклог, как и прежде, отправляется в парикмахерскую для того, чтобы команда и Владелец Продукта могли:
- Добавить, убрать или разбить Элементы Беклога Продукта (PBI).
- Уточнить или дать новые оценки.
- Изменить порядок следования элементов Беклога Продукта.
- Обсудить и прояснить требования.
Поддержка Беклога Продукта – это активность по добавлению деталей, оценок и упорядочивания элементов в Беклоге Продукта. Это непрерывный процесс, во время которого Владелец Продукта и Команда Разработки работают над требованиями Беклога Продукта. Во время обработки требования проверяются и пересматриваются. Скрам Команда решает, как и когда должна производиться Поддержка Беклога Продукта. Обычно это занимает не более 10% времени Скрам Команды. Однако Владелец Продукта в любое время может изменить требования на свое усмотрение (Scrum Guide, july 2013).
PBR одна из самых загадочных встреч, и у команд возникает много вопросов. Мы постараемся разобраться в этом, но для этого сначала давайте пробежимся по определению Беклога Продукта.
Беклог Продукта. Последняя версия Скрам Гайда дает нам определение:
Беклог Продукта – это УПОРЯДОЧЕННЫЙ список всего, что может быть нужным в продукте, он является ЕДИНСТВЕННЫМ источником требований для любых изменений, которые может потребоваться внести в продукт. ОТВЕТСТВЕННОСТЬ за Беклог Продукта несет Владелец Продукта, включая его содержимое, доступность и упорядочение.Беклог Продукта никогда не является полным. Начальная версия этого документа содержит только первоначально известные и наиболее понятные требования. Беклог Продукта постоянно обновляется по мере обновления самого продукта и среды, в которой он разрабатывается. Беклог Продукта является ДИНАМИЧЕСКИМ, постоянно изменяющимся для соответствия требованиям продукта, его конкурентоспособности и пригодности. Беклог Продукта существует ровно до тех пор, пока существует и сам продукт. Беклог Продукта содержит все ФИЧИ, ФУНКЦИИ, ТРЕБОВАНИЯ, УСОВЕРШЕНСТВОВАНИЯ и ДЕФЕКТЫ, то есть те данные, которые и определяют изменения, необходимые в следующих релизах продукта. Каждому Элементу Беклога Продукта присваиваться ОПИСАНИЕ, ПОРЯДКОВЫЙ НОМЕР, ОЦЕНКА и ЦЕННОСТЬ.
Я выделил некоторые слова большими буквами. Давайте быстро пробежимся по ним:
- УПОРЯДОЧЕННЫЙ. В течение многих лет Беклог Продукта был приоритезированным списком. Но приоритезация – лишь частный случай упорядоченности. Современная редакция Скрама требует от Владельца Продукта проставлять каждому элементу Беклога (PBI) свой порядковый номер, тем самым избегая синдрома «для нас все фичи важные» и «нам все нужно сделать. Подробнее об этом изменении в Скраме можно почитать в статье «Ordered, not Prioritized».
- Беклог Продукта является ЕДИНСТВЕННЫМ источником требований для продукта. Что это значит? Не должно быть никаких дублирующих Technical Debt, Defects и других Беклогов, в которых мы храним нечто, к чему хотим вернуться после, но на практике вряд ли это когда-либо произойдет. Логичнее было бы назвать такие артефакты «Never will do Backlog». Во-первых, подобные практики нарушают прозрачность и могут ввести в заблуждение Владельца Продукта, который строит план релиза исходя из Беклога Продукта. Он и не догадывается, что команда задумала грандиозный рефакторинг, план которого хранится в другом документе. Во-вторых, никто, даже CEO вашей компании, не может заставить Команду Разработки работать над требованиями, которых нет в Беклоге Продукта. Для того, чтобы это случилось, CEO должен убедить в этом сначала Владельца Продукта.
- ОТВЕТСТВЕННОСТЬ за Беклог Продукта несет один человек - Владелец Продукта. Он может делегировать те или иные активности членам команды. Иногда их называют «группой Владельца Продукта», в которую могут входить тестировщики, бизнес аналитики, разработчики и т.д. Но за все отвечает лишь один человек. Этого правило родилось из жизненной практики, ведь часто необходимо разрубить «гордиев узел» и принять быстрое бизнес решение.
- ДИНАМИЧНОСТЬ Беклога заключается в том, что он постоянно меняется и эволюционирует. Беклог Продукта – не толстая спека, которую набивают в течение нескольких месяцев бизнес аналитики, а живой артефакт. Владелец Продукта может вносить в него изменения когда угодно. Ключевое мероприятие, после которого мы ожидаем, что Беклог будет обновлен – Обзор Спринта. Мы получаем обратную связь о продукте от конечных пользователей, заказчиков и других заинтересованных лиц, и обновляем Беклог.
- Так как Беклог Продукта – единственный источник требований, но в нем хранятся элементы различного типа: ФИЧИ (features), ДЕФЕКТЫ (defects), ТРЕБОВАНИЯ (requirements), УСОВЕРШЕНСТВОВАНИЯ (enhancement), ФУНКЦИИ (functions). Беклог может включать как функциональные, так и нефункциональные требования продукта.
- Каждый элемент Беклога Продукта имеет 4 атрибута: ОПИСАНИЕ, ПОРЯДКОВЫЙ НОМЕР, ОЦЕНКУ и БИЗНЕС ЦЕННОСТЬ. С первыми двумя, вроде бы, все понятно. Что же касается оценок, то они отражают стоимость разработки и часто даются Командой Разработки в относительных величинах или «попугаях». Скрам не требует от нас использования относительных величин, но я видел мало Скрам Команд, которые бы ими не пользовались. Главная причина – люди не умеют оценивать в абсолютных величинах, поэтому стори-поинты лучше, чем часы. Что касается четвертого атрибута (бизнес ценность), то, к сожалению, лишь некоторые Владельцы Продукта пользуются им. Современный Скрам требует явно проставлять бизнес ценность для каждого Элемента Беклога Продукта (PBI). Можно пользоваться практикой Business Value Point (BVP), о которой пишет Джим Хайсмит в книге Adaptive Leadership или проставлять условные High, Medium, Low оценки для каждого элементов. Важно одно – мы хотим, чтобы между Владельцем Продукта и Командой Разработки состоялся разговор о ценности каждого элемента Беклога.
Ключ к эффективному планированию. Не все команды, к сожалению, понимают, что ключ к удачному планированию и, соответственно, к самому Спринту, лежит как раз в проведении эффективных Product Backlog Refinement встреч.
Нет ничего более болезненного для команды, чем плохо подготовленные Пользовательские Истории, с которыми она сталкивается на Планировании Спринта. Обсуждение затягивается на часы, команда погружается в бесконечные дискуссии и дебаты. Я видел такие встречи, и это ужасно. Хороший Владелец Продукта должен делать все возможное, чтоб избежать подобного сценария (Galen, Robert, Scrum Product Ownership).
Как часто нам нужно проводить PBR. В отличие от других обязательных мероприятий (Планирование, Ежедневный Скрам, Обзор Спринта, Ретроспектива), Скрам дает вам право самим решать как, когда и сколько раз проводить Product Backlog Refinement.
Готового рецепта нет, вы можете создать свой собственный. Но мы выработали хорошую, на наш взгляд, практику, которая хорошо прижилась во многих командах, с которыми мы работали. Мы рекомендуем командам посвящать 15-20 минут после Ежедневного Скрама подробному обсуждению одной истории. У всех появляется возможность заняться разведкой и до следующей встречи посмотреть на историю, покопаться в ней индивидуально, и, тем самым, подготовиться к планированию, чтобы чувствовать себя более комфортно.
Таким образом, планирование превращается в простой выбор того, что мы будем делать, и может занимать не более 10 минут. Такой подход позволяет сразу перейти к распилу историй на задачи и вовлечь всех в работу незамедлительно. Потом команда инспектирует и подстраивается соответствующим образом каждый день. При двухнедельной продолжительности спринтов у вас получится 2 часа (15 минут * 8 дней), которые вы сэкономили от планирования спринта.
Готовность элементов требований. Мы должны стремиться к тому, чтобы к моменту начала Планирования Спринта все элементы Беклога были «подготовленными» для их взятия в Спринт, чтобы избежать неприятных сюрпризов:
Требования Беклога Продукта, которые можно выполнить в течение одного Спринта считаются “Подготовленными” для следующего Планирования Спринта. Элементы Беклога Продукта обычно приобретают эту степень прозрачности при помощи описанных активностей по детализации (Scrum Guide, 2013).
ОК, это понятно. А теперь вопрос, насколько тщательно следует причесывать требования? Ведь совершенству нет предела. С одной стороны, чем больше мы потратим времени на разбор историй, тем более ясным и точным будет будущий Спринт и тем меньше рисков и неопределенностей нас ждет. С другой стороны, каждый лишний час, на который отвлекается Команда Разработки, можно считать потерей. Бесконечные статус митинги, мультизадачность – разве это не против чего мы боролись? Единственно правильного ответа нет. Мы находимся в запутанной среде. Но мне нравятся несколько моделей, которые могут помочь ответить на этот вопрос.
Кривая стоимости. Эту модель я обнаружил в книге «Real Life Scrum» (оттуда же украл и картинку).
Автор книги удачно подметил, что цена, которую мы платим за встречи и анализ требований возрастает примерно пропорционально времени. С другой стороны, цена имплементации требований падает нелинейно. Существует некая точка, в которой есть пересечение и после которой общая цена начинает резко расти. Наша задача как раз и заключается в том, чтобы найти эту пресловутую точку. Как это сделать? В этом может помочь вторая модель.
Правило 70/30. Эта модель предлагает Роберт Гален, и я не раз убеждался в ее правдивости. Представьте, что 100% - это абсолютно вылизанная и проанализированная история, от которой не стоит ждать каких-либо сюрпризов. Роберт предлагает подготавливать истории примерно на 70%.
Я рекомендую определять историю лишь на 70%. У нас должны оставаться открытые вопросы, сомнения и определенная доля неизвестности. Просто не слишком много, и не в самых критических местах. Когда же заполняются остальные 30%? Во время Спринта. Команды устраняют их, выполняя работу. Это и является одной из главных причин, почему Владелец Продукта должен быть доступен для Команды в течение всего Спринта (Galen, Robert, Scrum Product Ownership).
Примеры определения готовности элемента Беклога Продукта. Скрам - гибкий фреймворк и не отдает предпочтения какому-либо формату для определения элементов Беклога. Но большинство команд используют Пользовательские Истории. Поэтому я приведу пример готовности, используя этот формат:
- История ясно написана и имеет ни менее 5 приемочных критериев.
- История не превышает 8 Story Points.
- Историю обсуждали на нескольких PBR встречах, и она понятна команде.
- Команда понимает как функциональные, так и нефункциональные части истории.
- Определены все зависимости от других историй и это отражено в Беклоге Продукта.
- История имеет определенную бизнес ценность для конечных пользователей и поддерживает Цель Спринта.
Чем еще Скрам Мастер может помочь Владельцу Продукта и Команде Разработки? Не надо объяснять, как разработчики «любят» лишние встречи. И пусть. Это удел менеджеров. Дайте возможность разработчикам максимально фокусировано проводить встречи и заниматься их любимым делом - разработкой. Заранее распечатайте на бумаге истории, которые вы хотите обсудить и раздайте по экземпляру каждому. Настройте связь, видео, звук, подготовьте помещение, стикеры, маркеры, флип-чарты и остальные необходимые инструменты. Совершенствуйте свои навыки в фасилитации и коучинге. Избавьте свою команду от рутины, и команда ответит вам благодарностью и доверием.
