Пять действительно нужных agile-показателей KPI

Основные моменты

• Agile-метрики, такие как диаграмма Burndown для спринта, скорость, время цикла и сводные диаграммы процесса, помогают командам отслеживать прогресс и оптимизировать поставку.

• Эти метрики дают представление об эффективности команды, узких местах и позволяют прогнозировать будущие спринты.

• Регулярный анализ метрик способствует непрерывному улучшению и принятию решений на основе данных.

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

Показатели — вещь прихотливая.

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

Но все может быть иначе. Отслеживание достоверных agile-показателей и обмен ими может внести ясность и пролить свет на успехи (и провалы) команды в рамках цикла разработки. Хотите узнать, как именно? Читайте далее.

Что такое показатели Agile?

Показатели Agile — это способ количественного измерения, используемый для отслеживания прогресса, качества и эффективности Agile-команд и проектов. Распространенные показатели включают скорость, время выполнения, время цикла, диаграммы Burndown и сводные диаграммы процессов.

Эти показатели помогают командам выявлять узкие места, прогнозировать сроки поставки и непрерывно совершенствоваться. Например, отслеживание скорости позволяет командам предсказывать объем работы, которую они смогут выполнить в будущих спринтах, а мониторинг времени цикла выявляет области, в которых можно оптимизировать процессы.

Что такое KPI в Agile?

Ключевые показатели эффективности (KPI) в Agile — это специфическая система измерения, используемая для оценки успешности команды или проекта в достижении поставленных целей. В зависимости от приоритетов организации ключевые показатели эффективности могут включать оценку удовлетворенности клиентов, процент дефектов или время выхода на рынок.

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

Оптимизация поставки программного обеспечения с помощью agile-показателей KPI

«Готовый» продукт — какой он? Это актуальный продукт, созданный в нужное время для подходящего рынка. Неукоснительное следование программе подразумевает сбор и анализ определенных данных в ходе работы. В рамках любой agile-программы важно отслеживать как бизнес-показатели, так и метрики Agile. Первые показатели помогают понять, насколько решение удовлетворяет потребностям рынка, а вторые — позволяют оценить разные аспекты процесса разработки.

Для каждой инициативы на дорожной карте нужно предусмотреть несколько ключевых показателей эффективности (KPI), которые соотносятся с целями программы. Кроме того, нужно задать критерии успешности для каждого требования к продукту, например доля конечных пользователей, внедривших продукт, или покрытие кода автоматическими тестами (в процентах). Эти критерии успешности находят выражение в agile-показателях программы. И чем больше команды учатся, тем лучше они могут приспосабливаться и развиваться.

Диаграмма Burndown для спринта

Команды Scrum дробят процесс разработки на спринты с фиксированной продолжительностью. На начальной стадии спринта команда дает прогноз, какой объем работы она сможет выполнить за спринт. Затем ход выполнения работы в спринте отслеживается с помощью диаграммы Burndown. Ось X отражает время, а ось Y — объем работы, который осталось завершить, в очках оценки сложности или часах. Команда стремится выполнить весь запланированный объем работы к концу спринта.

Если показатели команды всегда соответствуют прогнозу, методика Agile может очень быстро набрать популярность в организации. Но не спешите выдавать желаемое за действительное и не объявляйте об успешном выполнении задачи раньше времени. Такой подход может принести плоды в краткосрочной перспективе, однако он помешает дальнейшему обучению и совершенствованию.  

Узнайте, как использовать диаграммы Burndown в Jira

Сгорание релиза и эпика

С помощью диаграмм Burndown для эпиков и релизов (или версий) отслеживается ход выполнения большего объема работы, чем с помощью диаграмм Burndown для спринтов. Ими могут руководствоваться при разработке команды, применяющие как Scrum, так и Kanban. В спринте (у команд Scrum) могут содержаться рабочие задачи из нескольких эпиков и версий сразу, поэтому важно отслеживать прогресс отдельных спринтов, равно как и эпиков и версий.

Расширение области проекта — это внесение дополнительных требований в уже скомпонованный проект. Например, если команда должна поставить новый веб-сайт для компании, расширением области проекта может считаться запрос новых функций после того, как были намечены первоначальные требования. С расширением области проекта в ходе спринта мириться не стоит, а вот в рамках эпиков или версий это явление логически вытекает из самой сути agile-разработки. Наблюдая, как команда выполняет рабочие задачи в проекте, владелец продукта может менять объем работы в зависимости от сделанных им выводов. Диаграммы Burndown для эпиков и релизов — это надежный источник информации обо всех изменениях в объеме работы в рамках эпика и версии.

Скорость команды

Скорость команды — это средний объем работы, который Scrum-команда выполняет за спринт, измеренный в очках оценки сложности или часах. Этот показатель используется при прогнозировании. С его помощью владелец продукта может предположить, как быстро команда справится с задачами из бэклога, поскольку в отчете учитывается объем запланированной и выполненной работы за несколько итераций. Чем больше итераций, тем точнее прогноз.

Предположим, что владелец продукта хочет выполнить работу из бэклога с оценкой сложности 500 очков. Известно, что команда разработчиков, как правило, за каждую итерацию выполняет работу с оценкой сложности 50 очков. Владелец продукта имеет все основания полагать, что команда справится с поставленными задачами примерно за 10 итераций.

Важно следить, как скорость команды изменяется со временем. У новых команд, как правило, скорость увеличивается по мере оптимизации рабочего процесса и укрепления связей между участниками. Существующие команды могут отслеживать свою скорость, чтобы поддерживать темпы работы и видеть, принесло ли пользу то или иное изменение в процессе. Если средняя скорость снижается, это обычно значит, что в каком-то аспекте рабочий процесс команды перестал быть эффективным. Это следует обсудить на следующей ретроспективе.

Скорость каждой команды уникальна. Если скорость команды А равна 50, а скорость команды Б — 75, это не значит, что производительность команды Б выше. В каждой команде складываются свои принципы оценки сложности работы, поэтому и скорость работы у каждой команды тоже будет своя. Не пытайтесь сравнивать скорости разных команд. Оценивайте количество усилий и результаты работы команды исходя из ее собственной трактовки оценки сложности. 

Контрольный график

Контрольные графики позволяют сосредоточиться на времени цикла отдельных задач — на времени, которое в сумме требуется для перемещения задачи со стадии «В процессе» на стадию «Готово». Небольшое время цикла, скорее всего, означает высокую производительность команды, а команды, для которых характерно стабильное время цикла при выполнении многих задач, более предсказуемы в плане поставки результатов работ. Время цикла — это основной показатель для оценки команд Kanban, но оптимизация времени цикла может быть целесообразна и для команд Scrum.

Измеряйте время цикла, чтобы знать, как усовершенствовать процессы команды эффективно и разными способами: результаты изменений заметны практически сразу, поэтому можно без промедления вносить дополнительные поправки. Конечная цель — добиться стабильного и короткого времени цикла независимо от типа работы (добавление новой функции, ликвидация технического долга и т. д.).

Сводная диаграмма процесса

Линии на сводной диаграмме процесса, которые читаются слева направо, должны быть в идеале лишены резких перепадов. Подъемы или пробелы на какой-либо линии одного цвета — признак дефицита или проблемных мест. При обнаружении подобных явлений следует попытаться сгладить цветные полосы на диаграмме.

Больше agile-метрик

Перечень хороших показателей не исчерпывается отчетами, описанными выше. Например, для agile-команд важным показателем является качество, и еще ряд традиционных показателей применим к agile-разработке. Среди них:

• Количество обнаруженных дефектов:

  • во время разработки;

  • после поставки продукта клиентам;

  • людьми, не входящими в состав команды;

• количество дефектов, перенесенных в будущий релиз;

• количество входящих запросов в службу поддержки от клиентов;

• покрытие кода автоматизированными тестами (в процентах).

Agile-команды должны также отслеживать частоту релизов и скорость доставки. В конце каждого спринта команда должна выпускать ПО в производство. Как часто это происходит на самом деле? Поставляется ли большая часть сборок релиза? Сколько времени требуется команде, чтобы выпустить в производство срочное исправление? Легко ли команде выпускать продукт или ей приходится каждый раз идти на подвиги?

Поиск аналитики в контексте

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

Аналитика дает визуальный снимок следующих показателей.

• Прогресс спринта

• Детализация типа задачи

• Объем работ по спринту

• Частота развертывания

• Продолжительность цикла

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

Как измерить успех Agile-проекта?

Успех Agile-проекта оценивается путем анализа количественных показателей и качественных результатов, таких как поставка ценности клиентам, достижение бизнес-целей и налаживание совместной работы в команде. Среди ключевых показателей — своевременная поставка результатов, удовлетворенность заинтересованных лиц и способность приспосабливаться к изменениям.

Для оценки эффективности команды часто используют сочетание таких показателей, как скорость, отзывы клиентов и влияние на бизнес. Например, в контексте Agile проект считается успешным, если позволяет выпустить продукт высокого качества в срок и получить положительную обратную связь от пользователей.

Заключение

Agile-показатели и KPI — это лишь один из аспектов построения командной культуры. С их помощью можно получить количественное представление об эффективности команды и поставить перед ней цели, поддающиеся количественной оценке. Они важны, но не стоит на них зацикливаться. Прислушивайтесь к участникам команды во время ретроспектив, ведь ваше внимание тоже важно для создания доверительных отношений, повышения качества продукта и сокращения времени до выпуска. Изменения должны основываться как на количественных, так и на качественных показателях.

Связанные ресурсы

• Ресурсы по управлению проектами

  • Ресурсы для руководителей проектов