Что такое Definition of Ready?

Что такое Definition of Ready (DoR)?

Definition of Ready (DoR) — это четко сформулированный и согласованный всеми участниками команды (разработчиками, тестировщиками, аналитиками, продакт-менеджером) набор критериев, которым должна соответствовать пользовательская история (User Story) или задача, прежде чем она будет принята в спринт для реализации. Если говорить простыми словами, DoR — это "билет в спринт". Это гарантия того, что задача полностью понятна, оценена, проработана и готова к тому, чтобы разработчик или команда приступили к работе над ней, не тратя время на уточнения, сбор недостающей информации или ожидание зависимостей.

В Agile-практиках, особенно в Scrum, часто акцент ставится на Definition of Done (DoD) — критериях завершенности задачи. Однако Definition of Ready — это не менее важный инструмент, который работает на опережение. Он позволяет предотвратить хаос в бэклоге, уменьшить количество незавершенной работы (WIP) и значительно повысить предсказуемость и скорость выполнения спринта.

Ключевые цели и преимущества использования DoR

• Повышение эффективности планирования спринта: Задачи, соответствующие DoR, позволяют команде реалистичнее оценивать свой потенциал (velocity) и уверенно брать обязательства на спринт.
• Снижение количества блокеров и простоев: Когда все зависимости, дизайны и требования готовы заранее, разработка идет плавно, без пауз.
• Улучшение качества с самого начала: Четкие критерии приемки (Acceptance Criteria), прописанные до начала работы, служат ориентиром для разработки "в нужном направлении" и уменьшают количество дефектов, вызванных недопониманием.
• Усиление ответственности и прозрачности: Product Owner или бизнес-аналитик несут ответственность за то, чтобы задача достигла статуса "Ready", а команда разработки — за ее выполнение согласно DoD. Это создает здоровые рабочие границы.
• Экономия времени на уточнениях: Минимизирует ежедневные встречи-пятиминутки, где половина времени уходит на выяснение: "А что имелось в виду в этом требовании?".

Типичные критерии Definition of Ready (пример)

Конкретные критерии варьируются от команды к команды и проекта к проекту, но обычно включают следующее:

1. Ясная и ценностно-ориентированная формулировка: История следует шаблону: "Как [роль], я хочу [функциональность], чтобы [получаемая ценность/бизнес-выгода]".
2. Детальные и тестируемые критерии приемки (Acceptance Criteria): Четкий, однозначный список условий, при которых история считается выполненной. Часто оформляются в формате Given-When-Then (Gherkin).

   Пример (для функции "Вход пользователя"):
   Сценарий: Успешный вход с валидными данными
       Дано: Пользователь находится на странице входа
       И: Введен валидный email
       И: Введен валидный пароль
       Когда: Пользователь нажимает кнопку "Войти"
       Тогда: Происходит перенаправление в личный кабинет
       И: Отображается приветственное сообщение с именем пользователя
   

3. Существующие UI/UX макеты или прототипы: Для фронтенд-задач дизайн должен быть утвержден и доступен в Figma, Sketch и т.д.
4. Отсутствие внешних зависимостей: Задача не блокируется другими командами, сторонними API или ожиданием данных. Все необходимые доступы (аккаунты, API-ключи) предоставлены.
5. Проведена оценка усилий: Задача оценена командой разработки (в story points, идеальных днях или часах). Оценка реалистична и понятна.
6. Определены нефункциональные требования (NFR): Указаны требования к производительности, безопасности, доступности (accessibility), совместимости с браузерами.
7. Определены границы (Scope) и тестовые данные: Четко оговорено, что входит в задачу, а что — нет. Известно, какие данные нужны для тестирования.
8. Проработаны сценарии ошибок и пограничные случаи: Команда понимает, как система должна вести себя при вводе неверных данных, таймаутах, отсутствии сети.

Роль Project Manager / Scrum Master в процессе DoR

Как руководитель проекта, я не просто слежу за наличием документации. Моя роль — фасилитация и настройка процесса:

• Создание и культивирование: Помогаю команде выработать свои, "живые" критерии DoR на ретроспективах, а не навязывать шаблонные.
• Организация предварительного обсуждения: Провожу или инициирую регулярные встречи по Backlog Refinement или Grooming, где PO и команда вместе прорабатывают истории до состояния "Ready".
• Контроль на входе: Во время Sprint Planning выступаю как модератор, помогая команде отфильтровывать неготовые задачи. Задаю наводящие вопросы: "Все ли зависимости закрыты?", "Достаточно ли этих критериев приемки для начала работы?".
• Защита команды: Не позволяю загружать в спринт "сырые" задачи под давлением стейкхолдеров, аргументируя это рисками для скорости и качества.
• Визуализация: Часто мы вешаем список критериев DoR на стенд или в Confluence, чтобы они всегда были перед глазами.

Практический пример из опыта

В одном из проектов по разработке финтех-приложения мы столкнулись с постоянным срывом спринтов из-за "сырых" историй, связанных с интеграцией с банковским API. Команда тратила первые 2-3 дня спринта на выяснение деталей с внешними поставщиками. Мы ввели жесткий критерий DoR: "Для всех задач с внешней интеграцией должны быть: подписанное техническое задание от партнера, работающий sandbox-доступ и примеры успешных/неуспешных ответов API".

После этого:

• Product Owner стал заранее готовить этот пакет документов.
• На планировании спринта мы сразу отсеивали истории, где доступ к sandbox'у еще не был получен.
• Скорость команды (velocity) стабилизировалась, а предсказуемость возросла.

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