Добавить в корзинуПозвонить
Найти в Дзене
KIT

Definition of Done: простое средство от болезни «почти готово»

Разработка часто страдает от болезни «почти готово». Это состояние, когда код написан, но функциональность еще не выпущена в продакшен, потому что «еще не дописали тесты», «забыли дополнительное условие» или «дизайнер еще не смотрел». И такие мелочи тянуться неделями и превращаются в бесконечные доработки. Definition of Done (DoD) — это ваш «чек-лист качества», который не дает задаче считаться выполненной, пока она не соответствует стандартам команды. Это способ синхронизировать ожидания. DoD не должен быть на 3 страницы. Оптимально: 5–7 пунктов, которые покрывают качество, безопасность и готовность к релизу. Пример универсального набора: ✅ Код прошел ревью — все аппрувы получены
✅ Автотесты (unit/integration) написаны, проходят локально и в CI без ошибок
✅ Функционал проверен на dev-окружении и соответствует критериям приемки
✅ Логи, метрики и алерты настроены
✅ Документация / API-спецификация / инструкции для поддержки обновлены
✅ Нет известных критических/блокирующих багов DoD — это
Оглавление

Разработка часто страдает от болезни «почти готово». Это состояние, когда код написан, но функциональность еще не выпущена в продакшен, потому что «еще не дописали тесты», «забыли дополнительное условие» или «дизайнер еще не смотрел».

И такие мелочи тянуться неделями и превращаются в бесконечные доработки.

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

📦 Что включить в DoD (и не превратить в роман)

DoD не должен быть на 3 страницы. Оптимально: 5–7 пунктов, которые покрывают качество, безопасность и готовность к релизу. Пример универсального набора:

✅ Код прошел ревью — все аппрувы получены
✅ Автотесты (unit/integration) написаны, проходят локально и в CI без ошибок
✅ Функционал проверен на dev-окружении и соответствует критериям приемки
✅ Логи, метрики и алерты настроены
✅ Документация / API-спецификация / инструкции для поддержки обновлены
✅ Нет известных критических/блокирующих багов

DoD — это «общая черта» для всех задач. Если хоть один пункт не выполнен, задача не считается закрытой. Никаких «сделаем после релиза».

🛠 Как внедрить DoD

Главное — не делать чек-лист на 50 пунктов, который никто не читает или «прокликивают» через python-скрипт (да-да, я такое встречал 😁).

  1. Пишите вместе, а не спускайте сверху. DoD должен рождаться на ретроспективе или планировании. Команда сама решает, что для них значит «качественно сделано».
  2. Начните с 3–4 пунктов. Не пытайтесь охватить всё и сразу. Лучше рабочий минимум, чем идеальный, но неисполнимый документ.
  3. Интегрируйте в workflow, а не в Wiki или Confluence. Пункты DoD должны быть чекбоксами в Jira/YouTrack/Gitlab или частью CI/CD pipeline. Автоматизируйте всё, что можно: линтеры, сборки, прогоны тестов.
  4. Изменяйте, когда нужно. DoD — живой контракт. Каждый спринт спрашивайте: «Этот пункт всё ещё нужен? Не тормозит ли он без причины?» Удаляйте лишнее, добавляйте только при повторяющихся инцидентах.
  5. Чётко разделяйте DoD и Критерии приемки. Критерии приемки описывают, что должно работать в конкретной задаче. DoD описывает, как это должно быть сделано в принципе. Они дополняют друг друга, а не дублируют.

💡Некоторые выводы

DoD — это договоренности о том, что значит задача готова. Когда команда фиксирует критерии готовности — уходит хаос, снижается число возвратов задач и переделок. Становится проще соблюдать ранее оговоренные сроки.

Начните с внедрения 5–7 критериев, которые защищают от «почти готово». Внедряйте DoD в чек-лист задачи/MR, а не в отдельном документе.

#management #processes #agile #TeamLead #team #DoD