Дано: Компания, использующая фреймворк 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.
Ревью мы проводим на еженедельной основе, как для бизнес-инициатив, так и для архитектурных. В идеале это пятиминутная презентация с последующими ответами на вопросы. Результатом ревью является решение о дальнейшей судьбе инициативы. Она может:
На этом этапе мы – ура! – можем привлечь сотрудников из ИТ: аналитиков, архитекторов, лидов, кого угодно. Под “мы” я подразумеваю себя как 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.
Как результат, мы имеем примерно следующую картинку на Канбан-доске:
Конечно, мы еще даже не в середине пути, но на данный момент я уже могу отметить, что благодаря использованию Канбана на уровне Портфолио-Бэклога
Где-то за месяц до планирования наступает горячая пора подготовки. Слишком много нужно учесть, и чтобы ничего не забыть, приходится создавать многостраничную “логистическую” гугл-таблицу. Постараюсь описать наиболее важные табы из этой таблицы и активности вокруг них.
Обратная связь. Через несколько дней после каждого планирования мы проводим ретроспективу, и для корректировки курса важно не забыть, к каким выводам мы пришли и как нам нужно скорректировать курс. Это важная часть в разрезе непрерывного улучшения процесса.
Техническая подготовка. С переходом на удалённое планирование возникли специфические запросы, такие как качество интернет-связи (приоритизация и оптимизация маршрутов для JIRA и Confluence) и теле- и аудиоприсутствие (мы используем комплекты Logitec Group, микрофоны Jabbra и персональные наушники в различных комбинациях, веб-камеры, ПО Zoom для видеоконференций).
Фасилитаторы. Здесь собран список сотрудников, ответственных за фасилитацию в каждой из рабочих групп, с указанием их локации и линком на постоянный Zoom-канал рабочей группы.
Аудитория. Соответственно, полный список всех приглашённых.
Чеклист. Полный список важных задач с дедлайнами и ответственными. Для большего погружения, приведу несколько примеров наиболее характерных и важных задач, повторяющихся для каждого планирования: обучение фасилитаторов (подготовлена методичка для фасилитаторов со всеми необходимыми этапами от организации рабочей команды, тайминга встреч по исследованию вариантов технических решений и до процесса декомпозиции инициативы на список фичей); апдейт планов расположения рабочих групп для каждого офиса; контроль апдейта велосити для всех команд разработки; заказ обедов; создание репортов по предыдущим кварталам; распечатки списков инициатив (чтобы были под рукой) и расписаний.
После всей подготовительной беготни наступает, наконец, этот момент – старт квартального планирования. За два дня мы должны успеть разобрать все инициативы, убедиться, что информации достаточно и закоммититься. После нескольких коротких, но зажигательных речей рабочие группы расходятся по местам и берутся за дело. На данный момент количество групп распределено между тремя офисами по формуле 4х4х2, а удалённые пользователи подключаются к необходимому столу через выделенный Zoom-канал.
По окончанию дискавери каждой из инициатив фасилитатор, убедившись, что все необходимые данные – такие, как например критерии приёмки, описание технического решения, риски, зависимости, наличие необходимости в новой инфраструктуре – имеются, отмечает инициативу чекбоксом IT Session Finished для прозрачности прогресса и рабочая группа может переходить к следующей.
После десятка планирований ощущение постоянного нервного напряжения и временного цейтнота, которое было с нами с самого начала, значительным образом рассосалось, и сейчас атмосфера более напоминает спокойную работу. Во второй половине первого и второго дня наступает время неспешного коммитмента в соответствии с приоритетами. Для выполнения коммитмента у меня есть несколько отдельных структур. Первая из них — структура, содержащая список фичей и сторей, запланированных к коммитменту:
К сожалению, данная структура содержит остатки материала, не влезшего в коммитмент текущего квартала, так что выборка нерепрезентативна. В любом случае, в поиске я могу выбрать интересующую меня инициативу в порядке приоритета по номеру, который в процессе дискавери проставляется в отдельном поле для каждой фичи и стори, поменять статус необходимых задач с Planned на Committed и поместить в нужную итерацию, тем самым закоммитившись:
В результате чего задача исчезнет из данной структуры и появится в новой, отражающей растущий коммитмент:
Как видно на скриншоте, в этой структуре стори попадают в папку команды разработки, которой они принадлежат, и группируются по итерациям. Здесь же я вижу общий велосити команды в названии папки, а также в колонке Commitment с помощью формулы автоматически определяется оверкоммитмент по каждой группе и сигнализирует нам красным цветом.
Само собой, если первые и наиболее приоритетные инициативы заходят в коммитмент без проблем, в скором времени, с появлением первых команд, набивших свой бэклог до отказа, начинаются проблемы и некоторые инициативы не без споров, но приходится откладывать.
По окончанию сего немудрёного процесса команды на флаге компании торжественно клянутся доставить коммитмент (шутка) и разбегаются по домам (тоже шутка – все разбегаются по барам).
Пока все пьют водку, RTE работает над созданием коммитмента в том виде, в котором его можно раздать в бэклоги команд разработки и мониторить в течение всего квартала. Для этого я использую плагин ‘Bulk Clone Professional for Jira’ — он добавляет пункт, обеспечивающий коллективное клонирование, в меню Bulk Change, и обладает такими нужными для меня возможностями, как клонирование ссылок, обновление ссылок между свежесозданными клонами, обновление эпик-линков, добавление префикса в заголовок и автоматическое добавление ярлыка:
Я добавляю статус в качестве префикса, поскольку на этапе планирования статусы отражают планируемую итерацию завершения, и в итоге я сразу в заголовке вижу, когда мы планируем закончить фичу или стори.
Сначала я клонирую абсолютно все задачи в отдельный проект Global Backlog, поскольку в нём мы храним эпики, а мне нужно иметь актуальные связи эпик — стори в свежесклонированных задачах. И уже в качестве второго шага я делаю запросы по каждой команде разработки отдельно и перемещаю стори в конечные проекты команд.
Как итог, я создаю структуру, отражающую текущий коммитмент и состоящую из конечных задач, которую потом использую для мониторинга:
В целом, преимущества, которые появились в результате такого подхода, следующие:
Друзья, я, конечно, понимаю, что описание довольно поверхностное, и еще кучу вещей можно было бы раскрыть подробнее — мониторинг распределения капасити между бизнес- и архитектурными инициативами и операционными задачами, расчёт формул в структурах, управление рисками и многое другое. Но мне пока непонятно, интересна ли данная тема аудитории, и если да, то что именно. Если я увижу заинтересованность, то буду готов раскрыть нужные темы.
И еще один момент – тяжело верится в то, что это возможно, но всеми силами хотелось бы избежать срача вокруг эджайла, фреймворков, эффективных и “эффективных” менеджеров. Пожалуйста, помните, что я описал весь процесс в надежде заинтересовать людей, которым это близко, его технической реализацией, и очень жду соответствующих дискуссий.
До встречи в комментариях!
* Тяжеловесный конструкт “План работы ИТ-команд на ближайшие 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, поскольку в нём мы храним эпики, а мне нужно иметь актуальные связи эпик — стори в свежесклонированных задачах. И уже в качестве второго шага я делаю запросы по каждой команде разработки отдельно и перемещаю стори в конечные проекты команд.
Как итог, я создаю структуру, отражающую текущий коммитмент и состоящую из конечных задач, которую потом использую для мониторинга:
В целом, преимущества, которые появились в результате такого подхода, следующие:
- Как ни банально, но новые фичи и стори человеку из ИТ легче напечатать, чем написать маркером на липкой бумажечке.
- Многие вещи, такие как остаток капасити и апдейт WSJF в зависимости от оценок сторей, рассчитываются автоматически с помощью формул.
- Благодаря клонированию изначальный слепок коммитмента сохраняется для истории и к нему можно всегда вернуться.
- Очень сильно экономится время и энергия на подготовке планирования – работа с бумагой отнимает силы.
- Конечно, здорово, что больше не нужно набивать таски в джиру с бумажечек.
Инструменты, используемые на данном этапе:
- Atlassian Jira Software Server
- Плагин ‘Bulk Clone Professional for Jira’ – для клонирования фичей и стори в конечные JIRA-проекты.
- Плагин ‘Structure — Project Management at Scale’ – для создания финальной структуры.
Эпилог
Друзья, я, конечно, понимаю, что описание довольно поверхностное, и еще кучу вещей можно было бы раскрыть подробнее — мониторинг распределения капасити между бизнес- и архитектурными инициативами и операционными задачами, расчёт формул в структурах, управление рисками и многое другое. Но мне пока непонятно, интересна ли данная тема аудитории, и если да, то что именно. Если я увижу заинтересованность, то буду готов раскрыть нужные темы.
И еще один момент – тяжело верится в то, что это возможно, но всеми силами хотелось бы избежать срача вокруг эджайла, фреймворков, эффективных и “эффективных” менеджеров. Пожалуйста, помните, что я описал весь процесс в надежде заинтересовать людей, которым это близко, его технической реализацией, и очень жду соответствующих дискуссий.
До встречи в комментариях!
paulousky
Большое спасибо за статью! Оч актуально
Есть ли у Вас end to end QA team? Если да, на сколько для них такой подход удобан для определения скоупа тестирования
pooh81 Автор
Спасибо! Наши тестеры являются полноправными членами команд разработки, и в полной мере участвуют в планировании. Скажем так, подход для них удобен не более и не менее, чем разработчикам )