1

我对用户故事的卡片、对话、确认公式一无所知。我不明白是否必须写下对话和确认部分，或者它们仍然作为对话，特别是对话部分。需要明确的是：在用户故事中写下所有这些内容是否正确？（见下面的例子）或者我只需要写下 CARD 部分吗？

例子：

CARD 作为咖啡机的用户，我希望能够购买饮料。

CONVERSATION - 如果用户没有向 CoffeeMaker 存入足够的钱，他们将无法购买饮料 - 如果没有足够的库存来制作饮料，用户的钱将被退回

确认 1 用户介绍购买饮料所需的金额 2 用户选择饮料 3 用户获得饮料

4

2 回答 2

2

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（业务驱动开发）技术

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

如果您想了解更多信息，我建议您研究INVEST原则并阅读 Mike Cohn 的User Stories Applied。

于 2013-10-20T09:19:20.047 回答
0

你可以做任何你想做的事情；），从写下一切到记住一切，什么也不写。就我个人而言，我把所有的东西都写下来，所以下一个接手这个故事的开发人员可以和我一样理解并从那里接起来。

于 2013-10-19T15:46:49.897 回答