Что такое Определение готовности

Определение готовности

(англ. definition of done, DoD) — это чёткий список критериев, которым должны соответствовать каждая задача, фича или инкремент продукта, чтобы команда считала их завершёнными

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

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

Пример использования термина

«Когда к нам пришёл новый разработчик, определение готовности стало его главным путеводителем по нашим стандартам качества. В первые дни он постоянно спрашивал: «Мне нужно писать unit-тесты для этой задачи?», «Кто должен проверить мою работу?». Теперь вместо этих бесконечных уточнений он просто открывает наш общий документ с критериями.

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

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

Что ещё нужно знать про Определение готовности

Почему важен

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

Сколько раз бывало, что задача вроде закрыта, но потом выясняется, что нет документации, не написаны тесты или не настроен мониторинг? Чёткие критерии готовности избавляют от таких сюрпризов.

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

Однако стоит быть аккуратными, поскольку у DoD есть ограничения:

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

Что входит в определение готовности

DoD обычно включает:

— Полное выполнение функционала задачи
— Пройденное тестирование (автоматизированные, ручные)
— Обновлённую документацию
— Проверку кода и принятие код-ревью
— Интеграцию с другими компонентами продукта
— Соответствие требованиям безопасности и производительности

Конкретный набор критериев зависит от проекта и команды, но все должны быть реализованы перед закрытием задачи. Вот так может выглядеть DoD для разработки, тестирования и производительности в проекте «Мобильное приложение доставки еды»:

Разработка:

Код написан и соответствует стандартам code style команды
Проведено код-ревью как минимум одним senior-разработчиком
Unit-тесты покрывают 80% критичной бизнес-логики
Интеграционные тесты пройдены успешно

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

Все сценарии проверены
Функциональность протестирована на iOS и Android
Проверена работа приложения при плохом интернет-соединении
UI корректно отображается на разных размерах экранов
Отсутствуют критические баги (блокирующие и серьёзные)

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

Время запуска приложения не превышает 2 секунд
Анимации работают плавно (60 FPS)
Приложение потребляет не более 150 МБ оперативной памяти

Как составлять и внедрять DoD

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

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

Внедряют определение готовности тоже постепенно. Сначала пробуют на одном-двух спринтах, смотрят, какие критерии работают, а какие создают лишнюю бюрократию. Затем корректируют и закрепляют окончательную версию.

❗ DoD — живой документ. Его регулярно пересматривают на ретроспективах. Если команда обнаруживает, что какие-то критерии постоянно игнорируют или, наоборот, не хватает важных пунктов, — вносят изменения