Автоматизация разработки программного обеспечения и ускорение инноваций

Традиционная разработка программного обеспечения идет медленно. Это просто для переосмысления.

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

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

Например, каждую неделю инженер-программист в среднем тратит 4 часа на ожидание завершения тестов, 3,5 часа на сборку и 3 часа на управление средой — более четверти своей рабочей недели, фактически не создавая ничего ценного. Если учесть, что инженеры часто являются самыми высокооплачиваемыми людьми в организациях, это становится большой проблемой. Однако все меняется.

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

Руководителем компании является Джим Роуз — шестикратный основатель, ранее инвестировавший в Google Ventures, Foundation Capital и Марка Андриссена. С тех пор как Роуз присоединилась к CircleCI чуть более четырех лет назад, она увеличила доход более чем на 450 % и превратила компанию в по-настоящему интересное предприятие.

Компания Information Age, заинтересованная в том, чтобы узнать больше об автоматизации разработки программного обеспечения и ускорении внедрения инноваций, поговорила с Роуз на эту тему.

Каково текущее состояние рынка программного обеспечения?

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

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

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

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

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

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

Вы считаете эту скорость основным препятствием в разработке программного обеспечения?

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

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

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

Таким образом, когда вы думаете о гибкости, речь идет о попытке стать более гибким как с точки зрения качества, так и с точки зрения скорости.

В США все зависит от скорости, но если работать быстрее, интегрировать небольшие фрагменты и иметь возможность выпускать программное обеспечение на более последовательной основе, ваше программное обеспечение становится лучше по своей сути. Все эти опасения по поводу необходимости развертывания исчезают, когда вы делаете это пять, восемь, 15 раз в неделю, а в некоторых случаях у нас есть клиенты, которые делают это по 100 раз в день.

Развертывание перестает быть проблемой.

С точки зрения качества, одна из больших проблем разработки программного обеспечения в прошлом заключалась в том, что если вы выпускаете продукт только раз в квартал, вам будет очень трудно убедиться, что все изменения, которые вы вносите в свое приложение, действительно работают вместе. Часто вы видите, как компании выпускают большой релиз, а затем, после того, как они делают релиз большого взрыва, они тратят следующие 60, 90 дней, пытаясь исправить все то, что регрессировало и ломалось. В этом методе ваш программный цикл замедляется, но страдает и качество самого приложения.

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

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

Есть несколько разных способов.

Во-первых, разработчиков трудно нанять, и поэтому вы хотите убедиться, что все время, потраченное с точки зрения разработки, посвящено созданию вашего специального программного обеспечения, чем бы оно ни было; если вы банк, создайте отличное банковское приложение, если вы приложение для электронной коммерции, создайте действительно отличное приложение для электронной коммерции. Я думаю, что одна из больших областей, в которую люди недостаточно инвестировали, заключается в том, что разработчики программного обеспечения исторически создавали вещи. Это то, что они делают, они создают программное обеспечение. Таким образом, цикл разработки был недостаточно проинвестирован с точки зрения стороннего приложения.

Есть только такие вещи, как, например, автоматизация тестирования и инфраструктура непрерывной доставки, которые командам не нужно создавать самостоятельно. Гораздо лучше приобрести его у кого-то, кто специализируется в этой области, чтобы вы могли сосредоточиться на том, в чем вы хороши. Это все равно, что сказать кому-то, что ему нужно построить кофеварку, и дать ему кучу медных труб, немного припоя и несколько клапанов. Ты бы никогда этого не сделал. Но исторически к развитию относились именно так. Поэтому очень важно установить правильные инструменты и платформы на всех этапах стека, от центра обработки данных до инструментов планирования.

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

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

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

Как искусственный интеллект и автоматизация могут стимулировать и улучшать инновации в программном обеспечении?

С помощью автоматизации вы можете автоматизировать как заранее определенные, так и самообучающиеся задачи. Примером этого может быть ситуация, когда каждый раз, когда вы пытаетесь выпустить часть программного обеспечения, вам приходится проводить сторонний тест с какой-либо другой сторонней платежной системой. В прошлом для выполнения этих задач вам приходилось нанимать группу контроля качества, которая, по сути, пыталась бы обрабатывать транзакции и делать все это вручную, что невероятно медленно. Это также невероятно чревато только ошибками и осложнениями.

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

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

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

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

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