DevOps и Agile сталкиваются с организационными проблемами — автоматизации и идентификации соответственно. Обе методологии необходимы для цифровой трансформации, которая определит будущий экономический ландшафт. Поэтому обе проблемы требуют скорейшего решения, считают опрошенные порталом ZDNet эксперты.

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

Проблема DevOps заключается в том, что в ней по-прежнему слишком много ручных процессов. «Полная автоматизация обычно отсутствует, — говорит Эрик Ньюкамер, технический директор WSO2. — Конвейер CI/CD позволяет полностью автоматизировать процесс создания и развертывания приложений. Но поскольку многие организации разделяют функции создания и развертывания, процесс сборки часто автоматизируется, а развертывание — нет».

Автоматизация является ключевым фактором, соглашается Киф Моррис, главный облачный технолог CharchWorks: «Мы рассматриваем инструменты Low-code со встроенной поддержкой ИИ как реальный инструмент изменения правил игры на поле облачных вычислений. Безопасное управление API является другим очень важным инструментом, помогающим получить преимущества от распространения моделей разработки на основе микросервисов и гарантировать, что они обеспечивают согласованную ценность для бизнеса, а не порождают хаос».

Более медленный, чем ожидалось, темп автоматизации связан с тем, что «организации запрещают разработчикам доступ к производственным средам, вероятно из-за того, что разработчики ранее вносили в них изменения, которые вызывали производственные проблемы, — полагает Ньюкамер. — Трудно изменить такую политику, особенно если имели место такие инциденты. Другая причина — простая институциональная инерция: процессы и процедуры, которые полностью встроены в повседневную практику, трудно изменить, особенно если ручное развертывание — это чья-то конкретная работа».

Прогресс DevOps и Agile должен быть хорошо измерен и задокументирован. «У людей разные определения DevOps и Agile, — говорит Лэй Чжан, глава группы Developer Experience в Bloomberg. Его команда решила воспользоваться метриками из руководства Google DevOps Research and Assessment — время подготовки, частота развертывания, время восстановления и изменение процента отказа, — сфокусировавшись на их комбинации. «Мы считаем такой подход оправданным несмотря на большой разброс результатов. В основном он связан со сложными зависимостями, определяемыми характером бизнеса, устаревшими, но важными программными артефактами, нормативными требованиями и низкоуровневыми инфраструктурными ограничениями», — отметил он.

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

В нынешнем году мы увидим больше усилий, чтобы стать более гибкими. Гибкость, которая свидетельствует о расширении исключительно важного делового сотрудничества по мере развития цифровых технологий, сдерживается непониманием и недопониманием. В то время как Ньюкамер видит много примеров успешного внедрения Agile, на практике все еще слишком много случаев антитеза Agile, каскадного подхода, который при этом маркируется как «agile». По его словам, есть много компаний, которые «говорят, что работают гибко, но часто это модифицированный „водопад“. Я думаю, что так и есть на самом деле, особенно когда команда разработчиков сосредоточена на поддержке унаследованного приложения. Командам, у которых есть возможность начать с нуля с новыми технологиями и новыми практиками разработки, намного легче получить преимущества Agile».

DevOps также страдает от проблемы идентичности. «Так же, как и в случае с Agile, DevOps означает разные вещи для разных людей, поэтому они делают разные вещи и называют это DevOps, — говорит Моррис. — Люди часто фокусируются на инструментах и поверхностных формах, а не на принципах и результатах. Вы можете увидеть команды DevOps, которые запускают серверы Jenkins и, возможно, применяют Ansible, но вы не всегда увидите разработчиков, вовлеченных в операционные аспекты кода, который они пишут, и вы не часто увидите, как исполнители разных ролей, включая тестирование и управление, эффективно сотрудничают во встраивании в ПО правильных вещей».

Существует даже тенденция просто попытаться провести ребрендинг существующего процесса как «DevOps,» не изменяя его основы. «Меня удивляет, когда на встречах с руководителями в других организациях я узнаю, что их члены команды DevOps в действительности являются просто переименованными операционными специалистами, — говорит Дэвид Торгерсон, старший директор по инжинирингу Lucid Software. — DevOps часто реализуется путем встраивания членов ops-команд в инженерные команды в надежде на увеличение скорости работы, создание товарищества и устранение конфронтации между командами. К сожалению, эта стратегия плохо масштабируется и часто может усугубить проблемы недопонимания, поскольку члены операционной команды начинают чувствовать себя изолированными».

По его словам, DevOps — это нечто большее, чем встраивание операционных специалистов в команды разработчиков. «Их основное внимание сосредоточено на обслуживании производственной системы, а не на улучшении жизненного цикла разработки ПО, непрерывной доставке и высококачественном выпуске. Способ взаимодействия традиционных ops- и dev-команд меняется, если сфокусироваться на этих целях, и именно тогда появляется истинная ценность DevOps».

В то же время Agile часто не приживается, не встраивается в корпоративную культуру. «Я вижу своего рода тревожный тренд рассматривать Agile больше как изменение практики управления программами и проектами, а не как изменение практики разработки», — говорит Ньюкамер.

«Здоровая и гибкая команда по бизнес-технологиям выходит за рамки ИТ-группы, — соглашается технический директор Bonitasoft Николя Шабанолес. — Нужна бизнес-направленность. Гибкие технологические инициативы становятся таковыми, особенно по мере того, как руководители процессов все глубже погружаются в автоматизацию, поэтому цифровые технологии автоматизации процессов, которые могут использоваться для тесного сотрудничества внутри организации, положительно влияют на гибкие проекты. Например, технологии автоматизации должны включать широкие возможности визуального программирования, позволяющие гражданским разработчикам создавать пользовательские интерфейсы, определять бизнес-правила и условия, а также возможности кодирования для разработчиков, такие как SDK, шаблоны, архетипы и точки расширения».

Такое полномасштабное участие бизнеса имеет решающее значение, особенно с точки зрения привлечения людей из начальственных кабинетов. «Большинству Agile-инициатив не хватает поддержки руководства, прозрачного и последовательного, — говорит Брайан Сталлингс, главный евангелист Lucid. — Большинству гибких инициатив не достает возможности количественно сопоставить влияние инициативы с расходами на нее. По мере того, как внимание руководства смещается в другие места, программа начинает выглядеть как куча расходов без количественной отдачи. Давление со стороны бизнеса усиливается, и зачастую те, кто участвуют в обеспечении изменений, устраняются или возвращаются к обычному ведению бизнеса». По его словам, в идеальных ситуациях топ-менеджеры — особенно генеральный директор — должны сообщать о своей приверженности Agile-усилиям и брать на себя личную ответственность.