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

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

Dan Radigan Dan Radigan
Просмотр тем

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

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

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

Знай свое дело

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

Бизнес-показатели программы должны основываться на ее дорожной карте.

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

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

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

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

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

Когда показатели команды постоянно соответствуют прогнозу, методология agile может очень быстро набрать популярность в организации. Но не спешите выдавать желаемое за действительное и не объявляйте об успешном выполнении задачи раньше времени. Может, в краткосрочной перспективе это и принесет свои плоды, но в долгосрочной лишь будет мешать обучению и совершенствованию.

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

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

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

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

Плохие примеры, которые лучше не повторять
  • Команда выполняет одну рабочую задачу за другой, а прогнозы на эпик или релиз не обновляются.
  • Прогресс не наблюдается в течение нескольких итераций. 
  • Объем проекта постоянно расширяется. Это, возможно, говорит о том, что владелец продукта не до конца понимает проблему, для решения которой был запланирован определенный объем работы.
  • Команда не поспевает за расширением объема проекта.
  • По мере выполнения эпика команда не поставляет инкрементальные релизы.

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

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

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

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

Плохие примеры, которые лучше не повторять

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

  • Возникают ли в процессе разработки непредвиденные трудности, которые не были учтены при оценке сложности? Есть ли способ лучше разбить работу на составляющие, чтобы учесть эти трудности?
  • Нет ли давления на команду со стороны для достижения определенных бизнес-показателей? Становится ли из-за этого сложнее придерживаться рекомендаций в области разработки?
  • Трезво ли мы как команда оцениваем свои способности при прогнозировании объема работы для спринта? 

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

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

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

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

Плохие примеры, которые лучше не повторять

Контрольные графики поначалу могут казаться непонятными. Не стоит слишком сильно беспокоиться из-за каждого резко отклоняющегося значения. Отслеживайте тенденции. Обращайте внимание на следующие два явления.

  • Увеличение времени цикла. Когда время цикла увеличивается, команда лишается заработанных нелегким трудом преимуществ agile-методологии. Во время командной ретроспективы выделите время, чтобы понять причины увеличения. Есть одно исключение: если команда принимает более жесткие критерии готовности, то время цикла, скорее всего, увеличится.
  • Хаотичные изменения времени цикла. В идеале время цикла при выполнении рабочих задач со схожей оценкой сложности неизменно. Чтобы проверить его изменчивость, можно фильтровать контрольный график по каждому значению оценки сложности. Если время цикла изменяется непредсказуемо при выполнении задач с низкой и высокой оценкой сложности, отведите часть ретроспективы на выявление огрехов и улучшение процесса оценки сложности в будущем. 

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

Сводная диаграмма процесса — это главный источник информации для команд Kanban, с помощью которого они добиваются понятности и предсказуемости рабочего процесса. Ось Y отражает количество задач, ось X — время, а разными цветами помечаются разные стадии рабочего процесса. Благодаря этому получают наглядное представление все дефициты и проблемные места. Диаграмма работает в сочетании с лимитами незавершенной работы.

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

Плохие примеры, которые лучше не повторять
  • Из-за невыполненных задач стоит другая работа, из-за чего в одних частях процесса образуются большие «пробки», а в других процесс «зависает».
  • Количество незакрытых задач в бэклоге растет. Виной тому владельцы продуктов, не закрывающие задачи, которые устарели или никак не могут перейти на следующую стадию из-за слишком низкого приоритета. 

Еще больше показателей

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

  • количество дефектов, обнаруженных:
    • во время разработки;
    • после поставки продукта клиентам;
    • людьми, не входящими в состав команды;
  • количество дефектов, перенесенных в будущий релиз;
  • количество входящих запросов в службу поддержки от клиентов;
  • покрытие кода автоматизированными тестами (в процентах).

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

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

продолжение темы
Gantt Chart