PI Planning

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

Когда компания растет, по мере ее роста увеличивается количество команд, а проблемы с синхронизацией множатся буквально на глазах. В такой ситуации с каждым днем становится все сложнее придерживаться единого вектора движения, развития продуктов и, конечно, все проблематичней договариваться. Помимо этого растет аппетит к размеру инкремента и горизонту планирования. В поисках готового решения крупные компании чаще всего смотрят в сторону планирования программного инкремента (PI Planning) из SAFe. Так как это очень хорошо описанный фреймворк, многие начинают пользоваться его элементами самостоятельно. Те элементы, которые вызывают сложности или трудозатратны, зачастую пытаются адаптировать под себя. Надо помнить, что все элементы не случайно описываются в фреймворке и являются критически важными для достижения целей PI Planning.

PI Planning проводится для определения целей программного инкремента (PI Objectives), формирования доски программы (Program Board) и карты рисков (Program risks).

Обычно PI Planning это 2х дневное мероприятие, в ходе которого происходит планирование одного релизного поезда (Agile Release Train - ART) в одно время и в одном месте, со всеми необходимыми участниками - при участии всех команд ART.

Стандартная подготовка к PI Planning продолжается 2 недели. Даже если пытаться «уложить» ее в 1 день планирования, то предыдущий день будет посвящен завершению работ прошлой итерации, а следующий – старту спринта новой итерации. При этом подготовка к планированию на квартал всё ещё требует длительных и когнитивно емких активностей. Как следствие, сложно готовить бэклог, не ясно завершена задача, или потребуется доработка. Ситуация, в целом, стрессовая. Помимо этого возникают нарекания к командам разработки, а именно в отсутствии прогресса, так как у команд нет времени анализировать и улучшать процесс (некогда точить пилу, нужно пилить). А при отсутствии буфера (запаса прочности) вероятность попадания в прогноз сильно снижается. По факту PI Planning не достигает целей, а время не экономится, а тратится впустую.

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

Особенно дорого может стоить ошибка, когда при первом PI planning не выделяется время на работу с рисками в явном виде. Это может приводить к нескольким вариантам развития событий:

• Команды разработки слишком много берут в работу, и после второго спринта план признается неактуальным. Низкий уровень уверенности в выполнении плана все равно приводит к необходимости переделывать (с рисками невыполнения вовремя). 
• Команды разработки слишком мало берут в работу, перезакладывая риски, что в скрытом виде может быть отражено на доске зависимостей. Визуализация рисков помогает избежать ситуаций, когда в середине квартала срочно нужно допланировать скоуп части команд.

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

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

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