×

PI Planning — планирование для больших команд: как его провести и что получается на практике

На этапе организации процесса разработки проектов, программ мы сегодня часто обращаемся к гибким (Agile) методологиям, например Scrum. В том числе и для планирования объема работ и условий разработки и поставки. Но Scrum-практики и артефакты эффективно работают для одной-двух команд общей численностью до 20 человек. А что делать, если нужно организовать планирование программы, где вовлечены сотни человек?

Полтора года назад мы к пришли к такой ситуации на одном из наших эккаунтов — Ahold Delhaize. Команда за этот период выросла от 40 до 130 человек. Мы столкнулись с необходимостью внедрения инструментов масштабирования в процесс планирования программы. Я расскажу о PI Planning. Не только о теории, но и о живом опыте из нескольких планировочных сессий с нашим клиентом. Так как опыт реальный, в нем есть и плюсы, и минусы. Попробую объяснить, как использовать этот инструмент по максимуму.

Вплоть до 1000 человек

Program Increment (PI) Planning Meeting — это практика планирования, которая пришла из Scaled Agile Framework (SAFe). SAFe — специально разработанный гибкий фреймворк для больших организаций. Набор предоставляемых инструментов SAFe помогает построить Agile-процессы и эффективную коммуникацию между бизнесом и командами разработки программного обеспечения в масштабе 100-1000 человек.

Здесь нужно отдельно сказать о нашем клиенте. 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 лучше не организовывать.

Другой недостаток — обратная сторона преимущества. В упражнении много людей. Если участвует больше 6-7 команд, обычно это больше 100 человек — уже тяжело. Нужны оптимизации. PI Planning точно хорошо работает до 100 человек. Больше 100 — уже искусство. Мы сталкивались с ситуациями, когда нам нужно было организовать PI для 160 человек.

Как это происходит на месте

Все начинается с подготовки. Как я говорила выше, вначале она обязательно идет на стороне бизнеса: там прорабатывается, какие требования у них есть и в каком приоритете. Затем составляется график самого мероприятия. Есть лидер всего Program Increment — обычно это Agile-коуч. В зависимости от масштаба, их может быть один или два. В нашем случае сначала был один, а в последний раз — двое.

Пример стандартного расписания, которое рекомендует сам SAFe. Мы во встречах с Ahold Delhaize идем по похожей, адаптируя ее под задачи мероприятия.

В начале есть интро, где бизнес привносит цели на следующий инкремент (квартал). Желательно в формате «Хотим внедрить вот эту фичу, чтобы получить новый сегмент рынка или заработать плюс $2-3 млн к доходам».

На уровень ниже в каждой команде есть Product Owners, которые прорабатывают пожелания бизнеса более детально. Они придумывают, как их переформатировать в реальные решения того функционала, который мы предоставляем клиенту. Вместе с командами они формируют более детальные требования и решения. Прежде чем это будет запланировано и обсуждено более подробно, они презентуют детальную разбивку. Обычно это занимает 2-3 часа первого дня.

Дальше команды расходятся. В каждой из них есть Scrum Master как фасилитатор внутрикомандных обсуждений вместе с Product Owner, который приносит пожелания бизнеса. Scrum Master фасилитирует и вместе со всей командой (5-6 разработчиков, тестировщики, а также, в зависимости от задач, дизайнеры и архитекторы) обсуждает, что у них за объем работ, какие пожелания у самой команды. Обсуждение идет около 2 часов. Они выделяют основные риски, зависимости с другими командами и/или вендорами.

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

Пример рабочего бумажного борда

Так проходит 2-3 итерации: команды вместе, команды отдельно, ключевые люди работают с бордом. В конце все команды снова расходятся и завершают планирование. После чего ключевые люди завершают зависимости и вопросы.

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

После этого начинается финализация общего плана и выравнивание с бизнесом. Представители бизнеса обязательно должны быть на этих встречах. Здесь идут дискуссии и консультации. Например, мы говорим представителям заказчика: «Мы видели ваш план из пяти пунктов. Он был вот такой, и согласно ему нужно успеть вот это. Но мы понимаем, что все это не успеем. Пожалуйста, подтвердите, что три из этих пяти пунктов — самые приоритетные. Мы их сделаем, если вы с этим согласны. Если не ок, давайте уберем вот это, но поставим вот это». Вот в таком ключе идут обсуждения второго дня.

Завершается все, как правило, голосованием от команд — 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 — это успех. Если разъезжаемся, и приоритеты вдруг меняются или по каким-то другим причинам мы не можем доставить обсужденный объем работ — надо думать над улучшением планирования и его форматом. Тогда собираемся ретроспективой и думаем, как это изменить в будущем.

У нас был опыт провальных сессий. Все собирались, делали очень дорогое и тяжелое упражнение, планировали. Затем все разъезжались, мы садились на рабочие места, стартовали — и через неделю по тем или иным причинам приоритеты менялись. Выходит, упражнение было практически бесполезным или использовалось максимум на 30-50% того, что мы обсуждали. По сути, надо заново делать планирование. Конечно, спустя две недели повторного собрания не делали. Поэтому мы проводили перепланирование уже более кустарным способом и сталкивались с теми же вопросами, ждали письменных ответов от ответственных менеджеров и только тогда двигались дальше. Но с каждой следующей сессией эта сложность уходила.

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

Результаты сессии модерируются и контролируются со стороны менеджмента клиента и нашей.

И несколько пунктов, чтобы все прошло эффективно:

  1. Подготовка — самое главное. План расписания должен прорабатываться опытными людьми. Желательно драйверами с сертификацией SAFe, с пониманием бизнес-целей, с осознанием, что и зачем мы делаем.
  2. Agile-коучи во главе проведения сессий.
  3. Правильные инструменты фасилитации митингов — чтобы люди вовремя останавливались. Не должно быть такого, что одна задача обсуждалась час, а остальные 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».

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному3
LinkedIn



25 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Хорошая статья, конкретно и по делу. Пишите еще.

Больше 100 — уже искусство. Мы сталкивались с ситуациями, когда нам нужно было организовать PI для 160 человек.

230 человек плюс подрядчики. дурдом, вобщем

Как раз попалась статья на глаза после того, как я вчера закончила PI планирование в качестве SAFe коуча :) Спасибо за статью, очень интересно было пройтись по вашему кейсу и сравнить со своими :)
Мы кстати для зависимостей исспользуем realtimeboard — удобнее, чем физическая доска. PI objectives тоже фиксируем сразу на Конфлюэнсе.
Еще интересно — вы Business Value исспользуете на практике? :) У нас последний раз нюансы с ними были :)

Спасибо, Елена.
Касательно Business Value — на сегодня мы уже используем и ожидаем увидеть фидбек от клиентов в цифрах по окончании текущего PI, но шли к этому тяжело и итеративно:
1ый PI — бизнес смог проставить только Business Priorities.
2ой PI — начали проставлять приблизительное Business Value во время презентации планирования от команд во время PI Planning, но по сути это поле еще никак не работало.
3ий PI — на основе информации с предыдущих PI, бизнес начал проставлять Business Value и направлять команды во время планирования.
4ый PI — Business Value были проанализированы бизнесом и проставлены перед PI Planning, после PI собрали значения по командам и обещют к следующему показать уже реальные цифры результата. Это пока наша последняя итерация.

Мы используем у себя бумажный — несколько склеенных листов А1 с таблицей, что каждая команда к какой дате принесет. Каждая команда на стикерах пишет свои основные фичи, риски, проблемы, вопросы и клеит их на эту бумажную доску. Потом ленточками проводит, где кто зависит друг от друга.

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

Даже если предположить наличие диджитала — окей, мы имеем достаточно сложный граф с большим количеством узлов. Кто и как его распутывает?

Буду благодарен за пояснения

Спасибо, Андрей. Постараюсь прояснить:
1. Так как доска заполняется в течении двух дней, конечно есть риск потерять какой либо стикер, поэтому в первый день мы просто все заклеивали сверху скотчем :). А на второй день у нас обязательный пункт в расписании: 1 час для всех PO/SM перенести всю информацию в JIRA по своим командам, обычно этого времени достаточно.
2 и 3. Почерк особо разбирать не надо, так как мы в основном указываем номера задач в JIRA и размер задач и приклеиваем на запланированный спринт, всю остальную информацию мы записываем в соответсвующей задаче в JIRA.
4. В конце дня проводится общее ревью перед Confidence Vote, обычно ошибки отлавливаются на этом этапе.
5. Независимо от версии доски, в работе с зависимостями выделяем два этапа:
1) на этапе PI Planning: идентифицируем зависимость, визуализируем, и кратко прописываем как на нас повлияет и план действий, согласуем план на месте с нужными сторонами.
2) на этапе PI (в течении кваратала): PO и SM ответсвенны прослеживать зависимости и насколько план по уменьшению влияния выполняется для каждой соответсвующей задачи.

Спасибо большое за статью, замечательно, когда делятся реальным опытом!
Маленький вопрос: project administrator — это Junior PM, чем он обычно занимается вне PI?

Спасибо, Игорь. Роль Project Administrator выделена на уровне компании и обычно актуальна для больших эккаунтов (100+чел), где мы сталикиваемся с вопросами организации специфичных для эккаунта внутренних процессов и их поддержки. Основные задачи, помимо подготовки к PI Planning, являются: контроль репортинга и финансовых отчетов, организация процесса ввода новых сотрудников, планирование различных мероприятий на уровне всего эккаунта. С этой роли есть возможность дальше развиваться в Project Management.

Чудова стаття, дякую. Читав як про свою компанію. В нашому арті також 9 команд, які розподілені по трьох локаціях, тому масштаби/проблеми органцзації приблизно такі ж, як і у вас.
Варто сказати, що дуже помагає гладко провести PI залучення команд в підготовку.
За тиждень-два до івенту продукт менеджмент проводить презентацію беклогу, коротко розказати командам про фічі та основні аксептенс критерії. Таким чином визначається, які фічі готові, а які потребують доопрацювання. Команди ще до PI можуть приблизно (в командо-спрінтах чи ще чомусь хай-левельному) оцінити об"єм кожної з фіч, обговорити, що вони хочуть/можуть витянути. Якщо для важливої фічі не знаходиться охочих, вона розбивається на менші, або зменшується її скоуп.
З оцінками об"єму продукт менеджмент може пріоритезувати беклог по WSJF.
Якщо ідентифікується залежність на інший арт, можна створити фічу йому в беклог. Це дуже важливо у випадку, коли їх PI проходить раніше за ваш — не потрібно буде чекати 3 місяці, поки вони інший арт її запланє і зможе зробити.

Спасибо, Андрей! Совершенно верно, постепенно и мы уже пришли к тому что команды начинают ревью требований с PO за две недели. Касательно приоритизации беклога по WSJF — мы не применяем еще. Было бы интересно увидеть на реальных примерах как оно работает, если есть возможность поделиться живыми примерами — была бы благодарна.

Хорошая статья, читалась довольно легко.
Интересно, не давит ли на команды атмосфера жёсткой ограниченности времени на планирование? 2 дня, даже при предварительной подготовке, кажутся очень маленьким сроком. Из других источников слышала, что и за 1 день умудряются справиться. Это тем более звучит фантастично.

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

Отличная статья, спасибо!
Program Increment (PI) Planning реально проводить в течении одного дня, если конечно все требования были готовы заранее и уже оценены командой; Product Owner вначале X релиза начинает работу над X+1 релиз и отчитывается о готовности беклога следующего релиза еще до PI планирования, это реально, если Product Management Team планирует Product Roadmap хотя бы на полгода вперед. Таким образом PO придет уже с распечатанными диаграмами, написанными на стикерах тасками и чашкой кофе :)
И несколько улучшений:
— Желательно также, чтобы последний спринт был стабилизационным и отводился на допиливание и т.д. Если 5-6 двухнедельных спринтов, это разработка за целый квартал.
— Зависимости легче контролировать, если каждая команда, отобразит их стикерами на досках команд зависимых от нее и на нее.
— Можна также задачи разбивать по типам: цель, продукт, пилот, эпика, исследование, техническая, user story — таким образом нагляднее, где именно происходить инкремент к продукту, где выше риски ошибок на клиентской стороне, где возможен онсайт и т.д. Использовать разные цвета и размер.
— Делать финальное демо с кратким итогом о целях, продуктах, рисках и т.д.
— Наносить на самом стикере задачи дополнительно к названию размещать оценку с сторипойнтах, эпику, код задачи в трекинговой системе, проект. Для эпики делать сразу два, для указания начала и конца.

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

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

Используем kendis.io сейчас, вроде как всем нравится

Спасибо, Илья, за совет. Мы сейчас как раз на стадии выбора более эффективного инструмента, рассмотрим и этот вариант.

Спасибо за наводку, тоже посмотрю :)

Спасибо Людмила, интересная статья. Не доводилось использовать SAFe в чистом виде, но живые примеры ее использования очень интересны. Поэтому есть несколько вопросов:
1. Почему ретроспектива проводится в самом конце? Не логичнее ли ее провести в начале, чтобы учесть все моменты уже на этом планировании?
2. В каком порядке перепланируется не сделаное в прошлой итерации (квартале) на новую?
3. Насколько реалистично PO задокументировать все цели бизнеса в виде User Story на весь квартал в течение 2 часов? Почему это не может проводиться в менее авральном и рискованном режиме за 2-4 недели до PI?
4. Насколько точны эстимейты на квартал, сделаные в течение 2 часов? Для того, чтобы проэстимировать задачи на спринт 2-3 недели этого может и хватит, но на 4-6 спринтов выглядит маловато.
5. Насколько Вы сами оцениваете выгоду от применения SAFe по сравнению с другими вариантами синхронизации?

1. Если ретроспектива майлстоуна — то да, логичнее в начале. А ретро самого пленинга логично проводить после этого пленнинга, а не перед :)
2. Согласно бизнес целей (приоритеты с прошлого пленинга вполне могли измениться)
3. User Story обычно готовятся ПО заранее. Или, как минимум, готовтся епики, а сторьки уже команды расписывают в процессе планирования.
4. Эстимейты «хайлевельные», могут потом уточняться и детализироваться при планировании спринтов. Но в среднем ± с допустимым отклонением.

Спасибо Сергей и Вадим, за комментарии. Во многом согласна с ответами Вадима, добавлю только по нашей специфике:
1. Если мы проводим ретроспективу по достижению целей с предыдущего PI, то основной фокус направлен на улучшение процессов в течении следующего PI (квартала), которые бы позволили нам гарантировать своевременную поставку нового функционала. Также при необходимости мы расширяем список рисков и зависимостей, которые в дальнейшем адресуются уже тоже во время PI. Поэтому проведение такой ретроспективы в конце мероприятия выглядит достаточно логично для нас.
2. В основном незавершенная работа в нашем случае переносится на начало следующего Program Increment, но также возможны варианты новых приоритетов от бизнеса и перенос незавершенных задач на последующие PI Planning.
3. Совершенно верно, это невозможно описывать требования во время PI Planning, и это НЕ является его целью, основная цель при большом масштабе — выявить зависимости, риски и запланировать порядок работ соответственно. И конечно, бизнес требования должны быть проработаны заранее PO — именно это я имела в виду под подготовкой к PI Planning в статье.
4. Для естимейтов на PI Planning мы используем T-shirt sizing (S, M, L). Этот вариант оценки начинает работать эффективно на второй-третий PI Planning, когда у команд уже есть опыт и есть на что опереться в оценках. При ряде факторов: 1) проработанные заранее требования, 2) слаженная Scrum команда, 3) управляемые зависимости — эстимейты достаточно точны и команды доставляют 100% запланированного объема работ.
5. PI Planning практика из SAFe позволила нам адресовать большое количество проблем, с которыми мы сталкивались ранее и не могли качественно и долгосрочно их решить, мы пробовали Scrum of Scrums с различными участниками, проcто регулярные поездки при старте новых больших фич, но именно регулярный PI Planning позволил качественно улучшить процесс непрерывной поставки нового функционала без провисаний по времени и загрузки для 9 команд работающих над одним продуктом. Поэтому для Enterprise стремящихся к Agile разработке, я лично считаю, что PI Planning является эффективным инструментом планирования.

Спасибо, полезная сатья!
хороший опыт

спасибо за статью. Читается сложно. Я бы лучше послушал и посмотрел :)

Приму к сведению :) Спасибо Сергей.

Підписатись на коментарі