Definition of Done

Слово «готово» в команде разработки означает примерно семь разных вещей — пока команда не договорится, что оно значит одну.

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

Зачем: проблема слова «готово»

Дейли. «Как задача по экспорту?» — «Готова». Через день на демо выясняется: код написан, но не отревьюен. Тестов нет. На стенд не выкачено, потому что «там миграцию надо накатить, я потом». Ошибки не обрабатываются — если файл большой, вкладка виснет. Документации нет, и никто, кроме автора, не знает, как это включить.

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

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

Из чего состоит DoD

Содержание зависит от команды и продукта, но каркас почти всегда один и тот же — путь кода от редактора до пользователя.

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

Пример DoD живой команды

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

DEFINITION OF DONE — команда «Заказы», версия от 14.03

Задача считается готовой, когда:

  КОД
  [ ] Все критерии приёмки из истории выполнены
  [ ] Линтер и проверка типов проходят без ошибок
  [ ] Нет TODO без заведённой рядом задачи в трекере

  РЕВЬЮ
  [ ] Pull request одобрен хотя бы одним разработчиком
  [ ] Все комментарии закрыты или переведены в отдельные задачи

  ТЕСТЫ
  [ ] Юнит-тесты на новую логику написаны
  [ ] Один e2e-сценарий на «счастливый путь» — если задача
      трогает пользовательский флоу
  [ ] Сборка CI зелёная на ветке

  ДОКУМЕНТАЦИЯ
  [ ] Обновлён README, если поменялся запуск или конфиг
  [ ] Новые переменные окружения добавлены в .env.example

  ДЕПЛОЙ
  [ ] Смёржено в main, автоматически выкачено на staging
  [ ] Миграции проверены: накатываются И откатываются
  [ ] Фича за feature flag, флаг по умолчанию выключен

  ПРОВЕРКА
  [ ] Владелец продукта посмотрел на staging и подтвердил

Чего в DoD НЕТ (сознательно):
  — покрытие тестами N процентов (гоняемся за цифрой, а не за смыслом)
  — выкат на прод (у нас релизы по расписанию, это не в руках команды)

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

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

Три механизма, ради которых всё затевалось.

1. Инкремент можно показывать

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

2. Скрытый долг перестаёт быть скрытым

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

DoD не даёт брать этот кредит. Задача либо сделана целиком, либо не сделана — тогда она честно не попадает в отчёт, и скорость команды с самого начала показывает правду. Правдивая скорость — единственное, на чём вообще можно строить планы.

3. Оценки становятся осмысленными

Когда все понимают «готово» одинаково, оценка в story points включает ревью, тесты и деплой. Без DoD один оценивает «только код», другой — «код плюс тесты», и оценки несопоставимы между собой. Тогда и планирование по скорости команды перестаёт работать.

DoD — живой документ

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

Частые ошибки

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

Итоги

• Definition of Done — единый для команды ответ на вопрос, что значит «готово»: код, ревью, тесты, документация, деплой на стенд, нефункциональные требования.
• «Готово на 90%» в Scrum равно «не готово»: показать пользователю нельзя, ценность нулевая.
• Без DoD команда незаметно берёт кредит техдолгом: скорость выглядит высокой ровно до момента, когда долг предъявляют к оплате.
• DoD один на все задачи и описывает качество; критерии приёмки — свои у каждой истории и описывают содержание.
• В DoD входит только то, что реально в силах команды. Невыполнимый пункт обесценивает весь список.
• DoD — живой документ: начинайте со слабого, но соблюдаемого, и усиливайте его на ретроспективах после каждой боли.
• DoR охраняет вход в спринт, DoD — выход из него. Вместе они и есть та рамка, внутри которой бэклог превращается в работающий продукт.