Джина Гайд

Пример: статусная модель задач трекера

Вымышленный проект «Обращения». Пример заполнения процесса задач. Способ работы агентов описан отдельно, правила веток и MR — в Git-примере.

Область и роли

Поток — изменение формы обращения и связанных API/тестов. Мария готовит постановку и назначает работу, Алексей проверяет код и интегрирует, Борис проверяет тесты и результат, Ольга принимает продуктовые решения. Реальные ID статусов и полей указываются в документе проекта.

Статусы

Статус Смысл Ответственный
Бэклог Постановка готовится или ждёт выбора Мария
Готово к выполнению Постановка и условия выполнения готовы, работа выбрана Мария
В работе Назначенный исполнитель выполняет задачу либо исправления Текущий исполнитель
На проверке Результат передан на ревью и продуктовую проверку Алексей, Борис и Ольга в своей области
Готово Ревью и приёмка выполнены, все необходимые изменения в main Мария проверяет комплект подтверждений
Отменено Есть решение прекратить работу Ольга

Ожидание человека отражается полями «Причина ожидания», «Адресат» и «Запрос», без нового статуса. Смена исполнителя отражается назначением; она не закрывает продуктовую задачу.

Переходы и связь с Git

Переход Условие Решение и подтверждение
Бэклог → Готово к выполнению Согласованы требования, определены границы и доступны необходимые входы Мария фиксирует готовность и выбор работы
Готово к выполнению → В работе Исполнитель принял задачу Запись назначения и принятия
В работе → На проверке MR и результаты проверок готовы по Git-процессу Ссылка на MR и проверенную ревизию, назначенные проверяющие
На проверке → В работе Есть подтверждённые замечания Вердикт и перечень исправлений
На проверке → Готово Борис подтвердил проверки, Ольга — приёмку, Алексей выполнил merge всех нужных MR Ссылки на вердикты, приёмку и merge
Любой незавершённый → Отменено Работа больше не нужна Решение Ольги с причиной

До merge после успешной приёмки задача остаётся «На проверке». Merge не означает выпуск в production. Если появляется новый объём, Мария оформляет его отдельно. При повторном открытии сохраняются прежние подтверждения и история; назначается новый необходимый шаг. Ошибочный статус исправляется по фактическому состоянию с записью причины.