Как вы уже поняли, пользовательские истории обычно используются для описания функций продукта и являются частью Скрам-артефактов — Журнал невыполненных работ по продукту и Журнал ожидания по спринту .
Пользовательские истории
В разработке программного обеспечения особенности продукта играют решающую роль. Это те функции, которые пользователь в конечном итоге любит использовать в конечном продукте. Они известны как Требования в общей терминологии. Успех проекта по разработке программного обеспечения заключается в точном и правильном понимании требований пользователя, а затем их внедрении в конечный продукт. Таким образом, требования или особенности продукта должны быть полностью известны команде разработчиков проекта.
В 1999 году Кент Бек предложил термин «Истории пользователей» для функций продукта. Он описал, что история пользователя рассказывается с точки зрения пользователя относительно того, что он или она хочет иметь, а не того, что система может сделать для него. Таким образом, представление полностью изменилось от продукта к пользователю, и пользовательские истории стали стандартом де-факто для требований во всех средах Agile.
В проектах Scrum Product Backlog — это список пользовательских историй. Эти пользовательские истории располагаются по приоритетам и заносятся в список невыполненных работ на совещании по планированию спринта.
Оценка также основана на пользовательских историях, а размер продукта оценивается в баллах пользователей.
Структура пользовательской истории
Структура User Story выглядит следующим образом:
Как <Тип пользователя> ,
Я хочу <Выполнить некоторую задачу> ,
Так что <я могу достичь какой-то цели / выгоды / ценности> .
Давайте посмотрим, как создается пользовательская история для сценария, когда Клиент Банка снимает наличные в банкомате.
История пользователя: снятие наличных с клиента
Как клиент ,
Я хочу снять наличные в банкомате ,
Чтобы мне не пришлось ждать в очереди в банке
Критерии принятия истории пользователя
В каждой пользовательской истории также определен критерий принятия, так что правильность реализации пользовательской истории подтверждается путем прохождения приемочного теста, основанного на критерии принятия.
Ниже приведен примерный критерий приемлемости для примера пользовательского рассказа «Снятие наличных».
Критерий принятия 1:
Учитывая, что аккаунт кредитоспособен
- И карта действительна
- И диспенсер содержит деньги,
Когда клиент запрашивает наличные
Затем убедитесь, что учетная запись списана
- И убедитесь, что деньги выдаются
- И убедитесь, что карта возвращается.
Критерий приемки 2:
С учетом того, что счет списан
- И карта действительна
Когда клиент запрашивает наличные
Затем убедитесь, что сообщение об отказе отображается
- И убедитесь, что деньги не выдаются
- И убедитесь, что карта возвращается.
Написание пользовательских историй
Владелец продукта отвечает за Журнал незавершенного производства и, следовательно, за Пользовательские истории. Однако это не значит, что только владелец продукта пишет пользовательские истории. Любой участник Scrum Team может написать пользовательские истории, и деятельность может быть распределена по проекту по мере уточнения требований и добавления новых функций.
Нефункциональные требования в пользовательских историях
Нефункциональные требования можно включить и в пользовательские истории. В данном примере банкомата, банкомат, который должен быть доступен пользователю 24X7, 365 дней, является нефункциональным требованием, которое можно описать с помощью варианта использования.
Управление пользовательскими историями
Пользовательские истории управляются в журнале незавершенного производства. Пользовательские истории упорядочены в соответствии с приоритетом. Наиболее приоритетные пользовательские истории уточняются до детального уровня, в то время как наименее приоритетные пользовательские истории хранятся на более низком уровне детализации. Для каждого спринта в журнал ожидания спринта включаются наиболее приоритетные и, следовательно, более детализированные пользовательские истории. Если пользовательский журнал должен быть добавлен в журнал невыполненных работ, сначала определяется его приоритет, и он размещается в соответствии с его местом в соответствии с приоритетом. Пользовательские истории могут быть переориентированы в любое время. Также возможно удалить любую из пользовательских историй, если требуется.
Преимущества с пользовательскими историями
-
Основное преимущество User Story заключается в самом определении, ориентированном на пользователя. Это потому, что, в конечном счете, именно пользователь будет использовать продукт в соответствующих пользовательских сценариях. Он соединяет конечных пользователей с членами команды.
-
Синтаксис самой пользовательской истории обеспечивает фиксацию цели, выгоды или ценности, которые пользователь хочет достичь.
-
Поскольку критерии принятия являются частью самой пользовательской истории, это будет дополнительным преимуществом для Scrum Team.
-
Можно внести изменения в пользовательскую историю в ходе выполнения проекта. Если область действия пользовательской истории становится большой, ее необходимо разделить на более мелкие пользовательские истории. Условия в критерии приемки также могут быть изменены.
-
Поскольку приращения рабочего продукта доставляются пользователям в конце каждого спринта, команда Scrum может получать отзывы от пользователей на собрании по рассмотрению спринта. Это позволяет постоянно включать обратную связь в продукт.
Основное преимущество User Story заключается в самом определении, ориентированном на пользователя. Это потому, что, в конечном счете, именно пользователь будет использовать продукт в соответствующих пользовательских сценариях. Он соединяет конечных пользователей с членами команды.
Синтаксис самой пользовательской истории обеспечивает фиксацию цели, выгоды или ценности, которые пользователь хочет достичь.
Поскольку критерии принятия являются частью самой пользовательской истории, это будет дополнительным преимуществом для Scrum Team.
Можно внести изменения в пользовательскую историю в ходе выполнения проекта. Если область действия пользовательской истории становится большой, ее необходимо разделить на более мелкие пользовательские истории. Условия в критерии приемки также могут быть изменены.
Поскольку приращения рабочего продукта доставляются пользователям в конце каждого спринта, команда Scrum может получать отзывы от пользователей на собрании по рассмотрению спринта. Это позволяет постоянно включать обратную связь в продукт.
Заключение
Пользовательские истории Scrum приближают пользователей к команде Scrum и предотвращают сюрпризы в последнюю минуту.