В трекере задача может быть в Done, а в жизни — ещё нет. Код написали, экран открывается, демо прошло спокойно. А потом выясняется: статус не сохраняется, ошибка непонятная, история операций не обновляется, а один важный сценарий никто не проверил.
Definition of Done нужен именно для таких ситуаций. Это договорённость команды о том, что должно быть сделано, проверено и зафиксировано, чтобы задачу можно было считать действительно готовой.
В Evercode Lab такие договорённости нужны не для отчётности, а для нормальной передачи задач между проджект-менеджером, разработчиками и QA. Часть условий фиксируют в описании задачи, чек-листе или критериях проверки: что должно работать, какие сценарии обязательны, какие данные нужно проверить и кто принимает результат.
Так DoD помогает команде не возвращаться к одним и тем же вопросам в конце работы. Когда задача подходит к проверке или релизу, все уже понимают, что значит «готово» именно для этой задачи.
| Если совсем коротко | Что это значит в работе |
| Definition of Done | Общие правила команды: что должно быть готово у задачи перед закрытием. |
| Задача в Done | Результат можно проверять, показывать или выпускать дальше. |
| Зачем нужен DoD | Команда заранее понимает, где проходит граница готовности. |
Что такое Definition of Done
Definition of Done, или DoD, — это список условий, по которым команда понимает: задача завершена. Не «почти готова», не «потом доправим», не «на моей машине работает», а действительно готова в рамках договорённостей команды.
В разных командах DoD может отличаться. Где-то в него входят тесты, ревью кода, проверка на тестовой среде и обновление документации. Где-то добавляют проверку аналитических событий, логи, тексты ошибок, проверку данных или демонстрацию результата заказчику.
Смысл DoD не в идеальном чек-листе на все случаи жизни. Смысл в том, чтобы команда одинаково понимала слово «готово».
Почему Done в трекере не всегда значит готово
У задачи может быть красивый статус Done, но внутри останется хвост: не проверили неуспешный сценарий, забыли сохранить данные, не обновили статус, не договорились, кто смотрит текст ошибки.
Чаще всего проблема не в том, что кто-то специально схалтурил. Просто у каждого в голове своё «готово».
- Разработчик может считать, что готово — это когда код написан и основной сценарий работает.
- QA-специалист может ждать список обязательных сценариев, но получить только общую постановку.
- Проджект-менеджер может думать, что очевидные статусы и ошибки команда предусмотрит сама.
- Бизнес может ждать работающий результат, а не набор технически закрытых подзадач.
Definition of Done снижает эту разницу. Он не заменяет живое обсуждение, но помогает не спорить каждый раз с нуля.
Если в задаче есть несколько сценариев и ограниченное время на проверку, важно заранее понять, что нельзя упростить без риска. Здесь близка тема приоритизации задач: команда решает, какие проверки и исправления влияют на результат сильнее всего.
Как выглядит Done на реальной продуктовой задаче
Возьмём задачу посложнее: выпустить виртуальную карту в личном кабинете, чтобы пользователь мог оплачивать покупки в блокчейне. На уровне бизнеса звучит понятно: «добавить виртуальную карту». Для команды это несколько слоёв продукта.
Чтобы такая задача стала Done, нужно пройтись по пользовательскому пути и технической логике: что человек видит, какие данные вводит, какие статусы получает, где может ошибиться и как система отвечает.
| Слой | Что должно быть готово | Что легко забыть |
| Frontend | Форма, кнопка, экран подтверждения, история операций, понятные ошибки. | Показать статус операции, а не просто «что-то пошло не так». |
| Backend | Проверка баланса, расчёт комиссии, статусы, интеграция с платёжным шлюзом или блокчейном. | Вернуть фронтенду понятный ответ для успешного и неуспешного сценария. |
| Database | ID карты, ID пользователя, статус, дата создания, история операций. | Проверить, что данные не только появились на экране, но и корректно записались. |
| QA | Основной путь, ошибки, краевые случаи, история, связка фронта, бэка и базы. | Не ограничиться одним успешным сценарием «карта выпущена». |
В таком примере DoD переводит разговор в конкретику: пользователь видит результат, логика отрабатывает, данные сохраняются, ошибки обработаны, критичные сценарии проверены.
Проджект-менеджеру здесь важно видеть задачу целиком: пользовательский путь, бизнес-логику, данные, зависимости и проверки. Ему не нужно знать код на уровне разработчика, но нужно понимать, какие части задачи должны быть готовы перед закрытием.
Если во время приёмки выясняется, что ожидания у участников разные, помогает не искать виноватого, а проговаривать конкретные расхождения. В этом смысле DoD хорошо связан с культурой обратной связи: команда обсуждает не человека, а результат и то, что нужно поправить.
Плохой DoD и хороший DoD: Коротко на примерах
Самая частая проблема с Definition of Done — он звучит правильно, но не помогает в работе. Ниже простой пример разницы.
| Плохой DoD | Почему не работает | Лучше так |
| Задача протестирована. | Непонятно, кто тестировал, где и какие сценарии смотрели. | Основной сценарий и критичные ошибки проверены на тестовой среде; блокирующих багов нет. |
| Код готов. | Это говорит только о разработке, но не о результате для пользователя. | Код прошёл ревью, развернут на тестовой среде, пользовательский сценарий можно пройти от начала до конца. |
| Данные сохраняются. | Неясно, какие данные и где это проверено. | Функции и работа с базой данных проверены: новые данные записываются и отображаются в истории операции. |
| Ошибки обработаны. | Фраза слишком общая: можно закрыть пункт и ничего не проверить. | Для неуспешного сценария пользователь видит понятное сообщение, а команда получает нужный статус или лог. |
Хороший DoD должен быть проверяемым. Если пункт нельзя подтвердить действием, тестом, логом, демо или другой понятной проверкой, он быстро превращается в красивую формулировку без пользы.
Что можно включить в Definition of Done
Не надо превращать DoD в простыню на 40 пунктов. Чем длиннее список, тем выше шанс, что его перестанут читать. Лучше начать с базовых вещей, которые действительно помогают команде не закрывать сырые задачи.
- Реализована функциональность, описанная в задаче и критериях приёмки.
- Основной пользовательский сценарий проверен на тестовой среде.
- Проверены функции и работа с базой данных, если задача меняет или сохраняет данные.
- Обработаны ошибки: для неуспешных сценариев есть понятные сообщения, статусы или логи.
- Проверены критичные сценарии, в том числе важные исключения.
- Код прошёл ревью, если в команде есть такая практика.
- Документация обновлена, если задача меняет поведение продукта, API, настройки или процесс работы.
DoD должен помогать работе, а не создавать видимость контроля. Если пункт не влияет на качество, поддержку или понимание результата, он быстро превратится в бюрократию.
DoD, Definition of Ready и acceptance criteria: как не смешать
Эти термины часто оказываются рядом, но отвечают на разные вопросы.
| Понятие | Вопрос | Пример |
| Definition of Ready | Можно ли брать задачу в работу? | Есть цель, контекст, зависимости, понятны вводные. |
| Acceptance criteria (критерии приёмки) | Что должна сделать конкретная задача? | Пользователь может выпустить карту, увидеть статус и историю операции. |
| Definition of Done | Когда задача считается завершённой? | Код готов, сценарии проверены, данные сохраняются, ошибки обработаны. |
В этой статье фокус именно на Definition of Done. Definition of Ready и acceptance criteria лучше разбирать отдельно: у них другой момент в жизни задачи и другая польза для команды.
Где DoD обычно ломается
| Ошибка | Что происходит | Как лучше |
| DoD слишком общий | Все согласны с фразой «задача должна быть проверена», но никто не понимает, что именно проверять. | Писать конкретнее: какие сценарии, данные, ошибки и статусы важны. |
| DoD живёт отдельно от команды | Список есть, но его вспоминают только на ретро или перед аудитом. | Возвращаться к нему при постановке и приёмке задач. |
| Проверяют только интерфейс | Экран выглядит готовым, но логика или данные работают неверно. | Смотреть на продукт слоями: интерфейс, логика, база, интеграции. |
| QA подключается слишком поздно | Критичные сценарии всплывают уже после разработки. | Обсуждать проверки до того, как задача почти готова. |
| Done становится формальностью | Задачу закрывают, потому что пора двигаться дальше. | Оставить в DoD только те пункты, за которые команда реально готова отвечать. |
Как внедрить Definition of Done без лишней бюрократии
Начинать лучше не с большого регламента, а с короткого разговора внутри команды. Что чаще всего доделывается после закрытия задачи? Где спорим о готовности? Какие ошибки повторяются?
- Соберите 5–7 пунктов, без которых задачу нельзя считать готовой.
- Проверьте эти пункты на ближайших рабочих задачах.
- Разделите общий DoD команды и критерии конкретной задачи.
- Не добавляйте пункт, если непонятно, кто и как его проверяет.
- Пересматривайте DoD, если команда, продукт или процесс изменились.
Хороший DoD не должен тормозить работу. Он должен экономить время: меньше возвратов, меньше «а я думал», меньше закрытых задач, которые через два дня снова открываются.
Что важно запомнить
Definition of Done — это не Agile-термин ради красоты. Это рабочая договорённость о том, когда задача правда готова.
Если коротко: задача готова не тогда, когда кто-то устал ей заниматься, и не тогда, когда код оказался в нужной ветке. Она готова, когда команда понимает результат, проверила важные сценарии и может спокойно показать работу дальше.
DoD не заменяет здравый смысл, проджект-менеджера, QA-специалиста или разработчика. Он помогает им договориться на одном языке.
Больше про карьеру, IT и жизнь в Evercode Lab — в нашем Telegram-канале. Публикуем полезные материалы, свежие вакансии, анонсы карьерных программ и новости компании.
FAQ
Definition of Done — что это?
Definition of Done — это список условий, по которым команда понимает, что задача действительно завершена: результат работает, важные сценарии проверены, данные сохраняются, ошибки обработаны.
DoD — это то же самое, что критерии приёмки?
Нет. Критерии приёмки описывают ожидания от конкретной задачи. Definition of Done задаёт общие правила готовности для задач команды.
Чем Definition of Done отличается от Definition of Ready?
Definition of Ready отвечает на вопрос, можно ли брать задачу в работу. Definition of Done отвечает на вопрос, можно ли считать задачу завершённой.
Кто отвечает за Definition of Done?
Вся команда. Проджект-менеджер помогает описать результат и зависимости, разработчики отвечают за реализацию, QA-специалист — за проверки и риски, а команда вместе договаривается, где проходит граница готовности.
Нужен ли DoD, если команда маленькая?
Да, просто он может быть короче. В маленькой команде особенно легко держать договорённости в голове, а потом спорить, почему задача закрыта, но результат ещё сырой.