Как анализировать метрики Канбан-систем в Jira

Друзья, всем привет!

Сегодня разберемся, как собирать некоторые базовые Канбан-метрики: время выполнения, уровни количества задач в работе, пропускную способность (System Lead Time, WIP Level, Throughput) и др. в Jira– пожалуй, самой популярной системе таск-трекинга, особенно в корпорациях. Статья написана на основе нашего с Кириллом Семеновым опыта работы с продуктовыми командами в С7 Group.

Стандартными инструментами Jira собрать эти метрики крайне сложно. А потребность в них возникает, когда вы:

  • решили перейти на третий уровень зрелости использования Канбан-метода и вам нужны метрики для принятия решений на основе данных, а не предположений.
  • хотите провести обзор сервиса поставки и вам нужны данные о том, как он сейчас работает.
  • хотите понять поведение потоковых систем.

В качестве рабочих инструментов мы используем расширения Jira Flow Companion и Jira-Helper для браузера Google Chrome. Покажем, как использовать их для анализа метрик на классических проектах для разработки ПО в JIRA.

Недавно в Jira появились проекты с типом “Проект для разработки ПО нового поколения” и они доступны только в Jira Cloud. Анализ метрик в таких проектах мы рассмотрим в следующих публикациях. 

Настройка Канбан-доски в JIRA

Начнем с небольшой подготовки Канбан-доски в JIRA.

Предусловия: для упрощения всех последующих шагов я настоятельно рекомендую провести воркшоп STATIK перед тем, как вы начнете все настраивать в JIRA. 

Сам алгоритм настройки (в очень упрощенном виде) выглядит следующим образом:

  1. Создаем необходимый набор типовых рабочих элементов в проекте JIRA.
  2. Создаем необходимый рабочий процесс (или несколько рабочих процессов для разных типовых рабочих элементов) в проекте JIRA.
  3. Создаем на основе проекта Канбан-доску в JIRA.
  4. Настраиваем внешний вид Канбан-доски:
    1. Колонки.
    2. Дорожки.
    3. Быстрые фильтры (они понадобятся вам для оценки метрик по типам или размеру рабочих элементов, классам обслуживания, продуктам или командам, если на доске их несколько).
Рис. 1 Настройка Канбан-доски в Jira.
Рис. 1 Настройка Канбан-доски в Jira.

Устанавливаем расширение Jira Flow Companion (помните про необходимость отключения опции SameSite на время анализа метрик) и jira-Helper для браузера Google Chrome.

После этого можно переходить непосредственно к анализу метрик.

Анализ метрик с Канбан-досок в Jira

Определение точки отсчета

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

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

Системное время выполнения и прочие метрики потока снимаются внутри указанного диапазона. 

Рис. 2. Определение точек принятия и возврата обязательств.
Рис. 2. Определение точек принятия и возврата обязательств.

Анализ системного времени выполнения (System Lead Time)

Системное время выполнения (System Lead Time) — время выполнения запроса с момента принятия обязательств. Показывает фактическое время выполнения типового рабочего элемента. Помогает определить ожидания SLA.

Алгоритм анализа системного времени выполнения:

  1. Открыть Канбан-доску в JIRA.
  2. Нажать на кнопку Analyze flow.
  3. Переключиться на вкладку Lead Times.
  4. Выбрать колонку – начало отсчета в поле “Start state”.
  5. Выбрать шаг шкалы распределения “Resolution”, для типовых проектов удобнее всего разрешение в 1 день. Если у вас время типовое выполнения рабочих элементов превышает пару недель, имеет смысл выбрать разрешение в неделю. 
  6. Выбрать нужный срез задач в Quick Filters.
  7. Оценить 85 перцентиль времени выполнения (оранжевая линия на графике).  Это – вероятность сроков выполнения типового рабочего элемента за указанное время.
Рис. 3. Диаграмма распределения времени выполнения пользовательских историй.
Рис. 3. Диаграмма распределения времени выполнения пользовательских историй.

Пример анализа системного времени выполнения

На графике выше видно, что пользовательские истории данный сервис поставляется с вероятностью 85% за 12 недель.

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

Анализ контрольной диаграммы (Control Chart)

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

Алгоритм анализа контрольной диаграммы:

  1. Открыть Канбан-доску в JIRA.
  2. Перейти на вкладку Reports.
  3. Открыть стандартный Jira-отчет Control Chart.
  4. Выбрать колонки, по которым строим график, начиная с точки отсчета.
  5. Выбрать дорожки.
  6. Выбрать тип рабочего элемента.
  7. Указать желаемый SLA в днях.
  8. Проанализировать реальные возможности поставки (время выполнения типового рабочего элемента).
Рис. 4. Анализ SLA для пользовательских историй на контрольной диаграмма.
Рис. 4. Анализ SLA для пользовательских историй на контрольной диаграмма.

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

Видео 1. KEA20 – Павел Ахметчанов, Control Chart в JIRA, все ее тайны.
Видео 2. KEA20 – Сергей Титков, Анализ частотных диаграмм.

Анализ отношения спроса и возможностей системы (Demand vs Capability)

Отношение спроса и возможностей показывает количество поступающей и выполненной работы в системе.

Алгоритм анализа соотношения поступающей работы с выполненной:

  1. Открыть Канбан-доску в JIRA.
  2. Нажать на кнопку Analyze flow.
  3. Переключиться на вкладку Flow.
  4. Выбрать в поле Report Type “Backlog Growth”.
  5. Выбрать нужный шаг времени выполнения “Iteration length”.
  6. Оценить прирост бэклога и пропускную способность команды.
Рис. 5. Диаграмма спроса и возможностей.
Рис. 5. Диаграмма спроса и возможностей.

Пример анализа соотношения поступающей работы с выполненной

На данном графике видно, что сначала был довольно большой прирост задач в бэклоге сервиса, но со временем новые задачи практически перестали поступать. При этом сервис стабильно делает небольшие поставки. 

Здесь не хватает быстрых фильтров по типам рабочих элементов. Это бы позволило посмотреть, сколько конкретно какой работы приходит и сколько поставляется. 

Анализ влияния блокеров (Blockers/Impact)

Анализ заблокированных элементов – залог улучшения надежности поставки Канбан-системы в долгосрочной перспективе. 

Алгоритм анализа влияния блокеров на время выполнения в системе:

  1. Открыть Канбан-доску в JIRA.
  2. Нажать на кнопку Analyze flow.
  3. Переключиться на вкладку Lead Times.
  4. Выбрать колонку-начало отсчета в поле “Start date”.
  5. Выбрать шаг времени выполнения “Resolution”.
  6. Выбрать нужный тип рабочего элемента в Quick Filters.
  7. Поставить галочку в поле Show report as table.
  8. Проанализировать задачи, время выполнения которых вышло за 85 процентиль:
    1. Открыть их в JIRA (они внизу таблицы).
    2. Перейти на вкладку History.
    3. Проанализировать блокировки и их причины.
    4. Принять системные решения по устранению причин.
Рис. 6. Диаграмма распределения времени выполнения с областью задач из зоны риска.
Рис. 6. Диаграмма распределения времени выполнения с областью задач из зоны риска.

Анализ накопительной диаграммы потока (Cumulative Flow Diagram)

Накопительная диаграмма потока (Cumulative Flow Diagram) показывает количество элементов в системе в целом или на определенных этапах.

Алгоритм анализа накопительной диаграммы потока:

  1. Открыть Канбан-доску в JIRA.
  2. Нажать на кнопку Analyze flow.
  3. Переключиться на вкладку CFD.
  4. Если хотите проанализировать не весь проект, а определённый период, например, последний квартал, выберите период или Start Date и отметьте опцию “Done starts from 0”
  5. Проанализировать текущие количество задач в работе на всех этапах system lead time.
Рис. 7. Накопительная диаграмма потока.
Рис. 7. Накопительная диаграмма потока.

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

Анализ уровня инноваций в бэклоге (Innovation Rate)

Показывает количество задач разных типов: на развитие, поддержку и т.д.

Алгоритм анализа уровня инновационных решений в бэклоге продукта:

  1. Открыть Канбан-доску в JIRA.
  2. Нажать на кнопку Analyze flow.
  3. Переключиться на вкладку CFD.
  4. Выберите Quick Filter для анализа текущих значений WIP по всем типам рабочих элементов:
    1. новое;
    2. поддержка;
    3. исправление дефектов;
    4. др.
Рис. 8. Накопительная диаграмма потока по пользовательским историям.
Рис. 8. Накопительная диаграмма потока по пользовательским историям.

Анализ частоты релизов (Release Frequency)

Метрика показывает частоту релизов за период.

Алгоритм анализа частоты релизов:

  1. Открыть Канбан-доску в JIRA.
  2. Перейти на вкладку Reports.
  3. Открыть стандартный Jira-отчет Control Chart.
  4. Выбрать все колонки.
  5. Выбрать дорожки.
  6. Выбрать все типы рабочих элементов.
  7. Проанализировать регулярность группового закрытия задач, если вы поставляете рабочие элементы пачками.
Рис. 9. Контрольная диаграмма с отсечками по поставкам сервиса.
Рис. 9. Контрольная диаграмма с отсечками по поставкам сервиса.

Анализ показателя отказов (Discard Rate)

Метрика показывает количество задач, которые были выброшены до точки принятия обязательств, то есть из бэклога.

Алгоритм анализа количества выброшенных задач:

  1. Настройка: для подсчета задач, от которых отказались, нужно использовать значение “won’t do” в поле resolution в момент закрытия задачи. 
  2. Чтобы найти все выброшенные задачи, нужно открыть вкладку “Search for issues” в JIRA. В поле поиска набрать “project = STL AND status = DONE AND resolution = “Cancelled” AND resolved >= -4w”, где project – ваш проект в JIRA.
Рис. 10. Фильтр по отклоненным задачам.
Рис. 10. Фильтр по отклоненным задачам.

Алгоритм по подсчету показателя отказов дополняется.

Заключение и еще раз, для чего это всё нужно

Анализ Канбан-метрик в Jira до сих остается нетривиальной задачей. Однако сегодня сделать это гораздо проще, чем еще пару лет назад. 

Используя описанные выше подходы, вы сможете существенного упростить себе подготовку к обзору сервиса поставки и обсудить с заказчиками реальные ожидания от работы сервиса.

Ну а если у вас есть свой алгоритм анализа метрик, присылайте его на school@filipyev.ru. Я с удовольствием поделюсь вашим опытом с читателям блога.

Удачи, друзья! 

С вами как всегда был Игорь Филипьев и Школа Канбана.

За ревью спасибо Жене Степченко (Telegram: @StepEv).

Мы используем cookie-файлы. Оставаясь на сайте, вы соглашаетесь с политикой конфиденциальности.
Хорошо