Должен ли актер истории пользователя быть человеком?

Истории пользователей традиционно записываются как выражение "Как [Тип пользователя] Я хочу [функцию], чтобы [какая-то польза]". В книгах и онлайн-ресурсах [Тип пользователя] обычно соответствует роли человека. Однако при описании функций внутренних систем системы часто проще разместить некоторую автоматическую службу вместо пользователя, например. "Как ServiceX я хочу, чтобы некоторые данные регулярно обновлялись, чтобы я мог делать XYZ с использованием самой последней информации".

Такая форма позволяет легко писать легко воспринимаемые приемочные тесты для связанных частей системы. Но является ли это концептуально правильным? Разве пользовательские истории не должны основываться на функциях, дающих значение бизнес, а так как системы и службы не заинтересованы в получении бизнес-ценностей, они не должны быть субъектами пользовательских историй?

Ответ 1

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

Ответ 2

Я не понимаю, почему актер должен быть человеком - ваш пример - отличная причина для того, чтобы этого не было.

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

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

Ответ 3

Вот секрет. Это не пользовательские истории, но они являются пользовательскими сценариями.

пользователь - это то, что делает взаимодействие - машина или человек.

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

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

Например, инвесторы Twitter хотят, чтобы пользователи пользовались Twitter, чтобы они могли сохранить все свои возможности для зарабатывания денег в будущем. Боссы хотят, чтобы их секретари использовали текстовые процессоры, чтобы они могли быстрее набирать буквы и менять свое мнение в последнюю минуту. StackOverflow хочет, чтобы большие должности поддерживались, чтобы получать доход от рекламы.

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