Самое сложное в ИТ — не технологии, а люди. Без них не получится ничего большого, но они сопротивляются, сомневаются, по-разному воспринимают изменения и далеко не всегда делают то, что казалось очевидным на схеме.

Поэтому эта история будет не только про очередной ИИ-инструмент, но и про команду из 16 человек, которая за несколько месяцев изменила привычный способ работы и перестроилась в пять микроюнитов.

Привет, Хабр! Меня зовут Сергей Чистяков, в ИТ я с 2006 года. Веду канал в телеграм. Сейчас работаю техлидом в Райффайзен Банке и строю систему автоматизации бизнес-процессов, в которой вместе работают люди и агенты. Расскажу про воркшоп, на котором никто не научился писать автотесты, двухдневный дофаминовый шок и пять маленьких команд, которые начали проводить задачи через весь цикл разработки и построили для этого собственный workflow поверх нескольких репозиториев.

Дедлайн вместо планов

Всё началось с решения, после которого мы почувствовали, что почва уходит из-под ног. Наша команда развивала новый продукт, а параллельно в банковском контуре больше десяти лет жила вендорская коробка. Она обрастала плагинами, доработками и обёртками и постепенно пустила метастазы по всему банку.

Конечно, мы собирались перенести всё необходимое в свой продукт и когда-нибудь отказаться от старой системы. Но в начале года бизнес решил, что «когда-нибудь» уже наступило и перенос нужно закончить в течение года.

Обычно у такой задачи есть два очевидных решения. Можно увеличить срок или добавить людей. У нас не изменилось ни то ни другое, зато появилось название «Прыжок веры». Мы летели в пропасть, попутно пытаясь сшить парашют. Остановиться, выбрать идеальную методологию и потом начать трансформацию не получалось, потому что нужно было продолжать пилить продукт.

Мы не рассматривали работу без выходных, потому что ради выигрыша нескольких недель не хотели терять людей. А вместо этого сделали ставку на ИИ-инструменты. Они должны были увеличить наши возможности и помочь людям брать задачи за пределами своей специализации.

Первый подход: AI Club

В команде было 16 человек: аналитики, разработчики, QA, DevOps и специалисты поддержки. По отношению к ИИ они разделились на три группы. Три энтузиаста сами следили за новыми инструментами, экспериментировали и приносили результаты коллегам. Шесть скептиков воспринимали ИИ как временное явление или технологию, которая однажды придёт за их профессией. Ещё семеро заняли позицию наблюдателей.

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

К тому моменту мы уже несколько месяцев проводили AI Club. Встречались раз в две недели и обсуждали новые плагины, модели и агентов. Встречи создавали информационный фон, но почти не влияли на ежедневную работу. Человек мог посмотреть демонстрацию, кивнуть, вернуться к своему бэклогу и даже не открыть агента. А на ретро звучали вполне конкретные претензии.

Формулировки пришлось отредактировать, чтобы не раскрывать внутреннюю кухню, но содержание сохранилось. Люди пробовали инструмент, получали плохой результат и делали рациональный вывод, что он только мешает.

Тогда стало ясно, что одних рассказов о возможностях ИИ недостаточно.

Как продать изменения своей команде

Я пару недель собирался с духом, а потом позвал команду на встречу-манифест. Мы прямо обсудили три вещи. Мир изменился, наши цели тоже, поэтому работать как раньше не получится.

Мы побурлили, покидались эмоциями, но в итоге договорились пробовать.

Когда мы поняли, что трансформация не сводится к умению писать промпты, то выбрали три направления с отдельной рабочей группой по каждому.

Процессы

Мы ожидали, что с помощью агентов команда будет выполнять больше задач и вносить больше изменений, но старый SDLC не был к этому готов. В нём оставались сложные операции с ветками, релизами и ручными проверками, которые раздражали нас и при прежней скорости. Поэтому группа процессов должна была максимально упростить цепочки, автоматизировать проверки и создать единые правила для команды и агентов.

AI Readiness

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

Рабочая группа даже собрала общий для бэкенда и фронтенда фреймворк на аннотациях. Всё выглядело красиво, но позже мы его выпилили. Оказалось, что проще поддерживать агентские скиллы. Но эксперимент всё равно оказался полезным. Пока мы искали эталонные решения, пришлось прочесать собственную систему, договориться об абстракциях и разобраться, какие паттерны повторяются.

T-shapeness

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

Группы встречались несколько раз в неделю. Я ходил к ним, бессовестно тормошил ребят и подталкивал обсуждения в нужном мне направлении, потому что у нас не было времени на медленное созревание идей, а параллельно проводил разговоры один на один. Приходилось подбирать ключ к каждому человеку. Одному требовались аргументы о рынке, другому живой пример, а третьему возможность проговорить страхи. На самых убеждённых скептиков неожиданно подействовал пример моего одиннадцатилетнего сына, который навайбкодил себе игру. Ребёнок смог — сможешь и ты!

Где искали идеи

Мы искали ответы не только среди новых агентских фреймворков. Большая часть нужного фундамента давно существовала в инженерной культуре. Мы брали практики из разных подходов, проверяли их на своих задачах и оставляли то, что помогало двигаться дальше. А из выбранных практик собирали лоскутное одеяло.

Первой стюардессой, которую мы откопали, оказалось экстремальное программирование, или Extreme Programming (XP). Сейчас о нём говорят не так часто, хотя многие его практики давно стали индустриальным стандартом.

Особый бриллиант — парная работа. Она позволяла объединить человека с более опытным коллегой и постепенно передавать ему задачи.

Из практик XP мы также взяли непрерывную интеграцию. Она стала незаменимой при росте числа изменений, поскольку ручные проверки уже не выдерживали нового темпа.

Вторым источником стал trunk-based development. Короткоживущие ветки и branch by abstraction помогали доставлять изменения небольшими частями и не разводить длинные параллельные истории.

Не хочу рассказывать сказку об идеальном внедрении, потому что это было не так. Branch by abstraction оказался одной из самых тяжёлых практик для инженерного мышления. Мы договаривались работать по-новому, потом начинали читить, возвращались к привычному подходу, снова обсуждали проблему и пробовали ещё раз. И только после долгих проб и ошибок что-то начало вырисовываться.

Feature toggles тоже были на исходной схеме, но почти не пригодились. В большинстве случаев мы обходились повышением версии или обратно совместимыми изменениями. Ситуации, когда потребовались именно feature toggles, можно было пересчитать по пальцам одной руки.

Элементы общего языка у нас существовали и раньше, но теперь мы сделали всё максимально серьёзно. За основу взяли ubiquitous language из предметно-ориентированного проектирования, или Domain-Driven Design (DDD). Единые термины стали использовать в общении с бизнесом, документации, декомпозиции, названиях скиллов, классов и переменных. Так одни и те же сущности начали проходить через несколько уровней проекта под одинаковыми именами. Это помогало людям, а ещё больше агенту, которому больше не требовалось угадывать, относятся ли два похожих слова к одному понятию.

Воркшоп — провал и прогресс

QA-команда хотела научить коллег писать автотесты и очень серьёзно вложилась в подготовку. Сначала все настраивали окружение, близкое к окружению бэкенд-разработчика, устанавливали сертификаты и готовили CLI-агентов. В банковской инфраструктуре это чуть сложнее, чем нажать кнопку «Установить». Подготовка заняла несколько дней. Рабочее окружение получили даже аналитики и Product Owner, которые раньше почти не работали с кодом.

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

По заявленной цели воркшоп можно считать провальным. Однако аналитик, которая написала на ретро о трёх днях настройки, позже начала создавать MR и спеки в общих репозиториях.

Этот эпизод научил нас смотреть на эксперименты шире первоначальной формулировки. Воркшоп не дал людям компетенции QA, зато подготовка создала общее рабочее окружение. Без него следующего шага бы не было.

Хакатон и дофаминовый шок

К концу марта у нас была запланирована офлайн-встреча. Вместо обычного тимбилдинга мы решили кодить и шевелить мозгами. У хакатона было три цели. Мы хотели:

• запилить пачку фичей,

• посмотреть, кто и как использует ИИ,

• показать, как работают специалисты из соседних команд.

Это должно было снять страх перед чужими стеками и помочь каждому почерпнуть что-то для себя.

К тому времени в продукте появился low-code-движок, с помощью которого бизнес-пользователи могли описывать условия. Мы подготовили около 15 похожих задач, где движок надо было подключить в разных местах продукта. Команду разделили на группы по три или четыре человека.

В первый день все испытали дофаминовый шок. Агент быстро делал первые 80 процентов фичи, и к концу дня участники сами попросили продлить хакатон на второй день.

Утром второго дня я увидел первый MR от аналитика. Всего аналитики подготовили три MR. В этот момент я подумал, что мы приехали не зря.

Отрезвление пришло позже. Агент отлично создавал ощущение быстрого старта, но последние проценты по-прежнему требовали проверки, рефакторинга и знания нюансов системы. Хакатон занял два дня, а затем потребовалась ещё неделя, чтобы дотащить изменения до продакшена.

На ретро состояние команды описали четырьмя словами: «Восторг, сумбур, объём, рефактор».

Эта формула получилась точнее любого отчёта. Хакатон снял страх и показал, что специалист способен зайти в соседнюю область. Участники перестали считать такой подход невозможным и бояться ИИ-ассистентов, хотя правильно использовать их пока не научились.

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

Сила маленьких команд

После хакатона мы запустили две пилотные группы в аналогичном режиме, чтобы проверить, сможет ли маленькая команда с агентами закрывать задачи. Результаты превзошли наши ожидания, и уже через месяц у нас было пять таких команд. Discovery и delivery объединили, чтобы участники сами разбирались в задаче и сразу начинали её реализовывать.

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

Сначала каждый специалист автоматизировал собственную работу. Он собирал скиллы и контекст в своей области, сокращал рутину и освобождал время. При этом участники постоянно общались и работали парами. Они могли разойтись, чтобы независимо выполнить разные части задачи, а затем снова объединиться. Агент особенно помогал там, где человеку не хватало собственного опыта.

Затем специалисты начали выходить за пределы своих ролей. Если разрыв в компетенциях оказывался слишком большим, к работе подключали коллегу из другой группы. Вместе с ним приходили подготовленные профессионалами скиллы из нужной области. Поэтому остальным не приходилось разбираться с чистого листа. Агент становился не заменой экспертизы, а экзоскелетом, на который коллеги заранее нанизали часть своего опыта.

От Definition of Ready мы быстро отказались. Раньше задача должна была пройти отдельную подготовку, прежде чем попасть к разработчикам. Теперь её разбор и внутренняя декомпозиция стали делом самого юнита.

Те же 16 человек распределились по пяти микроюнитам вместо двух feature teams. У каждого юнита появился собственный поток задач, который проводился end-to-end через discovery и delivery.

Сначала всё выглядело логично. Вместо двух больших потоков появились пять небольших, поэтому параллельно могло двигаться больше задач. Однако вскоре проявились две новые проблемы.

Первая была организационной. Каждый юнит начал вариться в собственной кастрюльке. Люди хуже понимали, чем заняты коллеги из других юнитов, какие решения нашли и можно ли их переиспользовать.

Вторая проблема оказалась технической. Локальные скиллы хранились в разных местах и у разных людей работали по-разному. Общего способа делиться ими и передавать проектный контекст между юнитами не было.

Мы сломали старые процессы, но не успели построить новые. Возвращаться к двум feature teams не хотелось. Более крупные команды упростили бы синхронизацию, но вместе с ней вернули бы прежние очереди. Поэтому организационную и техническую проблемы пришлось решать отдельно.

Как синхронизировать юниты, не возвращая старый процесс

Мы перестроили дейлики в формат Scrum of Scrums. Каждый юнит рассказывал о текущем фокусе и блокерах, а остальные видели пересечения со своими задачами. При этом команда не проваливалась в детали каждой подзадачи. Способ реализации оставался внутренним делом юнита.

Вмешаться в работу юнита команда могла в трёх контрольных точках.

1. После discovery юнит приносил спецификацию или схему будущего решения, которую могли почелленджить команда и владельцы затронутых компонентов.

2. Изменения проходили cross-team code review у владельцев соответствующих репозиториев.

3. Готовую функциональность показывали на внутреннем демо, которое обычно проходило раз в спринт перед общим ревью с бизнесом.

Для spec review выделили два дополнительных слота в неделю. А если вопрос требовал срочного решения, его можно было обсудить после обычного дейлика.

Так мы сохранили автономность маленьких групп, но вернули общее понимание происходящего. Юниту не требовалось согласовывать каждую операцию, а команда могла вмешаться, если локальное решение влияло на общую архитектуру.

Организационную часть удалось собрать сравнительно быстро. С технической оказалось сложнее. Людей синхронизировали созвоны, но агентам требовался контекст, который можно было сохранить, передать другому юниту и воспроизвести в новой сессии.

Моя воображаемая монорепа

Наш проект состоит из нескольких микросервисов, микрофронтендов и общих библиотек. Для каждого компонента используется отдельный репозиторий, пайплайн и артефакт. При обычной разработке такая организация не мешала. Человек знал, где находится нужный компонент, и мог переключаться между репозиториями. Но для end-to-end-задачи агенту требовалось одновременно видеть несколько частей системы.

В тот момент я впервые пожалел, что у нас не монорепозиторий. Пришлось собирать обходное решение, которое мы назвали metarepo. По сути, эрзац-монорепозиторий. Сам код компонентов по-прежнему жил отдельно, а metarepo выкачивал нужные репозитории и собирал вокруг задачи единое рабочее пространство. Там же находились скрипты синхронизации веток, настройки MCP и общепроектные скиллы.

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

Движение задачи между metarepo, репозиториями компонентов и автотестов выглядело так.

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

Проектный workflow поверх общего контекста

Наш workflow запускается для любой задачи из Jira и проводит её через обязательные для проекта стадии.

На каждом этапе появляется артефакт, который становится основой для дальнейшей работы. Если во время реализации обнаруживается новое ограничение, workflow возвращается на нужный уровень. Спецификация корректируется, а зависимые части получают обновлённый контекст. Мы не пытаемся заставить агента с первой попытки предсказать всё устройство системы.

Переходы между стадиями не происходят автоматически. Человек проверяет результат работы агента и только после этого разрешает двигаться дальше.

Ретроспектива помогает постепенно накапливать проектные знания. В конце работы мы вместе с агентом разбираем ошибки и определяем, какие правила стоит учитывать в следующий раз. Например, нам пришлось отдельно научить его не коммитить изменения без разрешения.

При разработке мы использовали идеи BMAD. По общей логике наш workflow похож на OpenSpec и GSD, но его этапы и артефакты адаптированы под наш проект. Основным инструментом стал CLI-агент с разными моделями. Для небольших задач также используется агент в GitLab Pipeline, который может исправлять отдельные замечания прямо в MR.

Нам было важно закрыть бэклог к концу года, а не добиться полной автономности. Агент опирался на проектные гайды, инструкции в репозиториях и спецификации, а специалист проверял результат на каждой стадии.

Что бы мы повторили ещё раз

За несколько месяцев мы перепробовали много приёмов, но не нашли одну волшебную практику, которая бы сделала команду быстрее. Парашют пришлось собирать по частям уже во время падения.

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