Definition of Done и Definition of Ready

Назначение: общий контракт качества команды; устранение споров «мы закончили — нет, не закончили».

Аудитория: команда разработки, PO, SM.

Статус: устоявшийся (Scrum Guide 2017/2020; SAFe).

Не путать с: Acceptance Criteria (критерии конкретной user story — частный случай DoD), Quality Gates (в CI/CD — техническое подмножество DoD).

Общее #

Definition of Done (DoD, «определение готовности») — формальное, разделяемое всей командой описание состояния «работа завершена»: полный список условий, при которых элемент бэклога считается сделанным. Definition of Ready (DoR, «определение готовности к старту») — симметричный контракт для начала работы: список условий, при которых элемент бэклога достаточно проработан, чтобы команда могла взять его в спринт без остановок на уточнение.

Пара DoD/DoR решает центральную коммуникативную проблему любой совместной работы — несовпадение скрытых критериев завершённости. Пока «сделано» не определено явно, каждый вкладывает в слово своё: для разработчика «код написан и работает на моей машине», для тестировщика «протестировано», для PO «можно показывать пользователю». Спор «мы закончили — нет, не закончили» — не конфликт людей, а отсутствие контракта. DoD делает скрытые ожидания явными и общими; в этом его главное назначение.

Место DoD в каноне фиксирует Scrum Guide. В редакции 2017 года: «члены команды имеют общее понимание того, что означает „Готово“, чтобы определять завершённость; хотя это существенно различается между командами, члены команды должны иметь общее понимание того, что значит, что работа над инкрементом завершена». Редакция 2020 года усилила формулировку: Definition of Done — это формальное описание качества инкремента; инкремент, не соответствующий DoD, не может быть предъявлен на Sprint Review и передан в использование. DoR в Scrum Guide не входит — это практика сообщества, популяризованная Майком Коном в книге Succeeding with Agile (2009) как «Definition of Ready для user story».

Связь DoD с артефактами Scrum идёт через Increment. Инкремент — сумма завершённых элементов бэклога за спринт; «завершённый» здесь означает именно «соответствующий DoD», а не «закрытый разработчиком». Именно DoD делает инкремент potentially shippable — пригодным к поставке: если Definition of Done строг (код проверен, протестирован, развёрнут, принят), то каждый инкремент можно выпустить; если слаб («код написан»), то «готовый» инкремент на самом деле требует недели доработки, и обещание частых поставок становится фикцией. Джефф Сазерленд (Scrum: The Art of Doing Twice the Work in Half the Time, 2014) описывает это как правило «done means done»: незавершённая работа — это не работа вовсе, а скрытый долг.

Принципиальная черта обоих контрактов: команда договаривается о критериях коллективно. DoD не спускается сверху менеджментом и не копируется из чужой презентации — он вырабатывается самой командой как рабочее соглашение. Причины две. Во-первых, исполним только тот критерий, за который исполнитель голосовал сам: навязанный DoD обходится так же, как отсутствующий. Во-вторых, DoD кодирует реальную инженерную дисциплину конкретной команды — её стек, инфраструктуру и уровень автоматизации, поэтому чужой DoD в принципе неприменим. Организация может задавать минимальную планку (см. раздел «Уровни DoD»), но наполнение внутри неё определяет команда.

DoD и DoR — два конца одного конвейера качества. DoR стоит на входе: он фильтрует «сырые» задачи, которые в противном случае застрянут в спринте, съедая capacity на уточнение; DoD стоит на выходе: он не выпускает работу, пока она не достигла согласованной планки. Вместе они устраняют оба классических разрыва Agile-команды — «взяли непонятное» и «выдали недоделанное».

Definition of Done (DoD) #

Что описывает DoD #

DoD применяется ко всем элементам бэклога одинаково — к любой user story, багу, задаче. В этом его отличие от критериев приёмки: DoD — общая рамка качества, одинаково действующая на каждую единицу работы; индивидуальные особенности истории покрывают её собственные acceptance criteria. Типовой DoD инженерной команды включает следующие пункты.

1. Код написан и self-reviewed. Автор провёл самообзор диффа перед передачей на ревью; код следует стандартам проекта.
2. Unit-тесты написаны и проходят. Новая логика покрыта автоматическими тестами; набор зелёный.
3. Code review пройдено. Изменения просмотрены и одобрены другими членами команды; замечания устранены.
4. Документация обновлена. Затронутые документы — README, API-описания, инструкции — приведены в соответствие с изменением.
5. Acceptance criteria выполнены. Все критерии приёмки самой истории проверены и соблюдаются.
6. Развёрнуто в стейджинге. Изменение собрано и установлено в среде, максимально похожей на продуктивную.
7. QA approved. Тестирование пройдено; результаты зафиксированы.
8. Нет critical/blocker багов. Критические дефекты отсутствуют; известные некритические — осознанно приняты и заведены.
9. PO accepted. Product Owner увидел результат и принял его против критериев приёмки.

Список — образцовый, не эталонный: конкретная команда сокращает или расширяет его под свою дисциплину. Команда без стейджинга убирает пункт 6, но тогда пункт 7 обязан ужесточиться; команда с сильным CI/CD может автоматизировать пункты 2–3 так, что они перестанут быть ручными шагами и станут фоновыми проверками.

Шаблон DoD #

Готовый чек-лист, который команда может взять за основу и адаптировать:

• Код написан и self-reviewed (дифф прочитан автором, замечания себе устранены).
• Unit-тесты написаны; набор тестов проходит локально и в CI.
• Code review пройдено, аппрув получен.
• Документация обновлена (README / API / runbook).
• Acceptance criteria истории выполнены и проверены.
• Изменение развёрнуто в стейджинге.
• QA: тестирование пройдено, отчёт зафиксирован.
• Critical/blocker баги отсутствуют (некритические — заведены и приоритизированы).
• PO принял результат против критериев приёмки.

Хороший практический тест пункта DoD — проверяемость за конечное время: каждый пункт должен отвечать на вопрос «как именно проверить?» словами «посмотреть туда-то». Пункт «качество приемлемо» — не пункт; пункт «нет critical/blocker дефектов в трекере» — пункт.

Что даёт DoD #

DoD выполняет четыре функции одновременно. Транзитивность завершённости: сумма элементов, соответствующих DoD, даёт инкремент, пригодный к поставке, — поэтому метрики (velocity) считают только полностью завершённые истории. Прозрачность для заказчика: PO и стейкхолдеры знают планку качества заранее, а не обнаруживают её на приёмке. Планируемость: команда, закрывающая истории по строгому DoD, имеет устойчивую velocity; команда с мягким DoD имеет «готовые» истории, кочующие в спринт за спринтом на доработку (в терминологии scope management — hope creep: «почти готово» выдаётся за готовое). Культурную планку: DoD легитимирует для инженера право не выпускать работу до тестирования — «так договорилась команда» сильнее личного «мне неудобно требовать».

Definition of Ready (DoR) #

Что описывает DoR #

DoR — чек-лист готовности элемента бэклога к попаданию в спринт. Его назначение — предотвращать попадание в спринт «сырых» задач: непонятных, неоценённых, зависимых от неизвестного. Задача, взятая в спринт без готовности, не ускоряет доставку — она конвертирует capacity планирования в capacity спринта: команда выясняет требования в то время, когда должна была их реализовывать, и предсказуемо не закрывает спринт. Типовой DoR включает следующие пункты.

1. User story сформулирована. История записана в пользовательском формате (User Voice: «как <роль>, я хочу <действие>, чтобы <ценность>»), а не как техническое поручение.
2. Acceptance criteria определены. Критерии приёмки сформулированы и проверяемы; команда понимает, как будет проверять результат.
3. Зависимости выявлены. Внешние зависимости — API, данные, другие команды, дизайн — определены и либо удовлетворены, либо заведены как риски.
4. Оценена командой. История оценена теми, кто будет её делать; оценка — самостоятельная проверка понимания.
5. Дизайн/макеты готовы. Если изменение затрагивает интерфейс, макеты существуют и приняты.
6. Производительность/capacity известна. Прогнозируемая трудоёмкость сопоставима с доступной capacity; заведомо непомещающаяся история дробится до готовности.
7. Связана с целью спринта. Понятно, на какую цель спринта работает история; история без связи не берётся.

DoR по построению короче и мягче DoD: он описывает минимальную пороговую готовность, а не полный контроль качества. Майк Кон (Mike Cohn, Succeeding with Agile, 2009) формулирует DoR как «doable»-критерий: команда должна иметь возможность оценить историю и спланировать её выполнение; всё сверх этого — предмет проработки бэклога, а не входного контроля.

Шаблон DoR #

• История сформулирована в User Voice формате (как <роль>, я хочу <действие>, чтобы <ценность>).
• Acceptance criteria записаны и проверяемы.
• Зависимости выявлены и учтены (API, данные, команды, дизайн).
• История оценена командой.
• Макеты/дизайн готовы и приняты (если применимы).
• Оценка сопоставлена с capacity команды.
• Связь с целью спринта ясна.

Границы DoR #

DoR — самая спорная из двух практик, и споры легитимны. Жёсткий DoR превращает проработку бэклога в водопадную фазу «согласования требований до начала работ» — против чего Agile и создавался; часть знания о задаче принципиально добывается только в работе. Поэтому зрелые команды используют DoR не как запрет («не готова — не берём»), а как индикатор риска: история без пунктов DoR может быть взята в спринт, но команда отдаёт себе отчёт, что берёт непонятное, и закладывает соотвествующий буфер. DoR — инструмент осознанного выбора, а не бюрократический фильтр.

DoD vs DoR vs Acceptance Criteria #

Три набора критериев часто смешивают. Различие проводится по двум осям: кому принадлежит набор (команде или конкретной истории) и какой вопрос он закрывает (готов ли к старту или завершён ли).

Соотношение между наборами вложенное: Acceptance Criteria — частный случай DoD. Каждый элемент бэклога = общая рамка (DoD) + индивидуальные критерии (AC). История завершена, когда выполнены и её собственные критерии приёмки, и общие критерии завершённости. Годжко Аджич (Specification by Example, 2011) показывает, что качественные AC — это спецификация поведения через примеры («при оплате картой МИР на 1000 ₽ пользователь видит чек с реквизитами»), и именно такие, конкретные формулировки дают команде проверяемость; DoD же покрывает то, что повторяется от истории к истории и потому не должно переписываться каждый раз.

Практическое следствие: нельзя «усилить» слабый DoD, переносим общие требования в AC каждой истории. Если «документация обновлена» нужна всегда — это пункт DoD; если «работает офлайн» нужен одной истории — это её AC. Перегруженные AC признак того, что команде не хватает DoD.

Как внедрить DoD/DoR #

Внедрение — процесс команды, а не решение менеджера. Работающая последовательность выглядит так.

1. Обсуждение на retrospective. Отправная точка — ретроспектива: команда разбирает, что на практике означало «сделано» в последних спринтах, где возникали споры «закончили — не закончили» и какие доработки сыпались после «готово». Из этого материала команда вырабатывает первоначальный список критериев. Ключевое требование — участие всех ролей: инженеров, QA, PO; контракт, написанный одной ролью, не будет исполняться остальными.
2. Фиксация в командном соглашении. Согласованный список фиксируется в рабочем соглашении команды (working agreement) — коротком документе, описывающем внутренние правила совместной работы. Фиксация отличает контракт от мнения: на соглашение можно ссылаться, его можно менять только явно.
3. Визуализация. DoD/DoR вывешиваются там, где работает команда: на стене у доски, в wiki, в шаблоне задачи в трекере. Механика простая: критерий, который не перед глазами, не применяется; визуализация дешевле любого контроля.
4. Использование в каждой story. DoD подключается к задачам механически: шаблон задачи в трекере содержит чек-лист DoD, история не переводится в «Done», пока чек-лист не пройден. DoR аналогично подключается к refinement: колонка «Ready» на доске или метка готовности означает «прошёл DoR». Первый месяц — самый важный: каждое исключение из DoD проговаривается явно, иначе список превращается в декорацию.
5. Ревизия на retrospective. DoD — живой контракт: он эволюционирует вместе с командой. Каждая ретроспектива проверяет его актуальность: слишком дорогой пункт ослабляется или автоматизируется, вскрывшаяся дыра (баг в проде, пропущенная документация) закрывается новым пунктом. DoD, не менявшийся год, почти наверняка мёртв.

Время внедрения — один-два спринта на выработку и ещё два-три на укоренение. Признак укоренения: члены команды сами говорят «это не done, стейджинг не прошёл», без участия Scrum Master.

Уровни DoD #

В одной команде DoD един и применяется ко всем задачам. В организации из нескольких команд картина многоуровневая.

Различение уровней снимает типичную путаницу: «история done, а фича не готова» — не противоречие. Каждая история прошла DoD команды, но фича целиком (включая интеграции между командами, миграции, обучение) добирает свои, более высокие критерии. Связь с product roadmap прямая: roadmap обещает фичи, а не истории, поэтому реалистичность roadmap определяется release/feature-level DoD — планка, при которой обещанное в дорожной карте считается поставленным.

В масштабном Agile уровни стыкуются явно. Дин Лефингуэлл (SAFe 5.0 Reference) фиксирует иерархию DoD: каждая команда определяет свой DoD, но инкременты программы (ART, Agile Release Train) требуют общего DoD уровня program: «фича не готова, пока не готовы все входящие команды и пройдены сквозные проверки». SAFe прямо предписывает зафиксировать DoD в соглашении между командами — решение проблемы «разные DoD у разных команд» (см. ниже).

Отдельно стоит технический срез иерархии: Definition of Done → Acceptance Criteria → Quality Gates. Если DoD — полный контракт завершённости, а AC — его индивидуальная часть, то Quality Gates — автоматизированное подмножество DoD, встроенное в CI/CD-конвейер: линтеры, сборка, автотесты, проверки безопасности, сканы уязвимостей. Гейты не заменяют DoD — они механически гарантируют его проверяемые пункты и освобождают команду от ручного контроля. Зрелость процесса видна по доле DoD, покрытой гейтами: чем больше контракт исполняется машиной, тем меньше он зависит от дисциплины и настроения.

Антипаттерны и типичные ошибки #

DoD «на бумаге». Список существует, утверждён, вывешен — и не применяется: задачи закрываются «по факту», чек-лист прокликивается задним числом. Причины обычно две: DoD навязан команде сверху и не воспринимается как свой, либо пункты невозможно проверить за разумное время. Диагностика простая: если переход задачи в «Done» не сопровождается реальной проверкой пунктов — контракт мёртв. Лечение — возврат к шагу 1 внедрения: команда пересобирает список сама.

Слишком слабый DoD. «Code complete = сделано»: код написан, компилируется, на этом всё. Такой DoD переносит всю стоимость качества (тестирование, интеграцию, документирование) за пределы «завершённой» работы: velocity выглядит высокой, инкремент — непригодным к поставке, а неполная работа накапливается как скрытый технический долг. Классический симптом: спринты закрываются на 100%, релиз всё равно сдвигается на недели доработок. Проверка на слабость: можно ли поставить последний инкремент в прод сегодня? Если нет — DoD не описывает «potentially shippable».

Слишком детальный DoD. Обратная крайность: 30–40 пунктов, включая «код красивый» и «команда довольна». Непроверяемые и субъективные пункты обесценивают весь контракт: раз часть пунктов невозможно объективно пройти, прохождение остальных перестаёт что-либо значить. Правило то же, что и для AC: пункт имеет право на существование, только если его проверка — конкретное действие за конечное время. Рабочий размер DoD — 5–10 пунктов.

DoR как бюрократия. DoR, применяемый как запрет, парализует бэклог: задачи месяцами «не готовы», refinement превращается в бесконечное уточнение, команда входит в спринт с пустыми руками — и берёт что попало, лишь бы заполнить. DoR обязан оставаться фильтром риска, а не входной панелью контроля качества требований. Здоровый паттерн: элементы бэклога, не прошедшие DoR, не запрещены к рассмотрению — они явно помечены как рискованные и берутся с запасом на доуточнение.

Разные DoD у разных команд. В многокомандной разработке одна фича режется между командами с несогласованными DoD. Результат: интеграция фичи всё время упирается в «недоделки соседей» — у команды A код отревьюен и протестирован, у команды B «просто работает», и суммарный инкремент не проходит ни одну планку. Это проблема масштабного Agile, и SAFe решает её фиксацией общего DoD уровня program: команды могут иметь более строгий собственный DoD, но не более мягкий, чем соглашение потока. Без такой фиксации разница DoD между командами превращается в постоянный источник конфликтов на интеграции.

Заключение #

Пять тезисов статьи:

• DoD — это командный контракт, не спускаемый сверху. Исполним только критерий, который команда выработала и приняла сама; организация задаёт минимальную планку, но не пишет командный DoD за неё.
• Главное назначение DoD — устранить «мы закончили — нет, не закончили». Пока «сделано» не определено явно, каждый вкладывает в слово своё; DoD делает скрытые критерии общими и проверяемыми.
• DoR предотвращает попадание в спринт «сырых» задач. Непонятная задача конвертирует capacity спринта в уточнение требований; DoR — фильтр риска на входе, парный DoD-фильтру качества на выходе.
• DoD ≠ Acceptance Criteria. DoD — общий контракт команды на всю работу; AC — индивидуальные критерии конкретной истории; завершённость истории = её AC + общий DoD.
• В масштабном Agile нужен общий DoD между командами. Разные DoD у команд одной фичи — постоянные конфликты интеграции; SAFe фиксирует общий DoD уровня потока, разрешая командам только ужесточать его.

Связанные статьи #

• Scrum — фреймворк, в каноне которого закреплён Definition of Done; связь DoD с инкрементом и potentially shippable result.
• Extreme Programming — инженерные практики (TDD, CI, рефакторинг), которыми наполняется DoD инженерной команды.
• Scope Creep — как DoD защищает от groping (расхождения понимания «сделано») и hope creep (сокрытия незавершённости).
• Метрики прогресса проекта — velocity и burn-down считаются только по историям, прошедшим DoD; слабый DoD искажает метрики.
• Ретроспектива — церемония, на которой DoD вырабатывается и ревизуется.
• Roadmap — реалистичность дорожной карты определяется release/feature-level DoD: что значит «обещанная фича поставлена».
• Приёмочное тестирование — механика проверки acceptance criteria: индивидуального слоя критериев каждой истории.