AI убивает Agile

AI убивает Agile. Звучит провокационно, но, кажется, это буквально происходит прямо сейчас

Больший сдвиг, который происходит с внедрением AI в разработку, произойдет и в области методологий ведения проектов. Многие компании внедрили гибкие методологии, но AI меняет разные правила, и в том числе он влияет на оргпроцессы внутри разработки.

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

Есть интересная статья с критикой Agile «Agile Is Dead. AI Killed It. Welcome Back, Waterfall.»

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

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

Kent Beck (один из авторов Agile-манифеста) предполагает, что внедрение AI может столкнуться в организациях с противодействием, потому что не всегда люди заинтересованы в ускорении и удешевлении процессов. Это из разговора Kent Beck и Martin Fowler на Pragmatic Summit. Там же Kent Beck говорит о том, что возвращается тенденция к программистам-интровертам, которые не любят и не хотят частого общения, что было нормой до недавнего времени. Сейчас можно сфокусироваться на нескольких коллегах и нескольких агентах, а задачей компании становится создание безопасной позитивной атмосферы для функционирования таких производственных единиц.

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

При этом, если описывать задачи в формате User Stories или JTBD, то будешь получать от AI простые решения. Надо уходить в детальное описание того, что требуется получить.

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

1. Функциональные требования — 1–2 предложения, которые формируют бэклог проекта.

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

3. Доработанные функциональные требования — 2–3–4 страницы. Вариант требований, который первоначально готовит AI на основе моего описания, который я потом дорабатываю с учетом нужного фокуса. Именно эти функциональные требования идут в AI для кодирования проекта.

Причем AI погружен в контекст проекта сквозным образом: начиная от архитектуры, заканчивая деталями интерфейса. Больше нет необходимости в традиционной декомпозиции проекта на небольшие фрагменты, которые можно вместить в спринт, типа «в этом спринте мы сделаем кнопку». Сейчас можно делать все связанное с требованием в один проход, но для этого нужно иметь структурированное описание системы, к которому мы можем каждый раз обращаться.

Нужна документация по системе, которая бы описывала все от общего к частному. Нужно понимание, в каком направлении движется создание проекта. По большому счету, мы возвращаемся к парадигме waterfall, когда к моменту кодирования у нас должно быть объемное видение проекта.

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