|
Professor Seleznov
|
Поискал облегченных методологий разработки, да и чтобы с возможностью включения агентов в процессы и не нашел.
В этой статье я пробую сформулировать облегчённую методологию разработки для кросс-функциональных команд.
Центральная идея — явный 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 задаётся на старте каждого эпика. Не глобально раз и навсегда — именно на эпик, потому что состав и распределение ответственности могут меняться. Но если роли статичны и не меняются от эпика к эпику - можно зафиксировать и где-нибудь в вики команды.
Роли
| Роль |
Зона ответственности |
Совмещение |
Агент может выполнять |
| Team Lead / PO |
Приоритеты, процесс, делегирование, сквозная ответственность, закрытие эпиков (политика) |
Аналитик (малые команды) |
Не подменяет ответственность TL/PO, но может помочь в автоматизации рутины |
| Аналитик |
Детализация требований, цель и критерии успеха |
Team Lead, Разработчик |
Структурирование требований, черновики, анализ данных |
| Разработчик |
Реализация, code review, деплой на DEV |
Тестировщик (малые команды) |
Реализация, review, генерация тестов |
| Тестировщик / QA |
Тестирование на стендах, ответственность за ГА и ТЛИ |
— |
Автотесты, регресс, тест-кейсы, функциональные тесты, проверка интеграций |
| Релиз-инженер / DevOps |
Деплой на тестовые стенды и ПРОД, ответственность за ПРОД |
Разработчик, SRE |
Автодеплой по правилам (ПРОД — только с явного разрешения человека, на старте я бы с этим не спешил) |
| Сопровождение / SRE |
Эксплуатация, приёмка, закрытие эпиков (исполнение), ПРОД совместно с релизом |
— |
Мониторинг, первичная обработка, поиск аномалий |
## Стартовый режим: что делать с новой командой
Самая частая критика, которую мы получили: «это работает только в сработанных командах, для новых — слишком много свободы».
Критика честная. Принцип «минимум обязательного» предполагает, что команда знает, что ей нужно. Новая команда этим знанием не обладает.
Ответ — стартовый режим на первые 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 и разделом про межкомандную работу выложу отдельно, если будет интерес.-Источник
|
