В пользовательской истории сказано: «Оператор быстро выгружает отчёт». Как сформулировать критерий приёмки, чтобы результат можно было однозначно проверить?
Нужно заменить слово «быстро» наблюдаемым условием с измеримым пределом, контекстом проверки и ожидаемым результатом. Например: «При выгрузке отчёта за период до 30 дней и объёме до 100 000 строк файл формируется не более чем за 10 секунд в 95% проверок». Такой критерий позволяет однозначно определить, выполнено требование или нет.
Пользовательские истории и критерии приёмки получили широкое применение в итеративной разработке, где требования уточняются постепенно, а результат регулярно проверяется представителем бизнеса. Исходная проблема состояла в разрыве между кратким описанием пользовательской ценности и конкретным пониманием того, что считать готовым результатом.
Критерии приёмки стали способом зафиксировать границу приемлемого поведения без преждевременного описания внутренней реализации. Они помогают заказчику, аналитику, разработчику и тестировщику одинаково понимать ожидаемый результат.
Слово «быстро» зависит от ожиданий человека, объёма данных, периода отчёта, нагрузки и характеристик среды. Один участник команды может считать приемлемыми 5 секунд, другой — 30 секунд, поэтому формулировка не задаёт проверяемого результата.
Если оставить требование расплывчатым, команда рискует принять функциональность с неудовлетворительной производительностью или, наоборот, потратить время на недостижимый показатель. Дополнительный риск возникает, если не указать условия проверки: одинаковый предел нельзя применять к отчёту из ста строк и к отчёту из миллиона строк.
Сначала нужно уточнить смысл слова «быстро»: какой отчёт проверяется, какой объём данных и период допустимы, от какого события измеряется время, какой результат должен получить оператор и какая доля запусков должна соответствовать пределу. Затем эти условия формулируются как наблюдаемое поведение системы.
Хороший критерий обычно содержит:
Критерий не должен описывать способ реализации, если это не является отдельным ограничением. Требование «выгрузка выполняется не более чем за 10 секунд» проверяет пользовательский результат, а требование «использовать конкретный механизм фоновой обработки» уже задаёт решение и может необоснованно ограничить команду.
Один критерий не обязан описывать все аспекты функции. Для отчёта могут потребоваться отдельные критерии для корректности данных, формата файла, поведения при превышении объёма и обработки ошибки. При этом показатели производительности должны быть достижимыми и проверяться в согласованной среде, иначе критерий будет формально точным, но практически бесполезным.
Заказчик попросил сделать выгрузку «быстрой». Рассматривались два варианта: оставить формулировку на усмотрение команды или сразу установить жёсткий предел в одну секунду для любого отчёта. Первый вариант быстро согласуется, но оставляет спор о готовности; второй создаёт ясную цель, но может быть технически и экономически неоправданным для больших объёмов данных.
После анализа выяснилось, что большинство операций относится к отчётам до 100 000 строк, а оператору важно получить файл не позднее чем через 10 секунд. Выбран критерий: «Для отчёта за период до 30 дней объёмом до 100 000 строк файл доступен оператору не более чем через 10 секунд после запуска выгрузки в 95% проверок».
Для больших отчётов добавили отдельное согласованное поведение: система показывает статус подготовки и уведомляет оператора после завершения. В результате обычный сценарий получил измеримую границу, а редкий тяжёлый сценарий не был искусственно подчинён неподходящему пределу.
Нельзя самостоятельно подменять отсутствие решения выдуманным числом. Аналитик должен выяснить, от чего зависит приемлемость: от нормативного срока, текущего процесса, ожиданий пользователя, объёма данных или стоимости операции.
До появления точного значения можно зафиксировать измерительный подход, собрать базовые показатели и оформить временное допущение как открытый вопрос. Критерий станет окончательным только после согласования владельцем требования; иначе число будет выглядеть объективным, хотя фактически не имеет бизнес-основания.
Критерий приёмки относится к конкретной пользовательской истории и проверяет её ожидаемый результат. Определение готовности задаёт общие условия для всех или группы работ, например наличие проверок, документации или прохождение обязательного процесса.
Критерий может требовать, чтобы конкретная выгрузка укладывалась в установленный предел, а определение готовности — чтобы результат был протестирован и согласован. Смешивание этих уровней приводит либо к повторению общих правил в каждой истории, либо к пропуску специфических условий функции.
Нет, если отказ или граничный случай существенно влияет на ценность и безопасность функции. Для выгрузки важно определить не только нормальное время формирования файла, но и поведение при превышении допустимого объёма или временной недоступности данных.
Однако не следует превращать один критерий в длинное описание всех возможных ситуаций. Основной успешный сценарий и значимые альтернативы лучше оформить отдельными критериями или сценариями, чтобы каждый результат можно было независимо проверить и связать с конкретным бизнес-ожиданием.