Блог
Что делать, когда приходят изменения Фичи во время Интервала Планирования?

Что делать, когда приходят изменения Фичи во время Интервала Планирования?

11 октября 2024

«Смысл жизни – в изменениях…» — китайская мудрость

Интервалы Планирования обычно длятся от 8 до 12 недель, и за такой промежуток времени высока вероятность возникновения изменений в нашем современном изменчивом мире. В результате мы сталкиваемся с изменениями Фич в рамках уже начатого Интервала Планирования. Это реальный сценарий, с которым важно уметь работать. В этой статье мы рассмотрим 2 уровня изменений:

Изменения Фич на уровне Поезда (Agile Release Train, ART) в рамках Интервала Планирования и варианты решения
Изменения Историй на уровне Команды в рамках Итерации внутри Интервала Планирования и варианты решения

Изменения Фичи на уровне Поезда

Во время мероприятия «PI Планирование» команды Релизного Поезда берут на себя обязательства по достижению сформулированных ими целей на Интервал Планирования.

«Цели Интервала Планирования (PI) — это краткое изложение бизнес-целей и технических целей, которые каждая Agile команда или поезд целиком намерены достичь в предстоящем PI.» (глоссарий SAFe)

«Интервал Планирования — это временной интервал на основе каденции, в течение которого Релизный Поезд Agile (ART) непрерывно доставляет ценность клиентам в соответствии с Целями на Интервал Планирования.» (глоссарий SAFe)

Основная задача SAFe – помочь организациям построить бизнес-гибкость, поэтому во время PI Планирования фреймворк не рекомендует жёстко фиксировать Фичи или Истории на предстоящий интервал. Единственное, что фиксируется – это цели на Интервал Планирования (PI Objectives). На мероприятии каждая команда пишет свои цели, исходя из своего понимания и уверенности, что они могут сделать, а что нет. При этом Владельцы Бизнеса, со своей стороны, обсуждают цели с командами, принимают их и проставляют им ценность, исходя из понимания, что для организации более ценно с точки зрения развития бизнеса, технологий и выполнения стратегии в целом. Таким образом, основным результатом мероприятия «PI Планирование» являются «согласованные» не Фичи или Истории, а именно Цели. И это действительно то, что не должно меняться. В идеале не должно.

Давайте рассмотрим несколько сценариев на уровне Поезда.

Сценарий 1. Изменения Фичи не требуют каких-то дополнительных действий

Когда наши клиенты сталкиваются с необходимостью внести изменения в Фичи во время уже начатого Интервала Планирования, я прошу их ответить на 2 группы вопросов:

1. Насколько эти изменения меняют цели на интервал, и если нет, то меняется ли достижимость существующих целей?

Напоминаю, что Фичи и Истории у нас жёстко не фиксируются, при этом цели на Интервал Планирования остаются неизменными.

Если «приходит» новая Фича взамен существующей или происходят изменения существующей Фичи, но при этом эти изменения не влияют на вероятность достижения целей, то можно рассматривать эти изменения как уточнение требований. Во время PI Планирования мы изначально пишем высокоуровневые цели таким образом, чтобы в дальнейшем в процессе работы у команд и Поезда была возможность уточнять движение к этой цели.

Одна из ценностей SAFe — прозрачность, поэтому изменение Фичи не должно производиться кулуарно, непрозрачно. Если команды работают над сложным, комплексным решением, то скорее всего между ними будут существовать зависимости. При этом Релизный Поезд (ART) несёт ответственность за достижимость совокупности всех целей, которые все команды взяли на Интервал Планирования. Таким образом, любые уточнения должны быть абсолютно прозрачны для всех участников Поезда. В результате мы ожидаем, что команды разработки, команда управления продуктом и архитекторы подтвердят, что изменения не влияют на достижение целей.

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

2. Укладываются ли изменения в существующую ёмкость команд? Меняют ли уточнения или создают ли новые зависимости?

Во время Планирования Интервала команда планирует всю свою ёмкость, в рамках которой часть ёмкости резервируется на некоторые работы, которые могут возникать в течение предстоящего Интервала Планирования. Соответственно, если в Поезд (ART) или в команды «приходят» какие-то небольшие задачи, под которые у команд заранее забронирована резервная ёмкость, то тоже всё нормально. То есть цели остаются достижимыми, мы просто делаем что-то ещё без ущерба для них.

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

Для того, чтобы эффективно работать с подобными ситуациями, важно определить и заранее договориться, что обозначает «небольшая» задача. Здесь каждый Поезд должен сам для себя решить, сколько это. Для ориентира мы предлагаем говорить о том, что небольшая задача – это История на +/- 8 сторипоинтов, то есть максимальный размер Истории, которая не требует дальнейшей декомпозиции.

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

Вывод: Если изменяются Фичи во время Интервала Планирования, но при этом соблюдаются одновременно два выше описанных условия, то какие-либо дополнительные действия не требуются:
1. Если изменения Фичи не влияют на достижимость Цели на Интервал Планирования
2. Если изменения Фичи укладываются в ёмкость каждой команды (существующие возможности команд, зависимости, учитывая другую работу, взятую на Интервал Планирования)

Сценарий 2. Изменения Фичи требуют отмены Интервала и проведения PI-Перепланирования

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

Что такое отмена интервала?

Мы должны подвести итоги интервала, то есть провести мероприятие Инспект-Адапт
Мы должны обсудить новый беклог Фич, которые мы выносим на внеочередное PI Планирование
Мы проводим внеочередное PI Планирование
Мы пишем новые цели на Интервал

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

Сценарий 3. Изменения Фичи требуют дополнительных действий, без проведения PI-Перепланирования

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

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

Внутри Поезда мы отдельно договариваемся и создаём политику относительно «прилетающих» изменений Фич в течение Интервала Планирования, которая состоит из совокупности 4-х обязательных условий:

Если «прилетают» существенные изменения в Фиче или новая Фича, то команда может написать только ОДНУ дополнительную цель в течение интервала. Дополнение второй и далее дополнительных целей не допускается.
Эта цель пишется командой, и команда не имеет права начать работать по ней без публикации этой цели на всех внутри Поезда. При этом другие команды или лидеры Поезда могут поднять вопрос о необходимости обязательного проведения PI перепланирования.
Владелец Бизнеса должен проставить до начала работы по ней ожидаемую ценность для этой новой цели так же, как это происходит во время 2-го прорыва PI Планирования.
Новая цель всегда рассматривается как «Цель без обязательств» («Без уверенности»), при этом имеющиеся цели не меняются.

Таким образом, когда приходит новая Фича, сначала продуктовые лидеры, потом команда разработки обсуждают изменение беклогов и пишут не больше одной новой цели для своей команды на Интервал Планирования. Дальше эта цель публикуется, обязательно рассматривается всеми командами в Поезде, чтобы не было никаких неожиданных зависимостей или рисков в результате корректировок. Если дополнительные риски и/или зависимости не выявлены, то мы переходим на следующий шаг. Уже в рабочем порядке (поскольку мы не делаем PI-Перепланирование) Владелец Бизнеса ставит ожидаемую ценность по новой цели по 10-бальной шкале. И только после этого команда может браться за работу.

Но здесь возникает совершенно логичный вопрос: «Но что же делать со списком целей на Интервал Планирования, которые были взяты Поездом в результате мероприятия PI Планирования? Можно ли какие-то цели удалять?»

Здесь у нас достаточно строгое правило: если мы не делаем PI-Перепланирование, то мы не имеем права трогать те цели, которые команда взяла на Интервал Планирования.

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

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

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

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

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

В рассматриваемом варианте мы сэкономили дополнительные издержки на проведение PI-Перепланирования за счет снижения качества планирования – взятия внеплановой работы. И мы это отразили в метрике. Мы сохранили цели, которые были, и поэтому далее на мероприятии Инспект-Адапт в конце Интервала Планирования мы обсудим, почему эта ситуация произошла и как нам избежать её повторения в дальнейшем.

Как избежать изменения Фич внутри Интервала Планирования в принципе?

На сегодняшний день в большинстве организаций продолжительность Интервала Планирования при двухнедельных итерациях составляет 10 недель (SAFe рекомендует продолжительность от 8 до 12 недель).

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

В результате своих наблюдений вы можете обнаружить, что:

У вас регулярно возникают новые Фичи или серьёзные изменения во время Интервала Планирования
На самом планировании интервала командам крайне сложно договориться о том, какие Истории они возьмут в последние итерации этого интервала

В этом случае вам серьёзно стоит рассмотреть сокращение продолжительности интервала. Для вас может подойти интервал до 8 недель, может быть, до 6 недель, а может быть, вообще до 2х итераций, как, собственно, один из наших клиентов сделал.

Я также вполне допускаю, что при высокой динамике и относительно простых продуктах, в кризисных сценариях или в ситуациях, где очень много инновационной работы, кому-то будет приемлемо проводить межкомандное планирование, то есть PI Планирование, даже на 1 итерацию. Безусловно, такой вариант несёт дополнительные серьёзные издержки. Именно поэтому очень важно определить оптимальную динамику именно вашего бизнеса и/или продукта. И исходя из этой динамики уже настраивать продолжительность интервала.

Я бы рекомендовал устанавливать продолжительность Интервала Планирования от 2х Итераций, иначе вы получите достаточно высокие издержки. Повторюсь, что если вы только переходите на SAFe в своей организации, то начинайте с рекомендованной продолжительности Интервала Планирования от 8 до 12 недель, и далее уже смотрите, какая именно продолжительность подойдёт под динамику вашего бизнеса.

Изменения на уровне команды

На уровне команды нужно различать, с одной стороны, Беклог Команды на Итерацию (или Беклог Спринта), и, с другой стороны, Беклог Команды на Интервал Планирования, (который является аналогом Беклога Продукта в Scrum гайде).

Беклог команды на Интервал Планирования включает те Истории, которые мы предварительно «набираем» на ближайшую перспективу (Интервал).

Беклог команды на Итерацию фиксирует Цель Итерации и Истории, которые команда сказала, что сделает, чтобы достичь этой цели.

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

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

Когда мы уточняем Истории внутри Итерации, то могут возникать разные сценарии:

Сценарий 1: уточнение Истории не влияет на вероятность достижения Цели Итерации.
Сценарий 2: уточнение Истории делает Цель Итерации недостижимой или неактуальной.

В SAFe цели команды на Итерацию не разделяются на цели с уверенностью или цели без уверенности. На Планировании Итерации команда берёт на себя ответственность за достижение какой-то определённой Цели Итерации (или нескольких Целей Итерации).

Если уже в рамках Итерации возникают изменения Истории/ий, но при этом они не оказывают влияние на выполнение Цели Итерации, то в этом сценарии работа над Историей продолжается в рабочем порядке. В этом 1-м сценарии не требуется никаких дополнительных действий.

Если во время Итерации команда понимает, что выполнение Истории/ий не приведёт к достижению Цели Итерации, то Владелец Продукта отменяет Итерацию и команда заново планирует Итерацию. В этом случае мы должны подвести итог. Если такая отмена происходит в Скрам команде (не все команды SAFe используют Скрам), то необходимо сделать следующие шаги:

Провести Обзор Итерации
Сделать Ретроспективу Итерации
Заново запланировать работу на оставшиеся дни до окончания Итерации

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

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

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

Примечание для Канбан команд

В SAFe организациях есть выделенные Канбан команды, которые работают на потоке и не используют Scrum. Это, в пёрвую очередь, касается определённого класса работ, который называется «Обслуживание и Поддержка».

У таких команд будут цели на соблюдение какой-то пропускной способности, на соблюдение метрик потока и уровней сервиса, о которых была достигнута договорённость на мероприятии «PI Планирование». Изменение Фич для Канбан команд будет означать, что, например, объём или содержание запросов более не соответствует тем обязательствам по соблюдению классов обслуживания, которые были взяты на PI Планировании. Для Канбан команд каждый отдельный запрос, который находится в рамках цели на сервис, будет оставаться плановым, хотя по своей сути его содержание всегда остается неизвестным заранее – это является спецификой работы сервисных команд.

Проблемой с выполнением целей будет, когда Канбан команда запланировала 50% своей ёмкости на поддержку, а тикетов с высоким приоритетом «прилетело» на 70% её ёмкости. Таким образом, команда уже не сможет выполнить цели по тем метрикам, под которые они подписались на PI Планировании и это может потребовать PI-перепланирования.

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

Заключение

Необходимость и частота изменений Историй внутри Итераций или Фич внутри Интервала Планирования помогают нам понять, насколько эффективно построена система Lean-Agile разработки. SAFe даёт достаточно большой инструментарий для того, чтобы настроить работу команд и Поезда для максимальной эффективности и управляемости.

Напоминаю, что одна из ценностей SAFe – это со-направленность, то есть у нас большое количество людей совместно работают для достижения стратегического продуктового видения. Чтобы достичь состояния со-направленности, нам нужно выстроить систему таким образом, чтобы 1) с одной стороны, гибко осуществлялась работа с учётом изменений требований, которые приветствуются даже на поздних стадиях разработки, как написано в Манифесте, но 2) с другой стороны, можно было увидеть перспективу, направление продуктовой разработки больше, чем на дни или даже недели, потому что мы со-направляем большое количество людей, создающих сложные продукты. Кроме этого, для бизнеса очень важно иметь представление будущего и со-направить всю организацию, не только ИТ разработку, вокруг реализации миссии бизнеса в целом.

Автор статьи: Алексей Ионов, управляющий партнер «Ионов и Партнеры»