Превратите желаемый результат в инициативу

Опишите результат до шагов реализации

Вымышленному сервису оборудования нужна самостоятельная подача заявок сотрудниками. Полезный запрос задаёт результат: «Аутентифицированный сотрудник может создать заявку и видеть только собственные заявки».

Объясните пользу: сейчас руководители вводят заявки за сотрудников. Определите объём: создание заявки, отображение статуса, проверки доступа и подтверждения этого поведения. Исключите автоматические закупки и изменения правила одобрения руководителем.

Не предписывайте изменения файлов до изучения репозитория. Инициатива фиксирует замысел. Подробное планирование превращает его в шаги реализации.

Проверьте результат запроса

Taiga использует запрос и контекст продукта для создания инициативы или упорядоченного набора инициатив. Новая работа поступает в Backlog. Большой запрос может потребовать нескольких изменений, каждое из которых можно проверить отдельно.

Прочитайте сгенерированное конечное состояние, Why и Scope. Проверьте, сохранено ли требуемое поведение и соблюдены ли исключения. Если существующая инициатива уже охватывает запрос, Taiga может указать её вместо создания дубликата.

Если запрос блокирует опубликованная политика, используйте предусмотренный ею порядок принятия решений. Прочитайте объяснение и разрешите противоречие этим способом. Не переписывайте запрос только ради сокрытия запрещённого действия.

Рассматривайте доску как последовательность выполнения

Taiga работает с одной инициативой на продукт за раз, включая планирование. Следующая инициатива из очереди начинается после merge текущего pull request. Элементы не перемещаются автоматически из Backlog или Todo в Queue.

Помещение в Queue имеет последствия. Оно отменяет ожидание незавершённых зависимостей. Перед постановкой самостоятельной подачи заявок в очередь убедитесь, что основа identity уже есть или выбранный объём корректно её создаёт.

Изучите подробный план

Планировщик читает репозиторий, документы продукта, политики, инструкции и контекст развёртывания. Сопоставьте план с реальным результатом для пользователя и средой.

Для сервиса оборудования проверьте три случая доступа. Сотрудник видит свою заявку. Другой сотрудник не может её увидеть. Руководитель сохраняет предусмотренный доступ для проверки. Учитывайте миграцию данных и последствия для эксплуатации, если реализация их меняет.

Если Build on its own by default выключено, готовый план ждёт вашего решения. Approve запускает реализацию от имени одобрившего человека в пределах его разрешений. Reject использует вашу обратную связь для повторного планирования. У инициативы может быть собственная настройка.

Используйте подходящую запись для следующего решения

Планы имеют версии. Run фиксирует, какой план он выполнил. Если предполагаемый подход меняется, проверьте инициативу и подходящее действие повторного планирования. Для изучения предыдущей попытки используйте run.

Реализация, pull request после merge и выпуск в production — разные состояния. По мере работы сохраняйте видимость подтверждений для приёмки и ответственности за развёртывание. Продолжите с настройками автономии.