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