«Я закончил» — ещё не общий стандарт
Definition of Done описывает условия качества готового результата.
Разработчик закончил форму, редактор подготовил тексты, проверяющий нашёл, что подтверждение не приходит. Каждый выполнил свой кусок, но человек всё ещё не может надёжно записаться. Общая договорённость о готовности нужна именно в таком месте: она связывает отдельные действия с пригодным к использованию результатом.
В Scrum Definition of Done относится к состоянию Инкремента и требованиям качества. Ниже используем эту идею на учебном примере формы записи в мастерскую. Конкретные пункты — авторский образец для обсуждения, а не универсальный стандарт, который можно без изменений перенести в любую команду.
- Написано
Код существует, но сценарии ещё не проверены.
- Соответствует DoD
Результат проходит согласованные проверки качества.
- Выпущено
Готовую версию предоставили нужным пользователям.
DoD, критерии приёмки и DoR отвечают на разные вопросы
| Договорённость | Вопрос | Пример |
|---|---|---|
| Definition of Ready | Достаточно ли ясности, чтобы начинать? | Известны поля формы и правила свободных мест. |
| Критерии приёмки | Что должна делать эта конкретная история? | На полностью занятый сеанс записаться нельзя. |
| Definition of Done | Какому общему качеству должен соответствовать результат? | Изменение проверено, интегрировано, известные блокирующие дефекты устранены. |
Критерии одной истории обычно меняются вместе с её назначением. Для отмены записи нужны другие условия, чем для выбора сеанса. Общая планка качества при этом сохраняется: изменения должны работать вместе с остальным продуктом и проходить согласованные проверки.
Definition of Ready — необязательная договорённость команды, а не обязательный элемент Scrum Guide. Не нужно вводить симметричные документы только потому, что рядом существуют два удобных сокращения. Начните с того разрыва, который действительно приводит к переделкам.
Пример Definition of Done для небольшого веб-продукта
В нашей учебной мастерской команда уже согласовала сценарии формы. Теперь она хочет перестать передавать друг другу «почти готовые» изменения. Рабочий черновик DoD может выглядеть так:
- Изменение интегрировано в текущую версию продукта и проверено вместе с затронутыми сценариями.
- Согласованные критерии истории выполнены; результат проверки доступен команде.
- Основной путь и предусмотренные ошибки проверены на согласованных устройствах.
- Не осталось известных дефектов, которые по принятой политике блокируют использование этой версии.
- Пользовательские тексты и затронутые инструкции соответствуют поведению.
- Нужные для сопровождения изменения и ограничения зафиксированы.
Для каждого пункта уточните, где увидеть подтверждение. «Всё протестировано» невозможно однозначно проверить. «Пройден сценарий свободного и занятого сеанса на телефоне и компьютере, результат приложен» уже позволяет обсудить достаточность проверки. Набор устройств выбирают по своему продукту, а не по этому примеру.
Разбираем спорную готовность
Допустим, форма принимает контакт и показывает подтверждение, но при повторном нажатии создаёт две записи. Разработчик считает работу законченной: основной сценарий проходит. Проверяющий возражает: один посетитель может занять два места. Решение зависит не от убедительности участников, а от согласованных условий и влияния дефекта.
Команда воспроизводит проблему, связывает её с критерием недопущения повторной записи и сохраняет пример. Пока этот критерий и общая политика качества не соблюдены, работа не отвечает договорённости о готовности. Перенос дефекта в новую карточку сам по себе не делает исходный результат готовым.
- Наблюдение
Двойное нажатие создаёт две записи.
- Условие
Один запрос не должен занимать два места.
- Действие
Исправить поведение и повторить проверку.
- Свидетельство
Сохранить результат проверки вместе с задачей.
Другая ситуация: форма полностью соответствует DoD, но мастерская запускает набор в понедельник. Готовность и выбранная дата публикации — разные вещи. Ожидание маркетингового анонса не обязано означать, что технический результат не готов; это отдельное решение о выпуске.
Как договориться о стандарте без огромного чек-листа
Соберите два-три недавних случая возврата работы. Выпишите, чего не хватило: совместной проверки, понятных текстов, обработки ошибки или инструкции. Из этих повторяющихся причин получится более полезный черновик, чем из длинного списка чужих требований.
Затем проверьте каждый пункт на конкретном изменении. Кто может увидеть, что он выполнен? Доступна ли нужная среда? Что происходит, если проверка не проходит? Если ответы неизвестны, пока перед вами пожелание, а не рабочая договорённость.
Не превращайте DoD в описание всех этапов процесса. «Созвонились в среду» — действие, которое может не влиять на качество результата. «Проверяющий смог воспроизвести сценарий и увидеть ожидаемый итог» — условие с понятным смыслом. Оставляйте в документе второе, а организационные привычки обсуждайте отдельно.
Кто отвечает и когда пересматривать
Готовность не стоит делать личной магией одного проверяющего. Участники должны одинаково понимать стандарт и знать, где лежат свидетельства. Если несколько команд работают над одним продуктом в Scrum, им нужна общая Definition of Done для согласованного качества Инкремента.
Пересмотр полезен после повторяющегося дефекта, изменения продукта или обнаружения ненужной проверки. Запишите новую версию и момент применения. Нельзя задним числом незаметно ослабить критерии только для того, чтобы текущий отчёт стал зелёным.
Если хочется сразу добавить двадцать пунктов, оцените стоимость каждого. Проверка должна защищать от конкретного риска. Иногда автоматизация делает стандарт дешевле; иногда достаточно убрать двусмысленное слово. Сам по себе объём документа качество не повышает.
Где сохранить рабочий результат
В Sinqly можно создать задачу «Проверить готовность формы записи» и добавить в описание общую договорённость о качестве и ссылки на результаты конкретных проверок; регистрация бесплатная.
Что проверить перед словом «готово»
Возьмите последнюю завершённую задачу и спросите: мог ли другой участник понять, почему она готова, без личного сообщения исполнителю? Если нет, добавьте не новый статус, а недостающее свидетельство: проверенный сценарий, результат теста или ссылку на согласованный документ.
После этого сравните два следующих результата по одному стандарту. Цель не в том, чтобы запрещать завершение любой мелочи, а в том, чтобы слово «готово» перестало менять значение от человека к человеку.
Критерии приёмки конкретной задачи помогают дополнить общий стандарт ожидаемым поведением.
Что ещё стоит уточнить
DoD — это список тестов?
Не только. Он описывает необходимые условия качества готового результата. Проверки могут подтверждать часть этих условий, но сам стандарт шире отдельного набора тестов.
Можно ли показать незавершённую работу?
Можно обсуждать прогресс и получать обратную связь, честно называя состояние. Это не делает работу соответствующей Definition of Done и не превращает её в готовый Инкремент Scrum.
Нужно ли отдельное DoD на каждую задачу?
Обычно общую планку качества переиспользуют, а особенности задачи описывают критериями приёмки. Иначе слово «готово» снова получает множество значений.
Помогло разобраться?
Оцените статью и расскажите, чего не хватило. Отзыв увидит редакция Sinqly — он не появится на сайте.
Источники и примечания
- Scrum Guide 2020: Definition of Done
- Предлагаемый порядок — редакционная практика, а не обещание одинакового результата для всех.
Критерии приёмки задачи: как написать и проверить, с примерами
Наблюдаемые условия вместо «сделать хорошо»: критерии приёмки формы, позитивные и негативные сценарии, границы задачи и разбор спорного результата.
Definition of Ready: как подготовить задачу к работе без бюрократии
Пример Definition of Ready для команды: что уточнить до старта, как обращаться с неизвестностью и почему DoR не должен становиться жёстким пропускным пунктом.
Scrum простыми словами: роли, события и артефакты на одном примере
Как устроен Scrum: ответственность участников, события, артефакты и короткие циклы проверки. На учебном примере продукта, без обещания универсальной методологии для всех команд.