На этапе организации процесса разработки проектов, программ мы сегодня часто обращаемся к гибким (Agile) методологиям, например Scrum. В том числе и для планирования объема работ и условий разработки и поставки. Но Scrum-практики и артефакты эффективно работают для одной-двух команд общей численностью до 20 человек. А что делать, если нужно организовать планирование программы, где вовлечены сотни человек?
Полтора года назад мы к пришли к такой ситуации на одном из наших эккаунтов — Ahold Delhaize. Команда за этот период выросла от 40 до 130 человек. Мы столкнулись с необходимостью внедрения инструментов масштабирования в процесс планирования программы. Я расскажу о PI Planning. Не только о теории, но и о живом опыте из нескольких планировочных сессий с нашим клиентом. Так как опыт реальный, в нем есть и плюсы, и минусы. Попробую объяснить, как использовать этот инструмент по максимуму.
Вплоть до 1000 человек
Program Increment (PI) Planning Meeting — это практика планирования, которая пришла из Scaled Agile Framework (SAFe). SAFe — специально разработанный гибкий фреймворк для больших организаций. Набор предоставляемых инструментов SAFe помогает построить Agile-процессы и эффективную коммуникацию между бизнесом и командами разработки программного обеспечения в масштабе
Здесь нужно отдельно сказать о нашем клиенте. Ahold Delhaize — один из крупнейших представителей grocery retail в мире. Проект по развитию онлайн-ветви их бизнеса у нас начался в 2015 году. Почти год на проекте в нашем харьковском офисе было задействовано до 20 человек. А затем клиент решил интенсифицировать выход нового функционала. Мы начали масштабироваться: 2 команды, 4, затем 6. А когда поняли, что команд будет 9, как сейчас, понадобились инструменты для поддержания этого масштаба.
Мы пришли к тому, что будем внедрять отдельные практики SAFe, в частности ежеквартальное PI планирование. SAFe — конечно, не единственный способ. Кроме него масштабирование для Agile организаций предоставляют: Scrum Of Scrums, Nexus, LeSS. Но наш заказчик, зная свою диджитал-организацию, решил, что именно SAFe подойдет лучше всего. Так что мы пришли к PI Planning эволюционно.
Если вкратце, сам PI Planning Meeting происходит в течение двух дней, которые полностью расписаны. В начале озвучиваются общие цели от бизнеса. Затем люди расходятся по командам, изучают, что нужно сделать конкретно каждой команде. Через время снова собираются вместе, делятся тем, что смогли запланировать, какие зависимости и риски выявили. Снова расходятся по командам и обсуждают: возможно, что-то нужно подвинуть по зависимостям от других команд.
На нашем проекте Program Increment включает в себя 6 двухнедельных спринтов. Поэтому, например, одна команда говорит: «Вам нужен вот этот функционал? Но мы сможем сделать его только в пятом спринте этого Program Increment». Другая говорит: «Чтобы нам доделать нашу фичу, нужна ваша. А нашу тоже нужно отдать в пятом спринте. Давайте вы запланируете закончить вашу в третьем, и тогда мы сможем отдать нашу в пятом».
Если совсем по-простому, именно для таких моментальных вопросов-ответов и организовывается общее планирование в течение двух дней.
Главная цель PI Planning
Вообще для Program Increment Planning необходимо собрать офлайн всех людей, которые участвуют в разработке проекта. Команда просматривает планы и цели на квартал от бизнеса, предоставляет решения. И планирует, когда эти решения будут отданы клиенту.
Главное преимущество, ради которого все затевается, это то, что участвует вся команда. То есть каждый разработчик, начиная от Junior, заканчивая Technical Leads, Solution Architects, Program Managers. Соответственно, все проблемы и зависимости можно достаточно качественно выявить и сразу их запланировать. Или озвучить как риски и начать работать над их управлением и уменьшением их влияния.
Так растет прозрачность процесса. Это уже не менеджеры, которые сказали, что нужно сделать то-то к такой-то дате, и давят на команды разработки сверху. Команда сама, изнутри, говорит: «Этот кусок можем сделать к этой дате». Сама анализирует проблемы, возможные риски и механизмы работы с ними. Думает, как сделать, чтобы зависимостей от других команд было меньше. После всех этих процессов команда чувствует себя более ответственной за конечный результат и доставку этого результата вовремя.
Также в случае больших команд (в нашем кейсе вместе с бизнесом и другими отделами на стороне клиента ± 200 человек) всегда есть несколько ключевых архитекторов, которые очень перегружены. Чтобы с ними пообщаться, встречи ради одного-двух вопросов порой приходится ждать неделями. E-mail коммуникация тоже не всегда эффективна, потому что количество e-mail у этих людей зашкаливает. Пока они смогут ответить, проходит еще пара недель. Сессии PI Planning решают и эту задачу.
Без сложностей никуда
Первая и самая главная трудность — для PI Planning нужна очень хорошая подготовка со стороны бизнеса. Бизнес-представители заранее должны определиться, что они хотят и в каком приоритете. «Я хочу новую страницу с супер UX для покупателей» — не подходит. Нужна конкретика — как и зачем будет использоваться эта новинка? Желательно заранее иметь анализ и дизайн.
В противном случае планирование превращается в очень сложное упражнение для всей команды. Без вводных она ощущает неудовлетворенность из-за того, что не может правильно запланировать. В таком случае, PI лучше не организовывать.
Другой недостаток — обратная сторона преимущества. В упражнении много людей. Если участвует больше
Как это происходит на месте
Все начинается с подготовки. Как я говорила выше, вначале она обязательно идет на стороне бизнеса: там прорабатывается, какие требования у них есть и в каком приоритете. Затем составляется график самого мероприятия. Есть лидер всего Program Increment — обычно это Agile-коуч. В зависимости от масштаба, их может быть один или два. В нашем случае сначала был один, а в последний раз — двое.
Пример стандартного расписания, которое рекомендуетсам SAFe. Мы во встречах с Ahold Delhaize идем по похожей, адаптируя ее под задачи мероприятия.
В начале есть интро, где бизнес привносит цели на следующий инкремент (квартал). Желательно в формате «Хотим внедрить вот эту фичу, чтобы получить новый сегмент рынка или заработать плюс $2-3 млн к доходам».
На уровень ниже в каждой команде есть Product Owners, которые прорабатывают пожелания бизнеса более детально. Они придумывают, как их переформатировать в реальные решения того функционала, который мы предоставляем клиенту. Вместе с командами они формируют более детальные требования и решения. Прежде чем это будет запланировано и обсуждено более подробно, они презентуют детальную разбивку. Обычно это занимает
Дальше команды расходятся. В каждой из них есть Scrum Master как фасилитатор внутрикомандных обсуждений вместе с Product Owner, который приносит пожелания бизнеса. Scrum Master фасилитирует и вместе со всей командой
Затем собираются ключевые люди из каждой команды и приносят эти риски и проблемы на один большой борд. Борд может быть двух типов. Мы используем у себя бумажный — несколько склеенных листов А1 с таблицей, что каждая команда к какой дате принесет. Каждая команда на стикерах пишет свои основные фичи, риски, проблемы, вопросы и клеит их на эту бумажную доску. Потом ленточками проводит, где кто зависит друг от друга. Сейчас мы рассматриваем диджитал — есть программы, которые позволяют делать то же самое с выводом на стену проектором.
Пример рабочего бумажного борда
Так проходит
Обычно основные итерации заканчиваются в первый день. На второй день остается финализация. В случае, если выявились какие-то большие риски и возникли вопросы, первую половину второго дня команды еще раз прорабатывают их по отдельности, а примерно к полудню приносят финальные планы.
После этого начинается финализация общего плана и выравнивание с бизнесом. Представители бизнеса обязательно должны быть на этих встречах. Здесь идут дискуссии и консультации. Например, мы говорим представителям заказчика: «Мы видели ваш план из пяти пунктов. Он был вот такой, и согласно ему нужно успеть вот это. Но мы понимаем, что все это не успеем. Пожалуйста, подтвердите, что три из этих пяти пунктов — самые приоритетные. Мы их сделаем, если вы с этим согласны. Если не ок, давайте уберем вот это, но поставим вот это». Вот в таком ключе идут обсуждения второго дня.
Завершается все, как правило, голосованием от команд — confidence vote. Насколько они уверены, что действительно как команда предоставят обещанный скоуп к концу следующего квартала. И желательно, чтобы confidence vote был достаточно высок. У нас он от одного до пяти — просто голосуем пальцами одной руки.
Пример подсчета «пальцев» во время голосования
Желательно, чтобы от всей команды confidence vote был около четырех. Тогда мы уверены, что все в порядке. Если же он меньше, значит, этой команде нужна еще одна итерация — на раздумья, обсуждение рисков и проблем. Скорее всего, мы что-то где-то недопонимаем. Поэтому на этом планировании важно личное присутствие архитекторов. Они помогут прояснить вопросы на месте. Это важная точка PI Planning как мероприятия: все ключевые люди, которые могут ответить на вопросы, как со стороны бизнеса, так и со стороны архитекторов, находятся в одной комнате и могут мгновенно отвечать на различные вопросы, непонимания, проблемы и т. д.
После confidence vote делается ретроспектива. Она может быть двух типов.
Первый вариант — предыдущий квартал. Все ли мы по нему выполнили, что обещали? Если нет, то в формате ретроспективы же разбираемся, почему.
Второй вариант — ретроспектива самого Program Increment. Как прошли эти 2 дня? Насколько они эффективны? Что бы мы улучшили к следующему разу? Что бы мы ни в коем случае не делали в следующий раз? Кстати, последний вопрос мы включили в недавнем очередном PI Planning с Delhaize. И фидбэк был очень ценным.
Приблизительно так проходят эти 2 дня.
Нужные люди
Выше я говорила, что в PI Planning участвуют все люди, задействованные в проекте. На деле можно пробовать оптимизировать состав. Но в целом это должны быть:
- представители бизнеса, которые могут принимать решение на месте;
- архитекторы;
- технические лиды;
- Scrum-мастера;
- аналитики;
- ключевые девелоперы;
- Subject Matter Experts;
- Program или Project Managers (если идут разработки различных уровней программ).
В целом Agile-коуч или Release Train Engineer фокусируется на том, чтобы вся программа была доставлена. А если какие-то части программы важно сделать к определенной дате, это отслеживают Program Managers. Это особенно важно, когда есть интеграция с другими системами или зависимости от внешней системы за пределами основной. Тогда необходимо согласовывать сроки с нескольких сторон. И чем больше сторон, тем сложнее это все происходит.
Критерии успеха и ошибки
Полностью ценность мероприятия можно измерить только на следующем PI Planning. Скажу просто: если мы разъезжаемся, и объем работ, и приоритеты не меняются, и мы доставляем основную часть работ согласно договоренностям во время PI — это успех. Если разъезжаемся, и приоритеты вдруг меняются или по каким-то другим причинам мы не можем доставить обсужденный объем работ — надо думать над улучшением планирования и его форматом. Тогда собираемся ретроспективой и думаем, как это изменить в будущем.
У нас был опыт провальных сессий. Все собирались, делали очень дорогое и тяжелое упражнение, планировали. Затем все разъезжались, мы садились на рабочие места, стартовали — и через неделю по тем или иным причинам приоритеты менялись. Выходит, упражнение было практически бесполезным или использовалось максимум на
Поэтому ключевой фактор успешного проведения PI Planning — это хорошая подготовка со стороны заказчика в плане приоритетов и пожеланий. Важно, чтобы они после встречи не поменялись. Бизнес должен понимать, чего он хочет как минимум в следующем квартале.
Результаты сессии модерируются и контролируются со стороны менеджмента клиента и нашей.
И несколько пунктов, чтобы все прошло эффективно:
- Подготовка — самое главное. План расписания должен прорабатываться опытными людьми. Желательно драйверами с сертификацией SAFe, с пониманием бизнес-целей, с осознанием, что и зачем мы делаем.
- Agile-коучиво главе проведения сессий.
- Правильные инструменты фасилитациимитингов — чтобы люди вовремя останавливались. Не должно быть такого, что одна задача обсуждалась час, а остальные 20 — по 1 минуте. Для этого желательно внедрять определенные ограничения по времени на каждый вопрос/задачу, чтобы люди были максимально сконцентрированы. Обычные инструменты фасилитации митинга очень важны, поэтому роль Scrum-мастера — вовремя их предлагать и применять. На уровне общих сессий это задача Agile-коучей.
Квартальный тимбилдинг
Точка проведения PI Planning в случае распределенных команд выбирается по нескольким факторам: удобство рабочей площадки, размещение гостей и, разумеется, стоимость. Например, в нашем случае с Ahold Delhaize несколько PI сессий мы проводили в Харькове. Здесь у нас большая часть команды, еще есть люди в Киеве и Гродно. Представители клиента — в Брюсселе и Афинах. Оказалось, что наш город отлично подходит для таких мероприятий по логистике и отелям. Плюс мы смогли провести PI Planning прямо в офисе.
Большой кусок закулисной работы по организации ложится на guest relations и event-менеджера. Проектом подготовки к двухдневной сессии занимается Project Administrator, который отвечает за весь процесс. Первый раз был вызовом, подготовка к нему заняла у нас почти 2 месяца. Каждый последующий раз требовалось меньше усилий — можно сказать, мы откатали процесс. Сегодня никто и не удивляется, когда мы говорим об организации визита клиентов в 40 человек и мероприятий на 180 человек.
В какой-то степени PI Planning одновременно превращается и в квартальный тимбилдинг. Для многих даже со стороны клиента это была первая личная встреча — ведь они тоже сидят по разным локациям. У нас планирование заканчивалось большим мероприятием на всю команду, где люди могли уже более неформально общаться друг с другом, познакомиться поближе.
И да, по нашему убеждению, серьезная работа должна оканчиваться фаном. Это полезно и для внутренней коммуникации, и для эмоционального вхождения команды в новый период. Как говорится, «work hard play hard».