Команда готовит спринт, но история содержит ценность без ясных границ и её нельзя оценить. Какой механизм должен остановить её попадание в планирование?
Такой механизм — Definition of Ready (DoR), то есть согласованный критерий готовности user story к планированию или разработке. История не должна попадать в спринт, пока не выполнены минимальные условия: понятна пользовательская ценность, определены границы поведения, выявлены ключевые зависимости и сформулированы проверяемые критерии приёмки.
DoR появился как командная практика в гибкой разработке, чтобы уменьшить количество историй, которые начинают обсуждать или реализовывать слишком рано. В Scrum это не обязательный артефакт и не формальное требование Scrum Guide, а локальное соглашение команды.
Исходная проблема заключалась в том, что слово «готово» разные участники понимали по-разному. Аналитик мог считать историю достаточно понятной, разработчик — недостаточно конкретной, а тестировщик — непроверяемой.
История с неясными границами создаёт ложную готовность: её можно включить в план, но нельзя надёжно оценить объём и проверить результат. В ходе спринта появляются новые трактовки, уточнения и зависимости, из-за чего растут переделки и нарушаются прогнозы.
DoR не должен превращаться в требование заранее описать абсолютно все детали. Если критерии слишком строгие, команда будет тратить много времени на анализ задач, которые ещё могут измениться, и потеряет гибкость.
Команда заранее определяет минимальный набор признаков готовности. Обычно он включает:
Проверка DoR проводится до планирования или до начала реализации — в зависимости от процесса команды. Если критерии не выполнены, историю не «проталкивают» в работу, а возвращают на уточнение, декомпозицию или исследование.
Важно отличать DoR от критериев приёмки. Критерии приёмки описывают, при каком поведении конкретная история считается принятой. DoR отвечает на другой вопрос: достаточно ли история подготовлена, чтобы команда могла осмысленно взять её в работу.
DoR также не гарантирует успешное выполнение. Он снижает риск неопределённости на старте, но не устраняет технические сбои, изменения приоритетов или новые сведения, обнаруженные во время реализации.
Практический компромисс — делать DoR коротким и проверяемым. Например, пункт «все заинтересованные лица согласны» слишком расплывчат; лучше указать, что определён владелец требования, спорные правила зафиксированы, а открытые вопросы либо закрыты, либо явно приняты как риск.
В бэклоге была история: «Как оператор, я хочу обрабатывать возвраты, чтобы быстрее решать обращения клиентов». Команда не могла оценить её, потому что не были определены виды возврата, правила частичного возврата и поведение при уже выплаченной компенсации.
Рассматривались три варианта. Можно было сразу начать разработку и уточнять детали по ходу работы, но это повышало риск переделок. Можно было полностью описать весь процесс заранее, однако такой подход задерживал обратную связь и требовал проработки ещё не приоритетных сценариев. Третий вариант — применить DoR и разделить историю на минимальные вертикальные срезы.
Команда выбрала третий вариант: зафиксировала основной сценарий полного возврата, критерии приёмки, исключения, зависимость от платёжного провайдера и отдельно вынесла частичный возврат как следующую историю. После этого задачу удалось оценить, а результат — проверить на демонстрации без подмены незакрытых вопросов догадками.
1. Может ли DoR запретить изменение требований после начала спринта?
Нет. DoR проверяет готовность на момент включения истории в работу, но не замораживает требования навсегда. Если обнаружилось новое важное обстоятельство, команда должна оценить влияние изменения на объём, критерии приёмки, сроки и связанные истории.
DoR не заменяет управление изменениями. Его задача — не блокировать адаптацию, а сделать исходное состояние задачи достаточно понятным для принятия осознанного решения.
2. Должна ли история быть полностью технически спроектирована, чтобы пройти DoR?
Нет. Для готовности обычно достаточно понимать пользовательское поведение, границы, критерии приёмки и существенные зависимости. Полное техническое решение заранее может преждевременно ограничить варианты реализации и создать лишнюю работу.
При этом неизвестность, способная существенно повлиять на оценку или выполнимость, должна быть либо исследована заранее, либо оформлена отдельной исследовательской задачей. Скрывать такой риск за формально заполненной историей нельзя.
3. Кто отвечает за прохождение истории через DoR?
Это не обязанность одного аналитика. Аналитик помогает уточнить потребность и критерии, владелец продукта подтверждает ценность и приоритет, разработчики выявляют технические зависимости, а тестировщик проверяет проверяемость поведения.
Конкретные роли зависят от процесса, но критерии должны быть общекомандным соглашением. Если только один участник объявляет историю готовой, DoR превращается в административную отметку и хуже защищает команду от разных трактовок.