Одно из препятствий на пути к готовому — слишком много изменений во время спринта. Стефани Окерман говорила об этом в своем предыдущем материале.

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

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

Так как нам одновременно и реагировать на изменения, и предусматривать срочность, и приносить рабочую ценность?

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

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

Сложно найти баланс между срочностью и поставками. Нет идеальной формулы. Командам приходится находить рабочие методы самостоятельно.

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

1. Когда в бэклог спринта добавляется новая работа

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

Вот несколько идей, как уладить срочные приоритеты, не соответствующие цели спринта.

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

2. Из-за плохого уточнения бэклога растет количество работы во время спринта

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

  • Попробуйте привлечь всю скрам-команду к участию в уточнении бэклога продукта. Участие всех разработчиков может дать вам два существенных преимущества: 1) Каждый станет частью дискуссии о том, что и почему мы строим, а это уменьшит количество недоразумений в дальнейшем. 2) Каждый сможет сделать свой взнос в декомпозицию и упорядочение элементов бэклога продукта, а значит, больше шансов иметь в итоге элементы правильного размера с уменьшенными взаимными зависимостями.
  • Цель уточнения состоит в том, чтобы довести элементы продуктового бэклога до необходимого для работы уровня детализации. Вы можете формализовать этот процесс, добавив в него определение готового. Нам нравится определение Романа Пихлера: он называет готовое “понятным, реализуемым и подлежащим проверке”. Некоторые команды создают визуальную доску, на которой продемонстрировано уточнение элементов бэклога продукта до состояния готовых.
  • Скрам-мастер коучит Продакт Оунеров выполнять свою роль и придерживаться обязательств по отношению к команде. Владелец продукта отвечает за максимизацию ценности продукта и за работу разработчиков. Уточнение необходимо, чтобы ценность продукта стала понятной и достижимой. Владелец продукта не должен выполнять всю работу по уточнению бэклога сам. Но если мы замечаем симптомы этой проблемы, стоит больше привлекать Продакт Оунера к Product Backlog Refinement.

3. Когда “Как” не обсуждается на планировании спринта

Бэклог спринта состоит из отобранных элементов бэклога продукта и плана их поставки. Это и правда свободный план с деталями, которые должны проявиться во время спринта. Но это не повод плохо планировать спринт. Обсуждение всяческих “как” помогает разработчикам лучше спрогнозировать количество работы на спринт. Это также помогает обнаружить зависимости, пробелы в навыках или знаниях, а также другие препятствия. Все это может убить спринт, если не уделить этому внимания.

  • Скрам-мастер должен подчеркивать ценность планирования спринта. Команда легко теряет видение цели этого события, порой всем нам нужно напоминание. Можно попросить члена команды начать мероприятие по обьявлению его цели и ожидаемых результатов. Периодически спрашивайте, двигаемся ли мы в направлении цели. В конце события спросите, все ли согласны, что мы достигли цели. Также можете спросить, какие препятствия предвидят члены команды и с чем им может понадобиться помощь.
  • Скрам-мастер может помочь команде эффективнее использовать таймбоксы. Если команда не успевает проговорить “как” в пределах таймбокса, разбейте его на два, чтобы помочь им сфокусироваться на обоих аспектах бэклога спринта. Метаться между “что” и “как” нормально, просто помогите команде сбалансировать этот процесс. Если команда заканчивает планирование спринта намного быстрее заложенного времени, но не обсудила “как” достаточно глубоко, используйте открытые вопросы, чтобы развить эту часть дискуссии. Вроде: «Это большой элемент. Как его разбить на более мелкие, которые потом склеим в один?», «Есть ли у нас все нужное, чтобы вовремя сделать готовый инкремент и достичь цели спринта?», «Какие зависимости будут определять, как мы будем делать поставки к цели спринта?»
  • Разделите элементы бэклога продукта на задачи.  Порой команды обсуждают “как”, но все еще не до конца понимают, о чем идет речь, до самого конца планирования спринта. Фасилитируя событие, вы можете попробовать визуализировать часть разговора на доске. Спросите: может, кто-то может прорисовать то, что объясняет? Предложите команде потом использовать эти визуалы и разбить элементы бэклога продукта на задачи на скрам-доске.

Все эти навыки делают вас по-настоящему хорошим скрам-мастером.

Научиться этому, как и многим ценным фасилитациям, можно на углубленном тренинге PSM II

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

Источник: scrum.org.