Персонажи не могут «гулять» из продукта в продукт, но человек, который создаёт их описание, может обращаться к давно созданным образам как за вдохновением, так и за шаблоном описания. Пользовательские истории — это краткое описание функциональности, детали которой должны уточняться в ходе устных обсуждений между заинтересованными лицами проекта. User Story (пользовательская история) — короткая формулировка намерения пользователя и того, что продукт должен сделать для него. При этом нужно учесть, что начальная история не разбивается на две «под-истории», а замещается двумя новыми. Это не разбиение историй на подзадачи для постановки их программистам, это всего лишь переформулировка требований для более эффективного управления ими.
Пользовательские истории изящно вписываются в методики Agile, такие как Scrum и Kanban. В Scrum пользовательские истории добавляют в спринты и отслеживают на диаграммах Burndown в течение спринта. Команды, работающие по методике Kanban, добавляют пользовательские истории в бэклог и пропускают их через рабочий процесс. Именно так Scrum-команды совершенствуют навыки оценки и планирования спринта, повышая точность прогнозов и свою гибкость.
Как правильно написать User Story?
Когда портрет продумали, можно идти и углубляться в анализ — здесь важно выяснить, с какими проблемами может сталкиваться пользователь, чем поможет продукт для решения этой проблемы. На этом этапе хорошо работают опросы и интервью — это помогает получить реальную информацию от целевой аудитории, а также улучшить ее портрет в целом. Прежде чем рассказать о структуре юзер стори, важно понять, для чего они вообще нужны и по каким правилам работают.
На чужих проектах я часто вижу, как результатом проектирования становится сотня артефактов, в которых заказчик не может разобраться. Потом на их основе пишут техническое задание на кучу страниц, которое тяжело воспринимать. Расскажу, как избегать всего этого с помощью пользовательских историй.
Пример функций, расписанных с помощью User Stories
Определение целей пользователей – команда должна понимать, что пользователи хотят достичь, используя продукт. Сложно сделать user stories это однозначный вывод относительно полезности Gherkin. Я много раз пытался начать постоянно использовать его на проекте.
После написания черновика истории следует обсудить ее со стейкхолдерами и, возможно, внести изменения, исправить ошибки. В ходе обсуждения команда ещё не говорит о том, как данная история будет реализована, а обсуждается лишь то, как будет удовлетворяться нужда пользователя. В описании следует отразить и задачи, которые наиболее важны для персонажа в его работе с системой. Это поможет всей команде увидеть нужды персонажа и поможет создать стимул для покупки премиум-версии или подписки.
Начало работы с пользовательскими историями в agile
Вы могли заметить, что у этих двух пользователей совсем разные роли, с разными ожиданиями с разными требованиями к системе. Основная ошибка этой истории — игнорирование роли и персоны пользователя. Пользовательские истории, как уже сказали, много значат для отдела разработки и выпуска удачного продукта.
- Я считал себя «хаотичным раздолбаем», но методики и принципы agile помогли навести порядок в моей повседневной жизни.
- Найти то влияние что вы должны оказать на актера в результате.
- Это помогает команде фокусироваться на том, что действительно важно для пользователей, и создавать продукт, который решает их проблемы.
- Пишите user story не для того, чтобы получить формальные «требования», а чтобы вытащить на свет все важные для вашего продукта, бизнеса и пользователей нюансы.
А для пользователя, как правило, ценность тем выше, чем более полно наш продукт закрывает его сценарий. Ваша задача — спроектировать по шагам действия пользователя в продукте на основе его реального сценария. Плохие User Stories могут привести к недостаточной информации или непониманию требований пользователей. Разработка детальных описаний – для каждой User Story необходимо написать более подробное описание, которое включает в себя шаги, необходимые для ее выполнения. Как посетитель кафе, я хочу, чтобы мой заказ сохранялся где-то, чтобы я мог смотреть историю заказов, распечатать чеки, отправить чеки по email.
Gherkin отлично подходит для описания сложных сценариев с ветвлением, вариантами. Тем не менее, этот способ не вызвал положительные отзывы со стороны (вообще не вызвал) команды разработки https://deveducation.com/ или тестирования. Получается так, что балом в “деталях” к историям правят критерии приёмки – именно на них команда смотрит чаще всего во время оценки и изучения задач.
Пользовательская история — это наименьшая единица работы в методике agile. Это конечная цель, а не возможность, сформулированная с точки зрения пользователя ПО. И это индикатор очень
важной проблемы в написании требований. Мы склонны смешивать наши цели и цели
пользователя.
