Definition of Done: как согласовать общую проверку готовности команды

Когда команда спорит о готовности работы, причина часто не в качестве самой задачи, а в смешении двух разных уровней проверки. Один уровень отвечает на вопрос: что мы всегда считаем обязательным для любой завершенной работы. Другой — что именно должно быть верно в этой конкретной задаче. Первый уровень обычно оформляют как Definition of Done, второй — как критерии приемки или иные условия конкретного элемента бэклога.

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

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

Общее правило готовности: зачем команде отдельный Definition of Done

В Scrum Definition of Done связан с качеством инкремента. Смысл не в красивом документе, а в прозрачности: все участники одинаково понимают, при каких условиях результат можно считать пригодным для использования и дальнейшей проверки. Это не список пожеланий менеджера и не комментарии к одной карточке, а общее правило для всей команды.

Хороший Definition of Done описывает именно повторяющийся минимум, который применяется к каждой задаче, вошедшей в инкремент. Например, команда может договориться, что любая завершенная работа проходит согласованный способ проверки, имеет понятный результат в нужной среде и не оставляет известных блокирующих дефектов в рамках оговоренного сценария. Конкретные пункты зависят от продукта и процесса, но логика одна: это требования не к одной истории, а ко всем.

Полезный признак общего правила — его можно читать отдельно от любой задачи. Если пункт невозможно понять без сюжета конкретной карточки, это уже не командный стандарт, а частное условие. Например, «показывается сообщение об успешной отправке» не подходит для общего Definition of Done, потому что относится только к одной функции. А вот «изменение проверено согласованным способом в рабочем сценарии» может быть общим правилом.

Еще один важный момент: Definition of Done не должен меняться от задачи к задаче по настроению. Иначе команда теряет единый порог качества. Пересматривать его можно, но делать это стоит осознанно всей командой, а не под давлением одной срочной карточки.

Критерии отдельной задачи: что не нужно прятать в общий список

Критерии приемки отвечают на другой вопрос: какой наблюдаемый результат должен дать именно этот элемент бэклога. Они не описывают весь процесс разработки и не заменяют командный стандарт качества. Их задача — сузить неоднозначность вокруг конкретной потребности пользователя или бизнеса.

Проще всего отличить критерий задачи по формулировке. Если условие начинается с контекста вроде «когда пользователь отправляет форму» или «если поле пустое», перед вами почти наверняка не общий Definition of Done, а частный сценарий. Такие условия меняются от карточки к карточке, потому что меняется и предмет проверки.

В критериях конкретной задачи лучше фиксировать три вещи: основной сценарий, важные исключения и границы объема. Основной сценарий показывает, что считается успешным исходом. Исключения защищают от споров о предсказуемом сбое или неполных данных. Границы объема полезны не меньше самих критериев: они помогают явно сказать, что в этой задаче не проверяется и не обещается.

Из-за этого не стоит заполнять критерии задачи общими пунктами вроде «код должен быть проверен» или «обновить краткую документацию». Если команда каждый раз переписывает одно и то же в карточки, это признак, что условие уже давно пора вынести в общий Definition of Done.

Как собрать рабочую пару: один общий стандарт и одна карточка задачи

Практически это работает так: во время уточнения или планирования команда сначала смотрит на критерии конкретной задачи, чтобы понять смысл и границы работы. Затем держит рядом общий Definition of Done как финальный порог качества. Итоговая формула простая: задача считается готовой только тогда, когда выполнены оба слоя проверки.

Чтобы не смешивать слои, удобно задать к каждому пункту один проверочный вопрос. Для общего Definition of Done вопрос звучит так: «Мы бы применили это ко всем задачам спринта?» Для критерия приемки — «Без этого условия задача все еще сохраняет свой смысл?» Если на первый вопрос ответ “нет”, пункт не должен жить в общем списке. Если на второй ответ “нет”, его нельзя терять внутри общих стандартов.

Команде обычно хватает короткого общего списка из 5–7 пунктов. Длиннее — уже трудно использовать в ежедневной работе. А вот критерии конкретной задачи могут быть короче или длиннее в зависимости от объема, но им полезно оставаться привязанными к наблюдаемому поведению, а не к абстракциям вроде «интерфейс удобный» или «ошибка понятная».

Если в процессе работы открывается новый сценарий, лучше не надеяться на устную договоренность. Его стоит явно добавить в критерии задачи или, если выяснилось, что это повторяющееся требование ко всем изменениям, вынести на обсуждение общего Definition of Done. Так команда не теряет прозрачность.

Учебный список проверок: условный пример для одной задачи

Учебный пример — условный. Представим продуктовую команду из шести человек, которая ведет каталог курсов. У команды уже есть общий Definition of Done из шести пунктов: изменение проверено коллегой, пройдены согласованные автоматические проверки затронутого модуля, результат виден в тестовой среде, по изменению обновлена короткая рабочая заметка при изменении пользовательского поведения, нет известных блокирующих дефектов в согласованном сценарии, владелец продукта может просмотреть результат.

Теперь команда берет отдельную задачу: после успешной отправки формы консультации пользователь должен увидеть подтверждение. Для этой карточки договорились о четырех критериях приемки: 1) при заполненных обязательных полях показывается блок подтверждения; 2) если обязательное поле пустое, отправка не происходит и ошибка показана рядом с полем; 3) если сохранение на сервере не удалось, сообщение об успехе не показывается, а введенные данные остаются в форме; 4) защита от повторного нажатия в эту задачу не входит и будет обсуждаться отдельно.

На первой проверке команда увидела два пропуска. В общих пунктах не хватало короткой заметки для коллег поддержки, потому что изменилось поведение формы. В критериях задачи не прошел сценарий серверной ошибки: форма очищалась, хотя по договоренности данные должны были сохраниться. Формально задача не готова не потому, что «в целом все работает», а потому что оба пропуска проверяемы и зафиксированы.

После доработки команда повторила те же десять проверок и получила 10 из 10. Практический результат такого разделения простой: обсуждение прошло без спора о терминах. Никто не доказывал, что «основная логика уже готова» или что «еще осталось совсем немного». Был виден точный список: один общий недостающий пункт и один частный сценарий задачи.

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

Definition of Done полезно пересматривать на ретроспективе или после повторяющейся проблемы. Если один и тот же тип пропуска всплывает в разных задачах, это кандидат в общий стандарт. Например, если команда уже третий раз забывает обновить заметку для соседней функции, такой пункт имеет смысл закрепить на уровне Definition of Done, а не напоминать о нем в отдельных карточках.

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

Критерии приемки пересматривают в другой точке процесса — во время уточнения бэклога, планирования или при появлении новой информации по самой задаче. Здесь полезны вопросы для читателя, если вы выбираете обучение или настраиваете процесс в команде: кто в вашей работе уточняет сценарии до старта, где фиксируются исключения, как вы проверяете результат самостоятельно и кто помогает обнаружить пропуски до демонстрации?

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

Если хотите углубить тему, в карточке курса Agile: Scrum и Kanban в работе над продуктом указаны блоки про Product Backlog Refinement, ретроспективу и различие между Definition of Done и Definition of Ready. Это полезно именно для отработки границы между общими правилами команды и условиями конкретной задачи.