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

Question

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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