Как устроен метод набегающей волны и почему он помогает сохранять время разработчиков и деньги клиентов — в материале IT-World.
Самый дорогой план — это тот, в который никто не верит, но который все согласовали. Правда, ещё дороже выходит — когда плана вообще нет. Большинство провалов в планировании сводится к двум: к детальной фикции и к бесплановому хаосу. Между ними есть третий путь — метод набегающей волны. Его главная сила в том, что это не техника, а способ мышления о неопределённости. И именно поэтому он универсален — работает и в бэклоге одной Scrum-команды, и в масштабе SAFe-поезда из десятка команд. А там, где его игнорируют, любой фреймворк рано или поздно превращается в каргокульт.
Как устроен метод набегающей волны и почему он помогает сохранять время разработчиков и деньги клиентов, рассказывает руководитель отдела разработки в 1С-Битрикс Алексей Кирсанов.
Почему я называю это способом мышления, а не техникой
Когда речь заходит о методе набегающей волны, его обычно подают как технику работы со списком задач: что-то расписать детально, что-то крупно, постепенно дополнять. Это верно, но только наполовину — техника здесь лишь видимая часть. За ней стоит более общая идея — определённый способ работать с неопределённостью будущего.
Когда мы планируем работу на горизонте дольше одного спринта, мы оказываемся в одной из двух ситуаций.
Первая — когда мы точно знаем точку Б, в которую хотим попасть, точно знаем целевое состояние и уверены, что оно не поменяется. Здесь имеет смысл расписать всю дорогу детально — полный план себя оправдает. Правда, не очень понятно, зачем нам в этом случае спринты, но эту мысль мы обсудим дальше.
Вторая ситуация устроена сложнее, и внутри неё есть два разных варианта. В первом точка Б нам изначально неизвестна: есть общее направление, есть туманное понимание того, куда мы хотим попасть, но какая эта точка конкретно — выяснится только по мере движения. Во втором точка Б известна, но с большой вероятностью изменится по ходу дела — потому что меняется внешний контекст или потому что меняется наше собственное понимание того, что должно получиться в итоге. Но вне зависимости от того, первый вариант или второй - суть в том, что мы не можем положиться на эту точку Б.
Эти две ситуации требуют разного отношения к планированию, и главная ошибка — применять к ним одни и те же подходы. Для первого случая работает проектный подход: можно строить иерархическую структуру работ и делать полную декомпозицию ещё на этапе планирования. Во втором — этот подход не работает. Здесь больше неизвестного, чем известного: на старте — много конкурирующих идей, ответы проявляются только по мере движения вперёд. Именно для второго случая и нужен метод набегающей волны.
Когда метод набегающей волны не применяют, остаются два плохих подхода.
Первый — действовать как в первой ситуации: строить полный детальный план. Такой план рассыпается ещё по дороге — потому что точка Б либо была известна лишь приблизительно и план ведёт нас не туда, либо изменилась по ходу дела вместе с контекстом или нашим пониманием. Команда план переделывает, и в какой-то момент сам процесс планирования становится фикцией: люди составляют план, не веря в него, и отчитываются по тому, что записано на доске, а не по тому, что реально происходит. Это и есть каргокульт планирования.
Второй плохой подход — отказаться от планирования вовсе и разбираться по ходу дела. Без понимания того, что будет за текущим шагом, нельзя принимать грамотные решения по самому шагу. Любой шаг в разработке можно сделать по-разному — с разной степенью архитектурности, с разными подходами. Какое решение правильное — зависит от того, что будет дальше. Без этого контекста мы выбираем архитектурные решения вслепую и через месяц-полтора переделываем то, что только что сделали.
У отказа от планирования есть и вторая сторона, которую часто недооценивают — мотивация. В творческих специальностях, к которым относится практически вся IT-работа, эффективность сотрудника равна произведению компетенции на мотивацию. Именно произведение, а не сумма. Если один из сомножителей около нуля, итоговая эффективность тоже около нуля. И когда сотрудник делает свою работу, не понимая, ради какой большой цели и какой ценности — мотивация неизбежно падает. Полный отказ от планирования одновременно бьёт по качеству принимаемых решений и по мотивации.
Как это устроено
Логика простая.
Ближайшие шаги — то, что команда возьмёт в работу прямо сейчас или в самом ближайшем будущем, — расписаны детально, декомпозированы, готовы к работе.
Чем дальше шаг отстоит от текущего момента, тем он более крупноблочный: мы знаем направление, но не вкладываемся в его детальную проработку заранее. По мере движения мы постепенно додекомпозируем то, что приближается к зоне ближайших спринтов. Волна планирования набегает вместе с движением работы.
У этого подхода три преимущества:
- При сдвиге цели нужно переписать одну-две крупные позиции, а не пересматривать сотни задач.
- Ближайшие шаги детализированы достаточно, чтобы по ним можно было принимать грамотные решения.
- И у команды остаётся общая картина того, куда движется работа.
Ниже я разберу три практики работы со списком задач и с планированием, в которых этот способ мышления находит применение.
Применение 1: бэклог Scrum-команды
Это самый простой случай. Хороший бэклог продукта в Scrum по определению устроен по принципу набегающей волны.
- Сверху лежат подробно описанные пользовательские истории — единицы работы, готовые к взятию в спринт, с критериями приёмки.
- Ниже — эпики, ещё не разложенные на истории.
- Ещё ниже — инициативы, обозначающие крупные направления.
Если бэклог устроен иначе — либо весь детализирован, либо весь представлен крупными мазками — это симптом проблемы. В полностью декомпозированном бэклоге владелец продукта и команда тонут в задачах, которые теряют актуальность быстрее, чем их успевают разобрать. Полностью крупноблочный бэклог делает невозможным нормальное планирование спринта.
В этом примере набегающая волна выглядит очевидной. Сложнее становится тогда, когда тот же принцип нужно применить не к одному списку задач одной команды, а к плану работы нескольких команд сразу.
Применение 2: PI-планирование в SAFe
SAFe, или Scaled Agile Framework, — это фреймворк масштабирования Agile, в котором несколько команд объединяются в Agile Release Train (ART) и работают синхронизированно над общим продуктом. Раз в десять-двенадцать недель в ART проводится PI Planning — двухдневное событие, на котором команды совместно планируют следующий Program Increment. На PI Planning составляется доска планирования: команды берут фичи, фиксируют зависимости друг с другом, формируют обязательства на инкремент.
Когда контекст устойчивый, эта схема работает. Команды действительно могут законтрактоваться на десять-двенадцать недель и выдержать обязательства. В таком контексте SAFe работает хорошо.
Контекст бывает изменчивым по разным причинам: быстрое внедрение AI-инструментов, которое каждые несколько недель открывает новые технические возможности; меняющееся законодательство; нестабильный рынок, на котором продуктовые гипотезы меняются ежемесячно. В таких условиях план на десять-двенадцать недель — это уже самообман.
Можно действовать по букве фреймворка: всё равно провести PI Planning, всё равно зафиксировать обязательства на двенадцать недель, всё равно сделать вид, что план реалистичен. План развалится через три-четыре недели, команды будут работать по факту, отчитываться будут по доске, и всё это будет называться SAFe. Именно это и есть каргокульт.
Классическое PI-планирование на десять-двенадцать недель в условиях высокой изменчивости — каргокульт по определению. Подчеркну: не сам SAFe — он создавался под определённый класс задач, и под этим классом работает хорошо. И не PI-планирование как таковое — в устойчивом контексте оно работает. А вот в условиях высокой изменчивости грамотная работа с SAFe — это его частичное и осознанное нарушение. Не отказ от фреймворка, а адаптация под реальность. Альтернатива устроена так.
Метод набегающей волны применяется к самому PI-планированию. На ближайший отрезок поезда — на четыре–шесть недель, возможно, до одного из ближайших системного демо — команды планируют детально, как в классическом SAFe: берут фичи, проявляют зависимости, фиксируют обязательства. Это та часть инкремента, в которую мы реально верим.
Оставшаяся часть PI планируется крупноблочно: только крупные эпики и принципиальные зависимости, без жёстких обязательств. После системного демо проводится следующая итерация планирования: детализируем следующий отрезок, при необходимости пересматриваем дальний горизонт. Конечно, такие планирования должны быть короче двух дней.
Возражение «но это нарушает SAFe» здесь почти неизбежно. Я отвечаю на него через Agile-манифест. Манифест говорит, что люди и взаимодействие важнее процессов и инструментов. Это не значит, что процессы не важны. Это значит, что они существуют, чтобы помогать достигать результата, а не наоборот. Если в конкретном контексте конкретный элемент процесса перестаёт работать, его правильно осознанно адаптировать, а не делать вид, что он работает.
Стоит добавить ещё одно наблюдение. Когда мы применяем набегающую волну к PI-планированию, мы детально планируем месяц-полтора, потом проводим следующее планирование, потом ещё одно — и так дальше. Планирование перестаёт быть дискретным событием раз в квартал и становится регулярным занятием. Становится потоком планирования методом набегающей волны. Возможно, это направление, в котором SAFe и подобные ему фреймворки будут естественно эволюционировать в условиях высокой изменчивости и AI-трансформаций: PI Planning постепенно перестаёт быть большим событием раз в квартал и превращается в процесс. Это отдельная тема, выходящая за рамки этой статьи.
Применение 3: продуктовая дорожная карта
Третий пример — на уровне продукта, а не команды. Продуктовые дорожные карты часто строят через три горизонта: Now, Next, Later. То, что в работе сейчас. То, что следующее на очереди и проработано до уровня готовых задач. И то, что обозначено направлением, без детализации.
Это и есть набегающая волна, только под другим названием. Now — детально, Next — средне, Later — крупноблочно. По мере того как Next переходит в Now, его додекомпозируют, а из Later отбирают то, что становится Next. Та же логика, что и в бэклоге команды, но на уровне продуктовых решений.
Когда менеджер продукта пытается составить детальную дорожную карту на год вперёд в условиях изменчивого рынка, он делает то же самое, что руководитель ART, который пытается зафиксировать десятинедельные обязательства в изменчивой среде. Это не планирование, это фикция.
Главное
Метод набегающей волны — это не приём из учебника по управлению. Это способ работать с неопределённостью будущего: ближние шаги мы понимаем лучше, дальние — хуже, и потому работать с ними нужно по-разному.
Из этого мышления вырастают конкретные практики — устройство бэклога в Scrum, адаптация PI-планирования в SAFe, формат продуктовой дорожной карты. Я думаю, что именно это мышление, а не сами практики, отличает грамотную работу с фреймворками от каргокульта. Если оно есть, фреймворк помогает. Если его нет, любой фреймворк, даже самый продуманный, со временем превращается в фикцию и каргокульт.