Agile метрики – какие из них важны и почему?

Всем привет!

Автор статьи расскажет об agile метриках трех разных категорий: производительность, стабильность и качество, а также какие метрики важны и почему. А еще в статье вы найдете бесплатный мини-курс по Agile, Scrum и Kanban!

Автор статьи – Dr. Sreeram Mullankandy (читать оригинал)

Содержание:

1. OKR - вклад в достижение целей
2. Предоставленная ценность (Value Delivered)
3. Диаграмма сгорания задач для спринта (Burndown chart)
4. Скорость (Velocity)
5. Время производства (Lead time)
6. Время цикла (Cycle time)
7. Накопительная диаграмма потока (Cumulative Flow Diagram/CFD)
8. Индекс потребительской лояльности (Net Promoter Score/NPS)
9. Соотношение запланированного и выполненного (Planned to Done Ratio)
10. WIP (Work In Progress)
11. Коэффициент своевременного выпуска (On-time release date)
12. Неудачный деплоймент (Failed Deployment)
14. Коэффициент текучести кадров (Team Turnover rate)
15. Оценка счастья (Happiness score)
16. Время устранения дефектов (Defect Resolution Time)
17. Покрытие кода (Code coverage)
18. Тестовое покрытие (Test coverage)
19. Пропущенные дефекты (Escaped defects)

За последние несколько десятилетий методология Agile захватила индустрию разработки программного обеспечения. Каждая технологическая организация либо уже является Agile, либо находится в процессе трансформации в Agile – их принято называть "Wagile!" (WAGILE – это гибридный процесс, который сочетает в себе лучшее из традиционных водопадных систем (waterfall systems) и методологии Agile ("W" + "Agile") - прим.ред.). Традиционные метрики управления проектами, такие как производительность, отклонения от графика, отклонения от стоимости и т.д., могут оказаться бесполезными в Agile-системе. Более того, они могут быть контрпродуктивными.

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

Для простоты давайте классифицируем метрики по трем категориям – производительность, стабильность и качество.

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

Важно измерить, сколько усилий вашей команды направлено на достижение стратегических целей организации или бизнес-подразделения. Например, можно показать, что в среднем 60% усилий команды направляется на достижение OKR в каждом спринте. В идеале 50% или более усилий должны быть направлены на достижение OKR или стратегических целей компании.

Данная метрика помогает измерить ценность, полученную в каждом спринте. Это проще сделать в организациях, управляемых продуктом, где формула или матрица расстановки приоритетов включает оценку ценности так же, как команды разработчиков оценивают Story Points (относительная мера сложности или трудоёмкости элементов бэклога продукта - прим ред). Например, метод приоритезации WSJF (Weighted Short Job First - Сначала Более Ценная и Короткая Работа) Модель оценки бэклога, на выходе с которой вы получаете приоритизированный список, где первый элемент — самый простой в реализации, но при этом и самый ценный с точки зрения бизнеса. - прим. ред.). WSJF оценивает точки ценности со стороны бизнеса, снижения рисков, критичности по времени и расширения возможностей, а метод RICE оценивает ценность по охвату и воздействию.

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

В широком смысле, скорость представляет собой количество Story Points, завершенных в каждом спринте (Story Point — это единица измерения, используемая в гибком управлении и разработке для оценки сложности реализации задач – прим. ред.).

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

Lead time обозначает время, которое проходит с момента создания рабочего элемента (сюжета, фичи или эпики) до его завершения (включает в себя Cycle Time и время ожидания в очереди на реализацию). Это хороший показатель эффективности работы команды. Чем меньше время ожидания, тем эффективнее команда в плане превращения идей или нереализованных запросов в работающее программное обеспечение.

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

Диаграмма кумулятивного потока дает вам представление обо всем процессе приема, разработки, тестирования и выпуска продукта от начала до конца. CFD – это простой способ визуализации, позволяющий мгновенно выявлять проблемные места.

Net Promoter Score – это процентная оценка разницы между вашими промоутерами и критиками. Клиентов просят поставить оценку от одного до десяти в качестве ответа на вопрос – с какой вероятностью они порекомендуют продукт другим? Те, кто поставил 9 и 10 баллов, являются промоутерами, 8 и 9 - нейтралами, а 6 и ниже – критиками.

(Промоутер: лояльные клиенты, которые высоко оценивают продукт или услугу и, скорее всего, будут рекомендовать их другим.

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

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

NPS, пожалуй, самая важная метрика из всех, поскольку клиент – лучшая заинтересованная сторона, которая может определить, предоставила ли команда что-то ценное для него.

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

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

WIP (Work In Progress – Задачи в работе – прим. ред.) – это ключевая метрика из Канбан – вы можете найти ее и в Скрамбане (гибкий подход, представляющий гибрид Скрама и Канбана). WIP – это количество рабочих элементов, над которыми активно ведется работа. Цель состоит в том, чтобы ограничить количество незавершенных работ, чтобы было меньше переключений контекста и чтобы команда вовремя устраняла блокирующие факторы. В идеале, мы должны стремиться к тому, чтобы на одного участника скрам-команды приходилось не более 1-2 задач одновременно.

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

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

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

Эта метрика показывает количество неудачных деплойментов (развертываний и запусков веб-приложения/сайта на сервере или хостинге – прим. ред.). за определенный период времени. Она используется для производственных развертываний серверов и для развертываний в нижних средах. Это показатель стабильности кода, который демонстрирует, готова ли команда разработчиков предоставить к концу спринта потенциально пригодный для отправки код.

Это одна из самых важных метрик для стабильности. Коэффициент текучести представляет собой скорость, с которой участники agile-команды покидают команду и заменяются другими. Текучесть кадров обходится недешево: затраты на наем сотрудников, время выхода на работу, потеря институциональных знаний – и это только некоторые из них. Определенное количество оттока неизбежно. Но если он превышает отраслевую норму, команда должна решить эту проблему. В целом, текучесть кадров в технологической отрасли составляет от 10 до 15% в год. Три основные причины текучести кадров – это заработная плата, возможности карьерного роста и условия работы. Итак, вы уже знаете, что делать, если у вас высокий уровень текучести кадров.

Подобно CSAT (Customer Satisfaction Score/Индексу удовлетворенности клиентов), Happiness Score оценивает по пятибалльной шкале средний уровень счастья команды. Опрос обычно проводится в рамках ретроспективы спринта и отслеживается во времени, чтобы выявить отклонения от нормы от спринта к спринту. Показатель счастья имеет прямую зависимость от коэффициента текучести кадров. Он обратно пропорционален коэффициенту текучести кадров – чем больше показатель счастья, тем меньше текучесть кадров!

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

Время устранения дефектов (DRT – Defect Resolution Time) или среднее время устранения (MTTR – mean time to recovery) – это среднее время, которое требуется команде разработчиков для устранения дефекта. Чем меньше, тем лучше. Среднее DRT или MTTR обычно отслеживается для дефектов во всех сферах.

SLA (Время ответа Service-Level Agreement — соглашение об уровне услуг – прим. ред.) для DRT варьируются в зависимости от типа организации и направления команды. В целом, команды должны стремиться к максимальному DRT в 1 день для критических дефектов, 1-2 дня для серьезных дефектов, 5-7 дней для средних и 10-14 дней для простых дефектов. MTTR находится в обратной зависимости от удовлетворенности клиентов и, следовательно, имеет большое значение.

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

Иногда термин "тестовое покрытие" используется как взаимозаменяемый с термином "покрытие кода". Но это не одно и то же. Покрытие кода измеряет, покрывается ли написанный код тестами или нет, а тестовое покрытие измеряет, покрываются ли функциональные требования существующим набором тестовых примеров. Стремитесь к покрытию 70-80%.

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

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

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

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

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

В результате обучения вы:

узнаете:

• принципы Agile и откроете для себя мир гибкого управления
• как управлять проектами и продуктами в условиях неопределенности с помощью гибких подходов
• как внедрить Agile в своей компании

научитесь:

• применять Scrum и Kanban на практике

сможете:

• улучшить процессы своей команды и ускорить разработку продуктов
• претендовать на карьерное продвижение

получите:

• международный сертификат от консорциума ICAgile
• сертификат от Product Lab