Юзер стори описывает задачу так, чтобы она описывала потребности клиента, который будет пользоваться продуктом. Для команд разработчиков, которым agile в новинку, пользовательские истории кажутся лишним шагом. Почему бы просто не разбить большой проект (эпик) на несколько шагов, а потом разбираться с ними?
Цель — это выгода, которую Персонаж хочет получить, или проблема, которую он надеется, решить с использованием продукта. При этом нужно учесть, что начальная история не разбивается на две «под-истории», а замещается двумя новыми. Это не разбиение историй на подзадачи для постановки их программистам, это всего лишь переформулировка требований для более эффективного управления ими. На переговорах мы стараемся вытянуть из него максимальную информацию о том, чего хочет пользователь. Полезность юзер стори прежде всего в том, что они помогают разработчику лучше понять область, продукт, аудиторию заказчика.
Пример истории пользователя: эмоджи
Переделаем историю на влияние — “Как инвестиционный аналитик я получаю отчет №17 об инвестициях БЫСТРЕЕ”. Вы указываете в АС что отчет должен формироваться за 15 сек. В конце понятно выполнено ли АС, понятно какие влияние вы оказали на работу аналитика.
Статья будет полезная Junior-специалистам, которые так или иначе работают с документацией на проекте. В статье рассматриваются как сами пользовательские истории, так и критерии, по которым можно написать хорошую историю. Из статьи читатель сможет подчерпнуть и как писать истории, и как правильно дополнить их деталями, и какие детали важны, и как не перегрузить историю. Эпики — это по сути те же истории пользователей, но они включают несколько и содержат описание функционала приложения и его задач. Обычно эпики используют, чтобы не перегружать список с общими задачами.
Как добавить деталей к истории?
Это все еще отличается от множества работ, которые необходимы для реализации одной пользовательской истории. Пользовательская история, User Story — это короткое, «минималистичное» описание задачи, которое формулируется как описание заинтересованным пользователем продукта желаемого функционала от продукта. История должна побуждать обсуждения, и эти обсуждения должны вестись, когда создается история. Этот принцип довольно легко запомнить по самому названию — пользовательская история это именно ИСТОРИЯ.
- Кто–то считает, что юзер стори — это что–то вроде небольшого описания задания разработчику.
- Таким образом можно сделать вывод, что User Stories — это эффективный инструмент для понимания потребностей пользователей и определения функциональности, которая реально нужна в системе.
- И мы можем подогнать наш
процесс разработки к этой растущей
сложности. - Отвечаем — многие топовые компании по разработке ПО, игр или приложений работают по методике Scrum, которая основывается на образе мышления Agile.
- В статье Иван Дубровин рассказывает, как выстроить стратегию тестирования бизнес-идеи до этапа разработки.
- Пользовательские истории — это небольшое и удобное в работе представление информации.
Как потребитель я, отбирая книги для покупки, хочу класть сразу каждую в корзину. Как управляющий по выпуску новой продукции я хочу иметь возможность отслеживать покупки наших клиентов, чтобы быть в курсе, какие книги им можно предлагать. Список можно продолжать и продолжать, метод очень полезен и позволяет закрывать огромное кол-во задач.
Scrum – Истории пользователей
Для этого у нас есть BDD («разработка через поведение») и язык gherkin. Это означает, что для того чтобы чтобы сделать нашу user story проверяемой, мы можем переписать ее в формате gherkin. Нужно проконсультироваться
на этот счет с реальными пользователями
или их представителями. Или, если мы не
можем ни у кого спросить, придется
строить предположения самостоятельно.
В истории пользователей можно включить неработающие требования. В данном примере ATM банкомат, доступный пользователю 24X7, 365 дней, является нефункциональным требованием, которое может быть описано в прецеденте. В проектах Scrum продукт Backlog представляет собой список пользовательских историй. Эти Истории пользователей приоритетны и взяты в Спринт Backlog в Спринт Планирование совещания. В 1999 году Кент Бек придумал термин «Истории пользователей» для функций продукта. Он описал, что «Пользовательская история» передается с точки зрения пользователя относительно того, что он или она хочет иметь, а что система может для него сделать.
примеров юзер стори и эпиков
Таким образом, представление полностью изменилось с продукта на пользователя, а User Stories стал стандартом de facto для требований во всех инфраструктурах Agile. И это индикатор очень
важной проблемы в написании требований. И хотя наша цель –
удовлетворить пользователя, нам все же
стоит сосредоточиться в первую очередь
на его желаниях. Нам стоит придавать
больше значения его целям, чем собственным. Пользовательские истории написаны на протяжении всего гибкого проекта. Обычно семинар по написанию историй проводится в начале.
Если история пользователя у вас не одна (а это скорее всего так), то вы расставляете приоритеты между ними и берете в работу “самую наболевшую” у пользователей, а после переходите к следующей. Таким образом https://deveducation.com/ на первом плане у вас стоит всегда интерес пользователя и каждая следующая функциональность выпущенная в релизе, будет востребована. Изначально данный термин появился в гибких методологиях разработки.
Используйте Персонажей для поиска правильных историй
Расскажу, как избегать всего этого с помощью пользовательских историй. Сценарии использования, в отличие от пользовательских историй, описывают процесс и его шаги подробно и могут быть сформулированы с точки зрения формальной модели. Он обеспечивает всю необходимую информацию и детали для user stories это понимания. Сценарий описывается как «обобщенное описание ряда взаимодействий между системой и одним или более агентами, где агент — пользователь или другая система». В экстремальном программировании (XP) пользовательские истории создаются совместно разработчиками и представителем клиента.
Написание пользовательских историй
Команды высчитывают оценки в размерах футболок, баллах из последовательности Фибоначчи или с помощью покера планирования. User Stories Applied – самая лучшая и полная книга о том, как писать, оценивать, тестировать и принимать пользовательские истории. Процесс разработки мобильного приложения состоит из нескольких последовательных этапов. Первоначальным и в итоге во многом определяющим конечный результат является написание User Story. Если вовлечь команду разработки нельзя, подумайте над использованием другой техники для определения функциональности продукта — Use Cases (кейсы использования продукта).