Agile метрики. Часть 1: Принципы.

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

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

Я разделил все метрики на пять категорий:

• Метрики Agile Project Tools – отслеживают элементы с которыми работает ваша команда
• Метрики Lean Kanban – получаются из Agile Project Tools или других источников
• Метрики из Инструментов Контроля Версий (VCS) – отслеживают коммиты, которые разработчики вносят в кодовую базу
• Метрики из Инструментов CI/CD – берутся из автоматизированных инструментов непрерывной интеграции и непрерывной доставки.
• Показатели Бизнес Аналитики – показывают как клиенты используют ваше программное обеспечение, как растет ваш бизнес, что клиенты думают о ваших продуктах и т.п.

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

Принципы Agile-метрик

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

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

Принцип №1: Agile метрики должны использоваться командой

Несмотря на очевидность данного принципа, им часто пренебрегают. В 99% случаев использования agile-метрик, этот принцип не соблюдается. В большинстве случаев потому что, кто-то вне команды, как правило менеджер, хочет “шпионить”, “измерять” или “оценивать” команды для “проверки продуктивности”. Это плохой подход по следующим причинам:

• данные показатели не измеряют продуктивность;
• не существуют простого способа измерения продуктивности;
• продуктивность – не является главным критерием успеха – вместо нее следует рассматривать поставку ценного программного обеспечения (я скорее выберу не продуктивную команду, которая поставляет ценное ПО, вместо продуктивной, которая поставляет бесполезное в любой день недели);
• большинство метрик являются отправными точками для обсуждений на встречах в команде, и если “менеджеры” смотрят эти показатели в отчете, то скорее всего они не берут участия в этих встречах;
• значения многих показателей зависит от окружающего их контекста, и единственные люди, которые понимают эти значения – члены команды.

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

Принцип №2: Agile метрики должны быть окружены обсуждениями

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

Принцип №3: Agile метрики должны быть частью конкретного исследования или эксперимента

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

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

Продолжение

В следующей статье мы начнем рассмотрение метрик. Первыми будут метрики из Agile Project Tools.