Definition of Ready (DoR) — это набор критериев, которым рекомендуется соответствовать при постановки задачи, прежде чем передавать ее разработчику для непосредственной реализации.
DoR помогает:
- избежать неясностей в требованиях;
- сократить доработки “на ходу”;
- ускорить реализацию и избежать паралича анализа;
- сделать планирование более точным и предсказуемым.
- повысить качество конечного результата.
Основные критерии DoR
1. Критерии приёмки (Acceptance Criteria)
Отвечают на вопрос: что должно быть реализовано, чтобы задача считалась завершённой.
- Проверяемые, конкретные, ориентированы на поведение: «Пользователь может сделать X», «Система не должна делать Y» .
- Включают позитивные и негативные сценарии.
- Формулируются в терминах поведения, описывают результат, а не реализацию .
- Помогают писать ручные и автотесты.
- Могут включать нефункциональные требования (производительность, масштабируемость и т.п.).
Примеры:
- Плохо: «Сделать удобно»
- Хорошо: «Пользователь может изменить пароль без перезагрузки страницы»
Рекомендуется использовать BDD (Given-When-Then) для описания поведения в сценариях.
Feature: Резервное копирование
Scenario: Только выбранные папки
Given: Есть папки A и B
When: Я исключаю B из резервного копирования
And: Запускаю процесс
Then: Сохраняется только папка A2. Бизнес-ценность
- Зачем нужна задача? Какую проблему решает? Кто конечный пользователь?
- Помогает расставлять приоритеты — особенно при ограниченных ресурсах.
- Желательно указать владельца бизнес-проблемы или того, кто может это уточнить.
- Учитываются обещания клиентам, сроки, интересы стейкхолдеров.
Совет: используйте шаблон User Story для выражения бизнес-контекста: «Как [роль], я хочу [действие], чтобы [цель]»
Пример: «Как контент-менеджер, я хочу видеть статус модерации, чтобы быстро проверять свежие материалы».
3. Спецификации (Specifications - технические характеристики)
Отвечают на вопрос: как должно работать или выглядеть поведение, описанное в критериях приёмки.
- Включают макеты, UX-потоки, API, правила отображения, граничные кейсы, схемы.
- Должны быть понятны и согласованы с командой.
- Идеи по реализации лучше записывать отдельно, в виде комментариев — чтобы не подменять ими спецификацию.
Важно понимать разницу между критериями приемки и спецификациями:
- Критерии приемки = что нужно реализовать
- Спецификации = как это должно выглядеть и работать
Пример:
Критерий приёмки:
- «Пользователь может изменить пароль без перезагрузки страницы.»
Спецификация:
- Figma-макет формы смены пароля
- POST
/user/passwordс{ old_password, new_password } - Сообщения валидации: «Пароль должен содержать минимум 8 символов»
- После смены пароля — принудительный выход из всех сессий
4. Оценка объёма работы
Оценка объема работ оценивает сложность задачи, а не точное время исполнение в часах и минутах.
- Оценивается обычно в story points или по виртуальной шкале от 1 до 10.
- Включает все этапы от DoR до DoD: разработку, тестирование, документацию.
- Это приближённая оценка, не точная, при изменениях нужно переоценивать вместе с командой.
5. Для багов и исследовательских задач
Баги:
- Описание ожидаемого и фактического поведения
- Шаги воспроизведения
- Скриншоты, логи, ошибки
Оценка:
- Если баг понятен — дать оценку
- Если нет — использовать таймбокс: «Исследуем баг 2 дня. Если не решим — переоценим приоритет»
Совет: Один баг — один тикет. Связанные баги — связать тикеты.
6. Ограничения и условия
- Технические: «Работает только на PostgreSQL 12»
- Организационные: «Нельзя добавлять новые зависимости»
- Продуктовые: «Только для пользователей в Казахстане»
Совет: всё, что может повлиять на реализацию, должно быть зафиксировано заранее — особенно если разработчики или аналитики могут меняться.
Примерная структура шаблона задачи
- Описание
- Критичность
- Ожидаемое и фактическое поведение (для багов)
- Шаги для воспроизведения (для багов)
- Персоны / User Story
- Первичное предложение решения
- Макеты / дизайн
- Критерии приёмки
- Оценка работы
- План тестирования
- Контактные лица