DoR и DoD на собеседовании системного аналитика

Зачем спрашивают на собесе SA

DoR / DoD — стандарты качества команды. На собесе SA: «отличие DoR и DoD», «отличие от AC», «зачем нужны».

Definition of Ready

DoR — критерии, которые задача должна удовлетворить, чтобы команда взяла её в работу.

Стандартный DoR (Story):

• User story сформулирована.
• AC прописаны и согласованы.
• Дизайн готов (если нужен).
• Зависимости известны.
• Технические нюансы прояснены с tech lead.
• Story points оценены.
• Все стейкхолдеры указаны.

Зачем. Без DoR команда берёт «полу-готовые» задачи, потом блокируется в середине спринта на уточнения.

Грумминг / refinement. Митинг для подготовки stories к DoR.

Definition of Done

DoD — критерии, при которых задача считается выполненной.

Стандартный DoD:

• Код написан.
• Code review пройден (минимум 2 approver'а).
• Unit / integration tests добавлены и проходят.
• Документация обновлена.
• AC удовлетворены.
• QA принял.
• Деплой на staging.
• Performance проверен (если NFR).
• Security check (если sensitive).
• Monitoring / alerting настроены.

DoD общий для всех stories команды. AC — индивидуальный для каждой story.

DoR vs DoD vs AC

Примеры

Story: «Пользователь восстанавливает пароль через email».

DoR (готовность):

• AC прописаны (Given/When/Then).
• Email-template согласован с маркетингом.
• Backend endpoint обсуждён с tech lead.
• Story points = 5.

AC (поведение):

• Given user на /forgot-password
• When вводит email and submits
• Then получает email с reset link через < 1 минуту

DoD (качество):

• Code review.
• Tests.
• QA pass.
• Email рендерится в Gmail / Outlook / iOS Mail.
• Security review (rate limit на сброс).
• Деплой на staging.

Когда обновлять

DoR / DoD — living документы. Обновлять на retrospective:

• «Половина stories блокируется на missing wireframes» → добавить «Дизайн готов» в DoR.
• «Bugs из прода, не покрыты тестами» → ужесточить test coverage в DoD.
• «Performance тестирование забывали» → добавить в DoD для backend stories.

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

DoR / DoD не существуют. Хаос — какие задачи готовы, что значит «сделано» — каждый раз discussion.

DoD на 30 пунктов. Никто не выполняет. Простой и достижимый — лучше.

DoR блокирует все stories. Если DoR слишком строг — backlog не двигается. Калибровка.

Игнорировать DoD под deadline. «Допишем тесты потом» — техдолг растёт.

DoR / DoD только в Confluence. Должны быть видны команде ежедневно (sprint board, чек-лист в JIRA).

Один DoD для всех типов задач. Bug-fix и new feature — разный DoD.

Связанные темы

• Acceptance Criteria Given/When/Then для SA
• User Stories и Acceptance Criteria для SA
• Scrum vs Kanban для SA
• Story points для SA
• Подготовка к собесу системного аналитика

FAQ

DoR и DoD одинаковы для bug?

Нет. Bug DoR: steps to reproduce, environment, severity. Bug DoD: фикс + regression test, не сломал другое.

Это официальная информация?

Нет. Статья основана на стандартных Scrum / Agile practices.

Тренируйте системный анализ — откройте тренажёр с 1500+ вопросами для собесов.