Definition of Done в Jira: договоритесь, что значит «готово»

Разработчик завершает изменение и продвигает задачу. Тестировщик обнаруживает, что новый экран работает, но старый сценарий сломан. Поддержка узнаёт о нововведении от растерянного клиента. Все сказали «готово», подразумевая разное.

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

Мы создадим пример для вымышленного портала, отделим общие проверки качества от критериев функции и разместим оба списка рядом с задачей через Definition of Done & AC в Power Pack.

Что такое Definition of Done?

Scrum Guide описывает Definition of Done как стандарт качества, которому должен соответствовать инкремент. Он обеспечивает общее понимание завершённой работы. Организационный стандарт, если установлен, служит минимумом для её Scrum-команд. См. официальный Scrum Guide.

В практическом примере это несколько вопросов для каждого подходящего изменения. Проверена ли реализация? Пройдены ли согласованные проверки? Есть ли информация для поддержки изменения?

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

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

Отделите общее качество от поведения функции

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

Функции нужны свои критерии приёмки. Например, сохранённый выбор остаётся после выхода и нового входа. Это относится к функции, поскольку описывает опыт клиента.

Definition of Done охватывает широкий стандарт завершения. Проверка реализации, затронутого старого поведения и обновление инструкций могут применяться ко многим изменениям.

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

Начните с наблюдаемых пробелов команды

Коротко обсудите работу с разработкой, тестированием и поддержкой. Возьмите недавний пример якобы завершённой работы с неожиданной доработкой.

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

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

Спросите, как проверять каждый пункт. Если никто не опишет доказательства, улучшите формулировку. «Документация завершена» может означать заметки релиза, внутренний проект или клиентскую статью. Определите нужные сведения и место.

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

Составьте практический общий список

Вот первый вариант команды портала. Это пример рабочей договорённости, а не универсальный стандарт.

• Проверка реализации завершена, обязательные замечания устранены.
• Согласованные критерии приёмки задачи проверены.
• Согласованные регрессионные проверки затронутых сценариев аккаунта пройдены.
• Согласованные проверки доступности изменённых экранов пройдены.
• Инструкции поддержки отражают изменённое клиентское поведение.
• Результаты и нужные ссылки на проверки сохранены в Jira.

До применения команда описывает содержание регрессии и доступности. Иначе разные люди отметят одинаковый пункт после разной работы.

Регрессия портала включает вход, открытие настроек и изменение старого поля профиля. Проверка доступности изменённых элементов включает клавиатуру, видимый фокус и понятные подписи. Это примеры выбранных проверок, не полный стандарт доступности.

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

Добавьте стандарт в задачу Jira

Откройте задачу и карточку Definition of Done & AC. В ней отдельные вкладки Acceptance Criteria и Definition of Done. Для общих проверок сначала выберите Definition of Done.

Для короткого списка введите название и нажмите Add или Enter. Название должно содержать одно проверяемое условие. Три несвязанные проверки в длинном предложении затрудняют частичное завершение.

Можно выбрать Bulk Import и вставить Markdown-список: например, шесть пунктов выше с дефисом и пробелом. Обычные Markdown-флажки тоже поддерживаются.

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

Для непроверенной работы берите неотмеченные пункты. Отмеченные Markdown-флажки импортируются завершёнными; скопированные из старой задачи отметки не заменяют проверку новой.

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

Пройдите настоящую проверку

Допустим, настройки готовы к проверке. Maya проверяет клиентские результаты, Priya — согласованную регрессию. Leo устраняет оставшиеся замечания и добавляет ссылку на проверку реализации.

Первый проход показывает правильное сохранение, но исчезновение клавиатурного фокуса после Save. Команда оставляет доступность незавершённой, записывает проблему в Jira и исправляет перед повторной проверкой.

Инструкции поддержки также не готовы. Это видно, хотя критерии функции выполнены. Раздельные списки объясняют оставшуюся работу.

После реального успеха выберите Done. Повторный выбор вернёт пункт к выполнению при новых сведениях. Результаты, ссылки и решения фиксируйте обычным процессом Jira или документации.

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

Внимательно читайте индикатор готовности

Инструмент показывает выполненное и общее количество в каждой вкладке. Ready for Release появляется только при хотя бы одном пункте в обоих списках и завершении всех пунктов. Иначе показывается In Verification.

Правило помогает видеть незавершённое и объясняет, почему полная Definition of Done не даёт общий завершённый статус при пустой Acceptance Criteria.

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

Список также не блокирует переход Jira или слияние pull request. Решайте это обычным процессом поставки и выпуска.

Сохраняйте полезность стандарта при изменениях

Пересматривайте стандарт при повторном дефекте, выявляющем пробел, значимом изменении продукта или утрате полезности проверки.

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

Обновите эталон и обсудите применение к текущей работе. Старые списки не наследуют правку автоматически. Проверьте затронутые задачи и вручную добавьте нужные новые пункты.

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

Попробуйте на текущей задаче

Выберите задачу перед проверкой. Согласуйте короткий стандарт, поместите его в Definition of Done, а конкретные клиентские результаты — в Acceptance Criteria.

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

Польза — более ясный разговор. Услышав «настройки готовы», команда может объяснить работающие результаты, пройденные проверки и основания вывода.

• Scrum Guide — Definition of Done