Варианты использования против пользовательских историй: разница между вариантами использования и пользовательскими историями

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

Варианты использования и пользовательские истории отличаются друг от друга во многих аспектах. Они преследуют разные цели. Несмотря на то, что они могут иметь схожие функциональные возможности, концепции являются полюсами друг от друга.

Посетите бесплатные курсы, чтобы повысить свою квалификацию

В этой статье мы обсудим варианты использования и пользовательские истории с примерами, а также объясним, чем пользовательские истории отличаются от вариантов использования . Мы также рассмотрим необходимость этих двух подходов и почему они пересекаются.

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

Вариант использования отражает процесс, связанный с достижением цели желаемого продукта. Это требование системы, которое помогает получить продукт. Он работает как описание продукта для актеров (или пользователей), которые будут его использовать. С технической точки зрения, это взаимодействие между системой и действующими лицами посредством описания.

Некоторые из критических элементов вариантов использования:

• Актер: Человек или группа людей, которые взаимодействуют с системой.
• Цель: конечный результат, для которого разрабатываются варианты использования.
• Система: все шаги, необходимые для достижения цели

Сценарии использования имеют причинно-следственную связь, которая включает в себя определенные события, в которых функции или особенности продукта описываются конечному пользователю. Он обеспечивает детальное понимание поведения пользователя при взаимодействии с системой.

Команда разработчиков использует варианты использования при проектировании, тестировании и разработке продуктов. Это помогает им наметить требования к тому, как должно быть разработано справочное руководство пользователя. Наряду с этим, они также могут устранять ошибки.

Варианты использования — это подробные описания продукта для заинтересованных сторон или конечных пользователей.

Пример варианта использования

Давайте возьмем пример приложения бренда одежды, созданного для удовлетворения потребностей клиентов в доставке одежды и аксессуаров. Клиенты просматривают приложение, выбирают наиболее подходящие товары и размещают заказ. При оформлении заказа они могут оплатить заказ онлайн или после доставки. После подтверждения со стороны клиента он получает письмо с подтверждением или уведомление о «размещении заказа».

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

• Система – приложение электронной коммерции
• Основное действующее лицо – заказчик
• Сценарий — просмотр приложения

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

• Пользователь выбирает элемент.
• Информация об оплате и доставке
• Подтверждение заказа и оформление
• Время обратного отсчета заказа или отслеживание
• Платежная информация

Давайте перейдем к пользовательским историям и поймем, чем пользовательские истории отличаются от вариантов использования.

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

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

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

• Карточка: Пользовательские истории должны быть написаны в виде карточек, что означает короткие и четкие истории со всей необходимой информацией.
• Разговор: пользовательская история должна быть разговором между клиентами и разработчиками через программное обеспечение.
• Подтверждение: это означает, что клиенты подтверждают определенные условия, которые должны быть выполнены до получения результата.Система должна быть в состоянии выполнить его должным образом.

Помимо этих трех составляющих пользовательской истории, она также фокусируется на еще одной важной цели: ИНВЕСТИРОВАТЬ. Это означает

• Независимый :от других проектов
• Возможен торг :место для дальнейшего развития
• Ценность :описание для пользователей
• Достойный оценки :пользовательская история для выполнения надлежащего плана
• Маленький :рабочие дни, чтобы закончить работу в течение 3-5 дней
• Тестируемый :механизм проверки ценности или достоверности процесса.

Пример пользовательской истории

Пользовательские истории выражаются следующим образом:

«Как (персона) я (хочу), (чтобы)».

• Как (персонаж) — человек, для которого создано приложение или программное обеспечение. Он должен подчеркивать конечного пользователя.
• Я (хочу) – Здесь описывается намерение, а не особенности. Он должен описывать цель пользователя, а не часть приложения или пользовательского интерфейса.
• (Так что) — это описывает общую выгоду или общую картину приложения. Какова общая выгода, которую получит конечный пользователь?

Вот несколько примеров пользовательских историй

• Как Эли, я хочу привязать свою кредитную карту к своему профилю, чтобы я мог легко платить за аренду без наличных.
• Как менеджер, я хочу организовать свою работу так, чтобы чувствовать больше контроля.

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

Зачем нужны Use Case и User Story?

Есть несколько причин, по которым нам нужны как варианты использования, так и пользовательские истории в нашей системе. Давайте углубимся в цель пользовательской истории и варианта использования:

Нам нужны варианты использования, чтобы…

• Управлять объемом работы
• Облегчение коммуникации между конечными пользователями и разработчиками
• Установить все требования
• Визуализируйте архитектуру системы
• Наметить структуру, посредством которой мы можем взаимодействовать с системой

Нам нужны пользовательские истории, чтобы –

• Создайте оптимизированный процесс
• Ставьте маленькие достижимые цели
• Держите технических и нетехнических пользователей на одной странице
• Дайте определение всему процессу

Ознакомьтесь с нашими программами по науке о данных в США

Разница между вариантом использования и пользовательской историей

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

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

Прочтите наши популярные статьи о науке о данных в США

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

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

Однако варианты использования используются для документирования процесса. Он состоит из всех требований процесса для достижения конечной цели. Сценарии использования рисуют более широкую картину существующей системы. Он включает в себя простые пункты для легкого процесса разработки.

Повысьте свою карьеру с upGrad

Правильное высшее образование может иметь большое значение для всех начинающих разработчиков и специалистов по данным. Если вы ищете возможность улучшить свои навыки и опыт, программа upGrad Executive PG в области науки о данных может стать отличным выбором. С помощью этого курса учащиеся получают выдающееся знакомство с техническим миром. WES и Институт аналитики признают ценность этого курса, созданного под руководством ведущих специалистов отрасли.

Заключение

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