Что такое PI планирование и как синхронизировать несколько команд разработки. Опыт внедрения PI Planning Board в SAFe

Меня зовут Павел Кондратьев, я руководитель проектов в ГК Юзтех. Управляю разработкой мобильных и веб-приложений. В статье, которую я сделал с платформой по управлению проектами WEEEK, хочу ответить на вопросы о том, как часто результат зависит от работы других команд, как синхронизировать разработку, грамотно управлять поставкой и ожиданиями в условиях постоянно изменяющихся требований. Также расскажу, как учесть риски проектов и что с ними делать.

Уже год мы работаем с крупной цифровой платформой заказчика. Начиная с первого проекта, команды, которыми я управляю, сталкиваются с ситуацией, которая тормозит процесс разработки: мы выполняем итерацию, а затем, чтобы продолжить работу, приходится ждать, пока свою часть задач выполнит команда, с которой мы планируем интегрироваться.

Гибкие методологии отлично себя показали во время реализации проектов автономной и небольшой командой. Для управления командами до 10-12 человек гибкие методологии хороши даже при решении сложных задач в enterprise-системах. В этом и сложность, ведь Agile ориентирован на небольшие команды и до определенного момента не отвечал на вопрос – что делать, если команд много?

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

Решили подключить инструмент, который бы справился с этой проблемой – PI planning Agile. Этот инструмент – часть фреймворка Scaled Agile Framework (SAFe), который расширяет стандартный Agile с его ограничениями по работе с небольшими командами до подхода управления командами, в которых 100 и более людей.

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

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

Шаг 1

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

Другая важная компонента – определение зависимостей между задачами разных команд и вехами: проводится предварительное планирование выпуска релизов.

Кстати, то, что получилось на доске, принято называть Agile release train – поездом релизов. В рамках одной компании таких поездов может быть один или несколько.

На примере выше все задачи отмечены белым, что не дает визуального представления о том, где формируется узкое место и от каких команд выстраивается зависимость. Пока понятно только то, как и какие задачи между собой связаны. Поэтому в следующем шаге нужно определить, кто ждет задачу, а кто должен её делать. Во время сессии планирования выделяется время в районе 5-10 минут, чтобы все PO и PM смогли распределить известные им задачи из бэклога на доске.

Шаг 2

После этого каждая команда за 5-10 минут должна подробно рассказать о задачах. На этом этапе могут всплыть зависимости, которые ранее не предполагались. Зависимости сразу должны быть зафиксированы фасилитатором. Задача-блокер окрашивается красным цветом.

Теперь у нас есть доска и на ней сформирована визуализация зависимостей:

Мы видим, что задачи с номерами 2, 6, 7 и 9 – это блокеры.

Любой блокер – это риск.

Поэтому попробуем в моменте понять, можем ли мы повлиять на риски, которые выявили, например, сдвинув сроки.

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

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

Справа от строки команды создаем карточки, на которых перечисляем все риски, о которых знаем на текущий момент:

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

Для начала попробуем сгруппировать риски.

Очевидно, что у нас есть три группы проблем. Одна связана с кадровыми ресурсами, вторая – с аналитикой и архитектурой, третья – инфраструктурная, допустим, нет стенда для тестирования.

Идем на доску ROAM.

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

Встреча примерно на 1,5 часа и инструмент PI-планирования позволили визуально отобразить проблемы, которые есть в кросс-зависимых командах, определить риски и решить, что с ними делать.

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

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

Нам, как руководителям проектов, использование PI planning Agile позволило составить реестр задач, которые мы на регулярных статусах синхронизируем и отслеживаем выполнение, принимая различные операционные решения. Актуализируем матрицу рисков. Управляем ожиданиями.

Наш профит от внедрения PI-планирования – сокращение разрывов в сроках поставки.

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

Прозрачность процессов планирования и синхронизации – профит бизнеса.

Через время, вспоминая разработку небольших проектов, понимаю, что подход с PI планированием может отлично заменить, например, Gant-диаграмму. Инструмент отлично работает для синхронизации команд, показывая зависимость между Discovery и Delivery фазами.

Если вы пробовали внедрять PI Board для синхронизации больших или средних команд, буду рад, если поделитесь опытом в комментариях.