Story (История) используется для описания нового/изменения ранее реализованного функционала системы с точки зрения потребителей системы (как внешних, так и внутренних).
В общем случае за Бизнес-Историю отвечает назначенный Бизнес-аналитик (BA) / Системный аналитик (SA), за техническую стори отвечает Тех.Лид.
Владелец продукта (РО) отвечает за приоритизацию и оценку затрат на реализацию истории.
Допускается назначать Историю на разработчика, если История слишком мала и нет смысла её детализировать на отдельные подзадачи (Sub-task).
1.Тема (Name) Story
Наименование Story должно быть четко и понятно сформулировано
2.Верхнеуровневое требование (→ цель)
Как <роль/персонаж>, я <что-то хочу получить>, <с такой-то целью>, писать четко и коротко, что необходимо сделать в рамках Story.
3.Допущения/Ограничения
Указываются Story функционал которого затрагивается в текущей Story, но не реализуется.
4.Сценарии (Use case)
Описание вариантов использования, используя следующий паттерн:
- Название варианта использования
- Основные действующие лица (Акторы)
- Предусловие/Триггер
- Основной сценарий
- Альтернативные сценарии
5. Критерии приемки
Функциональные требовая, обязательное условие для работы с историей.
Требования для пользовательской истории, формулировка и критерии приемки. Без них мы не сможем понять, выполнили историю или нет.
Важно ничего не упустить, если вы что-то не пропишете или упустите, то разработчики будут реализовывать так как описано и в конечном итоге функционал будет некорректно работать либо ж иметь множество багов. Также стоит учесть, что критерии приемки должны легко проверяться.
6.Требования к данным
Описываются испольуемые данные в реализуемом фукционале, если применимо.
7.Дополнительная информация
Это раздел должен содержать справочную информацию по реализуемой story:
- Исходные материалы
- Дизайн макеты
- Ссылки на Wiki
