Definition of Done: Наш стандарт качества
Definition of Done (DoD) — это формальный список критериев, которым должен соответствовать каждый элемент Бэклога, чтобы считаться завершенным. Это обязательство по качеству. Если задача не прошла хотя бы один пункт из DoD, её нельзя показывать на Обзоре Спринта и тем более выпускать к пользователям.
Право собственности и единый стандарт
Если в компании есть общий стандарт качества, команда обязана его соблюдать. Если его нет — Скрам-команда создает свой собственный. Как только DoD принят, он становится законом для всех. Все члены команды должны быть привержены этому стандарту: мы не снижаем планку ради скорости.
DOD — это ключевой инструмент Прозрачности для Трех Столпов Scrum. Он позволяет команде, Владельцу Продукта и заинтересованным сторонам точно знать, когда работа действительно завершена, а когда нет. Это устраняет любые споры о статусе элемента.
Что может входить в DoD (Пример)
Для каждого продукта критерии свои, но типичный список выглядит так:
- Код прошел проверку (Code Review).
- Написаны и пройдены автотесты.
- Дизайн соответствует макету.
- Обновлена техническая документация.
- Задача проверена на тестовом сервере.
Защита от технического долга
Соблюдение DoD — это главная страховка команды от накопления технического долга. Когда мы «срезаем углы» (например, забываем про тесты), чтобы успеть к дедлайну, мы берем кредит под огромный процент. Рано или поздно этот долг придется отдавать, исправляя горы багов. Четкий DoD гарантирует, что инкремент всегда стабилен и готов к работе.
| Ситуация | Роль DOD | Последствия при Отсутствии/Нарушении |
| Прозрачность Статуса | Обеспечивает единое понимание того, что работа действительно “Готова” к релизу. | Возникает спор о том, завершена ли работа, что нарушает Прозрачность и доверие. |
| Формирование Инкремента | Служит границей, отделяющей функционал, который может быть выпущен, от незавершенного. | Инкремент может содержать ошибки или быть непригодным к использованию. |
| Ретроспектива Спринта | Используется для Адаптации процесса: команда может улучшать DOD в каждом цикле. | Процесс улучшения качества застопорится, технический долг будет накапливаться. |
| Оценка Работы | Команда оценивает элементы Бэклога, учитывая объем работы, необходимый для соответствия DOD. | Планирование Спринта становится неточным, команда берет на себя слишком много или слишком мало работы. |
| Связь с Ценностями | Требует Приверженности и Смелости, чтобы не “срезать углы” и не выпускать некачественный продукт. | Усиливается давление на команду, чтобы обойти правила качества ради скорости. |
1. DOD и Технический Долг. В конечном счете, соблюдение Definition of Done — это главная защита Команды Разработки от накопления технического долга. Технический долг возникает, когда команда сознательно или неосознанно “срезает углы” (например, пропускает юнит-тестирование или ревью кода), чтобы выполнить задачу быстрее. Если элемент соответствует всем критериям DOD, он считается качественным и минимизирует риски будущих проблем.
2. DOD как Непрерывное Улучшение. Следовательно, DOD не является статичным документом; он должен постоянно улучшаться и адаптироваться. Разработчики должны регулярно инспектировать свой текущий DOD на Ретроспективе Спринта и, при необходимости, добавлять новые, более строгие критерии качества. Это гарантирует, что качество продукта будет только расти от Спринта к Спринту, что идеально соответствует принципам Адаптации в Scrum.
Эволюция качества
DoD — это не застывший документ. Команда регулярно инспектирует его на Ретроспективе. Со временем команда становится опытнее и может добавлять новые, более строгие критерии. Так качество продукта растет от спринта к спринту.
Резюме: Общий язык команды
DoD устраняет споры в духе «Я всё сделал, просто оно еще не работает». С этим списком статус задачи становится бинарным: либо она соответствует всем пунктам и она «Готова», либо нет.
Ключевой вывод: Definition of Done превращает субъективное мнение разработчика в объективный факт. Это фундамент доверия между командой и Владельцем Продукта. Когда PO видит задачу в колонке Done, он уверен — там нет сюрпризов и код не развалится завтра.
Часто задаваемые вопросы (FAQ)
Если в организации нет единого DOD, то его создает Разработчики. Если он есть в организации, команда обязана ему следовать.
Да. DOD — это живой документ. Он может и должен улучшаться (адаптироваться) на основе обратной связи с Ретроспективы Спринта. Однако его нельзя снижать в качестве.
DOD определяет, когда элемент завершен. DoR (Definition of Ready) определяет, когда элемент готов к взятию в Спринт (достаточно ясен для работы).
Нет. В Scrum Definition of Done должен быть единым для всего продукта. Если команда работает над несколькими продуктами, то для каждого продукта должен быть свой DOD. Это гарантирует, что все инкременты продукта соответствуют одному стандарту качества.
Этот элемент не может считаться частью Инкремента. Он должен быть возвращен в Бэклог Продукта и переупорядочен. Он может быть взят снова в следующий Спринт, но только после устранения причин, по которым он не был завершен.