Как лучше всего измерить продуктивность разработчиков в 2022 году?

Что именно мы измеряем, когда оцениваем продуктивность разработчиков?

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

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

![Фото Райланда Дина на Unsplash]

Что означает продуктивность разработчиков?

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

Текущая парадигма измерения производительности разработчиков основана на четырех ключевых показателях производительности доставки программного обеспечения. Сопоставив данные многолетних опросов тысяч специалистов по DevOps, команда Google DevOps Research and Assessment (DORA) смогла определить эти четыре важнейших контрольных показателя для измерения производительности разработчиков. Это позволяет командам определить свои результаты между [Elite и Low**]**, а также отметить области, в которых им необходимо продвинуться, чтобы добиться дальнейшего успеха.

Четыре показателя Accelerate, используемые для измерения производительности:

1. Частота развертывания:

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

1. Время внесения изменений:

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

1. Изменить процент отказов:

Какой процент изменений в коде приводит к сбоям развертывания или ошибкам, требующим исправлений, откатов или других ручных исправлений? Элитные команды сообщают о коэффициенте от 0% до 15%, в то время как в последнем отчете о состоянии DevOps за 2021 год стандарт для команд высокого и среднего уровня увеличился до 16%-30%.

1. Пора восстановить сервисы

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

![Фото Джефферсона Сантоса на Unsplash] (https://cdn.hackernoon.com//images/5piuqbzGNPae5bZRCn8CCDvc78P2-2022-04-19T12:50:12.428Z-cl2658pql000g0as64d42abii)

Зачем измерять показатели DORA?

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

Такие инструменты, как Haystack и Linear B, помогают измерять вышеуказанные показатели, предоставляя постоянный анализ производительности вашей команды, извлекая данные из потоков, включая GitHub и GitLab, чтобы помочь вам обнаружить блокираторы. в производительности доставки программного обеспечения и убедитесь, что ваша команда эффективно достигает всех четырех показателей.

Но есть ли ограничения для DORA framework?

Что ДОРА вам не говорит

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

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

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

![Фото Марса на Unsplash] (https://cdn.hackernoon.com//images/5piuqbzGNPae5bZRCn8CCDvc78P2-2022-04-19T12:50:12.431Z-cl2658pqn000h0as6b40cgw4i)

Сотрудничество и благополучие

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

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

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

К счастью, у нас есть инструмент для этого.

![Фото Джейсона Гудмана на Unsplash] (https://cdn.hackernoon.com//images/5piuqbzGNPae5bZRCn8CCDvc78P2-2022-04-19T12:50:12.431Z-cl2658pqn000i0as69h4w60m1)

Как мы делаем это?

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

Мы получаем данные о производительности с таких платформ, как GitLab, Jira и Google Workspace, и объединяем их с данными из таких инструментов для совместной работы, как Slack, чтобы получить общее представление о работе нашей команды. производительность доставки программного обеспечения.

Если вы являетесь частью технической команды, вам следует обратить внимание на следующее:

• Как вы управляете балансом между работой и личной жизнью?

• Сколько раз вы отвечали на сообщения в Slack до позднего вечера?

• Вы налаживаете прочные рабочие отношения, сотрудничая с одними и теми же разработчиками в нескольких проектах?

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

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

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

Также опубликовано здесь