Вам бонус- начислено 1 монета за дневную активность. Сейчас у вас 1 монета

Пользовательские истории (User Story) как способ описания требований

Лекция



Привет, Вы узнаете о том , что такое пользовательские истории, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое пользовательские истории, user story , настоятельно рекомендую прочитать все из категории Разработка программного обеспечения и информационных систем.

пользовательские истории (англ. User Story) — способ описания требований к разрабатываемой системе, сформулированных как одно или более предложений на повседневном или деловом языке пользователя. Пользовательские истории используются гибкими методологиями разработки программного обеспечения для спецификации требований (вместе с приемочными испытаниямиruen). Каждая пользовательская история ограничена в размере и сложности. Часто история пишется на маленькой бумажной карточке. Это гарантирует, что она не станет слишком большой. В Экстремальном программировании пользовательские истории пишутся пользователями (заказчиками) системы. В методологии SCRUM — проходят проверку пользователем в роли «Владелец продукта» (англ. Product Owner). Для заказчиков (пользователей) пользовательские истории являются основным инструментом влияния на разработку программного обеспечения.

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

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

Пользовательские истории (User Stories) - это методология описания требований в разработке программного обеспечения, который был впервые предложен в рамках Agile-подхода к управлению проектами и разработке. Они представляют собой краткие, но информативные описания функциональных требований, сфокусированные на потребностях пользователей. Пользовательские истории обычно содержат следующие элементы:

  1. Роль (Role): Кто будет использовать функцию или какую роль она затрагивает (например, "пользователь", "администратор", "гость" и т.д.).

  2. Действие (Action): Что пользователь или роль планирует сделать с системой или функцией (например, "просматривать", "создавать", "редактировать" и т.д.).

  3. Цель (Goal): Зачем пользователь или роль хочет выполнить это действие (например, "просмотреть список товаров", "создать новую задачу", "редактировать профиль пользователя" и т.д.).

  4. Польза (Benefit): Какую пользу получит пользователь или роль от выполнения этой задачи или действия (например, "быстрый доступ к необходимой информации", "повышение производительности" и т.д.).

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

В экстремальном программировании (XP) пользовательские истории создаются совместно разработчиками и представителем клиента. Об этом говорит сайт https://intellect.icu . Клиент ответственен за формулировку истории. Разработчик может использовать серию вопросов, чтобы подтолкнуть клиента и выяснить необходимость некоторых специфических функциональных возможностей. Но при этом разработчик должен быть осторожен и не доминировать над процессом создания идеи.

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

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

 
Как пользователь, я хочу просматривать список товаров,

чтобы мне было удобно выбирать и покупать необходимые товары онлайн.

Пользовательские истории (User Story) как способ описания требований

Использование

В методологии ХР пользовательские истории являются результатом планирования, и определяют то, что должно быть реализовано в программном проекте. Пользовательские истории приоритизируются клиентом по важности для системы, разбиваются на серию задач и оцениваются разработчиками.

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

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

Преимущества

XP и другие гибкие методологии предпочитают общение лицом к лицу вместо всесторонней документации; быструю адаптацию к изменениям вместо фиксации на проблеме. Это достигается следующим:

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

Преимущества использования пользовательских историй:

  1. Ориентированность на пользователей: Пользовательские истории акцентируют внимание на потребностях и ценностях пользователей, что способствует созданию более полезного и удовлетворительного продукта.

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

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

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

  5. Тестирование: Они могут служить основой для создания тестовых случаев и проверки выполнения требований.

Ограничения

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

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

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

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

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

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

Пользовательские истории и прецеденты |

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

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

См. раздел Вау!! 😲 Ты еще не читал? Это зря!

Вау!! 😲 Ты еще не читал? Это зря!

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

Из статьи мы узнали кратко, но содержательно про пользовательские истории
создано: 2023-10-10
обновлено: 2023-10-11
132265



Рейтиг 9 of 10. count vote: 2
Вы довольны ?:


Поделиться:

Найди готовое или заработай

С нашими удобными сервисами без комиссии*

Как это работает? | Узнать цену?

Найти исполнителя
$0 / весь год.
  • У вас есть задание, но нет времени его делать
  • Вы хотите найти профессионала для выплнения задания
  • Возможно примерение функции гаранта на сделку
  • Приорететная поддержка
  • идеально подходит для студентов, у которых нет времени для решения заданий
Готовое решение
$0 / весь год.
  • Вы можите продать(исполнителем) или купить(заказчиком) готовое решение
  • Вам предоставят готовое решение
  • Будет предоставлено в минимальные сроки т.к. задание уже готовое
  • Вы получите базовую гарантию 8 дней
  • Вы можете заработать на материалах
  • подходит как для студентов так и для преподавателей
Я исполнитель
$0 / весь год.
  • Вы профессионал своего дела
  • У вас есть опыт и желание зарабатывать
  • Вы хотите помочь в решении задач или написании работ
  • Возможно примерение функции гаранта на сделку
  • подходит для опытных студентов так и для преподавателей



Комментарии


Оставить комментарий
Если у вас есть какое-либо предложение, идея, благодарность или комментарий, не стесняйтесь писать. Мы очень ценим отзывы и рады услышать ваше мнение.
To reply

Разработка программного обеспечения и информационных систем

Термины: Разработка программного обеспечения и информационных систем