Пользовательские истории - Карточка, разговор и подтверждение

Question

Я ничего не понимаю в формуле карты, разговора, подтверждения для пользовательских историй. Я не понимаю, должна ли быть записана часть разговора и подтверждения, или они остаются в виде диалога, в частности, части разговора. Чтобы было ясно: правильно ли записывать ВСЕ эти вещи в истории пользователей? (см. пример ниже) Или я должен записать только часть CARD?

Пример:

КАРТОЧКА Как пользователь кофемашины, я хочу иметь возможность купить напиток.

РАЗГОВОР - Пользователь не сможет купить напиток, если он не внесет достаточное количество денег в Кофеварку. - Деньги пользователя будут возвращены, если для приготовления напитка недостаточно инвентаря

ПОДТВЕРЖДЕНИЕ 1 пользователь вводит сумму денег, необходимую для покупки напитка 2 пользователь выбирает напиток 3 пользователь получает напиток

Answer 1

3 C - это высказывание, которое служит напоминанием о том, что важно при использовании пользовательских историй.

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

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

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

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

Формат пользовательской истории обычно будет следующим:

As a (role) - This can be an end user or a business proxy

I want - A description of what need to be done

So that - the definition of the value

Попытка по вашему сценарию

As a vending machine customer

I want my change returned 

So that I do not loose my money

Часть подтверждения могла быть просто точками с маркером на спине

• Изменение должно быть возвращено, если клиент не вкладывает достаточно денег, а затем выбирает напиток

Или вы можете использовать стиль спецификации контекста, метод BDD (Business Driven Development)

Given a customer does not put in enough money
When they select a beverage
Then their change should be returned

Если вы хотите узнать больше, я бы посоветовал изучить принципы ИНВЕСТА и прочитать Приложенные пользовательские истории Майка Кона.

Answer 2

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