Пример
Пишем User Stories
Когда собраны все функциональные и бизнес-требования, сформирован глоссарий, пользователи разделены на роли — наконец-то можно писать User Stories.
Формируется команда: аналитик, менеджер проекта, технический директор, разработчики. По возможности мы приглашаем представителей бизнеса со стороны заказчика, либо даём им дополнить уже готовые User Stories. Благодаря наличию разных специалистов, мы можем на старте проговорить, какие есть сложности в реализации фич и какое примерное время понадобится на их разработку. Наша цель — определить, какие функции являются наиболее сложными в разработке и какие — более простыми.
Пишем критерии приёмки
User Story недостаточно, чтобы разработчик понял, что конкретно нужно сделать, а тестировщик мог проверить результат. User Story нужно дополнять критериями приёмки — подробными пунктами с требованиями к создаваемой функциональности. Пользовательская история описывает основную цель новой фичи — как она поможет пользователям. Критерии приемки перечисляют способы работы функциональности с технической точки зрения.
Можно использовать два типа критериев приёмки:
1. Основанные на сценариях. Описание на основе конкретного поведения или последовательности действий пользователя.
Например: При добавлении нового сотрудника Администратор должен заполнить форму — все поля обязательные для заполнения. ЕСЛИ Администратор не заполнил хотя бы одно поле, ТОГДА пользователь не создаётся, внесённые данные должны сохраняться до закрытия формы/закрытия раздела системы.
2. Критерии, как функция должна выглядеть и работать.
Например: 1. Все кнопки должны быть синего цвета. 2. Кнопка «Вход» должна перенаправлять пользователя в Личный кабинет.
Критерии приёмки позволяют любому участнику продакшн-команды проверить, что фича реализована точно так, как мы и задумывали. Так мы формируем единый документ для разработчиком, менеджеров, дизайнеров и QA-инженеров.