Professional Scrum Master (PSM)

Professional Scrum Master (PSM)
Professional Scrum Master (PSM)

понедельник, 22 сентября 2014 г.

Ищем гребешок для причесывания Беклога


Скрам Гайде версии 2011 года присутствовал термин Grooming. Это неофициальная встреча Скрама, во время которой Команда Разработки вместе Владельцем Продукта старательно «причесывают» Беклог, готовя его к следующим Спринтам. В последней версии встреча не изменила своего назначения, просто сменила вывеску и теперь называется Product Backlog Refinement (PBR).
Зачем? Откройте английский жаргонный словарь, и вы сразу поймете, почему многие англичане раньше смущенно качали головой.
Тем не менее, давайте считать, что во время Product Backlog Refinement (PBR) Беклог, как и прежде, отправляется в парикмахерскую для того, чтобы команда и Владелец Продукта могли:
  • Добавить, убрать или разбить Элементы Беклога Продукта (PBI).
  • Уточнить или дать новые оценки.
  • Изменить порядок следования элементов Беклога Продукта.
  • Обсудить и прояснить требования.
Поддержка Беклога Продукта – это активность по добавлению деталей, оценок и упорядочивания элементов в Беклоге Продукта. Это непрерывный процесс, во время которого Владелец Продукта и Команда Разработки работают над требованиями Беклога Продукта. Во время обработки требования проверяются и пересматриваются. Скрам Команда решает, как и когда должна производиться Поддержка Беклога Продукта. Обычно это занимает не более 10% времени Скрам Команды. Однако Владелец Продукта в любое время может изменить требования на свое усмотрение (Scrum Guide, july 2013).
PBR одна из самых загадочных встреч, и у команд возникает много вопросов. Мы постараемся разобраться в этом, но для этого сначала давайте пробежимся по определению Беклога Продукта.
Беклог Продукта. Последняя версия Скрам Гайда дает нам определение:
Беклог Продукта – это УПОРЯДОЧЕННЫЙ список всего, что может быть нужным в продукте, он является ЕДИНСТВЕННЫМ источником требований для любых изменений, которые может потребоваться внести в продукт. ОТВЕТСТВЕННОСТЬ за Беклог Продукта несет Владелец Продукта, включая его содержимое, доступность и упорядочение.
Беклог Продукта никогда не является полным. Начальная версия этого документа содержит только первоначально известные и наиболее понятные требования. Беклог Продукта постоянно обновляется по мере обновления самого продукта и среды, в которой он разрабатывается. Беклог Продукта является ДИНАМИЧЕСКИМ, постоянно изменяющимся для соответствия требованиям продукта, его конкурентоспособности и пригодности. Беклог Продукта существует ровно до тех пор, пока существует и сам продукт. Беклог Продукта содержит все ФИЧИ, ФУНКЦИИ, ТРЕБОВАНИЯ, УСОВЕРШЕНСТВОВАНИЯ и ДЕФЕКТЫ, то есть те данные, которые и определяют изменения, необходимые в следующих релизах продукта. Каждому Элементу Беклога Продукта присваиваться ОПИСАНИЕ, ПОРЯДКОВЫЙ НОМЕР, ОЦЕНКА и ЦЕННОСТЬ.
backlog.png
Я выделил некоторые слова большими буквами. Давайте быстро пробежимся по ним:
  • УПОРЯДОЧЕННЫЙ. В течение многих лет Беклог Продукта был приоритезированным списком. Но приоритезация – лишь частный случай упорядоченности. Современная редакция Скрама требует от Владельца Продукта проставлять каждому элементу Беклога (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 дней), которые вы сэкономили от планирования спринта.
pbr_collage.png
Готовность элементов требований. Мы должны стремиться к тому, чтобы к моменту начала Планирования Спринта все элементы Беклога были «подготовленными» для их взятия в Спринт, чтобы избежать неприятных сюрпризов:
Требования Беклога Продукта, которые можно выполнить в течение одного Спринта считаются “Подготовленными” для следующего Планирования Спринта. Элементы Беклога Продукта обычно приобретают эту степень прозрачности при помощи описанных активностей по детализации (Scrum Guide, 2013).
ОК, это понятно. А теперь вопрос, насколько тщательно следует причесывать требования? Ведь совершенству нет предела. С одной стороны, чем больше мы потратим времени на разбор историй, тем более ясным и точным будет будущий Спринт и тем меньше рисков и неопределенностей нас ждет. С другой стороны, каждый лишний час, на который отвлекается Команда Разработки, можно считать потерей. Бесконечные статус митинги, мультизадачность – разве это не против чего мы боролись? Единственно правильного ответа нет. Мы находимся в запутанной среде. Но мне нравятся несколько моделей, которые могут помочь ответить на этот вопрос.
 Кривая стоимости. Эту модель я обнаружил в книге «Real Life Scrum» (оттуда же украл и картинку).
pbr_curve.png
 Автор книги удачно подметил, что цена, которую мы платим за встречи и анализ требований возрастает примерно пропорционально времени. С другой стороны, цена имплементации требований падает нелинейно. Существует некая точка, в которой есть пересечение и после которой общая цена начинает резко расти. Наша задача как раз и заключается в том, чтобы найти эту пресловутую точку. Как это сделать? В этом может помочь вторая модель.
Правило 70/30. Эта модель предлагает Роберт Гален, и я не раз убеждался в ее правдивости. Представьте, что 100%  - это абсолютно вылизанная и проанализированная история, от которой не стоит ждать каких-либо сюрпризов. Роберт предлагает подготавливать истории примерно на 70%.
Я рекомендую определять историю лишь на 70%. У нас должны оставаться открытые вопросы, сомнения и определенная доля неизвестности. Просто не слишком много, и не в самых критических местах. Когда же заполняются остальные 30%? Во время Спринта. Команды устраняют их, выполняя работу. Это и является одной из главных причин, почему Владелец Продукта должен быть доступен для Команды в течение всего Спринта (Galen, Robert, Scrum Product Ownership).
Примеры определения готовности элемента Беклога Продукта. Скрам - гибкий фреймворк и не отдает предпочтения какому-либо формату для определения элементов Беклога. Но большинство команд используют Пользовательские Истории. Поэтому я приведу пример готовности, используя этот формат:
  1. История ясно написана и имеет ни менее 5 приемочных критериев.
  2. История не превышает 8 Story Points.
  3. Историю обсуждали на нескольких PBR встречах, и она понятна команде.
  4. Команда понимает как функциональные, так и нефункциональные части истории.
  5. Определены все зависимости от других историй и это отражено в Беклоге Продукта.
  6. История имеет определенную бизнес ценность для конечных пользователей и поддерживает Цель Спринта.
 Чем еще Скрам Мастер может помочь Владельцу Продукта и Команде Разработки? Не надо объяснять, как разработчики «любят» лишние встречи. И пусть. Это удел менеджеров. Дайте возможность разработчикам максимально фокусировано проводить встречи и заниматься их любимым делом - разработкой. Заранее распечатайте на бумаге истории, которые вы хотите обсудить и раздайте по экземпляру каждому. Настройте связь, видео, звук, подготовьте помещение, стикеры, маркеры, флип-чарты и остальные необходимые инструменты. Совершенствуйте свои навыки в фасилитации и коучинге. Избавьте свою команду от рутины, и команда ответит вам благодарностью и доверием.
pbr_prep.jpg