Определение завершенности (Definition of Done) — это общий для команды набор критериев, который определяет, когда приращение продукта (или отдельная задача) считается полностью завершённым и готовым к выпуску. Простыми словами, это список условий, ответ на вопрос «откуда мы знаем, что задача действительно сделана?». Чёткое DoD — ключевой элемент гибких методологий, таких как Scrum и Канбан, позволяющий командам работать эффективнее, с меньшим количеством переделок и с фокусом на качестве.
Важно понимать, что DoD не придумывает один человек. Оно создаётся и согласовывается всей командой: разработчиками, тестировщиками, владельцем продукта и другими заинтересованными сторонами. Только в этом случае оно становится общим ориентиром, который все используют при проверке задач. Если ваша работа связана с передачей результатов другим командам, убедитесь, что ваше определение завершенности включает всё необходимое для их успеха — согласуйте критерии с командами из вашего потока создания ценности.
Примеры определения завершенности
Набор критериев DoD может сильно отличаться в зависимости от типа проекта и специфики команды. Вот несколько примеров.
- Для разработки мобильного приложения: все изображения сжаты; весь код минифицирован и сжат.
- Для разработки программного обеспечения: весь код полностью протестирован (модульные, интеграционные и сквозные тесты); приращение продукта развёрнуто на тестовом стенде и протестировано командой.
- Для типового проекта: все ошибки исправлены; вся документация к релизу написана и отредактирована.
Важность определения завершенности
Наличие у команды чёткого и разделяемого всеми DoD критически важно для поставки качественного продукта. Вот какие выгоды оно даёт.
- Повышение качества: проверка каждого приращения продукта на соответствие критериям DoD гарантирует, что команда постоянно держит цели по качеству в фокусе.
- Снижение рисков: DoD минимизирует риск переделок и связанных с ними задержек, так как до того, как задача будет помечена как «готовая», она пройдёт все проверки.
- Улучшение взаимодействия в команде: общее понимание критериев готовности позволяет команде эффективнее фокусироваться на требованиях заказчика и доставлять ценность в каждом спринте.
- Измерение прогресса: чёткое DoD позволяет трезво оценивать, сколько приращений продукта действительно соответствует критериям готовности, например, при расчёте скорости команды (velocity).
Определение завершенности (DoD) vs. определение готовности к работе (DoR)
Эти два понятия тесно связаны, но описывают разные точки контроля и находятся на разных уровнях.
- DoD — это высокоуровневые критерии, определяющие, когда приращение продукта в целом является завершённым. Оно применяется ко всем приращениям и используется в конце спринта для проверки качества.
- DoR — это низкоуровневые, специфические критерии, которые определяют, когда элемент бэклога готов к тому, чтобы команда начала над ним работу. DoR используется в начале спринта (например, во время уточнения бэклога).
Шаги по созданию определения завершенности
Процесс создания DoD обычно включает несколько этапов, которые могут варьироваться в зависимости от команды и проекта.
- Привлеките нужных людей. В создании DoD должны участвовать владелец продукта, Scrum-мастер, команда разработки, тестировщики, продакт-менеджеры и другие заинтересованные стороны. Каждый вносит свои знания в свою область и помогает сформировать комплексные критерии.
- Установите критерии. Это главная задача. Критерии должны быть конкретными, измеримыми, достижимыми, релевантными и ограниченными во времени. Спросите себя: достаточно ли критерий конкретен? (вместо «весь код протестирован» — «весь код протестирован с помощью модульных, интеграционных и сквозных тестов»); ориентирован ли критерий на клиента? (например, «вся документация написана и обновлена» помогает конечным пользователям).
- Создайте чек-лист. Для мелких задач можно создать упрощённый чек-лист на основе тех же принципов, что и полноценное DoD.
- Свяжите DoD с критериями приемки для пользовательских историй. Критерии приемки (Acceptance Criteria, AC) относятся к конкретной пользовательской истории или задаче и описывают условия, при которых она становится приемлемой для заказчика. В отличие от AC, DoD применяется ко всем приращениям продукта и отвечает за общее качество. AC — это лишь часть DoD, которая может и должна быть индивидуальной для каждой истории.
- Пересматривайте и обновляйте DoD. DoD — это живой документ. Каждый найденный баг — это сигнал о том, что определение завершенности, возможно, недостаточно чёткое. Используйте обзоры спринта, чтобы пересматривать DoD и вносить изменения. По мере развития проекта команда узнаёт новое о требованиях заказчика, и DoD должно адаптироваться.
Лучшие практики
- Определяйте критерии вместе с командой. DoD должно создаваться совместно, с участием всей команды, для общего понимания качества.
- Сохраняйте DoD на виду. Оно должно быть всегда доступно во время планирования спринта или оценки задач. Распечатайте его и повесьте на стену или храните в общем документе.
- Будьте практичными и реалистичными. DoD должно быть достижимо в рамках отведённого времени и доступных ресурсов, и, что важнее, — оно должно быть релевантно реальным потребностям клиентов.