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

В 1999 году Кент Бек придумал термин «Истории пользователей» для функций продукта. Он описал, что «Пользовательская история» передается с точки зрения пользователя относительно того, что он или она хочет иметь, а что система может для него сделать. Таким образом, представление полностью изменилось с продукта на пользователя, а User Stories стал стандартом de facto для требований во всех инфраструктурах Agile.

В проектах Scrum продукт Backlog представляет собой список пользовательских историй. Эти Истории пользователей приоритетны и взяты в Спринт Backlog в Спринт Планирование совещания.

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

Структура пользовательской истории

Структура User Story выглядит следующим образом:

  • Как <Тип пользователя> ,
  • Я хочу <Выполнять некоторые задачи> ,
  • Чтобы <я мог достичь некоторой цели / выгоды / ценности> .

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

Владелец продукта отвечает за отставание продукта и, следовательно, за Истории пользователей. Однако это не означает, что только владелец продукта пишет истории пользователей. Любой человек из команды Scrum может писать истории пользователей, и деятельность может быть распространена по всему проекту, так как требования становятся уточненными, а новые функции добавляются.

Нефункциональные требования в пользовательских историях

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

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

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

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

  • Основное преимущество User Story заключается в определении самого пользователя. Это связано с тем, что в конечном итоге именно пользователь будет использовать продукт в соответствующих сценариях пользователя. Он соединяет конечных пользователей с членами команды.
  • Синтаксис самой пользовательской истории обеспечивает захват цели или выгоды или ценности, которые пользователь хочет достичь.
  • Поскольку критерии приемки являются частью самой пользовательской истории, это будет дополнительным преимуществом для команды Scrum.
  • В ходе выполнения проекта можно внести изменения в историю пользователей. Если масштаб истории пользователя становится большим, его нужно разделить на более мелкие истории пользователей. Условия в критерии приема также могут быть изменены.
  • По мере того, как рабочие изменения продукта доставляются пользователям в конце каждого спринта, команда scrum может получать обратную связь от пользователей в собрании по обзору спринта. Это позволяет непрерывно вводить обратную связь в продукт.