Definition of Done (DoD)

16 сентября 2026 · ~12 мин чтения

agile scrum процесс менеджмент команда

Definition of Done (DoD)

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

История

Корни DoD — в Extreme Programming (XP, «экстремальное программирование»), методологии, которую в конце 1990-х собрал Кент Бек (Kent Beck) на проекте Chrysler Comprehensive Compensation System. XP-команды столкнулись с классической болезнью разработки: разработчик говорит «готово», а через неделю выясняется, что код не покрыт тестами, не задокументирован или ломается в интеграции с чужим модулем. У каждого в голове было своё «готово».

Явную формулировку идеи как отдельной практики связывают с обсуждениями в agile-сообществе начала 2000-х — в частности, с книгами и статьями Майка Кона (Mike Cohn), одного из отцов-основателей Scrum-школы оценки и планирования («Agile Estimating and Planning», 2005) и с Биллом Вейком (Bill Wake), который в те же годы формулировал похожий по духу чек-лист INVEST для пользовательских историй (это соседнее, но не то же самое понятие — INVEST проверяет, хороша ли формулировка задачи, DoD проверяет, хорош ли результат).

Официальный статус в Scrum термин получил, когда Кен Швабер (Ken Schwaber) и Джефф Сазерленд (Jeff Sutherland) — соавторы самого Scrum — включили его в Scrum Guide. По разным источникам, явный текст про «Increment must meet the Definition of Done» закрепился в редакциях документа примерно к 2011 году, хотя сама практика к тому моменту уже несколько лет использовалась командами явочным порядком. С тех пор Scrum Guide регулярно обновляется (последняя крупная редакция — 2020 год), и DoD в нём остаётся одним из трёх формальных «обязательств» (commitments), наравне с целью спринта и целью продукта.

Важно: DoD — не изобретение одного человека и не стандарт с фиксированной датой рождения, как, скажем, TCP/IP. Это выкристаллизовавшаяся практика, которую сообщество agile-практиков сформулировало коллективно, отвечая на одну и ту же боль в разных командах примерно в одно время. Если тебе где-то попадётся точная дата «первого письменного упоминания» — отнесись с осторожностью, единого источника здесь нет.

Сегодня DoD вышла далеко за пределы разработки ПО: её используют дизайн-команды, маркетологи, HR, продуктовые команды в найме — везде, где нужно закрыть спор «это уже готово или нет».

Что это такое

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

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

Главное, чем DoD отличается от похожих вещей:

DoD vs Acceptance Criteria (критерии приёмки). Критерии приёмки — это условия для конкретной задачи («кнопка должна менять цвет при наведении», «форма должна отклонять email без @»). DoD — это условия для любой задачи в принципе, независимо от её содержания («код покрыт тестами», «прошёл ревью»). Критерии приёмки пишутся заново для каждой истории, DoD — один на всю команду, меняется редко.

DoD vs Definition of Ready (DoR, «определение готовности к работе»). DoR — это чек-лист на входе в работу («задача описана, оценена, есть макет»), DoD — чек-лист на выходе из работы. Зеркальные понятия: одно защищает от того, что команда начнёт делать непонятно что, второе — от того, что команда бросит недоделанное.

DoD vs QA/тестирование. Тестирование — это один из возможных пунктов внутри DoD, а не синоним. DoD шире: он может включать документацию, деплой, юридическую проверку — всё, что нужно, чтобы результат можно было использовать без доследования.

Зачем это вообще нужно

DoD решает не техническую, а социальную проблему: у слова «готово» в голове каждого человека — свой набор подразумеваемых условий. Без явного списка команда тратит время не на работу, а на выяснение, что значит «готово», уже после того, как кто-то радостно об этом заявил.

Аналогии из жизни

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

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

Техосмотр автомобиля. Машину не выпускают на линию, пока не проверены тормоза, фары, ремни — весь список, а не «на глаз вроде едет нормально». Где ломается: техосмотр статичен и почти не меняется десятилетиями, а DoD команда пересматривает сама, иногда каждый спринт — и если делает это редко или формально, чек-лист устаревает и перестаёт ловить реальные проблемы.

Как это работает

Процесс обычно выглядит так:

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

Схематично:

Задача написана → [проверка по DoD] → Готово / Не готово
                          │
                   если не готово
                          │
                          ▼
                  возврат в работу

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

Где встречается в обычной жизни

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

Где встречается в IT и бизнесе

Разработка ПО — исходное и самое частое применение: код готов, когда пройдены тесты, ревью, деплой на стенд.
Продуктовый менеджмент — фича готова к релизу, когда пройдена аналитика, юридическая проверка, готовы тексты интерфейса.
Маркетинг — рекламная кампания «готова к запуску», когда согласован бюджет, готовы креативы, настроена аналитика (это прямо касается роли директора по развитию — DoD на запуск кампании защищает от ситуации «запустили, а потом выяснилось, что пиксель не стоит»).
Найм (HR) — вакансия «закрыта», когда оффер принят, документы подписаны, а не когда кандидат просто сказал «да» на словах.
DevOps / инфраструктура — деплой «готов», когда прошли не только тесты, но и мониторинг, алерты настроены, откат (rollback) протестирован.

Кто пользуется

Практика не привязана к конкретному продукту — это методологическая практика, а не инструмент, который продаёт компания. Используется повсеместно в компаниях, работающих по Scrum или Kanban: от небольших стартапов до Spotify, Google, Microsoft — везде, где команды организованы по agile-принципам. Формально закреплена в Scrum Guide (официальный документ Schwaber и Sutherland, поддерживается через сайт scrumguides.org), на который ссылаются сертифицирующие организации вроде Scrum.org и Scrum Alliance при обучении Scrum Master'ов.

Точных цифр «сколько команд использует DoD» никто не считает — это не измеримый по трафику продукт, а элемент методологии, но по косвенным опросам (State of Agile Report, ежегодное исследование adoption agile-практик) Scrum и его практики, включая DoD, использует, по разным оценкам, большинство команд, заявляющих о работе по agile — вероятно, больше половины.

Альтернативы и конкуренты

Acceptance Criteria без общего DoD. Плюс: гибче, подстраивается под каждую задачу отдельно. Минус: без общего фундамента команда каждый раз заново спорит про базовые вещи вроде «нужны ли тесты» — тратится время на пересогласование очевидного.

Definition of Ready (DoR). Плюс: ловит проблемы на входе, а не на выходе, экономит ещё больше времени. Минус: это не замена DoD, а дополнение — решает другую половину проблемы (что нужно, чтобы начать, а не чтобы закончить).

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

Definition of Done + автоматизированные гейты (CI/CD-пайплайны). По сути не альтернатива, а усиление DoD: часть пунктов чек-листа проверяется не человеком, а автоматически (тесты, линтеры, security-сканеры). Плюс: устраняет человеческий фактор и лень. Минус: не всё формализуется в автоматическую проверку (например, «код читаемый» или «логика бизнес-корректна» пока требует человека).

Когда НЕ стоит использовать

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

Главная ловушка

DoD легко превращается в театр: чекбоксы отмечены, а по факту пункт не выполнен («тесты написаны» — но они пустые заглушки; «ревью пройдено» — но ревьюер посмотрел по диагонали). Формальное соответствие DoD не гарантирует реального качества, если никто не проверяет содержательность самих пунктов.

Связанные понятия

Acceptance Criteria (критерии приёмки) — условия готовности для конкретной задачи, в отличие от общих для всей команды условий DoD.
Definition of Ready (DoR) — зеркальный чек-лист, определяющий, когда задачу можно начинать делать.
Scrum — методология управления разработкой, в рамках которой DoD получила официальный статус как один из трёх commitments.
CI/CD (continuous integration / continuous deployment) — автоматизированный конвейер, который может проверять часть пунктов DoD без участия человека.
Технический долг — накопленные недоделки, которые чаще всего и возникают, когда DoD не соблюдается или отсутствует.
Adversarial verification (состязательная проверка) — смежная практика, когда результат проверяет не сам исполнитель, а независимая сторона (в том числе отдельная модель) именно для того, чтобы не полагаться на самооценку «готово».

Литература и источники

Scrum Guide (Ken Schwaber, Jeff Sutherland) — официальный текст методологии, включая формальное определение Definition of Done как часть Increment. Актуальная редакция 2020 года, доступна на scrumguides.org (официальный домен, стабильный URL).
Mike Cohn, «Agile Estimating and Planning» (2005, англ.) — одна из ранних книг, формализовавших практики оценки и готовности в agile-командах.
Kent Beck, «Extreme Programming Explained» (1999, англ., есть переиздание 2004 года) — корневая методология (XP), из культуры которой выросла идея явных критериев завершённости работы.
Статья в Википедии — искать «Definition of done» (англ. раздел заметно подробнее русского).
State of Agile Report — ежегодный отчёт об использовании agile-практик в индустрии, искать в Google по названию, публикуется digital.ai.
Scrum.org / Scrum Alliance — образовательные материалы для сертификации Scrum Master, обе организации подробно разбирают DoD в своих курсах.

Где встретилось у меня

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

Краткое резюме

Definition of Done — согласованный командой список бинарных условий, которым должен соответствовать результат работы, чтобы считаться завершённым.
Родилась в культуре Extreme Programming конца 1990-х, формальный статус получила в Scrum Guide (Schwaber, Sutherland) примерно к 2011 году.
Отличается от Acceptance Criteria (частные условия для одной задачи) и Definition of Ready (чек-лист на вход, а не на выход).
Главная польза — устраняет разное понимание слова «готово» у разных людей в команде и экономит время на переделки.
Главный риск — превращается в формальность, если пункты не проверяются содержательно, а просто отмечаются для галочки.