В любой продуктовой команде рано или поздно встает вопрос: что считать «готовым» и что можно брать в работу. Нечеткие критерии приводят к недопониманию, переработкам и потере темпа. В этой статье разберем, зачем нужны два простых, но мощных инструмента — Definition of Done и Definition of Ready — и как сделать их живыми инструментами, а не псевдодокументами на вики.
Коротко о назначении
Definition of Ready отвечает за готовность задачи к началу работы. Он формализует минимальные условия, при которых команда может с уверенностью браться за реализацию. Это уменьшает риски блокировок и лишних уточнений в середине спринта.
Definition of Done фиксирует ожидания к завершенной работе. Он гарантирует, что выполненная задача действительно приносит ценность и не требует тихой доработки после передачи. Такой список помогает держать качество на одном уровне и облегчает релизы.
Что обычно входит в Definition of Ready
В список готовности включают элементы, которые уменьшают неопределенности: четкое описание, критерии приема, дизайн, оценки и отсутствие внешних зависимостей. Это не должен быть громоздкий чек-лист, а работоспособный набор условий, проверяемых перед формированием бэклога спринта.
Например, если требуются данные от другой команды или доступы к среде — эти условия должны быть выполнены до начала. Иначе задача может встать на середине работы, что ломает план и демотивирует разработчиков.
Что обычно входит в Definition of Done
В определение «сделано» включают результаты, которые позволяют считать инкремент завершенным: код, покрытие тестами, код-ревью, обновленная документация, деплой в тестовую среду и подтверждение приемочных критериев. Это список требований, после выполнения которых продукт можно безопасно показать пользователю или доставить на прод.
Важно, чтобы пунктам DoD соответствовали реальные практики команды. Нерабочие или игнорируемые требования только ухудшают дисциплину и не дают эффекта.
Чем они отличаются и как взаимодействуют
Разница простая: один список говорит, когда можно начинать, другой — когда можно заканчивать. Вместе они закрывают начало и конец рабочего цикла, уменьшая промежуточные потери и улучшая предсказуемость.
В идеале обе декларации разрабатываются совместно — PO, разработчики, тестировщики и операторы должны согласовать критерии. Тогда на планировании команда понимает, что именно нужно подготовить и чего ожидать по завершению.
Примерная таблица чек-листов
| Definition of Ready | Definition of Done |
|---|---|
| Описание задачи с бизнес-ценностью и критериями приемки | Код соответствует стандартам, прошел статический анализ |
| Оценка истории командой (Story Points или время) | Юнит- и интеграционные тесты покрывают критичные сценарии |
| Зависимости решены или документированы | Код ревью выполнено, замечания обработаны |
| Нужные макеты и спецификации доступны | Функция задеплоена в тестовую среду |
| Доступы и окружения готовы | Критерии приемки подтверждены PO или тестировщиком |
Эта таблица — не догма. Она показывает, как лаконично можно отделить подготовку от результатов и что должно быть на контроле у каждой роли.
Как составлять рабочие критерии: шаги
Начните с малого. Вместо туманных формулировок сделайте несколько конкретных пунктов, которые легко проверить на планировании. Избегайте формулировок типа «готово, когда сделано», они ничего не дают.
Прогоните чек-листы через пару спринтов и корректируйте по факту. Если пункт весь спринт игнорируется — либо упростите его, либо устраните причину игнорирования. Важнее не идеальный список, а устойчивый процесс соблюдения.
Практические рекомендации
- Фиксируйте критерии в релевантном месте: сторипойнты — рядом с задачей, а DoD/DoR — в общей вики.
- Сделайте один ответственный за поддержание каждого пункта — кто-то должен проверять готовность перед планированием.
- Не перегружайте DoD техническими деталями, которые не добавляют ценности пользователю.
Эти простые правила помогают избежать бюрократии и сохранить фокус на результате.
Типичные ошибки и как их избежать
Частая ошибка — превращение Definition of Done и Definition of Ready в длинный документ, который никто не читает. Люди видят много пунктов и просто закрывают глаза на них при планировании. Лучше небольшая рабочая версия, чем идеальный, но мертвый регламент.
Еще одна проблема — отсутствие гибкости. Иногда команда оставляет строгие требования, не учитывая специфику задачи. Тогда мелкие задачи тормозятся из-за процессов, созданных для крупных историй. Настраивайте критерии по размеру и типу работ.
Личный опыт: как это сработало у меня
В одной из команд, где я работал, проекты постоянно сдвигались из-за незакрытых зависимостей. Мы ввели простой DoR из четырех пунктов: описание, макет, оценка и список известных зависимостей. Первая неделя показала, что почти половина историй приходила неготовыми.
Мы начали совместные мини-сессии с PO и дизайнерами перед планированием. Через три спринта количество блокировок снизилось вдвое, а командный моральный дух вырос — люди перестали тратить утро каждого дня на выяснение деталей.
С DoD был похожий путь: сначала таблица выглядела идеально на бумаге, но никто не выполнял пункт про документацию. Мы привязали выпуск заметок к завершению истории и сделали это частью Definition of Done — результат стал реальным, а документация стала появляться регулярно.
Как внедрять в разных контекстах
Для маленькой кросс-функциональной команды достаточно простого списка на одну страницу. Для крупных организаций стоит разбивать критерии по типам работ: баги, новые фичи, инженерные задачи. Так DoD и DoR не становятся тяжеловесным универсализмом.
В условиях DevOps полезно добавить в DoD требования к деплою и мониторингу. В классическом водопаде некоторые пункты могут отличаться, но идея одна — согласовать ожидания до и после работы.
Короткий набор правил для повседневной практики
- Держите списки короткими — максимум 6–8 пунктов.
- Пересматривайте критерии раз в квартал или после крупного ретро.
- Не используйте их как инструмент наказания — это инструмент договоренностей.
- Включайте в обсуждение всех, кто влияет на результат: PO, dev, тестировщиков, операторы.
Если команда понимает назначение и видит реальную пользу, соблюдение станет привычкой, а не рутиной.
Напоследок
Definition of Done и Definition of Ready — это простые опоры для коммуникации. Они не спасают от плохих решений, но делают договоренности явными и измеримыми. Начните с базовых пунктов, измеряйте эффект и корректируйте по мере роста команды и продукта.
Действуйте прагматично: не гонитесь за идеальным документом, стремитесь к ясности и удобству. Когда критерии действительно помогают уменьшить неопределенность и ускоряют поставку ценности, команда начинает работать мягче и увереннее.
