Вы когда-нибудь видели, как команда гордо демонстрирует функцию, а клиент говорит: «Это не то, что мы заказывали» ? Или как релиз, который казался готовым, падает из-за «мелочи», которую никто не проверил? Это — результат отсутствия Definition of Done (DoD).
DoD — это не просто список галочек. Это «качественный фильтр» , который превращает разработку из хаоса в систему. В этой статье мы разберём:
- Как DoD работает, как «страж» на выходе из завода (читай: вашего продукта).
- Почему он — главный «страховщик» от технического долга.
- Как создать DoD, который не станет формальностью, а станет вашим союзником.
Проблемы без DoD: Кейс из жизни
Ситуация:
Команда закончила спринт с фичей «поиска по голосу». Все рады: функция работает, тесты пройдены. Но через неделю клиент плачет: «Поиск не интегрирован с базой данных, и мы не видим результатов» .
Почему это случилось?
Команда не определила DoD для этой задачи. В их понимании «готово» = «работает в песочнице», а не «интегрировано в систему».
Результат:
Переработка, недовольный клиент, потеря репутации.
DoD — как «страж» на выходе: Как он работает?
1. DoD — это «правила выхода» из этапа разработки
- Для этапа «Дизайн»: «Макеты согласованы с заказчиком и DevOps».
- Для этапа «Разработка»: «Код прошёл ревью, тесты и интеграцию».
- Для этапа «Тестирование»: «Баги классифицированы и исправлены».
Пример из практики:
Команда добавила в DoD пункт: «Функция должна работать в браузерах Google Chrome начиная с версии 55.0.2883». Это сократило жалобы клиентов на 30%.
2. DoD — это «проверка на клиентоориентированность»
- Если в DoD есть пункт «Документация для пользователя написана», вы не рискуете, что клиент не поймёт, как пользоваться фичей.
- Если в DoD нет пункта «Кейсы использования», вы рискуете, что функция не решит проблемы клиента.
Как создать DoD, который не станет формальностью?
Секрет №1: Сделайте DoD «живым»
- Нет ❌: «Задача готова, если она работает» .
- Да ✅: «Задача готова, если:
✓ Код прошёл нагрузочное тестирование с 1000 юзерами
✓ Добавлены автотесты
✓ Документация обновлена
✓ DevOps подтвердил, что функция не ломает старые версии» .
Секрет №2: Делайте DoD «съедобным»
Если DoD слишком длинный, команда начнёт его игнорировать.
- Пример:
Для User Story: 5–7 критериев (например, «Тестирование», «Ревью», «Документация», «Интеграция», «Согласование с заказчиком» ).
Секрет №3: Используйте DoD как «проверку» перед релизом
Перед выходом в продакшен проведите «DoD-аудит»:
- Собрать всех: разработчик, тестировщик, Product Owner.
- Проверить: каждая задача в релизе прошла все критерии DoD.
Проблемы внедрения DoD и как их решить
Проблема: «Команда не знает, что входит в DoD»
Решение:
- Создайте DoD в виде чек-листа и обсудите его на встрече.
- Пример:
«Для Task:
[ ] Код отлажен
[ ] Тестирование завершено
[ ] Документация обновлена» .
Проблема: «DoD не меняется годами»
Решение:
- На ретроспективах спрашивайте:
«Что в DoD мешает работе? Что можно добавить?» - Пример:
После жалоб на скорость, добавили пункт «Функция должна загружаться за 2 секунды».
Заключение: DoD — ваш «страховочный купол»
DoD — это не просто список галочек. Это система, которая:
- Снижает риски (технический долг, баги в релизе).
- Улучшает коммуникацию (все понимают, что значит «готово»).
- Создаёт доверие (клиент видит, что вы не «берёте на авось»).
Как начать?
- Обсудите DoD с командой.
- Начните с базовых критериев (например, тестирование и ревью).
- Регулярно обновляйте DoD на ретроспективах.
Подписывайтесь на мой канал — я делюсь практическими кейсами по Agile и delivery. И не забудьте оставить комментарий: как вы используете DoD в своей команде? Возможно, ваши идеи помогут другим!
А вот другие интересные статьи про Agile: