Ответ.

Исторически формулирование критериев приемки (acceptance criteria) оставалось в руках тестировщиков или команды разработки. Однако с переходом к гибким масштабируемым процессам (SAFe, LeSS, Scrum-of-Scrums) без формализованных сценариев тестирования появляются риски расхождения в ожиданиях у разных участников большого проекта: бизнес, тестирование, девелоперы и поддержка могут по-разному трактовать завершённость задачи.

Проблема в мультикомандных или распределённых проектах: различные зоны ответственности, разные процессы и инструменты, языковые или культурные отличия между командами. Даже детально проработанные требования могут превратиться в конфликтные или неполные acceptance criteria, что влечёт за собой баги и недовольство бизнеса.

Решение — вовлечение системного аналитика на ранних стадиях формирования acceptance criteria, стыковка требований между командами, жёсткая формализация и совместное обсуждение сценариев и эджей (edge-cases) на общем демо или групповом воркшопе.

Ключевые особенности:

• Acceptance criteria должны быть однозначны, измеримы, воспроизводимы и валидируемы.
• Предварительное согласование критериев (ручной чек-лист + примеры ожидаемых данных/поведения).
• Взаимная трассировка: критерии всегда должны ссылаться на требования, кейсы и user stories, чтобы можно было отследить каждую цель.

Вопросы с подвохом.

Можно ли оставить формулирование acceptance criteria целиком на тестировщиков?

Нет, аналитик обязан участвовать. Только он владеет полнотой бизнес-контекста и знает все нюансы требований.

Нужно ли покрывать acceptance criteria только позитивные сценарии?

Нет, обязательно добавлять негативные и граничные случаи (edge cases), иначе возникнут пробелы в реализации и тестировании.

Можно ли определять acceptance criteria устно в мульти-командных проектах?

Нет, устные договоренности не выдерживают нагрузки распределённого взаимодействия и приводят к конфликтам. Критерии принимаются только формализовано (например, в виде Gherkin/BDD или структурированных чек-листов).

Типовые ошибки и анти-паттерны

• Формулировка acceptance criteria "по умолчанию", без ссылок на требования и спецификации.
• Отсутствие обратной связи от конечных команд.
• Игнорирование сценариев взаимодействия между компонентами разных команд, особенно при интеграциях.

Пример из жизни

Негативный кейс: В банкинговом приложении acceptance criteria для функционала переводов были согласованы только с одной командой. Вторая команда реализовала свои внутренние интерфейсы без учёта первого блока критериев, что привело к расхождению форматов ID транзакций.

Плюсы:

• Быстрое начало реализации.

Минусы:

• Необходимость рефакторинга API.
• Потеря времени на урегулирование коллизий.

Положительный кейс: Аналитик провёл серию воркшопов с визуальными сценариями и деталями для всех участвующих команд, с обязательной письменной фиксацией acceptance criteria в Confluence/JIRA с двусторонней трассировкой к требованиям.

Плюсы:

• Исключение двусмысленности.
• Быстрое детектирование и уход от потенциальных багов.

Минусы:

• Увеличение времени на предпроектное согласование.