Какую колонку добавить между in progress и in test?

Анализ и рекомендация по колонке между "In Progress" и "In Test"

Основываясь на моем опыте управления проектами в IT, типичный workflow задач в Kanban или Scrum-доске выглядит так: Backlog → To Do → In Progress → In Test → Done. Пропуск этапа между разработкой и тестированием часто приводит к "бутылочным горлышкам", некачественным билдам и конфликтам между командами. Чтобы сделать процесс более плавным и контролируемым, я рекомендую добавить колонку "Ready for Test" (или "Ready for QA").

Почему именно "Ready for Test"?

Эта колонка служит буфером качества и точкой согласования между разработчиками и тестировщиками. Ее добавление решает несколько критических проблем:

• Четкое разделение ответственности: Разработчик перемещает задачу в "Ready for Test", сигнализируя: "Моя работа по коду завершена, и я считаю, что задача соответствует критериям приемки (DoD)". Тестировщик берет задачу оттуда, принимая ответственность за ее валидацию. Это устраняет споры о том, "готово ли что-то для теста или нет".
• Контроль качества на входе: Задача должна пройти минимальный Definition of Done (DoD) перед попаданием в эту колонку. Это автоматически отфильтровывает "сырой" код.
• Управление потоком (Flow Management): Она предотвращает затопление команды тестирования неготовыми задачами. Если колонка "In Test" переполнена, новые задачи просто накапливаются в "Ready for Test", что визуализирует проблему и позволяет менеджеру вмешаться.
• Улучшение метрик: Появляется возможность измерять время ожидания в очереди на тест (Lead Time между "Ready for Test" и "In Test"). Это ключевой показатель эффективности процесса "разработка-тестирование".

Практическая реализация и критерии перехода

Колонка "Ready for Test" должна быть не просто контейнером, а контрольной точкой. Переход задачи в нее должен быть регламентирован. Типичный чек-лист (DoD) для перехода из "In Progress" в "Ready for Test":

Definition of Done для перехода в "Ready for Test":
  - Код завершен и соответствует стандартам.
  - Код проверен (code review) другим разработчиком.
  - Успешно выполнен модульный/интеграционный тест.
  - Задача локально собрана и запущена.
  - Код влит в основную ветку (main/develop) или выделенную для теста.
  - Обновлена документация (если требуется).
  - Критерии приемки (Acceptance Criteria) из тикета выполнены.

Альтернативные варианты и их применение

В зависимости от специфики проекта можно рассмотреть другие названия, которые несут дополнительный смысл:

1. "Code Review" / "Review" – Акцент на обязательном процессе проверки кода. Подходит для команд, где это слабое место.
2. "Build / Integration" – Акцент на этапе сборки и деплоя на тестовое окружение. Критично при сложных процессах интеграции.
3. "QA Ready" – Синоним "Ready for Test", более привычный для некоторых команд.
4. "Staging / Pre-Test" – Указывает на то, что функциональность уже развернута на специальном окружении, максимально близком к продовольственному.

Мой выбор: Для большинства проектов "Ready for Test" является оптимальным, так как это наиболее интуитивно понятный и процессно-нейтральный термин. Он фокусируется на состоянии задачи (готова к следующему шагу), а не на конкретном действии, что делает доску более гибкой.

Пример настройки workflow в Jira

Вот как может выглядеть упрощенная схема статусов после добавления:

Open (Создано) -> To Do (К выполнению) -> In Progress (В работе)
-> **Ready for Test (Готово к тесту)** -> In Test (В тестировании)
-> Resolved (Решено) -> Closed (Закрыто)

Вывод: Добавление колонки "Ready for Test" — это не просто механическое расширение доски, а внедрение важного процессного этапа. Она формализует передачу работы, повышает предсказуемость потока задач и качество продукта, а также дает менеджеру мощный инструмент для анализа и улучшения взаимодействия между разработкой и QA.