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

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

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

DoD защищает от ситуации, когда задача формально закрыта, но результат ещё нельзя передать пользователям.

Представим, что в команду пришёл новый разработчик. В первые дни он уточняет, нужны ли unit-тесты, кто должен проверить код и требуется ли обновлять техническую документацию. Вместо повторяющихся вопросов сотрудник открывает общий DoD и сверяется с ним перед передачей задачи на проверку.

Однажды разработчик завершает изменение API, но забывает обновить документацию. На код-ревью пул-реквест возвращают на доработку. Сотрудник открывает чек-лист, видит пропущенный критерий и исправляет недочёт.

Через месяц он уже сам предлагает добавить в DoD проверку миграций базы данных. Так определение готовности превращается в рабочий инструмент, который помогает всей команде одинаково понимать требования к качеству.

DoD не позволяет закрывать задачи раньше времени и выдавать сырые изменения за готовый результат. Все участники заранее договариваются, что означает слово «готово».

Без такого соглашения проблема часто обнаруживается слишком поздно: задача уже закрыта, но тесты не написаны, документация устарела или изменение не проверено вместе с другими компонентами.

Единые критерии упрощают планирование. Команда понимает обязательные этапы, точнее оценивает объём работы и учитывает тестирование, проверку и документацию в рамках спринта.

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

Частые изменения тоже мешают. Если критерии обновляют каждую неделю без причины, команда перестаёт воспринимать документ как устойчивый стандарт. Корректировки стоит вносить только при реальной необходимости.

Жёсткие требования подходят не всем видам работы. Для исследовательских и творческих задач лучше использовать более гибкий набор критериев.

Состав DoD зависит от продукта и процессов команды. Обычно в него включают:

• функциональность полностью реализована;
• код соответствует принятым стандартам;
• изменение прошло код-ревью;
• автоматические и ручные проверки завершены;
• критические ошибки устранены;
• документация обновлена;
• функциональность интегрирована с другими компонентами;
• соблюдены требования к безопасности и производительности.

Все обязательные пункты выполняют до закрытия задачи. При этом команды могут дополнять общий список требованиями своего продукта.

Критерии можно разделить на три группы.

Разработка

• Код соответствует правилам оформления команды.
• Изменение проверил опытный разработчик.
• Unit-тестами покрыта критичная бизнес-логика.
• Интеграционные тесты завершились без ошибок.

Тестирование

• Проверены основные пользовательские сценарии.
• Функциональность протестирована на iOS и Android.
• Приложение проверено при нестабильном интернете.
• Интерфейс корректно работает на разных экранах.
• Отсутствуют блокирующие и серьёзные ошибки.

Производительность

• Приложение запускается не дольше двух секунд.
• Анимации работают плавно.
• Потребление оперативной памяти не превышает 150 МБ.

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

Определение готовности лучше создавать всей командой вместе с владельцем продукта. Разработчик понимает технические ограничения, тестировщик знает необходимые проверки, дизайнер обозначает требования к интерфейсу, а владелец продукта учитывает интересы бизнеса.

Начинать стоит с минимального набора условий, без которых работу нельзя считать завершённой. Первая версия может состоять из трёх или четырёх пунктов. По мере развития процессов список расширяют, но каждый новый критерий должен решать конкретную проблему.

Сначала DoD можно проверить в течение одного или двух спринтов. На ретроспективе команда обсуждает, какие пункты помогли, а какие оказались непонятными или создали лишние действия. После этого документ корректируют и закрепляют.

DoD должен быть доступен всем участникам. Полезно сверяться с ним перед передачей результата на ревью и окончательным закрытием задачи.

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

Хороший DoD остаётся коротким, понятным и проверяемым. Он учитывает особенности проекта, но не превращает разработку в формальное заполнение десятков пунктов.

Определение готовности — живой документ. Его пересматривают на ретроспективах, когда команда замечает повторяющиеся ошибки, новые риски или устаревшие требования. Ненужные критерии убирают, а важные пропущенные этапы добавляют в общий список.