17 важных Agile-метрик, о которых должна заботиться ваша команда

Метрики уже давно являются предметом споров среди агилистов.

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

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

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

Для чего используются agile-метрики?

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

Железный треугольник против гибкого треугольника

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

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

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

Таким образом, важно понимать, что качество, изображенное в agile-треугольнике, является внутренним или внутренним качеством с точки зрения разработки, в то время как ценность в треугольнике на самом деле является формой внешнего качества. Понимание этой взаимосвязи важно для разработки хороших гибких показателей.

17 ключевых agile-метрик, которые нужно отслеживать

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

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

Верьте или нет, это случается. Хорошее решение для метрик должно охватывать все три точки Agile-треугольника. Эти 17 дадут вам инструменты, чтобы сделать это и многое другое.

Заблокированное время

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

Увеличение заблокированного времени может означать, что пользовательская история не была декомпозирована должным образом или что существует незапланированная зависимость от внешнего ресурса. Заблокированное время можно сократить за счет более тщательной декомпозиции пользовательской истории, расстановки приоритетов и планирования спринта.

Деловой импульс

Многие из обсуждаемых здесь показателей существуют уже довольно давно. Большинство из них сосредоточены на уровне проекта, команды или WIP (незавершенного производства). Однако по мере того, как технологии все больше интегрируются в нашу повседневную жизнь, а рынки для этих продуктов становятся сверхускоренными, организации ищут более сложные показатели, которые могут определять рыночные тенденции, оценивать улучшения процессов, прогнозировать конкуренцию и, по сути, измерять гибкость. Деловой импульс является одним из них. Импульс в этом контексте может быть выражен как общее количество баллов за выпуск, умноженное на его временную шкалу.

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

Покрытие кода

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

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

Контрольная карта

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

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

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

Суммарная блок-схема

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

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

Время цикла

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

Эпик и релиз Burndown

Диаграммы выгорания эпиков и релизов аналогичны всегда популярным выгораниям спринтов, обсуждаемым ниже. Диаграмма Burndown показывает, сколько работы осталось за определенный период времени или, в данном примере, для определенного эпика. В гибкой разработке эпик — это большая пользовательская история, состоящая из более мелких пользовательских историй или фрагментов работы.

По мере завершения работы количество пользовательских историй в эпопее постепенно уменьшается, пока не достигнет нуля. Это может быть полезно в тех случаях, когда необходимо достичь контрольных точек, чтобы выполнить договорные требования и выставить счет клиенту. Аналогичным образом, Burndown релиза может отслеживать ход работы, выделенной для конкретного релиза. Это может быть использовано для обеспечения своевременной доставки или раннего выявления необходимости изменить крайний срок.

Неудачные развертывания

Неудачное развертывание — это развертывание, которое приводит к любому из следующих действий:

• Служба, влияющая на отключение
• Не оправдывает ожиданий клиентов, что часто приводит к отклонению релиза.
• Серьезно влияет на удобство использования, работу или взаимодействие с пользователем продукта.
• Приводит к откату к предыдущему релизу.

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

Время выполнения

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

Чистый рейтинг промоутера (NPS)

Чистая оценка промоутера предназначена для оценки удовлетворенности клиентов. Обычно он рассчитывается на основе данных, полученных в ходе опроса. Цель состоит в том, чтобы узнать, сколько клиентов порекомендовали бы ваш продукт. Процент респондентов, проголосовавших «против», вычитается из голосов, проголосовавших «да», для получения оценки.

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

Аналитика качества

В начале статьи мы обсудили agile-треугольник и роль в нем качества. Аналитика качества может принимать разные формы, но обычно она состоит из множества показателей отслеживания дефектов. Дефекты можно отслеживать в зависимости от того, где и когда они возникают, их частоты и серьезности.

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

Выгорание спринта

Диаграммы выгорания спринта обеспечивают ежедневную оценку выполненной работы и работы, которую еще предстоит выполнить в данном спринте. Он сравнивает объем выполненной работы с первоначальными оценками. Из-за эмпирического характера гибкой разработки ценность диаграммы выгорания весьма ограничена.

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

пропускная способность

Количество продукции (количество элементов работы), доставленной заказчику в конкретную единицу времени, называется пропускной способностью. Это может быть измерено ежемесячно, ежеквартально, за выпуск, итерацию и так далее. Ценность этой метрики заключается в том, что ее можно использовать для определения того, сколько программного обеспечения может быть поставлено за определенный период времени. Его также можно использовать для отслеживания согласованности доставки с точки зрения команды и организации.

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

Доставленная ценность

В начале статьи мы обсуждали, как ценность состоит из внешнего качества, или восприятия продукта конечным пользователем. Как продукт влияет на бизнес клиента? Хорошие agile-метрики основаны на результатах, а в деловом мире это обычно выражается в долларах и центах. Точно так же, как мы присваиваем баллы истории каждой пользовательской истории как способ оценки работы, которую она требует, мы также можем добавлять баллы ценности в качестве относительной меры, чтобы показать, что конечный пользователь получает, когда работа выполнена.

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

Например, если в проекте 200 баллов ценности и ожидается, что клиент получит 1 миллион долларов дохода, то каждый балл ценности стоит 5000 долларов. Сумма каждой истории и их накопленная стоимость могут быть проиллюстрированы на графике выгорания. Хотя фактическое влияние продукта может быть неочевидным до его выпуска, этот метод может предоставить убедительную финансовую информацию как для руководства, так и для клиентов.

Скорость

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

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

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

Завихренность (подвижный)

Один из вопросов, с которым сталкиваются многие агилисты и менеджеры проектов, — «насколько мы гибки?» На самом деле, поиск ответа на вопрос об измерении аджилити был святым Граалем агилистов во всем мире. Agile vorticity — это новая мера, которая делает именно это. На основе более чем 10-летнего тематического исследования гибкая завихренность была разработана с помощью сложного качественного метода, называемого обоснованной теорией.

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

Возраст рабочего элемента

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

Если кажется, что рабочий элемент стареет, чем его родственники, потому что он перемещается из одного спринта в другой, может возникнуть проблема с декомпозицией. Может быть, его нужно переопределить или лучше понять? Рабочие элементы, которые находятся в невыполненной работе в течение длительного периода времени, возможно, потребуется отбраковать или переопределить.

Непрерывная обработка невыполненных работ имеет решающее значение для планирования спринта и расстановки приоритетов. Растущее количество устаревших требований в невыполненной работе может означать проблемы с тем, как требования разрабатываются и разлагаются. Плохое управление требованиями — одна из основных причин неудач гибких преобразований.

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

Вывод

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

Всегда будьте уверены, что полностью понимаете и точно передаете то, о чем говорят показатели, и следите за тем, куда ведут данные. Один из способов управлять и поддерживать хорошие показатели — это надежная гибкая структура.