Definition of Ready (DoR) — это входной фильтр: согласованный командой список условий, при которых задачу можно брать в работу. Понятна цель, есть критерии приёмки, нет блокеров, задача оценена и достаточно мелкая. Definition of Done (DoD) — выходной фильтр: список условий, при которых задача реально готова, а не «почти готова». Код написан, ревью пройдено, тесты зелёные, документация обновлена, выкачено. Оба — это общая планка качества на всю команду, а не личное мнение каждого. Они убивают главную болезнь — задачи в состоянии «осталось чуть-чуть» неделями. Аналитик особенно отвечает за DoR: чаще всего именно его работа определяет, готова ли задача войти.
Любимая фраза, которую я ненавижу: «ну там почти готово, осталось чуть-чуть». В одной команде у нас половина доски висела в «почти готово» по две недели. Разберёшься — и каждый под «готово» понимал своё: разработчик считал, что готово, когда код написан; тестировщик — когда проверено; продакт — когда выкачено в прод. Все правы, все спорят, задача стоит. Это не безобидно: те самые «почти готовые» задачи — это 40% незавершёнки (work in progress), которая заморожена и не приносит ничего, пока висит. На ретро мы посчитали честно: две фичи квартала уехали по срокам ровно из-за того, что «готово» у каждого значило своё. Полечилось это не мотивацией, а одним документом: командным определением того, что значит «готово». С этого дня «почти готово» перестало быть статусом.
Одна фраза, чтобы не путать
DoR отвечает на «можно ли начинать», DoD — на «можно ли останавливаться». А ещё короче: Definition of Done — это контракт против слова «почти». Пока пункт DoD не закрыт, «почти» не считается за «готово», как бы убедительно оно ни звучало.
DoR и DoD — это два таких документа на двух концах работы. Они звучат как бюрократия, но на деле это просто общий язык: команда один раз договаривается, что значит «можно брать» и «сделано», и перестаёт спорить об этом на каждой задаче.
Definition of Ready: можно ли брать в работу
DoR отвечает на вопрос «готова ли задача войти в спринт». Это входной фильтр перед разработкой: пока задача его не прошла, её не берут, как бы ни хотелось. Смысл — не пускать в работу сырое, потому что сырая задача либо встанет на полпути, либо будет сделана не то.
Типовой DoR — короткий список условий. Он у каждой команды свой, но костяк похож:
- Цель понятна. Ясно, зачем задача и какую проблему решает (то самое «зачем», без которого разработчик не примет ни одного решения на развилке).
- Есть критерии приёмки. Прописаны проверяемые условия, по которым поймём, что задача сделана. Без них непонятно, что вообще считать готовым.
- Нет блокеров. Не ждём чужого решения, доступа, ответа от смежной команды. Всё, что нужно для старта, на месте.
- Оценена. Команда посмотрела и понимает объём — а значит, внутри нет огромного неизвестного.
- Достаточно мелкая. Влезает в спринт. Если не влезает — её сначала декомпозируют.
DoR — это в первую очередь зона аналитика
Посмотрите на список: понятная цель, критерии приёмки, отсутствие неизвестного, нужный размер — это ровно то, за что отвечает аналитик. Если задача не проходит DoR, чаще всего недоделана именно аналитическая часть. Поэтому DoR — это, по сути, ваш личный чек-лист «отдал ли я задачу в работу в нормальном виде или подкинул разработчику головоломку». Критерии приёмки здесь — ключевой пункт, про них отдельно в записи user story и критерии приёмки.
Definition of Done: что значит «готово»
DoD отвечает на вопрос «можно ли сказать, что задача сделана». Это выходной фильтр: пока задача его не прошла, она не «готова», даже если код написан и «вроде работает». Смысл — чтобы «готово» значило одно и то же для всех, а не зависело от того, кого спросить.
Типовой DoD тоже список, и он шире, чем кажется новичку — «написал код» это только первый пункт:
- Код написан и соответствует критериям приёмки задачи.
- Код-ревью пройдено — другой разработчик посмотрел и согласовал.
- Тесты написаны и зелёные — автоматические проверки на месте и проходят.
- Протестировано — тестировщик прошёл по критериям приёмки, включая ошибки и граничные случаи (как это устроено — в записи про тестирование для аналитика).
- Документация обновлена — если поменялся контракт API или поведение, это отражено.
- Выкачено — изменения доехали до нужного окружения (стенд или прод).
Ключевая мысль: «готово» — это не «разработчик закончил печатать». Между «код написан» и «пользователь этим пользуется» лежит половина списка выше, и пропуск любого пункта — это и есть то самое «почти готово», которое потом всплывает багом в проде.
Список выше — это потолок джуна: код, ревью, тесты, выкатка. На грейде мидла в DoD появляются нефункциональные пункты — то, что не видно в счастливом пути, но ломает прод именно после релиза:
- Обратная совместимость не сломана. Если менялся контракт API, старые клиенты продолжают работать — иначе это ломающее изменение, и нужна версия или согласованный переход.
- Миграция БД обратима и протестирована. Накат проверен на копии данных, есть откат; необратимые шаги (удаление колонки) разнесены во времени по схеме expand/contract, а не сделаны одним коммитом.
- Нагрузочный профиль не деградировал. Новый код не добавил тяжёлый запрос на горячем пути; ключевые ручки укладываются в свой бюджет по времени ответа.
- Наблюдаемость заведена. На новую фичу есть логи, метрики и, где надо, алерт — иначе в инциденте вы слепы (подробнее — логи, метрики, трейсы).
- Фиче-флаг настроен, если фича катится постепенно: есть рубильник, чтобы выключить без релиза.
Эти пункты не висят на каждой задаче — они часть DoD более крупных уровней. И тут начинается разница, которую джуновские списки замалчивают: DoD у тикета, у спринта и у релиза — это не один и тот же чек-лист.
DoD бывает многоуровневым: история ≠ спринт ≠ релиз
«Выкачено в прод» для одного тикета и «релиз готов» — это разные планки. Частая путаница на грейде мидла: команда закрывает истории по DoD истории и думает, что инкремент готов, а на релизе всплывает то, что проверяется только целиком — обратная совместимость пачки изменений, прогон регресса, готовность отката. Поэтому зрелые команды держат DoD не одним списком, а лесенкой: чем крупнее единица поставки, тем выше планка.
| Пункт | DoD истории (тикет) | DoD спринта (инкремент) | DoD релиза |
|---|---|---|---|
| Код и ревью | Написан, ревью пройдено | Все истории спринта закрыты по своему DoD | Ветка релиза собрана, конфликтов нет |
| Тесты | Юнит/интеграционные зелёные | Прогнан регресс по затронутым областям | Полный регресс + дымовой тест на проде после выката |
| Совместимость | Контракт задачи не ломает существующий | Изменения спринта согласованы между собой | Обратная совместимость со старыми клиентами подтверждена |
| Данные | Миграция задачи обратима и протестирована | Миграции спринта применяются в нужном порядке | Накат и откат прогнаны на копии прод-данных |
| Наблюдаемость | Логи/метрики на фиче заведены | Алерты на новое поведение настроены | Дашборд релиза готов, дежурный предупреждён |
| Откат | — | Фиче-флаги на спорные фичи | План отката описан и проверен |
| Документация | Изменения контракта/поведения отражены | Релиз-ноут по инкременту черновиком | Чейнджлог опубликован, причастные оповещены |
Видно, как растёт планка: то, что для тикета звучит как «протестировано», на релизе превращается в «прогнан полный регресс и есть план отката». Не нужно тащить весь правый столбец в каждый тикет — это и убьёт поток. Нужно понимать, что галочка «готово» на тикете не равна галочке «готово» на релизе, и держать для каждого уровня свой список.
Чем DoR отличается от DoD
Их легко перепутать по названию, но это два разных шлагбаума на разных концах работы. Сведём в таблицу.
| Definition of Ready | Definition of Done | |
|---|---|---|
| Когда применяется | До старта работы (вход) | После работы (выход) |
| Отвечает на вопрос | Можно ли это брать? | Это действительно сделано? |
| Что проверяет | Готовность требований к разработке | Готовность результата к выпуску |
| Главный ответственный | Аналитик (постановка задачи) | Команда целиком |
| Что ловит | Сырые, недодуманные задачи | Задачи в состоянии «почти готово» |
Простая мнемоника: DoR — это про то, что задача готова войти, DoD — про то, что результат готов выйти. Вход и выход одного и того же конвейера.
Кто за что отвечает
Оба определения — командные: их пишут и согласовывают вместе, иначе планка снова станет личным мнением каждого. Но акценты разные.
За DoR в первую очередь отвечает аналитик, потому что готовность задачи к работе — это в основном готовность требований: цель, критерии приёмки, отсутствие неизвестного, нужный размер. Если в работу регулярно уходит сырое — это сигнал, что аналитик пропускает свой шлагбаум.
За DoD отвечает вся команда, потому что «готово» собирается из вкладов всех ролей: код от разработчика, проверка от тестировщика, ревью от другого разработчика, выкатка от девопса. Аналитик здесь не главный, но участвует — например, его критерии приёмки и есть та линейка, по которой тестировщик меряет «протестировано».
Чек-лист, который не соблюдают, хуже, чем его отсутствие
Самая частая ошибка — написать красивый DoR/DoD, повесить на стену и забыть. Тогда он только раздражает: формально есть, фактически игнорируется. Определение работает, только если команда реально не берёт задачу без DoR и реально не закрывает без DoD. Лучше короткий список из трёх пунктов, который соблюдают, чем идеальный из пятнадцати, который обходят. Начните с малого и дополняйте, когда поймаете грабли, на которые наступили.
Зачем это вообще нужно
Без общих определений каждый меряет своей линейкой, и из этого растут три беды. Первая — вечное «почти готово»: задача висит, потому что для одного она сделана, для другого нет. Вторая — работа в корзину: разработчик взял сырую задачу, сделал, а оказалось не то — потому что цель была непонятна на входе. Третья — баги в проде из пропущенных шагов: «забыли протестировать ошибки», «забыли обновить документацию» — ровно те пункты, что должны были быть в DoD.
DoR и DoD лечат всё три одним приёмом — делают планку явной и общей. Это дешёвый инструмент: пара списков, согласованных один раз, экономят команде десятки споров «а это готово или нет».
Откуда это взялось
Оба понятия выросли из Scrum-сообщества. Definition of Done старше и важнее — идея «общего понимания, что значит готово» обсуждалась scrum-практиками ещё в 2000-х, а в официальное руководство по Scrum DoD вошёл позже как обязательный артефакт. Definition of Ready появился как зеркальное дополнение в конце 2000-х — начале 2010-х: команды заметили, что мало договориться про выход, надо договориться и про вход, иначе в спринт сыплется сырьё. Любопытно, что DoR в официальном Scrum Guide так и не закрепили — его считают полезной практикой, но не обязательной, в отличие от DoD. Поэтому в разных командах DoR выглядит очень по-разному, а кое-где его осознанно не вводят, чтобы не превращать вход в бюрократический барьер.
Как это спрашивают на собесе
«Чем DoR отличается от критериев приёмки?» — проверяют, не путаете ли вы целое и часть: DoR — это готовность задачи к работе в целом (цель ясна, нет блокеров, размер влезает в спринт), а критерии приёмки — лишь один из его пунктов, описывающий, как поймём, что сделано. Сказать «это одно и то же» — провал. «Кейс: команда ввела жёсткий DoR — и скорость упала. Почему?» — ждут, что вы назовёте trade-off прямо: DoR превратился в водопадный gate, в него стали требовать всю проработку заранее, аналитик пишет мини-ТЗ вместо диалога, и поток встал на входе. Сильный ответ добавит, как чинить: оставить в DoR минимум, остальное уточнять в работе, и смотреть на lead time. «За какой из двух отвечает аналитик?» — за DoR в первую очередь (это в основном готовность требований), за DoD — вся команда, аналитик в нём держит критерии приёмки как линейку для «протестировано».
Частые вопросы
Что такое Definition of Ready?
Definition of Ready (DoR) — это согласованный командой список условий, при которых задачу можно брать в работу: понятна цель, есть критерии приёмки, нет блокеров, задача оценена и достаточно мелкая, чтобы влезть в спринт. Это входной фильтр перед разработкой — пока задача его не прошла, её не берут. За DoR в первую очередь отвечает аналитик, потому что готовность задачи — это в основном готовность требований.
Что такое Definition of Done?
Definition of Done (DoD) — это согласованный командой список условий, при которых задача считается действительно готовой, а не «почти готовой»: код написан и прошёл ревью, тесты написаны и зелёные, задача протестирована по критериям приёмки, документация обновлена, изменения выкачены. Это выходной фильтр, и отвечает за него вся команда, потому что «готово» собирается из вкладов всех ролей.
Чем Definition of Ready отличается от Definition of Done?
DoR — это вход: проверка, что задачу можно брать в работу (требования готовы, цель ясна, есть критерии приёмки). DoD — это выход: проверка, что результат готов к выпуску (код, ревью, тесты, документация, выкатка). Мнемоника: DoR — задача готова войти, DoD — результат готов выйти. За DoR в основном отвечает аналитик, за DoD — вся команда.