Шаблон: статусная модель задач трекера
Документ описывает действующий процесс команды: статусы, разрешённые переходы, условия и ответственность. Он применяется и к работе людей, и к работе с агентами. Ветки, MR и ревью описаны в Git-процессе; запуск агентов и точки HITL — в маршруте работы с агентами.
1. Паспорт процесса
- Проект, трекер, поток и область применения: …
- Версия, дата, владелец документа: …
- Кто подтвердил правила, дата и ссылка на запись: …
- Источник актуальной постановки и решений: …
- Ответственные за постановку, назначение, приёмку и изменение статусов: …
- Ссылка на действующие правила Git/MR: …
- Ссылка на маршрут работы с агентами, если применяется: …
2. Статусы и поля
Использовать реальные названия и ID статусов выбранного трекера. Для временного процесса указать область и отличия от целевого. Не создавать статусы ради агента или мониторинга, если различие уже выражено полем, меткой или причиной блокировки.
| Статус / ID | Смысл и обязательные поля | Ответственная роль | Условия входа | Условия выхода |
|---|---|---|---|---|
| … | … | … | … | … |
Описать используемые состояния подготовки, готовности, выполнения, проверки, исправления, интеграции/выпуска и завершения. Ожидание, передача другому исполнителю и отмена отражаются так, как принято в команде: статусом либо дополнительными полями. Новое назначение исполнителя само по себе не означает завершения задачи.
3. Разрешённые переходы
| Откуда → куда | Условие перехода | Кто принимает решение | Кто меняет статус / поля | Подтверждение в принятом процессе |
|---|---|---|---|---|
| … | … | … | … | … |
Покрыть основной путь и возвраты: уточнение постановки, замечания ревью, дефект на приёмке, изменение объёма, смена исполнителя и отмена. Указать, где фиксируются решения. Зелёный CI или отсутствие ответа не заменяют необходимую приёмку.
- Критерий готовности задачи к выполнению: …
- Кто и на каком основании подтверждает продуктовую приёмку: …
- Условие завершения: merge / выпуск / другая принятая точка; ссылка на правило: …
- Как учитываются новый объём, повторное открытие и отмена: …
- Кто устраняет ошибочный переход или расхождение с фактическим состоянием: …
4. Связь с Git-процессом
Задача связывается с рабочими ветками, MR и результатами проверок принятым в команде способом: … . Для переходов, зависящих от ревью, интеграции или выпуска, сослаться на соответствующие условия Git-процесса, без повторения его регламента.
Статус задачи, состояние MR и состояние запуска агента — разные сущности. Выполненный merge не означает выпуск, а остановленный агент не означает завершённую задачу. Кто может выполнять переход от имени агента, где он спрашивает решение и когда возобновляется, определяется только маршрутом работы с агентами.