Как Definition of Ready может стать ловушкой для команды

Вольный перевод статьи Definition of Ready: What It Is and Why Its Dangerous, опубликованной на сайте mountaingoatsoftware.com

Многие Scrum-команды используют понятие Definition of Ready (Определение готовности), чтобы решить, какие элементы из product backlog (бэклога продукта) попадут в следующую итерацию.

Что такое Definition of Ready? Это набор критериев, которые команда придумала для себя, чтобы понять, готова ли user story (пользовательская история) или другой элемент бэклога к началу спринта. Обычно сюда входят требования к размеру задачи (она должна быть достаточно небольшой, чтобы уместиться в спринт), наличие acceptance criteria (критериев приемки) и другие условия.

Definition of Ready работает как строгий фейс-контроль на входе в итерацию. Представьте, что, как в ночной клуб пускают только тех, кто соответствует определенным правилам — молодые, стильные, подходяще одетые, — так и Definition of Ready пропускает в спринт только те истории, которые подходят по всем критериям.

При этом каждая команда или компания сама решает, кого «пускать». Нет единого Definition of Ready, который подходит абсолютно всем. Каждый формулирует свои правила, исходя из собственных задач и особенностей работы.

Как может выглядеть Definition of Ready на практике

Какие истории пройдут через этот «фейс-контроль»? Например, команда может включать в итерацию только те задачи, которые соответствуют следующим условиям:

• Для истории полностью определены приемочные критерии (acceptance criteria).
• История уже оценена и не превышает установленный размер. Если команда использует story points (оценочные баллы), она может выбрать максимальное значение, и в спринт попадут только истории такого размера или меньше. Обычно этот максимум составляет примерно половину производительности (velocity) команды.
• Дизайнер интерфейса подготовил макет или даже полностью разработал экраны, связанные с этой историей.
• Все внешние зависимости сняты — например, не осталось нерешенных вопросов к другим командам или сторонним поставщикам.

Так команда поддерживает прозрачность всего бэклога продукта и снижает риск неожиданных задач.

 Почему важно заранее определить готовность задач

Определение готовности помогает команде договориться о чётких условиях, которые история должна выполнить, прежде чем попадет в итерацию. Такой подход позволяет избежать проблем ещё до их появления.

Например, если команда решает брать в работу только те задачи, у которых количество story points не превышает заданного лимита, она защищает себя от ситуаций, когда на итерацию попадает слишком крупная история. Так команда не рискует застрять и не успеть завершить задачу вовремя.

Похожий принцип работает и с внешними зависимостями. Если не запускать в итерацию истории, в которых не проработаны зависимости от других команд или внешних факторов, команда снижает риск того, что эти зависимости сорвут сроки или повлияют на результат всей итерации.

Представьте: вашей команде иногда нужно, чтобы коллеги из другой команды подготовили часть работы. Вы сможете закончить свою задачу только если они успеют сделать свою часть заранее, чтобы у вас осталось время на интеграцию. 

Если эта команда часто не укладывается в сроки и подводит вас, разумно будет ввести правило: не брать в работу истории с открытыми зависимостями от неё.

Так определение готовности, которое требует закрыть все внешние зависимости до старта задачи, становится для вашей команды действительно полезным инструментом.

Когда правила мешают работать

Не все правила на входе в итерацию одинаково полезны. Например, ограничение по размеру истории обычно помогает команде работать быстрее и спокойнее. 

Но другие требования, которые часто включают в Definition of Ready, могут серьёзно навредить процессу.

Фактически, определение готовности превращается в фильтр: только те задачи, что проходят по всем правилам, попадают в работу.

Если среди этих правил появляется требование, чтобы какая-то часть работы была полностью завершена до старта, команда незаметно переходит к этапному процессу (stage-gate). А такой подход мешает гибкости и идёт вразрез с принципами Agile.

Чем опасен процесс stage-gate

Что такое stage-gate и почему это может стать проблемой? Такой подход разбивает работу на отдельные этапы, а переход к следующему шагу возможен только после прохождения контрольной точки — «шлюза».

В детстве у меня дома тоже был свой stage-gate: десерт я получал только после того, как доедал основное блюдо. Нельзя было совместить оба этапа.

В продуктовой разработке процесс часто делят на этапы проектирования и программирования. Пока не завершится проектирование, команда не приступает к разработке — «шлюз» не дает двигаться дальше. Это правило вводят, чтобы убедиться: предыдущий этап проработан до конца.

По сути, stage-gate — это частный случай классической Waterfall-модели разработки.

Если в Definition of Ready появляется требование «завершить всё до перехода к следующему шагу», команда фактически начинает работать по stage-gate процессу. Такой подход лишает гибкости и замедляет работу. По сути, этапно-шлюзовая модель — это просто современное название старой каскадной (waterfall) схемы.

Чтобы понять, что именно при этом теряется, давайте посмотрим, чем полезна параллельная работа.

Почему Agile-командам важно работать параллельно

Если одна задача не может стартовать, пока не закончена другая, команда лишается возможности работать с пересечением. Перекрытие разных видов деятельности — явный признак того, что команда использует подходы Agile. Настоящая гибкая команда всегда одновременно анализирует, немного проектирует, пишет код и тестирует. Если ввести жесткие контрольные этапы, эта гибкость исчезает.

Подобный подход часто называют concurrent engineering — параллельной разработкой, когда этапы перекрываются максимально тесно.

Гибкие команды стремятся к параллельной разработке (concurrent engineering), когда разные задачи — анализ, проектирование, программирование и тестирование — идут одновременно. Конечно, все активности не совпадут на 100%, и это не обязательно. Главное — добиться максимального пересечения, насколько это возможно.

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

Definition of ready: как не перегрузить процесс

Понимая это, большинству команд я не советую перегружать  Definition of Ready различными ограничениями и правилами. Чаще всего он только усложняет работу и незаметно возвращает команду к устаревшей каскадной модели.

Для Scrum-команд особенно важно, чтобы DoR не превращался в еще один бюрократический барьер.

Тем не менее иногда Definition of Ready действительно помогает решить конкретные проблемы — например, связанные с внешними зависимостями, — и тогда его имеет смысл применять.

Чтобы извлечь максимум пользы и при этом не потерять гибкость, стоит придерживаться двух принципов:

1. Не создавать правил, которые требуют полной (100 %) готовности, прежде чем пользовательская история попадет в итерацию, — за исключением случаев, когда есть зависимости от других команд или внешних подрядчиков. 

2. Использовать рекомендации и ориентиры вместо жёстких требований в своём Definition of Ready.

Как сделать правила готовности гибче

Пример правила, которое стоит изменить: «Перед началом работы по каждой истории должен быть готов подробный макет всех новых экранов».

Такое требование превращается в барьер, который мешает разным видам работ идти параллельно. Пока не появится финальный дизайн, остальные задачи останутся на паузе.

Лучше сформулировать это иначе: «Если история предполагает новые экраны, стоит подготовить предварительные макеты настолько, чтобы команда могла уточнить детали уже по ходу итерации».

В результате:  

• Жёсткое правило превращается в гибкую рекомендацию.
• Команда может пересекать разные этапы работы, ведь макеты готовы настолько, насколько это нужно сейчас, а не полностью.

Эти изменения добавляют немного субъективности в использование Definition of Ready. Проще говоря, мы по-прежнему хотим видеть на входе стильных, энергичных людей, но даем больше свободы решать, что именно значит «стильно одет».