DevOps as a Service. Часть 5. Работа с бэклогом и сквозной приоритизацией команды

Всем доброе утро! С Вами Крылов Александр, и мы продолжаем серию статей про DevOps as a Service, и как с помощью данного подхода возможно решить ряд распространённых проблем в организации работы подразделения. В прошлых статьях мы описали подход и показали пути решения часто встречающихся проблем. С данными материалами можно ознакомиться тут Часть 1, Часть 2, Часть 3, Часть 4. Сегодня мы обсудим совмещение нескольких подходов для управления сквозным бэклогом команды.

Итак, проблема, которую мы будем решать — это отсутствие процесса работы с бэклогом и сквозной приоритизацией. Важно отметить, что инструменты, которыми я буду в основном оперировать, — это jira инсталляции server, плагин jira structure, jira kanban. Если реализация возможна на других инструментах, я буду в явном виде на них ссылаться. Но думаю, что в том или ином виде, подход можно переиспользовать и для других тикетных систем.

Начнём с описания пререквизитов, которые нам надо реализовать для того, чтобы система работала. Для начала напомню, что в Часть2 мы реализовали flow для issuetype devops в таком виде.

Наша статусная модель успешно работает по входящим в службу обращениям и никаких изменений тут не потребовалось. Это хорошо, потому что мы имеем отлаженный процесс, который не требует изменений, и по нему проходят регулярные встречи Daily (летучки) с пониманием того, что мы делаем в ближайшей перспективе - день и неделя. На ежедневных митингах каждый участник команды, включая вашего покорного слугу, рассказывает:

Казалось бы – всё стандартно, но в какой-то момент мы поняли, что есть дублирования и повторения, особенно, когда в наличии объёмные задачи, где просмотр под лупой объёма дел в сутки больше походит на микроменеджмент, чем контроль работы каждого. Поэтому было принято решения делать летучки 3 раза в неделю.

По понедельникам обсуждаем:

А по средам и пятница обсуждаем:

“Ну и причём тут бэклог и тем более сквозной?” - спросите вы. На что я отвечу: “Нам нужны все детали мозаики, чтобы вы поняли картину целиком.”

Поскольку есть flow, летучки на короткие периоды, а задач может быть 100+, то нужны инструменты контроля и временные срезы, по которым надо этот контроль осуществлять. Расширяем наш flow kanban методом, который позволяет делать планирование на более долгий период, например, спринт, который в нашем случае 3 недели.

Напомню, у нас есть типы работ = фильтрам на kanban = epic link в jira, по которым есть свои стейкхолдеры и это выглядит примерно так:

Что на kanban накладывается вот так:

В отличие от того, как это описано в Часть2, у нас добавились горизонтально размещённые удобные разделяющие фильтры по участникам нашей команды, что упрощает работу при больших объёмах задач, где фильтр = типам работ, а столбцы = шагам ранее упомянутого flow в issuetype devops. В настройках это выглядит так:

Отлично, есть flow, kanban, daily, есть 3-недельные спринты. Как будем их планировать?

Создаём jira structure –> structure, create structure и выбираем, что вам ближе.

По опыту, лучше делать пустую или agile.

После этого переходим в режим автоматизации и создаём папки, где каждая папка будет = задачам, входящим в epic link. Вот 3 варианта того, что можно использовать в качестве фильтров для построения содержимого папок:

После всех необходимых настроек у нас получается что-то вроде этого:

Для удобства, прокомментирую столбцы, которые тут добавлены:

Таким образом, у нас в одном месте в виде древовидной структуры есть отображение всех задач команды. То есть, мы видим весь бэклог команды с нужными нам разбивками.

Безусловно, это не всё, но тут стоит сделать ссылку на аналог в виде Notion, в котором так же есть возможность разбития задач по проектам с похожим набором полей. Покажу, как это может выглядеть на примере проекта с подкастами ProITStand:

Пользуемся, а мы возвращаемся к jira =)

Я не просто так напоминал про тип задач devops, в него можно добавлять кастомные поля, что мы и сделали. Мы добавили кастомное поле под названием “Приоритет DevOps”, которое в последствии переименовали в “RnDRank”, с возможностью введения только цифровых значений. На уровне заведения задач, это поле выглядит так:

Отлично, теперь мы можем проставлять сквозные приоритеты по задачам. Но по какой методике мы будем это делать? Мы будем использовать цифровые диапазоны, которые будут равны срокам взятия задачи в работу.

0 — это блокеры

1 - 20 — это приоритеты направлений epic link

20 - 50 — задачи первого приоритета 1-5 дней

51 - 70 — задачи второго приоритета 5-15 дней

71 - 100 — задачи третьего приоритета 15 – 30 дней

101 и выше — задачи бэклога с низким приоритетом, работы на квартал или год.

Исходя из этого, расставляем наши приоритеты и выводим поле в нашей структуре для отображения. Как мы это делаем? У нас есть:

Это и есть наши временные срезы, когда нам стоит уточнять приоритеты наших задач. Мы планируем объем работ на квартал и приоритезируем его со стейкхолдерами раз в 1,5 месяца, корректируя приоритеты на встречах, если необходимо. Внутри этих периодов у нас есть итеративные встречи, на которых уточняются приоритеты, например:

Поняв приоритеты и расставив их в нашей структуре по ранее созданному кастомному полю, мы получаем наглядный бэклог с сквозным приоритетом:

У нас добавился столбец RnDRank – это цифра сквозного приоритета. Для того чтобы управлять долгосрочными задачами со сроком более квартала, мы сделаем сквозной приоритет внутри сквозного приоритета, чтобы можно было ими “жонглировать”. Зачем это может потребоваться? Например, есть задача, которая важна, но она ждёт оборудования или есть понимание, что в текущий спринт или месяц она не попадает, но при этом мы не хотим выпускать её из фокуса. Мы ставим цифры в рамках диапазона 70-100, а дальше оперируем набором меток. Прежде всего на такие задачи ставится метка devops_backlog, а далее, в зависимости от степени важности, одна из следующих меток:

После чего контролируем такие задачи раз в спринт, то есть проводим встречи команды по задачам бэклога раз в 3 недели. Для удобства контроля капасити команды и того, сколько каждый боец может закрывать задач в спринт, было проведено небольшое исследование на базе фильтров jira и родилась такая таблица, перед представлением которой стоит ввести термин, чтобы больше понимания её содержимого.

Квант итерации выдоха – промежуток времени, когда участнику команды надо давать задач, чтобы он выдохнул. Например, участник команды Х решает в неделю 10-12 задач, в 3-недельный спринт это 30-36. На долгой дистанции поддерживать такой темп физически невозможно, человек просто сгорит, поэтому, раз в какой-то период времени ему надо передыхать от рутинных задач и выполнять инициативные, либо снижать на время, например, неделю общий объём задач. То есть, если мы говорим, что квант итерации выдоха равен 1 недели раз в 2 спринта, где 2 спринта это 6 недель, то это может быть, например, каждая 4 неделя в 2 спринтах. Теперь перейдём к таблице.

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

Для этого мы используем плагин jira – capacity tracker. Создаём в нём template configuration команду с ролями и проставлением рабочей недели

Связываем tempo teams с нашим проектом в jira и нашей kanban доской, если это ещё не сделано. Это важно для сквозной интеграции.

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

В итоге мы получаем общую картинку с capacity команды на спринт = 8 часов в день, 40 в неделю и 120 часов на спринт на основе списания времени в tempo трекер jira с показанием того, кто явно перерабатывает:

Что нам теперь делать со всей этой красотой?

Таким образом, используя плагины jira и несколько фреймворков работы с бэклогом, мы получили прозрачный процесс управление сквозным бэклогом задач команды.Спойлер – это была предпоследняя статья из этого цикла, следующая будет завершающей, а потом будет новый сериал или серия одиночных статей, ну а с вами был Крылов Александр, до новых встреч ;)
Теги:

#devops #процессы #управление #управлениекомандой