Definition of Done или как его сокращенно называют DoD — довольно популярный инструмент, про который вы уже могли прочитать в нашем блоге. В противоположность о Definition of Ready (DoR) довольно сложно найти информацию в интернете. При этом важно понимать, что оба эти инструмента могут быть использованы не только Scrum-командой.

Сама по себе концепция DoR немного противоречит Agile-мировозрению т к в неумелых руках может стать бюрократическим инструментом, но обо всем по порядку.

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

Какие симптомы могут сообщить, что вашей команде нужен DoR?

• У вашей команды много заказчиков и они все время забывают о правилах взаимодействия
• Для реализации функционала нужны согласования юристов/ информационной безопасности. Бизнес начинает получать эти согласования параллельно с разработкой, что приводит к изменениям требований
• Часто в середине спринта Product Owner меняет требования по задачам, делая проделанную ранее командой работу бесполезной
• Если функционал в вашей системе используется сразу разными бизнес-подразделениями и они забывают согласовать изменения между собой
• Если в вашей компании бывают большие проекты, затрагивающие несколько команд

DoR должен быть своеобразным щитом для команды

DoR должен быть своеобразным щитом для команды разработки от ненужной работы. Представьте, что вы взяли в работу задачу, которую заказчик еще не согласовал с юристами. В середине спринта оказывается, что выбранное решение противоречит законодательству и вся выполненная работа оказывается бесполезной. Команда демотивирована, заказчик потерял деньги. Именно от таких случаев должен защищать нас DoR.

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

Например, в моей команде DoR состоит из 3-х частей. В первой части пункты, которые заказчик должен выполнить самостоятельно. Во второй части пункты, которые заказчик выполняет совместно с командой во время PBR. Третья часть состоит из пунктов-напоминаий, которые нужны не во всех задачах, но заказчик может просто забыть их сделать.

Подробнее вы можете ознакомиться на примере.

Definition of Ready (DoR) пример.

• Задача прошла приоритизацию
• Архитектор определил целевую систему/системы
• Определен человек координрующий в се активности по задаче

Во время PBR:

• Определена бизнес-ценность задачи
• Определен end-to-end бизнес-процес
• User Story
• Критерии приемки
• Определен источник бюджета по задаче
• Список людей, принимающих доработку
• Задача имеет оценку
• Задача декомпозирована

В зависимости от контекста:

• При наличии зависимостей от других команд согласованы сроки начала работы
• Есть согласование от юристов
• Есть согласование от отдела информационной безопасности
• Согласованы изменения с владельцами функционала

Любой инструмент нужно использовать осознанно, в том числе и DoR. Если инструмент не решает никакой проблемы, то есть большая вероятность, что команда бесполезно потратит время на его создание. На практике он станет просто бесполезным артефактом. Опытный Скрам Мастер сможет определить, когда команда достаточно созрела для внедрения DoR.