Метрики agile-команды 1С в JIRA
Хабр, привет! Меня зовут Елена — я ИТ-лидер команды 1С, в начале года мы задались вопросом как повысить прозрачность процесса разработки в Moex, как приносить больше ценности (количество выполненных задач высокого качества) за минимальное время (количество спринтов). Если вы тоже задались подобными вопросами, предлагаю вам ознакомиться с нашими наработками и при желании настроить себе такие же.
В первую очередь автоматизировали свою работу. Весь учет задач перевели в тасктрекер из-за огромного количества каналов коммуникаций и потерь задач (перестали принимать задачи в разных чатах и мессенджере, почте, по телефону). Стейкхолдер мог самостоятельно создать нам задачу в JIRA, либо на почту отправить *.xlsx по шаблону, где робот разбирал письмо, создавал задачку и заполнял нужные поля из файла. Максимально детализировали задачки — создавали крупные эпики, внутри них юзер-стори, саб-таски на аналитику, разработку, тестирование и тд. Обязательно устанавливали сроки в задачах, связи между ними. Автоматизировали изменение сроков, статусов, если что-то меняется в связной задаче (переносится срок задачи, изменяется спринт).
Несмотря на уход от рутины в JIRA, остался ручной перенос сроков из трекера в программу MS Project, где мы показывали результаты по проекту.
Это было неудобно, стейкхолдерам и команде не хватало понимания — какой у нас прогресс, успеваем ли мы, с нужной ли скоростью идем. Поняли, что не хватает аналитики по JIRA, визуализации метрик, дашбордов, чтобы понимать зоны роста команды, где нужно уменьшать время выпуска фич и видеть динамику: от месяца к месяцу, от спринта к спринту.
Какие аналитики продуктивности мы использовали
Цель сбора метрик — дать реальную информацию о ходе разработки от идеи до готовности заявок бизнеса.
Готового инструмента в компании не было, поэтому пришлось искать и разрабатывать самим.
Трекер задач у нас был в JIRA, решили использовать ее возможности, изучили отчеты по задачам и спринтам.
Создание рабочего стала и дашбордов
Одного отчета по спринту оказалось недостаточно, переключаться между ними неудобно, поэтому создали отдельный Рабочий стол.
Отчетность о статусе спринта
Добавили различные графики и дашборды, вверху можно увидеть удобные фильтры по спринтам, нашему проекту, статусам.
В любой момент можно было открыть борду и увидеть статусы задач.
Круговая диаграмма по статусам
Различных графиков было очень много и необходимо было выбрать, что нам пригодится для анализа нашей работы.
В разрезе продуктов — план/факт
Добавили визуал — процент выполнения задач в спринте, показывает сколько задач было запланировано, сколько реализовано и отношение двух метрик
В разрезе типов задач
Дашборды можно формировать в разрезе необходимых аналитик, например, отдельно считали по «Продуктам»: 1С: Биллинг, 1С: Бухгалтерия, 1С: ЗУП, отдельно по проектным и непроектным задачам
Аналитика по количеству задач в разрезе Спринт/Резолюция
Добавили дашборд, чтобы проанализировать метрику производительности — количество закрытых задач (резолюция — Решено, Отменено) в каждом спринте, чтобы понять с какой скоростью мы движемся;
Добавили дашборд по оставшемуся времени в разрезе меток — в них мы вели свои аналитики, которые хотели отслеживать (например, отдельно задачки по кадровому учету, по бухучету, по C&B и тд)
Задачи можно оценивать в часах или в стори поинтах (story points). Для более точного планирования спринтов, кварталов, управления проектами, нам необходимо было знать, сколько работы команда может выполнить за определённый период времени — спринт.
Велосити (Velocity) — это метрика в Scrum, которая позволяет команде оценить свою производительность и прогнозировать выполнение будущих задач. Эта метрика измеряется в количестве выполненных стори-поинтов за один спринт. Она позволяет команде определить, сколько задач можно включить в следующий спринт, оценить, когда проект будет завершён, позволяет команде анализировать свою производительность и искать способы для улучшения.
Добавили дашборд для анализа всех Эпиков, отслеживали прогресс по всем и каждому в отдельности, сколько задач внутри эпика были решены.
Добавили дашборды, которые нам показывали количество созданных и решенных задач.
Использовали диаграммы сгорания задач Burndown. Они нужны, чтобы понять, что команда при планировании спринта берет недостаточно задач, если все время заканчивает свою работу раньше срока. Или наоборот, планирует слишком много и не успевает выполнить все за спринт есть перенесенные.
С какими проблемами столкнулись
Управление только по цифрам. Важно не только изолированно опираться на измеряемые метрики, но и вести неформальные наблюдения, которые усиливают друг друга. Иначе можно получить искажения — не важные результаты, не смотря на красивые цифры на дашбордах, снизить моральный дух сотрудников.
Метрик слишком много, но они не помогают в дальнейшем принятии решения. Мы добавили все возможные графики, попробовали каждый инструмент, который был на борде, по боязни что-то забыть измерить. На самом деле большая часть оказалась избыточна. Тратили время на анализ и сбор данных, но эта аналитика не помогает лучше принимать решения, поэтому приняли за правило, задавать себе вопросы:
Какие решения поможет принять эта метрика?
Каких метрик достаточно для принятия?
Нужно ли нам измерять это прямо сейчас?
На всех этапах проекта и развития мы используем одни и те же метрики. Мы столкнулись с проблемой, что те показатели, что мы измеряли на этапе Проектирования оказались уже не актуальны на этапе Тестирования. У нас уже были другие типы задач в JIRA, другие метки, статусы, поэтому нам срочно пришлось перестраиваться, чтобы наши дашборды и прогресс по проекту был актуальным. Важно помнить о том, что если все меняется, то нужно гибко перестраиваться.
Используются метрики не для анализа и улучшения продукта. Важно не искажать данные в своих целях, не использовать их для наказания. Метрика не должна служить только целям карьерного роста, не должно быть манипулирования данными. Метрики в первую очередь должны быть нацелены на эффективность команды, получение результата, развитие продукта.
Правила для использования метрик
Существует мнение, что вред от метрик больше, чем пользы. Такое возможно при неправильном внедрении этих классных инструментов. Поэтому нужно пользоваться правилами, чтобы такое избежать:
Применять метрики совместно с другими инструментами для анализа общей картины.
Использовать их только тогда, когда они помогают улучшать процесс принятия решений.
Обращать внимание на манипуляцию метриками людей, на изменение их поведения.
Аккуратно интерпретируйте значения метрик.
Такие правила помогли направить нашу команду в сторону более эффективных метрик и, что более важно, в сторону лучших бизнес-результатов.
Итог
Мы понимаем вместимость, скорость, прогнозируемость спринта и проекта в целом;
Повысили % закрытых задач, свели к минимуму перенесенные из спринта в спринт благодаря прогнозам;
Стали внедрять культуру метрик в компании, поделись своей практикой с другими командами разработки;
Процесс разработки стал прозрачнее для команды;
Повысили лояльность бизнес-пользователей, получали положительную обратную связь и настрой в команде улучшился!
