17 Agile-метрик для измерения продуктивности и производительности команды
28 марта 2022 г.
Измерение производительности при разработке программного обеспечения требует отслеживания определенных показателей для лучшего понимания того, как все части вашего процесса разработки работают вместе. Гибкие метрики могут помочь вам измерить производительность и качество на разных этапах вашего рабочего процесса. Понимание показателей Agile означает их эффективное измерение и знание того, какие из них важны для процесса разработки. В этой статье мы определяем эти показатели и обсуждаем 17 важных показателей Agile, которые следует измерять для повышения производительности и качества.
Что такое Agile-метрики?
Agile-метрики — это индикаторы, которые вы можете отслеживать на протяжении всего процесса разработки, чтобы контролировать качество и согласованность проекта, а также общую производительность команды. Эти показатели важны для выявления неудач, проблем команды, затрат и других показателей прогресса проекта. Метрики Agile являются частью Agile-разработки, которая представляет собой метод разработки, ориентированный на эффективность и производительность.
Вот основные типы показателей Agile, которые вы можете измерить:
Scrum: точки данных, которые команды разработчиков используют для улучшения своего процесса разработки и повышения его эффективности и результативности.
Канбан: метрики, которые помогут вам сосредоточиться на более важных частях процесса разработки.
Lean: метрики для измерения качества и согласованности проекта с использованием как можно меньшего количества ресурсов.
17 Agile-метрик для измерения
Измерение гибких метрик означает понимание того, какие метрики наиболее важны для процесса разработки. Вот 17 метрик, которые помогут вам улучшить качество и производительность вашего процесса Agile-разработки:
1. Время выполнения
Команды разработчиков отслеживают время выполнения заказа, чтобы измерить эффективность производственного процесса. Время выполнения — это измерение времени, которое требуется для реализации проекта с момента его запроса клиентом. Например, если на разработку приложения команде разработчиков требуется шесть недель, время выполнения заказа начинается, когда клиент делает запрос, и заканчивается через шесть недель, когда конечный продукт поступает к клиенту. Меньшее время выполнения может указывать на более эффективную команду разработчиков и процесс.
2. Время цикла
Этот показатель измеряет, насколько быстро команда разработчиков выполняет задачу. Разработчики измеряют время цикла, чтобы найти узкие места в процессе разработки или выявить препятствия для гибкой разработки. Например, вы можете измерить, сколько времени требуется команде для написания кода одного приложения, чтобы дать клиентам более точную оценку того, когда команда может завершить новые проекты. Меньшее время цикла может указывать на более эффективный процесс разработки и единую команду разработчиков.
3. Скорость
Скорость — это показатель, который отслеживает средний объем работы, которую команда разработчиков выполняет в течение одного спринта. Вы можете измерить скорость спринта с помощью часов или «очков истории», которые действуют как вехи во время отдельных спринтов проекта. Измерения скорости могут быть более точными, если у вас есть несколько итераций или точек истории для измерения. Чем выше скорость команды, тем эффективнее команда в процессе разработки, что позволяет быстро продвигаться по отдельным спринтам и целым проектам.
4. Выгорание спринта
Сгорание спринта — это отдельное измерение для отдельных задач во время спринта. Измерение выгорания спринта означает определение времени, которое команда должна выполнить для каждой задачи, и объема работы, которую осталось выполнить. Например, вы можете измерить метрику выгорания спринта, если команда придерживается жесткого графика разработки и отстает от отдельных задач. Вы также можете измерять выгорание спринта в часах или в пунктах для максимальной точности.
5. Суммарная блок-схема
Совокупная блок-схема — это метрика, которая позволяет измерять ход и эффективность проекта в более широкой перспективе, включая состояние задач в каждом спринте, ход каждого спринта и общий ход проекта. Эта диаграмма обеспечивает визуальное представление любых неудач или проблем в процессе разработки и может помочь вам определить узкие места в вашей Agile-разработке.
6. Покрытие кода
Метрика покрытия кода — это показатель того, какую часть жизнеспособного кода проекта покрывают ваши модульные тесты. Понимание того, какой объем кода могут охватывать ваши тесты, поможет вам создать более эффективные процессы тестирования и определить ход работы вашей команды по написанию кода, но это не обязательно поможет вам измерить общий прогресс или качество отдельных спринтов или всего проекта.
7. Статический анализ кода
Метрика статического анализа кода — это измерение жизнеспособности кода проекта без необходимости запуска программного обеспечения. Это измерение помогает вам протестировать код на наличие ошибок, ошибок и других проблем, прежде чем создавать окончательный продукт и запускать окончательные тесты. Этот показатель обычно является частью всего процесса разработки и может помочь повысить гибкость вашей разработки за счет сокращения количества ошибок и отзывов в готовом программном обеспечении.
8. Неудачные развертывания
Метрика неудачных развертываний — это показатель того, сколько раз команда развертывает или отправляет проект на этап тестирования или производства. Это измерение может показать вам, насколько эффективно ваша команда создает жизнеспособное программное обеспечение, готовое к тестированию или использованию. Измеряя количество неудачных развертываний по сравнению с количеством успешных, вы можете получить более полное представление о качестве работы вашей команды разработчиков.
9. Доставляемая ценность
Метрика «Доставленная ценность» — это измерение денежной или потребительской ценности каждой части проекта. Руководители проектов используют этот показатель, чтобы определить, какую ценность создает каждый проект. Например, менеджер проекта может измерить доход, который программное обеспечение приносит компании, по сравнению со стоимостью разработки этого программного обеспечения и присвоить ему денежную стоимость. Или менеджер может измерять удовлетворенность клиентов и назначать баллы каждому проекту, чтобы определить, какое место каждый проект занимает в цепочке создания стоимости.
10. Сбежавшие дефекты
Устраненные дефекты — это метрика, которая измеряет количество багов, ошибок или дефектов в проекте, когда он вводится в производство или закрывается в производстве и передается заказчику. Устраненные дефекты обычно являются мерой общего качества проекта и усилий команды по контролю качества. Поскольку ошибки во время производства могут привести к задержкам и проблемам с программным обеспечением, важно отслеживать упущенные дефекты, чтобы можно было применить методы их предотвращения, такие как более напряженные усилия по тестированию обеспечения качества.
11. Чистая оценка суфлера
Метрика чистого суфлера — это показатель готовности клиента рекомендовать ваши продукты другому человеку после их использования. Это помогает команде понять ценность своего программного обеспечения для клиента и предоставляет образец качества, который команда может использовать в будущих проектах. Вы можете измерить чистую оценку суфлера по шкале от -100 до 100, где 100 – наивысшая оценка. Чистая оценка суфлера также помогает вам измерить лояльность клиентов, что важно для успеха бизнеса, поскольку чем более лояльным является клиент, тем больше вероятность того, что он предпочтет ваши продукты конкурентам.
12. Счастье
Счастье — это измерение удовлетворенности команды разработчиков своим положением и компанией. Измерение счастья команды может помочь вам определить, нуждаются ли в улучшении рабочая среда, культура команды или инструменты и методы, доступные для них. Счастливая команда, как правило, более продуктивна, лояльна к компании и сосредоточена на качестве своей работы. Вы можете измерить счастье команды с помощью прямых интервью или групповых опросов, предоставив шкалу от одного до 10 для измерения счастья каждого члена команды.
13. Время выполнения функции
Время выполнения функции — это измерение времени, прошедшего между запросом на программную функцию и реализацией этой функции. Это помогает руководителю проекта определить, насколько эффективно команда разработчиков может добавлять новые функции в программное обеспечение и насколько это влияет на общее время выполнения и количество баллов. Обычно вы можете измерять время выполнения функции в часах.
14. Боевой дух команды
Моральный дух команды — это более продвинутая метрика счастья, которая фокусируется на конкретных, кратких заявлениях, помогающих руководителю проекта определить общее удовлетворение, которое испытывает каждый член команды разработчиков. Как правило, менеджеры измеряют моральный дух команды, прося членов команды согласиться или не согласиться с прямыми, действенными утверждениями, такими как:
Я чувствую себя ценным членом своей команды.
Я горжусь работой, которую делаю я и моя команда.
Мне нравится работа, которую я делаю для своей команды.
Я чувствую сильную связь с другими членами команды.
15. Пропускная способность сюжета
Пропускная способность историй похожа на скорость в том смысле, что они оба измеряют количество историй, которые команда завершает за один спринт. Тем не менее, пропускная способность историй фокусируется на измерении истории после завершения, а не когда команда начинает их. Это может показать менеджеру проекта, сколько историй команда фактически завершает за спринт и сколько историй составляет весь проект.
16. Качественная разведка
Аналитика качества — это метрика обеспечения качества, которая помогает команде разработчиков измерять жизнеспособность и качество программного обеспечения в целом, вместо того, чтобы сосредотачиваться на конкретных этапах процесса разработки. Используя качественные аналитические инструменты, команда может выявлять любые программные ошибки или проблемы до поставки, создавая высококачественные результаты для клиентов. Измерение данных на протяжении всего жизненного цикла разработки обеспечивает более широкое представление о качестве проекта и усилиях команды по поддержанию или повышению качества проекта.
17. Эпик и выгорание релиза
Метрика выгорания эпика и релиза отслеживает ход выполнения большого объема работы. Это отличается от выгорания спринта, который фокусируется на прогрессе в разные периоды времени или спринты. Диаграммы выгорания эпиков и релизов обычно отслеживают такие показатели, как:
Работы завершены
Работа добавлена
Прогноз работы
Осталось работы