Что такое Definition of Done (DoD)?

Определение Definition of Done (DoD)

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

Это понятие является фундаментальным в гибких методологиях разработки (Agile, Scrum, Kanban). DoD действует как контрольный список или "выходные ворота" качества, обеспечивая, что все работы выполняются с одинаковым уровнем тщательности и ни один критический шаг не пропускается. Это позволяет избежать ситуаций, когда разработчик считает задачу "сделанной" после написания кода, но тестировщик обнаруживает, что она не протестирована, или когда готовый инкремент нельзя развернуть в production.

Ключевые аспекты и преимущества DoD

1. Единое понимание "готовности": Устраняет разрыв в восприятии между разработчиками, тестировщиками, аналитиками и продакт-оунером. Все одинаково понимают, что значит "готово".
2. Повышение прозрачности и предсказуемости: Позволяет команде реалистично оценивать свою скорость (velocity) и давать прогнозы.
3. Встроенное качество (Quality Built-In): Гарантирует, что качество проверяется на каждом шаге, а не откладывается на конец цикла (waterfall подход). Критерии DoD часто включают требования к тестированию, безопасности и производительности.
4. Снижение технического долга: Чёткие требования к завершению (например, "код проверен в Code Review", "написаны юнит-тесты", "документация обновлена") предотвращают накопление недоделок.
5. Формирование инкремента, готового к релизу: Основная цель в Scrum — по итогам каждого спринта создать готовый к выпуску инкремент продукта. DoD — это инструмент для достижения этой цели.

Типичные элементы DoD для задачи (User Story)

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

• Код написан и соответствует принятым стандартам (например, пройден линтер).
• Код проверен через процедуру Code Review и все замечания устранены.
• Написаны и успешно выполнены юнит-тесты с заданным порогом покрытия кода.
• Интеграционные / API-тесты созданы и пройдены.
• Ручное функциональное тестирование QA Engineer завершено (позитивные и негативные сценарии, проверка граничных значений).
• Выполнено нефункциональное тестирование (если применимо): проверка на кросс-браузерность, адаптивность, базовое тестирование производительности.
• Авто-тесты для регрессионной проверки созданы и добавлены в CI/CD пайплайн.
• Все acceptance criteria из User Story подтверждены (часто через демонстрацию продакт-оунеру).
• Артефакты обновлены: документация (техническая, пользовательская), диаграммы, комментарии в задаче.
• Код смержен в основную ветку (main/trunk) и успешно собран на CI-сервере.

Отличие DoD от Acceptance Criteria (AC)

Это важное различие:

• Acceptance Criteria (Критерии приёмки) — это специфические, уникальные условия, определяющие что делает конкретная User Story. Это функциональные требования к фиче ("При вводе некорректного пароля отображается сообщение об ошибке").
• Definition of Done — это общие, повторяющиеся от задачи к задаче условия, определяющие как мы завершаем любую работу. Это требования к процессу и качеству ("Код проверен, протестирован, задокументирован").

Пример DoD в контексте процесса (псевдокод задачи)

### Задача: TASK-777 - Добавить валидацию email при регистрации

**Acceptance Criteria:**
1. Поле "Email" проверяет формат.
2. При невалидном email под полем отображается красное сообщение.
3. Кнопка "Зарегистрироваться" неактивна, пока email невалиден.

**Definition of Done (общее для команды):**
- [x] Код написан и соответствует ESLint rules.
- [x] Проведен и одобрен Code Review (2 аппрува).
- [x] Покрытие юнит-тестами >80%.
- [x] API-тест для эндпоинта /register добавлен в коллекцию Postman.
- [x] Ручное тестирование QA пройдено (чек-лист выполнен).
- [x] Авто-тест на валидацию email добавлен в регрессионную сьюту.
- [x] Изменения смержены в ветку `main`.
- [x] Сборка в Jenkins прошла успешно (#build-4512).
- [x] Демонстрация выполнена продакт-оунеру.

Создание и эволюция DoD

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

• Видимым (вывешен на информационном радиаторе или в Wiki).
• Достижимым (критерии реалистичны в рамках одного спринта).
• Актуальным (регулярно пересматривается на ретроспективах). Например, команда может добавить пункт "Статический анализ безопасности (SAST) пройден" после изучения уязвимости в прошлом спринте.

Вывод: Definition of Done — это не бюрократическая формальность, а мощный инструмент команды для гарантии качества, дисциплины и создания по-настоящему готового продукта на каждой итерации. Для QA Engineer понимание и активное участие в формировании DoD критически важно, так как именно тестирование обеспечивает выполнение многих его ключевых пунктов.

Что такое Definition of Done (DoD)?

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

Основная цель и ценность DoD

Цель DoD — устранить неоднозначность и предотвратить ситуацию, когда задача считается "сделанной" разными участниками по-разному. Это страховка от недоделок и технического долга. Ее ценность заключается в:

• Единое понимание "Готово": Все в команде — от разработчика до продакта — знают, что значит "задача завершена".
• Повышение качества продукта: DoD служит чек-листом, гарантирующим, что к коду применены все необходимые стандарты и проверки.
• Ускорение процессов: Сокращает время на обсуждения и доработки, так как требования к завершению ясны изначально.
• Прозрачность для стейкхолдеров: Менеджеры и заказчики видят объективные критерии приемки работы.
• Основа для автоматизации: Многие пункты DoD (например, запуск тестов) могут и должны быть автоматизированы.

Ключевые составляющие DoD

DoD обычно включает в себя критерии из разных областей, формируя многоуровневый чек-лист. Вот типичные пункты:

• Критерии завершенности кода:

    *   Код написан, проведен **code review** как минимум одним другим разработчиком.
    *   Все комментарии по ревью учтены.
    *   Код соответствует принятым в команде **стандартам оформления (coding standards)** и правилам **статического анализа**.

• Критерии тестирования:

    *   Разработчиком написаны и успешно пройдены **модульные (unit) тесты**.
    *   Написаны и успешно пройдены **интеграционные тесты** (при необходимости).
    *   **Автоматизированные регрессионные тесты** обновлены или созданы для новой функциональности.
    *   Проведено **ручное тестирование** (smoke, функциональное) тестировщиком (QA Engineer) и все дефекты исправлены.
    *   Выполнено **нефункциональное тестирование** (если применимо: производительность, безопасность, UX).
    *   Код покрывает **приемочные критерии (Acceptance Criteria)** пользовательской истории.

• Критерии сборки и интеграции:

    *   Код успешно **скомпилирован/собран** в основной ветке (main/trunk).
    *   Все **автоматизированные тесты (пайплайн CI/CD)** прошли успешно.
    *   Не произошло **регрессии** в существующей функциональности.

• Критерии документации:

    *   Обновлена **техническая документация** (API, схемы БД).
    *   Обновлена **пользовательская документация** (help, релизные notes) или созданы задачи на ее обновление.
    *   Код **самодокументирован** (осмысленные имена переменных, функций, комментарии для сложной логики).

• Операционные и релизные критерии:

    *   Код **деплоится** на тестовое/стейджинг-окружение без ошибок.
    *   Проведено **тестирование на стейджинг-окружении** (UAT, если требуется).
    *   **Метрики и логирование** для новой функциональности настроены.

Практический пример DoD для задачи

Для небольшой фичи команда может иметь такой DoD (как чек-лист в задаче):

### Definition of Done
- [ ] Код написан и соответствует стандартам ESLint/Prettier.
- [ ] Проведен code review, все замечания исправлены.
- [ ] Модульные тесты написаны и проходят (覆盖率 >80%).
- [ ] Интеграционные тесты в CI/CD пайплайне проходят успешно.
- [ ] Функциональность проверена QA на тестовом окружении.
- [ ] UI/UX соответствует макетам из Figma.
- [ ] Обновлена документация API (Swagger).
- [ ] Код влит в ветку `main` и деплой на стейджинг прошел без ошибок.

DoD в контексте роли QA Engineer

Для инженера по обеспечению качества DoD — это основной рабочий инструмент и гарантия, что его вклад будет учтен. QA активно участвует в формировании и совершенствовании DoD, особенно в части, касающейся тестирования. Он следит за тем, чтобы:

1. Критерии тестирования были конкретными и проверяемыми.
2. DoD соблюдалась перед тем, как задача попадает в тестирование (например, код с непройденными unit-тестами не должен передаваться QA).
3. DoD эволюционировала вместе с продуктом и процессами команды (например, добавление пунктов по безопасности или доступности).

Важное различие: DoD vs Acceptance Criteria (AC)

Часто происходит путаница. Acceptance Criteria — это специфичные для одной пользовательской истории условия, которые описывают что должно делать приложение с точки зрения бизнеса/пользователя ("Когда пользователь нажимает X, то происходит Y"). DoD — это общие для всех задач технические и процессуальные условия, которые описывают как и с каким качеством работа должна быть выполнена ("Код отрецензирован, тесты проходят").

Вывод: Definition of Done — это не формальность, а краеугольный камень культуры качества в agile-командах. Это живой документ, который требует согласия всей команды и периодического пересмотра, но его наличие кардинально повышает предсказуемость, скорость и надежность процесса разработки, позволяя уверенно говорить: "Эта задача действительно сделана".