По словам Роба Зубера, технического директора CI/CD Platerds Circleci, существует странная напряженность среди лидеров разработки программного обеспечения, когда речь заходит о производительности. Они должны взвесить радость от создания продуктов, которые компании могут использовать в отношении необходимости убедиться, что это сделано таким образом, чтобы лучше всего принести пользу их собственным предприятиям.
«Большинство инженерных лидеров выросли как инженеры и ценили личное вознаграждение и исполнение того, что они действительно продуктивны, потому что никто не любит бороться с трудом и борьбой с инструментами и всеми такими вещами», — сказал Зубер новому стеку. «Они любят доставлять продукт. На самом деле, действительно ли они в масштабировании бэкэнд -систем или размещение фронталов перед клиентами, что бы это ни было, это то, что действительно ценят инженеры».
Но когда дело доходит до измерения, есть «своего рода любопытная, аллергическая реакция» инженеров, которые чувствуют, что их всегда судят, сказал он. Организации должны решить для этого, потому что инженерные лидеры и другие руководители должны бороться с буксиром и измеряющим то, что они получают с точки зрения эффективности, независимо от того, продвигаются ли они достаточно быстро по сравнению со своими сверстниками.
Добавление ROI в микс
Это причина, по которой Circleci из Сан-Франциско использует расширенный подход к своему годовому отчету о доставке программного обеспечения, а шестое издание выпущено во вторник. В отчете по -прежнему рассматриваются ключевые показатели, используемые для определения производительности — продолжительность, пропускную способность, среднее время для восстановления (MTTR) и показатель успеха — но поставщик также измеряет организации ROI, полученные из них, ключевой инструмент измерения для лидеров бизнеса и заинтересованных сторон.
Это также становится важной метрикой, поскольку ИИ пронизывает практически каждый уровень разработки программного обеспечения, так же, как его толкает в любом другом его аспекте, и бизнес растет.
«Конечно, это оказывает влияние на нашу способность каким -то образом доставлять и [IT’s important] Зная, мы добились успеха? Мы следим за конкуренцией? » Zuber сказал.
Отчет основан на анализе поставщика почти 15 миллионов рабочих процессов команд, создающих программное обеспечение на платформе Circleci. Он также исследует, что такие передовые технологии, как автоматизация в CI/CD, инфраструктура как код (IAC) и ИИ означают для доставки программного обеспечения.
Метрики Circleci
Скорость — это ключ
Выводы на верхнем уровне заключались в том, что 25% исполнителей продолжали отделяться от остальной части пакета, в значительной степени из-за скорости. Например, они отправили обновления в три раза быстрее, чем команды в нижних 25%, что дает им рыночное преимущество в скорости развития.
Они сэкономили миллионы в годовых затратах на разработку, опять же из-за скорости: они выполнили критические рабочие процессы в пять раз быстрее, чем более низкоэффективные единицы, которые освободили ресурсы для стратегических инициатив-и отлаживали продукты в минуты, а не дни, освобождая больше времени для разработчиков.
«Части, которые были последовательными на протяжении многих лет, но все еще очень важны для нас [is] Это движение быстро выигрывает рынок и быстрое движение зависит от отличных систем, процессов, [and] приближается », — сказал он.
Именно здесь появляются эти передовые технологии, особенно ИИ и автоматизация. Они увеличивают скорость доставки программного обеспечения, и эти организации в верхней части списка являются теми, которые адаптируются к быстро развивающемуся характеру инженерии и обеспечения ценности для своих пользователей.
«Исторически, нам всегда приходилось выбирать между скоростью и качеством, и это, наконец, в том, что быстрое движение — это то, что стимулирует качество, потому что вы просто не можете сделать это, если вы не очень хороши в качестве», — сказал Зубер.
Другой фактор метрик в
Однако он предупредил, что это не единственный калибр. Команда разработчиков может быстро изготовить продукты, но это не принесет пользы, если продукт неисправен или если организация медленно устраивает исправления. Вот где другие показатели имеют значение, от продолжительности рабочего процесса до скорости восстановления до успеха. Цель отчета — дать разработчикам и руководителям команды подробностей, которые они могут разобраться в нюансах.
«Это позволяет людям видеть немного больше самих себя, и это:« О, эта смесь метрик немного похожа на нас. Что это говорит? » Мы действительно хороши в том, чтобы идти быстро, пока … что -то не сломается, и тогда нам нужно очень много времени, чтобы исправить это », — сказал технический директор. «Это потому, что наши системы сложны? Это говорит о нашей культуре?» Это может быть ряд разных вещей.
Повредящий и рентабельность инвестиций
Эти данные включают числа ROI. В отчете исследователи количественно определяют его через вымышленную компанию под названием «Recurship», в комплекте с 500 разработчиками, распределенными по всему миру, которые несут ответственность за три коммита в неделю, такие как обновления и оптимизация, и им платят 180 000 долл. сша, или 1,50 долл. сша на минуту разработчика.
Продолжительность — время, когда рабочий процесс запускается до тех пор, пока все шаги не будут завершены — является важным показателем. Данные в отчете указывают на то, что среднее время продолжительности составляет 2 минуты и 43 секунды, при этом 25% команд завершают свои рабочие процессы менее чем за 38 секунд. Остальные 75% завершают его за 8 минут или меньше. Самое быстрое время может быть результатом более легких рабочих процессов с меньшим количеством этапов проверки или другими факторами. Тем не менее, у некоторых команд было время продолжительности 25 минут или более.
Глядя на разживание, оптимизацию рабочего процесса и сокращении времени с 20 минутами до 10 минут, компания восстановит 750 000 минут разработчика в год, что составляет 1,50 долл. сша в минуту, приведет к 1,1 млн. Долл. сша в годовом повышении производительности.
Другим примером является пропускная способность, которая измеряет среднее количество рабочих процессов в проекте в день. В проектах, работающих на Circleci, средняя пропускная способность составляет 1,64 пробега в день, причем 25% разработчиков достигают 2,7. Среди 20 наиболее продуктивных организаций ежедневная пропускная способность достигает 3762, создавая «дельту между средним и лучшим исполнителем [that] Предлагает значительный неиспользованный потенциал в большинстве команд программного обеспечения », — говорится в отчете.
При повторном положении добавление 25 инженеров с задачей удаления трений из трубопроводов разработки в его 500 разработчиков (300 рабочих нагрузок в день или 0,6 на одного разработчика) увеличит пропускную способность до 394 ежедневных рабочих процессов, или 0,75 на разработчика в день.
Компания увидит повышение производительности на 25% на одного разработчика, основываясь на увеличении персонала на 5% и увидит повышение производительности, которые равны добавлению 156 разработчиков штата. Эти инвестиции в оптимизацию и улучшение опыта разработчиков возвращают 28,4 млн. Долл. сша в рост производительности.
ИИ принесет обещание, изменение
Потребность в скорости только увеличится по мере того, как ИИ и автоматизация станут более распространенным явлением. Инженеры и разработчики знают, как новый инструмент, используемый для построения программного обеспечения, изменит то, как они работают, создавая большую неопределенность. Учитывая это, работа для инженерных лидеров не заключается в прогнозировании будущего ИИ, а больше о создании команд, которые могут приспособиться к изменениям, когда они приходят.
«Мне нужно очень быстро адаптироваться к этому, поэтому это помогает нам подумать о том, как мы строим, как мы отправляем такие системы, которые мы строим», — сказал Зубер. «Все сейчас сталкиваются с этим.
«Гораздо интереснее подумать о том, как я бы подготовился к набору возможных результатов и готовлюсь к адаптации и адаптации, потому что это те люди, которые действительно будут называться.
Стратегии, большие и маленькие
В то же время, Circleci наметила шаги, которые компании могут предпринять сейчас, чтобы стать быстрее и эффективнее в разработке и доставке программного обеспечения. Небольшие компании должны создавать устойчивые трубопроводы, которые могут работать автономно, когда их команды работают над другими задачами, чтобы уменьшить бремя программного обеспечения отладки путем инвестирования в автоматическое тестирование.
Для компаний среднего размера эта работа заключается в том, чтобы продолжать быстрое время восстановления, стандартизировать процессы и копирование по всей организации практики, используемые высокопроизводительными командами. Авторы отчета написали, что более крупные организации должны оптимизировать управление изменениями и одобрение и баланс оптимизации скорости настройки с помощью процессов, которые масштабируются между бизнес -единицами.
(Команда) Размер имеет значение
Кроме того, все компании должны знать о размере своих команд.
«Меньшие команды, как правило, быстро движутся с меньшими координационными накладными расходами, в то время как более крупные команды должны ориентироваться в зависимости, стандартизации и сложности обрабатывания по мере масштабирования», — написали они. «Понимание этих компромиссов является ключом к оптимизации скорости развития и надежности».
Рекомендуемые стратегии включают создание команд автономных разработчиков из пяти до 10 инженеров, в то время как компании, выходящие за рамки 100 разработчиков, могут использовать стандартизированные инструменты и процессы для поддержания своего быстрого MTTR.
Компании с 50-100 инженеров, как правило, достигают пропускной способности и других барьеров, когда они масштабируются до такого размера, а затем возвращают их канавку по мере того, как они выходят за рамки этих чисел, сказал технический директор. Учитывая это, эти компании должны инвестировать в автоматизацию, чтобы помочь повысить пропускную способность и пройти мимо того, что Circleci называет «барьеры сложности», общим в таком размере.
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Джеффри Берт был журналистом более трех десятилетий, последние 20 с лишним лет охватывали технологии. В течение более 16 лет в Eweek и за годы, как в качестве независимого технического журналиста, он рассмотрел все из данных … Подробнее от Джеффри Берта
