Этапы внедрения и охват работы агента
Актуальная последовательность и условия переходов описаны в процессе внедрения. Этот документ помогает отдельно задавать сложность задач, охват агента и глубину проверки человеком.
Этапы и фазы
| Этап | Фаза | Срок | Назначение |
|---|---|---|---|
| Подготовка | Не делится на фазы | По согласованному плану | Обследование, контекст проекта, инфраструктура, доступы, выбор задач и процесс работы |
| PoC | 1. Онбординг агентов | Неделя 1 | Адаптация литературы, агентов и навыков; минимальный путь от сообщения в чате до feature-ветки, проверок, деплоя и MR по гайду |
| PoC | 2. Простые задачи | Неделя 2 | Повторяемый полный цикл на простых задачах, включая замечания и интеграцию |
| PoC | 3. Целевые задачи | Недели 3–4 | Типичные задачи выбранного потока Пилота |
| Пилот | На фазы не делится | По согласованному плану | Команда продукта решает задачи; каждую неделю фиксирует результаты и формирует следующий бэклог |
Включение команды, расширение охвата и оптимизация — рабочие действия внутри Пилота, а не последовательные фазы. Расширение охвата не обязательно. Его, как и режим проверки, меняют отдельным решением по данным задач.
Прохождение календарного срока не заменяет проверку результата. Пилот завершается при достижении целей либо с планом их достижения, поддержанным всей рабочей командой клиента и сопровождения, включая стейкхолдера. Полный охват и сокращённая ручная проверка не являются дополнительными условиями успеха.
Сложность задач
| Класс | Признак | Пример |
|---|---|---|
| Простое изменение | Локальная правка с однозначным результатом | Переименовать пункт меню |
| Понятная реализация | Работа объёмнее, но границы и способ реализации ясны | Добавить поле по существующему образцу |
| Аналитическая развилка | Нужно уточнить поведение или выбрать вариант до реализации | Изменить обработку заявки для нескольких статусов |
Сложность не равна риску: небольшая правка в критическом участке может требовать полной проверки. Задачи на реализацию нефункциональных требований не включаются в область внедрения; действующие ограничения продукта продолжают применяться.
Охват работы агента
| Охват | Что выполняет агент | Что остаётся у команды |
|---|---|---|
| Разработка | Готовит изменения по предоставленной постановке, запускает согласованные доступные проверки | Постановка, организация необходимого тестирования, ревью и решения о результате |
| Разработка и тестирование | Дополнительно готовит или изменяет тесты, выполняет согласованные проверки и предъявляет доказательства | Определение достаточности проверок, ревью автотестов и оценка результатов по выбранному режиму |
| Аналитика, разработка и тестирование | Дополнительно разбирает исходный запрос, выявляет вопросы, предлагает сценарии, критерии и варианты решения | Аналитик проверяет полноту и смысл; владелец продукта принимает продуктовые решения; команда оценивает реализацию и доказательства |
Это удобные типовые сочетания. Если у клиента иной порядок, он описывает фактический состав работ. Для тестирования отдельно указывают, какие виды проверок выполняет агент, а какие остаются у людей. Формулировка «разработка» не означает выпуск без тестирования: нужные проверки обеспечивает назначенный участник команды.
Охват можно расширять уже на PoC. На Пилоте разрешено сохранить узкий охват, если он соответствует целям. Перед добавлением новой области команда определяет критерии результата и исполнителя проверки; на новой области начинают с более подробной проверки, даже если другой поток уже работает в выборочном режиме.
Разработка и тестирование не предполагают наличие готового полного набора автотестов на старте. Unit-, API-, UI- и другие применимые проверки развиваются по стратегии тестирования; временные скрипты и поддерживаемый набор различаются явно.
Как обозначать текущее состояние
Для конкретного потока записываются отдельно:
- Этап; для PoC — фаза 1, 2 или 3, для Пилота — неделя журнала.
- Типы задач, сложность и признаки риска.
- Охват агента и работа, остающаяся у людей.
- Маршрут MR и режимы ревью кода, автотестов и результатов тестирования.
- Люди, сроки реакции и основание последнего изменения режима.
Пример: «Пилот, неделя 1; изменения форм с понятной реализацией; разработка и автотесты; все MR кода и тестов проверяются; тестировщик сопоставляет доказательства агента со своей проверкой». Это точнее, чем один общий статус «команда на Пилоте».
Режимы проверки и условия их изменения описаны в регламенте ревью и тестирования. Действия людей — в матрице ролей и связанных с ней гайдах.