Что такое Definition of Done (DoD): критерии готовности задачи в Scrum

В статье разберём: что такое definition of done и зачем он нужен, как фича (функциональность продукта) движется через спринт, чем DoD отличается от Definition of Ready (DoR) и критериев приёмки (Acceptance Criteria) — и как составить работающий чек-лист с нуля.

Что такое Definition of Done: перевод и суть понятия

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

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

Ключевой нюанс: DoD — не абстрактный принцип «хорошего качества», а конкретные измеримые критерии. Не «хорошо протестировано», а «юнит-тесты покрывают ≥ 80% нового кода». Не «задокументировано», а «README обновлён и прошёл проверку коллеги».

Definition of Done в Scrum: место фичи в цикле разработки

В Scrum разработка организована спринтами — итерациями длиной от одной до четырёх недель. Команда работает над функциональностью, приносящей ценность пользователю, — такую функциональность называют фичей (от англ. feature). Definition of Done регулирует ключевой переход: фича уходит из состояния «в разработке» в состояние «готово».

Именно здесь чаще всего возникает конфликт: разработчик объявляет фичу завершённой, ссылаясь на DoD, а менеджер ждёт состояния «Potentially shippable» — полной готовности к поставке в продакшн. Чтобы понять разницу, рассмотрим полный жизненный цикл.

Жизненный цикл фичи: от идеи до релиза

Фича проходит пять состояний:

1. Idea — исходная идея попадает в бэклог продукта.
2. Ready — через рефайнмент (уточнение требований, refinement) задача обрастает критериями, достаточными для старта разработки. Здесь применяется Definition of Ready (DoR).
3. Done — разработка завершена, все критерии DoD выполнены.
4. Potentially shippable — фича вместе с закрытым Undone Work готова к поставке бизнесу.
5. Shipped — фича доставлена конечному пользователю.

Definition of Done — граница перехода из «в разработке» в «готово». DoR предшествует этому переходу: обеспечивает, что задача вошла в спринт с чёткими требованиями, прежде чем команда начнёт работу.

Формула: Potentially shippable = DoD + Undone Work

Undone Work — работа, необходимая для полноценной поставки фичи, но не входящая в DoD команды. Типичные примеры: подготовка маркетинговых материалов, деплой через внешнего DevOps-подрядчика, аудит безопасности сторонним специалистом по обеспечению качества (QA).

Формула: Potentially shippable = DoD + Undone Work.

Логика проста: чем сильнее DoD, тем меньше Undone Work остаётся за его пределами. Идеальная цель — Done ≈ Potentially shippable: команда поставляет фичу без значительных дополнительных усилий после закрытия спринта.

Слабый и сильный DoD: почему сила критериев имеет значение

«Силу» definition of done определяет количество и конкретность охваченных критериев. Слабый DoD с единственным пунктом «код написан» оставляет огромный Undone Work: тестирование, ревью, документирование, деплой — всё это ляжет на следующий спринт или соседнюю команду. Итог предсказуем: технический долг растёт, стейкхолдеры недовольны, релизы затягиваются.

Команды, которые хотят выстраивать процессы разработки системно, могут освоить управление ИТ-проектами по программе «Специалист по информационным системам: от организации до сопровождения ИТ-проектов» в рамках нацпроекта «Кадры» — бесплатно для участника. Подробнее об условиях — в каталоге программ обучения.

Пример чек-листа: как выглядит сильный DoD на практике

Ниже — пример сильного DoD из семи критериев, минимизирующих зазор между состояниями Done и Potentially shippable:

1. Код написан и соответствует принятым стандартам команды.
2. Юнит-тесты (модульные тесты) покрывают ≥ 80% нового кода.
3. Интеграционные тесты пройдены без критических ошибок.
4. Выполнено код-ревью как минимум одним другим разработчиком.
5. QA-тестирование завершено, задача соответствует критериям приёмки (Acceptance Criteria).
6. Документация обновлена: API-описание, README, внутренняя вики.
7. Код задеплоен на staging-среду (тестовый стенд) или в продакшн.

Сравните со слабым DoD: единственный критерий «код написан» фактически переносит всю оставшуюся работу в Undone Work. Семь пунктов — разумный минимум для предсказуемых релизов.

DoD vs DoR и Acceptance Criteria: как не запутаться в терминах

В Scrum три понятия регулярно путают: definition of done, Definition of Ready и критерии приёмки (Acceptance Criteria). Все три описывают условия «готовности», но разной природы и на разных этапах цикла.

Смешение ведёт к конкретным проблемам: команда берёт задачи в спринт без достаточных требований или закрывает задачи, не соответствующие ожиданиям заказчика. Разберём каждое понятие.

DoD vs Definition of Ready: сравнительная таблица

DoR («определение готовности к старту») — соглашение о том, что задача готова войти в спринт. DoD фиксирует, что задача готова покинуть разработку.

DoR → Development → DoD — последовательность, а не конкуренция. Оба соглашения дополняют друг друга: первое определяет, что задача готова начаться, второе — что она готова завершиться.

Чем Definition of Done отличается от Acceptance Criteria

DoD — универсальный стандарт для всех задач команды. Acceptance Criteria (критерии приёмки) — уникальные условия успеха конкретной пользовательской истории или задачи.

Пример: команда разрабатывает функцию поиска. Acceptance Criteria этой задачи: «результаты отображаются менее чем за 2 секунды», «поиск поддерживает кириллицу» — условия именно этой фичи. DoD команды — «код прошёл ревью», «юнит-тесты ≥ 80%», «задеплоено на staging» — применяется к любой задаче в бэклоге.

Задача должна соответствовать обоим: своим Acceptance Criteria и общему DoD. Документы не заменяют, а дополняют друг друга.

Преимущества и ограничения Definition of Done

DoD решает реальные проблемы, но, как любой инструмент, имеет границы применимости.

Преимущества:

• Единый уровень качества. Каждый элемент бэклога проходит одинаковый набор проверок — команда не делает послаблений для «срочных» задач.
• Снижение числа доработок. Критерии выявляют проблемы до закрытия задачи, а не после деплоя в продакшн.
• Прозрачность процессов. Стейкхолдеры видят чёткие условия и понимают, когда задача будет в состоянии Done, без субъективных трактовок.
• Улучшение коммуникации. Разработчик и менеджер говорят на одном языке: «задача закрыта» — конкретный набор выполненных условий.
• Точность прогнозирования. Предсказуемые критерии выхода упрощают оценку сроков спринта.

Ограничения:

• Перегруженность при избыточных критериях. DoD из 20+ пунктов тормозит команду и превращается в бюрократию.
• Несогласованность при нечётких формулировках. «Хорошо протестировано» — не критерий. Размытый DoD хуже его отсутствия.
• Трудности при изменении требований. Если требования меняются в середине спринта, часть критериев DoD теряет актуальность.
• Ограничение гибкости. В творческих или исследовательских задачах жёсткий чек-лист мешает экспериментам.
• Формализм. Команда рискует ставить галочки ради галочек, фокусируясь на процессе, а не на ценности для пользователя.

DoD — живой инструмент. Его эффективность зависит от баланса строгости критериев и готовности команды осмысленно их применять.

Как составить Definition of Done: пошаговый алгоритм

Составление DoD — командная работа, а не задача одного руководителя. Вот алгоритм из пяти шагов.

Шаг 1. Собрать рабочую группу. В состав входят разработчики, специалисты по тестированию (QA) и технический руководитель (Engineering Manager). Владелец продукта (Product Owner) участвует как представитель бизнеса, чьи ожидания DoD должен учесть.

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

Шаг 3. Сформулировать измеримые критерии. Запрещённые формулировки: «хорошо протестировано», «достаточно задокументировано». Правильные: «юнит-тесты покрывают ≥ 80% нового кода», «README обновлён и прошёл проверку коллеги».

Шаг 4. Задокументировать и открыть доступ. DoD фиксируется в таск-трекере, корпоративной вики или аналогичном инструменте — в месте, которое видит каждый участник команды. Документ должен быть общедоступным.

Шаг 5. Применять, обучать, расширять. Первая версия DoD содержит 5–7 критериев, не двадцать. Команда применяет его к каждой задаче, а на каждой ретроспективе анализирует: что работает, что стоит добавить или убрать.

Как внедрить DoD и не превратить его в формальность

Главное правило: DoD создаётся командой, а не спускается сверху. Когда разработчики сами формулировали критерии, они воспринимают их как собственный стандарт, а не как внешний контроль.

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

Роль ретроспективы в обновлении DoD

Ретроспектива — завершающая церемония каждого спринта в Scrum. На ней команда анализирует, что шло хорошо, что мешало и что можно улучшить — в том числе в самом definition of done.

Типичные вопросы на ретроспективе в части DoD: «Все ли критерии были реалистичны?», «Какой пункт регулярно вызывал трудности?», «Чего не хватает, чтобы задеплоенный код работал стабильно?»

Именно участие всей Scrum-команды делает DoD «живым документом»: он адаптируется под реалии проекта, а не превращается в устаревший артефакт в забытой вики.

Часто задаваемые вопросы

Что означает аббревиатура DoD?

DoD — сокращение от Definition of Done, что переводится как «определение готовности» или «критерии завершённости». Это соглашение Scrum-команды: фиксированный набор измеримых условий, которым должна соответствовать задача, чтобы считаться выполненной. Термин пришёл из Scrum, но применяется шире — в любых Agile-командах.

Кто создаёт DoD в Scrum?

DoD создаётся совместно всей Scrum-командой: разработчиками, специалистами по тестированию, скрам-мастером (Scrum Master). Технический руководитель, как правило, инициирует процесс. Владелец продукта участвует как стейкхолдер. Итоговый документ принадлежит команде коллективно — не одному менеджеру.

Как часто нужно пересматривать DoD?

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

Может ли у разных команд быть разный DoD?

Да. Definition of done зависит от специфики проекта, стека технологий и состава команды. У фронтенд-команды и DevOps-команды критерии готовности различаются. Главное — чтобы DoD был согласован внутри конкретной команды и одинаково применялся ко всем задачам.

Что такое Undone Work?

Undone Work — работа, необходимая для доведения фичи до состояния Potentially shippable, но не входящая в DoD команды. Например: маркетинговые материалы, деплой через внешнего подрядчика. Формула: Potentially shippable = DoD + Undone Work. Слабый DoD увеличивает Undone Work и накапливает технический долг.

Чем DoD отличается от Acceptance Criteria?

DoD — универсальный стандарт для всех задач команды (ревью, тесты, деплой). Acceptance Criteria — уникальные условия успеха конкретной задачи или пользовательской истории. Задача должна соответствовать обоим: своим критериям приёмки и общему DoD команды.

Что произойдёт, если в команде нет DoD?

Без definition of done понятие «готово» каждый трактует по-своему: разработчик — после написания кода, менеджер — после деплоя в продакшн. Итог: недопонимание, доработки, накопление технического долга и срывы сроков. Это одна из типичных причин конфликтов между бизнесом и разработкой.

Сколько критериев должно быть в DoD?

Оптимальный сильный DoD содержит 7–9 измеримых критериев. Слабый DoD с одним пунктом («код написан») оставляет огромный Undone Work. Избыточный DoD из 20+ пунктов тормозит команду. Рекомендация: начинать с 5–7 критериев и расширять на ретроспективах по мере зрелости команды.