Разработка ПО — это гонка с препятствиями, где даже «сырые» задачи могут превратить проект в хаос. «Definition of Ready» (DoR) — простая практика, которая помогает избежать этого. Но мало кто знает, что DoR работает не только для User Story, Task и Bug, но и для любых других типов задач, которые ваша команда использует в трекере. Прелесть практики в её универсальности: DoR подходит для любых инструментов (Jira, Trello, Kaiten, Yandex Tracker, даже Excel), главное — определить, какие условия должны выполняться, чтобы задача считалась «готовой к работе».
DoR: универсальный фильтр для всех типов задач
DoR — это набор критериев , которые определяют, готова ли задача к выполнению. Например:
- Для Epic: «В Epic обозначена цель, внутри Epic созданы User Story».
- Для User Story: «Описание выполнено в формате «Как [роль пользователя], я хочу [действие], чтобы [цель]», есть acceptance criteria, прикреплены макеты или прототипы».
- Для Task: «Техническое задание ясно сформулировано, указаны зависимости (например, «ожидается API от backend»), и есть доступ к необходимым ресурсам (например, тестовый стенд)».
- Для Bug: «Есть шаги воспроизведения ошибки, приложены логи или скриншоты, и определена её критичность (например, «блокирует основной функционал»)».
DoR: не только для User Story, Task и Bug
DoR работает для любого типа задач , который ваша команда использует в трекере. Если вы работаете с Feature , Technical Debt , Sub-task , Design Task или другими типами — пишите свои критерии! Например:
- Для Feature: «Есть техническая спецификация, согласованы KPI (например, «скорость загрузки < 2 сек»), и прикреплены примеры MVP» .
- Для Technical Debt: «Описано влияние на продукт, определён приоритет (например, «высокий — блокирует разработку новой функции»)» .
- Для Sub-task: «Связь с родительской задачей ясна, есть сроки выполнения, и указаны ответственные» .
- Для Design Task: «Макеты или прототипы согласованы с заказчиком, есть технические требования к верстке» .
Как создать DoR для вашей команды: 5 правил
1. Совместно определите критерии
Что нужно делать:
Вовлекайте всех участников процесса — разработчиков, тестировщиков, Product Owner, менеджеров.
- Хорошо 👍:
«На ретроспективе мы обсудили, что для задачи по интеграции API DoR должен включать готовность тестового контура и согласование с DevOps». - Плохо 👎:
«Менеджер проекта сам определил DoR, не спросив команду, что важно для разработки».
2. Сделайте требования конкретными
Что нужно делать:
Избегайте общих фраз. Каждый критерий должен быть понятен и проверяем.
- Хорошо 👍:
«Для User Story: «Дизайн-макеты прикреплены к задаче, acceptance criteria написаны в формате Gherkin». - Плохо 👎:
«Для User Story: «Задача понятна и готова к разработке» .
3. Не перегружайте список
Что нужно делать:
Оптимальный размер DoR — 5–7 критериев.
- Хорошо 👍:
«Для Epic мы определили 3 ключевых пункта: цель согласована, есть первые User Story, сроки разработки». - Плохо 👎:
«Для Task мы добавили 12 критериев, включая «дизайн-макеты», «документацию» и «кофе для разработчиков».
4. Обновляйте DoR на ретроспективах
Что нужно делать:
Регулярно анализируйте, какие критерии работают, а какие мешают.
- Хорошо 👍:
«На ретроспективе мы удалили пункт «прикрепление скриншотов к каждому Task», так как это тратило время». - Плохо 👎:
«DoR остался неизменным годами, несмотря на жалобы команды, что критерии устарели».
5. Сделайте DoR доступным
Что нужно делать:
Сохраняйте DoR в общедоступном пространстве.
- Хорошо 👍:
«DoR добавлен в раздел «Настройки» в Jira, и каждый участник может его редактировать». - Плохо 👎:
«DoR записан в личном блокноте Product Owner, и команда не знает, где его найти».
Заключение: DoR — ваша «страховка» от хаоса
DoR — это не формальность, а инструмент, который:
✅ Спасает время команды, фильтруя «сырые» задачи.
✅ Снижает стресс за счёт ясности требований.
✅ Улучшает качество продукта, так как задачи выполняются «с первого раза».
Как начать?
Начните с базовых критериев для Task, Bug и User Story, а затем расширьте DoR на другие типы задач (Epic, Feature, Design Task и т.д.). Помните: DoR должен быть живым — возвращайтесь к нему на ретроспективах и улучшайте!
А вот другие интересные статьи про Agile: