Метрики программной инженерии

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

Вступление

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

Я создал библиотеку под названием EngineeringMetrics, чтобы обеспечить гибкий механизм для построения информационных панелей из компонентов, предназначенных для наблюдения за многими измерениями работы. Рассчитанные однажды данные могут быть позже опубликованы на сайте Confluence (макросы Jira Confluence поддерживаются для динамического обновления данных). Всю настройку можно произвести в ноутбуках jupyter.

Доступно множество инструментов, таких как встроенные гаджеты, информационные панели и отчеты в Jira, макросы в Confluence или такие инструменты, как eazyBI, но благодаря настраиваемому коду мы можем делать все (без затрат на лицензию). Например, мы можем интегрировать данные из разных источников, таких как Jira, Git, ServiceNow, и рассчитывать числовые измерения ключевых результатов, которых, как мы ожидаем, команда (группы) добьется. Мы можем разместить все на одной странице для всей организации.

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

Несколько примечаний:
1. В этой библиотеке есть функции в дополнение к метрикам DORA (DevOps Research & Assessment), из которых мы можем узнать, насколько мы успешны в DevOps (DF - Deployment Frequency, MLT - Среднее время выполнения изменений. , MTTR - среднее время восстановления, CFR - изменение частоты отказов).

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

Планирование и исполнение

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

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

Метрики выполнения

Показатели выполнения служат для измерения объема выполненной работы по сравнению с выполненной. Эти данные показывают, насколько предсказуема команда. В отличие от Story Points, процент выполненной работы по сравнению с запланированной можно сравнивать между командами. Такие показатели также можно агрегировать на уровне организации.

Доступный анализ:

  • Гистограмма сводной информации о выполнении для организации
  • Гистограмма истории выполнения для команды
  • Подробные сведения о последнем спринте, такие как цель, даты начала и окончания.
  • История оттока области
  • Перенести проблемы, которые были в более чем одном спринте и еще не решены

Пример основных результатов:

  • 90% содержимого спринта, переданного командой, доставляется.

Пример показателей выполнения для активных спринтов на уровне организации

Пример истории выполнения отряда

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

Пример истории оттока прицела на уровне отряда

Диаграмма «Отток объема» показывает количество задач в спринте, которые были добавлены, удалены, разблокированы и заблокированы в каждом спринте. Это могут быть признаки проблем с дорожной картой продукта и / или корректировкой приоритетов между организациями, отсутствие адекватного предварительного планирования между спринтами (уточнение бэклога), недостаточное количество заинтересованных сторон, приводящее к отсутствующим требованиям, производственным инцидентам, проблемам с Dev / Среда контроля качества и т. Д.

«Перенести» - задачи, которые были в более чем одном спринте и еще не решены.

Разрешение зависимостей

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

Коэффициент зависимости рассчитывается по следующим правилам:

  • ищет "внешние" зависимости, которые могут быть прямыми или косвенными.
  • тип ссылки - «Заблокировано» или «Зависит от».
  • связанные зависимости фильтруются, если их статус «Готово».
  • а также элементы Jira в заблокированном состоянии, на которых нет ссылок. Это считается, потому что есть команды, которые не используют Jira.

Доступный анализ:

  • Исторические показатели независимости («все проблемы» против «проблем с зависимостями», столбчатая диаграмма с накоплением с коэффициентом независимости 0–100 по оси Y и датами по оси X)
  • Разбивка внешних зависимостей по командам (внешние проекты Jira)
  • Разбивка внешних зависимостей по инициативе (Jira Epic)
  • Графики зависимостей, показывающие ссылки до второго уровня
  • Внутренние и внешние зависимости на уровне организации
  • Показатель общей независимости: сумма (all_issues) / сумма (all_with_dep)
  • График истории общей независимости

Пример основных результатов:

  • Фактор независимости всех команд ›90% (не более 10% историй, зависящих от работы другой команды)
  • Фактор независимости единой команды ›80%

Пример резюме независимости на уровне организации

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

Чтобы лучше понять ситуацию, мы можем провести дополнительный анализ:

Пример разбивки по зависимостям, чтобы узнать, от каких команд у нас есть зависимости и какие проекты заблокированы.

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

Отслеживание прогресса проекта

Метрики проекта предназначены для расчета прогресса проекта на основе количества выполненных задач и определенных для данного эпоса (инициативы). Метрики выполнения сосредоточены на спринтах, а не на подробностях того, сколько работы было выполнено для данного проекта. Метрики проекта сосредоточены на ходе проекта.

Доступный анализ:

  • Процент выполненного
  • Детали спринта
  • Круговая диаграмма по типу задачи (макрос Confluence Jira)
  • Напоминание о работе
  • Риски
  • Заблокированные истории (списки и графики зависимостей)

Пример основных результатов:

  • 80% сценариев использования, приносящих доход, выполняются вовремя

Метрики обеспечения качества

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

Цель состоит в том, чтобы контролировать:

  • В производственной среде обнаружены инциденты, оказывающие негативное влияние на конечного пользователя (программное обеспечение работает не так, как ожидалось)
  • Бюджет ошибки означает, что мы можем продвигать функции до тех пор, пока не будет достигнут SLO, но новые функции не допускаются, пока бюджет не будет перебалансирован. SLO должны быть определены для каждой службы, измеренные для подсчета несоответствующих запросов, например, если задержка обслуживания увеличивается, бюджет уменьшится.
  • Баланс ручного и автоматического тестирования. Есть определенные случаи, когда для тестирования системы требуется человек (тестирование удобства использования, UI / UX, исследовательское тестирование или специальное тестирование, которое не является частью регрессии). С другой стороны, тестовые примеры в наборе регрессии должны быть максимально автоматизированы.

Пример основных результатов:

  • В продакшене обнаружено не более 1 инцидента для 10 релизов
  • 10% или меньше усилий достаточно для поддержания стабильного состояния невыполненных работ (SLO выполняется)
  • 90% и более тестовых случаев выполняются не реже одного раза в неделю.

Выводы

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

Если вы используете Jira и Confluence, вы можете повторно использовать или настроить мой инструмент отчетности. Он общедоступен на github. Также есть дорожная карта с дополнительными метриками и анализом, которые нужно добавить. Проверьте это, чтобы найти дополнительную информацию здесь: https://github.com/LukaszSwolkien/EngineeringMetrics

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