Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Системный и бизнес-анализ доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 10
Everything as Code — подход, при котором все артефакты проекта хранятся как текстовые файлы в системе контроля версий (Git). Требования, архитектура, тесты, конфигурации, инфраструктура — всё становится кодом.
Полагаю, что в итоге может получиться "бардак as Code". Как показано в статье - "в лоб" это не сработает.
Нужна онтологическая составляющая на семантических стандартах (Linked Data), которая будет "склеивать" (семантический сахар) все эти "as Code".
По as Code
Вижу тип "Мнение" и это мнение поддерживаю.
Мы начинали с Docs as Code и чем дальше закапывались, тем больше понимали, что в ИТ все должно быть "as Code". Добавлю еще своего мнения.
Про будущее и настоящее
В конце статьи пишете:
Машины уже умеют читать спецификации, описанные по принципам Requirements as Code. Следующий шаг — они научатся их писать и использовать как промпты для AI-агентов, пишущих код. И тогда мы, возможно, станем свидетелями нового витка эволюции, где грань между требованием, кодом и тестом окончательно сотрется.
Это уже тестируют и практикуют многие команды. После появления скиллов это стало сильно проще, сама наблюдала несколько успешных кейсов.
Человекочитаемый текст (БТ, руководства) может и должен быть в MD. Тогда для нетехнических спецов, которые не работаю в клодкоде/курсоре можно делать дополнительные интерфейсы типа RAG по доке.
Автоматизации
Подход подразумевает использование стандартных и всем известных средств автоматизации. И позволяет быстро настроить что угодно: от уведомлений на почту по событиям до автоматических генераций артефактов по требованиям.
Про порог входа
Мы довольно успешно преодолели высокий порог входа с помощью визуального редактора для нетехнических спецов.
Пример флоу Everything as Code и описание редактора можно почитать тут - https://habr.com/ru/companies/gram_ax/articles/910716/
@krakenkaken Приятно, что именно вы поддерживаете мое мнение :) Я знакома с вашим продуктом Gramax. И мне кажется, что это именно тот инструмент, который может стереть барьер между нетехническими ролями и подходом «Everything as Code». Немного грустно, что самые «вкусные» функции совместной работы есть только в Enterprise версии. Хотя я, безусловно, понимаю, почему так получилось.
В части написания спецификаций требований AI-агентами я также тестировала продукт Spec Kit, и, на мой взгляд, он пока «очень сырой». Помимо обычных проблем, с которыми можно столкнуться при работе с ИИ, там есть очень опасная подмена понятий именно в части работы с требованиями.
Spec Kit предполагает, что ИИ опишет именно спецификацию, необходимую для работы AI-агента. По сути, он декомпозирует уже выявленные, проанализированные и задокументированные требования на более мелкие задачи, которые способны выполнить AI-агенты. При такой декомпозиции он может добавить что-то от себя и немного приврать. Проверка таких автоматически сгенерированных требований — это очень утомительная работа. Как по мне, проще декомпозировать требования самостоятельно.
Конечно, ИИ может и сам полностью придумать требования и сам их реализовать. Тогда получится создать продукт, который теоретически с определенной долей вероятности будет востребован пользователями. А может и не будет востребован. Это как играть в русскую рулетку.
Если исполнитель плохо понимает требования, то надо научиться писать требования выкинуть требования в мусорное ведро. А если ударило током из розетки, то заизолировать выкинуть все розетки из дому. А если в жизни что-то не так, то зумеры просто вешаются, надо уехать в Грузию, я всё верно понял?
А требования, которые лежат в GIT... стали кодом? Схрена ли, мадам? Извините меня за мой французский. Они не стали кодом, мадам. Они просто лежат в гите.
И этот прекрасный пассаж про "другие участники процесса". Которые плохо понимают требования в виде спеки на API. Вообще-то "другие участники" по-русски называется "заказчик", мэм! И да, он хреново понимает код. Поэтому требования не могут быть кодом. Вообще. Никогда.
И всё написанное можно свести к одной простой фразе: Зумерам лень учиться писать требования, поэтому они перепробовали кучу невменяемой галиматьи под названием "аджайл", и начали подозревать, что это всё не работает. Осталось полшага до того, чтобы признать, что придётся уметь писать требования. Так, чтобы их одинаково понимали все. Это такая профессия - уметь писать требования. Ей учиться надо. И да, это возможно. Только надо учиться ПИСАТЬ требования. А не класть их в гит.
Извините, что Вам прилетело. Я понимаю, что это у нас вся индустрия инфантильна до соплей, а не лично Вы.
PS: Найдите мне ОДНОГО специалиста по эджайлу, который вообще умеет управлять проектами НЕ по эджайлу. И может, вообще, сравнивать. Од-но-го. А то они все "эджайл лучше ватерфолла, только ватерфолл я не умею и вообще слышал про него только из статьи на хабре о том, как прекрасен эджайл. И там сказали, что ватерфолл это бяка."
(Ох, сейчас начнётся.)
В аджайле тоже надо уметь писать требования. Кто сказал, что не надо?
Аджайл он про быстрое получение обратной связи. Написали требования на MVP продукта или фичи, разработали, пощупали как работает, написали новые требования и так далее.
В аджайле тоже надо уметь писать требования. Кто сказал, что не надо?
Я видел такую картинку, когда постановщик задачи и программист сидят в одной комнате (точнее постановщик задач и группа программистов). Не нужно было писать требования, а лишь фиксировать (документировать) результат. Есть умное название такого сценария (только устные требования в интерактивном режиме и документирование только результата)?
Даже если бы они сидели в соседних комнатах (условно отдел тематиков и отдел программистов), то ничего не поменялось бы, если нет административных барьеров и есть немного бирюзовости.
У нас в Gramax всё очень бирюзовое и свободное, но когда не фиксируем требования, то получаем переделки. Потому что каждый человек по своему понимает информацию на встречах. Если всё записать и, в идеале, прототип приложить из ЛЛМа, то риск переделки стремится к нулю.
Потому что каждый человек по своему понимает информацию на встречах.
В моем примере - вообще "без встреч": они за соседними столами сидят в одной комнате и всегда можно переспросить, а каждая новая функция - тут же демонстрируется (даже можно до Merge).
Для меня вообще аджайле - это концепт "одной комнаты" (в крайнем случае соседних, но с всегда "открытыми дверями"): заказчик-тематик (владелец продукта, который знает каким должен быть результат) и разработчики.
«Поставщик задачи» — это или человек, работающий в предметной области, у которого есть своя работа, благодаря которой он и узнал особенности предметной области. Или аналитик, который формулирует задачи для разработчиков на основании выявления и анализа требований. Для того чтобы «поставщику задачи» делать свою работу хорошо, ему нужно оставаться в контексте, а не плясать вокруг разработчиков по первому требованию.
Еще возможны ситуации, когда «поставщик задачи» на самом деле не знает, каким должен быть результат, потому что у него недостаточно компетенций, но не признается в этом. Он может заболеть, уйти в отпуск или уволиться, не дождавшись результата. Как тогда проверить, выполнено ли задание?
Понимаю, сложно в это поверить, но не вокруг разработчиков мир вертится. Другие роли тоже работают. И иногда выяснить, каким же всё-таки должен быть результат, занимает больше времени, чем написание кода. А процесс документирования требований - это очень важная часть их анализа. Именно при документировании обычно всплывают подводные камни и логические противоречия.
Ваш концепт «одной комнаты» — это как «сферический конь в вакууме», если коротко.
Ваш концепт «одной комнаты» — это как «сферический конь в вакууме», если коротко.
Я же говорил - это реальный пример. Упрощенно, было два отдела: отдел тематиков (строчили ТЗ и концепции) и программистов. Один тематик ушел из отдела и создал новый отдел и нанял к себе троих программистов и ими "рулил": сам в программировании не понимая, но хорошо разбираясь в конечном продукте. Это для меня "икона "Аджайл", причём это было в начале 90-х.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эволюция подходов к работе со спецификациями: от бумажного ТЗ к Everything as Code