В чем разница между Definition of Done и Acception критериями?

Definition of Done vs Acceptance Criteria

Это два разных, но взаимосвязанных концепта в Agile разработке. Часто их путают, но на самом деле они решают разные проблемы.

Что такое Acceptance Criteria (AC)

Definition: Acceptance Criteria - это набор условий, которые должны быть выполнены, чтобы user story считалась выполненной с точки зрения бизнеса и пользователя.

Кто пишет: Business Analyst, Product Owner, иногда совместно с разработчиком

Когда определяются: ДО начала разработки, обычно на planning/refinement встречах

Фокус: На функциональности и бизнес-ценности

Пример:

Story: "Как клиент, я хочу фильтровать товары по цене, 
чтобы найти товары в моем бюджете"

Acceptance Criteria:
- Пользователь может ввести минимальную и максимальную цену
- Список товаров фильтруется в реальном времени при изменении цены
- Фильтр сохраняется при переходе на другую страницу
- Если результатов нет, показать "No results found"
- Работает на мобильных и десктопе
- Performance: фильтрация должна занимать < 500ms

Эти критерии отвечают на вопрос: "Что ровно должно работать, чтобы пользователь остался доволен?"

Что такое Definition of Done (DoD)

Definition: Definition of Done - это набор условий, которые должны быть выполнены, чтобы код считался качественным и готовым к продакшену.

Кто пишет: Обычно техническая команда (разработчики, QA, архитектор) вместе

Когда определяются: В начале проекта, это standard для всех stories

Фокус: На качество, тестирование, документирование, техническое совершенство

Пример:

Definition of Done:
- [ ] Код написан и reviewed (минимум 2 рецензента)
- [ ] Unit тесты написаны (coverage > 80%)
- [ ] Integration тесты добавлены
- [ ] Manual тестирование пройдено (happy path + edge cases)
- [ ] Нет console.logs и commented code
- [ ] Документирование обновлено (API docs, README if needed)
- [ ] Performance тесты пройдены (load time, memory usage)
- [ ] Security review пройден (если touch sensitive data)
- [ ] Deployed to staging и проверен
- [ ] Database migrations (если есть) протестированы
- [ ] Accessibility проверена (WCAG 2.1 AA)
- [ ] Error handling и logging добавлены

Эти условия отвечают на вопрос: "Как мы убеждаемся, что код качественный и не сломает продакшен?"

Ключевые различия

Конкретный пример в контексте

Story: "Пользователь может изменить пароль в профиле"

Acceptance Criteria:

1. На странице профиля есть кнопка "Change Password"
2. После клика открывается форма с полями:
   - Current Password
   - New Password
   - Confirm New Password
3. Система валидирует:
   - Current password правильный
   - New password не совпадает со старым
   - New password и Confirm совпадают
   - New password минимум 8 символов
4. При успехе показать "Password changed successfully"
5. При ошибке показать понятное сообщение об ошибке
6. После изменения пароля, пользователь разлогирован во всех других браузерах

Definition of Done (для этой story):

[ ] Code review пройден (минимум 2 человека)
[ ] Unit тесты написаны для валидации (password strength, match check)
[ ] Integration тесты написаны (mock DB, auth service)
[ ] Manual QA проверил все acceptance criteria
[ ] Security проверка: пароль не логируется, HTTPS используется
[ ] Error handling: network errors, timeout, DB errors
[ ] API docs обновлены (если создавался новый endpoint)
[ ] Merged to main и deployed to staging
[ ] Accessibility: форма работает на screen reader
[ ] Performance: форма грузится < 1 сек
[ ] No console errors or warnings

Как они работают вместе

Процесс:

1. Planning: BA пишет Acceptance Criteria, техническая команда определяет DoD
2. Development: Разработчик пишет код, чтобы прошли AC и DoD
3. Testing: QA проверяет AC (соответствует ли требованиям), Dev team проверяет DoD (качество кода)
4. Definition of Done: Можно считаться Done только если выполнены ОБА:
   • ВСЕ Acceptance Criteria пройдены ✓
   • ВСЕ Definition of Done пункты выполнены ✓

Как AC и DoD взаимодействуют

Идеальный сценарий:

• AC описывает ЧТО нужно сделать
• DoD описывает КАК это должно быть сделано
• Оба выполнены → story Done

Проблемный сценарий 1:

• AC пройдены, DoD не пройдены
• Пример: feature работает, но нет unit тестов, нет code review
• Результат: feature может сломаться при дальнейшей разработке

Проблемный сценарий 2:

• AC не пройдены, DoD пройдены
• Пример: код качественный, но feature работает не правильно
• Результат: пользователь недоволен, бизнес не получил ценность

Практические рекомендации

Для BA:

• Пишу clear, testable AC (не размытые описания)
• AC должны быть достижимы в одном спринте
• AC должны включать граничные случаи и error scenarios
• AC должны быть понятны QA и разработчикам

Пример хороших AC:

✓ Система валидирует email и показывает ошибку "Invalid email format"
✓ Пользователь может загрузить изображение максимум 5MB
✓ После успешной регистрации, отправляется confirmation email
✓ На мобильных, форма занимает 100% ширины с margin 16px

✗ Система должна быть быстрой
✗ Форма должна выглядеть хорошо
✗ Email валидация работает правильно

Для Dev Team:

• DoD должен быть реалистичен и выполним в каждом спринте
• Если DoD слишком тяжелый, story will never finish
• DoD должен быть consistent для всех stories
• Периодически review и update DoD (каждые 2-3 спринта)

Пример DoD для типичной Agile команды

Definition of Done (общая для всех stories):

--- CODE QUALITY ---
[ ] Code reviewed и approved (минимум 1 senior dev)
[ ] Sonar scan passed (code quality gate)
[ ] No new vulnerabilities (security scan)
[ ] Coding standards соблюдены

--- TESTING ---
[ ] Unit тесты написаны (coverage > 80%)
[ ] Integration тесты добавлены (если DB change)
[ ] Manual QA проверил все AC
[ ] Edge cases и error paths протестированы

--- DOCUMENTATION ---
[ ] Code comments добавлены (complex logic only)
[ ] API docs обновлены (if API change)
[ ] README обновлен (if setup change)

--- DEPLOYMENT ---
[ ] Database migrations tested (up and down)
[ ] Feature flag добавлен (if applicable)
[ ] Deployed to staging и проверен
[ ] No console errors/warnings

--- PROCESS ---
[ ] Merged to develop branch
[ ] CI/CD pipeline passed
[ ] Commit message is clear

Заключение

Acceptance Criteria — это контракт между бизнесом и разработкой: "Если выполнены эти условия, то feature решает бизнес-проблему."

Definition of Done — это контракт между разработкой и качеством: "Если выполнены эти условия, то код готов к продакшену и не создаст проблем."

Оба нужны для успешной разработки. AC без DoD = функциональный, но хрупкий код. DoD без AC = качественный, но неправильный код. Оба вместе = успешный product.