Краткое описание: показатели agile позволяют проанализировать продуктивность на различных этапах разработки программного обеспечения. Судя по ним, можно оценить качество продукта и эффективность команды.
Показатели — вещь прихотливая.
С одной стороны, каждому из нас доводилось сталкиваться с проектом, в котором не отслеживались никакие данные. Невозможно было понять, движется ли работа в правильном направлении и повышается ли эффективность со временем. С другой стороны, многим из нас приходилось участвовать в проектах, в которых статистику использовали как оружие: сталкивали команды между собой, как врагов, или требовали работать на выходных. Неудивительно, что у большинства команд сложились непростые отношения с показателями.
Но все может быть иначе. Отслеживание достоверных agile-показателей и обмен ими может внести ясность и пролить свет на успехи (и провалы) команды в рамках цикла разработки. Хотите узнать, как именно? Читайте далее.
Знай свое дело
«Готовый» продукт — какой он? Это актуальный продукт, созданный в нужное время для подходящего рынка. Неукоснительное следование программе подразумевает сбор и анализ определенных данных в ходе работы. В рамках любой agile-программы важно отслеживать как бизнес-показатели, так и метрики Agile. Первые показатели помогают понять, насколько решение удовлетворяет потребностям рынка, а вторые — позволяют оценить разные аспекты процесса разработки.
«Бизнес-показатели программы необходимо определять на основе ее дорожной карты».
Для каждой инициативы на дорожной карте нужно предусмотреть несколько ключевых показателей эффективности (KPI), которые соотносятся с целями программы. Кроме того, нужно задать критерии успешности для каждого требования к продукту, например доля конечных пользователей, внедривших продукт, или покрытие кода автоматизированными тестами (в процентах). Эти критерии успешности находят выражение в agile-показателях программы. И чем больше команды учатся, тем лучше они могут приспосабливаться и развиваться.
Оптимизация поставки программного обеспечения с помощью agile-показателей KPI
Диаграмма Burndown для спринта
Команды Scrum дробят процесс разработки на спринты с фиксированной продолжительностью. На начальной стадии спринта команда дает прогноз, какой объем работы она сможет выполнить за спринт. Затем ход выполнения работы в спринте отслеживается с помощью диаграммы Burndown. Ось X отражает время, а ось Y — объем работы, который осталось завершить, в очках оценки сложности или часах. Команда стремится выполнить весь запланированный объем работы к концу спринта.
Если показатели команды всегда соответствуют прогнозу, методика Agile может очень быстро набрать популярность в организации. Но не спешите выдавать желаемое за действительное и не объявляйте об успешном выполнении задачи раньше времени. Такой подход может принести плоды в краткосрочной перспективе, однако он помешает дальнейшему обучению и совершенствованию.
- Команда постоянно завершает спринты раньше срока, потому что берет на себя недостаточно работы.
- Команда постоянно не выполняет спринты в срок, потому что берет на себя слишком много работы.
- В линии диаграммы Burndown прослеживаются резкие спады вместо плавного снижения, потому что работа не была разбита на мелкие составляющие.
- Владелец продукта меняет объем работы посреди спринта.
Сгорание релиза и эпика
С помощью диаграмм Burndown для эпиков и релизов (или версий) отслеживается ход выполнения большего объема работы, чем с помощью диаграмм Burndown для спринтов. Ими могут руководствоваться при разработке команды, применяющие как Scrum, так и Kanban. В спринте (у команд Scrum) могут содержаться рабочие задачи из нескольких эпиков и версий сразу, поэтому важно отслеживать прогресс отдельных спринтов, равно как и эпиков и версий.
Расширение объема проекта — это внесение дополнительных требований в уже скомпонованный проект. Например, если команда должна поставить новый веб-сайт для компании, расширением объема проекта может считаться запрос новых функций после того, как были намечены первоначальные требования. С расширением объема проекта в ходе спринта мириться не стоит, а вот в рамках эпиков или версий это явление логически вытекает из самой сути agile-разработки. Наблюдая, как команда выполняет рабочие задачи в проекте, владелец продукта может менять объем работы в зависимости от сделанных им выводов. Диаграммы Burndown для эпиков и релизов — это надежный источник информации обо всех изменениях в объеме работы в рамках эпика и версии.
- Команда выполняет одну рабочую задачу за другой, а прогнозы на эпик или релиз не обновляются.
- Прогресс не наблюдается в течение нескольких итераций.
- Объем проекта постоянно расширяется. Это, возможно, говорит о том, что владелец продукта не до конца понимает проблему, для решения которой был запланирован определенный объем работы.
- Команда не поспевает за расширением объема проекта.
- По мере выполнения эпика команда не поставляет инкрементальные релизы.
Скорость команды
Скорость команды — это средний объем работы, который Scrum-команда выполняет за спринт, измеренный в очках оценки сложности или часах. Этот показатель используется при прогнозировании. С его помощью владелец продукта может предположить, как быстро команда справится с задачами из бэклога, поскольку в отчете учитывается объем запланированной и выполненной работы за несколько итераций. Чем больше итераций, тем точнее прогноз.
Предположим, что владелец продукта хочет выполнить работу из бэклога с оценкой сложности 500 очков. Известно, что команда разработчиков, как правило, за каждую итерацию выполняет работу с оценкой сложности 50 очков. Владелец продукта имеет все основания полагать, что команда справится с поставленными задачами примерно за 10 итераций.
Важно следить, как скорость команды изменяется со временем. У новых команд, как правило, скорость увеличивается по мере оптимизации рабочего процесса и укрепления связей между участниками. Существующие команды могут отслеживать свою скорость, чтобы поддерживать темпы работы и видеть, принесло ли пользу то или иное изменение в процессе. Если средняя скорость снижается, это обычно значит, что в каком-то аспекте рабочий процесс команды перестал быть эффективным. Это следует обсудить на следующей ретроспективе.
Если в течение продолжительного периода времени скорость колеблется непредсказуемым образом, обязательно пересмотрите подходы команды к оценке сложности. В ходе командной ретроспективы задайте следующие вопросы:
- Возникают ли в процессе разработки непредвиденные трудности, которые не были учтены при оценке сложности? Есть ли способ лучше разбить работу на составляющие, чтобы учесть эти трудности?
- Нет ли давления на команду со стороны для достижения определенных бизнес-показателей? Становится ли из-за этого сложнее придерживаться рекомендаций в области разработки?
- Трезво ли мы как команда оцениваем свои способности при прогнозировании объема работы для спринта?
Скорость каждой команды уникальна. Если скорость команды А равна 50, а скорость команды Б — 75, это не значит, что производительность команды Б выше. В каждой команде складываются свои принципы оценки сложности работы, поэтому и скорость работы у каждой команды тоже будет своя. Не пытайтесь сравнивать скорости разных команд. Оценивайте количество усилий и результаты работы команды исходя из ее собственной трактовки оценки сложности.
Контрольный график
Контрольные графики позволяют сосредоточиться на времени цикла отдельных задач — на времени, которое в сумме требуется для перемещения задачи со стадии «В процессе» на стадию «Готово». Небольшое время цикла, скорее всего, означает высокую производительность команды, а команды, для которых характерно стабильное время цикла при выполнении многих задач, более предсказуемы в плане поставки результатов работ. Время цикла — это основной показатель для оценки команд Kanban, но оптимизация времени цикла может быть целесообразна и для команд Scrum.
Измеряйте время цикла, чтобы знать, как усовершенствовать процессы команды эффективно и разными способами: результаты изменений заметны практически сразу, поэтому можно без промедления вносить дополнительные поправки. Конечная цель — добиться стабильного и короткого времени цикла независимо от типа работы (добавление новой функции, ликвидация технического долга и т. д.).
Контрольные графики поначалу могут казаться непонятными. Не стоит слишком сильно беспокоиться из-за каждого резко отклоняющегося значения. Отслеживайте тенденции. Обращайте внимание на следующие два явления.
- Увеличение времени цикла. Когда время цикла увеличивается, команда лишается заработанных нелегким трудом преимуществ методики Agile. Во время командной ретроспективы выделите время, чтобы понять причины такого увеличения. Есть одно исключение: если команда принимает более жесткие критерии готовности, то время цикла, скорее всего, увеличится.
- Хаотичные изменения времени цикла. В идеале время цикла при выполнении рабочих задач со схожей оценкой сложности неизменно. Чтобы проверить его изменчивость, можно фильтровать контрольный график по каждому значению оценки сложности. Если время цикла непредсказуемо меняется при выполнении задач с низкой и высокой оценкой сложности, отведите часть ретроспективы на выявление огрехов и улучшение процесса оценки сложности в будущем.
Сводная диаграмма процесса
Линии на сводной диаграмме процесса, которые читаются слева направо, должны быть в идеале лишены резких перепадов. Подъемы или пробелы на какой-либо линии одного цвета — признак дефицита или проблемных мест. При обнаружении подобных явлений следует попытаться сгладить цветные полосы на диаграмме.
- Из-за блокирующих задач стоит другая работа, из-за чего в одних частях процесса образуются большие «пробки», а в других процесс «зависает».
- Количество незакрытых задач в бэклоге растет. Виной тому владельцы продуктов, не закрывающие задачи, которые устарели или никак не могут перейти на следующую стадию из-за слишком низкого приоритета.
Еще больше показателей
Перечень хороших показателей не исчерпывается отчетами, описанными выше. Например, для agile-команд важным показателем является качество, и еще ряд традиционных показателей применим к agile-разработке. Среди них:
- Количество обнаруженных дефектов:
- во время разработки;
- после поставки продукта клиентам;
- людьми, не входящими в состав команды;
- количество дефектов, перенесенных в будущий релиз;
- количество входящих запросов в службу поддержки от клиентов;
- покрытие кода автоматизированными тестами (в процентах).
Agile-команды должны также отслеживать частоту релизов и скорость доставки. В конце каждого спринта команда должна выпускать ПО в производство. Как часто это происходит на самом деле? Поставляется ли большая часть сборок релиза? Сколько времени требуется команде, чтобы выпустить в производство срочное исправление? Легко ли команде выпускать продукт или ей приходится каждый раз идти на подвиги?
Поиск аналитики в контексте
Аналитика представляет собой превосходный инструмент, открывающий командам доступ к различным показателям. Так актуальные данные будут под рукой в нужный момент, например при планировании спринтов, проверке ситуации на ежедневных стендапах или при оптимизации поставки. Аналитические сведения расположены в правом верхнем углу представления доски, бэклога и развертываний в Jira.
Аналитика дает визуальный снимок следующих показателей.
- Прогресс спринта
- Детализация типа задачи
- Объем работ по спринту
- Частота развертывания
- Продолжительность цикла
Используйте эти показатели, чтобы непрерывно оптимизировать производительность команды. Подробнее об аналитике.
Заключение
Agile-показатели и KPI — это лишь один из аспектов построения командной культуры. С их помощью можно получить количественное представление об эффективности команды и поставить перед ней цели, поддающиеся количественной оценке. Они важны, но не стоит на них зацикливаться. Прислушивайтесь к участникам команды во время ретроспектив, ведь ваше внимание тоже важно для создания доверительных отношений, повышения качества продукта и сокращения времени до выпуска. Изменения должны основываться как на количественных, так и на качественных показателях.
Связанные ресурсы
