Процесс: разработка фичи по принятой спецификации
Учебный пример для продуктовой команды с общим Git-репозиторием и автоматическими проверками. Значения заменяются данными команды до пилота.
Зачем
- Какую проблему решаем: инженер вручную собирает контекст, пишет типовой код и проводит результат через повторные проверки.
- Какой результат должен измениться: сократить время от принятой спецификации до принятого изменения без роста дефектов и нагрузки на проверяющего.
- Как процесс связан с целью внедрения: агент исследует код, готовит план и изменение; люди принимают план, результат и решение о выпуске.
Точка входа
- Что запускает процесс: принятая спецификация фичи.
- Кто может запустить: руководитель продукта или владелец команды.
- Где это происходит: система задач, Git-репозиторий и CI.
- Как понять, что входные данные готовы: зафиксированы границы, критерии приёмки и актуальная версия спецификации.
Участники и ответственность
- Владелец процесса: руководитель продукта или команды.
- Кто готовит входные данные: автор спецификации.
- Кто принимает результат: владелец процесса и независимый инженер.
- Кто обновляет шаблоны, промпты или скиллы: Tech Lead или назначенный инженер.
Входные данные
- Принятая спецификация в системе задач или документов.
- Код и документация в каноническом Git-репозитории.
- Результаты автоматических проверок в CI.
Выходные артефакты
- Подтверждённый план изменения в задаче.
- Ветка с кодом, тестами и обновлённой документацией.
- Результаты CI, независимой проверки и решение о принятии.
Шаги процесса
Промпты, скиллы и инструменты
- Git, система задач и CI команды.
- Версионируемые инструкции агента и скилл разработки в репозитории.
- Чек-лист ревью и критерии приёмки в задаче.
Контрольные точки с человеком
- Где человек обязан проверить результат: после плана, перед слиянием и перед выпуском.
- Какие решения нельзя отдавать агенту: изменение требований, принятие риска, слияние и выпуск.
- Что делать, если результат сомнительный: остановить процесс, сохранить ветку и вернуть вопрос владельцу.
Данные и доступы
- Какие данные разрешены: код, спецификация, документация и результаты CI в периметре задачи.
- Какие данные запрещены: производственные секреты и данные вне согласованного периметра.
- Где лежат секреты или инструкции по доступу: в принятом командой хранилище секретов; в паспорт значения не копируются.
- Как отключить агента и продолжить вручную: отозвать доступ, сохранить ветку и передать её инженеру.
Метрики
- Основная метрика результата: медианное время от принятой спецификации до принятого изменения; источник — система задач и Git.
- Метрика качества или внедрённости: доля изменений, принятых после первого цикла ревью; источник — pull request.
- Негативный сигнал: дефекты после выпуска и рост времени человека на проверку.
- Исходный уровень: измерить на сопоставимых задачах за неделю до пилота.
Ресурсы и срок
- Срок первого этапа: 4 недели.
- Время команды: до 38 часов на настройку, сопровождение и разбор пилота, без учёта обычной разработки.
- Лимит на инструменты и инфраструктуру: определить до запуска и не превышать без решения владельца.
- Стоимость одного запуска: время агента, инфраструктуры и человеческого ревью; измерить на первых трёх задачах.
- Полная стоимость этапа: 38 часов по внутренним ставкам плюс фактическая стоимость инструментов.
Критерий внедрённости
- Когда процесс считается принятым: сопоставимые фичи регулярно проходят через план, отдельную ветку, CI и независимую проверку; метрики не хуже согласованного порога.
- Когда процесс нужно остановить или пересобрать: агент выходит за ветку, обходит проверки, увеличивает дефекты или запуски не попадают в журнал.
- Кто принимает решение: владелец процесса вместе с Tech Lead.
- Когда пересматривать: после 4 недель пилота, затем ежемесячно.
Журнал запусков
