Успех проекта в значительной степени зависит от того, как разработчик понимает своего заказчика. Как решение проблем, связанных с рассинхроном или долгим выяснением требований, выдвигаются Критерии приёмки, они же Acceptance Criteria.
Несмотря на простоту концепции, остаётся много вопросов, связанных с AC. В этой статье мы соберём основные моменты, связанные с написанием и применением критериев приёмки.
Что такое критерии приёмки?
Критерии приёмки — это письменно зафиксированные условия, которым должна соответствовать разработанная функциональность. Критерии пишутся на понятном пользователю языке. АС определяют поведение системы с точки зрения того, кто будет её использовать.
Для быстрого объяснения, мы часто используем фразу "Как я, будучи пользователем, пойму, что эта задача сделана?"
Хорошо написанные критерии помогают поднять уровень прозрачности в бизнес-требованиях и избежать неожиданных результатов в конце спринта. Они должны быть:
- трестируемыми и не оставлять поле для вольной интерпретации,
- чёткими и краткими, насколько это возможно,
- написанными простым языком, который сможет воспринять любой участник процесса,
- написанными с точки зрения конечного пользователя (без глубоких/технических деталей).
Кто отвечает за Acceptance Criteria?
Некоторые критерии определяются и пишутся владельцем продукта, когда он создает элемент бэклога. Создание некоторых из них может быть делегировано на команду во время или до груминга, а также вытекать из обсуждения истории на планировании спринта.
На самом деле, тут тоже нет строгих рекомендаций. Тем не менее, чаще всего и наиболее логично, что за АС отвечает владелец продукта, бизнес аналитик или иной продуктовый менеджер, который может быть в структуре ваших команд.
В какой момент спринта нужно писать AC?
Нет универсального совета, но наиболее очевидным кажется подготовить список критериев до сессии разбора бэклога, чтобы затем скорректировать их.
До планирования спринта большая часть АС должна быть подготовлена и закреплена. В противном случае разработка начнётся в высоко неопределённых условиях.
Какой шаблон можно использовать?
Наиболее популярные форматы, которые мы используем, это:
- ориентированные на сценарий (Given/When/Then),
- ориентированные на бизнес-правила.
Также вы можете использовать свой формат, который лучше всего ложится на ваш проект.
Given/When/Then
- Given — предварительные условия,
- When — когда я делаю следующее,
- Then — тогда я получаю определённый результат.
Дополнительные условия можно добавлять через AND.
Классический пример — восстановление пароля:
Сценарий1
- Юзер заходит на страницу входа,
- Когда он нажимает "Восстановить пароль",
- Система присылает ему письмо на электронную почту.
Сценарий2
- Юзер получает ссылку на восстановление пароля через почту,
- Когда он переходит по ссылке,
- Система позволяет ему установить новый пароль.
Модель GWT описывает приёмку верхнеуровнево. Не все команды на практике могут работать с подобным форматом — это зависит от зрелости и профессионализма разработчиков, погружённости в бизнес и, конечно, особенностей продукта.
АС по бизнес-правилам
Формат, ориентированный на правила, складывается, соответственно, из тех самых правил, которые описывают поведение системы.
Чаще всего это маркированный список с перечислением того, что нужно учесть при выполнении истории. Некоторые вещи, такие как требования к интерфейсу, легче показать в прикреплённом файле, чем пытаться описать через правила.
Сколько критериев приёмки должно быть у истории?
У одной истории должен быть минимум один критерий приёмки. Но это не значит, что нужно уместить все в один сценарий/предложение. Вы можете использовать комбинацию сценариев/несколько правил, которых будет достаточно для понимания работы.
Можно ли использовать одни и те же критерии приёмки для всех историй?
Не получится использовать одинаковые критерии, только если вы не занимаетесь копированием задач. Тем не менее, в критериях могут повторяться некоторые переходящие особенности. Например, профайлы, которые должны попасть в исключения, разметка для определённой группы пользователей и т. д.
Если что-то из подобных повторяющихся вещей покрывает абсолютно все пользовательские истории, есть смысл вынести это в Definition of Done.
Как scrum-мастер может помочь владельцу продукта?
Основная задача Scrum-мастера — познакомить команду с этой практикой и убедиться, что АС существуют в удобной и понятной форме. Для этого вы можете использовать чеклисты и тестировать разные модели в течение спринта, собирая обратную связь от команды разработки.
Также рекомендуем отталкиваться от данных и смотреть, сколько задач покрыто АС, как это повлияло на разработку, триггером к чему явилось и т. д.
Основное поле деятельности тут — наладить коллаборацию между владельцем продукта и командой разработки, чтобы вместе создать полноценные, но не слишком сложные критерии приёмки.
