Появление мощных LLM превращает разработку программного обеспечения в более структурированный конвейерный или водопадный процесс. Вместо того, чтобы многие разработчики итерировали короткими спринтами, конвейер с поддержкой LLM может разбить работу на стабильные фазы (требования, проектирование, реализация, тестирование), которые идут последовательно. Как отмечает один эксперт, «кодирование перешло от творческого поиска к модели производственной линии», и ИИ помогает сделать каждую фазу более предсказуемой. В этой парадигме «Waterfall 2.0» эксперты в предметной области (например, менеджеры по продуктам, дизайнеры) напрямую подключаются к потоку разработки с помощью подсказок ИИ, и отдельные шаги фиксируются, но все еще адаптируются с течением времени. Результатом является в основном линейный сквозной процесс — анализ, генерация историй, кодирование, QA — который по-прежнему включает циклы обратной связи по мере необходимости.
Например, конвейер Waterfall 2.0 может начинаться с глубоких требований и исследований, а затем передаваться LLM, который генерирует пользовательские истории и спецификации тестов. Затем система будет проходить циклы ATDD (приёмочные тесты)/BDD(поведенческие тесты)/TDD (используя синтетические данные обучения), использовать ИИ для написания основной части кода и, наконец, запускать автоматизированные тесты и шаги по исправлению. На практике ИИ может сканировать заметки со встреч для составления пользовательских историй и даже создавать фрагменты кода из простых подсказок. Хотя на бумаге это выглядит линейно, общая гибкость сохраняется: как замечает Аджит Джаокар, у нас будут «теперь фазы, которые будут более стабильными», даже если команды будут переходить между ними.
Объединение ролей Scrum с помощью ИИ
С появлением LLM традиционные роли Scrum разрушаются или меняются. Во многих командах, ориентированных на ИИ, один или два инженера (инженеры LLM) фактически выполняют все функции, используя ИИ для выполнения всего остального. Ключевые преобразования ролей включают:
Владелец продукта: вместо отдельного PO разработчик пишет (или передает) высокоуровневые требования и контекст ИИ. LLM может составлять черновики элементов бэклога и пользовательских историй на основе информации от заинтересованных сторон. ИИ также помогает расставлять приоритеты функций. Как отмечается в одном анализе, если LLM генерирует большинство пользовательских историй, работа PO в значительной степени сводится к их редактированию и упорядочиванию. На практике «агент владельца продукта» LLM может вести протоколы совещаний и превращать их в выполнимые задачи.
Scrum-мастер: церемонии и координация в значительной степени автоматизированы. Вместо человека-SM процесс контролирует разработчик или менеджер на неполный рабочий день (и помощник ИИ). LLM может планировать совещания, напоминать о сроках и даже суммировать ежедневные обновления. Например, исследователи продемонстрировали, как вводить ответы каждого члена команды в LLM, который «концентрирует информацию» и отмечает блокировщики или решения. По сути, ИИ берет на себя административные обязанности ScrumMaster. Как предупреждает один эксперт, поскольку многие задачи ScrumMaster связаны с обучением и администрированием, «по мере сокращения административных задач значительная часть роли может исчезнуть».
Разработчик (инженер): основная роль кодирования остается, но становится более интенсивной. С такими инструментами, как GitHub Copilot или IDE на базе ИИ (например, Cursor), один инженер может писать, рефакторить и отлаживать код гораздо быстрее. Эти инструменты позволяют разработчику «сосредоточиться на решении реальных проблем, а не на серфинге по StackOverflow весь день». На практике один человек может заниматься архитектурой, реализацией и даже низкоуровневым проектированием с помощью ИИ. Возникло понятие «инженер LLM»: гибридная роль, смешивающая программирование, продукт и экспертизу предметной области в одну.
QA/Tester: вместо отдельной команды QA тестирование становится в значительной степени автоматизированным. LLM могут генерировать модульные/интеграционные тесты из спецификаций и даже моделировать взаимодействие с пользователем. Например, агент тестирования ИИ (например, KaneAI от LambdaTest) может планировать, создавать и запускать тесты на основе кода и требований. Затем один инженер (или ИИ) просматривает отчеты о тестировании. Как отмечается в блоге, LLM уже «изменяют ландшафт тестирования программного обеспечения», автоматизируя рутинную генерацию тестов и выявляя сложные ошибки. (Разработчики по-прежнему просматривают критические случаи, но ИИ выполняет большую часть черновой работы по контролю качества.)
UX/дизайнер: вместо выделенного специалиста по UX разработчик может использовать инструменты проектирования ИИ. Получив текстовую подсказку («спроектировать интуитивно понятный интерфейс приложения для бронирования поездок»), такие инструменты, как плагины Uizard или Figma, могут автоматически создавать каркасы или высококачественные макеты. Помощники ИИ могут генерировать руководства по стилю, CSS или даже полный код интерфейса. Таким образом, один разработчик с помощью ИИ эффективно решает задачи UX за считанные минуты, а не за несколько дней.
Подводя итог, можно сказать, что команда, улучшенная с помощью ИИ, объединяет роли: один или два инженера LLM, поддерживаемые инструментами, выполняют работу PO, SM, Dev, QA и UX. Рабочий процесс команды переходит от рукописных карточек и ручных совещаний к процессу, управляемому подсказками, где ИИ обрабатывает большую часть деталей.
Обеспечение многоролевой разработки с помощью инструментов ИИ
Разнообразие инструментов на основе LLM делает эту консолидацию возможной:
IDE на основе ИИ (Copilot, Cursor и т. д.): они встраивают LLM в среду кодирования. Например, разработчик сообщил, что попросил Cursor AI IDE реализовать новую функцию светодиодной анимации; в течение нескольких секунд он сгенерировал весь файл кода (соответствующий стилю его фреймворка), включая параметры конфигурации и инструкции по интеграции. По сути, ИИ не только написал код, но и объяснил, как подключить его к существующей системе. Такие инструменты позволяют одному человеку писать код и тесты производственного качества за малую часть времени.
Автоматизированные агенты тестирования (KaneAI, Xray и т. д.): современные инструменты контроля качества используют LLM для автоматической генерации и выполнения тестов. Например, KaneAI от LambdaTest использует генеративный ИИ для создания тестовых сценариев из простых описаний. Реальные примеры показывают, что тестирование на основе LLM «преодолевает разрыв», обеспечивая «автоматизацию тестирования на основе ИИ». Эти системы могут создавать сотни тестовых случаев, моделировать потоки пользователей и даже исправлять ненадежные тесты с минимальным участием человека.
Планирование ИИ и фреймворки агентов: библиотеки, такие как LangChain и CrewAI, позволяют командам создавать собственных агентов для ролей Scrum. В качестве подтверждения концепции одна команда создала систему «AgileCrew» с LLM от Databricks: она определяет агента владельца продукта для определения приоритетов в бэклоге и агента мастера Scrum для проведения встреч. Эти агенты автономно выполняли такие задачи, как очистка бэклога и стендапы в последовательности. Используя такие фреймворки, даже сложные рабочие процессы проекта можно запрограммировать как задачи, управляемые LLM.
Помощники по дизайну и исследованиям: для UI/UX и документации LLM могут генерировать активы из высокоуровневых подсказок. Разработчики могут подсказать LLM набросать макет пользовательского интерфейса, предложить цветовые палитры или написать документы о потоке пользователя. Например, UX-дизайнеры обнаружили, что такие инструменты, как Uizard или UX Pilot, способны превратить краткую подсказку в многостраничный макет дизайна. Аналогично, LLM могут обобщать требования, составлять черновики документов API или создавать модели данных, эффективно действуя как исследовательская группа.
Эти инструменты позволяют одному инженеру эффективно стать многими: кодирование, тестирование, написание спецификаций и даже проектирование интерфейсов с помощью ИИ. В сочетании с контролем версий и автоматизацией CI/CD рабочий процесс с поддержкой LLM может заменить большую часть традиционного аппарата Scrum.
Переосмысление церемоний Scrum для команд ИИ
В процессе, ориентированном на ИИ, многие ритуалы Scrum упрощаются или автоматизируются:
Ежедневные стендапы: если команда состоит всего из одного или двух человек, живое стендап-совещание часто оказывается излишним. Вместо этого разработчики могут передавать обновления статуса помощнику ИИ (через чат или форму). Затем LLM объединяет все ответы в краткий отчет, выделяя прогресс и блокировщики. Это асинхронное резюме может просмотреть любой заинтересованный человек. По сути, «Scrum-мастер» ИИ автоматизирует стендап, экономя время и при этом выявляя проблемы.
Планирование спринта и обработка бэклога: планирование остается важным, но ИИ может выполнять рутинную работу. Разработчик может написать высокоуровневый бэклог в файле разметки, а затем попросить LLM разбить каждый элемент на задачи и оценить сложность. Как отмечалось выше, «агент PO» ИИ может преобразовывать требования в выполнимые тикеты. Команды все еще могут устанавливать цель для спринта, но подробный список работ может автоматически генерироваться и постоянно уточняться ИИ между совещаниями по планированию.
Обзоры/демонстрации спринта: вместо формальных церемоний обзора могут использоваться конвейеры непрерывного развертывания и демонстрационные среды. Поскольку большая часть кода генерируется ИИ, команды часто полагаются на автоматизированные демонстрации или бета-релизы. Клиенты и заинтересованные стороны могут просматривать функции по запросу в промежуточной среде. Если проводятся ручные демонстрации, они короче — команда в основном объясняет, как ИИ помог создать функцию.
Ретроспективы: традиционные ретроспективы становятся необязательными или основанными на данных. Команда ИИ может заставить LLM анализировать коммиты кода, журналы проблем и коммуникацию, чтобы выявлять узкие места или повторяющиеся проблемы. Фактически, эксперты представляют себе экстремальный сценарий «виртуального спринта»: ИИ может запустить тысячи смоделированных спринтов и изучить наилучший подход, что снижает необходимость для людей проводить ручные ретроспективы. На практике небольшие команды могут просто пропускать формальные ретроспективы или проводить краткий обзор только после основных этапов, доверяя непрерывной оптимизации ИИ руководство улучшениями.
Подводя итог, можно сказать, что многие церемонии упорядочены. Стендапы и ретроспективы могут быть в значительной степени автоматизированными или асинхронными, в то время как планирование и обзор становятся более ситуативными. Фокус смещается на непрерывную доставку: поскольку LLM занимается кодированием и тестированием, циклы обратной связи встроены в инструменты, а не в формальные встречи.
Преимущества и риски в разных контекстах
Стартапы: Экономные стартапы могут выиграть больше всего. Команда из 1-2 человек может предоставить гораздо больше программного обеспечения с помощью LLM. Более быстрый запуск функций и меньшая численность персонала означают быстрые циклы MVP с минимальным количеством персонала. Например, ИИ может писать код функций и тесты за ночь, на выполнение которых небольшой команде потребовались бы недели. Однако риски включают качество и безопасность: исследования показали, что такие инструменты, как GitHub Copilot, иногда создают небезопасный код (до 32% фрагментов, сгенерированных ИИ, имели потенциальные уязвимости). Стартапы по-прежнему должны тщательно проверять выходные данные ИИ. Чрезмерная зависимость от ИИ также может скрывать ошибки или создавать долг проектирования. В динамической среде стартапов «фиксированные фазы» Waterfall 2.0 могут снизить гибкость, если бизнес изменится. (Хорошей практикой является рассмотрение каждой функции, сгенерированной ИИ, как гипотезы для быстрой проверки с реальными пользователями.)
Корпорации: Более крупные компании могут инвестировать в частных LLM и строгое управление ИИ. Преимущества включают масштаб и согласованность: предприятия могут точно настраивать модели на основе своей кодовой базы и стандартов, интегрировать ИИ в устаревшие конвейеры и обучать персонал в качестве «инженеров LLM». Рост производительности потенциально огромен, отражая отчеты о том, что ранние последователи ИИ видят рост доходов в 1,5 раза. Однако предприятия сталкиваются с препятствиями: сложными процессами утверждения, безопасностью данных и соблюдением нормативных требований. Многие компании признают, что они все еще учатся управлять рисками генеративного ИИ. Они должны защищаться от «галлюцинаций» ИИ и гарантировать, что конфиденциальные данные не будут утекать. Необходимость аудита и человеческой проверки остается критической — например, обеспечение соответствия кода, написанного ИИ, политикам безопасности (CNCF отмечает, что у 75% организаций были инциденты из-за неправильных конфигураций, риск с конфигурациями, созданными ИИ). На практике предприятия могут пилотировать потоки Waterfall 2.0 на некритических проектах или в центрах передового опыта ИИ перед широким развертыванием.
Цифровые агентства: Креативные агентства могут использовать LLM для ускорения поставок (например, автоматическое создание прототипов интерфейса или черновиков контента). Команда из одного человека, использующая ИИ, может обслуживать клиентов быстрее. Подход «Waterfall 2.0» подходит агентствам, которые работают над четко определенными проектами. Однако агентства должны сбалансировать его с сотрудничеством с клиентами: многие клиенты ожидают итеративных проверок в стиле Agile. Агентства могут принять гибрид — использовать LLM внутри компании для быстрого создания прототипов концепции или макетов UX, а затем выполнять итерации с обратной связью от клиентов лично. Риск здесь заключается в однородности: если все агентства используют одни и те же инструменты ИИ, результаты могут начать выглядеть похожими. Оставаться креативным означает использовать ИИ в качестве помощника, а не опоры.
Распространенные риски: Во всех контекстах команды должны следить за подводными камнями. LLM могут вносить тонкие ошибки или дыры в безопасности, и они могут упустить бизнес-контекст. ИИ также влечет за собой расходы (вычисления, лицензирование) и требует постоянной оперативной разработки. Наконец, есть организационный риск: переход на Waterfall 2.0 меняет роли и культуру, что может выбить из колеи команды, привыкшие к Agile. Любая организация должна пилотировать рабочий процесс на основе ИИ в небольших масштабах, измерять воздействие и адаптировать процессы итеративно.
Руководство по внедрению и примеры
Наймите/обучите гибридные таланты: рассмотрите возможность создания команды инженеров LLM — разработчиков, которые также владеют навыками подсказок, данных и знаниями предметной области.
Используйте агентов ИИ: используйте фреймворки, такие как LangChain или CrewAI, для написания сценариев вашего процесса. Например, определите агента владельца продукта ИИ для обработки задач бэклога и агента мастера Scrum ИИ для стендап-резюме.
Интегрируйте ИИ в свою IDE: снабдите разработчиков Copilot, Cursor или аналогичными редакторами с дополнениями ИИ. Поощряйте «кодирование на основе подсказок»: напишите описание функции или строку документации, а затем попросите ИИ реализовать ее. Как обнаружил один пользователь, это может сгенерировать полный код, соответствующий фреймворку, за считанные секунды. Всегда проверяйте вывод ИИ на предмет стиля и ошибок.
Примите ИИ Test-First: продолжайте использовать разработку на основе тестов, но позвольте ИИ генерировать тесты. Для каждой новой функции предложите LLM создать модульные и интеграционные тесты. Запустите их и зациклите: если тест не пройден, отправьте ошибку обратно в LLM для рефакторинга кода. Этот «цикл LLM» (создание кода → тесты → исправление → повтор) часто может сходиться к рабочему решению без ручного кодирования.
Поддерживайте живой бэклог: сохраняйте бэклог продукта (даже как простой PLANNING.md) в формате, к которому ИИ может получить доступ. Предоставьте модели этот файл, чтобы обеспечить согласованность. Периодически просматривайте и уточняйте ее вывод. Например, каждый сеанс планирования спринта может начинаться с того, что вы просите ИИ составить список приоритетных задач из бэклога, который затем редактирует команда.
Аудит и мониторинг: используйте инструменты проверки кода и линтеры для всего кода, сгенерированного ИИ. Автоматизируйте сканирование безопасности и статический анализ. Настройте метрики для раннего выявления галлюцинаций ИИ (например, следы непоследовательных результатов тестов). Относитесь к каждому выводу ИИ как к «черновику», который дорабатывается людьми.
Учитесь у других: изучайте появляющиеся лучшие практики. Например, документация LangChain показывает, как создавать цепочечные подсказки для задач программного обеспечения, а форумы сообщества (например, сети инженеров LLM) делятся повторно используемыми подсказками для написания пользовательских историй или генерации тестов. Следите за академическими и отраслевыми исследованиями (например, документом «New Scrum Masters»), чтобы узнать больше об использовании ИИ в контекстах Agile.
По сути, Waterfall 2.0 — это не отказ от ценностей Agile, а переоснащение рабочего процесса. Он сочетает в себе предсказуемость поэтапной разработки с мощью генеративного ИИ. Продуманно консолидируя роли и автоматизируя задачи, организации — будь то разрозненные стартапы или крупные предприятия — могут добиться значительного роста производительности. Главное — делать это безопасно: постепенно интегрировать ИИ, сохранять человеческий надзор и всегда держать потребности клиента на переднем плане.
Благодарности
PS. Спасибо мои друзьям и коллегам подтолкнувшим меня к компиляции в цикл статей наших разговоров на "перекурах". И конечно же ChatGPT "помогший" оформить тезисы в текст, насытив примерами и скорректировавший форматирование.
PPS. Оригинальный текст был размещён на линкед-ин
Waterfall 2.0 серия статей включает: