Использование пользовательских историй для автоматизированной, запланированной или реактивной функциональности

Question

Мне было интересно, что думают об использовании пользовательских историй для описания автоматизированных, запланированных или реактивных функций. Например, что вы делаете, когда у вас есть что-то вроде процесса выполнения заказа, который включает в себя извлечение заказа из очереди, подготовку «формы заполнения заказа», отправку формы в центр обработки заказов, а затем ожидание какого-либо подтверждения от обрабатывающий центр, такой как «заказ выполнен» или «ошибка выполнения заказа: причины ...» и т. д. Имейте в виду, что единственным вмешательством пользователя в течение всего этого процесса было бы при вводе заказа. Можно всегда утверждать, что процесс выполнения - это то, что может подразумеваться из истории ввода заказа, или что это деталь реализации, но мне кажется, что процесс выполнения слишком велик, чтобы просто принять его, как подразумевается из записи заказа. пользовательская история или как детали реализации. Такое ощущение, что должно быть описание самого исполнения как истории.

В частности, аспекты, которые меня интересуют при написании пользовательской истории для автоматизированных, запланированных или реактивных функций, с чьей точки зрения это должно быть описано? Учитывая, что мы используем формат истории, такой как «Как [роль], я хочу [функциональность], чтобы [цель]», какова роль в «Как [роль]» части истории, и какова цель в «так что [цель]» часть истории? Функциональность обычно достаточно ясна, но роль и цель кажутся немного относительными. Например, я мог бы использовать систему в качестве отправной точки и написать что-то вроде: «Как система / агент выполнения заказов, я хочу иметь возможность получить заказ из очереди выполнения, подготовить форму заказа на заполнение и отправить ее по адресу центр обработки заказов, так что заказ может быть выполнен ". Или, в качестве альтернативы, я мог бы взглянуть на вещи с точки зрения бизнеса и написать что-то вроде: «Как получатель заказа, я хочу иметь возможность обрабатывать заказы, введенные клиентами, чтобы я мог выполнять свои обязанности перед своими клиентами и отдавать им то, что они хотят "(или что-то в этом роде). Тем не менее, я мог бы также написать это с точки зрения клиента и сказать что-то вроде: «Как клиент, я хочу, чтобы моя запись заказа была обработана / выполнена так, чтобы я мог получать то, что я хочу».

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

Answer 1

Это может помочь отойти от традиционного шаблона пользовательской истории и перейти к ориентированному на заинтересованные стороны формату внедрения функций (BDD в пространстве анализа):

In order to <achieve a goal>
As <the stakeholder>
I want <someone to do something for me>.

Вы можете выяснить, кто является заинтересованным лицом, подумав о том, кто будет готов заплатить за рассказ, который будет доставлен. Например, блоки CAPTCHA - те раздражающие вещи, которые пользователи должны заполнять, - сделаны для пользы модератора или для того, чтобы сделать сайт более привлекательным для получения дохода, а не для пользы пользователя вообще! Фактически, когда вы думаете о большинстве сайтов, приложений и т. Д., Они вряд ли когда-либо будут сделаны для пользователя. Большинство сайтов о доходах от рекламы. В большинстве корпоративных приложений один департамент вводит данные, чтобы их мог использовать другой департамент, или чтобы клиенты могли брать деньги.

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

In order to make sales
As the Sales Head
I want customers to be notified of any errors with their order.

In order to make sales
As the Sales Head
I want customers' orders to be fulfilled within 24 hours.

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

In order to fulfil customer's orders within 24 hours...

Теперь каждая история может быть прослежена до видения проекта, и вы можете увидеть все системы в игре. Таким образом, ваши автоматизированные сценарии могут выглядеть так:

Given a valid order in the queue
When the order fulfilment system runs
Then it should send a fill order form to the processing centre
When the processing centre responds successfully
Then the successful fulfillment should be logged
And the customer should be notified by email.

Given an invalid order in the queue
When the order fulfilment system runs
Then it should send a fill order form to the processing centre
When the processing centre responds with an error
Then the error should be logged
And the customer should be notified of the problem by email.

Например.

Кстати, если вы думаете о переходе на этот формат сейчас, помните, что прозрачность, которую он создает, может вызвать абсолютный хаос у людей, которые, скажем, развиваются, потому что у них есть бюджет, а не надлежащий видение проекта. Я думаю, что это хорошо. Другие находят политику менее удобной! Удачи, что бы вы ни решили.