Требования · База
Как описать Definition of Ready
Согласовать минимальные условия, при которых задача готова к разработке, дизайну или тестированию.
Кратко: за 2 минуты
Согласовать минимальные условия, при которых задача готова к разработке, дизайну или тестированию. На выходе: doR опубликован и доступен всей команде.
Когда применять
Пункт относится к этапу «Требования». Его задача — превратить рабочее действие в проверяемый результат. Он нужен до передачи результата команде, заказчику и владельцу продукта: иначе команда рискует делать DoR слишком формальным и длинным.
Что это дает
Definition of Ready снижает количество возвратов и простоев: команда не берет в работу задачи без контекста, критериев приемки, макетов, данных или понятной бизнес-цели.
Пошагово: как выполнить
- Опишите обязательные поля задачи: цель, пользователь, сценарий, ограничения, критерии приемки, макеты, зависимости.
- Согласуйте исключения: какие задачи можно брать без полного описания и кто принимает этот риск.
- Добавьте проверку DoR в процесс планирования спринта или этапа.
Критерии приемки
- DoR опубликован и доступен всей команде.
- Новые задачи проверяются по DoR до попадания в активную работу.
- Есть понятный порядок действий, если задача не готова.
Типичные ошибки
- Делать DoR слишком формальным и длинным.
- Требовать идеального описания там, где нужен discovery.
- Не использовать DoR при срочных задачах.
Инструменты
Пример
Плохой пример
Делать DoR слишком формальным и длинным.
Хороший пример
Учебный пример. Задача допускается к оценке при понятной цели, макете необходимых состояний и критериях приемки. Неизвестное ограничение API становится исследованием; команда не обещает реализацию на основе предположений.
Шаблон
Критерии входа в работу
Скачать рабочий лист этого урока
Выбрать рабочий шаблонРабочий артефакт
Реестр требований
Критерии входа в работу
Учебный пример. Задача допускается к оценке при понятной цели, макете необходимых состояний и критериях приемки. Неизвестное ограничение API становится исследованием; команда не обещает реализацию на основе предположений.
- User stories
- Acceptance criteria
- Приоритет
- Связанные макеты и API
Контроль качества
Backlog требований и критериев приемки
DoR опубликован и доступен всей команде.
После изменения целей, сроков, состава команды, рисков, бюджета и приоритетов продукта.
Решение, контекст, ответственного, срок, риски, зависимости и критерий успешного завершения.
Перед отметкой выполнено: DoR опубликован и доступен всей команде.
Как применять
Начинайте с цели и ограничения проекта. Затем уточните владельцев, зависимости, риски, критерии приемки и формат отчетности. Хороший пункт для менеджера делает работу прозрачной: кто что делает, зачем это нужно, когда результат готов и как команда увидит отклонение от плана.
Короткие ответы
Частые вопросы
Зачем выполнять пункт «Как описать Definition of Ready»?
Definition of Ready снижает количество возвратов и простоев: команда не берет в работу задачи без контекста, критериев приемки, макетов, данных или понятной бизнес-цели.
С чего начать выполнение?
Опишите обязательные поля задачи: цель, пользователь, сценарий, ограничения, критерии приемки, макеты, зависимости.
Как понять, что пункт выполнен?
DoR опубликован и доступен всей команде.
Какая ошибка чаще всего мешает результату?
Делать DoR слишком формальным и длинным.
Режим обучения
Тест по теме
Проверка понимания
Ответьте на вопросы по материалу и получите итоговый отчет: что понято хорошо, а что стоит перечитать.
Для углубленного изучения
Редакция Ariol · Версия 2 · Обновлено
Независимая экспертная проверка не заявлена.
Что обновлено
- — Обновлено: Название, Шаблон результата, Пример, Плохой пример, Заголовок поиска, Описание поиска, Поисковые фразы.
Материал предназначен для обучения. Адаптируйте рекомендации к внутренним регламентам компании и условиям проекта.
Предложить исправление через контакты Ariol