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

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

Центральная идея — явный handover: задача не переходит молча, каждая передача — это осознанное действие с контекстом. По идее, методология должна одинаково работать, когда в команде 3 человека, 15 человек, или когда один или несколько из «участников» — AI-агенты. Это концепт, идея, черновик, открытый для критики и комментариев.

---

## Откуда это взялось

Я руковожу центром разработки клиентских и аналитических решений — 50+ человек в семи кросс-функциональных командах с разными стеками. Аналитики, разработчики, QA, DevOps, сопровождение — всё в одной цепочке, от детализации требований до эксплуатации.

За несколько лет мы перепробовали стандартный набор: Scrum, Kanban, Scrumban. Каждый из них решал что-то своё, но во всех трёх я обнаружил одинаковый пробел.

Ни одна из методологий не отвечает на вопрос: что происходит, когда задача переходит от одной роли к другой?

Вот разработчик написал код и поставил статус «Готово к тестированию». Что дальше? Тестировщик это видит? Знает контекст? Понимает, что конкретно нужно проверить? А если тестировщик заболел — задача просто лежит? Кто за это отвечает?

Ни Scrum, ни Kanban на эти вопросы не отвечают. Они описывают итерации, доски, роли — но не сам момент передачи. А именно там живёт большинство операционных потерь.

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

Конечно, на начальном этапе агенты использовались только как расширенный инструмент сотрудника, но, очевидно, хочется большей интеграции агентов в процессы разработки, тестирования, анализа, хочется привлекать агентов как полноценных (почти) участников процесса, со своими учетками в трекере, правами доступа и закрепленными ролями. На мой взгляд, проблема handover для агентов та же самая, что и для людей — только острее, потому что агент не постучит в трекер или мессенджер сам.

Так появилась идея, которую я сформулировал как Lean Relay, или Эстафета, если по-нашему.

---

## Одна идея, из которой всё вытекает

Работа над задачей — это эстафета. Каждый участник принимает задачу, делает свою часть и передаёт дальше с полным контекстом. Эстафетная палочка не должна лежать на дорожке — кто-то всегда бежит.

Эта метафора определяет всё остальное:

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

- Передача — явное, осмысленное действие, а не молчаливая смена статуса

- Контекст передаётся вместе с задачей, не теряется по дороге

- Кто-то всегда несёт ответственность за текущий этап

Второй несущий принцип: задача в трекере — операционный индекс правды. Не хранилище всего (ADR, КАД, спеки в вики — пусть там и лежат), но центр связей: ссылка + выжимка + кто утвердил. Всё, что имеет значение для задачи, должно быть оттуда досягаемо.

---

## Восемь принципов

Коротко, без лишних слов:

1. Один индекс правды. Задача содержит историю работы и ссылки на все значимые артефакты. Решения, принятые вне задачи (на созвоне, в мессенджере), зеркалируются в задачу — в течение 4 рабочих часов.

2. Прозрачность через поток. Значимые события (смена статуса, блокер, handover) транслируются в командный канал автоматически. Дублировать вручную — не нужно. Настроить интеграцию большинства трекеров с чатами - задача несложная и типовая.

3. Передача с ответственностью. Каждый handover — явное действие: смена статуса + комментарий с контекстом + переназначение. Молчаливых переходов нет. Handover авторизует человек — даже если работу выполнил агент.

4. Готово — значит в жизни. Задача завершена, когда результат в реальной эксплуатации и принят заказчиком. Не когда закрыли тикет на анализ, разработку, тестирование или даже релиз.

5. Эстафета не останавливается. Нет нужной роли — Team Lead делегирует на доступного участника. Задача без исполнителя — немедленно блокер в командный чат.

6. Минимум обязательного — максимум свободы. Методология задаёт каркас. Доски, спринты, форматы встреч — команда выбирает сама.

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

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

---

## Что это даёт на практике: три ключевые вещи

### 1. Handover как ключевой элемент процесса

В стандартном Jira-процессе handover — это просто смена исполнителя. Иногда даже без этого: «поставил статус In Review, пусть сам найдёт».

В Lean Relay handover — явное действие с тремя обязательными элементами:

- статус сменился

- написан комментарий: что сделано, что осталось, что нужно от следующего

- задача переназначена на следующего исполнителя

Звучит очевидно. На практике — ломает привычку «сделал и бросил».

Цепочка выглядит так:

```

[Аналитик] → детализация → handover

      ↓

[Разработчик] → разработка → DEV-стенд → handover

      ↓

[Тестировщик] → интеграционный тест → препрод → handover

      ↓

[Релиз-инженер, только человек] → деплой на прод → handover

      ↓

[Сопровождение] → опытная эксплуатация → приёмка → закрытие

```

На каждом переходе — одно и то же: статус, комментарий, переназначение. Минимум, который не даёт задаче потеряться.

### 2. AI-агент как участник, а не инструмент

Когда агент выполняет часть работы в задаче, у него должно быть понятное место в процессе. Lean Relay даёт это место через несколько правил:

- В трекере агент — bot-user с различимым авторством. Его артефакты в задаче явно помечены.

- Перед handover — обязательная верификация. Схема: агент сделал → положил артефакты в задачу → уведомил человека-владельца роли → человек проверил → при одобрении авторизовал handover.

- Специальный статус «На верификации» — промежуточный между «В работе» и «Передано дальше».

- Асинхронный апдейт агента в задаче (+ трансляция в чат)— человекочитаемый (что сделано / что в работе / блокеры), не сырой технический лог.

Что агент не может без явного разрешения человека:

- релиз на прод

- закрытие эпика

- фиксация архитектурного решения как утверждённого (черновик от агента — не утверждение)

- любое действие, влияющее на данные пользователей

Это выглядит, как устойчивая модель: за результат всегда отвечает человек.

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

### 3. Зеркалирование решений

Классическая проблема: решение приняли на созвоне, в задаче ничего нет. Через три недели никто не помнит что и почему. Или помнит по-разному.

В Lean Relay это закрывается явным требованием: решение, принятое вне задачи, должно появиться в задаче — ссылка + краткое резюме (что решили, что меняется) + кто утвердил — в течение 4 рабочих часов.

Это самый операционно тяжёлый принцип. Без дисциплины зеркалирования трекер врёт. Но именно он делает задачу настоящим источником правды, а не витриной.

Lean Relay определяет шесть ролей: Team Lead / PO, Аналитик, Разработчик, Тестировщик, Релиз-инженер, Сопровождение. В малых командах роли совмещаются; при участии агентов добавляется колонка «что агент может делать в этой роли».

RACI задаётся на старте каждого эпика. Не глобально раз и навсегда — именно на эпик, потому что состав и распределение ответственности могут меняться. Но если роли статичны и не меняются от эпика к эпику - можно зафиксировать и где-нибудь в вики команды.

Роли

## Стартовый режим: что делать с новой командой

Самая частая критика, которую мы получили: «это работает только в сработанных командах, для новых — слишком много свободы».

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

Ответ — стартовый режим на первые 6–8 недель. Принцип Shu-Ha-Ri: сначала делаешь всё по правилам буквально, потом адаптируешь, потом отпускаешь лишнее. Нельзя нарушать правило, которого ещё не усвоил.

В стартовом режиме все опциональные элементы становятся временно обязательными:

- Доска: простая Kanban — Бэклог → В работе → На верификации → Тест → Готово. Без кастомизации.

- Апдейт: ежедневно утром, не «при событии». Формат: сделано / делаю / блокеры.

- Созвон: фиксированный день и время, повестка всегда одинаковая, итог — текстом в чат в течение 30 минут.

- Ретро: каждые две недели. Три вопроса: работало / мешало / изменить.

- Handover-комментарий: три пункта минимум — что сделано, что осталось, что нужно от следующего.

- Зеркалирование: 4 часа, без исключений.

- RACI: на каждом эпике до начала работы — обязательно. Без RACI — Team Lead не принимает эпик.

Выход из стартового режима — по трём условиям: не было потерянных handover за последние 2 недели, зеркалирование соблюдается без напоминаний, каждый участник может объяснить новичку, как выглядит «хороший» handover в этой команде.

Если условия не выполнены — ещё 2 недели с разбором конкретных случаев.

## Несколько команд на одну цель

Lean Relay масштабируется на уровень программы или инициативы. Принцип тот же: у каждой команды своя эстафета, на стыке — явные зависимости и владелец сквозной цели.

В трекере проект — контейнер над эпиками команд. Зависимость между командами — это не устная договорённость, а артефакт: задача с исполнителем на стороне поставщика, связь с задачей потребителя, комментарий при передаче.

Типичный провал без этого: каждая команда в своём Jira, интеграция — в головах нескольких техлидов, которые всё помнят. Пока помнят.

## Открытые вопросы и слабые места

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

Принцип 1 держится на дисциплине. Зеркалирование работает, только если все его соблюдают. В реальности первым срывается тот, кто занят. Противоядие — культура и конкретный ответственный, а не автоматика.

Срок зеркалирования — открытый вопрос. 4 часа — жёсткий дисциплинарный ориентир. Для нагруженных или распределённых команд это может быть сложно. 4–8 часов — компромисс. Мы сознательно оставили это открытым: пусть каждая команда зафиксирует в своём регламенте.

RACI на каждом эпике — операционная нагрузка. Для маленькой команды с устойчивым составом это может быть излишним. Контраргумент: RACI на эпик занимает 10 минут, но экономит несколько часов выяснений позже. Если есть дефолтный RACI на команду - отлично, значит не надо повторять его в каждом эпике, если матрица остается статичной и не меняется от эпика к эпику.

«Слишком много свободы» — частично решено стартовым режимом, но не полностью. Принцип 6 всё равно требует зрелости: команда должна осознанно выбирать, а не просто не делать.

Методология не решает, что брать в работу. Lean Relay описывает как, а не что. Приоритизация бэклога, планирование спринтов, работа с заказчиком на уровне product discovery — это за рамками. Намеренно. Для этого в трекерах есть все инструменты, не считаю нужным включать это непосредственно в каркас.

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

---

## Что дальше

Текущие соображения — черновик, публикую для поиска слабых мест и сбора обратной связи. Основной каркас, как мне кажется, рабочий. Ряд мест — открытые вопросы.

Буду рад обратной связи по конкретным пунктам:

- Handover на практике. У вас он явный или молчаливый? Что пошло не так, когда он был молчаливым?

- Агенты в процессе. Если вы уже встраиваете AI-агентов в рабочие цепочки — как решаете вопрос верификации и авторства?

- Зеркалирование результатов обсуждений в тикет. 4 часа — реально? Что работает у вас?

- Стартовый режим. Разумное количество обязательного для новой команды — или всё равно много?

Полный текст методологии (v0.5 Baton) с таблицами, RACI и разделом про межкомандную работу выложу отдельно, если будет интерес.