Definition of Done: простое средство от болезни «почти готово»
Разработка часто страдает от болезни «почти готово». Это состояние, когда код написан, но функциональность еще не выпущена в продакшен, потому что «еще не дописали тесты», «забыли дополнительное условие» или «дизайнер еще не смотрел».
И такие мелочи тянуться неделями и превращаются в бесконечные доработки.
Definition of Done (DoD) — это ваш «чек-лист качества», который не дает задаче считаться выполненной, пока она не соответствует стандартам команды. Это способ синхронизировать ожидания.
📦 Что включить в DoD (и не превратить в роман)
DoD не должен быть на 3 страницы. Оптимально: 5–7 пунктов, которые покрывают качество, безопасность и готовность к релизу. Пример универсального набора:
✅ Код прошел ревью — все аппрувы получены
✅ Автотесты (unit/integration) написаны, проходят локально и в CI без ошибок
✅ Функционал проверен на dev-окружении и соответствует критериям приемки
✅ Логи, метрики и алерты настроены
✅ Документация / API-спецификация / инструкции для поддержки обновлены
✅ Нет известных критических/блокирующих багов
DoD — это «общая черта» для всех задач. Если хоть один пункт не выполнен, задача не считается закрытой. Никаких «сделаем после релиза».
🛠 Как внедрить DoD
Главное — не делать чек-лист на 50 пунктов, который никто не читает или «прокликивают» через python-скрипт (да-да, я такое встречал 😁).
Пишите вместе, а не спускайте сверху. DoD должен рождаться на ретроспективе или планировании. Команда сама решает, что для них значит «качественно сделано».
Начните с 3–4 пунктов. Не пытайтесь охватить всё и сразу. Лучше рабочий минимум, чем идеальный, но неисполнимый документ.
Интегрируйте в workflow, а не в Wiki или Confluence. Пункты DoD должны быть чекбоксами в Jira/YouTrack/Gitlab или частью CI/CD pipeline. Автоматизируйте всё, что можно: линтеры, сборки, прогоны тестов.
Изменяйте, когда нужно. DoD — живой контракт. Каждый спринт спрашивайте: «Этот пункт всё ещё нужен? Не тормозит ли он без причины?» Удаляйте лишнее, добавляйте только при повторяющихся инцидентах.
Чётко разделяйте DoD и Критерии приемки. Критерии приемки описывают, что должно работать в конкретной задаче. DoD описывает, как это должно быть сделано в принципе. Они дополняют друг друга, а не дублируют.
💡Некоторые выводы
DoD — это договоренности о том, что значит задача готова. Когда команда фиксирует критерии готовности — уходит хаос, снижается число возвратов задач и переделок. Становится проще соблюдать ранее оговоренные сроки.
Начните с внедрения 5–7 критериев, которые защищают от «почти готово». Внедряйте DoD в чек-лист задачи/MR, а не в отдельном документе.
#management #processes #agile #TeamLead #team #DoD
Разработка часто страдает от болезни «почти готово». Это состояние, когда код написан, но функциональность еще не выпущена в продакшен, потому что «еще не дописали тесты», «забыли дополнительное условие» или «дизайнер еще не смотрел».
И такие мелочи тянуться неделями и превращаются в бесконечные доработки.
Definition of Done (DoD) — это ваш «чек-лист качества», который не дает задаче считаться выполненной, пока она не соответствует стандартам команды. Это способ синхронизировать ожидания.
📦 Что включить в DoD (и не превратить в роман)
DoD не должен быть на 3 страницы. Оптимально: 5–7 пунктов, которые покрывают качество, безопасность и готовность к релизу. Пример универсального набора:
✅ Код прошел ревью — все аппрувы получены
✅ Автотесты (unit/integration) написаны, проходят локально и в CI без ошибок
✅ Функционал проверен на dev-окружении и соответствует критериям приемки
✅ Логи, метрики и алерты настроены
✅ Документация / API-спецификация / инструкции для поддержки обновлены
✅ Нет известных критических/блокирующих багов
DoD — это «общая черта» для всех задач. Если хоть один пункт не выполнен, задача не считается закрытой. Никаких «сделаем после релиза».
🛠 Как внедрить DoD
Главное — не делать чек-лист на 50 пунктов, который никто не читает или «прокликивают» через python-скрипт (да-да, я такое встречал 😁).
Пишите вместе, а не спускайте сверху. DoD должен рождаться на ретроспективе или планировании. Команда сама решает, что для них значит «качественно сделано».
Начните с 3–4 пунктов. Не пытайтесь охватить всё и сразу. Лучше рабочий минимум, чем идеальный, но неисполнимый документ.
Интегрируйте в workflow, а не в Wiki или Confluence. Пункты DoD должны быть чекбоксами в Jira/YouTrack/Gitlab или частью CI/CD pipeline. Автоматизируйте всё, что можно: линтеры, сборки, прогоны тестов.
Изменяйте, когда нужно. DoD — живой контракт. Каждый спринт спрашивайте: «Этот пункт всё ещё нужен? Не тормозит ли он без причины?» Удаляйте лишнее, добавляйте только при повторяющихся инцидентах.
Чётко разделяйте DoD и Критерии приемки. Критерии приемки описывают, что должно работать в конкретной задаче. DoD описывает, как это должно быть сделано в принципе. Они дополняют друг друга, а не дублируют.
💡Некоторые выводы
DoD — это договоренности о том, что значит задача готова. Когда команда фиксирует критерии готовности — уходит хаос, снижается число возвратов задач и переделок. Становится проще соблюдать ранее оговоренные сроки.
Начните с внедрения 5–7 критериев, которые защищают от «почти готово». Внедряйте DoD в чек-лист задачи/MR, а не в отдельном документе.
#management #processes #agile #TeamLead #team #DoD