Привет! Меня зовут Анастасия Никонорова, я аналитик в Авито. Рассказываю, как мы сделали инструмент в Tableau для наших scrum-команд разработки.
Сначала опишу, как мы работаем по Agile и Scrum, потом — как подготавливали данные и создавали инструмент, как его внедряли и какие результаты получили. В конце статьи будет пара лайфхаков по визуализации в Tableau, которые пригодятся аналитикам.
Как работают команды разработки
Наши команды работают по Agile. Это подход к разработке программного обеспечения и других продуктов, который помогает подстраиваться под быстро меняющиеся условия рынка. Если вы знакомы с методологией, можно пропустить этот раздел и сразу перейти к следующему.
Главные принципы Agile:
Гибкость. Например, на рынке появляется новое направление. Нам нужно быстро перестроить работу, чтобы быть первыми и получить выгоду. Методология Agile позволяет это сделать.
Инкременты, или частые релизы. Мы создаём маленькие части работающего продукта и постепенно его улучшаем. Это позволяет быстро заметить, если что-то пошло не так, и скорректировать план.
Прозрачные процессы. Мы видим на доске в Jira, сколько задач взяла в работу команда и в каком статусе каждая. Команда, заказчик и продакт-оунер примерно понимают, какие у тасков приоритеты и когда эти задачи будут выполнены.
Scrum — это одна из методологий Agile. Наши команды работают короткими интервалами — спринтами, которые длятся 1–2 недели.
Команды регулярно встречаются, чтобы вместе оценить задачи по сложности в условных единицах — сторипоинтах. Это нужно, чтобы вычислять объём работы, которую команда может выполнить за спринт.
Каждый спринт состоит из нескольких этапов:
Планирование. Команда собирает в бэклог задачи, которые будет делать в рамках спринта.
Работа над задачами и ежедневные встречи. Во время спринта могут появляться дополнительные задачи, например срочное исправление багов. Каждый день все члены команды рассказывают, что было вчера, что будут делать сегодня и с какими проблемами они столкнулись.
Спринт-ревью. Команда показывает заказчикам, что сделала за спринт, и презентует инкремент, который получила.
Ретроспектива. После завершения спринта команда обсуждает, что было хорошо, а что — не очень. Цель этапа — понять, как нам в будущем избежать проблем, которые проявились во время спринта, и придумать, как ещё можно улучшить процесс.
Почему было сложно анализировать работу команд и как пытались это изменить
Раньше у нас не было общих метрик в Jira. Команды вели проекты, как им было удобно, и использовали разные поля для задач. Мы не могли объединить данные в один источник, чтобы сравнить их. А ещё в одном проекте в Jira «жили» несколько команд, поэтому было сложно понять, где чьи задачи.
Сначала мы создали большую (очень большую!) таблицу в Google Spreadsheets, чтобы тимлиды заносили руками все метрики по командам и спринтам. Вести такую таблицу суперресурсоёмко, а в данных часто появлялись погрешности.
Мы решили всё автоматизировать и для этого создали свой инструмент. Что от него хотели:
Видеть в едином окне метрики здоровья команд, чтобы быстро реагировать, если в команде что-то идёт не так.
Выделять проблемы в продуктивности.
Детально понимать, с чем именно связаны эти проблемы.
Как готовили данные
Чтобы добиться однородности данных, мы установили требования, как команды должны вести Jira.
Ввели обязательное поле Feature Team — это команда, которая делает задачу. Стали видны задачи разных команд в одном проекте.
Добавили типы тасков Sprint Goal и Retro Action Item. Цели спринта отмечаются типом Sprint Goal. Раньше они нигде не фиксировались, а теперь видно, к чему идёт команда весь спринт. Retro Action Item — это действия, которые мы выявили на ретроспективе. Их тоже стали заносить в бэклог и брать в спринт, когда есть возможность.
Сделали обязательной оценку всех задач в сторипоинтах или часах.
Так мы получили унифицированные данные, которые лежат в Jira. Затем собрали информацию в базу:
Через API Jira получили данные в JSON-файл.
Сложили их в нашу базу данных Vertica и создали там таблицу.
Создали views для Tableau-источника и настроили логику, чтобы делать отчёты.
Мы выбрали уровень детализации «задача + спринт». Задачи иногда перетекают из одного спринта в другой, и мы хотели такие моменты отслеживать.
Как мы сделали свой инструмент в Tableau
Вот как выглядит наш инструмент.
Сейчас расскажу, какие метрики здесь отражены и что они показывают.
Initial Scope Drop
Плохо, если показатель превышает 20%. Он сигнализирует, что команда не держит фокус на плановых задачах спринта, поэтому её работу сложно прогнозировать.
Done Total
С помощью метрики мы определяем, насколько адекватно команда оценивает свою нагрузку на спринт. Показатель меньше 80% значит, что команда берёт в спринт намного больше, чем может сделать.
Sprint Goals
Если цель спринта одна, то показатель выполнения должен быть равен 100%. Бывают случаи, когда команда заводит несколько целей и не успевает их выполнять — тогда значение показателя может быть другим.
Bug Policy SLA
В первом графике Bug Policy мы выводим количество багов, которые были решены поздно и превысили SLA. Пустые пространства между столбиками — это спринты, где вообще не было просроченных багов.
На втором графике Bug Policy мы смотрим, какой процент багов команда просрочила.
Velocity Chart
Среднее значение Velocity команды нужно, чтобы адекватно оценить, как работает команда и сколько задач может взять.
Cycle Time
Мы можем посмотреть, сколько в среднем у команды занимает решение задачи такого типа. Это нужно, чтобы прогнозировать нагрузку.
Retro Action Item
Когда команда заводит таски в бэклоге, увеличивается синяя зона to-do. На нашем графике видно, что у команды накопилось много задач to-do, но в in-progress почти ничего нет — серая зона маленькая. Значит, задачи с ретроспективы никто не делает, это плохо для процесса.
Общие показатели по команде мы вынесли над графиками — это Scope Drop, Done Total, прогрумленность бэклога и медианная Velocity.
Низкий коэффициент прогруммленности, как на примере, сигнализирует, что в бэклоге мало задач с оценками. Это значит, что тимлиду и команде надо встретиться, чтобы оценить таски.
Например, если показатель меньше 1, то на планировании нового спринта придётся грумить задачи. Если какой-то таск команда не может выполнить и на время блокирует в течение спринта, то надо будет снова грумить задачи, чтобы взять новые. Такой груминг происходит внепланово. В спринте есть одна встреча, когда разбор задач запланирован по расписанию, а в ситуации выше его придётся провести внепланово.
Как внедряли новый инструмент
Когда мы только создавали инструмент, то регулярно встречались с тимлидами и scrum-мастерами. Мы обсуждали, как они будут использовать отчёты. Потом провели обучение для scrum-команд, которым было интересно поучаствовать в процессе. Первую рабочую версию инструмента запустили 28 октября 2020 года.
Мы видим путь пользователя как переход от более общих показателей к частным, поэтому сделали три вида того, как отображаются дашборды:
Общий вид — это то, как видят дашборд кластер-лид и юнит-лид. Например, в юните может быть 6 команд. Если по каждой смотреть детальную информацию, то сложно сопоставить данные и определить, где проблема. Поэтому мы сделали общий вид, куда юнит-лид может зайти и сразу увидеть проблемные места.
Вид по команде, где мы подробно изучаем информацию о ней и находим инсайты.
Детали по задачам. Мы можем провалиться в любой показатель на графике и понять, какие задачи были в этом спринте. Например, заходим в Sprint Goal, смотрим таски, их описания и переходим по ссылке в Jira.
Как это работает в целом:
Юнит-лид видит на общем плане, что у одной из команд красный показатель по Scope Drop.
Он заходит на дашборд команды, чтобы посмотреть подробную информацию. Видит, что Done Total тоже достаточно низкий. Потом узнаёт по графику Velocity, что после начала спринта добавили больше задач, чем обычно.
Он проваливается внутрь Velocity — есть задачи, которые стоят без оценки. Это значит, что могли прийти суперсрочные баги, которые нужно было делать здесь и сейчас, и даже не было времени их оценивать. Поэтому в спринте у команды была такая просадка.
Для инструмента нет порога входа — подключиться может любая команда. С этой целью нужно заполнить показатели, например оценить задачи.
У нас есть чат в Slack, где можно обсудить работу инструментов. В первое время вопросов было много: почему в показателе именно такое число, как изменить исторические данные или командные процессы под инструмент.
Иногда мы сталкивались с процессами, которые не предусматривали. Например, команда снимала сторипоинты с задачи, потому что выполнила её. В итоге к закрытию спринта оценка таска в отчёте была равна 0.
Мы рассматриваем фича-реквесты пользователей и постоянно улучшаем инструмент. Так добавился отчёт по типам жизненного цикла задач.
Лайфхаки для аналитиков
Мы открыли для себя несколько приёмов визуализации, которые сильно упрощают работу с отчётами.
Кнопка, которая сбрасывает фильтры
Мы используем много фильтров, чтобы смотреть общий вид отчёта. Если показать все команды сразу, то информация станет нечитаемой, а работать система будет медленно. Чтобы перейти на дашборд отдельной команды и посмотреть нужные данные, надо сбросить общие фильтры и поставить новые.
Если делать это вручную, придётся снимать каждый фильтр отдельно. Поэтому можно создать кнопку, которая сбросит фильтры.
Как это сделать:
Создаём новый лист в Tableau, который оформляем как кнопку визуально — пишем там текст и бэкграунд.
Помещаем кнопку на дашборд.
В дашборде есть Actions — нам нужно выбрать Filter.
В фильтре отмечаем только те поля, которые у нас находятся на дашборде. Если выбрать вариант «Все поля», сбросятся фильтры, которые стоят на отчётах.
Появится ошибка Missing fields, что у вас нет указанных полей в отчёте. Так и должно быть, благодаря этому работает фильтр.
Особенности визуализации в графике Retro AI
Чтобы показать график Retro AI, мы делаем срез для каждой задачи по ежедневным статусам. Например, если задачу создали пять дней назад, она будет существовать в таблице со статусами все эти дни, включая текущий.
Обычно так данные не хранят, потому что это максимально неоптимальный способ. Зато таким способом можно сохранить логику процесса у команды и построить график Retro AI.
Дата обновления источника
Она добавляется в Title Worksheet через кнопку Insert. Чтобы дату было видно, надо закинуть данные на Worksheet: вывести что-то в детали или поставить фильтр.
Чтобы заголовок красиво отображался, нужно указать в Text Mark значение NULL.
Какие результаты мы получили
Напомню ещё раз, какие возможности мы хотели получить с помощью инструмента в Tableau:
Видеть в едином окне метрики здоровья команд.
Выделять проблемы в продуктивности.
Понимать детально, с чем проблемы связаны.
Мы собрали статистику за последние 3 месяца. Сейчас инструментом пользуются 144 команды — это 220 уникальных юзеров. В отчёты заходят руководители или scrum-мастера команд. В день выходит по 43 просмотра.
Тимлиды, юнит-лиды и аналитики могут оценить по графикам общую картину продуктивности команд, увидеть проблемные места и скорректировать рабочий процесс. Сами команды смотрят на график Velocity, чтобы при планировании следующего спринта понимать, какую нагрузку они могут взять.
