Что такое пользовательская история?

Что такое пользовательская история?

Пользовательская история — это запись, которая фиксирует то, что пользовательделает или должен сделать в рамках своей работы. Каждая пользовательская история состоит из краткого описания, написанного с точки зрения пользователя, на естественном языке. В отличие от традиционного сбора требований, пользовательская история фокусируется на том, что нужно пользователю, а не на том, что система должна предоставить. Это оставляет место для дальнейшего обсуждения решений и результата в виде системы, которая действительно соответствует бизнес-процессам клиентов, решая их операционные проблемы и, что наиболее важно, добавляя ценность организации.

Концепция 3C

3C относятся к трем критически важным аспектам качественных пользовательских историй. Эта концепция была предложена Роном Джеффризом, соизобретателем практики пользовательских историй. В настоящее время, когда мы говорим о пользовательских историях, мы обычно имеем в виду те истории, которые состоят из этих трех аспектов.

1. Карточка – Пользовательские истории записываются в виде карточек. Каждая карточка пользовательской истории содержит короткое предложение с достаточным количеством текста, чтобы напомнить всем, о чем идет речь.
2. Разговор – Требования находятся и уточняются через непрерывные разговоры между клиентами и командой разработки на протяжении всего жизненного цикла проекта программного обеспечения. В ходе встреч с заинтересованными сторонами будут выявлены и зафиксированы важные идеи и решения.
   
3. Подтверждение – или также известное как критерии приемки пользовательской истории. В ходе обсуждения требований клиент сообщает аналитику не только о том, чего он хочет, но и подтверждает, при каких условиях и критериях работающий программный продукт будет принят или отклонен. Определенные случаи записываются как подтверждение. Обратите внимание, что подтверждение направлено на проверку правильности выполнения соответствующей пользовательской истории. Это не интеграционное тестирование.
   

Как выявить пользовательскую историю?

Пользовательские истории должны выявляться совместно с заинтересованными сторонами, предпочтительно на личной встрече. Пользовательская история — это процесс выявления требований, а не процесс предварительного анализа требований. В традиционных подходах сбора требований системный аналитик пытается понять потребности клиентов, а затем подробно подготовить спецификацию требований для системы. Так работает не подход пользовательских историй. Вместо процесса документирования, выявление пользовательской истории скорее похоже на процесс записи заметок. В ходе обсуждений с пользователями мы слушаем и понимаем их проблемы и потребности, а затем сразу записываем их потребности в виде пользовательских историй. Эти пользовательские истории станут источником требований. Подробности могут быть заполнены вовремя, обеспечивая команду «достаточными» ссылками на требования на протяжении всего процесса разработки проекта.

Сопоставление бизнес-процессов с пользовательскими историями

BPMN — один из самых мощных инструментов для бизнес-анализа и моделирования. Мы можем не только использовать его для улучшения процессов, но и выявлять пользовательские истории из тех процессов, которые предназначены для автоматизации, следуя следующим шагам:

1. Просто смоделируйте рабочий процесс пользователя с помощью диаграммы бизнес-процессов BPMN.
2. Пройдитесь по модели процесса вместе с пользователями.
3. И проанализируйте бизнес-деятельность проблемы, а затем выявите пользовательские истории, связанные с процессом, который необходимо автоматизировать, что также известно как сопоставление бизнес-процессов с пользовательскими историями.

Как писать пользовательскую историю?

При написании пользовательской истории попробуйте писать от лица пользователя в форме, указанной ниже (или, по крайней мере, убедитесь, что то, что вы написали, соответствует следующему утверждению):

Я как <роль>, хочу <бизнес-цель>, чтобы <бизнес-ценность/причина>.

Например, как клиент, я хочу получить SMS, когда товар придет чтобы я мог иди забери его.

где:

1. <роль> представляет собой человека, систему, подсистему или любое другое существо, которое будет взаимодействовать с системой, которая будет реализована, для достижения цели. Он или она получит ценность, взаимодействуя с системой.
2. <бизнес-цель> представляет ожидание пользователя, которое может быть достигнуто за счет взаимодействия с системой.
3. <бизнес-ценность> представляет ценность, стоящую за взаимодействием с системой.

Это не правило, а руководство, которое помогает вам думать о пользовательской истории, учитывая следующее:

1. История пользователя принесет ценность кому-либо или определенной стороне (например, клиентам).
2. История пользователя удовлетворяет потребность пользователя (например, получить SMS, когда товар придет)
3. Есть причина поддерживать реализацию этой пользовательской истории (например, клиент может прийти и забрать купленный товар)

Каждая пользовательская история должна приносить ценность кому-либо. Но иногда ценность очевидна просто из прочтения бизнес-цели. Записывать ценность как часть заявления утомительно. В таком случае мы просто пропустим ее. Вот несколько примеров:

Я как клиент хочу оплатить с помощью кредитной картычтобы я мог использовать свою кредитную карту при онлайн-покупках.

Я как пользователь хочу выполнять поиск, введя имя своего другачтобы я мог найти своего друга по имени.

Неважно, как вы пишете пользовательскую историю, есть два момента, которые вы должны помнить. Во-первых, пользовательская история должна быть написана с точки зрения пользователя. Во-вторых, оставьте описание «всего лишь достаточным». Избегайте добавления слишком много деталей на начальном этапе разработки программного обеспечения. Позже у вас будет возможность уточнить и детализировать пользовательскую историю, чтобы она стала чем-то, что может быть использовано разработчиками при проектировании и реализации.

Жизненный цикл пользовательской истории

В широком смысле, на протяжении всего проекта программного обеспечения существует шесть основных состояний для каждой пользовательской истории:

1. Ожидание – В ходе общения между пользователем и командой проекта находятся пользовательские истории. В этом состоянии пользовательские истории имеют лишь краткое описание потребности пользователя. Пока нет подробного обсуждения требований, нет логики системы и нет разработки интерфейса. Фактически, единственная цель пользовательской истории на данный момент — напоминать всем участникам о будущем обсуждении запроса пользователя, записанного в этой пользовательской истории (карточке). Возможно, в будущем пользовательская история будет отклонена.
2. К выполнению – В ходе обсуждения между различными заинтересованными сторонами определяются пользовательские истории, которые будут рассмотрены в ближайшие недели, и они помещаются в ограниченный по времени период, называемый спринтом. Такие пользовательские истории считаются находящимися в состоянии «К выполнению». В этом состоянии еще не проводилось подробное обсуждение.
3. Обсуждение – Когда пользовательская история находится в состоянии «Обсуждение», конечный пользователь будет общаться с командой разработки для подтверждения требований и определения критериев приемки. Команда разработки будет записывать требования или любые решения в виде заметок к разговору. Специалист по UX может создать макеты или сценарии, чтобы пользователь мог предварительно просмотреть предлагаемые функции в визуальных макетах и почувствовать их. Этот процесс известен как проектирование пользовательского опыта (UX-дизайн).
   
4. Разработка – После того, как требования будут уточнены, команда разработки разработает и реализует функции для выполнения запросов пользователя.
5. Подтверждение – После того, как команда разработки реализовала пользовательскую историю, она будет подтверждена конечным пользователем. Ему/ей будет предоставлен доступ к тестовой среде или к полуготовому программному продукту (иногда называемому версией альфа) для подтверждения функции. Подтверждение будет выполнено на основе пунктов подтверждения, указанных при детализации пользовательской истории. Пока подтверждение не будет завершено, пользовательская история считается находящейся в состоянии Подтверждения.
6. Завершено – Наконец, функция подтверждена как завершенная, пользовательская история считается завершенной. Обычно это конец пользовательской истории. Если у пользователя появится новое требование, будь то новая функция или улучшение завершенной пользовательской истории, команда создаст новую пользовательскую историю для следующей итерации.

Детализация пользовательской истории – когда и зачем?

Ключевое отличие пользовательской истории от традиционных подходов к сбору требований заключается в том, что подход пользовательской истории разделяет определение проблемы и решения на два этапа, выполняемых на разных стадиях разработки программного обеспечения. В то время как проблемы и краткое понимание запросов пользователей определяются на начальном этапе проекта, детали системных требований выявляются только непосредственно перед началом проектирования и реализации. Вот некоторые преимущества такой организации:

1. Возможность оперативно реагировать на актуальные потребности пользователей, поскольку требования детализируются непосредственно перед реализацией, а не завершаются на начальном этапе.
2. Легче определить правильные требования, поскольку как проблемы, так и решения проходят детальное обсуждение. В традиционных подходах, поскольку детали всех требований должны быть определены на начальном этапе проекта, «предварительные требования» могли измениться с течением времени, что привело к значительным потерям аналитических усилий.
3. – С другой стороны, пользовательские истории, которые признаны недействительными, можно легко отбросить. Вы не тратите много времени на предварительное изучение и документирование

Как эффективно использовать пользовательскую историю?

Как и многие другие методологии разработки программного обеспечения, если вы правильно применяете пользовательскую историю в своем проекте, вы сможете создать качественную программную систему и завоевать доверие и удовлетворенность клиентов. Вот некоторые моменты, которые следует учитывать при использовании пользовательской истории:

1. Держите описание пользовательской истории кратким.
2. Думайте с точки зрения конечного пользователя при написании пользовательской истории.
3. Использование (UML) представляет бизнес-цель. Возможность группировать пользовательские истории под использованием позволяет убедиться, что пользовательская история соответствует бизнес-цели, другими словами, они разделяют одну и ту же системную цель. Это служит местом для хранения, чтобы управлять, планировать и приоритизировать пользовательские истории более удобным способом.
4. Пункты подтверждения должны быть определены до начала разработки
5. Оцените пользовательскую историю до реализации, чтобы убедиться, что нагрузка вашей команды находится под контролем.
6. Требования определяются совместно с конечными пользователями, а не только конечным пользователем или только командой разработки. Поддержание хорошей связи с конечными пользователями будет взаимовыгодным решением для обеих сторон.
7. Коммуникация всегда важна для понимания того, чего хочет конечный пользователь.

Visual Paradigm предоставляет все инструменты, которые вам нужны в агильной разработке программного обеспечения, которые включают в себя инструмент диаграммы использования UML, (агильный) пользовательская история, спринт, сценарий и макеты для проектирования пользовательского опыта, инструмент управления задачами, и т.д.