Привет, Хабр! Меня зовут Таня, и последние 3 года я работаю с IT-командами, помогая им выстраивать процессы, улучшать взаимодействие и внедрять рабочие практики, которые делают их работу продуктивнее и приятнее. Сегодня расскажу про DoR и DoD;)

Если ты когда-нибудь сталкивался с размытыми задачами или бесконечными доработками кода, то Definition of Ready (DoR) и Definition of Done (DoD) — это именно то, что поможет с этим справиться. Давай разберемся, что это такое, зачем они нужны и как правильно использовать.

План статьи:

1. Что такое DoR и DoD?

2. Чем они полезны?

3. Как выглядят качественные DoR и DoD?

4. Как использовать DoR и DoD на практике?

5. Как создать DoR и DoD?

1. Что такое DoR и DoD?

• Definition of Ready (DoR) — список критериев, которые задача должна выполнить, чтобы команда могла начать её разработку.

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

Если совсем просто, то DoR — это «можем ли мы начать?», а DoD — это «точно ли мы закончили?». Эти критерии должны одинаковы для всех задач, проходящих через команду.

2. Чем они полезны?

1. DoR спасает от недоделанных задач

Бывало такое, что тебе дают задачу, но в ней куча пробелов: неясные требования, отсутствуют макеты, не определены API? А потом ты или твоя команда тратите время на уточнения и переделки. DoR предотвращает такие ситуации, потому что задача не попадёт в работу, пока не будет четко описана.

2. DoD помогает не тянуть хвосты

Сделать «по фасту», а потом исправлять на проде — знакомо? DoD защищает от этого и гарантирует качество работы. Это чёткие критерии: код написан, покрыт тестами, ревью пройдено, задеплоено. Никаких «ну, оно почти готово» — либо сделано, либо нет.

3. Меньше нервов, меньше переделок

Если в команде чётко определено, когда задача начинается и когда она считается завершённой, меньше споров и больше предсказуемости. А значит, ты реже сталкиваешься с внезапными изменениями и сюрпризами от бизнеса.

3. Как выглядят качественные DoR и DoD?

Пример DoR:

• Зафиксированы Acceptance Criteria (AC).

• История соответствует INVEST (независимая, ценная, тестируемая и т. д.).

• Подготовлен дизайн.

• Определены основные и альтернативные сценарии.

• DevTeam понимает, как демонстрировать историю на обзоре спринта.

Пример DoD:

• Дизайн ревью пройден (Все экраны соответствуют макетам)

• Актуальная документация

• Код ревью пройден

• Код залит в ветку, тестирование пройдено

• История соответствует критериям приемки

• unit-тесты

4. Как использовать DoR и DoD на практике?

Где и как использовать DoR?

• На PBR (Product Backlog Refinement) — уточняем требования до момента, пока они не станут соответствовать DoR.

• На планировании спринта — в бэклог попадают только задачи, соответствующие DoR.

Где и как использовать DoD?

•  В процессе разработки — DoD используется как чек-лист.

• Sprint Review — только задачи, которые удовлетворяют DoD, могут считаться завершёнными и быть продемонстрированными. Если чего-то не хватает (например, нет тестов или документации), задача уходит в доработку.

• Перед выпуском в прод — проверяем, что весь инкремент разработки соответствует DoD. Если какие-то пункты не выполнены (например, нет регрессионного тестирования), задача не должна попадать в релиз.

5. Как создать DoR и DoD?

Откуда берутся эти требования?

В некоторых компаниях есть общие DoR и DoD, которые распространяются на все команды. Если таких нет — вы можете создать их сами. Это договоренности внутри команды, которые помогает делать задачи быстрее и качественнее.

Лучше заложить 2 часа (можно на ретро или отдельной встрече) и собираем всю команду.

1. Брейншторминг DoR (10 минут)

Каждый записывает на стикерах свои предложения:

• Какие требования должны быть выполнены, чтобы мы могли спокойно начинать работу над задачей?

• Какие внешние риски мы раньше не учитывали, из-за которых задачи затягивались?

2. Формирование текущего DoR (15+ минут, может быть холивар)

• Если команда маленькая (до 6 человек) — обсуждаем голосом.

• Если большая — голосуем стикерами за самые важные пункты, потом обсуждаем.

• Не нужно гнаться за количеством, выберите буквально 3-4 пункта, которым вы будете следовать в ближайшие 3 месяца, чтобы «сырые» задачи не попадали в спринт.

  Проверочные вопросы:

• Что из этого мы можем применять уже сейчас?

• Какие ограничения накладывает наша инфраструктура и экспертиза?

• Какие из этих практик являются стандартами индустрии?

После согласования финального списка фиксируем его как «Сейчас» (Now).

3. Определяем перспективу на будущее

Полезные идеи, которые пока сложно внедрить, тоже важно сохранить, записываем в «Дальше» (Next). Можно занести в бэклог команды, то что нам нужно, чтобы внедрить эти критерии

4. Повторяем предыдущие три пункта для создания DoD

Вопрос для пункта 1: Через какие этапы должна пройти работа, чтобы стать доступной конечному пользователю?

Не забывайте обновлять DoR и DoD

Реальность меняется, и ваши DoR/DoD тоже стоит пересматривать раз в полгода или по мере необходимости. Они должны быть актуальными и удобными для работы, а не формальностью.

Если хочется меньше переделок, чёткие требования к задачам и прозрачный процесс разработки — попробуй внедрить DoR и DoD. Начни с малого: обсудите их на ретро или создайте минимальный список, а дальше дорабатывайте его вместе.