Эволюция подходов к работе со спецификациями: от бумажного ТЗ к Everything as Code

[itGuevara]

Everything as Code — подход, при котором все артефакты проекта хранятся как текстовые файлы в системе контроля версий (Git). Требования, архитектура, тесты, конфигурации, инфраструктура — всё становится кодом.

Полагаю, что в итоге может получиться "бардак as Code". Как  показано в статье - "в лоб" это не сработает.

Нужна онтологическая составляющая на семантических стандартах (Linked Data), которая будет "склеивать" (семантический сахар) все эти "as Code".

По as Code 

[krakenkaken]

Вижу тип "Мнение" и это мнение поддерживаю.

Мы начинали с Docs as Code и чем дальше закапывались, тем больше понимали, что в ИТ все должно быть "as Code". Добавлю еще своего мнения.

Про будущее и настоящее

В конце статьи пишете:

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

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

Человекочитаемый текст (БТ, руководства) может и должен быть в MD. Тогда для нетехнических спецов, которые не работаю в клодкоде/курсоре можно делать дополнительные интерфейсы типа RAG по доке.

Автоматизации

Подход подразумевает использование стандартных и всем известных средств автоматизации. И позволяет быстро настроить что угодно: от уведомлений на почту по событиям до автоматических генераций артефактов по требованиям.

Про порог входа

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

Пример флоу Everything as Code и описание редактора можно почитать тут - https://habr.com/ru/companies/gram_ax/articles/910716/

[NastenaA]

@krakenkaken Приятно, что именно вы поддерживаете мое мнение :) Я знакома с вашим продуктом Gramax. И мне кажется, что это именно тот инструмент, который может стереть барьер между нетехническими ролями и подходом «Everything as Code». Немного грустно, что самые «вкусные» функции совместной работы есть только в Enterprise версии. Хотя я, безусловно, понимаю, почему так получилось.

В части написания спецификаций требований AI-агентами я также тестировала продукт Spec Kit, и, на мой взгляд, он пока «очень сырой». Помимо обычных проблем, с которыми можно столкнуться при работе с ИИ, там есть очень опасная подмена понятий именно в части работы с требованиями.

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

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

[dzavalishin]

Если исполнитель плохо понимает требования, то надо научиться писать требования выкинуть требования в мусорное ведро. А если ударило током из розетки, то заизолировать выкинуть все розетки из дому. А если в жизни что-то не так, то зумеры просто вешаются, надо уехать в Грузию, я всё верно понял?

А требования, которые лежат в GIT... стали кодом? Схрена ли, мадам? Извините меня за мой французский. Они не стали кодом, мадам. Они просто лежат в гите.

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

И всё написанное можно свести к одной простой фразе: Зумерам лень учиться писать требования, поэтому они перепробовали кучу невменяемой галиматьи под названием "аджайл", и начали подозревать, что это всё не работает. Осталось полшага до того, чтобы признать, что придётся уметь писать требования. Так, чтобы их одинаково понимали все. Это такая профессия - уметь писать требования. Ей учиться надо. И да, это возможно. Только надо учиться ПИСАТЬ требования. А не класть их в гит.

Извините, что Вам прилетело. Я понимаю, что это у нас вся индустрия инфантильна до соплей, а не лично Вы.

PS: Найдите мне ОДНОГО специалиста по эджайлу, который вообще умеет управлять проектами НЕ по эджайлу. И может, вообще, сравнивать. Од-но-го. А то они все "эджайл лучше ватерфолла, только ватерфолл я не умею и вообще слышал про него только из статьи на хабре о том, как прекрасен эджайл. И там сказали, что ватерфолл это бяка."

(Ох, сейчас начнётся.)