На связи Анастасия Шильникова, менеджер по тестированию компании «Гарда».

Мы регулярно сталкиваемся с ситуациями, когда в Jira к задаче вроде есть какое-то описание, стоит статус «готово», но, чтобы понять, в чем была проблема, что было исправлено, как было проверено, приходится «нырять» в мессенджер или звонить коллегам. Все это съедает время, размывает ответственность между командами и мешает выпускать продукт быстро, качественно, в срок.

Вот несколько реальных примеров, когда описание к задаче похоже на квест:   

Чтобы решить проблему, мы решили внедрить в жизненный цикл разработки концепцию DoR (Definition of Ready) и DoD (Definition of Done). В этой статье я расскажу:

• чем DoR и DoD отличаются от критериев приемки и почему их важно не путать;

• как не превратить полезный инструмент в бюрократическую обязаловку;

• какие узкие места могут возникнуть при внедрении концепции.

DoR и DoD — это не про идеал, а про синхронизацию ожиданий

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

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

Не стоит путать критерии DoR и DoD с Acceptance Criteria (критериями приемки). Последние отвечают на вопрос «какой функциональностью должен обладать продукт, чтобы удовлетворять требованиям заказчика или пользователя?». Этот список условий или требований всегда будет уникальным для каждой задачи, которая попадает в разработку или тестирование. Например, «поле никнейма сохраняется и отображается в профиле» или «для каждого интерактивного элемента есть состояния: default, hover, active, disabled».

В свою очередь, DoR и DoD — это чек-лист действий, которым должна соответствовать каждая задача, чтобы она могла перейти на следующий этап цикла разработки. Эти критерии будут одинаковы для всех задач (например, «код прошел ревью» или «написаны юнит-тесты»). Без таких договоренностей команда сталкивается с типичными проблемами:

• требования к задачам не зафиксированы, нечетко прописаны или двояко интерпретируются участниками;

• в процессе разработки уточняются детали в личных переписках, а не в задаче. В итоге информация теряется или нужно много времени, чтобы восстановить цепочку;

• трудоемкость разработки меняется в процессе из-за уточнения требований, что ломает все планирование, сроки готовности задачи к поставке сдвигаются, и заказчик нервно ждет обещанные фичи;

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

Антипаттерны DoR и DoD: когда правила начинают мешать работе

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

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

Первый и самый краеугольный камень — формальный подход. Бывает так: разработчик заливает коммит, а потом коллега в процессе ревью просто пролистывает код до конца, ставит «ОК» и закрывает вкладку. Задача формально соответствует критерию «код-ревью пройдено», но реальной проверки не было. В таких случаях критерии превращаются в галочки ради отчетности, а не в инструмент качества. Доверие к процессу падает, и команда начинает игнорировать чек-листы как бесполезную бюрократию.

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

Третья проблема — размытые формулировки. Когда критерий написан так, что его можно прочитать по-разному в зависимости от ситуации, возникает хаос. Один участник команды будет считать условие выполненным, а другой — нет. В итоге возникнут споры, переделки или в самом худшем варианте критерий будут просто игнорировать, потому что «непонятно, чего от меня хотят».

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

Пятая сложность при внедрении DoR и DoD — отсутствие актуализации: когда критерии написали один раз, «приколотили» к стене (или сохранили в Confluence) и забыли. А процессы тем временем меняются. Например, решили отказаться от практики линковать мерж-реквест к задаче в Jira, так как ссылка теперь появляется в отдельном поле автоматически при его создании, а в DoD зафиксировано, что разработчик должен выполнить это действие вручную. В результате получается, что DoR и DoD перестают соответствовать реальности и их начинают игнорировать. Поэтому нужно пересматривать требования регулярно. Какой-то выбитой в камне периодичности нет. Это можно делать, к примеру, раз в спринт, раз в квартал или по триггерам, которые команда определит для себя.

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

Как экологично встроить критерии в процессы, а не держать чек-лист у монитора

Хорошие новости: большинство критериев можно автоматизировать или встроить в привычные рабочие инструменты. Тогда не нужно держать список перед глазами. Поделюсь некоторыми идеями по автоматизации

Во-первых, в Jira можно настроить заполнение обязательных полей при смене статуса. Например, задача не перейдет в статус «In Progress», пока не заполнено поле «Критерии приемки» или не указана оценка сложности разработки. Такой подход гарантирует, что сырые задачи просто физически не попадут в разработку.

Во-вторых, полезны шаблоны для описания задач. Особенно для багов: при создании дефекта в поле описания автоматически подставляется шаблон с пунктами «Шаги воспроизведения», «Фактический результат», «Ожидаемый результат». Заводящему баг остается только заполнить поля — и задача сразу содержит всю необходимую информацию. Это решает проблему «описания на языке птичек», когда в дескрипшене написано что-то вроде «в функцию Х добавить метод для обработки эксепшена Y» без контекста для тестировщика.

В-третьих, в CI/CD-пайплайнах можно настроить триггеры, блокирующие деплой кода в стабильную ветку при невыполнении критериев DoD. Например, если в мерж-реквесте нет ссылки на задачу в Jira, или отсутствуют юнит-тесты, или не пройдено код-ревью — пайплайн остановится и не даст залить код в stable -ветку. Такие проверки превращают критерии из рекомендаций в неотъемлемую часть процесса.

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

Заключение

DoR и DoD – это фундаментальные инструменты, которые позволяют командам разработки и тестирования работать более слаженно, предсказуемо и с высоким качеством продукта. Их внедрение требует дисциплины, но приносит ощутимые выгоды: снижение количества возвратов, ясность требований и более точное планирование. При правильном использовании DoR/DoD становятся частью культуры команды и помогают доставлять ценность бизнесу без дополнительных затрат ресурсов.

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

А у вас бывают задачи, которые «закрыты, но непонятно почему»? Делитесь в комментариях — интересно собрать статистику.