Новости

May 22, 2023

Почему разработчики программного обеспечения предпочитают метрики DORA

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

Дилан Эткин, InfoWorld |

Новые технологии в анализе технологов

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

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

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

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

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

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

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

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

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

Николь Форсгрен, одна из основательниц DORA (DevOps Research Assessment), разработала эту структуру, целью которой является понимание продуктивности разработчиков. Но вместо жестких показателей структура SPACE фокусируется на душевном состоянии и физическом благополучии разработчиков, которые, несомненно, являются важными факторами общего удовольствия разработчиков от своей работы и эффективности работы команды.

Структура SPACE оценивает пять аспектов продуктивности разработчиков:

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

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

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

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