Комментарии 10
Статьи про SDD живут в парадигме задач. А как вы управляете знаниями и переводите знания в задачи?
Привет! Постараюсь ответить:
Стараемся идти в сторону подключения контекста (кода, бизнес-процессов, телеметрии, словарей), и формирование машиночитаемого связанного контекста.
А как вы управляете знаниями и переводите знания в задачи?
Знания текущие при необходимых изменениях (получение нового контекста), с помощью скилов (которые умеют ingest-ить информацию и выдавать ее в нужном формате). Опять же это вектор, а не рецепт.
Ситуация: команда нашла подробную документацию API для compliance. За спринт собрала удобный адаптер с помощью кодинг-агентов - хоба, и им уже заинтересовались коллеги!А в следующем спринте выяснилось, что API — внутренний инструмент с доступом к сырым данным. Другим командам пользоваться им нельзя. Сервис и два спринта разработки пришлось списать.
Я вижу как раз agile подход, взяли задачу сделали, а потом решили подумать. Между тем Waterfall, даже молниеносный и с помощью агентов предполагает соблюдение стадий: обследование (сбор требований), проектирование, реализацию и т.д. На каждой стадии результат должен верифицироваться, иначе как вы закрываете стадию?
Вряд ли мы узнаем это из слопа компании
Мы с вами уже поспорили в Agile Ufa :) Проблема Waterfall-a, что он не приемлет изменения контракта и возврата назад и не дает параллельности выполнения этапов.
Обследование (сбор требований) не должен идти строго перед проектированием, а проектирование не значит что мы его потом не меняем. В рамках реализации нового функционала этапы в Agile (в отличие от классического Waterfall) могут идти параллельно, четкой последовательности нет. Мы часто в ходе реализации можем понять что фича должна в целом быть спроектирована иначе (потому что на рынке произошло изменение), в отличии от водопада мы можем вносить изменения и менять подходы.
Ну это ваш выдуманный waterfall, однако в данном случае и его нет.
Собственно при использовании агентов как раз лучше, использовать agile: что-то сделали, протестировали, затем либо в прод, либо откатили. Ведь стоимость кода снизилась, значит надо снижать и стоимость определения требований и проектирования, а в этом месте всегда ускорялись ща счёт прототипирования и экспериментальной разработки.
Прошу прощения за лонгрид, можете попросить агента выжать суть из моего коммента)) Смотрите, вы защищаете сферический Waterfall в вакууме по PMBOK или ГОСТу, где гейты между этапами идеально фильтруют риски. Но мы ж с вами говорим о реальной практике, а не об экзамене по методологиям. Здесь и далее - водопад=каскад.
Почему я привожу (немного кликбейтный заголовок + приплетаю паттерн Watefall'a)? Потому что waterfall — это линейная реализация непроверенных (подчеркиваю) допущений. Мы в продуктовой разработке работаем над реализацией гипотез.
В каскадной модели главная проблема (на мой взгляд) всегда была не в наличии регламентированных изолированных стадий с фиксированными артефактами на входе и выходе, а в вере, что требования на бумаге самодостаточны.
У нас такой же кейс: команда взяла спеку как абсолютную истину, спроектировала решение, агент линейно сгенерировал под него кодовую базу с тестами -> а столкновение с реальностью произошло только в самом конце цепочки. Это классический Big Design Up Front, просто в ускоренной версии. Причем это был единичный случай, как один из примеров того как AI нас возвращает к тому, от чего мы уходили годами.
Именно это я привожу как антипод Agile. Базовый принцип Agile это у нас ранняя обратной связи и маленькие батчи. По-хорошему, подход здесь требовал не писать адаптер целиком, а сделать spike (исследовательскую задачку): запросить боевой доступ к эндпоинту в первый же день и закрыть главный интеграционный риск до написания прод-кода.
Решил бы проблему канонический Waterfall по своей методологии? Это опять же моё имхо, спорить я с вами больше не собираюсь :)
В теории - да (мы можем аппелировать что "не подписали согласование на стадии анализа").
В реальности энтерпрайза - нет (на моей памяти и опыте это точно не так работает). На фазе обследования аналитик взял бы ту же открытую документацию, оформил бы ТЗ, архитекторы и ИБ согласовали бы интеграцию по верхам. Проблема «сырых данных» вылезла бы ровно так же, но на этапе интеграций уже ближе к проду или на проде - позже по календарю. Ну и изолированность этапов у каскадной модели ощутимо бы удлиннила разработку, потому что кроме проблемы с данными, у нас было бы много комментов от заказчиков на изменения. Каскад тут бы записывал все изменения - проектировал бы их - планировал бы их - реализовывал и показывал заново. А в гибких подходах мы с вами бы сели с заказчиком и в моменте проработали бы реализацию, совместно, усаживая команду / безопасников / compliance вместе за один стол, параллеля этапы.
Поэтому моя метафора - удешевление кодогенерации возвращает людей в ментальную ловушку каскадной модели: если у тебя есть детальная спека (одобренная на выходе из фазы анализа) и тесты зеленые, то задачу можно считать решенной - ибо ща он все забабахает и будет красота. Это не так.
Так про сферический Waterfall начали вы. По ГОСТу, да и по PMBOK, каскад (водопад) это линейная интерпретация принятых и проверенных допущений. Пока не проверим - не примем. В этом и слабость, на выходе то, что надо, но выход получаем когда-то в будущем, а результат нужен сейчас (фактор времени, а не качества).
Если переводить каскад на агентов, то будет примерно так:
Базовый запрос (на входе человек),
Проверка базового запроса (может быть возврат),
Формирование функциональных требований
Обследование текущих артефактов (процессов, документов, кода).
Уточнение полноты артефактов (может быть возврат)
Формирование технического задания (спецификации).
Проверка спецификации (может быть возврат)
Проектирование решений:
- Прототипирование отдельных решений
- Проверка отдельных решений (может быть возврат)
- Сборка проектных решений
- Проверка сборки решений (может быть возврат)
Реализация запроектированного:
- написание кода
- написание тестов
- проверка кода (может быть возврат)
Поставка реализованного (там еще дальше могут быть разворачивание, тестовая эксплуатация, нагрузочные тестирования и т.п.) и тут на выходе может быть человек.
В целом постарался указать только ту работу, которую поручить можно агентам, в промежуточных стадиях люди тоже буду проверять и согласовывать.
В вашем же случае вы сделали:
1) Запрос (на входе человек)
2) Реализация
3) Тестирование
4) Поставка (на выходе оказался человек)
Проверок не было. Наличие спецификации в запросе не делает этот подход водопадом. В чем отличие от гибкого подхода? Ни в чем. Сделали быстро, быстро получили обратную связь. Просто из-за уменьшения сроков реализации и тестирования у вас задачи, которые раньше разбивались на несколько итераций теперь делаются за одну.
Что делать с этим ускорением:
1) Возможно сократить итерации, если ускорили разработку, значит надо от 2-х недель идти к дням. Чаще коммуницировать с соседями и вот это всё.
2) Оставить как есть, shit happens, раньше тоже некоторые спринты не давали прироста ценности и работу выкидывали, что изменилось? Цена двух недель ведь не выросла, значит и дальше можно выкидывать двухнедельную работу.
SDD для AI-агентов: как мы заново изобрели очень быстрый waterfall