Definition of Ready и Definition of Done: как критерии изменили правила игры в управлении задачами и проектами
Любая команда разработки сталкивается с двумя вечными вопросами: что значит «можно начинать» и что значит «сделано». Именно на этих границах зарождаются конфликты, проседает производительность и сгорают бюджеты. Когда задача поступает в работу слишком рано — с недописанным техническим заданием, противоречивыми требованиями, без необходимых данных — она становится очагом рисков. С другой стороны, когда результат разработки уходит в бесконечные круги согласования, уточнений и тестов — проект теряет темп, бизнес теряет терпение.
Решение появилось внутри Agile-подхода — в виде двух инструментов: Definition of Ready (DoR) и Definition of Done (DoD). Эти понятия сначала появились как практики для Scrum-команд, но сегодня стали универсальными рамками, помогающими навести порядок в любых проектах — от стартапов до крупных цифровых трансформаций.
Часть 1. Что такое Definition of Ready (DoR)
Суть Definition of Ready
Definition of Ready (DoR) — это набор критериев, которые задача должна удовлетворить, прежде чем её можно взять в разработку. Это своего рода фильтр качества входящего потока задач.
Проще говоря, если DoR не соблюден, задача не может быть реализована эффективно, потому что:
- неизвестен объем работ;
- нет необходимых входных данных;
- неясен бизнес-смысл;
- противоречия в ТЗ ещё не устранены;
- требования находятся в «подвешенном» состоянии.
Введение DoR — это способ дисциплинировать входной поток задач, особенно когда над требованиями работают несколько аналитиков, заказчиков, архитекторов и бизнес-пользователей.
Типичные критерии DoR
Хотя содержание DoR зависит от контекста проекта, в большинстве случаев он включает:
- У задачи есть сформулированная цель и бизнес-контекст.
- ТЗ утверждено или согласовано с бизнесом.
- Понятна ценность задачи для бизнеса (например, что улучшится после её реализации).
- Указаны входные данные, которые будут использоваться в разработке (например, API, файлы, базы).
- Имеются все макеты, схемы, шаблоны.
- Определены зависимости (если есть смежные задачи).
- Указаны тестовые сценарии или критерии приемки.
- Оценен объем работ и задача разбита на подзадачи (если необходимо).
- Назначен ответственный бизнес-заказчик.
Это не чек-лист от методолога — это страховка команды от неопределенности.
Технические аспекты
Системы, где можно реализовать DoR:
- Jira — создание кастомного состояния Ready, при переходе к которому проверяются флажки в карточке.
- Azure DevOps — можно использовать поля типа Ready to Start или настроить Work Item Rules.
- YouTrack, Trello, Asana — через чек-листы, статусы или интеграции с Templater/Automation.
Формат хранения DoR:
- Шаблоны задач с обязательными полями.
- Документ на Confluence с пояснениями и примерами.
- Встроенные правила перехода в workflow (например, без заполнения поля Acceptance Criteria задача не может попасть в sprint backlog).
Практический кейс: дисциплина в ТЗ
Проект: Внедрение витрин продаж для BI-платформы
Проблема: аналитики добавляют задачи в backlog сразу после встречи с бизнесом. Макетов нет, формулы расчётов KPI не прописаны, источники данных не проверены.
Решение: введён DoR. В карточку задачи добавлены обязательные поля: источник данных, список метрик, макет визуализации, ответственный от бизнеса. Теперь задача не может попасть в спринт, пока все поля не заполнены и не согласованы.
Результат: время на доработки в ходе реализации сократилось на 40%, количество спорных ситуаций при демонстрации — почти до нуля.
Часть 2. Что такое Definition of Done (DoD)
Суть Definition of Done
Definition of Done (DoD) — это набор критериев, описывающих, что значит «задача завершена». Иначе говоря, это граница завершённости, которую понимают одинаково все: разработчики, тестировщики, аналитики, бизнес.
DoD снимает классическую боль: когда разработка «сделала всё», а заказчик говорит — «а где описание? а где тест-кейс? а почему не работает у меня?»
Типичные критерии DoD
- Код написан, проверен и залит в нужную ветку.
- Пройдены все unit-тесты и интеграционные тесты.
- Продукт задокументирован (инструкция, описание API, список изменений).
- Подготовлены тестовые и демо-данные.
- Обновлены схемы, макеты, схемы процессов (если нужно).
- Отработаны ручные и автотесты QA.
- Подготовлена и проведена демо-презентация для бизнеса.
- Устранены все блокирующие баги.
- Описание включено в release notes или changelog.
Важно: DoD — это не личное мнение, а командный договор, зачастую формализованный.
Технические аспекты
Где фиксировать DoD:
- В шаблоне задачи (Issue template) — в виде чек-листа.
- В Confluence или Wiki проекта — отдельный документ, утверждённый командой.
- В Workflow задач (например, Jira) — нельзя перевести задачу в статус Done, пока не проставлены флажки Tested, Documented, Approved.
Автоматизация:
- Системы CI/CD (Jenkins, GitLab CI, Azure DevOps) — позволяют настроить автоматическую проверку по DoD.
- Интеграция с TestRail или Xray — автозапуск тестов перед завершением задачи.
- Notion или Google Sheets с чек-листами — для малых команд.
Практический кейс: борьба с бесконечными согласованиями
Проект: Миграция отчётов с устаревшей OLAP-системы в новую BI-среду
Проблема: каждый отчёт пересогласовывается по 3–4 раза. Бизнес говорит: «график не такой», «заголовки не те», «а вот в старом было по-другому».
Решение: внедрение DoD. Включили в критерии:
- макет отчёта с утверждёнными элементами;
- согласованный список метрик и расчётов;
- демо-встреча с записью;
- тестирование на реальных данных;
- сопроводительный документ для пользователей.
Результат: отчёты стали приниматься с первого раза, среднее число итераций упало с 4 до 1.2, уровень удовлетворённости бизнес-пользователей — +30%.
Часть 3. Взаимосвязь DoR и DoD
DoR и DoD — это зеркальные рамки, которые обрамляют жизненный цикл задачи.
|
Этап |
Без DoR/DoD |
С DoR и DoD |
|---|---|---|
|
Постановка задачи |
Неясно, что делать |
Все требования, макеты, цели — на входе |
|
Разработка |
Частые уточнения, переделки |
Чёткое понимание, что должно быть сделано |
|
Завершение |
«Почти готово», но не принято |
Заранее известные критерии приемки |
Главное: эти рамки помогают не просто «навести порядок», а выстроить предсказуемость: команда знает, чего ожидать, а бизнес знает, что получит.
Часть 4. Как внедрить DoR и DoD в команде
Шаги по внедрению Definition of Ready
- Проанализировать типовые ошибки постановки задач — что мешает начинать работу сразу?
- Собрать реальные примеры плохих и хороших задач.
- Сформировать базовый DoR — от 5 до 10 пунктов.
- Согласовать с командой — особенно с аналитиками и заказчиками.
- Интегрировать в workflow — через поля, чек-листы, шаблоны.
- Контролировать соблюдение — на планировании или grooming-сессиях.
- Регулярно пересматривать — DoR должен эволюционировать.
Шаги по внедрению Definition of Done
- Собрать типовые претензии к завершённым задачам.
- Обсудить с командой, что реально делать на каждом этапе.
- Создать DoD как чек-лист (технический и пользовательский уровень).
- Внедрить в pipeline — CI, тестирование, проверки.
- Формализовать в документации.
- Назначить ответственных за контроль DoD — например, тестировщика или тимлида.
- Регулярно улучшать — при появлении новых типов задач.
Часть 5. Ошибки и подводные камни
Типовые ошибки при внедрении DoR
- Слишком формальный подход — DoR превращается в бюрократию.
- Нереалистичные требования — невозможно собрать всё до старта.
- Отсутствие гибкости — не учитываются разные типы задач.
- Неучастие бизнеса — DoR разработан без учёта заказчиков.
Типовые ошибки при использовании DoD
- Скрытые ожидания — команда думает, что всё сделано, бизнес — что ещё нет.
- Нет автоматизации — всё проверяется вручную.
- Игнорирование документации — «сделано» только на уровне кода.
- Отсутствие прозрачности — DoD нигде не зафиксирован.
Definition of Ready и Definition of Done — не просто инструменты Agile. Это операционные рамки, без которых невозможна стабильная поставка ценности. Они позволяют избежать ключевых рисков: разработки «впустую», неготовности задач, бесконечных итераций при приёмке, пробелов в документации и тестировании.
Хороший DoR и DoD — это не догма. Это договор внутри команды и с бизнесом, это доверие, дисциплина и прозрачность. Внедрив эти критерии однажды, вы сэкономите месяцы правок и тонны нервов.
Если задача отвечает DoR — она будет реализована качественно.
Если результат соответствует DoD — он будет принят без лишних слов.
