Acceptance criteria

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

Эту страницу открывают, когда требование вроде бы понятно на общем уровне, но по нему невозможно однозначно определить, что считать приемлемым результатом.

Acceptance criteria связывают требование, реализацию, проверку и приёмку в одну линию. Без них проект постоянно спотыкается об разночтения между тем, что было задумано, что было сделано и что в итоге принимается.

Что это за компетенция

Это умение формулировать проверяемые критерии, по которым можно понять, соответствует ли результат ожиданию по конкретному требованию или сценарию.

Acceptance criteria не описывают всю систему целиком. Они уточняют, какой результат приемлем именно в рамках данного требования или кейса.

Зачем нужна

Навык нужен, чтобы:

  • снизить неоднозначность при реализации;
  • сделать проверку результата предметной;
  • улучшить качество постановок;
  • сократить количество возвратов на доработку;
  • связать требования с будущей приемкой.

Где проявляется в реальной работе

Это особенно важно:

  • при уточнении требований;
  • при постановке задач в трекере;
  • при подготовке к тестированию;
  • при работе с DoR и DoD;
  • в проектах, где команда и заказчик часто расходятся в трактовках результата.

Что ломается без неё

  • задача считается готовой по ощущению;
  • тестирование проверяет не то или проверяет слишком поверхностно;
  • заказчик оценивает результат по скрытым ожиданиям;
  • PM не может стабильно принимать работу;
  • постановки выглядят понятными, но порождают много возвратов.

Что можно делегировать, а что нельзя

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

Можно делегировать:

  • детализацию отдельных проверок;
  • помощь QA или аналитика в формулировке;
  • оформление критериев в рабочем шаблоне.

Как выглядит слабый уровень

  • критерии либо отсутствуют, либо слишком общие;
  • внутри одного блока смешано несколько разных сценариев;
  • требования передаются без понятных признаков готовности;
  • приёмка начинается с попытки заново договориться, что вообще нужно было сделать.

Как выглядит сильный уровень

  • критерии привязаны к конкретному требованию или сценарию;
  • они проверяемы и понятны;
  • команда и принимающая сторона используют одну трактовку;
  • по ним можно реально пройтись на демонстрации или тестировании.

Как понять, что это ваш пробел

  • задачи часто «формально готовы», но не проходят показ;
  • QA, разработка и заказчик оценивают результат по-разному;
  • PM трудно быстро ответить, по каким признакам работа должна считаться приемлемой;
  • одна и та же задача возвращается на повторные доработки по ожиданиям.

Что делать пошагово

1. Возьмите одно требование или сценарий. 2. Сформулируйте ожидаемое поведение. 3. Уточните условия, при которых оно должно проявляться. 4. Добавьте критичные ограничения и крайние случаи. 5. Проверьте, можно ли по критерию реально провести проверку. 6. Согласуйте критерии с теми, кто будет выполнять и принимать работу. 7. Зафиксируйте их вместе с требованием.

Практический шаблон

Часто помогает структура:

  • дано;
  • когда;
  • тогда.

Но ключевой критерий не в шаблоне, а в проверяемости и привязке к сценарию.

Практический ориентир

Хорошие acceptance criteria обычно покрывают минимум три вещи:

  • основной сценарий, ради которого вообще существует требование;
  • критичные исключения или ограничения;
  • наблюдаемый результат, который можно проверить на демонстрации, в тестировании или при приёмке.

Если критерии описывают только «счастливый путь», а исключения и границы остаются в голове у участников, возвраты почти неизбежны.

Как отличить хороший критерий от слабого

Слабый вариант:

  • «Пользователь может удобно оформить заявку».

Рабочий вариант:

  • «Если обязательные поля заполнены и данные валидны, пользователь может отправить заявку и получает подтверждение об успешной отправке».

Во втором случае уже видно, что именно проверять, и такой критерий легче связать с критериями приёмки и DoD.

Типовые ошибки

  • писать критерии слишком абстрактно;
  • смешивать независимые сценарии в одном критерии;
  • путать критерии приемлемости с критериями успеха проекта;
  • не обсуждать критерии с теми, кто будет принимать результат;
  • включать в критерии лишние технические детали, не влияющие на приемлемость.

Как качать навык

Связанные материалы