БЛОК 2. Работа с требованиями — 7. Definition of Done
🧭 Введение: почему без DoD команда путает “сделано” и “почти сделано”
В большинстве команд слово “готово” звучит много раз за день. Но без общего критерия каждый понимает это по-своему: для разработчика “код написан”, для QA “проверки не завершены”, для PO “пользовательская ценность ещё не подтверждена”. В итоге задача двигается по доске, но качество остаётся неясным.
Definition of Done (DoD) решает эту проблему как командный контракт: что именно должно быть выполнено, чтобы задача считалась реально завершённой.
💡 Совет:
Если в команде часто спорят “можно ли релизить”, почти всегда нужно улучшить DoD.
✅ Вывод:
DoD нужен, чтобы одинаково понимать “готово” и принимать решения по релизу на фактах.
⚠️ Проблема -> решение
Проблема без DoD выглядит так: задачи “закрывают”, но потом возвращают в работу, баги всплывают после релиза, QA и Dev спорят о качестве, а PO не понимает реальный статус готовности.
Решение — зафиксировать Definition of Done в виде прозрачного чек-листа для команды: качество кода, тестирование, дефекты, документация, продуктовая проверка и критерии релиза.
🟢 Если совсем просто:
DoD это общий список условий “готово”, который обязателен для всех.
🎯 Как понять, что этап прошёл успешно:
Любой участник команды может открыть DoD и объективно проверить статус задачи без догадок.
🛠️ Чем помогает и как работает
DoD снижает хаос перед релизом и убирает разночтения между ролями. Команда тратит меньше времени на споры и больше на реальное улучшение качества.
Как это работает:
- Шаг 1: Команда согласовывает единый DoD для типа задач.
- Шаг 2: По каждой задаче проверяются все пункты DoD до перевода в “Done”.
- Шаг 3: Если пункт не выполнен, задача не считается завершённой.
- Шаг 4: QA фиксирует результат проверок по DoD в понятном summary.
- Шаг 5: На ретро команда обновляет DoD по реальным инцидентам и боли.
✅ Вывод:
DoD превращает завершение задачи из субъективной оценки в проверяемый процесс.
🧩 Пошаговый алгоритм: как применять DoD в задаче
Чтобы junior QA не терялся, удобно идти по короткому алгоритму.
🟢 Если совсем просто:
Перед переводом задачи в Done пройдите фиксированные пункты и зафиксируйте результат.
🎯 Как понять, что этап прошёл успешно:
По каждому шагу есть подтверждение “выполнено / не выполнено”.
Алгоритм:
- Открыть актуальный DoD команды для типа задачи.
- Проверить, что acceptance criteria закрыты.
- Проверить тестовый результат: happy/negative/edge, ретест, регресс.
- Проверить, что нет открытых blocker/critical дефектов.
- Проверить артефакты: документация, логи изменений, нужные комментарии.
- Подготовить краткий QA-summary по DoD.
- Только после этого переводить задачу в “Done”.
✅ Вывод:
Алгоритм DoD убирает “формальное закрытие” и делает качество прозрачным.
✅ Мини-чеклист DoD для junior QA
Этот чеклист можно использовать прямо в тикете перед финальным статусом.
🟢 Если совсем просто:
Если хотя бы один критичный пункт не выполнен, задача ещё не Done.
🎯 Как понять, что этап прошёл успешно:
Все обязательные пункты чек-листа закрыты и подтверждены.
QA-checklist DoD:
- acceptance criteria полностью закрыты?
- выполнены planned тесты (happy/negative/edge)?
- ретест по фиксам завершён?
- ключевой регресс вокруг изменения пройден?
- blocker/critical багов не осталось?
- окружение и данные проверки зафиксированы?
- документы/описания/чек-листы обновлены?
- релизный риск оценен и понятен?
- команда согласна с финальным статусом?
- можно ли обосновать “Done” фактами?
✅ Вывод:
Чеклист DoD защищает команду от поспешного закрытия задач.
📚 Ключевые термины (простыми словами)
- Definition of Done (определение готовности) — критерии, после выполнения которых задача считается завершённой.
- Acceptance Criteria (критерии приёмки) — условия, описывающие ожидаемое поведение фичи.
- Blocker defect (блокирующий дефект) — проблема, из-за которой задача/релиз не может быть принят.
- Regression (регрессия) — проверка, что изменения не сломали существующий функционал.
- Retest (ретест) — повторная проверка конкретно исправленного дефекта.
- Release readiness (готовность к релизу) — состояние, при котором риск релиза приемлем.
- Definition of Ready (DoR, определение готовности к старту) — критерии, когда задачу можно брать в работу.
- Quality gate (порог качества) — формальное условие допуска к следующему этапу.
1. Что такое DoD и чем он отличается от “задача двигается по доске”
Частая ошибка junior: воспринимать Done как “задача дошла до правой колонки”. В реальности статус в борде без DoD не гарантирует качество.
🟢 Если совсем просто:
Done без DoD — это мнение, Done с DoD — это факт.
🎯 Как понять, что этап прошёл успешно:
Есть доказуемое соответствие всем пунктам DoD.
Назначение:
Сделать момент завершения задачи объективным и одинаковым для всех ролей.
Простыми словами:
DoD — это не “дополнительная бюрократия”, а единая договорённость команды о качестве.
Для новичка:
Если вы не можете показать, какими пунктами подтверждается “Done”, значит задача ещё не готова.
Аналогия:
Это как техосмотр автомобиля: нельзя сказать “машина готова”, пока не пройдены обязательные проверки.
Пример:
Done по DoD:- AC passed- planned tests passed- blocker/critical = 0- docs updated- QA summary completed🔎 Как это происходит на практике:
- Команда держит DoD в явном виде (Confluence/Jira template).
- QA и Dev сверяются с ним перед финальным статусом.
- Статус Done ставится только после прохождения критериев.
Характеристики:
- ✅ Уменьшает возврат задач из Done обратно.
- ✅ Делает релизные решения прозрачнее.
- ✅ Снижает конфликт “кто что должен был сделать”.
Когда использовать:
Всегда, независимо от размера задачи.
✅ Вывод:
DoD это базовая защита команды от ложной готовности.
2. DoD глазами QA: какие пункты критичны
Для QA DoD это рабочий инструмент завершения тестового цикла, а не формальная галочка. Важно, чтобы в DoD были не только “кодовые” пункты, но и проверяемые условия качества.
🟢 Если совсем просто:
QA по DoD отвечает на вопрос: “что доказывает, что это безопасно выпускать”.
🎯 Как понять, что этап прошёл успешно:
Пункты DoD позволяют QA дать чёткую релизную рекомендацию.
Назначение:
Закрепить минимально необходимый уровень тестового качества перед Done.
Простыми словами:
Если DoD не содержит тестовых критериев, он не защищает релиз.
Для новичка:
В DoD обязательно должны быть: AC, тесты, дефекты, регресс, итоговый QA-вывод.
Аналогия:
Это как чек-лист пилота перед взлётом: без него нельзя безопасно стартовать.
Пример:
QA-блок DoD:- AC verified- happy/negative/edge passed- retest completed- targeted regression passed- no open blocker/critical- QA summary posted🔎 Как это происходит на практике:
- QA ведёт отметки по DoD прямо в тикете.
- Если пункт не выполнен, QA указывает причину и блокирующий риск.
- Финальный статус ставится после закрытия пунктов.
Характеристики:
- ✅ Повышает качество закрытия задач.
- ✅ Ускоряет triage релизных рисков.
- ✅ Делает коммуникацию QA с командой предсказуемой.
Когда использовать:
На каждой задаче, которая влияет на пользователя или бизнес-метрики.
✅ Вывод:
DoD для QA — это формализованный минимум качества перед Done.
3. DoR vs DoD: не путать начало и конец
Junior QA часто путает Definition of Ready и Definition of Done. Это разные контрольные точки процесса: одна до старта работы, вторая перед завершением.
🟢 Если совсем просто:
DoR = можно начинать, DoD = можно завершать.
🎯 Как понять, что этап прошёл успешно:
Команда использует DoR и DoD как разные чек-листы в разные моменты.
Назначение:
Развести критерии входа в работу и критерии выхода из работы.
Простыми словами:
DoR защищает от старта “сырой” задачи, DoD защищает от раннего закрытия.
Для новичка:
Перед стартом смотрим DoR, перед финальным статусом — DoD.
Аналогия:
DoR — проверка билетов перед посадкой, DoD — проверка багажа и состояния самолёта перед вылетом.
Пример:
DoR:- AC сформулированы- макеты/контракты готовы DoD:- AC выполнены- тесты пройдены- критичных багов нет🔎 Как это происходит на практике:
- На planning команда использует DoR.
- На финале задачи команда проходит DoD.
- Несоблюдение любого из них приводит к возврату задачи.
Характеристики:
- ✅ Уменьшает старт “сырого” тикета.
- ✅ Уменьшает закрытие “недоделанного” тикета.
- ✅ Делает поток задач стабильнее.
Когда использовать:
В любом agile-процессе с командной разработкой.
✅ Вывод:
DoR и DoD работают в паре и закрывают разные риски процесса.
4. Как обновлять DoD без бюрократии
DoD не должен быть “вечным документом”. Если команда сталкивается с повторяющимися инцидентами, DoD нужно пересматривать и усиливать.
🟢 Если совсем просто:
Сломалось в релизе — добавьте защиту от этого в DoD.
🎯 Как понять, что этап прошёл успешно:
После обновления DoD аналогичные проблемы перестают повторяться.
Назначение:
Поддерживать DoD актуальным под реальные риски команды.
Простыми словами:
DoD должен учиться на ошибках, иначе он быстро теряет ценность.
Для новичка:
Если один и тот же тип дефекта повторяется, проверьте: есть ли пункт про это в DoD.
Аналогия:
Это как обновлять правила безопасности после инцидента, чтобы не наступать на ту же проблему.
Пример:
Инцидент: после фикса ломалась соседняя логикаОбновление DoD: добавить обязательный targeted regression для критичных фич🔎 Как это происходит на практике:
- На ретро команда разбирает релизные инциденты.
- Выбирает 1-2 изменения в DoD, которые реально предотвратят повторение.
- Фиксирует обновление и применяет его в следующих задачах.
Характеристики:
- ✅ DoD остаётся живым и полезным.
- ✅ Команда снижает повторяемость дефектов.
- ✅ Улучшается предсказуемость релизов.
Когда использовать:
После релизных инцидентов и заметных сбоев процесса.
✅ Вывод:
Сильный DoD — это evolving-чеклист, а не статичный документ.
5. DoD зависит от типа задачи (UI / API / Integration)
Важно не попасть в ловушку “один вечный DoD на всё”. Базовый каркас может быть общим, но акценты должны меняться под тип задачи. Тогда DoD реально работает, а не превращается в формальность.
🟢 Если совсем просто:
Для UI, API и integration задач критерии Done частично разные, потому что риски разные.
🎯 Как понять, что этап прошёл успешно:
Команда использует общий DoD-скелет, но адаптирует его под тип фичи.
Назначение:
Сделать DoD практичным и релевантным конкретному типу изменений.
Простыми словами:
Одинаковый DoD для всех задач либо перегружает команду, либо пропускает важные риски.
Для новичка:
Всегда спрашивайте: “Это UI, API или integration задача? Какие риски у этого типа самые критичные?”
Аналогия:
Это как аптечка: базовые средства общие, но набор для похода и для офиса отличается.
Пример:
UI-задача (акцент):- корректные состояния элементов- тексты ошибок и UX-флоу- кросс-браузер/адаптив (если требуется) API-задача (акцент):- контракт request/response- статусы и коды ошибок- валидации и backward compatibility Integration-задача (акцент):- таймауты/ретраи/fallback- идемпотентность и консистентность- обработка частичных сбоев внешних сервисов🔎 Как это происходит на практике:
- Команда держит базовый DoD.
- Для типа задачи добавляет 2-4 специальных пункта.
- QA проверяет сначала базовые, потом типовые акценты.
Характеристики:
- ✅ DoD остаётся коротким и полезным.
- ✅ Критичные риски по типу задачи не теряются.
- ✅ Меньше формальных “галочек ради галочек”.
Когда использовать:
Всегда при задачах разной природы (UI/API/integration).
✅ Вывод:
Сильный DoD — общий по каркасу, но адаптивный по акцентам.
📊 Сравнение: “Done по ощущению” vs “Done по DoD”
| Подход | Done по ощущению | Done по DoD |
|---|---|---|
| Основание решения | Субъективная оценка | Проверяемые критерии |
| Статус задачи | Часто возвращается назад | Реже переоткрывается |
| Конфликты ролей | Частые споры QA/Dev/PO | Меньше споров |
| Релизный риск | Непрозрачный | Явно оценён |
| Командная скорость | Нестабильная | Более предсказуемая |
✅ Must-Know для junior QA
- Definition of Done — это командный контракт качества.
- Без DoD статус Done не гарантирует реальную готовность.
- QA-пункты в DoD обязательны: AC, тесты, дефекты, регресс, summary.
- Open blocker/critical дефекты несовместимы с качественным Done.
- DoR и DoD — разные чек-листы для разных этапов.
- DoD нужно обновлять на основе инцидентов и боли команды.
- Итог по DoD должен быть подтверждён фактами, а не интуицией.
❌ Частые мифы
❌ Миф: DoD нужен только для enterprise-команд.
✅ Как правильно: DoD полезен любой команде, где больше одного участника и есть релизы.
📎 Почему это важно: даже маленькая команда страдает от разного понимания “готово”.
❌ Миф: Если код смержен, задача Done.
✅ Как правильно: merge — только часть пути, нужен полный проход по DoD.
📎 Почему это важно: без тестовых и продуктовых критериев риски остаются.
❌ Миф: DoD — это зона только QA.
✅ Как правильно: DoD общий для всей команды: Dev, QA, PO, Lead.
📎 Почему это важно: иначе ответственность за качество размазывается.
❌ Миф: DoD замедляет delivery.
✅ Как правильно: он убирает дорогие возвраты и ускоряет стабильный поток.
📎 Почему это важно: меньше переоткрытий задач и авральных фиксов.
❓ Часто спрашивают на собеседованиях
❓ Вопрос: Что такое Definition of Done простыми словами?
✅ Ответ: Это набор обязательных критериев, после которых задача действительно считается завершённой.
❓ Вопрос: Чем DoD отличается от acceptance criteria?
✅ Ответ: AC описывают поведение конкретной фичи, а DoD задаёт общий стандарт завершения задачи в команде.
❓ Вопрос: Как QA использует DoD в ежедневной работе?
✅ Ответ: QA сверяет задачу с DoD перед финальным статусом, фиксирует незакрытые пункты и релизные риски.
❓ Вопрос: Что важнее в DoD для релиза?
✅ Ответ: Закрытые AC, выполненные проверки, отсутствие blocker/critical дефектов и прозрачный QA-summary.
❓ Вопрос: Когда нужно менять DoD?
✅ Ответ: Когда повторяются инциденты или текущие пункты DoD не предотвращают реальные риски.
🚫 Типичные ошибки
Ошибка 1: Ставить Done до завершения тестового цикла
❌ Неправильно:
Закрывать задачу после merge без ретеста и регресса.
✅ Правильно:
Завершать задачу только после полного прохода пунктов DoD.
Почему:
Иначе команда получает “готово на бумаге”, но не в продукте.
Ошибка 2: Не фиксировать DoD-статус в тикете
❌ Неправильно:
Держать прогресс по DoD “в голове” или в чате.
✅ Правильно:
Отмечать пункты DoD прямо в задаче, чтобы все видели статус.
Почему:
Прозрачность снижает конфликты и ускоряет решение по релизу.
Ошибка 3: Игнорировать связь DoD с рисками
❌ Неправильно:
Проходить DoD формально, не связывая с реальными угрозами.
✅ Правильно:
Оценивать, какие пункты DoD закрывают конкретные риски пользователя/бизнеса.
Почему:
DoD должен защищать релиз, а не быть “ритуалом”.
Ошибка 4: Никогда не обновлять DoD
❌ Неправильно:
Использовать один и тот же DoD годами без изменений.
✅ Правильно:
Регулярно улучшать DoD после ретро и инцидентов.
Почему:
Процесс и риски меняются, DoD должен меняться вместе с ними.
🧩 Best Practices
- Храните DoD в одном месте, доступном всей команде.
- Делайте DoD коротким, но обязательным и проверяемым.
- Добавляйте в DoD только то, что реально снижает риск.
- Используйте отдельный мини-summary QA по DoD в каждом тикете.
- Связывайте инциденты из ретро с точечными улучшениями DoD.
- Для разных типов задач допускайте разные DoD-шаблоны (UI, API, integration).
🏁 Заключение
Definition of Done — это практический механизм командной дисциплины качества. Он убирает разночтения между ролями и помогает принимать релизные решения на фактах, а не на ощущениях.
Сильный junior QA не просто “проверяет функцию”, а умеет провести задачу через DoD и доказать, почему она действительно готова.