Как провести PI-планирование на 100+ человек: от глобальных целей до точечных задач
Скрам-мастера IT-компании RDP.RU рассказали, как проводят PI-planning в Kaiten
Пару слов о компании
Компания RDP.RU входит в группу компаний «Ростелеком» и специализируется на разработке инновационного программного обеспечения и программно-аппаратных комплексов для высокопроизводительной обработки сетевого трафика. Продукция компании широко востребована в сетях операторского класса, крупных предприятиях и Госсекторе.
Какие проблемы помогают решить Kaiten и PI-планирование
В своей работе с одним из ключевых заказчиков из Госсектора мы столкнулись со сложностями в коммуникациях, непрозрачностью процессов; стандартные инструменты и методы коммуникаций были неэффективны и мы задумались об улучшении взаимодействия.
Одни из основных проблем, которые мы пытались решишь:
Проблема №1: заказчик хотел общаться напрямую с инженерами и разработчиками, иметь минимальное число посредников, тем самым сократить время на коммуникации и доносить свое видение напрямую исполнителям.
Проблема №2: разные команды работают над разными продуктами, эти продукты вместе образуют комплексное решение, которое несет основную ценность для заказчика, однако иногда возникали сложности в синхронизации между командами, недопонимание влияния зависимостей между продуктами, что приводило к задержкам финальной поставки решения и неудовлетворенности заказчика.
Текущая модель взаимодействия не отвечала запросам заказчика по эффективности и оперативности. Необходимо было придумать новый формат.
Тогда у нас возникла идея попробовать визуальную систему управления процессами Kaiten, которую поддержал директор по развитию. Целью было создать кросс-функциональный бизнес-процесс между всеми заинтересованными лицами. Чтобы руководители, заказчики и исполнители всех направлений могли видеть происходящее без посредников и получать аналитику, когда им это потребуется.
В связи с масштабированием компании и ростом количества межкомандных зависимостей мы решили обратиться к SAFe 6.0 — это фреймворк, спроектированный для внедрения гибких методик разработки в крупных компаниях от 100 человек. Он применяется, когда компания вышла из состояния стартапа в матричную структуру, бизнес-процессы усложняются, но компания хочет оставаться достаточно маневренной.
Что такое PI-планирование
Одним из событий в рамках SAFe является PI-планирование (планирование программного инкремента) — это мероприятие, на котором владельцы бизнеса (Business Owners) и все команды (Agile Release Train) определяют высокоуровневые цели и согласно этим целям планируют свою работу на квартал.
Agile Release Train (ART, или поезд) — это несколько Agile-команд, которые на постоянной основе участвуют в едином потоке создания ценности, приносящей пользу заказчику. Они совместно планируют, принимают обязательства, разрабатывают и выпускают эту ценность.
Программный инкремент — это период времени до 12 недель, в течение которого команды выполняют запланированную работу над проектом.
PI-планирование обычно длится 2 дня. Все участники проекта собираются вместе, чтобы поставить цели на новый период, критически оценить, насколько они выполнимы, и услышать обратную связь от заказчиков.
В ходе PI-планирования обязательно применяется визуализация задач и строятся взаимосвязи между уровнями. В нашей компании это Epic — Feature/Enabler — Tasks. Это помогает командам увидеть, как конкретная точечная задача связана с глобальной целью компании, а также подсветить зависимости друг от друга — пока одна команда не сделает свою часть, другая не сможет выполнить следующую.
Результатом PI-планирования является детальный план на 3 месяца, который включает в себя согласованные цели команд, задачи, которые необходимо выполнить, а также оценку рисков.
Это дает ощущение стабильности и способствует сближению заказчика и команд.
Команды, которые ежедневно работают над продуктом, могут напрямую услышать от заказчика требования и ожидания. Заказчик транслирует цели конкретного квартала, и все участники понимают, куда нужно двигаться.
Заказчик видит, какие задачи команда берет в план и как она их декомпозирует. Он может задать свои вопросы напрямую исполнителям.
Все участники принимают на себя обязательства и точно знают, в какой точке будут находиться через квартал. Это исключает ситуации, когда заказчик может сказать «я вовсе не это имел в виду» или когда команда скажет «мы не учли риски, поэтому не успели». Так как на планировании открыто проговариваются все эти вопросы.
PI-планирование создает условия, в которых мозг работает быстрее. Все участники готовы обсуждать острые моменты здесь и сейчас, а не откладывать вопросы до какой-то встречи.
Как происходит PI-планирование на практике
В нашем случае планирование проводится 1 раз в квартал в формате живой встречи. В нем участвуют 16 команд, работающих над разными под-продуктами, владельцы бизнеса и заказчики. На текущий момент мы провели 5 подобных мероприятий.
3 уровня иерархии рабочих элементов
Мы решили, что у нас будет 3 уровня иерархии рабочих элементов:
самый верхний уровень — это эпики — глобальные цели на уровне представителей бизнеса;
второй уровень — это фичи и энейблеры. Фича — это часть функциональности, которая несет ценность для клиента. А энейблер — это техническая вспомогательная задача, которая обеспечивает создание этой ценности;
далее фичи и энейблеры декомпозируются на таски — это рабочие задачи, с которыми команды исполнителей взаимодействуют каждый день.
Для каждого из этих уровней предусмотрен свой тип карточек в Kaiten, а также особое место для визуализации — отдельные доски и пространства.
На PI-планировании нам необходимо синхронизировать работу всех участников процесса таким образом, чтобы в результате таски каждой команды вели к выполнению глобальных целей и не противоречили друг другу.
Уровни рабочих элементов и люди, которые с ними работают
Подготовка к PI-планированию
Подготовка является важным этапом, без которого PI-планирование не будет результативным. Перед общим собранием на каждом из уровней определяются и декомпозируются рабочие элементы:
представители бизнеса устанавливают ключевые цели;
менеджер продукта, системный архитектор и Release Train Engineer раскладывают эти цели на составляющие и производят верхнеуровневую проработку идей;
Agile-команды вместе с владельцем продукта разбивают проработанные идеи на задачи и формируют свой бэклог.
Таким образом, все участники планирования заранее проводят отбор идей и задач, которые дальше им нужно будет синхронизировать друг с другом — найти зависимые задачи и договориться, к какому этапу какая команда выполнит свою часть поставляемой ценности.
Мы визуализировали этот процесс в Kaiten:
На уровне эпиков у нас расписан верхнеуровневый end-to-end процесс всего Agile Release Train, который обеспечивает поставку ценности. Для этого в Kaiten у нас есть верхнеуровневое пространство, на котором мы отображаем эпики. На нем показаны все этапы от зарождения идей, до их проработки, реализации и релиза.
Шаблон пространства для работы с эпиками. Доска Upstream и Downstream
Когда бизнес выдвигает идею, она прорабатывается сначала на верхнем уровне, а затем попадает в колонку «Предварительная оценка командой» и отправляется на пространство команд для технической оценки:
Схема показывает, как на этапе «Предварительная оценка командой» карточки эпиков декомпозируются на составляющие на доске команды.
Команда, ответственная за определенный подпродукт, раскладывает идею на фичи и энейблеры на своем пространстве. Проработка задачи включает в себя описание, определение критериев готовности и оценку в стори-поинтах. После этого карточки попадают в колонку «to plan». Это означает, что они готовы к PI-планированию и этап подготовки завершен.
Погружение команд в бизнес-контекст
Само PI-планирование проходит в 2 дня. Все заинтересованные лица собираются в конференц-зале и общаются друг с другом лично.
Всё начинается с погружения команд в бизнес-контекст. Заказчик описывает, какие проблемы предстоит решить, а топ-менеджмент компании фокусирует внимание на верхнеуровневых целях.
Это позволяет командам понять полную картину и выйти за рамки мышления точечными задачами. В результате команды разработки не просто получают задачу, а понимают бизнес-цель — что именно нужно сделать и для чего. У них появляется место для маневра и возможность самостоятельно предлагать решение конкретной цели.
Расписание планирования. Первые часы выделены на погружение в бизнес-контекст.
Планирование итераций
Дальше люди расходятся по своим командам. Их задача — договориться и разложить фичи и энейблеры по двухнедельным итерациям на квартал вперед. Из колонки «to plan» они распределяют карточки по колонкам на доске планирования на уровне команды:
Схематично показан процесс планирования фичей и энейблеров по итерациям в команде.
Далее им также нужно разложить по итерациям таски, которые являются составными элементами фичей или энейблеров.
Здесь для каждой итерации важно учитывать емкость команды: сколько задач она сможет осилить. В этом помогает отчет Kaiten о средней скорости команды. Мы точно знаем, сколько стори-поинтов может выполнить команда и, соответственно, сколько работы она может взять за итерацию.
Также при планировании итераций мы оставляем командам буферы для внеплановых задач, чтобы у них оставалось пространство для маневра.
Схематично показан процесс планирования задач по итерациям в команде.
Определение зависимостей
В процессе распределения задач по итерациям командам нужно выявить зависимости и синхронизироваться между собой, потому что некоторые задачи находятся на стыке разных продуктов.
Мы визуализируем зависимости на специальной доске в Miro. На ней отмечены итерации и глобальные цели. А на пересечении находятся задачи, по которым есть несостыковки. Сами зависимости обозначаются красными стрелками.
Когда зависимости определены, командам нужно договориться, кто и в какую итерацию выполнит свою часть работы.
Доска в Miro, на которой визуализированы все зависимости.
Определение рисков
Еще один шаг, который выполняется в рамках PI-планирования, — это определение рисков, с которыми мы можем столкнуться при выполнении плана.
Сначала команда фиксирует бэклог рисков на специальной доске. А далее они разбиваются на 4 колонки по категориям (по модели ROAM):
Accepted — риски, которые мы принимаем и берем на себя ответственность;
Owned — риски, за которые назначается ответственным определенный человек. Он будет наблюдать за развитием ситуации и принимать меры по их снижению или устранению;
Mitigated — риски, по которым мы заранее формируем план, как будем действовать в случае их наступления;
Resolved — риски, урегулированные в процессе самого планирования.
В карточках отмечается подробная информация по всем рискам, при необходимости назначаются ответственные, а с помощью меток отмечаем, какие команды и продукты этот риск может затронуть.
Пример доски для визуализации и проработки рисков
Защита планов команд и голосование
Когда план итераций составлен, зависимости определены, риски проработаны, команды переходят к защите своих планов. Обычно защита проходит в два этапа:
Предзащита в конце первого дня PI-планирования, когда команды приносят черновики, а руководство дает обратную связь.
Дальше команды дорабатывают и представляют скорректированные планы в конце второго дня PI-планирования.
Все участники обсуждают планы команд, анализируют зависимости и могут оставлять свои комментарии.
Для удобства у нас есть отдельное пространство в Kaiten, на котором видно, с какими фичами будет работать каждая команда в разбивке по итерациям:
Пример пространства, на котором собраны доски с планами всех команд
Важный ритуал на защите планов — это пятибалльная оценка уровня доверия своему плану. Каждый участник команды рукой показывает, насколько он верит, что этот план выполним. Если кто-то ставит низкую оценку, это повод поговорить о том, какие риски он видит, и найти решение.
Команда оценивает доверие своему плану.
Завершение PI-планирования, реализация и контроль
После того как команды защитили все планы и определили риски, остается только зафиксировать итоговый план, поздравить всех участников и начать новый квартал.
На пространстве с верхнеуровневыми целями (эпиками) карточки распределяются по двум колонкам:
обязательные (Committed) — те, которые мы обязуемся выполнить;
необязательные (Uncommitted) — те, что мы планируем сделать, но учитываем, что есть риски, которые могут нам помешать.
Важно, что владельцы бизнеса и заказчики определяют бизнес-ценность для каждой цели и прописывают ее в карточке в виде коэффициента от 1 до 10. После мы сможем оценить, насколько эта ценность была выполнена.
Доска Downstream с карточками, в которых прописан планируемый business value
Затем начинается непосредственно реализация планов. У команд уже составлен подробный бэклог на каждую итерацию. Они берут готовые таски и перетаскивают их на рабочую Канбан-доску в соответствии со своими алгоритмами пополнения.
В течение 2-х недельных итераций команды Agile Release Train встречаются между собой, чтобы обсудить, в правильном ли направлении движется каждая команда, насколько эффективно решаются зависимости, есть ли какие-то проблемы.
В конце итераций команды предоставляют готовые элементы функциональности системы и демонстрируют их заказчику. Он, в свою очередь, может дать обратную связь.
Пример рабочей доски команды
Также в конце итераций мы возвращаемся к верхнему уровню целей и оцениваем, насколько нам удалось их достичь. В каждой карточке с целью мы проставляем фактический коэффициент ее выполнения. То есть, если цель была оценена на 10 и выполнена на 100%, то в поле Actual BV (business value) будет стоять 10.
Это помогает нам контролировать, как выполнение точечных задач команд влияет на финальную ценность для заказчика.
Выполненные эпики, в которых прописан фактический business value
Удалось ли достичь поставленных целей?
Пройдя через несколько циклов PI-планирования и визуализировав работу команд в Kaiten, мы можем смело говорить о достигнутых результатах на уровне всей компании.
В разы увеличилась продуктивность. Каждая команда точно знает, какие задачи ей надо и не надо делать для достижения верхнеуровневых целей. Соответственно, снизилось количество «работы ради работы». Команды занимаются только тем, что принесет результат.
Появилась прозрачность и доверие между исполнителями и заказчиками. Kaiten позволяет генерировать аналитику, которая показывает количество задач, трудоемкость, прогресс по задачам и другие метрики. Это становится хорошим аргументом для конструктивного диалога с заказчиками. Они видят, что наши слова обоснованы и подтверждаются аналитическими данными.
У менеджмента компании появился инструмент для быстрого отслеживания прогресса с минимальными издержками. Достаточно отслеживать задачи верхнего уровня, в которых автоматом отражается весь прогресс по подчиненным задачам. Это позволяет нам быстро получать актуальную информацию для принятия управленческих решений.
Выводы и работа над ошибками
В заключение хотим рассказать об ошибках, которые компании часто допускают при проведении PI-планирования, вследствие чего результат не совпадает с ожиданиями, а сам инструмент считают неэффективным.
Ошибка №1: Думать, что идеальное планирование получится провести с первого раза. Чтобы разобраться в основах, научиться основательно готовиться к планированию и организовывать коммуникацию команд, требуется время и опыт. Первый раз обычно получается пробным и служит тренировкой для будущих мероприятий.
Ошибка №2: Не доносить до всех уровней сотрудников «зачем мы это делаем». Довольно распространенная ситуация, когда менеджмент решает провести планирование, а сотрудники воспринимают это как «очередное ненужное собрание», потому что не понимают, в чем его смысл.
Ошибка №3: Недостаточное погружение команд в бизнес-контекст. В начале планирования владельцу продукта и заказчикам необходимо подробно рассказать командам о текущем положении и о глобальных целях бизнеса. Иначе не получится построить связь между точеными задачами и общими целями.
Ошибка №4: Не учитывать разную скорость работы команд. Кому-то будет вполне достаточно двух дней, чтобы запланировать свои задачи, а кому-то этого будет мало. Это сильно зависит от уровня подготовки команд к планированию.
Ошибка №5: На первое же планирование приглашать без разбора абсолютно все команды («вдруг пригодятся»). Пока инструмент не обкатан, лучше приглашать на планирование команды с большим количеством зависимостей и постепенно добавлять участников, а не звать всех подряд. Например, если команда никак не влияет на глобальные цели и не взаимодействует с другими командами, то участники могут не понять, для чего им это нужно, и даже начать саботировать мероприятие. В подобной ситуации можно пригласить хотя бы одного представителя команды, который при необходимости сможет ответить на вопросы или связаться с коллегами для уточнения.
Мне и моим коллегам будет интересно услышать ваши мнения. Как вы планируете в условиях множества команд? Пробовали ли вы проводить PI-планирование? Каким вспомогательным инструментом пользовались? Какие видите достоинства и недостатки такого формата? Давайте обсудим.
