Что такое Definition of Done — критерии готовности к работе?

DoD — это набор общих критериев, определяющих то, когда инкремент продукта можно считать завершенным. Они обеспечивают качество и согласованность результатов. Обычно команды используют DoD в конце спринта, чтобы проверить качество инкремента.

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

Наличие DoD крайне важно для поставки качественного продукта, востребованного клиентами, поскольку эти критерии позволяют определить, когда элемент можно отметить как завершенный и включить в инкремент продукта. Хорошо продуманные DoD дают следующие преимущества.

Повышение качества: проверяя каждый инкремент по критериям DoD, Agile-команды придерживаются целевых показателей качества на протяжении всей разработки продукта. Это гарантирует, что стандарты качества для релиза выполняются постоянно.

Снижение рисков: соблюдение DoD сводит к минимуму риск доработки и связанных с этим возможных задержек, поскольку команда точно знает, каким критериям должен соответствовать элемент, который она отмечает как завершенный. Так поддерживается качество на всех этапах проекта.

Слаженность в команде: поскольку критерии DoD проекта понимает и разделяет вся команда, ей легче сосредоточиться на требованиях клиентов и поставлять ценность в каждом спринте.

Измерение прогресса: наличие четких критериев DoD позволяет командам отслеживать количество инкрементов продукта, соответствующих условиям готовности. Так, например, одним из показателей Scrum может быть скорость, которая отражает, сколько завершенных инкрементов продукта сотрудник поставляет за указанный период.

Хотя конкретные этапы различаются в зависимости от команды или проекта, общий алгоритм при создании критериев готовности работы всегда одинаков. Ниже приведены этапы создания DoD.

При формулировании DoD важно работать с нужными участниками команды, поскольку выбранным критериям должны будут единодушно следовать все сотрудники, задействованные в проекте. Привлеките всех, кому есть что сказать о том, как должна выглядеть завершенная работа в проекте: владельцев продуктов, Scrum-мастера, участников Scrum-команды, тестировщиков, менеджеров по продуктам, спонсоров и другие заинтересованные стороны.

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

Самая трудоемкая задача состоит в непосредственном определении критериев, которые команда будет использовать для оценки готовности работ в проекте. Определение этих критериев имеет решающее значение, поскольку на кону — качество выполняемой работы.

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

1. Достаточно ли критерии конкретны? Не давайте расплывчатых формулировок («весь код протестирован»). Будьте конкретны («весь код тщательно проверен с помощью модульных, интеграционных и сквозных тестов»).
2. Ориентированы ли критерии на клиента? Хорошим примером будет критерий «вся документация написана и обновлена», нацеленный на облегчение поиска инструкций по использованию продукта для конечного пользователя.

«Помните, что критерии выполнения — это не то же самое, что критерии приемки, — объясняет Крут. — DoD — это набор действий, которые, по мнению команды, необходимо выполнить, чтобы присвоить пользовательской истории статус „готово“ (что может включать критерии приемки). Но это не эквивалентно утверждению, что пользовательская история была реализована корректно».

Использование критериев DoD кажется естественным для команд c крупными проектами. Однако команды, работающие над небольшими заданиями, задачами или ошибками, могут применять те же концепции для создания менее обширного контрольного списка. Наличие такого списка для каждого задания или задачи гарантирует, что команда будет стабильно поставлять результаты высокого качества.

Критерии приемки (AC) означают условия, которым должны соответствовать пользовательские истории, чтобы считаться приемлемыми для клиентов. Они отличаются от DoD тем, что относятся к пользовательским историям или возможностям, а не к инкрементам продукта.

Критерии AC служат для определения готовности пользовательской истории или отдельного задания и, как и DoD, подлежат согласованию. Для примера возьмем такую пользовательскую историю: «Как пользователь, я хочу использовать поле поиска, чтобы находить нужные продукты». Критерии приемки могут быть в том числе следующими.

• Поле поиска находится на верхней навигационной панели.
• Поиск выполняется при нажатии кнопки «Поиск».

• В поле поиска содержится серый замещающий текст «Что вы ищете?».

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

«Критерии выполнения должны быть живым документом. По мере того как вы узнаете что-то новое о своей работе, команде следует обновлять DoD, — добавляет Крут. — Подумайте о ежеквартальном пересмотре DoD, чтобы критерии оставались актуальными и включали все необходимые элементы».

Пересматривайте и обновляйте DoD во время обзоров итогов спринтов, чтобы критерии не теряли актуальности для проекта. По мере развития проекта и изучения требований клиентов, команде, возможно, также придется корректировать критерии DoD, чтобы они по-прежнему оставались достижимыми. Предоставьте участникам команды возможность предлагать изменения DoD во время обзоров итогов спринтов или на собраниях по уточнению бэклога.

Пользуясь Jira, команды разработчиков ПО могут без труда сформулировать критерии выполнения. Создав пользовательские поля или скачав соответствующее расширение, можно сформировать контрольные списки по каждой задаче Jira. Создавайте отдельные критерии DoD для разных типов работы, настраивая типы задач Jira.

Миллионы высокопроизводительных agile-команд доверяют Jira поддержку своих потребностей в управлении программами и проектами, от agile-планирования до стендапов по спринтам и не только. Попробуйте бесплатно.

Обычно их создает команда разработчиков под руководством Scrum-мастера. При этом нужно учитывать мнение владельцев продуктов, тестировщиков и других заинтересованных сторон.

DoD — это набор общих критериев, определяющих то, когда инкремент продукта можно считать завершенным. Они применяются ко всем инкрементам продукта и в целом определяют его качество.

Критерии приемки, в свою очередь, — подробные условия, применимые только к конкретным пользовательским историям или возможностям. Критерии AC определяют, приемлема ли пользовательская история для клиента. Пример DoD: «Вся документация написана и обновлена». Пример AC: «Ссылка на пользовательскую документацию доступна в меню навигации».

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

Держите документ на видном месте: сотрудники должны иметь под рукой критерии DoD, когда планируют спринт или вырабатывают оценку элементов в бэклоге продукта. У команды должна быть возможность постоянно сверяться с этой информацией. Напечатайте документ и повесьте его на стену или добавьте в вики либо план проекта.

Ставьте реалистичные цели: критерии DoD должны быть достижимыми в установленные сроки и с имеющимися ресурсами. Более того, эти критерии должны соответствовать реальным потребностям клиентов.