Определение готовности к работе (Definition of Ready, DoR) — это набор критериев, которые помогают команде определить, когда элемент бэклога (например, пользовательская история) достаточно проработан, чтобы его можно было взять в спринт. Если DoR — это ответ на вопрос «когда мы можем начать работу?», то определение готовности (Definition of Done) отвечает на вопрос «когда работа полностью завершена?». Чёткое DoR помогает командам избегать ситуаций, когда в спринт попадают размытые или неготовые задачи, что приводит к задержкам, переработкам и срыву обязательств.
Зачем нужно определение готовности к работе?
Без DoR команды часто начинают спринт с задачами, в которых не хватает требований, критериев приёмки или понимания зависимости. Это вызывает следующие проблемы:
- Разработчики вынуждены тратить время на уточнения вместо выполнения работы.
- В конце спринта оказывается, что задача выполнена лишь частично, потому что изначально не была готова.
- Возникает недопонимание между владельцем продукта и командой.
- Растёт технический долг из-за поспешных решений.
DoR решает эти проблемы, устанавливая чёткие и прозрачные требования к каждой задаче до того, как команда возьмёт на себя обязательство её выполнить. Это повышает предсказуемость спринта, улучшает фокус и снижает количество незавершённой работы.
Из чего состоит определение готовности?
Конкретные критерии DoR зависят от команды и контекста, но обычно включают следующие пункты:
- Сформулирована цель и контекст. Команда понимает, зачем нужна эта задача и какую цену она приносит пользователю или бизнесу.
- Описаны чёткие критерии приёмки (Acceptance Criteria). Это конкретные, измеримые условия, которые должны быть выполнены, чтобы считать задачу готовой к разработке.
- Задача независима и реалистична по размеру. История не имеет скрытых зависимостей от других задач и может быть выполнена в рамках одного спринта.
- Оценка сложности проведена. Команда имеет общее понимание объёма работы (стори-поинты или часы).
- Определены все зависимости. Если для выполнения задачи нужны данные от другой команды или доступ к специфическому окружению, это должно быть согласовано заранее.
- Дизайн и UX проработаны. Для интерфейсных задач необходимо наличие макетов, сценариев использования или любых других артефактов дизайна.
- Тестовые сценарии известны. Команда тестирования понимает, как проверять выполненную функцию, и у неё есть необходимые данные.
Пример определения готовности
Вот как может выглядеть DoR для среднестатистической команды разработки:
- Пользовательская история написана по шаблону «Как [роль], я хочу [функция], чтобы [выгода]».
- Критерии приёмки согласованы с владельцем продукта.
- Есть хотя бы одна предварительная оценка сложности (например, 3 или 5 стори-поинтов).
- Задача имеет приоритет на текущий спринт.
- Нет открытых вопросов к владельцу продукта, которые могут заблокировать работу.
- Все внешние зависимости (API, данные, доступы) уже предоставлены или запланированы на начало спринта.
Как внедрить определение готовности в команде
Создание DoR — это коллективный процесс. Рекомендуется следовать этим шагам:
- Обсудите на ретроспективе или встрече по улучшению процессов. Спросите команду: «С какими проблемами мы чаще всего сталкивались, когда брали задачи в спринт?». На основе ответов сформируйте список критериев.
- Начните с малого. Включите в DoR 3-5 самых важных пунктов. Не пытайтесь охватить всё сразу — это вызовет сопротивление.
- Зафиксируйте DoR на видном месте. Разместите его на доске команды, в вики или в общем документе, чтобы все могли к нему обращаться.
- Используйте DoR при уточнении бэклога (backlog refinement). Перед планированием спринта убедитесь, что задачи, которые попадают в спринт, соответствуют критериям DoR. Если нет — отправляйте их на доработку.
- Пересматривайте и адаптируйте. Каждые несколько ретроспектив проверяйте, нужны ли изменения в DoR. Команда растёт, и критерии могут меняться.
Распространённые ошибки при использовании DoR
- Слишком жёсткие или объёмные критерии. Если DoR требует идеальной проработки каждой мелочи, команда будет тратить массу времени на подготовку, теряя гибкость.
- Игнорирование DoR на практике. Когда команда договаривается о критериях, но в спешке берёт в спринт задачи, которые им не соответствуют, DoR теряет смысл.
- Путаница между DoR и Definition of Done. Нельзя смешивать критерии «готово к работе» и «готово к выпуску». DoR предшествует спринту, а DoD — завершает работу.
- DoR не учитывает тестирование. Если тестировщики не понимают, как проверять задачу, или у них нет окружения, они не смогут своевременно завершить работу.
Когда DoR особенно полезен?
- В командах, которые часто страдают от неполных требований и зависят от внешних команд.
- При работе с распределёнными командами или разными часовыми поясами, где уточнения занимают дни.
- В проектах с высокими требованиями к качеству и безопасностью (например, медицинское или финансовое ПО).
- На этапе, когда команда только осваивает Scrum и хочет повысить предсказуемость своих спринтов.
Итог
Определение готовности к работе — это простой, но очень эффективный инструмент, который помогает командам перестать гадать и начать уверенно планировать спринты. DoR не гарантирует, что в процессе не возникнет проблем, но оно значительно снижает риск попадания в спринт «сырых» задач, которые срывают обязательства и снижают доверие заинтересованных сторон. Лучшее DoR — это то, которое команда создала сама, использует на практике и регулярно улучшает.