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

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

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

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

• кто и что сделал за предыдущий день;

• какие были достижения или провалы;

• что удалось сделать, а где нужна помощь;

• последние новости, если таковые имелись по процессам и компании;

• планы на будущий день.

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

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

• у кого какие новости, кто как провёл выходные (до 4 мин на человека). Это небольшой командообразующий элемент, чтобы все наши разговоры сводились не только к работе;

• основные планы на неделю с расставлением акцентов всего подразделения;

• достижения и провалы за прошлую неделю;

• последние новости со встреч;

• объём работы каждого сотрудника на неделю со сроками и приоритетами.

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

• текущие задачи;

• сложности, если они есть;

• пересматриваем приоритеты с “горячими пирожками”, если такие прилетают;

• новые проблемы, если появились;

• последние новости с встреч;

• прочее.

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

Поскольку есть 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 варианта того, что можно использовать в качестве фильтров для построения содержимого папок:

1. Фильтр назначения на всех участников команды на самом верхнем уровне, с исключением, например, всех решённых задач, чтобы показаны были только те, что не закрыты

2. Фильтр = папке = типу работ. В данном случае troubleshooting

3. Иные фильтры по меткам и т.д.

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

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

• Sprint – номер спринта;

• Код – код задачи;

• Тема – заголовок задачи;

• Исполнитель – исполнитель задачи;

• Создано – дата создания задачи;

• Срок исполнения – планируемый срок завершения задачи;

• Первоначальная оценка – планируемый срок решения задачи.

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

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

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

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

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

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

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

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

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

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

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

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

• стейкхолдеры активностей;

• аллокации на квартал;

• приоритеты;

• временные отрезки в 3 недели на спринт и квартал на инкремент.

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

• еженедельный SOS (Scrum of Scrum);

• еженедельное планирование команды по понедельникам;

• еженедельный статус RnD и внедрений;

• летучки на неделе;

• внеплановые встречи по повышению приоритета задач или при поступлении “горячих пирожков” и т.д.

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

У нас добавился столбец 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 с показанием того, кто явно перерабатывает:

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

1. Еженедельно у нас есть понятные критерии изменения приоритетов по задачам спринта

2. Раз в спринт мы принимаем участие в спринтовом планировании и приоритизации наших задач в нём с формированием капасити команды

3. Внутри спринта есть понятные механизмы контроля бэклога и изменения приоритетов

4. Раз в 1,5 месяца есть точка контроля глобальных приоритетов задач инкремента

5. Следить на спринтовой основе за нагрузкой команды.

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

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