Использование платформ вайб-кодинга, в которых разработчики ПО при генерации, уточнении и отладке кода используют для управления большими языковыми моделями (LLM) промпты на естественном языке, продолжает расширяться. Параллельно с этим развивается и сама вайб-технология. Хотя пока неясно, как это повлияет на будущее, вайб-кодинг уже изменил существующие методологии разработки ПО. И это влияние значительно. Это как agile на стероидах, или «гипергибкая разработка», пишет в корпоративном блоге Нил Николаизен, внештатный научный консультант в программе IDC для ИТ-руководителей.

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

Как традиционные методы разработки обходят узкое место в кодировании

Чтобы обойти это узкое место, организации делают следующее:

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

Что меняется, когда код перестаёт быть ограничивающим фактором

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

Узкое место смещается: в игру вступает теория ограничений. Что это значит? Узкое место, вокруг которого традиционно строились методологии разработки, смещается на другую часть процесса. Это прекрасный пример из теории ограничений.

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

Первые уроки применения ваб-кодинга на практике

Мой первый опыт в области вайб-кодинга показывает следующее:

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

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

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

  • Объем работ больше не должен быть жестко ограничен. Больше нет необходимости контролировать объем работ, отказываясь от некоторых идей или потребностей. Заинтересованные стороны могут представлять свои пожелания.
  • Проверка результатов заинтересованными сторонами становится новым узким местом. Если на создание версии ПО уходит на 50, 60 или 75% меньше времени, проверки заинтересованных сторон и принятие ими решений должны происходить гораздо быстрее. Вероятно, команде следует готовить версию ПО к обзору каждые день-два, а на ранних этапах проекта — даже чаще.

Заинтересованные стороны и лица, принимающие решения, часто очень заняты. Есть ли у них время встречаться раз в день или через день для обзора последней версии ПО? Возможно, нет.

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

Должна ли команда консультироваться с генеральным директором по поводу того, на каком расстоянии от края страницы должно располагаться изображение? Надеемся, что нет. Только небольшая часть решений должна требовать рассмотрения заинтересованными сторонами, чтобы команда могла быстро продвигаться вперед.

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

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

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

  • Развертывание становится узким местом только в том случае, если команды позволяют ему стать таковым. В процессе развертывания все еще может возникнуть узкое место, но только если организация еще не освоила DevOps, DevSecOps и CI/CD. ИИ может быть проинформирован о цели развертывания и выполнить большую часть работы.

Ускорение получения ценности требует изменения процессов, а не только инструментов

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

Будет досадно, если организация внедрит вайб-возможности, не перестроив при этом более широкий процесс разработки ПО.