Ускорение инноваций: автоматизация разработки ПО для конкурентного преимущества

Традиционная разработка ПО медленна. Пришло время переосмыслить её.

Почти три года назад Сатья Наделла от Microsoft сказал: «Каждый бизнес станет программным бизнесом». Сегодня глобальный рынок ПО в $500 млрд на пути к удвоению до $1 трлн к 2030 г.

J.P. Morgan заявлял о 40 000 инженеров по ПО (больше, чем у Alphabet). Каждая крупная компания гонится за инженерами, чтобы опередить конкурентов. Главная проблема: традиционная разработка медленна, фрагментирована и расточительна.

Например, средний инженер в неделю тратит: 4 часа на ожидание тестов, 3,5 часа — на сборки, 3 часа — на управление окружением — более четверти рабочей недели без создания ценности. Учитывая, что инженеры часто самые высокооплачиваемые сотрудники, это серьёзная проблема. Но всё меняется.

Ведущая платформа CircleCI поставила на ИИ и автоматизацию как ключ к ускорению инноваций и освобождению инженеров для важной работы. За год компания внедрила улучшения автоматизации и ML, сократив время ожидания инженеров на 50%. Именно поэтому более 300 000 разработчиков, включая Facebook, Spotify, GoPro, InstaCart и другие, выбрали CircleCI для ускорения.

Компанию возглавляет Джим Роуз — шестикратный основатель с инвестициями от Google Ventures, Foundation Capital, Марк Андриссен. За 4+ года он увеличил выручку более чем на 450% и превратил компанию в увлекательный объект.

Information Age поговорил с Роузом об автоматизации разработки и ускорении инноваций.

Каково текущее состояние рынка ПО?

Сейчас многие компании и люди всё ещё выполняют процессы вручную. Цифровая трансформация — это попытка создать команду разработки ПО.

Первое — вынести ПО из on-premise дата-центров в облачные нативные среды для мгновенного доступа к вычислениям.

Второе — ПО традиционно считалось лишь руководством или дополнением к основному бизнесу. Теперь банки, автопроизводители, ритейлеры понимают: ПО — ядро их деятельности. Им нужно определить, чем они владеют, консолидировать активы и интегрировать их как стандарт.

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

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

Именно сюда мы приходим, помогая компаниям ориентироваться. Команды ускоряются, создают больше ПО, пытаются делать это быстрее — чтобы быть отзывчивыми к возможностям рынка и к негативным изменениям. Бизнесу нужно полностью переосмыслить, как все эти части соединяются.

Является ли скорость главной преградой в разработке?

Компании и команды пытаются ускориться, так как рынок ускоряется. Они ищут, как работать быстро, чтобы адресовать возможности.

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

По мере ускорения команд, когда ПО — основной витрина для клиента, нужно обеспечивать высокое качество: чтобы не падало, не было уязвимостей безопасности.

Agile — это попытка стать более гибкими как с точки зрения качества, так и скорости.

В США всё про скорость, но, двигаясь быстрее, интегрируя меньшие куски и выпуская ПО чаще, оно становится лучше. Страхи деплоя исчезают, когда делаешь это 5, 8, 15 раз в неделю, а некоторые клиенты — 100 раз в день.

Деплой становится не-проблемой.

С качеством: если выпускаете раз в квартал, сложно убедиться, что все изменения работают вместе. Часто делают big bang release, а потом 60-90 дней чинят регрессии. Цикл замедляется, качество страдает.

С точки зрения agile — это то, что пытаются решить.

Как организация может измениться для поддержки команд разработки?

Есть несколько путей.

Разработчиков нанять сложно, поэтому нужно, чтобы всё их время уходило на создание вашего уникального ПО — банковского приложения, e-commerce и т.д. Одной из зон недоведения — цикл разработки: разработчики исторически строили вещи, а инфраструктуру тестирования и CI/CD им не нужно строить самим. Лучше приобрести у специалистов, чтобы фокусироваться на своём. Это как попросить построить кофемашину, дав медные трубы, припой и клапаны. Никто так не делает. Но исторически разработку так и относились. Правильные инструменты и платформы по всему стеку — критически важны.

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

Есть понятие «shift left» — сдвиг разработки всё раньше в цикл планирования, чтобы потребности команды учитывались и в конструировании, и в доставке. С операционной точки зрения — нужно думать об эксплуатации приложения гораздо раньше. Для cloud-native приложений нужна особая архитектура, решение о которой принимается рано.

При переходе на software-first, agile процессы возникает триангуляция интересов: владельцы бизнеса/продукт-менеджеры (зачем строить), технические архитекторы/разработчики (как строить), операторы (что запускать в конце). Все должны быть вовлечены. Это сложный переход для некоторых компаний.

Как ИИ и автоматизация стимулируют и улучшают инновации в ПО?

Автоматизация позволяет автоматизировать как заранее определённые, так и самообучающиеся задачи. Пример: каждый релиз требует стороннего теста против платёжной системы. Раньше нанимали QA-команду для ручной обработки транзакций — невероятно медленно и ошибочно.

Это идеальные задачи для полной автоматизации в тестовом наборе — всё, что повторяется снова и снова, должно быть автоматизировано для детерминизма, предсказуемости и скорости.

Есть возможности убрать повторяющиеся задачи, на которые тратится время разработчиков — пустая трата времени и денег.

Когда смотришь на ИИ и создаваемое ПО, вместо предсказательного детерминированного ПО вы запускаете модель. Модель — песочница предварительных представлений о том, как что-то может работать, и по мере прохождения тестов она меняется и эволюционирует, учась, что работает, а что нет. Это создаёт невероятное давление на систему тестирования.

Когда думаешь о промахах ИИ — бессознательная предвзятость, ИИ выходит из-под контроля, блокирует доступ, отключает системы — всё это с точки зрения тестирования сложные вызовы.

Становится сложнее, но и намного быстрее и отзывчивее. Включение ИИ и ML в разработку ПО будет только расти. Но теперь нужны все необходимые фреймворки для тестирования всех этих изменений.