Авиатор спонсировал этот пост.
Монитонные панели, рамки метрик, аббревиатуры, показатели показателей, инструменты — в спешке к количественной оценке и оптимизации каждого аспекта разработки программного обеспечения, наша отрасль забыла, что метрики никогда не должны измерять производительность вообщеПолем
Метрики DORA — это не индивидуальная производительность или инструмент для сравнения команд. Веб -сайт для Dora — группы исследований и оценки Google — все еще напоминает нам, что эти четыре метрики — частота развертывания, время выполнения изменений, среднее время для восстановления и изменения частоты отказов — не являются показателями производительности. Это показатели доставки, которые помогают инженерным организациям «поправляться в улучшении».
Но в мире удаленной работы и асинхронных команд пост-ковиды мы увидели рост небезопасности менеджера о том, что и как делали их команды, поэтому родился «Промышленный комплекс производительности разработчика». Были добавлены десятки дополнительных метрик, появились новые инструменты, и были созданы мониторные мониторинги, отслеживающие 30 или 40 метрик. В постоянных усилиях по созданию лучших показателей, чтобы разработчики могли быть более продуктивными, мы потеряли то, что они стали циклом обратной связи.
«Измерение производительности разработчика — это поручение дурака»
Мартин Фаулер, архитектор современной разработки программного обеспечения, был прав. Мы не можем измерить производительность разработчиков. Определение производительности состоит в том, сколько вывода генерируется для данного количества ввода. Как бы мы даже попытались выяснить продуктивность человека?
Но мы можем измерить прокси для эффективности команды и обработки здоровья. Мы на самом деле хотим выяснить, это ответы на два вопроса:
- Способны ли мы как организация часто и эффективно отправлять, чтобы мы могли поддерживать бизнес?
- Является ли жизнь индивидуальным разработчикам в этой организации хорошей?
Вопросы обманчиво просты, но им очень трудно ответить. И когда доверие мало в организации, менеджеры склонны опираться на данные. Они чувствуют, что им приходится поддержать эффективность, наем или бюджет своей команды с числами, и именно так мы получаем, как показатели доры интерпретируются как показатели производительности или, что еще хуже, производительность отдельного разработчика, измеряемых строками написанного кода.
Старшие инженеры часто пишут меньше кода, а не больше. Они тратят время на наставничество, знания проектов, разблокируя товарищей по команде и улучшая архитектуру. Это занятия с высоким уровнем леверей, но они не появляются на приборной панели метрик. Билл Гейтс однажды сказал, что измерение программного обеспечения по линиям кода похоже на измерение самолета по весу.
Зачем вообще измерять?
Есть две причины: ценность или риск. Либо мы считаем, что изменение поможет нам обеспечить большую ценность (быстрее, лучше, дешевле), либо мы считаем, что существует риск (технический долг, нестабильность, стоимость инфраструктуры), который должен быть рассмотрен.
Чтобы решить это, мы должны идентифицировать это, и лучший способ сделать это-не смотреть на панель панели, а для картирования потока стоимости, отследить путешествие от идеи к производству до созданной ценности. Где задержки? Где отходы? Где вещи падают? Затем выберите метрики, не для того, чтобы измерить людей, а для улучшения системы.
В конечном счете, все, что мы делаем в опыте или производительности разработчиков, должно быть связано с результатами бизнеса. Вот почему метрики важны — как механизм обратной связи. Мы должны подключить метрики к ценности, измерять их и всегда проверять, приводит ли улучшение метрического уровня ожидаемое значение.
Проектирование метрик, которые имеют значение
Если бы нам было поручено разработать метрики доставки или производительности с нуля в инженерной организации, вот как мы подходим к ней:
Шаг 1: Соберите требования
Не ныряйте и не измеряйте, чтобы измерить. Каждая инженерная работа начинается с сбора требований. Что спрашивают и почему? Вы часто услышате такие проблемы, как медленное развертывание, длительные циклы обзора, сложенные тесты или частые инциденты. Посмотреть на метрики Dora часто является солидным первым ответом, но вы все равно должны сначала задать вопросы.
Шаг 2: Поговорите с заинтересованными сторонами Frontline
Метрики не живут в вакууме. Поговорите со своими заинтересованными сторонами, обычно командой продукта. Спросите их: что для вас не достаточно хорошо для вас?
Шаг 3: Поговорите с руководством
Ваш следующий разговор с руководством. Объясните, что вы планируете делать с проблемами, которые поднял продукт. Руководство управления и поддержка необходимы; Для достижения ваших целей вам может понадобиться бюджет на инфраструктуру или найм.
Шаг 4: Поговорите с инженерией
Этот шаг часто пропускается именно потому, что метрики не рассматриваются как механизмы обратной связи для улучшения. Поговорите с инженерией и спросите их, как они решат проблему. Не входите с указанием нисходящего вниз: «Вот ваши новые цели производительности».
Шаг 5: Пара метрик с ограждениями
Мы все знаем закон Гудхарта: «Когда мера становится целью, она перестает быть хорошей мерой». Если вы попытаетесь улучшить только одну метрику, люди рано или поздно поймут, как играть в это число.
Допустим, вы определили, что есть проблема качества кода, которую вы бы хотели улучшить. Увеличение тестового покрытия кажется первой метрикой, которая приходит на ум, но вы также должны помнить о времени построения и сбои в строительстве. Теперь у вас есть целевой показатель, который вы хотите улучшить, и два числа, которые действуют как ограждения. Опять же, Дора представляет собой набор из четырех метрик, а не единой метрики, и отдельный инженер практически невозможно переместить любой из них.
Шаг 6: Drop или Deprioritize устаревшие метрики
Опять же, метрики — это механизм обратной связи. После того, как вы достигли желаемого улучшения тестового покрытия, вы можете изменить эту метрику в фоновом режиме и просто отслеживать, падает ли он ниже определенного уровня. Не влюбляйтесь в перегрузку метрик. Если вы активно отслеживаете 40 метрик, как бы вы узнали, что важно?
Имейте в виду, что метрики не будут измерять производительность и не решат проблемы вашей инженерной организации; Они просто помогут вам определить их.
В Aviator мы строим инструменты, вдохновленные инициативой Google по производительности производительности в современном инженерном стеке для решения проблем совместной работы на каждом этапе процесса разработки, от обзоров кода до сборки, тестирования, слияния и развертывания.
Aviator-это разработчик с низким содержанием конфигурации, работающий с AI, который автоматизирует владение, обзоры кода, слияния и развертывание. Он создает организационный график знаний для упрощения назначения билетов, резюме проекта и поддержки внутренней разработчиков. Узнайте больше последних из Aviator Trending Stories YouTube.com/thenewstack Tech Moving быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Ankit Jain является соучредителем и генеральным директором Aviator, разработчика с низким конфигурацией, который автоматизирует владение, который автоматизирует владение, обзоры кода, объединяет и развертывает. Он также возглавляет ангар, сообщество старших DevOps и старших инженеров -программистов, ориентированных на опыт разработчиков, … Подробнее от Ankit Jain Adam Berry работал над инструментами разработчиков и инфраструктурой на протяжении всей своей карьеры, от плагинов Eclipse до обслуживания и инфраструктуры; Теперь он сосредотачивается на платформах разработчиков как на продуктах, чтобы расширить возможности инженеров и сделать команды и организации более эффективными. Подробнее от Адама Берри
