Измерение продуктивности инженеров — сложный процесс: сложно получить полную картину того, как разработчики тратят свое время. Распространенный способ измерения производительности — анализ системных показателей, таких как DORA или SPACE. Это могут быть чрезвычайно полезные показатели для понимания продуктивности команды по сравнению с отраслевыми стандартами. Анализ каждого из этих показателей также может дать представление о том, что замедляет работу команды. Но иногда существуют «скрытые карманы» времени, которые разработчики тратят в течение дня, и которые могут не восприниматься как влияющие на производительность. Однако когда мы начнем складывать эти цифры, цифры могут вызвать тревогу. Например, представьте, сколько времени разработчик тратит на отладку нестабильного теста, пытаясь выяснить, провалился ли он из-за внесенных изменений или нет. Или время, потраченное разработчиком, который пытается устранить сбой основной сборки. Чтобы обеспечить такую перспективу, мы создали калькулятор, который позволяет оценить инженерную эффективность. Это ни в коем случае не дает полного анализа эффективности вашей инженерной команды. Что он действительно дает, так это представление о «скрытых карманах» потраченного впустую времени, которые обычно не проявляются в более распространенных показателях производительности. Калькулятор показывает, сколько времени вы и ваша команда теряете из-за сбоев сборки и тестирования в рабочих процессах разработчиков. Если вы сравните это с показателями DORA, то на время выполнения изменений существенно влияет нестабильность сборки и тестирования. Это влияние можно оценить с помощью этого калькулятора. Как это работает Мы просим вас вводить данные на основе вашей деятельности на GitHub и того, как вы используете ветки GitHub. Чтобы объяснить фактические вычисления ниже, давайте назначим переменные каждому из них: M – PR объединены за день X – отказы магистрали за неделю T – среднее время CI F – коэффициент шелушения, % На основе этих данных мы оцениваем, сколько времени ваша команда инженеров тратит еженедельно на устранение сбоев сборки и работу с нестабильными тестами. Давайте рассмотрим результаты один за другим. Часы потрачены на исправление Это подсчитывает, сколько часов тратится на идентификацию, сортировку, исправление и повторное выполнение сборки при обнаружении сбоя основной сборки. Обычно в большой команде кто-то заметит и сообщит о неработающей основной сборке. Мы предполагаем, что в случае сбоя основной сборки в отладке и исправлении участвуют в среднем 1-3 разработчика. Если принять во внимание, что время, необходимое для сообщения о проблеме и внесения исправления в среднем составляет один час, мы тратим на отслеживание, исследование и решение проблемы. (2*T + 1) часов Это означает, что если в неделю происходит X сбоев, мы тратим (( времени разработчиков на борьбу с сбоями основной сборки каждый день. 2 разработчиков * X/5 * (2*T + 1)) часов Часы, потраченные впустую на разрешение конфликтов слияния Откаты и конфликты слияний могут вызвать дополнительные проблемы. Предполагая, что примерно 2% PR имеют конфликты слияния в течение периода нарушенного времени сборки , а PR приходят каждый час, мы потратим тратится впустую на разрешение этих конфликтов. ((2*T + 1) * X/5) M/8 ((2* Т + 1) * Х/5) * 0,02 * М/8 Еженедельные сбои CI из-за сломанных сборок Если команда не использует золотую ветвь в качестве основы для своих веток функций, они, скорее всего, создадут ветки функций поверх неудачной основной ветки. Поскольку количество PR, созданных в любое время, будет аналогично среднему количеству ветвей функций, основанных на основной ветке, это приведет к тому количество сбоев CI, происходящих каждый день. . , что (2*T + 1 час) * X/5 * M/8 Время решить CI При примерно пятнадцати минутах переключения контекста при каждом сбое сборки это часа времени разработчика, ежедневно тратимого впустую из-за сбоев CI. (2*T + 1 час) * X/5 * M/8 * 0,25 Время, потраченное на повторный запуск нестабильных тестов. Аналогично, в случае с нестабильными тестами время переключения контекста требуется для того, чтобы выяснить, был ли тест нестабильным или реальным, а сам повторный запуск тестов занимает в среднем пятнадцать минут за один запуск. В зависимости от фактора нестабильности разработчики тратили бы часов каждый день. (0,25*M*F/100) Повышение эффективности Хотя большинство из них влияют на показатели DORA, связанные со мы все еще только поверхностно оцениваем неэффективность рабочих процессов команды инженеров. Влияние сбоев сборки и тестирования также приводит к задержке выпусков, что влияет на другие показатели DORA, такие как и постоянство нестабильных тестов в системе, что может привести к более высокой вероятности возникновения сбоев. . временем выполнения изменений, частота развертывания, время восстановления обслуживания Узнайте больше о метриках DORA Или узнать больше об их недостатках. Мы создали , чтобы решить некоторые из этих скрытых проблем для больших инженерных команд. Сегодня, используя Aviator MergeQueue, многие инженерные организации могут масштабировать рабочий процесс слияния, не нарушая сборки. Объединив это с ненадежной системой подавления тестов, такой как , команды могут экономить сотни инженерных часов каждую неделю. Aviator TestDeck Также опубликовано . здесь
