Что такое Definition of Done и Definition of Ready в Scrum?

Definition of Done и Definition of Ready в Scrum

Определение понятий

Definition of Ready (DoR) — это чеклист критериев, которые user story должна удовлетворять, прежде чем попасть в спринт.

Definition of Done (DoD) — это чеклист критериев, которые задача должна удовлетворять, чтобы считаться полностью завершённой.

Это два якоря качества в Scrum: один гарантирует, что story готова к разработке, другой — что она полностью завершена.

Definition of Ready (DoR) — готовность к разработке

Суть: Перед тем как добавить user story в спринт, убедись, что она достаточно детализирована и понятна разработчикам.

Пример DoR чеклиста:

Требование к User Story:

☐ Есть понятное название (не "Исправить баг", а "Пользователь видит ошибку валидации email")
☐ Есть чёткое описание (формат: "Как <тип пользователя>, я хочу <действие>, чтобы <ценность>")
☐ Есть приёмочные критерии (как минимум 3-5 criteria)
☐ Оценена разработчиками (от 1 до 13 story points)
☐ Зависимостей либо нет, либо они явно указаны
☐ Есть дизайн/mockup (если требуется UI)
☐ Бизнес-требования согласованы с product owner
☐ Понятны нефункциональные требования (производительность, безопасность)
☐ Test cases написаны или известны QA
☐ Нет блокирующих вопросов от разработчиков

Процесс проверки DoR:

1. Product Owner готовит story перед спринт-планированием
2. На встречу Refinement нескольких дней до спринта
3. Разработчики проверяют story на соответствие DoR
4. Если не соответствует → отправляем обратно PO
5. Когда все ☐ установлены → story готова к спринту

Пример:

CLIENT STORY:
Как покупатель, я хочу добавить товар в избранное, 
чтобы вернуться к нему позже.

Дизайн: [ссылка на Figma макет]
Оценка: 5 story points
Приоритет: High (много запросов от пользователей)

Приёмочные критерии:
☐ При клике на сердечко товар добавляется в "Избранное"
☐ Сердечко меняет цвет на красное
☐ При вторичном клике товар удаляется из избранного
☐ На странице "Мои избранные" отображаются все добавленные товары
☐ При перезагрузке страницы список сохраняется (localStorage)
☐ На мобильных экранах сердечко видно и кликается
☐ Уведомление об ошибке, если не удалось сохранить

Депенденсии: Нет (можно разрабатывать независимо)
Технические вопросы: Нет
Дизайн согласован: Да

Это story READY для спринта.

Definition of Done (DoD) — полная готовность

Суть: Story считается завершённой только если она прошла через все этапы: разработку, тестирование, review и развёртывание.

Пример DoD чеклиста:

Код:
☐ Код написан в соответствии с style guide
☐ Нет commented code
☐ Нет console.log / debug вывода
☐ Нет hardcode (магические числа, строки)
☐ Все переменные и функции имеют понятные имена
☐ DRY — нет дублирования кода

Тестирование (разработчик):
☐ Unit tests написаны (минимум 80% coverage)
☐ Все тесты проходят локально
☐ Код проверен на линтер (npm run lint)
☐ Проверена производительность

Ревью:
☐ Code review пройден (как минимум один разработчик)
☐ Все комментарии от reviewer исправлены
☐ CI/CD пайплайн прошёл успешно
☐ Нет конфликтов при мерже в main

Тестирование (QA):
☐ QA протестировал в браузере
☐ Приёмочные критерии подтверждены
☐ Нет регрессии в других частях приложения
☐ Протестировано на мобильных устройствах (если требуется)
☐ Edge cases протестированы

Ошибки и документация:
☐ Нет critical / high severity bagов
☐ Все medium bagов задокументированы и спланированы на будущие спринты
☐ Code comments/docstrings добавлены где нужно
☐ API документация обновлена (если требуется)

Деплой:
☐ Код развёрнут на staging
☐ Миграции БД накатаны (если требуется)
☐ Feature flag активирован (если требуется)
☐ Код готов к production (может быть развёрнут сейчас или позже)

Это story считается DONE только если все ☐ установлены.

Definition of Ready vs Definition of Done

Практический пример

Story: "Авторизация через Google OAuth"

BEFORE (без DoR/DoD) - проблемы:

1. На планировании: "Делай OAuth"
   Разработчик: "А какой flow? Какие permissons нужны? Какая error handling?"
   Потеря времени на уточнения

2. После разработки: 
   Разработчик: "Готово!"
   QA: "А что если пользователь отклонит permission? Что с токеном при logout?"
   Нужна переделка

3. На production:
   "Какой-то баг с refresh token"
   Но это не видел перед релизом

WITH DoR/DoD - всё правильно:

Definition of Ready:

☐ Story: "Как пользователь, я хочу авторизоваться через Google OAuth, чтобы быстро создать аккаунт"
☐ Приёмочные критерии:
  ☐ Кнопка "Login with Google" на странице входа
  ☐ Пользователь перенаправляется на Google consent screen
  ☐ После согласия создаётся аккаунт с email и name от Google
  ☐ Пользователь логинится автоматически
  ☐ При отклонении разрешений: сообщение об ошибке
  ☐ Email уже в системе: обновляем profile, логиним

☐ Дизайн: [Figma link]
☐ Оценка: 8 story points
☐ Технические решения:
  - Используем Google Cloud OAuth
  - Refresh token хранится в secure httpOnly cookie
  - Access token в memory (не в localStorage)
  - Logout очищает cookie
☐ Нет dependencies
☐ API endpoint задокументирован: POST /api/v1/auth/google

Definition of Done:

☐ Google OAuth implementation завершена
☐ Unit tests: 90% coverage (test auth flow, token refresh)
☐ Integration test: е2е тест через реальный Google account
☐ Code review пройден
☐ Lint и все checks пройдены
☐ QA протестировала:
  ☐ Успешная авторизация
  ☐ Отклонение разрешений
  ☐ Exist user login
  ☐ Logout корректно очищает токены
  ☐ Token refresh работает при истечении
☐ Security review пройден (tokens safe, no leaks)
☐ API документация обновлена
☐ На staging работает без проблем
☐ Готово к production

Частые ошибки

1. DoR слишком строгий

❌ Story требует дизайна, API spec, и согласования с 5 people
✅ DoR простой и проверяется за 15 мин

2. DoD слишком свободный

❌ "Код готов, когда разработчик скажет что готов"
✅ Чеклист с четкими критериями (tests, review, QA)

3. DoR не соответствует DoD

❌ DoR: нужен дизайн, но DoD: нет требования по дизайну
✅ DoR и DoD согласованы

4. DoR/DoD никогда не пересматриваются

❌ Чеклист из 2019 года, не обновлялся
✅ Ежемесячный ретроспектив: меняем DoR/DoD если нужно

Как внедрить DoR/DoD

Шаг 1: Создай черновик (1 день)

Собери team, напиши то, что, на твой взгляд, должно быть в DoR/DoD

Шаг 2: Тестируй на реальных story (1-2 спринта)

Применяй чеклист к каждой story
Обсуждай: что работает, что нет

Шаг 3: Итерируй (каждый спринт)

На retro: "Может ли мы улучшить DoR/DoD?"
Добавляй критерии на основе ошибок прошлого

Пример эволюции DoD:

Спринт 1: [базовый чеклист]
Спринт 2: "Забыли про unit tests" → добавили в DoD
Спринт 3: "Баг в production" → добавили QA тестирование
Спринт 4: "API не документирована" → добавили documentation

Заключение

Definition of Ready и Definition of Done — это два якоря качества в Scrum:

• DoR гарантирует, что story готова к разработке (no surprises)
• DoD гарантирует, что story полностью завершена (no bugs in production)

Без них team тратит время на:

• Уточнение requirements
• Переделки из-за missed criteria
• Баги в production

С ними process становится efficient и predictable.