Что такое критерий готовности?

Что такое критерий готовности (Definition of Ready, DoR)?

Критерий готовности (DoR) — это набор четко определенных, согласованных и проверяемых условий, которым должна соответствовать пользовательская история (или другая единица работы) до того, как она будет принята в спринт для разработки. Это инструмент планирования и управления качеством входа, который помогает командам избежать недопонимания, расплывчатых требований и потери времени в ходе итеративной работы. Основная цель DoR — убедиться, что история понятна, осуществима и готова к немедленному старту работы, минимизируя риски блокировок и переделок.

Ключевые цели и преимущества использования DoR:

• Повышение эффективности планирования спринта: Команда тратит меньше времени на выяснение деталей во время планирования, так как основные вопросы решены заранее.
• Снижение числа блокировок: Устранение неясностей до старта разработки предотвращает простой из-за ожидания уточнений от продукт-оунера или бизнес-аналитика.
• Улучшение предсказуемости: Когда все истории в бэклоге продукта соответствуют DoR, оценка емкости спринта становится более точной.
• Повышение качества и фокуса: Команда концентрируется на реализации, а не на анализе сырых требований. Это прямо влияет на качество кода и продукта.
• Разделение ответственности: Продукт-оунер и команда разработки имеют ясный чек-лист для совместной подготовки backlog items.

Типичные компоненты критерия готовности:

Конкретные пункты DoR варьируются от команды к команде, но обычно включают:

• Четкая ценность для пользователя: История имеет ясную формулировку ценности (как часть формата: "Как [роль], я хочу [функцию], чтобы [получить выгоду]").
• Детализированные критерии приемки (Acceptance Criteria, AC): Существует согласованный, исчерпывающий список условий, определяющих, что работа выполнена правильно. Часто оформляются в виде сценариев (Given-When-Then).
• Дизайн и UX-требования: При необходимости готовы и согласованы макеты, прототипы, пользовательские сценарии.
• Технические требования и ограничения: Определены зависимости, нефункциональные требования (производительность, безопасность), архитектурные решения.
• Возможность оценки: Команда может оценить объем усилий (в story points, часах). Отсутствие оценки часто сигнализирует о недостаточной ясности.
• Размер истории: История достаточно мала, чтобы быть выполненной в рамках одного спринта (соблюдение принципа INVEST, особенно "Small").
• Определены зависимости: Известны все внутренние и внешние зависимости, и есть план по их разрешению.
• Готовность тестовых данных и окружения: Понимание, какие данные нужны для разработки и тестирования, и их доступность.

Пример применения DoR на практике (псевдокод оформления истории)

Представим, что у нас есть история в бэклоге продукта. Перед тем как переместить ее в спринт, мы проверяем соответствие DoR.

Исходный статус (НЕ ГОТОВ):

[US-101] - Улучшить поиск на сайте.
Acceptance Criteria:
1. Поиск должен работать быстрее.
Комментарий команды: "Слишком расплывчато. Что значит "быстрее"? На каких страницах? Какие поля искать?"

Работа по уточнению (Grooming/Refinement): Продукт-оунер, аналитик и разработчики совместно детализируют историю.

Статус после уточнения (ГОТОВА к спринту):

### **User Story: [US-101] - Реализовать полнотекстовый поиск по статьям в блоге**
**Как** читатель блога,
**Я хочу** мгновенно находить статьи по ключевым словам в заголовке и содержании,
**Чтобы** быстро получать нужную информацию, не просматривая все материалы вручную.

---

### **Критерии приемки (AC):**
**AC1: Базовый поиск**
*   Дано: Я нахожусь на странице блога.
*   Когда: Я ввожу слово "Agile" в строку поиска в шапке сайта и нажимаю Enter.
*   Тогда: Мне отображается список из всех статей, где слово "Agile" встречается в заголовке (title) или основном тексте (body).
*   И: Результаты отсортированы по релевантности (точное совпадение в заголовке -> в тексте).
*   И: Для каждой статьи в результатах показывается заголовок, дата публикации и фрагмент текста с подсвеченным искомым словом.

**AC2: Поиск с уточнением**
*   Дано: Я выполнил поиск по слову "Agile" и вижу более 10 результатов.
*   Когда: Я активирую чекбокс "Только в заголовках".
*   Тогда: Список результатов обновляется, оставляя только статьи с словом "Agile" в заголовке.

**AC3: Производительность (Non-functional)**
*   Время отклика поискового запроса (от нажатия Enter до отображения результатов) не должно превышать **300 мс** при 95-м процентиле (p95) на нагрузке до 100 параллельных запросов.

---

### **Дополнительные пункты DoR (подтверждены):**
*   **Дизайн:** Макет страницы результатов поиска (Figma) утвержден.
*   **Технические требования:** Для реализации использовать ElasticSearch. Индексация новых статей должна происходить не позднее 5 минут после публикации.
*   **Зависимости:** Настройка ElasticSearch кластера (задача DEV-321) будет завершена к началу целевого спринта.
*   **Оценка:** Командой оценена в **5 story points**.
*   **Тестовые данные:** База данных с 10к тестовых статей для проверки производительности готова в среде Stage.

Роль Project Manager / Scrum Master в обеспечении DoR

Как руководитель проекта, я считаю поддержание Definition of Ready критически важной практикой. Моя роль заключается в:

1. Фасилитации сессий уточнения бэклога (Backlog Refinement): Организую и веду регулярные встречи, где команда вместе с продукт-оунером "шлифует" истории до состояния готовности.
2. Контроле и напоминании: Слежу, чтобы на планировании спринта рассматривались только истории, соответствующие DoR. Если история не готова — она не включается в спринт.
3. Эволюции DoR: Помогаю команде периодически пересматривать и адаптировать чек-лист DoR, чтобы он оставался актуальным и полезным, отражая накопленный опыт и специфику проекта.
4. Защите команды: Не допускаю ситуации, когда в спринт "втискивают" сырые требования под давлением дедлайнов, так как это прямой путь к техническому долгу и срыву итерации.

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