Хорошо, уговорилию. Согласен с узким замечанием: само наличие спеки и последовательности написали > протестили > получили обратную связь не позволяет классифицировать процесс как Waterfall.
Прошу прощения за лонгрид, можете попросить агента выжать суть из моего коммента)) Смотрите, вы защищаете сферический Waterfall в вакууме по PMBOK или ГОСТу, где гейты между этапами идеально фильтруют риски. Но мы ж с вами говорим о реальной практике, а не об экзамене по методологиям. Здесь и далее - водопад=каскад.
Почему я привожу (немного кликбейтный заголовок + приплетаю паттерн Watefall'a)? Потому что waterfall — это линейная реализация непроверенных (подчеркиваю) допущений. Мы в продуктовой разработке работаем над реализацией гипотез.
В каскадной модели главная проблема (на мой взгляд) всегда была не в наличии регламентированных изолированных стадий с фиксированными артефактами на входе и выходе, а в вере, что требования на бумаге самодостаточны.
У нас такой же кейс: команда взяла спеку как абсолютную истину, спроектировала решение, агент линейно сгенерировал под него кодовую базу с тестами -> а столкновение с реальностью произошло только в самом конце цепочки. Это классический Big Design Up Front, просто в ускоренной версии. Причем это был единичный случай, как один из примеров того как AI нас возвращает к тому, от чего мы уходили годами.
Именно это я привожу как антипод Agile. Базовый принцип Agile это у нас ранняя обратной связи и маленькие батчи. По-хорошему, подход здесь требовал не писать адаптер целиком, а сделать spike (исследовательскую задачку): запросить боевой доступ к эндпоинту в первый же день и закрыть главный интеграционный риск до написания прод-кода.
Решил бы проблему канонический Waterfall по своей методологии? Это опять же моё имхо, спорить я с вами больше не собираюсь :)
В теории - да (мы можем аппелировать что "не подписали согласование на стадии анализа").
В реальности энтерпрайза - нет (на моей памяти и опыте это точно не так работает). На фазе обследования аналитик взял бы ту же открытую документацию, оформил бы ТЗ, архитекторы и ИБ согласовали бы интеграцию по верхам. Проблема «сырых данных» вылезла бы ровно так же, но на этапе интеграций уже ближе к проду или на проде - позже по календарю. Ну и изолированность этапов у каскадной модели ощутимо бы удлиннила разработку, потому что кроме проблемы с данными, у нас было бы много комментов от заказчиков на изменения. Каскад тут бы записывал все изменения - проектировал бы их - планировал бы их - реализовывал и показывал заново. А в гибких подходах мы с вами бы сели с заказчиком и в моменте проработали бы реализацию, совместно, усаживая команду / безопасников / compliance вместе за один стол, параллеля этапы.
Поэтому моя метафора - удешевление кодогенерации возвращает людей в ментальную ловушку каскадной модели: если у тебя есть детальная спека (одобренная на выходе из фазы анализа) и тесты зеленые, то задачу можно считать решенной - ибо ща он все забабахает и будет красота. Это не так.
Мы с вами уже поспорили в Agile Ufa :) Проблема Waterfall-a, что он не приемлет изменения контракта и возврата назад и не дает параллельности выполнения этапов.
Обследование (сбор требований) не должен идти строго перед проектированием, а проектирование не значит что мы его потом не меняем. В рамках реализации нового функционала этапы в Agile (в отличие от классического Waterfall) могут идти параллельно, четкой последовательности нет. Мы часто в ходе реализации можем понять что фича должна в целом быть спроектирована иначе (потому что на рынке произошло изменение), в отличии от водопада мы можем вносить изменения и менять подходы.
Стараемся идти в сторону подключения контекста (кода, бизнес-процессов, телеметрии, словарей), и формирование машиночитаемого связанного контекста.
А как вы управляете знаниями и переводите знания в задачи?
Знания текущие при необходимых изменениях (получение нового контекста), с помощью скилов (которые умеют ingest-ить информацию и выдавать ее в нужном формате). Опять же это вектор, а не рецепт.
Оч крутой кейс! В итоге по таймлайну все успелось?
И как команда реагировала на то, что дедлайн есть, а тут еще и AI надо учить. Многие сталкиваются с тем что это новый инструмент на который надо еще время.
Согласен. Команды постоянно меняются, технологии меняются, измерять что-то в целом очень сложно :) Я возьму на вооружение идею - а стали ли мы делать больше сложных задач)
Так вопрос-то у этих людей: гоняли ли они на конкретных бенчах своих агентов и навыки? У каждой организации/стартапа/человека есть свои стандарты и контекст. Поэтому бенчмарки и эвалы должны соответствовать тому, как вы собираетесь решать задачу. Если вы просто берете и пишете "generic" запрос клоду и ожидаете результата, который вас удовлетворит, у меня для вас плохие новости =)
Решать тому кто принимает решение о внедрении ИИ в организации - так как внедрение, это в том числе про удобство и результат. Мы ж делаем все для какого-то результата. Если вы фрилансер - то сами и решаете - ваша же инвестиция :)
Вопрос провокационный. Мы не моё использование обсуждаем, а ваш скептицизм (на который вы имеете право, я его не оспариваю). Мой стек - это в основном java, где у людей есть возможность попробовать перевесить на агентов написание бойлерплейта и кусков логики в контролируемом окружении, которое они сами допиливают (добровольно). Думалку никто у нас и вас не отбирает)
А вот с точки зрения пересборки: просто организация часто хочет чтобы было быстрее.
А быстрее без пересборки процессов не получится, потому что надо уменьшить цепочку передачи артефактов.
А если результат от работы агентов получается некачественный, вы, безусловно, останетесь 1-1 с нейрослопом, который нельзя проверить адекватно. Мы даже знаем статы от того же coderabbit: багов в PR от ИИ в 1.7 раз больше, а люди кликают в два раза чаще "аппрув не глядя", когда видят огромный PR от ИИ-шки.
И все это надо решить, перед тем как пересобирать процесс. Вот только кто ответственен за решения этих проблем? В одном случае команда сама может туда контрибьютить (у меня таких много): делает обвязку, эвалы, улучшает повторяемость результатов на разных моделях. В других командах - ждут централизованного решения, потому что им не до этого. В данном случае каждая организация/отдел/команда должны иметь явный ответ на вопрос - кто доводит до нормального состояния ИИ-тулы.
Если вы не хотите разбираться - это ваше право, мне кажется базовое. Тут вопрос - если агенты плодят нейрослоп, может быть вам дают плохой инструмент? Плохих агентов? Хреновую обвязку? А кто за это ответственен (за DevExperience, который в вашем случае плохой).
Глобально, вы бы, наверное, не были бы против удобного инструмента, избавляющего от рутины?
Так и статья про то что не надо оголтело и без цели внедрять ИИ. И ничего вы не внедрите, еслрине будете работать с людьми и если они не будут выкупать - зачем это и какой бенефит будет.
А если сопротивляются - это проблема в системе, а не людях.
Ковыряться в нейрослопе вы больше полугода не сможете, надо пересобрать весь процесс работы - причем самой команде - и чтобы она в этом была сама заинтересованна.
Не меняются потому что надо перестраивать весь процесс поставки, а не просто давать людям инструмент. Иначе точечное , в не системное использование инструментов не ускоряет end 2 end процесс
Так для этого (мы видим по опыту китая) надо вкладывать дохулиардные инвестиции много лет подряд, чего сейчас в текущих условиях не делается (денег выделено на импортзам и передовые железки с гулькин нос). А с учетом дефицита бюджета и подавно не будет.
То есть прямо сейчас надо будет усиленно переориентировать инвестиции в НИОКР, чего не предвидится.
Мы смотрели шире, на качество коммуникации тоже. Support / CSM / Sales могут пороть ерунду, могут преувеличивать проблемы. Там, по-хорошему, надо еще и в то как они свою работу делают погружаться и мониторить. Но это совсем другая история (там моделька - тогда еще ранний gemini - ходила по заметкам общения с клиентами в google meet / gong / salesforce и очень базово репортила если были паттерны общения, которые мы не поощряем). Это было на заре начала chatGPT и всяких суммаризаторов google meet (в end 2022- mid 2023)
Хорошо, уговорилию. Согласен с узким замечанием: само наличие спеки и последовательности написали > протестили > получили обратную связь не позволяет классифицировать процесс как Waterfall.
Прошу прощения за лонгрид, можете попросить агента выжать суть из моего коммента)) Смотрите, вы защищаете сферический Waterfall в вакууме по PMBOK или ГОСТу, где гейты между этапами идеально фильтруют риски. Но мы ж с вами говорим о реальной практике, а не об экзамене по методологиям. Здесь и далее - водопад=каскад.
Почему я привожу (немного кликбейтный заголовок + приплетаю паттерн Watefall'a)? Потому что waterfall — это линейная реализация непроверенных (подчеркиваю) допущений. Мы в продуктовой разработке работаем над реализацией гипотез.
В каскадной модели главная проблема (на мой взгляд) всегда была не в наличии регламентированных изолированных стадий с фиксированными артефактами на входе и выходе, а в вере, что требования на бумаге самодостаточны.
У нас такой же кейс: команда взяла спеку как абсолютную истину, спроектировала решение, агент линейно сгенерировал под него кодовую базу с тестами -> а столкновение с реальностью произошло только в самом конце цепочки. Это классический Big Design Up Front, просто в ускоренной версии. Причем это был единичный случай, как один из примеров того как AI нас возвращает к тому, от чего мы уходили годами.
Именно это я привожу как антипод Agile. Базовый принцип Agile это у нас ранняя обратной связи и маленькие батчи. По-хорошему, подход здесь требовал не писать адаптер целиком, а сделать spike (исследовательскую задачку): запросить боевой доступ к эндпоинту в первый же день и закрыть главный интеграционный риск до написания прод-кода.
Решил бы проблему канонический Waterfall по своей методологии? Это опять же моё имхо, спорить я с вами больше не собираюсь :)
В теории - да (мы можем аппелировать что "не подписали согласование на стадии анализа").
В реальности энтерпрайза - нет (на моей памяти и опыте это точно не так работает). На фазе обследования аналитик взял бы ту же открытую документацию, оформил бы ТЗ, архитекторы и ИБ согласовали бы интеграцию по верхам. Проблема «сырых данных» вылезла бы ровно так же, но на этапе интеграций уже ближе к проду или на проде - позже по календарю. Ну и изолированность этапов у каскадной модели ощутимо бы удлиннила разработку, потому что кроме проблемы с данными, у нас было бы много комментов от заказчиков на изменения. Каскад тут бы записывал все изменения - проектировал бы их - планировал бы их - реализовывал и показывал заново. А в гибких подходах мы с вами бы сели с заказчиком и в моменте проработали бы реализацию, совместно, усаживая команду / безопасников / compliance вместе за один стол, параллеля этапы.
Поэтому моя метафора - удешевление кодогенерации возвращает людей в ментальную ловушку каскадной модели: если у тебя есть детальная спека (одобренная на выходе из фазы анализа) и тесты зеленые, то задачу можно считать решенной - ибо ща он все забабахает и будет красота. Это не так.
Мы с вами уже поспорили в Agile Ufa :) Проблема Waterfall-a, что он не приемлет изменения контракта и возврата назад и не дает параллельности выполнения этапов.
Обследование (сбор требований) не должен идти строго перед проектированием, а проектирование не значит что мы его потом не меняем. В рамках реализации нового функционала этапы в Agile (в отличие от классического Waterfall) могут идти параллельно, четкой последовательности нет. Мы часто в ходе реализации можем понять что фича должна в целом быть спроектирована иначе (потому что на рынке произошло изменение), в отличии от водопада мы можем вносить изменения и менять подходы.
Привет! Постараюсь ответить:
Стараемся идти в сторону подключения контекста (кода, бизнес-процессов, телеметрии, словарей), и формирование машиночитаемого связанного контекста.
А как вы управляете знаниями и переводите знания в задачи?
Знания текущие при необходимых изменениях (получение нового контекста), с помощью скилов (которые умеют ingest-ить информацию и выдавать ее в нужном формате). Опять же это вектор, а не рецепт.
ну да, и мы идем в итоге смотреть на "обвес" вокруг агента и бесконечную отладку + evals :)
Оч крутой кейс! В итоге по таймлайну все успелось?
И как команда реагировала на то, что дедлайн есть, а тут еще и AI надо учить. Многие сталкиваются с тем что это новый инструмент на который надо еще время.
Согласен. Команды постоянно меняются, технологии меняются, измерять что-то в целом очень сложно :) Я возьму на вооружение идею - а стали ли мы делать больше сложных задач)
Огонь)
Аминь!
Так вопрос-то у этих людей: гоняли ли они на конкретных бенчах своих агентов и навыки? У каждой организации/стартапа/человека есть свои стандарты и контекст. Поэтому бенчмарки и эвалы должны соответствовать тому, как вы собираетесь решать задачу. Если вы просто берете и пишете "generic" запрос клоду и ожидаете результата, который вас удовлетворит, у меня для вас плохие новости =)
Решать тому кто принимает решение о внедрении ИИ в организации - так как внедрение, это в том числе про удобство и результат. Мы ж делаем все для какого-то результата. Если вы фрилансер - то сами и решаете - ваша же инвестиция :)
Вопрос провокационный. Мы не моё использование обсуждаем, а ваш скептицизм (на который вы имеете право, я его не оспариваю). Мой стек - это в основном java, где у людей есть возможность попробовать перевесить на агентов написание бойлерплейта и кусков логики в контролируемом окружении, которое они сами допиливают (добровольно). Думалку никто у нас и вас не отбирает)
А вот с точки зрения пересборки: просто организация часто хочет чтобы было быстрее.
А быстрее без пересборки процессов не получится, потому что надо уменьшить цепочку передачи артефактов.
А если результат от работы агентов получается некачественный, вы, безусловно, останетесь 1-1 с нейрослопом, который нельзя проверить адекватно. Мы даже знаем статы от того же coderabbit: багов в PR от ИИ в 1.7 раз больше, а люди кликают в два раза чаще "аппрув не глядя", когда видят огромный PR от ИИ-шки.
И все это надо решить, перед тем как пересобирать процесс. Вот только кто ответственен за решения этих проблем? В одном случае команда сама может туда контрибьютить (у меня таких много): делает обвязку, эвалы, улучшает повторяемость результатов на разных моделях. В других командах - ждут централизованного решения, потому что им не до этого. В данном случае каждая организация/отдел/команда должны иметь явный ответ на вопрос - кто доводит до нормального состояния ИИ-тулы.
Погодите, давайте разделять. Тут два вопроса.
Если вы не хотите разбираться - это ваше право, мне кажется базовое. Тут вопрос - если агенты плодят нейрослоп, может быть вам дают плохой инструмент? Плохих агентов? Хреновую обвязку? А кто за это ответственен (за DevExperience, который в вашем случае плохой).
Глобально, вы бы, наверное, не были бы против удобного инструмента, избавляющего от рутины?
Так и статья про то что не надо оголтело и без цели внедрять ИИ. И ничего вы не внедрите, еслрине будете работать с людьми и если они не будут выкупать - зачем это и какой бенефит будет.
А если сопротивляются - это проблема в системе, а не людях.
Ковыряться в нейрослопе вы больше полугода не сможете, надо пересобрать весь процесс работы - причем самой команде - и чтобы она в этом была сама заинтересованна.
Пока в мире на масштабе нет ни одного кейса, что внедрение ИИ и агентизация принесли больше денег кому-то (кроме антропика и openai)
Не меняются потому что надо перестраивать весь процесс поставки, а не просто давать людям инструмент. Иначе точечное , в не системное использование инструментов не ускоряет end 2 end процесс
По итогу первых двух гипотез не было от слова совсем изменений в Lead Time, Throughput, Defect Rate.
Я попробовал ответить на вопрос во второй статье, где мы наконец-то локально смогли увидеть, как AI-first команды изменяют нужную сторону метрики потока.
Так для этого (мы видим по опыту китая) надо вкладывать дохулиардные инвестиции много лет подряд, чего сейчас в текущих условиях не делается (денег выделено на импортзам и передовые железки с гулькин нос). А с учетом дефицита бюджета и подавно не будет.
То есть прямо сейчас надо будет усиленно переориентировать инвестиции в НИОКР, чего не предвидится.
Мы смотрели шире, на качество коммуникации тоже. Support / CSM / Sales могут пороть ерунду, могут преувеличивать проблемы. Там, по-хорошему, надо еще и в то как они свою работу делают погружаться и мониторить. Но это совсем другая история (там моделька - тогда еще ранний gemini - ходила по заметкам общения с клиентами в google meet / gong / salesforce и очень базово репортила если были паттерны общения, которые мы не поощряем). Это было на заре начала chatGPT и всяких суммаризаторов google meet (в end 2022- mid 2023)