DoD открывают, когда команда и стейкхолдеры по-разному понимают слово «готово». Для одних задача закрыта после разработки, для других после теста, для третьих после выкладки, а для четвёртых после подтверждения результата. В таком контуре конфликт по качеству и приёмке почти неизбежен.
Что это за подход
Definition of Done полезен как рамка фактической завершённости работы. Для PM это способ убрать двусмысленность вокруг окончания задачи, инкремента или изменения.
Когда он нужен
- у разных ролей расходится понимание завершённости;
- спор по качеству возникает слишком поздно;
- важно связывать завершение с проверкой и выпуском;
- delivery-контур уже достаточно зрел, чтобы выдержать общую рамку done.
Когда он не нужен
- если команда слишком разнородна по типам работы и единый DoD искусственен;
- если рамка существует только как плакат на стене;
- если её используют как ширму вместо реальной проверки качества.
Что из него реально применимо для PM
- делать окончание работы проверяемым;
- уменьшать количество «почти готово»;
- увязывать done с тестом, релизом и документацией;
- поддерживать честный статус по степени готовности.
Какие артефакты, ритуалы и правила важны
- ограниченный и понятный список условий done;
- связь с типом работы и релизным контуром;
- явная договорённость между ролями;
- пересмотр при изменении требований к качеству.
Какие ошибки чаще всего делают при внедрении
- делают DoD слишком широким и абстрактным;
- смешивают done для задачи, релиза и продукта;
- не связывают его с фактической приёмкой и проверкой;
- продолжают использовать слово done в произвольных смыслах.
Чем можно заменить или упростить
- коротким done-checklist для конкретного типа работы;
- релизным чеклистом, если главный вопрос в выпуске;
- критериями приёмки, если важнее ожидания по конкретному результату.