Встречи планирования разработки в пандемию, или Как устроить электро PIP

Сегодня мне хотелось бы с помощью моих коллег Agile-коучей Ани Родионовой, Макса Зотова и владельца продукта в Трайбе «Розничное взыскание и урегулирование» Свята Божухина рассказать о практике применения интересного инструмента. Итак, речь пойдёт о Program Increment Planning Meeting aka PI Planning.

Это метод планирования из SAFe (Scaled Agile Framework) — гибкого фреймворка для крупных компаний. Ну, знаете, это когда люди стоят у стены, оклеенной стикерами, лепят всякие ниточки от одного стикера к другому, но при этом в городе не орудует маньяк.

Ниже — пример места встречи одной из команд для PI в Сбере (обратите внимание на ту самую стену на заднем плане):

Все мы помним, что в марте 2020 года всё стало иначе: пандемия и режим самоизоляции внесли свои коррективы. Мы «переобувались на лету» за неделю, а то, что ранее, как нам казалось, было возможно только оффлайн, переместилось в онлайн.

С чего началось

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

Вот так выглядит SAFe, и скромную часть в нём занимает PI:

Вот что должны сделать разные участники, чтобы планирование прошло успешно:

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

Scrum-мастерам поручили подготовить все шаблоны флипов (флипчартов). В онлайне они трансформировались в таблички на Confluence в специальном пространстве для совместной работы.

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

Группа фасилитаторов следила за тем, чтобы все шаблоны в Confluence были подготовлены и всё логистически готово.

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

Второй тип необычных задач — «сиротки». Представьте, что вы владелец продукта, у вас есть команда, вы понимаете, как развиваете свой продукт, но видите что-то со стороны, что тоже нужно сделать. И это важно. А вы уже не можете, ваш бэклог переполнен, и ваши задачи важнее. Тогда вы берёте эту задачу и помещаете её в специальное пространство, где живут все задачи, которые нужно сделать. Ну и, конечно, прояснить и посмотреть по эффектам, зачем они в принципе нам нужны.

Сама история почти не поменялась: если раньше были физические флипчарты, то теперь они стали виртуальными.

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

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

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

Потом — риски. Если команда видит, что у неё, возможно, будут проблемы при реализации какой-то задачи, то она его обозначает, и потом уже мы решали, кто с этим работает и как.

И дальше — распределение по спринтам. Мы смотрели на оптимистичность, пессимистичность и реалистичность команд и приводили их к чему-то единому, равному. Кто был не нагружен — нагружали, а кто был перегружен — чуть помогали освободить их бэклог.

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

Процесс

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

Дальше идёт работа команд:

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

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

В электронном виде стало удобнее: появилась чёткая структура, добавилась лучшая сохранность артефактов. Каждая задача ставится в Confluence.

В среднем из запланированного делается по факту 70–80 %. Это очень качественный показатель.

Инвестиция в будущее

PIP’ы нужны потому, что планирование — это инвестиция в будущее. После планирования, когда все команды так два дня плотно поработали с бэклогами, с зависимостями, обсудили всё «на берегу», на последующие события, скрамы и планирование в команде уходит сильно меньше времени.

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