Как провести распределённое безбумажное квартальное планирование и не облажаться?

Дано: Компания, использующая фреймворк Scaled Agile (SAFe) для масштабирования Agile-разработки в рамках всей организации; 10 команд разработки, объединённых в одну большую команду (Agile Release Train, согласно терминологии SAFe), доставляющую общий продукт; необходимость проведения двухдневного квартального планирования (PI Planning) для определения плана работы ИТ-команд на ближайшие 3 месяца*; три офиса разработки, расстояние между самыми удалёнными превышает 6 тысяч километров с соответствующей разницей в 5 часов рабочего времени; предыдущий опыт планирования, предусматривавший физическое присутствие ключевых коллег в одном помещении и использование аналоговых досок/вайтбордов/маркеров/липких бумажечек.

* Тяжеловесный конструкт “План работы ИТ-команд на ближайшие 3 месяца” грозит серьёзно увеличить объем текста, поэтому в дальнейшем я планирую вместо него писать просто – “коммитмент”. Соответственно, составить и принять план работы – “закоммититься”.

Зачем это понадобилось?

1) Усталость от аналоговых методов работы. В то время, как космические корабли бороздят просторы, а Илон Маск роет тоннели, мы, «айтишники», упорно пишем маркерами на липучих бумажках и лепим их на доски – есть в этом некий диссонанс. Так выглядел наш коммитмент некоторое время назад:


Да, это лист бумаги размером примерно 2х5 метров, и каждую бумажку следовало после планирования превратить в задачу в Джире…

2) Усталость коллег-кочевников. Несмотря на то, что головной офис у нас расположен в довольно таки приветливой, тёплой стране, к моему удивлению в прошлом году я узнал, что они совсем не рады такой своей кочевой жизни, и мои аргументы в стиле «да ладно, в море покупаетесь, на солнышке погреетесь», которые я имел неосторожность высказать, были восприняты не очень тепло – не все готовы к частым командировкам, их домочадцы не всегда это приветствуют, у кого-то организм на частые перелёты реагирует не очень хорошо.

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

4) Оптимизация финансовых затрат. Да, это чувствительный момент – ключевых людей достаточно много, и возить их самолётами туда-сюда четыре раза в год – накладное дело.

Часть Нулевая, или Работа с Портфолио-Бэклогом

А начинается всё гораздо раньше – для того, чтобы плодотворно работать над коммитментом во время планирования, необходимо, чтобы было под что коммититься. Чтобы обеспечить это, мне приходится “загружать” бизнес-владельцев работой над предполагаемыми инициативами (или, в терминологии SAFe, Эпиками, но я буду использовать привычный для меня термин) как можно раньше. В идеале этот процесс должен быть полностью оторван от цикличности квартальных планирований и идти своим, канбанным путём. За основу мы взяли SAFe portfolio Kanban:

У нас есть отдельный JIRA-проект с тремя типами задач: эпики, бизнес-инициативы и архитектурные инициативы; а также соответствующая Канбан-доска. Алгоритм для бизнес-владельца инициативы прост: он добавляет задачу в этот проект, и она по дефолту попадает в Бэклог – это первый статус нашего канбана — Funnel:

Там хранятся инициативы, еще не готовые к ревью. Бизнес-владелец работает над содержанием инициативы, пока не почувствует себя готовым к следующему шагу. Минимум, необходимый на этом этапе – заполненные поля Problem Statement, Desired Outcome и Measure of Success, а также чуть более развёрнутая, но простая и понятная презентация. На данном этапе важно уйти от упоминания технических решений и сконцентрироваться на бизнес-параметрах. Когда все данные собраны, владелец двигает задачу в следующий статус – Reviewing.

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

• уйти обратно в бэклог на доработку
• упраздниться без шанса на дальнейшую жизнь (для этого я использую отдельный статус Out-of-Date, скрытый на Канбан-доске)
• получить согласование и пройти на следующий этап – Analyzing.

На этом этапе мы – ура! – можем привлечь сотрудников из ИТ: аналитиков, архитекторов, лидов, кого угодно. Под “мы” я подразумеваю себя как Release Train Engineer’a, но в идеальном случае бизнес-владельцев, которые уже обрели некий опыт работы и самостоятельность, необходимую для привлечения нужных команд и самостоятельного запуска процесса аналитики. Пишу про идеальный случай, поскольку уровень самоорганизации наших коллег плавает, и в некоторых случаях они просят помощь в виде специально назначенного фасилитатора, но от данной практики я стараюсь понемногу отойти.

Цель данного этапа — предварительная аналитика, или, как мы её называем, пре-дискавери. На выходе мы должны получить тот минимум, который позволит нам закоммититься: предлагаемые решения, риски и зависимости, нефункциональные и инфраструктурные требования, пользовательские карты (user maps), архитектурные схемы. Дополнительно мы просим команды дать предварительную оценку в стори-поинтах (story points) на уровне фичей – это позволит нам в конце квартала определить приоритеты.

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

Также на этапе аналитики в этот процесс привлекаются архитекторы или, как у нас принято в последнее время, их доверенные люди – “амбассадоры” (EA Ambassadors). Их задача – донести до участников процесса видение архитектурного департамента, помочь найти наилучшее решение и в конце концов согласовать данное решение с главным архитектором компании (Head of Enterprise Architecture).

Когда команды считают, что инициатива достаточно проработана и готова к следующему шагу, они двигают её в следующий статус – Portfolio Backlog.

На этом этапе важный шаг – провести WSJF-приоретизацию (Weighted Shortest Job First). Для этого за 3 недели до планирования мы проводим большую встречу, которая пока, к сожалению, занимает многие часы, и во время этой встречи с помощью покера по шкале Фибоначчи члены менеджмент-борда оценивают бизнес-ценность (Business Value), критичность по времени (Time Criticality), потенциальное уменьшение рисковости (Risk Reduction) и реализацию возможностей (Opportunity Enablement):

Чтобы иметь возможность отслеживать историю инициатив, к каждой из них я добавляю ярлык (label) в джире с данными о квартале: 2018Q4, 2019Q1 и т.д.

Забегая вперёд, опишу следующие возможные статусы. После проведения коммитмента инициативы, успешно взятые в работу, переезжают в статус Implementing, а “невлезшие” получают статус Parked и в дальнейшем имеют возможность быть рассмотренными для следующих кварталов. Доставленные же инициативы переезжают в Done.

Как результат, мы имеем примерно следующую картинку на Канбан-доске:

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

Инструменты, используемые на данном этапе:

• Atlassian Jira Software Server
• Плагин Colors for Jira – для подсвечивания бизнес- и архитектурных инициатив
• Плагин ‘Structure – Project Management at Scale’ — для визуализации структуры из инициатив с прилинкованными к ним фичами и их WSJF-приоретизации
• Atlassian Confluence – источник внутренней документации
• Lucidchart и его плагины для Jira и Confluence – для рисования диаграм

Часть I. Подготовка к планированию

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

Обратная связь. Через несколько дней после каждого планирования мы проводим ретроспективу, и для корректировки курса важно не забыть, к каким выводам мы пришли и как нам нужно скорректировать курс. Это важная часть в разрезе непрерывного улучшения процесса.

Техническая подготовка. С переходом на удалённое планирование возникли специфические запросы, такие как качество интернет-связи (приоритизация и оптимизация маршрутов для JIRA и Confluence) и теле- и аудиоприсутствие (мы используем комплекты Logitec Group, микрофоны Jabbra и персональные наушники в различных комбинациях, веб-камеры, ПО Zoom для видеоконференций).

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

Аудитория. Соответственно, полный список всех приглашённых.

Чеклист. Полный список важных задач с дедлайнами и ответственными. Для большего погружения, приведу несколько примеров наиболее характерных и важных задач, повторяющихся для каждого планирования: обучение фасилитаторов (подготовлена методичка для фасилитаторов со всеми необходимыми этапами от организации рабочей команды, тайминга встреч по исследованию вариантов технических решений и до процесса декомпозиции инициативы на список фичей); апдейт планов расположения рабочих групп для каждого офиса; контроль апдейта велосити для всех команд разработки; заказ обедов; создание репортов по предыдущим кварталам; распечатки списков инициатив (чтобы были под рукой) и расписаний.

Часть II. Планирование и коммитмент

После всей подготовительной беготни наступает, наконец, этот момент – старт квартального планирования. За два дня мы должны успеть разобрать все инициативы, убедиться, что информации достаточно и закоммититься. После нескольких коротких, но зажигательных речей рабочие группы расходятся по местам и берутся за дело. На данный момент количество групп распределено между тремя офисами по формуле 4х4х2, а удалённые пользователи подключаются к необходимому столу через выделенный Zoom-канал.

По окончанию дискавери каждой из инициатив фасилитатор, убедившись, что все необходимые данные – такие, как например критерии приёмки, описание технического решения, риски, зависимости, наличие необходимости в новой инфраструктуре – имеются, отмечает инициативу чекбоксом IT Session Finished для прозрачности прогресса и рабочая группа может переходить к следующей.

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

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

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

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

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

По окончанию сего немудрёного процесса команды на флаге компании торжественно клянутся доставить коммитмент (шутка) и разбегаются по домам (тоже шутка – все разбегаются по барам).

Инструменты, используемые на данном этапе:

• Atlassian Jira Software Server
• Плагин ‘Structure – Project Management at Scale’ – для мониторинга процесса дискавери и во время выполнения коммитмента.

Часть III. Клонирование задач в рабочую JIRA-экосистему компании

Пока все пьют водку, RTE работает над созданием коммитмента в том виде, в котором его можно раздать в бэклоги команд разработки и мониторить в течение всего квартала. Для этого я использую плагин ‘Bulk Clone Professional for Jira’ — он добавляет пункт, обеспечивающий коллективное клонирование, в меню Bulk Change, и обладает такими нужными для меня возможностями, как клонирование ссылок, обновление ссылок между свежесозданными клонами, обновление эпик-линков, добавление префикса в заголовок и автоматическое добавление ярлыка:

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

Сначала я клонирую абсолютно все задачи в отдельный проект Global Backlog, поскольку в нём мы храним эпики, а мне нужно иметь актуальные связи эпик — стори в свежесклонированных задачах. И уже в качестве второго шага я делаю запросы по каждой команде разработки отдельно и перемещаю стори в конечные проекты команд.

Как итог, я создаю структуру, отражающую текущий коммитмент и состоящую из конечных задач, которую потом использую для мониторинга:

В целом, преимущества, которые появились в результате такого подхода, следующие:

Инструменты, используемые на данном этапе:

• Atlassian Jira Software Server
• Плагин ‘Bulk Clone Professional for Jira’ – для клонирования фичей и стори в конечные JIRA-проекты.
• Плагин ‘Structure — Project Management at Scale’ – для создания финальной структуры.

Эпилог

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

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

До встречи в комментариях!

Автор: pooh81

Источник