User story
Очень важно однозначно для всех интерпретировать требования. Для этого есть много форматов, один из популярных User Story или Пользовательская история. Собрав требования, можно наполнить бэклог, разбив истории по эпикам. После этого приступить к проектированию пользовательского пути.
Формат написания:
Как <роль или тип пользователя>, я хочу/могу <выполнить действие или получить результат>, чтобы <получить ценность>.
- Важно указывать ценность, потому что это дополнительная проверка на необходимость разработки, здравый смысл и инструмент для создания метрики.
- К US нужно указывать критерии приемки.
- Уровень абстракции определяется внутри команды.
Пример:
Как специалист ОЦОП, я хочу создать карточку кандидата, чтобы зафиксировать его данные и наполнить базу.
Критерии приемки:
- Возможность указать персональные данные кандидата.
- Возможность вставить скопированные ФИО.
- Возможность проверить карточку на дубликат.
- Возможность указать данные о вакансии.
Мы рекомендуем использовать формат пользовательских историй для сбора требований.
Исчерпывающие руководства есть в интернете, например:
- Та самая статья на Medium
- User Story: пора применять правильно
- Для увлекающихся – Use Case
- Альтернативный подход – JTBD