PI-планирование в SAFe

    Scaled Agile Framework, SAFe — фреймворк Agile-разработки, разработанный Scaled Agile Inc., по сути база знаний по реализации бережливой Agile-разработки в корпоративных масштабах. Ниже вольный пересказ оригинальной статьи «PI Planning — Scaled Agile Framework».


    Сессия PI-планирования на 190 участников


    Задачи по разработке продукта невозможно заранее предугадать. Передайте планирование и отслеживание тем, кто может оценить конечный результат и влиять на то, каким он будет.
    — Michael Kennedy, «Product Development for the Lean Enterprise»
    В SAFe нет никакого волшебства… разве что только PI-планирование.
    — Авторы SAFe

    Один из принципов Agile-манифеста говорит, что «непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды». Это несложно осуществить, если у вас одна небольшая команда. А как быть в масштабах огромной компании, когда команд много и необходима их синхронная работа? Для этого в Scaled Agile Framework (SAFe) используется инструмент PI-планирование (PI Planning) — это практика прямого общения всех команд, представителей бизнеса и других заинтересованных лиц, которые как бы объединяются в одну большую команду — Agile Release Train (ART).

    Общение проходит на регулярных встречах со стандартной повесткой: в начале презентация представителей бизнеса с рассказом о текущей ситуации, стратегии и задачах, затем сессия планирования, когда команды создают план реализации инкремента продукта, создаваемого в рамках программы — Program Increment (PI). Сразу оговоримся: в терминологии SAFe для обозначения большого количества взаимосвязанных между собой команд используется термин «программа», в дальнейшем мы будем его придерживаться. В этой сессии принимают участие все члены ART, насколько это возможно. Для фасилитации таких встреч выделена специальная роль — Release Train Engineer (RTE). Он же отвечает за эскалацию блокеров, помогает в управлении рисками, поставке ценности и непрерывном совершенствовании.

    Для подобных мероприятий по планированию, исследованиям и обучению предусмотрена специальная IP-итерация (Innovation and Planning iteration), чтобы не занимать время команд на других итерациях внутри PI. Сессия длится от 1,5 до 2 дней. Результатом является согласованный набор целей программы на следующий PI.

    Географически-распределенные ART проводят эту встречу одновременно в разных местах, но поддерживают между собой постоянную связь.

    Обзор


    PI-планирование важно проводить регулярно, ведь оно задает ритм работы всего ART. Это неотъемлемая часть SAFe: если вы не проводите PI-планирование, вы не применяете SAFe.


    Сессия PI-планирования на 250 участников

    PI-планирование предоставляет бизнесу множество преимуществ:

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

    К сессии готовятся следующие материалы: дорожная карта, концепция, топ-10 приоритетных фич из бэклога программы и другие артефакты для передачи бизнес-контекста.

    Основными результатами PI-планирования являются:

    1. Набор SMART-целей команд на PI, которые каждая команда определяет самостоятельно. Каждая цель оценена с точки зрения значимости для бизнеса. Цели всех команд объединены в набор целей всей программы на PI.
    2. Доска программы, на которой показаны новые фичи, ожидаемые сроки их реализации и любые другие вехи, с которыми связаны цели команд.
    3. Общее согласие с реалистичностью и готовность взять на себя ответственность за достижения этих целей.

    Подготовка


    PI-планирование — важное событие, которое требует подготовки, координации и коммуникации. Участники мероприятия: продуктовые менеджеры, Agile-команды, архитекторы и инженеры, системные команды, заинтересованные лица — все они должны быть заранее оповещены и прийти на мероприятие хорошо подготовленными.

    Успешное мероприятие готовится по следующим направлениям:

    • Организация: согласованность бизнеса и разработки по стратегии, готовность команд и всего ART.
    • Содержание: подготовленность менеджмента и разработчиков.
    • Инфраструктура: место проведения и логистика мероприятия.

    Ниже приводится описание подготовки по каждому направлению.

    Организация


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

    Ниже примеры вопросов, которые помогают определить эту готовность.

    • Объем работы и контекст планирования: «Понятны ли рамки планирования: продукта, системы, технологической области? Знаем ли мы, какие команды нужны для совместного планирования?»
    • Согласованность бизнеса: «Согласованы ли приоритеты между представителями от бизнеса?»
    • Agile-команды: «Есть ли у нас Agile-команды? Все ли команды укомплектованы разработчиками и тестировщиками? Везде ли определены Скрам-мастер и владелец продукта?»

    Содержание


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

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

    Инфраструктура


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

    Ниже приведены моменты, которые следует учесть.

    • Пространство: в помещении должно быть достаточно просторно для всех участников, включая места для перерывов при необходимости.
    • Техническая поддержка: заранее определите людей, которые будут помогать вам с настройкой, тестированием и решением проблем с технической инфраструктурой на мероприятии.
    • Каналы связи: распределенные сессии планирования требуют наличия основных и резервных каналов трансляции аудио, видео и презентаций.

    Повестка


    В целом мероприятие соответствует стандартной повестке, которая показана ниже. Далее мы рассмотрим каждый блок мероприятия подробнее.


    Стандартная повестка 2-дневной сессии PI-планирования

    День 1


    Бизнес-контекст


    Топ-менеджер или владелец бизнеса описывает текущее состояние бизнеса и то, насколько хорошо текущие решения в перспективе будут удовлетворять потребности клиентов.

    Концепция продукта


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

    Архитектура и практики разработки


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

    Контекст планирования


    Ведущий — RTE — объясняет процесс планирования и ожидаемые результаты от мероприятия.


    Ведущий объясняет цели и план сессии PI-планирования на 100 человек

    Работа команд — 1


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


    Команды выявляют взаимозависимости на сессии PI-планирования на 100 человек

    Рецензирование черновиков планов


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


    Владелец продукта презентует собранный ее командой план на сессии PI-планирования на 100 человек

    Рецензирование руководством и решение проблем


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

    День 2


    Изменение планов


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

    Работа команд — 2


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


    Результаты планирования одной из команд на сессии PI-планирования на 100 человек

    Презентация итоговых планов


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

    Риски программы


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

    • Resolved — команда согласилась, что проблема больше не актуальна;
    • Owned — вопрос не может быть решен на мероприятии, но кто-то согласился продвигать разрешение этого вопроса далее;
    • Accepted — некоторые риски являются фактами или потенциальными событиями, которые просто должны быть всеми поняты и учтены в дальнейшей работе;
    • Mitigated — команда может определить план по устранению последствий данного риска или блокера.



    Риски программы на сессии PI-планирования на 100 человек

    Голосование


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


    Правила голосования на сессии PI-планирования на 100 человек

    Если по всем командам в среднем подняты три или четыре пальца, то руководство может принять такие обязательства. Если же в среднем меньше трех пальцев, то в план вносятся необходимые изменения и все планы перерабатываются. Каждый, кто поднимает два или меньше пальцев, должен высказать свои опасения. Это позволяет или идентифицировать новый риск, требующий перепланирования, или просто донести до всех важную информацию.


    Голосование на репетиции с участием Скрам-мастеров и владельцев продуктов команд перед сессией PI-планирования на 100 человек

    Переделка планов, если нужно


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

    Ретроспектива


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

    После этого можно обсудить дальнейшие шаги, занести цели и пользовательские истории в IT-инструменты управления Agile-проектами, запланировать предстоящие ключевые активности и мероприятия… и даже прибраться в помещении!

    Результаты


    Успешное PI-планирование позволяет получить три основных артефакта.

    1. Набор SMART-целей команд на PI, которые каждая команда определяет самостоятельно. По каждой цели представителями от бизнеса определена оценка ее бизнес-ценности.
    2. Доска программы, на которой видны сроки поставки новых фич, зависимости между командами и зависимости от других ART, а также важные вехи.


      Доска программы одного ART

    3. Согласие всех команд ART с реалистичностью целей PI и их готовность взять на себя ответственность за достижение этих целей.


    Практика


    В этом видео наша практика PI-планирования:


    PS. Если вам интересны материалы по трансформации процессов в крупных компаниях, рекомендуем группу Enterprise Agile Russia в Facebook. Будем обсуждать подходы к масштабированию, такие как SAFe и LeSS.
    ScrumTrek
    47.51
    Мы помогаем компаниям стать крутыми!
    Share post

    Comments 3

      0
      Ерунда все это. :)
        0
        Когда речь идет в настолько позитивном ключе, начинаешь задумываться, а проработан ли подход. Не засыпится ли он на корню при малейшем отклонении. Вы писали о преимуществах для бизнеса, а о недостатках ни слова. А их не может не быть. Во встречах параллельно участвуют представители как топ-менеджмента, так и конечные исполнители. При этом предполагается, что оценка реалистичности планов управленцев дается командами в ходе открытого голосования. А не будет ли в этом случае давление на исполнителя слишком сильным? Не будет ли он просто соглашаться с руководством в надежде на авось? Тут вопросов уйма, и ни на один из них не то что не дается ответов — даже намека нет. Это придирка даже не к конкретно этой статье, а практически ко всем проповедям аджайл-стайл. Позитив — это хорошо, но без техник выхода из кризисов (чаще неизбежных), он, на мой взгляд, опасен.
          0
          Статья — это перевод оригинальной статьи консультантов Scaled Agile Inc. из описания фреймворка SAFe. Если интересует именно практика, то посмотрите мой доклад, на который есть ссылка в конце статьи. В этом докладе я рассказываю в том числе и про «давление», которое происходит на встрече: правда, я больше указыванию на давление на менеджмент со стороны исполнителей — хотя и обратное происходит.


          Если не верите консультантом, то посмотрите другой доклад от Сбербанка:

        Only users with full accounts can post comments. Log in, please.