После аджайла и вотерфола
В предыдущей главе рассказывал, что стили процессов разработки пытаются аккуратно обойти главный ограничитель работы
Вотерфол ставит главную проблему — сложность. Большой сложный проект с большим количеством (тысяча и более) участников не может управляться через дейли и спринты. Какие-то команды будут подключаться ближе к концу и для их работы нужны результаты других команд. Большой управленческий оверхед, но зато у проекта появляется шанс быть сделанным
Аджайл ставит другую проблему — производительность разработчиков. Что люди важнее процессов, что можно не писать документацию, потому что код это лучшая документация. Написание кода становится сложнее, зато другие задачи (менее важные) не нужно делать. В небольших командах и в условиях высокой переменчивости такой подход результативнее
В агентной разработке другая проблема — агенты не знают ваш контекст. Что за систему делаете, какие планы на нее, какая архитектура, какие компоненты нужно использовать, какие устаревшие, как работает этот модуль.
И решение в лоб проблемы — строгий контроль и управление человеком. Нужно подробно ставить задачу (детально описывать технические решения). Нужно внимательно проводить ревью кода (а то вдруг агент что-то там не так придумал?). Минусы такого решения понятны — на человека большая нагрузка, невозможно раскрыть на полную мощность скорость агентов
Решение лучше — формировать контекст проекта. Делать рамки и подсказки, чтобы агент автоматически их учитывал, и не нужно было его постоянно подруливать:
1. линты кода (красить красным как нельзя делать)
2. тесты — правила написания, требования выполнять и сами тесты
3. архитектура в целом — какие компоненты, как собирается, как поставляется клиенту, как устроен деплой
4. архитектура в частности — подробнее про компоненты, их структуру и правила. Например, как пишем helm-чарты. Или как работаем с базой данных
5. спецификации — планы разработки модулей (целевая модель), текущие интенты (почему именно так было сделано, важные требования и ограничения)
6. фидбек-луп — набор скиллов, который проверяет полученный код на разные аспекты: качества кода, дизайн, безопасность
И здесь видно где новый поход начинает конфликтовать с очень привычным всем аджайлом. В аджайле тоже есть похожие практики, но там обычно нормально что это все в головах у людей. Они эти практики делают руками, данные прошиты в их голове. С агентами так не получается, необходимо, чтобы агенты тоже были прошиты этими правилами. Документация и явно описанные правила снова становятся важным аспектом работы
#nextgen_dev
В предыдущей главе рассказывал, что стили процессов разработки пытаются аккуратно обойти главный ограничитель работы
Вотерфол ставит главную проблему — сложность. Большой сложный проект с большим количеством (тысяча и более) участников не может управляться через дейли и спринты. Какие-то команды будут подключаться ближе к концу и для их работы нужны результаты других команд. Большой управленческий оверхед, но зато у проекта появляется шанс быть сделанным
Аджайл ставит другую проблему — производительность разработчиков. Что люди важнее процессов, что можно не писать документацию, потому что код это лучшая документация. Написание кода становится сложнее, зато другие задачи (менее важные) не нужно делать. В небольших командах и в условиях высокой переменчивости такой подход результативнее
В агентной разработке другая проблема — агенты не знают ваш контекст. Что за систему делаете, какие планы на нее, какая архитектура, какие компоненты нужно использовать, какие устаревшие, как работает этот модуль.
И решение в лоб проблемы — строгий контроль и управление человеком. Нужно подробно ставить задачу (детально описывать технические решения). Нужно внимательно проводить ревью кода (а то вдруг агент что-то там не так придумал?). Минусы такого решения понятны — на человека большая нагрузка, невозможно раскрыть на полную мощность скорость агентов
Решение лучше — формировать контекст проекта. Делать рамки и подсказки, чтобы агент автоматически их учитывал, и не нужно было его постоянно подруливать:
1. линты кода (красить красным как нельзя делать)
2. тесты — правила написания, требования выполнять и сами тесты
3. архитектура в целом — какие компоненты, как собирается, как поставляется клиенту, как устроен деплой
4. архитектура в частности — подробнее про компоненты, их структуру и правила. Например, как пишем helm-чарты. Или как работаем с базой данных
5. спецификации — планы разработки модулей (целевая модель), текущие интенты (почему именно так было сделано, важные требования и ограничения)
6. фидбек-луп — набор скиллов, который проверяет полученный код на разные аспекты: качества кода, дизайн, безопасность
И здесь видно где новый поход начинает конфликтовать с очень привычным всем аджайлом. В аджайле тоже есть похожие практики, но там обычно нормально что это все в головах у людей. Они эти практики делают руками, данные прошиты в их голове. С агентами так не получается, необходимо, чтобы агенты тоже были прошиты этими правилами. Документация и явно описанные правила снова становятся важным аспектом работы
#nextgen_dev