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

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.

Например.

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