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

Question

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

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

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

Answer 1

Это могло бы помочь отойти от традиционного шаблона пользовательской истории и к формату заинтересованных ориентированных на Feature Injection (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. 

Например,

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